Bahasa Indonesia

Pengarsipan Jangka Panjang Data CRM Lama: Apa yang Perlu Disimpan dan Caranya

Sebuah perusahaan bermigrasi dari Salesforce pada tahun 2021. Proses migrasi data berjalan lancar. CRM baru sudah berfungsi. Namun tidak ada satu pun yang mengambil keputusan tentang apa yang harus dilakukan dengan Salesforce org lama itu.

Dua tahun kemudian, mereka masih membayar lisensi Salesforce. Dua puluh lisensi dengan harga $150 per bulan: $36.000 per tahun hanya untuk akses read-only ke data historis yang baru dilihat oleh tiga orang di perusahaan selama enam bulan terakhir. Alasan belum dibatalkan: "Kami tidak yakin apa yang ada di sana yang mungkin kami butuhkan."

Sebuah insiden tata kelola data pada tahun 2023 (permintaan penghapusan GDPR yang mengharuskan pencarian dan penghapusan rekaman di semua sistem) akhirnya memaksa pengambilan keputusan. Mereka menghabiskan tiga minggu mengaudit Salesforce org, menemukan sebagian besar datanya redundan dengan CRM baru, mengekspor yang tidak redundan, lalu membatalkan langganan. Total biaya akibat penundaan: $72.000 biaya lisensi yang tidak perlu, tiga minggu waktu IT, dan respons GDPR yang memakan waktu 14 hari alih-alih 2 hari.

Keputusan pengarsipan yang seharusnya dibuat pada 2021 baru terjadi pada 2023. Panduan ini adalah keputusan tersebut, yang dibuat pada waktu yang tepat. Panduan ini melanjutkan dari mana audit data pasca-migrasi berakhir: setelah audit 72 jam dan 30 hari mengonfirmasi bahwa CRM baru sudah lengkap, peran sistem sumber beralih dari jaring pengaman rollback menjadi arsip data historis.

Apa yang Wajib Anda Simpan Secara Hukum

Sebelum memutuskan apa yang akan diarsipkan, pahami dulu apa yang wajib Anda simpan secara hukum. Jawabannya berbeda-beda tergantung wilayah, industri, dan jenis rekaman.

GDPR (Uni Eropa dan Inggris):

GDPR menciptakan ketegangan yang belum sepenuhnya diselesaikan oleh banyak perusahaan: hak untuk dihapus (individu dapat meminta datanya dihapus) versus kewajiban retensi yang sah (Anda mungkin perlu menyimpan data tertentu untuk alasan hukum atau kontraktual). Artikel Wikipedia tentang GDPR membahas ketentuan hak penghapusan (Pasal 17) dan pengecualian untuk retensi kewajiban hukum, yang keduanya secara langsung mempengaruhi data CRM yang diarsipkan dan harus dapat dihapus atas permintaan.

Dalam praktiknya, untuk data CRM:

  • Anda dapat menyimpan data yang memiliki kepentingan bisnis yang sah (hubungan pelanggan aktif, kewajiban kontraktual)
  • Anda wajib menghapus data atas permintaan penghapusan, dengan pengecualian terbatas
  • Periode retensi harus ditetapkan, "kami menyimpannya tanpa batas waktu" tidak sesuai dengan GDPR
  • Anda harus dapat membuktikan bahwa data warisan yang diarsipkan tercakup dalam peta data Anda (artinya, jika seseorang mengajukan permintaan penghapusan, Anda harus dapat menemukan dan menghapus rekamannya di arsip juga)

Retensi data di AS:

Tidak ada satu undang-undang federal tentang retensi data CRM, namun aturan khusus sektor berlaku:

  • Jasa keuangan (SEC Rule 17a-4): rekaman bisnis tertentu harus disimpan selama 3-7 tahun dalam format yang tidak dapat dihapus
  • Layanan kesehatan (HIPAA): jika CRM Anda mengandung PHI, aturan retensi sangat ketat dan prosedur penghapusan harus didokumentasikan
  • California (CCPA): konsumen memiliki hak penghapusan serupa dengan GDPR; arsip Anda harus mendukung permintaan penghapusan tersebut

Panduan NIST tentang retensi dan pembuangan data menyediakan kerangka kerja yang tidak terikat teknologi untuk menentukan periode retensi dan prosedur penghapusan yang aman, berguna sebagai referensi kepatuhan terlepas dari regulasi khusus sektor yang berlaku bagi bisnis Anda.

Rekaman komersial umum:

Data terkait kontrak (ketentuan kesepakatan, perjanjian yang ditandatangani, komunikasi pelanggan seputar negosiasi kontrak) sering masuk dalam kategori retensi rekaman komersial umum, biasanya 7 tahun di AS dan EU untuk rekaman keuangan.

Siapa yang bertanggung jawab atas keputusan ini:

Legal atau tim kepatuhan, dengan masukan dari IT dan RevOps. Ini bukan keputusan IT secara sepihak. Dapatkan memo yang ditandatangani dari legal atau kepatuhan yang menetapkan periode retensi Anda berdasarkan jenis rekaman sebelum mengarsipkan apa pun. Jenis rekaman yang menjadi dasar keputusan retensi ini tumpang tindih langsung dengan cakupan yang ditetapkan dalam penanganan aktivitas historis, catatan, dan email, yaitu apa yang Anda pilih untuk dimigrasi, diarsipkan, atau dibuang pada saat ekspor yang kini memerlukan perlakuan retensi formal.

Kerangka Kerja Keputusan Retensi

Dengan memahami dasar hukum, terapkan kebijakan retensi berdasarkan jenis rekaman.

Template kebijakan retensi:

Jenis rekaman Retensi yang direkomendasikan Alasan
Kesepakatan yang berhasil ditutup (data kontrak, ketentuan kesepakatan) Minimal 7 tahun Rekaman komersial, kontrak yang dapat diaudit
Kesepakatan yang gagal ditutup 3 tahun Analisis Pipeline, referensi kompetitif
Kontak aktif pada saat migrasi 3 tahun pasca-migrasi Referensi hubungan bisnis yang sedang berjalan
Kontak tidak aktif (tidak ada keterlibatan dalam 2 tahun ke atas) 1 tahun pasca-migrasi, lalu hapus Tidak ada kepentingan yang sah setelah penghapusan
Log aktivitas: catatan yang dimasukkan rep 3 tahun Konteks hubungan, penyelesaian sengketa
Log aktivitas: kejadian yang dihasilkan sistem Maksimal 1 tahun Sinyal rendah; tidak ada kewajiban retensi
Metadata email (subjek, tanggal, pengirim) 2 tahun Cukup untuk sebagian besar kebutuhan referensi
Isi email 3 tahun untuk email terkait kesepakatan Referensi kontrak/sengketa
Snapshot laporan kustom 5 tahun Rekaman kinerja bisnis
Log akses pengguna dan audit 3-5 tahun Persyaratan keamanan dan kepatuhan

Siapa yang memutuskan:

Legal atau kepatuhan mengesahkan periode retensi. RevOps mengusulkan jenis rekaman dan alasan bisnis. IT bertanggung jawab atas implementasi (format apa, di mana disimpan, bagaimana cara mengaksesnya).

Dokumentasikan keputusan secara formal. Kebijakan retensi tidak harus berupa dokumen 50 halaman, namun harus ada sebagai rekaman tertulis yang telah ditinjau dan disetujui. Jika regulator menanyakan praktik retensi data Anda dua tahun ke depan, "kami mendiskusikannya dalam rapat" bukan jawaban yang dapat diterima.

Memilih Format Arsip

Format arsip menentukan apa yang dapat Anda lakukan dengan data tersebut di kemudian hari. Optimalkan untuk: portabilitas (dapat dibaca tanpa sistem sumber), kemampuan kueri (apakah seseorang dapat mencarinya?), dan biaya.

Opsi A: Ekspor CSV + JSON

Ekspor semua objek sebagai file CSV flat (satu file per objek) ditambah data relasi sebagai JSON atau tabel join terpisah. Simpan bersama kamus data yang memetakan setiap kolom ke nama dan tipe bidang.

Kelebihan: Alat apa pun dapat membacanya. Tidak terikat vendor. Mudah diaudit untuk permintaan penghapusan. Dapat dibuka di Excel, Sheets, atau alat data apa pun.

Kekurangan: Kueri memerlukan pemuatan ke database atau penggunaan alat spreadsheet. Relasi antara objek memerlukan join manual.

Terbaik untuk: Sebagian besar tim. Sederhana, tahan lama, portabel.

Opsi B: Database dump

Backup lengkap dari database CRM sumber yang mendasarinya (jika vendor menyediakannya).

Kelebihan: Dapat dipulihkan ke instans baru jika diperlukan. Mempertahankan semua relasi secara native.

Kekurangan: Format sering kali bersifat proprietary atau spesifik versi. Pemulihan memerlukan infrastruktur yang sesuai. Tidak dapat dibaca manusia tanpa alat bantu.

Terbaik untuk: Tim dengan kapabilitas IT yang menginginkan opsi untuk memulihkan sistem sumber sementara (misalnya, untuk permintaan temuan hukum besar).

Opsi C: Cloud data warehouse (BigQuery, Redshift, Snowflake)

Ekspor data CRM ke cloud warehouse terstruktur yang dapat dikueri via SQL.

Kelebihan: Sepenuhnya dapat dikueri. Menangani permintaan penghapusan via SQL DELETE. Skalabel. Dapat dihubungkan ke alat BI.

Kekurangan: Memerlukan penyiapan infrastruktur cloud dan pemeliharaan berkelanjutan. Berlebihan untuk sebagian besar tim dengan kurang dari 100.000 kontak.

Terbaik untuk: Tim yang sudah menggunakan data warehouse dan ingin riwayat CRM menjadi bagiannya.

Opsi D: Ekspor terkelola SaaS-ke-cloud (Salesforce Data Archive, alat pengarsipan HubSpot)

Beberapa vendor menawarkan pengarsipan native yang memindahkan data lama ke tingkat penyimpanan yang lebih murah sekaligus tetap dapat dikueri melalui platform.

Kelebihan: Tetap dalam antarmuka platform yang sudah familiar. Upaya migrasi minimal.

Kekurangan: Masih memerlukan lisensi vendor. Tidak benar-benar menonaktifkan sistem sumber. Tidak menyelesaikan masalah "kami membayar untuk sistem yang tidak kami gunakan".

Terbaik untuk: Perusahaan yang membutuhkan solusi arsip jangka pendek sembari merencanakan penonaktifan penuh.

Perbandingan format arsip:

Format Portabilitas Kemampuan kueri Biaya Kompleksitas
CSV + JSON Tinggi Rendah (manual) Hampir nol Rendah
Database dump Rendah (proprietary) Rendah (perlu restore) Rendah Sedang
Cloud warehouse Tinggi Tinggi (SQL) Rendah-sedang (hanya penyimpanan) Sedang
SaaS-ke-cloud terkelola Sedang Sedang Sedang (lisensi) Rendah

Opsi Penyimpanan dan Biaya

Setelah memilih format arsip, tentukan di mana arsip tersebut disimpan.

Cold storage (AWS Glacier, Azure Archive, Google Coldline):

  • Biaya: sekitar $0,004/GB/bulan (AWS Glacier Deep Archive)
  • Waktu pengambilan: Jam hingga hari
  • Terbaik untuk: Data yang mungkin diperlukan untuk keperluan hukum/kepatuhan namun tidak sering diakses
  • Biaya pengambilan: $0,02/GB untuk ekspedisi; lebih rendah untuk standar

Untuk ekspor CRM 100 GB (tipikal untuk CRM berusia 5 tahun dengan 100.000 kontak), cold storage memakan biaya sekitar $0,40 per bulan. Arsip 5 tahun membutuhkan biaya penyimpanan sekitar $24. Angka ini bukan salah ketik.

Penyimpanan cloud standar (AWS S3, Azure Blob, Google Cloud Storage):

  • Biaya: sekitar $0,023/GB/bulan (AWS S3 Standard)
  • Pengambilan: Segera
  • Terbaik untuk: Data yang kadang diakses (bulanan atau kuartalan)
  • Titik tengah yang baik antara biaya dan kecepatan akses

Cloud data warehouse (BigQuery, Redshift, Snowflake):

  • Biaya penyimpanan: sekitar $0,02/GB/bulan (BigQuery)
  • Biaya kueri: Tambahan per TB yang dipindai
  • Terbaik untuk: Data yang dikueri secara rutin (mingguan) atau perlu mendukung pencarian mandiri

On-premises:

  • Biaya: Pengeluaran modal untuk perangkat keras dan pemeliharaan IT
  • Akses: Segera
  • Terbaik untuk: Organisasi dengan infrastruktur on-prem yang ada dan persyaratan kedaulatan data yang kuat
  • Kekurangan: Beban pemeliharaan; risiko kegagalan perangkat keras

Untuk sebagian besar perusahaan yang bermigrasi dari CRM mid-market:

Cold storage adalah pilihan default yang tepat untuk data yang lebih dari 2 tahun. Penyimpanan cloud standar untuk data dari 2 tahun terakhir yang mungkin masih dirujuk. Cloud warehouse hanya jika Anda sudah menjalankannya dan biaya inkrementalnya minimal.

Membangun Jalur Akses untuk Tim Penjualan

Rep akan meminta rekaman lama. Bangun prosesnya sebelum permintaan pertama datang.

Volume permintaan yang realistis:

Dalam 30 hari pertama pasca-migrasi, perkirakan 5-15 permintaan per 50 rep. Setelah 90 hari, jumlahnya turun menjadi 1-3 per bulan. Setelah 6 bulan, hampir tidak ada. Rencanakan untuk volume tinggi di awal, lalu volume rendah yang stabil.

Opsi akses, diurutkan berdasarkan kepraktisan:

Opsi 1: Pertahankan sistem sumber read-only selama 90 hari

Pendekatan paling sederhana. Jangan nonaktifkan segera. Berikan rep akses read-only langsung ke CRM lama selama 90 hari. Setelah itu, volume permintaan cukup rendah sehingga proses pencarian manual sudah memadai.

Biaya: Satu kuartal biaya lisensi. Untuk 20 pengguna dengan $75/bulan read-only: $4.500. Sepadan untuk sebagian besar tim agar tidak perlu membangun sistem akses paralel. Periode read-only 90 hari ini juga yang membuat perencanaan rollback tetap layak: jangan mulai proses penonaktifan sampai Anda yakin CRM baru sudah sepenuhnya tervalidasi dan jendela rollback telah ditutup.

Opsi 2: Ajukan permintaan ke IT

Setelah periode read-only berakhir, "ajukan permintaan" menjadi jalur akses. Rep mengirim email ke ops atau IT dengan nama kontak dan alasan. IT mengkueri arsip dan merespons dalam 24 jam.

Ini berfungsi pada volume rendah (kurang dari 5 permintaan per bulan). Tidak skalabel jika permintaan tetap tinggi.

Opsi 3: Kueri arsip mandiri (untuk tim teknis)

UI web ringan atau alat kueri database yang dapat digunakan rep untuk mencari arsip berdasarkan nama kontak atau email. Membutuhkan waktu penyiapan tetapi mengurangi beban IT pada skala besar.

Realistis untuk: Tim yang sudah memiliki alat BI (Tableau, Looker, Metabase) di mana arsip dapat ditambahkan sebagai sumber data.

Menonaktifkan Sistem Sumber dengan Bersih

Penonaktifan adalah langkah terakhir, dan yang paling sering bermasalah jika terburu-buru.

Daftar periksa penonaktifan:

  • Ekspor arsip diverifikasi dan divalidasi (jumlah baris sesuai sumber, contoh rekaman dapat dibaca)
  • Kebijakan retensi telah disahkan oleh legal/kepatuhan
  • Semua integrasi aktif yang mengarah ke CRM sumber telah diidentifikasi dan dialihkan atau dinonaktifkan
  • Konfigurasi SSO/SAML diperbarui (hapus CRM lama dari identity provider)
  • Sinkronisasi email atau kalender yang terhubung ke CRM lama telah diputus
  • Kunci API dan token OAuth yang diterbitkan oleh CRM lama dicabut atau dirotasi di sistem yang terhubung
  • Pembatalan kontrak vendor diajukan dengan periode pemberitahuan yang benar (biasanya 30 hari)
  • Dokumentasi internal diperbarui (runbook, dokumen IT yang merujuk ke sistem lama)
  • Peta data diperbarui untuk menghapus CRM lama (sangat penting untuk dokumentasi kepatuhan GDPR)
  • Backup akhir diambil pada hari pembatalan (sebagai tindakan pencegahan tambahan)

Waktu pembatalan:

Sebagian besar vendor CRM memerlukan pemberitahuan tertulis 30 hari sebelum periode penagihan berakhir. Periksa kontrak Anda. Melewatkan jendela pembatalan satu hari saja dapat berarti satu siklus penagihan penuh lagi.

Integrasi adalah titik kegagalan paling umum dalam penonaktifan. Alat internal yang masih melakukan panggilan API ke CRM lama akan mulai melempar error sehari setelah penonaktifan. Audit semua integrasi sebelum membatalkan. Pencarian sederhana nama domain CRM lama di repositori kode, alur kerja Zapier, dan alat otomatisasi Anda sering kali mengungkap koneksi yang tidak diingat siapa pun. Audit ini juga mengonfirmasi bahwa sinkronisasi email dan kalender telah sepenuhnya dialihkan ke CRM baru sebelum sistem warisan dinonaktifkan.

Kesalahan Umum

Mengarsipkan dalam format proprietary yang hanya bisa dibaca oleh vendor. Jika arsip Anda berformat ekspor Salesforce yang hanya dapat diinterpretasikan oleh alat Salesforce, Anda membayar Salesforce tanpa batas waktu. Arsipkan dalam format terbuka: CSV, JSON, SQL, atau format database standar. Riset tata kelola data dari PwC merekomendasikan format terbuka yang netral terhadap vendor untuk retensi data jangka panjang sebagai bagian dari tata kelola data yang bertanggung jawab, memastikan data yang diarsipkan tetap dapat diakses dan diaudit secara independen dari hubungan vendor.

Mempertahankan sistem sumber aktif melewati masa kegunaannya untuk retensi. Biaya terus bertambah tanpa terasa. Tetapkan tanggal penonaktifan sebelum migrasi selesai. Masukkan dalam rencana proyek. Perlakukan sebagai deliverable.

Tidak mendokumentasikan lokasi arsip dan cara mengaksesnya. Dua tahun ke depan, orang yang mengelola migrasi mungkin sudah tidak ada. Dokumentasikan lokasi arsip, kredensial akses, dan proses kueri di tempat yang bertahan dari pergantian staf.

Lupa API key dan integrasi yang terhubung ke sistem warisan. Setiap alat yang terhubung ke CRM lama (sinkronisasi email, marketing automation, pengayaan data) perlu diaudit sebelum penonaktifan. Satu alur kerja Zapier yang terlupakan yang mengirimkan email konfirmasi ke kontak baru via API CRM lama akan rusak sehari setelah pembatalan, dan mungkin tidak disadari selama berminggu-minggu.

Langkah Berikutnya

Selesaikan dokumen kebijakan retensi dan keputusan format arsip sebelum mencapai 90 hari pasca-migrasi. Jendela antara "migrasi selesai" dan "penonaktifan selesai" biasanya 90-180 hari. Manfaatkan waktu tersebut dengan baik.

Arsip ini terhubung langsung ke penanganan aktivitas historis, catatan, dan email, khususnya rekaman yang Anda putuskan untuk diarsipkan daripada dimigrasi. Rekaman tersebut perlu dapat ditemukan di arsip saat rep memintanya.

Dan audit data pasca-migrasi adalah pemicu yang baik untuk memulai keputusan arsip: setelah audit 72 jam dan 30 hari mengonfirmasi CRM baru sudah lengkap, peran sistem sumber beralih dari "cadangan jika terjadi rollback" menjadi "arsip data historis". Itulah saat yang tepat untuk memulai proses penonaktifan.

Untuk perencanaan rollback, perlu diketahui bahwa begitu Anda mulai menonaktifkan sistem sumber, rollback tidak lagi menjadi opsi. Jangan mulai proses penonaktifan sampai Anda yakin CRM baru sudah sepenuhnya tervalidasi.

Pelajari Lebih Lanjut