Belajar System Analyst - Stakeholder Management

#Pendahuluan

Setelah di episode 9 kalian membangun model data TokoKita, kita beralih ke sisi yang menentukan apakah model itu pernah sampai dipakai atau tidak: orang-orang. Episode ini membahas stakeholder management — identifikasi, analisis, rencana komunikasi, dan pengelolaan ekspektasi.

Mengapa topik soft ini masuk series teknis? Karena statistik kegagalan proyek jarang bicara teknologi. Proyek gagal karena sponsor kehilangan minat di tengah jalan, karena dua divisi tidak pernah sepakat, karena user merasa sistemnya dipaksakan kepada mereka. Analyst adalah aktor pertahanan depan semua masalah itu. Kemampuan teknis membawa Anda sampai desain yang benar; kemampuan mengelola stakeholder membawa desain itu sampai diterima.

#Mengidentifikasi Stakeholder

Stakeholder adalah siapa pun yang memengaruhi proyek atau terdampak hasilnya — termasuk yang tidak pernah duduk di rapat. Teknik identifikasi:

1. Brainstorm berjenjang — mulai dari sponsor & owner proyek, tanya "siapa lagi yang terdampak?" secara rekursif.
2. Snowball dari wawancara — tutup tiap interview dengan pertanyaan "siapa lagi yang harus saya temui?"; wawancara Bu Rina (episode 3) melahirkan nama staf gudang.
3. Telusuri aliran proses — peta proses episode 8 memperlihatkan pelaku tiap langkah; setiap lane adalah stakeholder.
4. Cari yang diam — unit yang datanya disentuh sistem tapi tak pernah bicara (keuangan, pajak, IT support toko) sering jalan tikusnya nanti.

Hasilnya dicatat dalam stakeholder register:

ID  Nama              Peran               Kepentingan Utama          Pengaruh
S1  Pak Budi          Owner/sponsor       ROI, kontrol harga pusat   Sangat tinggi
S2  Bu Rina           Manajer cabang      Operasional harian lancar  Tinggi
S3  Sinta & kasir     End-user kasir      Tidak repot, cepat         Sedang (bisu!)
S4  Andi              Staf gudang         Opname tidak makan waktu   Sedang (bisu!)
S5  Mbak Dwi          Akuntan eksternal   Rekap sesuai format pajak  Tinggi (musiman)
S6  Vendor QRIS       Partner integrasi   API stabil, volume naik    Sedang
S7  Tim dev (3 orang) Pelaksana build     Spesifikasi jelas          Tinggi (eksekusi)

Perhatikan kolom terakhir S3-S4: stakeholder bisu — paling terdampak, paling sedikit suara. Mereka wajib mendapat kanal suara eksplisit; adopsi sistem ditentukan oleh mereka, bukan oleh sponsor.

#Analisis Power-Interest

Register memberi daftar; analisis power-interest memberi strategi perlakuan. Plot tiap stakeholder pada dua sumbu: kekuasaan (bisa mengubah keputusan) vs ketertarikan (seberapa peduli):

Posisi bukan permanen — saat fase integrasi QRIS dimulai, vendor naik kuadran; saat rollout mendekati, akuntan pindah ke manage closely. Review grid tiap bulan.

#Rencana Komunikasi

Rencana komunikasi menerjemahkan analisis menjadi ritme konkret:

Prinsip yang menjaga rencana tetap hidup:

1. Satu pesan, bentuk beda-beda — progress sprint yang sama: owner menerima "pilot on-track, go-live 14 Oktober", developer menerima burn-down chart, kasir menerima "mulai bulan depan strukmu berubah begini".
2. Buruk lebih cepat — kabar jejak yang dikabarkan dini adalah informasi; yang disembunyikan adalah pengkhianatan. Credibility dibangun di momen sulit, bukan di momen sukses.
3. Selalu sertakan decision needed — tiap laporan ke sponsor ditutup daftar keputusan yang dibutuhkan + deadline. Laporan tanpa ask akan diabaikan.

#Expectation Management

Ekspektasi adalah kontrak psikologis — dan ia dibentuk sejak percakapan pertama, bukan saat sign-off BRD. Empat teknik inti:

1. Jual masalah, jual trade-off — bukan impian. Saat Pak Budi minta "laporan real-time semua cabang", jawaban analyst bukan "bisa" melainkan: "Bisa. Real-time butuh internet stabil tiap cabang; alternatif near-real-time (delay maksimal 5 menit via sync batch) lebih tahan internet flaky. Saran saya opsi kedua untuk pilot." Pilihan yang tampak, kompromi yang jujur.

2. Tulis ulang lisan menjadi tulisan dalam 24 jam. Kesepakatan verbal di ruangan = rumor; email ringkasan = kesepakatan. Format empat baris: konteks, kesepakatan, yang tidak termasuk, langkah berikut.

3. Kelola scope creep dengan gerbang, bukan tembok. Permintaan baru tidak ditolak mentah-mentah; masukkan ke backlog, tunjukkan apa yang bergeser: "Fitur poin member bisa masuk, dengan konsekuensi go-live pilot mundur 3 minggu atau fitur laporan harian mundur ke rilis kedua. Mana yang Anda pilih?" Keputusan tetap milik sponsor; biaya transparan.

4. Bedakan kepentingan dari posisi. Bu Rina memposisikan diri minta fitur approval manual semua diskon (rasa kontrol); kepentingannya sebenarnya tidak ada pemborosan tak terkontrol. Solusi: ambang otomatis — diskon di bawah 5% bebas, di atasnya butuh kode manajer. Kepentingan terlayani tanpa beban manual.

#Menangani Konflik Antar-Stakeholder

Kasus nyata TokoKita: owner ingin harga hanya diedit dari pusat; Bu Rina ingin fleksibilitas harga cabang saat kompetitor turun harga dadakan. Langkah fasilitasi:

1. Panggil keduanya bersama (jangan jadi kurir antar-kamar).
2. Nyatakan kepentingan masing-masing netral: kontrol konsistensi vs responsivitas pasar.
3. Usulkan opsi dengan konsekuensi: harga pusat penuh / koridor +/-10% / override berjejak wajib alasan.
4. Dokumentasikan keputusan di decision log + komunikasikan ke semua pihak terdampak.

#Praktik: Stakeholder Plan Satu Halaman

Gabungan register, grid, dan rencana komunikasi diringkas jadi satu halaman 06-decision/stakeholder-plan.md — dokumen kerja yang di-update tiap milestone:

# Stakeholder Plan - TokoKita v1.2 (review tiap milestone)
 
## Top 3 relasi prioritas
1. Pak Budi (sponsor) - weekly Thursday 09.00, selalu bawa:
   progress %, risiko top-3, decision needed
2. Bu Rina (manajer pilot) - kanal WA harian fase pilot;
   jadwalkan shadowing 1x/2 minggu
3. Kasir pilot (Sinta) - sesi feedback 15 mnt tiap Jumat;
   catat frustasi verbatim -> backlog usability
 
## Risiko relasi
- R1 Mbak Dwi belum lihat format rekap -> demo draft
  minggu depan SEBELUM development selesai
- R2 Andi (gudang) skeptis app mobile -> libatkan pilih
  device & uji lapangan awal
 
## Aturan main tim
- Semua kesepakatan verbal -> email ringkas <24 jam
- Scope baru -> backlog + tunjuk trade-off, keputusan owner
- Kabar buruk -> dikabarkan hari yang sama

#Kesalahan Umum

1. Menganggap org chart = peta pengaruh — pengaruh nyata sering dipegang asisten lama yang tahu segalanya, atau akuntan keluarga. Petakan pengaruh faktual, bukan jabatan formal.
2. Komunikasi hanya saat ada kabar bagus — sponsor yang kehilangan visibilitas akan mengambil kendali dengan cara yang tidak kalian sukai.
3. Berjanji tanggal tanpa buffer — janji go-live tanpa cadangan mengubah keterlambatan wajar menjadi drama kepercayaan.
4. Menjadikan kasir objek, bukan subjek — "user akan diajarkan" vs "user dilibatkan merancang". Beda satu kata, beda nasib adopsi.

#Penutup

Inti yang harus dibawa pulang:

• Identifikasi stakeholder lewat brainstorm, snowball interview, peta proses, dan pencarian stakeholder bisu; catat dalam register bernomor.
• Grid power-interest menentukan strategi: manage closely, keep satisfied, keep informed, monitor — dan direview berkala karena posisi bergerak.
• Rencana komunikasi konkret: audiens-pesan-kanal-frekuensi-PJ, dengan prinsip satu pesan banyak bentuk dan kabar buruk lebih cepat.
• Ekspektasi dikelola lewat trade-off transparan, konfirmasi tertulis 24 jam, scope creep via gerbang, dan fasilitasi kepentingan-bukan-posisi.

Orang-orang sudah terkelola; sekarang kita bantu mereka melihat sistem sebelum dibangun. Di episode 11 selanjutnya kita membahas prototyping & wireframing: wireframe low-fidelity, mockup, dan klik-able prototype — dipraktikkan merancang layar kasir TokoKita di Figma supaya feedback datang sebelum satu baris kode ditulis. Pastikan tetap semangat!