Menganalisis Evolusi dan Integrasi ERP
Indikator: konsep dan evolusi sistem ERP. Simulasikan bagaimana satu transaksi pesanan pelanggan mengalir ke stok, produksi, dan keuangan setelah sistem terintegrasi.
1–2. Data proses bisnis sebelum integrasi aplikasi terpisah
| Departemen | Sistem saat ini | Masalah |
|---|
Keempat baris di atas belum berbagi satu basis data — setiap kolom “Masalah” adalah gejala dari data yang sama disimpan berbeda-beda di tiap aplikasi.
Arsitektur proses — sebelum ERP
spreadsheet sendiri
aplikasi stok sendiri
formulir manual
aplikasi akuntansi sendiri
Tidak ada panah antar kotak — artinya tidak ada aliran data otomatis; semua pertukaran data dilakukan manual (dicatat ulang oleh orang).
Arsitektur proses — setelah ERP
Setiap modul membaca dan menulis ke data yang sama — satu transaksi di satu modul langsung terlihat oleh modul lain.
3–4. Data master bersama yang perlu digunakan lintas departemen
5. Simulasi transaksi pesanan pelanggan interaktif
Produk: Komponen Otomotif Tipe A · harga Rp150.000/unit · stok produk jadi: 120 unit · 1 unit produk membutuhkan 3 unit bahan baku (stok bahan baku: 500 unit)
Merancang dan Menguji Arsitektur Teknis ERP
Indikator: arsitektur teknis ERP untuk 100 pengguna di bagian penjualan, gudang, produksi, pembelian, dan keuangan.
1. Arsitektur teknis
LAN
Internet + VPN
Kotak oranye adalah titik kegagalan tunggal (single point of failure) pada rancangan dasar — lihat simulasi gangguan di bawah.
2. Matriks hak akses pengguna
| Modul | Penjualan | Gudang | Produksi | Pembelian | Keuangan |
|---|
3. Pencadangan & pemulihan data
Jalankan backup untuk mencatat snapshot, lalu coba pulihkan salah satunya.
4–6. Simulasi gangguan sistem
Perubahan kondisi: 100 → 800 pengguna, anggaran hanya naik 15%
Pemetaan Proses Bisnis dan Perancangan Alur Persetujuan
Indikator: pemetaan dan perancangan proses bisnis — pengadaan bahan praktik laboratorium Politeknik META Industri.
A. Diagram as-is
B. Diagram to-be
C. Aturan bisnis
- Permintaan harus memiliki identitas pengaju yang tercatat di sistem.
- Permintaan pembelian wajib diperiksa terhadap stok gudang secara otomatis sebelum diteruskan.
- Pesanan pembelian di atas ambang nominal wajib disetujui pihak berwenang sebelum PO terbit.
- Pembayaran hanya diproses jika permintaan, PO, dan bukti terima barang saling cocok (tiga dokumen).
D. Simulasi kondisi khusus — nilai pembelian berubah
Ambang persetujuan: ≤ Rp5.000.000 Kepala Lab · Rp5.000.001–Rp20.000.000 Pimpinan · > Rp20.000.000 Direktur
Konfigurasi dan Simulasi Modul Keuangan
Indikator: konfigurasi dan simulasi modul keuangan. Saldo awal kas Rp30.000.000 — lima transaksi berikut sudah dikonfigurasi dan dicatat otomatis sebagai jurnal.
Tahap 1 — Konfigurasi akun
| Kode | Nama Akun | Tipe | Saldo Normal |
|---|
Tahap 2 — Input transaksi
Lima transaksi skenario praktikum sudah dimuat di bawah. Transaksi baru akan ditambahkan ke jurnal yang sama.
Tahap 3 — Jurnal, buku besar & neraca saldo
Tahap 4 — Pengujian kesalahan
Simulasikan pembayaran utang pemasok yang tercatat dua kali, lalu perbaiki dengan jurnal pembalik tanpa menghapus jejak audit.
Konfigurasi SCM dan Pembelian Berbasis Kebutuhan Material
Indikator: konfigurasi modul SCM dan pembelian. Produk butuh 3 unit Bahan A + 2 unit Bahan B per unit; target penyelesaian produksi 6 hari kerja.
Tahap 1 — Data master & persediaan
| Komponen | Stok tersedia | Pesanan belum diterima | Waktu pengadaan |
|---|
Tahap 2–3 — Perhitungan kebutuhan & simulasi pembelian
Tahap 4 — Simulasi penerimaan barang
Tahap 5 — Pengujian perubahan kondisi pemasok
Skenario: pemasok Bahan B baru dapat mengirim barang dalam sejumlah hari kerja tertentu, sementara produksi harus selesai dalam 6 hari kerja.