Bir önceki yazımda operasyon modelinin BT’ler için ne anlama geldiği ve hangi bileşenlerden oluştuğundan bahsetmiştim, bu yazıdaysa bir operasyon modeli nasıl tasarlanır, başlıca adımları nasıldır ve kurumsal mimarinin bu süreç içerisindeki rolü nedir konularından bahsedeceğim. Daha önceki yazıda operasyon modeli bileşenlerini anlatırken Gartner’ın tanımını kullanmıştık, bu yazıda da aynı bileşenler üzerinden devam edeceğim ama süreç olarak kendi yöntemimden bahsediyor olacağım. Sizde kendi organizasyonunuz ve içinde bulunduğunuz ortama göre bu yöntemin bir kısmını kullanabilir veya tamamen kendinize uygun bir şekilde devam edebilirsiniz. Operasyon modelini bileşenlere ayırıp bu bileşenler üzerinden tasarımı yapmak bize hem esneklik sağlamaktadır hem de her seferinde tüm yapıyı düzenlemek yerine değişime uygun parçalara dokunarak değişimle beraber tüm modeli parça parça değiştirmek daha gerçekçi bir yaklaşım olacaktır.

Operasyon Model tasarımı:

Yeni bir şirkete BT departmanının yöneticisi olarak katıldınız ve üst yönetimle yaptığınız ilk toplantıda sizden ve BT’den önümüzdeki yıl için beklentilerini aşağıdaki gibi sıraladılar.

• Şirket ciddi bir dönüşüm geçirmektedir; müşteri ihtiyaçlarına ve piyasaya daha hızlı cevap verebilmek için portföyündeki ana ürün ailelerine göre iş birimlerini tekrardan organize etmiş ve BT’den de bunu destekleyecek bir organizasyon beklenmektedir.
• İş modelinde köklü değişime gitme hedefleri bulunmakta ve bunun sonucu olarak IoT, Mobil ve VR/AR teknolojilerini kullanarak yeni ürünler/servisler çıkartmak istiyorlar. BT’nin onları bu konuda nasıl ve ne kadar destekleyebileceğini bilmek istiyorlar.
• Öteki yandan şirketin CFO’su bir anda artan BT bütçesine anlam verememekte ve harcanan paraya karşılık şirketin gerçekten ne kadarlık bir kazancı olduğunu ölçememekten şikayetçi. Bu sebepten dolayı ürün bazında BT’nin katkısını ve maliyetlerini görebilmeyi mümkünse bunu ürünün ciroya olan katkısına göre yorumlamak istediğinden bahsediyor.
• COO ise BT’nin bir anda fazla büyüdüğünden şikayetçi ve mümkün olduğunca çalışan sayısını limitlemek istiyor; siz bunun operasyonel olarak sorunları olacağını söylesenize rağmen bu konuda çok ısrarcı olduğundan geri adım atıyorsunuz.

Operasyon model tasarımına nasıl başlanacağına dair net bir yönlendirme olmamakla beraber ben genelde organizasyon, çalışma yöntemleri ve karar hakkı bileşenleriyle başlayıp daha sonra diğer bileşenlerle devam etmeyi tercih ediyorum. Bunun en büyük sebebi en başta ideal organizasyonu ve nasıl çalışması gerektiğini gördükten sonra aşağıya doğru diğer bileşenleri bunlara bağla noktasının daha kolay olduğunu düşünmem. Yukarıdaki maddeleri birbirleriyle çelişen noktaları olsa da aslında dünya genelinde bir gerçeği yansıtmakta.

İlk önce yeni organizasyon şemasına bakarak kaç adet ürün grubu olduğunu, her grup için hangi BT yetkinliklerine ihtiyacımız olduğunu tespit etmeliyiz. Misal bir ürün grubu e-ticarete yoğunlaşacaksa bu grubu desteklemesi beklenen BT ekibinin bu tür bir dijital kanal geliştirme ve destekleme konusunda yetkinlikleri ne durumda ve ne tür bir yetkinlik ağacına ihtiyaçları bulunmaktadır. Bu analizin sonucunda şu çıktıları elde edeceğiz;

• Mevcut insan kapasitem bu şekilde bir organizasyonu desteklemeye uygun mu?
• Ne tip yeni yetenekler ve teknolojilere ihtiyaç duyacağım.
• BT kabiliyetlerini (Mobil geliştirme, Alt yapı, yönetişim gibi) bu yeni organizasyonda nasıl dağıtmam gerekli. Hangi servisleri uzmanlık merkezi (CoE) olarak tutarken hangilerini ürün grupları içerisinde eritmem lazım.

Organizasyon yapısını çıkardıktan sonra yetenek, konum ile partnerlik ve dış kaynak kullanımı bileşenlerinde karar verebilecek duruma gelebilirsiniz.

Örnek; bir tekstil fabrikası giyilebilir elektronik konusunda ürünler çıkartmak istiyor ve bu tür ürünleri geliştirmesi için bir ürün grubu oluşturuyor ve BT olarak sizin de bu ürün grubu içerisine gerekli yetkinleri koyabilmenizi bekliyorlar. Analizi yaptığınızda proje yöneticisi, yazılım geliştiricileri ve analitik uzmanlarını ürün grubuna yerleştirebilirken, kritik olan IoT konusunda bir yetkinliğinizin olmadığınızı görebilirsiniz. IoT ile ilgili birçok konu için (sensör tasarımı, devre tasarımı gibi) içerde bir yetkinlik oluşturmak yerine partner arayarak organizasyonu bu şekilde tanımlayabilirsiniz veya finans sektöründesiniz ve tüm ürünlerinizi mobil/web üzerinden sunmaya karar verdiniz ve sizin için en önemli konu değişen son kullanıcı deneyimine hızla uyum sağlayabilmek. Bu durumda analizi yaptığınızda organizasyonda UI/UX yeteneğini katmanız hatta stratejik önemi olacağından da dolayı iç kaynak olarak alınması gerekeceğini daha net görebileceksiniz.

Artık BT organizasyonunun neye benzemesi gerektiğini ve mevcut durumda hangi yetkinliklerin/yeteneklerin eksik olduğunu görebilmekteyiz. Bir sonraki adımdaysa eksik yetkinlik ve yetenekleri nasıl temin edeceğinize karar vermemiz gerekmektedir. Burada sorulması gereken kritik sorular, hangi yetkinlikleri içeride tutmalıyım(insource) ve hangi yetkinlikleri dışardan temin etmeliyim. Burada unutulmaması gereken önemli bir noktaysa yetkinliğe sadece insan kaynağı olarak bakmamak aynı zamanda teknoloji partneri olarak da bakmamız gerektiğidir. Mesela veri merkezi hizmetini Azure/Aws gibi bir bulut servis sağlayıcısı üzerinden almak onları teknoloji konusunda stratejik partneriniz halini getirirken fabrikanızın enerji kullanımını optimize etmek için geliştirmek istediğimiz ML algoritmasını, kendi ekipleriniz yerine dışarıda bu konuda uzman bir ekibe geliştirme gibi çeşitli perspektiflerden de bakabilmeliyiz.

İnsan kaynağı üzerine söyleyebileceğim en önemli noktalardan biriyse mümkün olduğu kadar yeteneği tek bir insan olarak kurumunuza katmamanız yönünde olacaktır. Bu durum sürdürülebilir olmaktan uzak ve sorunlara açıktır; kişinin organizasyondan ayrılması durumunda birçok proje ve süreç ciddi olarak sekteye uğrayacaktır. Benim önerim eğer kadro veya bütçe sıkıntısı sebebiyle tek kişiyle devam etmeniz gerekliyse bu kişiyi destekleyecek bir partner bulmanız veya mutlaka kişinin yetkinliğinin içeride başka kişilere de dağılabilmesi için eğitim programlarınızı da operasyon modelinize eklemenizin gerekliliğidir.

Hatırlarsanız örneğimizde COO sizden kişi sayısını mümkün olduğunca sınırlamanızı istemişti; bu tür bir yetkinlik, yetenek ve partner haritası çıkarttıktan sonra kritik yeteneklere göre insan gücü anlamında yalın bir organizasyon kurabilir. Sizin için en kritik yetenek ve bilgileri içeride tutarken partnerlerinize diğer operasyonlarınızı yaptırabilirsiniz.

Artık yapımızın neye benzeyeceğini, kimlerle çalışacağımızı ve hangi BT kabiliyetlerine sahip olacağımızdan eminiz. Bir sonra ki adımda nasıl çalışmamız gerektiğine ve karar mekanizmalarının kurulmasına sıra geldi. Zaten organizasyon haritasına(iş ve BT) ve şirketin stratejik hedeflerine baktığımız zaman iş birimleriyle nasıl çalışmamız gerektiğine göre bir temeli rahatlıkla görebilirsiniz.
Şirketin ürün bazlı bir yapılanmaya gittiğinden bahsetmiştik; bunun BT üzerinde ki en büyük etkisi bir birinden bağımsız hala gelen grupların ürünleriyle ilgili daha sık güncelleme/yenilik talebi olacak ve daha agresif şekilde ürünlerini büyütmeye yönelebileceklerdir. Bu duruma ayak uydurabilmek için öncelikle proje/talep kabul ve backlog’unuza alma süreçlerinizle başlayıp iş birimleriyle projeleri nasıl yöneteceğiniz(Scrum, XP, gibi) temellerde anlaştığınız noktada çalışma şeklinin yarısını tamamlamış olacaksınız. Öteki yarısıysa fikirden proje/talep haline gelmiş uygulamaların nasıl geliştirileceği, daha alt yapısal ve güvenlik gibi görece statik sistemlerin nasıl yönetileceği gibi konulara karar verilmesidir.

Örneğimizden devam edersek; iş birimlerinin yeni yapısına en iyi şekilde Çevik (Agile) çalışma yöntemleriyle cevap verebileceğinizi düşünüp iç tarafta uygulama geliştirme döngünüzü sprintler halinde yönetmek mantıklı gözükmekte, ama bildiğiniz gibi BT bir birine bağlı bir sürü küçük hücreden oluşmaktadır, geliştirme döngünüz otomatik olarak daha esnek ve hızlı bir canlıya alma süreci ihtiyacı doğuracaktır. Bunu destekleyebilmesi için değişiklik süreçlerimizin yeniden yazılması ve hızlı sürüm çıkartmayı destekleyecek CI/CD yapılarının alt yapıda da kurulması gerekecektir. Tüm bunların üzerinde de bilgi güvenliğinin engelleyen, durduran ve yasaklayan metotlardan çıkıp; yol gösteren, kural koyan ve denetleyen bir yapıya dönüşmesi gerekecektir. Çalışma metotlarımızı planlarken yapılan en büyük hatalardan biride aslında budur, genelde sadece iş birimiyle veya projeler üzerine çalışan ekiplerin çalışma yöntemlerini değiştirirken onun destek aldığı alt katmanlara çok dokunulmamasıdır. Unutulmamalı ki en yavaş, katı ve kapalı ekibimiz kadar hızlanabiliriz.

Şu ana kadar yaptığımız planlama sonucunda çalışan bir organizasyon oluşturmayı başardık, talepler gelmeye başladı ve ekipler bunları hedeflenen zaman aralıklarında geliştirip hızlı bir şekilde sürümler çıkmaya başladılar. Peki, BT’yi de etkileyen birçok kararı kimler nasıl almalı, bunu konuyu hala tam olarak netleştirmedik.

Mesela ürünle ilgili bir geliştirme talebi geldi ama bunun için BT mimarisinde ciddi bir değişiklik gerekiyor, bunun onayını kim vermelidir? Ürünlerin ne zaman yeni sürümünün çıkacağına veya hangi taleplerin ne koşullarda kabul edilmesi gerektiğine karar verilebilmesi gerekiyor. Kararlar hakkında örnekler çoğaltılabilir, burada sınırları net olarak çizmek çok zor ve gri bölgeler çok fazla. Tepeden inme birçok sert kuralın uzun vadede işe yaramadığı sonuç itibariyle insanlar bir şekilde bu kuralların çevresinden dolanarak iş yapmaya başlıyorlar. Aksi durumda çok genel geçer bir yönerge çizilirse de bu sefer BT mimarisini, projeleri ve maliyetleri yönetmek imkânsız duruma gelebiliyor.  

Eğer en başında doğru bir BT kabiliyet (capability) haritası çıkartabilirsek mevcut durumda ve ileride ihtiyaç duyabileceğiniz birçok yetkinlik konusunda bir fikriniz oluşmuş olmalı, aynı zamanda insan kaynağı olarak ya bünyenizde ya da partnerleriniz üzerinden yetkinliğinizi doğru şekilde konumlandırdıysanız önceden iş birimlerinden gelecek her türlü teknik ihtiyaca cevap verebilir durumda olacağınız için her türlü mimari karar, teknoloji partnerinin seçimi ve teknik ürün seçimi konusunda önceden kural setlerini belirleyebilir veya onları doğru kanallara yönlendirebilirsiniz. Bunu anlatmamın sebebi eğer önceden bunları belirlemezseniz iş birimi bu konuda ki boşluğu kendisi doldurarak bir karar verecektir, benim önerdiğim yöntemle çalışmanızın avantajı önceden belli temellerde onlarla anlaşabilir ve onlara da vakit kaybettirmeden tüm teknik tarafta kararların sahibi olabilirsiniz.

Ürünle ilgili her türlü UI/UX, yeni sürüm sıklığı ve neleri geliştirmeye dâhil edilmesi gerektiği gibi konularda yol gösterici olabilir ama asla karar merkezi olamaya çalışmanızı önermem. İş birimine hayır demek yerine onlara seçenek sunan ama onlarında bizim teknik kararlarımıza aykırı ilerlememeleri için karar mekanizmasını bu şekilde kurmanızı öneririm.

Son olarak Finansalların ve performansın nasıl yönetilmesi konusuna değineceğim. Hatırlarsanız CFO BT’nin artan maliyetlerine bir türlü anlam veremediğini söylemişti. Gerçekte BT’nin bir maliyeti bulunmamaktadır, her iş birimi talebinin, projenin veya iş için eklenen sistemin bir maliyeti vardır. Doğal olarak finansal bir model oluştururken kataloğumuzda olan tüm servislerin bir parasal değeri olmalı ve bu değer karşılığında iş birimlerinin nasıl bir parasal değer yarattığının karşılaştırılabiliyor olması önemlidir. Mesela sizden bir BI raporu oluşturmanız istendi bu rapor için gereken iş gücü ve lisans maliyetinin 300$ olduğunu varsayalım ama raporu isteyen arkadaş bunu 1 gün ekstradan oluşturup kendisi oluştursa şirkete maliyeti 100$; sırf talebi yapan kişi daha az çalışacak diye bu raporu oluşturmalı mısınız? Bunu gösterebilmeniz ve anlatabilmeniz önemli. Başka bir örnekse mevcut e-ticaret sitenize gerçek zamanlı satış modülü eklenmesi istendi ve siz bunun için ciddi bir yatırımla beraber geliştirme süresi harcandınız. Yılsonu bilançosunda e-ticaret sitesinin ciroya oranla karlılık oranının düştüğü ve buna en büyük sebebin BT maliyeti olduğu düşünüldüğünden dolayı sizin üzerinizde maliyetleri azaltmanıza yönelik baskı hissediyorsunuz. Raporlara baktığınızdaysa talep edilen yeni özellik için harcanan maliyete karşılık iş birimi hedeflenen başarıyı elde edememiş olduğunu görüyorsunuz, bu sayede hem sonucun bu şekilde olmasının sebebinin BT olmadığını kanıtlıyor hem de üzerinizde ki maliyet baskısını bir nebze azaltabilme imkânınız oluşabilir.

Finansal model aslında BT’nin bir savunma mekanizması değildir, iş birimlerinin BT harcamalarını en yüksek fayda sağlayacak noktaya kaydırabilecekleri bir araçtır. Bu sebepten dolayı basit gözüken ama etkisinin gayet yüksek olduğu, her servis için charge-back mekanizmasının oluşturulması ve talep bazında finansal bir değere bağlayabilmek BT olgunluğunuzu çok ilerletmektedir.

Son bileşenimizse BT’nin performansını nasıl ölçmemiz gerektiği üzerinedir; şu ana kadar yaptığınız her şey aslında performans ölçümünü destekleyen aksiyonlardı. Her çalışma yönteminin kendine has bir performans ölçüm yöntemini kullanabilir, finansal gözlükle bakıp aslında t kaynak ile ne kadarlık fayda yarattığınızı ölçebilir veya iş birimlerinin taleplerine verdiğiniz tepki süresi arasında ki süreye göre(sürüm sıklığı olabilir) birçok işe dokunan KPI seçebilirsiniz. Ben genelde mimari olgunluk yani standartlara ne kadar uyuluyor, sürdürülebilir ve genişleyebilir sistemlerin sağlığı için bir KPI grubu, süreçler(Cobit olabilir) bir KPI grubu ve en önemli yaratılan değer için bir KPI grubu öneriyorum.

İlk ikisi bizim kendimizi iyileştirmemiz için önemliyken son grup iş birimlerinin bizi ölçebilmesi içindir bu KPI’ların finansal ve değer(geliştirilen yazılım sayısı olabilir) cinsinden olması gereklidir.

Araçlar ve Yer konusundaysa benim tercih ettiğim bir yaklaşım bulunmamakta, genelde yukarıda ki bileşenlere karar verdikten sonra bir şekilde doğal süreci içerisinde çözülmektedirler. Yine de operasyonunuzu yönetirken hangi araçları kullanacağınızın net bir şekilde belirlenmesi ve yaygınlaştırılması gereklidir.

Kurumsal Mimari ile Operasyon Modeli arasında ki ilişki:

Bu yazı serisinin asıl yazılma ve en kısa kısmına geldik 🙂 Kurumsal Mimari yeni operasyon modelini (Target operating model) oluşturmada hem destekleyici bir öğe hem de girdi olarak kullanılabilir.

Kurumsal mimari, operasyon modeli özelinde size iki önemli bilgi sağlar öncelikle kurumunuzun şu andaki iş kabiliyetlerinden (Business capability),süreçler, veri ve teknoloji alt yapısına kuş bakışı tek ve yalın bir görünüm sunar. Bu görünüm mevcut durumu anlamanız, hangi iş kabiliyetlerine ne seviyede destek verebildiğinizi ve sistemleriniz arasında ki ilişkiyi görmenizi sağlar. Bu sayede mevcut operasyon modelimizde neleri geliştirmemiz gerektiğini görebilirsiniz. Gelecek mimarisi ile de aslında BT’nin değişen iş stratejisi ve ona bağlı işin operasyon modeliyle beraber ne tür kabiliyet, yetkinlik ve yeteneklere ihtiyaç duyacağını ön görüp. Mimari ve teknoloji standartlarını belirleyerek; bunun BT’nin mevcut yapısına nasıl bir etkisi olacağının analizini yapabiliriz. Bu çalışma özellikle Partner, Karar mekanizması, Araç, Yetenek ve Performans konusundaki modelin oluşmasında size ciddi bir girdi sağlar.

Yukarda anlattığım yaklaşım kurumsal mimarinin klasik yaklaşımıdır. Daha modern yaklaşımsa BT operasyon modelinin işin operasyon modeli tarafından tetiklenerek değişmesi yerine kurumsal mimarların bir iç danışman gibi iş birimlerine teknolojiyle nasıl fark yaratabileceklerini göstererek, stratejilerini oluşturmada onlara destek olarak, önceden doğru öngörülerle BT’ye yeni servisler katarak BT’nin sunduğu değerin işin operasyon modelini değiştirmesini sağlamaktır. Peki kurumsal mimarlar bunu nasıl yapabilir.

Operasyon modelinin hem BT hem de iş için ana girdisinin strateji olduğundan bahsetmiştik, genelde üst seviye strateji planlaması belli çerçeveler tarafından yapılır ve genelde BT stratejinin oluşturulurken her zaman bir parçası olmamaktadır. Şirket stratejisinin oluşturulması veya sadece uygulaması tarafında olsanız da proaktif davranarak tüm şirketin operasyon modelini etkilemeniz mümkündür.

Genelde şirketin stratejileri sayfalarca süren dokümanlar yerine birkaç ana maddeden oluşan hatta tek sayfaya sığdırılabilen sadece yönümüzü belirlemeye yardımcı olan hedeflerden oluşur. Mesela bir şirketin 2020 stratejisi sadece aşağıdaki maddelerden oluşabilir.

• Bu yıl maliyetleri %10 azaltacağız
• Mevcut müşterilerde derinleşmek ve yeni satış kanalları yaratmak
• Her zaman her yerden müşteriler tarafından erişilebilir servisler sunmak

Şimdi iki farklı senaryo inceleyelim. Birinci senaryoda kurumsal mimari daha geleneksel bir pozisyon almakta sadece BT içerisiyle sınırlı kalmış ve iş birimlerinin bu stratejiyi nasıl uygulayacağına dair bir oyun planı hazırlamamış/desteklememiş olsun.

Bu durumda iş birimleri yeni operasyon planlarını yaparken masraf merkezi olarak görülen BT üzerinde maliyet baskısında bulunacaklardır, bunun etkisi BT için daha az insan ve kaynakla aynı işleri düşen bir kalite ile yapmaya zorlanması demektir. BT, iş birimlerine yeteri kadar destek verememeye başlayacak ve gittikçe değerini kaybedeceği için bütçesi kısılmaya başlayacak ve sonsuz bir döngüye girecek.

Öbür taraftan iş birimlerinin yeni kanalları yaratırken dış tedarikçilere mobil/web/e-ticaret veya yeni nesil Iot, AR/VR gibi çözümleri geliştirip entegrasyon noktasında hatta bazen onda bile BT’ye gelinmeden devreye alınabilir. Özetle ne mimari ne de tedarikçi seçiminde asla BT’ye danışılmaması durumu oluşabilir. Bunun sürdürülebilirlik, güvenlik ve ileri yönelik büyümede nasıl problemler yarattığını anlatmaya başlasam sanırım ayrı birkaç yazı dizisi çıkabilir.

Müşterilerin veya çalışanların her zaman her yerden şirket kaynaklarına erişebilmesi bence harika bir yaklaşım ama genelde pratikte bu iki türlü çalışmakta. Ya işin baskısı sebebiyle birçok kritik servis dış dünyaya yeteri kadar kontrolü bir şekilde açılmaz ve ciddi bir bilgi güvenliği riski yaratır veya BT bu taleplere “hayır” demek zorunda kalırsa da, BT şirketin sevilmeyen iş yapılmasını engelleyen birimi pozisyonuna düşmüş olur. Başka bir problemse birçok servis aslında arka tarafta bulunan “system of record” katmanına bağımlı olarak çalışmaktadır ve genelde “system of record” katmanı en yeni teknolojilerden oluşmaz hatta mümkünse pek dokunmakta istemeyiz. Bu katmanlar her zaman modern entegrasyonları desteklemeyebileceğinden dolayı ya veriyi bir şekilde mobil/web servislerinin kullanabilmesi kopyalıyor veya teknik borcumuzu(technical debt) artıracak çözümlere gidiyoruz. Her iki yaklaşımının da kendine göre sorunları bulunmakta ve mümkün olduğunca kaçınılması gereken yaklaşımlardır.

Peki, bizim rolümüz burada ne olmalıdır? Hayır demek veya bu talepleri engellemek hem iş açısından hem de BT’nin varlık amacı açısından doğru bir yaklaşım değildir. BT mimarisinin, yapısının ve hedeflerininse dış etmenler tarafından bir tarafa doğru savrulması da aslında kendi içinde kısır bir döngüde olan, sınırlı değer yaratabilen, sürekli yangın söndürmeye odaklı organizasyona dönmemize sebep olmaktadır.

Kurumsal mimari tam bu noktada bizim reaktif bir yaklaşımdan çıkıp proaktif bir yaklaşıma geçmemizi sağlayarak doğru bir BT konumlandırması yapmamıza hatta iş birimlerinin çalışma şeklini etkilememizi sağlar.

Bir kurumsal mimarın oyun planı BT’nin şirket içindeki algısı ve pozisyonlamasına göre değişmekle beraber temel yaklaşımları aynıdır. Kurumsal mimarinin BT fonksiyonları haricinde ekosistemi tarayarak şirkete değer yaratacak teknoloji ve partnerlik fırsatlarını bulma, iyi uygulamaları şirket içine tanıtma, mevcut teknolojilerin/yöntemlerin iş birimlerine nasıl değer katabileceğine dair şirket içi danışmanlık faaliyetlerini yürütme gibi aksiyonlardan oluşabilir.

Mesela yukarıdaki strateji örneğine bu gözle bakıp bunu operasyon modelimize bağlayalım. İlk hedefimiz kurumsal mimari olarak şirketin maliyetlerini azaltmaksa klasik portföy rasyonelleşmesinin ve tedarikçi optimizasyonun haricinde iş birimlerinin kendi dijitalleşmesini sağlayacak servisler sunmakla başlayabiliriz, örnek vermek gerekirse son zamanlarda sıkça konuştuğumuz RPA’lerin devreye alınarak iş gücünden kazanç veya BPM servislerinin daha iyi kullanılarak şirkete kazandırabileceğimiz hızın genel giderlere etkisi olacaktır. Başka bir yaklaşımsa iş birimlerinin en çok sıkıntı yaşadığı noktalara odaklanmaktır(Pain points); mesela üretim yapan bir şirketteyseniz depo alanının optimize edilmesi, forkliftlerin minimum mesafede maksimum iş yapabilmesi veya enerji kaybının azaltılması için gerekli çözümleri bulunması, iyi uygulamaların şirketi getirilmesi önem kazanacaktır. Bu problemlerin çoğu artık bilişim teknolojileri sayesinde dijital platformlarda çözülebilir ve iş birimlerinin kendi çözümünü bulmasından önce proaktif olarak onlara alternatifleri gösterip beraber bir çözümün oluşturulmasına liderlik edilebilir.

Benzer yaklaşım diğer maddeler içinde geçerlidir, strateji maddelerine bakıldığında 3 noktayı çok iyi görebilmeniz gereklidir.

• Şirket stratejisinin doğal bir sonucu olarak birçok yeni uygulama ve dış bağlantıya ihtiyaç duyacağımızı çok rahat ön görebiliriz. Bu durumu yönetmek ve esnekliği sağlamak için bir API katmanı oluşturulması, içerde geliştirilen uygulamaların ve tedarikçilerin geliştirecekleri uygulamaları bu katman üzerinden diğer katmanlarla iletişim kurmasını sağlayabiliriz.
  API katmanı sayesinde hem sürekli değişen uygulama ihtiyaçlarına hızla cevap verebilir, dış firmalarla entegrasyonunuz kolaylaşırken bir yandan da en değerli sistemlerimiz olan “system of record” katmanına olan etkiyi ciddi anlamda azaltabiliyoruz.

• Stratejiye göre BT’nin yeni satış kanallarını destekleyecek kabiliyetlere sahip olması gerekmektedir, öncelikle genel bir kapsamda ekosistem ve endüstride ki örneklere bakıp ne tür kabiliyetlere ihtiyaç olunması gerektiğinin tespiti. Bu kabiliyetlerde ne durumda olduğumuzun analizini ve nasıl bir şekilde bu kabiliyetleri iş birimlerine sunacağınızın planlamasının daha iş birimleri tarafından projeler gelmeden önce başlanması gerekmektedir. Özellikle bu kabiliyetlerin belirlenmesi iş birimlerini doğru yönlendirmemizi sağlayacak doğru partnerler ile onları aynı masaya oturtabilir ve BT alt yapımızın istenmeyen bir noktaya sürüklenmesinin önüne geçilebilir.

• Mevcut müşteriyi daha iyi anlamak için farklı iş birimleri ve partnerlerinizde bulunan verinin konsolide edilmesi, analizi ve doğru zamanda doğruluğundan emin sonuçların üretilmesi gerekecektir. Veri yapısının değişmesi hem iş birimlerinin tepki süresini değiştirecek hem de şirketin veri odaklı bir yapıya doğru evirilmesini sağlayacaktır. Maalesef bu yazıldığı kadar kolay bir senaryo değildir, etkili bir analitik katmanının oluşturulabilmesi için öncelikle veri stratejisinin olması, veri kataloğu, veri sözlüğü, metadata/refdata gibi kavramların çalışır duruma getirilmesi gereklidir. Farklı sistemler arasında ki verinin entegrasyonundan sonra ancak bu tür bir yapı geliştirilebilir. Eğer bu tür bir iş stratejisi önünüze geldiğinizde yukardaki konularda hazırlıklı değilseniz hedefinizi tutturmanızda mümkün olmayacaktır. Bu sebepten dolayı iyi bir kurumsal mimarın iş ve teknolojideki eğilimi sürekli takip edip, hem iş birimlerini bu konuda eğitilmesine destek olmalı hem de teknik alt yapıyı sunmak için gerekli yol haritalarını yaratmalıdır.

Bu noktada hala şu soruyu sorabilirsiniz; kurumsal mimari hakkında konuştuklarımızın operasyon modeliyle ilişkisi nedir diye? Operasyon modeli bir değerin nasıl oluşturulacağının ve hedefe varmak için gerekli hayatı düzenler; Kurumsal mimarların hedefleri, iş birimlerinin isteklerini ve içlerinde bulundukları politik ortamı iyi okuyarak iş birimlerinin çalışma şekillini nasıl değiştirebileceğine odaklanması, BT’nin sürekli rekabetçi kalabilmesi için değişimini planlaması gerekmektedir.

Doğal olarak bu yaklaşım hem BT’nin pozisyonlanması hem de çalışma şeklini değiştirirken, BT’den iş birimlerine doğru değişen değer önerisi ve yeni servislerde iş birimlerini değişime doğru itecektir.

Klasik BT ile sınırlı kalmış kurumsal mimari tamamen ölmüş bunun yerine değer odaklı, değişimi kontrol eden değil tam tersine aşağıdan yukarı doğru tetikleyen bir kurumsal mimari yerini almıştır.

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