Siapa Saja yang Terdampak

9.3 Siapa Saja yang Terdampak

Dengan outcome yang jelas, kita perlu tahu siapa saja yang terlibat dan terdampak oleh solusi ini. Ini bukan pertanyaan sepele. Saya pernah melihat satu inisiatif penggantian sistem CRM berjalan enam bulan, lalu tiba-tiba dihentikan karena tim compliance baru tahu bahwa data pelanggan akan dipindahkan ke server baru yang belum tersertifikasi. Enam bulan kerja, enam bulan biaya, enam bulan harapan yang kandas hanya karena satu fungsi tidak dilibatkan sejak awal.

Kesalahan seperti ini terjadi karena kita mengira stakeholder solusi hanya pengguna dan pemilik bisnis. Padahal dalam organisasi modern, hampir tidak ada inisiatif yang berdiri sendiri. Setiap solusi menyentuh sistem lain, data orang lain, proses yang sudah berjalan, dan aturan yang harus dipatuhi.

Mari kita bedah siapa saja yang perlu diidentifikasi.

Pertama, user dan owner bisnis. User adalah orang yang akan memakai solusi ini sehari-hari. Mereka tahu di mana sepatu menjepit, alur kerja mana yang bikin frustrasi, dan workaround apa yang terpaksa mereka lakukan. Owner bisnis adalah pihak yang bertanggung jawab terhadap outcome. Mereka yang akan menjawab pertanyaan: apakah masalah ini memang penting? Apakah solusi ini memberikan nilai yang diharapkan? Tanpa keduanya, solusi berjalan tanpa arah dan tanpa validasi.

Kedua, engineer dan operation. Engineer yang akan membangun solusi ini perlu tahu konteksnya, bukan hanya spesifikasi teknis. Mereka perlu memahami mengapa keputusan tertentu diambil, agar ketika menemui hambatan teknis, mereka bisa memilih alternatif yang tetap selaras dengan tujuan. Operation adalah tim yang akan menjalankan solusi setelah live. Jika mereka tidak dilibatkan sejak awal, bisa jadi solusi yang dibangun tidak cocok dengan ritme operasional yang ada.

Ketiga, security, data, dan compliance. Ini adalah fungsi yang sering dianggap sebagai penghambat, padahal mereka adalah pelindung. Security memastikan solusi tidak membuka celah yang bisa dieksploitasi. Data memastikan data yang digunakan tersedia, bersih, dan tidak melanggar kebijakan. Compliance memastikan solusi tidak melanggar regulasi yang berlaku. Melibatkan mereka sejak awal bukan untuk memperlambat, tetapi untuk menghindari temuan di akhir yang memaksa ulang desain.

Keempat, support dan fungsi terkait. Support adalah tim yang akan menangani pertanyaan dan masalah setelah solusi berjalan. Mereka perlu tahu apa yang berubah, bagaimana cara kerja baru, dan apa yang harus dilakukan jika ada yang tidak beres. Fungsi terkait adalah bagian lain yang mungkin terdampak secara tidak langsung. Misalnya, inisiatif yang mengubah alur pengajuan pembelian pasti akan menyentuh tim procurement, meskipun mereka bukan target utama.

Setiap stakeholder punya peran dalam mendefinisikan scope. User dan owner bisnis menentukan apa yang penting. Engineer dan operation menentukan apa yang feasible. Security, data, dan compliance menentukan apa yang boleh. Support dan fungsi terkait menentukan apa yang perlu diantisipasi. Solution architect bukanlah orang yang paling tahu segalanya. Ia adalah orang yang tahu siapa yang perlu diajak bicara.

Tabel berikut merangkum peran dan kepentingan masing-masing stakeholder agar mudah dijadikan acuan saat memulai inisiatif baru.

Berikut diagram yang merangkum hubungan dan pengaruh antar stakeholder dalam mendefinisikan scope solusi.

Dengan daftar stakeholder yang jelas, langkah selanjutnya adalah memahami keadaan sekarang. Kita perlu tahu proses apa yang berjalan saat ini, sistem apa yang terlibat, dan titik sakit apa yang membuat inisiatif ini perlu dijalankan. Tanpa pemahaman itu, kita hanya membangun solusi di atas asumsi.