Servis ve teknik destek ekiplerinde arıza kaydı çoğu zaman tek bir noktada başlamaz. Bir müşteri çağrı merkezi üzerinden talep açar, bayi WhatsApp’tan fotoğraf yollar, saha personeli işi telefonla devralır, kapanış ise ERP’ye gün sonunda işlenir. Bu durum parçalı veriye, geciken müdahaleye ve eksik kayıtlara yol açar. Mobil arıza yönetimi uygulaması tam da bu kırılma noktası için tasarlanır: talebin açıldığı andan iş emrinin kapanmasına kadar tüm süreci sahada, anlık ve izlenebilir kılar.
Başarılı bir kurgu yalnızca “teknisyene iş atayan bir mobil ekran”dan ibaret değildir. Rol bazlı akış, SLA takibi, konum doğrulama, yedek parça hareketleri, offline çalışma, fotoğraf ve imza ile kanıt toplama gibi detaylar uygulamanın gerçek değerini belirler. Özellikle 20, 50 veya 200 kişilik saha ekiplerinde küçük tasarım hataları bile operasyon yükünü büyütür. Bu yazıda talep, atama, yedek parça ve kapanış süreçlerini merkeze alarak uygulanabilir bir mimari çerçeveyi ele alacağız.
Mobil arıza yönetimi uygulaması hangi problemi çözer?
Sahada en sık karşılaşılan sorunlardan biri, tek bir arıza için birden fazla kayıt oluşmasıdır. Örneğin aynı ekipman için sabah 09:12’de çağrı merkezi talep açar, 09:18’de müşteri tekrar arar, 09:26’da teknisyen kendi notunu ayrı bir Excel’e yazar. Üç kayıt, tek arıza. Bu yapı hem SLA hesabını bozar hem de ilk müdahale süresini yanlış gösterir.
İyi kurgulanmış bir uygulama, her iş emrine benzersiz bir kayıt numarası verir; örneğin ARZ-2026-004381. Aynı varlık kodu, seri numarası, lokasyon ve belirti eşleşmeleri üzerinden mükerrer talep kontrolü yapar. Operasyon yöneticisi açık işlerin durumunu tek panelden izler: yeni talep, yolda, müdahale başladı, parça bekliyor, müşteri onayı bekliyor, kapandı.
Buradaki hedef yalnızca görünürlük sağlamak değildir. Ölçülebilirlik de şarttır. En temel 6 metrik genelde şunlardır:
- İlk yanıt süresi
- İlk müdahale süresi
- Kapanış süresi
- İlk seferde çözüm oranı
- Tekrar açılan iş emri sayısı
- Parça kaynaklı gecikme süresi
Uygulama bu metrikleri üretemiyorsa, sahadaki dijitalleşme eksik kalır.
Talep oluşturma akışı: doğru veri ilk 90 saniyede toplanmalı
Arıza sürecinin kalitesi, talep oluşturma ekranında başlar. Kullanıcının karşısına 25 alanlı bir form çıkarmak veriyi artırmaz; aksine eksik ve hatalı girişlere neden olur. İlk adımda 5 ile 8 kritik alan yeterlidir: müşteri, cihaz veya varlık kodu, lokasyon, arıza tipi, öncelik, kısa açıklama ve varsa fotoğraf.
Talep kanalları tek modele bağlanmalı
Çağrı merkezi, web formu, müşteri portalı, bayi paneli ve iç ekip ekranı farklı kaynaklar olabilir. Ancak arka planda tek bir talep veri modeli bulunmalıdır. Örnek bir minimal kayıt yapısı şöyle kurgulanabilir:
{
"ticketNo": "ARZ-2026-004381",
"assetId": "CHL-17-4481",
"customerId": "CRP-1029",
"location": "Gebze Depo 3",
"faultCode": "E214",
"priority": "P2",
"attachments": 2,
"openedAt": "2026-07-11T09:12:00+03:00"
}Bu yapı CRM, ERP veya servis yönetimi sistemiyle kolayca entegre olur. Varlık bazlı çalışılıyorsa seri numarası zorunlu tutulabilir. Tüketici elektroniği gibi senaryolarda IMEI ya da garanti numarası da eklenir.
Önceliklendirme kuralları açık olmalı
Her arıza aynı değildir. Soğuk hava deposunda sıcaklık alarmı ile bir ofis yazıcısının kağıt sıkışması aynı kuyruğa düşmemelidir. Uygulama içinde en az 3 seviyeli bir öncelik modeli net biçimde tanımlanmalıdır. Örneğin P1 için 30 dakika içinde ilk temas, P2 için 2 saat, P3 için aynı gün planlama gibi. Süreler şirketten şirkete değişir; önemli olan bunların sistemde kesin kurallarla tanımlanmasıdır.
Bir diğer pratik detay da talep açılır açılmaz müşteri tarafına otomatik bildirim gitmesidir. “Kaydınız alındı” mesajı tek başına yeterli olmaz. Kayıt numarası, tahmini değerlendirme süresi ve varsa takip bağlantısı da paylaşılmalıdır.
Atama motoru: teknisyeni en yakın kişiye değil, en uygun kişiye yönlendirin
Sahada yapılan en yaygın hatalardan biri, iş emrini yalnızca konuma göre atamaktır. Oysa doğru atama en az 4 değişken üzerinden yapılır: yetkinlik, sertifika, müsaitlik ve mesafe. Yüksek gerilim paneli arızasını o bölgede en yakın ama yetkisiz personele vermek operasyonel risk yaratır.
Pratik bir puanlama yaklaşımı kurulabilir. Örneğin yetkinlik eşleşmesi yüzde 40, SLA riski yüzde 25, mesafe yüzde 20, mevcut iş yükü yüzde 15 ağırlık taşıyabilir. Sistem bu skora göre öneri listesi sunar; son onay ise operasyon planlayıcısında kalır. 50 kişilik bir ekipte bu yaklaşım manuel planlamaya göre ciddi zaman kazandırır, ancak burada kesin bir oran vermek doğru olmaz; sektör, şehir dağılımı ve vardiya yapısı sonucu değiştirir.
Atama ekranında bulunması gereken alanlar
- Teknisyenin canlı veya son senkronize konumu
- Günün açık iş sayısı
- Gerekli sertifika veya ürün yetkinliği
- Tahmini varış süresi
- Araçta bulunan kritik yedek parçalar
- Vardiya ve çalışma saati durumu
Teknisyen mobil uygulamada işi kabul ettiğinde saat damgası oluşmalıdır. “Yolda” durumuna geçtiği an ile “sahaya ulaştı” anı ayrı tutulmalıdır. Aradaki fark, rota ve zaman planlama kalitesini gösterir.
Şebeke erişiminin sınırlı olduğu sahalarda offline mod kritik hale gelir. Uygulama atanan işi cihazda yerel olarak saklamalı, işlem loglarını bağlantı geldiğinde sunucuya aktarmalıdır. Çakışma çözümü için de basit bir kural gerekir: örneğin en son durum güncellemesi sunucu zamanına göre işlenir, ama fotoğraf ve notlar birleştirilir.
Yedek parça yönetimi: iş emriyle stok hareketi aynı zincirde ilerlemeli
Arıza süreçlerindeki en pahalı gecikmelerden biri, parça kaynaklı beklemedir. Uygulama parça ihtiyacını yalnızca not alanında bırakırsa depodan araca, araçtan sahaya kadar iz kaybolur. Bu nedenle mobil arıza yönetimi uygulaması en azından mikro stok mantığıyla çalışmalıdır.
Buradaki temel seviye şudur: teknisyenin araç stoğu, bölge deposu ve merkez depo ayrı kaynaklar olarak tanımlanır. Bir iş emrinde kullanılan parça okutulduğunda ilgili stoktan düşer. QR veya barkod okutma büyük kolaylık sağlar. Örneğin PRC-VALF-3/4-118 kodlu vana sahada kullanıldıysa, iş emrine bağlanan tüketim kaydı otomatik olarak oluşmalıdır.
Parça akışında 4 kritik durum
- Rezervasyon: İş emri açıldığında gerekli parça ayrılır.
- Transfer: Bölge deposundan araca ya da şubeye hareket başlatılır.
- Tüketim: Parça sahada gerçekten kullanıldığında düşüm yapılır.
- İade: Açılan ama kullanılmayan parça geri alınır.
Burada tarih ve kullanıcı izi önemlidir. Hangi parçayı kim, saat kaçta, hangi iş emri için kullandı? Bu kayıt hem maliyet kontrolü hem de garanti analizi için gereklidir. ERP entegrasyonu varsa tüketim hareketi servis fişiyle muhasebeleşebilir. Entegrasyon yoksa önce ara bir servis katmanı kurmak daha sağlıklıdır; doğrudan mobil istemcinin ERP’ye yazması çoğu zaman kırılgan bir yapı oluşturur.
Gerçek bir saha senaryosu düşünelim: teknisyen pompa arızasına gidiyor, ilk tespitte salmastra ve rulman ihtiyacı görüyor, araçta sadece biri var. Uygulama “parça bekliyor” durumuna geçerken eksik parçayı depo talebine dönüştürmelidir. Bu adım telefon ve mesajlaşma üzerinden yürütülürse izlenebilirlik kaybolur.
Kapanış süreci: tamamlandı demek yetmez, kanıt ve kalite kontrol gerekir
Birçok ekipte iş emri “müşteriyle konuştuk, halloldu” notuyla kapatılır. Oysa sağlıklı bir kapanış için kanıt, sınıflandırma ve kalite verisi gerekir. Uygulama kapanış adımında en az şu alanları istemelidir: yapılan işlem, kullanılan parçalar, harcanan süre, arıza kök nedeni, cihazın son durumu, müşteri onayı.
Müşteri onayı dijital imza, tek kullanımlık doğrulama kodu ya da uygulama içi onayla alınabilir. Fotoğraf zorunluluğu da bazı sektörlerde kritik hale gelir. Örneğin bir endüstriyel bakım işinde önce-sonra fotoğrafı olmadan kapanışa izin verilmemesi, denetim kalitesini yükseltir.
Kapanış kontrol listesi örneği
- Arıza nedeni seçildi mi?
- Kullanılan parça kayıtları işlendi mi?
- Çalışma süresi girildi mi?
- Fotoğraf veya servis formu eklendi mi?
- Müşteri onayı alındı mı?
- Tekrar ziyaret gerekiyor mu?
Eğer tekrar ziyaret gerekiyorsa mevcut iş emrini kapatıp yenisini açmak yerine, bağlı alt görev üretmek çoğu zaman daha doğru olur. Böylece ana arıza geçmişi bölünmez. Ayrıca “ilk seferde çözüm” metriği de gerçeğe daha yakın hesaplanır.
Kapanış sonrası otomasyonlar da önem taşır. Müşteriye PDF servis formu gönderimi, ERP’ye hizmet kaydı, CRM’de memnuniyet anketi tetikleme ve yöneticilere SLA ihlal bildirimi bu aşamada çalışabilir.
Teknik mimari: saha uygulaması, yönetim paneli ve entegrasyon katmanı birlikte düşünülmeli
Uygulama tarafında genelde üç katmanlı bir yapı yeterlidir. Birinci katman iOS/Android mobil istemci, ikinci katman web tabanlı operasyon paneli, üçüncü katman ise ERP, CRM, stok ve kimlik doğrulama sistemleriyle konuşan API servisleridir. Bu yapı hem küçük ekiplerde hem de birden fazla şehirde çalışan servis organizasyonlarında ölçeklenebilir.
Mobil istemcide kritik teknik başlıklar nettir: offline veri saklama, medya yükleme sıkıştırması, push bildirim, konum servisi, rol bazlı yetki, cihaz güvenliği. Özellikle fotoğraf ve video ekleri düşünülüyorsa mobil ağ koşulları için kademeli yükleme tasarlanmalıdır. 12 MB’lık bir görseli tek seferde göndermek yerine, sıkıştırılmış önizleme ve arka planda tam dosya yükleme daha iyi bir deneyim sunar.
API ve entegrasyonda dikkat edilmesi gerekenler
- Her iş emri için benzersiz dış sistem anahtarı üretin.
- Webhook veya kuyruk tabanlı entegrasyon kullanın.
- Log ve hata yönetimini merkezi olarak izleyin.
- Yetki modelinde teknisyen, planlayıcı, depo ve yönetici rollerini ayırın.
Kurumsal tarafta sık görülen ihtiyaçlardan biri de raporlamadır. Günlük açık iş sayısı tek başına yetmez. Bölge bazında ortalama kapanış süresi, teknisyen bazında tekrar ziyaret oranı, parça bazında arıza eğilimi gibi raporlar karar kalitesini artırır. Bu yüzden veri modeli en baştan analitik tüketimi de desteklemelidir.
Projeyi canlıya alırken hangi sırayla ilerlenmeli?
En güvenli yaklaşım, tüm süreçleri tek sürümde açmak yerine kontrollü fazlarla ilerlemektir. İlk 6 ila 8 haftalık fazda talep, atama, saha durum güncellemesi ve temel kapanış devreye alınabilir. İkinci faza parça yönetimi, depo entegrasyonu ve gelişmiş SLA raporları eklenir. Üçüncü fazda ise kestirimsel bakım önerileri, arıza kodu önerme veya görselden ekipman tanıma gibi yapay zeka destekli özellikler devreye alınabilir.
Pilot ekip küçük seçilmelidir. Örneğin 8 teknisyen, 1 planlayıcı, 1 depo sorumlusu. Buradaki amaç kusursuz bir başarı hikayesi yazmak değil, saha gerçeklerini görmektir. Hangi form alanı gereksiz, hangi bildirim gürültü yaratıyor, hangi ekran güneş altında okunmuyor? Bu soruların yanıtı ofiste değil, sahada bulunur.
İyi tasarlanmış bir mobil arıza yönetimi uygulaması, servis operasyonunu dijitalleştirmekten fazlasını yapar; talep kalitesini artırır, doğru atamayı kolaylaştırır, parça hareketini izlenebilir hale getirir ve kapanış verisini güvenilir kılar. İşin özünde teknoloji kadar süreç disiplini de vardır. Uygulama, ekiplerin mevcut dağınık alışkanlıklarını yalnızca mobil ekrana taşımamalı; bunları daha ölçülebilir ve daha sürdürülebilir bir iş akışına dönüştürmelidir.
