Kaçınmanız gereken 10 ERP modernizasyonu hatası

En çok zarar veren ERP modernizasyonu hataları teknik değil, stratejiktir: canlıya geçişi bitiş çizgisi saymak, eski süreçleri yeni sisteme kopyalamak, veri ve değişiklik işine çok geç başlamak, her şeyi ERP'nin içine kurmak ve beş yıllık bir model olmadan lisans imzalamak. Nadiren anında görünürler. Canlıya geçişten sonra, vaat edilen verimlilik kazançları gelmediğinde ve geçici çözümler geri döndüğünde ortaya çıkarlar.

Bu yazı, bir S/4HANA ya da başka bir ERP modernizasyonunu planlayan veya kurtarmaya çalışan CIO'lara, CFO'lara ve program direktörlerine yönelik. Aşağıdaki her hata, pratikte neye benzediği ve çözümüyle birlikte geliyor; ardından tek sayfalık bir erken uyarı kontrol listesi ve 2026'daki SAP değişikliklerinin ne anlama geldiği var.

İyi finanse edilmiş, deneyimli ekipli ve tam kadro danışmanlı projelerin yine de hedefin altında kaldığını izledim. Neden nadiren sistemdir. Sahiplik, entegrasyon planlaması ve birbirine bağlı kararlar alan ekipler arasındaki iletişimdeki boşluklardır.

1. Canlıya geçişi bitiş çizgisi saymak

Sistem canlıya çıktığında birçok ekip ağır işin bittiğini varsayar. Gerçek baskı o zaman başlar: günlük operasyonlar, değişen gereksinimler ve gerçek kullanıcı davranışı tasarımı zorlar.

Yönlendirme komitesinin canlıya geçişten hemen sonra dağıldığı projeler gördüm. Altı ay sonra benimsenme yerinde sayıyor ve backlog'un sahibi yok.

Çözüm: canlıya geçiş sonrası için 6 ila 12 aylık, finanse edilmiş bir yönetişim dönemi öngörün. Yönlendirme komitesinin yetkisini uzatın. Yalnızca çalışma süresini değil, süreç benimsenmesini izleyin. Canlıya geçiş sonrası için adı konmuş sahiplerle kalite kapıları belirleyin.

2. Eski süreçleri yeniden düşünmeden taşımak

Onay zincirlerinin tamamının, ilgili kişilerin yarısının mevcut süreçle hiçbir ilgisi olmasa bile, tıpatıp eskisi gibi yeniden kurulduğunu gördüm. Adımların hâlâ gerekli olup olmadığını kimse sormamıştı. Sonuç, eski iş akışlarını çalıştıran modern bir ERP'ydi: zaten sahip olduklarının daha pahalı bir sürümü.

Bunun S/4HANA'daki hali: ECC'den olduğu gibi taşınan, artık var olmayan tablo yapıları üzerine kurulmuş özel toplu işler. Taşıma teknik olarak temiz. İş mantığı bozuk.

Çözüm: süreçleri yapım başlamadan önce yeniden tasarlayın. Operasyon, finans ve teslimat ekiplerini her iş akışında birlikte gezdirin ve her adımı sorgulayın.

Eski alan	Sıklıkla neyin ters gittiği	Onun yerine ne yapmalı
ECC'deki özel kod	Kullanılmayan özel kod S/4HANA'ya taşınıyor	Kullanım analizini ve SAP'nin özel kod kontrollerini çalıştırın; kullanılmayan kodu emekliye ayırın
Eski iş akışları	Artık otomasyon mümkünken onay akışları yeniden kuruluyor	İş sahipleriyle yeniden ele alın; standart Fiori uygulamalarını ya da SAP Build Process Automation'ı kullanın
Standart dışı ana veriler	Esnek eski kurulumlar S/4HANA doğrulamasında başarısız oluyor	Taşımadan önce temizleyin ve uyumlaştırın; uygun yerde SAP MDG ile
Eski tablolar üzerindeki raporlar	Doğrudan tablo erişimi S/4HANA'nın veri modeline uymuyor	CDS view'lar üzerinde yeniden kurun
Gizli elle geçici çözümler	Yan süreçler canlıya geçişten sonra geri dönüyor	Taşımadan önce süreç madenciliği kullanın ve boşlukları dijitalleştirin

3. Veri taşımaya çok geç başlamak

Kötü veriyi yeni bir ERP'ye taşımak, hiçbir şey atmadan eve taşınmak gibidir. Dağınıklık sizinle gelir ve yapılandırılmış bir sistemin içine girdikten sonra temizlemek daha zordur.

Bir keresinde, çekirdek bir veri kümesinin her biri kendi kodlama mantığına sahip beş farklı iş biriminden kayıt içerdiğini kimse yakalamadığı için başarısız olan bir canlıya geçiş gördüm. Teknik taşıma doğruydu. Veri kullanılabilir değildi. Raporlar bozuldu, kullanıcılar güvenini yitirdi ve canlı sistemde temizlik aylar sürdü.

Çözüm: veriyi, iş tarafının sorumlu olduğu bir iş akışı yapın. Yalnızca teknik danışmanlara değil, süreç sahiplerine de görev verin. Taşıma başlamadan önce neyin getirileceğine, arşivleneceğine ya da yeniden kurulacağına karar verin. Yükleme sırası için bir bağımlılık haritasıyla ve her yükleme için tanımlı bir geri alma planıyla en az iki tam deneme yüklemesi yapın. SAP veri taşımanın neden başarısız olduğunu anlatan yazım daha derine iniyor.

4. Değişiklik yönetimini yan görev saymak

Olağan hali: değişiklik yönetimi “zaten halledildi”; bu da birkaç slayt, bir demo ve canlıya geçişten önce tek bir eğitim oturumu demek.

İnsanlar değişimden hoşlanmadıkları için direnmez. Neden değiştiğini ya da bunun kendilerine nasıl yardım ettiğini kimse açıklamadığında direnirler. Kontrol listesini geçecek kadar sistemi izler, sonra hesap tablolarına geri dönerler.

Olağan tetikleyici takvim baskısıdır: zaman kazanmak için eğitim sıkıştırılır, kullanıcılar canlıya geçişte bunalır ve fazladan hypercare, kesilen eğitimden daha pahalıya gelir.

Çözüm: değişiklik yönetimine baştan kendi bütçesini, takvimini ve kıdemli bir sahibini verin. Rolleri erken eşleyin, yerel şampiyonlar bulun ve benimsenme KPI'larını teknik kilometre taşlarıyla birlikte izleyin. Değişiklik yönetimi planı rehberim yapıyı ortaya koyuyor.

5. Sağlayıcı yol haritalarına göre planlama yapmak

Entegrasyon stratejisini bir sağlayıcının gelecekteki sürümüne dayandıran, sonra bunun 12 ay ertelendiğini gören ekipler gördüm. Bu arada geçici çözümler kurmak zorunda kaldılar ve geçici çözümler kalıcı oldu.

Sağlayıcılar yol haritalarını geniş müşteri grupları için hazırlar. İşletmeniz bu tasarımın merkezinde nadiren yer alır.

Çözüm: yol haritasını bir girdi olarak ele alın. Bugün genel olarak kullanıma açık olana göre tasarlayın, yeni özellikleri üzerine plan yapmadan önce bir sandbox'ta test edin ve yol haritasındaki faydaları bütçe değil, ek kazanç olarak sayın.

6. Eski sistemler için kapatma planının olmaması

Bir keresinde, yılda iki kez rapor çekmesi gereken altı kullanıcı için eski bir sistemi ayakta tutmak üzere yılda altı haneli rakam ödeyen bir şirket gördüm. Kimse bir kapatma planı hazırlamamıştı.

Çözüm: kapatmayı ilk günden proje başlatma belgesine koyun; yalnızca BT değil, hukuk, uyumluluk ve veri yönetişimi de dahil olsun. Canlıya geçişten önce saklama sürelerini ve bir arşiv yaklaşımını kararlaştırın, eski sisteme giden her arayüzü eşleyip ayırın ve onu kapatma işini tek bir ekibe verin.

7. Entegrasyon karmaşıklığını hafife almak

Entegrasyon başarısız olduğunda iş tarafı bunu BT'den önce fark eder, çünkü iş akışları bir test sisteminde değil, üretimde süreç ortasında durur.

Yaygın örüntü: BT ve iş tarafı, entegrasyon gereksinimlerini diğerinin tanımladığını varsayar. İkisi de tanımlamamıştır. Boşluklar testte ortaya çıktığında, yeniden tasarım için zaman kalmamıştır.

Çözüm: entegrasyon tasarımına blueprint aşamasında başlayın. Her senaryoyu, middleware'i, eşlemeyi ve mesaj hacimlerini tanımlayın; arayüz başına gerçek zamanlı ile toplu işlem arasındaki farkı iş tarafıyla netleştirin. Canlıya geçişten önce SLA'sı olan bir arayüz sahibi belirleyin. Yeni SAP programları için middleware SAP Integration Suite'tir; SAP PI/PO ana akım bakımdan 2027 sonunda çıkıyor.

8. ERP'nin her şeyi halledebileceğini varsaymak

Ekiplerin, ServiceNow gibi harici sistemleri işin içine katmak istemedikleri için karmaşık hizmet iş akışlarını (BT talepleri, varlık istekleri, yükseltme yönlendirmesi) ERP'ye zorladığı projelerde çalıştım. Sonuç, her yerde özel alanlar, elle geçici çözümler ve hiçbir zaman uymayan bir sürece sıkışmış kullanıcılardı.

ERP; yapılandırılmış, işlem odaklı, finansal bir dayanağı olan süreçlerde iyidir. BT hizmet talepleri, iş akışı orkestrasyonu ve bilgi yönetimini ise özel platformlar daha iyi yapar.

Çözüm: ERP'de neyin kurulmayacağına bilinçli olarak karar verin. İstisnalar için SAP BTP üzerinde side-by-side uzantıları, işlem çekirdeğinin dışındaki orkestrasyon için ServiceNow ya da benzerini kullanın. SAP ve ServiceNow ile ERP modernizasyonu yazım bu ayrımı ele alıyor.

9. Uzun vadeli lisans maliyetini hafife almak

İkinci yılda lisans harcamasını ikiye katlayan bir ekip biliyorum, çünkü tek bir özellik için daha üst kademe bir lisansa ihtiyaçları vardı. İş senaryosu yalnızca canlıya geçiş maliyetini modellemişti.

ERP lisansları kullanıcı, modül, işlem ve API kullanımı için ücret alır; planlamış olsanız da olmasanız da maliyet işle birlikte ölçeklenir. SAP'de Digital Access modeli, üçüncü taraf sistemlerin oluşturduğu belgelerin, özgün ticari modelde olmayan lisans maliyeti taşıyabileceği anlamına gelir. RISE ve SAP GROW kapsamında, Full User Equivalent (FUE) sayıları benimsenmeyle birlikte büyür.

Çözüm: imzalamadan önce üç ila beş yıllık bir lisans modeli kurun. Rolleri lisans türleriyle eşleyin, FUE büyümesini gerçekçi bir benimsenme eğrisiyle modelleyin, harici sistemleri bağlamadan önce dolaylı erişimi anlayın ve canlıya geçişten sonra etkin olmayan kullanıcıları denetleyin.

10. ERP'yi bir BT projesi saymak

En yaygın ve en zararlı örüntü. Planlama BT'de başlar, BT tarafından yönetilir ve BT sorunlarını çözer.

Kâğıt üzerinde her kilometre taşına ulaşan, ama iş tarafı hâlâ hiçbir şeyin neden daha iyi hissettirmediğini soran ekipler gördüm. Bu genellikle ERP'nin dünün süreçleri için, tasarımda operasyon, finans ya da ticari liderler olmadan kurulduğu anlamına gelir.

Çözüm: ticari, finans ve operasyon liderlerini baştan yönlendirme komitesine alın. Proje başlatma belgesine yalnızca teknik kapsamı değil, stratejik uyumu da yazın. Tasarım başlamadan önce programın hedeflerini yönetim kurulu düzeyindeki sonuçlara karşı sınayın.

Bunu her yönlendirme komitesinde kullanın. Bir uyarı işareti varsa, adı konmuş sahip, ortadan kalkana kadar bu konuda rapor verir.

1. Başlatma belgesiSahiplik ve maliyetOperasyon ya da finans lideri yok, beş yıllık lisans modeli yok, emeklilik tarihi yok
2. BlueprintSüreç ve entegrasyon tasarımıBugünün süreci kopyalanmış, arayüzler hâlâ tasarlanmamış
3. İlk deneme yüklemesiVeriHenüz veri kalitesi raporu yok
4. Canlıya geçişSonrasında olanlarSonraki 12 ay için finanse edilmiş yönetişim yok

Hata	Erken uyarı işareti	Sahip
1. Canlıya geçiş bitiş çizgisi	Canlıya geçişten sonraki 12 ay için finanse edilmiş bir yönetişim planı yok	Sponsor
2. Kopyalanan eski süreçler	Tasarım atölyeleri “bugün nasıl yapıyoruz” ekranlarından başlıyor	Süreç sahipleri
3. Geç veri işi	İlk deneme yüklemesinden önce veri kalitesi raporu yok	Veri taşıma lideri
4. Yan görev olarak değişiklik yönetimi	Değişiklik planı bir eğitim takvimi	Değişiklik lideri
5. Yol haritası bağımlılığı	Bir tasarım kararı, henüz yayımlanmamış bir özelliği bekliyor	Çözüm mimarı
6. Kapatma yok	Başlatma belgesinde hiçbir eski sistem için emeklilik tarihi yok	PMO
7. Hafife alınan entegrasyon	Arayüzler blueprint sonunda tasarlanmamış	Entegrasyon lideri
8. Her şey için ERP	İşlem dışı iş akışları için özel nesneler	Kurumsal mimar
9. Lisanslama	İş senaryosunda beş yıllık lisans modeli yok	CFO
10. Yalnızca BT programı	Yönlendirme komitesinde operasyon ya da finans lideri yok	Sponsor

Dağıtım. Yeni SAP programları için varsayılan, SAP Cloud ERP Private üzerinde RISE with SAP ya da orta ölçekli şirketler için genel sürümde (SAP Cloud ERP) SAP GROW'dur. Yeni on-premise dağıtımlar nadirdir. ECC müşterileri, 2, 3 ve 7. hataları düzeltmek için kalan süreyi kısaltan 31 Aralık 2027'de biten ana akım bakımla karşı karşıya.

Clean Core. SAP artık uzantıları dört Clean Core seviyesinde derecelendiriyor: A'dan (yalnızca yayımlanmış API'ler; BTP üzerinde side-by-side ya da sistem içinde ABAP Cloud ile) D'ye (temiz değil). Genel sürüm yalnızca A seviyesine izin verir ve bu, 2. hatanın ardındaki konuşmayı zorunlu kılar. Özel sürüm hâlâ klasik uzantılara izin veriyor; dolayısıyla disiplin yönetişimden gelmek zorunda. Her yükseltmeyi bir projeye çeviren şey, klasik özel koddur. Clean Core stratejisi yazım daha ileri gidiyor.

Teslimat araçlarında yapay zeka. Joule artık SAP Cloud ALM'de ve SAP Activate Roadmap Viewer'da yer alıyor; SAP Build Code ise uzantı geliştirme için Joule'u kullanıyor. İş ortaklarına yapay zeka araçlarının ücret tarifelerine nasıl yansıdığını sorun. Yansımıyorsa, ya fiyat yüksektir ya da tasarruf onların marjına gidiyordur.

Yaşam döngüsü araçları. SAP Cloud ALM, bulut programları için yaşam döngüsü yönetim aracıdır. Solution Manager 7.2 ana akım bakımdan 2027 sonunda çıkıyor; dolayısıyla ikisini birden çalıştıran ortamların geçiş için bir plana ihtiyacı var.

On hata değişmedi. Yanlış yapmanın maliyeti değişti. Bir RISE programında Clean Core kararı, dağıtım modeli ve FUE modeli, program başlatmanın ilk haftalarında belirlenir. Bunları etkileme penceresi kısadır.

ERP modernizasyonu çabaları canlıya geçişten sonra neden hedefin altında kalır?

Çoğu ekip canlıya geçişe kadar plan yapar ve orada durur. Geliştirmelerin, geri bildirimin, süreç düzeltmelerinin ya da backlog'un sahibi yoktur. Yönlendirme komitesinin canlıya geçişte dağılması, sorunun en güvenilir işaretidir. İlk günden canlıya geçiş sonrası için 6 ila 12 aylık yönetişimi finanse edin.

Eski süreçleri yeni bir ERP'ye kopyalamanın riski nedir?

Yeni sistem eski verimsizlikleri daha yüksek maliyetle devralır. Özellikle S/4HANA taşımalarında, ECC tabloları için kurulmuş özel kod ve toplu işler çoğu zaman çalışmaz; dolayısıyla taşıma teknik olarak temiz olabilir, iş mantığı ise bozuk.

Kötü veri kalitesi bir ERP modernizasyonuna nasıl zarar verir?

Mükerrer tedarikçiler, tutarsız ana veriler, eski kodlar ve eksik kayıtlar, biri önce temizlemedikçe yeni sisteme taşınır. Raporlar bozulur, kullanıcılar rakamlara güvenmeyi bırakır ve canlı sistemde temizlik aylar sürer.

ERP projelerinde değişiklik yönetimi neden bu kadar sık hafife alınır?

Çünkü bir proje planında konfigürasyon kadar görünür değildir. Yöneticiler birkaç eğitim oturumunun yeterli olduğunu varsayar. Değişiklik yönetimi, insanları canlıya geçişten önce günlük işlerinde gerçekte neyin değişeceğine hazırlamaktır. Artık SAP'nin sahibi olduğu WalkMe gibi dijital benimsenme araçları uygulama içi rehberliğe yardımcı olur, ama nedenin açıklanmasının yerini tutmaz.

Eski sistemler ERP canlıya geçişinden yıllar sonra neden çalışmaya devam eder?

Çünkü kimse onları kapatmayı planlamadı. Herkes yeni ERP'yi canlıya almaya odaklanır; eski sistemler uyumluluk, referans ya da rahatlık için açık kalır. Kapatma işi ilk günden kapsamda olmalı, hukuk ve uyumluluk da dahil edilmeli.

RISE with SAP ve Clean Core bu hataları nasıl değiştirir?

Genel sürümde Clean Core kuralları derin özelleştirmeyi imkânsız kılar; bu da 2. hatanın ardındaki süreç konuşmasını zorunlu kılar. Özel sürümde klasik uzantılara hâlâ izin var; dolayısıyla Clean Core yönetişime bağlıdır. PI/PO bakımı sona ererken entegrasyon SAP Integration Suite'e taşınır. Lisanslama bir FUE büyümesi sorusu haline gelir. Eski sistemleri paralel çalıştırmak çok yıllı bir aboneliğin üstüne maliyet bindirdiği için kapatma daha acil hale gelir.