Vzdrževanje SAP ECC se konča 31. decembra 2027: dražje vzdrževanje, ne izklop

Omrežne omare z modrimi povezovalnimi kabli v strežniški sobi

SAP 31. decembra 2027 konča redno vzdrževanje (mainstream maintenance) za SAP ECC 6.0 in druge osrednje aplikacije SAP Business Suite 7. 1. januarja 2028 se nič ne izklopi. Vaš sistem teče naprej, vaši uporabniki še naprej knjižijo račune, SAP pa vam bo podporo še vedno prodajal. Spremeni se, koliko zanjo plačate in kaj dobite.

To razlikovanje je pomembno, ker veliko nasvetov v obtoku leto 2027 obravnava kot prepad. Za večino podjetij, ki so še na ECC, ni, in to vedo: največja skupina preostalih uporabnikov ECC načrtuje za leto 2030. Pravo tveganje je drugačno. Delo, ki dejansko določa datum (ABAP po meri, vmesniki, podatki), se opredeli pozno, in leto 2030 se izkaže za enako tesno, kot je bilo 2027.

Članek je namenjen direktorjem informatike in vodjem SAP v srednje velikih podjetjih, večinoma na nemško govorečih trgih, ki še uporabljajo ECC in se morajo odločiti, kako bodo videti naslednja tri leta.

K čemu se je SAP dejansko zavezal

Pogoji so na SAP-ovi strani o strategiji vzdrževanja, prvič pa so bili napovedani februarja 2020:

Do 31. decembra 2027: redno vzdrževanje za osrednje aplikacije Business Suite 7, med njimi SAP ERP 6.0, na zadnjih treh paketih izboljšav (enhancement packages). Če je vaš sistem na starejšem paketu izboljšav, preverite SAP Note 2881788 (povezava je na tej strani), preden načrt zgradite na datumu 2027.
Od 1. januarja 2028 do 31. decembra 2030: neobvezno podaljšano vzdrževanje (extended maintenance) z „doplačilom dveh odstotnih točk na osnovo za vzdrževanje“. Preprosto povedano, stopnja za vzdrževanje, ki jo plačujete danes, se zviša za dve točki.
Če podaljšanega vzdrževanja ne izberete: samodejno preidete na vzdrževanje za posameznega naročnika (customer-specific maintenance). Kaj to pokriva, je opisano v SAP Note 52505, povezanem z iste strani. Preberite ga, preden predpostavite, da je dovolj.
Za S/4HANA: SAP se je zavezal k vzdrževanju do konca leta 2040.

Za manjšo skupino obstaja še ena pot. Avgusta 2025 je SAP predstavil možnost prehoda SAP ERP, private edition: časovno omejeno naročnino, ki ECC od leta 2031 do 2033 nosi znotraj SAP-ovega zasebnega oblaka. Pogoji so strogi. „Sisteme je treba pred 31. decembrom 2030 preseliti na SAP ERP, private edition na SAP HANA.“ HANA je edina podprta baza podatkov, možnost je na voljo le skupaj s paketom max success plan za leta od 2031 do 2033, za sisteme, naročene v tem okviru, pa SAP določa najmanj 2 TB. SAP pravi, da je namenjena „našim največjim in najbolj zapletenim strankam SAP ERP“. „Komercialno enakovredni pogoji“, ki jih je SAP ponudil, so veljali za stranke, ki so se za private edition zavezale do konca leta 2025.

Katero koli raven izberete, SAP-u in svojemu partnerju v pisni obliki zastavite eno vprašanje: katere zakonske spremembe (davki, plače, formati e-računov) bodo še prišle do vašega sistema ECC in do kdaj. Za nemško podjetje lahko že ta odgovor odloči, ali je ostati na mestu izvedljivo.

Kaj počne preostali trg

DSAG, združenje uporabnikov SAP z nemško govorečega območja, je med 8. decembrom 2025 in 21. januarjem 2026 izvedel Investment Report 2026 s 198 anketiranci. Od teh jih 54 odstotkov še uporablja ECC ali starejši Business Suite, kar je manj od 68 odstotkov leta 2024.

Glede časovnice skoraj polovica anketirancev načrtuje prehod na S/4HANA do konca leta 2030, kar po opozorilu DSAG pomeni plačevanje podaljšanega vzdrževanja. Nadaljnjih 37 odstotkov želi preiti do konca leta 2027, le 4 odstotki pa ciljajo na leto 2033 in možnost prehoda na private edition.

Predsednik DSAG Jens Hungershausen je razloge povedal naravnost: pomanjkanje strokovnjakov, vzporedni transformacijski projekti in omejeni proračuni časovnice potiskajo nazaj, „tudi če to pomeni višje stroške vzdrževanja“.

Premikajo se tudi javni naročniki. Naše lastno štetje obvestil o javnih naročilih v EU kaže približno 200 postopkov za selitev na S/4HANA na polletje skozi leti 2025 in 2026, do začetka oktobra pa več kot 300 v letu 2026, večino v Nemčiji. Delo poteka. Razporejeno je le na daljšo stezo, kot jo nakazujejo naslovi o letu 2027.

Kje je delo v resnici

Tehnična pretvorba iz ECC v S/4HANA je pri SAP in njegovih partnerjih dobro podprta z orodji. Če imate malo prilagojen ECC s peščico standardnih vmesnikov, je vaš integrator to naredil že velikokrat in večina tega, kar sledi, ni vaša težava.

Vaša težava postane sorazmerno s tem, koliko ste zgradili sami.

ABAP po meri: kjer projekti zdrsnejo

S/4HANA ni ECC na novi bazi podatkov. Deli podatkovnega modela so se spremenili. Kupci in dobavitelji postanejo poslovni partnerji. Finančna knjiženja in knjiženja zalog so bila združena v manj, a širših tabel. Nekatere transakcije in funkcije so bile odstranjene ali zamenjane.

Koda po meri, ki tabele bere neposredno, se zanaša na izhod (exit), ki se je premaknil, ali tiho predpostavlja vrstni red razvrščanja (HANA ga ne obljublja, razen če ga poizvedba zahteva), lahko prestane preverjanje sintakse in vseeno dela narobe. Ta zadnja vrsta boli, saj se pokaže pri integracijskem testiranju ali po zagonu, ne pri pregledu kode.

Postopek, ki deluje:

Najprej izmerite uporabo. V produkciji vklopite beleženje uporabe (ABAP call monitor, transakcija SCMON) in ga pustite teči skozi celoten zaključek leta. V dolgo živečih sistemih se precejšen delež objektov po meri pogosto nikoli ne izvede. Koda, ki je nihče ne izvaja, se izbriše, ne preseli.
Na tistem, kar ostane, poženite orodja za analizo. SAP-ova preverjanja najdejo kandidate za težave. Ne morejo vam povedati, katere so za poslovanje pomembne.
Razvrstite vsak objekt. Ukinite ga, nadomestite s standardno funkcionalnostjo, popravite na mestu ali zgradite znova zunaj jedra. Ena odločitev za vsak objekt, z imenovanim poslovnim lastnikom.
Testirajte po procesih, ne po objektih. Sprememba kode je poceni del. Dokazati, da proces od naročila do plačila (order-to-cash) in mesečni zaključek še vedno dajeta enake številke, je drag del.

Projekti tu zdrsnejo iz dolgočasnega razloga: nihče ni štel dovolj zgodaj. Obseg kode po meri je znan le približno, ljudje, ki so jo napisali, so pogosto odšli, prave ugotovitve pa pridejo v drugem ciklu testiranja, ko je datum interno že napovedan.

Vmesniki in PI/PO na isti uri

ECC redko stoji sam. IDoc-i v skladišče, klici RFC in BAPI iz proizvodnje, ploske datoteke za banko in davčnega svetovalca, portal za stranke, ki bere pogled v bazi podatkov, ki ga je nekdo ustvaril leta 2011. Vsakega od njih je treba najti, preizkusiti in v nekaterih primerih zgraditi znova.

Če ti vmesniki tečejo prek SAP Process Integration ali Process Orchestration, obstaja na iste datume še drug rok. SAP-ov Architecture Center navaja, da se PI/PO bliža „koncu standardnega vzdrževanja leta 2027“, da lahko stranke vzdrževanje podaljšajo do leta 2030 in da se SAP-ova podpora nato konča. SAP stranke PI/PO usmerja na SAP Integration Suite, ki ima oceno pripravljenosti na selitev in orodja za selitev s čarovniki.

Orodja pomagajo pri standardnih objektih. Ne povedo pa vam, kateri vmesniki še čemu služijo, logiko preslikav po meri pa mora še vedno prebrati človek. Popis zgradite iz konfiguracije vmesne programske opreme, dnevnikov in načrtovanih opravil, ne iz vprašalnika. Nato selitev ERP in selitev vmesne programske opreme načrtujte skupaj. Če ju izvedete eno za drugo, se vsak vmesnik testira dvakrat.

Selitev podatkov

Pri pretvorbi sistema (system conversion) se vaši podatki premaknejo s sistemom, z njimi pa tudi njihova kakovost. Pretvorba v poslovne partnerje je običajno prvi trk: podvojeni kupci, dobavitelji, ki so hkrati kupci, naslovi v poljih s prostim besedilom, davčne številke na napačnem mestu. Vse to je treba počistiti pred pretvorbo, ne med njo.

Pri novi uvedbi podatke izluščite, počistite, preoblikujete in naložite, težji del pa je usklajevanje. Finance potrdijo, ko se ujemajo stanja in odprte postavke, ne ko se konča opravilo nalaganja. Selitev zgradite kot ponovljivo kodo, ki jo lahko ducatkrat poženete na vedno bolj čistih podatkih in ob vsakem zagonu samodejno primerjate rezultate.

Na kateri koli poti najprej arhivirajte, česar ne potrebujete več. Manj podatkov pomeni krajše pretvorbe in krajše okno izpada.

Razširitve po načelu čistega jedra

Skušnjava v projektu, ki ga ženejo roki, je, da vse modifikacije prenesete in obljubite, da boste pospravili pozneje. Pozneje ne pride.

SAP-ovo ime za alternativo je clean core, čisto jedro: standardni sistem pustite nespremenjen, razširitve pa gradite na vmesnikih, ki jih SAP objavlja in ohranja stabilne, bodisi znotraj S/4HANA bodisi ob njem na SAP Business Technology Platform. Vse ne more biti čisto že prvi dan. Pravilo, ki se ga lahko dejansko držite, je preprostejše: nič novega se ne gradi na stari način. Vsaka modifikacija, ki se ji izognete zdaj, je ena, ki je ne boste znova testirali ob vsaki prihodnji nadgradnji.

Okvir za odločitev

Obstajajo tri realne poti in četrta, ki je deležna manj pozornosti.

Zagon na S/4HANA do 31. decembra 2027. To ustreza podjetjem, ki so že začela, imajo večinoma standarden sistem in rezerviranega partnerja. Od danes je to petnajst mesecev, le malo finančnih ekip pa bo sprejelo prehod sredi zaključka leta. Če analiza kode po meri še ni narejena, to verjetno ni vaša pot.

Plačilo podaljšanega vzdrževanja in zagon do leta 2030. Sem se usmerja večina trga. Strošek je doplačilo dveh točk; s SAP potrdite, kako se uporablja, če zaženete sredi obdobja. Tveganje je, da leto 2030 obravnavate tako, kot je bilo obravnavano leto 2027: kot oddaljeno, dokler nenadoma ni več.

Možnost prehoda na private edition do leta 2033. To pomeni pogodbo RISE with SAP, HANA, vaš sistem, preseljen na SAP ERP, private edition pred 31. decembrom 2030, paket max success plan in najmanj 2 TB. Za srednje veliko podjetje je to redko najcenejši način za nakup časa.

Odhod s SAP. Za nekatere srednje velike proizvajalce in distributerje je manjši ERP resnična možnost. Delo z vmesniki in podatki se ne zmanjša. Postane večina projekta.

Naslednjih šest mesecev, karkoli izberete

Od zdaj do konca marca 2027 se vse to izplača na vsaki poti:

Potrdite izhodišče. Paket izboljšav, baza podatkov, pogodba o vzdrževanju. Ekipo SAP, ki skrbi za vaš račun, pisno prosite za pogoje podaljšanega vzdrževanja, ki veljajo za vas.
Beleženje uporabe vklopite zdaj, da zajame zaključek leta 2026.
Izvedite analizo kode po meri in iz nje pridite s številko, ne z vtisom: koliko objektov, koliko se jih uporablja, koliko se jih dotika spremenjenih delov podatkovnega modela.
Zgradite popis vmesnikov, vključno z vsem, kar teče prek PI/PO, z lastnikom in odločitvijo za vsak vmesnik.
Začnite čistiti matične podatke, najprej kupce in dobavitelje.
Nehajte dodajati modifikacije. Nov razvoj od danes sledi načelu čistega jedra.
Podražitev vzdrževanja za leto 2028 vključite v proračun za leto 2027 kot znan strošek in ne kot presenečenje.
Rezervirajte zmogljivosti: partnerja, svojo interno ekipo SAP in razvijalce, ki skrbijo za sisteme okoli SAP. Pomanjkanje strokovnjakov je eden od razlogov, ki jih člani DSAG navajajo za zdrse časovnic.

Šteto nazaj od zagona leta 2030: cikli testiranja in generalke prehoda leta 2030, gradnja in odpravljanje težav leta 2029, zasnova in čiščenje podatkov leta 2028, analiza zdaj. V tem je manj rezerve, kot se zdi.

Kje dobiti pomoč

Nismo funkcionalno svetovalno podjetje za SAP in ne izvajamo pretvorb na S/4HANA; delamo ob partnerju, ki jih izvaja, na popisu in ponovni gradnji vmesnikov, na kodi za selitev podatkov in njenem usklajevanju ter na aplikacijah, zgrajenih okoli ECC, ki morajo selitev preživeti. To delo je opisano na naši strani o posodobitvi ERP, vzdrževanje podedovanih sistemov pa pokriva sisteme, ki ostanejo, kjer so, dokler se ne preselite. Če želite, da pred podpisom programa preštejemo okolje okoli vašega ERP, pišite na office@c9group.dev.