Bab 10 · ProjectVIEW ERP Master SaaS Framework
Bab 10 mengatur apa yang terjadi ketika versi ProjectVIEW ERP mencapai akhir masa pakai: pemberitahuan minimal 12 bulan, layanan migrasi, penerapan integrasi dan kustomisasi, pelatihan ulang, dan manajemen perubahan. Baik Customer beralih ke versi penerus maupun mengakhiri Subscription, data dikembalikan dalam 2 hari kerja sejak permintaan tertulis (SQL backup, CSV, JSON atau XML) dan lingkungan didekomisioning melalui proses yang ditetapkan — “no customer left behind”.
- 12 bulanpemberitahuan minimum EOL
- 2 BDpengembalian data setelah permintaan tertulis
- .bak · CSV · JSON · XMLformat ekspor
10.1 Ikhtisar & Tujuan
Bab ini menetapkan kerangka komprehensif yang mengatur siklus hidup end-of-life (EOL) Platform ProjectVIEW ERP, termasuk transisi versi utama, layanan migrasi, kewajiban pelatihan ulang, adopsi integrasi dan kustomisasi, hak pengembalian data, dan prosedur penghentian Subscription. Bab ini menggantikan dan memperluas ketentuan ringkasan dalam Bab 4, §4.7.4.
Kerangka EOL Penyedia dimodelkan berdasarkan praktik transisi versi yang matang dari vendor SaaS dan ERP enterprise terkemuka — termasuk SAP S/4HANA, Oracle Fusion Cloud, IFS Cloud, dan Infor CloudSuite — yang disesuaikan dengan model deployment private sovereign khusus Penyedia dan hak Customer atas kepemilikan data penuh (Bab 9, §9.9).
Prinsip desain intinya adalah no Customer left behind : setiap Customer akan menerima pemberitahuan yang memadai, dukungan migrasi komprehensif, pelatihan ulang, dan layanan pengembalian data terlepas dari apakah mereka memilih untuk beralih ke versi penerus atau mengakhiri subscription.
10.2 Ruang Lingkup
Bab ini mencakup:
- (a) Fase siklus hidup versi: General Availability (GA), Mainstream Support, Extended Support, End of Engineering (EOE), dan End of Life (EOL) untuk setiap versi mayor Platform.
- (b) Layanan migrasi: migrasi data yang dipimpin Provider, transformasi skema, penyediaan lingkungan, dan perencanaan cutover bagi Customers yang bertransisi ke versi penerus.
- (c) Pelatihan ulang & manajemen perubahan: program pelatihan wajib, sertifikasi ulang Champion, lokakarya adopsi pengguna, dan pembaruan knowledge base yang diperlukan untuk transisi versi yang sukses.
- (d) Adopsi integrasi & kustomisasi: penilaian, rekayasa ulang, dan validasi integrasi, kustomisasi, dan konfigurasi spesifik Customer pada versi penerus.
- (e) Pengembalian data bagi Customers yang tidak melakukan upgrade: kewajiban ekspor data, spesifikasi format, jadwal pengiriman, dan dokumentasi chain-of-custody bagi Customers yang memilih untuk tidak bertransisi.
- (f) Penghentian Subscription: prosedur formal untuk penghentian layanan, dekomisioning environment, dan pengakhiran kontraktual.
- (g) Peran & tanggung jawab: alokasi RACI untuk semua aktivitas EOL di seluruh organisasi Provider dan Customer. Bab ini tidak mencakup rilis/pembaruan inkremental dalam suatu versi mayor (lihat Chapter 4, §4.7.1) atau peningkatan platform COTS yang dilakukan selama Mainstream Support (lihat Chapter 4, §4.7.3).
10.3 Tahap Siklus Hidup Versi
Setiap versi utama Platform (misalnya, v11, v12) berkembang melalui siklus hidup yang ditetapkan. Model siklus hidup Penyedia mengacu pada kerangka dukungan versi yang diterbitkan oleh SAP (Maintenance Strategy), Oracle (Sustaining Support), IFS (Mainstream/Extended Maintenance), dan Infor (Product Lifecycle Policy), yang disesuaikan dengan model pengiriman SaaS-only Penyedia:
| Fase | Durasi | Yang Diterima Customer | Kewajiban Penyedia |
|---|---|---|---|
| General Availability (GA) | Berlanjut hingga successor GA | Akses penuh ke seluruh fitur, modul, dan API Platform. Rilis inkremental (v11.01, v11.02...) disampaikan melalui sprint Agile (§4.7.1). | Pengembangan aktif, penyempurnaan fitur, perbaikan bug, patch keamanan, pemeliharaan kekinian COTS. |
| Pengumuman EOL | T− 12 bulan | Pemberitahuan tertulis formal bahwa versi utama saat ini akan mencapai End of Life. Pemberitahuan menyebutkan versi penerus, jadwal migrasi indikatif, dan layanan transisi yang tersedia. | Menerbitkan Pengumuman EOL. Memulai asesmen kesiapan versi penerus untuk setiap Customer. |
| Jendela Transisi | T− 12 bulan hingga T− 30 hari | Perencanaan migrasi, pelaksanaan migrasi data, pelatihan ulang, rekayasa ulang integrasi, UAT pada versi penerus, dan operasi paralel (bila dipilih). | Menyediakan Layanan Migrasi, Pelatihan, dan Adopsi Integrasi sebagaimana didefinisikan dalam 10.5– 10.7. |
| End of Engineering (EOE) | T− 30 hari | Tidak ada Change Request baru yang diterima. Dukungan Teknis tetap berlanjut (hanya penyelesaian insiden + patch keamanan). | Melanjutkan pengiriman patch keamanan dan penyelesaian Insiden P1/P2 untuk versi lama. |
| End of Life (EOL) | T = 0 (12 bulan setelah Pengumuman) | Seluruh dukungan untuk versi lama dihentikan. Customer harus sudah beroperasi pada versi penerus atau telah memilih Subscription Cessation. | Mendekomisioning lingkungan lama. Melaksanakan pengembalian data jika Customer telah memilih penghentian (10.9). |
| Extended Support (opsional) | Hingga 12 bulan pasca-EOL | Tersedia atas permintaan tertulis dan dikenai biaya tambahan. Hanya menyediakan penyelesaian Insiden P1/P2 dan patch keamanan kritis. Tidak ada pengembangan fitur. | Menyediakan Extended Support berdasarkan Addendum Extended Support terpisah pada Commercial Contract. |
Komitmen utama: Penyedia menjamin minimum dua belas (12) bulan antara Pengumuman EOL dan Tanggal EOL. Tidak ada Pelanggan yang diwajibkan untuk bertransisi dalam waktu kurang dari 12 bulan sejak tanggal pemberitahuan tertulis resmi. Hal ini selaras dengan praktik terbaik sebagaimana diamati di kebijakan siklus hidup SAP, Oracle, IFS, dan Infor.
10.4 Pengumuman EOL & Komunikasi kepada Pelanggan
Penyedia harus mengomunikasikan siklus hidup EOL kepada setiap Pelanggan melalui program terstruktur berikut:
| Komunikasi | Waktu | Saluran | Isi |
|---|---|---|---|
| Surat Pengumuman EOL | T− 12 bulan (minimum) | Pemberitahuan tertulis kepada kontak yang ditunjuk oleh Pelanggan + email Account Manager | Tanggal EOL resmi, identifikasi versi penerus, ringkasan layanan migrasi, jadwal indikatif, dan tindakan yang harus dilakukan Pelanggan. |
| Penilaian Kesiapan Migrasi | T− 11 bulan | Lokakarya bersama (jarak jauh atau di lokasi) | Penilaian dampak terhadap integrasi, kustomisasi, dan volume data milik Pelanggan. Rencana migrasi awal dan kebutuhan sumber daya. |
| Pembaruan Status Transisi Triwulanan | T−‒9, T−6, T−3 bulan | Rapat Tinjauan Layanan + laporan tertulis | Kemajuan migrasi, tindakan yang belum selesai, daftar risiko, jadwal pelatihan, dan perkiraan tanggal cutover. |
| Pemberitahuan EOE | T− 30 hari | Pemberitahuan tertulis + spanduk dalam aplikasi | Konfirmasi bahwa Change Request baru tidak lagi diterima untuk versi lama. Pemberitahuan pengurangan cakupan dukungan. |
| Konfirmasi Migrasi Akhir | T− 14 hari | Pemberitahuan tertulis | Konfirmasi migrasi telah selesai (atau pilihan Pelanggan untuk penghentian + pengembalian data). Logistik cutover akhir. |
| Konfirmasi EOL | T = 0 | Pemberitahuan tertulis | Versi lama dinonaktifkan. Versi penerus menjadi satu-satunya versi yang didukung. Ketersediaan Extended Support dikonfirmasi (jika berlaku). |
10.5 Layanan Migrasi
Penyedia harus menyampaikan program migrasi terstruktur bagi setiap Pelanggan yang beralih ke versi penerus. Layanan migrasi termasuk dalam langganan tanpa biaya tambahan untuk cakupan migrasi standar yang ditetapkan di bawah ini. Layanan migrasi yang ditingkatkan (misalnya, ingestion data dari sistem lama, transformasi ETL yang kompleks, paralel running di luar periode standar) tersedia sebagai engagement terpisah.
10.5.1 Cakupan Migrasi Standar
- (a) Penyediaan environment: Penyedia harus menyediakan environment versi penerus dalam sovereign tenant Azure privat khusus milik Pelanggan, dikonfigurasi dengan kontrol keamanan, jaringan, dan pengaturan kepatuhan yang sama seperti environment produksi yang ada.
- (b) Migrasi data: Migrasi penuh seluruh Data Pelanggan dari database versi lama ke database versi penerus, termasuk master data, data transaksi, data konfigurasi, dan audit trail. Penyedia harus menggunakan skrip transformasi skema otomatis yang divalidasi terhadap profil data Pelanggan.
- (c) Saran pembersihan data: Selaras dengan praktik terbaik Oracle Fusion dan Infor CloudSuite, Penyedia harus memberi saran kepada Pelanggan mengenai peluang pembersihan data sebelum migrasi. Pendekatan yang direkomendasikan adalah memigrasikan tidak lebih dari tiga (3) tahun data transaksi aktif, dengan data historis diarsipkan dalam format read-only yang dapat diakses untuk pelaporan dan kepatuhan.
- (d) Migrasi konfigurasi: Seluruh konfigurasi spesifik Pelanggan (peran, alur kerja, rantai persetujuan, aturan notifikasi, template laporan, dasbor) dimigrasikan ke versi penerus menggunakan perangkat export/import konfigurasi milik Penyedia.
- (e) Pengujian migrasi: Minimal dua (2) kali simulasi migrasi penuh harus dilaksanakan di Staging Environment sebelum cutover ke produksi. Setiap simulasi mencakup verifikasi integritas data (referensial, komputasional, temporal), smoke testing pada lapisan aplikasi, dan benchmarking kinerja.
- (f) Pelaksanaan cutover: Cutover produksi ke versi penerus pada jendela pemeliharaan yang telah disepakati sebelumnya, termasuk transisi DNS/jaringan, peralihan basis data, verifikasi pasca-cutover, dan kesiapan rollback.
- (g) Periode hypercare: Minimal tiga puluh (30) hari kalender dukungan hypercare pasca-migrasi yang didedikasikan, selama periode tersebut Penyedia harus menugaskan Migration Lead dan sumber daya dukungan khusus untuk penyelesaian insiden prioritas dan stabilisasi.
10.5.2 Jaminan Integritas Migrasi Data
Penyedia harus menerapkan kontrol integritas data berikut selama proses migrasi, selaras dengan kerangka pengujian yang ditingkatkan AI sebagaimana didefinisikan dalam Bab 5 (Kualitas Perangkat Lunak & Pengujian):
- (a) Baseline pra-migrasi: Hash kriptografis (SHA-256) dari seluruh basis data dan inventaris jumlah baris ditangkap segera sebelum migrasi dimulai, untuk menetapkan baseline integritas data.
- (b) Rekonsiliasi pasca-migrasi: Rekonsiliasi jumlah baris, pernyataan integritas referensial, dan pemeriksaan integritas komputasional dijalankan terhadap database versi penerus. Hash pasca-migrasi dibandingkan dengan baseline pra-migrasi.
- (c) Validasi agen AI (opsional): Apabila Pelanggan memilih layanan AI-Augmented Testing (Bab 5), Penyedia harus menerapkan agen AI pada environment versi penerus untuk menjalankan skenario simulasi end-to-end, memvalidasi aliran data, aturan bisnis, dan titik integrasi.
- (d) Persetujuan migrasi: Pelanggan harus melakukan UAT pada environment versi penerus. Persetujuan tertulis dari Pelanggan diperlukan sebelum cutover produksi, sesuai dengan persyaratan UAT yang didefinisikan dalam Bab 5, §5.8.
10.6 Adopsi Integrasi & Kustomisasi
Transisi versi utama dapat memengaruhi integrasi, kustomisasi, dan ekstensi pihak ketiga yang spesifik milik Pelanggan. Penyedia harus mengelola transisi ini melalui program adopsi terstruktur:
10.6.1 Penilaian Dampak Integrasi
Dalam tiga puluh (30) hari kalender sejak Pengumuman EOL, Penyedia harus menyampaikan kepada Pelanggan Penilaian Dampak Integrasi yang mencakup:
- (a) Analisis kompatibilitas API: Pemetaan seluruh API yang digunakan Pelanggan pada versi lama ke padanannya di versi penerus, dengan identifikasi perubahan yang memutus kompatibilitas, endpoint yang sudah usang, dan kemampuan baru.
- (b) Inventaris integrasi pihak ketiga: Katalog seluruh integrasi aktif (middleware, konektor B2G, shipping API, interface perbankan, alat pelaporan pihak ketiga) beserta status kompatibilitasnya untuk versi penerus.
- (c) Registri kustomisasi: Inventaris lengkap kustomisasi spesifik Pelanggan (compiled DLL, fungsi SQL kustom, laporan khusus, ekstensi alur kerja) dengan klasifikasi jalur migrasi: (i) kompatibel ke depan, (ii) memerlukan re-engineering, (iii) usang / tersedia pengganti.
- (d) Estimasi upaya & jadwal: Estimasi upaya indikatif (person-day) dan jadwal untuk re-engineering integrasi dan kustomisasi yang tidak kompatibel, dengan membedakan antara cakupan standar (termasuk) dan cakupan tambahan (dikutip terpisah).
10.6.2 Re-Engineering & Validasi
Untuk integrasi dan kustomisasi yang diklasifikasikan sebagai “memerlukan re-engineering”:
- (a) Re-engineering yang dikelola Penyedia: Apabila kustomisasi tersebut awalnya dibangun oleh Penyedia (tercatat di repository Git pada Client Branch milik Pelanggan), Penyedia harus melakukan re-engineering dan menguji komponen tersebut tanpa biaya tambahan sebagai bagian dari cakupan migrasi standar.
- (b) Integrasi yang dikelola Pelanggan atau pihak ketiga: Apabila integrasi tersebut dibangun oleh Pelanggan atau pihak ketiga, Penyedia harus (i) menyediakan dokumentasi teknis untuk surface API versi penerus, (ii) menyediakan Staging Environment untuk pengujian, dan (iii) menawarkan bantuan layanan profesional opsional berdasarkan waktu dan material.
- (c) Pengujian regresi integrasi: Seluruh integrasi yang dimigrasikan harus menjalani pengujian regresi otomatis di Staging Environment sebelum cutover produksi, menggunakan kerangka agen AI (Bab 5) atau skrip uji manual sebagaimana disepakati.
10.7 Pelatihan Ulang & Manajemen Perubahan
Transisi versi utama merupakan Perubahan Platform yang Signifikan dan memicu kewajiban pelatihan ulang wajib berdasarkan Bab 6 (Pelatihan & Transfer Pengetahuan). Penyedia harus menyampaikan program pelatihan transisi yang disesuaikan, mencakup:
10.7.1 Penilaian Ulang Kebutuhan Pelatihan
Dalam enam puluh (60) hari kalender sejak Pengumuman EOL, Penyedia harus melakukan Penilaian Ulang Kebutuhan Pelatihan (TNRA) untuk mengidentifikasi:
- (a) Elemen UI, alur kerja, dan pola navigasi baru atau yang berubah pada versi penerus.
- (b) Fitur yang sudah usang dan penggantinya.
- (c) Kemampuan baru yang diaktifkan oleh versi penerus (termasuk fitur berbasis AI jika berlaku).
- (d) Persyaratan pelatihan spesifik per peran berdasarkan konfigurasi modul aktif dan struktur organisasi Customer. Keluaran TNRA adalah Rencana Pelatihan Transisi, yang dilampirkan pada Migration Plan, yang menetapkan sesi, durasi, metode penyampaian, dan audiens sasaran.
10.7.2 Program Pelatihan Transisi
| Komponen Pelatihan | Audiens | Format | Waktu | Durasi |
|---|---|---|---|---|
| Briefing “Apa yang Baru” | Semua Pengguna yang Berwenang | Webinar (direkam + ditranskripsi AI) | T−6 bulan | 90 menit |
| Lokakarya Praktis: Perubahan Inti | Super User + Champion | Dibawakan instruktur (online atau di lokasi) | T−5 hingga T−4 bulan | 2–3 hari per kelompok modul |
| Sertifikasi Ulang Champion | Champion DANAOS ProjectVIEW ERP | Dibawakan instruktur + ujian | T−4 hingga T−3 bulan | 1 hari per Champion |
| Lokakarya Integrasi & API | Tim IT / Integrasi Pelanggan | Lokakarya teknis (online) | T−4 bulan | 1 hari |
| Sesi Panduan UAT | Peserta UAT | Briefing oleh instruktur | T−2 bulan | Setengah hari |
| Pengecekan Kesiapan Go-Live | Champions + Pemimpin IT Pelanggan | Rapat checkpoint | T−14 hari | 2 jam |
| Klinik Drop-In Pasca Migrasi | Semua Pengguna yang Berwenang | Tanya Jawab online (dua mingguan) | T + 0 hingga T + 90 hari | 1 jam per sesi |
Seluruh sesi pelatihan transisi harus direkam dan ditranskripsi oleh AI sesuai dengan Bab 6, §6.4.4. Rekaman dan transkrip harus dipublikasikan ke Per-Client Training Wiki milik Pelanggan (https://docs.projectview.wiki/[client]) dalam waktu lima (5) Hari Kerja setelah setiap sesi.
10.7.3 Pembaruan Basis Pengetahuan
Penyedia harus memperbarui sumber pengetahuan berikut sebelum cutover produksi pada versi penerus:
- (a) Per-Client Training Wiki: Seluruh halaman khusus modul, panduan proses, dan artikel FAQ diperbarui untuk mencerminkan UI, alur kerja, dan terminologi versi penerus.
- (b) Platform Release Centre: Catatan rilis, panduan deployment, dan referensi konfigurasi untuk versi penerus yang dipublikasikan di.
- (c) Panduan dalam aplikasi: Tooltip kontekstual, tautan bantuan, dan prompt berbantuan AI diperbarui untuk merujuk pada fungsi versi penerus.
10.8 Keputusan Pelanggan: Transisi atau Penghentian
Paling lambat enam (6) bulan sebelum Tanggal EOL (yaitu T−6 bulan), Pelanggan harus secara resmi memberitahukan Penyedia mengenai pilihannya untuk:
- (a) Opsi A — Transisi: Melanjutkan migrasi ke versi penerus. Penyedia memberikan Layanan Migrasi (§10.5), Adopsi Integrasi (§10.6), dan Pelatihan Ulang (§10.7). Langganan berlanjut tanpa gangguan pada versi penerus berdasarkan ketentuan komersial yang berlaku saat ini (kecuali diubah berdasarkan kesepakatan tertulis bersama).
- (b) Opsi B — Penghentian Langganan: Memilih untuk tidak bertransisi. Penyedia memulai proses Penghentian Langganan (§10.9), termasuk pengembalian data (§10.10), penonaktifan environment (§10.11), dan penghentian kontrak (§10.12). Langganan berakhir pada Tanggal EOL (atau tanggal berakhirnya Extended Support, jika dipilih). Jika Pelanggan tidak memberikan pemberitahuan tertulis pada tenggat T−6, Penyedia harus mengirim pemberitahuan pengingat. Jika tidak ada respons dalam tambahan tiga puluh (30) hari kalender, Penyedia akan menganggap Pelanggan telah memilih Opsi A (Transisi), dan Layanan Migrasi akan dilanjutkan.
10.9 Proses Penghentian Langganan
Apabila Pelanggan memilih Opsi B (Penghentian Langganan), proses berikut berlaku:
| Fase | Waktu | Aktivitas | Pemilik |
|---|---|---|---|
| 1. Pemberitahuan Penghentian | T−6 bulan (pilihan Pelanggan) | Pelanggan memberikan pemberitahuan tertulis atas niat untuk tidak bertransisi. Penyedia mengonfirmasi penerimaan dalam 2 Hari Kerja. | Pelanggan → Account Manager |
| 2. Perencanaan Penghentian | T−6 hingga T−5 bulan | Penyedia dan Pelanggan menyepakati Rencana Penghentian yang mencakup: format ekspor data, jadwal, pengalihan kontak, penyelesaian tiket terbuka, dan jadwal penurunan environment. | Manajer Akun + Pimpinan Operasi Cloud |
| 3. Ekspor & Pengembalian Data | T−5 hingga T−2 bulan | Penyedia mengekspor seluruh Data Pelanggan dalam format yang disepakati dalam 2 Hari Kerja sejak setiap permintaan yang sah (§10.10). Permintaan ekspor dapat diajukan lebih dari sekali. | DBA + Cloud Ops |
| 4. Validasi Pelanggan | T−2 hingga T−1 bulan | Pelanggan memvalidasi kelengkapan dan integritas data yang diekspor. Keberatan atas kelengkapan data (jika ada) harus diajukan dalam 14 hari kalender sejak diterima. | Customer IT Lead |
| 5. Penyelesaian Tiket Terbuka | T−3 hingga T−30 hari | Penyedia menyelesaikan seluruh Insiden P1/P2 yang masih terbuka. Tiket dengan prioritas lebih rendah ditutup dengan persetujuan Pelanggan atau didokumentasikan sebagai belum terselesaikan. | Cloud Ops + Account Manager |
| 6. Penonaktifan Environment | T = Tanggal EOL | Environment lama dinonaktifkan: penghentian VM, penghapusan database, penghapusan storage account, pemusnahan kunci enkripsi (§10.11). | Cloud Ops + DBA |
| 7. Sertifikat Penonaktifan | T + 14 hari | Penyedia menerbitkan Sertifikat Penonaktifan yang menegaskan bahwa seluruh Data Pelanggan telah dimusnahkan secara aman sesuai NIST SP 800-88. | CTO → Pelanggan |
| 8. Penghentian Kontrak | T + 30 hari | Perjanjian secara resmi berakhir. Klausul yang tetap berlaku (kerahasiaan, IP, pembatasan tanggung jawab, kewajiban residual perlindungan data) tetap berlaku sesuai dengan §10.12. | Legal / Account Manager |
10.10 Pengembalian Data
Pelanggan setiap saat memiliki kepemilikan tunggal dan eksklusif atas seluruh Data Pelanggan (Bab 9, §9.9). Setelah Penghentian Langganan, kewajiban pengembalian data oleh Penyedia adalah sebagai berikut:
10.10.1 Format Ekspor & Pengiriman
- (a) Format ekspor standar: file backup SQL Server (.bak), CSV, JSON, dan/atau XML. Pelanggan dapat meminta kombinasi format apa pun.
- (b) Jadwal pengiriman: Dalam waktu dua (2) Hari Kerja sejak menerima permintaan tertulis yang sah dari Pelanggan.
- (c) Metode pengiriman: Transfer aman terenkripsi melalui endpoint SFTP yang ditunjuk Pelanggan, Azure Blob Storage SAS token, atau media fisik terenkripsi (dikirim via kurir dengan dokumentasi rantai penguasaan).
- (d) Cakupan ekspor: Seluruh Data Pelanggan termasuk: master data, data transaksi, data konfigurasi, audit trail, catatan pelacakan perubahan, lampiran dokumen (blob storage), dan laporan yang dihasilkan aplikasi.
- (e) Beberapa kali ekspor: Pelanggan dapat meminta beberapa kali ekspor selama periode penghentian. Setiap permintaan harus dipenuhi dalam 2 Hari Kerja.
10.10.2 Validasi Pengembalian Data
Setelah setiap ekspor data:
- (a) Hash integritas: Penyedia harus menyampaikan hash kriptografis SHA-256 untuk setiap kumpulan data yang diekspor, sehingga Pelanggan dapat memverifikasi integritas data saat diterima.
- (b) Sertifikat jumlah baris: Penyedia harus menyampaikan sertifikat jumlah baris yang mencantumkan jumlah record untuk setiap tabel/entity dalam ekspor, yang dirujuk silang terhadap database produksi pada titik waktu ekspor.
- (c) Jendela validasi: Pelanggan memiliki empat belas (14) hari kalender sejak penerimaan untuk mengajukan keberatan atas kelengkapan atau integritas data. Penyedia harus memperbaiki dan mengekspor ulang dalam waktu dua (2) Hari Kerja atas setiap keberatan yang sah.
- (d) Penerimaan dianggap: Jika Pelanggan tidak mengajukan keberatan dalam jendela validasi 14 hari, ekspor dianggap diterima.
10.10.3 Biaya Pengembalian Data
Pengembalian data dalam cakupan standar (ekspor dalam format standar melalui transfer digital aman) termasuk dalam langganan tanpa biaya tambahan. Layanan berikut tersedia dengan biaya tambahan berdasarkan waktu dan material:
- (a) Transformasi data yang diekspor ke format non-standar (misalnya, transformasi skema spesifik sistem target untuk ingestion ke ERP penerus).
- (b) Persiapan media fisik dan pengiriman melalui kurir.
- (c) Jendela ekspor data yang diperpanjang melampaui jadwal penghentian standar.
- (d) Nasihat teknis mengenai pemetaan data, skrip migrasi, atau desain ETL untuk sistem penerus Customer.
10.11 Penonaktifan Environment
Setelah pengembalian data selesai dan jendela validasi Pelanggan berakhir, Penyedia harus menonaktifkan environment privat sovereign khusus milik Pelanggan:
- (a) Penghentian virtual machine: Semua VM Pelanggan (produksi dan staging) dihentikan, image disk dihapus, dan sumber daya komputasi dibebaskan.
- (b) Pemusnahan database: Semua database SQL Server (produksi, staging, backup) dihapus secara permanen. Transaction log dan file backup di Azure Backup Vault dibersihkan.
- (c) Pembersihan storage account: Semua container Azure Blob Storage, file share, dan table storage yang terkait dengan Pelanggan dihapus secara permanen, termasuk salinan yang direplikasi GRS di region sekunder.
- (d) Pemusnahan kunci enkripsi: Semua kunci enkripsi, rahasia, dan sertifikat spesifik Pelanggan di Azure Key Vault dibersihkan (pengesampingan purge-protection diotorisasi oleh CTO).
- (e) Pembersihan jaringan: Virtual network, NSG, alamat IP publik, record DNS, dan sertifikat SSL/TLS yang terkait dengan Pelanggan dihapus dari layanan.
- (f) Pembaruan CMDB: Seluruh item konfigurasi yang terkait dengan Pelanggan ditandai sebagai dinonaktifkan dalam CMDB milik Penyedia.
- (g) Pemusnahan data aman: Seluruh pemusnahan data dilakukan sesuai NIST SP 800-88 (Guidelines for Media Sanitisation). Penghapusan kriptografis Azure memastikan bahwa data pada storage yang dinonaktifkan tidak dapat dipulihkan.
NIST SP 800-88 Rev. 1: Pedoman untuk Sanitasi Media Azure Data Destruction
10.12 Kewajiban yang Tetap Berlaku
Kewajiban berikut tetap berlaku setelah berakhir atau habisnya Framework dan akan terus berlaku penuh dan efektif:
- (a) Kerahasiaan: Kewajiban kerahasiaan timbal balik tetap berlaku selama lima (5) tahun sejak tanggal pengakhiran (Bab 8, §8.11).
- (b) Kekayaan Intelektual: Seluruh hak kekayaan intelektual dan pembatasan lisensi tetap berlaku tanpa batas waktu.
- (c) Kewajiban residual perlindungan data: Kewajiban privasi berdasarkan Bab 7 tetap berlaku terkait setiap Data Pribadi yang disimpan oleh Penyedia berdasarkan kewajiban hukum atau regulasi (Bab 7, §7.13).
- (d) Pembatasan tanggung jawab: Batas tanggung jawab dan pengecualian tetap berlaku untuk klaim yang timbul dari peristiwa selama Masa Langganan.
- (e) Penyelesaian sengketa: Hukum yang berlaku dan ketentuan penyelesaian sengketa tetap berlaku untuk setiap klaim yang timbul dari atau sehubungan dengan Framework.
- (f) Hak audit: Hak Pelanggan untuk mengaudit kepatuhan pemusnahan data tetap berlaku selama dua belas (12) bulan setelah tanggal Sertifikat Penonaktifan.
10.13 Opsi Extended Support
Selaras dengan model Extended Support yang ditawarkan oleh SAP (Extended Maintenance), Oracle (Sustaining Support), IFS (Extended Maintenance), dan Infor (Extended Maintenance), Penyedia menawarkan periode Extended Support opsional bagi Pelanggan yang memerlukan waktu tambahan untuk menyelesaikan transisi mereka:
(a) Ketersediaan: Dukungan Lanjutan harus diminta secara tertulis paling lambat enam puluh (60) hari kalender sebelum Tanggal EOL. (b) Durasi: Hingga dua belas (12) bulan setelah Tanggal EOL, dalam kelipatan triwulanan. (c) Ruang lingkup: Hanya penyelesaian Insiden P1 dan P2 serta patch keamanan kritis. Tidak ada pengembangan fitur, tidak ada Change Request baru, tidak ada aktivasi modul baru. (d) Harga: Dukungan Lanjutan dikenakan premi dua puluh persen (20%) di atas ARR yang berlaku saat itu, dibayarkan triwulanan di muka. (e) Pengakhiran: Dukungan Lanjutan berakhir otomatis pada akhir periode yang dipilih. Seluruh ketentuan Penghentian Langganan (§10.9–§10.12) berlaku pada saat Dukungan Lanjutan berakhir.
10.14 Peran & Tanggung Jawab (Matriks RACI)
Matriks RACI berikut mengalokasikan tanggung jawab atas aktivitas EOL utama di antara peran Provider dan Customer:
| Aktivitas | CTO | Cloud Ops Lead | Account Mgr | DBA Lead | Customer IT Lead | Customer Champions |
|---|---|---|---|---|---|---|
| Penerbitan Pengumuman EOL | A | I | R | I | I | I |
| Penilaian Kesiapan Migrasi | A | R | C | R | C | I |
| Penilaian Dampak Integrasi | I | R | C | C | R | I |
| Pelaksanaan migrasi data | I | R | I | R | C | I |
| Verifikasi integritas migrasi data | I | R | I | R | C | I |
| Penyampaian Program Pelatihan Transisi | I | C | R | I | C | R |
| Sertifikasi Ulang Champion | I | I | R | I | C | R |
| Pembaruan basis pengetahuan | I | R | C | I | I | C |
| Rekayasa ulang integrasi | I | R | I | C | R | I |
| UAT pada versi penerus | I | C | C | C | R | R |
| Perencanaan & pelaksanaan cutover | A | R | C | R | C | I |
| Keputusan Customer (Transisi / Penghentian) | I | I | C | I | R | I |
| Pemenuhan ekspor data | I | R | C | R | R | I |
| Validasi pengembalian data | I | I | I | I | R | I |
| Penonaktifan lingkungan | A | R | I | R | I | I |
| Penerbitan Sertifikat Penonaktifan | R | C | I | C | I | I |
| Manajemen Dukungan Lanjutan | A | R | C | R | I | I |
Legenda: R = Responsible · A = Accountable · C = Consulted · I = Informed.
10.15 Register Proses
Register proses berikut mengatalogkan seluruh proses formal yang didefinisikan dalam bab ini.
| ID Proses | Nama Proses | Pemicu | Penanggung Jawab | Penyetuju | Hasil | Ref. Bagian |
|---|---|---|---|---|---|---|
| P-10.01 | Pengumuman EOL | Keputusan peta jalan produk untuk menghentikan versi utama | Account Manager | CTO | Pengumuman EOL tertulis disampaikan kepada seluruh Customer yang terdampak ≥ 12 bulan sebelum Tanggal EOL. | §10.4 |
| P-10.02 | Penilaian Kesiapan Migrasi | Pengumuman EOL diterbitkan (T−11 bulan) | Cloud Ops + DBA | CTO | Penilaian dampak khusus Customer dan rencana migrasi awal disampaikan. | §10.4 |
| P-10.03 | Penilaian Dampak Integrasi | Pengumuman EOL diterbitkan (dalam 30 hari) | Cloud Ops Lead | CTO | Analisis kompatibilitas API, inventaris integrasi, registri kustomisasi, dan estimasi upaya disampaikan. | §10.6.1 |
| P-10.04 | Penilaian Ulang Kebutuhan Pelatihan | Pengumuman EOL diterbitkan (dalam 60 hari) | Account Manager | CTO | Rencana Pelatihan Transisi dilampirkan pada Rencana Migrasi. | §10.7.1 |
| P-10.05 | Pelaksanaan Migrasi Data | Rencana Migrasi disetujui dan Lingkungan Staging disediakan | DBA + Cloud Ops | Cloud Ops Lead | Data Customer dimigrasikan; integritas diverifikasi; simulasi selesai. | §10.5.1 |
| P-10.06 | Verifikasi Integritas Migrasi | Simulasi migrasi data atau cutover produksi selesai | DBA + Cloud Ops | Cloud Ops Lead | Perbandingan hash pra/pasca lolos; rekonsiliasi jumlah baris selesai; laporan integritas diterbitkan. | §10.5.2 |
| P-10.07 | Rekayasa Ulang Integrasi | Integrasi diklasifikasikan sebagai ‘memerlukan rekayasa ulang’ dalam Penilaian Dampak | Cloud Ops | Cloud Ops Lead | Integrasi diperbarui, diuji, dan divalidasi pada versi penerus. | §10.6.2 |
| P-10.08 | Penyampaian Pelatihan Transisi | Rencana Pelatihan Transisi disetujui | Account Manager + Trainer | Cloud Ops Lead | Seluruh sesi pelatihan yang dijadwalkan telah disampaikan; rekaman dipublikasikan ke Wiki. | §10.7.2 |
| P-10.09 | Sertifikasi Ulang Champion | Program Pelatihan Transisi dijadwalkan | Account Manager | CTO | Champions lulus ujian versi penerus; sertifikat diterbitkan. | §10.7.2 |
| P-10.10 | UAT pada Versi Penerus | Simulasi migrasi lolos; pelatihan selesai | Customer IT Lead + Champions | Customer | Persetujuan tertulis Customer atas versi penerus diperoleh. | §10.5.2 |
| P-10.11 | Cutover Produksi | Persetujuan UAT diterima; jendela cutover disepakati | Cloud Ops + DBA | CTO | Lingkungan produksi menjalankan versi penerus; rollback tersedia selama 72 jam. | §10.5.1 |
| P-10.12 | Dukungan Hypercare | Cutover produksi selesai | Cloud Ops + DBA | Account Manager | Periode hypercare 30 hari telah diberikan; stabilisasi dikonfirmasi. | §10.5.1 |
| P-10.13 | Pilihan Penghentian Customer | Pemberitahuan tertulis Customer tentang niat untuk tidak bertransisi | Account Manager | CTO | Rencana Penghentian disepakati; jadwal ekspor data dikonfirmasi. | §10.8 |
| P-10.14 | Ekspor & Pengembalian Data | Permintaan tertulis yang valid dari Customer selama periode penghentian | DBA + Cloud Ops | Account Manager | Data Customer diekspor dalam format yang disepakati dalam 2 Hari Kerja. | §10.10 |
| P-10.15 | Validasi Pengembalian Data | Ekspor data disampaikan kepada Customer | Customer IT Lead | Customer | Customer mengonfirmasi kelengkapan dalam jendela validasi 14 hari (atau dianggap diterima). | §10.10.2 |
| P-10.16 | Penonaktifan Lingkungan | Jendela validasi pengembalian data berakhir; Tanggal EOL tercapai | Cloud Ops + DBA | CTO | Seluruh sumber daya Customer dimusnahkan sesuai NIST SP 800-88; CMDB diperbarui. | §10.11 |
| P-10.17 | Sertifikat Penonaktifan | Penonaktifan lingkungan selesai | CTO | CTO | Sertifikat Penonaktifan diterbitkan kepada Customer dalam 14 hari. | §10.11 |
| P-10.18 | Aktivasi Dukungan Lanjutan | Permintaan tertulis Customer ≥60 hari sebelum Tanggal EOL | Cloud Ops Lead | CTO | Addendum Dukungan Lanjutan telah dieksekusi; dukungan P1/P2 dilanjutkan selama periode yang dipilih. | §10.13 |
10.16 Skema Alur Proses
Siklus hidup sembilan tahap berikut menggambarkan alur end-to-end transisi versi dan penghentian langganan:
① Pengumuman & Komunikasi EOL → ② Kesiapan & Penilaian Dampak → ③ Pelanggan
Keputusan (Transisi / Penghentian)
↓
JALUR TRANSISI: ④ Migrasi & Rekayasa Ulang → ⑤ Pelatihan Ulang & Manajemen Perubahan → ⑥
UAT & Cutover Produksi
↓
JALUR PENGHENTIAN: ⑦ Ekspor & Pengembalian Data → ⑧ Penonaktifan Lingkungan → ⑨ Pengakhiran
Kontrak
Tahap ① Pengumuman & Komunikasi EOL: Provider menerbitkan Pengumuman EOL formal ≥12 bulan sebelum Tanggal EOL, memulai program komunikasi terstruktur (§10.4). Seluruh Customer menerima pemberitahuan tertulis, dan Account Manager menjadwalkan Migration Readiness Assessment (P-10.01).
Tahap ② Kesiapan & Penilaian Dampak: Provider menyampaikan Migration Readiness Assessment, Integration Impact Assessment, dan Training Needs Re-Assessment dalam 60 hari sejak Pengumuman EOL (P-10.02, P-10.03, P-10.04).
Tahap ③ Keputusan Customer: Pada T−6 bulan, Customer secara formal memilih Transisi (Opsi A) atau Penghentian (Opsi B). Default adalah Transisi jika tidak ada respons dalam 30 hari sejak pengingat (P-10.13).
Tahap ④ Migrasi & Rekayasa Ulang (Jalur Transisi): Migrasi data, migrasi konfigurasi, dan rekayasa ulang integrasi dijalankan di Lingkungan Staging dengan ≥2 simulasi (P-10.05, P-10.06, P-10.07).
Tahap ⑤ Pelatihan Ulang & Manajemen Perubahan (Jalur Transisi): Program Pelatihan Transisi disampaikan: briefing What’s New, lokakarya praktis, resertifikasi Champion, dan pembaruan basis pengetahuan (P-10.08, P-10.09).
Tahap ⑥ UAT & Cutover Produksi (Jalur Transisi): Customer melakukan UAT pada versi penerus. Persetujuan tertulis memicu cutover produksi. Setelah itu diikuti periode Hypercare selama 30 hari (P-10.10, P-10.11, P-10.12).
Tahap ⑦ Ekspor & Pengembalian Data (Jalur Penghentian): Provider mengekspor seluruh Data Customer dalam 2 Hari Kerja sejak setiap permintaan yang valid. Beberapa ekspor diperbolehkan. Sertifikat hash integritas dan jumlah baris disertakan bersama setiap ekspor (P-10.14, P-10.15).
Tahap ⑧ Penonaktifan Lingkungan (Jalur Penghentian): Setelah jendela validasi berakhir dan Tanggal EOL tercapai, Provider memusnahkan seluruh sumber daya Customer sesuai NIST SP 800-88 dan menerbitkan Sertifikat Penonaktifan (P-10.16, P-10.17).
Tahap ⑨ Pengakhiran Kontraktual (Jalur Penghentian): Framework secara formal berakhir 30 hari setelah penonaktifan. Kewajiban yang tetap berlaku (kerahasiaan, IP, perlindungan data, tanggung jawab, hak audit) berlanjut sesuai §10.12 (P-10.18 jika Dukungan Lanjutan aktif).
