Praktikum 3

Pemetaan Proses Bisnis dan Perancangan Alur Persetujuan

Indikator: pemetaan dan perancangan proses bisnis. Studi kasus: pembelian bahan praktik laboratorium Politeknik META Industri.

A. Diagram As-Is (Proses Manual Saat Ini)

flowchart TD
  A["Dosen
ajukan kebutuhan via WhatsApp"] --> B["Kepala Lab
periksa berdasarkan perkiraan"]
  B --> C["Pembelian
minta penawaran pemasok"]
  C --> D["Pembelian
beli tanpa cek stok gudang"]
  D --> E["Gudang
terima barang"]
  E --> F["Gudang
kirim bukti terima via pesan"]
  F --> G["Keuangan
bayar berdasarkan dokumen yang diterima"]
  style A fill:#fde8e8,stroke:#d03a3a,color:#1c2330
  style B fill:#fde8e8,stroke:#d03a3a,color:#1c2330
  style D fill:#fde8e8,stroke:#d03a3a,color:#1c2330
  style F fill:#fde8e8,stroke:#d03a3a,color:#1c2330

Kotak merah adalah aktivitas berisiko menimbulkan kesalahan atau keterlambatan.

Kelemahan, penyebab, dan dampak

Kelemahan	Penyebab	Dampak
Permintaan lewat chat	Tidak ada formulir atau sistem resmi	Tidak ada jejak, permintaan hilang atau ganda
Kebutuhan hanya perkiraan	Verifikasi tidak memakai data stok dan pemakaian	Bahan menumpuk atau kurang
Beli tanpa cek stok	Pembelian dan Gudang tidak terhubung	Pembelian ganda dan pemborosan anggaran
Bukti terima lewat pesan	Dokumen penerimaan tidak baku	Pembayaran terlambat atau salah
Tidak ada persetujuan jelas	Alur approval tidak terdefinisi	Pembelian tanpa otorisasi

B. Diagram To-Be (Setelah ERP)

flowchart TD
  A["Dosen
input permintaan di ERP
(identitas otomatis)"] --> B["Kepala Lab
verifikasi kebutuhan"]
  B --> C{"Stok gudang
cukup?"}
  C -- "Ya" --> D["Gudang
keluarkan dari stok"]
  C -- "Tidak" --> E["Pembelian
buat PR dan pilih pemasok"]
  E --> F["Pembelian
buat PO"]
  F --> G{"Nilai PO
di atas batas?"}
  G -- "Ya" --> H["Pimpinan
setujui PO"]
  G -- "Tidak" --> I["Kepala Lab / Manajer
setujui PO"]
  H --> J["Gudang
penerimaan barang (GR)"]
  I --> J
  J --> K{"PO, GR, dan Faktur
cocok (3-way match)?"}
  K -- "Ya" --> L["Keuangan
proses pembayaran"]
  K -- "Tidak" --> M["Tahan pembayaran
dan telusuri selisih"]

Perbedaan nyata dari as-is: ada titik keputusan stok, persetujuan berjenjang, dan pencocokan dokumen sebelum bayar.

C. Aturan Bisnis

Identitas pengaju: setiap permintaan wajib terhubung dengan akun pengaju (login), tidak bisa anonim.
Cek stok: permintaan pembelian otomatis diperiksa terhadap stok. Jika stok cukup, pembelian diblokir dan barang diambil dari gudang.
Persetujuan sesuai wewenang: PO hanya sah setelah disetujui pihak yang berwenang menurut batas nilai.
Pembayaran berdasarkan dokumen: pembayaran hanya diproses jika PO, penerimaan barang, dan faktur cocok (3-way match).
Pemisahan tugas: pembuat PO tidak boleh menyetujui atau membayar PO yang sama.

Tabel Aktor dan Tanggung Jawab

Aktor	Tanggung jawab
Dosen	Mengajukan permintaan bahan di sistem
Kepala Laboratorium	Memverifikasi kebutuhan dan menyetujui PO bernilai kecil
Gudang	Memeriksa stok, menerima barang, mencatat penerimaan
Pembelian	Membuat PR, memilih pemasok, menerbitkan PO
Pimpinan	Menyetujui PO di atas batas nilai
Keuangan	Memproses pembayaran setelah dokumen cocok

D. Simulasi Kondisi Khusus: Nilai Pembelian Naik

Pemasok mengirim penawaran terbaru yang lebih mahal. Apakah persetujuan sebelumnya masih berlaku? Coba dengan angka sendiri.

Cek Persetujuan Ulang

Nilai PO yang sudah disetujui (Rp)

Nilai PO setelah penawaran baru (Rp)

Batas wewenang penyetuju awal (Rp)

Toleransi kenaikan (%)

Aturan yang dirancang Persetujuan lama hanya berlaku jika nilai baru tidak melewati batas wewenang penyetuju awal dan kenaikannya tidak lebih dari toleransi. Jika salah satu terlampaui, status PO kembali ke "Menunggu Persetujuan" dan harus disetujui ulang. Setiap perubahan dicatat di log.

Pembelian Darurat (Kebutuhan 24 Jam)

Prosedur normal butuh lima hari kerja, sedangkan bahan dibutuhkan dalam 24 jam. Pengendalian internal tetap dijaga, hanya waktunya dipersingkat.

Langkah	Pengendalian
1. Ajukan lewat jalur emergency PO	Alasan tertulis wajib diisi, identitas pengaju tercatat
2. Cek stok dan sumber lain	Gudang memastikan tidak ada stok yang bisa dipakai
3. Pilih pemasok terdaftar	Hanya pemasok yang ada di data master, harga dibandingkan jika memungkinkan
4. Persetujuan cepat satu tingkat	Pimpinan menyetujui lewat notifikasi, ada batas nilai maksimum
5. Terima barang dan catat GR	Penerimaan tetap dicatat di sistem
6. Review pasca-kejadian	Semua PO darurat ditinjau ulang, penyalahgunaan dapat ditelusuri

Alasan Rancangan Baru Lebih Baik

Permintaan terdokumentasi dan bisa ditelusuri, tidak hilang di chat.
Stok dicek sebelum membeli, sehingga mencegah penumpukan dan pembelian ganda.
Persetujuan berjenjang mencegah pembelian tanpa otorisasi.
Pembayaran hanya dengan dokumen yang cocok, mengurangi salah bayar dan keterlambatan.

Riwayat Simulasi (Terhubung Database)

Bukti yang Dikumpulkan

Diagram as-is dan to-be (bagian A dan B)
Daftar aturan bisnis (bagian C)
Tabel aktor dan tanggung jawab (bagian C)
Simulasi kondisi khusus (bagian D)
Alasan rancangan baru lebih baik (bagian terakhir)