Clevago — Field Service Management System

Tipe: Information System Analysis & Design
Fokus: Field Service Management, Route Optimization, Resource Allocation
Industri: Multi-service (Laundry, Home Cleaning, Pest Control)
Durasi: [isi durasi]

1. Background

Clevago adalah entitas bisnis hasil merger dari tiga perusahaan yang menggabungkan layanan laundry, home cleaning, dan pest control dalam satu atap. Penggabungan ini menciptakan potensi bisnis yang besar — satu pelanggan bisa mengakses tiga layanan sekaligus — tapi juga menciptakan kompleksitas operasional yang tidak sederhana.

Di lapangan, satu kendaraan dalam satu hari bisa harus mengantar tim home cleaning ke satu lokasi, mampir mengambil laundry kotor di lokasi lain, mengantar laundry bersih ke tempat berbeda, sekaligus menjemput tim yang sudah selesai bekerja. Ini bukan sekadar masalah penjadwalan — ini adalah teka-teki logistik yang dinamis, dan sebelum proyek ini dimulai, semua itu dikelola secara manual.

Saya ditugaskan pada area Field Service Management (FSM) — bukan sekadar merancang fitur penjadwalan, tapi merancang "otak" operasional yang mampu menangani skenario lapangan paling kompleks sekalipun.

2. Peran Saya

Saya bertindak sebagai System Analyst dengan fokus pada domain Field Service Management. Tanggung jawab saya mencakup:

• Melakukan analisis mendalam terhadap proses operasional lapangan yang berjalan saat ini
• Mengidentifikasi akar masalah di balik inefisiensi yang terlihat di permukaan
• Merancang arsitektur data sebagai fondasi solusi, menggunakan pendekatan domain modeling berbasis Class Diagram
• Mendefinisikan aturan bisnis (business rules) untuk setiap skenario operasional
• Merancang alur kerja dan mekanisme alokasi sumber daya secara end-to-end
• Mendesain konsep dashboard operasional untuk manajer lapangan

3. What I Solved

Mengurai tiga masalah fundamental yang saling terkait

Setelah analisis, saya menemukan bahwa masalah lapangan Clevago bukan satu isu tunggal — melainkan efek domino dari tiga masalah fundamental yang saling memperburuk satu sama lain.

Masalah 1 — Logistik kendaraan yang sangat kompleks Satu kendaraan harus menyelesaikan beberapa tugas berbeda dalam satu hari secara bersamaan: mengantar tim, mengambil laundry, mengantarkan barang, menjemput tim lain — di lokasi yang berbeda-beda, dengan kondisi lalu lintas yang tidak terprediksi. Tidak ada sistem yang membantu manajer melihat dan mengatur ini semua secara visual.

Masalah 2 — Visibilitas sumber daya yang nol (black box) Pertanyaan seperti "Apakah staf berlisensi pest control tersedia pukul 14.00?" atau "Apakah mesin vakum X sedang dipakai atau dalam perbaikan?" harus dijawab lewat telepon atau chat — manual, lambat, dan rawan error.

Masalah 3 — Risiko kualitas dan kepatuhan layanan Beberapa pekerjaan memiliki syarat yang tidak bisa ditawar: pembersihan gedung tinggi memerlukan staf berlisensi khusus, disinfeksi pasca-COVID wajib mengikuti protokol tertentu. Tanpa sistem yang mampu mengidentifikasi kebutuhan ini secara otomatis, risiko kegagalan kualitas dan keselamatan kerja menjadi sangat nyata.

Ketiga masalah ini menghasilkan satu dampak bisnis yang sama: biaya operasional membengkak, kepuasan pelanggan terancam, dan ekspansi bisnis menjadi sangat sulit dilakukan di atas fondasi operasional yang rapuh.

Fondasi solusi: mulai dari arsitektur data

Saya tidak memulai dari desain UI atau fitur. Saya memulai dari pemodelan domain — karena saya percaya bahwa perbaikan fundamental harus dimulai dari cara data distrukturkan.

Pertanyaan pertama yang saya ajukan: "Bagaimana sistem bisa secara otomatis mengetahui semua kebutuhan untuk satu jenis layanan?"

Jawaban ada di Class Diagram. Saya merancang struktur di mana setiap entitas Layanan tidak berdiri sendiri, melainkan memiliki relasi ke PaketStandarKebutuhan — yang secara eksplisit mendefinisikan peralatan, material, dan keahlian staf yang dibutuhkan, lengkap dengan jumlah dan status ketersediaannya.

Dengan fondasi data ini, "kotak hitam" ketersediaan sumber daya mulai terbuka. Dari sinilah tiga pilar solusi dibangun.

Pilar 1 — Dynamic Booking: dari reaktif menjadi proaktif

Berdasarkan struktur data yang sudah didefinisikan, saya merancang mekanisme Dynamic Booking dengan aturan bisnis yang jelas:

• Layanan kompleks seperti Home Cleaning wajib dipesan minimal H-1
• Saat pelanggan memilih jadwal, sistem secara real-time memeriksa ketersediaan staf (dengan skill yang sesuai), peralatan, dan material
• Slot jadwal hanya ditampilkan jika semua sumber daya tersedia 100%
• Alokasi material dan peralatan dikelola oleh tim material di masing-masing cabang — admin hanya fokus pada alokasi staf dan optimasi rute

Hasilnya: proses yang tadinya "Nanti kita cek dulu, Bu" berubah menjadi konfirmasi instan berbasis data. Masalah sumber daya diselesaikan sebelum pesanan bahkan berhasil dibuat.

Pilar 2 — Session-based Service: mengukur yang sebelumnya tidak terukur

Untuk mengatasi ketidakpastian durasi kerja — yang menjadi sumber kekacauan penjadwalan — saya mengubah paradigma layanan dari per meter persegi menjadi berbasis sesi.

Satu sesi = satu jam pengerjaan yang terstandarisasi. Pengecualian diberikan untuk layanan deep clean yang memerlukan survei lokasi terlebih dahulu.

Dengan satuan kerja yang terukur dan konsisten, estimasi waktu selesai menjadi jauh lebih akurat — dan akurasi waktu selesai adalah kunci untuk bisa menjadwalkan tugas berikutnya bagi tim yang sama tanpa jeda yang terbuang.

Pilar 3 — Interactive Route Dashboard: orkestrasi kendaraan secara visual

Setelah masalah ketersediaan dan waktu teratasi, saya merancang dashboard berbasis peta interaktif untuk memberikan situational awareness penuh kepada manajer lapangan.

Mekanismenya:

• Manajer dapat melihat seluruh tugas hari itu di satu tampilan peta
• Pengelompokan tugas ke dalam satu rute kendaraan dilakukan secara drag-and-drop (Update : ada debat antara saya dan dosen, katanya ini sulit di implementasikan, jadi modelnya diubah menjadi klik on klik)
• Setelah tugas dikelompokkan, sistem secara otomatis mengoptimalkan urutan perhentian menggunakan integrasi Google Maps API, dengan mempertimbangkan prioritas dan estimasi kondisi lalu lintas

Proses alokasi rute yang sebelumnya berbasis intuisi dan telepon berubah menjadi proses yang visual, terukur, dan dapat diaudit.