Çevrimdışı çalışan saha uygulaması, kaydı iş yapılırken teknisyenin telefonunda oluşturan, sinyal yokken yerel kuyrukta bekleten ve sinyal dönünce merkezdeki sisteme aktaran mobil yazılımdır. Kaydın nerede doğacağı veri modelinde kararlaştırılır; kimliği, sırası ve çakışma davranışı da orada tanımlanır. AlgoKlima’da kuyruğu boşaltan şey bağlantının geri dönmesidir; kayıtlar sahada açıldıkları sırayla merkeze ulaşır, ayrı bir gönder adımı yoktur.
Kayıt, iş yapılırken sahada doğar
AlgoKlima’da servis kaydı, teknisyen işi yaparken sahadaki telefonda oluşturulur; ofise sonradan anlatılarak girilmez. Kaydın doğduğu yer dediğimizde kastettiğimiz bu: bilginin ilk kez yazıldığı yer. Bu, ürünün kuruluş kararlarından biri.
Öncesi tanıdık. Klima, kombi ve beyaz eşya servislerinde müşteri, cihaz ve teknisyen birbirinden ayrı yerlerde izleniyor: ofiste bir tablo, teknisyende bir defter, ikisinin arasında telefon trafiği. Teknisyen gün içinde ne yaptığını akşam anlatıyor, ofis de anlatılanı yazıyor. Aradaki her aktarım bilgi eksiltiyor. Hangi parça takıldı, cihazın seri numarası neydi, müşteri şikâyeti nasıl tarif etti: hepsi hatırlanmaya kalıyor.
Aynı kopukluğun ikinci yüzünü şantiye personel takip sisteminde gördük. Orada kayıt kâğıt puantajda tutuluyordu. Ay sonunda kimin hangi sahada ne kadar çalıştığı doğrulanamıyor; elde kalan tek dayanak, olaydan haftalar sonra imzalanmış bir kâğıt. İtiraz çıktığında tartışılan şey artık iş değil, kâğıdın kendisi oluyor.
İki durumda da kaybolan şey ayrıntı. Ofise ulaşan bilgi, olayın kendisi değil hatırlanan hâli; hatırlananın ne kadarının doğru olduğunu ölçecek bir dayanak da yok. Kayıt sonradan üretilince tartışma kaydı üretenin belleğine kayıyor.
İki işin çözümü de aynı yerden başladı: kayıt, iş yapılırken sahadaki telefonda oluşturuluyor. Sonrasında ne olduğu, yani hangi veritabanına yazıldığı, hangi ekranda göründüğü ve hangi rapora düştüğü, bu ilk adımın sonucu.
Kapsama alanı kazan dairesinde biter, iş orada bitmez
AlgoKlima’nın teknisyenleri fiilen kazan dairesinde ve asansör boşluğunda çalışır; bu noktalarda bağlantısızlık bir arıza değil, saha işinin olağan koşuludur.
Pratikteki anlamı şu: iş tam olarak bağlantının olmadığı noktada yapılıyor. Servis çağrısı bir kombinin başına gidiyor, kombi kazan dairesinde duruyor, kazan dairesi binanın en alt katında. Asansör boşluğu da aynı sınıfta. Sinyalin kaybolması, işin geçtiği yerin doğal bir özelliği.
Uygulamayı buna göre kurmak, soruyu değiştirmek demek. “Bağlantı koparsa ne yaparız” bir hata senaryosu tarif eder; cevabı da genelde bir uyarı ekranı olur, çünkü sorun geçici sayılmıştır. “Bağlantı yokken nasıl çalışırız” ise doğrudan veri modeline dokunur; cevabı bir ekran değil, kaydın nerede tutulacağıdır. İki soru aynı ürünü üretmiyor.
Aradaki fark yaygın bir uygulama alışkanlığında da görünür. Formu bellekte tutup arka planda yeniden denemek, bağlantıyı hâlâ zorunlu sayar: deneme başarısız olduğunda kayıt hâlâ hiçbir yere ait değildir. Kaydın telefonda yazılması ise bağlantıyı kaydın varlık koşulu olmaktan çıkarır. Birincisinde bağlantı gecikmiş, ikincisinde gereksizleşmiştir.
Farkı teknisyenin eli gösteriyor. Bağlantı bekleyen bir form, teknisyeni tam işini yaparken durduruyor. Kayıt girilemeyince iki seçenek kalıyor: ya iş bekliyor ya kayıt sonraya erteleniyor. İkincisi seçildiğinde bir önceki bölümdeki probleme geri dönülüyor: akşam ofiste anlatılan iş, yarısı eksik.
Karşı durum da açık. İşin tamamı kapsama içinde ve masa başında dönüyorsa çevrimdışı katman gereksiz karmaşıklıktır. Showroom’da tablet başında çalışan bir ekip için yerel kuyruk kurmak, bakımı olan ama karşılığı olmayan bir yapı bırakır. Belirleyici olan sektör değil, ekibin fiilen durduğu yer.
Bağlantı yokken kayıt telefonun yerel kuyruğuna yazılır
AlgoKlima’nın saha uygulamasında bağlantı yokken açılan kayıt önce telefonun yerel kuyruğuna yazılır ve uygulamanın geri kalanı için tamamlanmış bir kayıt sayılır.
Teknisyen kapsama dışında kayıt açıp kapatıyor. Uygulama bağlantı beklemeden çalışmaya devam ediyor, çünkü yazma işlemi hedefini telefonun içinde buluyor. Bu bir kuruluş kararı: kaydın ilk nerede yazıldığını belirlediği için sisteme sonradan eklenemez. Sunucuya yazan bir uygulamayı çevrimdışı çalışır hâle getirmek yeni bir ekran açmak değildir; kaydın kimliğini, sırasını ve çakışma davranışını baştan tanımlamayı gerektirir.
Kuyruktaki kaydın statüsü belirleyici. Uygulamanın geri kalanı için o kayıt tamamlanmıştır: teknisyen bir sonraki işe geçer, kuyruk arka planda bağlantıyı bekler. Ekranda “gönderilemedi” uyarısı çıkmaz; uyarının yokluğu sorumluluğun yerini gösteriyor. Teknisyenin işi kaydı doğru tutmak, taşımak uygulamanın işi.
Kaydın telefonda yazılmasının ikinci sonucu sıra bilgisi. Kayıt orada oluştuğu için ne zaman oluştuğu da orada belli oluyor; sunucu bu bilgiyi sonradan tahmin etmek zorunda kalmıyor. Sunucuda oluşturulan bir kayıtta sıra, verinin ulaştığı ana göre kurulur; sahada art arda yapılan iki iş ofise ters sırayla düşebilir.
Karşı durum burada da var. Kuyruk modeli, kaydın ofiste anında görünmesini şart koşan işler için uygun değildir. Çağrı merkezi sahadaki adımı canlı izlemek zorundaysa kuyruk bir gecikme üretir. Bu bekleme mekanizmanın hatası değil, tanımı; onu ortadan kaldırmak isteyen iş, çevrimdışı çalışmadan da vazgeçiyor demektir.
Üç ayrı saha koşulunun kaydı nasıl oluşturduğunu yan yana koyalım.
| Saha koşulu | Kayıt nerede ve nasıl açılır | Kayıt merkeze ulaşınca ne olur |
|---|---|---|
| Kapsama alanı dışında servis noktası (kazan dairesi, asansör boşluğu) | Teknisyen kaydı sahada açıp kapatır; kayıt önce telefonun yerel kuyruğuna yazılır | Bağlantı dönünce kuyruk oluşturulma sırasıyla boşalır; ofis ve saha değişiklikleri çakışma çözümüyle tek kayıtta birleşir |
| Geçici şantiye — sabit donanım kurulamaz, personel sahalar arasında dolaşır | Giriş kaydı QR okutma anında personelin telefonunda açılır; saha bilgisi kayda o anda yazılır | Laravel kaydı alır, MySQL tutar; süre eşleşen giriş-çıkış çiftinden çıkar, açık giriş eksik kayıt olarak görünür |
| Atölye — iş aracın girişiyle başlar, kayıt zinciri içeride ilerler | İş emri açılır, tüketilen parça o emre yazılır | Parça yazıldığı anda stoktan düşer, fatura aynı kayıttan kesilir; maliyet ve gelir aynı sistemde kapanır |
Üç satırın ortak yanı, kaydın oluştuğu anın işin yapıldığı anla çakışması. Farklı olan, kaydın merkeze ne taşıdığı.
Bağlantı dönünce kuyruk oluşturulma sırasına göre boşalır
AlgoKlima’da senkronizasyonu tetikleyen şey teknisyenin tuşa basması değil bağlantının geri dönmesidir; kuyruk, kayıtların oluşturulma sırasına göre merkeze boşalır.
Sıranın korunması olgusal bir gereklilik. Teknisyen bir binada art arda birkaç kayıt açıp kapatıyor. Bunlar merkeze aynı sırayla ulaşmazsa olayların kronolojisi bozulur; hangi arızanın hangisinden önce görüldüğü, hangi parçanın hangi işte kullanıldığı sıraya bağlı bilgiler.
Sıra kuralının pratik karşılığı şu: aynı adreste birden çok cihaza bakan bir teknisyen, her cihaz için ayrı kayıt açıyor. Bu kayıtlar merkeze rastgele bir düzende ulaşsaydı, hangi işin hangisinden sonra yapıldığı ancak saat alanına bakılarak kurulabilirdi. Kuyruk sırayı zaten taşıdığı için ofis tarafında ek bir düzeltme adımı gerekmiyor.
Ayrı bir gönder adımı yok, olmaması da tercih. Gönderme elle yapılsaydı akşam toplu veri girişi problemi kılık değiştirip geri gelirdi: bu kez akşam toplu gönderme olarak. Kaydın sahada yazılmasıyla kazanılan şey, taşıma adımı kullanıcıya bırakıldığında kaybedilir.
İki taraf aynı kaydı değiştirirse çakışma tek kayıtta birleşir
AlgoKlima’da ofis panelinden ve saha uygulamasından aynı kayda gelen değişiklikler çakışma çözümüyle tek kayıtta birleşir.
Durum sık yaşanıyor. Teknisyen kapsama dışındayken ofis aynı işi güncelliyor: randevu saati kayıyor, müşteri telefonda ek bir talep söylüyor, adres notu düzeltiliyor. İki taraf birbirinden habersiz aynı kaydı değiştiriyor ve ikisinin de haklı bir gerekçesi var.
Bağlantı döndüğünde sahadan ve ofisten gelen değişiklikler çakışma çözümüyle tek kayıtta birleşiyor. Kullanıcı tarafındaki karşılığı şu: çakışma bir hata olarak teknisyene devredilmiyor, birleştirme senkronizasyonun olağan bir adımı olarak işliyor.
Alternatifi düşünmek mekanizmayı anlaşılır kılıyor. Çakışmayı kullanıcıya sormak, yani sahadaki hâli mi tutalım ofistekini mi diye sormak, kararı kapsama alanına yeni girmiş, aklı bir sonraki işte olan teknisyene bırakır. Üstelik soru, iki değişikliğin de yerinde olduğu durumlarda yanlış bir seçim dayatır: birini seçmek diğerini silmektir. Birleştirme bu yüzden hem daha az soru sorar hem daha az veri kaybeder.
Sınırı da yazalım. Çakışma çözümü kayıt düzeyinde çalışır. İki tarafın aynı anda çelişen iş kararları vermesi, örneğin aynı işin iki teknisyene atanması, yazılımın çözeceği bir durum değil; operasyonun. Yazılım kaydı tekilleştirir, kararı tekilleştirmez.
Sahada açılan kayıt zinciri kırmaz: parça ve fatura aynı kayıttan yürür
AlgoCar’da tüketilen parça iş emrine yazıldığı anda stoktan düşer ve fatura aynı kayıttan kesilir.
Sahada yazılan kaydın değeri, yazıldığı anda bitmiyor. Asıl soru kaydın sonrasında ne olduğu: aynı bilgi ikinci kez giriliyor mu, yoksa zincirin geri kalanı o kayıttan mı yürüyor.
AlgoCar’da zincir tek kayıttan yürüyor. İş emri açılıyor, tüketilen parça o emre yazılıyor, fatura aynı kayıttan kesiliyor. Parça iş emrine yazıldığı anda stoktan düşüyor; depo hareketi ayrı bir ekranda ikinci kez elle girilmiyor. Bir işin maliyeti ile geliri ay sonunda iki programda eşleştirilmiyor, çünkü ikisi zaten aynı kaydın üstünde duruyor. Parçanın stoktan düşüşü iş emrine bağlı olduğu için fatura tarafına sonradan bir köprü kurmak da gerekmedi.
Bunun saha tarafıyla bağı doğrudan. Kayıt sahada yazılıp merkeze ulaştığında, oradan sonrası ya yeni bir veri girişi turudur ya da zincirin devamı. İkincisi olabilmesi için kaydın yapısının baştan buna göre kurulmuş olması gerekiyor.
Bir sınırı burada belirtelim. AlgoCar bir atölye yazılımı; iş aracın rampaya çıkmasıyla başlıyor ve kayıt zinciri atölyenin içinde ilerliyor. Bu bölüm çevrimdışı çalışmayı AlgoCar’a atfetmiyor, sahada yazılan kaydın sonraki değerini gösteriyor: kayıt ilk nerede yazılırsa yazılsın, ondan sonrasının tek zincirde yürüyüp yürümediği ayrı bir tasarım sorusudur.
Ters düzen tanıdık: iş emri bir programda, parça deposu başka bir programda, fatura üçüncü bir yerde. Burada sahada yazılan kayıt bile ofiste yeniden yazılıyor. Çevrimdışı çalışmayla kazanılan tek şey, verinin daha erken ama yine bir kez daha girilmesi oluyor; mekanizma çalışıyor, kazancı zincirin ikinci halkasında geri veriliyor.
Geçici sahada kayıt cihaza değil personelin telefonuna bağlanır
Şantiye personel takibinde giriş kaydı, QR okutma anında personelin telefonunda açılır; şantiye kapanınca sökülecek bir turnike kurulmaz.
Şantiye geçici bir saha. Sabit turnike kurmak, şantiye kapanınca onu sökmek demek. Personel de tek bir sahaya bağlı değil; hafta içinde başka bir şantiyede olabiliyor. Kayıt cihaza bağlansaydı saha kapandığında kayıt altyapısı da sökülecekti, üstelik personel sahalar arasında dolaştıkça hangi cihazın hangi kaydı tuttuğu ayrı bir soru hâline gelirdi.
Kayıt personelin telefonunda açılıyor. QR kod okutulduğu anda giriş kaydı oluşuyor ve hangi sahada olunduğu kayda o anda yazılıyor; saha adı bir listeden elle seçilmiyor. Şantiye kapandığında sahada sökülecek donanım kalmıyor, çünkü sahaya baştan bir şey kurulmadı.
Süre eşleşen giriş ve çıkış kaydından çıkıyor. Açık kalan bir giriş, çıkışı okutulana kadar eksik kayıt olarak görünür duruyor. Kapanmamış kayıt sessizce tamamlanmıyor; eksikliği ekranda kalıyor.
Donanım kararının ikinci yüzü hareketle ilgili. Sabit bir okuyucu kaydı geçtiği noktaya bağlar; personel o noktadan geçmediğinde kayıt da oluşmaz. Telefon ise personelle birlikte geziyor, bu yüzden aynı kişinin farklı şantiyelerdeki kayıtları ayrı ayrı duruyor.
Karşı durum burada da net. Tek ve kalıcı bir tesiste, personel sabit ve giriş noktası tekse telefon merkezli modelin geçicilik avantajı ortadan kalkar. Orada sabit bir okuyucu daha az hareketli parça demektir. Bu model, geçici sahanın modeli.
Ofis paneli ve saha uygulaması aynı veritabanını okur
AlgoKlima’da ofis paneli Laravel ve Inertia ile, saha uygulaması React Native (Expo) ile çalışır; ikisi de Redis’in önbellek taşıdığı aynı MySQL veritabanına bağlanır.
Bu, mekanizmanın nerede durduğunu söylüyor. Çevrimdışı kuyruk ayrı bir sistem değil; aynı sistemin saha ucu. Ofis paneli ile saha uygulaması ayrı kopyalar tutmuyor, aynı müşteri ve cihaz kaydını okuyor. Ayrı kopyalar tutulsaydı hangi kopyanın doğru sayılacağı sorusu sistemin ortasına sonradan yazılmak zorunda kalırdı.
Aynı düzen şantiye tarafında da işliyor: React Native (Expo) uygulaması personelin telefonunda çalışıyor, Laravel kayıtları alıyor, MySQL tutuyor. Desen tek bir projeye özgü değil. Masadan çıkan her telefon uygulamasını React Native (Expo) ile kuruyoruz ve hepsi ofis tarafıyla aynı Laravel uygulamasına bağlanıyor. Yığını proje başına değiştirmiyoruz; yıllarca bakabileceğimiz tek bir set üzerinde kalıyoruz.
Tek yığında kalmanın buradaki karşılığı somut. Saha uygulaması ile ofis panelinin aynı veritabanını okuması, kuyruğun boşalttığı kaydın ikinci bir dönüşüme girmeden yerine oturması demek. İki taraf ayrı sistemlerde dursaydı, kuyruğun ucunda bir aktarım katmanı daha olurdu ve çakışma çözümü o katmanın da hesaba katılmasını gerektirirdi.
Yerel kuyruğun tasarlandığı yer mobil uygulama tarafı: kaydın telefonda nasıl yazılacağı, hangi sırayla taşınacağı ve çakışmanın nasıl kapanacağı orada kararlaştırılıyor. Sahada yazılan kaydın ofis panelindeki karşılığı ise iş süreç takibi tarafında duruyor; aynı kayıt, yetkisi farklı bir yüzeyden okunuyor.
Bir saha uygulamasını değerlendirirken sorulacak soru bu yüzden tek: kayıt nerede doğuyor. Cevap telefonsa bağlantı bir koşuldur ve kesildiğinde iş devam eder. Cevap sunucuysa bağlantı bir bağımlılıktır ve kesildiği anda kaydın kendisi kaybolur.
