7.6 Capability Map: Peta Kebutuhan Teknologi Organisasi
Kepala teknologi di perusahaan ritel itu sudah punya pemahaman tentang business model, operating model, dan value stream. Ia tahu bahwa nilai diciptakan dari bagaimana barang sampai ke tangan pelanggan di kota kecil, bagaimana proses pembelian terjadi, dan bagaimana layanan purna jual dijalankan. Tapi ketika ia duduk bersama tim untuk merencanakan teknologi apa yang perlu dibangun, mereka kembali bingung.
“Kita perlu sistem kasir baru,” kata seorang engineer.
“Tapi kita juga perlu aplikasi mobile untuk pelanggan,” timbal yang lain.
“Jangan lupa integrasi dengan logistik,” sambung seorang arsitek.
Semua terdengar penting. Tapi bagaimana cara memutuskan mana yang harus didahulukan? Bagaimana cara melihat apakah semua kebutuhan teknologi sudah tertangkap, atau justru ada yang terlewat?
Di sinilah capability map masuk.
Berikut adalah contoh capability map untuk perusahaan ritel tersebut, yang memisahkan kemampuan bisnis dari solusi teknis.
Capability map adalah peta yang menunjukkan kemampuan apa saja yang dimiliki atau dibutuhkan organisasi untuk menjalankan bisnisnya. Bukan peta aplikasi, bukan peta database, bukan peta cloud provider. Ini peta yang menjawab pertanyaan: apa yang harus bisa dilakukan organisasi ini agar value stream-nya berjalan?
Untuk perusahaan ritel itu, capability map bisa dimulai dari hal-hal mendasar: kemampuan mengelola inventaris, kemampuan memproses pesanan, kemampuan mengelola pengiriman, kemampuan menangani pembayaran, kemampuan melayani pelanggan, kemampuan mengelola data pelanggan, kemampuan mengelola promosi, dan seterusnya. Setiap capability ini bukanlah aplikasi. Ia adalah kemampuan bisnis yang mungkin didukung oleh satu atau beberapa sistem teknologi.
Yang menarik dari capability map adalah ia membuat organisasi melihat teknologi dari sisi kebutuhan, bukan dari sisi solusi yang sudah ada. Ketika tim mulai memetakan capability, mereka sering menemukan hal-hal yang selama ini tidak pernah dianggap sebagai kebutuhan teknologi. Misalnya, kemampuan mengelola relasi dengan pemasok lokal di kota kecil. Atau kemampuan menangani retur barang dari pelanggan yang tidak punya rekening bank. Atau kemampuan memberikan pelatihan kepada kasir yang baru pertama kali menggunakan sistem digital.
Setiap capability yang terpetakan bisa dinilai: seberapa baik organisasi menjalankannya saat ini? Apakah sudah ada sistem yang mendukung? Apakah sistemnya memadai? Apakah ada kesenjangan?
Kesenjangan inilah yang menjadi bahan prioritas. Jika capability “memproses pesanan” saat ini dijalankan secara manual dengan kertas dan telepon, sementara volume pesanan diperkirakan naik sepuluh kali lipat setelah ekspansi, maka jelas ini adalah kesenjangan yang perlu segera diatasi. Sebaliknya, jika capability “mengelola data pelanggan” sudah didukung oleh sistem yang cukup baik, mungkin tidak perlu menjadi prioritas.
Capability map juga membantu arsitek berbicara dengan pemimpin bisnis. Ketika seorang kepala divisi operasi berkata, “Saya butuh sistem baru,” arsitek bisa bertanya, “Capability apa yang ingin ditingkatkan?” Pertanyaan ini menggeser percakapan dari fitur teknis ke kebutuhan bisnis. Dan dari sana, keputusan teknologi menjadi lebih jelas: pilih teknologi yang paling baik mendukung capability yang menjadi prioritas.
Di perusahaan ritel itu, setelah capability map selesai dibuat, tim tidak lagi berdebat tentang database atau microservices. Mereka berdebat tentang capability mana yang paling kritis untuk ekspasi ke kota kecil. Dan dari perdebatan itu, muncullah prioritas yang jelas: kemampuan memproses pesanan dari pelanggan yang tidak terbiasa dengan aplikasi mobile, dan kemampuan mengelola pengiriman ke alamat yang tidak terdaftar secara formal.
Capability map tidak menjawab semua pertanyaan teknis. Tapi ia memberikan pijakan yang kokoh untuk memulai. Setelah peta ini ada, arsitek bisa mulai masuk ke domain yang lebih spesifik: aplikasi apa yang perlu dibangun, data apa yang perlu dikelola, integrasi apa yang perlu disiapkan, infrastruktur seperti apa yang diperlukan, dan bagaimana keamanan harus dirancang. Semua itu akan dibahas di subbab berikutnya, saat kita melihat bagaimana enterprise architecture menjaga agar semua domain ini tetap selaras dengan arah organisasi.