8.3 Gap Analysis: Apa yang Hilang dan Lemah

Setelah dua titik ini jelas, kita perlu mencari celah antara keduanya. Kepala teknologi perusahaan logistik itu sudah punya target architecture yang cukup gamblang: data dari semua sistem operasional harus bisa mengalir ke satu platform analitik, setiap keputusan operasional harus didukung data real-time, dan laporan untuk direksi tidak perlu lagi menunggu tiga hari. Ia juga sudah memetakan current state-nya: data tersebar di delapan aplikasi warisan, tiga di antaranya tidak punya API, laporan masih diketik manual di Excel, dan tim IT menghabiskan 60 persen waktunya untuk memadamkan masalah sistem lama.

Sekarang ia harus menjawab pertanyaan paling tidak nyaman: apa yang hilang dan lemah?

Gap analysis bukanlah latihan akademik untuk menghasilkan dokumen tebal yang disimpan di server. Ia adalah proses mengidentifikasi dengan jujur apa yang tidak dimiliki organisasi saat ini untuk mencapai target capability-nya. Dalam kasus perusahaan logistik itu, targetnya adalah keputusan berbasis data. Maka ia harus bertanya: data apa yang belum terkumpul? Sistem mana yang belum terintegrasi? Kapabilitas analitik apa yang belum dimiliki tim? Proses bisnis mana yang masih manual dan tidak menghasilkan data?

Pertanyaan-pertanyaan ini membawa kita pada tiga jenis gap yang paling umum ditemui.

Ketiga jenis gap tersebut dapat divisualisasikan dalam diagram berikut.

flowchart TD CS[Current State] --> CG[Capability Gap] CS --> TG[Technology Gap] CS --> PG[Process Gap] CG --> C1[Tidak ada tim data engineering] CG --> C2[Tidak ada data warehouse] CG --> C3[Tidak ada pipeline data] TG --> T1[Aplikasi warisan tanpa API] TG --> T2[Sistem tidak terintegrasi] TG --> T3[Data tersebar di 8 aplikasi] PG --> P1[Laporan manual di Excel] PG --> P2[Butuh 3 hari per laporan] PG --> P3[60% waktu untuk pemadaman] C1 & C2 & C3 --> TA[Target Architecture] T1 & T2 & T3 --> TA P1 & P2 & P3 --> TA TA --> D[Keputusan berbasis data real-time]

Pertama, capability gap. Ini adalah kemampuan yang belum dimiliki organisasi sama sekali. Misalnya, perusahaan logistik itu tidak punya tim data engineering. Data mentah dari sistem operasional memang ada, tetapi tidak ada yang bisa membersihkan, mentransformasi, dan menyimpannya di tempat yang bisa diakses untuk analisis. Tidak ada jalur pemrosesan data. Tidak ada data warehouse. Tidak ada orang yang mengerti cara membangunnya. Ini gap yang jelas dan besar.

Kedua, technical debt. Ini adalah kondisi di mana sesuatu memang sudah ada, tetapi dalam keadaan yang menghambat. Aplikasi warisan yang tidak punya API adalah contoh klasik. Secara teknis aplikasi itu berfungsi, tetapi ia menjadi penghalang untuk integrasi. Untuk mencapai target architecture, organisasi harus mengeluarkan biaya lebih besar untuk merawat atau menggantinya. Technical debt tidak selalu terlihat dari luar. Sering kali ia baru terasa saat tim mencoba menambahkan fitur baru atau menghubungkan sistem.

Ketiga, gap yang mahal dan lambat. Ini adalah kondisi di mana sesuatu ada dan berfungsi, tetapi biaya operasionalnya terlalu tinggi atau kecepatannya tidak memadai. Misalnya, perusahaan logistik itu mungkin sudah memiliki sistem pelaporan, tetapi butuh tiga hari untuk menghasilkan satu laporan. Secara capability, sistem itu ada. Secara kecepatan, ia gagal memenuhi kebutuhan bisnis. Gap jenis ini sering luput dari perhatian karena secara fungsional sistem masih berjalan. Padahal, kelambatan adalah gap yang nyata.

Setelah gap-gap ini teridentifikasi, organisasi perlu menilai mana yang paling mendesak untuk ditangani. Tidak semua gap harus ditutup sekaligus. Prioritas muncul dari pertanyaan: gap mana yang paling menghambat pencapaian target capability? Dalam kasus perusahaan logistik, ketiadaan jalur pemrosesan data adalah hambatan paling fundamental. Tanpa itu, tidak ada data yang bisa dianalisis. Sementara technical debt pada aplikasi warisan bisa dimitigasi sementara dengan pendekatan lain, misalnya menambahkan lapisan middleware.

Gap analysis yang baik menghasilkan dua hal: daftar celah yang jujur dan pemahaman tentang mana yang harus ditangani lebih dulu. Ia bukan alat untuk menyalahkan masa lalu, melainkan peta untuk memutuskan langkah selanjutnya. Setelah celah-celah ini terlihat, kita bisa mulai menyusun urutan perubahan yang akan menutupnya satu per satu.