Modernizacija ERP-a u 2026.: cloud, AI i clean core

Modernizacija ERP-a u 2026. znači tri odluke donesene redom: što bi vaš ERP trebao prestati raditi, koliko ćete čistom držati njegovu jezgru i jesu li vaši podaci dovoljno dobri da AI bude koristan. Za SAP kupce iza sve tri stoji tvrd datum: standardno održavanje ECC-a završava 31. prosinca 2027., uz plaćeno produljeno održavanje do kraja 2030.

Ovo je za CIO-e, financijske direktore i enterprise arhitekte koji su završili analizu i sada moraju izvoditi. Obuhvaća sile koje pokreću akciju, arhitekturu okosnice i satelita, clean core, prazninu u upravljanju, spremnost za AI i tablicu rizika za idućih 18 mjeseci.

Godine 2024. većina rukovoditelja još je kupovala vrijeme: proučavali su rokove za ECC, raspravljali o hibridnoj naspram potpune migracije, izvodili testove u sandboxu bez obveze. Taj je prozor zatvoren. Tehnički dug u ECC i Oracle E-Business Suite okruženjima više nije teorijski. Vidi se u neuspjelim regresijskim testovima nakon ažuriranja, u revizorskim nalazima o prilagođenom kodu koji nitko ne posjeduje i u podacima kojima treba 12 sati da se premjeste između sustava za planiranje i izvršenje.

Rok. Nakon 2027. ECC kupci mogu kupiti produljeno održavanje do kraja 2030. uz višu naknadu. Nakon toga SAP nudi opciju prijelaza za ERP private edition za razdoblje od 2031. do 2033., ali samo kroz RISE, a SAP je izričit da je to plaćena ponuda prijelaza, a ne produljenje održavanja. U međuvremenu je Gartnerovo istraživanje koje je prenio The Register utvrdilo da je do kraja 2024. tek oko 39 % od otprilike 35.000 SAP-ovih ECC kupaca kupilo ili pretplatilo S/4HANA licence. Licencirano nije isto što i migrirano. Tržište partnera bit će napeto.

Model proračuna. Cloud ERP premješta potrošnju s capex licenci na pretplate. To zvuči čišće. U praksi financijski direktori nalaze da su cloud troškovi manje predvidljivi: pod RISE with SAP i SAP GROW rast Full User Equivalenta (FUE), dodatne usluge i režijski troškovi integracije dodaju troškove kojih nije bilo u izvornom poslovnom slučaju.

Fragmentacija u financijama i opskrbnom lancu. Financijski timovi pokreću AI nad obvezama i potraživanjima, dok revizijski procesi i dalje koriste predloške izgrađene za drugo doba. Opskrbni lanci djelomično su modernizirani: SAP IBP za planiranje, stariji sustav za upravljanje skladištem za izvršenje, Ariba za nabavu, ali ručni prijem robe. Usko grlo nije tehnologija. To su spojevi među sustavima.

ERP je jedan sloj, a ne cijeli stog. ServiceNow u mnogim poduzećima vodi orkestraciju procesa, Salesforce vodi korisničke tijekove rada, Workday ili SuccessFactors vodi životni ciklus kadrova. ERP je postao financijska okosnica, a ne sveobuhvatno procesno središte kakvim su ga prodavali 1990-ih.

Model s kojim danas radi većina enterprise arhitekata jest financijska okosnica (SAP S/4HANA ili Oracle Fusion) okružena specijaliziranim platformama.

Sloj	Što je ovdje	Što nije
Financijska okosnica	Glavna knjiga, kontroling, nabava, zalihe, izvršenje proizvodnje, zakonsko zatvaranje	Odobrenja tijekova rada, CRM, upravljanje radnom snagom, analitika
Tijek rada	ServiceNow za IT i operativne procese, odobrenja, upravljanje promjenama	Vođenje transakcijskih zapisa
Angažman kupaca	Salesforce ili SAP Sales and Service Cloud	Financijska obrada
Radna snaga	Workday ili SAP SuccessFactors	Operativne transakcije
Analitika	SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake	Sustav zapisa (system of record)

Razdvajanje je namjerno. Vraćanje svega natrag u SAP dodaje trenje, usporava ažuriranja i zamućuje vlasništvo. Natrpavanje CRM-a, tijeka rada, analitike i EHS-a u jedan sustav učinilo je ranije programe tako bolnima.

Pitanje koje treba postaviti: za što ERP više ne bi trebao biti odgovoran? Preskočite ga i ponovno gradite isti monolit na novijoj licenci. Moj tekst o modernizaciji ERP-a uz SAP i ServiceNow razrađuje jednu verziju te podjele.

U kolovozu 2025. SAP je troslojni model proširivosti zamijenio četirima razinama clean corea. Razina A koristi samo objavljene, stabilne API-je, side by side na SAP BTP-u ili unutar sustava uz ABAP Cloud. Razina B koristi klasične API-je i tehnologije koje SAP još smatra čistima. Razina C zadire u interne objekte i traži posebne mjere. Razina D nije clean.

Public edition (SAP Cloud ERP, koji se prodaje kao SAP GROW) dopušta samo razinu A, pa platforma provodi clean core i apsorbira dva velika izdanja godišnje. Private edition (SAP Cloud ERP Private, pod RISE-om) i on-premise i dalje dopuštaju klasična proširenja, pa tamo clean core ovisi o upravljanju. U oba slučaja jako prilagođen sustav svaki upgrade pretvara u projekt, a svaki regresijski test u krizu.

Što clean core traži od vas:

1. Izvadite neiskorišteni prilagođeni kod iz jezgre. Svaki prilagođeni program koji zadržite nešto je što treba testirati pri svakom upgradeu.
2. Nova proširenja gradite na razini A gdje možete: na SAP BTP-u, uz SAP Build ili unutar sustava uz ABAP Cloud.
3. Koristite standardne procese gdje god ih SAP isporučuje, a prilagođavajte samo ondje gdje to traži regulativa ili stvarna konkurentska razlika.

Otpor je kulturni, a ne tehnički. Poslovni voditelji koji su se 15 godina oslanjali na prilagođeni kod i dalje očekuju da će se on „jednostavno ponovno implementirati“. To očekivanje pripada 2012.

Tipično ECC okruženje sadrži 1.500 do 3.000 prilagođenih objekata, prema procjenama koje sam provodio u proizvodnji i uslugama, a samo oko četvrtine pokazuje aktivnu poslovnu upotrebu. Ostalo je povijesni balast koji napuhuje trošak migracije i stvara revizijsku izloženost.

Praktičan potez: pokrenite sada skeniranje korištenja. Ukinite ono što je neaktivno. Objavite popis za rezanje prije početka dizajna. Timovi koji planiraju clean core od prvog tjedna imaju daleko bolja iskustva s upgradeima od timova koji ga tretiraju kao ograničenje koje treba zaobići. Moj članak o strategiji clean corea detaljno opisuje metodu.

S ERP-om kao jednim slojem među mnogima pitanja vlasništva postaju presudna. Tko je vlasnik:

1. API-ja između Salesforcea i ERP-a?
2. Tijeka rada koji prelazi preko SAP-a i ServiceNowa?
3. Sukobljenih prioriteta promjena kad oba sustava istodobno trebaju ažuriranja?

Vidio sam da to odgađa go-liveove za mjesece. Timovi ne shvaćaju da su zapeli dok integracijsko testiranje ne razotkrije preklapanje.

U jednom slučaju pet je sustava dodirivalo isti matični zapis dobavljača. Pet. Nitko nije imao dokument o vlasništvu nad matičnim podacima i nitko nije osmislio tko što smije mijenjati, u kojem sustavu. To nije tehnološki neuspjeh. To je neuspjeh upravljanja koji je tehnologija razotkrila.

Vrijednost AI-ja u ERP-u je stvarna, ali ovisi o kvaliteti podataka i čistoj arhitekturi. Joule sada obuhvaća S/4HANA, SuccessFactors, Ariba i druge SAP proizvode, a SAP-ovi agenti rade pod Joule asistentima. Agentni slučajevi uporabe na SAP BTP-u se isporučuju, nisu slideware. Svi ovise o čistim, dosljednim, strukturiranim podacima.

Ako su vaši podaci dupli, nedosljedno kodirani ili leže u prilagođenim tablicama koje S/4HANA ne prepoznaje, AI nema ničega pouzdanog za rad. Financijski timovi koji pokreću AI nad obvezama to brzo otkriju kad se računi sparuju s krivim dobavljačem jer matični podaci dobavljača nikad nisu očišćeni.

Slijed koji funkcionira: najprije clean core, drugo upravljanje podacima, treće analitika, četvrto AI. Preskakanje koraka ništa ne ubrzava. Problem se samo premješta na kasnije.

1. 01Postavite granicuOdlučite što ERP treba prestati raditi
2. 02Očistite jezgruUkinite neiskorišteni kod, nova proširenja gradite na razini A
3. 03Uvedite upravljanje podacimaJedan vlasnik po objektu podataka
4. 04Izgradite analitikuSAP Business Data Cloud, SAC ili Power BI nad uređenim podacima
5. 05Dodajte AIJoule i agenti na pouzdanoj osnovi

AI s nečim pouzdanim za rad

Rizik	Signal	Praktičan odgovor
Pritisak roka za ECC	Standardno održavanje završava u prosincu 2027.; većina ECC kupaca do kraja 2024. nije licencirala S/4HANA	Zaključajte planove resursa partnera sada; senior dnevne cijene u SAD-u već iznose 1.800 do 3.500 USD
Dug prilagođenog koda	1.500 do 3.000 prilagođenih objekata, oko četvrtine u aktivnoj upotrebi	Pokrenite skeniranja korištenja, objavite popis za rezanje, započnite sprintove ukidanja
Poremećaji izdanja	Izdanja se sudaraju sa zatvaranjem financija i vrhuncima opskrbnog lanca	Postavite prozore izdanja podalje od zatvaranja; automatizirajte regresijske testove
Rizik migracije podataka	Kasno usklađivanje stvara greške koje timovi pogrešno označe kao bugove	Rano dimenzioniranje; provjere bankovnih, poreznih i podataka o usklađenosti prije zamrzavanja dizajna
Praznine u vlasništvu integracija	Pet ili više sustava koji dodiruju zajedničke matične podatke	Objavite matricu ovlasti; jedan vlasnik po objektu podataka
Dva alata za životni ciklus	Hibridna okruženja paralelno koriste Solution Manager i SAP Cloud ALM	Cloud ALM kao zadani za cloud programe; standardno održavanje Solution Managera 7.2 završava krajem 2027.

Za verziju ovih rizika na razini isporuke pogledajte deset pogrešaka u modernizaciji ERP-a koje treba izbjegavati, a za same putove migracije vodič za migraciju s ECC-a na S/4HANA.

Što je clean core u SAP S/4HANA?

Držati S/4HANA što bliže standardu i smještati proširenja ondje gdje ih upgradei ne mogu slomiti. Od kolovoza 2025. SAP ocjenjuje proširenja od razine A (samo objavljeni API-ji, na SAP BTP-u ili unutar sustava uz ABAP Cloud) do razine D (nije clean). Poslovni je razlog zaštita upgradea: čist sustav apsorbira izdanja za nekoliko dana, a jako prilagođen svako pretvara u projekt.

Što je arhitektura okosnica plus sateliti za ERP?

ERP (SAP S/4HANA ili Oracle Fusion) radi ono za što je izgrađen: financijske zapise, zalihe, nabavu, proizvodne transakcije i zakonsko izvještavanje. Specijalizirane platforme rade ostalo: ServiceNow tijek rada, Salesforce angažman kupaca, Workday ili SuccessFactors kadrovske poslove, a analitičke platforme uvide. Guranje svega toga u ERP stvara monolit koji se sporo ažurira i jako prilagođava.

Kako bi tvrtke trebale pristupiti roku za SAP ECC 2027.?

Počnite sa SAP Readiness Checkom. On otkriva količinu prilagođenog koda, ovisnosti o dodacima i dimenzioniranje podataka, tri čimbenika koji odlučuju hoćete li ići brownfield, greenfield ili selektivno. Složene enterprise migracije obično traju 18 do 24 mjeseca od procjene do go-livea, pa ako do sada niste odabrali pristup i započeli razgovore s partnerima, go-live 2027. već je tijesan. Produljeno održavanje do 2030. košta više i kupuje vrijeme, a ne inovaciju.

Kada je AI vrijedan u modernizaciji ERP-a, a kada nije?

Kad su podaci čisti, dosljedni i strukturirani, a proces ima jasna pravila: automatizacija obveza, prognoziranje potražnje i detekcija anomalija u financijskim transakcijama dokazani su slučajevi. AI nije prečac mimo loših podataka ili praznina u upravljanju. Odluke donesene na lošim ulaznim podacima teže je uhvatiti nego ručne pogreške. Najprije dolaze clean core, upravljanje podacima i stabilni procesi.

Koje su najveće pogreške tvrtki u modernizaciji ERP-a?

Tretiranje kao tehnološkog projekta, pa se rasprava o clean coreu izgubi prije nego poslovni voditelji uđu u prostoriju. Započinjanje upravljanja podacima nakon dizajna, kad bi odluke donesene u prvom tjednu uštedjele mjesece testiranja. Nedefiniranje što ERP treba prestati raditi, pa opseg jezgre raste po zadanom, što je upravo način na koji je izgrađen zadnji monolit.

Koliko košta modernizacija ERP-a?

Brownfield konverzija s ECC-a na S/4HANA za srednje veliku tvrtku obično košta 2 do 8 milijuna USD troškova implementacije, plus tekuću pretplatu. Enterprise programi globalnog opsega, znatnih prilagodbi i mnogo pravnih subjekata mogu stajati 20 do više od 100 milijuna USD. Uz licence modelirajte integraciju, testiranje i operativnu podršku, a pod RISE-om i SAP GROW modelirajte rast FUE-a kroz rok ugovora.