Integrated Web-Based Statistical Process Control Platform

1. Ringkasan Eksekutif

Klien membutuhkan pengganti sistem SPC lokal (legacy) yang sudah tidak didukung Windows 11, terkunci pada kiosk tetap, dan belum memiliki integrasi kamera. Solusi yang diusulkan adalah aplikasi web SPC terpusat dengan arsitektur hybrid: aplikasi dan basis data di cloud, ditambah edge agent di jaringan pabrik yang menangani pembacaan timbangan digital, antrean data saat internet terganggu, dan registrasi perangkat kiosk/tablet.

Pendekatan hybrid dipilih karena tiga alasan operasional:

1. Timbangan digital umumnya hanya punya keluaran serial (RS-232/USB-serial), bukan API jaringan. Browser tidak bisa membacanya secara andal di mode kiosk, sehingga dibutuhkan komponen lokal yang berbicara ke perangkat keras.
2. Konektivitas lantai produksi tidak selalu stabil. Tanpa buffer lokal, satu kali WiFi putus berarti operator kehilangan data entry — tidak dapat diterima untuk data kualitas.
3. Fleksibilitas kepatuhan. Jika IT korporat klien mewajibkan seluruh data produksi tetap di dalam jaringan pabrik, komponen cloud dapat dipindahkan ke on-premise tanpa membangun ulang aplikasi.

Estimasi cakupan: 13–15 minggu untuk build penuh setelah discovery, dengan prototype fungsional 5–7 hari kerja yang dapat dipakai lebih dulu untuk mengunci pemahaman bersama sebelum kontrak pengembangan.

2. Pemahaman Kebutuhan Berdasarkan URS

Seluruh acuan kebutuhan dalam proposal ini bersumber dari URS-IT-SPC-001 v0.1. Tidak ada requirement dari sumber lain yang diperlakukan sebagai bagian dari kesepakatan.

2.1 Cakupan yang didefinisikan URS

URS-IT-SPC-001 memuat 23 requirement — 17 berprioritas Must dan 6 Should — tersebar pada empat kategori:

Struktur dokumen URS dan implikasinya terhadap desain:

2.2 Di luar lingkup

Sesuai URS: advanced predictive analytics, integrasi ERP/MES, dan electronic approval workflow — kecuali ditambahkan melalui change control. Proposal ini tidak mengklaim kemampuan prediktif atau AI pada modul SPC; seluruh perhitungan bersifat statistik deterministik yang dapat diaudit.

3. Ruang Lingkup dan Pemetaan URS

3.1 Modul solusi

3.2 Matriks pemenuhan requirement

4. Arsitektur Solusi

4.1 Gambaran komponen

4.2 Prinsip desain

• Edge agent bersifat opsional-gagal. Jika edge mati, kiosk tetap bisa dipakai dengan input manual berat. Tidak ada single point of failure pada entry data.
• Outbound-only. Edge agent hanya membuka koneksi keluar ke cloud. Tidak ada port masuk ke jaringan pabrik — memudahkan persetujuan tim keamanan jaringan.
• Satu codebase, dua persona. Kiosk dan tablet memakai aplikasi yang sama; perbedaan hanya pada layout adaptif dan mode kunci (kiosk mode).
• Immutable by construction. Tidak ada operasi UPDATE/DELETE untuk hasil pengukuran. Koreksi dilakukan dengan record pembetulan (supersede) yang tertaut, sehingga histori tetap utuh.
• Spec limit versioned. Perubahan LSL/USL oleh QA tidak mengubah klasifikasi record lama; setiap record menyimpan spec_version_id yang berlaku saat itu.

4.3 Opsi deployment

Rekomendasi: Opsi B, dengan aplikasi dibangun agar migrasi ke Opsi C hanya mengganti konfigurasi endpoint — bukan menulis ulang kode. Keputusan final menunggu jawaban atas pertanyaan data residency di bagian 14.

5. Tech Stack dan Justifikasi

Catatan: seluruh komponen bersifat open-source atau berbiaya operasional rendah. Tidak ada lisensi tersembunyi per-seat — penting untuk kiosk yang jumlahnya bisa bertambah.

6. Desain Data

6.1 Tabel inti

6.2 Prinsip integritas

• Append-only untuk hasil ukur. records tidak memiliki policy UPDATE/DELETE. Salah input ditangani lewat record pembetulan bertaut (superseded_by) yang tetap menyisakan record asli.
• Trigger audit universal. Satu fungsi trigger dipasang pada seluruh tabel yang dapat diubah, menulis before/after sebagai JSONB. audit_log hanya memiliki policy SELECT untuk admin dan INSERT untuk trigger — tidak ada UPDATE/DELETE untuk siapa pun, termasuk admin.
• Soft-delete master data. Deaktivasi mengisi active=false. Record historis tetap merujuk baris lama sehingga laporan tahun lalu tetap terbaca utuh.
• Immutability gambar. File disimpan dengan nama berbasis record_id + checksum; verifikasi checksum dijalankan pada job harian.
• Zona waktu. Semua timestamp disimpan timestamptz UTC, ditampilkan dalam Asia/Jakarta. recorded_at selalu dari server, bukan jam perangkat — perangkat kiosk sering salah jam.

6.3 Indeks untuk performa

Indeks komposit pada records (line_id, recorded_at desc), records (parameter_id, recorded_at desc), records (batch_id), dan records (status) where status <> 'ok'. Untuk volume realistis (mis. 20 line × 200 record/hari ≈ 1,4 juta record/tahun), Postgres dengan indeks ini tetap responsif tanpa partisi; partisi bulanan disiapkan sebagai opsi bila volume melebihi 10 juta record.

7. Integrasi Timbangan Digital

7.1 Realita protokol

Timbangan industri hampir selalu berkomunikasi lewat RS-232 (DB9) atau USB-serial, dengan keluaran ASCII. Protokol yang paling umum:

• Mettler Toledo — MT-SICS, atau mode BDI (Bidirectional Data Interface) dengan perintah ASCII
• Sartorius — SBI
• Adam Equipment / Ohaus / AND / CAS — ASCII continuous atau on-demand (karakter perintah seperti S / SI)

Tidak ada standar tunggal. Karena itu desain driver dibuat profile-based: setiap profil berisi konfigurasi port (baud, data bits, parity, stop bits), mode (continuous vs on-demand), perintah permintaan, dan regex parsing.

7.2 Alur pembacaan

1. Timbangan mengirim data ASCII ke port serial.
2. Edge agent mem-parsing sesuai profil perangkat yang aktif.
3. Edge agent mendeteksi kestabilan: flag ST dari timbangan, atau N sampel identik dalam ≥ 500 ms.
4. Nilai divalidasi terhadap rentang dan satuan yang diharapkan.
5. Nilai dikirim ke kiosk lewat WebSocket localhost:8787 dan tampil di field berat.

Kiosk berlangganan WebSocket lokal dan menampilkan berat live. Operator menekan "Ambil" untuk mengunci nilai — bukan otomatis tersimpan. Ini mencegah nilai transien (barang masih bergerak di atas timbangan) ikut tersimpan, dan memberi operator kendali yang jelas.

7.3 Penanganan kasus tepi

7.4 Kriteria penerimaan FUN-006

Uji integrasi: tempatkan anak timbangan standar (mis. 100 g), pastikan nilai terbaca pada field yang benar tanpa pengetikan ulang, dan selisih terhadap display timbangan ≤ resolusi alat (mis. ±0,1 g untuk timbangan 0,1 g). Uji diulang untuk setiap merek/model timbangan yang terpasang.

8. Capture Kamera

• Akuisisi: getUserMedia pada browser kiosk/tablet — tanpa komponen tambahan, tanpa izin instalasi.
• Alur UX: tombol kamera → preview live → jepret → pratinjau hasil → Ulangi atau Pakai. Operator tidak bisa menyimpan record tanpa menekan salah satu.
• Kompresi: canvas resize ke maksimal 1600px sisi terpanjang, JPEG kualitas 0,8. Rata-rata 150–300 KB per foto — cukup untuk verifikasi visual, hemat storage.
• Penyimpanan: bucket privat, path {line_code}/{YYYY}/{MM}/{record_id}/{ts}.jpg. Akses hanya via signed URL berumur pendek.
• Keterkaitan (FUN-008): path memuat record_id, dan baris record_media menyimpan product_id + batch_id hasil join, sehingga gambar dapat ditelusuri dari record maupun dari batch.
• Fallback: tablet tanpa kamera dapat mengunggah file dari galeri; kind dibedakan (camera vs upload).
• Offline: foto diantrekan di edge agent (SQLite + folder lokal) lalu diunggah ulang saat koneksi pulih, dengan deduplikasi berbasis checksum.

9. Mesin SPC

9.1 Klasifikasi hasil (FUN-009)

Setiap nilai dibandingkan dengan versi spec yang berlaku saat penyimpanan:

Klasifikasi dijalankan di Edge Function saat insert — bukan di klien — agar tidak dapat dimanipulasi dari browser, dan agar hasil konsisten bila ada entry dari sumber lain (API, impor).

9.2 Statistik kemampuan proses

• Cp / Cpk dihitung per parameter per jendela waktu (default 30 hari terakhir atau 25 subgroup terakhir): Cpk = min((USL − x̄), (x̄ − LSL)) / 3σ.
• Pp / Ppk untuk variasi keseluruhan (long-term).
• Control chart: I-MR untuk pengukuran tunggal per pengecekan (paling umum di lini es krim — satu sampel per interval), X̄-R bila data dikelompokkan per shift/batch.
• Aturan alert (opsional, dapat diaktifkan QA): 1 titik di luar 3σ; 7 titik berurutan pada satu sisi mean; 6 titik naik/turun berurutan. Ini aturan SPC klasik yang dapat dihitung deterministik — bukan analitik prediktif, jadi tetap dalam lingkup URS.

9.3 Alert deviasi (FUN-010)

Saat status oos:

1. Baris deviations dibuat otomatis (status=open).
2. Edge Function mengirim notifikasi berisi: parameter, nilai, LSL/USL, line, produk, batch/lot, timestamp, dan tautan langsung ke record.
3. Kanal: in-app (wajib) + email ke daftar penerima (wajib) + WhatsApp Business API (opsional, biaya terpisah).
4. Eskalasi opsional: bila belum ditangani dalam X menit, naik ke supervisor QA.

Untuk mencegah banjir notifikasi saat satu batch bermasalah berulang, alert dikelompokkan per (batch, parameter) dengan jendela 15 menit — satu notifikasi dengan hitungan, bukan 20 notifikasi terpisah.

10. Dashboard dan Pelaporan

10.1 Dashboard live (FUN-011, FUN-012, FUN-013)

Filter global: rentang tanggal/jam, line, produk, batch/lot, parameter, status. Semua filter tersimpan di URL sehingga sebuah tampilan dashboard dapat dibagikan sebagai tautan.

10.2 Laporan (FUN-015)

Semua ekspor memuat ID record, nilai, limit, status, timestamp, dan identitas pencatat — memenuhi kriteria FUN-015. Ekspor dijalankan sebagai job untuk data besar, dengan tautan unduhan berumur terbatas.

10.3 UX untuk lingkungan produksi

Ini bagian yang sering diabaikan dan menjadi penyebab adopsi gagal:

• Tombol aksi minimal 56×56 px, angka input 24pt+, kontras tinggi.
• Alur entry maksimal 3 layar: pilih batch → ukur → simpan.
• Kerja dengan sarung tangan: tanpa gesture geser, tanpa menu tersembunyi.
• Tablet di area freezer memerlukan perangkat rated suhu rendah — spesifikasi perangkat dibahas di bagian 14.
• Umpan balik instan: warna hijau/kuning/merah setelah simpan, plus bunyi pendek untuk OOS.

11. Keamanan, Kepatuhan, dan Non-Functional

11.1 Autentikasi dan otorisasi

• Akun unik per operator (SEC-001), tanpa akun bersama.
• Kiosk bersama memakai login PIN 6 digit yang dipetakan ke akun individual — memenuhi "unique accounts" tanpa memaksa operator mengetik password panjang di lantai produksi. PIN disimpan sebagai hash, dicabut otomatis bila tidak dipakai 90 hari.
• Sesi auto-lock: 15 menit untuk operator, 30 menit untuk QA (dapat dikonfigurasi, SEC-002). Setelah lock, PIN diminta lagi.
• Opsi SSO Entra ID / Microsoft 365 bila IT klien mensyaratkannya — disiapkan sebagai modul, bukan dibangun di fase 1 kecuali diminta.
• RLS membatasi operator pada line yang ditugaskan; QA dan admin lintas line.

11.2 Backup dan pemulihan (NFR-004)

Uji restore dilakukan per kuartal dan didokumentasikan (siapa, kapan, berapa lama, hasil verifikasi) — inilah bukti yang diminta kriteria NFR-004, bukan sekadar konfigurasi backup.

11.3 Performa (NFR-002)

• Target muat halaman < 5 detik pada koneksi 10 Mbps: bundle awal < 300 KB gzip, code-splitting per modul, gambar lazy-load.
• Freshness dashboard: Realtime Supabase memberi update < 2 detik — jauh di bawah batas 60 detik.
• Uji performa dilakukan dengan profil beban yang disepakati (jumlah record/hari, jumlah pengguna bersamaan).

11.4 Ketersediaan (NFR-003)

• SLA usulan: 99,5% pada jam operasional yang disepakati, dengan maintenance window di luar jam produksi.
• Monitoring: uptime check per 60 detik dari dua lokasi, alert ke tim support.
• Ketahanan offline: edge agent menyimpan entry di SQLite ketika cloud tidak terjangkau dan menyinkronkan otomatis saat pulih. Operator melihat indikator "tersimpan lokal — menunggu sinkronisasi", sehingga data tidak hilang meski internet mati berjam-jam.
• Health check edge agent: bila heartbeat > 5 menit hilang, admin menerima notifikasi.

11.5 Retensi data

Belum ditetapkan di URS (open item). Usulan default: data hasil ukur dan audit disimpan minimal 5 tahun; foto 24 bulan (volume terbesar); setelah itu diarsipkan ke cold storage, bukan dihapus. Angka final menunggu kebijakan QA/Regulatory klien.

12. Rencana Kerja dan Timeline

12.1 Kondisi jadwal saat ini

URS menargetkan launch Nov 2026. Per 27 Oktober 2026, itu berarti tinggal ±4 minggu — tidak realistis untuk lingkup penuh (integrasi timbangan, kamera, audit trail, backup teruji, UAT dua tipe perangkat). Menawarkan tanggal tersebut akan berujung pada go-live yang tidak lolos kriteria penerimaan URS sendiri.

12.2 Baseline yang diusulkan

Total: 13–15 minggu kalender dengan asumsi feedback klien ≤ 3 hari kerja per siklus review.

Rollout yang disarankan bertahap: pilot 1–2 line (4 minggu), evaluasi, lalu perluasan ke seluruh line (2–3 minggu). Rollout bertahap menurunkan risiko dan memberi QA kesempatan menyesuaikan spec limit berdasarkan data nyata.

12.3 Jika klien tetap mengejar tanggal lebih awal

Satu-satunya jalur realistis adalah pilot terbatas: 1 line, parameter timbangan + volume saja, tanpa kamera, tanpa ekspor PDF lanjutan, tanpa WhatsApp alert. Ini bisa live dalam 6–7 minggu. Sisa modul menyusul. Perlu persetujuan tertulis bahwa kriteria penerimaan URS dipenuhi bertahap — bukan sekaligus.

13. Estimasi Biaya

13.1 Acuan anggaran klien

URS mencantumkan capex reference 4,9 kEUR. Dengan kurs EUR/IDR ±Rp 20.200 (per 27 Okt 2026), acuan tersebut setara ±Rp 99 juta.

13.2 Usulan alokasi

Setara ±78 man-days dengan blended rate ±Rp 1,27 juta/man-day. Angka ini adalah estimasi perencanaan, bukan penawaran final; penawaran mengikat disusun setelah P1 Discovery ketika jumlah line, jumlah timbangan, dan kompleksitas laporan sudah pasti.

13.3 Belum termasuk

• Perangkat keras: mini-PC edge agent, tablet industri (rated suhu rendah untuk area freezer), kabel RS-232/USB-serial, mounting kiosk. Perlu quotation terpisah dari vendor hardware.
• Server on-premise bila klien memilih Opsi C.
• WhatsApp Business API (biaya per percakapan).
• Lisensi Windows 11 / kalibrasi timbangan.
• Migrasi data historis dari sistem legacy — belum disebut di URS, perlu dikonfirmasi. Bila ada, estimasi tambahan 1–2 minggu.

13.4 Biaya operasional (indikatif)

Kategori: hosting aplikasi, Supabase (paket berbayar untuk PITR & kapasitas), storage foto, domain, monitoring. Rentang indikatif Rp 700 ribu – 1,5 juta/bulan untuk skala satu pabrik. Harga paket penyedia perlu diverifikasi ulang saat PO — jangan dijadikan angka kontraktual tanpa konfirmasi.

14. Asumsi dan Open Items

14.1 Dari URS (belum terjawab)

14.2 Tambahan dari kami (belum ada di URS)

15. Manajemen Risiko

16. Rencana Prototype (P0)

Prototype dibangun sebelum kontrak pengembangan penuh, untuk mengunci pemahaman bersama dan memberi klien sesuatu yang konkret untuk dinilai.

Lingkup prototype (5–7 hari kerja)

1. Login dengan 3 role + RLS dasar
2. Master data minimal: line, produk, batch, parameter, spec limit
3. Form entry SPC yang responsif (desktop/kiosk + mobile/tablet): berat, volume, catatan
4. Simulasi input timbangan (WebSocket) — menunjukkan alur FUN-006 tanpa hardware
5. Klasifikasi otomatis OK/Warning/OOS terhadap LSL/USL
6. Dashboard: live feed + tren per parameter dengan garis target & limit
7. Laporan: tabel terfilter + ekspor CSV

17. Langkah Selanjutnya

1. Review proposal ini bersama tim — tandai bagian yang perlu disesuaikan dengan realitas internal.
2. Jawab open items di bagian 14, khususnya A (data residency), B (security review), C (jumlah line), F (migrasi data).
3. Jadwalkan kunjungan pabrik — inventaris timbangan, kamera, kiosk, dan kondisi jaringan adalah variabel terbesar yang belum terukur.
4. Setujui prototype sebagai langkah pertama; demo ke stakeholder QA & IT.
5. Susun penawaran mengikat setelah P1 Discovery, dengan jumlah line dan perangkat yang sudah pasti.