“Bizim süreç özel” cümlesi her şirkette kuruluyor. Bir kısmında doğru, çoğunda alışkanlık.
İki tarafın da haklı olduğu yer
Hazır paketi savunan taraf şunu söylüyor: bu yazılımlar yüzlerce şirkette kullanıldı, süreç zaten oturmuş, siz de uyum sağlayın. Kurulum hızlı, maliyet öngörülebilir, güncellemeler sorunsuz geliyor.
Uyarlamayı savunan taraf ise şunu söylüyor: bizim işimizin kendine has yanları var, standart akış bunu karşılamıyor, yazılım işe uymalı, iş yazılıma değil.
İkisi de haklı ve mesele hangisinin haklı olduğu değil. Mesele, sizin sürecinizin hangi bölümünün gerçekten özel olduğu.
Çünkü her şirkette “bizde şöyle yapılır” denen şeylerin bir kısmı gerçek bir iş gereği, bir kısmı ise sadece uzun süredir öyle yapılıyor olması.
Gerçekten özel olan ile alışkanlık olanı ayırmak
Ayrımı yapmanın pratik bir yolu var: bu kural neden var, sorusunu üç kez sorun.
“Talepler önce Ayşe Hanım’a gider.” Neden? “Çünkü o kontrol ediyor.” Neyi kontrol ediyor? “Malzeme adı doğru mu, miktar mantıklı mı.” Bu bir uyarlama gereği değil; malzeme ağacı kurulduğunda o kontrolün konusu ortadan kalkıyor.
Buna karşılık: “Talepler proje müdürünün onayından geçer, ama sözleşmesi maliyet artı olan projelerde ayrıca işveren temsilcisine gider.” Bu bir iş gereği. Sözleşme yapınızdan doğuyor ve kaldırılamıyor.
Birincisi mevcut sistemin eksikliğini kapatmak için kurulmuş bir insan adımı. İkincisi işin kendisinden gelen bir kural.
Uyarlama kararı ikinciler için verilmeli. Birinciler yazılım kurulduğunda kendiliğinden yok oluyor ve onlar için uyarlama yaptırmak, çözülmüş bir sorunu kalıcı hale getirmek oluyor.
Uyarlama gerçekten gereken üç alan
Sahada tekrar tekrar karşımıza çıkan üç başlık var. Bunlar genelde uyarlama hak ediyor.
Onay kuralları. Standart paketler tutar ve departman üzerinden onay veriyor. Projeye, masraf merkezine, malzeme sınıfına ya da sözleşme tipine göre onay isteyen bir yapı standart akışa sığmıyor. İnşaat ve proje bazlı çalışan şirketlerde bu neredeyse kural.
Sektöre özgü belge ve alanlar. İlaç ve gıdada parti ve son kullanma tarihi, metal sektöründe döküm sertifikası, inşaatta poz numarası. Bunlar kalem üzerinde taşınması gereken bilgiler ve standart alanlarla karşılanmıyor.
Dış sistem bağlantıları. Kendi üretim takip sisteminiz, müşteri portalınız ya da özel bir raporlama aracınız varsa bağlantı yazılması gerekiyor.
Bunların dışında kalan taleplerin çoğu, ekran düzeni ve alışkanlık kaynaklı oluyor.
Uyarlamanın görünmeyen bedeli
Uyarlamanın maliyeti teklifteki rakam değil. Asıl bedel sonraki yıllarda çıkıyor.
Sürüm yükseltmesi zorlaşıyor. Standart üründe yeni sürüm geliyor ve kuruluyor. Uyarlanmış üründe her yükseltmede uyarlamaların çalışıp çalışmadığı test ediliyor, bir kısmı yeniden yazılıyor.
Destek yavaşlıyor. Sorun çıktığında standart üründe cevap hazır oluyor. Uyarlanmış kısımda önce ne yapıldığına bakılıyor.
Ve bilgi kişiye bağlanıyor. Uyarlamayı yapan ekip ya da danışman değiştiğinde o kodu kimse tanımıyor.
Bu yüzden pratik bir ölçüt işe yarıyor: uyarlama, işin kendisinden geliyorsa yapılır; ekran alışkanlığından geliyorsa yapılmaz.
Üçüncü yol: ayarla çözmek
Son yıllarda ikisinin arasında bir alan büyüdü ve karar tablosunu değiştirdi.
Modern satın alma yazılımlarında eskiden kod gerektiren birçok şey artık ayar seviyesinde yapılabiliyor. Onay kurallarının tanımlanması, ek alan eklenmesi, form düzeninin değiştirilmesi, bildirim kurgusu. Bunlar geliştirme değil, yapılandırma.
Aradaki fark önemli: yapılandırma sürüm yükseltmesinde korunuyor, geliştirme korunmuyor.
Bu yüzden teklif alırken sorulacak soru “uyarlanabilir mi” değil, “bu ihtiyaç ayarla mı çözülüyor, kod yazılarak mı” olmalı. Cevap teklifin fiyatını da, üç yıl sonraki halinizi de belirliyor.
Low-code yaklaşımı tam olarak bu aralığı büyütmek için var: standart ürünün kapsamadığı akışları, sıfırdan yazılım projesine dönüştürmeden kurmak.
On dört uyarlama istendi, üçü gerçekten gerekliydi
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Bu tabloyu neredeyse her kurulumda görüyoruz.
Bir ambalaj firması kurulum öncesinde on dört maddelik bir uyarlama listesi hazırladı. Liste ciddiydi; her madde bir toplantıda konuşulmuştu.
Standart akışla başlanmasına karar verildi ve liste üç ay sonra yeniden ele alındı.
Dokuz madde listeden düştü. Sebepleri şöyleydi. Dört madde, malzeme listesinin dağınık olmasından doğan kontrol adımlarıydı; malzeme ağacı kurulunca o kontrollerin konusu kalmadı. Üç madde ekran düzeniyle ilgiliydi ve ekip birkaç hafta sonra mevcut düzene alışmıştı. İki madde ise eski sistemdeki bir kısıtı taklit etmek içindi; yeni sistemde o kısıt zaten yoktu.
Kalan beş maddenin ikisi ayar seviyesinde çözüldü: ek alan tanımı ve bildirim kurgusu.
Gerçekten geliştirme gerektiren üç madde kaldı. Üçü de firmanın işinden geliyordu: müşteri şartnamesine bağlı kalite belgesi zorunluluğu, ihracat siparişlerinde farklı onay rotası ve bir müşteri portalına bağlantı.
Baştan yapılsaydı on dört madde geliştirme kalemi olarak fiyatlanacaktı. Üç ay beklendiğinde rakam ciddi biçimde küçüldü ve sürüm yükseltmelerinde taşınacak yük de küçüldü.
Codigno tarafında
Codigno ERP’nin satın alma tarafı standart zinciri kapsıyor: ortak talep havuzu, proje ve departman bazlı onay hiyerarşisi, malzeme ve hizmet ağacı, varyant kurgusu, kalem bazlı parametre, çok lokasyonlu stok. Bu başlıkların çoğu tanım seviyesinde kuruluyor.
Şirkete özel akışlar gerektiğinde low-code tarafı devreye giriyor. Amaç, uyarlamayı geliştirme kaleminden çıkarıp yapılandırma kalemine yaklaştırmak.
Uygulamada işleyen sıra genelde şu oluyor: standart akışla başlanıyor, sistem birkaç ay kullanılıyor, gerçekten eksik kalan yerler ondan sonra kurgulanıyor. Kurulum öncesinde istenen uyarlamaların önemli bir kısmı bu aşamada listeden düşüyor.
Fiyat tarafı: satın alma yazılımı fiyatları. Zincirin bütünü: satın alma yönetimi rehberi.
Sık sorulan sorular
Uyarlama kararını ne zaman vermeliyiz?
Mümkünse kurulumdan sonra. Sistem kullanılmadan yapılan uyarlama listesi, gerçek ihtiyaçtan çok mevcut alışkanlığı yansıtıyor.
Standart akışla başlarsak ekip direnir mi?
Bir süre direnç oluyor. Bunu azaltan şey, hangi eksikliklerin ne zaman ele alınacağının baştan söylenmesi. Belirsizlik, eksikliğin kendisinden daha çok direnç üretiyor.
Uyarlanan kısımlar sürüm yükseltmesinde kayboluyor mu?
Yapılandırmayla yapıldıysa korunuyor, kod yazılarak yapıldıysa test edilmesi ve bazen yeniden yazılması gerekiyor. Bu ayrım sözleşme aşamasında netleşmeli.
Sektörümüze özel alanlar eklenebiliyor mu?
Parti, seri, son kullanma tarihi, sertifika ya da poz numarası gibi alanların kalem üzerinde taşınması yaygın bir ihtiyaç. Bunun ayarla mı yoksa geliştirmeyle mi çözüldüğü sağlayıcıya göre değişiyor.
Low-code ile yapılan akışlar bize mi ait oluyor?
Devredilebilirlik ve lisans koşulları sözleşmede yazılı olmalı. Bu madde proje başlamadan netleştirilmesi gereken konulardan biri.
Hangi kuralınız işten geliyor, hangisi alışkanlıktan? Onay kurgunuzu ve sektörünüze özel alanlarınızı paylaşın; hangisinin ayarla, hangisinin geliştirmeyle çözüleceğini birlikte ayıralım.
