SAP projelerinde “Go-Live” (canlıya geçiş) anı aylarca süren uykusuz gecelerin meyvesinin alındığı bir kutlama sahnesidir. Ancak o sahnenin spot ışıkları söndüğünde ve proje ekibi yavaş yavaş sahadan çekilmeye başladığında, sistemin gerçek sahipleri olan operasyon ekipleri için sessiz bir gerilim başlar. Proje ekibi için “başarıyla tamamlanan bir görev” olan sistem, bakım ekibi için ucu her an açık bir sorumluluklar silsilesidir. Zira SAP projelerinde başarısızlık çoğu zaman teknik yetersizlikten değil, devir sürecinin stratejik bir faz olarak değil, bir ‘formalite’ olarak görülmesinden kaynaklanır.
Gerçek bir devir süreci, sadece bir klasör dolusu PDF ve kullanıcı şifrelerinin paylaşımı değildir; sistemin karakterini, kurulum sırasında atılan “geçici” düğümlerin yerini ve en önemlisi projenin ruhunu teslim etmektir. Bu rehber yazıda, bir SAP sistemini kurmakla onu yaşatmak arasındaki o ince çizgide gizlenen riskleri ve bu riskleri nasıl bertaraf edeceğinizi, sahadan gelen bir tecrübeyle ele alacağız.
1. İnsan Faktörü ve “Bilgi Uçuşu” Riski
SAP dünyasında teknik mimariden daha kritik bir şey varsa, o da bilgiyi elinde tutan insandır. Proje devirlerinde en sık rastlanan ama en az konuşulan risk “Kilit Kişi” bağımlılığıdır.
Görünmez Risk: Projenin tüm teknik detaylarının, kritik entegrasyon noktalarının ve standart dışı çözümlerin sadece bir veya iki kıdemli danışmanın zihninde hapsolmasıdır. Bu kişiler sahadan ayrıldığında veya beklenmedik bir şekilde ulaşılamaz olduğunda, sistemde oluşacak bir kesinti “operasyonel körlüğe” dönüşür. “Biri çarparsa ne olur?” testi yapılmamış bir devir, devir değildir. Sadece personelin ayrılması değil, personelin zihnindeki SPOF (Single Point of Failure) noktalarını analiz etmelisiniz. Bir kriz anında kilit danışman ulaşılamaz olduğunda, bakım ekibinin elinde o krizi yönetecek bir ‘Emergency Runbook’ var mı?
Gerçek Çözüm: Çözüm, sadece doküman değil, İkili Sahiplik (Backup Ownership) ve net bir RACI Matrisi kurmaktır. Kimin hangi interface’den, hangi sertifika yenilemesinden veya hangi kernel update’inden sorumlu olduğu bir isim listesiyle değil, fonksiyonel bir matrisle belirlenmelidir. Bilgi transferi, “anlat-geç” şeklinde değil, sorumlulukların paylaşıldığı bir geçiş dönemiyle mühürlenmelidir.
Ek Bilgi Kaynağı
Stratejik risklerin ötesinde, S/4HANA özelinde adım adım teknik bir kontrol listesine ihtiyaç duyuyorsanız, SAP Community üzerindeki bu kapsamlı rehberi inceleyebilirsiniz.
2. Dokümantasyonun Sessiz İhaneti ve Gölge Takibi
Hepimiz biliriz: Yüzlerce sayfalık “Technical Design Document” (TDD) dosyaları, genellikle tozlu dijital raflarda bekler. Çünkü bu dokümanlar genellikle ne yapıldığını anlatır ama neden yapıldığını söylemez.
Görünmez Risk: Dokümantasyonda sistem parametrelerinin değerleri yazar. Ancak kurulum sırasında yaşanan bir performans darboğazını aşmak için neden o parametrenin standart değerinin dışına çıkıldığı yazmaz. Bakım ekibi aylar sonra standart bir güncelleme yaptığında, o parametrenin neden orada olduğunu bilmediği için sistemi kararsızlığa sürükleyebilir.
Gerçek Çözüm: Devir paketine mutlaka bir Karar Günlüğü (Decision Log) eklenmelidir. Standart dışı her adımın hikayesi burada anlatılmalıdır. Bununla beraber, kağıt üzerindeki bilginin ete kemiğe bürünmesi için Shadowing (Gölge Takip) süreci işletilmelidir. Bakım ekibi, canlı öncesi son iki hafta proje ekibinin “gölgesi” olmalı; klavyeye bizzat dokunmalı ve hata anındaki o “sezgisel” müdahaleyi yerinde öğrenmelidir.
3. Yetkilendirme Enkazı ve Güvenlik Disiplini
Proje fazı bir yarıştır ve bu yarışta “erişim engeli” en büyük düşmandır. Bu yüzden kurulum ekipleri genellikle geniş yetkilerle (SAP_ALL) çalışmaya alışkındır.
Görünmez Risk: Go-live sonrası, proje ekibinden kalan bu geniş yetkilerin açık unutulması veya “belki lazım olur” denilerek temizlenmemesidir. Bu durum sadece bir güvenlik açığı değil, aynı zamanda denetim (audit) süreçlerinde de büyük bir felaketin habercisidir. Ayrıca, acil durum yönetimi (Firefighter) prosedürleri netleşmeden yapılan devirler, ilk krizde “kim yetkiliydi?” kaosuna yol açar.
Gerçek Çözüm: Net bir Canlı Sonrası (Post-Go-Live) Temizlik Takvimi oluşturulmalıdır. Canlıya geçişten sonraki 15. veya 30. günde tüm proje yetkilerinin geri alınacağı önceden deklare edilmelidir. Acil müdahaleler için SAP GRC Access Control (Emergency Access Management) veya en azından loglanan ve sonradan denetlenen bir Firefighter erişim modeli devir anında aktif edilmelidir.
4. Yüksek Erişlebilirlik (HA) ve Cluster Mimari: “Hata Payı” Devredilemez
Bir SAP sisteminin “ayakta” olması, o sistemin “dayanıklı” olduğu anlamına gelmez. Kurulum ekipleri genellikle sistemin en yüksek performansla çalıştığı “ideal durumu” teslim etmeye odaklanırken; operasyon ekiplerinin asıl ihtiyacı, sistemin “en kötü durumda” nasıl davrandığını bilmektir. Yüksek Erişilebilirlik (HA) mimarileri, kağıt üzerinde kusursuz görünen ama ilk gerçek donanım hatasında sessizliğe bürünen birer “kağıttan kaplan” olmamalıdır.
Görünmez Risk: HANA System Replication (HSR) ayarlarının sadece senkronizasyon bazlı kontrol edilmesi ve ASCS/ERS Cluster failover (hata aktarımı) testlerinin sadece kurulumun ilk günlerinde yapılıp bırakılmasıdır. Çoğu devir sürecinde, ikincil düğümün (secondary node) gerçekten veritabanını devralıp almadığı veya cluster yazılımının “split-brain” senaryolarında nasıl tepki verdiği test edilmeden imza atılır. Bu durum, ilk kesintide sistemin elinizde kalması demektir.
Gerçek Çözüm: Devir anında fiili ve sert bir “Failover Testi” talep edilmelidir. Düğümler arası geçiş süreleri (RTO), dokümandaki teorik rakamlarla değil; bizzat kronometre tutularak ölçülmeli ve SAP katmanındaki uygulama sunucularının bu geçişi ne kadar sürede algıladığı doğrulanmalıdır. Ayrıca, teslimat paketine kapsamlı bir SPOF (Single Point of Failure) analiz raporu eklenmeli; tek bir bileşenin (disk, network, switch) tüm mimariyi nasıl etkilediği netleştirilmelidir.
İleri Okuma
Teknik detayların ötesine geçip, SAP sisteminizin kurumsal mimari standartlarında nasıl konumlandırılması ve yönetilmesi gerektiğini anlamak isterseniz; SAP Enterprise Architecture Framework portalı, stratejik yol haritanız için en üst düzey referans kaynağıdır.
5. Görünmez Sistem Yükleri: Joblar, Z-Tablolar ve Entegrasyon
Bir SAP sistemi, canlıya geçtiği andan itibaren kirlenmeye başlayan bir organizmadır.
Görünmez Risk: Proje ekibinin test için kurduğu, sahibi silinmiş veya periyodu yanlış ayarlanmış batch job’lar; boyutu kontrolsüz büyüyen ve housekeeping stratejisi belirlenmemiş “Z” tabloları; ve en tehlikelisi, son kullanma tarihi yaklaşan ama listelenmemiş SSL sertifikaları. Bir sabah sistemin dış dünya ile bağlantısının kopması, genellikle “not alınmamış” küçük bir sertifika detayında gizlidir.
Gerçek Çözüm: Operasyon ekibi, devir sırasında bir Connectivity Runbook (Bağlantı Rehberi) talep etmelidir. Tüm dış bağlantıların muhatapları, sertifika bitiş tarihleri ve hata anındaki iletişim kişileri burada yer almalıdır. Ayrıca, merkezi bir housekeeping stratejisiyle, hangi logların ne zaman silineceği sistem daha ilk günündeyken otomatize edilmelidir.
6. Felaket Senaryoları: Tatbikatı Yapılmamış Plan “Plan” Değildir
CFO veya BT yöneticilerinin en çok sorduğu soru şudur: “Sistem çökerse ne kadar sürede ayağa kalkarız?”
Görünmez Risk: Yedeklerin (backup) alınıyor olması, sistemin kurtarılabileceği (restore) anlamına gelmez. Birçok projede yedekleme başarılı görünürken, ilk restore ihtiyacında veritabanının tutarsız olduğu veya yedekleme medyasının arızalı olduğu fark edilir. Tatbikatı yapılmamış bir Disaster Recovery (DR) planı, sadece bir iyi niyet beyanıdır.
Gerçek Çözüm: Devir sürecinin bir parçası olarak, canlı verilerle bir Restore Drill (Geri Yükleme Tatbikatı) yapılmalıdır. RPO (Veri Kaybı Toleransı) ve RTO (Kurtarma Süresi) değerleri kağıt üzerinde değil, bizzat kronometre tutularak test edilmeli ve sonuçlar yönetimle paylaşılmalıdır.
7. Teknik Borç ve Gözlemlenebilirlik: Sisteminiz Konuşuyor mu?
Geleneksel izleme (monitoring) yöntemleri “sistem ayakta mı?” sorusuna yanıt verir. Modern dünya ise “sistem nasıl hissediyor?” sorusunun peşindedir.
Görünmez Risk: “Çalışıyorsa dokunma” kültürüyle biriktirilen teknik borçlardır. Versiyonların dondurulması, kernel güncellemelerinin ertelenmesi ve sadece loglara bakıp trendleri görmemek, sistemi bir performans krizine sürükler. İzleme araçlarında alarm vardır ama bağlam (context) yoktur; bu da “alarm yorgunluğu” yaratır.
Gerçek Çözüm: Observability (Gözlemlenebilirlik) kültürüne geçiş yapılmalıdır. Loglar arasında korelasyon kurabilen, kapasite planlamasını trend analizleriyle sunan bir yapı kurulmalıdır. Bakım ekibi, proje ekibinden sadece dashboardları değil, sistemin normal davranış reflekslerini (baseline) devralmalıdır.
Devir Anı Geçti, Gerçek Yolculuk Şimdi Başlıyor
Sonuç olarak; SAP projeleri “Go-Live” ile bitmez, aslında tam o gün başlar. Kurulum ekibi sahneden çekilirken, operasyon ekibi yukarıda saydığımız görünmez risklerle baş başa kalır. Başarılı bir devir, sadece bir sorumluluk transferi değil, sistemin sürdürülebilirliği için yapılan en büyük yatırımdır.
Unutulmamalıdır ki; SAP operasyonu bir maliyet merkezi değil, iş sürekliliği için hayati bir Risk Sigortasıdır. Görünmez risklerin farkında olan, teknik derinliği stratejik vizyonla birleştiren bir devir süreci, kurumun dijital omurgasını yıllarca dimdik tutacaktır.
Bu rehberdeki adımlar, firmanızın SAP dünyasındaki yolculuğunu bir “kriz yönetim” sürecinden, “huzurlu bir işletim” modeline taşıyacaktır. Siz de kendi sisteminizde bu görünmez tehlikelerin ne kadarını kontrol altına aldınız?