Saha Servis Yazılımı: İş Emri, Parça ve Tamamlama Akışı

İş emri ile ziyareti aynı kayıt sanmayın

Bir iş emri birkaç ziyaret gerektirebilir. İlk ziyarette arıza belirlenir, ikinci ziyarette parça değiştirilir. Microsoft Field Service dokümantasyonu da iş emri ve rezervasyon durumlarının bağımsız yaşam döngülerini açıklar. [1] Kendi yazılımınızda tek ziyaretin bitmesini tüm işin bitmesiyle karıştırmayın.

İş emrine problem, müşteri/varlık ilişkisi, öncelik ve hedef sonuç ekleyin. Ziyarette ise atanan personel, zaman aralığı, gerçekleşen süre ve yapılan iş tutulabilir. Bu ayrım tekrar ziyaretlerin nedenini ve işin hangi aşamada beklediğini anlamayı kolaylaştırır.

Parça kullanımını bir not alanına bırakmayın

Teknisyen “bir parça değişti” yazdığında stok ve maliyet sistemi bunu güvenilir biçimde işleyemez. Kullanılan parça kimliği, miktar, kaynak depo veya araç stoğu ve ilgili iş emri kaydedilmelidir. Microsoft başlangıç rehberi iş emrinde görev, ürün ve hizmet bileşenlerini ayrı tanımlar. [2]

Parça kullanıldıktan sonra geri alındıysa ters hareketin nasıl yapılacağı belli olsun. Kullanılmayan parçayı tüketilmiş göstermek stok farkı yaratır. Seri numarası takibi gereken ürünlerde eski ve yeni parça ilişkisi ayrıca korunabilir; gereklilik ürün tipine göre değerlendirilmelidir.

Örnek: ilk ziyarette çözülmeyen bakım işi

Varsayımsal bir ekip kapı mekanizmasını incelemek için gidiyor ve farklı bir yedek parça gerektiğini görüyor. Ziyaret tamamlandı ama iş emri “parça bekliyor” durumunda kalıyor. Parça temin edilince ikinci ziyaret planlanıyor. Müşteriye “işiniz tamamlandı” yerine beklenen adımın ne olduğu bildiriliyor.

Bu örnek, bir müşteriye uygulanmış çalışma iddiası değildir. Amacı, aynı “tamamlandı” kelimesinin farklı kayıtlar için farklı anlam taşıdığını göstermektir.

Mobil kullanımda eksik bilgiyi yönetilebilir kılın

Teknisyen sahada uzun formları dolduramayabilir. Gerekli bilgileri işin doğal aşamalarına dağıtın. Varışta durum, işlem sırasında parça ve görevler, çıkışta sonuç kaydedilebilir. Bir alanın zorunlu olması, o anda gerçekten elde edilebilecek bir bilgiye dayanmalıdır.

Fotoğraf, dosya veya müşteri notu eklendiğinde yüklemenin tamamlanıp tamamlanmadığı görünür olsun. Bağlantı kesildiğinde kayıt cihazda mı, sunucuda mı? Kullanıcı belirsizliği bilmelidir. Yeniden gönderimin ikinci iş emri veya ikinci stok hareketi oluşturmaması test edilmelidir.

Müşteri kabulü ile teknik kapanışı ayırın

Müşterinin ziyareti onaylaması, teknik çözümün tüm kalite kontrollerinin yapıldığı anlamına gelmeyebilir. Aynı şekilde teknisyenin işi bitirmesi de müşteri itirazı kalmadığını kanıtlamaz. Hangi koşulla iş emrinin kapandığını ve yeniden açılabildiğini belirleyin.

Kapanış sonrasında değiştirilen parça veya süre için denetim izi tutmak faydalıdır. Yanlış kayıt düzeltilebilir, ancak eski değerin neden değiştiği bilinmelidir. Fatura veya tahsilat gibi sonraki süreçlere aktarılan bilgiler değiştiğinde ilgili ekipler haberdar olmalıdır.

Verimlilik raporunu eksik ölçümden koruyun

Sadece günlük kapatılan iş emri sayısını ölçmek, karmaşık işleri yapan ekibi haksız gösterebilir. İş türü, tekrar ziyaret nedeni, beklenen parça ve seyahat koşulları birlikte değerlendirilmelidir. Ziyaret süresi ile çözüm süresini aynı gösterge olarak kullanmayın.

Yazılım tesliminde iş emri açma, atama, parça bekletme, tekrar ziyaret, müşteri kabulü ve yeniden açma zincirini çalıştırın. Her aşamada stok ve raporların nasıl değiştiğini görün. Yalnızca takvime görev sürüklemek saha servis sisteminin tamamlandığını göstermez.

Sık sorulan sorular

### Bir iş emrine birden fazla teknisyen atanabilir mi? İhtiyaç varsa tasarlanabilir. Her kişinin görevi, zamanı ve tüketim kaydı ile işin ortak tamamlanma koşulu açık olmalıdır.

Müşteri imzası bütün teslim sorunlarını çözer mi?

Hayır. İmzanın veya onayın neyi doğruladığı tanımlanmalıdır. Teknik kabul, hizmet kapsamı ve hukuki değerlendirme ayrı konulardır; tek düğmeye indirgenmemelidir.