9.5 Keadaan yang Dituju: Perubahan yang Ingin Terjadi
Dari keadaan sekarang, kita bisa membayangkan keadaan yang diinginkan setelah solusi berjalan. Ini bukan sekadar daftar fitur atau tampilan layar yang lebih cantik. Target state adalah gambaran konkret tentang bagaimana proses, aplikasi, data, dan integrasi akan berubah setelah solusi diterapkan.
Saya pernah mendampingi tim yang sedang membangun sistem pengajuan kredit baru. Waktu saya tanya apa yang ingin dicapai, mereka menjawab, “Kami ingin proses pengajuan lebih cepat.” Itu terlalu abstrak. Lebih cepat bagaimana? Dari tiga minggu menjadi tiga hari? Atau dari tiga hari menjadi tiga jam? Tanpa target yang jelas, tim akan kesulitan memutuskan apakah solusi yang mereka rancang sudah cukup baik atau masih perlu perbaikan.
Target state yang baik menjawab empat dimensi perubahan. Pertama, perubahan proses. Hari ini seorang customer service harus mengetik ulang data dari formulir cetak ke sistem. Di target state, data masuk otomatis lewat portal digital dan customer service hanya perlu memverifikasi. Kedua, perubahan aplikasi. Mungkin ada aplikasi lama yang perlu diubah, aplikasi baru yang perlu dibangun, atau aplikasi existing yang perlu diintegrasikan. Ketiga, perubahan data. Format data mungkin perlu diseragamkan, data yang tadinya tersebar di spreadsheet perlu dipusatkan, atau data historis perlu dimigrasi. Keempat, perubahan integrasi. Sistem yang tadinya berjalan sendiri-sendiri perlu saling berbicara, atau alur data yang tadinya manual perlu menjadi otomatis.
Perbedaan antara current state dan target state inilah yang menjadi dasar perancangan solusi. Semakin jelas perbedaannya, semakin mudah tim menentukan apa yang perlu dikerjakan. Saya biasa meminta tim menuliskan perbandingan dalam bentuk tabel sederhana: di sisi kiri keadaan sekarang, di sisi kanan keadaan yang dituju. Misalnya, hari ini data pelanggan diinput tiga kali di tiga sistem berbeda. Targetnya, data cukup diinput sekali dan otomatis tersebar ke sistem lain. Atau hari ini laporan mingguan dibuat manual dengan copy-paste dari tiga sumber. Targetnya, laporan tergenerate otomatis setiap Senin pagi.
Yang perlu diingat, target state bukanlah solusi teknis yang sudah detail. Ini bukan tentang memilih database, framework, atau cloud provider. Ini tentang menjawab pertanyaan: seperti apa keadaan setelah masalah selesai? Dengan jawaban itu, tim punya arah yang jelas sebelum mulai merancang arsitektur.
Berikut contoh tabel perbandingan yang bisa digunakan sebagai template.
| Dimensi | Current State | Target State |
|------------|----------------------------------------------------|---------------------------------------------------|
| Proses | CS mengetik ulang data dari formulir cetak | Data masuk otomatis via portal digital, CS verifikasi |
| Aplikasi | Aplikasi lama monolitik | Aplikasi baru modular dengan API |
| Data | Data tersebar di spreadsheet | Data terpusat di database |
| Integrasi | Manual, file CSV | API real-time, event-driven |
Tabel ini bisa langsung diisi sesuai konteks proyek masing-masing.
Sebagai gambaran, berikut diagram yang membandingkan keadaan sekarang dan keadaan yang dituju dalam empat dimensi perubahan.
Target state juga membantu menjaga fokus. Ketika nanti muncul ide-ide baru yang menarik, tim bisa bertanya: apakah perubahan ini membawa kita lebih dekat ke target state? Jika tidak, mungkin ide itu perlu ditunda atau masuk ke inisiatif lain. Tanpa target state, setiap ide baru terdengar masuk akal dan tim mudah tersesat.
Setelah target state tergambar, langkah berikutnya adalah menentukan batas solusi. Tidak semua perubahan bisa dilakukan sekaligus. Ada yang masuk dalam lingkup inisiatif ini, ada yang tidak. Ada asumsi yang perlu dipegang, ada ketergantungan yang perlu dikelola. Itu menjadi fokus subbab selanjutnya: bagaimana memastikan solusi tetap fokus dengan menentukan in-scope, out-of-scope, dan asumsi yang melingkupinya.