Pertanyaan Abadi untuk membeli atau membangun perangkat lunak Anda (James Monaghan)

Selamat. Anda memiliki masalah, proyek, anggaran, dan tenggat waktu. Alih-alih melemparkan tubuh ke dalamnya, perangkat lunak adalah solusinya tetapi sekarang Anda perlu memutuskan untuk membangun atau membeli, itulah pertanyaannya. Atau itu? Saya tidak begitu yakin itu keputusan yang jelas lagi.
Bangun gunakan untuk merujuk pada mempekerjakan pemrogram internal untuk membuat kode sistem apa pun yang diperlukan dan membeli mengacu pada produk siap pakai yang dapat dibeli dan dijalankan. Ini masuk akal ketika kami berbicara tentang sistem akuntansi, sistem Perdagangan, CRM, Pelaporan,
Peminjaman, Pengumpulan, CLM, dll. Kita sekarang hidup di lingkungan kode rendah di mana membangun sesuatu tidak memerlukan pengalaman pengkodean. Bisa drag and drop. Pasangkan itu dengan membeli solusi rak yang akhirnya disesuaikan sedemikian rupa sehingga Anda bisa melakukannya
baik telah membangunnya. Jadi di mana hal itu membuat kita membuat keputusan untuk membangun atau membeli? Mari kita lihat apa yang sebenarnya kita butuhkan.

Tidak ada sistem modern yang dapat mengandalkan satu titik masuk lagi. Harapan klien menentukan bahwa berbagai saluran diperlukan. Secara langsung, melalui telepon langsung atau pusat panggilan, email, media sosial, SMS, web, seluler, tablet – baik yang diaktifkan seluler maupun asli
aplikasi, semua dengan kebutuhan untuk dapat dipertukarkan tanpa kehilangan konten atau konteks. Seorang pelanggan yang memulai di cabang/toko atau secara langsung tetapi harus pergi untuk membuat janji ingin dapat melanjutkan dari bagian terakhir yang mereka tinggalkan ketika mereka masuk hari itu secara online. Atau
jika mereka mulai online tetapi merasa frustrasi dan meminta bantuan, mereka tidak mau harus memulai proses dari awal. Ini juga berlaku untuk pemangku kepentingan internal. Rantai informasi dalam suatu organisasi harus sefleksibel yang dihadapi klien
Pilihan. 

Lalu bagaimana selanjutnya untuk kita mulai input data dimana saja? Nah, ada alasan mengapa kita membutuhkan data itu sejak awal. Apakah klien baru ingin bekerja dengan organisasi, klien lama menginginkan produk atau layanan baru, atau bahkan hanya pertanyaan sehari-hari, keluhan
atau permintaan informasi. Semua ini harus dimulai dengan proses yang ditentukan tetapi fleksibel untuk menyelesaikan permintaan seefisien dan semudah mungkin. Proses umumnya didefinisikan dan biasanya staf dilatih untuk mengikuti urutan tugas untuk menyelesaikannya dengan yang telah ditentukan sebelumnya
tindakan berdasarkan input data tertentu. 

Baik pelanggan akhir maupun pengguna sistem tidak boleh memasukkan ulang informasi di mana pun jika informasi tersebut telah diambil di suatu tempat. Faktanya, jika informasi tersedia di manapun dalam organisasi atau dari sumber pihak ketiga seperti penyedia data, biro kredit,
penyedia penyaringan, dll. itu harus dapat diakses selama proses untuk semua pengguna yang membutuhkannya. Prosesnya ditentukan tetapi titik kontak harus dapat dipertukarkan dan data yang dikumpulkan harus diintegrasikan jika memungkinkan dan terstruktur jika memungkinkan.
Menu tarik-turun, nilai pencarian, bidang tanggal, dan nilai teks bebas terkontrol untuk memastikan pengambilan kualitas data sebanyak mungkin di muka. Ini memungkinkan lebih banyak otomatisasi di seluruh proses dan lebih sedikit penanganan pengecualian.

Sekarang data sedang dalam proses ditangkap atau diperbarui secara aktif, kecerdasan buatan dapat diterapkan. Staf tidak perlu mengetahui semua detail dan bahkan anggota yang lebih baru dapat mengerjakan kasus yang lebih kompleks karena sistem menggunakan aturan kode kebijakan
logika untuk secara otomatis membuat keputusan yang sebelumnya harus ditangani oleh staf yang memiliki pelatihan dan pengalaman ekstensif. Tidak ada lagi kesalahan sementara juga mengizinkan pengawasan dan bahkan pemeriksaan kontrol kualitas atau antrean pengecualian langsung untuk intervensi manual jika diperlukan.

Ini semua membutuhkan pendekatan yang sistematis. Gagasan lama tentang folder manilla yang berada di laci anggota staf untuk portofolio klien mereka sudah usang dan menciptakan risiko yang tidak perlu. Klien yang sedang diproses dalam isolasi dapat membatasi dan berlebihan
pada saat yang sama. Jika pelanggan korporat memiliki direktur yang duduk di beberapa klien lain, mengapa setiap ulasan individu mengabaikan gambaran yang lebih besar. Apakah Anda juga akan meninjau direktur yang sama beberapa kali di setiap hubungan atau dapatkah Anda
melakukannya sekali dan menggunakan kembali informasi tersebut di seluruh organisasi?

Mereka bahkan tidak harus memiliki pihak terkait yang sama agar manfaatnya terlihat. Industri serupa, pelanggan klien serupa, bagaimana jika vendor/pemasok klien Anda juga klien itu sendiri? Ini membawa kita ke bagaimana Anda perlu memproses informasi
dan mengapa organisasi perlu melihat ke seluruh perusahaan saat mempertimbangkan perangkat lunak akhir-akhir ini. Jika Anda melihat masalah secara terpisah dan memperlakukannya seperti itu, menetapkan anggaran dan mengeluarkan RFP untuk setiap komponen CRM, Fincrime, Client Outreach, Anda akan berakhir
dengan menghabiskan lebih banyak sumber daya untuk mencoba mengintegrasikan semuanya bersama-sama daripada potensi penghematan yang awalnya diharapkan. Sekarang terapkan itu untuk setiap wilayah atau lini bisnis yang mungkin mendapatkan anggaran dan pengawasan terpisah dan Anda akan mendapatkan 8 versi
dari perangkat lunak yang sama yang perlu diintegrasikan dengan dirinya sendiri karena penyesuaian yang berat per area menghilangkan skala ekonomi yang dapat mereka capai.

Folder di laci yang perlu ditinjau setiap tahun atau sebaliknya, dengan staf perlu dilatih apa yang harus dilakukan dan kapan melakukannya. Seluruh ulasan (atau onboarding baru/produk/layanan tambahan/dll) dapat dipecah menjadi bagian komposit yang mungkin atau
tidak boleh ditangani oleh orang/tim lain. Sistem kemudian dapat menentukan kapan suatu tugas selesai atau kapan cukup data diambil untuk dikirim ke orang berikutnya untuk input mereka. Semua ini disusun sebagai kasus dan sub-kasus di dalamnya. Dengan cara ini setiap elemen dari
kasus dapat memiliki tenggat waktu, jalur eskalasi, penerima tugas, dan pemberi persetujuannya sendiri. Alih-alih satu tugas besar yang harus dimiliki seorang anggota staf yang cukup berpengalaman untuk mengetahui cara menyelesaikan dan kepada siapa harus pergi untuk berbagai elemen di dalamnya, sistem sekarang menugaskan pekerjaan
dan memastikan penyelesaian tepat waktu di seluruh perusahaan dengan sebanyak mungkin tugas terotomatisasi untuk membebaskan pembuat keputusan untuk fokus pada hal yang penting.

Ini semua baik dan bagus dari sudut pandang bisnis. Pekerjaan diketahui dan apa yang perlu dilakukan. Tetapi ketika kami mencoba untuk memutuskan apakah kami harus membeli atau membuat perangkat lunak sendiri, bagaimana faktor itu menjadi faktor? Baiklah anggap saja ada banyak sumber
data di beberapa sistem. Sistem modern apa pun diharapkan digerakkan oleh API dan memiliki kemampuan kode rendah/tanpa kode. Asumsi yang masuk akal untuk perangkat lunak yang lebih cepat dan fleksibel. Segala sesuatu hari ini perlu diperlakukan sebagai semacam layanan mikro yang harus dihindari
monolit perangkat lunak gaya lama. Perangkat lunak harus diinstal dan digunakan karena merupakan yang terbaik yang tersedia dan terbukti di masa mendatang untuk beradaptasi dengan perubahan sesuai kebutuhan. Terlalu banyak penawaran yang mengakar dan hanya dipertahankan karena terlalu sulit dan memakan waktu
untuk menggantikan. Sebagian besar karena aturan dikodekan dengan keras, mungkin terjalin dengan data itu sendiri, data tidak hanya terintegrasi tetapi juga direplikasi berkali-kali untuk setiap perangkat lunak terpisah dalam rantai informasi dan jika Anda mencoba mengganti satu bagian,
seluruh sistem bisa rusak. Terlalu banyak proses berpikir lama, jika tidak rusak maka jangan diperbaiki. Yang benar-benar dibutuhkan adalah agar semua bagian komponen tersebut menjadi layanan mikro, mengambil data yang diperlukan, menerapkan aturan otomatis atau masukan/ulasan pengguna, dan
meneruskannya ke layanan mikro berikutnya. Data tidak boleh disimpan di lebih dari satu lokasi. Itu mungkin federasi tetapi tidak direplikasi di luar cadangan. Sistem CRM, Onboarding, KYC, Client Outreach, dll Anda seharusnya hanya mengakses data yang mereka butuhkan dan tidak
menjadi repositori data sendiri kecuali Anda telah memilihnya. Mereplikasi data yang sama di beberapa lokasi dan aturan yang mengaturnya adalah sia-sia karena setiap sistem tambahan yang ditambahkan akan melipatgandakan kerumitan yang terlibat.

Ini membawa kita ke pertimbangan terakhir. Apakah Anda memiliki satu sumber kebenaran/Salinan Emas atau beberapa catatan dan sistem yang redundan dan bersaing yang dapat memperbaruinya, Anda masih akan menemukan diri Anda berada di lapisan persyaratan lain berdasarkan garis
bisnis, yurisdiksi, jenis klien, dan produk/layanan. Seorang individu diperlakukan berbeda dengan perusahaan atau kepercayaan dan berbeda menurut lini bisnis konsumen/ritel, komersial atau korporat untuk persyaratan dan kesesuaian. Pada contoh paling dasar jika
kami memiliki 10 jenis klien (perorangan – lajang, menikah, dll, perusahaan swasta, perusahaan publik, kepercayaan, amal, dll) dan Anda dapat beroperasi di 10 wilayah, dan Anda mungkin menawarkan 10 jenis produk/layanan, kami sudah berada di berpotensi 1000+ aturan yang bisa
diterapkan. Bukankah jauh lebih mudah untuk menentukan aturan untuk suatu wilayah, untuk lini bisnis, untuk jenis klien dan produk atau layanan dan membiarkan sistem menyelesaikan persyaratannya? Menghapus duplikat dan menggunakan kembali titik data yang sebelumnya
asalkan. Ini adalah manfaat mengabstraksi proses dan aturan Anda dari lapisan data Anda. 

Jadi sekarang ketika kami mempertimbangkan pertanyaan lama tentang membeli atau membangun perangkat lunak, kami tahu kami membutuhkan orkestrasi omni-channel, otomatisasi proses jika memungkinkan, logika aturan yang fleksibel, manajemen kasus untuk pengawasan dan kemampuan audit, kode rendah dan digerakkan oleh API, abstrak
lapisan data dan mesin aturan cerdas yang dapat mewarisi dari berbagai lapisan logika. Pasar teknologi penuh dengan inovator yang dengan senang hati memuaskan setiap masalah khusus yang dapat dipikirkan, tetapi pada titik mana tidak masuk akal untuk memiliki 'keluar dari rak'
produk yang semuanya perlu disesuaikan dan diintegrasikan satu sama lain alih-alih membangunnya sendiri. Platform kode rendah dapat membuat Anda memiliki 80% dari kebutuhan Anda tersedia dan Anda hanya perlu mengonfigurasi delta itu 20%. Yang terbaik dari kedua dunia adalah yang rendah
platform kode yang juga telah dibuat oleh orang lain untuk komponen yang dapat digunakan kembali sehingga Anda bisa mendapatkan produk 'dari rak' sebagai akselerator untuk bisnis Anda sementara juga memiliki kemampuan untuk staf Anda atau pihak ketiga bersertifikat untuk membuat persyaratan khusus lainnya
ke organisasi Anda. Untuk membeli atau membangun? Itu benar-benar harus keduanya.