Çok Şirketli Finansal Yapılarda IT Yönetimi

Merkezi Hizmet Modeli ve Sahadaki Gerçekler

Şükür Muhacir  |  IT Genel Müdür Yardımcısı, Fair Teknoloji A.Ş.

Bu yazı, “Finansal Bir Kuruluşta IT’yi Kurmak” başlıklı makalenin ikinci serisi. Birinci yazıda altyapı mimarisi, felaket kurtarma, siber güvenlik olgunluğu ve değişiklik yönetimi gibi temel başlıkları ele aldım; o yazıda da çoklu şirket yapısının karmaşıklığına değindim. Bu yazıda ise o boyutu daha derinlemesine işliyorum. Birden fazla finansal şirketi kapsayan holding veya grup yapılarında IT’yi merkezi olarak nasıl yönetirsiniz?

Bu soru, Türkiye’de henüz yeterince konuşulmuyor. Çoğu IT makalesi ya tek bir kuruluş perspektifinden yazılıyor ya da çok uluslu büyük holdinglerin kurumsal mimari modellerini anlatıyor. Ortada bir yer var. Birkaç finansal şirketin birbiriyle bağlantılı ama her birinin ayrı regülatif yükümlülükleri bulunan yapıları. İşte bu makale tam olarak o yer için.

1. Merkezi IT Hizmet Modelinin Mantığı

Birden fazla finansal şirketi kapsayan gruplarda her şirket için müstakil bir altyapı kurulması hem doğru hem de gereklidir. Regülatif açıdan ortam ayrılığı zorunludur; her şirketin kendi güvenlik duvarı, kendi yedekleme sistemi, kendi ağ segmentasyonu olmalıdır. Bu yola gitmek doğru bir tercihtir.

Asıl soru şudur; Bu müstakil altyapıları kim, nasıl yönetecek?

Her şirket için ayrı bir uzman ekip kurmak, ayrı politika seti yazmak, ayrı denetim hazırlığı yapmak hem ölçeksizdir hem de uzmanlığı parçalar. İşte merkezi IT modelinin değer yarattığı yer burasıdır. Altyapı müstakil, yönetim merkezi.

İşleyen model şudur, grup bünyesinde bir IT hizmet sağlayıcı kuruluş kurulur ve tüm grup şirketlerine merkezi olarak IT hizmeti sunar. Bu modelde uzmanlık konsolide edilir, maliyet dağıtılır.

Ama bu modelin kendi karmaşıklığı vardır. Merkezi yönetim, sorumluluğu da merkeze çeker. Ve finansal sektörde her şirketin ayrı denetçisi, ayrı mevzuat yükümlülüğü, ayrı risk iştahı vardır.

2. Regülatif Gerçeklik: Her Şirket Ayrı Bir Evren

Grubun en büyük karmaşıklığı teknik değil, regülatiftir.

Bir katılım bankası BDDK’nın Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliği’ne tabidir. Aynı gruptaki finansman şirketi, faktoring şirketi ya da finansal kiralama şirketi de BDDK denetimine girer; ancak her birinin sistem gereksinimleri, denetim frekansı ve uyum zorunlulukları farklılaşabilir.

BDDK mevzuatına göre, banka konsolidasyon kapsamındaki ortaklıklar bilgi sistemleri denetimi açısından bankayla birlikte değerlendirilir. Bu önemli bir detay, denetçi, yalnızca bankayı değil, onun konsolidasyon kapsamındaki şirketleri de inceleyebilir. Merkezi IT hizmet sağlayıcısı bu kapsamın içindedir.

Sahada bunun anlamı şudur. Grup şirketleri birbirinden tamamen bağımsız ve ayrı altyapılarla çalışır. Banka ile finansman şirketi teknik olarak kesişmez. Ancak her ikisine de hizmet veren merkezi IT sağlayıcısı, her birinin denetiminde ayrı ayrı sorgulanır.

Banka denetçisi geldiğinde merkezi IT’nin bankaya verdiği hizmetin standartlarını inceler. Finansman şirketinin denetiminde ise aynı merkezi IT’nin o şirkete verdiği hizmet masaya yatırılır. Yani merkezi IT sağlayıcısı olarak her denetimde muhatap sizsiniz; ancak her seferinde farklı bir müşteri ilişkisi üzerinden.

Bu gerçek şunu zorunlu kılar. Merkezi IT’nin süreçleri, politikaları ve kayıtları o kadar sağlam olmalıdır ki her şirket için ayrı ayrı yapılan denetimlerin tamamında tutarlı biçimde savunulabilsin. Bir değişiklik yönetimi süreci atlatıldığında, bir yedekleme rutini aksadığında ya da bir erişim yetkisi gereğinden fazla verildiğinde, bu açık yalnızca bir şirketin denetiminde değil, hizmet verdiğiniz her şirketin denetiminde karşınıza çıkabilir.

3. Hizmet Kataloğu: Olmadan Çalışmak Mümkün Değil

Merkezi IT modelinin en kritik yapı taşlarından biri hizmet kataloğudur.

Hizmet kataloğu, IT’nin hangi hizmeti hangi koşullarda, hangi SLA’larla ve hangi maliyetle sunduğunu tanımlayan belgedir. Kulağa bürokratik gelebilir. Ama olmadığında ne olduğunu sahadaki herkes biliyor. Her şirketten gelen talep farklı öncelikle değerlendiriliyor, kimse ne bekleyeceğini bilmiyor, IT ekibi kimi memnun edeceğine karar verirken zorlanıyor.

Hizmet kataloğu şu soruları cevaplar:

  • IT hangi hizmetleri sunuyor?
  • Her hizmetin yanıt süresi ve çözüm süresi nedir?
  • Hangi hizmetler standart, hangileri talep üzerine?
  • Acil destek için süreç nedir?
  • Hizmetlerin maliyeti nasıl hesaplanıyor?

Finansal gruplarda hizmet kataloğu aynı zamanda bir uyum belgesidir. Denetçi, bankaya hangi IT hizmetinin dışarıdan sağlandığını sorduğunda yanıt bu belgeden gelir.

4. Maliyet Dağılımı: Adil ve İzlenebilir Olmalı

Merkezi IT modelinin en çok anlaşmazlık yaratan konusu maliyet dağılımıdır.

Paylaşılan bir altyapı üzerinde çalışan beş şirket varsa, bu altyapının maliyetini nasıl dağıtırsınız? İki temel yöntem vardır.

Birincisi düz dağılım; Toplam maliyeti şirket sayısına bölersiniz. Uygulaması kolaydır ama adil değildir. Küçük bir şirket, büyük bir şirketle aynı tutarı ödüyor olabilir. Bu içten içe bir huzursuzluk kaynağına dönüşür.

İkincisi kullanım bazlı dağılım; Her şirketin gerçek tüketimi ölçülür ve buna göre faturalandırılır. Daha adildir ama ölçümlemek için altyapı gerektirir.

Pratik yaklaşım genellikle hibrit olur; Stratejik ve güvenlik hizmetleri (SIEM, SOC, güvenlik duvarı, yedekleme) merkezi olarak finanse edilirken, kullanıcı sayısı, ticket hacmi veya sistem kaynağı gibi ölçülebilir metrikler üzerinden kısmi dağılım yapılır.

Önemli olan şu, dağılım yöntemi ne olursa olsun, şeffaf ve izlenebilir olmalıdır. Hangi şirketin ne kadar ödediği ve bunun neye dayandığı her zaman açıklanabilir olmalıdır.

5. Konsolide İzleme: Tek Ekrandan Tüm Grup

Çok şirketli yapılarda en büyük operasyonel tehlikelerden biri görünürlük kaybıdır.

Her şirket için ayrı izleme araçları, ayrı panolar, ayrı alarm sistemleri kurulduğunda ne olur? Ekip zamanının büyük bölümünü farklı ekranlar arasında geçirir, olayların şirketler arasındaki bağlantısını kaçırır ve kritik bir sistemin sessizce çökmesini saatler sonra fark eder.

Doğru yapı, konsolide bir izleme mimarisidir. Bu, tek bir NOC panosundan grubun tüm sistemlerinin anlık durumunun görülebildiği, alarm eşiklerinin merkezi olarak tanımlandığı ve olayların otomatik olarak ilgili ekibe yönlendirildiği bir yapı anlamına gelir.

Güvenlik tarafında da aynı ilke geçerlidir. Birden fazla şirkete yayılmış bir tehdit aktörü, şirket bazlı izleme ile görülemez. Konsolide SIEM, logları farklı kaynaklardan birleştirerek şirketler arası korelasyon yapabilir ve bu tür saldırıları erken aşamada tespit edebilir.

6. Politika Mimarisi: Merkezi Kural, Yerel Uygulama

Çok şirketli yapılarda IT politikaları için tek bir model önerim var. Merkezi politika, yerel uygulama.

Temel güvenlik politikaları (erişim kontrolü, parola yönetimi, veri sınıflandırması, değişiklik yönetimi, yedekleme standartları) grubun tamamı için merkezi olarak yazılır ve merkezi IT tarafından sahiplenilir. Bu, uyum raporlamasını kolaylaştırır, tutarlılığı sağlar ve denetçiye tek bir politika seti gösterilmesine imkân tanır.

Ancak her şirketin operasyonel gereklilikleri farklıdır. Bir katılım bankasının kullanıcı erişim süreçleri ile bir finansal teknoloji şirketinin iş akışları aynı değildir. Merkezi politikanın ruhuna sadık kalarak, her şirketin kendi operasyonel prosedürlerini oluşturmasına alan tanımak gerekir.

Bu dengeyi kurmak teoride kolaydır. Sahada ise en çok sürtüşme yaşanan konulardan biridir. Çözüm, merkezi politikaların gerçekten uygulanabilir biçimde yazılması ve her şirketin operasyon ekibine yeterince sezdirilmesidir.

7. Varlık Envanteri: Grubun Hafızası

Merkezi IT modelinde en sık ihmal edilen konulardan biri varlık envanteri yönetimidir.

Grubun hangi şirketinde hangi sunucu çalışıyor, hangi yazılım lisansı kime ait, hangi cihaz kimin kullanımında, hangi sistem kritik iş sürecine bağlı? Bu soruların yanıtı bir envanter sisteminde durmalıdır.

Envanter olmadan ne olur?

  • Lisans maliyetleri kontrol dışına çıkar.
  • Artık kullanılmayan sistemler kaynak tüketmeye devam eder.
  • Felaket kurtarma planı gerçekçi önceliklendirme yapamaz.
  • Bir denetimde hangi sistemin kapsama girip girmediği tartışmaya açık hale gelir.
  • Bir güvenlik olayında etki alanını hızlıca belirlemek imkânsızlaşır.

Envanter yönetimi, hem ITSM süreçlerinin hem de felaket kurtarma planlamasının temel girdisidir. Grubun hangi sisteminin “kritik” olduğunu, hangisinin birkaç saatlik kesintiye toleranslı olduğunu bu envanter üzerinden tanımlamanız gerekir.

8. BDDK Kapsamında Dış Hizmet Sağlayıcı Konumu

Merkezi IT hizmet sağlayıcı olarak çalışmak, BDDK mevzuatı açısından özel bir konum doğurur.

BDDK mevzuatı, bankalara ve diğer denetim altındaki kuruluşlara bilgi sistemleri hizmeti veren kuruluşları “destek hizmeti kuruluşu” olarak tanımlar ve bunları da belirli ölçüde denetim kapsamına dahil eder. Bu; merkezi IT sağlayıcısının yalnızca teknik hizmet sunmakla kalmayıp, regülatif sorumluluğun bir bölümünü de fiilen üstlendiği anlamına gelir.

Sahada bunun yansıması şöyle görünür. Bir grup şirketinin denetiminde denetçi, merkezi IT’nin süreçlerini, politikalarını ve teknik kontrollerini inceleme hakkına sahiptir. Değişiklik yönetimi kayıtları, erişim logları, yedekleme doğrulama raporları, felaket kurtarma tatbikat belgeleri, bunların tamamı denetim kapsamındadır.

Bu gerçeği baştan kabullenip IT süreçlerini buna göre tasarlamak, ilerleyen dönemde çok daha az enerji harcatır.

9. Ekip Yapısı ve Rol Ayrımı

Merkezi IT modelinde ekip yapısı, tek şirket modeline kıyasla daha karmaşıktır. Çünkü aynı ekip birden fazla müşteriye (grup şirketlerine) hizmet vermektedir.

Bu yapıda şu ayrımları net tutmanız gerekir.

Birincisi teknik roller ile koordinasyon rolleri ayrımı. Ağ, sistem, güvenlik, DevOps gibi teknik roller doğrudan altyapıyı yönetir. Koordinasyon rolleri ise şirketler arası talebi yönetir, önceliklendirme yapar, denetim hazırlıklarını koordine eder.

İkincisi merkezi IT ile şirket içi IT bağlantısı. Bazı grup şirketlerinin kendi bünyesinde de küçük bir IT ekibi ya da koordinatörü olabilir. Bu kişilerle merkezi IT arasındaki iş bölümü baştan netleştirilmeli ve yazılı hale getirilmelidir.

Üçüncüsü dış hizmet yönetimi. Merkezi yapıda birden fazla tedarikçi, birden fazla şirket için hizmet sunabilir. Tedarikçilerin hangi şirkete hangi SLA ile bağlı olduğu, kimin hangi tedarikçiyi yönettiği netleştirilmelidir.

10. Üst Yönetimle İletişim: IT’yi Değer Olarak Anlatmak

Çok şirketli yapılarda IT yöneticisinin muhatabı tek bir üst yönetici değildir. Her şirketin CEO’su ya da genel müdürü, aynı merkezi IT’den hizmet alan ama farklı beklentilere sahip birer paydaştır. Ve bunların hepsinin üzerinde grubun patronu vardır.

Teknik göstergeleri değil, iş sonuçlarını ön plana çıkarın. Kaç ticket kapandı değil, kritik sistemlerin yıllık erişilebilirlik oranı neydi. Kaç güvenlik alarmı tetiklendi değil, kaç olayı olaya dönüşmeden kapattınız. Yedekleme sistemi kuruldumu değil, son tatbikatta RTO hedefinizi tutturdunuz mu.

Her şirkete verilen hizmeti ayrı raporlamak da önemlidir. Grup genelinde tek bir IT raporu yeterli değildir. Her şirket kendi hizmet seviyesini, kendi maliyet payını ve kendi uyum durumunu görmek ister.

IT yönetimi görünmez olduğunda başarılı sayılmaz, somut değer ürettiğinde görünür olduğunda başarılı sayılır.

Son Söz

Çok şirketli finansal yapılarda IT yönetmek; hem mühendislik hem hizmet yönetimi hem de regülatif uyum disiplinlerini aynı anda yürütmek demektir.

Bu yapının en büyük tuzağı şudur; Merkezi olmak, sorumlulukları da merkezileştirir. Bir şirketin sisteminde yaşanan sorun, merkezi IT’nin sorumluluğuna girer. Bu baskıyı yönetmenin yolu; süreçleri, politikaları ve rolleri baştan net tanımlamak ve herkese görünür kılmaktır.

Tek bir altyapı, beş farklı şirkete hizmet verebilir. Ama bu hizmetin sürdürülebilir olması için altyapı kadar, o altyapıyı yöneten model de sağlam kurulmuş olmalıdır.

Kaynakça

BDDK & Türk Mevzuatı

BDDK — Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik (15.03.2020) — https://www.bddk.org.tr/Mevzuat/Liste/50

BDDK — Bilgi Sistemleri ve İş Süreçleri Bağımsız Denetimi Hakkında Yönetmelik — https://www.bddk.org.tr/Duyuru/EkGetir/850?ekId=778

BDDK — Denetim ve Gözetim Faaliyetleri — https://www.bddk.org.tr/Sss/Liste/109

Akademik Bağımsız Denetim — Bilgi Sistemleri Denetimi — https://akademikdenetim.com.tr/hizmetlerimiz/bilgi-sistem-denetimi/

IT Yönetişim & Merkezi Hizmet Modeli

ISACA — A Group IT Governance System Model for a Financial Group — https://www.isaca.org/resources/news-and-trends/industry-news/2017/a-group-it-governance-system-model-with-a-pair-of-wheelsoversight-and-shared-itfor-a-financial-group

MetricStream — What is IT Governance? — https://www.metricstream.com/learn/it-governance-guide.html

NETBankAudit — IT Governance in Financial Institutions — https://www.netbankaudit.com/resources/it-governance-financial-services

CloudEagle — 7 IT Governance Best Practices 2026 — https://www.cloudeagle.ai/blogs/it-governance-best-practices

Peeriosity — Creating a Shared Services Governance Structure — https://www.peeriosity.com/shared-services/articles/2018/06/creating-a-shared-services-governance-structure-that-ensures-alignment-with-key-stakeholders/

ScottMadden — Finance Shared Services: Governance and Scope — https://www.scottmadden.com/insight/financial-shared-services-governance-structure-scope/

Maliyet Dağılımı & Hizmet Kataloğu

Uptime Institute — IT Chargeback Drives Efficiency — https://journal.uptimeinstitute.com/it-chargeback-drives-efficiency/

Binadox — IT Chargeback Models — https://www.binadox.com/blog/it-chargeback-models-enhancing-financial-transparency-in-it/

Serviceware — IT Chargeback Models: How to Pick, Price & Roll Out — https://serviceware-se.com/en/blog/it-chargeback-models-how-to-pick-price-and-roll-out

Parsolvo — Chargeback, ITFM and TBM — https://www.parsolvo.com/chargeback-itfm-tbm/

CloudNuro — Shared Services Cost Allocation — https://www.cloudnuro.ai/blog/chargeback-shared-services-cost-allocation

Konsolide İzleme & Güvenlik

Splunk — What Is a SOC? — https://www.splunk.com/en_us/blog/learn/soc-security-operation-center.html

RiverSafe — SIEM Consolidation — https://riversafe.co.uk/resources/tech-blog/everything-you-need-to-know-about-siem-consolidation/

Microsoft Security — What Is SIEM? — https://www.microsoft.com/en-us/security/business/security-101/what-is-siem

SentinelOne — What is SIEM? — https://www.sentinelone.com/cybersecurity-101/data-and-ai/what-is-security-information-and-event-management-siem/