
İçindekiler
- Kurulum neye benziyordu
- Neler ters gidiyordu
- İki ERP arasında raporlama
- Ay sonu konsolidasyonu
- Operasyonel raporlama
- Araç tartışması
- Kullanıcı direnci
- Müdahale: yönetişim, kapsam ve değişim yönetimi
- SAP Analytics Cloud tartışmayı neden kazandı
- Uygulamanın öne çıkanları
- Altıncı ayda iş sonuçları
- Çıkarılan dersler
- Bu çalışma 2026'da nasıl görünürdü
- Sık sorulan sorular
Bu vaka çalışması, birden fazla ERP çalıştıran ve tek bir rakam seti elde edemeyen CFO'lar ve BT liderleri için. Kısa özet: Singapur'daki Oracle ile Birleşik Krallık'taki SAP arasında tıkanmış sınır ötesi bir raporlama projesi altı ayda toparlandı. Bunu beş şey yaptı. Gerçek yetkiye sahip daha küçük bir yönlendirme grubu. Kapsamın, kararları yönlendiren raporlara indirilmesi. İki sistem arasında üzerinde anlaşılan tanımlar. Tek raporlama katmanı olarak SAP Analytics Cloud. Ve sınıf eğitimi yerine yerel şampiyonlar. Aynı durumdaysanız, araç tartışmasıyla değil yönetişim ve tanımlarla başlayın.
Hikâye, merkezi Singapur'da olan tanınmış bir FMCG grubunda tıkanmış bir ERP analitik projesiyle başlıyor. Grubun, Birleşik Krallık'taki bir enerji içeceği işinde %26 payı vardı. Azınlık payına rağmen yönetim kontrolü Singapur'daydı; dolayısıyla Asya'daki yönetim kurulu stratejisi Avrupa'daki günlük raporlamayı ve planlamayı şekillendiriyordu.
Teknoloji işi zorlaştırıyordu. Singapur Oracle ERP çalıştırıyordu. Birleşik Krallık SAP ERP. Her biri kendi başına çalışıyordu ve birlikte, zaten aylarca emek tüketmiş bir raporlama sorunu yaratıyorlardı.
Rakamlar nadiren tutuyordu. Mutabakatlar günlerce sürüyordu. En temel gelir raporlaması bile hangi sisteme baktığınıza göre farklı çıkıyordu.
Kurtarma çalışmasından sonraki altı ay içinde, başarısız bir girişim gibi görünen şey, finansın ve operasyonun birlikte güvendiği sınır ötesi bir raporlama modeline dönüştü.
Tablo başlangıç durumunu ve her sorunun nasıl çözüldüğünü özetliyor.
| Zorluk | Etki | SAP Analytics Cloud ile çözüm |
|---|---|---|
| İki ERP: Singapur'da Oracle, Birleşik Krallık'ta SAP | Rakamlar hizalanmıyordu; mutabakat günler sürüyordu | İkisi de tek bir raporlama modelini besledi |
| Sınır ötesi raporlama sahipliği belirsiz | Asya'daki strateji, Avrupa'daki operasyonel verilerle çatışıyordu | Standart KPI'lar, her iki şirketin de aynı metrikleri raporlaması anlamına geliyordu |
| Yavaş gelir raporlaması | Rakamlar kaynak sisteme göre farklıydı, kararlar gecikiyordu | Birleşik planlama ve raporlama döngüyü kısalttı |
| Planlama uyumsuzluğu | Singapur stratejiyi belirliyor; Birleşik Krallık farklı varsayımlarla uyguluyordu | Ortak planlama modelleri iki işi hizaladı |
İki ERP arasında raporlama
Singapur'da Oracle, Birleşik Krallık'ta SAP olunca raporlama, iki ayrı işi yönetmek gibi hissettiriyordu. Finans aynı metriği iki sistemden çekiyor ve farklı yanıtlar alıyordu. Bir aylık değerlendirmede Singapur bir gelir rakamı sundu ve Birleşik Krallık hemen başka bir rakamla itiraz etti. Tartışma, toplantıdan uzun sürdü.
İnsanlar Excel'e dönüyordu, çünkü daha güvenli hissettiriyordu: saatlerce dışa aktarma, mutabakat ve kendi doğruluk sürümlerini kurma. Kısa vadede işe yarıyordu ve grup raporlamasında kronik gecikmeler yaratıyordu. CFO'ların neden hâlâ Excel'e uzandığına dair yazım bu örüntüyü daha geniş ele alıyor.
Ay sonu konsolidasyonu
Ay sonu en zor kısımdı. Bir ERP'de “operasyon” altında duran bir maliyet, bazen diğerinde “idari” altına düşüyordu. Aynı giderin farklı başlıklar altında iki kez göründüğü bir konsolidasyon taslağı gördüm. Bu, rakamlara güveni öldürdü. Geç sonuçlar norm haline geldi ve grup yayımladığında genellikle revizyonlar izliyordu.
Operasyonel raporlama
Sorunlar finansın ötesine geçiyordu. Oracle sevkiyatları izliyor, SAP stoku izliyordu ve tek bir kaynak yoktu. Bir depo müdürü bana bir haftada üç farklı stok raporu aldığını, hepsinin bakiyelerinin farklı olduğunu söyledi. Söylerken güldü, ama bu gerçek kararları yavaşlatıyordu. İkmal geride kalıyor, sevkiyat gecikmelerini açıklamak da zorlaşıyordu, çünkü operasyon gösterge panellerine güvenmiyordu.
Araç tartışması
Bir raporlama aracı seçmek başlı başına bir projeye dönüştü. Bazı yöneticiler Power BI'ın maliyet profilini beğeniyordu; diğerleri daha uzun yol haritası nedeniyle SAP'yi savundu. Zamanın yarısının raporlama ihtiyaçları yerine “neden Power BI değil de SAC” sorusuna gittiği bir çalıştaya katıldım. Tartışma aylarca sürdü ve ivmeyi tüketti.
Kullanıcı direnci
İlk gösterge panelleri yayına girdikten sonra bile benimseme düşük kaldı. Bir finans toplantısında birinin bir gösterge panelini açıp göz gezdirdiğini, kapattığını ve Excel dosyasına döndüğünü izlediğimi hatırlıyorum. Kimse sorgulamadı. İnsanlar bildiklerine güveniyordu ve gösterge panelleri bu güveni henüz kazanmamıştı.
Yönetişimi sıfırlamak. Toplantılar bitmez gibi geliyordu ve insanlar kararı kimin verdiğinden emin olmadan ayrılıyordu. Liderlik, yönlendirme grubunu gerçek karar vericilere indirdi. Oturumlar kısaldı ve kararlılaştı; eskalasyonlar doğru kişilere hızla ulaştı. Mükemmel değildi, ama işler hareket etmeye başladı. SAP yönlendirme komitesi yürütme rehberim aynı ilkeleri ortaya koyuyor.
Kapsamı kontrol altına almak. İnsanlar grup görünümüne hangi rakamların ait olduğu konusunda sürekli tartışıyordu ve gereksinim listesi yönetilemez hale gelmişti. Baştan sona taleplerle kaplı bir çalıştay beyaz tahtasını hatırlıyorum; yarısı gerçek bir kararla ilgisizdi. İşe yarayan çerçeve şuydu: raporlama yalnızca kararları yönlendiren şeyi kapsamalı. Bu üzerinde anlaşılınca teslimat hızlandı.
İlgili hissettiren iletişim. Önceki güncellemeler geneldi; bu yüzden finans, operasyon ve BT her biri farklı bir yorumla ayrıldı. Uyarlanmış güncellemelere geçtik: finans için raporlama takvimleri, operasyon için lojistik süreç değişiklikleri, BT için teknik bir yol haritası. İnsanlar daha iyi sorular sormaya başladı, çünkü güncellemeler kendi dillerini konuşuyordu.
Yerel şampiyonlar. Tek başına eğitim işe yaramamıştı: insanlar oturumlara katılıp ertesi sabah Excel'e dönüyordu. Değişim, ekiplerinde zaten itibarı olan meslektaşlar olan yerel şampiyonlardan geldi; gösterge panellerini kendi sözleriyle, gayriresmî biçimde açıklıyorlardı. O oturumlardan birine katıldım ve fark çarpıcıydı. İnsanlar bir sınıfta asla sormayacakları soruları sordu. Benimseme her seferinde bir ekip olarak iyileşti.
Tablo neyin değiştiğini ve neden işe yaradığını özetliyor.
| Odak alanı | Ne değişti | Etki |
|---|---|---|
| Yönetişim sıfırlama | Yönlendirme grubu gerçek karar vericilere indirildi; daha kısa ve keskin oturumlar | Kararlar toplantıda alındı; eskalasyonlar hızlı ilerledi |
| Kapsam kontrolü | Gereksinimler, kararları yönlendiren raporlamaya indirildi | Daha az tartışma, daha net veri modelleri, daha az hareketli hedef |
| Uyarlanmış iletişim | Finans, operasyon ve BT için ayrı güncellemeler | Her ekip kendisi için neyin önemli olduğunu anladı; güven geri geldi |
| Yerel şampiyonlar | Resmî sınıflar yerine küçük gruplarda akran koçluğu | Benimseme ekip ekip iyileşti; Excel bağımlılığı azaldı |
Araç seçimi sonunda tamamlandığında SAC kazandı; kısmen Oracle ve SAP verisini ağır özel çalışma olmadan tek bir modele getirebildiği için. Bu, tartışmanın hararetini biraz düşürdü. Raporlar değişiklikleri eski dışa aktarma döngüsünden çok daha hızlı yansıttı. Bir finansal kontrolör, gününe başlamak için gece veri yenilemesini beklemek zorunda kalmadığı ilk seferin bu olduğunu söyledi.
Finans müdürü Oracle verisini ve SAP verisini tek bir gösterge panelinde yan yana ilk gördüğünde üzerinden bir yük kalktı. O an tartışmayı kapattı.
SAC yalnızca finansı değil, daha fazlasını da kapsadı. Operasyon lojistik ve depolama için bir görünüm istiyordu, İK iş gücü planlaması. Planlamanın, raporlamanın ve görselleştirmenin tek platformda olması, taktik bir çözümle daha uzun vadeli bir temel arasındaki farkı yarattı. Hazır şablonlar, bazıları genel bulunsa da ekibe bir ön start verdi ve o ilk teslimatın hızı, aylarca süren gecikmenin ardından güveni geri kazandırdı.
Bu tasarımı kopyalamayı planlıyorsanız bir teknik nokta. SAC canlı veri bağlantıları, SAP HANA, BW, S/4HANA, gömülü BPC, BusinessObjects evrenleri ve SAP Datasphere gibi SAP kaynaklarıyla sınırlıdır. Oracle ERP gibi SAP dışı veri genellikle bir içe aktarma bağlantısı, bir evren ya da aradaki bir veri katmanı üzerinden gelir. Bu mimariyi erkenden belirleyin, çünkü her iki tarafın rakamlarının ne kadar taze olabileceğini bu belirler.
Finans müdürü, tek bir gösterge panelinde Oracle verisini ve SAP verisini yan yana ilk gördüğünde üzerinden bir yük kalktı. O an, tüm projenin beklediği kanıt noktasıydı.
İlk kilometre taşı veri modeliydi. Oracle ve SAP'nin ikisi de tek bir yapıyı beslemek zorundaydı; bu göründüğünden zordu. Alanlar aynı etiketi taşıyordu ama her sistemde farklı anlama geliyordu. Finans, gelirin, maliyetin ve marjın gerçekte ne demek olduğunda anlaşana kadar tanımları eşlemek haftalar aldı.
Gösterge panelleri adım adım yayına alındı. Önce finans, sonra satış ve operasyon; her biri gerçek işleri etrafında kurulmuş raporlarla. İlk sürümler fazla katı geldi. Kullanıcılar bunu söyledi ve haklıydılar. Gösterge panelleri iyileşti ve üzerinde anlaşılan KPI'lar, sürekli aylık tartışmaların yerini aldı.
Yeniden başlatma altı ay içinde tamamlandı. İlk kez Oracle ve SAP verisi SAC içinde tek bir modeldeydi. Mutabakat tartışmaları azaldı ve yöneticiler Excel dosyalarının dolaşmasını beklemeden rakamları gözden geçirdi.
Haftalar süren planlama döngüleri günler sürdü. Planlamacılar senaryoları modelleyip gerçekleşenlerle karşılaştırabildi. Bazı yöneticiler gösterge panellerinin verdiğinden daha fazla ayrıntı istedi, ama rakamlara güvenmeleri bile başlı başına anlamlıydı.
Bir depo müdürü, ilk kez raporundaki stok seviyelerinin finansın gösterdiğiyle örtüştüğünü söyledi. Departmanlar arasındaki bu sessiz uyum gerçek göstergeydi. Kimse eski sürece geri dönmeyi istemedi.
Tablo, projeyi tıkayan hataları ve her birinden çıkan dersi listeliyor.
| Hata | Neye yol açtı | Ders |
|---|---|---|
| Belirsiz yönetişim | Bitmeyen toplantılar, karar yok, artan gecikmeler | Rolleri ve karar haklarını erkenden sıfırlayın |
| Kapsam kayması | Raporlama hedefleri sürekli değişti | Kapsamı dar tutun ve kararlara bağlayın |
| Kullanıcıları göz ardı etmek | Kullanıcılar güvenini yitirdi ve benimseme yavaşladı | Kullanıcıları erkenden dahil edin ve bağlam verin |
| Aşırı özelleştirme | Raporları yeniden kurmakla zaman kaybedildi | Şablonlarla ve standart konektörlerle başlayın; özelleştirmeyi sonra yapın |
| Zayıf değişim yönetimi | Eğitim hedefi ıskaladı; eski alışkanlıklar yerleşti | Yerel şampiyonları ve akran koçluğunu erkenden devreye alın |
Üç ders diğerlerinin üstünde duruyor. Yönetişim araçtan daha önemli: çok ERP'li bir yapıda net sahiplik olmadan, platform ne olursa olsun raporlama dağılır. Veri tanımlarını araç seçiminden önce hizalayın: Power BI'a karşı SAC tartışması konuyu kaçırıyordu, çünkü hiçbir araç birbirini tutmayan tanımları düzeltmez. Ve değişim yönetimi benimsemeyi belirler: şampiyonlar ve hedefli iletişim olmasaydı gösterge panelleri kullanılmadan kalırdı.
Aynı iş şimdi başlasaydı üç şey değişirdi.
SAC ile kaynaklar arasında bir veri katmanı olurdu. Artık SAP Business Data Cloud'un parçası olan SAP Datasphere, üstünde anlamsal bir model bulunan SAP ve SAP dışı kaynaklara birleşik (federated) erişim sağlıyor. Bunun gibi iki ERP'li bir vakada, Oracle ve SAP verisini her SAC story'sinin içinde yapmaktansa o katmanda uyumlaştırmak daha temiz. Ayrıca SAC'a, uyumlaştırılmış modele canlı bağlantı sağlıyor.
Doğal dil soruları bazı gösterge paneli yapımlarının yerini alırdı. SAC'ın doğal dil sorgusu ve Joule, finans ekiplerinin örneğin çeyrek için bölgeye göre geliri, Singapur'a karşı Birleşik Krallık olarak istemesine izin veriyor. Önce bir story kurulması gerekmiyor. Veri uyumlaştırıldıktan sonra işi hızlandırır. Tanım boşluğunu kapatmaz.
Ticari konuşma ERP sözleşmesinden başlardı. SAC'ı müzakere etmeden önce bulut ERP sözleşmenizin hangi analitiği zaten içerdiğini kontrol edin. Tam SAC planlaması ayrı lisanslanır ve bir şirketi bulut ERP'de, diğeri değil olan hibrit ortamlar da dikkatli lisanslama gerektirir.
Yönetişim sıfırlaması, kapsam disiplini, yerel şampiyonlar ve uyarlanmış iletişim değişmezdi. Bu örüntüler teknoloji ne olursa olsun geçerli. İki ERP'yi aynı rakamları raporlamaya ikna etmenin insani işi otomatikleşmez. SAC'ın kendisi hakkında daha fazlası için SAP Analytics Cloud rehberime bakın.
Bu FMCG grubunun ERP raporlama projesi neden tıkandı?
Singapur Oracle, Birleşik Krallık SAP çalıştırıyordu ve finans her ay rakamları elle birleştiriyordu. Günler sürüyordu ve sonuca kimse tam güvenmiyordu. Singapur bir rakam sunup Birleşik Krallık başka bir rakamla itiraz ettiğinde değerlendirmeler tıkanıyordu. Yönlendirme grubu da çok büyüktü, bu yüzden kimse karar vermiyordu. Maliyetler arttı, güven düştü ve proje sürüklendi.
Kurtarmanın yönünü ne değiştirdi?
Liderlik projenin takıldığını kabul etti ve bir kurtarma planı üzerinde anlaştı. Yönlendirme grubu küçük bir gerçek karar verici grubuna indirildi, öncelikler belirlendi, tek raporlama aracı olarak SAP Analytics Cloud seçildi ve iletişim hedef kitleye özel hale geldi. Toplantılar suçlamadan sonraki adıma kaydı ve insanlar projenin teslim edebileceğine inanmaya başladı.
SAP Analytics Cloud hem Oracle'ı hem SAP'yi nasıl ele aldı?
SAC, Oracle ve SAP verisini tek bir raporlama modeline getirdi; böylece ikisi de manuel mutabakat dosyaları olmadan tek bir gösterge panelinde yan yana göründü. İki sistemi tek görünümde görmek, araç tartışmasını bitiren andı. SAC'ın canlı bağlantılarının yalnızca SAP kaynaklarını desteklediğini unutmayın; Oracle verisi genellikle bir içe aktarma bağlantısı, bir BusinessObjects evreni ya da SAP Datasphere gibi bir veri katmanı üzerinden gelir.
Kullanıcılar gösterge panellerine başta neden direndi?
Gösterge panelleri yeterli iş bağlamı olmadan yayına girdi. Kullanıcılara SAC'ı kullanmaları söylendi ama günlük işlerine nasıl uygulandığını kimse göstermedi ve eğitim geneldi. İnsanlar bildiklerine güvenir ve gösterge panelleri bu güveni henüz kazanmamıştı. Gösterge panellerini kendi sözleriyle anlatan yerel şampiyonlar bunu değiştirdi.
Başarılı bir ERP raporlama kurtarması neye benzer?
Nadiren tek bir şeydir. Burada yönetişim sıfırlaması, kapsam daraltma, üzerinde anlaşılan tanımlar, uyarlanmış iletişim ve akran şampiyonlarının birlikte çalışmasıydı. SAC, iki ERP'yi ağır özel çalışma olmadan tek modele getirdiği için yardımcı oldu, ama teknoloji tek başına projeyi kurtarmazdı. Altı ay sonra, çökmesini bekleyen insanlar kendi kurdukları gösterge panellerini sunuyordu.
Sonraki adım
Şu anda bir ERP programı mı yürütüyorsunuz?
Bu makale şu anda içinde olduğunuz bir programa dokunduysa, 30 dakikalık bir görüşme genellikle bir hafta daha süren iç analizden daha fazla yol aldırır.




