İçeriğe geç

FMCG ERP kurtarma: SAP Analytics Cloud ile birleşik raporlama

Singapur'daki bir FMCG grubu Oracle çalıştırıyordu; Birleşik Krallık'taki enerji içeceği işi ise SAP. Rakamlar hiçbir zaman tutmuyordu. Yönetişim, kapsam kontrolü ve SAP Analytics Cloud, tıkanmış bir raporlama projesini altı ayda nasıl döndürdü.

Oracle ve SAP verilerini bir araya getiren birleşik bir SAP Analytics Cloud gösterge panelini inceleyen FMCG finans ekibi
İçindekiler
  1. Kurulum neye benziyordu
  2. Neler ters gidiyordu
  3. İki ERP arasında raporlama
  4. Ay sonu konsolidasyonu
  5. Operasyonel raporlama
  6. Araç tartışması
  7. Kullanıcı direnci
  8. Müdahale: yönetişim, kapsam ve değişim yönetimi
  9. SAP Analytics Cloud tartışmayı neden kazandı
  10. Uygulamanın öne çıkanları
  11. Altıncı ayda iş sonuçları
  12. Çıkarılan dersler
  13. Bu çalışma 2026'da nasıl görünürdü
  14. 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ü.

Altı ayda ne değiştiYönetişim ve tanımlar araçtan önce geldi. Bu sıra, yapılan seçimler kadar önemliydi.
Kurtarmadan önceYeniden başlatmada
YönetişimKurtarmadan önceKalabalık yönlendirme grubu, ertelenen kararlarYeniden başlatmadaYalnızca gerçek karar vericiler, kararlar toplantıda
KapsamKurtarmadan önceTaleplerle dolu bir beyaz tahtaYeniden başlatmadaKararları yönlendiren raporlar
TanımlarKurtarmadan önceAynı etiket, her ERP'de farklı anlamYeniden başlatmadaÜzerinde anlaşılmış gelir, maliyet ve marj
RaporlamaKurtarmadan önceGünler süren Excel mutabakatıYeniden başlatmadaOracle ve SAP verisi SAP Analytics Cloud'da tek modelde
BenimsemeKurtarmadan önceSınıf eğitimi, sonra yine ExcelYeniden başlatmadaYerel şampiyonlar, her seferinde bir ekip

Tablo başlangıç durumunu ve her sorunun nasıl çözüldüğünü özetliyor.

ZorlukEtkiSAP Analytics Cloud ile çözüm
İki ERP: Singapur'da Oracle, Birleşik Krallık'ta SAPRakamlar hizalanmıyordu; mutabakat günler sürüyorduİkisi de tek bir raporlama modelini besledi
Sınır ötesi raporlama sahipliği belirsizAsya'daki strateji, Avrupa'daki operasyonel verilerle çatışıyorduStandart KPI'lar, her iki şirketin de aynı metrikleri raporlaması anlamına geliyordu
Yavaş gelir raporlamasıRakamlar kaynak sisteme göre farklıydı, kararlar gecikiyorduBirleşik planlama ve raporlama döngüyü kısalttı
Planlama uyumsuzluğuSingapur stratejiyi belirliyor; Birleşik Krallık farklı varsayımlarla uyguluyorduOrtak 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ştiEtki
Yönetişim sıfırlamaYönlendirme grubu gerçek karar vericilere indirildi; daha kısa ve keskin oturumlarKararlar toplantıda alındı; eskalasyonlar hızlı ilerledi
Kapsam kontrolüGereksinimler, kararları yönlendiren raporlamaya indirildiDaha az tartışma, daha net veri modelleri, daha az hareketli hedef
Uyarlanmış iletişimFinans, operasyon ve BT için ayrı güncellemelerHer ekip kendisi için neyin önemli olduğunu anladı; güven geri geldi
Yerel şampiyonlarResmî sınıflar yerine küçük gruplarda akran koçluğuBenimseme 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.

HataNeye yol açtıDers
Belirsiz yönetişimBitmeyen toplantılar, karar yok, artan gecikmelerRolleri ve karar haklarını erkenden sıfırlayın
Kapsam kaymasıRaporlama hedefleri sürekli değiştiKapsamı dar tutun ve kararlara bağlayın
Kullanıcıları göz ardı etmekKullanıcılar güvenini yitirdi ve benimseme yavaşladıKullanıcıları erkenden dahil edin ve bağlam verin
Aşırı özelleştirmeRaporları yeniden kurmakla zaman kaybedildiŞablonlarla ve standart konektörlerle başlayın; özelleştirmeyi sonra yapın
Zayıf değişim yönetimiEğitim hedefi ıskaladı; eski alışkanlıklar yerleştiYerel ş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.

Noel D'Costa

Yazar

Noel D'Costa

Havacılık, kamu, finans, perakende ve üretim sektörlerinde SAP ve Oracle ERP programlarında 25 yıl. Finans kökenliyim. Yönetim ekiplerinin dönüşümleri gerçekçi biçimde kapsamlandırmasına, sorunlu programları toparlamasına ve canlı ortamdaki ilk yılını sağlam atlatan sistemler kurmasına yardımcı oluyorum.

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.