Author: Content Manager

Masuk ke hampir semua lantai produksi di Indonesia, Anda akan menemukan hal yang sama: sebuah clipboard.

Operator mencatat output per jam di formulir cetak. Di akhir shift, supervisor memotretnya dan mengirimkannya ke grup WhatsApp. Besok paginya, ada orang kantor yang mengetik angka-angka itu ke file Excel. Menjelang sore, ringkasannya sampai ke manajemen.

Tidak ada yang merancang alur ini. Ia terbentuk sendiri. Dan sebenarnya berjalan — dalam arti angkanya akhirnya sampai dan sebagian besar cocok.

Masalahnya ada pada biayanya, dan biaya itu hampir tidak pernah masuk ke pos anggaran siapa pun.

Jarak antara lantai produksi dan kantor

Line produksi Anda menghasilkan informasi terus-menerus. Jumlah unit, mesin berhenti, alasan berhenti, reject, material terpakai, siapa menjalankan apa.

Hampir semua itu sudah diketahui di lantai produksi, saat itu juga, oleh orang-orang yang berdiri di sana. Dan hampir tidak ada yang sampai ke pengambil keputusan tepat waktu untuk memutuskan apa pun.

Di jarak itulah uang menguap. Line yang kemarin jalan di 60% tidak bisa diperbaiki kemarin. Cetakan yang mulai menghasilkan reject jam 10 pagi baru ketahuan di akhir shift — setelah tiga jam scrap. Kekurangan material yang sudah terlihat oleh gudang hari Selasa berubah menjadi berhentinya produksi hari Kamis.

Tidak satu pun dari itu muncul sebagai masalah software. Munculnya sebagai scrap, lembur, dan pengiriman terlambat.

Spreadsheet bukan kesalahannya

Menganggap Excel sebagai biang keladi memang menggoda. Padahal bukan, dan tim yang mulai dari asumsi itu biasanya membangun sesuatu yang lebih buruk.

Spreadsheet menang di lantai produksi karena alasan yang masuk akal. Gratis. Semua orang bisa memakainya. Bisa diubah bentuknya dalam lima menit ketika prosesnya berubah — dan di line produksi sungguhan, itu terjadi terus. Tidak perlu request ke IT, tidak perlu vendor, tidak perlu menunggu.

Fleksibilitas itu benar-benar berharga, dan kebanyakan software pabrik gagal justru karena lebih kaku daripada spreadsheet yang digantikannya. Supervisor yang dulu bisa menambah kolom dalam tiga puluh detik sekarang harus mengajukan permintaan perubahan dan menunggu tiga minggu. Maka spreadsheet-nya kembali, jalan berdampingan dengan sistem baru, dan sekarang Anda punya dua sumber kebenaran yang tidak ada dipercaya.

Jadi pertanyaannya bukan “bagaimana menghilangkan Excel”, melainkan: di titik mana persisnya spreadsheet gagal, dan berapa biaya kegagalan itu?

Di mana spreadsheet benar-benar jebol

Empat kegagalan, kira-kira sesuai urutan kapan pabrik menyadarinya.

Keterlambatan

Spreadsheet memberi tahu Anda apa yang sudah terjadi. Ia tidak bisa memberi tahu apa yang sedang terjadi.

Pada saat data produksi selesai diketik, dicek, dan diringkas, shift yang dilaporkannya sudah lewat. Setiap keputusan yang diambil dari data itu adalah keputusan tentang masa lalu. Untuk laporan bulanan tidak masalah. Untuk menangkap line yang jalan 20% di bawah target, tidak ada gunanya — kerugiannya sudah terlanjur.

Ujinya sederhana: berapa lama jarak antara sesuatu yang salah di line dan orang yang bisa bertindak mengetahuinya? Di kebanyakan pabrik yang kami nilai, jaraknya delapan sampai dua puluh empat jam. Kadang seminggu, kalau masalahnya baru kelihatan di ringkasan bulanan.

Rekonsiliasi

Begitu spreadsheet-nya lebih dari satu — dan selalu lebih dari satu — angkanya mulai tidak cocok.

Produksi punya file sendiri. Gudang punya file sendiri. QC punya buku. Maintenance punya buku lain. Finance punya Accurate atau Zahir. Masing-masing dipegang orang yang teliti, dan tetap saja berbeda, karena yang dihitung sedikit berbeda, pada momen yang sedikit berbeda, dengan aturan yang sedikit berbeda soal apa yang dihitung sebagai reject.

Biayanya bukan selisihnya. Biayanya adalah jam kerja tiap bulan untuk mencari tahu angka mana yang benar, dan terkikisnya kepercayaan pada semua angka itu. Ketika orang berhenti percaya laporan, mereka kembali mengambil keputusan berdasarkan feeling — dan Anda membayar biaya pelaporan sekaligus tidak memakainya.

Ketertelusuran

Yang ini tidak terlihat sampai ada audit atau komplain pelanggan, lalu langsung mahal sekaligus.

Pelanggan melaporkan batch cacat. Anda perlu tahu: shift mana, mesin mana, lot bahan baku mana, operator siapa, berapa hasil pengukuran QC-nya. Dalam sistem kertas-dan-Excel, itu proyek arkeologi. Ada orang yang menghabiskan dua hari membongkar arsip, dan jawabannya tetap sepotong-sepotong.

Untuk pabrik dengan kewajiban sertifikasi — SNI, registrasi BPOM, sertifikasi halal lewat BPJPH, ISO 9001, atau pelanggan ekspor dengan standar audit sendiri — ini bukan sekadar bagus kalau ada. Auditor meminta rekaman dalam batas waktu tertentu, dan “ada kok, di suatu tempat” dihitung sebagai temuan.

Ini juga menentukan besarnya recall. Ketertelusuran yang presisi berarti menarik satu lot. Ketertelusuran yang kabur berarti menarik produksi sebulan, karena Anda tidak bisa membuktikan unit mana yang terdampak.

Pengetahuan yang terkunci

File produksi induk ada di satu PC, dibuat oleh satu orang, dan berisi formula yang tidak sepenuhnya dipahami orang lain.

Orang itu cuti, pelaporan mandek. Orang itu resign, dan Anda menemukan file-nya menyimpan asumsi tak terdokumentasi yang menumpuk selama empat tahun. Hard disk-nya rusak, dan salinan terakhir dari bulan Maret.

Kami pernah melihat pabrik kehilangan delapan bulan riwayat produksi karena drive rusak tanpa backup. Tidak ada yang pernah memutuskan bahwa itu sistem kritis. Kenyataannya memang kritis.

Apa yang didigitalkan duluan

Di sinilah kebanyakan proyek digitalisasi pabrik salah jalan: mereka mencoba mengerjakan semuanya.

MES lengkap, terintegrasi dengan ERP, plus modul maintenance, quality, dan gudang — proyek delapan belas bulan yang harus sempurna saat go-live. Proyek seperti ini rutin gagal, dan kegagalannya cukup mahal dan kelihatan sehingga pabrik tidak berani mencoba lagi bertahun-tahun.

Mulailah dari satu hal, di titik tempat datanya lahir.

Prinsipnya: tangkap informasi di tempat dan pada saat kejadiannya, bukan belakangan, dari formulir, oleh orang yang tidak ada di sana. Setiap lompatan antara kejadian dan catatan menambah jeda dan kesalahan. Hitungan yang ditulis di kertas lalu diketik besok pagi sudah melewati dua manusia dan satu malam tidur.

Tiga kandidat, tergantung mana yang paling menyakitkan.

Pencatatan downtime dan stoppage. Biasanya paling tinggi hasilnya, karena inilah kerugian terbesar yang tidak terukur di kebanyakan pabrik. Ketika mesin berhenti, operator mencatat berhentinya dan memilih alasan dari daftar pendek. Selesai. Dalam sebulan Anda tahu apa yang sebenarnya memakan produksi — dan seringkali bukan yang selama ini diduga semua orang. Tim maintenance yakin penyebabnya breakdown; datanya sering bilang changeover, atau menunggu material.

Penghitungan produksi di line. Output real-time dibanding target, terlihat di lantai produksi dan di kantor secara bersamaan. Menghapus jeda semalam sepenuhnya, dan cenderung menaikkan output dengan sendirinya — semata-mata karena angkanya terlihat oleh orang yang memengaruhinya.

Rekaman mutu dan ketertelusuran. Kalau Anda punya kewajiban sertifikasi atau pelanggan ekspor, mulai dari sini apa pun keluhan lainnya. Rekaman QC terstruktur yang terkait batch, mesin, shift, dan lot material mengubah masalah audit dari arkeologi menjadi sekadar query.

Pilih satu. Buat berjalan benar. Baru kembangkan.

Apa yang benar-benar dituntut lantai produksi

Software lantai produksi gagal karena alasan yang tidak ada hubungannya dengan logika software-nya. Ia gagal karena tempat ia harus berjalan.

Harus jalan offline. Wifi pabrik itu buruk — beton, logam, mesin, jarak dari kantor. Aplikasi yang butuh koneksi untuk mencatat satu hitungan akan ditinggalkan dalam seminggu, karena operatornya tetap harus mencatat hitungan itu. Tangkap secara lokal, sinkronkan saat jaringan kembali.

Harus tahan sarung tangan dan debu. Target sentuh besar, kontras tinggi agar terbaca di bawah lampu industri, tanpa dropdown kecil, tanpa isian bebas kalau bisa pakai pilihan. Kalau tidak bisa dioperasikan dengan sarung tangan kerja, tidak akan dioperasikan.

Harus lebih cepat daripada kertas yang digantikannya. Ini yang paling sering diremehkan. Kalau mencatat stoppage lebih lama daripada menulis di clipboard, operator akan tetap memakai clipboard dan mengisi sistemnya belakangan — dari ingatan, sekaligus banyak, yang mengembalikan semua masalah yang tadi mau diselesaikan. Scan barcode lalu tekan satu tombol selalu menang dibanding mengetik.

Harus bisa dipelajari dalam sepuluh menit. Perputaran staf line itu nyata, dan shift-nya bergilir. Kalau sistemnya butuh sesi pelatihan, pelatihannya tidak akan konsisten terjadi. Harus langsung jelas.

Harus menangani shift dengan benar. Shift malam yang melewati tengah malam, pola bergilir, lembur, tunjangan shift. Software yang ditulis tanpa memikirkan ini menghasilkan angka yang salah secara halus, persis di batas-batas yang penting.

Realitas integrasi di Indonesia

Apa pun yang Anda bangun harus hidup berdampingan dengan yang sudah berjalan.

Kebanyakan pabrik Indonesia memakai Accurate atau Zahir untuk akuntansi. Keduanya kompeten sebagai software akuntansi dan memang tidak dirancang sebagai sistem produksi. Pola yang realistis adalah data produksi mengalir ke sana sebagai jurnal ringkas atau pergerakan stok — bukan menggantikannya.

Selain itu, hal-hal spesifik yang jarang ditangani dengan baik oleh software pabrik internasional: BPJS Ketenagakerjaan dan Kesehatan di payroll, tunjangan shift yang dihitung sesuai praktik ketenagakerjaan Indonesia, e-Faktur untuk pajak keluaran, kebutuhan dokumentasi SNI, dan dokumen ekspor yang perlu dilampiri data ketertelusuran.

Rencanakan titik-titik integrasinya sebelum membangun apa pun. “Nanti diintegrasikan” hampir selalu berubah menjadi satu orang yang mengetik ulang data antara dua sistem — yaitu titik awal Anda tadi, dengan tambahan langkah.

Urutan yang berhasil

Ukur dulu biaya yang sekarang. Selama dua minggu, hitung jam kerja tim Anda untuk mencatat, mengetik, mengejar, dan merekonsiliasi data produksi. Termasuk pelaporan akhir shift supervisor, entri data di kantor, dan perdebatan bulanan soal angka siapa yang benar. Kebanyakan pabrik belum pernah menjumlahkannya dan terkejut melihat hasilnya.

Total itulah yang memberi tahu seberapa berharga sebuah solusi. Tanpa itu Anda menebak, dan akhirnya kurang berinvestasi pada hal penting atau berlebihan pada hal yang tidak.

Lalu pilih satu line dan satu masalah. Bukan seluruh pabrik. Satu line, satu titik pengambilan data. Jalankan sebulan berdampingan dengan proses kertas yang ada — ya, sebentar jadi dobel kerja, dan itu sepadan, karena Anda akan tahu di mana sistemnya keliru selagi kertasnya masih ada sebagai jaring pengaman.

Buktikan, baru kembangkan. Ketika line yang memakainya terlihat jelas lebih baik — lebih sedikit kejutan, respons lebih cepat, tidak lagi berdebat soal angka — line berikutnya akan minta sendiri. Itu jalur yang jauh lebih baik daripada rollout sepabrik yang tidak diminta siapa-siapa.

Jaga agar tetap bisa diubah. Kebutuhan akan berubah, karena produksi berubah. Bangun sesuatu yang bisa disesuaikan supervisor dalam batas tertentu — menambah alasan downtime, mengubah target, menyesuaikan pola shift — tanpa developer. Ini faktor tunggal terbesar yang menentukan apakah sistemnya masih dipakai dua tahun kemudian.

Mulai dari mana besok

Ajukan satu pertanyaan ke supervisor produksi Anda: kalau boleh tahu satu hal secara real time yang sekarang baru Anda ketahui besoknya, apa yang Anda pilih?

Jawabannya biasanya spesifik, biasanya tepat, dan biasanya lebih murah diselesaikan daripada dugaan siapa pun. Itu juga titik awal yang jauh lebih baik daripada daftar fitur dari vendor.

---

TechGarage membangun sistem pencatatan produksi dan ketertelusuran untuk manufaktur Indonesia — bisa jalan offline, dirancang untuk lantai produksi bukan untuk kantor, dan dibuat agar terintegrasi dengan software akuntansi yang sudah Anda pakai. Kalau Anda ingin penilaian jujur soal di mana alur data Anda sekarang memakan biaya, hubungi kami.

Setiap beberapa bulan, ada pemilik bisnis yang menanyakan hal yang kurang lebih sama kepada kami: sebaiknya beli software jadi, atau bangun sendiri?

Biasanya mereka datang membawa dua penawaran. Yang satu berupa langganan bulanan — terjangkau, bisa dipakai sore ini juga. Yang satu lagi proposal pengembangan dengan angka yang bikin mengernyit dan timeline berbulan-bulan. Kalau dibandingkan seperti itu, jawabannya terlihat jelas. Dan kira-kira separuh waktu, jawaban yang terlihat jelas itu memang benar.

Separuh sisanya mahal. Bukan mahal sekarang — mahal delapan belas bulan kemudian, ketika opsi “murah” tadi diam-diam sudah memakan satu orang penuh yang kerjanya hanya mengakali keterbatasan sistem.

Masalahnya bukan orang salah memilih. Masalahnya, yang dibandingkan memang bukan hal yang tepat.

Perbandingan yang sebenarnya penting

Harga di depan membandingkan langganan dengan biaya pembangunan. Yang seharusnya Anda bandingkan adalah total biaya menjalankan proses bisnis ini selama lima tahun ke depan untuk masing-masing opsi.

Itu dua perhitungan yang sangat berbeda, karena biaya software sebagian besar bukan biaya software. Sebagian besarnya adalah biaya tenaga kerja di sekelilingnya.

Software jadi punya biaya langganan, lalu punya:

• Jam kerja yang habis untuk menyesuaikan proses Anda dengan asumsi si software
• Input ulang data secara manual antara sistem itu dan sistem lain yang Anda pakai
• Biaya per pengguna yang naik seiring pertumbuhan karyawan, terlepas dari apakah nilainya ikut naik
• Pekerjaan integrasi setiap kali Anda menambah sistem baru
• Biaya keluar yang menumpuk — makin besar tiap bulan, karena makin banyak riwayat operasional Anda tersimpan dalam struktur data milik orang lain

Software custom punya biaya pembangunan, lalu punya:

• Hosting dan infrastruktur
• Pemeliharaan, patch keamanan, pembaruan dependensi
• Biaya perubahan ketika bisnis berubah
• Risiko ketergantungan pada orang tertentu, kalau yang membangun sudah tidak tersedia

Tidak ada daftar yang lebih pendek. Pertanyaannya, daftar mana yang lebih terasa untuk bisnis Anda secara spesifik.

Kapan software jadi memang pilihan yang benar

Kami hidup dari membangun software custom, dan kami tetap sering menyarankan klien untuk membeli saja. Membeli adalah jawaban yang benar ketika prosesnya bersifat umum.

Akuntansi. Buku besar Anda bekerja dengan cara yang sama seperti buku besar perusahaan lain, karena aturannya ditetapkan dari luar. Membangun sistem akuntansi sendiri berarti membangun ulang logika kepatuhan yang sudah dipelihara vendor untuk ribuan pelanggan dan diperbarui setiap kali regulasi berubah. Anda tidak akan membuatnya lebih baik, dan tidak akan lebih murah.

Email, kalender, penyimpanan file, chat. Sudah selesai. Benar-benar selesai. Lanjut.

CRM, untuk kebanyakan tim sales. Kalau proses penjualan Anda adalah kontak, kualifikasi, penawaran, follow up, closing — tool standar memodelkan itu dengan baik, karena sebagian besar proses penjualan memang berbentuk seperti itu.

Apa pun yang harus jalan minggu depan. Pengembangan custom tidak bisa mengalahkan formulir pendaftaran dalam hal kecepatan. Kalau bisnis butuh sesuatu sekarang, beli sesuatu, dan tinjau ulang nanti setelah Anda tahu apa yang sebenarnya dibutuhkan. Langganan sementara adalah jawaban yang sah untuk masalah yang mendesak.

Polanya: beli yang umum. Kalau sebuah proses berjalan dengan cara yang pada dasarnya sama di perusahaan Anda dan di kompetitor, berarti sudah ada yang membangunnya, memeliharanya, dan menyebar biayanya ke basis pelanggan yang tidak mungkin Anda tandingi.

Kapan software jadi gagal tanpa terasa

Software jadi gagal secara perlahan, dan justru itu yang membuatnya sulit disadari. Ada tiga jenis “pajak” yang menumpuk.

Pajak akal-akalan

Software mengandung asumsi. Ketika asumsi vendor tidak cocok dengan operasional Anda, celahnya diisi oleh manusia.

Ada distributor yang kami tangani menjalankan inventori di platform regional yang cukup terkenal. Sistemnya berasumsi satu gudang per pesanan. Kenyataannya mereka rutin memecah pesanan ke tiga gudang. Setiap pesanan yang dipecah berarti staf harus membuat tiga record terpisah, merekonsiliasinya manual, lalu mengoreksi jumlah stok setelahnya. Sekitar empat puluh menit sehari, setiap hari, ditambah kesalahan yang lolos.

Tidak ada yang mencatat itu sebagai biaya software. Di pembukuan, itu muncul sebagai waktu kerja staf. Padahal itu biaya software — kira-kira satu bulan kerja penuh per tahun, dihabiskan untuk membuat sebuah tool berpura-pura bisa melakukan sesuatu yang sebenarnya tidak bisa.

Pertanyaan diagnostiknya: apa yang dikerjakan staf Anda yang seharusnya dikerjakan software? Kalau jawabannya melibatkan file spreadsheet yang ada semata-mata untuk menjembatani dua sistem, Anda sedang membayar pajak ini.

Pajak integrasi

Satu tool tidak masalah. Masalah mulai muncul di tool keempat atau kelima, ketika informasi yang perlu diketahui bisnis tersebar di tempat berbeda dan tidak ada yang terekonsiliasi otomatis.

Di sinilah bisnis Indonesia menemui hambatan yang tidak jadi prioritas vendor internasional. Operasional Anda menyentuh hal-hal yang dihadapi perusahaan Jakarta setiap hari dan tidak pernah didengar vendor San Francisco:

• QRIS untuk pembayaran, dan merekonsiliasi laporan settlement dengan pesanan
• e-Faktur dan kepatuhan coretax untuk pelaporan PPN
• Perhitungan BPJS Ketenagakerjaan dan Kesehatan dalam payroll
• Kurir lokal — JNE, J&T, SiCepat, Anteraja — masing-masing dengan API, aturan cakupan, dan format tracking sendiri
• Integrasi marketplace Tokopedia, Shopee, dan Lazada, yang mengubah API mereka sesuai jadwal mereka sendiri

Platform internasional mendukung ini setengah-setengah, atau tidak sama sekali. Yang biasanya terjadi: ada staf yang setiap pagi mengekspor CSV dari satu sistem lalu mengimpornya ke sistem lain. Gaji orang itu adalah bagian dari biaya software Anda, dan hampir tidak pernah dihitung sebagai biaya software.

Pajak keluar

Yang ini tidak terlihat sampai Anda mencoba pindah.

Setiap bulan Anda beroperasi di sebuah platform, makin banyak riwayat Anda yang hidup dalam model data platform itu. Tiga tahun berjalan, data pelanggan, riwayat pesanan, aturan harga, dan pengetahuan operasional Anda sudah berbentuk sesuai skema vendor tersebut. Migrasi bukan sekadar ekspor data. Itu proyek rekonstruksi.

Artinya, daya tawar vendor terhadap Anda justru meningkat seiring waktu, dan biaya pindah naik bahkan ketika kecocokannya makin memburuk. Harga per pengguna mempertajam ini: tool yang terjangkau untuk delapan staf bisa menjadi pos biaya yang berarti di angka empat puluh — dan pada titik itu, pindah adalah proyek yang tidak ada yang mau menanggungnya.

Kapan custom sepadan dengan biayanya

Software custom layak dibangun ketika prosesnya adalah bisnisnya — ketika cara Anda melakukan sesuatu adalah alasan pelanggan memilih Anda.

Beberapa sinyal konkret:

Proses Anda memang tidak lazim, dan itu disengaja. Kalau Anda sudah membangun metode penjadwalan, model harga, atau pendekatan fulfilment yang tidak dimiliki kompetitor, software jadi akan menarik Anda kembali ke standar industri. Anda membayar langganan untuk menjadi lebih biasa.

Anda sudah melewati titik silang jumlah pengguna. Harga per pengguna murah di sepuluh user dan signifikan di seratus. Ada titik di mana total langganan lima tahun melampaui biaya membangun, dan titik itu datang lebih cepat daripada perkiraan kebanyakan orang. Hitung saja — aritmetikanya sederhana dan sering mengejutkan.

Integrasi adalah pekerjaan utamanya. Kalau nilainya terletak pada menyambungkan sistem-sistem yang tidak saling bicara, Anda akan membangun sesuatu bagaimanapun juga. Lebih baik dibangun dengan sengaja daripada menumpuk sebagai kumpulan script yang tidak ada dokumentasinya.

Datanya adalah aset. Kalau riwayat operasional Anda punya nilai analitis — pola permintaan, perilaku pelanggan, respons terhadap harga — Anda ingin data itu dalam struktur yang Anda kendalikan, bukan bentuk yang ditentukan vendor dan hanya bisa diekspor sebagai CSV datar.

Kewajiban kepatuhan yang tidak jadi prioritas vendor. PP 71/2019 dan UU Perlindungan Data Pribadi menetapkan kewajiban tentang di mana data tertentu berada dan bagaimana ia ditangani. Vendor global mengoptimalkan untuk pasar terbesarnya. Kalau kewajiban Anda spesifik, kendali menjadi penting.

Perhitungan yang jujur

Abaikan harga di depan. Susun perbandingan lima tahun, dan jujurlah pada baris kedua dan ketiga — justru itu yang menentukan.

Untuk opsi software jadi: biaya langganan lima tahun pada proyeksi jumlah karyawan, ditambah implementasi dan konfigurasi, ditambah jam staf untuk pekerjaan manual yang dipaksakan oleh tool, ditambah pengembangan integrasi, ditambah perkiraan realistis biaya migrasi di akhir.

Untuk opsi custom: biaya pembangunan awal, ditambah hosting dan infrastruktur, ditambah pemeliharaan tahunan — anggarkan lima belas sampai dua puluh persen dari biaya pembangunan per tahun, dan curigai siapa pun yang bilang lebih murah dari itu — ditambah perubahan yang pasti Anda inginkan seiring bisnis berkembang.

Dua aturan agar perhitungan ini jujur. Hitung waktu staf sesuai biaya sebenarnya, termasuk seluruh komponennya — bukan angka yang membuat jawaban yang sudah Anda sukai terlihat lebih baik. Dan gunakan pertumbuhan yang realistis: bandingkan bisnis lima tahun yang sama di kedua opsi, bukan jumlah karyawan hari ini melawan ambisi tahun depan.

Ketika orang melakukan ini dengan benar, hasilnya sering berbeda dari dugaan awal. Kadang langganan yang tadinya terlihat mahal jelas menjadi pilihan yang tepat. Kadang pembangunan yang tadinya terlihat berlebihan sudah balik modal di tahun ketiga dan terus memberi hasil setelahnya.

Jawabannya biasanya keduanya

Keputusan sebenarnya jarang bersifat semua-atau-tidak sama sekali, dan membingkainya seperti itu justru menghasilkan keputusan buruk.

Kebanyakan bisnis yang dikelola baik yang kami tangani berakhir dengan pembagian yang disengaja: beli yang umum, bangun yang membedakan.

Akuntansi, email, administrasi HR, penyimpanan — dibeli, karena sama saja di mana-mana. Hal yang benar-benar menjadi keunggulan bisnis — inti operasional, alur kerja yang membuat mereka lebih cepat atau lebih akurat dari kompetitor — dibangun, karena di situlah software menciptakan keunggulan, bukan sekadar mengurangi hambatan.

Salah satu klien logistik kami memakai software akuntansi standar, email standar, HR standar. Sistem routing dan dispatch mereka custom, karena routing adalah alasan pelanggan memilih mereka. Itu bentuk yang benar. Mereka mengeluarkan uang untuk software di tempat yang membedakan, dan berhemat di tempat lain.

Kalau memutuskan membangun, kurangi risikonya

Keberatan yang sah terhadap software custom bukan soal biaya, melainkan bahwa proyek custom lebih sering gagal dibanding langganan — dan pembangunan yang gagal jauh lebih mahal daripada langganan yang salah pilih.

Cara menurunkan risikonya:

Mulai dari yang sempit. Bangun satu alur kerja yang paling menyakitkan, pakai betul-betul di lapangan, baru kembangkan. Proyek dua belas bulan sebelum ada yang menyentuh apa pun adalah cara termudah untuk menemukan di bulan kesebelas bahwa kebutuhannya ternyata salah.

Pastikan Anda memiliki semuanya. Source code, akun infrastruktur, domain, kredensial deployment, dokumentasi. Kalau developer Anda hilang besok, tim lain harus bisa melanjutkan. Masukkan ini ke kontrak sebelum pekerjaan dimulai, bukan sesudahnya.

Pakai teknologi yang membosankan dan didukung luas. Framework yang seru di tahun 2026 bisa jadi tidak punya pemelihara di 2029. Untuk software yang menopang operasional, yang tidak glamor dan dipakai banyak orang lebih baik daripada yang baru.

Rencanakan pemeliharaan sejak hari pertama. Software bukan pembelian, melainkan komitmen berjalan. Anggarkan, atau tiga tahun lagi Anda menjalankan dependensi tanpa patch dan menyebutnya insiden keamanan.

Perjelas arti “selesai”. Tertulis, spesifik, disepakati sebelum pengembangan dimulai. Ketidakjelasan di titik ini adalah penyebab paling umum proyek yang melar.

Mulai dari mana

Jangan mulai dari meminta penawaran. Mulai dari mengukur.

Pilih proses yang paling terasa menyakitkan saat ini. Selama dua minggu, catat jam kerja nyata yang dihabiskan tim untuk proses itu — termasuk akal-akalannya, input ulangnya, rekonsiliasinya, koreksinya. Kebanyakan bisnis belum pernah mengukur ini dan terkejut melihat totalnya.

Angka itulah yang memberi tahu Anda seberapa berharga menyelesaikan masalah tersebut. Baru setelah itu masuk akal untuk bertanya apakah langganan, pembangunan, atau kombinasi keduanya adalah cara yang tepat untuk membelanjakannya.

---

TechGarage membangun aplikasi web dan mobile custom untuk bisnis Indonesia. Kami juga tidak sungkan memberi tahu klien ketika software jadi adalah jawaban yang lebih tepat — proyek yang seharusnya tidak dibangun tidak menguntungkan siapa pun. Kalau Anda ingin pendapat kedua soal keputusan beli-atau-bangun, hubungi kami.