Belajar System Analyst - Technical Feasibility & Estimation

#Pendahuluan

Setelah di episode 11 prototype layar kasir memastikan semua pihak melihat solusi yang sama, muncul dua pertanyaan yang menentukan nasib proyek di tangan sponsor: layakkah ini dibangun dan berapa biaya serta waktunya secara realistis. Episode ini membahas studi kelayakan dan seni estimasi.

Mengapa analyst harus terlibat di sini, bukan hanya manajemen? Karena kalian pemilik data terlengkap: hasil process mapping episode 8 memberi angka pemborosan, SDD episode 7 memberi kompleksitas arsitektur, dan prototype episode 11 memberi cakupan fitur yang disepakati. Tanpa kontribusi kalian, keputusan investasi diambil dari tebakan — dan proyek yang lolos dengan feasibility bohong akan mati perlahan setelah anggaran habis.

#Lima Dimensi Kelayakan

Studi kelayakan menimbang proyek pada beberapa sumbu sekaligus:

Praktik penting: kelayakan dinilai terhadap alternatif, bukan terhadap nol. Alternatif TokoKita bukan "tidak ada apa-apa" melainkan: tetap Excel dengan biaya tersembunyinya, belajar POS komersial langganan bulanan, atau hire satu staf konsolidator. Proyek internal kadang kalah lawan SaaS — dan itu temuan sah yang menghemat ratusan juta.

#Kelayakan Teknis: Kasus Offline-First

Untuk TokoKita, risiko teknis terbesar adalah pola offline-first + sinkronisasi multi-cabang. Cara menilainya bukan diskusi filosofis melainkan proof-of-concept berukuran kecil: satu aplikasi kasir sederhana menyimpan transaksi lokal, satu skrip server menerima batch, uji skenario internet putus-sambung.

Skenario 1: 50 transaksi saat offline, sinkron saat pulih
  -> sukses, durasi sync 8 detik, tanpa duplikasi (UUID idempotent)
 
Skenario 2: koneksi putus DI TENGAH upload batch
  -> retry otomatis berhasil; transaksi tidak hilang
 
Skenario 3: dua cabang edit produk sama selama offline
  -> TERDETEKSI: konflik harga; perlu aturan prioritas pusat
  -> keputusan desain: master produk read-only di kasir (DL-03)
 
Kesimpulan: feasible dengan pendekatan antrian pending_sync;
risiko tersisa: jam device (tablet murah) -> uji ketahanan baterai

Perhatikan nilai PoC nomor tiga: konflik yang ditemukan di minggu riset mengubah desain lebih murah daripada ditemukan saat UAT. Inilah esensi kelayakan teknis — membeli kepastian dengan eksperimen murah, bukan dengan optimisme.

#Cost-Benefit Analysis TokoKita

Manfaat dikuantifikasi langsung dari process mapping episode 8 dan data operasional:

Biaya:

Dengan investasi awal Rp 264 jt dan arus kas bersih pasca-go-live Rp 13 jt/bulan:

Payback period = 264 jt / 13 jt per bln ~= 20 bulan
ROI 3 tahun    = (manfaat 540 jt - biaya total 336 jt) / 336 jt
               ~= 61%
Break-even     = sekitar bulan ke-20 dari mulai pengembangan

Angka-angka ini bukan presisi ilmiah — dan itu wajar. Fungsinya adalah kerangka keputusan yang bisa didebat: Pak Budi boleh menantang asumsi shrinkage 1,5%, lalu kita hitung ulang bersama. Keputusan atas asumsi yang terbuka jauh lebih sehat daripada angka pasti-yang-palsu.

#Teknik Estimasi yang Jujur

#Analogi

Bandingkan dengan pekerjaan serupa yang sudah selesai: "modul retur mirip modul penyesuaian stok di proyek X, ambil baseline 8 hari." Murah dan cepat, akurasi bergantung kemiripan nyata — wajib catat penyimpangan.

#Three-Point (PERT)

Tiap item diestimasi tiga kali: optimis (O), paling-mungkin (M), pesimis (P). Ekspektasi dan simpangannya:

E  = (O + 4M + P) / 6        # expected duration
SD = (P - O) / 6             # standar deviasi / ketidakpastian
 
Contoh - modul sinkronisasi offline:
O = 5 hari, M = 10 hari, P = 22 hari
E  = (5 + 40 + 22) / 6  = 11,2 hari
SD = (22 - 5) / 6       = 2,8 hari  <- risiko tinggi!

Nilai SD yang besar adalah sinyal: item ini butuh spike riset lebih dulu, bukan cuma buffer tambahan. Estimasi yang baik mengukur ketidakpastian, bukan menyembunyikannya.

#Bottom-up dari Backlog

Rinci epic menjadi story (episode 5), estimasi per story oleh orang yang mengerjakan, jumlahkan. Ini paling akurat tapi termahal; cocok untuk fase eksekusi, terlalu berat untuk proposal awal. Pola dewasa: analogi untuk proposal, PERT untuk item berisiko, bottom-up untuk sprint.

Tiga hukum yang menjaga estimasi tetap jujur:

1. Estimasi adalah distribusi, bukan janji tunggal — sampaikan "11 hari ± 3", bukan "11 hari". Manajer yang meminta satu angka pasti sedang meminta bohong yang nyaman.
2. Buffer di level proyek, bukan per-item — buffer tersebar per item akan dihabiskan per item (Parkinson's law). Satu cadangan terpusat 15-25% lebih terkendali.
3. Re-estimasi legal — begitu fakta baru datang, revisi openly: "setelah PoC, sinkronisasi naik dari 10 ke 14 hari, berikut kompensasinya..." Kejutan di akhir adalah dosa; koreksi di tengah adalah profesionalisme.

#Praktik: Dokumen Studi Kelayakan Ringkas

Output akhir episode ini satu dokumen 01-brd/feasibility-study.md — padat, angka, siap diputuskan:

# Studi Kelayakan - Sistem POS & Inventori TokoKita
Status: untuk keputusan sponsor | Tanggal: 2026-08-16
 
## Rekomendasi
PROCEED dengan pendekatan bertahap (pilot 1 cabang),
metodologi hybrid sesuai ep.02. Alternatif SaaS komersial
ditolak karena: kebutuhan offline-first tak terpenuhi penuh,
biaya langganan 12 cabang Rp 4,5 jt/bln (Rp 162 jt/3 thn),
dan data member milik vendor.
 
## Temuan per dimensi
Technical   : LAYAK - PoC offline-sync sukses; 1 risiko tersisa
              (ketahanan tablet) -> mitigasi uji lapangan pilot
Operational : LAYAK DENGAN SYARAT - adopsi kasir butuh program
              change management (ep.15); Bu Rina mendukung aktif
Economic    : LAYAK - payback 20 bln; ROI 3 thn 61%;
              asumsi sensitif: shrinkage 1,5% & volume penjualan
Schedule    : PILOT 14 MINGGU - breakdown estimasi terlampir;
              rollout penuh +4 bulan setelah pilot stabil
Compliance  : AMAN - pencatatan pajak standar; PDP dicek ep.19-20
 
## Keputusan yang diminta dari sponsor
D1 Setujui anggaran tahap pilot (dev Rp 95 jt + hw 1 cabang Rp 7 jt)
D2 Tetapkan cabang pilot: Denpasar (volume tertinggi, manajer terkuat)
D3 Sepakati gerbang evaluasi pilot: 2 sprint + kriteria kelulusan

Catatan bagian rekomendasi: alternatif SaaS ikut dihitung dan ditolak dengan alasan — dokumen yang menampilkan opsi gugur lebih kredibel daripada yang hanya membela satu jawaban.

#Kesalahan Umum

1. Feasibility sebagai formalitas — dokumen yang ditulis untuk membenarkan keputusan yang sudah diambil. Kalau kesimpulannya pasti PROCEED apa pun temuan, itu bukan studi kelayakan.
2. Optimism bias & anchoring — angka pertama yang terucap (biasanya milik sponsor) menjadi jangkar semua estimasi berikut. Lawan dengan PERT dan riwayat kalibrasi.
3. Melupakan biaya perpindahan — migrasi data Excel (cleansing 12 file!), training, produktivitas turun 2-3 minggu pertama. Biaya transisi sering 10-15% total proyek dan hampir selalu lupa dihitung.
4. Sunk cost fallacy — "sudah jalan 6 bulan, ya dilanjutkan saja." Kelayakan dievaluasi ulang tiap gerbang milestone; uang yang sudah keluar bukan alasan melanjutkan proyek yang tak layak.

#Penutup

Inti yang dibawa pulang:

• Kelayakan lima dimensi — technical, operational, economic, schedule, compliance — dinilai terhadap alternatif nyata (termasuk SaaS), bukan terhadap kosong.
• Kelayakan teknis dibuktikan lewat PoC murah; konflik yang muncul di eksperimen awal adalah desain yang diselamatkan.
• CBA TokoKita: manfaat Rp 15 jt/bulan dari efisiensi terukur, payback ±20 bulan, ROI 3 tahun ±61% — asumsi terbuka untuk didebat sponsor.
• Estimasi jujur = distribusi (PERT), buffer terpusat, re-estimasi legal, dan riwayat kalibrasi tim.

Proyek sudah layak dan terjadwal — sekarang sistem harus bicara dengan dunia luarnya. Di episode 13 selanjutnya kita membahas system integration analysis: memetakan integrasi TokoKita dengan payment gateway QRIS, sistem akuntansi Mbak Dwi, dan supplier — lengkap dengan kontrak API dan pola pertukaran data. Pastikan tetap semangat!