Praktikum 1

Menganalisis Evolusi dan Integrasi ERP

Indikator: konsep dan evolusi sistem ERP. Studi kasus: perusahaan dengan aplikasi terpisah di empat departemen.

Kondisi Awal

Departemen	Sistem saat ini	Masalah
Penjualan	Spreadsheet	Data pesanan terlambat diperbarui
Gudang	Aplikasi stok	Stok berbeda dengan catatan pembelian
Produksi	Formulir manual	Jadwal produksi sering berubah
Keuangan	Aplikasi akuntansi	Transaksi harus dimasukkan ulang

1. Hubungan Data yang Belum Terintegrasi

Dari → Ke	Masalah	Akibat
Penjualan → Produksi	Pesanan di spreadsheet tidak otomatis menjadi rencana produksi	Jadwal berubah-ubah, janji kirim tidak sesuai kapasitas
Gudang → Pembelian/Produksi	Stok tidak sinkron dengan catatan pembelian	Stok di laporan berbeda dengan catatan produksi
Produksi → Gudang	Pemakaian bahan dicatat manual, stok tidak terpotong otomatis	Stok sistem tidak mencerminkan stok fisik
Semua → Keuangan	Transaksi diinput ulang	Laporan terlambat dan rawan salah ketik

2. Diagram Sebelum Penerapan ERP

flowchart LR
  J["Penjualan
(Spreadsheet)"]
  G["Gudang
(Aplikasi stok)"]
  P["Produksi
(Formulir manual)"]
  K["Keuangan
(Aplikasi akuntansi)"]
  J -. "salin manual" .-> P
  G -. "lapor manual" .-> P
  J -. "input ulang" .-> K
  G -. "input ulang" .-> K
  P -. "input ulang" .-> K

Setiap panah putus-putus adalah titik risiko salah input dan keterlambatan.

3. Diagram Setelah Penerapan ERP

flowchart TB
  DB[("Database Terpusat ERP
satu sumber data")]
  J["Modul Penjualan"] <--> DB
  G["Modul Gudang"] <--> DB
  P["Modul Produksi"] <--> DB
  K["Modul Keuangan"] <--> DB

Data diinput sekali, semua modul membaca sumber yang sama secara real-time.

Perbedaan nyata cara kerja Sebelum: tiap departemen menyalin data dari departemen lain. Sesudah: departemen hanya memicu proses berikutnya (pesanan → produksi → stok → faktur) dan sistem meneruskan datanya.

4. Data Master Bersama

Data master	Dipakai oleh
Pelanggan	Penjualan, Keuangan
Produk jadi	Penjualan, Produksi, Gudang
Bahan baku	Gudang, Produksi, Pembelian
Bill of Materials (BOM)	Produksi, Gudang, Pembelian
Pemasok	Pembelian, Keuangan
Gudang/lokasi	Gudang, Produksi
Chart of Accounts	Keuangan (dipakai otomatis oleh semua modul)
Satuan ukur	Semua departemen

5. Simulasi Transaksi Pesanan Pelanggan

Asumsi: pelanggan memesan 100 unit dengan harga Rp500.000/unit (sesuaikan dengan data dosen).

flowchart TD
  A["Sales Order 100 unit
Rp50.000.000"] --> B{"Stok barang jadi
cukup?"}
  B -- "Ya" --> E["Kirim barang"]
  B -- "Tidak" --> C["Perintah produksi"]
  C --> D{"Bahan baku
cukup (via BOM)?"}
  D -- "Tidak" --> F["Purchase Request otomatis"]
  D -- "Ya" --> G["Produksi berjalan
bahan terpotong, stok barang jadi naik"]
  F --> G
  G --> E
  E --> H["Faktur otomatis
Debit Piutang / Kredit Penjualan"]

Area	Dampak dari satu pesanan
Stok	Stok barang jadi dicek. Jika kurang, sistem memicu produksi. Bahan baku dihitung lewat BOM dan dicek ke gudang.
Produksi	Perintah produksi dibuat. Bahan dipakai (stok bahan turun), hasil produksi menambah stok barang jadi.
Keuangan	Saat barang dikirim: Debit Piutang Usaha Rp50.000.000 / Kredit Penjualan Rp50.000.000. Piutang terbuka sampai pelanggan membayar.

6. Input Sales Order (Terhubung Database)

Isi data pesanan pelanggan. Total dan status dihitung otomatis: stok cukup menjadi Siap Kirim, stok kurang menjadi Perlu Produksi. Data tersimpan di database dan tetap ada setelah halaman ditutup.

Form Sales Order

Nama pelanggan

Produk

Jumlah pesanan (unit)

Harga per unit (Rp)

Stok barang jadi saat ini (unit)

Daftar Sales Order

No. SO	Pelanggan	Produk	Jumlah	Total	Status	Aksi
Memuat data...

Satu Masalah dan Cara Mengatasinya

Masalah: stok gudang tidak sama dengan catatan produksi Penyebab: dua sistem terpisah, pemakaian bahan di produksi dicatat manual dan tidak memotong stok gudang.

Solusi Satu database stok untuk semua departemen. Setiap pemakaian bahan di modul Produksi otomatis mengurangi stok di modul Gudang, sehingga angka keduanya selalu sama.

Bukti yang Dikumpulkan

Diagram sebelum dan sesudah integrasi (bagian 2 dan 3)
Daftar data master (bagian 4)
Hasil simulasi transaksi (bagian 5)
Penjelasan satu masalah dan solusinya (bagian terakhir)