Uyarlanabilir & Programlanabilir Sistem
Bir yazılım seçerken sorulan soru genellikle şudur: “Bu sistem bize uyuyor mu?” Oysa bu sorunun cevabı, sistemi kullanacağınız on yılın yalnızca ilk gününü ilgilendirir. Asıl soru daha zordur ve nadiren sorulur: “Uymayan kısmı değiştirmek ne kadara mal olacak — bugün ve her sürüm geçişinde?” Bu sayfa, Minerva’nın bu ikinci soruya nasıl cevap verdiğini anlatıyor.
Sayfa İçi Başlıklar- Yanlış soru: bu yazılım bize uyar mı?
- Endüstrinin temel paradoksu
- Özel yazılım neden çürür?
- Doğru ölçüt: değişim maliyeti
- Faturanın geldiği yer: sürüm geçişi
- Uyarlama merdiveni: yedi katman
- Katman 1: parametrik yapı
- Katman 2: kullanıcı tanımlı alanlar ve etiketleme
- Katman 3: raporlar ve analiz panelleri
- Katman 4: form ve etiket tasarımı
- Katman 5: müşteriye özgü triggerlar
- Katman 6: ek modül ve açık platform
- Katman 7: sektörel çekirdek
- Kim uyarlıyor? Bekleme süresi meselesi
- Uyarlama yönetişimi
- Ne zaman uyarlamamalısınız?
- Tedarikçinize soracağınız sekiz soru
- Özet karşılaştırma
- Sonuç
Yanlış soru: Bu yazılım bize uyar mı?
Bu soru, uyumu ikili bir şeymiş gibi ele alır: uyar ya da uymaz. Gerçekte uyum ikili değil, katmanlıdır. Bir işletmenin gereksinimlerini ayrıştırdığınızda kabaca şu tablo çıkar.
Gereksinimlerin ayrışması
Oranlar sektöre göre değişir; yapı değişmezSektörde yapılan klasik hata şudur: en küçük dilime bakarak tüm strateji belirlenir. Yüzde beşlik özgün ihtiyaç yüzünden sıfırdan yazılım geliştirmeye karar verilir; ya da tam tersine, o yüzde beş görmezden gelinerek katı bir standart pakete girilir ve işletme kendini yıllarca yazılıma uydurmaya çalışır.
Doğru soru
“Bu yazılım bize uyar mı” değil, “uymayan kısmı hangi katmandan, kim, ne kadar sürede kapatabilir” sorusudur.
Endüstrinin temel paradoksu
Minerva gibi uygulama programları, birçok sektörde ve birçok farklı alanda kullanılmak üzere tasarlanır. Bu, geliştiricinin standardizasyona uygun davranmasını ve genel amaçlı sistemler üretmesini gerektirir. Şirketler ise sektörlerine özel, hatta yalnızca kendileri için geliştirilmiş sistemler talep eder.
Bu talep üç nedenle ekonomik değildir:
- Tek bir şirketin gereksinimleri için özel bir sistem geliştirmek çok uzun sürer.
- Nitelikli proje personeline ve uzun süreye duyulan ihtiyaç pahalı bir yapı oluşturur.
- Proje bittikten sonra güncelleme, bakım, destek ve yeni teknolojilere uyum maliyetleri çok yüksektir.
Buradan endüstrinin temel paradoksu doğar. Ya gereksinimlerinizi karşılamaktan uzak, ama ekonomik ve hızlı uygulanabilir standart bir yazılım alırsınız; ya da masraflı ve uzun sürecek özel bir program geliştirirsiniz. İkilemin eşiğindesiniz.
Katı standart paket
Hızlı devreye alınır, maliyeti öngörülebilir, bakımı üretici üstlenir.
Buna karşılık işletme kendini yazılıma uydurur. Uymayan kısımlar için Excel dosyaları, yan sistemler ve elle yürütülen süreçler doğar.
Beş yıl sonra: sistem duruyor, ama işin önemli bir kısmı sistemin dışında yürüyor.
Sıfırdan özel yazılım
Tam olarak istediğiniz gibi çalışır — devreye alındığı gün.
Buna karşılık uzun sürer, pahalıdır ve tamamlandığında gereksinimler çoktan değişmiştir.
Beş yıl sonra: sistemi yazan kişi ayrılmış, teknoloji eskimiş, değiştirmeye kimse cesaret edemiyor.
Minerva bu ikilemi ortadan kaldırmayı hedefler. Standart, ekonomik ve hızlı uygulanabilir olmasının yanında, gereksinimlerinize göre programlanabilir katmanlara sahiptir. Bu sayfanın geri kalanı, o katmanların ne olduğunu ve her birinin gerçek maliyetini anlatıyor.
Özel yazılım neden çürür?
“Özel yazılım pahalıdır” cümlesi doğru ama yüzeysel. Asıl mesele fiyat değil, ekonomik yapıdır. Özel yazılımın üç yapısal zaafı vardır.
Tek kişilik izleyici kitlesi
Standart bir üründe yüzlerce müşteri aynı kodu çalıştırır. Bir hata varsa, biri onu bulur ve herkes için düzeltilir. Özel yazılımda hatayı bulacak tek kişi sizsiniz — ve genellikle bulduğunuzda iş çoktan aksamıştır.
Paylaşılmayan modernizasyon maliyeti
Tarayıcılar değişir, işletim sistemleri değişir, veri tabanı sürümleri emekli olur, güvenlik standartları sıkılaşır. Standart üründe bu uyum çalışmasının maliyeti tüm müşteri tabanına yayılır. Özel yazılımda tamamını siz ödersiniz — ve genellikle ödemek istemezsiniz, sistem de eskimeye bırakılır.
Bir veya iki kişilik bilgi
Özel sistemi yazan kişi ayrıldığında, sistemin nasıl çalıştığını bilen kimse kalmaz. Dokümantasyon vardır ama eksiktir; kod okunabilir ama gerekçeler yazılı değildir. Bu noktadan sonra sisteme kimse dokunmak istemez. Yazılım teknik olarak çalışmaya devam eder, ama gelişmeyi bırakır.
Özel yazılım ölmez, donar. Ve donmuş bir sistem, işletme değiştikçe her yıl biraz daha yanlış hale gelir.
Bu, özel geliştirmenin her zaman yanlış olduğu anlamına gelmez. Yanlış olan, ortak ve değişken katmanları da özel geliştirmektir. Muhasebe motorunuzu sıfırdan yazmanın size rekabet üstünlüğü sağlamayacağı açıktır. Özel geliştirme, yalnızca gerçekten size özgü olan yerde anlamlıdır.
Doğru ölçüt: Değişim maliyeti
Yazılım seçiminde en yanıltıcı varsayım, uyumun bir kez belirlenip sabit kaldığıdır. Oysa gereksinimler durmadan değişir: yeni bir ürün grubu, yeni bir ülke, yeni bir mevzuat, satın alınan bir şirket, değişen bir müşteri talebi.
Bu yüzden doğru ölçüt uyum oranı değil, değişim maliyetidir. Ve bunun içinde en çok gözden kaçan bileşen şudur: ellinci değişikliğin maliyeti, birincinin maliyetiyle aynı mı?
Artan maliyet eğrisi
İlk uyarlama kolaydır. Her uyarlama bir sonrakini zorlaştırır.
Değişiklikler birbirine dolanır; hangi kuralın nereden geldiği belirsizleşir. Bir yeri değiştirmek başka üç yeri bozar.
Sonunda “dokunmayalım” kararı alınır ve sistem donar.
Böylece temizlik operasyonu yerine sürekli bir hijyen kurulur.Sabit maliyet eğrisi
Değişiklikler ayrı ve tanımlı katmanlarda yapılır; birbirine karışmaz.
Parametre parametredir, alan alandır, kural kuraldır. Her biri kendi yerinde durur ve geri alınabilir.
Ellinci değişiklik, birincisi kadar kolaydır.
Bu ayrımın teknik nedeni basittir ve sayfanın geri kalanının anahtarıdır: bir değişikliği nereye koyduğunuz, ne kadar sürdüğünden daha önemlidir.
Faturanın geldiği yer: Sürüm geçişi
Bir uyarlamanın gerçek maliyeti, yapıldığı gün ödenmez. Her sürüm geçişinde yeniden ödenir. Sektörde bunun adı vardır: teknik borç. Ve faizi sürüm geçişlerinde tahsil edilir.
Ayrımı net koyalım. İki tür değişiklik vardır ve ikisi taban tabana zıttır:
Genişletme
Ürünün size sunduğu tanımlı noktalardan yararlanır: parametre, alan, rapor, form, tanımlı kural.
Ürünün kendi kodu değişmez. Yeni sürüm geldiğinde genişletmeleriniz olduğu gibi kalır.
Bunlar veridir — ve veri sizin tablolarınızdadır.
Böylece temizlik operasyonu yerine sürekli bir hijyen kurulur.Değiştirme
Ürünün standart kodunu ya da davranışını doğrudan değiştirir.
Yeni sürüm geldiğinde çakışır. Ya değişiklik kaybolur, ya sürüm alınamaz.
Sonuç genellikle üçüncüsüdür: sürüm alınmaz ve sistem yıllarca eski kalır.
Parametrenin yükseltmeye dayanıklı olması bir vaat değil, bir sonuçtur
Bu, bu sayfadaki en önemli teknik cümle. Parametre veridir. Veri, ürünün kodunda değil, sizin veri tabanınızdaki tablolarda durur. Sürüm geçişi ürünün kodunu yeniler, verinizi değil. Bu yüzden parametrik yapılandırma sürümden etkilenmez — birisi öyle söz verdiği için değil, mimari olarak etkilenemeyeceği için.
Aynı mantık kullanıcı tanımlı alanlar, raporlar, formlar ve tanımlı iş kuralları için de geçerlidir. Bunların hepsi tanım kaydıdır. Kod değildir.
Bir tedarikçi “her şeyi özelleştirebiliriz” dediğinde sorulacak tek soru şudur: “Bu değişiklik bir sonraki sürümde ne olacak?” Cevap net değilse, aldığınız şey esneklik değil, ertelenmiş bir maliyettir.
Uyarlama merdiveni: Yedi katman
Minerva’nın uyarlama yeteneklerini bir özellik listesi olarak sıralamak yerine, maliyet ve risk sırasına göre bir merdiven olarak sunuyoruz. Merdivenin her basamağında güç artar; buna karşılık hız azalır, gereken uzmanlık yükselir ve sürüm hassasiyeti başlar.
Tek bir yönetişim kuralı: Her ihtiyacı, çözülebileceği en alt basamakta çözün. Bir ihtiyaç parametreyle karşılanabiliyorsa trigger yazmayın; kullanıcı tanımlı alanla çözülebiliyorsa modül geliştirmeyin. Bu kural, sistemin beş yıl sonraki sağlığını belirleyen tek kuraldır.
Parametrik yapılandırma
Sistemin davranışını, kod yazmadan, tanım kayıtlarıyla belirlemek.
Kullanıcı tanımlı alanlar ve etiketleme
Veri modelini kendi ihtiyacınıza göre genişletmek.
Raporlar ve analiz panelleri
Okuma tarafı. Veriyi bozamaz, bu yüzden en serbest katmandır.
Form ve etiket tasarımı
Sunum katmanı. İşin mantığına dokunmadan çıktının görünümünü belirler.
Müşteriye özgü triggerlar
Davranış katmanı. En güçlü ve en dikkat gerektiren basamak.
Ek modül ve fonksiyonellik geliştirme
Gerçekten size özgü olan yüzde beş için.
Sektörel çekirdek geliştirme
Kullanıcı tarafından programlanamayan, mimariye ait kavramlar.
Aşağıdaki bölümler bu yedi basamağı tek tek açıyor. Her birinde hem yeteneği hem de dikkat edilmesi gerekeni bulacaksınız.
Katman 1: Parametrik yapı
Minerva’da hemen hemen tüm işlemler şirkete, işletme birimine, kullanıcı grubuna veya kullanıcıya göre yapılandırılabilir. Örneğin kredi ve risk değerlendirmesinde riskin nasıl hesaplanacağı, risk kontrolünün ne zaman ve nasıl yapılacağı tamamen parametrik olarak tanımlanır.
Bunun yanında, sistemde yapılan işlere özgü İş Yönetim Parametreleri bulunur. Bu parametreler şu boyutlarda tanımlanabilir:
İş yönetim parametrelerinin boyutları
- İşin niteliği
- Hangi şirketler için
- Şirketin hangi işyeri için
- Hangi kullanıcılar için
- Hangi kullanıcı rolleri için
Neden bu boyutlar önemli?
Çoğu sistemde parametre küresel olarak tanımlanır: bir kural açılır, herkes için açılır. Gerçek hayatta ise kurallar nadiren herkes için aynıdır. İhracat departmanının onay eşiği ile perakende kanalının onay eşiği farklıdır. Yeni açılan şubede daha sıkı risk kontrolü isteyebilirsiniz. Deneyimli bir satış müdürüne tanınan esneklik, yeni başlayana tanınmaz.
Parametrenin şirket, işyeri, kullanıcı ve rol boyutlarında tanımlanabilmesi, tek bir kuralı istisnalarla yönetmek yerine, gerçek kural setini tanımlayabilmek demektir. İstisnalar açıklama alanlarında ve sözlü mutabakatlarda değil, sistemde durur.
Parametrik katmanın en çok gözden kaçan faydası hız değil, izlenebilirliktir. Bir kural kodun içine gömülüyse, neden öyle olduğunu anlamak için kodu okumanız gerekir. Parametre olarak duruyorsa, kimin ne zaman değiştirdiğiyle birlikte görünür.
Katman 2: Kullanıcı tanımlı alanlar ve etiketleme
Kullanıcı tanımlı alan işlevselliği, Minerva’nın kullanıcılarına sunduğu en temel özelliklerden biridir. Tüm ana kartlarda — müşteri, tedarikçi, stok kartı ve diğerleri — ve tüm işlemlerde — sipariş, irsaliye, fatura, depo fişi, iş emri ve diğerleri — müşteriye ve sektöre özgü alanlar tanımlanabilir.
Kullanıcı tanımlı alan türleri
- Metin – Karakter
- Sayısal
- Para Birimi – Tutar
- Tarih
- Tarih – Saat
- Check Box
- Combo Box
- Tanımlanabilir Combo Box
- Not (uzun bilgi alanı)
- E-Posta
- Web Bağlantısı – URL
- Formül
Tür listesinin ardındaki tasarım kararı
Bu listenin uzun olması bir özellik yarışı değil. Her tür, veriyi sonradan işlenebilir kılmak için var. Bir teslim tarihini metin alanına yazarsanız, “gecikmeler ortalama kaç gün” sorusunu asla cevaplayamazsınız. Tarih alanına yazarsanız, cevabı raporlayabilirsiniz.
Pratik tavsiye:
Serbest metin yerine, mümkün olan her yerde tanımlanabilir combo box kullanın. Aradaki fark girişte üç saniyedir, raporlamada ise her şeydir. Serbest metin alanına yazılmış bir bilgi — örneğin müşteri segmenti — üç ay sonra on farklı yazımla karşınıza çıkar ve hiçbir analize girmez. Serbest metin, veri değil not tutar.
Kayıt etiketleme
Kayıtlar çeşitli şekillerde (önemli, önemsiz ve benzeri) veya kullanıcı tarafından tanımlanmış anahtar kelimelere göre etiketlenebilir.
Etiketleme, alan tanımlamanın hafif alternatifidir ve farklı bir ihtiyaca hizmet eder. Alan, önceden bildiğiniz ve her kayıtta olması gereken bir bilgi içindir. Etiket ise önceden öngörmediğiniz, geçici veya kayıtların yalnızca bir kısmını ilgilendiren bir ayrım içindir: bu yılın riskli müşterileri, bu sevkiyatta sorun çıkan kalemler, denetimde incelenecek kayıtlar. Her yeni ayrım için alan açmak veri modelini şişirir; etiket bunu esnek biçimde çözer.
Dürüst uyarı — alan entropisi:
Kullanıcı tanımlı alanların bilinen bir hastalığı vardır. Üç yıl sonra kırk alan olur, yarısı boştur ve Özel Alan 7 ne demek kimse bilmez. Bu, yazılımın değil yönetişimin sorunudur.
Çözüm basit ve zorunludur: her alana açıklayıcı bir ad verin, her alanın bir sahibi olsun, yılda bir kez kullanılmayan alanları gözden geçirin. Bunu yapmayan kurumlarda kullanıcı tanımlı alan, çözdüğünden fazla karmaşa yaratır.
Katman 3: Raporlar ve analiz panelleri
Sistemde istenilen her türlü rapor yaratılabilir. Raporlama sistemi, bu amaçla kullanılan araçların hemen hemen tüm yeteneklerine sahiptir.
Rapor formatları
- Ekran (HTML)
- Yazıcı (HTML)
- Genişletilebilir İşaretleme Dili (XML)
- Virgülle Ayrılmış Metin Dosyası (CSV)
Rapor çıktıları
- Ekranda gösterim
- Excel dosyası olarak indirme
- Dosya olarak indirme
- Sistem dokümanı olarak kaydetme
- Arka planda hazırlama
- E-posta olarak gönderme
Analiz panelleri tarafında da sistemde her türlü panel yaratılabilir. Paneldeki bileşenler liste, grafik veya istenilen formattaki bilgiyle doldurulabilir.
Neden okuma tarafında serbest olmalı?
Bu katmanın diğerlerinden ayrı bir yeri var ve tasarım ilkesi şudur: okuma tarafında cömert, yazma tarafında disiplinli olun. Bir rapor veriyi bozamaz. Yanlış yazılmış bir rapor yanlış sonuç verir, ancak sistemi etkilemez ve saniyeler içinde düzeltilir. Bu yüzden raporlamada kısıtlayıcı olmanın hiçbir teknik gerekçesi yoktur.
Buna karşılık raporlama, bir sistemin gerçek kullanım oranını belirleyen tek şeydir. İnsanlar bir sisteme veri girmeyi, o veriden bir çıktı aldıkları sürece sürdürür. Rapor alamayan kullanıcı, kayıt tutmayı da bırakır. Raporlama esnekliği bir konfor değil, veri kalitesinin ön koşuludur.
Arka planda hazırlama ve e-posta gönderimi ilk bakışta küçük ayrıntı gibi görünür; uygulamada raporun kullanılıp kullanılmayacağını belirler. Kimsenin açmadığı bir panel yerine, her pazartesi sabahı gelen bir e-posta çoğu zaman daha fazla iş görür. İyi rapor, kullanıcının gitmesi gereken değil, kullanıcıya gelen rapordur.
Katman 4: Form ve etiket tasarımı
Sistemde tüm işlemlere ait form tasarım olanağı vardır ve her işlem için birden fazla form tasarlanabilir. Ayrıca form kütüphanesinden hazır formlar kullanılabilir.
Sistem içi programlama: barkod etiketi örneği
Minerva’da HTML ve Oracle fonksiyonlarını kullanarak sistem içinde programlama yapılabilir. Barkod etiketleri bunun en somut örneğidir. Etiket tasarımı şirketten şirkete değişir; dahası aynı şirket farklı amaçlar için on farklı etiket tasarımına ihtiyaç duyabilir.
Minerva’da barkod etiketlerinizi istediğiniz ebatta, istediğiniz stilde ve istediğiniz standarda (EAN ve benzeri) göre tasarlayabilir, üzerlerine resim ve görüntü ekleyebilirsiniz.
Bu örnek küçük görünür ama tipiktir. Etiket tasarımı, hiçbir yazılım üreticisinin önceden tahmin edemeyeceği bir alandır — çünkü sizin raf sisteminize, müşterinizin talebine ve makinenizin özelliğine bağlıdır. Bu tür ihtiyaçlar, üreticiden talep edilerek değil, yerinde çözülmelidir.
Aynı mantık formlar için de geçerlidir. Bir işlem için birden fazla form tasarlanabilmesi, pratikte şu anlama gelir: aynı sipariş kaydı, müşteriye giderken farklı, depoya giderken farklı, arşive giderken farklı basılabilir. Tek bir çıktı formatına mahkûm değilsiniz.
Katman 5: Müşteriye özgü triggerlar
Sistemin en güçlü uyarlama özelliklerinden biridir. Tamamen müşteri ve sektör ihtiyaçları için veri tabanı düzeyinde triggerlar tanımlanabilir. Bu triggerlar, girilen kayıtları denetlemenizi sağlar veya kayıt öncesinde ve sonrasında yapılması gereken tüm operasyonları yönetir.
Veri tabanı düzeyinde olmasının anlamı
Bu ayrıntı teknik görünür ama sonucu tamamen iş tarafındadır. Uygulama katmanında tanımlanan bir kontrol, yalnızca o ekrandan geçen kayıtları denetler. Veri toplu yüklemeyle, bir arayüzden veya bir entegrasyondan geldiğinde o kontrol devreye girmez.
Veri tabanı düzeyindeki bir trigger ise kaydın hangi yoldan geldiğine bakmaz. Bu yüzden gerçekten güvenebileceğiniz tek denetim noktasıdır. Bir iş kuralının istisnasız uygulanması gerekiyorsa — örneğin belirli bir müşteri grubuna kredi limiti aşımıyla sevkiyat yapılmaması — o kural buraya yazılmalıdır.
Aynı güç, aynı ölçüde dikkat gerektirir
Bunu söylemeyen bir tedarikçiye temkinli yaklaşın. Triggerların üç bilinen riski vardır:
Görünmezlik
Trigger arka planda çalışır. Beklenmeyen bir davranışla karşılaşan kullanıcı, nedenini ekranda göremez. Bu yüzden her trigger belgelenmeli ve kayıt altına alınmalıdır.
Performans
Her yazma işleminde çalışır. Ağır bir trigger, tek bir kaydın girilmesinde fark edilmez; günlük on bin kayıtlık bir yüklemede sistemi durdurur.
Birikme
Yıllar içinde eklenen triggerlar birbirini tetikleyebilir. Beşinci yılda “bu kayıt neden reddedildi” sorusunun cevabı üç ayrı triggerın birleşiminde olabilir.
Bu risklerin hiçbiri triggerlardan kaçınmayı gerektirmez. Gerektirdiği tek şey disiplindir: her trigger için bir gerekçe, bir sahip ve bir kayıt. Uyarlama yönetişimi bölümünde bunun nasıl yürütüleceğini anlatıyoruz.
Katman 6: Ek modül ve açık platform
Minerva Oracle veri tabanı üzerinde çalışır. HTML, Java, Oracle programlama ürünleri, Microsoft programlama ürünleri veya istemci-sunucu programlama ürünlerini kullanarak istediğiniz fonksiyonelliği geliştirebilirsiniz.
Bunun asıl değeri: bağımlılık sigortası
Bu maddeyi bir geliştirme özelliği olarak okumak eksik olur. Asıl anlamı şudur: veriniz açık, standart ve belgelenmiş bir platformda duruyor.
Kurumsal yazılım alırken en az konuşulan ama en gerçek risk, tedarikçiye bağımlılıktır. Şirketler değişir, ilişkiler bozulabilir, üreticiler el değiştirir. Bu durumda kritik soru şudur: verim nerede ve ona kimler ulaşabilir?
- Veriniz kapalı bir formatta veya belgelenmemiş bir yapıdaysa, tedarikçiniz olmadan hiçbir şey yapamazsınız.
- Veriniz standart bir ilişkisel veri tabanındaysa, piyasada bulunabilir yetkinliklerle ulaşılabilir, taşınabilir ve genişletilebilir.
Bu, bizimle çalışmayı bırakmanız için bir davet değil. Aksine: ayrılabildiğiniz için kalmanız, ayrılamadığınız için kalmanızdan sağlıklı bir ilişkidir. Bir tedarikçinin size verebileceği en dürüst güvence budur.
Proje ve modifikasyon hizmetleri
Her uyarlamayı kendiniz yapmanız gerekmez ve çoğu zaman doğru da değildir. Minerva, gereksinimlerinize göre ek fonksiyonellik yaratma ve proje geliştirme hizmetleri sunar. Böylece yeni gereksinimleriniz için yeni bir yazılım almanız gerekmez.
Doğru iş bölümü genellikle şöyledir: merdivenin ilk dört basamağı sizin ekibinizde kalmalı — çünkü hızlı olmalı. Beşinci ve altıncı basamaklarda ise üreticiyle çalışmak, hem sürüm uyumu hem de bakım sürekliliği açısından daha güvenlidir.
Katman 7: Sektörel çekirdek
Sektörlerin bazı gereksinimleri, kullanıcılar tarafından kolayca programlanabilecek nitelikte değildir. Tekstilde ürünler için beden ve rengin tanımlanması bunun klasik örneğidir. Bu tür temel sektörel işlevler, sistem tasarımı sırasında ele alınmalı ve mimarinin parçası olarak kurulmalıdır.
Neden alan eklemek yetmez?
Bu, merdivenin sınırını anlamak için önemli. Tekstilde beden ve renk, ürünün özelliği değildir — ürünü bir matrise dönüştürür. Tek bir tişört modeli, beş beden ve altı renkle otuz ayrı stok birimine karşılık gelir.
Bu matrisi sistemin her yerinin anlaması gerekir:
- Sipariş satırı bir ürünü değil, bir beden-renk dağılımını taşır.
- Stok hareketi matris hücresi düzeyinde tutulur, ürün düzeyinde değil.
- Fiyat listesi bazen ürüne, bazen bedene göre farklılaşır.
- Üretim planı, satın alma ve maliyet aynı matrisle çalışır.
Kullanıcı sisteme alan ekleyebilir. Kavram ekleyemez.
Bir kullanıcı tanımlı alan, veriyi taşır. Bir kavram ise sistemin her modülünün davranışını değiştirir. İkisini karıştıran projeler, üçüncü ayda tıkanır.
Minerva’nın sektöre özel birçok yeteneği vardır ve tek bir platformda çok sektörlü uygulamaları yönetir. Bir tedarikçiyi değerlendirirken sorulacak doğru soru şudur: “Benim sektörümün temel kavramları çekirdekte mi, yoksa benden bunları kullanıcı tanımlı alanlarla taklit etmem mi bekleniyor?” İkinci durumdaysanız, uyarlanabilirlik size yardım etmez.
Sektörel çözümlerimiz hakkında ayrıntılı bilgiyi Sektörel Çözümlerbölümünde bulabilirsiniz.
Kim uyarlıyor? Bekleme süresi meselesi
Uyarlanabilirlik tartışmasında en çok atlanan boyut teknik değil, örgütseldir: değişikliği kimin yapabildiği.
Standart yazılımların katı hissedilmesinin nedeni çoğu zaman değişikliğin imkânsız olması değildir. Değişiklik mümkündür — ama bir kuyruğa girer: talep açılır, üreticiye iletilir, analiz edilir, teklif gelir, onaylanır, geliştirilir, test edilir, bir sonraki sürümle yayınlanır.
Altı haftalık kuyruk
Satış müdürü müşteri kartında yeni bir bilgi izlemek istiyor.
Talep açılır, teklif beklenir, geliştirme sıraya girer.
Üçüncü haftada müdür bir hesap tablosu açar. Değişiklik geldiğinde artık kimse kullanmaz — çünkü bilgi zaten başka yerde tutuluyordur.
On dakikalık işlem
Aynı ihtiyaç, anahtar kullanıcı tarafından kullanıcı tanımlı alanla karşılanır.
Bilgi sistemde tutulur, raporlanabilir ve herkes tarafından görülür.
Hesap tablosu hiç açılmaz.
Bu, önceki bölümde anlattığımız gölge sistem olgusunun tam kaynağıdır. Excel dosyaları ve yan çözümler, kullanıcıların sisteme karşı yaptığı bir hile değildir; bekleme süresine verilen rasyonel bir tepkidir. Kimse altı hafta beklemez; herkes on dakikada bir çözüm üretir.
Bir sistemin gerçek esnekliği, neyin değiştirilebildiğiyle değil, değişikliğin ne kadar sürdüğüyle ölçülür. Altı hafta süren bir esneklik, pratikte esneklik değildir.
Merdivenin ilk dört basamağının anahtar kullanıcı tarafından yapılabilir olması, bu yüzden bir kolaylık değil, veri bütünlüğünü koruyan bir mekanizmadır.
Uyarlama yönetişimi
Uyarlanabilir bir sistem, yönetilmediğinde uyarlanamaz bir sisteme dönüşür. Bunu satıcı olarak söylemek alışılmadık ama gereklidir: esnekliğin en büyük düşmanı, kayıtsız kullanılan esnekliktir.
Uzun ömürlü kurulumlarda gördüğümüz dört pratik şunlar:
Uyarlama kütüğü tutun
Her parametre değişikliği, her kullanıcı tanımlı alan ve özellikle her trigger için tek satırlık bir kayıt: ne, neden, kim, ne zaman.
Beşinci yılda “bu kural neden var” sorusunun cevabı burada olur. Bu kütük olmadan, hiçbir uyarlama güvenle kaldırılamaz.
Her uyarlamanın bir sahibi olsun
Sahibi olmayan alan, kimsenin doldurmadığı alandır. Sahibi olmayan trigger, kimsenin kaldırmaya cesaret edemediği triggerdır.
Sahiplik, uyarlamayı isteyen birime verilmelidir — bilgi işleme değil.
Yılda bir kez temizlik yapın
Kullanılmayan alanları, çalışmayan raporları ve gerekçesi ortadan kalkmış kuralları gözden geçirin.
Bir saatlik yıllık gözden geçirme, üç yıl sonraki karmaşayı önler.
En alt basamakta çözün
Bir ihtiyaç parametreyle karşılanabiliyorsa trigger yazmayın. Kullanıcı tanımlı alanla çözülebiliyorsa modül geliştirmeyin.
Bu tek kural, sistemin beş yıl sonraki sağlığını diğer hepsinden fazla belirler.
Ne zaman uyarlamamalısınız?
Uyarlama yeteneği satan bir firmanın söylemesi gereken en önemli şey bu: çoğu zaman en iyi uyarlama, hiç uyarlamamaktır.
Kötü bir süreci korumak için
Bir sürecin sistemde karşılığı yoksa, ilk soru “nasıl uyarlarız” değil, “bu süreç neden böyle” olmalıdır.
Standart akış, yüzlerce kurumda test edilmiş bir birikimdir. Onu değiştirmek için para ödediğinizde, çoğu zaman kötü bir alışkanlığı korumak için ödemiş olursunuz.
Tek bir kişinin alışkanlığı için
“Ahmet Bey böyle görmeye alışkın” gerekçesiyle yapılan uyarlamalar, Ahmet Bey ayrıldıktan sonra da sistemde kalır ve kimse neden orada olduğunu bilmez.
Uyarlama talebi kişiden değil, süreçten gelmelidir.
Henüz anlaşılmamış bir ihtiyaç için
Devreye alma projesinin ilk aylarında gelen uyarlama taleplerinin önemli bir kısmı, standart işleyişin henüz öğrenilmemiş olmasından kaynaklanır.
Pratik kural: ilk üç ayın taleplerini kaydedin ama hemen uygulamayın. Üçüncü ay sonunda listenin bir bölümünün kendiliğinden düştüğünü göreceksiniz.
Geçici bir durum için
Bir kereye mahsus bir ihtiyaç, kalıcı bir uyarlamayı hak etmez.
Geçici ihtiyaçlar için etiketleme ve rapor katmanı yeterlidir; veri modeline dokunmayın.
Tedarikçinize soracağınız 8 soru
Bu sayfa sizi ikna etmeye çalışmasın; elinize bir ölçüt versin. Aşağıdaki soruları değerlendirdiğiniz her tedarikçiye — bize dâhil — sorun ve cevapları yazılı isteyin.
Uyarlanabilirlik değerlendirme soruları
Somut bir gereksinim üzerinden sorun; genel cevaplarla yetinmeyin.
- Bu değişikliği kim yapabilir? Kendi ekibim mi, danışman mı, yoksa yalnızca üretici mi?
- Ne kadar sürer? Geliştirme süresi değil, talepten canlıya alınana kadar geçen toplam süre.
- Bir sonraki sürümde ne olacak? Değişiklik korunuyor mu, yeniden mi yapılıyor, yoksa sürüm mü alınamıyor?
- Geri alınabilir mi? Yanlış bir uyarlamayı kaldırmak dakikalar mı sürer, proje mi gerektirir?
- Bu değişikliğin kaydı nerede tutuluyor? Üç yıl sonra kimin, neden yaptığını nereden okuyacağım?
- Ayrı bir platform veya ek lisans gerekiyor mu? Uyarlama için ikinci bir ürün satın almam gerekiyor mu?
- Sektörümün temel kavramları çekirdekte mi? Yoksa bunları kullanıcı tanımlı alanlarla taklit etmem mi bekleniyor?
- Sizinle çalışmayı bırakırsam verime ve uyarlamalarıma ne olur? Veri açık ve belgelenmiş bir platformda mı duruyor?
Üçüncü ve sekizinci sorular en ayırt edici olanlardır. Bu iki soruya net cevap veremeyen bir tedarikçi, size esneklik değil ertelenmiş maliyet satıyordur.
Özet karşılaştırma
| Konu | Katı standart paket | Sıfırdan özel yazılım | Minerva |
|---|---|---|---|
| Devreye alma | Hızlı | Çok uzun | Hızlı, standart çekirdek üzerinden |
| İlk gün uyumu | Kısmi; işletme yazılıma uyar | Tam | Katmanlı uyarlamayla yüksek |
| Ellinci değişiklik | Genellikle mümkün değil | Birinciden çok daha pahalı | Birincisiyle aynı maliyette |
| Değişikliği kim yapar | Yalnızca üretici | Geliştirici ekip | İlk dört katman anahtar kullanıcı |
| Tipik bekleme süresi | Haftalar | Haftalar | Katman 1-4 için dakikalar veya saatler |
| Sürüm geçişi | Sorunsuz ama esneklik yok | Sürüm kavramı yok; sistem donar | Tanım kayıtları korunur, kod katmanı test edilir |
| Bakım maliyeti | Üreticide, paylaşılır | Tamamen sizde | Çekirdek üreticide, uyarlama sizde |
| Sektörel kavramlar | Varsa var, yoksa yok | Yazılırsa var | Çekirdekte tanımlı, genişletilebilir |
| Tedarikçi bağımlılığı | Yüksek | Geliştirene bağımlılık | Açık ve standart veri platformu |
| Beş yıl sonra | İşin bir kısmı sistem dışında yürür | Sistem donmuş, kimse dokunmuyor | Değişmeye devam eder |