6.6 Memetakan Building Block ke Pengguna, Proses, dan Data

Setelah bisa membedakan keduanya, kita perlu memetakan building block ke konteks yang lebih luas. Sebuah building block tidak pernah berdiri sendiri. Modul persetujuan di aplikasi procurement misalnya, tidak ada artinya tanpa tahu siapa yang memakainya, dalam proses apa dia berjalan, dan data apa yang dihasilkan.

Bayangkan Anda sedang mereview aplikasi procurement yang sudah Anda bongkar menjadi building block. Anda menemukan ada modul persetujuan, modul purchase request, dan modul vendor management. Sekarang Anda perlu menjawab pertanyaan: modul persetujuan ini untuk siapa? Jawabannya mungkin untuk manager departemen. Tapi manager yang mana? Apakah semua manager punya akses? Atau hanya manager dengan level tertentu? Ini pertanyaan yang tidak bisa dijawab hanya dengan melihat kode atau dokumen teknis.

Anda perlu memetakan setiap building block ke empat dimensi: pengguna, proses, data, dan value. Pengguna adalah siapa yang berinteraksi langsung dengan building block itu. Bisa manusia, bisa sistem lain. Proses adalah urutan kegiatan yang menggunakan building block tersebut. Data adalah informasi yang diolah atau dihasilkan. Value adalah hasil yang dirasakan oleh organisasi atau pengguna.

Ambil contoh modul persetujuan tadi. Penggunanya adalah manager departemen dan kepala divisi. Prosesnya adalah alur purchase request: staf membuat permintaan, manager menyetujui atau menolak, kepala divisi melihat status persetujuan. Data yang diolah adalah detail permintaan, jumlah, vendor, dan history persetujuan. Value yang dihasilkan adalah kontrol pengeluaran dan akuntabilitas.

Berikut adalah visualisasi pemetaan building block modul persetujuan ke empat dimensi tersebut.

flowchart TD A[Modul Persetujuan] --> B[Pengguna] A --> C[Proses] A --> D[Data] A --> E[Value] B --> B1[Manager Departemen] B --> B2[Kepala Divisi] C --> C1[Staf buat permintaan] C --> C2[Manager setuju/tolak] C --> C3[Kepala lihat status] D --> D1[Detail permintaan] D --> D2[Jumlah & vendor] D --> D3[History persetujuan] E --> E1[Kontrol pengeluaran] E --> E2[Akuntabilitas]

Sekarang tambahkan satu dimensi lagi: owner. Siapa yang bertanggung jawab jika modul persetujuan ini bermasalah? Bukan hanya tim IT yang mengelola aplikasi, tetapi juga pemilik bisnis yang menentukan kebijakan persetujuan. Tanpa owner yang jelas, building block akan menjadi milik semua orang dan tidak ada yang benar-benar menjaganya.

Pemetaan ini penting karena beberapa alasan. Pertama, saat Anda ingin memodernisasi aplikasi, Anda tahu siapa yang harus diajak bicara. Kedua, saat ada perubahan proses bisnis, Anda bisa melihat building block mana yang terdampak. Ketiga, saat ada masalah, Anda tahu siapa yang harus dilibatkan dalam troubleshooting.

Yang sering terjadi di organisasi adalah building block dipetakan hanya secara teknis. Modul persetujuan dicatat sebagai fitur di aplikasi procurement, tanpa tahu siapa penggunanya dan dalam proses apa dia dipakai. Akibatnya, ketika proses bisnis berubah, tim IT tidak tahu building block mana yang perlu disesuaikan. Atau ketika pengguna pindah peran, akses tidak dicabut karena tidak ada pemetaan pengguna ke building block.

Anda tidak perlu memetakan semua building block sekaligus. Mulai dari yang kritis. Aplikasi dengan criticality tinggi, building block yang sering dipakai, atau modul yang sering menjadi sumber masalah. Satu per satu, Anda akan melihat pola: building block yang sama bisa dipakai di beberapa proses, atau satu proses bisa menggunakan beberapa building block dari aplikasi yang berbeda.

Pemetaan ini juga membantu Anda melihat kesenjangan. Mungkin ada proses yang berjalan manual karena tidak ada building block yang mendukungnya. Atau ada building block yang dipakai oleh banyak proses tetapi tidak ada owner yang jelas. Atau ada data yang dihasilkan oleh satu building block tetapi tidak pernah dipakai oleh building block lain.

Setelah pemetaan ini selesai, Anda tidak hanya punya daftar building block, tetapi juga peta keterkaitan. Anda tahu modul persetujuan procurement dipakai oleh manager, mengalir dalam proses purchase request, menghasilkan data persetujuan history, dan di-owner oleh kepala procurement. Anda siap untuk langkah berikutnya: melihat capability organisasi secara utuh.