ITIL Foundation eğitimine parelel, temel konular ile ilgili yazılara devam ediyoruz. ITIL’da belki de en çok bilinen, en çok hayata geçirilen, uygulanan pratiklerden (süreçlerden) bir tanesi arıza/kesinti yönetimi bu yazıda konumuz.
İsterseniz ufak bir noktayı hatırlayalım. Daha önce izleme ve olay yönetimi ile ilgili yazıda da bahsetmiştim, ITIL’da iki farklı kavramın Türkçe çevirileri hemen hemen aynı! “Incident” ve “event” kavramları, Türkçeye genellikle “olay” veya “vaka” olarak çevriliyor.
Fakat bu çeviriler bir takım karışıklıklara yol açabiliyor. Bazı kuruluşlarda BT birimleri “incident” kavramını “vaka”, “event” kavramını “olay” olarak kullanırken; bazı BT birimlerinde, “event” kavramı “vaka”, “incident” kavramı “olay” olarak ele alınıyor.
Yine isterseniz “hangi kavramı kullanmak doğru olur?” tarzı tartışmalara çok girmeyelim. Büyük ölçüde bizim ihtiyacımızı karşılayacak “arıza/kesinti” ile devam edelim. Ama her zaman daha uygun, farklı kelimelere de açığım. 😊
Arıza/kesinti (Incident): Planlanmamış kesinti veya hizmet kalitesindeki düşüklük.
Amaç
Amacımız, yaşanmakta olan olumsuzluğun kullanıcılara olan etkisini en aza indirmek; bu arızayı/kesintiyi ya da kalite düşüklüğünü olabildiğince hızlı bir biçimde gidermek.
Mümkün olan en kısa sürede normal hizmet işleyişini yeniden sağlamak istiyoruz. Örneğin kullanıcı yazıcıdan çıktı alamıyor. Hızlı bir biçimde kullanıcının çıktı almasını sağlayalım. Veya bir bilgiye ulaşmak için Internet’e erişmesi gerekli ama erişemiyor. Internet erişimini sağlayalım.
Ne kadar kısa sürede arıza/kesinti (incident) için çözüm sağlayabilirsek, kullanıcı o kadar memnun kalacak. O yüzden hız önemli! Yaşanan olumsuzluğu kalıcı olarak gidermek önceliğimiz değil, şimdilik geçici veya alternatif çözümler de bizim için yeterli. Örneğin, kullanıcının başka bir yazıcıdan çıktı almasını sağlamak da işini görebilir. Ya da Internet erişimini geçici olarak farklı bir cihazdan verebiliriz.
Yani önce “yangını söndürmek” istiyoruz. Yangının çıkış nedenleri ve yangının tekrarlamaması için alınabilecek önlemler ile daha sonra ilgileniriz.
Peki bu olumsuzlukları yönetmek için ne yapmalı?
Süreç
Hatırlıyor musunuz “basit ve pratik tutmak” ile ilgili bir prensibimiz vardı. Biz de basit ve pratik tutalım mı?
Aslında temel işleyişimiz son derece basit:
İsterseniz birlikte akış üzerinden hızlıca geçelim:
- Önce bir arıza/kesinti veya kalite düşüklüğü yaşanmakta olduğunu tespit ediyoruz. Kullanıcılardan gelen bildirimler ile bu durumun farkına varıp, gerekli çalışmaları başlatabiliriz. Fakat aslında yaşanmakta olan arızayı/kesintiyi ne kadar erken tespit edersek, o kadar iyi. Hatta mümkünse kullanıcı farkına varmadan bu durumu algılayıp hızlıca harekete geçelim istiyoruz. İzleme ve olay yönetimi pratiği ve izleme araçları bize bu konuda yardımcı oluyor.
- Kullanıcı tarafından iletilen veya izleme aracılığıyla tespit edilen arızaları/kesintileri kayıt altına alıyoruz. Gerek arıza/kesinti yönetimi sürecini gerekse diğer birçok süreci etkin bir biçimde işletebilmek için BT hizmet yönetimi yazılımlarından yararlanıyoruz.
- Arızayı/kesintiyi, doğru ekibe hızlı bir şekilde aktarabilmek için sınıflandırıyoruz. Sınıflandırma sayesinde daha sonra arızaları/kesintileri analiz etme şansımız da olacak.
- Elimizdeki insan kaynağı çoğu zaman sınırlı. Ekipler aynı anda birçok başka iş ile de ilgileniyor. Bir kaynak çatışması söz konusu ise, doğru zamanda, doğru konuya doğru kaynağı aktarabilmek için arızayı/kesintiyi önceliklendiriyoruz. Önceliklendirme sırasında işe olan etkiyi göz önünde bulunduruyoruz.
- Elimizde uygulayabileceğimiz, hazır bir çözüm varsa hızlıca ilgili ekiplerin bu çözümü uygulamasını sağlıyoruz.
- Hazır bir çözümümüz yoksa, arızanın/kesintinin zorluğuna göre, arızayı/kesintiyi ilk karşılayan ekip teşhis, tanı çalışmalarını gerçekleştiriyor. Eğer konu uzmanlık getiren bir konuysa, arıza/kesinti ilgili ekiplere vakit kaybetmeksizin aktarılıyor. Teşhis/tanı çalışmaları ilgili ekip tarafından gerçekleştiriliyor.
- Eğer arızayı/kesintiyi gidermek için bir çözüm bulunduysa bu çözümü uyguluyoruz. Çözümün uygulanması için değişiklik gerekebilir, bu gündeme değişiklik yönetimini getiriyor!
- Teşhis/tanı çalışmalarında herhangi bir çözüm bulamadıysak, konuyu daha derin bir biçimde analiz etmek gerekebilir. Problem yönetimine göz kırpıyoruz.
- Çözümün uygulanması, her şeyin tamamlanması anlamına gelmeyebilir. O yüzden çözüm sonrası arızayı/kesintiyi yaşamakta olan kullanıcılardan bir onay bekliyoruz. Olumsuzluğu giderebildiysek, hizmeti çalışır hale getirebildiysek kaydımızı kapatıyoruz. Yok eğer arıza/kesinti giderilemediyse, çalışmalarımıza devam ediyoruz.
Her şeyden önemlisi hızlı ve çözüm odaklı hareket ediyoruz.
Majör arızalar/kesintiler (major incidents) ve sibergüvenlik ihlalleri (cybersecurity incidents)
Bazı arızaların/kesintilerin etkileri çok büyük olabiliyor, bu tür arızalar/kesintiler dramatik sonuçlara yol açabiliyor. Kurum için kritik iş süreçlerini ciddi biçimde etkileyen arızalar/kesintiler, majör (ya da büyük) arıza/kesinti olarak adlandırılıyor. Genellikle işi, üretimi durduran arızalar/kesintiler bunlar.
Bu tür durumlar özel ilgi, farklı bir yaklaşım gerektiriyor. Örneğin, majör bir arıza/kesinti ile karşılaşıldığında, tüm ilgili paydaşlar ile iletişim için bir koordinatör ya da yönetici belirlenebilir. Çözüm süresi boyunca belirli aralıklarla kritik paydaşlar bilgilendirilebilir. Belki hızlı bir biçimde ilgili teknik uzmanları bir araya getirmek daha çabuk çözüm elde edilmesini kolaylaştırabilir.
Benzer şekilde sibergüvenlik ihlallerini (cybersecurity incidents) de ayrı bir biçimde ele almakta fayda var. Mesela müdahele planları oluşturarak, olası sibergüvenlik ihlallerine karşı önceden hazırlanılabilir. Ya da herhangi bir sibergüvenlik ihlalinin yaşanması durumunda, bir an önce ihlalin yaşandığı sistem izole edilebilir.
Bu arada sibergüvenlik tarafında da incident ve event kavramlarının Türkçe kullanımına birilerinin el atması gerekmiyor mu sizce de!?
Ölçme ve iyileştirme
Amacımız arızayı/kesintiyi ya da kalite düşüklüğünü olabildiğince hızlı bir biçimde gidermek. Peki acaba bu amaca uygun hareket edebiliyor muyuz? Bunu anlamak için çeşitli ölçümlerden yararlanabiliriz.
Yaşanan arızaların/kesintilerin, ne kadar sürede çözüldükleri, eğer tanımlı bir çözüm süresi hedefi varsa bu hedefi tutturma oranları ilk akla gelen ölçümler arasında.
Bununla birlikte:
- İzleme araçları tarafından açılan arıza/kesinti kayıtlarının tüm kayıtlara oranı (erken tespit yeteneğini değerlendirmek için),
- Birinci seviye ekipler tarafından çözülen arıza/kesinti yüzdesi (arızalar/kesintiler ile ilk ilgilenen ekiplerin yetkinliklerini değerlendirebilmek için),
- Arızalar/kesintiler sonrası düzenlenen anket sonuçları (kullanıcı memnuniyetini yorumlayabilmek için)
izlenebilir.
Ben bir de, bir çok kurumda çok uzun süredir ilgi bekleyen kayıtların var olduğunu gözlemliyorum. Bunların sayısı genelde çok değil ama tek tük de olsa yine de var. Örneğin 90 gündür açık kayıt. E hani amacımız bir an önce çözmekti? Burada bir başka durum var demek. Bu tür kayıtların incelenmesi hiç de fena olmaz!
Şunu da unutmayalım, süreç başlangıçta istediğimiz şekilde olmayabilir. Bir şeyleri yanlış, eksik yapmış olabiliriz. Önemli olan nelerin yürüdüğünü, nelerin yürümediğini, eksiklikleri, hataları fark etmek ve iyileştirmek.
Hiç bir süreç, politika taşa yazılı değil. Hiç uygulama değiştirilemez, geliştirilemez değil. İşler istediğimiz gitmiyorsa değiştirmekten, iyileştirmekten kaçınmayalım.
Birkaç ufak nokta
Yukarıda kısaca tarif ettiğimiz süreci işletirken bir kaç konuyu göz önünde bulundurmakta fayda var:
- Amacımız bir an önce arızayı/kesintiyi gidermek. Gecikmek istemiyoruz. Oluşturduğumuz sürecin, süreci işletmek için kullandığımız yazılımın bu amacımızı desteklemesi ve bizi hızlandırması gerek yavaşlatması değil!
- Arızayı/kesintiyi mümkün olduğunca ilk karşılayan ekibin çözmesini sağlamak, daha deneyimli uzmanların analizlere, yeni projeler ve yaratıcı işlere odaklanabilmelerine yardımcı olabilir. O zaman bilgi paylaşımını sağlamak şart!
- Unutmayın, kayıt altına alınmamış her arıza/kesinti gösteremediğimiz iş anlamına da geliyor. Belki de ilk hedef tüm arızaları/kesintileri kayıt altına almak! Kullanıcının size ilettiği arızayı/kesintiyi kaydetmeden çözerek belki kullanıcıya “hoşluk” yaptığınızı düşünüyorsunuz ama kendinize kötülük yapıyorsunuz!
Bir de şöyle bir konu var: Süreci tanımladınız, bir hizmet yazılımı uygulamasını da kullanmaya başladınız. “Tamam daha ne olsun, artık işimiz bitti” diye düşünmeyin. Bu süreç kendi kendine işlemiyor! Bu süreci BT çalışanları işletiyorlar. Süreç ile ilgili, yazılım ile ilgili ekiplere eğitimlerin verilmesi; bir süreç sorumlusu/yöneticisi aracılığıyla süreç işleyişinin koordinasyonunun, kontrolünün sağlanması oldukça önemli.
Peki ben ne yapabilirim?
Arızaların/kesintilerin ve kalite düşüklüklerinin çözümü kullanıcı memnuniyetini direk olarak etkileyecek en önemli faktörlerden. Bu yüzden sizin de arızaları/kesintileri yönetmek için bir yaklaşım geliştirmenizde fayda var.
- İşe çalışma kapsamını belirleyerek başlayabilirsiniz. Tüm BT ile ilgili arıza/kesinti ve kalite düşüklükleri ilgi alanımızda olacak yoksa sadece bir ekibe mi yoğunlaşacağız?
- Kapsam doğrultusunda sürece dahil olacak ekipleri ve ekip temsilcilerini belirleyebilir, sorumlulukları tanımlayabilirsiniz. Hatta süreç ve/veya prosedür oluşturmadan, ana hatları ile temel kurallarımızı tanımladığımız bir politika oluşturmak harika olur.
- Mümkünse kullanıcılardan gelen tüm bildirimler için (arıza/kesinti dışında, istekler de dahil) tek bir iletişim noktası oluşturmak oldukça önemli. Gerek bildirimler ve gerekse kullanıcı iletişimi için arayüz görevini üstlenecek bir hizmet masası düşünülebilir.
- Bu arada süreç işleyişini de tasarlayabilirsiniz. Yukarıdaki adımları ipucu olarak kullanmaktan kaçınmayın. Bu arada prensibimizi unutmayın: basitlik ve pratiklik kazandırır. Sürecinizin anlaşılır ve daha çok uygulanır olmasına yardımcı olur.
- Bu yazıda çok detaya girmediğimiz ama işletim sırasında size yardımcı olabilecek bazı tanımları baştan yapmak faydalı olabilir. Örneğin öncelik seviyeleri neler olacak, önceliği hangi kriterlerden yararlanarak, nasıl belirleyeceğiz? Ya da kategoriler neler olacak, sınıflandırmayı nasıl yapacağız? Hangi tür arızaları/kesintileri hangi ekiplere aktaracağız?
- Süreci işletebilmek, yaşanan arızaları/kesintileri takip edebilmek ve yönetebilmek için bir BT Hizmet Yönetimi (ITSM) yazılımına ihtiyacınız olacak. Merak etmeyin ücretli, ücretsiz onlarca yazılım var. Fakat kurumunuza, ekibinize (ve hatta kullanıcılarınıza) uygun bir çözüm seçmek biraz zaman alabilir! Kendinize göre uyarlamak ve kullanıma almak da öyle! 😀
- Süreç işletimi sırasında gerekli koordinasyonun sağlanması, süreç etkinliğinin izlenmesi, değerlendirilmesi için özellikle bir süreç yöneticisi/sorumlusu belirlemeyi unutmayın! Eğer bir hizmet masası oluşturduysanız, ilk etapta hizmet masası yöneticisine de bu görevi verebilirsiniz.
- Çözüm süresi ve kullanıcı memnuniyeti gibi sürecin etkinliğini ölçmek için yararlanacağınız ölçümleri belirleyip, en kısa sürede ölçmeye başlamak süreç işleyişini gözlemlemenize yardımcı olur.
- Tüm bunların yanı sıre süreç kapsamında görev alacak tüm ekip için eğitimler düzenlemeyi, farkındalık çalışmaları geliştirmeyi de ihmal etmemek gerek…
Uzun lafın kısası…
Hiç bir şey yapmasak da, iyi bir BT hizmeti sunmak istiyorsak, kullanıcıların karşı karşıya kaldıkları arızaları/kesintileri, kalite düşüklüklerini gidermek zorundayız.
Ama uygun ekipler aracılığı ile hızlı çözüm üretebilmek, kullanıcı memnuniyetini arttırabilmek, zaman içerisinde daha doğru kaynak planlayabilmek, hangi konularda, ne tür olumsuzluklarla karşı karşıya kaldığımızı belirlemek için sistematik bir yaklaşım geliştirmek faydalı olabilir. Bu konuda arıza/kesinti yönetimi (incident management) pratiği size yol gösteriyor.
Peki hiç arıza/kesinti yaşanmasa daha iyi değil mi? Tabii ki evet ama o konuyu daha sonraya bırakalım isterseniz.
😊
Bu arada aklınıza takılan her türlü soruyu ya da isteklerinizi, önerilerinizi bekliyorum…
ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.