Geospatial Product Ops: Di Antara Peta dan Bisnis

#Apa itu Geospatial Product Ops?

Geospatial Product Ops adalah pekerjaan mengubah masalah operasional menjadi solusi spasial yang benar-benar dipakai orang. Selama delapan tahun di Grab, saya mengerjakannya dari posisi di antara data peta, produk, dan bisnis: memastikan peta di balik setiap pemesanan cukup baik bagi pengemudi dan penumpang, sekaligus cukup berguna bagi bisnis yang bergantung padanya.

Secara resmi, tim saya bernama Map and Product Operations. Kami memegang tiga area: points of interest (POI), routing dan navigasi, serta perangkat IoT yang memasok data untuk pembuatan peta. Rekan kerja harian kami adalah product manager, engineer, tim transport dan business operations, partner B2B, serta tim product marketing.

#Kenapa saya tidak memakai jabatan resmi saya?

"Map operations" terdengar seperti orang yang mengedit titik di peta. Sebagian pekerjaannya memang begitu, terutama di tahun-tahun awal. Tetapi sebagian besar pekerjaan saya kemudian menyentuh apa pun yang punya lokasi: dataset geospasial berukuran besar di data lake, dashcam dan kamera 360° yang dipasang di kendaraan mitra untuk mengumpulkan citra jalan, geofence yang menentukan layanan mana berjalan di mana, dan fitur-fitur yang dibangun di atas GrabMaps.

Karena itu saya menyebutnya Geospatial Product Ops. Geospatial karena bahan mentahnya selalu data lokasi. Product karena hasilnya selalu berupa fitur, atau keputusan yang mengubah perilaku produk. Ops karena semuanya tidak berarti kalau tidak berjalan setiap hari, di setiap kota, tanpa perlu ditunggui.

Latar belakang saya menjelaskan kenapa sisi teknisnya terasa alami. Saya kuliah Sains Informasi Geografi di Universitas Gadjah Mada, dengan minor statistik dan pemrograman, jadi data spasial sudah menjadi bahasa yang saya kuasai sejak pertama bergabung.

#Apa yang terjadi kalau setiap tim menginginkan hal yang berbeda?

Satu peluncuran menggambarkan peran ini lebih baik daripada deskripsi pekerjaan mana pun. Saat itu kami sedang menghadirkan navigasi indoor di sebuah bandara: fitur yang memandu penumpang dari dalam terminal ke titik jemput yang tepat.

Setiap tim di meja punya tujuan yang masuk akal, dan semuanya menarik ke arah yang berbeda:

• Product dan atasan saya ingin seluruh bandara selesai dipetakan pada tanggal yang sudah ditetapkan.
• Tim business development bandara masih bernegosiasi dengan pengelola bandara. Area bea cukai dan imigrasi tidak boleh dipetakan; hanya area publik yang boleh.
• Tool milik engineering untuk mengubah hasil kerja QGIS kami ke format indoor masih belum stabil, dan belum ada prosedur yang disepakati untuk memasukkan data lapangan ke dalamnya.
• Tim campaign butuh slot di layar pemesanan untuk mendorong adopsi, tetapi slot itu sudah diantre promo lain yang prioritasnya lebih tinggi.

Tidak satu pun dari masalah ini adalah masalah peta dalam arti sempit. Tugas saya adalah mengubahnya menjadi rencana yang bisa dirilis. Kami membatasi pemetaan hanya di area publik, sehingga negosiasi bisnis tidak lagi menghambat pekerjaan data. Kami menyepakati prosedur input dengan engineering, sehingga data yang dikumpulkan tidak lagi merusak tool konversi. Kami juga menegosiasikan penempatan berbasis geofence, sehingga fitur hanya muncul bagi orang yang secara fisik berada di bandara. Dengan cara itu, fitur ini menyesuaikan diri dengan antrean promo alih-alih berebut dengannya.

Pola itu berulang di hampir setiap peluncuran. Petanya justru bagian yang mudah. Pekerjaan sebenarnya adalah membuat lima tim sepakat tentang arti "selesai".

#Apa saja cakupan peran ini?

Cara paling jelas untuk menggambarkan cakupannya adalah sebagai sebuah siklus. Baca diagram searah jarum jam dari atas: data masuk, diperiksa, dirilis, diukur, dan apa yang kami pelajari kembali ke titik awal.

Buka ukuran penuh

1. Collect and enrich. Merencanakan pengumpulan dan pengayaan data POI, jalan, dan citra jalan, serta menentukan ke mana tim lapangan dan vendor harus pergi lebih dulu.
2. Validate. Memeriksa geometri dan atribut, dengan aturan validasi yang menangkap kesalahan sebelum sampai ke aplikasi.
3. Deploy IoT. Menjalankan operasional dashcam dan kamera 360° di kendaraan armada dan mitra pengemudi: pemasangan, pelatihan, dan memastikan data yang kembali bisa dipakai.
4. Launch. Merilis fitur peta dan mendukung eksperimen. Product manager dan data scientist yang merancang eksperimennya; tim saya mengusulkan area treatment, memantau guardrail metrics selama pengujian, dan menggali alasan di balik angka sebelum keputusan peluncuran diambil.
5. Measure and automate. BI, analisis, dan otomasi, bagian yang saya anggap sebagai keahlian saya sendiri.
6. Feed back. Mengubah temuan menjadi usulan untuk product dan engineering, yang memulai siklus berikutnya.

Focus group sering menjadi titik awal siklus berikutnya. Merchant bercerita bahwa memindahkan lokasi penjemputan berarti proses persetujuan yang lambat, padahal usaha mereka sudah buka dan kehilangan pesanan. Dari situ muncul alasan kuat untuk membiarkan pemilik usaha mengoreksi lokasinya sendiri. Mitra pengemudi menyampaikan dua hal: GPS yang tertinggal di sebagian ponsel membuat mereka terlihat diam padahal sudah bergerak, dan melaporkan jalan yang ditutup atau rusak berarti harus keluar dari peta dan mengisi formulir dukungan terpisah. Pelaporan jalan kemudian dipindahkan ke dalam GrabMaps itu sendiri.

#Apa yang membuatnya menjadi peran teknis?

Daftar tool tidak membuat sebuah peran menjadi teknis. QGIS, Databricks, spreadsheet, Google Apps Script, Superset, dan tool internal semuanya bagian dari keseharian. Ujian yang sebenarnya lebih sederhana: apakah keputusan itu bisa diambil tanpa orang yang mampu membaca datanya langsung? Untuk sebagian besar pekerjaan saya, jawabannya tidak.

Menemukan titik buta di area padat. Beberapa lingkungan punya banyak POI di peta, tetapi tetap menghasilkan feedback bahwa sebuah tempat tidak bisa ditemukan. Mengirim surveyor ke semua tempat akan membuang anggaran vendor. Sebagai gantinya, kami menggabungkan kepadatan POI dengan feedback "tempat tidak ditemukan" di level geohash terkecil, lalu mengirim tim lapangan hanya ke sel yang kedua datanya bertentangan, lengkap dengan daftar jenis POI yang belum ada di sana.

-- Simplified illustration (not production code):
-- geohash cells that look well covered but still generate "place not found" feedback
with density as (
  select geohash7, count(*) as poi_count
  from pois
  group by geohash7
),
feedback as (
  select geohash7, count(*) as not_found_reports
  from user_feedback
  where feedback_type = 'place_not_found'
  group by geohash7
)
select d.geohash7, d.poi_count, f.not_found_reports
from density d
join feedback f using (geohash7)
where d.poi_count >= 50          -- looks well covered
  and f.not_found_reports >= 10  -- but people still can't find places
order by f.not_found_reports desc;

Memilih lokasi berikutnya untuk loker IoT. Dengan 200+ loker makanan yang beroperasi di Jakarta, pertanyaan berikutnya adalah ke mana ekspansi dilakukan. GMV saja hanya menunjuk ke kota-kota yang sudah jelas. Menggabungkannya dengan volume pemesanan dan ketersediaan merchant, dengan ambang batas yang disepakati di awal, menghasilkan shortlist kandidat lokasi yang benar-benar sanggup menopang sebuah loker.

Mengubah ide campaign menjadi poligon yang siap dipakai. Tim campaign ingin promo transport dengan harga berbeda berdasarkan jenis POI dan jam: sekolah pukul 7 pagi tidak sama dengan mal pukul 7 malam. Lokasinya terlalu banyak untuk digambar manual, jadi saya membangun model spasial yang mengklasifikasikan dan mengelompokkan POI menjadi poligon yang siap dimuat ke tool konfigurasi internal kami.

Otomasi yang paling saya banggakan justru yang paling tidak glamor. Jam kerja proyek, kehadiran, skor kualitas, dan jam yang belum tercatat tersebar di banyak spreadsheet. Saya membangun pipeline Google Apps Script yang menyatukannya menjadi satu dashboard terstruktur, dengan trigger yang memberi peringatan ke tim ops atau lead mereka ketika jam kerja tidak dicatat dengan benar, atau ketika sebuah proyek butuh perbaikan kualitas yang belum dikerjakan.

#Bagaimana peran ini berubah selama 8 tahun?

Saat saya bergabung pada 2018, pekerjaannya sebagian besar operasional: mengumpulkan POI, memelihara data jalan, dan menjaga kualitas data. Itu berubah ketika GrabMaps menjadi peta milik Grab sendiri. Pada 2023, Grab melaporkan bahwa GrabMaps telah menjalankan layanannya di kedelapan negara tempat Grab beroperasi. Begitu petanya milik kami, setiap perbaikan menjadi tanggung jawab kami untuk dirilis, dan tanggung jawab kami juga ketika ada yang salah.

Buka ukuran penuh

Ada dua hal yang paling berubah.

Peluncuran. Kami sekarang bisa membangun fitur yang tidak akan pernah bisa dikonfigurasi di peta berlisensi. Mal, bandara, dan stasiun mendapat titik jemput sampai level pintu masuk, sehingga pengemudi dan penumpang bisa saling menemukan tanpa perlu menelepon. Bagian sulitnya, mobil dan motor sering butuh titik jemput yang berbeda, dan peralihan di antara keduanya butuh konfigurasi yang tidak membingungkan pengguna. Saran rute bisa berbeda per layanan, lewat tol atau tidak, yang mengubah tarif yang ditampilkan. Navigasi indoor bisa berada di dalam alur pemesanan dan memandu penumpang dari lantai tiga sebuah mal ke pintu keluar yang tepat.

Metrik. Tim saya memantau guardrail metrics di balik fitur-fitur ini: pembatalan yang terkait dengan sebuah POI, seberapa sering pengemudi mengikuti rute yang disarankan, dan apakah pengguna tetap memakai navigasi GrabMaps atau pindah ke aplikasi lain. Route adherence menunjukkan kenapa konteks itu penting. Angkanya memang tidak pernah dimaksudkan mencapai 100%, karena penumpang meminta jalan memutar dan kondisi jalan berubah. Penurunan baru berarti sesuatu setelah kedua faktor itu dikesampingkan.

Kami menjalankan root-cause analysis ke dua arah. Penurunan berarti ada yang perlu diperbaiki. Lonjakan, entah setelah dorongan pengayaan data, sebuah campaign, atau kadang tanpa disengaja, berarti ada yang perlu dipahami lalu ditiru di kota atau layanan lain. Sebagian besar tim hanya menyelidiki kegagalannya. Ternyata menyelidiki keberhasilan sama bergunanya.

	Sebelum: map operations	Sesudah: tech ops
Output utama	Data peta yang dikumpulkan dan dikoreksi	Fitur yang dirilis dan keputusan berbasis data
Pekerjaan data	Spreadsheet dan QGIS	SQL di data lake, BI, otomasi
Ukuran keberhasilan	Volume dan akurasi editan	Guardrail metrics dan adopsi
Paling sering bekerja dengan	Tim ops dan vendor	Product, engineering, bisnis, B2B, marketing
Saat angka bergerak	Perbaiki datanya	Cari akar masalahnya, lalu perbaiki atau tiru

Mulai 2023 cakupannya melebar lagi. Sebagai senior, saya memimpin tim hingga sepuluh orang dan menjalankan beberapa inisiatif secara paralel di Indonesia, Thailand, dan Myanmar, termasuk deployment dashcam dan loker makanan, pengumpulan citra jalan, serta navigasi indoor. Menjelang akhir, pengayaan data semakin banyak berjalan lewat partner dan tool berbantuan AI. Saya tidak membangun teknologinya; bagian saya adalah roadmap operasional dan memastikan datanya memenuhi kualitas yang dibutuhkan sistem-sistem itu.

#Apa benang merah dari semuanya?

Benang merahnya adalah penerjemahan. Engineer melihat bug, bisnis melihat pendapatan yang hilang, penumpang melihat titik jemput yang salah. Sering kali itu masalah yang sama, diceritakan dengan tiga cara. Tugas saya adalah menyadari hal itu, menemukan dari mana masalahnya benar-benar berawal, lalu mengubahnya menjadi sesuatu yang bisa dirilis oleh satu tim.

Beberapa pelajaran yang akan saya bawa ke peran apa pun:

• Baca datanya sendiri. Root-cause analysis tercepat selalu yang tidak perlu saya tunggu dari orang lain.
• Scope adalah alat negosiasi. Membatasi pemetaan bandara hanya di area publik membuka jalan untuk semua hal lainnya.
• Selidiki keberhasilan seserius kegagalan. Lonjakan yang bisa dijelaskan adalah strategi yang bisa diulang.
• Tulis prosedur input sebelum pengumpulan data pertama, bukan setelah tool-nya mulai rusak.

#Ke mana saya membawa ini selanjutnya?

Teknologi lokasi bukan hanya untuk ride-hailing. Logistik, ritel, pertanian, utilitas, dan usaha lokal kecil semuanya mengambil keputusan yang bergantung pada letak sesuatu, dan sebagian besar masih melakukannya tanpa lapisan spasial yang memadai. Itulah sebabnya saya bergerak ke arah cloud data engineering dan solution architecture dengan fokus geospasial: membangun pipeline dan merancang sistem yang memungkinkan organisasi mana pun, dari industri besar sampai usaha kecil, memakai data lokasi seperti yang sudah dipelajari Grab.

Saya sudah memulainya dengan pipeline end-to-end pada data publik taksi NYC, dari data perjalanan mentah sampai analisis spasial tentang di mana pasokan tidak bertemu permintaan: NYC Taxi Supply-Demand Gap. Artikel berikutnya dalam seri ini membahas satu masalah di Grab secara mendalam: bagaimana celah kecil di antara batas layanan berubah menjadi area tanpa layanan sama sekali.

#FAQ

#Apakah Geospatial Product Ops sama dengan GIS?

Tidak. GIS adalah salah satu tool-nya. Geospatial Product Ops memakai data spasial untuk meluncurkan fitur, menjalankan operasional, dan mendukung keputusan bisnis, sehingga posisinya lebih dekat ke product dan operations daripada ke kartografi.

#Apakah peran ini butuh kemampuan coding?

Tidak selalu, tetapi SQL dan sedikit Python mengubah apa yang bisa Anda putuskan sendiri. Tanpa keduanya, setiap pertanyaan harus menunggu di antrean tim lain.

#Apa itu guardrail metric?

Metrik yang tidak boleh memburuk saat Anda memperbaiki metrik utama. Kalau sebuah fitur mengurangi pembatalan tetapi membuat penjemputan lebih lambat, guardrail metric itulah yang menangkapnya.

#Referensi

• Grab to be fully powered by its own mapping technology by Q3 2022, siaran pers Grab, Juni 2022
• Grab Makes World's Most Innovative Companies by Fast Company for 2023, Business Wire, Maret 2023
• NYC Taxi Supply-Demand Analysis, repositori proyek