Belum terhubung ke Stockwiz. Semua angka, bukti, dan transaksi pada simulasi ini bersifat ilustratif serta hanya berlaku selama halaman terbuka. Pemilihan peran di sini merupakan demonstrasi alur, bukan login atau otorisasi operasional.

Simulasi ini hanya mencakup satu kasus produk jadi. Gudang bahan baku, bahan kemas, B2B, dan area lainnya tercantum pada cakupan seluruh warehouse.

*Reserved merupakan bagian dari stok diluluskan, bukan penambahan on-hand. Available = diluluskan − reserved pada skenario ini; retur/hold/expired tidak menjadi stok siap alokasi. Saat peran penghitung aktif, angka pembanding dan hasil petugas lain disembunyikan untuk demonstrasi blind count.

Cakupan area berikut menjadi dasar usulan pengendalian warehouse. Warehouse B2B termasuk dalam cakupan kerja; penanggung jawab serta garis pelaporannya perlu dipetakan ke struktur yang disahkan. Penetapan jabatan dan garis pelaporan mengikuti struktur organisasi yang disahkan.

Contoh stock explorer lintas area

Seluruh baris berikut adalah ilustrasi pemetaan, terpisah dari simulasi kasus CAPA. Tidak ada penjumlahan kg, liter, pcs, atau stok beda SKU menjadi satu angka persediaan. On-hand = diluluskan + karantina + blocked pada contoh ini; reserved merupakan bagian dari diluluskan.

*Blocked mencakup stok tidak layak alokasi pada contoh. Dalam data operasional, alasan reject/rusak/expired/recall tetap dipisahkan dan ditelusuri per status. Kode lokasi contoh belum menyatakan pemetaan aktual Stockwiz.

Aturan pemetaan lokasi dan kanal

• Setiap baris stok memakai ID lokasi/bin Stockwiz, SKU, lot/batch, status dan satuan dasar yang jelas; tambahkan owner/entitas jika relevan. Kelompok RM/PM/FG/B2B membantu penyajian, bukan mengganti identitas lokasi.
• Jika B2B adalah gudang fisik berbeda, catat sebagai lokasi berbeda dengan transfer dan receipt. Jika hanya alokasi kanal dalam gudang FG yang sama, catat reservasi kanal B2B pada stok tersebut; jangan menyalin saldo ke gudang virtual lalu menjumlahkannya lagi.
• Capture kanal/customer/sales order pada reservasi/pengeluaran produk jadi. Bahan baku/kemas terhubung ke order produksi/packing; satu jenis relasi order tidak dipaksakan untuk semua area.
• UOM dan presisi mengikuti SKU/spesifikasi: RM dapat memakai kg/liter/desimal; PM dan produk jadi memakai unit yang dipetakan beserta pack conversion. Simulasi count produk jadi berunit bulat bukan aturan untuk semua bahan.
• Setiap area memakai pola tugas, count/recount, investigasi, koreksi sumber dan CAPA yang sama, dengan aturan mutu, bukti, toleransi serta pemeriksa yang disesuaikan risikonya.

Pemetaan ini menyelaraskan dokumen program dengan rancangan sistem pendukung. Modul operasional masih berupa rancangan dan belum terhubung ke Stockwiz. Prototipe aktif hanya memperagakan kasus count–transfer produk jadi–CAPA; tabel cakupan area lainnya adalah contoh data.

Matriks keterkaitan peran dan aplikasi

Standar penyelesaian setiap pekerjaan

1. Identitas: ID kasus/tugas, area/lokasi, dokumen/baris sumber, SKU/lot/batch, UOM, waktu dan versi data yang relevan.
2. Pelaksanaan: pelaksana, penanggung jawab, pemeriksa, tenggat, realisasi dan bukti serah terima.
3. Verifikasi: cek fisik/dokumen dan read-back bila ada perubahan sumber; catat siapa memeriksa, keputusan, serta alasan bila ada tahapan yang tidak relevan.
4. Tindak lanjut: exception memiliki severity, containment, PIC dan tenggat. CAPA memiliki akar masalah, implementasi, rencana review, pemeriksa dan status close/reopen.
5. Pengukuran: hasil memperbarui KPI dengan scope/periode yang konsisten; kesalahan data sumber tidak dianggap perbaikan operasional tanpa bukti lapangan.

Kriteria penyelesaian per alur

Status kesiapan implementasi

Materi keputusan dan kepemimpinan

Rancangan aplikasi mendukung pelaksanaan program kerja, pengendalian operasional, dan pengembangan tim. Acuan pembahasan utama tersedia pada ringkasan keputusan, rencana pembinaan SPV/PIC, business case untuk validasi Finance, rencana hambatan/eskalasi, serta pengalaman dan kompetensi pendukung. Panel kendali SPV dan laporan Manager perlu menampilkan perkembangan tim, kapasitas, biaya serta keputusan yang diperlukan sesuai mandat, bukan hanya jumlah temuan.

Sebelum go-live: sahkan PIC/backup dan scope B2B, metode akses Stockwiz, kamus status/UOM, cutoff dan SLA, batas nilai/risiko persetujuan, klasifikasi CAPA, rencana efektivitas, retensi, backup/restore serta acceptance test. Hal-hal ini merupakan keputusan implementasi, bukan asumsi bahwa sistem sudah terintegrasi.

Keputusan rancangan: seluruh data operasional diperoleh dari Stockwiz, berdasarkan informasi awal mengenai proses operasional. Cakupan meliputi bahan awal (bahan baku dan bahan kemas), produk jadi/stockroom, warehouse B2B, serta area produk jadi dan kanal lain yang ditetapkan. Aplikasi ini tidak membangun buku stok tandingan. Stockwiz tetap menjadi sumber resmi saldo/transaksi; aplikasi menyimpan penugasan, hitungan fisik, bukti, investigasi, persetujuan, dan CAPA beserta referensi ke data sumber.

Ketersediaan API, webhook, dan izin tulis Stockwiz perlu diverifikasi bersama Systems. Rancangan awal mendukung pembacaan API yang diotorisasi atau ekspor file terkontrol; metode final ditetapkan setelah pemeriksaan teknis bersama Systems.

Modul yang dibutuhkan tim

Contoh antrean kerja harian

Jalur pelaporan: Warehouse & Inventory Manager → Deputi COO → CO Founder & COO. HR menjadi mitra pembahasan organisasi, uraian tugas, kompetensi serta kebutuhan personel bersama kedua atasan tersebut. Akses approval di aplikasi mengikuti delegasi yang disahkan, bukan otomatis mengikuti hak administrator atau jabatan HR.

Aturan otorisasi

• Hak akses diperiksa di server pada setiap tindakan, objek, lokasi, dan status workflow. Pembatasan pada antarmuka dilengkapi validasi otorisasi di server.
• Identitas pengguna unik; akun bersama tidak dipakai untuk persetujuan. Perubahan hak akses/pengganti dicatat, disetujui, dan memiliki masa berlaku.
• Requester, pelaksana koreksi, approver, dan pemeriksa efektivitas dipisahkan berdasarkan risiko. Jika tim kecil, gunakan pemeriksa silang dengan otorisasi tercatat.
• Barang quarantine/hold/reject tidak menjadi available. Keputusan QC tidak dapat diubah SPV atau Admin melalui aplikasi pendamping.

Selector peran pada simulasi hanya berisi pelaksana skenario count–koreksi–CAPA. Daftar tersebut tidak menggantikan matriks akses seluruh area di atas.

Rute keputusan dan pelaporan dalam aplikasi

• SPV/PIC melaporkan realisasi, exception serta tindakan kepada Manager; Manager menyerahkan ringkasan kinerja, risiko, CAPA dan kebutuhan keputusan kepada Deputi COO.
• Permohonan di atas batas nilai/risiko atau di luar mandat Manager berstatus pending approval Deputi COO; bila melampaui delegasinya diteruskan kepada CO Founder & COO. Persetujuan tidak dipaksakan pada Manager hanya agar workflow selesai.
• Approval mengikat objek, jumlah/nilai, risiko, versi dan delegasi. Perubahan signifikan memerlukan review ulang; keputusan terpisah QA/QC/Finance tetap dipenuhi.
• Simulasi saat ini memakai transaksi ilustrasi dalam mandat Manager. Approval Deputi COO/CO Founder & COO serta pengelolaan delegasi masih spesifikasi pembangunan, belum fungsi operasional prototipe.

Kontrak data Stockwiz

Alur integrasi bertahap

1. Landing: simpan batch impor/snapshot mentah dengan ID, waktu sumber/ingest, scope, jumlah baris, checksum, dan hasil pemeriksaan.
2. Validasi: periksa mapping, UOM, angka, batch/status, kelengkapan pagination/file, duplikasi, dan total kontrol. Snapshot tidak lengkap gagal secara utuh, tidak mengganti snapshot valid terakhir.
3. Promosi: hanya snapshot tervalidasi menjadi tampilan aktif. Tampilkan freshness dan sumber; notifikasi bila sinkronisasi terlambat menurut SLA yang disepakati.
4. Investigasi/koreksi: rekomendasi disetujui mengikuti risiko/nilai. Jika API tulis terverifikasi dan diotorisasi, kirim perintah dengan kunci idempoten; jika belum, Admin memposting di Stockwiz lalu memasukkan referensi.
5. Read-back teknis: integrasi membaca kembali transaksi dan saldo sumber; cocokkan referensi, scope, jumlah serta versi. Timeout berstatus “hasil belum pasti”; telusuri referensi sebelum retry.
6. Verifikasi bisnis: Inventory Control memeriksa substansi dokumen, kedua lokasi, cutoff/movement dan hasil fisik, kemudian memberi sign-off. Systems tidak menggantikan persetujuan bisnis; mismatch tetap menjadi exception terbuka.

Empat status yang tidak boleh dicampur

• Status mutu barang: karantina/diluluskan/ditolak dan keputusan mutu terkait, berasal dari fungsi berwenang.
• Status logistik/alokasi: reserved, picked, staged, in-transit, partial atau received, ditautkan ke dokumen dan lokasi. Reserved bukan tambahan on-hand atau keputusan mutu.
• Status kasus: open, investigasi, pending approval, koreksi, verifikasi, CAPA, close/reopen; kasus terbuka tidak otomatis mengubah status QC barang.
• Status integrasi: valid, stale, incomplete, failed, pending confirmation. Angka dari snapshot tidak lengkap tidak dianggap saldo nol atau sumber baru yang sah.

Entitas aplikasi pendamping

Arsitektur implementasi yang disarankan

Mulai dengan satu aplikasi web responsif, satu layanan API, database relasional, penyimpanan bukti, dan worker integrasi terjadwal. Pisahkan modul secara logis sebelum mempertimbangkan layanan terpisah. Gunakan stack yang sudah dikuasai Systems; PostgreSQL merupakan opsi database, bukan keputusan pengadaan final.

Perubahan status kasus, approval, audit event, dan antrean perintah dicatat dalam transaksi database yang konsisten. Gunakan versi rekaman/locking untuk mencegah dua approval atau posting bersamaan, constraint unik untuk idempotensi, serta pembatasan akses di API. Integrasi eksternal memakai antrean perintah dan rekonsiliasi hasil; transaksi lokal tidak dianggap bisa menjamin transaksi lintas Stockwiz secara otomatis.

Alur kasus standar

Containment berjalan sejak temuan terdeteksi: lindungi barang/proses terdampak, hentikan alokasi yang diragukan sesuai risiko, dan amankan bukti. Pengendalian risiko mutu atau selisih yang signifikan dimulai segera, sejalan dengan proses investigasi. Freeze lokasi/batch pada count disepakati dengan operasi; jika pergerakan tetap terjadi, semua movement selama interval harus direkonsiliasi sebelum delta ditetapkan.

Triage dan cabang penyelesaian

• Count sesuai: tutup perintah hitung dengan verifikasi scope/cutoff; tidak membuat adjustment atau CAPA otomatis.
• Koreksi sederhana: masalah terisolasi dengan bukti memadai dapat ditutup setelah koreksi dan verifikasi, bila tidak memenuhi kriteria CAPA. Alasan dan persetujuan triage tetap dicatat sesuai risiko.
• Temuan sistemik, berulang, atau berisiko tinggi: buka CAPA dengan akar masalah, pemilik, tenggat dan rencana efektivitas. Ambang penilaian disahkan QA/manajemen, tidak diputuskan sepihak oleh aplikasi.
• Temuan mutu/proses tanpa perubahan saldo: misalnya kondisi simpan atau higiene, dapat langsung masuk jalur QA/CAPA tanpa count atau posting stok. Bukti evaluasi mutu dan implementasi menjadi syarat verifikasi.
• Data sumber tidak andal: perbaiki/revalidasi snapshot dan rekonsiliasi sebelum menyimpulkan variance fisik. Penahanan alokasi sementara dicatat terpisah dari keputusan hold mutu.

Kontrol otomatis yang perlu disediakan

• Dokumen: referensi ganda, nomor tidak dikenal, jumlah/baris tidak sesuai, serta bukti serah terima belum lengkap.
• Stok: saldo negatif, mismatch lokasi/batch/status, reserved melebihi eligible stock, expiry, dan available yang memasukkan barang non-saleable.
• Transfer: dispatch tanpa receipt melewati SLA, jumlah diterima parsial, perbedaan batch, serta dokumen fisik tanpa posting.
• Count: blind count, recount oleh pengguna berbeda, scope count tumpang tindih, kondisi awal berubah, dan transaksi selama count.
• CAPA: tugas overdue, bukti implementasi belum diverifikasi, periode efektivitas belum selesai, kasus berulang, dan approval atas versi lama.
• Integrasi: snapshot stale, file/pagination tidak lengkap, retry duplikat, hasil posting belum pasti, serta saldo read-back tidak sesuai.

Persyaratan penutupan CAPA

1. Akar masalah didukung bukti dan containment dinilai cukup.
2. Jika ada koreksi transaksi/status di Stockwiz, hasil read-back diverifikasi secara bisnis oleh Inventory Control serta QC bila terkait keputusan mutu. Jika tidak ada perubahan sumber, ketidakrelevanan tahap tersebut memiliki alasan dan persetujuan pemeriksa.
3. Tindakan implementasi mempunyai pemilik, tanggal, bukti, dan verifikasi penyelesaian.
4. Review efektivitas selesai sesuai rencana periode/sampel dan dilakukan pihak yang berbeda dari pelaksana tindakan.
5. Efektif → penutupan disetujui sesuai mandat; tidak efektif → kasus dibuka kembali dengan tindakan dan tenggat baru. Kejadian terkait setelah close ditautkan ke kasus lanjutan/reopen sesuai kebijakan tanpa menghapus riwayat.

Rancangan mutu mengikuti pembagian tugas dan matriks CPKB dalam proposal program. Sistem mendukung pelaksanaan dan bukti; penilaian mutu, kriteria risiko, otorisasi, serta validasi sistem tetap ditetapkan perusahaan bersama QA/Regulatory.

Uji terima sebelum penggunaan operasional

Ukuran manfaat uji coba

Bandingkan waktu administrasi per dokumen, jumlah/umur backlog, selisih fisik per baris/nilai, kecepatan investigasi, pengulangan kasus, CAPA overdue, serta ketersediaan produk uji coba. Penurunan stockout dinilai bersama stock aging, modal kerja, dan biaya distribusi agar perbaikan tidak hanya berasal dari penumpukan barang.

Keputusan yang diperlukan

Rancangan dibahas bersama HR, Deputi COO dan CO Founder & COO, dengan QA, Systems serta pemilik Stockwiz untuk aspek teknis/mutu. Manager mengajukan scope uji coba, metode akses data, PIC/backup, kebutuhan sumber daya, batas delegasi/persetujuan dan kriteria go-live melalui Deputi COO; keputusan pada tingkat CO Founder & COO mengikuti kewenangannya. HR mendukung organisasi dan personel. Prototipe belum memiliki backend, koneksi Stockwiz, autentikasi, penyimpanan bersama atau kontrol produksi.