Sistemin parçaları ve sınırları koddan önce belirleniyor.
Birden fazla kurum tek sistemde, bilgileri ayrı.
Tek kod tabanı, iki mağaza: iOS ve Android.
Yürüyen bir sistemi devralıp iyileştiriyoruz.
Yapay zekâyı yalnız işin gerektirdiği yerde.
Klima ve havalandırma işinde siteye iki ayrı talep geliyor: satış öncesi keşif randevusu ve montaj sonrası servis. İkisi baştan ayrı akış olarak kuruldu; tanıtım sayfalarıyla aynı Laravel uygulamasında duruyor, talepler operasyona ayrışmış halde ulaşıyor.
Siteyi görüntüle →Diotek klima ve havalandırma işi yapıyor. Bu işte siteye gelen talep tek tip değil: biri satış öncesi keşif randevusu, çünkü cihaz kapasitesi mekâna bağlı ve firma karar vermeden önce yeri görmek zorunda; diğeri montaj sonrası bakım ve arıza.
Eskiden ikisi de aynı telefon hattından geliyordu. Sezon başında üst üste bindiklerinde hangi talebin ne olduğu ancak konuşarak anlaşılıyor, hat meşgulken gelen ziyaretçi kayboluyordu. Klima, kombi ve beyaz eşya servisleri için AlgoKlima’yı kendi ürünümüz olarak geliştiriyoruz; keşif randevusunun bir bakım çağrısı gibi davranamayacağını bu yüzden işe başlamadan biliyorduk.
İşin bugün nasıl yürüdüğünü ve yazılımdan ne beklediğinizi konuşuyoruz; kapsam buradan çıkıyor.
Sistemin hangi parçalardan kurulacağına ve bilginin nerede tutulacağına karar veriyoruz.
Ekranları ve akışı kod yazmadan önce çiziyoruz; onayınızdan sonra geliştirmeye geçiyoruz.
Yazılımı, başka bir ekibin de sürdürebileceği düzende yazıp teslim ediyoruz.
Ziyaretçi cihaz seçmeden önce mekân için bir tarih istiyor; talep, montaj sonrası servis kuyruğuna karışmadan kendi akışında operasyona düşüyor.
Montaj sonrası bakım ve arıza talebi kurulu cihazı merkeze alarak siteden açılıyor; kayıt yazılı kalıyor, telefon notuna bağlı olmuyor.
Inertia sayfa geçişini istemcide yapıyor, yönlendirme ve form doğrulaması Laravel'de kalıyor; talep kaydı ile içerik aynı MySQL şeması üzerinde duruyor.
Redis önbelleği sezon başı trafiğini aynı kod tabanında karşılıyor; kurumsal sayfalar ve talep ekranları aynı Tailwind ölçeğinde duruyor.
| Zorluk | Sonuç |
|---|---|
| Cihaz kapasitesi mekâna bağlı; firma teklif vermeden önce yeri yerinde görmek zorunda | Ziyaretçi cihaz seçmeden önce mekân için keşif randevusu isteyebiliyor |
| Keşif randevusu mekânı, servis talebi kurulu cihazı merkeze alıyor; ikisi aynı form değil | Montaj sonrası bakım ve arıza talebi kendi akışından, siteden açılıyor |
| Sezon başında iki talep üst üste biniyor, hangisinin ne olduğu konuşarak anlaşılıyor | Sezon başında iki talep tipi operasyona ayrışmış halde ulaşıyor, hangisi ne diye sorulmuyor |
| Hat meşgulken gelen ziyaretçi kayboluyor; site bu akışın dışında duran bir vitrin | Talep girişi telefon hattına bağlı değil; hat meşgulken gelen ziyaretçi de yazılı kayıt bırakıyor |
Atölyeye gelen aracın etrafında kurduğumuz kendi servis yönetim yazılımımız. İş emri, tüketilen parça ve kesilen fatura tek zincirde ilerliyor; işletme ve muhasebe tarafı da aynı kayda bağlı. Bakım geçmişi plaka ve şasi kaydında durduğu için araç el değiştirdiğinde geçmişi kendisiyle geliyor.
Klima, kombi ve beyaz eşya servisleri için geliştirdiğimiz kendi ürünümüz. Ofisteki müşteri ve cihaz kaydıyla sahadaki teknisyen aynı sistemde buluşuyor. Teknisyen telefon çekmeyen bir kazan dairesinde de servis kaydını açıp kapatabiliyor; garanti ve bakım geçmişi cihaza bağlı kalıyor.
Kendi ürünümüz; geliştirme aşamasında, henüz yayında değil. Bir randevunun ne kadar sürdüğü, neye bağlandığı ve arka arkaya nasıl dizildiği sektöre göre değişiyor. Bu kuralları koda gömmek yerine ürün ayarı olarak bırakıyoruz.
İşin bugün nasıl yürüdüğünü yazın; yazılıma hangi adımın geçebileceğine bakalım.
