Saha Servis ve İş Emri Mobil Uygulaması Yaptırma Rehberi

Kısa cevap: İş emri uygulaması, sahayı ofis sisteminin küçük ekranına sığdırmak değildir

Saha servis iş emri mobil uygulaması yaptırma projesinin amacı kâğıt formu telefona taşımak değil; çağrı, planlama, teknisyen müdahalesi, parça tüketimi, müşteri kabulü ve finansal kapanış arasında kesintisiz ve denetlenebilir bir kayıt zinciri kurmaktır. Teknisyen bodrum katında bağlantı bulamadığında iş durmamalı; dispeçer acil arıza geldiğinde doğru yetkinliği görebilmeli; depo kullanılan seri numaralı parçayı izleyebilmeli; müşteri ne yapıldığını anlayabilmeli ve yönetim SLA ile ilk seferde çözüm oranını ölçebilmelidir.

Başarılı saha ürünü, en çok form alanına sahip olan değildir. Teknisyenin sahada hızlı ve doğru veri girmesini, yalnız gerekli talimatı görmesini ve tekrar ofiste kayıt yapmamasını sağlar. Aynı zamanda merkezi sistemin veri kalitesini bozan serbest metin, mükerrer müşteri, yanlış varlık ve açıklanamayan parça hareketlerini azaltır. Bunun için mobil uygulama, operasyon paneli ve ERP/CRM entegrasyonu tek süreç olarak tasarlanmalıdır.

Bu rehber bakım-onarım, kurulum, altyapı, enerji, cihaz servisi, tesis yönetimi ve benzeri saha ekipleri için teklif öncesi kararları ele alır. İş sağlığı-güvenliği, çalışan izleme, müşteri kabulü ve sektörel kayıt şartları faaliyet alanına göre yetkili uzmanlarla doğrulanmalıdır.

Bir iş emrinin soy ağacını çıkarın

İş emri genellikle bir çağrı, alarm, planlı bakım takvimi, satış sonrası kurulum veya IoT olayıyla doğar. Fakat tek kayıt her şeyi temsil etmemelidir. Müşteri ve hizmet noktası, servis sözleşmesi/SLA, varlık veya cihaz, arıza/iş tipi, beceri, öncelik, randevu penceresi, atanmış ekip, görev adımları, kullanılan parçalar, çalışma/seyahat süresi, kanıtlar ve sonuç kodu ayrı fakat ilişkili kavramlardır.

Örneğin aynı bina müşterisine ait on cihaz bulunabilir; “klima bozuk” kaydı doğru seri numarasına bağlanmazsa bakım geçmişi değersizleşir. Bir iş emri iki teknisyen ve üç ziyaret gerektirebilir. İlk ziyaret tanılama, ikinci ziyaret parça değişimi ise tek “tamamlandı” alanı gerçeği saklar. Ana iş emri, ziyaretler ve faaliyet satırları bu ayrımı desteklemelidir.

Durumlar da işletme diline göre tanımlanır: yeni, sınıflandırılıyor, planlama bekliyor, atandı, kabul edildi, yolda, sahada, işe başlandı, parça bekliyor, müşteri aksiyonu bekliyor, takip ziyaretine açık, çözüldü, müşteri onayı, teknik/finansal kapanış. Her geçişi kimin yapabildiği, SLA saatini durdurup durdurmadığı ve hangi alanları zorunlu kıldığı yazılır.

Rolleri unvana değil karara göre ayırın

Çağrı merkezi veya talep sahibi

Çağrı merkezi müşteri ve hizmet noktasını doğrular, doğru varlığı bulur, talebi sınıflandırır, etki-aciliyet bilgisini girer ve müşteriye takip numarası verir. Aynı arıza için açık kayıt varsa uyarı almalıdır. Kurumsal müşterinin kendi portalı bulunuyorsa yalnız yetkili lokasyon ve varlıklar için talep açabilmelidir.

Planlayıcı / dispeçer

Planlayıcı açık işler, SLA riski, gereken yetkinlik, konum, vardiya, izin, parça ve teknisyen kapasitesini görür. Atama yapar, rotayı ve randevuyu düzenler, acil işi araya alır, iş yükünü dengeler. Takvim görünümü yanında “SLA'ya 45 dakika kaldı ve yetkin teknisyen yok” gibi karar kuyrukları gerekir. Otomatik öneri sunulsa bile neden o teknisyenin seçildiği açıklanabilir olmalıdır.

Teknisyen ve ekip lideri

Teknisyen görev paketini indirir; müşteri/lokasyon, güvenlik talimatı, varlık geçmişi, kontrol listesi ve gerekli parçaları görür. Görevi kabul eder, seyahat ve çalışma zamanını kaydeder, tanı/sonuç kodu seçer, ölçüm girer, fotoğraf ekler, parça/seri no işler, takip işi açar ve müşteri kabulünü alır. Ekip lideri belirli işlerde kontrol/onay verebilir; fakat teknisyenin yaptığı kayıt sonradan izsiz değişmemelidir.

Depo ve parça sorumlusu

Depo, teknisyen araç stoğu, rezervasyon, transfer, kullanılan/iade edilen/arıza çıkan parça ve seri numaralarını yönetir. “Parça kullanıldı” mobil işlemi ERP stok hareketini hemen veya onay sonrası tetikleyebilir. Bağlantı yokken aynı son parçanın iki işte tüketilmesi gibi çatışma kuralları gerekir. Stok doğruluğu zayıfsa gelişmiş optimizasyondan önce temel sayım ve hareket disiplini kurulmalıdır.

Müşteri, yönetici ve finans

Müşteri randevu penceresini, teknisyen yaklaşımını ölçülü biçimde, servis özetini ve onay talebini görebilir. Operasyon yöneticisi SLA, tekrar ziyaret, verim ve kaliteyi izler. Finans garanti/sözleşme kapsamı, işçilik, parça ve faturalama durumunu görür. Bir rolün kişisel performans, maliyet ve müşteri verisine sınırsız erişmesi yerine görev ayrılığı uygulanır.

Sahadaki mutlu yol ve kırılma noktaları

Mutlu yol çağrı → sınıflandırma → randevu → atama → teknisyen kabulü → yola çıkış → check-in → tanılama → işlem/parça → test → müşteri özeti/onay → çözüm → kapanış → fatura/rapor şeklinde yürüyebilir. Fakat uygulama yatırımının karşılığı şu kırılmalarda ortaya çıkar:

• Müşteri adreste değildir; bekleme ve yeniden randevu kime yazılır?
• Varlık etiketi kayıp veya sistemdeki seri numarası yanlıştır; kim düzeltebilir?
• İş güvenli değildir; teknisyen işi durdurup fotoğraf ve risk kaydı açabilir mi?
• Gerekli parça araçta görünür ama fiziksel olarak yoktur; takip işi ve sipariş nasıl oluşur?
• Başka teknisyen yardım eder; süre, yetki ve performans nasıl bölünür?
• İnternet yokken müşteri imzası alınır; ofis işi iptal etmişse senkron ne yapar?
• İş çözüldü fakat müşteri imza vermeyi reddetti; kapanış kanıtı nedir?

Bu senaryolar durum, zorunlu veri, bildirim, entegrasyon ve raporlama kararlarına çevrilmeden yazılım firması sağlıklı tahmin üretemez.

Karar matrisi: hangi özellik ne zaman değer üretir?

MVP'yi küçültmek için ileri optimizasyon, AR veya karma müşteri portalı ertelenebilir. Offline kayıt güvenliği, rol/yetki, iş emri geçmişi ve veri senkronizasyonu ise “sonra bakarız” kalemleri değildir; saha çekirdeğinin parçasıdır.

Offline-first mimariyi kullanım hikâyesine çevirin

Çevrimdışı destek bir aç/kapa özelliği değildir. Hangi bilgiler önceden indirilecek? Teknisyen yalnız bugünkü işleri mi, varlık geçmişinin ne kadarını mı görecek? Çevrimdışıyken yeni iş oluşturabilir, parça ayırabilir veya yalnız not girebilir mi? Fotoğraf ve büyük PDF ne zaman indirilecek? Cihazda veri ne kadar tutulacak ve oturum iptalinde nasıl korunacak? Her veri türü için karar gerekir.

Mobil istemcide yerel veritabanı kritik ekranların kaynağı olabilir; sunucudan gelen değişiklikler bu depoya uygulanır. Çevrimdışı yazmalar benzersiz işlem kimliği ve sürümle kuyruğa alınır. Bağlantı geldiğinde önce yetki ve iş emri sürümü kontrol edilir. Basit not eklemek birleştirilebilirken iş emrini kapatmak veya son parçayı tüketmek çatışmada yönetici incelemesi gerektirebilir. Android'in resmi offline-first uygulama mimarisi yerel/ağ veri kaynakları ve senkronizasyon stratejileri için yararlı birincil kaynaktır.

Senkron ekranı teknisyene teknik hata kodu değil, aksiyon sunmalıdır: “Bu iş başka bir ekibe aktarıldı; çevrimdışı notunuz taslak olarak korundu” gibi. Başarısız fotoğraf yüklemesi görünür kuyruğa alınmalı; kullanıcı aynı kanıtı defalarca çekmeye zorlanmamalıdır. Sunucu idempotent işlemeli, tekrar gönderimde çift parça veya süre kaydı oluşturmamalıdır.

Dinamik formlar ve veri kalitesi

Her iş tipine tek dev form vermek teknisyeni serbest metne iter. Kurulum, periyodik bakım ve arıza için farklı kontrol listeleri; varlık tipine göre ölçüm alanları; cevaba göre açılan koşullu sorular tasarlanabilir. Form sürümlenmelidir: geçmiş iş emri, bugün değişen soru setiyle yeniden yorumlanmamalıdır. Zorunluluk yalnız rapor merakıyla artırılmamalı; her alan bir karar veya kanıt üretmelidir.

Kod listeleri “diğer” seçeneğini tamamen engellerse saha gerçeği kaybolabilir; sınırsız serbest metin ise analiz edilemez. Dengeli model standart arıza/çözüm kodu + kısa açıklama + gerektiğinde yeni kod önerisi olabilir. Sesle not, barkod/QR, NFC veya kamera OCR girişi hızlandırabilir; yanlış okuma için insan doğrulaması korunur.

Fotoğraf için amaç ve minimum içerik açıklanmalı, otomatik sıkıştırma ve güvenli yükleme uygulanmalıdır. Müşteri evinde gereksiz kişi veya eşya görüntüsü çekilmesini teşvik eden genel “fotoğraf zorunlu” kuralı yerine iş tipine özgü kanıt istenir.

ERP, CRM, varlık ve IoT entegrasyon haritası

CRM müşteri, lokasyon, iletişim ve sözleşme bilgisinin; EAM/varlık sistemi cihaz, bakım planı ve geçmişin; ERP stok, parça, işçilik, satın alma ve faturanın ana kaynağı olabilir. İş emrinin sahibi mevcut bir FSM modülü veya yeni backend olabilir. Her nesne için tekil kimlik, ana sistem, veri yönü, güncelleme sıklığı ve hata sahibi yazılmalıdır.

Entegrasyon “her gece dosya aktarımı”ndan gerçek zamanlı API/webhook'a kadar değişebilir. SLA ve atama için müşteri/varlık bilgisinin anlık olması gerekirken finansal faturanın kontrollü toplu aktarımı yeterli olabilir. Aynı iş emri tekrar geldiğinde mükerrer kayıt oluşmaması; ERP kapalıyken hareketlerin kuyrukta tutulması; hatalı parça kodunun insan incelemesine düşmesi gerekir. Entegrasyon paneli yalnız geliştiricinin loguna değil operasyonun anlayacağı hata kuyruğuna sahip olmalıdır.

IoT alarmı otomatik iş emri açacaksa cihaz kimliği, alarm bastırma, mükerrer olay, bakım penceresi ve insan doğrulaması tasarlanır. Gürültülü sensörün binlerce acil iş üretmesini kota değil iş kuralı engellemelidir. Tahmine dayalı bakım, etiketli arıza ve bakım geçmişi olmadan pazarlama özelliği olarak eklenmemelidir.

Planlama ve rota: önce veri, sonra optimizasyon

Atama önerisinin girdileri beceri/sertifika, bölge, vardiya, randevu penceresi, öncelik/SLA, tahmini iş süresi, seyahat, araç/parça ve müşteri kısıtıdır. Bunların yarısı güncel değilse optimizasyon yanlış kesinlik üretir. MVP'de filtrelenmiş uygun teknisyen listesi ve planlayıcı kararı, veri toplamak için daha güvenli olabilir.

Planlanan başlangıç, gerçek varış, işe başlama/bitiş, bekleme ve seyahat ayrı ölçülür. Teknisyeni hız uğruna gerçek dışı iş sürelerine zorlayan model güvenlik ve kaliteyi bozabilir. Amaç fonksiyonu yalnız günlük iş sayısı değil; SLA, ilk seferde çözüm, beceri uygunluğu, seyahat ve dengeli yükü bir arada değerlendirmelidir. Önerinin manuel değiştirilme nedeni, model iyileştirmesi için değerli veridir.

Güvenlik, KVKK ve çalışan mahremiyeti

Saha uygulamasında müşteri adresi, telefon, varlık güvenlik bilgisi, fotoğraf, imza, teknisyen konumu ve performans verisi bulunabilir. Veri envanteri; amaç, hukuki sebep, erişim, aktarım, saklama ve imha kararlarını kapsamalıdır. KVKK uyum süreci resmi duyurusu, veri envanteri ve teknik/idari tedbirler için başlangıç kaynağıdır; somut uygulama uzman görüşü gerektirir.

Konum “belki lazım olur” diye 7/24 toplanmamalıdır. Atama, güvenlik veya varış için gereken olay ve zaman aralığı belirlenir; çalışan açıkça bilgilendirilir; kimlerin hangi ayrıntıyı göreceği ve ne kadar saklanacağı sınırlandırılır. Müşteriye teknisyenin evden başlayan tam rotasını göstermek yerine randevu yaklaşım bilgisi yeterli olabilir.

Kurumsal veya kişisel cihaz modeline göre yerel veri şifreleme, ekran kilidi, kök/jailbreak risk politikası, kopyala-yapıştır/ekran görüntüsü kısıtlarının ölçülülüğü, uzaktan oturum kapatma ve minimum sürüm belirlenir. Yönetici MFA'sı, rol bazlı/nesne bazlı yetki, güvenli API, dosya taraması, sır yönetimi, denetim izi, yedekleme ve geri yükleme testi uygulanır. OWASP Mobile Application Security doğrulama ve test kapsamı için resmi topluluk standardı sağlar.

İmza görselini tek başına “hukuken kesin” saymak doğru değildir. İmzanın hangi özet ve metin için, kimden, ne zaman alındığı; reddetme ve alternatif onay akışı; kayıt bütünlüğü ve erişimi hukuk danışmanıyla belirlenmelidir.

Maliyet ve süreyi belirleyen iş kırılımı

Teknisyen uygulamasına ek olarak dispeçer paneli, müşteri portalı, depo ekranı ve yönetim raporları ayrı ürün yüzeyleridir. İş emri/ziyaret modeli, dinamik form sayısı, offline veri kapsamı, varlık ve seri numarası, araç stoğu, fotoğraf/video/imza, rota ve planlama, bildirim ile entegrasyonlar eforu belirler. Bir ERP'nin modern API'si ile yalnız eski dosya/kapalı veritabanı bağlantısı olan sistem aynı tahmine sahip değildir.

Kullanıcı, iş emri, dosya ve senkron hacmi altyapı ve test yaklaşımını etkiler. Büyük teknik dokümanların offline dağıtımı, düşük özellikli cihazlar, çoklu ülke/dil, sektörel güvenlik, SSO/MDM ve erişilebilirlik ayrıca kapsamlandırılır. Lisanslı harita, mesajlaşma, depolama, gözlem ve imza sağlayıcılarının kullanım giderleri sahip olma maliyetine eklenir.

Süre keşif ve saha gözlemi, süreç/rol tasarımı, prototip, entegrasyon ispatı, geliştirme, veri temizliği, otomatik/saha/kullanıcı kabul testi, eğitim, pilot bölge ve kademeli yayını içerir. ERP ekibinin erişimi, test verisi, cihaz tedariki ve müşteri karar süreleri bağımlılık olarak yazılır. Sağlıklı teklif varsayım ve hariçleri görünür kılar; sabit fiyatı belirsiz kapsamın üstüne yapıştırmaz.

Teslimat ve kabul paketi

Beklenen çıktılar iş emri durum sözlüğü ve süreç haritası, rol/yetki matrisi, veri/ana sistem haritası, offline ve çatışma kararları, tıklanabilir prototip ve saha test notları, tasarım sistemi, mobil/web/backend kaynak kodları, API/entegrasyon belgeleri, veri şeması, form şablonları, ortam ve dağıtım tanımları, otomatik testler, güvenlik kontrolü, analitik sözlüğü, izleme/uyarılar, mağaza dağıtımı, eğitim materyali, yedekleme/geri yükleme ve bakım modelidir.

Kabul testi gerçek saha koşullarında yapılır. Teknisyen çevrimdışı işi açar, parça ve fotoğraf ekler, uygulamayı kapatır; ofis işi bu sırada yeniden atar; bağlantı geldiğinde sistem veri kaybetmeden çakışmayı açıklar. Yanlış yetkili başka müşteri varlığını açamaz. Aynı senkron paketi iki kez çift stok düşmez. Form sürümü geçmiş kaydı değiştirmez. ERP kesintisinde kapanış kuyruğa girer ve operasyon bunu görür. Büyük dosya düşük bağlantıda görevi kilitlemez. Kayıp cihazın oturumu iptal edilir.

Yönetim KPI'ları: hız, kalite ve maliyeti birlikte okuyun

SLA cevap ve çözüm süreleri temel sonuçtur; fakat kök neden için çağrıdan sınıflandırmaya, atamaya, kabulden varışa, tanıdan parça beklemeye ve teknik kapanıştan faturaya süreler ayrılır. İlk seferde çözüm oranı; aynı varlık/sorun için belirli penceredeki tekrar ziyaret tanımıyla ölçülür. “Tamamlandı” tuşuna basma oranı olarak bırakılmaz.

Teknisyen kullanım oranı seyahat, çalışma, bekleme ve idari zamanı ayırır. Yüksek kullanım dinlenme, eğitim veya kaliteyi yok ediyorsa sürdürülebilir değildir. İş başına seyahat, parça bulunabilirliği, yanlış parça, garanti tekrarı, müşteri onay süresi ve faturalama gecikmesi izlenir. Mobil ürün kalitesinde senkron başarısı, çökme, görev başına dokunma/veri girişi süresi ve destek talebi önemlidir.

Müşteri memnuniyeti iş sonucu, randevu uyumu ve iletişimle birlikte segmentlenir. Bir teknisyeni yalnız müşteri puanıyla değerlendirmek iş zorluğu ve müşteri koşullarını yok sayabilir. Metrikler koçluk ve süreç iyileştirme için kullanılmalı; tanımı ve erişimi yönetişim altında olmalıdır.

Risk siciline eklenecek maddeler

1. Ofis sürecini aynen mobile kopyalamak: Sahada gereksiz alan ve tıklama oluşur. Teknisyenle bağlamsal görev testi yapılır.
2. Ana veri temizliğini ertelemek: Mükerrer müşteri ve yanlış varlık uygulamayı güvenilmez kılar. Pilot veri seti temizlenir ve sahip atanır.
3. Offline'ı son sprintte eklemek: Veri katmanı ve durum modeli yeniden yazılır. Çevrimdışı hikâyeler mimarinin başında seçilir.
4. Her çakışmada son yazan kazanır: Parça ve kapanış kaybı oluşur. Veri türüne göre birleştirme, reddetme veya inceleme kuralı tanımlanır.
5. Aşırı konum takibi: Çalışan güveni ve uyum riski büyür. Amaçla sınırlı olay bazlı politika uygulanır.
6. Entegrasyon hatasını gizlemek: ERP'ye gitmeyen işler fatura ve stokta kaybolur. Operasyonel hata kuyruğu ve yeniden işleme aracı kurulur.
7. Kâğıdı erken kapatmak: Pilot eksikleri saha operasyonunu durdurur. Paralel kullanım için ölçülebilir çıkış kriteri belirlenir.
8. Performansı tek metrikle teşvik etmek: Hız artarken kalite ve güvenlik düşer. Dengeli KPI seti kullanılır.

Teklif brief'i için doldurulabilir çerçeve

İş türlerini, hizmet bölgelerini, ekip/teknisyen sayısını, vardiya ve SLA sınıflarını yazın. Müşteri, lokasyon, varlık, sözleşme, iş emri, ziyaret, faaliyet, parça ve form örneklerini anonimleştirerek ekleyin. Durumları ve her geçişin yetkilisini; acil, parça bekleyen, güvenli olmayan, tekrar ziyaret ve müşteri yok senaryolarını açıklayın.

Atama girdileri, beceri/sertifika, rota ve randevu kurallarını belirtin. Teknisyenin çevrimdışı görmesi ve yazması gereken alanları; kullanılan cihazları ve en kötü bağlantı koşulunu tarif edin. Fotoğraf, ölçüm, imza, barkod/QR, seri numarası, araç stoğu ve müşteri raporu gereksinimini yazın. ERP, CRM, EAM, depo, muhasebe, IoT, harita ve SSO sistemlerinin doküman/test erişimini paylaşın.

Veri saklama ve çalışan konumu karar sahiplerini, pilot ekip/bölgeyi, başarı KPI'larını, eğitim-destek modelini, kaynak kod/hesap sahipliğini ve proje karar vericisini ekleyin. Son olarak biri ilk ziyarette çözülen, biri parça bekleyen, biri bağlantısız alanda gerçekleşen üç gerçek iş emrini uçtan uca anlatın.

Uygulama süreci: teknisyenle birlikte tasarla, bölgeyle pilotla

Keşif yalnız yöneticilerle toplantı değildir. Ekip çağrı merkezi, dispeçer, depo ve teknisyen işini izler; mevcut kâğıt, WhatsApp, Excel ve ERP tekrarlarını çıkarır. Durum/ana veri atölyesi ortak dili kurar. Prototip, eldiven, güneş, tek el ve düşük bağlantı gibi bağlamlarda gerçek görevle test edilir. En riskli entegrasyon veya offline çatışma küçük teknik ispatla erken doğrulanır.

Geliştirme tek iş emrini çağrıdan kapanışa taşıyan dikey dilimle başlar; ardından parça, çok ziyaret, istisna ve entegrasyonlar eklenir. Test, otomatik kural kontrolleri kadar sahada uçuş modu ve düşük cihaz deneyimini kapsar. Pilot sınırlı ekip ve iş türünde yürür; eski-yeni kayıt mutabakatı günlük izlenir. Yaygınlaştırma eğitim şampiyonları, destek hattı, cihaz planı ve veri kalite sahipleriyle dalgalar halinde yapılır.

Sık sorulan sorular

Hazır saha servis yazılımı mı özel uygulama mı seçilmeli?

Standart iş emri, planlama ve mobil form ihtiyacı hazır üründe karşılanıyorsa yapılandırma daha hızlı olabilir. Rekabet avantajı özel saha akışı, eski sistem entegrasyonu, regüle kanıt veya benzersiz varlık/parça modelindeyse özel geliştirme anlamlıdır. Lisans, uyarlama, entegrasyon, veri çıkışı ve uzun dönem sahip olma maliyeti birlikte karşılaştırılır.

Teknisyen uygulaması iOS ve Android olmak zorunda mı?

Cihaz filosu tek platformsa ilk dağıtım buna odaklanabilir. BYOD veya müşteri/alt yüklenici ağı varsa iki platform gerekebilir. Cross-platform yaklaşım kod paylaşımını artırabilir; kamera, arka plan, offline dosya ve cihaz yönetimi gibi kritik işlevler hedef cihazlarda yine yerel koşullarla test edilmelidir.

Dinamik iş emri formunu yöneticiler değiştirebilir mi?

Evet, rol ve yayın akışıyla form tasarım aracı geliştirilebilir. Taslak, test, onay, sürüm ve geri alma gerekir. Yayındaki formun değişmesi açık eski işleri bozmamalı; zorunlu alan ve rapor eşleşmesi doğrulanmalıdır. Çok nadir değişiyorsa özel form editörü MVP'ye göre pahalı olabilir.

Müşteriye teknisyenin canlı konumu gösterilmeli mi?

Çoğu durumda randevu penceresi, yola çıktı ve tahmini varış yeterlidir. Tam konum yalnız belirli zaman aralığında ve güvenlik/mahremiyet değerlendirmesiyle sunulabilir. Teknisyenin önceki müşterisi veya vardiya dışı hareketi açığa çıkmamalıdır.

Bakım ve destek anlaşmasında ne bulunmalı?

Kritik iş emri/senkron arızası için müdahale hedefleri, entegrasyon hata kuyruğu, izleme, mobil OS ve SDK güncellemeleri, güvenlik yamaları, yedekleme geri yükleme testi, cihaz/sürüm desteği, dahil efor, acil kanal ve yeni özellik ayrımı açık olmalıdır.

Sonuç: ilk hedef daha fazla veri değil, kapanan kayıt döngüsü olsun

Saha dönüşümünde en değerli başlangıç, bir iş emrinin ofis ve saha arasında tekrar yazılmadan, veri kaybetmeden ve sorumluluğu belirsizleşmeden kapanmasıdır. Otomatik optimizasyon veya tahmine dayalı bakım bundan sonra temiz veriye dayanabilir. Proje öncesinde bir teknisyenin gününü, bir parça bekleme olayını ve bir çevrimdışı ziyareti ayrıntılı yürütmek gerçek MVP sınırını ortaya çıkarır.

MobiCraft'a anonimleştirilmiş iş emri örneğinizi, mevcut durum listenizi ve entegrasyon haritanızı ileterek kapsam görüşmesi başlatabilirsiniz. Teknisyen mobil deneyimi, planlama paneli, müşteri görünümü ve ERP/CRM veri akışını aynı operasyon modeli üzerinde fazlandırabiliriz. Saha servis uygulamanızı birlikte planlayalım.