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.
Elektrikli ısıtıcı üreticisi için bir seçim ve teklif yazılımı. Kullanıcı ürün kodu değil ısıtma ihtiyacını giriyor; mühendislik hesabını yazılım yapıyor, hesabın seçtiği ürün de doğrudan teklifin bir kalemi oluyor.
Siteyi görüntüle →Resterm elektrikli ısıtıcı üretiyor. Bir ısıtıcının doğru seçilmesi mühendislik hesabı gerektiriyor; teklifin yazılması ise ticari bir iş ve bu ikisi çoğu yerde iki ayrı masada duruyor. Yazılımın asıl işi de hesabı yapmaktan çok, o iki masayı birbirine bağlamaktı.
İş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.
Girdi, ısıtılacak işin kendi ihtiyacı; bir katalog kodu aranmıyor. Yazılım mühendislik hesabını yapıp uygun elektrikli ısıtıcıyı seçiyor.
Hesabın seçtiği ısıtıcı sepete düşüyor; sepet bir projeye, proje o projenin müşterisine bağlanıyor, kayıtlar MySQL'de tek zincirde duruyor.
Teknik seçim ile ticari kalem arasında elle veri taşınmıyor; bir teklifin hangi ısıtma ihtiyacı girdisinden çıktığı geriye doğru okunabiliyor.
Yazılımı Resterm'in kendi ürün yapısı üzerine kurduk; hazır bir teklif aracına sonradan katalog eklenmiş hâli değil. Hesap ve kayıtlar Laravel'de, arayüz Vue'da.
| Zorluk | Sonuç |
|---|---|
| Isıtıcı seçimi hesap istiyor, ama teklifi hazırlayan kişi çoğunlukla hesabı yapan kişi değil | Kullanıcı ısıtma ihtiyacını giriyor, uygun ısıtıcıyı yazılım hesaplayıp seçiyor |
| Hesap bir tabloda, katalog bir dosyada, teklif üçüncü bir yerde tutuluyor | Hesap, katalog ve teklif aynı zincirde duruyor; üçü ayrı yerlerde tutulmuyor |
| Seçim ile teklif kalemi kopunca hangi kalemin hangi hesaba dayandığı kayboluyor | Bir teklifin hangi ihtiyaç girdisinden çıktığı geriye doğru okunabiliyor |
| Genel amaçlı teklif aracına katalog eklemek üreticinin kendi ürün yapısını taşımıyor | Katalog, üreticinin kendi ürün yapısıyla duruyor; genel bir araca sonradan eklenmedi |
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.
