Pazartesi sabahı SAP sistemleri açılmadığında ya da kritik bir siber güvenlik açığı ortaya çıktığında, SAP Basis ekibinizin performansı o anki teknik reflekslerinden değil, aylar önce seçtiğiniz operasyonel modelden kaynaklanır.
SAP dünyasında “her şey yolunda gidiyor” çoğu zaman test edilmemiş bir varsayımdır. Asıl soru sistemin durup durmayacağı değil, durduğunda şirketin ne kadar hızlı ve kontrollü şekilde ayağa kalkabileceğidir.
SAP Basis operasyonu çoğu organizasyonda teknik bir konu olarak görülür. Oysa gerçekte bu bir yönetişim tercihidir. Riskin kim tarafından taşınacağı, kritik bilginin nerede konumlanacağı ve 7/24 sürekliliğin nasıl sağlanacağı stratejik kararlardır.
Bir CTO için temel soru şudur:
SAP operasyon modelimiz, şirketimizin risk profilini gerçekten karşılıyor mu?
Bu yazıda, farklı operasyon modellerini analitik bir çerçevede ele alıyor ve hangi yapının hangi koşulda daha mantıklı olduğunu değerlendiriyoruz.
1. SAP Basis Operasyonu Gerçekte Neyi Yönetir?
SAP Basis yalnızca sistem izleme değildir. Şu alanları kapsar:
- 7/24 monitoring ve alarm yönetimi
- Performans ve kapasite planlama
- Backup & restore süreçleri
- Yüksek Erişilebilirlik ve Felaket Kurtarma tasarımı ve testleri
- Kernel ve yama (patch) yönetimi
- SAP Note ve güvenlik güncellemeleri
- Entegrasyon ve altyapı koordinasyonu
- Teknik güvenlik sertleştirmeleri
Bu işler “arka planda” görünür. Ancak bu arka plan, iş sürekliliğinin temelidir. Dolayısıyla konu teknik değil; operasyonel dayanıklılıktır.
2. Modern Bağlam: Cloud, RISE ve Paylaşılan Sorumluluk
2026 itibarıyla SAP operasyonu artık yalnızca veri merkezi yönetimi değildir.
RISE with SAP, hyperscaler geçişleri (Azure, AWS, GCP) ve hibrit yapılar nedeniyle kurumlar “Shared Responsibility Model” içinde çalışmaktadır.
Altyapı katmanı bulut sağlayıcıda olabilir.
Uygulama katmanı kurumda veya partnerde olabilir.
Ancak güvenlik sertleştirmeleri, yama sorumluluğu ve HA/DR sınırları çoğu zaman sözleşmelerde net tanımlanmış olsa bile operasyonel pratikte gri alana dönüşebilir.
Bu nedenle operasyon modeli seçimi artık sadece insan kaynağı kararı değil; bir bulut yönetişim kararıdır.
3. SAP Basis Operasyon Modelleri
Reaktif Model
Sistem çalıştığı sürece müdahale edilmez. Olay (incident) olduğunda çözüm aranır.
Görünür maliyet: düşük
Görünmeyen maliyet: yüksek
- Felaket kurtarma testleri yapılmaz
- Kernel güncellemeleri ertelenir
- Performans iyileştirmeleri talep geldikçe yapılır
Bu model genellikle küçük ekiplerde görülür. Risk profili öngörülemezdir.
In-House Model
Operasyon tamamen kurum içi ekip tarafından yürütülür.
Avantajları
- Kontrol kurumda
- Kritik bilgi içeride
- Mimari kararlar hızlı
Riskleri
- Tek kişiye bağımlılık
- 7/24 sürdürülebilirlik problemi
- Operasyon yükü nedeniyle stratejik projelerin gecikmesi
- Uzmanlık derinliğinin sınırlı kalması
- Yetenek Kıtlığı ve Piyasa Riski:
Global SAP Basis uzmanı arzındaki daralma, in-house ekipleri yüksek maaş skalalarına ve agresif işe alım rekabetine açık hale getirir. Kritik bir uzmanın ayrılması yalnızca bir personel kaybı değil, kurumsal hafızanın zayıflaması anlamına gelir.
Bu model, güçlü bir organizasyon kültürü ve sürdürülebilir yedekleme planı yoksa zamanla kırılgan hale gelir.
CTO için kritik soru:
Kritik bilgi kaç kişide?
Bir ayrılık operasyonel kırılganlık yaratır mı?
Yönetilen Hizmetler Modeli (Managed Services)
Operasyon büyük ölçüde dış servis sağlayıcı tarafından yürütülür.
Avantajları
- 7/24 kapsama
- Uzmanlık çeşitliliği
- Operasyonel disiplin
- Süreklilik
Riskleri
- Bilgi kurum dışına kayabilir
- İç ekip zayıflayabilir
- SLA ile gerçek performans arasında fark olabilir
- Sorumluluk sınırları bulanıklaşabilir
- Vendor bağımlılığı ve sözleşme esnekliğinin sınırlı kalma riski (Vendor-Lock riski)
Bu model özellikle:
- Küçük–orta ölçekli SAP ortamlarında
- İçeride sürdürülebilir uzmanlık yoksa
- SAP ana iş odağı değilse
daha anlamlıdır.
Hibrit Model
Operasyonel yük paylaşılır.
- Günlük izleme dış ekipte
- Mimari ve stratejik kararlar içeride
- Proje dönemlerinde kapasite desteği
- DR ve güvenlik testleri ortak yürütülür
Avantajı
- Bilgi kurum içinde kalır
- Operasyonel yük azalır
- Esneklik artar
Zorluk
- Rol tanımı net değilse karmaşa oluşur
Birçok orta ve büyük ölçekli organizasyon için en dengeli model budur.
Ek Bilgi Kaynağı
Çoğu SAP dönüşümü teknolojiden değil, diyagramları karar sanmamızdan dolayı başarısız olur. SAP ortamları neden güçlü görünürken kırılgan davranıyor? Gerçek mimari hangi katmanlardan oluşmalı? Dayanıklı bir SAP ekosistemi nasıl tasarlanır? Hepsini bu yazıda keşfedin!
4. Operasyon Ayrı, Mimari Ayrı: Danışmanlık Katmanı
Operasyonel kapasite ile mimari uzmanlık aynı şey değildir.
Bir şirket Basis operasyonunu in-house başarıyla yönetebilir. Ancak şu kararlar günlük operasyonun ötesindedir:
- S/4HANA dönüşüm mimarisi
- HANA scale-up vs scale-out kararı
- Active-active vs active-passive HA tasarımı
- Hyperscaler geçiş planı
- DR senaryosunun iş sürekliliği ile hizalanması
- SAP Security hardening stratejisi
Bu kararlar nadir alınır ama etkisi büyüktür.
Operasyonel stabilite, mimari doğruluğun garantisi değildir.
Kendi sistemini kuran ekip, kendi kör noktasını her zaman göremez. En güçlü in-house ekibe sahip olsanız bile, yılda bir kez yapılan bağımsız bir “System Health Check” veya mimari teknik inceleme, modelden bağımsız bir gerekliliktir. Bu yaklaşım bir güvensizlik değil, kurumsal olgunluk göstergesidir.
Dolayısıyla modelden bağımsız olarak şu yapı mantıklıdır:
- Operasyon in-house olabilir
- Kritik mimari kararlar için dış teknik danışmanlık alınabilir
- Dönemsel bağımsız teknik review yapılabilir
5. Görünen ve Görünmeyen Maliyetler
CTO ve CFO için en zor konu maliyettir.
Görünen maliyet
- Maaş
- Hizmet bedeli
- Sözleşme tutarı
Görünmeyen maliyet
- Bir saatlik kesintinin iş kaybı
- Tek kişiye bağımlılık riski
- Ertelenen iyileştirmelerin fırsat maliyeti
- Proje gecikmesi
- Regülasyon riski
- Güvenlik zafiyeti
Bir büyük olayın (incident) maliyeti çoğu zaman yıllık yönetilen hizmetler sözleşme bedelinden daha yüksektir. Özellikle üretim, perakende ve finans sektörlerinde birkaç saatlik kesinti, operasyon bütçesinin tamamını sorgulatabilecek etki yaratabilir.
Dolayısıyla soru:
“Hangisi ucuz?” değil,
“Hangi yapı riski daha öngörülebilir hale getiriyor?”
6. CFO Perspektifi
Finans bakış açısı genellikle sabit maliyet vs değişken maliyet üzerinden ilerler.
In-house model:
- Sabit maaş gideri
- Uzmanlık derinliği sınırlı
- Yüksek işe alım ve tutundurma riski
Yönetilen Hizmet modeli:
- Sözleşmeye bağlı maliyet
- Ölçeklenebilir kapasite
- Risk transferi
Hibrit model:
- Dengeli maliyet dağılımı
Ancak CFO için asıl mesele şudur:
- Kritik olay maliyeti nedir?
- Sistem kesintisinin finansal etkisi nedir?
- Felaket kurtarma başarısızlığı durumunda zarar ne olur?
SAP operasyonu bir maliyet merkezi değil; risk sigortasıdır.
7. Hızlı Karar Matrisi: Hangi Model Size Uygun?
Soru | Cevap “Evet” ise |
7/24 gerçek müdahale ihtiyacı var mı? | Managed / Hibrit |
Kritik bilgi tek kişide mi? | Managed / Hibrit |
SAP stratejik platform mu? | In-house + danışmanlık |
Sistem karmaşıklığı yüksek mi? | Hibrit |
Regülasyon baskısı yüksek mi? | In-house / Hibrit |
Ekip projelere zaman ayıramıyor mu? | Managed / Hibrit |
Sonuç: Doğru Model, Doğru Risk Yönetimiyle Başlar
SAP Basis operasyonunda tek doğru model yoktur.
Yanlış olan şudur:
- Ölçeğe uymayan yapı
- Risk profilini karşılamayan organizasyon
- Bilgi tekeline dayalı operasyon
- Reaktif yönetim
Doğru model, şirketinizin:
- Karmaşıklığına
- Risk toleransına
- Stratejik hedeflerine
- Ekip kapasitesine
uyum sağlayan modeldir.
Şu anki modelinizin risk profilini net olarak biliyor musunuz?
Bir sonraki büyük SAP projesine (örneğin S/4HANA dönüşümü veya Cloud geçişi) başlamadan önce şu üç soruyu ekibinize sorun:
- Son 12 ayda operasyonel zayıflıklarımız nerede ortaya çıktı?
- Kritik bilgi kaç kişiye bağlı?
- Büyük bir kesintide ilk 24 saatte kim hangi kararı verecek?
Bu sorulara verilen netlik, modelinizin doğruluğunu gösterecektir.
SAP operasyonu çalışıyor olabilir. Ancak dayanıklılık, seçtiğiniz modelin bir sonucudur. Model, kriz anında test edilir. O ana kadar yalnızca bir tercihtir.