Planlamacı sabahın ilk üç saatini telefonla geçiriyordu
Firma Türkiye genelinde 12 ofisten çalışan 180 teknisyenle endüstriyel soğutma ekipmanlarının bakımını yapıyor. Günde ortalama 240 iş emri açılıyor; bir kısmı planlı periyodik bakım, bir kısmı acil arıza.
Dağıtımı üç planlamacı elle yapıyordu. Excel'de bir çizelge, yanında WhatsApp grupları. Planlamacı bir arıza bildirimi aldığında hangi teknisyenin nerede olduğunu, o ekipman tipinde sertifikası olup olmadığını ve gerekli parçanın hangi araçta bulunduğunu bilmiyordu. Telefonla soruyordu.
Sonuç: teknisyenler günde ortalama iki kez yanlış işe gidiyordu. Parça olmadığı için ikinci ziyaret gerekiyordu ve müşteriye verilen randevular tutmadığı için sözleşme cezaları birikiyordu.
İlk hafta sahada üç teknisyenle gezdim. Asıl problem planlama değil, planlamacının karar verirken ihtiyaç duyduğu üç bilginin üç ayrı yerde durmasıydı.
Önce tek bir doğru kaynak, sonra atama motoru
İlk fazda hiçbir zeki şey yapmadım. Teknisyen konumu, araç stoğu ve sertifika kayıtlarını tek bir veritabanı şemasında topladım. Konum verisi zaten takip cihazlarından geliyordu ama başka bir sistemde duruyordu.
Araç stoğu hiç dijital değildi. Her iş sonunda kullanılan parçanın telefondan işaretlendiği basit bir akışla başladık. İlk üç hafta stok doğruluğu %70'ti, ikinci ayın sonunda %94'e çıktı.
Bu veri oturduktan sonra atama motorunu yazdım: her iş emri için uygun teknisyen kümesi, mesafe, sertifika eşleşmesi, parça uygunluğu ve hizmet süresi kısıtları. Model her on dakikada bir çalışıp henüz başlamamış işleri yeniden dağıtıyor.
Planlamacı öneriyi ekranda görüyor ve tek tuşla onaylıyor. Elle değiştirdiğinde sistem sebebini soruyor; bu kayıtlar modelin haftalık kalibrasyonunda kullanılıyor.
Sesli servis raporu, yapılandırılmış kayıt
Teknisyenlerin en sevmediği iş rapor doldurmaktı. Eldiven ve yağ içinde telefonda on dört alanlı bir form. Doldurma oranı %62 idi, dolduranların yarısı tek kelimelik yanıtlar giriyordu.
Formu kaldırdım. Teknisyen işi bitirince kayıt tuşuna basıp konuşuyor. Ses transkript ediliyor, ardından bir dil modeli metni şemaya oturtuyor: yapılan işlem, kullanılan parçalar, tespit edilen riskler, önerilen sonraki bakım tarihi.
Model emin olamadığı alanları boş bırakıyor ve teknisyene tek onay ekranında gösteriyor. Rapor başına ortalama düzeltme 0.4 alan. Kritik olan şu: kayıt hiçbir zaman sessizce oluşmuyor.
Bu projede öğrendiğim şey: dil modelini veri girişini yazan taraf yapın, karar veren taraf değil. Onay adımı kalkarsa güven de kalkıyor.
Sıkıcı ve tahmin edilebilir
Next.js ön yüz, NestJS API, PostgreSQL. Transkripsiyon ve model çağrıları kuyruğa gidiyor, çünkü saniyeler sürüyor ve teknisyenin telefonunun beklemesi gerekmiyor.
Optimizasyon motoru ayrı bir Python servisi. Ayırma sebebim ölçeklenebilirlik değil, çökme izolasyonu: model takılırsa panel çalışmaya devam ediyor, sadece öneri gelmiyor.
Tek bir sunucuda konteynerlerle çalışıyor. Mikroservis yok. 180 kullanıcı ve günde 240 iş emri için fazlasıyla yeterli; müşterinin kendi ekibi de bu kurulumu devralabiliyor.
Ne işe yaramadı
İlk sürümde teknisyene rotasını harita üzerinde sıralı gösteren bir ekran yaptım. Kimse kullanmadı; herkes kendi navigasyon uygulamasını açıyordu. İki ay sonra kaldırdım.
Müşteriye otomatik varış saati bilgilendirmesi de eklemiştik. Tahmin tutmadığında şikâyet arttı. Şimdi bildirim yalnızca teknisyen yola çıktığını söylediğinde ve geniş bir saat aralığıyla gidiyor.