Bir SAP projesinde canlıya geçişe birkaç hafta kalmıştı. Proje planı ilerliyor, kullanıcı testleri tamamlanıyor, entegrasyonlar sırayla devreye alınıyordu. Kâğıt üzerinde her şey kontrollü görünüyordu.
Ancak testlere daha fazla kullanıcı katıldığında sistemin davranışı değişmeye başladı. Bazı raporların açılma süresi uzuyor, toplu işlemler beklenenden uzun sürüyor, entegrasyon trafiğinin yoğunlaştığı saatlerde performans dalgalanıyordu.
Altyapı yetersiz değildi. En azından sunucu kapasitesine bakıldığında öyle görünüyordu.
Sorun, kapasitenin proje gerçekleriyle birlikte değerlendirilmemesiydi. Kullanıcı sayısı dikkate alınmış ancak eşzamanlı kullanım, dönemsel işlem yoğunluğu, entegrasyon yükü ve veri büyümesi aynı senaryoda bir araya getirilmemişti.
Bu örnek, tek bir projeye özgü değil. Sahada farklı ölçeklerde tekrar eden bir durumu gösteriyor: S/4HANA Greenfield projelerinde altyapı çoğu zaman yeterince güçlü kurulur; ancak her zaman doğru iş yüküne göre tasarlanmaz.
Greenfield yaklaşımı, şirketlere süreçlerini ve teknik mimarisini yeniden kurma fırsatı sunar. Fakat gerçek bir yeni başlangıç, yalnızca eski süreçlerden kurtulmakla değil, sistemin üzerinde çalışacağı yapıyı da gelecekteki ihtiyaçlara göre tasarlamakla mümkündür.
Peki, süreç tasarımı, veri geçişi ve canlıya geçiş takvimi kadar görünür olmayan altyapı kararları, S/4HANA Greenfield projelerinde hak ettiği ilgiyi ne ölçüde görüyor?
Altyapı planlaması projelerde ihmal edilen bir konu değildir. Ancak çoğu zaman teknik ekiplerin kendi içinde çözeceği bir iş paketi olarak değerlendirilir ve iş yükleri, entegrasyonlar, büyüme beklentileri ve iş sürekliliği hedefleriyle yeterince erken ilişkilendirilmez. Oysa altyapı kararları; sistemin performansını, ölçeklenebilirliğini, kesintilere karşı dayanıklılığını ve uzun vadeli işletme modelini doğrudan etkiler.
Bu yazıda, S/4HANA Greenfield dönüşümünün tamamını değil; bu dönüşümün başarılı ve sürdürülebilir olabilmesi için altyapının nasıl planlanması, boyutlandırılması, doğrulanması ve canlıya geçiş sonrasında nasıl izlenmesi gerektiğini ele alıyoruz.
Greenfield ve Brownfield Yaklaşımları Arasındaki Temel Fark
S/4HANA dönüşümlerinde iki temel yaklaşım öne çıkar: Greenfield ve Brownfield.
Greenfield yaklaşımında süreçler, sistem yapısı ve teknik mimari yeniden tasarlanır. Şirket yalnızca mevcut SAP sistemini taşımayı değil, daha sade, standart ve geleceğe açık bir yapı kurmayı hedefler.
Brownfield yaklaşımında ise mevcut SAP sistemi, süreçler ve veriler büyük ölçüde korunarak S/4HANA’ya dönüştürülür. Mevcut yapısından memnun olan, operasyonel değişimi sınırlamak isteyen veya dönüşümü daha kontrollü yürütmeyi hedefleyen şirketler için uygun olabilir.
Greenfield daha anlamlı olabilir | Brownfield daha anlamlı olabilir |
Süreçler karmaşıklaştıysa | Mevcut süreçler sağlıklı çalışıyorsa |
Eski geliştirmeler azaltılmak isteniyorsa | Mevcut yatırımlar korunmak isteniyorsa |
Süreçler yeniden tasarlanacaksa | Değişimin sınırlı tutulması hedefleniyorsa |
Yeni bir mimari kurulacaksa | Mevcut yapı üzerinden ilerlemek isteniyorsa |
Her iki yaklaşımın da avantajları ve riskleri vardır. Bu yazının odağı, sıfırdan bir yapı kurma imkânı sunan Greenfield projelerde altyapının neden yalnızca teknik bir iş paketi olarak görülmemesi gerektiğidir.
Greenfield yaklaşımının temel değeri, eski sistemin teknik ve süreçsel yükünü yeni ortama taşımak yerine, gelecekte ihtiyaç duyulacak işletim modelini yeniden tasarlama fırsatı sunmasıdır. Bu nedenle Greenfield, yalnızca yeni bir S/4HANA sistemi kurmak değil; süreçlerden entegrasyonlara, uygulama mimarisinden altyapıya kadar daha sade, ölçeklenebilir ve sürdürülebilir bir yapı oluşturmak anlamına gelir.
Greenfield Projesinde Altyapı Neden Baştan Planlanmalı?
Greenfield dönüşüm projesinde yeni bir sistem kurulurken süreçler, kullanıcı rolleri, entegrasyonlar ve veri yapısı yeniden ele alınır. Buna rağmen altyapı kararları bazen projenin diğer başlıklarından bağımsız yürütülür.
Greenfield projelerde uygulama tarafında hedeflenen sadelik, altyapı ve işletim modelinde de karşılık bulmalıdır. Clean Core yaklaşımıyla gereksiz geliştirmelerin ve eski teknik yüklerin azaltılması hedeflenirken, yeni sistemin üzerinde çalışacağı yapının da yönetilebilir, izlenebilir ve değişen ihtiyaçlara uyum sağlayabilir biçimde tasarlanması gerekir. Aksi hâlde uygulama katmanında sağlanan sadeleşme, karmaşık bir altyapı ve işletim modeli nedeniyle beklenen faydayı üretemeyebilir.
İş birimleri süreçleri tasarlarken teknik ekip sunucu ve kapasite planlaması yapar. İki çalışma yeterince erken birleşmediğinde altyapı, gerçek kullanım senaryoları yerine varsayımlar üzerinden şekillenebilir.
Bu durum canlıya geçişe yaklaşıldığında şu riskleri ortaya çıkarabilir:
- Yoğun kullanımda performans dalgalanmaları
- Beklenmeyen kapasite yatırımları
- Yedekleme ve geri dönüş sürelerinin uzaması
- Entegrasyonlar arttıkça oluşan yeni darboğazlar
- Proje takviminde son dakika değişiklikleri
- İlk yıllarda yeniden altyapı yatırımı ihtiyacı
Buradaki kritik nokta şudur:Altyapı planlaması, teknik ekiplerin yalnız başına yaptığı bir kapasite çalışması değil; iş yüklerinin teknik mimariye çevrilmesi sürecidir.
Doğru Altyapının İlk Adımı: Sizing
Sizing (Kapasite Boyutlandırma), S/4HANA sisteminin ihtiyaç duyacağı kapasitenin öngörülmesi sürecidir. İşlem gücü, bellek, depolama ve diğer sistem kaynakları; kullanıcı sayısı, veri hacmi, işlem yoğunluğu ve büyüme beklentileri gibi girdilere göre planlanır.
Greenfield projelerde SAP Quick Sizer, kullanıcı sayısı ve işlem hacmi gibi iş verilerinin bellek, işlem gücü, depolama ve I/O gereksinimlerine dönüştürülmesine yardımcı olur. CPU ihtiyacı ise SAP sistemlerinde SAPS olarak ifade edilen standart performans birimleri üzerinden değerlendirilebilir. Bununla birlikte Quick Sizer çıktısı doğrudan bir donanım sipariş listesi değil, altyapı tasarımını destekleyen bir başlangıç verisi olarak ele alınmalıdır.
Çünkü sizing yalnızca “Kaç kullanıcı olacak?” sorusunun cevabı değildir. Aynı kullanıcı sayısına sahip iki şirketin altyapı ihtiyaçları birbirinden tamamen farklı olabilir. Bir şirkette kullanıcıların önemli bölümü rapor görüntülerken diğerinde sipariş, üretim, faturalama, planlama ve entegrasyon işlemleri gün boyunca eşzamanlı çalışabilir.
Her iş yükü kullanıcı sayısıyla da açıklanamaz. Toplu faturalama, dönem sonu işlemleri, planlama çalışmaları veya entegrasyon akışları gibi senaryolarda belirleyici olan, işlemi kaç kullanıcının başlattığından çok, belirli bir zaman aralığında kaç iş nesnesinin işlendiğidir. Bu nedenle kullanıcı tabanlı sizing ile işlem hacmi tabanlı sizing birlikte değerlendirilmelidir.
Günlük toplam işlem hacmi de tek başına yeterli bir gösterge değildir. Aynı işlem adedi günün tamamına yayıldığında farklı, iki saatlik kritik bir zaman aralığında tamamlanması gerektiğinde farklı bir kapasite ihtiyacı doğurur. Bu nedenle sizing çalışmasında yalnızca ortalama yük değil, tepe (peak – time) saatler ve iş süreçlerinin tamamlanması gereken süreler de dikkate alınmalıdır.
Greenfield projelerde hedef sistemin gerçek kullanım geçmişi henüz oluşmamıştır. Ancak bu, sizing çalışmasının tamamen varsayımlara dayanacağı anlamına gelmez. Mevcut operasyon verileri, geçmiş işlem hacimleri, iş birimlerinin beklentileri ve gelecekteki büyüme tahminleri birlikte değerlendirilerek hedef sistem için gerçekçi bir yük profili oluşturulabilir.
Sağlıklı bir sizing çalışması şu sorulara birlikte yanıt vermelidir:
- Sistemi toplam kaç kişi kullanacak?
- Aynı anda kaç kullanıcı aktif olacak?
- Kullanıcılar hangi işlemleri ne sıklıkta gerçekleştirecek?
- Belirli zaman aralıklarında kaç belge veya iş nesnesi işlenecek?
- Günlük ve dönemsel işlem yoğunluğu nasıl değişecek?
- Veri hacmi önümüzdeki üç ila beş yılda nasıl büyüyecek?
- Entegrasyonlar, raporlama ve analitik kullanımlar sisteme ne kadar yük getirecek?
- Yeni şirket, tesis veya lokasyonların sisteme eklenmesi planlanıyor mu?
Doğru sizing, doğru altyapı tasarımının başlangıç noktasıdır. Ancak sizing sonucunun gerçek kullanım senaryoları, iş sürekliliği hedefleri, altyapı modeli ve büyüme planlarıyla birlikte yorumlanması gerekir. Başka bir ifadeyle sizing, nihai mimari kararın kendisi değil, bu kararın en önemli girdilerinden biridir.
Performans Yalnızca Donanım Gücü Değildir
S/4HANA altyapısında performans, tek bir bileşenin yüksek kapasitesinden doğmaz. İşlemci, bellek, depolama, ağ, işletim sistemi ve uygulama katmanlarının dengeli çalışması gerekir.
Ayrıca iş yükü yalnızca klasik kullanıcı işlemlerinden oluşmaz. Fiori uygulamaları, OData servisleri, sistemler arası entegrasyonlar, raporlama işlemleri ve arka plan işleri de altyapı üzerinde farklı yükler oluşturur. Bu yükler tek tek sınırlı görünse bile aynı zaman aralığında çalıştıklarında önemli bir tepe yük meydana getirebilir.
Sahada karşılaşılan yaygın yanılgılardan biri, güçlü sunucunun yüksek performansı garanti ettiği düşüncesidir. Oysa hızlı bir işlemci, depolama veya ağ tarafındaki bir darboğaz nedeniyle beklenen sonucu veremeyebilir.
Bir diğer önemli konu da test ortamının canlı ortamı ne kadar temsil ettiğidir.
Test ortamında canlıya göre daha az veri, daha az eşzamanlı kullanıcı ve daha sınırlı entegrasyon trafiği bulunuyorsa başarılı sonuçlar yanıltıcı olabilir. Özellikle Greenfield projelerde test verisinin ve işlem hacminin canlı sistemi yeterince temsil etmemesi, performans darboğazlarının ancak gerçek kullanıma geçildiğinde ortaya çıkmasına neden olabilir.
Bu yüzden yalnızca sistemin açılması ve işlemlerin tamamlanması yeterli değildir. Yük testleri, sistemin beklenen normal ve yoğun kullanım altında nasıl davrandığını gösterirken; stres testleri kapasite sınırlarının ve olası darboğazların hangi noktada ortaya çıktığını görünür hâle getirir.
Canlıya geçiş öncesinde şu senaryolar da değerlendirilmelidir:
- Eşzamanlı kullanıcı yükü
- Toplu işlemler
- Yoğun raporlama
- Entegrasyon trafiği
- Dönem sonu operasyonları
- Yedekleme sırasında oluşan sistem yükü
Bu testler, yalnızca performansı ölçmek için değil, mimarinin zayıf noktalarını canlıya geçişten önce görmek için yapılmalıdır.
İleri Okuma
Canlıya geçiş sonrası sistem performansını korumak ve olası operasyonel kesintilerin önüne geçmek için [ SAP Kurulumu Sonrası Devir Rehberi: Görünmez Riskler, Gerçek Çözümler ] başlıklı rehberimize de göz atabilirsiniz.
İş Sürekliliği Sonradan Eklenen Bir Özellik Değildir
S/4HANA birçok şirket için finans, üretim, satış, satın alma ve lojistik süreçlerinin merkezindedir. Sistemin erişilemez olması yalnızca teknik bir arıza değil, operasyonun durması anlamına gelir.
Bu nedenle Greenfield projede şu sorular daha başlangıç aşamasında yanıtlanmalıdır:
- İşletme ne kadar süreli kesintiyi kabul edebilir?
- Arıza durumunda sistem ne kadar sürede yeniden çalışmalıdır?
- Kabul edilebilir veri kaybı sınırı nedir?
- Yedekleme ve geri dönüş senaryoları test edilecek mi?
- Kritik bileşenler için yedekli yapı gerekiyor mu?
- Felaket durumunda sistem farklı bir lokasyonda çalışabilecek mi?
Burada önemli olan, en kapsamlı veya en pahalı çözümü kurmak değildir. İşletmenin risk seviyesi ile altyapı yatırımını dengeli biçimde eşleştirmektir.
Her şirketin süreklilik ihtiyacı aynı değildir. Ancak bu ihtiyacın tanımlanmamış olması, düşük bir ihtiyaç olduğu anlamına gelmez.
Bugünü Karşılayan Değil, Büyümeyi Destekleyen Altyapı
Greenfield projelerde sık yapılan hatalardan biri, altyapının yalnızca ilk canlıya geçiş kapsamına göre planlanmasıdır.
İlk yıl için yeterli görünen kapasite; yeni şirketlerin sisteme eklenmesi, entegrasyon sayısının artması, veri hacminin büyümesi veya analitik kullanımın yaygınlaşmasıyla kısa sürede sınırlarına yaklaşabilir.
Veri büyümesini planlamak, yalnızca gelecek yıllardaki veri tabanı boyutunu tahmin etmek değildir. Hangi verinin aktif sistemde ne kadar süre tutulacağı, hangi verinin arşivleneceği, yedeklerin ne kadar alan kullanacağı ve yedekleme sürelerinin operasyonel pencereye sığıp sığmayacağı da altyapı ihtiyacını doğrudan etkiler. Bu nedenle sizing ile veri yaşam döngüsü yaklaşımı birlikte ele alınmalıdır.
Bunun yanında, gelecekte ortaya çıkabilecek her ihtimal için gereğinden büyük bir sistem kurmak da doğru yatırım yaklaşımı değildir.
Doğru hedef şu olmalıdır:
Bugünkü ihtiyacı karşılayan, büyümesi ölçülebilen ve ihtiyaç arttığında kontrollü biçimde genişletilebilen bir mimari kurmak.
Ayrıca, sistemin şirket içinde, özel bulutta veya yönetilen bir bulut modeli üzerinde konumlandırılması da kapasitenin nasıl artırılacağını, sorumlulukların kimde olacağını ve süreklilik yapısının nasıl tasarlanacağını değiştirir.
Kısacası, Greenfield altyapı tasarımında yalnızca kapasite değil, kapasitenin nasıl izleneceği ve ne zaman artırılacağı da planlanmalıdır.
Altyapı Tasarımı Kurulumla Bitmez
Bir altyapının doğru tasarlanmış olması, onun uzun vadede doğru işletileceği anlamına gelmez.
Canlıya geçiş sonrası şu soruların da cevabı olmalıdır:
- Sistem performansını kim izleyecek?
- Kapasite artışı hangi göstergelere göre planlanacak?
- Kritik uyarılar nasıl takip edilecek?
- Yedeklerin geri yüklenebilirliği nasıl doğrulanacak?
- Güncelleme ve bakım sorumlulukları kimde olacak?
- Performans sorunu oluştuğunda hangi ekipler birlikte çalışacak?
Sonuç olarak altyapı tasarımı ile işletim modeli birbirinden ayrı düşünülmemelidir. Proje döneminde kurulan sistem, canlıya geçişten sonra ölçülmüyor ve düzenli olarak iyileştirilmiyorsa başlangıçta yapılan doğru yatırım zamanla değerini kaybedebilir.
Greenfield Altyapısı Nasıl Daha Sağlıklı Planlanır?
Greenfield projelerde altyapı kararlarının yalnızca teknik varsayımlara dayanmaması gerekir. İş birimleri, uygulama danışmanları, entegrasyon ekipleri ve SAP Basis uzmanları aynı kullanım senaryosu üzerinde çalışmalıdır.
İş hacmini kullanıcı sayısıyla sınırlamayın. Quick Sizer çalışmasında toplam kullanıcı sayısının yanı sıra eşzamanlı kullanıcılar, saatlik belge adetleri, toplu işlemler, arka plan işleri ve dönemsel yoğunluklar da dikkate alınmalıdır.
Tüm iş yüklerini aynı resimde değerlendirin. Fiori uygulamaları, OData servisleri, entegrasyonlar, raporlama işlemleri ve toplu işler ayrı ayrı küçük görünse de aynı zaman aralığında çalıştıklarında belirgin bir tepe yük oluşturabilir.
Entegrasyon haritasını erken oluşturun. Yalnızca kaç sistemle entegrasyon kurulacağını bilmek yeterli değildir. Hangi sistemlerin ne sıklıkta veri göndereceği, işlem hacimlerinin hangi saatlerde yoğunlaşacağı, başarısız işlemlerin nasıl tekrar çalıştırılacağı ve canlıya geçiş sırasında hangi bağlantıların eşzamanlı devreye alınacağı da belirlenmelidir. Bu harita, hem sizing varsayımlarının doğruluğunu artırır hem de yük ve uçtan uca test senaryolarının gerçekçi biçimde hazırlanmasını sağlar.
Canlıya yakın senaryolarla test edin. Test ortamında yalnızca fonksiyonların çalışması yeterli değildir. Canlıya yakın veri hacmiyle yapılan yük ve stres testleri, beklenen kullanım koşullarını ve sistemin kapasite sınırlarını görünür hâle getirir.
Sizing’i tek seferlik çalışma olarak görmeyin. Proje kapsamı, kullanıcı sayısı, entegrasyonlar veya veri beklentileri değiştiğinde sizing varsayımları yeniden gözden geçirilmelidir. Canlıya geçiş sonrasında ise gerçek kullanım değerleri izlenerek başlangıç tahminleri doğrulanmalıdır.
SAP Basis Uzmanlığı Projeye Nerede Değer Katar?
SAP Basis uzmanlığı yalnızca sistem kurulumu ve teknik yönetimden ibaret değildir.
Deneyimli bir SAP Basis ekibi;
- İş ihtiyaçlarını teknik kapasite gereksinimlerine dönüştürür,
- Sizing sonuçlarını gerçek kullanım senaryolarıyla değerlendirir,
- Altyapı bileşenleri arasındaki uyumu kontrol eder,
- Test ve canlı ortamlar arasındaki riskleri görünür hâle getirir,
- Performans ve süreklilik senaryolarını proje başlamadan sorgular,
- Canlıya geçiş sonrası izleme ve işletim modelinin kurulmasına katkı sağlar.
Buradaki asıl değer, sorun çıktığında müdahale etmekten önce, sorunun oluşabileceği noktaları proje tasarımında fark edebilmektir. Özetle proaktif bir yaklaşım ortaya koymaktır.
Altyapı Planlamasında Araçlar Nasıl Konumlandırılmalı?
S/4HANA Greenfield projelerinde altyapı planlaması tek bir sizing çalışmasıyla tamamlanmaz. Başlangıç varsayımlarının araçlarla desteklenmesi, planlanan altyapının testlerle doğrulanması ve canlıya geçiş sonrasında gerçek kullanım verileriyle izlenmesi gerekir. Bu yaklaşım üç aşamada özetlenebilir: öngör, doğrula ve izle.
SAP Quick Sizer gibi araçlar beklenen kaynak ihtiyacının öngörülmesine yardımcı olurken, SAP HANA Hardware and Cloud Measurement Tools planlanan sunucu, depolama ve ağ yapısının SAP HANA gereksinimlerini karşılayıp karşılamadığını ölçmek için kullanılabilir.
Canlıya geçiş sonrasında ise kapasite planı sabit bir belge olarak bırakılmamalıdır. SAP Cloud ALM gibi izleme çözümleriyle sistem sağlığı, kaynak kullanımı, entegrasyonlar ve performans eğilimleri takip edilerek başlangıç varsayımlarının gerçek kullanımla ne kadar örtüştüğü görülmelidir.
Bu araçların hiçbiri tek başına doğru altyapı kararını garanti etmez. Asıl değer, araçlardan elde edilen sonuçların gerçek iş yükleri, büyüme beklentileri, entegrasyonlar, iş sürekliliği hedefleri ve işletim modeliyle birlikte yorumlanmasında ortaya çıkar.
Sağlıklı yaklaşım; altyapıyı önce öngörmek, ardından doğrulamak ve canlı kullanım boyunca izlemektir.
Tablo 1. S/4HANA Greenfield Altyapı Planlamasında Önerilen Araçlar
Aşama ve amaç | Kullanılabilecek araç |
Öngör Beklenen kapasite ihtiyacını belirlemek | SAP Quick Sizer |
Doğrula Planlanan altyapının SAP HANA gereksinimlerini karşılayıp karşılamadığını test etmek | SAP HANA Hardware and Cloud Measurement Tools |
İzle Canlı sistemde performans, kapasite ve sistem sağlığını takip etmek | SAP Cloud ALM |
Sonuç: Güçlü Başlangıç, Sürdürülebilir Sistem
S/4HANA Greenfield projeleri, şirketlere süreçlerini ve teknoloji altyapısını yeniden tasarlama fırsatı sunar. Ancak bu fırsatın gerçek değere dönüşmesi için altyapının yalnızca teknik bir kurulum konusu olarak görülmemesi gerekir.
Sizing önemli bir başlangıç noktasıdır. Fakat performans, iş sürekliliği, entegrasyonlar, veri büyümesi, test yaklaşımı ve işletim modeli birlikte ele alınmadan tek başına yeterli değildir.
Sağlam altyapı; en yüksek kapasiteye sahip sistem değil, iş yükünü doğru anlayan, riskleri önceden gören ve değişen ihtiyaçlara kontrollü şekilde uyum sağlayan sistemdir.
S/4HANA Greenfield projelerinde güçlü bir başlangıç, yalnızca yeni bir sistem kurmakla değil, o sistemin hangi koşullarda çalışacağını daha proje başlamadan kapsamlı planlamakla mümkündür.
Sık Sorulan Sorular
Greenfield, mevcut sistemin ve teknik borçların doğrudan taşınması yerine; süreçlerin, sistem yapısının ve teknik mimarinin sıfırdan ve geleceğe dönük tasarlandığı S/4HANA dönüşüm yaklaşımıdır.
Sizing; doğru donanım veya bulut maliyetini belirlemek, atıl kapasiteden kaçınmak ve canlı geçiş sonrası performans tıkanıklıklarının önüne geçmek için veri, işlem ve entegrasyon ihtiyaçlarına uygun altyapıyı boyutlandırma işlemidir.
Yanlış sizing, canlı geçiş sonrasında sistem kilitlenmelerine ve performans krizlerine ya da ihtiyaçtan fazla donanım alarak yüksek ve gereksiz maliyetlere (over-provisioning) yol açar. Doğru sizing; sistemin ilk günden itibaren hem kesintisiz çalışmasını hem de bütçenin optimal kullanılmasını sağlar.
Hayır. Toplam lisans veya kullanıcı sayısı tek başına yanıltıcıdır. Eşzamanlı kullanım (concurrency), arka plan işleri, entegrasyon trafiği ve dönemsel tepe yükler (peak load) mutlaka hesaba katılmalıdır.
Ölçek olarak canlı sistemin gerisinde kalan ve sentetik veri barındıran test ortamları, yük altındaki darboğazları göstermez. Gerçekçi bir performans ve stres testi için test ortamının mimarisi ve veri ölçeği canlı sistemi yansıtmalıdır.
Hayır. Bulut altyapıları (Cloud ERP / RISE with SAP) kaynak artırmayı (scale-up/scale-out) kolaylaştırsa da; yanlış tasarlanmış bir bellek, disk I/O veya uygulama katmanı mimarisi canlı geçiş anında ciddi kesintilere ve tahmin edilmeyen yüksek bulut maliyetlerine (cloud cost Overrun) yol açar. Esneklik, doğru altyapı planlamasının yerini tutmaz; sadece onu destekler.
SAP Basis ekibi; altyapı ve mimari tasarımdan sizing doğrulamasına, sistem kurulumlarından entegrasyon, güvenlik, yük testi ve canlıya geçiş (cutover) süreçlerine kadar projenin tüm teknik omurgasını inşa eder.