Studi Kasus CHAS ERP: Menyatukan Operasional yang Tersebar Menjadi Satu Sistem Terintegrasi

Ada satu pola yang saya lihat berulang di banyak bisnis yang sudah tumbuh beberapa tahun: di permukaan operasionalnya lancar, tapi di baliknya data tersebar ke mana-mana. Penjualan tercatat di satu file Excel, stok dihitung manual di gudang, pengajuan pembelian lewat chat, dan laporan keuangan dirakit ulang setiap akhir bulan. Semuanya "berjalan" — sampai ada yang salah, dan tidak ada yang bisa memastikan angka mana yang benar.

Proyek CHAS ERP lahir dari kondisi yang lebih menantang lagi: bukan menggantikan spreadsheet, tapi memodernisasi sistem ERP yang sudah dipakai harian oleh puluhan karyawan. Artikel ini saya susun sebagai studi kasus digitalisasi bisnis yang jujur: bagaimana sistemnya dipikirkan, keputusan apa yang saya ambil, dan pertimbangan apa yang perlu Anda pikirkan sebelum menyusuri jalan serupa.

Konteks: ERP Lama yang Tidak Boleh Berhenti

PT. Cipta Hasil Sugiarto (CHAS) sudah punya ERP: fleet.chas.co.id, aplikasi PHP murni tanpa framework modern dengan 193 halaman yang dipakai setiap hari untuk purchasing, gudang, keuangan, dan operasional. Sistem ini bukan proyek yang bisa dimatikan lalu diganti dalam semalam — di dalamnya ada ribuan transaksi, master data, dan kebiasaan kerja yang sudah terbentuk bertahun-tahun.

Analisis log akses Nginx menunjukkan ±2,44 juta request dalam enam minggu. Angka itu memberi dua pelajaran penting. Pertama, sistemnya benar-benar hidup dan dipakai. Kedua, tidak semua bagian sama pentingnya — ada modul yang diakses ratusan ribu kali, ada yang nyaris tidak tersentuh. Dari data itulah prioritas modernisasi ditentukan, bukan dari daftar fitur yang terdengar keren.

Tanda-Tanda ERP Lama Perlu Dimodernisasi

Dari pengalaman proyek ini, tanda-tandanya cukup konsisten:

• Setiap halaman memanggil ulang data master (dropdown, daftar item) — terasa lambat dan membebani server.
• Kode API terduplikasi per endpoint dan per tanggal, sehingga satu perbaikan harus disalin ke banyak tempat.
• Proses persetujuan (pengajuan pembelian, kasbon, cuti) masih bergantung pada alur yang di-hardcode per dokumen.
• Attachment tersebar di endpoint masing-masing modul, tanpa penyimpanan terpusat.
• Laporan dan rekap baru bisa dirakit manual, dan tidak ada dashboard ringkas untuk manajemen.
• Kalau satu orang kunci tidak ada, operasional ikut tersendat.

Satu tanda saja belum tentu berarti. Tapi kalau tiga atau lebih terasa familiar, biasanya itu momen yang tepat untuk mulai bicara soal modernisasi.

Solusi CHAS ERP: Satu Sumber Data, Dibangun Bertahap

CHAS ERP saya bangun dengan premis sederhana: satu sumber data untuk proses inti bisnis, dengan peran dan hak akses yang jelas — siapa boleh melihat apa, siapa boleh menyetujui apa. Stack-nya SvelteKit (Svelte 5) di frontend, NestJS di backend, PostgreSQL dengan Drizzle ORM, ditambah Redis untuk cache dan MinIO untuk penyimpanan attachment terpusat.

Rincian modul dan pendekatannya bisa Anda lihat di portofolio proyek CHAS ERP, tapi intinya begini: setiap transaksi cukup dicatat satu kali di tempat yang benar, lalu informasi turunannya — laporan, status, notifikasi — mengikuti secara otomatis. Tidak ada lagi "versi Excel" dari data yang sama.

Yang saya tekankan sejak awal: ERP di sini bukan berarti aplikasi raksasa dengan segudang fitur. Yang dibutuhkan adalah aplikasi yang pas dengan proses bisnisnya, bukan sebaliknya.

Cara Proyek Ini Dikerjakan: Mulai dari Proses dan Data, Bukan Daftar Fitur

Kesalahan paling umum dalam proyek ERP adalah mulai dari daftar fitur. Saya sengaja menghindari jalan itu. Langkah pertama proyek ini adalah memetakan proses yang benar-benar terjadi dan membaca data trafik nyata: modul mana yang paling sering dipakai, endpoint mana yang paling sering gagal, dan di titik mana pekerjaan paling sering diulang.

Dari situ, migrasi dipecah menjadi delapan tahap. Modul yang paling sering menimbulkan masalah dan paling banyak dipakai didahulukan — Purchasing, lalu Warehouse & Inventory, Finance, Accounting, Operation, Workshop, dan terakhir Marketing. Modul HRMS (absensi, cuti, lembur, payroll master) dan Manajemen Aset justru sudah berjalan lebih dulu dan terhubung dengan aplikasi mobile CHAS.

Bagian tersulit bukan menulis kodenya, melainkan memindahkan data tanpa menghentikan operasional. Master data — 187.805 item, 5.437 karyawan, 3.189 supplier, 1.596 customer, dan 1.856 unit alat berat — dipindahkan lewat Change Data Capture (CDC) dari database lama ke PostgreSQL. ERP lama tetap berjalan read-only sampai setiap modul siap di-cutover, sehingga tidak ada satu pun hari di mana karyawan kehilangan sistemnya.

Pelajaran terpenting dari proyek ini: ERP yang berhasil bukan yang fiturnya paling banyak, tapi yang alurnya paling mirip cara kerja bisnis Anda sehari-hari. Kalau sistem memaksa orang mengubah kebiasaan secara paksa, sistem itu akan ditinggalkan — sebagus apa pun kodenya.

Hasil Kualitatif dan Pertimbangan Jujur: Kapan Bisnis Butuh ERP, Kapan Belum

Hasil yang paling terasa setelah sistem berjalan sifatnya kualitatif, dan justru itu yang paling berharga: tidak ada lagi perdebatan soal "angka yang benar", rekap tidak lagi dirakit manual dari banyak sumber, dan jejak setiap transaksi bisa ditelusuri tanpa harus bertanya ke orang tertentu. Tanggung jawab juga lebih jelas karena setiap langkah punya pemilik di dalam sistem.

Tapi saya ingin jujur soal sisi lainnya: ERP bukan untuk semua orang. Kalau bisnis masih sangat kecil, prosesnya masih sering berubah, atau volumenya belum memaksa, spreadsheet yang tertata mungkin sudah cukup — membangun ERP terlalu dini bisa jadi pemborosan. Sebaliknya, kalau tanda-tanda di atas sudah terasa setiap bulan, menunda berarti membiarkan biaya tersembunyi itu terus berjalan. Istilah ERP memang sering terdengar seperti urusan korporasi besar, padahal aplikasi ERP untuk UMKM justru paling berguna di titik transisi seperti ini.

Pertimbangan lain yang tidak kalah penting adalah memilih siapa yang membangun sistemnya. Saya membahasnya lebih dalam di artikel tentang cara jujur memilih antara solo developer dan agency software untuk aplikasi bisnis. Pendekatan yang sama — mulai dari proses, bukan fitur — juga saya terapkan di proyek sistem operasional transportasi alat berat CHAS, karena prinsipnya sama: sistem harus mengikuti cara kerja lapangan, bukan memaksanya.

Kalau Anda sedang menghadapi kondisi serupa — sistem lama yang mulai menghambat, data terpecah, rekap manual, angka yang tidak pernah sinkron — saya senang mendiskusikan apakah modernisasi sistem seperti CHAS ERP cocok untuk tahap bisnis Anda sekarang, atau memang masih terlalu dini. Ceritakan kondisi operasional Anda melalui halaman kontak, dan kita mulai dari proses bisnis Anda, bukan dari daftar fitur.