Author: Content Manager

Kalau Anda bertanya ke lima pabrik berapa OEE mereka, Anda akan dapat lima angka — dan kemungkinan besar tidak satu pun dihitung dengan cara yang sama.

Cara menghitung OEE sebenarnya sederhana. Yang membuatnya sering salah bukan rumusnya, melainkan keputusan-keputusan kecil di sekitarnya: apa yang dihitung sebagai downtime, kecepatan ideal mana yang dipakai, dan apakah rework masuk kategori produk bagus.

Perbedaan itu bisa menggeser angka dua puluh poin. Dan OEE yang dihitung longgar lebih berbahaya daripada tidak punya OEE sama sekali, karena Anda jadi yakin pada angka yang salah.

Rumusnya

OEE adalah hasil kali tiga hal:

OEE = Availability × Performance × Quality

Availability — berapa lama mesin benar-benar jalan, dibanding waktu yang dijadwalkan untuk produksi.

Performance — seberapa cepat jalannya, dibanding kecepatan idealnya.

Quality — berapa banyak yang keluar bagus pada percobaan pertama.

Ketiganya berupa persentase, dan karena dikalikan, angka akhirnya selalu lebih kecil dari yang orang kira. Tiga komponen yang masing-masing 90% menghasilkan OEE 73%, bukan 90%.

Contoh perhitungan satu shift

Angka samar tidak membantu. Ini satu shift nyata, dihitung sampai selesai.

Waktu

Keterangan	Menit
Durasi shift	480
Berhenti terencana (istirahat, briefing)	60
Waktu produksi terjadwal	420
Berhenti tak terencana (breakdown, changeover, tunggu material)	85
Waktu jalan (run time)	335

Produksi

Keterangan	Nilai
Cycle time ideal	0,5 menit per unit
Total unit diproduksi	520
Unit bagus	495
Reject	25

Perhitungan

Availability = 335 ÷ 420 = 79,8%

Performance = (0,5 × 520) ÷ 335 = 260 ÷ 335 = 77,6%

Quality = 495 ÷ 520 = 95,2%

OEE = 79,8% × 77,6% × 95,2% = 58,9%

Perhatikan satu hal: tidak ada komponen yang terlihat buruk. Availability hampir 80%, Quality di atas 95%. Tapi hasil kalinya 58,9% — artinya hampir separuh kapasitas shift itu hilang.

Inilah yang membuat OEE berguna. Angka-angka yang terlihat wajar sendiri-sendiri bisa menghasilkan kerugian besar ketika digabung.

Cara memeriksa hitungan Anda

Ada jalan pintas untuk memverifikasi:

OEE = (Unit bagus × Cycle time ideal) ÷ Waktu produksi terjadwal

Dengan angka di atas: (495 × 0,5) ÷ 420 = 247,5 ÷ 420 = 58,9%. Cocok.

Kalau dua cara ini memberi hasil berbeda, ada yang salah di salah satu komponen. Pakai ini setiap kali menyusun perhitungan baru.

Lima kesalahan yang paling sering terjadi

Menghitung berhenti terencana sebagai downtime

Istirahat makan, briefing pagi, dan shift yang memang tidak dijadwalkan produksi tidak masuk perhitungan. Mesin tidak gagal — Anda memang tidak menjadwalkannya jalan.

Kalau 60 menit istirahat di contoh tadi dimasukkan sebagai downtime, Availability turun ke 69,8% dan OEE jadi 51,5%. Angka itu salah, dan membuat Anda mengejar masalah yang tidak ada.

Memakai cycle time dari brosur mesin

Ini kesalahan yang paling halus. Kecepatan di spesifikasi mesin dicapai dalam kondisi ideal pabrikan — material sempurna, tanpa variasi, tanpa operator.

Kalau Anda memakai angka brosur, Performance akan selalu terlihat buruk dan tidak pernah membaik, lalu orang berhenti mempercayai metriknya. Pakai kecepatan terbaik yang pernah benar-benar Anda capai secara berkelanjutan dengan material Anda sendiri.

Menghitung rework sebagai produk bagus

Unit yang perlu diperbaiki bukan produk bagus. Ia sudah memakan waktu mesin dua kali dan tenaga kerja tambahan.

Quality harus mengukur first pass yield — keluar benar pada percobaan pertama. Kalau rework dihitung bagus, Anda menyembunyikan biaya yang paling mudah dihilangkan.

Menghitung per bulan

OEE bulanan adalah rata-rata yang menutupi segalanya. Shift malam yang buruk tertutup shift pagi yang bagus. Satu line bermasalah tertutup line lain.

Hitung per shift, per line. Itu level di mana angkanya bisa ditindaklanjuti. Rata-rata pabrik hanya berguna untuk laporan, bukan untuk perbaikan.

Membandingkan OEE antar line yang berbeda

OEE bagus untuk membandingkan satu line dengan dirinya sendiri dari waktu ke waktu. Ia buruk untuk membandingkan line A dengan line B, karena cycle time ideal, jenis produk, dan frekuensi changeover-nya berbeda.

Line dengan changeover sepuluh kali sehari tidak akan pernah mengalahkan line yang memproduksi satu SKU sepanjang shift. Itu bukan berarti timnya lebih buruk.

Soal angka 85%

Di banyak materi, 85% disebut sebagai standar “world class”. Angka itu benar untuk produksi massal dengan sedikit variasi produk — dan menyesatkan untuk hampir semua orang lain.

Pabrik dengan banyak SKU dan changeover sering akan punya plafon struktural yang lebih rendah, dan itu bukan kegagalan.

Yang penting bukan membandingkan diri Anda dengan 85%, melainkan membandingkan diri Anda dengan diri Anda bulan lalu. Naik dari 59% ke 64% bernilai nyata dalam rupiah. Mengejar 85% yang tidak realistis hanya menghasilkan tim yang mulai memanipulasi cara menghitungnya.

Mulai mengukur tanpa software mahal

Anda tidak perlu sistem untuk mulai. Anda perlu data yang jujur.

Minggu 1–2: kertas. Satu lembar per shift di satu line. Operator mencatat jam berhenti, jam jalan lagi, dan alasannya dari daftar pendek yang sudah dicetak — bukan isian bebas. Catat juga total unit dan reject.

Daftar alasan yang pendek itu penting. Lima sampai delapan kategori sudah cukup: breakdown, changeover, tunggu material, setting/adjustment, masalah kualitas, tidak ada operator, lain-lain.

Minggu 3–4: spreadsheet. Masukkan data mingguan ke satu file. Hitung ketiga komponennya. Anda akan mulai melihat pola — dan hampir selalu, penyebab terbesarnya bukan yang diduga semua orang. Tim maintenance yakin penyebabnya breakdown; datanya sering menunjuk changeover atau menunggu material.

Bulan 2 ke atas: baru pikirkan sistem. Setelah Anda tahu data apa yang benar-benar dipakai dan kategori mana yang berguna, barulah masuk akal mengotomatiskan pengumpulannya. Membangun sistem sebelum tahu ini menghasilkan sistem yang mengumpulkan hal yang salah dengan rapi.

Urutan ini dibahas lebih lengkap di tulisan tentang digitalisasi pabrik.

Yang biasanya ditemukan

Setelah satu bulan data jujur, pola yang muncul hampir selalu mirip.

Changeover lebih mahal dari dugaan. Waktu ganti produk yang “cuma dua puluh menit” ternyata rata-rata empat puluh lima, dan terjadi lebih sering dari yang diingat orang.

Kehilangan terbesar bukan breakdown. Mesin rusak terlihat dan diingat. Berhenti lima menit karena menunggu material, dua belas kali sehari, tidak terlihat — padahal totalnya lebih besar.

Shift malam berbeda. Hampir selalu. Penyebabnya bervariasi dan jarang soal kemalasan — biasanya dukungan yang lebih tipis saat ada masalah.

Sebagian “reject” sebenarnya masalah setting. Terkonsentrasi di awal run, setelah changeover.

Tidak satu pun dari temuan ini butuh investasi besar untuk diperbaiki. Yang dibutuhkan hanyalah mengetahuinya.

Kapan sistem benar-benar diperlukan

Kertas dan spreadsheet cukup untuk satu line selama beberapa bulan. Setelah itu batasnya terasa.

Saat Anda mengukur beberapa line sekaligus, saat datanya mulai telat sehingga tidak bisa ditindaklanjuti, atau saat ada orang yang pekerjaannya mengetik ulang lembar OEE setiap pagi — di titik itu pengumpulan otomatis mulai masuk akal.

Tandanya sederhana: ketika biaya mengumpulkan datanya mulai mendekati nilai yang Anda dapat darinya. Sebelum itu, kertas lebih murah dan sama benarnya.

---

TechGarage membangun sistem pencatatan produksi untuk pabrik di Cikarang, Karawang, Subang, dan sekitarnya — menangkap downtime dan hitungan di lantai produksi, bisa jalan saat koneksi mati, dan menghitung OEE tanpa ada yang perlu mengetik ulang. Kalau Anda sudah punya data kertasnya dan ingin berhenti merekapnya manual, hubungi kami.

Permintaan yang paling sering kami dengar dari pabrik bukan soal fitur. Bunyinya kira-kira begini: “Ada yang lebih murah tidak?”

Pertanyaan itu wajar. Dan jawabannya: ya, hampir selalu ada. Jasa pembuatan software pabrik punya rentang harga yang sangat lebar untuk pekerjaan yang terdengar sama di atas kertas.

Yang jarang dijelaskan adalah kenapa satu penawaran bisa sepertiga harga penawaran lain. Kadang alasannya bagus. Kadang selisihnya bukan penghematan, melainkan penundaan — biaya yang dipindahkan ke tahun depan, biasanya dengan bunga.

Artikel ini tentang cara membedakan keduanya, sebelum Anda menandatangani.

Dua cara membuat software jadi murah

Cara pertama: mengurangi pekerjaan yang memang tidak perlu.

Ini yang benar. Ruang lingkup dipersempit ke yang benar-benar dipakai. Teknologi yang dipilih membosankan dan terbukti, bukan yang sedang tren. Yang sudah ada dipakai ulang, tidak dibangun dari nol. Dikerjakan bertahap, sehingga bagian yang ternyata tidak dibutuhkan tidak pernah dibuat.

Penghematannya nyata dan permanen.

Cara kedua: menghilangkan hal yang tidak terlihat hari ini.

Ini yang mahal. Keamanan dilewati. Dokumentasi tidak dibuat. Source code tidak diserahkan. Pemeliharaan tidak dianggarkan. Pengujian dilewati karena “nanti kelihatan kalau dipakai”.

Semua itu memang menurunkan angka di penawaran. Tidak ada satu pun yang menghilangkan pekerjaannya — hanya memindahkannya ke Anda, nanti, ketika memperbaikinya jauh lebih mahal.

Selisih harga antara dua vendor sering kali persis sebesar cara kedua ini.

Yang benar-benar menurunkan biaya

Lima hal ini menurunkan harga tanpa mengorbankan apa pun. Kalau penawaran Anda mahal dan tidak satu pun dari ini dibahas, ada ruang untuk bernegosiasi.

Ruang lingkup yang disiplin. Sebagian besar pemborosan terjadi karena membangun fitur yang diminta tapi tidak pernah dipakai. Mulai dari satu alur kerja yang paling menyakitkan, pakai betul-betul, baru tambahkan. Pendekatan ini dibahas lebih detail di tulisan tentang digitalisasi pabrik.

Teknologi yang membosankan. Framework yang seru tahun ini bisa tidak punya pemelihara tiga tahun lagi. Teknologi yang umum berarti lebih banyak orang bisa mengerjakannya, lebih murah dirawat, dan Anda tidak terkunci pada satu vendor.

Tidak membangun yang sudah ada. Akuntansi, email, penyimpanan — beli. Bangun hanya bagian yang memang keunggulan Anda. Pembahasan lengkapnya ada di artikel tentang custom vs software jadi.

Menyambung, bukan mengganti. Kalau Anda sudah memakai Accurate atau Zahir, menyambungkannya jauh lebih murah daripada membangun ulang akuntansi. Migrasi besar hampir selalu lebih mahal dari yang diperkirakan.

Bertahap, bukan sekaligus. Proyek delapan belas bulan yang harus sempurna saat go-live rutin gagal, dan kegagalannya adalah biaya terbesar yang bisa Anda tanggung. Potongan kecil yang berjalan lebih murah daripada rencana besar yang tidak pernah selesai.

Apa artinya “aman” untuk sistem pabrik

“Aman” sering dipakai sebagai kata pemanis di proposal. Padahal keamanan itu konkret, dan bisa dicek satu per satu.

Akun per orang, bukan akun bersama. Kalau satu line memakai satu login bersama, Anda kehilangan kemampuan mengetahui siapa melakukan apa — dan tidak bisa mencabut akses satu orang tanpa mengganggu semua orang.

Hak akses berjenjang. Operator tidak perlu melihat data gaji. Staf gudang tidak perlu mengubah harga. Setiap orang melihat yang dibutuhkan pekerjaannya, tidak lebih.

Enkripsi saat lewat dan saat disimpan. HTTPS untuk semua akses, dan database yang terenkripsi. Ini standar, bukan fitur tambahan — kalau ada yang menagihnya sebagai opsi, itu tanda peringatan.

Backup yang pernah diuji pulih. Punya backup itu mudah. Yang menentukan adalah apakah pernah ada yang benar-benar memulihkan data darinya. Kebanyakan pabrik punya backup dan belum pernah mengujinya — bahasan lengkapnya ada di artikel tentang cloud untuk pabrik.

Log audit. Catatan siapa mengubah apa dan kapan. Ini yang membuat selisih stok bisa ditelusuri, dan yang diminta auditor.

Dependensi yang diperbarui. Software dibangun di atas ratusan komponen pihak ketiga, dan kerentanan ditemukan di sana setiap bulan. Sistem yang tidak pernah diperbarui sejak dibangun adalah sistem yang tidak aman, sebagus apa pun kodenya dulu.

Jaringan produksi terpisah dari jaringan kantor. Perangkat di lantai produksi tidak seharusnya berada di jaringan yang sama dengan laptop yang membuka email. Ini pemisahan paling dasar dan paling sering diabaikan.

Kepatuhan data pribadi. Sistem Anda menyimpan data karyawan — NIK, gaji, BPJS. UU Perlindungan Data Pribadi berlaku untuk itu, dan kewajibannya ada pada Anda, bukan pada vendor.

Delapan pertanyaan untuk menguji penawaran

Ajukan ini ke setiap vendor, termasuk kami. Jawabannya membedakan penawaran yang murah karena efisien dari yang murah karena ada yang dihilangkan.

1. Apakah source code menjadi milik kami, tertulis di kontrak? Kalau tidak, Anda menyewa, bukan memiliki — dan biaya pindah vendor nanti tidak terbatas.
2. Siapa yang memegang akun server, domain, dan kredensial deployment? Harus Anda. Kalau vendor hilang besok, tim lain harus bisa melanjutkan.
3. Apa yang termasuk pemeliharaan, dan berapa per tahun? Anggaran wajar lima belas sampai dua puluh persen dari biaya pembangunan. Penawaran yang tidak menyebutkannya sama sekali belum selesai dihitung.
4. Bagaimana pengelolaan hak akses penggunanya? Kalau jawabannya “semua user sama”, sistemnya tidak dirancang untuk pabrik dengan banyak peran.
5. Bagaimana backup dilakukan, dan bagaimana cara mengujinya? Kalau tidak ada prosedur uji pemulihan, anggap backup-nya belum ada.
6. Apakah sistem tetap bisa mencatat saat internet mati? Di pabrik, ini bukan pertanyaan teknis melainkan pertanyaan operasional. Sistem yang berhenti saat koneksi putus akan ditinggalkan operator.
7. Teknologi apa yang dipakai, dan berapa banyak orang di Indonesia yang bisa mengerjakannya? Jawaban yang terlalu unik berarti Anda terkunci.
8. Apa definisi “selesai”, tertulis? Ketidakjelasan di titik ini adalah penyebab paling umum proyek yang melar — dan sumber tagihan tambahan.

Vendor yang bagus akan senang menjawab semuanya. Yang berkelit pada nomor satu, dua, atau tiga sudah memberi tahu Anda banyak hal.

Tanda penawaran yang terlalu murah

Harganya bulat dan datang cepat. Penawaran serius butuh memahami proses Anda dulu. Angka yang keluar setelah satu pertemuan singkat adalah tebakan, dan tebakan yang meleset akan ditagihkan kemudian.

Tidak ada pembahasan integrasi. Kalau sistem baru tidak dibicarakan hubungannya dengan Accurate, Zahir, atau sistem yang sudah ada, integrasi itu tidak masuk hitungan — dan nanti muncul sebagai orang yang mengetik ulang data setiap pagi.

Pemeliharaan tidak disebut. Software bukan pembelian sekali, melainkan komitmen berjalan.

“Nanti bisa disesuaikan” tanpa penjelasan siapa yang mengerjakan dan dengan biaya berapa.

Tidak ada yang datang ke pabrik. Sistem lantai produksi tidak bisa dirancang dari kantor. Kalau tidak ada yang melihat line-nya, apa yang dibangun akan meleset dari cara kerja sebenarnya.

Biaya yang muncul belakangan

Kalau pilihannya salah, tagihannya datang dalam bentuk yang tidak terlihat seperti tagihan software.

Sistem yang tidak dipakai operator karena terlalu lambat, sehingga kertas kembali dan Anda membayar keduanya. Vendor yang tidak bisa dihubungi saat ada masalah. Source code yang tidak Anda miliki, sehingga vendor lain menolak melanjutkan dan Anda harus membangun ulang dari awal. Kebocoran data karyawan karena sistemnya tidak pernah diperbarui.

Satu saja dari ini biasanya lebih mahal dari seluruh selisih harga yang tadi Anda hemat.

Cara memulai dengan risiko kecil

Jangan menandatangani proyek besar untuk menguji sebuah vendor.

Mulai dari satu bagian kecil yang nyata. Satu alur kerja, satu line, satu masalah. Anda akan tahu cara kerja vendornya — apakah mereka datang ke pabrik, apakah pertanyaannya tajam, apakah tenggatnya ditepati — dengan biaya yang kecil.

Pastikan kepemilikan sejak bagian pertama. Source code, akun, dokumentasi. Kalau vendor keberatan di proyek kecil, mereka akan lebih keberatan di proyek besar.

Perluas kalau berhasil. Kalau tidak, Anda berhenti dengan kerugian yang terukur, bukan setelah dua belas bulan dan satu sistem yang tidak jalan.

---

TechGarage membangun sistem operasional untuk pabrik di Cikarang, Karawang, Subang, dan sekitarnya. Kami menjaga biaya tetap masuk akal dengan mempersempit ruang lingkup, memakai teknologi yang terbukti, dan menyambung ke sistem yang sudah Anda pakai — bukan dengan melewati keamanan, dokumentasi, atau kepemilikan kode. Kalau Anda sedang membandingkan penawaran dan ingin pendapat kedua, hubungi kami.

Kebanyakan pabrik mencari software manajemen pabrik bukan karena ingin modern, tapi karena satu hari tutup buku bulanan molor sampai tanggal dua puluh, dan tidak ada yang bisa menjelaskan kenapa margin satu order turun.

Di koridor industri Cikarang, Karawang, dan Subang, pola ini berulang hampir sama di mana-mana. Pabriknya tumbuh. Jumlah order naik. Tim keuangan bertambah satu, lalu dua orang. Tapi caranya bekerja tidak berubah sejak pabrik masih separuh ukurannya sekarang: satu file Excel induk, beberapa file pendukung, dan Accurate atau Zahir di ujungnya.

Ini artikel tentang kapan cara itu berhenti sanggup, dan apa yang sebaiknya menggantikannya.

Kenapa keuangan yang pertama patah

Produksi biasanya bertahan lebih lama dengan cara manual. Operator tahu apa yang dikerjakannya, supervisor tahu kondisi line-nya, dan kesalahan ketahuan di hari yang sama.

Keuangan tidak begitu. Keuangan adalah tempat semua kesalahan dari bagian lain akhirnya berkumpul.

Angka produksi yang dicatat beda format. Penerimaan barang yang belum diinput saat tutup buku. Reject yang dihitung dengan aturan berbeda antar shift. Lembur yang dikirim terlambat dari HR. Semua itu bukan masalah keuangan — tapi keuangan yang harus merapikannya sebelum laporan bisa ditutup.

Itu sebabnya gejalanya muncul di sana lebih dulu. Bukan karena tim keuangan kurang rapi, tapi karena mereka berada di hilir semuanya.

Lima tanda pabrik Anda sudah melewati batas

Tutup buku lewat tanggal sepuluh. Kalau laporan bulan lalu baru selesai saat bulan berjalan sudah separuh, angkanya sudah terlambat untuk dipakai mengambil keputusan.

HPP per order tidak bisa dijelaskan. Anda tahu total biaya produksi bulan itu, tapi tidak bisa menjawab dengan yakin berapa biaya sebenarnya satu order tertentu — apalagi memecahnya ke material, tenaga kerja, dan overhead.

Stok di sistem berbeda dengan stok di gudang. Selisihnya selalu ada, selalu dijelaskan, dan tidak pernah hilang.

Ada orang yang pekerjaannya memindahkan data. Setiap pagi ada yang mengekspor dari satu sistem dan mengetiknya ke sistem lain. Gaji orang itu adalah biaya software yang tidak pernah dihitung sebagai biaya software.

Pertanyaan sederhana butuh dua hari. “Berapa margin produk A kuartal lalu?” seharusnya satu menit. Kalau jawabannya butuh seseorang menggabungkan tiga file, sistemnya sudah tidak memadai.

Satu gejala masih bisa ditoleransi. Tiga ke atas, Anda sedang membayar biaya yang jauh lebih besar dari harga software mana pun.

Yang harus ada di software manajemen pabrik

Bukan daftar fitur vendor. Ini yang benar-benar menentukan berguna atau tidaknya sebuah sistem di pabrik Indonesia.

Costing yang tersambung ke produksi

Ini intinya. Sistem keuangan yang tidak menerima data produksi secara otomatis hanya akan mengulang masalah lama dalam bentuk yang lebih mahal.

HPP per order, per batch, atau per SKU harus terbentuk dari data yang ditangkap di lantai produksi — bukan dari rekap yang diketik ulang seminggu kemudian. Kalau produksi dan keuangan masih dijembatani manusia, Anda belum menyelesaikan apa pun.

e-Faktur dan kepatuhan pajak

Faktur keluaran, pelaporan PPN, dan alur coretax harus terhubung, bukan dikerjakan terpisah lalu dicocokkan. Ini bagian yang paling sering ditangani setengah-setengah oleh software asing, karena aturannya khas Indonesia dan berubah.

Payroll dengan shift dan BPJS

Shift malam yang melewati tengah malam, pola bergilir, lembur, tunjangan shift, BPJS Ketenagakerjaan dan Kesehatan. Software yang tidak dirancang dengan ini akan menghasilkan angka yang salah secara halus — dan salahnya muncul tepat di batas yang paling penting.

Multi-lokasi

Banyak pabrik di koridor ini punya kantor pusat di Jakarta dan pabrik di Cikarang atau Karawang. Kalau sistemnya hanya hidup di pabrik, manajemen di Jakarta akan selalu melihat angka kemarin. Ini alasan kenapa arsitektur cloud untuk pabrik menjadi relevan begitu ada lebih dari satu lokasi.

Ketertelusuran untuk audit dan ekspor

Kalau Anda memasok ke rantai otomotif, atau mengekspor, Anda akan diaudit. Ketertelusuran dari order sampai lot bahan baku harus bisa dipanggil sebagai query, bukan dicari di arsip selama dua hari.

Accurate dan Zahir: kapan cukup, kapan tidak

Hampir semua pabrik di wilayah ini memakai salah satunya, dan itu keputusan yang benar.

Keduanya kompeten sebagai software akuntansi. Untuk buku besar, piutang, hutang, dan laporan keuangan standar, tidak ada alasan membangun sendiri — aturannya ditetapkan dari luar, dan vendor memeliharanya untuk ribuan pelanggan.

Yang tidak mereka lakukan adalah menjalankan pabrik. Keduanya tidak dirancang untuk menangkap data dari lantai produksi, menghitung HPP dari data real-time, atau mengelola ketertelusuran batch.

Jadi polanya bukan mengganti, melainkan menyambung: sistem operasional menangkap apa yang terjadi di pabrik, lalu mengirim ringkasannya ke Accurate atau Zahir sebagai jurnal dan pergerakan stok. Pembahasan lebih lengkap soal kapan membangun dan kapan membeli ada di artikel ini.

Kenapa lokasi pabrik Anda berpengaruh

Tiga kawasan, tiga kondisi yang berbeda.

Cikarang punya salah satu konsentrasi kawasan industri terbesar di Asia Tenggara — Jababeka, MM2100, EJIP, Delta Silicon. Kepadatannya berarti infrastruktur relatif matang dan tenaga IT lebih mudah dicari. Tapi kepadatan itu juga berarti persaingan tenaga kerja tinggi, dan perputaran staf administrasi lebih cepat — yang membuat sistem yang bergantung pada satu orang yang hafal caranya menjadi risiko nyata.

Karawang didominasi klaster otomotif — KIIC, Suryacipta, dan sekitarnya. Kalau Anda pemasok tier satu atau tier dua, tuntutan ketertelusuran dan ketepatan pengiriman datang dari pelanggan Anda, bukan dari keinginan sendiri. Sistem yang tidak bisa menghasilkan rekaman yang diminta audit pelanggan akan menjadi masalah komersial, bukan sekadar masalah internal.

Subang relatif lebih baru, dan sedang berkembang seiring Pelabuhan Patimban dan kawasan industri di sekitarnya. Pabrik baru di sini punya satu keuntungan besar: belum punya warisan sistem lama. Membangun alur data yang benar sejak awal jauh lebih murah daripada membongkar kebiasaan sepuluh tahun. Kelemahannya, ketersediaan vendor lokal dan tenaga IT masih lebih tipis, jadi kemampuan dukungan jarak jauh menjadi pertimbangan yang serius.

Urutan penerapan yang realistis

Kesalahan paling mahal adalah mencoba mengganti semuanya sekaligus. Proyek delapan belas bulan yang harus sempurna saat go-live rutin gagal, dan kegagalannya membuat pabrik tidak berani mencoba lagi bertahun-tahun.

Tahap satu — ukur dulu. Selama dua minggu, catat jam kerja yang dihabiskan untuk mencatat, mengetik ulang, mengejar, dan merekonsiliasi data. Angka itu adalah kasus bisnis Anda. Tanpa itu, Anda menebak.

Tahap dua — satu titik pengambilan data. Pilih satu: pencatatan produksi di satu line, atau penerimaan barang di gudang. Jalankan sebulan berdampingan dengan proses lama. Pendekatan ini dibahas lebih detail di tulisan tentang mendigitalkan pabrik.

Tahap tiga — sambungkan ke keuangan. Setelah datanya terpercaya, alirkan ke sistem akuntansi. Di titik inilah tutup buku mulai bergerak lebih cepat.

Tahap empat — perluas. Line berikutnya, gudang berikutnya, lokasi berikutnya. Setelah satu bagian terbukti, bagian lain akan meminta sendiri.

Soal biaya

Pertanyaan yang selalu muncul: berapa?

Jawaban jujurnya, rentangnya lebar, dan siapa pun yang memberi angka sebelum melihat proses Anda sedang menebak. Yang bisa dikatakan adalah cara menilainya.

Bandingkan dengan biaya yang sekarang sudah Anda tanggung tanpa mencatatnya: jam kerja staf untuk pekerjaan manual, keterlambatan keputusan karena angka datang terlambat, selisih stok yang ditulis sebagai kerugian, dan risiko temuan audit. Kebanyakan pabrik belum pernah menjumlahkan ini, dan totalnya hampir selalu lebih besar dari dugaan.

Anggarkan juga pemeliharaan — lima belas sampai dua puluh persen dari biaya pembangunan per tahun — dan curigai penawaran yang tidak menyebutkannya sama sekali.

Mulai dari mana

Jangan mulai dari meminta penawaran. Mulai dari satu pertanyaan ke manajer keuangan Anda: berapa lama tutup buku bulan lalu, dan berapa jam yang habis untuk merapikan data dari bagian lain?

Kalau jawabannya membuat Anda tidak nyaman, itu titik awalnya. Sisanya — vendor mana, sistem apa, bangun atau beli — hanya detail, dan detail jadi mudah begitu alasannya jelas.

Informasi umum tentang kebijakan dan perkembangan sektor manufaktur nasional bisa dilihat di situs Kementerian Perindustrian.

---

TechGarage membangun sistem operasional dan integrasi keuangan untuk pabrik di Cikarang, Karawang, Subang, dan sekitarnya — menangkap data di lantai produksi, menyambungkannya ke Accurate atau Zahir, dan membuat tutup buku berhenti menjadi proyek bulanan. Kalau Anda ingin penilaian jujur tentang di mana alur data Anda sekarang memakan biaya, hubungi kami.

Coba tanyakan ini ke bagian keuangan Anda: berapa total yang kita bayarkan untuk langganan software bulan lalu?

Di kebanyakan perusahaan, jawabannya butuh beberapa hari. Bukan karena keuangannya tidak rapi, tapi karena angkanya memang tidak pernah dikumpulkan jadi satu. Ada yang lewat kartu kredit perusahaan, ada yang lewat kartu pribadi lalu direimburse, ada yang masuk sebagai “biaya lain-lain”, dan ada yang diperpanjang otomatis sejak 2022 tanpa ada yang meninjau ulang.

SaaS bukan masalah. Model langganan itu masuk akal — Anda tidak perlu membeli server, tidak perlu memelihara, dan bisa berhenti kapan saja. Masalahnya adalah tidak ada yang melihat angka totalnya, dan pengeluaran yang tidak terlihat tidak pernah dikelola.

Kenapa menumpuk tanpa terasa

Setiap langganan, sendirian, terlihat kecil. Tiga ratus ribu sebulan untuk satu tim. Delapan dolar per pengguna untuk tool desain. Lima belas dolar untuk penjadwalan media sosial.

Tidak ada satu pun yang cukup besar untuk memicu persetujuan. Itulah desainnya — vendor SaaS sengaja memasang harga di bawah ambang batas di mana orang perlu bertanya ke atasan.

Lalu terjadi tiga hal.

Ditambah per tim, bukan per perusahaan. Marketing memilih tool-nya sendiri. Operasional memilih sendiri. Keduanya benar secara lokal. Tidak ada yang melihat bahwa keduanya kini membayar untuk hal yang mirip.

Perpanjangan otomatis. Langganan tidak pernah meminta izin untuk lanjut. Ia hanya lanjut. Tool yang dipakai intensif selama satu proyek di 2023 masih ditagih hari ini, dan orang yang mendaftarkannya sudah resign.

Tidak ada yang punya daftarnya. Keuangan melihat transaksi, bukan langganan. IT tahu tool yang mereka pasang sendiri. Tidak ada satu pun pihak yang memegang daftar lengkapnya, jadi tidak ada yang bisa meninjaunya.

Empat biaya yang tidak muncul di tagihan

Angka di invoice bukan angka sebenarnya.

Kursi untuk orang yang sudah tidak ada

Ini yang paling sering, dan paling mudah diperbaiki.

Harga per pengguna berarti Anda membayar untuk setiap akun, bukan untuk setiap orang yang memakainya. Ketika karyawan resign, akun email-nya dinonaktifkan hari itu juga — tapi kursinya di enam tool lain biasanya tidak. Perusahaan dengan perputaran karyawan normal bisa membayar kursi untuk sepuluh sampai dua puluh persen orang yang sudah tidak bekerja di sana.

Ini juga masalah keamanan, bukan cuma pemborosan. Akun aktif milik mantan karyawan adalah pintu yang masih terbuka.

Lompatan paket yang tidak disadari

Paket SaaS punya batas — jumlah pengguna, jumlah kontak, jumlah penyimpanan. Lewat sedikit dari batas, Anda otomatis naik ke paket berikutnya, yang sering dua sampai tiga kali lipat harganya.

Kenaikan itu jarang diumumkan dengan jelas. Ia muncul di tagihan bulan berikutnya, dan karena tagihannya toh sudah rutin, tidak ada yang memperhatikan. Kami pernah menemukan perusahaan yang naik paket karena satu kontak melewati batas lima ribu — dan membayar selisihnya selama empat belas bulan sebelum ada yang sadar.

Tumpang tindih

Begitu tool-nya lebih dari sepuluh, hampir pasti ada dua atau tiga yang mengerjakan hal yang sama.

Dua tool manajemen proyek karena dua tim memilih berbeda. Tiga tempat penyimpanan file. Dua alat chat. Sering kali ada juga fitur yang sebenarnya sudah termasuk dalam langganan yang sudah Anda bayar — Anda membayar tool video conference terpisah padahal paket kantor Anda sudah menyediakannya.

Data yang tersebar

Biaya ini tidak berbentuk uang, tapi paling mahal jangka panjang.

Setiap tool menyimpan sepotong informasi perusahaan Anda dalam format miliknya sendiri. Data pelanggan di satu tempat, riwayat proyek di tempat lain, catatan produksi di tempat ketiga. Tidak ada yang bisa menjawab pertanyaan yang membutuhkan dua sumber sekaligus tanpa seseorang mengekspor CSV dan menggabungkannya manual.

Cara menghitungnya dengan benar

Jangan tanya orang tool apa saja yang mereka pakai. Jawabannya akan tidak lengkap, bukan karena mereka menyembunyikan, tapi karena orang lupa langganan yang jarang disentuh.

Mulai dari uangnya.

Ambil dua belas bulan terakhir mutasi rekening dan tagihan kartu kredit perusahaan. Semua kartu, termasuk kartu direksi. Tandai setiap transaksi yang berulang.

Periksa reimbursement. Langganan yang dibayar dengan kartu pribadi lalu diklaim tidak akan muncul di mutasi perusahaan. Ini sering jadi sepertiga dari total.

Cek email untuk kata “invoice”, “receipt”, “subscription”, dan “renewal”. Kotak masuk keuangan biasanya menyimpan seluruhnya, walaupun tidak terorganisir.

Susun satu tabel. Nama tool, biaya bulanan, biaya tahunan, jumlah kursi, siapa pemiliknya, tanggal perpanjangan, dan untuk apa dipakai.

Tabel itu sendiri sudah bernilai, bahkan sebelum Anda membatalkan apa pun. Kebanyakan perusahaan belum pernah melihat daftarnya secara utuh, dan reaksi pertamanya hampir selalu sama: “kita bayar untuk ini?”

Apa yang dilakukan dengan hasilnya

Empat kategori, dikerjakan sesuai urutan kemudahannya.

Batalkan yang mati. Langganan yang tidak ada yang bisa menjelaskan kegunaannya, atau yang pemiliknya sudah tidak bekerja di sana. Biasanya ini menutup biaya seluruh proses audit.

Rapikan kursinya. Cocokkan daftar pengguna setiap tool dengan daftar karyawan aktif. Hapus yang tidak cocok. Jadikan ini bagian dari proses offboarding supaya tidak menumpuk lagi.

Gabungkan yang tumpang tindih. Pilih satu tool untuk tiap fungsi. Bagian yang berat bukan teknis, melainkan meyakinkan tim yang harus pindah — jadi biarkan pemakaian yang paling besar yang menang, bukan yang paling keras suaranya.

Negosiasikan sisanya. Langganan tahunan hampir selalu lebih murah daripada bulanan, dan vendor memberi diskon kalau diminta — terutama menjelang akhir kuartal mereka. Ini jarang dicoba karena terasa tidak nyaman, padahal hanya butuh satu email.

Kapan sebaiknya berhenti berlangganan dan membangun sendiri

Ini pertanyaan yang wajar muncul setelah melihat tabelnya, dan jawabannya jarang “bangun semuanya”.

Beli yang umum. Akuntansi, email, penyimpanan, HR — sama saja di mana-mana, dan vendor menyebarkan biayanya ke ribuan pelanggan.

Bangun ketika angkanya sudah tidak masuk akal, atau ketika prosesnya memang keunggulan Anda. Dua sinyal yang paling jelas: biaya per kursi sudah melewati titik di mana total lima tahun melampaui biaya membangun, dan Anda membayar seseorang untuk memindahkan data antar sistem setiap hari — karena pekerjaan itu adalah software yang belum ditulis, dibayar sebagai gaji.

Tiga hal khas Indonesia yang perlu diperhatikan

Harga dalam dolar, pendapatan dalam rupiah. Sebagian besar SaaS global menagih dalam USD. Artinya biaya software Anda bergerak mengikuti kurs, dan anggaran yang disusun awal tahun bisa meleset cukup jauh tanpa ada yang menambah satu pengguna pun. Kalau langganannya besar, ini pantas dipertimbangkan saat memilih antara bayar bulanan atau tahunan di muka.

PPN atas produk digital luar negeri. Penyedia SaaS asing yang terdaftar sebagai pemungut PPN PMSE menambahkan pajak pada tagihan Anda. Pastikan bagian keuangan mencatatnya dengan benar dan menyimpan bukti pungutnya — ini sering terlewat karena tagihannya masuk seperti transaksi kartu biasa.

Perpanjangan tahunan tidak bisa dibatalkan di tengah jalan. Kontrak tahunan lebih murah, tapi juga berarti Anda terikat dua belas bulan. Sebelum menandatangani, pastikan tool itu benar-benar akan dipakai — lakukan audit dulu, baru pindah ke tahunan, bukan sebaliknya.

Supaya tidak menumpuk lagi

Audit sekali tidak menyelesaikan apa pun kalau tidak ada yang berubah setelahnya. Dua kebiasaan sudah cukup.

Satu orang memegang daftarnya. Bukan departemen — satu orang, dengan satu spreadsheet yang isinya semua langganan dan tanggal perpanjangannya. Tidak perlu tool khusus.

Tinjau sebelum perpanjangan, bukan sesudah. Pasang pengingat empat belas hari sebelum setiap tanggal perpanjangan. Satu pertanyaan saja: apakah kita masih memakai ini, dan berapa orang yang benar-benar memakainya bulan lalu?

Dua kebiasaan itu mengubah pengeluaran software dari sesuatu yang terjadi kepada Anda menjadi sesuatu yang Anda putuskan.

Mulai dari mana

Blokir dua jam. Buka mutasi kartu kredit perusahaan dua belas bulan terakhir. Tandai semua yang berulang.

Anda kemungkinan besar akan menemukan sesuatu yang tidak Anda ketahui sedang dibayar — dan dua jam itu biasanya terbayar lunas di bulan pertama.

---

TechGarage membantu perusahaan Indonesia menata sistem mereka: menggabungkan tool yang tumpang tindih, menyambungkan sistem yang tidak saling bicara, dan membangun sendiri hanya ketika angkanya memang masuk akal. Kalau Anda sudah punya daftar langganannya dan ingin pendapat kedua soal apa yang layak dipertahankan, hubungi kami.

Ada satu ruangan di hampir setiap pabrik yang jarang dipikirkan orang. Isinya meja, lemari arsip, AC dinding yang menyala kalau ada yang ingat menghidupkannya, dan sebuah PC tower yang berdengung di bawah meja.

PC itu menyimpan database produksi. Semua order, semua catatan batch, semua angka stok. Sudah jalan sejak 2019. Tidak ada yang benar-benar yakin apakah backup-nya masih berjalan.

Ketika orang bilang pabrik sebaiknya “pindah ke cloud”, pembicaraannya biasanya dimulai dari ujung yang salah — istilah keren, transformasi digital, Industry 4.0. Lebih berguna memulai dari ruangan tadi, karena pertanyaan sebenarnya bukan apakah cloud itu modern, melainkan apakah bisnis Anda sanggup bertahan terhadap apa yang bisa terjadi di ruangan itu.

Apa yang benar-benar bisa terjadi

Bukan risiko teoretis. Ini yang memang terjadi.

Panas dan debu. Lantai produksi adalah lingkungan yang kejam bagi komputer. Perangkat server di ruangan tanpa pendingin, atau yang pendinginnya hidup-mati, rusak bertahun-tahun lebih cepat dari seharusnya — dan rusaknya perlahan. Disk mulai bermasalah, performa menurun, dan tidak ada yang menghubungkan keduanya sampai ada yang berhenti total.

Listrik. Kawasan industri di Indonesia mengalami gangguan listrik. Line Anda mungkin punya genset; PC kantor di bawah meja biasanya hanya punya UPS kecil yang terakhir diuji tiga tahun lalu, atau tidak punya sama sekali. Mati mendadak merusak database. Kerusakannya sering tidak terasa sampai ada yang menjalankan laporan dan angkanya tidak cocok.

Air. Kalau pabrik Anda ada di sabuk Bekasi, Karawang, atau Jakarta Utara, Anda tahu banjir bukan hal hipotetis. Server yang diletakkan di lantai, di kantor lantai dasar, adalah masalah kelangsungan bisnis — bukan sekadar masalah IT.

Satu disk, satu salinan. Kebanyakan mesin seperti ini tidak punya redundansi. Dulu ada yang menyiapkan backup ke hard disk eksternal. Tidak ada yang memeriksanya. Kami pernah membuka folder backup yang file terbarunya berumur delapan belas bulan.

Satu orang. Sistemnya disiapkan oleh seseorang yang sekarang sudah tidak bekerja di sana, atau oleh vendor yang tidak lagi membalas. Ketika rusak, tidak ada yang tahu bagaimana dulu dikonfigurasi. Ini bukan masalah perangkat keras — tapi mau di cloud atau tidak, akar masalahnya sama: pengetahuannya tidak tersimpan di mana pun.

Satu saja dari hal ini bisa menghapus seminggu catatan produksi. Digabung, inilah alasan kenapa “server itu sebaiknya diurus” selalu ada di daftar mental setiap manajer pabrik.

Apa yang benar-benar berubah kalau pindah ke cloud

Lupakan slogannya. Ini yang nyata berubah.

Data Anda tidak lagi bergantung pada gedung Anda. Ini yang utama. Kalau kantor kebanjiran, terbakar, atau kemalingan, riwayat produksi ada di tempat lain. Asuransi mengganti perangkatnya; asuransi tidak mengembalikan catatan batch tiga tahun terakhir.

Kantor pusat bisa melihat lantai produksi tanpa harus ada di sana. Kalau pabrik Anda di Cikarang dan manajemen duduk di Jakarta Selatan, jarak itu sekarang diisi pesan WhatsApp dan spreadsheet akhir hari. Ketika sistem produksi bisa diakses dari mana saja, jedanya hilang — begitu juga rasa sungkan meminta orang memotret layar.

Pabrik kedua jadi mungkin. Sistem yang hidup di satu pabrik tidak bisa diperluas. Buka pabrik kedua, Anda dapat sistem terisolasi kedua, lalu satu orang yang tugasnya menggabungkan dua set angka yang tidak pernah persis cocok. Infrastruktur bersama membuat pabrik kedua menjadi perluasan, bukan duplikat.

Ada yang mengurus patch-nya. PC tower itu kemungkinan besar menjalankan sistem operasi yang sudah lama berhenti menerima pembaruan keamanan. Infrastruktur cloud terkelola memindahkan pekerjaan itu ke pihak yang memang tugasnya begitu.

Anda berhenti membeli kapasitas yang tidak dipakai. Server pabrik dibeli untuk puncak kebutuhan yang Anda bayangkan lima tahun lagi — jadi dibayar sekarang, lalu menganggur. Kapasitas cloud menyesuaikan. Apakah itu lebih hemat, tergantung beban kerja Anda; siapa pun yang menjanjikan penghematan tanpa melihat datanya sedang menebak.

Kapan cloud justru jawaban yang salah

Bagian ini biasanya dilewati vendor, dan di pabrik justru lebih penting daripada di tempat lain.

Kendali mesin harus tetap lokal. Selalu. Apa pun yang menutup loop kendali — PLC, SCADA, safety interlock, motion control — tempatnya di lantai produksi, di jaringan pabrik, tanpa ketergantungan pada koneksi internet. Latensi yang tidak terasa di aplikasi kantor menjadi berbahaya di sebelah mesin press. Kalau ada yang menawarkan memindahkan kendali real-time ke cloud, itu alasan untuk menghentikan pembicaraan.

Line harus tetap jalan saat koneksi putus. Internet di kawasan industri Indonesia cukup baik, tapi tidak sempurna. Fiber bisa terputus kena pekerjaan jalan. Sistem yang membuat operator tidak bisa mencatat produksi saat koneksi mati akan ditinggalkan — karena produksi tidak ikut berhenti hanya karena jaringannya berhenti.

Data sangat besar lewat pipa yang sempit. Data sensor berfrekuensi tinggi atau citra machine vision bisa menghasilkan lebih banyak daripada yang sanggup dikirim koneksi Anda. Data seperti itu perlu diolah di sisi pabrik, lalu ringkasannya yang dikirim ke atas — bukan aliran mentah didorong lewat link yang dipakai bersama seluruh kantor.

Bentuk yang benar-benar berhasil

Hampir tidak ada pabrik di Indonesia yang sebaiknya sepenuhnya cloud, dan hampir tidak ada yang sebaiknya sepenuhnya lokal. Yang berhasil adalah pembagian yang disengaja.

Di lantai produksi: kendali mesin, dan pencatatan data yang disentuh operator. Semua ini jalan secara lokal dan tetap berfungsi saat jaringan mati. Operator mencatat output, mencatat stoppage, memindai batch — semuanya langsung tersimpan di tempat.

Di cloud: database utama, pelaporan, dashboard, konsolidasi antar-pabrik, dan apa pun yang perlu dilihat kantor pusat.

Di antaranya: sinkronisasi yang tahan terhadap putusnya koneksi. Lantai produksi tetap bekerja selama gangguan dan menyusul setelahnya, tanpa ada yang perlu mengetik ulang apa pun.

Ini bukan jalan tengah karena terpaksa. Ini arsitektur yang benar. Selain itu, pilihannya cuma dua: catatan Anda berisiko di ruangan hangat, atau line Anda berhenti ketika satu kabel terputus.

Memilih di mana “cloud”-nya berada

“Cloud” bukan satu tempat, dan untuk pabrik di Indonesia lokasinya berpengaruh.

Latensi dan regulasi sama-sama mengarah ke Jakarta. AWS, Google Cloud, Azure, dan Alibaba menjalankan region Indonesia, di samping penyedia lokal seperti Biznet Gio. Server di Jakarta merespons dalam hitungan milidetik satuan sampai belasan dari Cikarang. Beban kerja yang sama di Singapura menambah jeda yang terasa; di Amerika Serikat, sistem interaktif akan terasa rusak.

Pahami kewajiban data Anda. PP 71/2019 dan UU Perlindungan Data Pribadi mengatur bagaimana data pribadi ditangani dan, untuk sebagian kategori penyelenggara sistem elektronik, di mana data boleh disimpan. Pabrik yang menyimpan data karyawan dan data pelanggan sebaiknya memastikan aturan mana yang berlaku sebelum memilih region, bukan sesudah migrasi.

Tanyakan di mana backup-nya disimpan. Region cloud di Jakarta dengan backup yang direplikasi hanya di dalam Jakarta bukanlah pemulihan bencana untuk kejadian berskala Jakarta. Replikasi lintas region biasanya cuma satu centang dan biaya kecil.

Perbaiki koneksinya dulu

Ini urutan praktis yang paling sering dibalik: pabrik menilai platform cloud sebelum membereskan koneksi yang menjadi sandaran cloud itu.

Kalau pabrik Anda punya satu koneksi internet dari satu penyedia, koneksi itu sekarang menjadi titik kegagalan tunggal untuk seluruh operasi. Sebelum memigrasikan apa pun:

Ambil link kedua dari penyedia berbeda, idealnya lewat jalur fisik yang berbeda, dengan failover otomatis. Cadangan 4G atau 5G murah dan menutup sebagian besar kasus fiber putus.

Ukur yang benar-benar Anda punya. Bukan angka di kontrak — throughput dan latensi nyata pada jam 10 pagi hari Selasa, ketika kantor juga sedang memakainya.

Uji failover-nya dengan sengaja mencabut link utama, di shift yang sepi, saat ada orang yang mengawasi. Failover yang belum pernah diuji hanyalah cerita yang Anda karang sendiri.

Soal biaya

Cloud tidak otomatis lebih murah, dan mengklaim sebaliknya adalah cara proyek kehilangan kredibilitas di bulan keempat.

Yang benar-benar berubah adalah bentuk pengeluarannya. Server adalah belanja modal: bayar sekali, ditambah listrik, ditambah penggantian lima tahun lagi, ditambah berapa pun biaya gangguan yang terjadi. Cloud adalah biaya operasional: angka bulanan yang menyesuaikan pemakaian.

Biaya tersembunyinya ada di sisi lokal dan jarang masuk perbandingan — jam kerja untuk merawat mesin itu, listrik dan pendinginannya, UPS yang tidak pernah diganti, dan nilai data produksi yang hilang kalau disk-nya rusak besok.

Hitung lima tahun dengan jujur, termasuk gangguan yang belum Anda alami. Kadang cloud memang lebih murah. Kadang sedikit lebih mahal dan tetap sepadan, karena risiko yang dihilangkannya tidak bisa Anda beli dengan cara lain.

Mulai dari mana

Bukan dari platform. Bukan dari rapat dengan vendor.

Datangi servernya. Cari tahu apa saja yang ada di dalamnya, kapan terakhir backup-nya berjalan, dan apakah pernah ada yang menguji pemulihan data. Pertanyaan terakhir itu yang biasanya mengubah arah pembicaraan — kebanyakan pabrik punya backup dan belum pernah sekali pun memulihkan darinya.

Lalu tanyakan: apa yang hilang kalau server itu mati malam ini? Berapa hari catatan, berapa jam untuk menyusunnya kembali, dan apa yang akan Anda katakan kepada pelanggan yang meminta ketertelusuran satu batch dari bulan lalu.

Angka itulah kasus bisnisnya. Sisanya — penyedia mana, region mana, arsitektur seperti apa — hanya detail, dan detail jadi mudah begitu alasannya sudah jelas.

---

TechGarage membangun dan memigrasikan sistem produksi untuk manufaktur Indonesia — cloud di tempat yang memang seharusnya, tetap di lantai produksi untuk yang memang harus, dan sinkronisasi di antaranya yang tahan koneksi putus. Kalau Anda ingin penilaian jujur tentang apa yang sekarang ada di server itu, hubungi kami.

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.