Database ERP terus membesar, folder dokumen menyimpan banyak revisi, dan ekspor laporan tersebar di komputer tim. Menghapus semuanya yang terlihat lama berisiko menghilangkan bukti transaksi. Menyimpan semuanya selamanya juga menyulitkan pengendalian akses, pencarian, dan biaya penyimpanan. Perusahaan membutuhkan keputusan yang lebih jelas daripada sekadar menambah kapasitas server.
Retensi data enterprise adalah pengaturan berapa lama suatu kelompok data perlu dipertahankan, sejak peristiwa apa masa simpan dihitung, siapa yang berwenang mengambil keputusan, dan apa yang terjadi setelah periode tersebut selesai. Hasilnya berupa aturan operasional yang dapat diterapkan pada aplikasi, dokumen, integrasi, serta salinan turunannya.
Panduan ini ditujukan bagi kepala IT, operations, finance, dan pemilik data yang ingin menyusun matriks retensi sebelum mengotomatisasi pengarsipan atau penghapusan. Fokusnya adalah lifecycle penyimpanan dan keputusan akhir data, bukan migrasi ERP, pemetaan asal data, atau desain log aktivitas.
Mengapa kebijakan retensi perlu mengikuti proses bisnis?
Usia file tidak selalu menunjukkan bahwa informasi sudah tidak dibutuhkan. Kontrak yang dibuat beberapa tahun lalu mungkin masih aktif. Pesanan yang lama dapat berkaitan dengan retur yang belum selesai. Sebaliknya, ekspor sementara untuk pemeriksaan harian mungkin sudah tidak diperlukan meskipun baru dibuat.
Karena itu, pisahkan tanggal pembuatan data dari peristiwa bisnis yang memulai masa simpan. Peristiwa tersebut dapat berupa penutupan transaksi, berakhirnya kontrak, atau selesainya suatu perkara. Pilihan pemicu harus dapat dibuktikan dari sistem yang memiliki kewenangan atas status tersebut.
Menetapkan periode seragam untuk semua data memudahkan konfigurasi, tetapi dapat mengabaikan perbedaan kebutuhan. Dokumen pembelian, data kandidat karyawan, file debug, dan laporan agregat membutuhkan penilaian masing-masing. Durasi final harus ditentukan bersama fungsi bisnis, legal, dan compliance sesuai aturan yang berlaku pada organisasi; artikel ini tidak menetapkan angka masa simpan wajib.
Bedakan retensi, arsip, backup, dan legal hold
- Retensi: keputusan tentang masa simpan dan tindakan setelahnya untuk kelompok data tertentu.
- Arsip: pemindahan data dari penggunaan aktif ke penyimpanan yang tetap dapat ditemukan dan dibaca sesuai kebutuhan. Arsip tetap membutuhkan aturan retensi dan akses.
- Backup: salinan untuk pemulihan ketika sistem gagal atau data rusak. Siklus backup harus dikoordinasikan dengan kebijakan data, bukan dijadikan tempat menyimpan seluruh histori tanpa batas.
- Legal hold: penahanan data yang relevan agar tidak dihapus selama kebutuhan investigasi atau proses hukum yang ditetapkan pihak berwenang dalam organisasi.
Dokumentasi Microsoft Purview membedakan pengaturan mempertahankan data, menghapus data, serta mempertahankan kemudian menghapus. Dokumentasi tersebut juga menjelaskan penerapan aturan pada lokasi dan label pada item. Ini menunjukkan perlunya memilih tingkat pengaturan yang sesuai; fitur suatu produk tidak otomatis berlaku pada ERP atau aplikasi custom.
Dalam rancangan kebijakan perusahaan, data yang sedang ditahan harus dikecualikan dari penghapusan rutin sampai pelepasan hold disetujui. Cara sistem menegakkan pengecualian itu perlu diuji. Jangan menganggap pemberitahuan melalui email sudah cukup untuk menghentikan job penghapusan otomatis.
Untuk kebutuhan pemulihan layanan, hubungkan kebijakan ini dengan perencanaan disaster recovery aplikasi enterprise. Rencana pemulihan harus memperhitungkan apakah salinan yang dipulihkan akan mengembalikan data yang sebelumnya telah dihapus melalui proses yang sah.
Susun matriks retensi yang bisa diterjemahkan menjadi aturan sistem
Matriks yang hanya berisi nama dokumen dan jumlah tahun belum cukup untuk implementasi. Gunakan struktur berikut sebagai bahan workshop lintas fungsi. Isinya merupakan rekomendasi desain, bukan ketentuan hukum atau konfigurasi universal.
- Kelompok data: definisikan jenis informasi, tujuan penggunaan, dan batasnya. Bedakan transaksi utama, lampiran, ekspor, log, serta data turunan.
- Owner keputusan: tunjuk pemilik proses yang menetapkan kebutuhan, beserta fungsi peninjau dan pemberi persetujuan.
- Dasar penyimpanan: catat kebutuhan bisnis, kontrak, kebijakan, atau aturan yang sudah diverifikasi. Hindari alasan kosong seperti “mungkin diperlukan”.
- Pemicu masa simpan: tentukan event, sumber status, zona waktu, dan perlakuan bila event belum tersedia atau dikoreksi.
- Periode: simpan durasi yang telah disetujui, versi kebijakan, tanggal efektif, serta kondisi pengecualian.
- Lokasi dan salinan: petakan aplikasi utama, lampiran, object storage, warehouse, indeks pencarian, cache, ekspor, dan backup yang relevan.
- Tindakan akhir: pilih evaluasi ulang, arsip, penghapusan, atau transformasi tertentu yang sesuai kebutuhan. Tentukan bukti keberhasilan setiap tindakan.
- Hold dan approval: jelaskan siapa yang dapat menahan, melepas, meninjau, serta menyetujui pemrosesan akhir.
Contoh ilustratif: untuk dokumen kontrak, pemicu dapat berupa status kontrak berakhir dari sistem legal. Jika status itu belum terkonfirmasi, dokumen masuk daftar pengecualian. Masa simpan tidak dimulai hanya karena tanggal file lama. Contoh ini membantu membahas logika; durasi serta kewenangan tetap mengikuti keputusan organisasi.
Inventaris lokasi lebih mudah ditelusuri bila perusahaan telah memiliki pemetaan data lineage enterprise. Lineage menjelaskan asal dan perpindahan informasi, sedangkan matriks retensi menetapkan apa yang harus dilakukan terhadap informasi tersebut sepanjang lifecycle.
Petakan hubungan data sebelum mengarsipkan atau menghapus
ERP menyimpan relasi antara order, pengiriman, invoice, pembayaran, dan jurnal. Menghapus satu bagian karena melewati tanggal tertentu dapat membuat laporan atau penelusuran transaksi kehilangan konteks. Lampiran di storage juga dapat tertinggal setelah baris database dihapus, sehingga pekerjaan terlihat selesai padahal salinan masih ada.
Mulailah dari diagram hubungan dan daftar penggunaan. Tanyakan apakah laporan historis masih membaca data aktif, apakah audit memerlukan lampiran asli, dan apakah aplikasi lain menyimpan salinan. Tentukan unit pemrosesan: satu dokumen beserta seluruh komponennya, satu kelompok transaksi, atau objek lain yang sesuai domain.
Arsip perlu mempertahankan metadata yang membuat informasi dapat ditemukan: identitas bisnis, periode, entitas, versi, owner, serta keterkaitan dokumen. Uji apakah pengguna berwenang masih dapat mencari dan membaca arsip dengan perangkat serta aplikasi yang tersedia. File yang tersimpan tetapi tidak bisa dibuka belum memenuhi tujuan pengarsipan.
Rancang penghapusan sebagai workflow terkendali
Jangan langsung menghubungkan matriks baru ke job produksi yang menghapus data. Pisahkan seleksi kandidat, evaluasi pengecualian, persetujuan, eksekusi, dan verifikasi. Pemisahan ini memberi perusahaan kesempatan menemukan kesalahan aturan sebelum menghasilkan perubahan permanen.
1. Seleksi kandidat tanpa mutasi
Jalankan dry run yang menghasilkan daftar objek, dasar aturan, pemicu, usia, lokasi, dan perkiraan dampak. Cocokkan sampel dengan pemilik data. Bila status pemicu tidak lengkap atau terdapat relasi yang belum dipetakan, tahan kandidat tersebut untuk peninjauan.
2. Periksa hold dan perubahan status
Daftar kandidat bisa kedaluwarsa. Sebuah dokumen dapat terkena hold setelah dry run, atau transaksi dibuka kembali untuk koreksi. Periksa ulang kondisi kelayakan mendekati eksekusi. Simpan alasan pengecualian dan jangan mengubahnya menjadi kandidat baru secara otomatis tanpa evaluasi.
3. Gunakan batch terbatas dan identitas job
Setiap batch membutuhkan identitas, versi kebijakan, scope, pemberi persetujuan, serta batas penghentian. Pengulangan job setelah timeout harus memeriksa hasil sebelumnya agar tidak salah memproses objek yang sudah berubah. Batasi beban kerja supaya proses retensi tidak mengganggu transaksi aktif.
4. Verifikasi hasil dan salinan turunannya
Bukti selesai perlu menunjukkan hasil pada lokasi yang termasuk scope. Bedakan objek yang dihapus, ditahan, gagal, atau belum diverifikasi. Penghapusan dari database belum membuktikan indeks pencarian atau ekspor sudah mengikuti aturan. Catat sistem yang membutuhkan mekanisme tersendiri dan PIC penyelesaiannya.
Catatan job sebaiknya memuat metadata keputusan tanpa menggandakan seluruh isi sensitif. Gunakan prinsip audit trail aplikasi enterprise agar perubahan kebijakan, approval, dan tindakan akhir dapat ditelusuri. Retensi bukti pemrosesan sendiri juga perlu diatur.
Kelola backup, restore, dan data turunan secara eksplisit
Beberapa sistem backup tidak dirancang untuk menghapus satu record dari setiap snapshot. Sebelum menjanjikan penghapusan menyeluruh, dokumentasikan kemampuan produk, siklus kedaluwarsa salinan, pembatasan akses, serta prosedur restore. Pemilik kebijakan perlu memahami batas teknis dan menyetujui perlakuannya berdasarkan kewajiban yang relevan.
Saat restore dilakukan, sistem dapat kembali ke keadaan sebelum suatu penghapusan. Rancang pemeriksaan pascapemulihan terhadap keputusan retensi dan hold yang masih berlaku. Metadata keputusan harus cukup untuk rekonsiliasi, namun tidak boleh menjadi salinan baru dari isi data yang sudah tidak perlu disimpan.
Data pada warehouse, dashboard, dan ekspor membutuhkan keputusan terpisah berdasarkan tujuan penggunaannya. Agregasi tidak otomatis berarti anonim. Jika individu masih dapat dikenali dari atribut atau kombinasi data, jangan menyebutnya telah dianonimkan tanpa pengujian yang sesuai.
Checklist uji sebelum retensi otomatis diaktifkan
Gunakan lingkungan uji dan data sintetis untuk membuktikan aturan. Berikut skenario yang layak dimasukkan ke acceptance criteria:
- Objek tepat sebelum dan sesudah batas periode diperlakukan sesuai aturan.
- Event pemicu kosong, terlambat, atau dikoreksi menghasilkan pengecualian yang jelas.
- Hold aktif mencegah kandidat masuk pemrosesan akhir, termasuk hold yang muncul setelah dry run.
- Dokumen dengan relasi aktif atau perkara belum selesai tidak diproses tanpa keputusan yang tepat.
- Job berhenti di tengah batch dan dilanjutkan tanpa kehilangan pencatatan hasil.
- Database, lampiran, indeks, dan salinan dalam scope menghasilkan status yang dapat dibuktikan.
- Pengguna tanpa kewenangan tidak bisa mengubah periode atau menyetujui batch.
- Arsip dapat ditemukan dan dibaca oleh pengguna berwenang, sementara akses lain ditolak.
- Restore diikuti rekonsiliasi kebijakan sehingga data yang kembali tidak otomatis aktif tanpa evaluasi.
Kriteria lulus tidak cukup berupa “job berhasil”. Owner harus dapat menjelaskan mengapa suatu objek masuk kandidat, siapa yang menyetujui, apa hasil setiap lokasi, dan bagaimana pengecualian ditutup. Perubahan permanen di produksi tetap memerlukan kewenangan khusus dan kontrol organisasi.
Mulai dari pilot yang memiliki owner dan bukti
Pilih satu kelompok data yang batasnya jelas dan pemiliknya tersedia. Hindari menjadikan seluruh ERP sebagai pilot pertama. Urutan yang disarankan: inventaris kebutuhan dan lokasi, persetujuan matriks, dry run, koreksi aturan, uji pemulihan, lalu aktivasi terbatas dengan monitoring.
Ukur proporsi kelompok data yang memiliki owner, kandidat yang tertahan karena metadata tidak lengkap, kegagalan pemrosesan, waktu penutupan pengecualian, serta kemampuan menemukan arsip. Penghematan storage dapat dicatat setelah ada baseline dan pengukuran; jangan menetapkan persentase penghematan tanpa melihat volume serta pola salinan aktual.
Jika dry run menghasilkan banyak kandidat yang masih dibutuhkan, tunda otomatisasi. Perbaiki pemicu dan definisi kelompok data terlebih dahulu. Mempercepat penghapusan dengan aturan yang belum stabil akan memperbesar risiko, bukan menyelesaikan tata kelola.
Pertanyaan yang sering diajukan
Apakah semua data enterprise harus disimpan selamanya?
Tidak ada satu keputusan yang tepat untuk semua kelompok data. Tentukan tujuan, kewajiban, peristiwa pemicu, dan pengecualian masing-masing. Keputusan menyimpan tanpa batas juga membutuhkan alasan dan owner, bukan menjadi pengaturan default karena tim belum menyusun kebijakan.
Apakah memindahkan data ke arsip sudah menyelesaikan retensi?
Belum. Arsip memerlukan pencarian, keterbacaan, akses, masa simpan, dan tindakan akhir. Perusahaan tetap harus mengetahui lokasi serta hubungan salinannya agar kebijakan tidak berhenti pada database utama.
Siapa yang seharusnya menetapkan masa simpan?
Pemilik proses bekerja bersama legal, compliance, records management bila tersedia, dan IT. Fungsi bisnis menjelaskan kebutuhan; fungsi terkait memvalidasi kewajiban; IT menilai penerapan serta buktinya. Pengembang tidak seharusnya menetapkan durasi hanya berdasarkan kapasitas server.
Siapkan brief retensi sebelum memilih alat
Retensi data enterprise yang dapat dijalankan dimulai dari kelompok data, owner, pemicu, lokasi, hold, dan bukti tindakan akhir. Setelah keputusan tersebut jelas, perusahaan dapat memilih apakah kemampuan aplikasi yang tersedia sudah cukup atau membutuhkan penyesuaian dan integrasi.
Untuk diskusi awal, siapkan daftar aplikasi, kelompok data prioritas, lokasi salinan, aturan yang sudah disetujui, kendala arsip, serta PIC bisnis dan IT. Jangan mengirim data pelanggan atau dokumen sensitif untuk sekadar menjelaskan kebutuhan; gunakan contoh yang telah disamarkan.
Pelajari layanan sistem integrator Layana.ID, lalu konsultasikan pemetaan retensi dan lifecycle data untuk menyusun scope, dependency, dan tahapan implementasi yang sesuai sistem perusahaan.
Sumber acuan dan batas penerapan
Konsep mempertahankan, menghapus, dan mempertahankan kemudian menghapus, serta pengaturan pada lokasi dan item, merujuk Microsoft Learn: Learn about retention policies and retention labels untuk Microsoft Purview. Matriks, workflow, checklist, dan pilot dalam artikel ini merupakan rekomendasi penerapan. Kemampuan produk perlu diperiksa pada platform masing-masing; durasi simpan dan keputusan hukum harus ditetapkan oleh pihak berwenang sesuai konteks organisasi.