Kurumsal Yazılımda Bakım ve Destek Süreçleri Nasıl İşler
Proje bittiğinde bir teslim toplantısı yapılır, ekran görüntüleri paylaşılır, herkes rahatlar. Sonra üç ay sonra bir sabah GİB'in e-fatura protokolünde küçük bir değişiklik yapıldığı, entegrasyonun sessizce çalışmayı kestiği ortaya çıkar. İşte kurumsal yazılımın gerçek hikayesi orada başlar. Teslim anı bir final değil, bakım ve destek ilişkisinin startıdır ve bu ilişki genelde projenin kendisinden çok daha uzun sürer.
Biz SUNS Tech olarak IT, satın alma veya proje yönetiminden sorumlu ekiplerle konuştuğumuzda en çok karşılaştığımız soru şu oluyor: bir bakım-destek sözleşmesini imzalamadan önce nereye bakmalıyız? Bu yazıda sürecin hangi aşamalardan geçtiğini, SLA'da gözden kaçan detayları ve kurumların sık düştüğü tuzakları ele alıyoruz.
Kurumsal yazılımda bakım ve destek süreçleri neyi kapsar
Bakım ve destek genelde tek kelimeymiş gibi konuşulur ama aslında iki farklı iştir. Bakım, yazılımın mevcut halini ayakta tutmakla ilgilidir: güvenlik yamaları, sunucu ve veritabanı güncellemeleri, üçüncü taraf kütüphanelerin uyumluluğunun korunması, düzenli yedekleme kontrolleri. Destek ise kullanıcıdan gelen taleplere cevap vermekle ilgilidir: bir hata bildirimi, bir özelliğin beklenildiği gibi çalışmaması, kullanım sorusu.
Bu ikisini birbirinden ayırmadan yazılan bir sözleşme, ileride anlaşmazlık kaynağı olur. Kurumun IT ekibi "destek paketi aldık, her şey dahil" diye düşünürken, tedarikçi tarafı yeni bir özellik talebini kapsam dışı sayabilir. Sözleşme imzalanmadan önce bakım ve destek kalemlerinin ayrı ayrı, yazılı şekilde tanımlanması, ilerideki tartışmaların büyük kısmını baştan önler.
Bakım kapsamına giren işler
Sunucu tarafındaki işletim sistemi ve veritabanı güncellemeleri, SSL sertifikası yenilemeleri, performans izleme, düzenli yedekleme testleri ve güvenlik taramaları bakımın standart parçalarıdır. Bir e-fatura entegrasyonu varsa, GİB tarafında yapılan bir protokol değişikliği de bu kapsama girer; çünkü yazılımın çalışır durumda kalması bu güncellemelere bağlıdır.
Destek kapsamına giren işler
Kullanıcıdan gelen hata bildirimleri, mevcut bir modülün davranışıyla ilgili sorular, küçük arayüz düzeltmeleri destek kapsamındadır. Yeni bir modül eklemek, farklı bir sisteme entegrasyon kurmak ya da mevcut iş akışını kökten değiştirmek genelde ayrı bir geliştirme talebi olarak fiyatlandırılır ve destek paketinin içinde sayılmaz.
Kurumsal yazılım destek süreci hangi aşamalardan oluşur
Destek süreci genelde bir talep kaydıyla başlar. Kurum tarafındaki kullanıcı veya IT sorumlusu, karşılaştığı sorunu bir ticket sistemine girer. Bu sistem gelen talebin kim tarafından, ne zaman ve hangi öncelikle bildirildiğini kayıt altına alan bir yazılımdır. Kayıt olmadan yürütülen bir destek ilişkisi, altı ay sonra "kaç talep geldi, hangileri çözüldü" sorusuna cevap veremez hale gelir.
Talep kaydedildikten sonra önceliklendirme yapılır. Sistemin tamamen çalışmaz hale gelmesi kritik, bir modülün kısmen çalışmaması yüksek, kullanım kolaylığıyla ilgili bir istek düşük öncelik olarak sınıflandırılır. Bu önceliklendirme, hangi sorunun ne kadar sürede yanıtlanacağını belirleyen SLA'nın temelini oluşturur.
-
Talep kaydı: sorunun tanımlanması ve sisteme girilmesi
-
Önceliklendirme: kritiklik seviyesine göre sıralama
-
İlk yanıt: teknik ekibin sorunu incelemeye başlaması
-
Çözüm veya geçici önlem: sorunun giderilmesi ya da iş akışının aksamaması için ara çözüm uygulanması
-
Kapanış ve dokümantasyon: çözümün kayıt altına alınması
Dokümantasyon adımı çoğu zaman atlanır, ama kurumsal ölçekte en kritik parçalardan biridir. Bir yıl sonra farklı bir teknik ekip devraldığında, geçmişte hangi sorunların nasıl çözüldüğünü bilmek, aynı hatayı sıfırdan çözmek zorunda kalmamak demektir.
SLA nedir ve kurumsal sözleşmede neye dikkat edilmeli
SLA, tedarikçinin hangi sürede yanıt vereceğini ve hangi sürede çözüm sunacağını taahhüt ettiği belgedir. Kritik bir arıza için "ilk yanıt 2 saat içinde, çözüm 8 saat içinde" gibi maddeler içerir. Buradaki ayrım önemlidir: yanıt süresi, birinin sorunla ilgilenmeye başladığı süredir; çözüm süresi sorunun fiilen giderildiği süredir. Bir sözleşmede yalnızca yanıt süresi yazıp çözüm süresi belirtilmemesi, kurumun beklentisiyle gerçekleşen arasında ciddi bir fark yaratabilir.
Kurumsal alımlarda satın alma ekiplerinin genelde gözden kaçırdığı bir nokta, SLA'nın çalışma saatleriyle ilişkisidir. "7/24 destek" ifadesi bazı tedarikçilerde yalnızca kritik arızalar için geçerliyken, düşük öncelikli talepler mesai saatlerine bırakılabilir. Bu ayrımın sözleşmede net yazılı olması, vardiyalı çalışan üretim tesisleri veya kesintisiz hizmet veren kurumlar için belirleyicidir.
Sözleşmede aranması gereken maddeler
- Yanıt süresi ve çözüm süresinin ayrı ayrı, öncelik seviyesine göre tanımlanması
- Kapsam dışı işlerin, yeni geliştirme veya ek entegrasyonun nasıl fiyatlandırılacağı
- Kaynak kodun ve dokümantasyonun kurumda mı yoksa yalnızca tedarikçide mi tutulacağı
- Sözleşme sona erdiğinde devir sürecinin nasıl işleyeceği
Bu son madde, kurumsal projelerde sıkça göz ardı edilen bir risktir. Kaynak kod ve teknik dokümantasyon yalnızca tedarikçide kalıyorsa, o firmayla ilişki bozulduğunda kurum başka bir ekiple devam edemez hale gelir. Bu bağımlılık riskini azaltmak için kaynak kodun düzenli aralıklarla kuruma teslim edilmesi ya da ortak bir depoda tutulması sözleşmeye madde olarak eklenmelidir.
Yaygın yanlış: bakım anlaşması olmadan da idare edilir düşüncesi
Bazı kurumlar, proje teslim alındıktan sonra bakım sözleşmesi yapmadan ilerleyebileceğini düşünür. Mantık şudur: sorun çıkarsa o zaman birini buluruz. Bu yaklaşım kısa vadede tasarruf gibi görünür ama gerçekte riski öne değil geriye atar. Sorun çıktığında, sistemi hiç tanımayan bir ekip acil durumda devreye girmek zorunda kalır ve bu hem daha yavaş hem daha maliyetli sonuçlanır.
Düzenli bakım anlaşması olan bir sistemde güncellemeler proaktif yapılır, güvenlik açıkları önceden kapatılır, performans sorunları büyümeden fark edilir. Bakım sözleşmesini bir gider kalemi değil, kesinti riskini önceden satın almak olarak görmek, kurum içi bütçe tartışmalarında daha sağlıklı bir çerçeve sunar.
Bakım ve destek maliyetini neler belirler
Bakım-destek maliyeti sabit bir sayı değildir, birkaç değişkene bağlı olarak şekillenir. Sistemin karmaşıklığı, entegre olduğu üçüncü taraf servis sayısı, kullanıcı sayısı ve beklenen yanıt süresi bu değişkenlerin başında gelir. Daha hızlı bir SLA isteniyorsa, tedarikçinin o kurum için ayrı kaynak ayırması gerekir; bu da maliyeti doğrudan etkiler.
Burada net bir denge kurulmalıdır: düşük maliyetli bir destek paketi genelde daha uzun yanıt süresi ve sınırlı kapsam anlamına gelir. Kritik üretim sistemleri için bu paket yetersiz kalabilir. Daha kapsamlı bir SLA ve daha kısa yanıt süresi isteniyorsa, bunun karşılığında daha yüksek bir aylık veya yıllık bakım bedeli kabul edilmelidir. Kurumun yapması gereken, sistemin durması halinde oluşacak kaybı gerçekçi şekilde tahmin edip destek paketini buna göre seçmektir. Muhasebe, CRM veya e-ticaret entegrasyonlarında yaşanan sorunların çoğu, aslında bakım aşamasında değil entegrasyon aşamasında yapılan hatalardan kaynaklanır ve bu hatalar sonradan bakım bütçesine yansır.
Bulut maliyetlerinin bakım bütçesine etkisi
Bulut altyapısı kullanan sistemlerde bakım maliyetinin bir kısmı döviz bazlı sunucu ve lisans giderlerinden oluşur. Kur dalgalanmaları bu kalemi zaman zaman öngörülenin üzerine taşıyabilir. Sözleşme yapılırken bu tür maliyetlerin sabit mi yoksa kur endeksli mi olacağı netleştirilmeli, aksi halde yıl içinde bütçe sapmaları yaşanabilir. Bu konuyu daha derinlemesine ele aldığımız bulut altyapısına geçişte maliyet ve güvenlik dengesi başlıklı yazımıza da göz atabilirsiniz.
Doğru bakım-destek ortağı nasıl seçilir
Bir kurumun bakım-destek ortağını seçerken teknik yeterliliğin yanında süreç olgunluğuna da bakması gerekir. Talep takip sistemi kullanıyor mu, düzenli raporlama yapıyor mu, kaynak kod paylaşımı konusunda şeffaf mı gibi sorular sözleşme öncesi netleştirilmelidir. Kurulan mimarinin bakıma uygun, okunabilir ve dokümante edilmiş olması da uzun vadeli destek maliyetini doğrudan etkiler; kötü kurgulanan bir sistem, en iyi destek ekibiyle bile pahalıya bakım gerektirir. Biz SUNS Tech olarak web tasarım ve geliştirme süreçlerinde bu yüzden dokümantasyonu proje teslimatının ayrılmaz bir parçası olarak görüyoruz.
Kurumsal projelerde bağımsız bir teknik değerlendirme, mevcut bir sistemin bakım süreçlerinin sağlıklı işleyip işlemediğini üçüncü bir gözle görmek için de kullanılabilir. Özellikle sözleşme yenileme dönemlerinde, mevcut SLA'ları ve maliyet yapısını dışarıdan bir ekiple gözden geçirmek, kurumun pazarlık gücünü artırır. Teknik borcun ne zaman refactoring gerektirdiğine dair yazdığımız teknik borç yönetimi içeriği de bu değerlendirme sürecine ışık tutabilir.
Bakım-destek sürecini kurarken atılacak adımlar
Kurumsal yazılımda bakım ve destek süreçlerini sağlıklı kurmak, projeyi teslim almadan önce başlayan bir plandır. İlk adım, bakım ve destek kalemlerini ayrı ayrı tanımlayan, SLA'ları önceliğe göre net yazan bir sözleşme hazırlamaktır. İkinci adım, kaynak kod ve dokümantasyonun kurumda da erişilebilir olmasını sağlayarak tek bir tedarikçiye bağımlılığı azaltmaktır.
Üçüncü adım, düzenli aralıklarla mevcut SLA'ların ve maliyet yapısının gözden geçirilmesidir; sistemin ölçeği büyüdükçe ilk imzalanan sözleşme yetersiz kalabilir. Projenizin kapsamına ve mevcut sisteminizin karmaşıklığına göre bakım-destek ihtiyacınızı netleştirmek isterseniz, ekibimizden teklif alarak durumunuzu birlikte değerlendirebiliriz. Geçmiş projelerimizde bu süreçleri nasıl kurguladığımızı görmek isterseniz portfolyomuza da bakabilirsiniz.
