Forward Deployed Engineer: Ketika Insinyur Ikut Tinggal, Bukan Sekadar Mengirim ProposalForward Deployed Engineer: Ketika Insinyur Ikut Tinggal, Bukan Sekadar Mengirim Proposal

Ada satu momen yang berulang di hampir setiap proyek sistem yang gagal dipakai. Konsultan datang, mewawancarai beberapa orang, menulis laporan tebal berisi rekomendasi, lalu pergi. Beberapa bulan kemudian, sistem yang direkomendasikan itu memang jadi, tapi dibangun oleh vendor lain yang tidak pernah membaca laporan itu secara utuh, dan hasilnya tidak benar-benar cocok dengan cara kerja tim yang harus memakainya setiap hari. Semua pihak sudah bekerja keras. Tidak ada yang salah secara teknis. Tapi sistemnya tetap tidak dipakai, atau dipakai setengah hati, karena tidak ada satu orang pun yang tinggal cukup lama untuk memastikan sistem itu benar-benar pas.

Ini bukan cerita tentang konsultan yang malas atau vendor yang tidak kompeten. Ini soal model kerja yang keliru sejak awal: memisahkan orang yang merancang dari orang yang membangun, dan memisahkan keduanya dari orang yang setiap hari memakai hasilnya. Ada satu pendekatan yang lahir justru untuk menutup celah ini, dan namanya forward deployed engineer.

Insinyur yang Tinggal, Bukan yang Mengirim Proposal

Istilah forward deployed engineer dipopulerkan oleh Palantir, perusahaan teknologi yang membangun sistem data untuk klien dengan kebutuhan sangat spesifik, mulai dari militer sampai rumah sakit. Alih-alih menjual produk jadi yang harus disesuaikan klien, Palantir mengirim insinyurnya untuk duduk langsung di tempat klien bekerja. Insinyur itu belajar alur kerja yang sesungguhnya, ikut rapat operasional, melihat sendiri di mana proses macet, lalu membangun dan mengubah sistemnya di tempat, berulang kali, sampai benar-benar terpakai.

Bedanya dengan model konsultasi biasa cukup sederhana. Konsultan biasa datang, menganalisis, lalu menyerahkan rekomendasi kepada pihak lain untuk membangunnya. Vendor software biasa menjual platform yang sudah jadi, lalu klien yang harus menyesuaikan cara kerjanya dengan platform itu. Forward deployed engineer melakukan ketiganya sekaligus: analisis, pembangunan, dan penyesuaian, dikerjakan oleh orang yang sama, di tempat yang sama, selama proyek berjalan.

Kami memakai pendekatan ini justru karena dua kebutuhan yang sedang kami dampingi hari ini punya masalah yang sama persis: sistem manajemen pengetahuan yang dibutuhkan pemerintah, dan sistem manajemen pengetahuan yang dibutuhkan organisasi yang sedang bertumbuh cepat. Dua situasi ini kelihatannya sangat berbeda, tapi akar masalahnya kembar.

Situasi Pertama: Instansi Pemerintah dan Indikator 26 SPBE

Peraturan Presiden No. 95/2018 tentang SPBE mewajibkan setiap instansi pemerintah menjalankan manajemen pengetahuan, dan kinerjanya dinilai setiap tahun lewat Indikator 26 dari 47 indikator Indeks SPBE Nasional. Instansi boleh membangun sistemnya sendiri, asal terintegrasi dengan sistem nasional bernama SIMPAN.

Masalahnya, dua jenis pihak yang biasa dipanggil untuk mengerjakan ini punya keterbatasan yang sama. Vendor software generik bisa membangun sistemnya dengan cepat, tapi mereka tidak paham SOP internal instansi, tidak tahu siapa sebenarnya pemegang pengetahuan kritis, dan tidak tinggal cukup lama untuk melihat apakah sistemnya benar-benar dipakai atau cuma jadi pajangan menjelang audit tahunan. Konsultan strategi di sisi lain bisa merumuskan kerangka kematangan dan struktur peran dengan baik, tapi mereka tidak membangun sistemnya sendiri, jadi rekomendasi itu berhenti di dokumen.

Forward deployed engineer mengisi celah di antara keduanya. Insinyur kami duduk di instansi, ikut memahami bagaimana pegawai sehari-hari mencatat, menyimpan, dan mencari informasi, lalu membangun sistemnya langsung di sana. Kalau ternyata struktur yang dirancang minggu pertama tidak cocok dengan cara kerja bagian tertentu, sistemnya diubah minggu itu juga, bukan menunggu kontrak fase dua. Yang paling penting, pendekatan ini langsung menjawab risiko yang disebut sendiri oleh Badan Riset dan Inovasi Nasional dalam pedomannya: hilangnya pengetahuan akibat pegawai yang mutasi atau pensiun. Insinyur yang tinggal di tempat bisa langsung menangkap pengetahuan itu dari orangnya, bukan dari dokumen serah terima yang sering ditulis terburu-buru di hari terakhir kerja.

Situasi Kedua: Organisasi yang Tumbuh Lebih Cepat dari Sistemnya

Situasi kedua muncul di korporasi, BUMN, NGO besar, atau lembaga apa pun yang berkembang cepat. Ciri khasnya selalu sama: makin banyak orang, makin banyak proyek, dan makin banyak sistem yang dipakai secara terpisah, mulai dari intranet, spreadsheet bersama, sampai aplikasi manajemen proyek yang berbeda-beda di tiap divisi. Pengetahuan yang seharusnya jadi satu malah tersebar di tempat yang tidak saling bicara.

Di sini pun ada dua pilihan lama yang sama-sama tidak memuaskan. Membeli platform manajemen pengetahuan atau manajemen proyek yang sudah jadi memang cepat, tapi platform itu kaku dan organisasi harus menyesuaikan cara kerjanya dengan aturan platform, bukan sebaliknya. Membangun sistem custom lewat vendor luar biasanya jauh lebih mahal, dan begitu selesai serah terima, sistem itu berhenti berkembang padahal organisasinya terus berubah.

Forward deployed engineer menawarkan jalan ketiga. Insinyur kami ikut duduk bersama tim, membangun versi pertama sistemnya dalam waktu singkat, lalu tetap terlibat untuk terus menambah dan menyesuaikan fitur seiring organisasi bertumbuh. Sistem manajemen pengetahuan dan alat manajemen proyek yang kami bangun dengan cara ini tidak pernah benar-benar "selesai" dalam arti kaku, karena memang dirancang untuk ikut berubah bentuk mengikuti organisasi yang memakainya. Ini juga jadi fondasi yang jujur kalau organisasi mulai ingin memakai AI atau chatbot internal untuk mencari pengetahuannya sendiri, sebab alat semacam itu hanya akan sebagus arsitektur pengetahuan yang menopangnya.

Kenapa Ini Bukan Sekadar Istilah Baru untuk Hal Lama

Ada yang mungkin bertanya, bukankah ini cuma nama baru untuk pendampingan implementasi yang selama ini sudah ada? Bedanya terletak pada siapa yang mengerjakan apa. Pendampingan implementasi biasa umumnya tetap memisahkan peran perancang dan pembangun, hanya durasi pendampingannya diperpanjang. Forward deployed engineer menyatukan perancangan dan pembangunan dalam satu orang yang sama, yang hadir langsung di lokasi kerja klien, dan yang punya kewenangan untuk mengubah desain begitu ia melihat sendiri desain itu tidak jalan.

Perbedaan kecil ini punya konsekuensi besar. Siklus dari "kami menemukan masalah" sampai "sistemnya sudah diperbaiki" bisa terjadi dalam hari, bukan menunggu putaran kontrak berikutnya. Kepercayaan yang terbangun juga berbeda, karena tim klien melihat sendiri orang yang membangun sistem itu duduk di ruangan yang sama, mengalami friksi yang sama, dan ikut bertanggung jawab kalau sesuatu tidak berjalan.

Baik untuk instansi yang mengejar target Indikator 26 maupun organisasi yang sistemnya sudah kalah cepat dari pertumbuhannya sendiri, pertanyaan yang perlu dijawab bukan lagi soal membeli platform atau menyewa konsultan. Pertanyaannya adalah apakah ada orang yang bersedia tinggal cukup lama untuk memastikan sistemnya benar-benar dipakai. Itulah yang sebenarnya kami tawarkan lewat pendekatan ini.