Saha sorun bildirme uygulaması: Ekipler için pratik bir plan

Saha raporları neden geç veya eksik gelir?

Bir saha sorunu gevşemiş bir kablo, hasarlı bir tabela ya da arızalanmış bir ekipmanla başlayabilir. Ekip bunu hemen görür, ancak harekete geçebilecek kişi saatler boyunca haberdar olmayabilir. Kâğıt notlar kamyonda kalır. Telefon görüşmelerinde ayrıntılar eksik kalır. Fotoğraflar, iş referansı olmayan özel mesajlaşma gruplarında kaybolur.

Bu gecikme onarımları yavaşlatır. Ofisin saha, varlık, aciliyet veya sorunun tam olarak ne olduğu gibi bilgileri yeniden sorması gerekir. O zamana kadar ekip başka bir yere geçmiş olabilir ve ayrıntılar daha az net hale gelir.

Ekiplerin, sorunu buldukları anda çalışabilecek bir saha sorun bildirme uygulamasına ihtiyacı vardır. Çalışan bir fotoğraf çekebilmeli, konumu doğrulayabilmeli, sorun türünü seçebilmeli, gerekirse kısa bir not ekleyebilmeli ve raporu gönderebilmelidir. «Yeni», «Devam ediyor» veya «Çözüldü» gibi durumları güncellemek bir iki dokunuştan fazla sürmemelidir.

Uzun formlar bu alışkanlığı zorlaştırır. Yağmur altında, eldiven takarken veya işler arasında hareket ederken kimse on zorunlu alanı doldurmak istemez. Daha sonra tamamlamayı planlayabilir, sonra da varlık numarasını unutabilir veya notunu kaybedebilir. Zorunlu metin kutuları «bozuk» gibi belirsiz girişlere de yol açar. Oysa bir fotoğraf ve basit bir kategori ofise çok daha fazla bilgi verebilir.

İyi bir iş akışı yalnızca sonraki adımı etkileyen ayrıntıları ister: fotoğraf, konum, sorun türü, gerektiğinde aciliyet, isteğe bağlı not ve açık bir durum. Uygulama, raporu gönderen kişinin adını ve gönderim zamanını otomatik olarak kaydetmelidir. Telefonun zaten bildiği bilgileri insanlardan yeniden istemek zaman kaybettirir ve hata oluşturur.

Dağınık kanallar ikinci bir sorun yaratır: kaydın tamamından kimse sorumlu olmaz. Bir yönetici bir telefon görüşmesi, sohbet fotoğrafı ve başka bir çalışandan gelen takip mesajı alabilir. Bu mesajları bir onarım talebine dönüştürmek zaman alır; acil raporlar da rutin konuşmaların arasında kaybolabilir.

Tek bir saha uygulaması her soruna tek bir kayıt verir. Sevk ekipleri fotoğrafı, yeri, kategoriyi ve güncel durumu birlikte görebilir. Ekipler ne olduğunu açıklamaya daha az zaman harcar, onarım ekipleri de gitmeden önce ne yapacaklarına karar vermeleri için yeterli bağlama sahip olur.

Her raporun neye ihtiyacı olduğunu belirleyin

Bir ekip üyesi, işe yarar bir raporu bir dakikadan kısa sürede gönderebilmelidir. Birinin sorunu anlamasına, bulmasına ve kimin harekete geçeceğine karar vermesine yardımcı olan en küçük ayrıntı grubuyla başlayın.

Birçok ekip için bu grup fotoğraf, sorun türü, mevcut konum, durum ve kısa bir nottan oluşur. Fotoğraf; çatlamış bir boruyu, kapanmış bir geçiş yolunu veya hasarlı bir tabelayı uzun bir açıklamadan daha hızlı anlatır. Not, «Su yükleme alanına ulaşıyor» veya «Kapı kilitlenmiyor» gibi görüntünün gösteremediği bağlamı eklemelidir.

İlk raporu, sahadaki kişinin bildikleriyle sınırlı tutun:

• Görsel kanıt gerektiğinde fotoğraf veya video
• Kısa ve tanıdık bir listeden seçilen sorun türü
• Telefon tarafından alınan ve düzeltilebilen konum
• «Yeni» veya «İncelenmeli» gibi başlangıç durumu
• İsteğe bağlı not

Ofis işlerini ofise bırakın. Bir teknisyen onarım sorumlusu atamak, maliyet tahmin etmek veya resmî bir çözüm yazmak zorunda kalmamalıdır. Yöneticiler raporu inceledikten sonra bu ayrıntıları ekleyebilir. Böylece mobil sorun bildirimi hızlı kalırken yöneticilerin işi düzenlemesi için alan oluşur.

Bir alanı yalnızca rapor onsuz ilerleyemiyorsa zorunlu yapın. Sorun türü genellikle gereklidir, çünkü raporun doğru yere yönlendirilmesine yardımcı olur. Hasar taleplerinde fotoğraf zorunlu olabilir, ancak yetersiz ışıkta güvenlik sorunu bildiren birini yavaşlatabilir. Notlar genellikle isteğe bağlı kalmalıdır.

Basit bir kural işinize yarar: Ekip üyesinin durması, bilgi araması veya bir cümleden fazlasını yazması gerekiyorsa bu alanı sonraki inceleme adımına taşıyın.

Formu gerçek bir örnekle test edin. Bir ekip üyesinden açık havada ve eldiven takarken kırık bir çiti bildirmesini isteyin. Bir alanda tereddüt ederse alanı yeniden adlandırın, kaldırın veya yazmak yerine bir seçim sunun. Amaç her sorunu evraka dönüştürmeden harekete geçmek için yeterli kanıt toplamaktır.

Rapor ekranını hızlı kullanıma göre tasarlayın

Bir ekip üyesinin tek eli boş olabilir, ekrana parlak güneş vurabilir ve hemen ilgilenilmesi gereken bir sorun bulunabilir. İlk ekran bir ofis formu gibi değil, birkaç dokunuştan oluşan basit bir akış gibi hissettirmelidir.

Üste yakın bir yerde büyük bir fotoğraf düğmesi gösterin, ardından ekiplerin yaptığı işlerle örtüşen kısa bir sorun türü listesi sunun. Bir bakım ekibi «Hasar», «Güvenlik sorunu», «Ekipman arızası» veya «Erişim sorunu» seçeneklerini kullanabilir. Boş kategori alanlarından kaçının. Çalışanlar sahada ofisin hangi ifadeyi beklediğini tahmin etmek zorunda kalmamalıdır.

İlk ekranı dört eyleme odaklayın:

• Fotoğraf eklemek veya çekmek
• Sorun türü seçmek
• Mevcut durumu belirlemek
• Raporu göndermek veya taslak olarak kaydetmek

«Yeni», «Devam ediyor» ve «Çözüldü» gibi görünür durum düğmeleri kullanın. Bir rapor için «Yeni» durumunu varsayılan yapın. Ekip lideri veya yönetici, iş atandıktan sonra durumu güncelleyebilir. Düğmeler, açılır menülerden genellikle daha kullanışlıdır, çünkü mevcut durum ekranda görünür kalır.

Notlar önemini korur, ancak ana eylemlerin altında yer almalı ve isteğe bağlı olmalıdır. Büyük ve zorunlu bir metin kutusu yerine «Gerekirse ayrıntı ekleyin» gibi bir yönlendirme daha iyi çalışır. Fotoğrafın bağlama ihtiyaç duyduğu durumda çalışan «3. kapının yanında su sızıntısı» yazıp devam edebilir.

Her dokunuş gerçek bir karara götürmelidir. Bir alan sonraki adımı etkilemiyorsa ilk ekrandan kaldırın ve daha sonra toplayın.

AppMaster, görsel arayüz oluşturucuları ve iş mantığı araçlarıyla bu tür bir mobil arayüz oluşturmanıza yardımcı olabilir. Ekipler kısa bir rapor formu hazırlayabilir, fotoğrafları ve durum değişikliklerini aynı sorun kaydına bağlayabilir ve ekipler uygulamayı gerçek koşullarda kullandıktan sonra ekranı düzenleyebilir.

Konumu ek iş çıkarmadan yakalayın

Hasarlı bir varlığı, kapalı bir erişim noktasını, güvenlik tehlikesini, teslimat sorununu veya tamamlanan işi bulmak onarım ekibine yardımcı olacaksa konum isteyin. Genel bir malzeme talebi ya da vardiya notu için konum gerekmeyebilir.

Bir raporun konuma ihtiyacı olduğunda uygulama, cihaz iznini bir kez istemeli ve ekip üyesi raporu başlattığında veya gönderdiğinde mevcut koordinatları almalıdır. Basit bir doğrulama gösterin: saha adı, adres veya küçük bir haritada pin. Çalışan koordinat yazmak ya da dışarıda adres aramak zorunda kalmamalıdır.

GPS, yüksek binaların yanında, depolarda, yer altında veya kötü hava koşullarında hatalı olabilir. Çalışanlara konumu kolayca düzeltme imkânı verin. Pini taşıyabilmeli, kayıtlı bir sahayı arayabilmeli veya bilinen konumlardan birini seçebilmelidir. Yöneticinin neyin değiştiğini görebilmesi için otomatik alınan konumu düzeltilmiş seçimle birlikte saklayın.

Yararlı olduğunda bir harita noktasından fazlasını saklayın: konum kaynağı, alınma zamanı, seçilen saha ve kısa bir konum notu. «Kuzey yükleme rampası», büyük bir tesisin ortasındaki bir pinden daha kullanışlıdır.

Aynı yerlere sık giden ekipler için seçenekleri sınırlı tutun. Sahada bulunan bir olayda cihaz konumunu kullanın, kayıtlı müşteriyi veya projeyi seçin, gerektiğinde pini taşıyın ve harita tam noktayı göstermiyorsa bir referans noktası notu ekleyin.

AppMaster'da ekipler onaylı sahaları uygulamanın veri modelinde tutabilir ve konum alma özelliğini fotoğraf ve sorun alanlarının yanına yerleştirebilir. Bu, tekrarlanan yazma işini azaltırken hatalı GPS okumasını düzeltmeye de imkân verir. Bir depo sızıntısında ekip üyesi fotoğraf çekebilir, «4. Bölme»yi seçebilir, pini yükleme kapılarının yakınına taşıyabilir ve raporu hızla gönderebilir.

Çevrimdışı taslakları iş akışının parçası yapın

Ekipler sık sık sinyalin kesildiği yerlerde çalışır: bodrumlar, uzak sahalar ve büyük tesislerin uzak bölümleri. Raporlama akışı, ekip üyesi çalışmaya başladığı anda taslağı cihaza kaydetmelidir. Birinin «Gönder»e basmasını beklemek risklidir. Bağlantının kesilmesi, uygulamanın çökmesi veya pilin bitmesi, yararlı bir raporu ikinci bir saha ziyaretine dönüştürebilir.

Sistem başarıyla gönderene kadar kaydedilen öğeyi taslak olarak kabul edin. Çalışanlar bağlantı olmadan fotoğraf çekebilmeli, sorun türü seçebilmeli, not ekleyebilmeli ve konum alabilmelidir. Cihaz bu ayrıntıları birlikte tutar; böylece kimsenin daha sonra hatırlamaya çalışması gerekmez.

Yükleme durumunu kolay anlaşılır yapın

Her raporun hangi aşamada olduğunu açık etiketlerle gösterin:

• Taslak: Rapor cihazda ve bilgi veya inceleme bekliyor
• Yükleme bekliyor: Rapor tamamlandı, ancak cihazda bağlantı yok
• Yükleniyor: Uygulama raporu gönderiyor
• Gönderildi: Merkez ekip raporu görüntüleyebilir
• Dikkat gerekiyor: Yükleme başarısız oldu; çalışan yeniden denemeli veya raporu kontrol etmeli

Ana ekrandaki küçük bir sayaç da yardımcı olur. «Yükleme bekleyen 3 rapor» ifadesi, ekibe bağlantının iyi olduğu bir sahadan ayrılmadan önce hatırlatma verir.

Cihaz yeniden bağlandığında, uygulama destekliyorsa tamamlanan raporlar arka planda otomatik olarak yüklenmelidir. Birkaç rapor bekliyorsa önce metin ve durumu gönderin, ardından fotoğrafları tek tek yükleyin. Rapor geçmişinde rapor numarası, sorun türü ve zamanla birlikte açık bir onay kalmalıdır. Raporu gönderen kişi ofisin raporu aldığını göstermek zorunda kalabilir.

Yayına almadan önce bu akışı gerçek koşullarda test edin. Telefonu uçak moduna alın, birkaç fotoğraflı bir rapor oluşturun, uygulamayı kapatıp yeniden açın ve bağlantıyı geri getirin. Rapor bozulmadan kalmalı ve telefon yeniden bağlandığında yüklenmelidir.

Sorun türlerini ve durum güncellemelerini ayarlayın

Sorun türleri ekiplerin normal vardiyada karşılaştığı durumlarla örtüşmelidir. «Diğer» veya «Sorun» gibi genel seçenekler dağınık kayıtlar oluşturur ve yöneticileri her notu okumaya zorlar. İnsanların en sık bildirdiği olaylarla başlayın, ardından birkaç haftalık kullanımdan sonra listeyi yenileyin.

Bir saha bakım ekibi hasarlı ekipman, güvenlik tehlikesi, kapalı erişim, sızıntı, eksik malzeme ve temizlik gerekiyor seçeneklerini kullanabilir. Bir altyapı ekibinin ise direk hasarı, sayaç sorunu, hizmet kesintisi veya kazı riski seçeneklerine ihtiyacı olabilir. Etiketleri hızlıca taranabilecek kadar açık tutun.

Uzun bir katalogdan kaçının. İnsanlar 25 tür arasında kaydırma yapmak zorunda kalırsa en yakın seçeneği işaretler veya raporu erteler. Başlangıçta genellikle beş ila on tür yeterli yapı sağlar. «Diğer» seçeneğini eklerseniz liste boşluklarını görebilmek için kısa bir not isteyin.

Her yeni rapora, genellikle «Yeni» olmak üzere varsayılan bir durum verin. Sahadaki kişinin yalnızca ne bulduğunu bildirmesi yeterlidir. Yönetici daha sonra işi önceliklendirebilir, atayabilir ve planlayabilir.

Durum menüsünü kısa tutun:

• Yeni: Rapor incelenmeyi bekliyor
• Atandı: Sonraki adımdan bir kişi sorumlu
• Devam ediyor: Çalışma başladı
• Çözüldü: Ekip işi tamamladı
• Kapatıldı: Yönetici sonucu kontrol etti

Yöneticiler rapor sayfasından sorumlu kişi ve teslim tarihi belirleyebilmelidir. Sorumlu kişinin kişisel iş listesine, raporu oluşturan kişinin de birinin sorumluluğu aldığını görmeye ihtiyacı vardır. Bu, sık karşılaşılan «Ben başkasının ilgilendiğini sanıyordum» sorununu önler.

Çalışanlar ilk raporu yeniden yazmadan hızlı güncellemeler de yapabilmelidir. Bir durum değişikliği, kısa yorum ve isteğe bağlı takip fotoğrafı çoğu zaman yeterlidir. Bir teknisyen, sızdıran vanayı iki fotoğrafla «Yeni» olarak bildirebilir. Onarımın ardından ekip lideri durumu «Çözüldü» yapıp değiştirilen parçanın fotoğrafını ekleyebilir.

AppMaster sorun türlerini kontrollü listelerde tutabilir, gönderim sırasında «Yeni» durumunu otomatik belirleyebilir ve yöneticilere atamalarla teslim tarihleri için ayrı bir görünüm sunabilir. Böylece ekip akışı hızlı kalırken yöneticiler açık işlerden oluşan net bir kuyruğu korur.

Basit bir ekip raporlama senaryosu

Bir bakım ekibi rutin ziyaret için bir depolama sahasına gelir. Girişin yakınında bir çalışan, bir aracın metal kapının alt çubuğunu eğdiğini görür. Kapı hâlâ kapanır, ancak artık düzgün kilitlenmez.

Çalışan raporlama uygulamasını açar ve yeni kayıt başlatır. Saha ziyareti zaten seçili olduğundan yazılacak fazla bir şey yoktur. «Hasarlı kapı»yı seçer, kapının tamamının bir fotoğrafını ve eğilmiş çubuğun başka bir fotoğrafını çeker, ardından önerilen harita pinini kontrol eder. Kısa not şöyledir: «Kapı kapanıyor, ancak mandal oturmuyor.»

Çalışan raporu «Yeni» durumuyla kaydeder. Sahada sinyal zayıftır, bu nedenle uygulama fotoğrafları, konumu ve zamanı içeren bir çevrimdışı taslak tutar. Ekibin formu yeniden doldurmasına veya ayrıntıları kâğıda yazmasına gerek kalmaz.

Telefon yeniden bağlandığında rapor yüklenir. Yönetici fotoğrafları ve konumu görür, onarımı atar ve durumu «Atandı» olarak değiştirir. Teknisyen kapıyı düzelttikten ve mandalı değiştirdikten sonra tamamlanma fotoğrafı ekler ve durumu «Çözüldü» yapar.

Tüm kayıt tek yerde kalır: sorunu kimin bildirdiği, nerede ve ne zaman gerçekleştiği, kimin ilgilendiği ve sonucun ne olduğu. Kapının yanında yapılan birkaç dokunuş, saatler sonra uzun bir açıklamanın yerini alır.

Ekipleri yavaşlatan hatalar

Bir saha raporlama uygulaması, ekip üyesinden masa başındaki biri gibi çalışmasını istediğinde başarısız olur. Hasarlı bir tabelanın, sızdıran borunun veya kapanmış erişim noktasının yanındaki kişi, çoğu zaman eldiven ve zayıf sinyalle sorunu hızla bildirebilmelidir.

Uzun açıklama alanları yaygın bir hatadır. Notu isteğe bağlı tutun ve bilgileri fotoğraf, sorun türü, konum ve basit durum kontrolleriyle toplayın. Çalışan gerektiğinde «Vananın yanında su» yazabilmeli, ancak uygulama kaydetmeden önce bir paragraf istememelidir.

Çok fazla sorun kategorisi aynı gecikmeye neden olur. İlk ekranda 25 etiket görünürse insanlar duraksar, en yakın seçeneği seçer veya işi sonraya bırakır. Günlük çalışmaya uyan küçük bir grupla başlayın ve ekip uygulamayı kullandıktan sonra listeyi geliştirin.

Kaydetme işlemini görünür kılın

Ekipler uygulamanın raporlarını saklayıp saklamadığını bilmelidir. Telefon bağlantısızken açık bir taslak etiketi, yeniden bağlandığında yükleme ilerlemesini ve gönderimden sonra onayı gösterin.

Durum kontrollerini de aynı hızda tutun. «Yeni», «Devam ediyor» ve «Çözüldü» gibi düğmeler, her seferinde insanlardan güncelleme yazmalarını isteyen bir ekrandan daha iyi çalışır. Kullanıcıların yalnızca iş gerektirdiğinde ayrıntı eklemesine izin verin.

Gerçek saha koşullarında test edin

Ofis Wi-Fi'ı üzerinden yeni bir telefonda çalışan rapor formu çok az şey kanıtlar. Eski telefonları, neredeyse dolu fotoğraf depolamasını, zayıf mobil veriyi, kısa bağlantı kesintilerini ve büyük görselleri test edin.

Yayına almadan önce bağlantı fotoğraf yüklenirken kesildiğinde uygulamanın tam bir taslak kaydedip kaydetmediğini, hangi raporların hâlâ yükleme beklediğini gösterip göstermediğini, biri Kaydet'e iki kez bastığında yinelenen kayıt oluşturup oluşturmadığını ve ekiplerin kamera, konum ve durum kontrollerini tek elle kullanıp kullanamadığını kontrol edin.

İlk sürümü dar kapsamlı tutun. Gerçek ekipler sürtüşmenin nerede olduğunu bir planlama toplantısından daha hızlı gösterir.

Yayına almadan önce hızlı kontroller

Uygulamayı yalnızca güvenilir Wi-Fi bulunan bir masada değil, ekiplerin çalıştığı yerlerde test edin. Bir veya iki çalışandan hasarlı tabela ya da sızdıran vana gibi gerçek ve küçük bir sorunu bildirmesini isteyin. Nerede duraksadıklarını, yanlış kontrole dokunduklarını veya yardım istediklerini gözlemleyin.

İlk ekran sorun türüne, fotoğrafa, isteğe bağlı nota ve gönderime odaklanmalıdır. Büyük kontroller ve mantıklı varsayılanlar kullanın. Çalışanların kaydetmeden önce uzun bir açıklama yazması gerekiyorsa raporlar geç gelir.

Yayın öncesi sinyal kaybı testi yapın. Bir rapor başlatın, fotoğraf ve konum ekleyin, ardından mobil veriyi kapatın. Uygulamanın taslağı kaydettiğini ve hâlâ gönderilmeyi beklediğini açıkça gösterdiğini doğrulayın. Bağlantı döndüğünde çalışanların hiçbir şeyi yeniden girmesi gerekmemelidir.

Yönetici görünümünü de aynı özenle kontrol edin. Her kayıtta ekli fotoğraflar, konum, sonraki adımdan sorumlu kişi ve güncel durum görünmelidir. Kapatma akışını da test edin. Sorunu çözen çalışan, atanan öğeyi açabilmeli, durumunu güncelleyebilmeli, gerekirse son fotoğrafı ekleyebilmeli ve birkaç dokunuşla kapatabilmelidir.

Uygulamayı AppMaster'da oluşturuyorsanız her değişiklikten sonra mobil iş akışını gerçek bir telefonda test edin. Görsel ekranları ve iş süreci kuralları alanlarla onaylar eklemeyi kolaylaştırır, ancak her ek adım sahada zaman kaybettirir. Birinin karar vermesine, atama yapmasına veya çözümü doğrulamasına yardımcı olmayan alanları kaldırın.

Küçük bir çalışan sürümle başlayın

İlk sürümü bir ekip ve yaygın bir iş türü için oluşturun. Bir haftalık normal kullanım, nelere dikkat etmeniz gerektiğini gösterir. Çalışanlardan olağan vardiyalarında fotoğraflar, konumlar ve durum değişiklikleri içeren gerçek raporlar göndermelerini isteyin.

Yalnızca birinin sorunu anlaması ve harekete geçmesi için ihtiyaç duyduğu ayrıntıları ekleyin: sorun türü, fotoğraf, konum, isteğe bağlı not ve mevcut durum. Bir yönetici bir alanı karar vermek için kullanamıyorsa şimdilik bu alanı eklemeyin.

Pratik bir deneme, beş bakım çalışanının beş gün boyunca saha sorunlarını bildirmesini içerebilir. Daha sonra raporları onlarla birlikte inceleyin. Boş alanları, tekrarlanan düzeltmeleri ve karışıklığa neden olan etiketleri arayın.

Bulduklarınıza göre doğrudan değişiklikler yapın: ekiplerin atladığı alanları kaldırın, belirsiz etiketleri yeniden adlandırın, ayırt edilemeyen sorun türlerini birleştirin, durumları ekibin kullandığı güncellemelerle sınırlayın ve çevrimdışı taslakların doğru kaydedilip gönderildiğini doğrulayın.

AppMaster, ekiplerin görsel Veri Tasarımcısı'nda rapor veri yapısını oluşturmasına, İş Süreci Düzenleyicisi'nde rapor kurallarını tanımlamasına ve kod yazmadan mobil ekranlar hazırlamasına imkân verdiği için böyle bir ilk sürüm için uygundur. Fotoğraf alanlarını, koordinatları ve «Yeni», «Atandı» ve «Düzeltildi» gibi durumları içeren odaklı bir uygulamayı destekleyebilir.

Deneme öncesinde her istisnayı tahmin etmeye çalışmayın. Ekipler yeni bir sorun türüne ihtiyaç duyabilir, yöneticiler ise iki durum etiketinin aynı anlama geldiğini fark edebilir. Gerçek raporları gördükten sonra iş akışını yenileyin. AppMaster, gereksinimler değiştiğinde uygulamaları yeniden oluşturur. Bu da ekiplerin eski kodu taşımadan uygulamayı güncellemesine yardımcı olur.

Denemeden sonra hangi ekranın çok uzun sürdüğünü ve ofisin hangi bilgileri hâlâ telefonla istemek zorunda kaldığını sorun. Bu boşlukları giderin, kısa bir test daha yapın ve ardından daha fazla ekibe genişleyin.