Uygulama bakım ve destek (AMS) modeli kurma rehberi

Uygulama bakım ve destek (AMS) neyi kapsar?

Uygulama bakım ve destek, canlıya alınmış bir yazılımın iş değeri üretmeye devam etmesini sağlayan işletim faaliyetlerinin bütünüdür. İngilizce karşılığı Application Management Services, kısaca AMS'tir. Konu yeni özellik geliştirmekten çok, var olan uygulamanın çalışır, güvenli, güncel ve kullanılabilir kalmasıdır: kesintilerin giderilmesi, hata düzeltmeleri, yama ve sürüm geçişleri, kullanıcı sorularının yanıtlanması ve küçük iyileştirmeler bu işin gündelik parçalarıdır.

AMS kurgusu kurulurken ilk ayrım bakım türleri üzerinden yapılır. Düzeltici bakım, üretimde ortaya çıkan hataları giderir. Önleyici bakım, henüz arıza vermemiş ama risk taşıyan bileşenlerle ilgilenir; örneğin eskiyen bir kütüphanenin güncellenmesi ya da veritabanı büyümesinin izlenmesi. Uyarlayıcı bakım, uygulamayı değişen çevreye uydurur: işletim sistemi sürümü, mevzuat değişikliği ya da entegre olunan başka bir sistemin yeni arayüzü. Geliştirici bakım ise iş biriminin istediği küçük ve orta ölçekli iyileştirmeleri karşılar. Bu bakım türleri aynı ekip ve aynı kuyrukta karışırsa hangi işin neden yapıldığı, kime ve nasıl faturalandığı belirsizleşir.

AMS, proje ekibinin canlıya aldıktan sonra uygulamayı bırakıp gittiği bir devir noktasında başlar. Projeden işletmeye geçiş iyi yönetilmezse destek ekibi, kodun neden öyle yazıldığını bilmeden ilk kesintiyi karşılamak zorunda kalır. Bu yüzden iyi bir kurgu, bilgi devrini sonradan akla gelen bir adım olarak değil, modelin ilk bileşeni olarak ele alır.

Destek kademeleri nasıl tasarlanır?

Destek kademeleri, bir talebin kimin elinde, ne kadar süre ve hangi yetkiyle çözüleceğini belirleyen katmanlı yapıdır. Amaç, her talebi doğrudan en pahalı uzmana taşımak yerine, çözülebilen işin mümkün olan en erken noktada çözülmesidir.

Tipik yapı şöyle çalışır: • İlk kademe: Kullanıcıyla ilk temas noktasıdır. Talebi kaydeder, sınıflandırır, bilinen çözümleri bilgi tabanından uygular, parola sıfırlama ya da yetki sorusu gibi tekrar eden işleri kapatır. Çözemediğini eksiksiz notlarla yukarı iletir. • Uzman kademe: Uygulamayı ve iş sürecini tanıyan analistlerden oluşur. Log inceleme, veri düzeltme, yapılandırma değişikliği ve kök neden analizi bu kademede yapılır. • Geliştirici kademesi: Kod düzeyinde müdahale gerektiren hatalar bu kademeye gelir. Düzeltme, test ve canlıya alma süreci değişiklik yönetimiyle birlikte yürür. • Üretici ve tedarikçi kademesi: Paket yazılımlarda ya da dış servislerde sorun sağlayıcıya aittir; bu kademe, sağlayıcıyla yazışmayı ve takibi üstlenir.

Kademe tasarımında şu kavramlar netleşmelidir: yönlendirme kuralı, yükseltme (eskalasyon) eşiği ve geri dönüş yolu. Hangi talebin hangi kademeye gideceği önceden yazılı olmalı; belirli bir süre içinde ilerleme yoksa talebin otomatik olarak üst kademeye taşınacağı bilinmeli; üst kademe işi çözdüğünde bilgi tabanına çözümü yazarak ilk kademenin bir sonraki seferde bunu kendisinin halledebilmesini sağlamalıdır. Bu geri besleme olmazsa üst kademeler aynı sorunlarla uğraşmaya devam eder ve model pahalılaşır.

Uygulama portföyü hangi ölçütle sınıflandırılır?

Her uygulama aynı düzeyde destek istemez. Portföy analizi, uygulamaları iş açısından kritikliklerine, kullanıcı çevrelerine ve teknik durumlarına göre gruplar. Muhasebe kapanışında kullanılan bir finans sistemi ile yılda birkaç kez açılan bir iç form uygulaması aynı destek penceresine ve aynı yanıt süresine ihtiyaç duymaz.

Sınıflandırmada sorulacak sorular açıktır. Uygulama durursa iş hangi noktada durur? Kullanıcılar çalışanlar mı, müşteriler mi, iş ortakları mı? Yasal bir yükümlülük ya da denetim izi bağlıdır mı? Teknoloji desteklenen sürümde mi, yoksa üretici desteğini çekmiş mi? Kodu ve dokümantasyonu bilen kişi hâlâ kurumda mı? Cevaplar uygulamaları kritik, önemli ve standart gibi destek düzeylerine ayırır; her düzey için çalışma saatleri, yanıt ve çözüm hedefleri, kullanılacak kademeler ve izleme yoğunluğu farklı tanımlanır.

Portföy çalışması bir yan fayda daha üretir: yinelenen, kimsenin sahiplenmediği ya da kullanımı çok düşen uygulamalar görünür olur. Bunlar emekliye ayırma, birleştirme ya da modernizasyon adaylarıdır. AMS maliyetinin önemli bir bölümü çoğu zaman az değer üreten eski uygulamalarda harcandığı için bu görünürlük, model kurulumunun en kârlı çıktılarından biridir.

Sözleşme ve ticari model nasıl seçilir?

Bakım ve destek hizmeti ister kurum içi bir ekiple ister dış hizmet sağlayıcıyla verilsin, ticari yapı sorumluluğun nasıl paylaşıldığını belirler. Sık görülen modeller birkaç ailede toplanır.

Kaynak tabanlı model, belirli yetkinlikte kişilerin zaman karşılığı çalıştırılmasıdır. Esnektir ve talep belirsizken kolaydır; ancak sonuç sorumluluğu çoğunlukla müşteride kalır ve verimlilik artışı sağlayıcıya ek kazanç değil, müşteriye azalan fatura olarak dönmeyebilir. Hizmet düzeyi tabanlı model, belirlenen yanıt ve çözüm hedefleri karşılığında sabit ya da kademeli bir bedel öngörür. Kesinti ve gecikme durumunda hizmet kredisi ya da yaptırım tanımlanabilir. Talep hacmi tabanlı model, çözülen talep sayısı ya da işlenen iş birimi üzerinden fiyatlar; hacim iyi tahmin edilebildiğinde şeffaftır.

Hangi model seçilirse seçilsin sözleşmede şunlar yazılı olmalıdır: kapsama giren ve girmeyen uygulamalar, bakım türleri ile geliştirme talebi arasındaki sınır, öncelik tanımları, ölçüm yöntemi, raporlama sıklığı, bilgi devri yükümlülüğü ve sözleşme bitişinde geri devir koşulları. En sık yaşanan anlaşmazlık, bir değişiklik talebinin hata mı yoksa yeni geliştirme mi olduğunun belirsiz kalmasıdır. Sınırı örnek vakalarla ekte tanımlamak, sonradan yaşanacak ticari sürtüşmeyi büyük ölçüde azaltır.

Kapasite ve talep nasıl yönetilir?

Destek ekibinin büyüklüğü ortalama talep sayısına göre değil, taleplerin zamana yayılış biçimine göre planlanır. Ay sonu kapanışı, kampanya dönemi, mevzuat değişikliğinin yürürlüğe girdiği tarih ya da büyük bir sürüm geçişi, talebi birkaç katına çıkaran tepe noktaları yaratır. Kapasite planı bu tepeleri bilir ve karşılığında esnek kaynak, nöbet düzeni ya da önceden hazırlanmış çözüm notları öngörür.

Talep yönetimi ise gelen iş türlerini ayırmakla başlar. Olay (incident), kullanıcının çalışmasını engelleyen kesintidir ve önceliklidir. Hizmet talebi, önceden tanımlı ve tekrarlanabilir istektir; yetki verme ya da rapor çıkarma gibi. Problem, aynı olayın tekrar tekrar yaşanmasına yol açan kök nedenin yönetimidir. Değişiklik talebi ise uygulamada yapılacak planlı bir müdahaledir. ITIL gibi servis yönetimi yaklaşımları bu ayrımı standartlaştırır; AMS ekipleri için ortak dil sağladığı için bu terimlerin ortak kullanılması işi kolaylaştırır.

Talep azaltma, kapasite artırmaktan çoğu zaman daha ucuzdur. Aynı hatanın tekrar tekrar gelmesi problem kaydı açılması gerektiğini gösterir. Kullanıcıların sık sorduğu soruların bilgi tabanına dönüşmesi, ilk kademenin çözüm oranını yükseltir. Otomatik izleme, kullanıcı şikâyet etmeden önce olaya müdahale imkânı verir. İyi işleyen bir AMS modelinde talep hacmi, uygulama sayısı arttıkça orantılı büyümez; çünkü sistem öğrenir.

Performans nasıl ölçülür, hizmet nasıl iyileştirilir?

Ölçüm, sözleşmedeki hedeflerin tutulup tutulmadığını ve kullanıcının hizmetten memnun olup olmadığını birlikte göstermelidir. Süreç ölçütleri arasında ilk yanıt süresi, çözüm süresi, yükseltme oranı, ilk temasta çözüm oranı ve bekleyen talep yaşlandırması sayılabilir. Uygulama sağlığı ölçütleri ise kesinti süresi, tekrar eden olay sayısı ve kullanılabilirlik düzeyini izler. Bunlara kullanıcı memnuniyeti geri bildirimi eklendiğinde rakamların arkasındaki deneyim de görünür olur.

Ölçütlerin tek başına hedef hâline gelmesi tehlikelidir. Yalnızca çözüm süresi ödüllendirilirse ekip talepleri erken kapatır, kullanıcı ise aynı sorunu yeniden açar. Bu nedenle ölçüt setinde dengeleyici çiftler bulunmalı: hız ile kalite, kapatma ile yeniden açılma, maliyet ile memnuniyet birlikte okunmalıdır.

İyileştirme döngüsü düzenli yönetim toplantılarıyla işler. En çok talep üreten uygulamalar, tekrar eden problemler ve hedefi kaçıran talep türleri ele alınır; her toplantıdan sahibi ve tarihi olan iyileştirme maddeleri çıkar. Bilgi devri de bu döngünün parçasıdır: ekipte değişiklik olduğunda yeni gelenin bilgi tabanı, çalışma talimatları ve uygulama belgeleriyle hızla verimli hâle gelebilmesi, modelin kişiye bağımlı olmamasını sağlar.

Bu konuyu Mindset programlarında nerede çalışırsınız?

Mindset'in Uygulama Bakım ve Destek (AMS) Modelleri ve Destek Kademeleri eğitimi, AMS kurulumunun ana başlıklarını müfredat olarak ele alır: uygulama yaşam döngüsü ve bakım türleri, uygulama portföyü analizi ve destek düzeyleri, destek kademelerinin tasarımı, sözleşme modelleri ve ticari yapı, kapasite planlama ve talep yönetimi, performans ölçümü ile bilgi devri ve iyileştirme.

Bu başlıklar sırayla düşünülürse bir kurumun kendi AMS yapısını kurma yolu da ortaya çıkar: önce neyin bakımı yapılacağı ve hangi türde olduğu, sonra hangi uygulamaya hangi düzeyde destek verileceği, ardından kademelerin ve sözleşmenin kurulması, son olarak kapasite ile ölçümün işletilmesi. Ayrıntılı program bilgisi eğitimin kendi sayfasındadır.