Meninjau Risiko CRM di Jasa Keuangan: Apa yang Harus Diperiksa Sebelum Perubahan Berikutnya

Dalam organisasi jasa keuangan, pekerjaan CRM dapat melampaui pencarian calon pembeli hingga tinjauan klien, pengumpulan dokumen, persetujuan internal, dan pelaporan. Ketika tanggung jawab tersebut bertambah, sistem mungkin tidak lagi sesuai dengan proses yang dilakukan orang-orang.

Sebelum menambahkan otomatisasi lain, identifikasi keputusan yang bergantung pada catatan. Siapa yang perlu mengetahui apakah tinjauan klien telah selesai? Bukti manakah yang mendukung persetujuan? Informasi apa yang harus diterima tim lain sebelum dapat mulai bekerja?

Tinjauan ini merupakan latihan operasional dan desain sistem. Hal ini tidak menggantikan nasihat hukum, penilaian peraturan atau tanggung jawab kepatuhan organisasi. Libatkan pemilik risiko atau kepatuhan yang relevan saat menentukan persyaratan dan minta mereka menyetujui pengendalian yang menjadi kewenangan mereka.

Pilih proses yang terbatas, seperti penyerahan dari pertanyaan awal ke tinjauan klien. Mintalah orang yang melakukan pekerjaan untuk menunjukkan formulir, catatan, pesan dan laporan mereka. Bandingkan akun mereka dengan proses yang terdokumentasi.

Sertakan pengecualian: dokumen hilang, penasihat berubah, permintaan untuk mengubah catatan setelah persetujuan, atau klien yang menghentikan sementara penugasan. Pengecualian mengungkapkan ketika orang mengandalkan spreadsheet pribadi atau pesan informal untuk menyelesaikan pekerjaan.

Catat setiap serah terima dengan pengirim, penerima, informasi yang dipertukarkan dan bukti bahwa hal itu diterima. Jika tidak ada yang dapat mengidentifikasi siapa yang memiliki suatu keputusan, tandai itu sebagai pertanyaan terbuka. Jangan menyembunyikannya dengan menggambar panah rapi di antara dua kotak.

Simpan materi sensitif klien dalam pengaturan tinjauan yang disepakati organisasi. Gunakan contoh-contoh yang telah disunting dalam lokakarya ketika catatan lengkap tidak diperlukan. Peninjauan itu sendiri tidak boleh menciptakan kumpulan dokumen klien yang tidak terkendali.

Catatan yang tidak lengkap adalah observasi. Mengapa tidak lengkap memerlukan penyelidikan. Bidangnya mungkin tidak jelas, pengguna mungkin tidak memiliki informasi pada saat itu, atau sistem lain mungkin sudah memiliki jawabannya. Menjadikan bidang tersebut wajib dapat menghasilkan nilai tebakan jika penyebabnya masih belum terselesaikan.

Demikian pula, dua laporan berbeda tidak secara otomatis menjadi bukti adanya data yang korup. Mereka mungkin menggunakan periode, populasi atau definisi yang berbeda. Ikuti contoh catatan melalui kedua laporan sebelum memutuskan apakah koreksi termasuk dalam data, konfigurasi, atau definisi bisnis.

Pertahankan agar perbedaan tetap terlihat dalam temuan Anda: apa yang diamati, bukti apa yang mendukungnya, kemungkinan konsekuensinya, dan apa yang masih perlu dikonfirmasi. Hal ini mencegah hipotesis awal menjadi persyaratan yang disetujui tanpa tinjauan.

Perlakukan hal ini sebagai daftar periksa awal dan bukan sebagai pernyataan persyaratan hukum. Kontrol yang sesuai bergantung pada aktivitas, data, dan kewajiban Anda. Peninjau harus menguji perilaku sebenarnya dengan akses resmi, tidak hanya mengandalkan tangkapan layar pengaturan.

Temuan yang berguna menyebutkan proses yang terkena dampak dan buktinya. Misalnya, tinjauan ilustratif mungkin mengidentifikasi bahwa kasus yang dipindahkan tetap mempertahankan tugas yang dimiliki oleh mantan penasihat tersebut. Pengamatan adalah penanggung jawab tugas yang basi. Konsekuensi yang mungkin terjadi adalah tidak adanya tindak lanjut. Langkah selanjutnya adalah mengkonfirmasi aturan penugasan kembali dan menguji koreksi.

Jangan mendeskripsikan contoh tersebut sebagai cacat pada sistem klien tertentu kecuali jika hal tersebut telah diamati. Contoh yang berhasil membantu tim memahami metode sambil menjaga perbedaan antara panduan dan bukti.

Untuk tinjauan sebenarnya, catat ruang lingkup sampel dan batasan kesimpulannya. Menemukan masalah di beberapa catatan tidak memberi tahu Anda prevalensinya di seluruh database. Jika cakupan yang lebih luas penting bagi keputusan tersebut, setujui pemeriksaan tambahan.

Tindakan kelompok berdasarkan pekerjaan yang diperlukan. Beberapa di antaranya mungkin memerlukan solusi operasional segera, seperti menetapkan tanggung jawab atas antrean yang tidak dipantau oleh siapa pun. Lainnya memerlukan perubahan konfigurasi, pembersihan data, atau keputusan tentang proses di masa depan.

Urutkan dependensinya. Koreksi dasbor mungkin bergantung pada definisi yang disepakati; definisi tersebut mungkin bergantung pada organisasi yang memutuskan sistem mana yang memiliki status. Pembuatan laporan terlebih dahulu akan menghasilkan pengerjaan ulang jika keputusan tersebut kemudian berubah.

Untuk setiap tindakan, identifikasi pemilik bisnis, pemilik implementasi, dan bukti yang diperlukan untuk menutupnya. Tugas pengembangan yang diselesaikan tidak sama dengan bisnis yang mengonfirmasi bahwa proses yang diperbaiki berhasil. Pertahankan agar pertanyaan yang belum terselesaikan tetap terlihat daripada memasukkannya ke dalam label “fase dua” yang luas.

Gunakan skenario pengujian yang diperoleh dari tinjauan. Meliputi pekerjaan normal, informasi yang tidak lengkap, penugasan ulang, dan pengecualian yang relevan dengan ruang lingkup. Periksa bagaimana perubahan yang diusulkan memengaruhi laporan dan integrasi serta layar yang sedang diedit.

Mintalah pemilik proses meninjau hasilnya dan mendokumentasikan penerimaannya. Siapkan instruksi untuk orang-orang yang pekerjaannya berubah. Jika perubahan tersebut memperkenalkan kontrol baru, konfirmasikan siapa yang memantaunya dan bagaimana mereka akan mengenali kegagalan.

Setelah rilis, periksa sampel catatan baru dan masalah yang diangkat oleh pengguna. Beginilah cara tim memeriksa apakah perubahan tersebut memperbaiki masalah yang diamati. Jangan mengklaim pengurangan risiko operasional atau peraturan tanpa dasar yang disepakati untuk kesimpulan tersebut.

• Penjelasan tentang proses dan keputusan yang didukungnya.
• Peran yang terlibat, termasuk bisnis dan pemilik risiko.
• Peta proses saat ini, formulir dan definisi laporan yang relevan.
• Sampel resmi kecil yang mencakup pekerjaan normal dan luar biasa.
• Masalah yang diketahui, perubahan terkini dan usulan investasi berikutnya.

Artikel asli Zolution menjelaskan pemetaan proses, wawancara, audit CRM, dan pekerjaan peta jalan. Hal-hal ini tetap menjadi inti dari pendekatan ini. SEBUAH Tinjauan CRM dapat menentukan pertanyaan mana yang perlu dijawab sebelum pekerjaan konfigurasi atau integrasi dimulai.