Praktikum 1. Menganalisis Evolusi dan Integrasi ERP
Indikator: konsep dan evolusi sistem ERP
1. Hubungan data yang belum terintegrasi
| Dari → ke | Data yang seharusnya mengalir | Kondisi sekarang → akibat |
|---|---|---|
| Penjualan → Gudang | Pesanan pelanggan, ketersediaan stok | Spreadsheet tidak mengecek stok → janji barang ada padahal kosong |
| Penjualan → Produksi | Jumlah dan tanggal pesanan | Dikirim manual → jadwal produksi sering berubah |
| Gudang ↔ Pembelian | Barang masuk dan stok | Aplikasi stok terpisah → stok berbeda dengan catatan pembelian |
| Produksi → Gudang | Pemakaian bahan baku | Formulir manual → stok tidak berkurang tepat waktu |
| Semua → Keuangan | Faktur, penerimaan barang, pembayaran | Aplikasi akuntansi berdiri sendiri → transaksi diinput ulang, laporan terlambat |
2. Diagram proses sebelum ERP (silo)
PenjualanSpreadsheetPesan WA / formulir ke Produksimanual, rawan lambatProduksiFormulir manualMinta bahan ke Gudangstok tidak dicek otomatisGudangAplikasi stokRekap kertas / file ke Keuanganinput ulangKeuanganAplikasi akuntansi
Merah = titik rawan kesalahan atau keterlambatan. Setiap departemen memiliki database sendiri.
3. Diagram rancangan proses setelah ERP
Sales Order diinput sekaliPenjualanSistem cek stok real-timeGudangStok cukup?Ya: reservasi stok, kirimGudangTidak: work order otomatisProduksiKebutuhan bahan (BOM) → permintaan beliPembelianFaktur & piutang terbentuk otomatisKeuangan
Semua departemen memakai satu database. Data diinput sekali oleh pemilik prosesnya, departemen lain membaca hasilnya.
4. Data master yang dipakai bersama
| Data master | Dipakai oleh |
|---|---|
| Pelanggan | Penjualan, Keuangan (piutang) |
| Produk jadi + harga jual | Penjualan, Produksi, Gudang |
| Bahan baku + satuan | Produksi, Gudang, Pembelian |
| Bill of Materials (BOM) | Produksi, Pembelian, Gudang |
| Gudang / lokasi stok | Gudang, Produksi, Penjualan |
| Pemasok | Pembelian, Keuangan (utang) |
| Chart of Accounts (daftar akun) | Keuangan, semua modul yang menghasilkan jurnal |
| Pengguna dan peran | Seluruh departemen (hak akses) |
5. Simulasi satu transaksi pesanan pelanggan
Asumsi: PT Sinar memesan 100 unit komponen @ Rp250.000 = Rp25.000.000. Stok jadi 40 unit. BOM per unit: 2 bahan A + 1 bahan B. Stok bahan A 100, B 80.
| Langkah | Modul | Dampak |
|---|---|---|
| Sales Order diinput | Penjualan | Sistem cek stok jadi: 40 tersedia, kurang 60 unit |
| Work order 60 unit | Produksi | Butuh A 120 dan B 60. Stok A 100 → kurang 20 A; B cukup (80) |
| Permintaan beli 20 A | Pembelian | PR otomatis ke pemasok, produksi menunggu bahan |
| Produksi selesai | Gudang | Bahan A dan B berkurang; stok jadi +60 lalu 100 unit dikirim, stok jadi menjadi 0 |
| Surat jalan dan faktur | Keuangan | Dr Piutang usaha 25.000.000 / Cr Penjualan 25.000.000 otomatis |
Tantangan individual
| Perubahan | Bagian terdampak | Perubahan pada sistem |
|---|---|---|
| Stok bahan baku tidak cukup | Produksi, Pembelian, Penjualan | Work order tertahan, PR otomatis, tanggal janji kirim dihitung ulang |
| Pelanggan ubah jumlah pesanan | Penjualan, Produksi, Keuangan | Revisi SO, reservasi stok dan work order disesuaikan, nilai piutang berubah |
| Pembayaran belum diterima | Keuangan, Penjualan | Piutang tetap terbuka, umur piutang dipantau, blokir pesanan baru bila melewati batas kredit |
| Produksi terlambat | Produksi, Penjualan, Gudang | Jadwal diperbarui, tanggal kirim di SO direvisi, pelanggan diberi tahu |
Masalah yang ditemukan dan solusinya
Masalah: stok di gudang berbeda dengan catatan produksi karena dua pihak mencatat stok sendiri-sendiri. Solusi: satu data stok di database ERP; pemakaian bahan tercatat otomatis saat work order selesai (backflush), jadi selisih hanya bisa muncul dari kerusakan atau kehilangan fisik yang diselesaikan lewat stock opname.