Memilih software house untuk membangun sistem enterprise tidak sama dengan memilih vendor untuk membuat website sederhana atau aplikasi dengan ruang lingkup terbatas. Sistem enterprise biasanya berhubungan langsung dengan proses utama perusahaan, menyimpan data penting, digunakan oleh banyak peran, terhubung dengan aplikasi lain, dan terus berubah mengikuti perkembangan bisnis. Kesalahan memilih partner bukan hanya berisiko menghasilkan proyek yang terlambat, tetapi juga dapat menciptakan sistem yang sulit dikembangkan, mahal dipelihara, tidak aman, atau tidak benar-benar menyelesaikan masalah bisnis yang menjadi alasan proyek tersebut dimulai.<\/p>\n\n\n\n
Namun proses pemilihan vendor masih sering dimulai dari tiga hal yang paling mudah dibandingkan: jumlah fitur, durasi proyek, dan harga. Perusahaan mengirimkan kebutuhan kepada beberapa software house, menerima proposal, lalu membandingkan siapa yang menawarkan fitur paling lengkap dengan biaya paling rendah. Pendekatan tersebut memang mempermudah procurement, tetapi belum tentu menghasilkan keputusan investasi teknologi yang tepat.<\/p>\n\n\n\n
Dalam proyek enterprise, dua software house dapat menerima daftar kebutuhan yang sama dan menghasilkan sistem dengan kualitas ekonomi yang sangat berbeda. Keduanya mungkin sama-sama berhasil membuat modul procurement, approval, dashboard, atau integrasi ERP. Namun satu sistem dapat mudah dikembangkan selama lima tahun berikutnya, sementara sistem lainnya membutuhkan perubahan besar setiap kali proses bisnis berubah. Satu vendor mungkin memahami bahwa masalah utama perusahaan adalah lamanya waktu approval, sedangkan vendor lain hanya menerjemahkan proses lama menjadi form digital tanpa memperbaiki bottleneck yang ada.<\/p>\n\n\n\n
Karena itu, pertanyaan yang perlu dijawab perusahaan bukan sekadar:<\/p>\n\n\n\n
\u201cSoftware house mana yang bisa membuat sistem ini?\u201d<\/strong><\/p>\n\n\n\n Pertanyaan yang lebih penting adalah:<\/p>\n\n\n\n \u201cSoftware house mana yang mempunyai kemampuan untuk memahami masalah bisnis, menerjemahkannya menjadi solusi teknologi yang tepat, serta mempertahankan kualitas sistem sepanjang siklus hidupnya?\u201d<\/strong><\/p>\n\n\n\n Ketika perusahaan menunjuk software house, yang dibeli sebenarnya bukan hanya jam kerja developer. Enterprise membutuhkan serangkaian kapabilitas yang lebih luas: memahami proses bisnis, menganalisis kebutuhan, merancang arsitektur, mengelola data dan integrasi, membangun aplikasi, melakukan pengujian, menjaga keamanan, menyiapkan deployment, mengelola perubahan, serta memastikan sistem dapat digunakan dan dipelihara setelah go-live.<\/p>\n\n\n\n Inilah alasan mengapa jumlah developer atau daftar teknologi yang digunakan belum cukup untuk menggambarkan kemampuan sebuah software house.<\/p>\n\n\n\n Vendor dengan banyak engineer belum tentu mempunyai kemampuan discovery yang baik. Vendor yang menguasai teknologi terbaru belum tentu memahami konsekuensi bisnis dari keputusan arsitektur yang dibuat. Sebaliknya, software house yang tidak memiliki jumlah orang terbesar dapat lebih relevan apabila mempunyai struktur delivery, governance, dan kemampuan problem solving yang sesuai dengan kompleksitas proyek.<\/p>\n\n\n\n Untuk sistem enterprise, perusahaan sebaiknya mengevaluasi vendor sebagai delivery capability<\/strong>, bukan sekadar sumber tenaga pengembangan.<\/p>\n\n\n\n Salah satu indikator penting software house yang matang terlihat dari pertanyaan yang mereka ajukan sebelum menawarkan solusi.<\/p>\n\n\n\n Misalnya perusahaan menyampaikan kebutuhan:<\/p>\n\n\n\n \u201cKami ingin membuat sistem approval procurement.\u201d<\/strong><\/p>\n\n\n\n Vendor yang berorientasi pada fitur mungkin langsung menanyakan jumlah level approval, siapa saja user-nya, dan halaman apa yang dibutuhkan. Informasi tersebut penting, tetapi belum menjelaskan mengapa sistem baru diperlukan.<\/p>\n\n\n\n Software house yang lebih business-oriented seharusnya menggali lebih dalam. Berapa lama approval saat ini? Di tahap mana request paling sering tertahan? Apakah masalahnya benar-benar karena proses masih manual, atau karena authority matrix tidak jelas? Apakah terdapat banyak exception? Apakah data budget berasal dari sistem lain? Apakah target bisnisnya mengurangi waktu approval, meningkatkan kontrol pengeluaran, atau mengurangi purchase request yang tidak sesuai kebijakan?<\/p>\n\n\n\n Perbedaan tersebut penting karena teknologi seharusnya datang setelah masalah dan outcome dipahami.<\/p>\n\n\n\n Dalam framework kerja Crocodic, hubungan idealnya adalah:<\/p>\n\n\n\n Business Problem \u2192 Baseline \u2192 Target Outcome \u2192 Process Change \u2192 Required Capability \u2192 Technology Intervention \u2192 Measured Impact<\/strong><\/p>\n\n\n\n Bukan:<\/p>\n\n\n\n Request User \u2192 Feature List \u2192 Development \u2192 Go-Live<\/strong><\/p>\n\n\n\n PMI melalui Benefits Realization Management Framework<\/a> membedakan antara menghasilkan output proyek dan memastikan manfaat yang diharapkan benar-benar terealisasi serta dipertahankan setelah proyek selesai. Prinsip tersebut penting dalam pengembangan software enterprise karena sistem yang selesai sesuai spesifikasi belum tentu memberikan manfaat yang menjadi dasar investasinya.<\/p>\n\n\n\n Karena itu, salah satu pertanyaan pertama ketika mengevaluasi software house adalah: apakah vendor hanya memahami apa yang ingin dibangun, atau juga memahami mengapa sistem tersebut perlu dibangun?<\/strong><\/p>\n\n\n\n Discovery merupakan salah satu fase yang paling menentukan kualitas keputusan teknologi. Pada tahap ini, vendor seharusnya mampu menghubungkan konteks bisnis dengan proses, data, pengguna, integrasi, dan sistem existing.<\/p>\n\n\n\n Discovery yang baik bukan sekadar meeting untuk mengumpulkan daftar kebutuhan. Tujuannya adalah menemukan problem yang benar-benar perlu diselesaikan, memahami kondisi saat ini, mengidentifikasi dependency, serta menentukan kapabilitas minimum yang perlu dibangun untuk menghasilkan dampak yang diharapkan.<\/p>\n\n\n\n Misalnya perusahaan mengatakan membutuhkan dashboard baru karena management kesulitan melihat performa penjualan. Vendor dapat langsung membuat dashboard, tetapi akar masalahnya mungkin bukan visualisasi. Data penjualan ternyata tersebar di CRM, ERP, marketplace, dan spreadsheet cabang dengan definisi revenue yang berbeda-beda. Jika masalah tersebut tidak ditemukan pada tahap discovery, dashboard baru hanya akan menampilkan inkonsistensi data dalam antarmuka yang lebih menarik.<\/p>\n\n\n\n Sebelum menunjuk vendor, perusahaan dapat melihat bagaimana software house melakukan requirement discovery. Apakah mereka memetakan proses? Apakah mereka menanyakan baseline? Apakah mereka memahami sistem existing? Apakah mereka mengidentifikasi dependency dan constraint? Apakah requirement langsung diterjemahkan menjadi fitur, atau diuji lebih dahulu terhadap masalah yang ingin diselesaikan?<\/p>\n\n\n\n Crocodic membahas pendekatan tersebut lebih jauh dalam Strategic Discovery Framework: Langkah Wajib sebelum Koding<\/a>.<\/p>\n\n\n\n Sistem enterprise jarang berdiri sendiri. Aplikasi baru dapat berhubungan dengan ERP, CRM, HRIS, payment gateway, data warehouse, identity provider, aplikasi legacy, layanan pihak ketiga, atau bahkan spreadsheet yang masih menjadi bagian dari proses operasional.<\/p>\n\n\n\n Karena itu, vendor perlu mampu melihat sistem baru sebagai bagian dari enterprise technology landscape<\/strong>, bukan sebagai aplikasi yang terisolasi.<\/p>\n\n\n\n Misalnya perusahaan ingin membangun portal distributor. Dari sisi tampilan, requirement mungkin terlihat sederhana: distributor login, membuat order, melihat status, dan mengunduh invoice. Namun di belakangnya terdapat dependency terhadap master product di ERP, pricing berdasarkan distributor, inventory availability, order processing, payment, invoice, dan logistic status.<\/p>\n\n\n\n Vendor yang hanya berfokus pada portal dapat menghasilkan aplikasi yang terlihat selesai tetapi menciptakan proses manual baru di belakang layar.<\/p>\n\n\n\n Software house yang lebih matang akan bertanya:<\/p>\n\n\n\n Sistem mana yang menjadi sumber data utama? Bagaimana sinkronisasi dilakukan? Apa yang terjadi jika sistem utama tidak tersedia? Siapa pemilik data? Bagaimana error ditangani? Bagaimana transaksi direkonsiliasi?<\/strong><\/p>\n\n\n\n Pertanyaan semacam ini menunjukkan bahwa vendor memahami sistem sebagai rangkaian dependency, bukan hanya kumpulan halaman.<\/p>\n\n\n\n Pembahasan arsitektur sering berhenti pada istilah teknis seperti microservices, monolith, cloud-native, container, atau framework tertentu. Bagi management, terminology tersebut dapat terasa jauh dari kebutuhan bisnis.<\/p>\n\n\n\n Padahal keputusan arsitektur mempunyai konsekuensi ekonomi yang sangat nyata.<\/p>\n\n\n\n Arsitektur menentukan seberapa mudah sistem diubah ketika proses bisnis berkembang. Ia menentukan seberapa besar dampak ketika satu komponen mengalami gangguan, seberapa mudah aplikasi diintegrasikan, bagaimana sistem menangani pertumbuhan transaksi, dan berapa besar effort yang diperlukan untuk melakukan perubahan beberapa tahun kemudian.<\/p>\n\n\n\n Karena itu, perusahaan tidak perlu menentukan teknologi apa yang harus digunakan vendor. Tetapi vendor seharusnya mampu menjelaskan mengapa arsitektur tertentu dipilih dan apa konsekuensinya terhadap bisnis<\/strong>.<\/p>\n\n\n\n Pertanyaan yang dapat diajukan misalnya: bagaimana aplikasi akan menangani peningkatan volume transaksi? Bagaimana modul dipisahkan agar perubahan pada satu area tidak merusak area lain? Bagaimana integrasi dengan sistem existing dirancang? Bagaimana data ownership ditentukan? Bagaimana sistem dapat dikembangkan jika perusahaan membuka unit bisnis atau channel baru?<\/p>\n\n\n\n Software house yang matang seharusnya dapat menjelaskan keputusan teknis dengan bahasa konsekuensi: cost, scalability, maintainability, reliability, security, dan speed of change<\/strong>.<\/p>\n\n\n\n Banyak proyek enterprise menjadi jauh lebih kompleks ketika masuk ke tahap integrasi.<\/p>\n\n\n\n Di proposal, requirement dapat terlihat sederhana:<\/p>\n\n\n\n \u201cIntegrasi dengan ERP.\u201d<\/strong><\/p>\n\n\n\n Tetapi implementasinya dapat membutuhkan authentication, data mapping, synchronization, retry mechanism, reconciliation, error handling, queue, API management, audit trail, dan monitoring.<\/p>\n\n\n\n Karena itu, pengalaman membuat aplikasi belum tentu sama dengan pengalaman melakukan enterprise integration.<\/p>\n\n\n\n Perusahaan perlu mengetahui bagaimana vendor merancang hubungan antar-sistem, menentukan source of truth, menangani kegagalan integrasi, serta menjaga konsistensi data.<\/p>\n\n\n\n Pada proyek dengan banyak sistem existing, integration capability bahkan dapat lebih menentukan daripada kemampuan membuat user interface.<\/p>\n\n\n\n Crocodic membahas area tersebut melalui API-First Architecture: Fondasi Integrasi Sistem Bisnis<\/a> dan Enterprise Application Integration: Cara Menghubungkan Sistem Bisnis Tanpa Mengganti Seluruh Aplikasi<\/a>.<\/p>\n\n\n\n Salah satu pembeda paling mudah dalam proposal vendor adalah timeline.<\/p>\n\n\n\n Vendor A menawarkan enam bulan.<\/p>\n\n\n\n Vendor B delapan bulan.<\/p>\n\n\n\n Vendor C sepuluh bulan.<\/p>\n\n\n\n Pilihan enam bulan terlihat paling menarik, tetapi angka timeline tidak banyak berarti tanpa memahami asumsi dan dependency di belakangnya.<\/p>\n\n\n\n Enterprise project mempunyai uncertainty. Data mungkin belum siap. API existing belum terdokumentasi. Stakeholder mempunyai kebutuhan berbeda. Approval bisnis membutuhkan waktu. Integrasi membutuhkan koordinasi dengan vendor lain. UAT dapat menemukan requirement baru.<\/p>\n\n\n\n Karena itu, vendor yang matang bukan vendor yang selalu memberikan timeline paling agresif, tetapi vendor yang dapat menunjukkan bagaimana timeline dibentuk, dependency apa yang memengaruhinya, dan bagaimana perubahan dikelola<\/strong>.<\/p>\n\n\n\n Riset McKinsey mengenai efektivitas product team<\/a> menggunakan delivery predictability<\/em> dan value realization<\/em> sebagai dua dari tiga outcome utama untuk melihat efektivitas tim. Artinya, kemampuan memenuhi komitmen dan menghasilkan business value menjadi ukuran yang lebih bermakna daripada sekadar terlihat cepat pada rencana awal.<\/p>\n\n\n\n Saat mengevaluasi vendor, perusahaan dapat meminta penjelasan mengenai milestone, dependency, definition of done, proses review, mekanisme perubahan scope, serta bagaimana status proyek dilaporkan.<\/p>\n\n\n\n Portfolio penting karena menunjukkan jenis proyek yang pernah dikerjakan vendor. Namun portfolio hanya menunjukkan hasil akhirnya.<\/p>\n\n\n\n Dua perusahaan dapat sama-sama memiliki portfolio ERP, CRM, atau aplikasi enterprise, tetapi mempunyai cara delivery yang sangat berbeda.<\/p>\n\n\n\n Karena itu, setelah melihat portfolio, pertanyaan berikutnya perlu masuk ke operating model vendor.<\/p>\n\n\n\n Bagaimana discovery dilakukan? Siapa yang bertanggung jawab atas solution architecture? Bagaimana requirement didokumentasikan? Bagaimana code review dilakukan? Bagaimana QA bekerja? Bagaimana vendor menangani perubahan? Bagaimana stakeholder mendapatkan visibility terhadap progress? Bagaimana issue dan risk di-escalate?<\/p>\n\n\n\n Yang perlu dinilai bukan hanya:<\/p>\n\n\n\n \u201cPernah membuat sistem seperti ini?\u201d<\/strong><\/p>\n\n\n\n Tetapi juga:<\/p>\n\n\n\n \u201cApakah cara mereka membangun sistem dapat dipercaya untuk complexity proyek kami?\u201d<\/strong><\/p>\n\n\n\n Portfolio membuktikan pengalaman.<\/p>\n\n\n\n Delivery system menunjukkan kemungkinan vendor dapat mengulang kualitas tersebut.<\/p>\n\n\n\n Keamanan tidak seharusnya muncul pertama kali menjelang go-live ketika penetration test dilakukan.<\/p>\n\n\n\n Enterprise system dapat memproses data pelanggan, data karyawan, data keuangan, credential, intellectual property, dan berbagai informasi sensitif lainnya. Security requirement karena itu perlu diterjemahkan sejak tahap desain.<\/p>\n\n\n\n NIST Secure Software Development Framework (SSDF)<\/a> merekomendasikan secure software development practices yang terintegrasi dengan software development lifecycle. NIST juga secara eksplisit menyebut bahwa organisasi yang membeli software dapat menggunakan SSDF sebagai bahasa bersama untuk berkomunikasi dengan supplier dalam proses acquisition dan aktivitas pengelolaan vendor.<\/p>\n\n\n\n Artinya, perusahaan mempunyai alasan yang kuat untuk menanyakan secure-development practice sebelum memilih software house.<\/p>\n\n\n\n Bagaimana vendor mengelola source code? Bagaimana dependency diperiksa? Bagaimana secrets disimpan? Apakah akses production dibatasi? Bagaimana authentication dan authorization dirancang? Bagaimana vulnerability ditangani setelah sistem digunakan?<\/p>\n\n\n\n Jawaban terhadap pertanyaan tersebut lebih penting dibandingkan sekadar pernyataan:<\/p>\n\n\n\n \u201cKami menggunakan teknologi yang aman.\u201d<\/strong><\/p>\n\n\n\n Security adalah proses.<\/p>\n\n\n\n Bukan atribut otomatis dari framework tertentu.<\/p>\n\n\n\n Salah satu biaya paling mahal dalam software enterprise adalah defect yang baru ditemukan setelah sistem masuk production dan sudah bergantung pada banyak proses lain.<\/p>\n\n\n\n Karena itu, perusahaan perlu memahami QA capability vendor.<\/p>\n\n\n\n Apakah terdapat QA role yang jelas? Apakah test scenario dibangun dari business flow? Apakah integration diuji? Apakah regression dilakukan ketika feature baru ditambahkan? Bagaimana defect ditelusuri? Bagaimana acceptance criteria didefinisikan?<\/p>\n\n\n\n Untuk critical application, pertanyaan dapat diperluas ke performance testing, security testing, recovery, dan data integrity.<\/p>\n\n\n\n Tujuan QA bukan mengejar sistem tanpa defect sama sekali.<\/p>\n\n\n\n Tujuannya adalah menurunkan probability bahwa perubahan software menghasilkan operational disruption yang tidak terdeteksi.<\/p>\n\n\n\n Vendor yang memasukkan quality sejak development berlangsung biasanya mempunyai risk profile berbeda dibandingkan vendor yang menjadikan testing sebagai fase singkat di akhir proyek.<\/p>\n\n\n\n Ownership sering baru dibahas ketika proyek hampir selesai.<\/p>\n\n\n\n Padahal perusahaan perlu mengetahui sejak awal apa yang sebenarnya mereka miliki setelah membayar pengembangan sistem.<\/p>\n\n\n\n Source code memang penting, tetapi ownership tidak berhenti di sana.<\/p>\n\n\n\n Perusahaan perlu mempertimbangkan repository, documentation, infrastructure, database, deployment pipeline, API documentation, domain, cloud account, third-party services, credential, dan knowledge mengenai bagaimana sistem dijalankan.<\/p>\n\n\n\n Jika source code berada di tangan perusahaan tetapi deployment hanya dapat dilakukan oleh vendor, dependency tetap ada.<\/p>\n\n\n\n Jika cloud account dimiliki vendor, perpindahan partner di masa depan dapat menjadi rumit.<\/p>\n\n\n\n Jika seluruh architecture knowledge berada pada satu engineer external, source-code ownership belum tentu memberikan operational independence.<\/p>\n\n\n\n Karena itu, perusahaan sebaiknya membangun prinsip:<\/p>\n\n\n\n Technology Ownership = Code + Access + Documentation + Infrastructure + Knowledge + Operational Capability<\/strong><\/p>\n\n\n\n Exit strategy bukan tanda ketidakpercayaan terhadap vendor.<\/p>\n\n\n\n Ia adalah bagian dari enterprise governance.<\/p>\n\n\n\n Project software tidak berakhir pada go-live.<\/p>\n\n\n\n Setelah sistem digunakan, akan ada defect, perubahan regulasi, perubahan business rule, dependency baru, kebutuhan integrasi, update security, dan requirement baru.<\/p>\n\n\n\n GAO Cost Estimating and Assessment Guide<\/a> menekankan bahwa operasi dan maintenance perlu masuk dalam perhitungan lifecycle cost software. Maintenance mencakup perbaikan defect, penyesuaian terhadap perubahan environment, dan enhancement functionality setelah software digunakan.<\/p>\n\n\n\n Implikasinya terhadap vendor selection cukup besar.<\/p>\n\n\n\n Harga development awal bukan seluruh biaya software.<\/p>\n\n\n\n Perusahaan perlu mengetahui bagaimana maintenance dihitung, bagaimana enhancement dikelola, apakah terdapat support model, bagaimana incident ditangani, dan apakah architecture memungkinkan perubahan dilakukan secara ekonomis.<\/p>\n\n\n\n Vendor yang murah ketika development tetapi menghasilkan sistem yang mahal diubah dapat mempunyai total cost lebih tinggi daripada vendor dengan investasi awal yang lebih besar.<\/p>\n\n\n\n Karena itu:<\/p>\n\n\n\n Initial Development Cost \u2260 Total Lifecycle Cost<\/strong><\/p>\n\n\n\n Membandingkan quotation software house hanya masuk akal jika perusahaan mengetahui apa yang dibeli dari setiap proposal.<\/p>\n\n\n\n Misalnya terdapat tiga vendor:<\/p>\n\n\n\nMemilih Software House Bukan Sekadar Membeli Kapasitas Developer<\/strong><\/h2>\n\n\n\n
Mulai dari Masalah Bisnis, Bukan Daftar Fitur<\/strong><\/h2>\n\n\n\n
1. Evaluasi Kemampuan Discovery dan Analisis Bisnis<\/strong><\/h2>\n\n\n\n
2. Nilai Kemampuan Vendor Memahami Sistem Enterprise secara Menyeluruh<\/strong><\/h2>\n\n\n\n
3. Arsitektur Harus Dinilai dari Dampaknya terhadap Bisnis<\/strong><\/h2>\n\n\n\n
4. Integrasi Harus Menjadi Kapabilitas Utama<\/strong><\/h2>\n\n\n\n
5. Evaluasi Delivery Berdasarkan Predictability, Bukan Janji Timeline Paling Cepat<\/strong><\/h2>\n\n\n\n
6. Jangan Hanya Melihat Portfolio, Lihat Cara Vendor Bekerja<\/strong><\/h2>\n\n\n\n
7. Security Harus Menjadi Bagian dari Proses Pengembangan<\/strong><\/h2>\n\n\n\n
8. Quality Assurance Tidak Boleh Berarti \u201cDeveloper Sudah Mencoba\u201d<\/strong><\/h2>\n\n\n\n
9. Periksa Ownership sejak Sebelum Kontrak Ditandatangani<\/strong><\/h2>\n\n\n\n
10. Jangan Mengabaikan Maintenance dan Cost of Change<\/strong><\/h2>\n\n\n\n
11. Harga Harus Dibandingkan setelah Scope dan Responsibility Setara<\/strong><\/h2>\n\n\n\n