Yazılım bakım, destek ve kapasite aboneliği: projeden sonrasının rehberi

Bir yazılım projesinin sözleşmesi teslimle biter; sistemin ömrü teslimle başlar. Canlıya geçtiği gün doğru çalışan bir uygulama, hiçbir şeye dokunulmasa bile zamanla bozulur. Çünkü çevresi durmaz: işletim sistemleri ve tarayıcılar sürüm atlar, kullanılan kütüphanelerde güvenlik açıkları duyurulur, entegre olduğunuz ERP yeni bir sürüme geçer, e-fatura veya kargo sağlayıcısı arayüzünü değiştirir, mevzuat yeni bir alan zorunlu kılar. Yazılım aynı kalır, dünyası değişir.

Buna bir de işin kendisinin değişmesi eklenir. Yeni bir hat kurulur, yeni bir müşteri farklı bir rapor ister, fiyat kuralı değişir, bir departman yeniden yapılanır. Üretim yapan bir işletmede bir yıl içinde hiçbir sürecin değişmemesi beklenen bir durum değildir. Dolayısıyla teslim sonrası düzenlemesi olmayan bir yazılım, ya kullanılmaz hale gelir ya da her ihtiyaçta sıfırdan pazarlık gerektiren bir yük olur.

Teslim sonrasını düzenlemenin üç yolu vardır ve bu üçü birbirinin alternatifi değil, birbirinden farklı işleri çözen yapılardır: sistemi ayakta tutmayı hedefleyen yıllık bakım ve destek sözleşmesi, sistemi geliştirmeye devam etmek için ayrılan aylık mühendislik kapasitesi aboneliği ve hiçbir sözleşme kurmadan iş bazlı ilerleyen talep bazlı çalışma. Bu rehberin geri kalanı bu üçünün farkını, ne taahhüt ettiklerini ve kime uygun olduklarını açar.

Fiyat tarafında da baştan bir çerçeve verelim. Piyasa söyleminde yıllık bakım ve destek bedeli, projenin bir kerelik yatırım tutarının yaklaşık yüzde 15-25'i bandında telaffuz edilir; kapsamı geniş, çok entegrasyonlu ve yüksek erişilebilirlik beklenen sözleşmelerde bu bandın üzeri de konuşulur. Bu bir piyasa söylemidir, bizim fiyat listemiz değildir; gerçek bedel kapsam, destek düzeyi ve sistemin karmaşıklığı netleştikten sonra hesaplanır. Maliyet kalemlerinin tamamı için özel yazılım fiyatları rehberimize bakabilirsiniz.

Kapasite aboneliğini anlamanın en kolay yolu, onu bir kapsam sözleşmesi olarak düşünmeyi bırakmaktır. Klasik proje sözleşmesinde ne yapılacağı baştan yazılır ve bedel buna bağlanır. Kapasite sözleşmesinde ise bedel, ayrılan mühendislik süresine bağlanır; o sürenin hangi işe harcanacağına ay içinde işletme karar verir.

Bu yapının işleyebilmesi için sözleşmede dört konunun net olması gerekir. Birincisi devir kuralıdır: kullanılmayan sürenin bir sonraki aya aktarılıp aktarılmadığı, aktarılıyorsa tavanının ne olduğu ve ne kadar süreyle geçerli kaldığı. İkincisi aşım tarifesidir: aylık kapasite dolduktan sonra gelen işlerin hangi birim ücretle çalışılacağı ve aşımın önceden onaya bağlı olup olmadığı. Üçüncüsü önceliklendirme yöntemidir: talep listesinin nasıl tutulduğu ve ay başında hangi işlerin sıraya alınacağına nasıl karar verildiği. Dördüncüsü raporlamadır: ay sonunda hangi işe ne kadar süre harcandığını gösteren, denetlenebilir bir dökümün verilip verilmeyeceği.

Kapasite aboneliğinin güçlü yanı, küçük ama sürekli ihtiyaçların her seferinde teklif sürecine takılmadan çözülebilmesidir. Bir raporun kolonunu değiştirmek, bir onay akışına adım eklemek veya bir entegrasyonun değişen alanını güncellemek, ayrı ayrı fiyatlandığında hem bekler hem de yönetim yükü üretir. Aynı işler tanımlı bir kapasitenin içinde yapıldığında planlanabilir hale gelir.

Aynı yapının sınırını da açıkça söylemek gerekir. Kapasite aboneliği büyük tek seferlik işler için doğru araç değildir. Yeni bir modülün sıfırdan geliştirilmesi, kapsamlı bir veri göçü ya da bir sistemin baştan yazılması, aylık kapasitenin içine sıkıştırıldığında ne bütçesi ne takvimi sağlıklı yönetilebilir. Bu tür işler ayrı bir proje sözleşmesiyle ele alınmalı, kapasite ise projenin dışında kalan sürekli akışa ayrılmalıdır.

Bizim için bakım sözleşmesi, müşteriyi tutmanın aracı değil, sistemin yaşamasının aracıdır. Bu nedenle geliştirdiğimiz her sistemde kaynak kodun tamamı müşteride kalır. Sözleşme sürerken de, sona erdiğinde de kod sizindir; bizimle devam etmek bir zorunluluk değil, tercih olmalıdır. Bir sistemin sürdürülebilmesi için tedarikçisine mahkûm olması gerektiği fikrini kabul etmiyoruz.

Mevcut ERP'nize dokunmadan çalışma ilkemiz teslim sonrasında da geçerlidir. Logo, Mikro, Netsis, Canias veya SAP kurulu bir işletmede yazdığımız katman, ERP'nin yanında çalışır; onun tablolarını değiştirmez, kendi kurgusunu bozmaz. Amacımız, ERP tedarikçinizin destek kapsamıyla bizim çalışmamızın çakışmamasıdır; ERP'nin kendi tabloları ve kurgusu değişmediği için müdahale sınırları ayrı kalır. Yine de nihai belirleyici, ERP sözleşmenizin kendi şartlarıdır; devreye almadan önce bu maddeyi birlikte kontrol ederiz. Netsis kullanan bir işletmede, ERP'ye hiç dokunmadan yanında çalışan bir katman üzerinde çalıştık.

Neyi bilmediğimizi de yazarız. İncelediğimiz bir kurumsal uygulamanın tersine mühendisliğinde günlük hesaplama katmanını tamamen çözdük; aynı sistemin aylık katmanın dayandığı altı veritabanı nesnesi (beş fonksiyon ve bir saklı yordam)nun gövdesine ise ulaşamadık ve bunu kapatılmış gibi göstermek yerine raporda eksik olarak işaretledik. Başka bir sistemde ise kaynağı bulunamayan veritabanı nesnelerini yeniden kurduk ve çıkan sonucu, sözleşme ile gövde ayrımını koruyarak bağımsız bir denetimden geçirdik. Bakım ilişkisinde de aynı ilke geçerlidir: doğrulanmamış bilgiyi doğrulanmış gibi sunmayız.

Devir dosyası standardımız teslim sonrasının güvencesidir. Kurulum adımları, bağımlılıklar, yapılandırma, bilinen riskler ve çalışır bir derleme ortamı yazılı hale getirilir. Amaç, bizden başka bir ekibin de bu sistemi sürdürebilmesidir; bu belge olmadan bir bakım sözleşmesi, gizli bir bağımlılık sözleşmesine dönüşür.

Fiyat konusunda ise bu sayfada rakam vermiyoruz. Sistemin karmaşıklığı, entegrasyon sayısı, beklenen erişilebilirlik ve arıza durumunda işin durma maliyeti bilinmeden verilen bir bakım rakamı, ya gereğinden yüksek ya da tutulamayacak kadar düşüktür. Kısa bir değerlendirme sonrasında hangi modelin size uygun olduğunu, kapsamın neyi içerip neyi dışarıda bırakacağını ve hangi kalemlerin ayrıca fiyatlanacağını yazılı olarak paylaşırız.