TKP study materials
TKP study resources

Migrasi 12.400 Berkas, Tenggat Sembilan Hari, dan Drive Pribadi

TKP · Put your knowledge to work in context.

All case studies

Migrasi 12.400 Berkas, Tenggat Sembilan Hari, dan Drive Pribadi

Dinas Anda menargetkan migrasi 12.400 berkas layanan dari aplikasi lama ke sistem baru dalam sembilan hari kerja karena audit internal dijadwalkan dua minggu lagi. Vendor menyatakan waktu realistis adalah 14 hari. Uji sampel 500 berkas menunjukkan 37% tidak memiliki NIK valid (kosong, 15 digit, atau berisi tanda hubung), format tanggal bercampur antara dd/mm/yyyy dan yyyy-mm-dd, dan 112 berkas memuat nama ganda. Di tengah rapat, seorang staf mengaku sudah memindahkan 2.300 berkas lewat akun Google Drive pribadinya karena jaringan kantor lambat; tautannya bahkan pernah ia kirim ke grup WhatsApp tim. Aturan internal melarang data pribadi keluar dari pusat data, tetapi kanal transfer resmi belum siap. Anda ditunjuk sebagai koordinator migrasi tanpa tambahan personel, dan atasan meminta sistem tetap go-live sesuai tanggal.

1. Susun prioritas kerja sembilan hari tersebut. Bagian mana yang Anda relakan dan bagian mana yang tidak boleh dikompromikan?

Read the worked answer

Hal yang tidak boleh dikompromikan: kerahasiaan data pribadi dan keutuhan data. Keduanya bukan variabel kecepatan.

Rencana sembilan hari:

  1. Hari 1 - hentikan risiko, bukan hentikan pekerjaan. Cabut akses ke Drive pribadi, tetapi pada hari yang sama sediakan kanal resmi pengganti: server staging internal, SFTP, atau transfer fisik terenkripsi. Jaringan lambat diatasi dengan penjadwalan transfer pada jam sepi dan permintaan prioritas bandwidth ke unit TI. Melarang tanpa menyediakan alternatif hanya memindahkan pelanggaran ke tempat yang lebih sulit dilacak.
  2. Hari 1–2 - gate kualitas data. Tetapkan aturan validasi (format NIK, format tanggal, aturan duplikasi) dan jalankan pembersihan otomatis untuk kasus yang bisa distandarkan.
  3. Hari 2–6 - migrasi bertahap berdasarkan risiko, bukan big bang. Kelompokkan berkas per jenis layanan dan tingkat kekritisan. Mulai dari kelompok yang datanya sudah bersih untuk uji end-to-end, lalu jalankan parallel run pada subset sebelum cutover.
  4. Hari 3 - renegosiasi berbasis bukti. Bawa angka 37% data kotor ke manajemen dan vendor. Ini perubahan lingkup, bukan kelalaian tim. Ajukan dua opsi: tambahan tenaga, atau go-live terbatas pada modul/berkas yang siap dengan cutover bertahap.
  5. Hari 7–9 - verifikasi dan serah terima. Uji rekonsiliasi jumlah berkas, dokumentasikan berkas bermasalah, dan serahkan daftar perbaikan pasca-migrasi dengan penanggung jawab dan tenggat.

Menyetujui target yang mustahil tanpa catatan resmi berarti memindahkan risiko kepada tim dan kepada institusi.

2. Apa yang Anda lakukan terhadap staf yang memakai Google Drive pribadi dan terhadap 2.300 berkas yang sudah dipindahkan?

Read the worked answer

Urutannya: hentikan, amankan, audit, laporkan, baru edukasi atau sanksi.

  1. Hentikan akses segera - minta staf menghapus berkas dari Drive pribadi, mencabut tautan yang beredar, dan mengeluarkan berkas dari tempat sampah. Minta bukti penghapusan.
  2. Audit jejak akses - dari log, identifikasi siapa saja yang membuka tautan, apakah ada unduhan atau penerusan. Hasilnya menentukan apakah ini pelanggaran prosedur biasa atau insiden kebocoran data.
  3. Klasifikasikan dan laporkan - catat sebagai insiden keamanan informasi dan pelindungan data pribadi, lalu sampaikan ke pejabat yang berwenang di instansi. Ini penting karena kewajiban pelaporan tidak bisa ditawar demi menjaga nama baik unit.
  4. Bedakan niat dan kelalaian - periksa apakah staf pernah diberi kanal resmi dan pelatihan. Jika tidak, sanksi berat justru tidak adil dan tidak akan memperbaiki sistem. Jika ada indikasi penyalahgunaan sengaja, serahkan ke mekanisme kepegawaian.
  5. Perbaiki penyebabnya - staf memakai Drive pribadi karena jaringan kantor lambat dan tidak ada kanal resmi. Tanpa perbaikan itu, kejadian serupa akan berulang dengan pelaku lain.

Poin penting: respons yang hanya menghukum akan membuat staf lain menyembunyikan praktik serupa, dan itu jauh lebih berbahaya daripada insiden awal.

3. Bagaimana Anda memastikan 37% data yang tidak valid tidak memblokir go-live tanpa membuat sistem baru dipenuhi data sampah?

Read the worked answer

Saya memisahkan dua hal yang sering dicampur: data yang layak tampil dan data yang layak dipercaya.

Langkahnya:

  1. Triase per field. Tidak semua cacat sama berat. NIK kosong menghambat pencarian dan verifikasi; format tanggal campur bisa dinormalkan otomatis; nama ganda butuh keputusan manusia. Saya akan membuat tiga keranjang: bisa dibersihkan mesin, butuh verifikasi manual, dan tidak bisa diselesaikan sebelum go-live.
  2. Status data, bukan sekadar migrasi. Berkas yang belum tervalidasi tetap dimigrasikan, tetapi ditandai dengan status “perlu verifikasi” dan tidak dipakai untuk keputusan layanan yang berisiko. Ini menghindari dua kegagalan sekaligus: go-live tertunda total, atau data cacat dianggap benar.
  3. Aturan validasi di sistem baru. Sistem harus menolak input NIK tidak valid sejak awal, agar masalah tidak kembali menumpuk.
  4. Rencana perbaikan pasca-migrasi. Daftar berkas bermasalah dibagi per unit asal, dengan penanggung jawab dan tenggat. Tanpa pemilik yang jelas, daftar itu hanya akan menjadi dokumen yang tidak pernah ditindaklanjuti.
  5. Transparansi ke manajemen. Laporkan angka 37% dan konsekuensinya dalam satu halaman. Pimpinan berhak memutuskan menerima risiko, tetapi keputusan itu harus tercatat, bukan tersirat.

Dengan cara ini go-live tetap berjalan, tetapi kualitas data tidak dikorbankan secara diam-diam.