0%
8 min left

Solo Builder, Enterprise Scale — Cerita di Balik TeMan, Project & Timesheet System yang Saya Bangun Sendiri

Solo Builder, Enterprise Scale — Cerita di Balik TeMan, Project & Timesheet System yang Saya Bangun Sendiri
← Kembali ke Blog

Ada satu jenis rapat yang semua orang di proyek besar pasti pernah alami.

Rapat dimulai. Seseorang membuka spreadsheet di layarnya. Orang lain membuka spreadsheet yang berbeda di laptopnya. Angkanya tidak sama. Lima belas menit pertama habis untuk mencari tahu mana yang benar — sebelum rapat bahkan sampai ke agenda sesungguhnya.

Di proyek yang saya kelola, ini bukan kejadian langka. Ini adalah format standar.

Dan di satu titik, saya berhenti dan bertanya: berapa banyak waktu kolektif yang hilang setiap minggu hanya untuk fase ini? Berapa banyak keputusan yang dibuat di atas data yang tidak sinkron? Berapa lama ini sudah terjadi — dan berapa lama lagi kita akan membiarkannya?

Dari pertanyaan-pertanyaan itu lahirlah apa yang sekarang berjalan di teman.telkomdigital.id — sistem yang saya bangun sendiri, atas inisiatif sendiri, untuk proyek yang sudah berusia tiga tahun dan sudah terlalu besar untuk dikelola dengan cara lama.


Skala yang Tidak Pernah Direncanakan

GTP — singkatan dari Government Technology Program — bermula di 2023 sebagai proyek kolaborasi Telkom dan LKPP untuk modernisasi pengadaan pemerintah digital melalui platform INAPROC.

Di atas kertas, ini adalah satu unit di bawah satu divisi di Telkom. Tapi kalau kamu lihat ke dalamnya, gambarannya berbeda.

478 Key Initiative yang sedang berjalan. 473 orang di roster — dari Product Manager, Project Manager, Engineer, Legal, Policy, Partnerships, Keuangan, sampai Helpdesk. Multi-fungsi, multi-disiplin, dengan stakeholder eksternal dari LKPP yang punya ekspektasi dan deadline tersendiri.

Ruang forum GTP penuh peserta lintas fungsi, dengan slide "Got an idea? That's the hard part." di layar utama

Satu forum, ratusan orang, puluhan fungsi berbeda — skala yang sudah lama melampaui kapasitas spreadsheet.

Ini bukan lagi proyek dalam artian konvensional. Ini sudah mirip satu perusahaan kecil — hanya saja ia berjalan di bawah satu atap divisi, dengan semua kompleksitas yang menyertainya tapi tanpa infrastruktur pengelolaan yang sepadan.

Dan selama bertahun-tahun, semua kompleksitas itu dikelola dengan spreadsheet.


Tiga Pain yang Sudah Terlalu Lama Dianggap Normal

Yang paling berbahaya dari masalah yang sudah lama ada adalah ia berhenti terasa seperti masalah. Semua orang sudah adaptasi. Semua orang punya workaround-nya masing-masing. Dan workaround itu, lama-lama, menjadi cara kerja resmi.

Di GTP, ada tiga pain yang sudah mencapai tahap itu.

Spreadsheet sebagai sumber kebenaran yang tidak bisa dipercaya.

Setiap Product Manager punya versinya sendiri. Tidak ada yang curang — semua orang hanya memperbarui file yang ada di tangannya. Tapi di organisasi dengan ratusan orang dan ratusan inisiatif, hasilnya adalah ekosistem angka yang tidak pernah betul-betul sinkron. Keputusan dibuat berdasarkan data yang berbeda. Laporan yang naik ke atas disusun dari sumber yang berbeda. Dan tidak ada yang bisa dengan yakin menjawab: mana yang benar?

Data yang ada tapi tidak terkoneksi.

Sebelum TeMan ada, data timesheet sebetulnya sudah tersebar di tiga sistem berbeda — salah satunya WAD, sistem yang selama ini dipakai tim untuk mencatat aktivitas kerja. Datanya ada, tapi tidak terkoneksi ke Key Initiatives yang ada di spreadsheet. Tiga sistem bicara sendiri-sendiri. Tidak ada yang bisa menjawab: orang ini mengerjakan Key Initiative mana, dan sudah berapa jam? C-Suite yang butuh gambaran utilisasi tim harus menyusun jawabannya dari potongan-potongan yang terpencar. Laporan mingguan ke EVP disusun dari nol setiap minggu, oleh orang yang harusnya bisa menggunakan waktunya untuk hal yang lebih bernilai. TeMan yang menghubungkan semuanya — connecting the dots antara aktivitas, orang, dan inisiatif yang selama ini hidup di tempat yang berbeda-beda.

Resource yang hanya ada di kepala beberapa orang.

Tidak ada satu tempat untuk menjawab "siapa mengerjakan apa sekarang." Resource mapping — dalam arti yang sesungguhnya — hanya ada sebagai pengetahuan implisit yang tersebar di kepala beberapa PM senior. Orang baru yang masuk butuh berminggu-minggu hanya untuk orientasi, bukan karena mereka tidak mau belajar, tapi karena tidak ada tempat tunggal untuk melihat gambaran keseluruhan.


Yang Sudah Dicoba — dan Kenapa Tidak Cukup

Jira sudah ada. Excel sudah ada. Keduanya dipakai, dan keduanya melakukan apa yang mereka dirancang untuk lakukan dengan baik.

Tapi Jira yang bagus untuk tracking task tidak bisa bicara soal utilisasi orang. Excel yang bagus untuk angka tidak bisa jadi sistem persetujuan berlapis. Dan tidak ada satu pun dari keduanya yang bisa menjawab pertanyaan yang paling sering ditanyakan oleh stakeholder di level atas: proyek ini sehat atau tidak?

Yang dibutuhkan bukan tool baru yang menambah satu lagi ke tumpukan. Yang dibutuhkan adalah satu tempat — single source of truth — yang bisa dipakai oleh semua orang: PM, engineer, C-Suite di Telkom, dan stakeholder di LKPP sekaligus.

Tidak ada yang seperti itu tersedia. Jadi saya membangunnya.


Momen yang Memaksa Keputusan

Saya tidak membangun ini karena ada yang menyuruh. Saya membangunnya karena saya ingin bisa melihat proyek yang sudah berusia tiga tahun ini dari ketinggian yang sesungguhnya — helicopter view yang lengkap, yang tidak bisa saya dapatkan dari skill apapun yang saya miliki kecuali dengan membangun alat yang memungkinkan pandangan itu.

Latar belakang saya bukan developer aktif. Saya bekas CEO. Tapi justru dari kursi itu saya tahu persis pertanyaan apa yang tidak bisa dijawab oleh sistem yang ada — dan berapa mahalnya ketidakmampuan menjawab pertanyaan itu setiap harinya.

Titik akselerasinya datang ketika ada permintaan formal dari Direktur Enterprise Business: timesheet dan manageability proyek yang bisa dibuktikan, bisa diaudit, bisa dilihat kapanpun tanpa harus menunggu laporan dikompilasi. Ini bukan permintaan fitur. Ini permintaan akuntabilitas.

Dan jawabannya harus ada dalam waktu kurang dari sebulan.

Sistem yang awalnya bernama GTP Control Tower — dibangun untuk satu proyek, dengan infrastruktur yang ada dan mindset cepat dulu — akhirnya di-extend. EVP Divisi Digital Product kemudian memberinya nama baru yang lebih tepat menggambarkan fungsinya: TeMan. Timesheet Management.

Kick Off Piloting Timesheet Management DDP — penyerahan penghargaan di atas panggung dengan slide judul acara di layar belakang

Kick off piloting Timesheet Management — momen sistem ini resmi berpindah dari inisiatif pribadi menjadi program divisi.


Yang Lebih Susah dari Dugaan

Ini bagian yang jarang ditulis orang — tapi justru bagian yang paling penting.

Mengubah kebiasaan PM yang agile ke disiplin proyek.

Product Manager yang terbiasa dengan sprint, backlog, dan iterasi tiba-tiba harus bekerja dalam sistem yang punya baseline, timeline terukur, dan konsekuensi biaya setiap kali ada pergeseran.

Resistensinya bukan karena mereka tidak mau. Cara kerja mereka memang berbeda — dan memang benar bahwa proyek sebesar ini masih terus bergerak, masih ada perubahan, dan pergeseran timeline adalah realita, bukan pengecualian.

Solusinya bukan memaksa. Saya membangun workflow approval berlapis untuk setiap rebaseline — pergeseran tetap bisa terjadi, tapi harus melewati forum Komite Bersama yang disepakati oleh kedua belah pihak, Telkom dan LKPP. Perubahan menjadi terdokumentasi, akuntabel, dan tidak bisa terjadi begitu saja tanpa jejak.

Tapi mengimplementasikan itu ke dalam kebiasaan ratusan orang? Itu butuh waktu yang jauh lebih lama dari membangun fiturnya.

Fondasi yang dibangun untuk cepat, bukan untuk scale.

Ini keputusan yang kalau bisa diulang, saya akan buat berbeda.

Di awal, saya memilih untuk mulai dengan infrastruktur yang sudah ada dan prioritas utama adalah kecepatan delivery. Wajar — ada permintaan yang harus dijawab dalam hitungan minggu. Tapi ketika sistem tumbuh menjadi enterprise, fondasi itu mulai terasa. Satu halaman timesheet butuh 47 detik untuk dimuat. Bukan karena logikanya salah, tapi karena terlalu banyak kueri yang berjalan bersamaan untuk sesuatu yang diakses oleh ratusan orang setiap hari.

Masalahnya bukan tidak bisa diperbaiki — bisa, dan akhirnya diperbaiki. Tapi biaya untuk memperbaiki fondasi yang salah selalu lebih mahal dari membangun fondasi yang benar dari awal.

Tiga sumber data yang harus disatukan tanpa memaksa orang mengubah kebiasaan.

TeMan mengambil data dari tiga tempat: sistem yang sudah biasa dipakai tim sebelumnya, input langsung dari aplikasi, dan upload file. Menggabungkan ketiganya adalah tantangan teknis yang bisa diselesaikan. Tapi memastikan bahwa penggabungan itu tidak menciptakan kebingungan baru di level pengguna — bahwa orang tidak merasa harus belajar dari nol — itu yang paling menguras energi.

Bugs di awal sebagian besar lahir dari asumsi tentang bagaimana orang akan menggunakan sistem yang ternyata berbeda dari kenyataannya. Semakin ke sini asumsi itu semakin terkalibrasi, dan sistemnya semakin stabil.


Apa yang Berubah

Per Januari 2026 sampai sekarang, lebih dari 92.000 entri timesheet sudah tercatat di TeMan. 400 orang aktif menggunakannya setiap hari — melaporkan pekerjaan, mencatat aktivitas, clocking jam kerja mereka.

Tapi angka yang paling berbicara bukan itu.

Halaman timesheet yang dulu butuh 47 detik untuk dimuat sekarang terbuka dalam 476 milidetik. Bukan perbaikan inkremental — ini dua orde magnitudo berbeda. Dan perbaikan itu lahir bukan dari infrastruktur baru, tapi dari pemahaman yang lebih dalam tentang di mana masalahnya benar-benar berada.

Orang baru yang masuk ke tim sekarang punya pengalaman yang berbeda. Mereka didaftarkan ke sistem, di-assign ke inisiatif yang relevan, login ke teman.telkomdigital.id — dan di sana mereka bisa langsung melihat apa pekerjaan mereka hari ini, minggu ini, bulan ini. Tidak perlu berminggu-minggu orientasi. Tidak perlu bertanya ke banyak orang.

C-Suite tidak lagi menunggu laporan dikompilasi. Data ada, real-time, bisa dilihat kapanpun.

Dan ketika Setneg masuk sebagai proyek kedua dengan nama SITROOM, sistemnya sudah siap. INAPROC dan SITROOM masing-masing punya ruang kerjanya sendiri — konteks yang terpisah, data yang terpisah — tapi infrastrukturnya sama. Satu sistem, dua proyek, satu cara kerja.


Satu Hal yang Saya Pelajari

Saya bukan developer yang ditugaskan membangun tools. Saya orang yang duduk di tengah masalah dan memutuskan bahwa tidak ada yang akan menyelesaikannya kalau bukan saya.

Dan justru karena itu — karena saya tahu persis rapat mana yang waktunya habis untuk debat angka, laporan mana yang disusun dari nol padahal datanya sudah ada, orang mana yang butuh berminggu-minggu hanya untuk tahu harus lihat ke mana — sistem ini tahu mana yang harus diselesaikan dulu.

Bukan karena teknologinya canggih. Tapi karena ia dibangun dari dalam, oleh orang yang merasakan sendiri biaya dari masalah yang sudah terlalu lama dianggap normal.

Yang paling susah bukan membangun sistemnya.

Yang paling susah adalah berhenti menganggap cara lama sudah cukup.


TeMan bisa diakses di teman.telkomdigital.id

— Sandi Mardiansyah Venture Builder & CEO Founder, SMVC | Advisory Consultant

Komentar

Memuat komentar…