Bu yazı dizisinde bir BT için operasyon modeli nedir? Nasıl kurgulanmalıdır ve kurumsal mimarın görevi operasyon modelinin tasarımı aşamasında neler olmalıdır konularına değineceğim.

Birçok şirket ve organizasyon hem teknolojinin hem de rekabetin gittikçe sertleşmesi sebebiyle, konfor alanlarından çıkıp yeni servisleri sunmakta ve iş modellerinde köklü değişikliklere gitmektedirler. Bu değişime paralel bir şekilde, şirketlerin BT organizasyonları da şirket hedeflerine varması için en uygun şekilde organize olmalı, şirket içinde doğru şekilde konumlandırılmalı ve servislerini tam zamanında ihtiyaç duyulan değere göre sunmalıdır.

Bu sebeplerden dolayı her BT organizasyonun şirket hedeflerine göre yaşayan, sürekli değişim gösteren ve en önemlisi anlaşılır bir şekilde kurgulanmış operasyon modeli olmalıdır. Genelde BT’ler operasyon modelini oluşturan bileşenleri içgüdüsel olarak veya zorunluluktan dolayı bir şekilde tanımlamaktadırlar ama bu sürecin planlanmasından hayata alınmasına kadar geçen evreleri bir disiplin çerçevesinde yürütmemektedirler.

Operasyon Modeli Nedir:

Operasyon modeli adından da anlaşıldığı üzere bir organizasyonun değer yaratmak için neler yaptığı ve neleri kullandığını gösteren bir modeldir. Aşağıdaki şekilde de inceleyeceğiniz üzere, Operasyon Modeli, stratejimiz ile işleri nasıl hallettiğimiz yani gerçek hayat arasındaki köprüdür ve stratejinin belirlediği aksiyonların nasıl yürütüleceğini belirlemede kullandığımız araçlardan biridir.

Maalesef, günümüzde birçok şirketin BT organizasyonları yeni teknoloji ve servisleri devreye alırken veya organizasyon yapılarında köklü değişikliklere gidip yeni rolleri eklerken çalışma şekillerini doğru şekilde değiştirmedikleri veya ihtiyaç duyulduğu anda gerekli kabiliyetlere sahip olamadıkları için iş birimlerine hedeflenen katkıyı sağlayamıyor, değer üreten bir birim olarak kendini konumlandıramıyor.

BT Operasyon Modelimi neden değiştirmeliyim?

Dijitalleşmenin getirdiği yeni BT kabiliyetlerinin (IT Capability) nasıl kazanılması gerektiği konusu, BT ve operasyonel teknolojilerin artık hiç olmadığı kadar iç içe geçmesi, çevik ve çoklu disiplinlere sahip organizasyonlara doğru everilmemiz sebebiyle klasik operasyon modelleri artık sürdürülebilir olmaktan çıkmıştır. Artık kontrolden çok karar vermeyi destekleyecek, maliyet ölçümünden çok yaratılan değerin ölçüldüğü ve her şeyi kendi başına halletmek yerine doğru zamanda doğru kaynaklara erişebilecek bir modele ihtiyaç duyulmaktadır.

Birçok BT organizasyonunu incelediğimizde olması gereken ile (mevcut OM’de olan) gerçekte olan çalışma şeklinin birbiriyle örtüşmediği veya BT’nin değer önerisi ve ortaya koyduğu yetkinliklerle işin ihtiyaçlarını karşılayacak esneklik ve yetkinlikler arasında bir fark olduğu görülmektedir.

Bunlara ek olarak, kişisel gözlemlerimde de gördüğüm mevcut BT modelleri, BT dışındaki grupları yani iş birimlerini çok fazla kapsamamakta bu da özellikle yeteneğin kazanılması yani insan kaynağı, karar noktaları ve finansın yönetilmesi gibi konularda sıkıntı yaratmaktadır. Mevcut rekabet koşullarında iş birimleri mümkün olduğunda yeni kabiliyetleri elde etmek hatta birçok konuda BT’den otonom şekilde hareket edebilmek arzusundalar. Bu anlaşılabilir bir refleks olsa da uzun vadede yarattığı “Shadow IT – Gölge BT” şirkete daha büyük zarar getirmektedir. Bu sebepten dolayı BT operasyon modelini tüm şirketi kapsayacak şekilde planlayıp hangi kontrollü bir otonomluk sağlanması veya hangi noktalarda nasıl davranılacağının keskin hatlarının çizilmesini de sağlamaktadır.

Birkaç örnek üzerinden devam edelim.

• Bu senaryomuzda, satış departmanlarından biri yeni satış kanalları oluşturabilmek için mobil uygulama geliştirmek istiyor ve bunu bir dijital ajansa yaptırma planları olduğunu varsayalım.
• Başka bir senaryoda; müşteri yönetim ekibi müşteri eğilimlerini daha iyi analiz yapabilmek önceden piyasayı tahmin ederek doğru aksiyonları olabilmek için ekiplerine birkaç tane veri bilimcisi (data scientist) alıyor veya mevcut kullandıkları CRM’i bulut bazlı bir CRM ile değiştirmeğe karar verdiler.

Mesela bu senaryolarda ajansın nasıl seçileceği, mimarinin nasıl olacağı, hangi teknolojilerin kullanılacağı gibi kritik kararların verilmesinde BT ne kadar etkin veya sizin önünüze proje bittikten sonra mı geliyor? Her ne kadar veri bilimcileri iş birimleri içerisinde olsa da BT kaynaklarına (web servisleri, API, veri tabanları gibi) erişecekler ve geliştirdikleri uygulamaların bir yaşam döngüsü olacaktır. BT’nin dışında olsalar bile BT ile bu kadar içli dışlıyken sizin bu kişilerin seçimi, uygulama geliştirme standartlarının belirlenmesi veya kaynakların nasıl kullanılacağı konusunda sınırlamalar belirlemeniz gerekmiyor mu?

Artık bu sebeplerden dolayı operasyon modeli, sadece BT içerisinde sınırlı kalamaz ve bu nedenle de tüm şirketi kapsayacak şekilde genişletilmelidir. Tüm organizasyonda hedeflenen inovasyon, esneklik ve rekabet gücünü sağlayacak şekilde tekrardan konumlanmalıdır.

BT Operasyon Modelinin yapısı nasıl olmalıdır?

Operasyon modelinin oluşturulması, gösterilmesi ve ölçümüyle ilgili endüstride kabul edilmiş birçok farklı yöntem bulunmaktadır. Hangi modelle çalışırsanız çalışın temelde aynı bileşenlere sahiptirler. Ben bu yazı dizisinde kendimin de en çok hâkim olduğu ve daha önce çalıştığım Gartner’ın yapısını baz alarak bazı noktaları anlatacağım. Gartner’a göre bir BT operasyon modeli aşağıdaki bileşenlere sahip olmalıdır.

• Finansallar (Financials): BT bütçesinin ne kadar ve kimin kontrolünde olması gerektiği, yatırım kararlarının nasıl verileceği, bütçenin nasıl izleneceği ve şirket hedefleriyle uyumlu finansal yatırımların nasıl yapılması gerektiğine dair kurallar bütünüdür. Bu konu aynı zamanda BT’nin sunduğu hizmeti nasıl ücretlendirmesi (Chargeback mekanizması) gerektiğini planlayabilmesi içinde önemlidir.
  Birçok BT organizasyonu aşağıdan yukarı doğru toplama yöntemiyle yıl başında bir bütçe belirliyor ve bu bütçe içerisinde kalmaya çalışarak hem iş birimlerine destek olmak hem de sürekli değişen bir ortamda gemilerini yürütmeye çalışıyorlar. Buradaki temel sorun iş biriminin bütçeye katkısı veya stratejik önemiyle aynı oranda bir efor harcıyor muyum veya iş birimi BT’ye harcattığı efor karşılığında ne kadarlık bir değer yaratabiliyor sorularının net bir şekilde cevaplanamamasıdır. Düzgün bir Chargeback mekanizmasının kurulmasıyla beraber BT’ler doğrudan iş birimleri hatta proje ve operasyonel işleri için bile ne kadarlık bir maliyet yaratmışlar gösterebilme yeteneğini kazanırlar.
  Bu sayede aşağıdaki kazanımlar ortaya çıkmaktadır;
  • BT’nin harcadığı efora karşılık iş biriminin ne kadarlık bir değer yarattığının ölçümü
  • Kaynakların doğru inisiyatiflere, teknolojilere ve birimlere aktarılması
  • BT’nin bir masraf merkezi olduğu algısının kırılması ve değer odaklı bir merkeze doğru evirilmesi.
  • İş birimlerinin yeni proje veya taleplerde bulunurken doğru bir maliyet/fayda analizi yapabilmesinin sağlanması.

• Karar hakkı (Decision Rights): Organizasyon içerisinde kim, neye ve nasıl karar vereceğinin belirlenmesidir. Mesela BT mimarisiyle ilgili bir karar alınması gerektiğinde bunu uygulama ekipleri kendileri alabilir mi yoksa merkezi mimari ekibe mi danışılmalı, iş birimleri kendi ihtiyaçlarına uygun “3rd party” bir uygulama satın alabilir mi? Dağıtık bir şirket yapısındaysanız bir hizmete ihtiyacınız olduğunda bunu merkezden mi sağlamalısınız yoksa kendiniz yaratabilir misiniz? Bu tür soruların cevaplarını verebilmek ve bu kritik kararlarda kimin yetkili olduğunun belirlenmesini sağlar. Bu kural setinin belirlenmesi hem işlerin daha hızlı akmasını sağlar hem de ileride oluşabilecek çeşitli yanlış anlaşılmalarla sürtüşmelerinde önüne geçebilmektedir.
  Mesela şirketinizin çevik (agile) dönüşüm geçirdiğini ve ürünler bazında chapter’lara böldüğünü varsayalım; her chapter’ın kendi teknik lideri nelere karar verebilmeli, mesela kendisi uygulamada bir fırsat gördü ve daha önce şirket içinde kullanılmamış bir teknolojiyi kullanmak istiyor buna izni var mı? API’ların döndüğü cevapları standarttın dışında bir çıktı kullanabilir mi? Product owner’lar istedikleri tedarikçi çalışmayı tercih edebilir mi veya ürünün özellikleriyle ilgili gerçekte ne kadar karar sahibi olmalılar.
  Eğer büyük bir kurumsal yapı içerisinde, otonom çevik ekipler kullanmak istiyor bir yandan da hedefe doğru mimari ve ürünlerle gidebilmek istiyorsak bu kural setlerinin belirlenmesi hayati önem taşımaktadır.
  
• Performans (Performance): Adından da anlaşıldığı üzere BT organizasyonunun performansının nasıl ölçüleceğinin belirlenmesidir. Burada en önemli nokta şirket stratejisine uygun KPI’ların belirlenmesidir mesela iş birimlerinin dijitalleşmesine destek verilmesi beklenirken bütçe/süreç optimizasyonuyla ilgili KPI’ların ağırlıkta olması çok anlamlı olmayacaktır. Aynı zamanda BT’nin siloları için ayrı ayrı KPI’lar belirlemenin yanında bir bütün olarak yarattığı değeri ölçebileceğiniz KPI’ların olması önerilir.
  Örneğin;
  • Yeni Ürün/sürüm çıkartma sıklığı
  • Dijital kanalların rakiplere göre olan performansı ve teknik üstünlüğü
  • Kullanıcı deneyiminin iş performansına etkisi ve son kullanıcı mutluluğu
  • İş birimlerinin yeni kanal ve iş modelleri yaratabilmeleri için sunulan yeni teknolojiler ve süreçlerin dijitalleşmesi (Self-service portal, RPA, Chatbot, VR/AR araçları gibi). Bunların doğrudan ciroya olan etkisi.

• Organizasyon yapısı (Organizational structure): BT organizasyon yapısı nasıl olmalı, iş birliği nasıl sağlanmalı ve kritik kaynaklar arasındaki ilişki nasıl kurulmasıyla ilgili tüm bileşenler bu başlık altında toparlanır. Yukarıda değindiğim çevik organizasyon ile ilgili örneğinden devam edersem; şirketi ürünler bazında böldüğümüz durumda BT’de kendini ürünler bazında çalışma gruplarına bölmesi beklenmektedir. Peki her grup içerisinde kimler bulunmalı, bunlar normal şartlarda hiyerarşik olarak kime bağlı olmalı, gruplar içerisinde dağıtılamayan alt yapı, güvenlik ve yönetişim ekipleriyle bu yapıların ilişkisi nasıl olmalıdır gibi soruların cevabını verdiğimiz kısımdır.
  
• Çalışma yöntemleri (Ways of working): Aslında BT’nin ve doğal olarak onunla çalışan partner ve iş birimlerinin nasıl çalışacağının belirlendiği katman. Burada şirketinizin kendi metotları/süreçleri olabileceği gibi endüstri tarafından kabul edilmiş standartlarda kullanılıyor olabilir. Mesela fikirlerin kabul edilip projeye dönüştürülmesi için gerekli kabul ve geçiş süreçlerini içeride geliştirirken, BT’nin performansını Cobit’e göre ölçüyor olabilirsiniz. Projenizi sprintler halinde yönetip, CI/CD sayesinde hızla yeni sürümlere geçiyor olabilirsiniz. Burada önemli olan işin ihtiyaçlarına göre doğru yöntemi belirleyebilmenizdir. Her ihtiyaç düşünülenin aksine çok sık yeni uygulama özelliklerine ihtiyaç duymazken, fikirden proje aşamasına geçişte her şirketin kendi kabul koşulları birbirinden farklılık gösterecektir. İşin ihtiyacını net olarak anlayarak ona göre bir yöntemler belirlenmeli, paydaşlarla el sıkışılmalıdır.
  
• Konum (Places): BT, iş birimleri ve partnerler fiziksel olarak nerede konumlanacak. BT ve iş birimi ayrı ofislerde/binalarda çalışıp birbirlerinden izole mi çalışacak yoksa iş birimi ve ona hizmet eden BT fonksiyonları aynı ofiste mi bulunmalı? Outsource ettiğiniz hizmetlerin veya dışarıdan aldığını danışmanlık hizmeti nasıl ve nerede bulunmalı gibi konuların netleştiği yerdir. Artık iş birimleriyle onlara doğrudan hizmet veren ürün grubunun yazılım geliştiricileri, proje yöneticileri gibi BT fonksiyonlarını bir arada tutma eğitimi bulunmakta ama genelde alt yapı, UI/UX tasarımcıları, güvenlik veya test ekipleri gibi paylaşımlı kaynakların nasıl konumlanacağı gibi sorular yeni modellerde sıklıkla atlanmaktadır.
  
• Yetenek (Talent): İnsan kaynağı, ihtiyaç duyulan insan kaynağını organizasyonun nasıl ve ne şekilde bulabileceği, çekeceği ve bünyesine alabileceği gibi konulara eğilir. Bu insanların ne tür bilgi ve birikime sahip olması beklenmektedir, şirket içerisinde nasıl konumlandırılmalıdır gibi sorulara da cevap verebilmelidir
  .
• Partnerlik ve dış kaynak kullanımı (Sourcing and alliances): BT organizasyonlarının ihtiyaç duyduğu hem teknoloji hem de dış insan kaynağını nasıl tedarik ettiği, neleri dışarıdan alıp ne tür kaynakları içeride bulunduracağı/geliştireceği konularının değerlendirilmesidir. Tedarikçi yönetimi, yeni partner ve tedarikçilerin seçim yöntemine dair prensipler ve yönlendirmeler bütünüdür. Benim özellikle çok önem verdiğim bir konu olduğunu söylemek isterim. BT’ler her fonksiyonu kendi içinde bulundurup tek bir insan veya yetersiz kaynaklarla departmanları döndürmek yerine asıl fark yaratacakları konulara yönelip, temel yeteneklerine odaklanmalı; gerekli dönüşüm ve teknoloji desteği için doğru partnerleri kullanmayı öğrenmelidir.
  
• Araçlar (Tools): BT’nin hedeflediği değer önerisini sağlayabilmesi ne gibi araçlara ihtiyacı bulunuyor sorusunun irdelenmesidir. Bunu şu anda kullandığımız servis masası uygulamasından tutunda, CMDB ve proje yönetim araçlarına kadar genişletebilirsiniz. Bazı firmaların ihtiyaçlarına göre bu uygulamalar RPA’ler, test uygulamaları veya container teknolojisi de olabilmektedir. Buradaki liste tamamen sizin hedeflerinize göre değişmektedir.

Gartner’ın modeli haricinde başka modellerde bulunmakla beraber içerik olarak birçoğu hemen hemen aynıdır.

Bir Operasyon Modelinin nasıl tasarlanması gerektiği ve kurumsal mimariyle olan ilişkisine bir sonraki yazımda değineceğim.

Okuduğunuz için teşekkür ederim.