S2SMFG — ERP Case Study | Ardyan Syahputra

The Situation

Di lantai produksi PT. Mada Wikri Tunggal, setiap material yang bergerak mengikuti sebuah kartu fisik — disebut Kartu Travel. Kartu ini adalah satu-satunya jejak yang mencatat material telah melewati proses apa, dari mana, menuju mana.

Masalahnya: kartu ini dari kertas. Di lantai pabrik yang ramai dengan mesin, oli, dan pergerakan forklift, kartu itu robek, kotor, dan hilang. Ketika hilang, riwayat satu lot material ikut hilang bersamanya. PPIC tidak tahu stok sesungguhnya sampai rekap Excel malam hari selesai dikerjakan — 24 jam kemudian.

Dalam kondisi itu, kesalahan ketik satu digit pada kode part yang mirip bisa mengakibatkan pengurangan stok yang salah — dan satu insiden seperti itu nilainya bisa mencapai puluhan juta rupiah.

The Engineering Challenge

Tantangan sesungguhnya bukan memindahkan Excel ke web. Tantangannya adalah membangun sistem yang bisa dipercaya oleh 50+ operator yang mengaksesnya bersamaan, memproses 600 transaksi per hari, tanpa satu pun yang boleh double-counted atau terlewat.

CHALLENGE 01

Concurrency — Dua operator tidak boleh bisa menerima PO yang sama di saat bersamaan

CHALLENGE 02

Accuracy — Backflushing otomatis: operator hanya lapor hasil, sistem yang hitung material terpakai dari BOM

CHALLENGE 03

Integrity — Satu box barang jadi tidak boleh bisa di-scan dua kali ke dalam truk yang berbeda

Setiap tantangan itu bisa mengakibatkan kerugian nyata jika tidak ditangani di level arsitektur database — bukan hanya di level UI.

The Architecture

Saya merancang sistem dengan 78 tabel relasional di MariaDB yang merepresentasikan 15 tahap alur kerja dari Procurement hingga Shipping. Tiga pola kritis yang menjadi tulang punggung integritas data:

Receiving

DB::transaction() + lockForUpdate() memastikan tidak ada double-receive pada PO yang sama.

→

Production

BOM-based backflushing otomatis. Operator lapor yield, sistem deduct raw material sesuai Bill of Materials.

→

Shipping

MD5 hash unique constraint pada setiap scan QR box. Satu scan berhasil, scan kedua ditolak di level database.

ERD dibangun berpusat pada tiga tabel kritis: m_part (master material), t_spk (work order), dan t_finish_good_out (pengiriman). Dengan composite index dan covering index (idx_spk_status), query yang awalnya lambat pada volume 600 transaksi/hari tetap responsif tanpa timeout.

// ReceivingController — mencegah double-receive pada PO yang sama
public function processReceiving($poId)
{
    return DB::transaction(function () use ($poId) {
        $po = PurchaseOrder::lockForUpdate()->findOrFail($poId);

        if ($po->status === 'received') {
            throw new \Exception('PO sudah diterima oleh user lain.');
        }

        $po->update(['status' => 'received']);
        // ... BOM backflush logic
    });
}

The Outcome

Sistem berjalan di production dengan beban nyata sejak awal 2024. Ini bukan prototype — ini sistem operasional yang menggantikan seluruh proses kertas di lantai pabrik:

ACCURACY

Akurasi rekonsiliasi inventaris mencapai ~99.9% — dari sebelumnya bergantung pada rekap manual yang rawan typo

SPEED

PPIC mendapat data real-time. Waktu perencanaan produksi harian berkurang 2 jam per hari

SCALE

78 tabel · 50+ user aktif · 600 transaksi/hari (100 SPK + 500 inventory movement) berjalan stabil

LOSS

Kehilangan dokumen fisik: 0%. Risiko kerugian puluhan juta akibat selisih stok dieliminasi

"Yang paling berdampak bukan fiturnya — tapi keputusan arsitektur di level database yang memastikan tidak ada satu transaksi pun yang bisa bocor, terduplikasi, atau hilang, bahkan ketika 50 orang mengakses sistem secara bersamaan."