Bab 3 · Kerangka SaaS Utama ProjectVIEW ERP
Perjanjian Tingkat Layanan ProjectVIEW ERP berkomitmen pada ketersediaan lingkungan production sebesar 99.9% per bulan, Recovery Point Objective 15 menit, dan Recovery Time Objective 4 jam. Insiden diklasifikasikan P1 sampai P4 dengan target respons dan penyelesaian (MTTR) yang ditetapkan — insiden P1 memperoleh respons segera dan target MTTR 4 jam, 24×7×365 — dan kinerja SLA dilaporkan setiap bulan serta ditinjau setiap kuartal.
- 99.9%ketersediaan bulanan (production)
- 15 menitRecovery Point Objective
- 4 jamRecovery Time Objective
- 4 jamtarget MTTR P1, 24×7×365
3.1 Ikhtisar SLA
Bagian ini mendefinisikan Service Levels yang menjadi komitmen Provider untuk dicapai dalam penyediaan dan dukungan Platform. Provider wajib menggunakan upaya yang secara komersial wajar untuk memenuhi atau melampaui Service Levels yang ditetapkan dalam Bagian ini saat menyediakan Services.
Service Levels mencakup ketersediaan platform, respons insiden, target penyelesaian, sasaran cadangan dan pemulihan, serta Service Credits terkait jika terjadi ketidakpatuhan.
SLA berlaku hanya untuk lingkungan production dari Platform. Lingkungan non-production (development, sandbox/test) dikecualikan dari pengukuran SLA kecuali ditentukan lain dalam Kontrak Komersial.
3.1 Ketersediaan Platform
3.1.1 Sasaran Tingkat Layanan (SLO)
Provider berkomitmen pada Sasaran Tingkat Layanan sebesar 99.9% uptime bulanan untuk lingkungan production Platform, yang diukur sebagai persentase dari total menit pada bulan kalender yang berlaku.
| Metrik | Target | Periode Pengukuran |
|---|---|---|
| Sasaran Tingkat Layanan (SLO) | 99.9% | Bulan kalender |
| Downtime Maksimum yang Diizinkan | 43.2 menit / bulan | Dihitung: (1 – 0.999) × 43,200 menit |
3.1.2 Perhitungan Ketersediaan
Ketersediaan Bulanan dihitung menggunakan rumus berikut:
Ketersediaan % = ((Total Menit – Menit Downtime) / Total Menit) × 100
Dengan:
- Total Menit = jumlah total menit dalam bulan kalender yang berlaku
- Menit Downtime = total menit saat lingkungan production tidak tersedia, tidak termasuk Scheduled Maintenance dan Excluded Events
3.1.3 Pemeliharaan Terjadwal
Provider harus melaksanakan pemeliharaan terjadwal selama Maintenance Windows yang telah disepakati sebelumnya. Scheduled Maintenance dikecualikan dari perhitungan Ketersediaan dengan ketentuan bahwa:
- (a) Provider memberikan kepada Customer pemberitahuan tertulis minimal 5 Hari Kerja sebelumnya untuk pemeliharaan terjadwal;
- (b) Pemeliharaan dijadwalkan pada Jam Off-Peak (antara pukul 22.00 dan 06.00 waktu setempat di lokasi utama Customer), kecuali disepakati lain;
- (c) Total Scheduled Maintenance tidak melebihi 4 jam per bulan kalender;
- (d) Provider menggunakan upaya yang secara komersial wajar untuk meminimalkan durasi dan dampak setiap jendela pemeliharaan. Pemeliharaan Darurat: Dalam hal terjadi kerentanan keamanan kritis atau kegagalan sistem yang akan segera terjadi, Provider dapat melakukan pemeliharaan darurat dengan pemberitahuan kurang dari 5 Hari Kerja. Provider wajib memberitahu Customer secepat yang secara wajar dapat dilakukan dan memberikan laporan pascapemeliharaan dalam waktu 2 Hari Kerja.
3.2 Siklus Hidup Lingkungan
Selama implementasi, Provider menyediakan dua (2) lingkungan yang berbeda untuk Customer:
| Fase | Lingkungan | Tujuan |
|---|---|---|
| Implementasi | Development / Sandbox | Konfigurasi, kustomisasi, migrasi data, pengujian integrasi, dan Universal User Acceptance Testing (UAT). Customer dan Provider bersama-sama memvalidasi seluruh persyaratan fungsional sebelum Go-Live. |
| Implementasi | Produksi | Lingkungan operasional langsung untuk seluruh Authorized User. Tunduk pada metrik SLA penuh yang didefinisikan dalam Bagian 3 ini. |
3.2.1 Transisi Lingkungan Pasca Go-Live
Setelah Go-Live, struktur lingkungan beralih sebagai berikut:
| Lingkungan | Peran Pasca Go-Live | Tujuan |
|---|---|---|
| Development / Sandbox | Staging Environment | Menjadi lingkungan staging permanen yang digunakan untuk: debugging dan reproduksi gangguan, permintaan perubahan dan pengembangan peningkatan, pembaruan perangkat lunak dan pengujian patch, serta Universal User Acceptance Testing (UAT) sebelum penerapan ke produksi. |
| Produksi | Lingkungan Produksi | Tetap berfungsi sebagai lingkungan operasional langsung. Tidak ada perubahan yang diterapkan ke produksi tanpa validasi sebelumnya dan persetujuan UAT di Staging Environment. |
Universal User Acceptance Testing (UAT): Seluruh perubahan perangkat lunak, patch, pembaruan, dan rilis fitur baru harus melalui UAT di Staging Environment sebelum diterapkan ke Production. Customer harus diberi waktu minimum 5 Hari Kerja untuk menyelesaikan UAT, dan penerapan ke Production mensyaratkan persetujuan tertulis Customer. Provider tidak boleh menerapkan perubahan apa pun ke Production Environment tanpa persetujuan UAT yang terkonfirmasi, kecuali dalam hal Emergency Maintenance sebagaimana didefinisikan dalam Bagian 3.1.3.
Provider harus menjaga kesetaraan lingkungan antara Staging dan Production untuk memastikan hasil UAT representatif terhadap perilaku produksi. Kedua lingkungan harus selalu menjalankan versi perangkat lunak, konfigurasi, dan kebijakan keamanan yang identik, dengan perbedaan hanya pada konten data.
3.3 Tujuan Pemulihan
Provider berkomitmen pada tujuan pemulihan berikut untuk lingkungan produksi, yang selaras dengan arsitektur Business Continuity and Disaster Recovery (BC/DR) Platform:
| Metrik | Target | Definisi |
|---|---|---|
| Recovery Point Objective (RPO) | 15 menit | Jumlah kehilangan data maksimum yang dapat diterima, diukur berdasarkan waktu. Backup transaction log berjalan setiap 15 menit, memastikan tidak lebih dari 15 menit data yang dapat hilang dalam skenario bencana. |
| Recovery Time Objective (RTO) | 4 jam | Durasi maksimum gangguan layanan yang dapat diterima. Provider harus memulihkan seluruh fungsi platform dalam waktu 4 jam setelah menyatakan terjadinya peristiwa bencana. |
Tujuan pemulihan ini didukung oleh arsitektur backup berikut :
| Jenis Backup | Frekuensi | Retensi | Enkripsi |
|---|---|---|---|
| Backup transaction log | Setiap 15 menit | 7 hari | AES-256 saat tersimpan |
| Backup penuh database | Setiap 12 jam | 30 hari | AES-256 saat tersimpan |
| Backup file inkremental | Harian | 30 hari | AES-256 saat tersimpan |
| Backup penuh mingguan | Mingguan (Minggu) | 90 hari | AES-256 saat tersimpan |
| Backup arsip bulanan | Bulanan (tanggal 1) | 12 bulan | AES-256 saat tersimpan |
Seluruh backup disimpan dalam Azure storage geo-redundan di wilayah Azure yang ditetapkan Customer, dengan replikasi lintas wilayah opsional sebagaimana ditetapkan dalam Commercial Contract. Integritas backup diverifikasi melalui pengujian pemulihan otomatis yang dilakukan triwulanan.
Ikhtisar Azure Backup: https://azure.microsoft.com/en-us/products/backup
3.4 Klasifikasi Prioritas Insiden
Seluruh insiden yang dilaporkan ke Provider Service Desk (PSD) harus diklasifikasikan sesuai dengan tingkat prioritas berikut:
| Prioritas | Keparahan | Definisi | Contoh |
|---|---|---|---|
| P1 | Kritis | Ketidaktersediaan sistem secara penuh atau kegagalan fungsi bisnis kritis yang berdampak pada seluruh atau hampir seluruh Authorized User. Integritas data berisiko. | Server produksi down, kerusakan database kritis, platform sama sekali tidak dapat diakses, peristiwa kehilangan data. |
| P2 | Mendesak | Penurunan signifikan pada fungsi bisnis kritis. Sistem beroperasi tetapi dengan fungsionalitas yang sangat terbatas. Fitur utama tidak tersedia. | Modul utama tidak berfungsi (misalnya, Cost Control), penurunan kinerja berat, kegagalan integrasi kritis. |
| P3 | Mayor | Fungsi non-kritis terganggu atau kinerja menurun namun tidak menghambat operasi bisnis inti. Tersedia solusi sementara yang wajar. | Kegagalan pembuatan laporan, masalah pada modul non-kritis, cacat kosmetik yang berdampak pada kegunaan, gangguan integrasi minor. |
| P4 | Minor | Masalah kosmetik, permintaan informasi, atau saran peningkatan tanpa dampak operasional langsung. | Masalah perataan UI, koreksi dokumentasi, permintaan fitur, pertanyaan umum. |
Klasifikasi prioritas harus disepakati bersama antara Customer dan Provider pada saat tiket dicatat. Jika Para Pihak tidak dapat mencapai kesepakatan, klasifikasi Customer akan berlaku sementara menunggu peninjauan oleh Service Delivery Manager pada rapat Service Review terjadwal berikutnya.
Incident P1 dan P2 harus dilaporkan melalui telepon ke Provider Service Desk agar mendapat perhatian segera. Incident P3 dan P4 dapat dilaporkan melalui email, portal PSD, atau telepon.
3.5 Matriks Respons & Resolusi SLA
Provider harus merespons dan menyelesaikan Incident sesuai target yang ditetapkan dalam Matriks SLA di bawah ini:
| Prioritas | Waktu Respons | Target MTTR | Target Solusi Sementara | Jendela Operasi | Target GOS |
|---|---|---|---|---|---|
| P1 – Kritis | Segera | 4 Jam | Upaya berkelanjutan hingga terselesaikan | 24 × 7 × 365 | 98% |
| P2 – Mendesak | Segera | 8 Jam | 15 Hari Kerja | 24 × 7 × 365 | 95% |
| P3 – Mayor | Dalam 2 Jam | 12 Jam | 20 Hari Kerja | 24 × 7 × 365 | 93% |
| P4 – Minor | Dalam 4 Jam | Rilis Berikutnya | Rilis terjadwal berikutnya | Jam Kerja | 90% |
Dengan:
- Response Time = waktu dari pengakuan Incident oleh PSD hingga tindakan diagnostik pertama oleh engineer yang ditugaskan
- MTTR (Mean Time to Repair) = target waktu berlalu dari pengakuan Incident hingga penyelesaian penuh atau solusi sementara yang efektif
- Workaround Target = waktu berlalu maksimum untuk menyediakan penyelesaian sementara yang memulihkan fungsi bisnis inti sambil menunggu perbaikan permanen
- GOS (Grade of Service) = persentase Incident dalam setiap tingkat prioritas yang diselesaikan dalam target MTTR selama periode pengukuran
3.6 Pengecualian SLA
Peristiwa berikut dikecualikan dari pengukuran SLA dan tidak akan dihitung sebagai Downtime atau memengaruhi perhitungan GOS:
- (a) Pemeliharaan Terjadwal : pemeliharaan yang diberitahukan sebelumnya dan dilakukan dalam Maintenance Windows yang disepakati sebagaimana didefinisikan dalam Bagian 3.1.3
- (b) Peristiwa Keamanan : setiap Downtime yang diakibatkan oleh pelanggaran keamanan, serangan DDoS, atau patch keamanan darurat yang diterapkan untuk melindungi Platform dan Data Customer
- (c) Force Majeure : peristiwa di luar kendali wajar Provider sebagaimana didefinisikan dalam Bagian 9
- (d) Keterlambatan yang Disebabkan Customer : keterlambatan yang timbul akibat kegagalan Customer memenuhi kewajibannya berdasarkan Bagian 2.8, termasuk kegagalan memberikan informasi tepat waktu, keterlambatan persetujuan, atau modifikasi yang tidak diizinkan
- (e) Kegagalan Pihak Ketiga : gangguan pada konektivitas internet, DNS, atau layanan lain yang tidak berada di bawah kendali langsung Provider, termasuk gangguan platform Microsoft Azure yang memengaruhi infrastruktur dasar
- (f) Keterlambatan Siklus Persetujuan : keterlambatan yang disebabkan oleh alur kerja persetujuan Customer atau proses sign-off yang menghalangi Provider untuk melanjutkan aktivitas penyelesaian Jika terjadi gangguan platform Azure, Provider harus memberikan kepada Customer Microsoft Root Cause Analysis (RCA) yang relevan dalam waktu 5 Hari Kerja sejak dipublikasikan oleh Microsoft.
Azure Service Health: https://azure.microsoft.com/en-us/features/service-health/ Azure Status: https://status.azure.com/
3.7 Penalti Ketidakpatuhan SLA
Apabila Provider gagal mencapai target SLO atau Grade of Service (GOS) yang ditetapkan dalam Bagian 3 ini, Customer berhak atas penalti finansial yang dibayarkan oleh Provider. Skala penalti, dasar perhitungan, dan batas maksimum diatur dalam Commercial Contract masing-masing Customer. Ringkasnya:
- (a) Bertingkat menurut deviasi: penalti meningkat sesuai besarnya kekurangan terhadap target. Deviasi kecil dalam batas toleransi yang disepakati tidak dikenai penalti.
- (b) Dua ukuran: baik performa Availability (SLO) maupun Grade of Service (GOS) diperhitungkan dalam penalti, dengan bobot lebih besar pada Availability.
- (c) Pembayaran langsung: penalti dibayarkan sebagai pembayaran finansial langsung, bukan credit note, setelah klaim Customer divalidasi. Batas maksimum berlaku per kuartal.
- (d) Proses klaim: Customer mengajukan klaim tertulis beserta Incident terkait dan bukti pendukung dalam waktu 30 hari sejak akhir bulan saat pelanggaran terjadi. Provider memvalidasi atau membantah klaim dalam 10 Hari Kerja. Sengketa dibawa ke Steering Committee.
- (e) Satu-satunya upaya pemulihan finansial: penalti merupakan satu-satunya dan eksklusif upaya pemulihan finansial bagi Customer atas kegagalan memenuhi Service Levels. Hal ini tidak membatasi hak Customer untuk mengakhiri Framework karena pelanggaran material berdasarkan Section 7.
- (f) Pengecualian: tidak ada penalti yang terutang apabila kegagalan SLA disebabkan oleh Excluded Event sebagaimana didefinisikan dalam Section 3.6.
3.8 Lisensi Tambahan & User Baru
Apabila Customer memilih untuk menambahkan Authorized User baru (lisensi tambahan) selama Subscription Term, ketentuan berikut berlaku:
- (a) Cakupan SLA yang Sama: Seluruh Service Level, target kinerja, tujuan pemulihan, dan ketentuan penalti yang diatur dalam Bagian 3 ini berlaku sama bagi seluruh Authorized User dan lisensi tambahan sejak tanggal aktivasi. Tidak ada SLA yang dikurangi atau diterapkan bertahap untuk user baru.
- (b) Penyesuaian ARR: ARR yang digunakan untuk perhitungan penalti berdasarkan Section 3.8 harus dihitung ulang untuk mencakup biaya lisensi tambahan sejak tanggal aktivasi, secara proporsional untuk sisa periode pengukuran yang berlaku.
- (c) Konsistensi Lingkungan: Pengguna baru harus memiliki akses ke lingkungan Production dan Staging yang sama. Provider wajib memastikan bahwa Platform dapat diskalakan untuk mengakomodasi pengguna tambahan tanpa penurunan kinerja atau Availability.
- (d) SLA Onboarding: Provider wajib mengaktifkan akun pengguna baru dalam 2 Business Days sejak menerima permintaan penambahan lisensi yang lengkap dari Customer, termasuk penetapan peran, penyediaan akses, dan materi pelatihan awal.
- (e) Jaminan Kapasitas: Provider menjamin bahwa dedicated private sovereign environment memiliki headroom yang memadai, atau akan diskalakan secara proaktif, untuk mendukung pengguna tambahan tanpa memengaruhi SLO 99,9% atau target GOS apa pun. Prosedur penambahan lisensi baru, termasuk harga dan persyaratan amandemen Commercial Contract, diatur dalam Section 6 (Fees, Invoicing & Payment Terms).
3.9 Pelaporan SLA & Service Review
3.9.1 Laporan SLA Bulanan
Atas permintaan Client, Provider dapat menyampaikan laporan kinerja SLA bulanan kepada Customer dalam waktu 10 Hari Kerja setelah akhir setiap bulan kalender. Laporan harus mencakup:
- (e) Persentase Availability bulanan dan perbandingan terhadap target SLO
- (f) Total Incident berdasarkan tingkat prioritas, beserta waktu respons dan resolusi
- (g) Pencapaian GOS per tingkat prioritas
- (h) Tingkat keberhasilan backup dan setiap kejadian backup yang gagal
- (i) Setiap pelanggaran SLA beserta analisis akar penyebab dan tindakan korektif
- (j) Perhitungan penalti (jika berlaku) dengan basis ARR yang ditampilkan
- (k) Analisis tren yang membandingkan kinerja dengan 3 bulan sebelumnya
3.9.2 Tinjauan Layanan Triwulanan
Para Pihak dapat mengadakan rapat Quarterly Service Review untuk meninjau kinerja SLA, membahas inisiatif peningkatan layanan, dan menangani isu yang belum terselesaikan. Provider harus menyiapkan dan menyampaikan laporan layanan triwulanan dalam format yang disepakati Customer setidaknya 5 Hari Kerja sebelum setiap rapat tinjauan. Laporan triwulanan harus mencakup:
- (l) Kinerja SLA gabungan selama kuartal tersebut
- (m) Ringkasan Insiden Mayor beserta analisis akar penyebab
- (n) Pembaruan dan progres rencana peningkatan layanan
- (o) Analisis tren kapasitas dan kinerja
- (p) Ringkasan manajemen perubahan (patch, pembaruan, rilis yang diterapkan)
- (q) Penilaian risiko ke depan dan rencana mitigasi
3.9.3 Peningkatan Layanan Berkelanjutan
Provider harus memelihara daftar Continual Service Improvement (CSI) yang mendokumentasikan peluang peningkatan yang diidentifikasi, tindakan yang disepakati, pihak yang bertanggung jawab, dan tanggal penyelesaian target. Daftar CSI harus ditinjau pada setiap Quarterly Service Review.
3.10 Tata Kelola SLA
Struktur tata kelola berikut berlaku untuk pengelolaan SLA:
| Peran | Tanggung Jawab | Frekuensi |
|---|---|---|
| Service Delivery Manager (Provider) | Titik akuntabilitas utama untuk kinerja SLA. Bertanggung jawab atas laporan SLA bulanan, pengelolaan eskalasi, dan daftar CSI. | Berlangsung terus-menerus |
| Account Manager (Provider) | Pengelolaan hubungan komersial. Titik eskalasi untuk sengketa SLA dan klaim Service Credit. | Sesuai kebutuhan |
| Customer IT Liaison | Kontak utama Customer untuk pengelolaan layanan harian, pelaporan Incident, dan koordinasi UAT. | Berlangsung terus-menerus |
| Steering Committee | Forum manajemen senior gabungan untuk tinjauan strategis hubungan layanan, peninjauan Major Incident, dan keputusan tingkat kontrak. | Semesteran |
Target SLA yang ditetapkan dalam Bagian ini akan ditinjau setiap tahun pada rapat Steering Committee dan dapat diubah melalui kesepakatan tertulis bersama Para Pihak.
Ringkasan Azure SLA: https://azure.microsoft.com/en-us/support/legal/sla/summary/ ITIL Service Level Management: https://www.axelos.com/best-practice-solutions/itil
3.11 Register Proses
Tabel berikut merangkum proses pengelolaan SLA yang ditetapkan dalam Bab ini, termasuk peran yang bertanggung jawab, hasil yang diharapkan, dan rujukan silang ke proses terkait di Bab lain.
Role Legend: P = Penyedia | C = Pelanggan | PSD = Meja Layanan Penyedia | SDM = Manajer Penyampaian Layanan | SC = Steering
Committee
3.11.1 Registri Proses
| Ref | Proses | Pemicu | Penanggung Jawab | Penyetuju | Hasil yang Diharapkan | Cross-Ref |
|---|---|---|---|---|---|---|
| P-3.01 | Pemantauan Availability | Berlangsung terus-menerus (otomatis) | Provider (NOC) | SDM | SLO 99,9% terjaga; peringatan saat ambang terlampaui | § 3.2 |
| P-3.02 | Klasifikasi Incident | Incident dilaporkan ke PSD | PSD | Customer / SDM | Prioritas yang disepakati bersama (P1–P4) | § 3.5, § 4.3 |
| P-3.03 | Pengukuran Kinerja SLA | Penutupan akhir bulan | SDM | — | Laporan SLA bulanan dalam 10 BD | § 3.9.1 |
| P-3.04 | Deteksi Pelanggaran SLA | Laporan SLA bulanan mengungkap pelanggaran | SDM | Manager Akun Provider | Perhitungan penalti dimulai | § 3.8 |
| P-3.05 | Klaim & Pembayaran Penalti | Customer mengajukan klaim dalam 30 hari | Keuangan Provider | Manager Akun Provider | Pembayaran finansial dalam 30 hari setelah validasi | § 3.8 |
| P-3.06 | Quarterly Service Review | Akhir kuartal | SDM + Customer IT Liaison | Steering Committee | Tinjauan layanan selesai; daftar CSI diperbarui | § 3.9.2, § 4.10 |
| P-3.07 | Aktivasi User Baru | Permintaan penambahan lisensi Customer | Provider (PSD) | Penghubung IT Customer | User aktif dalam 2 BD; ARR disesuaikan secara pro rata | § 3.9, § 6 |
| P-3.08 | Pemeliharaan Terjadwal | Jadwal maintenance disusun | Provider (Infra) | SDM | Maintenance selesai; ≤ 4 jam/bulan; Customer diberi pemberitahuan 5 BD sebelumnya | § 3.1.3 |
3.11.2 Matriks RACI
| Proses (Ref) | Provider | PSD | Customer | SDM | SC |
|---|---|---|---|---|---|
| P-3.01 Pemantauan Availability | R | I | I | A | — |
| P-3.02 Klasifikasi Incident | — | R | C | A | — |
| P-3.03 Pengukuran SLA | — | — | I | R/A | I |
| P-3.04 Deteksi Pelanggaran | — | — | I | R | I |
| P-3.05 Klaim Penalti | R | — | R | A | I |
| P-3.06 Tinjauan Triwulanan | C | — | R | R | A |
| P-3.07 Aktivasi User | R | R | A | I | — |
| P-3.08 Pemeliharaan Terjadwal | R | I | I | A | — |
R = Responsible (melaksanakan) | A = Accountable (persetujuan) | C = Consulted | I = Informed | — = Tidak Terlibat
3.11.3 Alur Proses — Siklus Hidup SLA
| Tahap | Aktivitas | Peran | Keluaran |
|---|---|---|---|
| ① Pantau | Pemantauan ketersediaan dan performa berkelanjutan (Azure Monitor, Defender) | Provider (NOC) | Peringatan waktu nyata; data uptime |
| ② Deteksi | Incident terdeteksi atau dilaporkan melalui omnichannel PSD | PSD / Customer | Tiket dibuat → § 4.3 |
| ③ Klasifikasikan | Prioritas ditetapkan (P1–P4), jam SLA dimulai | PSD + Customer | Prioritas yang disepakati; timer respons |
| ④ Selesaikan | Penyelesaian sesuai target MTTR; eskalasi jika diperlukan | Engineering Provider | Incident terselesaikan → § 4.4 |
| ⑤ Laporkan | Laporan SLA bulanan dihasilkan; GOS dan Availability dihitung | SDM | Laporan SLA → § 3.9.1 |
| ⑥ Tinjau | Quarterly Service Review; daftar CSI diperbarui | SDM + Customer + SC | Tindakan CSI → § 4.10 |
| ⑦ Kenakan Penalti | Jika terjadi pelanggaran: klaim penalti, validasi, pembayaran finansial | Customer → Keuangan Provider | Pembayaran dalam 30 hari |
