Türk Dil Kurumu problem kelimesini “sorun, mesele” olarak tanımlamış. Genellikle kullancılar, sunduğumuz hizmetler ile ilgili bir sıkıntı yaşadıklarında “benim bir problemim var” diyerek bize ulaşıyorlar. Fakat ITIL’a göre bu bizim problemimiz değil.
😊
Daha önce arıza/kesinti yönetimi (incident management) kapsamında kullanıcıların yaşadıkları sıkıntılar ile ilgilenmiş; “hızlı olalım, geçici de olsa çözüm üretelim, günü kurtaralım” demiştik.
Problem yönetiminde ise bu arızaların/kesintilerin ortaya çıkma nedenlerini (veya olası nedenlerini) analiz etmeye, mümkünse kalıcı çözümler geliştirmeye odaklanıyoruz.
Yani ITIL için problem kavramı kök neden ile ilişkili:
Problem: Bir veya birden fazla arızanın/kesintinin nedeni (veya potansiyel nedeni).
Bu arada çok sıklıkla kullanılmasa da, bize yardımcı olacak bir tanımımız daha var:
Bilinen hata (known error): Analiz edilmekte olan ancak henüz kalıcı olarak çözülememiş problem.
Amaç
Amacımız, bizi etkileyen, üzen arızaların/kesintilerin asıl (veya olası) nedenlerini belirlemek. Mümkünse kalıcı çözümler – olmuyorsa geçici çözümler – geliştirmek; arızaların/kesintlerin tekrarlama olasılıklarını ve etkilerini azaltmak.
Bir bakıma “yangın söndürme” modundan çıkmayı hedefliyoruz. Biraz daha sakin bir şekilde ne olup bittiğini anlayalım, inceleyelim. Arızanın/kesintinin bir daha yaşanmaması için ne yapılabileceğini sorgulayalım, kök nedeni tamamen ortadan kaldıracak çözümler bulalım!
ITIL’da problem yönetimini üç temel fazda ele alınıyor:
Problemlerin Belirlenmesi
Bir kere hemen ilk paragrafta yazdığımızı tekrarlayalım. Kullancıların “bir problemim var” diyerek bize ilettiği sıkıntılar bizim problemimiz değil. Bu tür sıkıntılar için ilk başvuru kaynağı arıza/kesinti yönetimi (incident management).
Problem yönetiminde işe “kök neden analizi gerçekleştirmeye değecek” sıkıntıları belirleyerek başlıyoruz.
Elimizde sınırsız kaynak, sınırsız zaman olsa, yaşanan tüm sıkıntıların kök nedenlerini analiz etmek, bu sıkıntılara kalıcı çözümler bulmak çok güzel olabilirdi. Ama sınırsız kaynağımız ve zamanımız yok! Bu durumda elimizdeki kısıtlı kaynağı gerçekten değecek konular için kullanmakta fayda var.
Örneğin kronik hale gelmiş, sürekli tekrarlayan arızalar/kesintiler için kök neden analizleri gerçekleştirebiliriz. Ya da henüz tekrarlamıyor olsa da bir daha karşılaşmak istemeyeceğimiz (genellikle kapsamı ya da etkisi büyük) arızalar/kesintiler için kök neden analizleri anlamlı olabilir.
Reaktif vs. Proaktif Problem Yönetimi
Biraz detaya girdiğimizde, problemlerin tespit edilmesine yönelik iki temel yaklaşım karşımıza çıkıyor: reaktif yaklaşım ve proaktif yaklaşım. Zaman zaman bu kavramlar, ”reaktif problem yönetimi” ve “proaktif problem yönetimi” olarak da kullanılıyorlar.
Reaktif yaklaşım, daha önce meydana gelmiş arızaların/kesintilerin (incidents) nedenlerini araştırmaya odaklanıyor. Bu yaklaşımda amaç, arızaların/kesintilerin tekrarlanmasını önlemek, eğer varsa henüz giderilmemiş arızaların/kesintilerin çözümüne katkı sağlamak.
Yani bir yaşanmışlık üzerine tepki veriyoruz, analiz çalışmalarını tetikliyoruz.
Proaktif yaklaşım ise arızalar/kesintiler meydana gelmeden önce problemi belirlemeye, ilgili riskleri değerlendirmeye; arızaların/kesintilerin olasılıklarını ve/veya etkilerini en aza indirme amacıyla ne yapılabileceğini bulmaya odaklanıyor.
Bir bakıma henüz bir arıza/kesinti yaşanmadan arızanın/kesintinin yaşanabileceğini fark ediyoruz ve gerçekleşebilecek arızanın/kesintinin önüne geçmek için analiz çalışmalarını başlatıyoruz.
Peki henüz bir arıza/kesinti (incident) yaşanmadan, böyle bir durumun yaşanabileceğini nasıl fark edebiliriz?
Aslında proaktif yaklaşım için beslenebileceğimiz birçok farklı bilgi kaynağı var:
- Üretici firmaların, ürünlerinde tespit ettikleri açıklar, sorunlar;
- Henüz canlı sistemleri etkilememiş, yazılım veya test ortamlarında fark edilen arızalar, hatalar;
- Diğer kurumlarda/şirketlerde yaşananlar – hatta teknik forumlarda veya kullanıcı topluluklarında duyduklarımız;
- İzleme araçları aracılığı ile gözlenen performans sapmaları,
- Teknik değerlendirmeler ve/veya denetimler sırasında ortaya çıkan konular.
Tüm bu yukarıdakiler (ve hatta daha fazlası) problem yönetiminin tetiklenmesine neden olabilir.
Problem Kayıtları
Kök neden analizine değer durumları belirledikten sonra, problem çözümüne yönelik gerçekleştireceğimiz tüm çalışmaları düzenli bir şekilde takip edebilmek için bir problem kaydı oluşturuyoruz.
Problem kayıtları, ne üzerinde çalıştığımızı, vaktimizi ne için harcadığımızı görmek ve göstermek açısından önemli.
Bir taraftan da, bu problem kayıtları, ileride farklı ekiplerin gerçekleştirdikleri analizlere ilişkin değerlendirmeleri, geçici veya kalıcı çözüm önerilerini paylaştıkları bir bilgi paylaşım platformunun temelini atmamıza yardımcı olabilir!
Problem kaydını oluştururken, kök neden analizi kararını vermemize neden olan diğer kayıtlar (örneğin arıza/kesinti(incident) kayıtları) ve BT bileşenleri ile ilişki kurmak ne güzel olur. Böylelikle takip edilebilirliği de bir nebze sağlamış oluruz. İleride sorulabilecek “Bu problem kaydı neden oluşturulmuştu?” gibi soruları cevaplamamız kolaylaşır.
Problem Kontrolü
Kök neden analizine değer durumları belirleyip, problem kaydı oluşturduktan sonra problemi ilgili kişiye (ve/veya ekibe) atayıp analiz çalışmalarını başlatacağız. Fakat bir saniye, önce hangi problemi analiz etmeli?
Problem yönetimi anlaşılıp kullanıldıkça, açılan problem kayıtları – dolayısıyla kök neden analizi beklentileri – artıyor. Fakat elimizde kök neden analizi yapabilecek yetkinlikte kaynak kısıtlı. Problemleri bir sıraya sokmak, ilk olarak üzerinde çalışılacak problemleri belirlemek, kaynaklarımızı daha kritik konulara aktarmak için önceliklendirmeden yararlanıyoruz.
Pratikte, problemlerin önceliklendirilmesi için en sık kullanılan yöntemlerden biri, arıza/kesinti yönetiminde (incident management) olduğu gibi etkiyi ve aciliyeti değerlendirerek bir öncelik belirlemek.
Fakat aslında problemlerin önceliklerinin belirlenmesi sırasında farklı yöntemler kullanılabilir. Reaktif problemler ile proaktif problemler için etki ve aciliyet farklı biçimlerde ele alınabilir. Örneğin proaktif olarak belirlenmiş (henüz kullancılara yansımamış) problemler için, arıza/kesinti gerçekleşme olasılığını, ya da kullanıcının etkilenme olasılığını göz önünde bulundurarak bir öncelik belirleyebiliriz. (Belki bu konuyu ayrıca ele almamız iyi olabilir.)
Problem Analizi
Sıra geliyor analiz çalışmalarına. Analiz çalışmaları, bir çok farklı kaynaktan alınacak bilgilerin uzmanlar tarafından incelenmesini, değerlendirilmesini, duruma göre farklı ekiplerin veya tedarikçilerin devreye girmesini gerektiren zaman alabilecek çalışmalar.
Yaşanan arızaların/kesintilerin genellikle birbiriyle ilişkili birçok – ve karmaşık – nedeni olabiliyor. Analiz çalışmaları sırasında, arızaların/kesintilerin sürelerine ve etkilerine katkıda bulunan (veya bulunması olası) tüm nedenlerin dikkate alınmasında fayda var. O yüzden problemleri sadece teknik açıdan değil, hizmet yönetiminin dört boyutu perspektifinde analiz etmek istiyoruz.
Örneğin, analizlerimiz sırasında, bize sıklıkla iletilen bir tür kullanıcı bildiriminin yanlış bir yapılandırmadan kaynaklandığını tespit edebiliriz! Bu problemi ortadan kaldırmak için yalnızca söz konusu yapılandırmayı düzeltmek yeterli olmayabilir. Aynı zamanda dokümantasyonu güncellemek, belki de destek personeli, tedarikçiler ve kullanıcılar için eğitim ve farkındalık çalışması gerçekleştirmek gerekebilir.
Bu arada, analiz çalışmaları sırasında edinilen bilgiler, zaman zaman geçici çözümlerin oluşturulmasına da yardımcı olabiliyor.
Gerek geçici çözümlerin, gerekse analiz sırasında edinilen bilgilerin, ilgili tüm ekipler ile paylaşılması çok iyi olmaz mı? Hatta belki bu tür çözümler, bir bilgi deposu (knowledge base) oluşturmamıza da ön ayak olabilir.
Düşünecek olursak, analiz çalışmalarını gerçekleştiren kişiler, konunun uzmanı olan, bilgili, tecrübeli kişiler. Problem yönetimi, bu tecrübeli uzmanlardan, genç ve tecrübesiz ekiplere bilgi aktarımını sağlamak için bir araç olarak kullanılabilir!
Hata Kontrolü
Problem yönetiminin üçüncü ve son fazı, hata kontrolü fazı.
Sonuçta elimizde bir problem var, bu problemi kalıcı olarak çözmenin bir yolunu bulmak fena olmaz!
Hata fazı, belirlenen kök neden(ler)i kalıcı olarak ortadan kaldırabilecek potansiyel çözümlerin belirlenmesi ve hayata geçirilmesi ile ilgili. Hazırlanan kalıcı çözümlerin bir çoğunu hayata geçirmek için ise değişiklik yönetimine başvuracağız. Ama bu tamamen apayrı bir konu, bir sonraki yazımızda değişiklikleri konuşalım.
Bu arada, tabii ki kalıcı çözümü göz kapalı uygulamak istemiyoruz! Kalıcı çözümü gerçekleştirme maliyetini, riskleri, karşılığında elde edilecek faydaları değerlendirerek bir karar vermek önemli.
Örneğin etkili bir geçici çözüm, problemin kalıcı çözümü uygulanabilir olmadığında veya yüksek maliyetli olduğunda, problemler ile başa çıkmak için kullanılan kalıcı bir yol haline gelebilir.
Yani elimizde kalıcı çözüm olsa bile geçici çözümler ile günü kurtarmaya devam etmeyi tercih edebiliriz! Hatta bazı durumlarda geçici çözümü iyileştirmeyi (belki otomatik hale getirmeyi) bile düşünülebiliriz.
Bazen de o kadar uzun süren analiz çalışmalarına rağmen, bir ilerleme olamayabiliyor. Sizler de yaşamışsınızdır, bildiğiniz, tıkanabiliyoruz!
O zaman düzenli olarak, henüz üzerinde çalışılmakta olan, bilinen hataların durumlarını değerlendirmekte fayda var.
Bu değerlendirmeler sırasında, bilinen hataların (known errors),
- müşteriler üzerindeki genel etkilerini,
- bu bilinen hatalar ile ilgili mevcut geçici çözümlerin etkinliklerini,
- kalıcı çözümlerin uygulanabilirliklerini, vb.
göz önünde bulundurabiliriz. Elimizdeki kısıtlı kaynakları, bu değerlendirme çalışmaları doğrultusunda, daha öncelikli noktalara yönlendirebiliriz.
Analiz çalışmaları uzun sürebiliyor demiştik, bu uzun analiz çalışmaları sırasında, konu önceliğini yitirmiş olabiliyor. Fayda sağlamayacağını bile bile, kök neden analizlerini sürdürmenin çok anlamı yok!
Bu değerlendirmeler ışığında, bazı problemler üzerinde devam etmekte olan analiz çalışmalarını durduruyoruz/donduruyoruz. Kaynaklarımızı başka problemlerin analizine yönlendiriyoruz.
Peki ben ne yapmalıyım?
Aslında bir çoğumuz, adına “problem yönetimi” demesek de, problem yönetimi ile ilişkili aktiviteleri gerçekleştiriyoruz.
Bazen yaşadığımız olayların kök nedenleriniz analiz ediyoruz, geçici çözümler geliştiriyoruz. Bazen kalıcı çözümler buluyoruz, uyguluyoruz. Bana kalırsa tüm bu yaptıklarımızı sistematik hale getirmek, bir alışkanlık edinmek çok zor değil.
Peki ne yapabiliriz?
- Bir an önce kayıt altına almaya başlayın! ITIL prensiplerini hatırlayın: bulunduğun yerden başla, basit ve pratik tut. İlk adım problemleri kayıt altına almak olabilir.
- Değere odaklanın. Gerçekten fayda sağlayacak problemleri önceliklendirin.
- Bütüncül düşünün ve iş birliği yapın. Günümüzde sistemler karmaşık. Her şey birbirine dokunuyor. Doğru kişileri, problem yönetimine dahil edin. Birlikteliği sağlayın.
- Analiz için bilgili, tecrübeli, yetkin kişilere, uzmanlara ihtiyacımız var. Çözüm üretebilmeleri için uzmanlara zaman ve alan yaratın.
- Bilginin (ve birikimin) paylaşımını sağlayın. Uzmanların elde edikleri geçici (veya kalıcı) çözümleri paylaşabilecekleri ortam oluşturun. Bir bilgi deposu oluşturmaya başlamak için en uygun zaman şu an!!
- Problem kayıtlarını ilgili bileşenler ile, arıza/kesinti kayıtları ve değişiklik kayıtları ile ilişkilendirin. Takip edilebilirliği sağlayın….
Uzun lafın kısası…
Günü kurtarmak, yangını söndürmek elbette gerekli ama yeterli değil. Tekrar tekrar aynı arızalarla/kesintilerle uğraşmak uzun vadede maliyetli olabilir. Üstelik ekibin motivasyonunu ciddi şekilde düşürebilir.
Kronikleşen sorunları kökten çözebilmek, sunulan hizmetlerin kalitesini arttırabilmek, belki biraz olsun normalleşebilmek için problem yönetimini denemeye değer.
😊
Bu arada problem yönetimi ile ilgili aklınıza takılan herhangi bir soru ya da istek olursa çekinmeden bana ulaşabilirsiniz…
ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.