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.
Tedavi planı diş bazında kuruluyor ve haftalara yayılan seanslara bölünüyor. Randevu, planın hangi adımının ne zaman yapılacağına bağlı; plan değişince takvim de kayıyor. Fatura ve raporlar aynı hasta kaydından türüyor.
Diş tedavisi tek randevuda bitmiyor. Plan diş bazında kuruluyor, haftalara yayılan seanslara bölünüyor, arada değişiyor. Bir diş sağlığı kliniği bu düzeni genel amaçlı bir randevu yazılımıyla yürütmeye çalışıyordu: yazılım saati tutuyor, planı tutmuyordu.
Hastanın planın neresinde olduğu takvimden, hangi işlemin faturalandığı defterden, ay sonu tablosu üçüncü bir yerden çıkıyordu. Kliniğin istediği ayrı modüller değildi; tedavi planının, randevunun ve faturanın aynı hasta kaydı üzerinde durmasıydı.
İş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.
Plan hangi dişe hangi işlemin yapılacağını sıralı seanslara bölerek tutuyor; tedavi randevudan bağımsız, kendi başına duran bir kayıt.
Her randevu planın belirli bir adımına bağlanıyor; adım değiştiğinde ya da seans eklendiğinde takvim de buna göre kayıyor.
Fatura kendi defterinde durmuyor: yapılan işlem hasta kaydında olduğu için faturalanan ile uygulanan tedavi aynı yerden okunuyor.
Raporlar aynı hasta kaydını farklı bir açıdan okuyor; ay sonu tablosu için ikinci bir yere veri girilmiyor.
| Zorluk | Sonuç |
|---|---|
| Diş tedavisi tek randevuda bitmiyor; plan diş bazında kuruluyor, haftalara yayılan seanslara bölünüyor | Tedavi planı diş bazında kuruluyor, seans sırası plan üzerinde duruyor |
| Genel amaçlı randevu yazılımı saati tutuyor, tedavi planının hangi adımında olunduğunu tutmuyor | Plan değiştiğinde takvim de değişiyor, randevu boşta kalan bir kayıt olmuyor |
| Klinik yöneticisi planı takvimden, faturayı defterden, ay sonu tablosunu üçüncü bir yerden çıkarıyor | Klinik yöneticisi planı, randevuları ve faturayı aynı hasta kaydından okuyor |
| Yapılan işlem ile kesilen fatura ayrı defterlerde durduğunda raporlama elle birleştirmeye kalıyor | Rapor da aynı kayıttan çıkıyor; işlemle faturayı elle karşılaştırmak gerekmiyor |
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.
