SAP implementasyonu ve rollout: farklar ve ne zaman hangisi

Bir SAP implementasyonu, sistemin hiç bulunmadığı yerde onu sıfırdan kurar. Rollout ise grubun bir yerinde zaten çalışan bir SAP sistemini yeni bir ülkeye, tüzel kişiye ya da iş birimine yaygınlaştırır. Çoğu kişi rollout'u daha küçük bir implementasyon sanır. Bu varsayım, bu programlarda herhangi bir teknik karardan daha fazla yeniden işe yol açar.

Bir keresinde bir CFO'nun, bölgesel bir SAP rollout'unun tak-çalıştır olacağına inanmasına izin verdim. Riskleri anlattım ama üstelemedim. Küresel bir şablon kullanıyorduk ve o, her lokasyonun çok çaba harcamadan uyum sağlayacağını varsaydı. Öyle olmadı. Bir bölgenin ek vergi işlemeye ihtiyacı vardı. Bir başkasında yerel yasalar nedeniyle zorunlu çalışan verisi alanları vardı. Kopyala-yapıştır gibi görünen iş, gerçek bir özelleştirme gerektirdi.

Yani bu seçim, kaynağı nasıl ayıracağınızı, bütçeyi nasıl kuracağınızı ve işi nasıl yürüteceğinizi değiştirir. Yanlış seçerseniz sistem yine de canlıya geçebilir, ama planladığınız biçimde değil.

Bir implementasyon sıfırdan başlar. Kapsamı tanımlar, süreçleri haritalar, yapılandırma yapar, veri taşır ve entegrasyonlar kurarsınız. Kuruluşta hiç SAP yoksa ya da eski bir sistem tümüyle değiştirilecekse bu yol geçerlidir.

Bir rollout zaten işleyen bir tasarımı yeniden kullanır: süreçleri, yapılandırmayı, ana veri standartlarını. İş, bu şablonla yeni lokasyonun ihtiyaçları arasındaki farktır. Vergi, yasal raporlama, para birimleri, diller, yerel entegrasyonlar ve sistemi kullanacak insanlar.

1. 05Yerel kullanıcılarYerel sürece uyarlanmış, yerel dilde eğitim
2. 04Yerel entegrasyonlarYeni ülkedeki bankalar, vergi beyanı ve lojistik sistemleri
3. 03Yerel veriKüresel standartlara eşlenmiş müşteri, satıcı ve malzeme verileri
4. 02Yerel gereksinimlerVergi, yasal raporlama ve zorunlu alanlar. Yalnızca gereksinimler, tercihler değil
5. 01Küresel şablonZaten işleyen süreçler, yapılandırma ve ana veri standartları

İkisi pratikte şöyle karşılaştırılır:

Alan	SAP implementasyonu	SAP rollout
Başlangıç noktası	SAP yok ya da eski bir sistem değiştiriliyor	SAP merkezde ya da başka bir tüzel kişide zaten çalışıyor
Tasarım	Yeni tasarım, fit-to-standard	Kontrollü yerel sapmalarla küresel şablon
Tipik süre	12 ila 24 ay, büyük gruplarda daha uzun	Lokasyon başına 6 ila 12 ay
Ana risk	Tüm iş akışlarında belirsizlikler	Yerelleştirme ve yerel hazırlık
Veri	Eski sistemlerden tam yükleme	Küresel ana veri standartlarına eşlenen yerel veri
Test	Tam döngü: birim, entegrasyon, UAT, performans	Yerelleştirme, yerel arayüzler, UAT
Değişim yönetimi	Sıfırdan tam program	Yerel ekiplere uyarlanan mevcut materyaller

Implementasyon şu durumlarda uygundur:

1. Kuruluş hiç SAP kullanmamıştır.
2. Mevcut sistem başarısız oluyor ve bütünüyle değiştirilmesi gerekiyor.
3. Bir birleşme, satın alma ya da yeni bir işletme modeli, eski tasarımı artık uygunsuz kılıyor.
4. Bir sektör çözümü ilk kez devreye giriyor; örneğin SAP for Utilities ya da SAP for Public Sector.
5. İhtiyaç duyduğunuz kapsamı karşılayan mevcut bir şablon yok.

Implementasyonlar daha uzun sürer ve baştan daha pahalıdır. Karşılığında işinize uyan bir tasarım ve arkasındaki her tercihi anlayan bir ekip elde edersiniz. Gereksinimleri aceleyle geçen şirketler, hataları sonradan düzeltmek için yüzde 30 ila 50 daha fazla harcıyor. Bunun defalarca yaşandığını gördüm.

Rollout, SAP grubun bir yerinde zaten iyi çalışıyorsa, çekirdek süreçler oturmuşsa ve şablon, yerel gereksinimleri bozulmadan karşılayacak kadar esnekse uygundur. Bu üçünden biri sağlam değilse, şablonu hiçbir yere yaygınlaştırmadan önce düzeltin.

Teknik taraf genellikle zamanında biter. Gecikmeler insanlardan ve yeni ülkede geçerli olmayan varsayımlardan gelir.

Yerel ekiplere dayatılan şablon

Kuzey Amerika'da iyi çalışan bir şey Asya'da ya da Orta Doğu'da yetersiz kalabilir. Vergi yapıları, onay iş akışları ve veri girişi kuralları farklıdır. Bir keresinde Avrupa şablonunun Orta Doğu'da da işleyeceğini varsayan bir şirketle çalıştım. Gecikmelere, baştan yazmalara ve epeyce gerginliğe yol açtı. İş süreçleri birbirinden çok farklıydı.

Çözüm, yeni lokasyona karar verme yetkisi olan bir iş sahibi vermektir. Merkez ekiplerinin anlamadıkları yerlerin süreçlerine karar vermesi, yerel kullanıcılarla karşılaşır karşılaşmaz çöken tasarımlar üretir.

Testte ortaya çıkan yerelleştirme

Vergi işleme, yasal raporlar ve zorunlu veri alanları, tasarım başlamadan önce doğrulanmalıdır. Bir keresinde, basit bir vergi yapılandırması farkı yüzünden canlıya geçişi bir aydan fazla gecikmiş bir müşteriyi destekledim. Konu teknoloji değildi. Yerel ihtiyaçları kimse yeterince erken doğrulamamıştı.

Birbirine oturmayan ana veri

Ürün kodları, müşteri numaraları ve satıcı sınıflandırmaları küresel standartlarla eşleşmelidir. Canlıya geçişten sonra bulunan uyumsuzlukları düzeltmek pahalıdır ve konsolide raporlamayı bozar. Yerel veriyi küresel modele UAT'de değil, tasarım sırasında eşleyin.

Yerel sistemi değil, küresel sistemi anlatan eğitim

Rollout'lar çoğunlukla ilk implementasyondaki eğitimi yeniden kullanır. Bu materyal, sistemin merkezde nasıl çalıştığını anlatır. Yerel uyarlamaları anlatmaz. Kendi sürümlerinin neden farklı olduğunu anlamayan kullanıcılar geçici çözümler üretir.

Yukarıdaki çerçeve geçerliliğini korur. Şablonun dağıtım modeli, ekonominin bir kısmını ve uzantı kurallarını değiştirir.

RISE with SAP'de (Private Edition), her yeni ülke, tam kullanıcı eşdeğerleri (FUE) üzerinden fiyatlanan bir aboneliğe kullanıcı ekler. Maliyet öngörülebilir olur, altyapı işi azalır. Maliyet canlıya geçişten sonra da sürer; bu yüzden seçenekleri yalnızca ilk yıla değil, birkaç yıla yayarak karşılaştırın.

GROW with SAP'de (Public Edition), önce SAP'nin o ülke için yerel bir sürüm sunup sunmadığına bakın. SAP, Şubat 2024 itibarıyla 59 ülke ve bölge için yerel sürümler listelemişti. Diğer ülkeler için SAP'nin kendi kendine hizmet olarak yerelleştirme programı, iş ortaklarının Configuration Localization Tool ile müşteriye özel bir yerel sürüm geliştirmesine olanak tanıyor; bu yol şu anda erken benimseyenlere yönelik bir kanal üzerinden işliyor (SAP Learning). İkisi de geçerli değilse, ortada bir rollout değil, bir kapsam sorunu var.

Clean Core her yerel sapma için geçerlidir. Public Edition uzantıları yalnızca yayımlanmış arayüzler üzerinden kabul eder. Private Edition'da bu bir yönetişim tercihidir, ancak izin verdiğiniz her yerel değişiklik, her yükseltmede yeniden test edilecek bir nesne daha demektir ve bu, ülke sayısıyla çarpılır. Benim savunduğum disiplin basit: vergi yasaları, yasal raporlama ve düzenleyici zorunluluklar bir sapmayı haklı çıkarır. Yerel tercihler çıkarmaz.

Bir sonraki ülke için tarih vermeden önce bunların her birinde evet yanıtı alın. Her birinin bir sahibi var.

1. Yerel iş sahibi (yeni ülke): adı belli, yerel tasarımı onaylama yetkisi var.
2. Vergi ve hukuk danışmanı: vergi, yasal raporlama ve zorunlu veri alanları, tasarım başlamadan önce belgelenmiş.
3. Şablon sahibi (merkez): önerilen sapmaların listesi, her biri gereksinim ya da tercih olarak işaretlenmiş.
4. Veri lideri: yerel müşteri, satıcı ve malzeme verileri küresel standartlara eşlenmiş.
5. Entegrasyon lideri: bağlanması gereken yerel sistemler, örneğin bankalar, vergi beyanı ya da lojistik, belirlenmiş ve kapsamlandırılmış.
6. Değişim lideri: eğitim, yerel sürece uyarlanmış; yerel dilde ve yerel örneklerle hazırlanmış.
7. Program direktörü: her seferinde tek lokasyon; son canlıya geçişten çıkan dersler bir sonrakine aktarılıyor.

Kapsam şablonu rehberim 3. madde için işinize yarar, proje başlatma belgesi rehberim ise karar yetkilerinin nasıl yazıya dökülmesi gerektiğini ele alıyor.

Mısır'da sıfırdan bir implementasyon. Mısır merkezli bölgesel bir üretim şirketi, eski ve birbirinden kopuk sistemler ile çok sayıda elle yapılan işle sıkışıp kalmıştı. Tedarik zinciri, üretim takibi ve finansal raporlama birbiriyle konuşmuyordu. SAP S/4HANA'yı sıfırdan uygulayıp finans, satın alma ve üretimi tek bir sistemde bağladılar. Otomatik tedarik zinciri planlaması kurdular ve canlıya geçmeden önce dört ülkede 5.000'den fazla çalışanı eğittiler. Acele etmediler. Operasyonel maliyetleri yüzde 25, tahmin hatalarını yüzde 35 azalttılar.

15 pazara rollout. Bir perakende şirketinde SAP S/4HANA merkezde zaten çalışıyordu ve 15 yeni pazarda gerekiyordu. Her pazarın vergi kuralları, para birimleri ve iş uygulamaları farklıydı. Küresel bir şablonla başladılar, her lokasyon için uyarladılar, hepsini birden değil, iki yıla yayılan aşamalarla devreye aldılar ve her bölge için eğitim hazırladılar. Sonuç: daha hızlı finansal konsolidasyon, mağazalar genelinde gerçek zamanlı envanter takibi ve grup düzeyinde yüzde 20 daha doğru raporlama.

Biri var olmayan bir şeyi kuruyordu. Diğeri işleyen bir şeyi genişletiyordu. İkisi de tak-çalıştır değildi. İlk türün başındaysanız, SAP implementasyonuna doğru başlama rehberim başlangıç noktası olur.

SAP implementasyonu ile SAP rollout arasındaki fark nedir?

Implementasyon, SAP'yi sıfırdan kurar: gereksinimler, süreç tasarımı, yapılandırma, veri taşıma, entegrasyon, test ve canlıya geçiş. Rollout ise mevcut bir SAP sistemini ve küresel şablonunu yeni bir ülkeye, tüzel kişiye ya da iş birimine yaygınlaştırır. Rollout işi, şablon ile yerel ihtiyaçlar arasındaki farktır: vergi, yasal raporlama, dil, yerel entegrasyonlar ve eğitim.

Bir şirket ne zaman rollout yerine implementasyonu seçmeli?

Genişletilecek bir SAP yoksa ya da eski bir sistem bütünüyle değiştiriliyorsa implementasyonu seçin. İş modeli, mevcut tasarım artık uymayacak kadar değiştiyse ya da hiçbir şablon gereken kapsamı karşılamıyorsa da daha doğru yol budur. Yanlış şablonu rollout'la zorlamak, temiz bir tasarımdan daha fazla yeniden işe yol açar.

Bir SAP rollout'u, implementasyona kıyasla ne kadar sürer?

Bir implementasyon tipik olarak 12 ila 24 ay sürer, büyük gruplarda daha uzun. Rollout ise yerelleştirmeye, entegrasyonlara ve veriye bağlı olarak lokasyon başına tipik olarak 6 ila 12 ay sürer. En büyük değişken, yerel gereksinimlerin tasarım başlamadan önce ne kadar iyi doğrulandığıdır.

Çok ülkeli bir SAP rollout'unda en büyük zorluklar nelerdir?

Dört şey tekrar tekrar karşımıza çıkar. Yerel ekiplerin görüşü alınmadan onlara dayatılan şablonlar. Testte ortaya çıkan yerelleştirme gereksinimleri. Küresel standartlarla eşleşmeyen ana veri. Yerel sistemi değil, küresel sistemi anlatan eğitim. Bunların çoğu teknik değil, insan ve planlama sorunlarıdır.

SAP rollout'u her zaman tam bir implementasyondan ucuz mudur?

Genellikle evet, çünkü tasarım zaten var ve kanıtlanmış. Bir ülkede karmaşık vergi ya da bordro kuralları varsa, birkaç yerel entegrasyon gerekiyorsa ya da veri kalitesi düşükse tasarruf azalır. RISE with SAP'de her yeni ülkenin aboneliği canlıya geçişten sonra da sürer; bu yüzden maliyetleri birkaç yıla yayarak karşılaştırın.

Bir SAP rollout'unda küresel şablon nasıl işler?

Küresel şablon, grubun standart süreçleri için belgelenmiş ve yapılandırılmış SAP tasarımıdır. Her rollout ondan başlar ve yalnızca gerçekten gereken yerel değişiklikleri ekler. Her sapma, her yükseltmede bir bakım yükümlülüğü yaratır; bu yüzden onları yönetin: vergi yasası gibi gereksinimler bir sapmayı haklı çıkarır, tercihler çıkarmaz.