Menganalisis Evolusi dan Integrasi ERP
balqiserp.pagitrpl.my.id

Menganalisis Evolusi dan Integrasi ERP

Indikator: Konsep dan evolusi sistem ERP. Mengidentifikasi hubungan data yang belum terintegrasi, perbandingan arsitektur sebelum vs sesudah ERP, penetapan data master bersama, dan simulasi dampak pesanan terhadap departemen.

Kondisi Sistem Saat Ini & Evaluasi Permasalahan Operasional

Departemen Sistem Saat Ini Masalah yang Muncul Dampak Negatif Terhadap Operasional
Penjualan (Marketing) Spreadsheet Data pesanan terlambat diperbarui Bagian gudang dan produksi tidak mengetahui lonjakan pesanan baru secara tepat waktu.
Gudang (Warehouse) Aplikasi stok terpisah Stok berbeda dengan catatan pembelian Data fisik persediaan tidak sinkron; sering terjadi kehabisan bahan mendadak.
Produksi Formulir manual Jadwal produksi sering berubah Kebutuhan bahan baku tidak terprediksi; janji tanggal kirim ke pelanggan sering meleset.
Keuangan (Finance) Aplikasi akuntansi terpisah Transaksi harus dimasukkan ulang Laporan keuangan akhir bulan selalu terlambat karena rekonsiliasi manual yang memakan waktu.

1. Identifikasi Hubungan Data yang Belum Terintegrasi

Penjualan ↔ Gudang Pesanan baru di spreadsheet tidak otomatis mereservasi stok di aplikasi gudang, memicu over-committing.
Gudang ↔ Produksi Pengambilan bahan baku secara manual tidak langsung mengurangi saldo persediaan gudang, menyebabkan selisih data stok.
Produksi ↔ Penjualan Jadwal perakitan manual tidak dapat dilihat oleh tim sales, berujung pada janji tanggal pengiriman yang tidak realistis.
Operasional ↔ Keuangan Faktur pembelian dan penjualan dicatat ulang manual, menciptakan risiko salah ketik (human error) dan keterlambatan jurnal.

2. Arsitektur Proses — Sebelum ERP (Silo Terpisah)

PenjualanSpreadsheet pesanan mandiri
GudangAplikasi stok lokal
ProduksiFormulir kertas manual
KeuanganSoftware akuntansi offline
Kelemahan: Tidak ada aliran data otomatis antar bagian. Setiap departemen menyimpan pulau informasi (data silo) tersendiri.

3. Arsitektur Proses — Setelah ERP (Database Terintegrasi)

Single Source of Truth (Database ERP Terpusat) Relational Database Management System (RDBMS) Terpadu
⇅ Aliran Data Realtime Dua Arah ⇅
Penjualan
Gudang
Produksi
Keuangan
Keunggulan: Satu kali input transaksi penjualan langsung memotong alokasi stok di gudang, menjadwalkan produksi, dan membentuk jurnal piutang di keuangan secara otomatis.

4. Data Master yang Digunakan Bersama (Shared Master Data)

Nama Data Master Departemen Pengguna Tujuan & Manfaat Bersama
Master Produk & BOM Penjualan, Gudang, Produksi, Keuangan Menjamin spesifikasi produk, rasio kebutuhan material (Bill of Materials), dan harga jual standar konsisten di semua divisi.
Master Pelanggan (Customer) Penjualan, Keuangan Menghubungkan histori pesanan dengan batas kredit (credit limit) dan jadwal penagihan piutang.
Master Pemasok & Lead Time Pembelian, Gudang, Produksi Memastikan waktu pengadaan bahan baku akurat untuk perencanaan jadwal produksi (MRP).
Master Lokasi Gudang & Persediaan Gudang, Produksi, Penjualan Memberikan visibilitas stok yang tersedia (Available to Promise) tanpa perlu verifikasi fisik manual berkali-kali.
Master Bagan Akun (Chart of Accounts) Keuangan, Seluruh Modul Terkait Mengotomatiskan penjurnalan dari setiap transaksi operasional (pembelian, penjualan, penerimaan barang).

5. Simulasi Pesanan Pelanggan & Evaluasi Antar-Departemen

Hasil Simulasi Transaksi yang Tersimpan

No. Order Pelanggan Qty Kondisi Pengujian Dampak Stok Dampak Produksi Dampak Keuangan Tindakan Sistem ERP

Penjelasan Masalah yang Ditemukan dan Solusi ERP

Akar Masalah: Selisih Jumlah Stok Antara Gudang dan Catatan Produksi

Penyebab: Bagian gudang mencatat mutasi stok saat pengiriman barang masuk, sedangkan produksi mencatat kebutuhan material menggunakan kertas formulir manual setelah proses perakitan selesai. Karena tidak ada validasi waktu-nyata (real-time lock), bahan baku sering diambil tanpa potongan sistematis.

Solusi Penerapan ERP: Menerapkan modul Inventory & Production Management terintegrasi dengan mekanisme Backflushing / Auto-Issue BOM. Setiap kali Perintah Kerja (Work Order) dirilis, sistem otomatis membekukan (reserve) kuantitas bahan baku di gudang. Ketika produksi selesai diinput, saldo fisik gudang terpotong seketika secara otomatis tanpa memerlukan rekap manual.

Merancang dan Menguji Arsitektur Teknis ERP

Indikator: Arsitektur teknis ERP. Perancangan arsitektur untuk 100 pengguna (penjualan, gudang, produksi, pembelian, keuangan), matriks hak akses, SOP pencadangan/pemulihan, aliran data transaksi pembelian, dan simulasi 5 gangguan teknis.

1. Diagram Hubungan Pengguna, Antarmuka, Server Aplikasi, Database & Pencadangan

Tier 1 — Lapisan Pengguna & Antarmuka (Client Interface) 100 Pegawai (Penjualan, Gudang, Produksi, Pembelian, Keuangan) via Browser Laptop / PC Desktop
⇅ Protokol Jaringan (HTTP/HTTPS, LAN 1Gbps, VPN untuk Remote Worker) ⇅
Tier 2 — Jaringan & Keamanan (Network & Security Layer) Firewall Perusahaan, TLS/SSL Encryption, Subdomain Routing (balqiserp.pagitrpl.my.id)
⇅ Web Gateway Interface (Server Web Engine) ⇅
Tier 3 — Server Aplikasi ERP (ERP Application Server) Memproses Logika Bisnis, Aturan Validasi Transaksi, Autentikasi Pengguna, dan Session State
⇅ Koneksi Database RDBMS (Port 3306) ⇅
Tier 4 — Server Database Terpusat (Primary Database Server) Penyimpanan Relasional Data Transaksi, Master Data, ACID Transaction & Foreign Key Integrity
↓ Replikasi Terjadwal & Snapshot Backup Dump Harian ↓
Tier 5 — Sistem Pencadangan Terpisah (Isolated Off-Site Backup Server) Storage Cadangan Terpisah (NAS / Cloud Storage) untuk Pemulihan Bencana (Disaster Recovery)

2. Matriks Hak Akses Pengguna (Role-Based Access Control)

Departemen Menu & Modul yang Diakses Kewenangan Akses Pembatasan Keamanan (Restriction)
Penjualan Katalog Produk, Order Penjualan, Pelanggan Create, Read Dilarang melihat dan memodifikasi jurnal keuangan.
Gudang Penerimaan Barang (GR), Pengeluaran, Stok Fisik Create, Read, Update Dilarang menyetujui pembayaran utang pemasok.
Produksi Bill of Materials (BOM), Work Order, MRP Create, Read, Update Dibatasi hanya pada alokasi bahan dan jadwal mesin.
Pembelian Permintaan Pembelian (PR), PO, Data Pemasok Create, Read, Update Dilarang mencairkan kas atau membuat jurnal pengeluaran.
Keuangan Jurnal Umum, Buku Besar, Neraca Saldo, Kas/Bank Full Access Keuangan Dilarang mengubah spesifikasi BOM atau jadwal produksi.
Pimpinan Executive Dashboard, Persetujuan PO, Audit Trail Read, Approval Dibatasi dari entri teknis transaksi harian.

3. Rencana Pencadangan & Prosedur Pemulihan Data

  • Metode Pencadangan: Full Backup database otomatis setiap hari pukul 01:00 WIB dan backup snapshot mingguan.
  • Lokasi Penyimpanan: Menggunakan server NAS terisolasi atau bucket cloud terenkripsi (AES-256) terpisah dari server produksi.
  • Target Ketahanan: RPO (Recovery Point Objective) < 24 jam dan RTO (Recovery Time Objective) < 2 jam.
  • Prosedur Pemulihan (DR): 1. Isolasi server bermasalah, 2. Deploy database baru dari dump `.sql` tervalidasi, 3. Verifikasi jumlah baris data dan saldo akun, 4. Rekonsiliasi transaksi offline.

4. Aliran Data Ketika Pengguna Melakukan Transaksi Pembelian

Langkah 1: Pengadaan Buat Permintaan Pembelian (PR) Modul Pembelian memeriksa stok minimal
Langkah 2: Persetujuan Persetujuan & Terbit PO Pimpinan menyetujui, PO dikirim ke Vendor
Langkah 3: Penerimaan Penerimaan Barang di Gudang Gudang input Surat Jalan; stok bertambah
Langkah 4: Keuangan 3-Way Matching & Jurnal Utang Invoice dicocokkan; Utang Usaha dibukukan

5. Potensi Kegagalan Teknis & Simulasi Penanganan Gangguan

Matriks Dampak dan Prosedur Penanganan Operasional

Potensi Kegagalan Dampak Terhadap Operasional Prosedur Mitigasi & Pemulihan Teknis
Database Mati / Down Seluruh transaksi pembukuan, penjualan, dan mutasi gudang terhenti total. Restart service database, periksa kapasitas disk, alihkan ke server database replika (failover), atau restore backup terakhir.
Server Aplikasi Gangguan Pengguna tidak dapat login ke antarmuka ERP meskipun data di database tetap aman. Restart web server engine, periksa error log, deploy ulang source code stabil, dan aktifkan load balancer.
Koneksi Internet Terputus Pegawai lapangan / luar kantor tidak dapat mengakses sistem; operasional lokal kantor tetap bisa berjalan via LAN. Alihkan koneksi internet ke ISP cadangan (Dual WAN Failover); pengguna lokal tetap bekerja menggunakan IP LAN server lokal.
Pelanggaran Hak Akses Potensi kebocoran data rahasia keuangan atau manipulasi nominal transaksi. Tolak akses secara otomatis (403), catat insiden ke Security Audit Trail, dan kunci akun sementara jika percobaan berulang.
Pencadangan Gagal Data transaksi hari berjalan berisiko hilang permanen jika terjadi bencana server. Jalankan audit harian status cron backup, kirim alert saat dump gagal, dan lakukan uji restore berkala.

Alasan Pemilihan Rancangan Arsitektur

Mengapa Menggunakan Arsitektur 3-Tier Web-Based Client-Server?

1. Skalabilitas & Kemudahan Maintenance: 100 pengguna dapat mengakses sistem hanya melalui web browser tanpa perlu instalasi aplikasi di setiap komputer (Zero Client Installation). Pembaruan kode cukup dilakukan sekali di server.

2. Keamanan Data Terpusat: Server aplikasi dan database dapat dipisahkan secara fisik/jaringan. Database tidak diekspos langsung ke internet, melainkan hanya menerima query terverifikasi dari server aplikasi.

3. Integritas Transaksional (ACID): Menjamin bahwa transaksi pembelian atau penerimaan barang yang melibatkan beberapa tabel dieksekusi secara atomik (tidak terjadi pembukuan setengah jadi).

Pemetaan Proses Bisnis dan Perancangan Alur Persetujuan

Indikator: Pemetaan dan perancangan proses bisnis. Studi kasus pengadaan bahan praktik laboratorium Politeknik META Industri. Membandingkan alur manual (as-is) dengan alur terintegrasi ERP (to-be), menetapkan aturan bisnis, dan menguji perubahan harga penawaran.

A. Diagram As-Is (Proses Manual Saat Ini dengan Tanda Risiko ⚠)

1. Dosen Pengampu Mengajukan kebutuhan bahan praktik melalui pesan WhatsApp ⚠ RISIKO: Tidak ada formulir baku, tanpa tanggal tenggat, pesan mudah tertimbun
↓
2. Kepala Laboratorium Memeriksa kebutuhan berdasarkan perkiraan ⚠ RISIKO: Subjektif; tidak mengecek ketersediaan fisik stok di gudang
↓
3. Bagian Pembelian Meminta penawaran dan melakukan pembelian ke pemasok ⚠ RISIKO: Pembelian dilakukan tanpa cek stok gudang; risiko pembelian ganda tinggi
↓
4. Petugas Gudang Menerima barang fisik; bukti terima dikirim via foto/pesan WA ⚠ RISIKO: Dokumen fisik rentan hilang; stok tidak langsung terdata di sistem
↓
5. Bagian Keuangan Membayar tagihan berdasarkan dokumen yang diterima ⚠ RISIKO: Pembayaran terlambat, tanpa pencocokan faktur vs surat jalan vs pesanan
Dampak Masalah di Akhir Semester: Bahan praktik menumpuk di gudang karena dibeli ganda, anggaran terbuang untuk barang yang tidak mendesak, dan hubungan dengan vendor terganggu akibat keterlambatan pembayaran.

B. Diagram To-Be (Rancangan Proses Terintegrasi Sistem ERP)

1. Dosen Pengampu Input Permintaan Pembelian (PR) di Modul ERP ✓ Identitas pengaju, mata kuliah, spesifikasi, dan estimasi biaya tercatat baku
↓
2. Kepala Laboratorium Verifikasi Kebutuhan & Kelayakan Praktikum ✓ Melihat jadwal semester dan silabus kurikulum
↓
3. Sistem ERP & Gudang Pemeriksaan Otomatis Saldo Stok & PO Terbuka Titik Keputusan: Apakah persediaan bahan di gudang mencukupi?
↓
STOK CUKUP Diterbitkan Bukti Pengeluaran Barang (Goods Issue) ✓ Langsung diambil dari gudang tanpa pembelian baru
STOK KURANG Rekomendasi Pembelian Terbit Sebesar Kekurangan Lanjut ke alur pengadaan vendor
↓
4. Bagian Pembelian & Pimpinan Pemilihan Pemasok & Persetujuan Berjenjang (Approval) ✓ PO otomatis diterbitkan setelah approval pihak berwenang
↓
5. Gudang & Keuangan Penerimaan Barang (GR) & Verifikasi 3-Way Matching ✓ Pembayaran hanya cair jika PO, Surat Jalan, dan Faktur cocok

C. Aturan Bisnis Pengadaan (Business Rules)

  • Aturan 1 (Identitas Pengaju): Setiap permintaan bahan harus mencantumkan identitas dosen, laboratorium tujuan, mata kuliah, dan tanggal penggunaan.
  • Aturan 2 (Verifikasi Stok): Sistem wajib memverifikasi saldo stok gudang dan PO yang sedang berjalan sebelum mengizinkan pembuatan Purchase Order baru.
  • Aturan 3 (Kewenangan Approval): Nilai pengadaan s/d Rp5.000.000 cukup Kepala Lab; nilai > Rp5.000.000 wajib disetujui Pimpinan / Direktur.
  • Aturan 4 (3-Way Matching): Bagian keuangan dilarang mencairkan pembayaran jika dokumen Purchase Order, Bukti Penerimaan Gudang, dan Faktur Pemasok tidak cocok.
  • Aturan 5 (Re-Approval Harga): Jika terdapat kenaikan penawaran harga dari pemasok, persetujuan sebelumnya otomatis gugur dan sistem mewajibkan persetujuan ulang.

D. Tabel Aktor dan Tanggung Jawab

Aktor Peran & Tanggung Jawab Utama
Dosen Mengajukan kebutuhan bahan praktik dengan rincian kuantitas dan jadwal.
Kepala Lab Memvalidasi urgensi bahan terhadap silabus praktikum mahasiswa.
Gudang Memeriksa stok fisik dan mencatat penerimaan barang (Goods Receipt).
Pembelian Meminta quotation pemasok, menerbitkan PO resmi setelah disetujui.
Pimpinan Memberikan persetujuan anggaran pengadaan sesuai batas otorisasi.
Keuangan Melakukan 3-way matching dan memproses pembayaran tagihan vendor.

E. Simulasi Permintaan Pengadaan & Kondisi Khusus Perubahan Harga

Daftar Permintaan Pengadaan & Uji Kenaikan Penawaran Harga Pemasok

Ujilah dengan menaikkan nilai penawaran terbaru lebih besar dari nilai awal. Sistem akan otomatis membatalkan persetujuan lama dan mengubah status menjadi "Perlu Persetujuan Ulang".

No. PR Pemohon & Bahan Qty Nilai Awal Nilai Terbaru Status Saat Ini Uji Perubahan Harga Aksi Persetujuan

Pengadaan Darurat 24 Jam Tanpa Menghilangkan Pengendalian Internal

Prosedur Fast-Track Emergency Purchase

1. Identifikasi Kedaruratan: Dosen menandai checkbox "Emergency Purchase" disertai justifikasi ujian mahasiswa.

2. One-Click Mobile Approval: Notifikasi instan dikirim ke smartphone Kepala Lab dan Pimpinan; otorisasi diberikan secara digital dalam hitungan menit.

3. Pemasok Rekanan Terverifikasi: PO langsung dialihkan ke vendor rekanan resmi (preferred vendor) yang memiliki komitmen pengiriman instan (same-day delivery).

4. Kontrol Pascabayar: Barang diterima dan langsung digunakan untuk ujian, namun bagian keuangan tetap mewajibkan Post-Audit 3-Way Matching sebelum pencairan transfer dana ke pemasok.

Alasan Mengapa Rancangan Baru Lebih Baik

Manfaat Utama Sistem Baru:
  • Meniadakan risiko pembelian ganda karena sistem memverifikasi stok dan pesanan berjalan terlebih dahulu.
  • Pengendalian anggaran yang ketat: harga yang naik otomatis membatalkan persetujuan lama, mencegah pembengkakan biaya tanpa izin.
  • Penyelesaian tagihan tepat waktu dengan pencocokan dokumen elektronik terpadu (3-Way Matching).

Konfigurasi dan Simulasi Modul Keuangan

Modul Finansial & Akuntansi: Saldo awal kas Rp30.000.000, konfigurasi bagan akun (COA), pencatatan transaksi kredit dan tunai, laporan jurnal umum & buku besar, neraca saldo, serta pengujian deteksi duplikasi dan koreksi jurnal pembalik dengan jejak audit.

Saldo Kas Saat Ini
Rp 0
Kas Operasional (Debit)
Piutang Usaha
Rp 0
Tagihan Pelanggan (Debit)
Persediaan Bahan Baku
Rp 0
Aset Stok (Debit)
Utang Usaha Pemasok
Rp 0
Kewajiban (Kredit)

Tahap 1 — Konfigurasi Bagan Akun (Chart of Accounts / COA)

Struktur kode akun dan klasifikasi saldo normal yang diterapkan pada modul keuangan ERP.

Kode Akun Nama Akun Kategori Saldo Normal Deskripsi Penggunaan

Tahap 2 — Input Transaksi Keuangan

Sistem telah memuat Saldo Awal Kas Rp30.000.000 dan transaksi operasional awal. Anda dapat menambahkan transaksi baru di bawah ini:

Tahap 3 — Laporan Jurnal Umum (General Journal)

ID Txn Tanggal Keterangan Transaksi Nama Akun Debit (Rp) Kredit (Rp) Jejak Audit / Referensi

Buku Besar per Akun (General Ledger)

Nama Akun Total Debit Total Kredit Saldo Akhir

Neraca Saldo (Trial Balance)

Nama Akun Debit Bersih Kredit Bersih

Tahap 4 — Pengujian Kesalahan: Duplikasi Pembayaran & Jurnal Koreksi

Skenario: Pembayaran Pemasok Dicatat Dua Kali

1. Menemukan Duplikasi: Transaksi nomor #3 (Pembayaran utang pemasok Rp3.000.000) dicatat ulang karena kelalaian pengguna.

2. Dampaknya terhadap Saldo: Kas berkurang ganda (menjadi Rp27.500.000 alih-alih Rp30.500.000) dan Utang Usaha berkurang ganda (menjadi Rp2.000.000 alih-alih Rp5.000.000), mengakibatkan laporan keuangan salah saji.

3. Prosedur Koreksi yang Benar: Dilarang menghapus baris dari database karena akan merusak jejak audit (Audit Trail). Koreksi dilakukan dengan menerbitkan Jurnal Pembalik (Reversing Entry): Kas di-Debit Rp3.000.000 dan Utang Usaha di-Kredit Rp3.000.000.

Langkah A: Buat Duplikat Simulasi Pembayaran Utang

Langkah B: Koreksi Jurnal Pembalik (Reversal Entry)

Transaksi Duplikat Nominal Tindakan Koreksi

Konfigurasi SCM dan Pembelian Berbasis Kebutuhan Material

Indikator: Konfigurasi modul SCM dan pembelian. Skenario: Produksi 300 unit produk jadi dalam tenggat 6 hari kerja. BOM: 3 unit Bahan A dan 2 unit Bahan B per produk. Perhitungan kebutuhan bruto/bersih, simulasi PO, penerimaan barang bertahap, dan analisis keputusan saat pemasok terlambat.

Tahap 1 — Konfigurasi Data Master Produk, BOM, Stok & Pemasok

Kode Nama Komponen Tipe Stok Tersedia PO Belum Diterima Kebutuhan per Unit Produk (BOM) Waktu Pengadaan (Lead Time) Status Kesiapan

Daftar Pemasok Resmi & Waktu Pengiriman Standar

Tahap 2 — Perhitungan Kebutuhan Material (Kebutuhan Bruto & Bersih)

Bahan Baku Rasio BOM Kebutuhan Bruto Stok Tersedia PO Belum Datang Kebutuhan Bersih (Net) Lead Time Standar Evaluasi Terhadap Tenggat

Asumsi & Analisis Waktu Pengadaan:

1. Bahan Baku A: Kebutuhan Bruto = 300 × 3 = 900 unit. Tersedia Stok = 400 unit, dan PO belum datang = 100 unit. Maka Kebutuhan Bersih = 900 − 400 − 100 = 400 unit. PO 100 unit dapat dipakai karena waktu pengadaan 4 hari kerja masih dalam batas tenggat 6 hari.

2. Bahan Baku B: Kebutuhan Bruto = 300 × 2 = 600 unit. Tersedia Stok = 250 unit, PO belum datang = 0. Maka Kebutuhan Bersih = 600 − 250 = 350 unit. Waktu pengadaan standar 7 hari kerja melebihi tenggat 6 hari kerja, sehingga menjadi kendala utama (bottleneck).

Tahap 3 — Simulasi Permintaan Pembelian (PO Baru)

Tahap 5 — Pengujian Perubahan Kondisi (Pemasok B Terlambat 8 Hari)

Pemberitahuan Pemasok:
"Pemasok Bahan B menginformasikan bahwa barang baru dapat dikirim dalam 8 hari kerja, sedangkan produksi harus selesai dalam 6 hari kerja."

Pilih Keputusan Pengadaan & Evaluasi Risiko:

Tahap 4 — Penerimaan Barang Sebagian & Laporan Perubahan Stok

ID PO Material & Pemasok Dipesan Diterima Sisa Pesanan Status PO Penerimaan Barang Sebagian (Partial)

Riwayat Penerimaan Fisik di Gudang (Goods Receipts)

Waktu Penerimaan Referensi PO Material Jumlah Diterima Catatan / Nomor Surat Jalan

Rangkuman Evaluasi Data Modul SCM

(1) Data Master & BOM

Tersedia master Bahan A (BOM: 3) dan Bahan B (BOM: 2) untuk 1 unit produk jadi.

(2) Kebutuhan Bruto & Bersih

Target 300 unit: A = 900 bruto / 400 bersih; B = 600 bruto / 350 bersih.

(3) Bukti Permintaan PO

Tersimpan pada tabel pesanan pembelian dengan tracking kuantitas terbuka.

(4) Simulasi Penerimaan

Penerimaan bertahap langsung menambah stok fisik dan memotong PO terbuka.

ERP System — TRPL Politeknik META Industri · By Nadia Putri Balqis