8.4 Bukan Sekadar Daftar Proyek
Kepala teknologi perusahaan logistik itu sekarang punya daftar panjang hasil gap analysis. Data tidak terintegrasi. Tiga sistem warisan tidak punya API. Tim IT kelelahan memadamkan masalah. Laporan masih manual. Ia bisa saja membuat daftar proyek: “Tahun depan kita kerjakan integrasi sistem A, tahun depannya lagi sistem B, lalu bangun data warehouse, lalu ganti sistem lama.” Itu terdengar rapi. Tapi itu jebakan.
Banyak organisasi jatuh ke dalam pola pikir daftar proyek. Mereka membuat spreadsheet dengan puluhan baris, masing-masing punya nama proyek, timeline, dan pemilik. Lalu mereka mengerjakan satu per satu secara berurutan. Masalahnya, proyek pertama sering mandek karena ternyata bergantung pada proyek lain yang belum dimulai. Atau proyek ketiga selesai, tetapi tidak ada yang siap memakainya karena proses bisnisnya belum berubah. Atau tim mengerjakan proyek kelima, lalu sadar bahwa infrastruktur yang dibutuhkan belum tersedia.
Roadmap arsitektur bukan daftar proyek. Ia adalah urutan perubahan yang membangun capability secara bertahap. Perbedaan ini fundamental. Daftar proyek menjawab “apa yang harus dikerjakan”. Roadmap arsitektur menjawab “perubahan apa yang harus terjadi, dalam urutan apa, agar organisasi makin mampu mencapai target capability-nya”.
Perbedaan ini dapat divisualisasikan dalam diagram berikut.
Mari kita lihat contoh perusahaan logistik tadi. Gap analysis menunjukkan tiga masalah besar: data tersebar, sistem lama tidak terintegrasi, dan tim IT kelelahan. Kalau kita buat daftar proyek, kita mungkin mulai dengan membangun data warehouse. Tapi data warehouse tidak akan berguna jika data dari sistem operasional tidak bisa mengalir masuk. Jadi proyek pertama seharusnya bukan data warehouse, melainkan integrasi data dari sistem yang paling sering dipakai. Setelah itu baru data warehouse. Tapi sebelum integrasi, kita perlu memastikan tim IT punya kapasitas untuk mengerjakan integrasi itu. Artinya, kita mungkin perlu mengurangi beban pemadaman sistem lama terlebih dahulu.
Di sinilah dependency mapping menjadi penting. Kita tidak bisa mengerjakan perubahan secara acak. Setiap perubahan bergantung pada perubahan lain: infrastruktur harus siap sebelum aplikasi baru berjalan, data harus bersih sebelum analitik bisa diandalkan, tim harus punya kapasitas sebelum proyek baru dimulai. Roadmap arsitektur memetakan dependensi ini dan menentukan urutan yang logis.
Selain dependensi, ada faktor readiness. Apakah organisasi siap menerima perubahan ini? Apakah pengguna sudah dilatih? Apakah proses bisnis sudah disesuaikan? Apakah tim teknis punya kompetensi yang diperlukan? Sebuah perubahan bisa secara teknis benar, tetapi gagal karena organisasi belum siap. Roadmap yang baik mempertimbangkan readiness sebagai syarat untuk melangkah ke tahap berikutnya.
Yang paling penting, roadmap arsitektur membangun capability secara bertahap. Setiap tahap harus menghasilkan sesuatu yang bisa dipakai, bukan sekadar komponen teknis yang menunggu tahap lain selesai. Misalnya, tahap pertama perusahaan logistik itu bisa berupa integrasi data dari dua sistem pengiriman utama ke satu dashboard sederhana. Itu sudah punya value: manajer operasi bisa melihat status pengiriman secara real-time. Tahap berikutnya menambahkan sistem ketiga, lalu keempat. Setiap tahap memperluas capability, bukan sekadar mencentang daftar.
Dengan pendekatan ini, roadmap arsitektur menjadi alat navigasi, bukan sekadar jadwal. Ia menunjukkan arah, urutan, dan apa yang harus siap sebelum melangkah. Kepala teknologi itu tidak perlu bertanya “proyek apa yang harus dikerjakan tahun depan?”. Ia perlu bertanya “capability apa yang harus kita bangun pertama, dan apa yang harus siap agar itu bisa terjadi?”.
Pertanyaan itu membawa kita ke dimensi-dimensi yang harus ada dalam roadmap: aplikasi, data, integrasi, infrastruktur, keamanan, dan platform. Masing-masing punya peran dan dependensinya sendiri.