Hayır, ITIL çeviklik için bir engel değildir!
Bir sonraki yazımızda görüşmek üzere….
Aslında bu yazıyı burada bitirebiliriz. 😊 Ama biraz bu çeviklik konusunu açalım.
Türkiye’de genel olarak yerleşmiş bir ön yargı var ITIL’a karşı. “ITIL süreçlerinin” bürokratik olduğu, çeviklik için engel oluşturduğu, kuruluşu ya da BT’yi hantallaştırdığı düşünülüyor. Siz de öyle mi düşünüyorsunuz?
Çeviklik
Günümüz koşullarında, bir kuruluşun başarılı olabilmesi için değişen koşullara uyum sağlayabilmesi gerekiyor. BT’nin kuruluşlar için vazgeçilmez olduğu bir dünyada, BT ve BT yönetimi için çeviklik artık bir “olmazsa olmaz”. Peki nedir bu çeviklik?
Pek çok BT uzmanı için çeviklik denildiğinde ilk olarak akla yazılım geliştirme ve 2001 yılında ilan edilen “Çevik Manifesto (Agile Manifesto)” gelir.
Zamanın bir grup öncü yazılım geliştirme uzmanı tarafından hazırlanan çevik manifesto,
- süreçler ve araçlardan ziyade bireyler ve etkileşimlere;
- kapsamlı dokümantasyondan ziyade çalışan yazılıma;
- sözleşme pazarlıklarından ziyade müşteri ile işbirliğine;
- bir plana bağlı kalmaktan ziyade değişime karşılık vermenin
daha değerli olduğunu öne sürer. (Bununla birlikte manifestoda şu cümlenin de yer aldığını söylemek gerek: “Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.”)
Bu manifestoyu temel alan çevik yazılım geliştirme yöntemleri genellikle:
- Geri bildirimler ve doğrudan gözlem yoluyla sürekli gelişen (değişen) gereksinimleri toplamak;
- Geliştirme çalışmasını küçük artışlara ve yinelemelere bölmek;
- Ürün bazlı, farklı yetkinliklere sahip kişilerden oluşan, kendi kendine yeten ekipler kurmak;
- İlerlemeyi görsel olarak yönetmek (Kanban) ve düzenli olarak tartışmak (günlük stand-up’lar);
- Her yinelemenin sonunda paydaşlara çalışan (en azından minimum uygulanabilir) bir yazılım sunmak
gibi ilkeler üzerine kurgulanır. Ama benim amacım çevik yazılım geliştirme üzerine uzun uzun yazmak değil. (Bu arada benim atladığım çok detay olabilir. Konunun uzmanı arkadaşlar kusuruma bakmasınlar. 🙂)
Değer akışları ve çeviklik
Başarılı bir şekilde uygulandığında çevik yazılım geliştirme, müşterilerin/kullanıcıların gelişen ihtiyaçlarına hızlı yanıt verilmesini sağlar. Fakat çoğu kuruluşta çevik yazılım geliştirme – genellikle yazılım geliştirmeyi takip eden diğer aşamalarda çeviklik bulunmaması nedeniyle – beklenen faydaları sağlayamaz.
Hizmet değer zincirini ve değer akışlarını hatırlayalım. Müşteriye/kullanıcıya değer sunmak için gerçekleştirilen adımlardan oluşan uçtan uca akışlar. Uygulamayı geliştirmek, test etmek yetmez. Uygulamanızı kullanıcı ile buluşturmak için devreye almanız lazım. Sonra işletmeniz!
Ne kadar çevik bir biçimde uygulama geliştirirseniz geliştirin, aynı çeviklikte devreye alamıyorsanız, işletemiyorsanız – yani çevikliğiniz bir anlamda “parçalanmış” ise – beklenen değeri, istediğiniz ölçüde yaratamazsınız.
Hani derler ya, “bir zincir, en zayıf halkası kadar güçlüdür”. Bir akış/süreç de en hantal adımı kadar çeviktir. Aslında BT’nin uçtan uca çevik olmasını sağlamak için bütüncül bir yaklaşım benimsemek, yani tüm hizmet yönetimi boyutları ve tüm hizmet değer zinciri faaliyetlerini göz önünde bulundurmak gerekir.
ITIL’ın çevikliğe yaklaşımı
Geçmişte uçtan uca çevikliğin önündeki en büyük engellerden biri, altyapı çözümlerinin katılığıydı. Yeni bir yazılım için gerekli altyapının devreye alınması aylar sürebiliyordu; bu durum tüm geliştirme çevikliğinin müşteri/kullanıcı için görünmez olmasına neden olabiliyordu.
Günümüzde teknolojinin gelişmesiyle bu sorun büyük ölçüde çözülmekte. Sanallaştırma, hızlı Internet ve bulut bilişim, kuruluşların BT altyapılarını bir hizmet veya kod olarak ele almasına olanak tanıyor. Böylece daha önce yalnızca yazılım için mümkün olan bir hızda altyapı değişiklikleri gerçekleştirilebiliyor.
Altyapı yapılandırması ve dağıtımına ilişkin bu tür temel teknik sorunların çözülmesi sayesinde çevik yöntemler altyapı ve operasyon için de artık uygulanabiliyor. Bu durum, yazılım ve altyapı ekiplerinin (ve dolayısıyla geliştirme ve operasyon arasındaki) birlikte çevik olmasını mümkün hale getiriyor.
Böyle bir ortamda, sanılanın aksine ITIL 4, hizmet yönetimini çevik hale getirmek için bize yol gösteriyor.
Örneğin daha önceki yazılarımızda tanıştığımız rehber prensipler ile çeviklik ilkelerinin bir kısmı örtüşüyor. Değere odaklanalım, geri bildirimler ile yinelemeli olarak ilerleyelim demiştik. İş birliği yapmak ve görünür hale getirmekten bahsetmiştik. Bu prensipler “çevikleşmemize” yardımcı oluyor.
Ya da bir bütün kitap (ve eğitim) boyunca yüksek hıza ulaşmak için kullanabileceğimiz yöntemleri paylaşıyor. (ITIL kitapları arasında yer alan “Yüksek hızda BT (High-velocity IT)” ile ilgili ayrıca konuşacağız)
Yani dikkatsizce, ezbere oluşturulan süreçler, özensiz bir biçimde kurgulanan uygulamalar bizi hantallaştırıyor. ITIL değil!
Teknoloji çevik olmamız için imkan sunarken hantal bir akışın/sürecin bizi yavaşlatmasına izin vermememiz gerekli! Fakat hızlı olmaya çalışırken de güvenilirliği ve sağlamlığı bir kenara atmamalı. Aslında dengeyi bulabildiğiniz oranda başarılı oluyorsunuz.
Bütüncül bir çeviklik
Çevikliği sadece bir yazılım geliştirme özelliği olarak görmek çok doğru değil. Çeviklik günümüzde BT’nin tümü için (hatta kuruluş için) önemli ve gerekli bir kavram. Çevik geliştirmeyi, çevik devreye alma, çevik işletme ile destekleyebiliriz. Hatta çevik kaynak sağlama, çevik proje yönetimi, çevik satın alma, vb. ile. Fakat bunun için belki de bir çok kuruluşta zihniyet değişikliğine ihtiyaç var.
Çevik olmak temel bir prensip olarak benimsenirse, bir kuruluşun sürekli değişen bir ortamda hayatta kalma ve başarılı olma olasılığı artabilir.
Aksine, parçalı bir şekilde uygulandığında ise çevik yöntemler kuruluş için maliyetli ve israfa yol açan karmaşıklıklara dönüşebilir.
Peki siz ne kadar çeviksiniz?
Çevikliği yazılım geliştirme dışına taşıyabiliyor musunuz? Altyapı/operasyon ekiplerinin daha “çevik” olmalarını sağlayabiliyor musunuz?
Her türlü sorunuzu, isteğinizi, önerinizi bekliyorum…
ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved