Zoho CRM atau Sistem Kustom? Bagaimana Membuat Keputusan Membangun versus Membeli

Pilihannya lebih luas daripada membeli CRM atau menulis keseluruhan sistem. Sebuah bisnis dapat mengonfigurasi Zoho CRM, membuat aplikasi khusus, atau menggunakan CRM untuk pekerjaan penjualan dan aplikasi terpisah untuk operasi khusus. Batasan yang tepat bergantung pada catatan, keputusan, dan pengguna yang terlibat.

Mulailah dengan daftar alur kerja penting. Pisahkan tugas penjualan konvensional, seperti manajemen kontak dan tindak lanjut proposal, dari pekerjaan khusus seperti inspeksi peralatan atau penghitungan layanan yang rumit. Kemudian tanyakan apakah persyaratan yang tidak biasa tersebut penting bagi bisnis atau merupakan pengecualian yang dapat ditangani dengan lebih sederhana.

Evaluasi Anda harus mencakup siapa yang akan memiliki sistem setelah peluncuran. Desain yang memenuhi persyaratan formulir saat ini namun bergantung pada satu pengembang yang tidak tersedia untuk setiap perubahan memiliki risiko berbeda dari konfigurasi yang dapat dikelola oleh administrator Anda.

Kemampuan Zoho CRM yang dipublikasikan mencakup prospek, transaksi, aktivitas, pelaporan, dan penyesuaian. Ini memberikan titik awal untuk pekerjaan penjualan konvensional. Bisnis masih harus menentukan tahapan, tanggung jawab, izin, dan laporan.

Selidiki konfigurasi ketika masalah utama tim Anda adalah tidak adanya tindak lanjut, catatan yang tidak konsisten, atau visibilitas yang buruk di seluruh jalur penjualan. Aplikasi kustom baru dapat menimbulkan masalah yang sama jika tidak ada yang sepakat bagaimana penjualan harus beroperasi.

Uji pengecualian sebelum memutuskan bahwa konfigurasi sudah cukup. Bisakah Anda mempertahankan revisi proposal, mengelola beberapa peluang untuk satu pelanggan, dan membatasi akses berdasarkan peran? Periksa edisi yang dipilih dan upaya administrasi yang diperlukan. Kumpulan skrip yang banyak dapat mengubah profil pemeliharaan dari apa yang awalnya tampak seperti pengaturan standar.

Operasi khusus mungkin memiliki catatan dan siklus hidupnya sendiri. Inspeksi lokasi, misalnya, dapat melibatkan aset, lokasi, foto, temuan, dan tindakan tindak lanjut. Memasukkan semua hal tersebut ke dalam peluang penjualan dapat membuat CRM lebih sulit untuk dipahami.

Zoho Creator menyediakan alat untuk membuat formulir, alur kerja, laporan, dan aplikasi. Ini dapat dipertimbangkan untuk jenis persyaratan ini, namun pengembangan kode rendah masih melibatkan desain, pengujian, izin, dan pemeliharaan berkelanjutan. Aplikasi yang dibuat dengan cepat belum tentu siap untuk penggunaan bisnis.

Jelaskan catatan operasional dalam istilahnya sendiri. Siapa yang menciptakannya? Apa yang membuatnya lengkap? Bisakah itu diubah setelah disetujui? Informasi apa yang harus dilihat oleh tim yang berhadapan dengan pelanggan? Pertanyaan-pertanyaan ini menentukan apakah aplikasi terpisah dapat dibenarkan dan apa yang harus ditukar dengan CRM.

Pertimbangkanlah bisnis jasa lapangan. Contoh hipotetis ini menunjukkan satu kemungkinan pembagian kerja; ini bukan proyek pelanggan yang disampaikan. Penjualan menggunakan CRM untuk mengelola pelanggan, proposal, dan pekerjaan yang disepakati. Insinyur memerlukan pandangan yang berbeda: kunjungan yang ditugaskan, peralatan yang diperiksa, bukti dari lokasi, dan pekerjaan yang masih harus diselesaikan.

Desain yang mungkin menyimpan catatan penjualan di CRM dan catatan inspeksi di aplikasi Creator. Serah terima yang disepakati membuat atau menghubungkan pekerjaan operasional menggunakan pengidentifikasi yang stabil. Aplikasi ini hanya mengembalikan status dan informasi yang dibutuhkan oleh tim penjualan atau manajemen akun.

Masih ada beberapa keputusan sebelum desain ini dapat digunakan. Siapa yang mengubah janji temu? Apa yang terjadi jika pelanggan membatalkan setelah teknisi memulai? Sistem mana yang memiliki alamat kontak? Bagaimana pembaruan yang gagal terdeteksi dan dicoba lagi tanpa membuat pekerjaan kedua?

Gunakan pertanyaan-pertanyaan itu untuk menguji batasannya. Jika setiap perubahan operasional memerlukan rekonsiliasi manual antara dua sistem, desain integrasi mungkin perlu disederhanakan. Jika bisnis dapat memenuhi kebutuhannya dalam satu aplikasi, mungkin tidak ada alasan untuk memperkenalkan aplikasi kedua.

Perbandingan ini menjelaskan tanggung jawab, bukan peringkat biaya tetap. Kompleksitas dapat membuat pendekatan apa pun menjadi mahal. Sistem kustom mungkin dapat dibenarkan, namun kasus tersebut harus menjelaskan mengapa persyaratan tersebut tidak dapat dipenuhi melalui konfigurasi, perluasan, atau perubahan pada proses.

Untuk setiap informasi yang dibagikan, identifikasi sistem otoritatifnya dan siapa yang dapat mengubahnya. Gunakan pengidentifikasi catatan yang stabil; nama dan alamat email saja dapat berubah atau diduplikasi. Setuju dengan apa yang terjadi jika satu record dihapus, digabungkan, atau dikoreksi.

Tentukan peristiwa yang memicu pertukaran dan waktu yang diperlukan. Pembaruan pelaporan harian memiliki kebutuhan yang berbeda dari pekerjaan yang harus terlihat sebelum teknisi berangkat berkunjung. Nyatakan bagaimana pengguna akan mengenali pembaruan yang tertunda dan di mana kegagalan akan ditinjau.

Uji duplikat dan coba ulang. Jika koneksi gagal setelah membuat catatan tetapi sebelum menerima konfirmasi, percobaan ulang tidak boleh membuat salinan lain secara diam-diam. Sertakan perilaku tersebut dalam tes penerimaan dan tugaskan seseorang untuk menjaga koneksi setelah go-live.

Kami kasus operasi akuntansi memberikan contoh yang dipublikasikan tentang Creator, CRM, dan informasi sistem akuntansi yang mendukung pekerjaan di seluruh entitas bisnis. Arsitektur yang tepat untuk perusahaan lain masih memerlukan desainnya sendiri.

Perkirakan biaya menjalankan dan mengubah sistem, bukan hanya pembangunan awal. Sertakan langganan, lingkungan, layanan integrasi, waktu administrator, dokumentasi dan dukungan. Sepakati perubahan mana yang dapat dilakukan oleh administrator bisnis dan mana yang memerlukan pengembangan.

Tanyakan bagaimana pembaruan akan diuji sebelum menjangkau pengguna. Perubahan kecil pada bidang wajib dapat memengaruhi formulir, impor, laporan, dan integrasi. Identifikasi komponen yang terkena dampak dan simpan catatan keputusan sehingga orang berikutnya tidak perlu menyimpulkan desain dari kode.

Uji juga pengaturan jalan keluarnya. Dapatkah organisasi Anda mengekspor catatan yang diperlukan, menyimpan kode dan dokumentasi yang disepakati, dan memberikan akses administrator pengganti? Ini adalah pertanyaan kesinambungan praktis, bahkan ketika Anda mengharapkan hubungan jangka panjang dengan tim implementasi awal.

Sebelum memilih suatu pendekatan, tulislah catatan keputusan singkat. Nyatakan alur kerja, alternatif yang dipertimbangkan dan alasan pilihan yang dipilih. Sertakan asumsi yang dapat mengubah keputusan, seperti volume transaksi, konektivitas lapangan, atau persyaratan persetujuan baru.

• Sebutkan persyaratan yang harus ditunjukkan, termasuk pengecualian.
• Pisahkan konfigurasi dari kode khusus dan pisahkan keduanya dari pekerjaan integrasi.
• Sebutkan orang yang memiliki setiap sistem dan definisi data yang dibagikan.
• Setuju bagaimana pendekatan yang diusulkan akan diuji dan diterima.
• Identifikasi apa yang dapat ditunda tanpa mencegah rilis pertama berfungsi.

Untuk pekerjaan CRM dan Creator Zolution, diskusi desain dimulai dengan batasan tersebut. Memberikan contoh nyata hasil kerja dan sistem yang ada saat ini kepada a melingkupi percakapan; langkah selanjutnya adalah menguji persyaratan terhadap pendekatan paling sederhana yang bisa diterapkan.