Teklif al

İş Süreç Takibi · Başakşehir

Başakşehir markaları için İş Süreç Takibi

Bir kalıp atölyesinin sitesine iki ayrı talep gelir: yeni iş için teklif isteyen ile elindeki kalıbın revizyonunu soran. İkisi de tek iletişim formuna düşer, aynı posta kutusunda karışır, hangisinin önce açılacağına kimse karar vermez. Başakşehir iş süreç takip yazılımı ararken sorulacak asıl soru budur: gelen talep hangi akışa düşüyor. Diotek'te bunu tanıtım sayfalarının içinde çözdük; iki talep tipi baştan ayrı akış olarak kuruldu ve ikisi de aynı Laravel uygulamasında duruyor.

İş Süreç Takibi — Başakşehir

Başakşehir'in dokusu İkitelli hattı makine imalatı ve kalıp atölyeleri. Ön büronuz tek masaysa aynı kişi hem yeni iş teklifini hem duran tezgâhın çağrısını karşılıyor; salonun gürültüsünde telefon duyulmuyor ve geri dönüş akşama kalıyor. Bu ilçenin sektör profiline en yakın işimiz Diotek. Klima ve havalandırma işi için yazıldı; üretim planlaması ve tezgâh doluluk takibi için gösterecek işimiz yok. Anlattığımız yer dar: talebin siteden hangi akışla girdiği ve operasyona nasıl ayrışmış hâlde ulaştığı. Altında Laravel çekirdek, MySQL kayıt ve Redis önbellek duruyor; arayüz tarafını Inertia ile Tailwind taşıyor. Ofisimiz yok, ekip tamamen uzaktan çalışıyor.

  • Teklif talebi ile revizyon çağrısı ayrı akışlarda ilerliyor; ikisi tek posta kutusuna düşmediği için operasyona ayrışmış hâlde ulaşıyor.
  • Talep kaydı ile tanıtım içeriği aynı MySQL şeması üzerinde duruyor; formu dışarıdan bir servise bağlayıp aynı bilgiyi iki yerde tutmak gerekmiyor.
  • Sayfa geçişini Inertia istemcide yapıyor, yönlendirme ve form doğrulaması Laravel'de kalıyor; talep eksik alanla açılmıyor.

Neden Algoriel

  • İnternet yokken de çalışır

    Saha uygulaması bağlantı yokken kaydı almaya devam ediyor; bağlantı gelince biriken kayıtlar sırasıyla sunucuya geçiyor. AlgoKlima'da böyle işliyor.

  • Cihaz yerine QR ve konum

    Sabit turnike kurulamayan yerlerde giriş ve çıkış QR kod ile konum okumasından alınıyor; hak ediş doğrudan bu okumalardan çıkıyor.

  • Kayıt akşama kalmıyor

    İş sahada kapanıyor; ofis günün sonunu beklemeden hangi işin hangi aşamada olduğunu görüyor.

  • Panel ve saha aynı yerden okur

    Ofisteki panel ile sahadaki uygulama aynı bilgiyi okuyor; yanında ikinci bir tablo tutmanız gerekmiyor.

Ne inşa ediyoruz

İş Süreç Takibi
  • Kaydın neye bağlandığı

    Süreci soyut bir harita olarak çizmek yerine kaydın neye bağlanacağını belirliyoruz. Şantiye personel takibinde bir satır personele ve sahaya birlikte bağlı, bu ikisi hiç ayrılmıyor. AlgoRandevu'da randevunun kişiye, odaya ya da ekipmana bağlanabildiği yapıyı şu an inşa ediyoruz.

  • Açık kalan kayıt

    Gerçek zamanlı gösterge yerine tek kural: eşleşen giriş ile çıkış süreyi üretir, çıkışı okutulmamış giriş açık kalır. İşin nerede takıldığı bu boşluktan görünür.

  • Kimin nerede olduğunun kayda geçmesi

    Bir satır hem kişiyi hem sahayı taşıdığı için toplamlar saha bazında ayrışıyor. Aynı personel ay içinde iki farklı şantiyede çalıştığında süreleri tek torbaya girmiyor.

  • İtiraz edildiğinde geriye kalan dayanak

    Hak ediş kayıt çiftlerinden üretildiği için ay sonunda tartışılan sayının arkasında zaman ve konum damgalı bir kayıt duruyor. Karşılaştırılacak paralel bir hesap tablosu yok; itiraz doğrudan kaydın üstünde konuşuluyor.

  • Kaydın kapsama dışında da alınması

    AlgoKlima'nın servis akışında zincir, ağın bittiği yerde kopmuyor. Bağlantı döndüğünde bekleyen kayıtlar oluşturulma sırasına göre işleniyor; aynı kayda sahadan ve ofisten gelen değişiklikler çakışma çözümüyle tek kayıtta birleşiyor.

  • Süreç kuralının koda gömülmemesi

    Bir adımın süresi ve arka arkaya diziliş aralığı gibi kurallar sektöre gömülmesin, ürün ayarı olarak kalsın istiyoruz; kural değiştiğinde yeni sürüm gerekmesin. Bu yapıyı AlgoRandevu'da şu an inşa ediyoruz.

Buna benzer çalışmalar

İş Süreç Takibi · Vaka çalışması

Diotek — keşif randevusu ve servis talebi ayrı akış, ikisi tek Laravel uygulamasında

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. Ziyaretçi cihaz seçmeden önce mekân için tarih isteyebiliyor; bu talep servis kuyruğuna karışmadan kendi akışında operasyona düşüyor. 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. Tanıtım sayfaları ile talep ekranları tek Laravel uygulamasında: Inertia sayfa geçişini istemcide yapıyor, yönlendirme ve doğrulama Laravel'de kalıyor, içerik ile talep kaydı aynı MySQL şemasında duruyor.

Vaka çalışmasını okuyun →

Başakşehir ekipleriyle uzaktan çalışmak

Ofisimiz yok; bu şehirdeki işleri de uzaktan yürütüyoruz ve yerinde destek vermiyoruz. Ne yapıldığı ve neden öyle yapıldığı yazılı duruyor. Ortaklıkla geliştirdiğimiz işler proje sayfalarında işaretli.

  • İlk sürüm çalışan bir parçayla çıkar, ek yetenekler sonra eklenir.
  • Bildiğimiz müşterilerimizin tamamı Türkiye'de.
  • Kararlar yazılı duruyor, ilerleme çalışan ekranlardan görünüyor.

Sık sorulan sorular

  • Sitemizde zaten bir iletişim formu var; neden ayrı akış kuralım?

    Tek formun sorunu görünürlük değil sıralama. Teklif isteyen ile duran tezgâhı için arayan aynı kutuya düştüğünde sırayı okuyan kişi belirliyor. Diotek'te iki talep tipi baştan ayrıldı; hangi alanların doldurulacağı da tipe göre değişiyor.

  • Talep formunu hazır bir dış servise bağlasak olmaz mı?

    Olur, ama o zaman kayıt sitenin dışında açılıyor ve içerikle aynı yerde durmuyor. Diotek'te talep kaydı ile tanıtım içeriği aynı MySQL şeması üzerinde; aramak, listelemek ve geçmişe bakmak için ikinci bir hesap açmak gerekmiyor.

  • Diotek klima işi; biz kalıp ve makine imalatı yapıyoruz. Bu bize ne söylüyor?

    Diotek'i klima ve havalandırma için yazdık, bunu olduğu gibi söylüyoruz. Taşınan şey sektör değil talebin biçimi: yeni iş ile mevcut ekipmanın revizyonu ayrı akışlar, ikisi tek uygulamada. Üretim planlaması ve tezgâh doluluk takibi bu kapsamın dışında.

  • Sezon başında talep yığılıyor; bu yük aynı sitede karşılanır mı?

    Diotek'te sezon başı trafiği aynı kod tabanında karşılanıyor, okuma yükünü Redis önbelleği alıyor. Kaç talebin karşılandığına dair bir rakam vermiyoruz; ölçmediğimiz şeyi yazmıyoruz.

Ay sonundaki sayının arkasında bugün ne duruyor?