Održavanje SAP ECC-a se završava 31. decembra 2027: skok cene, a ne gašenje

SAP 31. decembra 2027. završava redovno održavanje (mainstream maintenance) za SAP ECC 6.0 i ostale ključne aplikacije SAP Business Suite 7. Ništa se ne gasi 1. januara 2028. Vaš sistem nastavlja da radi, vaši korisnici nastavljaju da knjiže fakture, a SAP će vam i dalje prodavati podršku. Menja se koliko za nju plaćate i šta dobijate.

Ta razlika je važna, jer veliki deo saveta koji kruže 2027. tretira kao provaliju. Za većinu kompanija koje su još na ECC-u to nije, i one to znaju: najveća grupa preostalih korisnika ECC-a planira za 2030. Pravi rizik je drugačiji. Posao koji zaista određuje datum (prilagođeni ABAP, interfejsi, podaci) procenjuje se kasno, pa se 2030. pokaže jednako tesnom kao što je bila 2027.

Ovaj tekst je za direktore IT-a i rukovodioce SAP-a u srednjim kompanijama, uglavnom na tržištima nemačkog govornog područja, koje i dalje koriste ECC i moraju da odluče kako će izgledati naredne tri godine.

Na šta se SAP zaista obavezao

Uslovi su na SAP-ovoj stranici o strategiji održavanja, a prvi put su objavljeni u februaru 2020:

• Do 31. decembra 2027: redovno održavanje za ključne aplikacije Business Suite 7, među njima i SAP ERP 6.0, na poslednja tri enhancement paketa. Ako je vaš sistem na starijem enhancement paketu, proverite SAP Note 2881788 (do koga vodi link sa te stranice) pre nego što plan zasnujete na datumu iz 2027.
• Od 1. januara 2028. do 31. decembra 2030: opciono produženo održavanje (extended maintenance), uz „doplatu od dva procentna poena na osnovicu za održavanje". Jednostavno rečeno, stopa održavanja koju danas plaćate raste za dva poena.
• Ako ne uzmete produženo održavanje: automatski prelazite na održavanje specifično za kupca (customer-specific maintenance). Šta ono pokriva opisano je u SAP Note 52505, do koga vodi link sa iste stranice. Pročitajte ga pre nego što pretpostavite da je dovoljno.
• Za S/4HANA: SAP se obavezao na održavanje do kraja 2040.

Za manju grupu postoji još jedan put. SAP je u avgustu 2025 predstavio SAP ERP, private edition, transition option: vremenski ograničenu pretplatu koja ECC od 2031. do 2033. prenosi u SAP-ov privatni cloud. Uslovi su strogi. „Sistemi moraju da budu migrirani na SAP ERP, private edition na SAP HANA pre 31. decembra 2030." HANA je jedina podržana baza podataka, opcija dolazi samo uz max success plan za period od 2031. do 2033, a SAP za sisteme pretplaćene po ovoj opciji postavlja minimum od 2 TB. SAP kaže da je namenjena „našim najvećim i najsloženijim SAP ERP kupcima". „Komercijalno ekvivalentni uslovi" koje je SAP nudio važili su za kupce koji su se na private edition obavezali do kraja 2025.

Koji god nivo izabrali, postavite SAP-u i svom partneru jedno pitanje pismeno: koje zakonske izmene (porezi, obračun zarada, formati e-faktura) će i dalje stizati do vašeg ECC sistema, i do kada. Za nemačku kompaniju sam taj odgovor može da odluči da li je ostanak održiv.

Šta radi ostatak tržišta

DSAG, udruženje SAP korisnika nemačkog govornog područja, sproveo je svoj Investment Report 2026 sa 198 ispitanika između 8. decembra 2025. i 21. januara 2026. Od njih, 54 odsto i dalje koristi ECC ili stariji Business Suite, u odnosu na 68 odsto 2024.

Što se tiče vremena, skoro polovina ispitanika planira prelazak na S/4HANA do kraja 2030, što, kako DSAG ističe, znači plaćanje produženog održavanja. Još 37 odsto želi da pređe do kraja 2027, a samo 4 odsto cilja 2033. i private edition transition option.

Predsednik DSAG-a, Jens Hungershausen, razloge je izneo otvoreno: nedostatak stručnjaka, paralelni projekti transformacije i ograničeni budžeti guraju rasporede unazad, „čak i ako to dovodi do većih troškova održavanja".

Pokreću se i javni naručioci. Naše sopstveno brojanje obaveštenja o javnim nabavkama u EU pokazuje oko 200 postupaka za migraciju na S/4HANA po polugodištu tokom 2025. i 2026, i više od 300 u 2026. do početka oktobra, većinom u Nemačkoj. Posao se odvija. Raspoređen je na duži period nego što naslovi o 2027. nagoveštavaju.

Gde je zapravo posao

Tehnička konverzija sa ECC-a na S/4HANA dobro je podržana alatima SAP-a i njegovih partnera. Ako koristite blago prilagođen ECC sa nekoliko standardnih interfejsa, vaš integrator je ovo radio mnogo puta i većina onoga što sledi nije vaš problem.

Postaje vaš problem srazmerno tome koliko ste toga sami izgradili.

Prilagođeni ABAP: gde projekti kasne

S/4HANA nije ECC na novoj bazi podataka. Delovi modela podataka su se promenili. Kupci i dobavljači postaju poslovni partneri. Knjiženja finansija i zaliha objedinjena su u manje, šire tabele. Neke transakcije i funkcije su uklonjene ili zamenjene.

Prilagođeni kod koji direktno čita tabele, oslanja se na exit koji je premešten ili prećutno pretpostavlja redosled sortiranja (HANA ga ne garantuje ako ga upit ne traži) može da prođe proveru sintakse i da i dalje radi pogrešnu stvar. Ta poslednja vrsta je ona koja boli, jer se pojavljuje u integracionom testiranju ili posle puštanja u rad, a ne pri skeniranju koda.

Proces koji radi:

1. Prvo izmerite upotrebu. Uključite beleženje upotrebe u produkciji (ABAP call monitor, transakcija SCMON) i ostavite ga da radi kroz čitavo godišnje zatvaranje. U dugovečnim sistemima znatan deo prilagođenih objekata se često nikada ne izvršava. Kod koji niko ne pokreće briše se, a ne migrira.
2. Pokrenite alate za analizu nad onim što preostane. SAP-ove provere pronalaze moguće probleme. Ne mogu da vam kažu koji su bitni za poslovanje.
3. Klasifikujte svaki objekat. Ugasite ga, zamenite standardnom funkcionalnošću, popravite ga na mestu ili ga izgradite iznova van jezgra. Jedna odluka po objektu, sa imenovanim vlasnikom iz poslovanja.
4. Testirajte po procesu, a ne po objektu. Izmena koda je jeftin deo. Dokazivanje da order-to-cash i mesečno zatvaranje i dalje daju iste brojeve je skup deo.

Projekti ovde kasne iz dosadnog razloga: niko nije prebrojao dovoljno rano. Obim prilagođenog koda poznat je samo okvirno, ljudi koji su ga pisali često su otišli, a pravi nalazi stižu u drugom ciklusu testiranja, pošto je datum već objavljen unutar firme.

Interfejsi, i PI/PO na istom satu

ECC retko stoji sam. IDoc-ovi ka magacinu, RFC i BAPI pozivi iz proizvodnje, ravni fajlovi ka banci i poreskom savetniku, portal za kupce koji čita pogled u bazi koji je neko napravio 2011. Svaki od njih mora da se pronađe, testira, a u nekim slučajevima i izgradi iznova.

Ako ti interfejsi idu kroz SAP Process Integration ili Process Orchestration, na istim datumima postoji i drugi rok. SAP-ov Architecture Center kaže da se PI/PO približava „kraju standardnog održavanja 2027", da kupci mogu da produže održavanje do 2030. i da posle toga SAP-ova podrška prestaje. SAP kupce PI/PO usmerava na SAP Integration Suite, koji dolazi sa procenom migracije i alatima za migraciju vođenim čarobnjakom.

Alati pomažu kod standardnih objekata. Ne govore vam koji interfejsi i dalje nečemu služe, a prilagođenu logiku mapiranja i dalje mora da pročita čovek. Popis pravite iz konfiguracije middlewarea, logova i zakazanih poslova, a ne iz upitnika. Zatim selidbu ERP-a i selidbu middlewarea planirajte zajedno. Ako se rade jedna za drugom, svaki interfejs se testira dvaput.

Migracija podataka

Pri sistemskoj konverziji vaši podaci sele se zajedno sa sistemom, a sa njima i njihov kvalitet. Konverzija u poslovne partnere obično je prvi sudar: duplirani kupci, dobavljači koji su ujedno i kupci, adrese u poljima sa slobodnim tekstom, poreski brojevi na pogrešnom mestu. Sve to mora da se očisti pre konverzije, a ne tokom nje.

Pri novoj implementaciji podatke izvlačite, čistite, transformišete i učitavate, a težak deo je usaglašavanje. Finansije daju saglasnost kada se salda i otvorene stavke slažu, a ne kada se posao učitavanja završi. Migraciju gradite kao kod koji se može ponoviti i pokrenuti desetak puta nad sve čistijim podacima, uz automatsko poređenje rezultata pri svakom pokretanju.

Na oba puta prvo arhivirajte ono što vam više ne treba. Manje podataka znači kraća pokretanja konverzije i kraći period zastoja.

Proširenja po principu clean core

Iskušenje u projektu koji goni rok je da se svaka modifikacija prenese uz obećanje da će se sve srediti kasnije. Kasnije ne dolazi.

SAP alternativu naziva clean core: standardni sistem ostaje neizmenjen, a proširenja se grade prema interfejsima koje SAP objavljuje i drži stabilnim, bilo unutar S/4HANA, bilo pored njega na SAP Business Technology Platformu. Ne može sve da bude čisto od prvog dana. Pravilo koje zaista možete da održite je jednostavnije: ništa novo se ne gradi na stari način. Svaka modifikacija koju sada izbegnete je jedna koju nećete ponovo testirati pri svakoj budućoj nadogradnji.

Okvir za odluku

Postoje tri realna puta i četvrti, kome se poklanja manje pažnje.

Puštanje S/4HANA u rad do 31. decembra 2027. Ovo odgovara kompanijama koje su već počele, koriste uglavnom standardan sistem i imaju rezervisanog partnera. Od danas je to petnaest meseci, a malo koja finansijska služba će prihvatiti prelazak usred godišnjeg zatvaranja. Ako analiza prilagođenog koda nije urađena, ovo verovatno nije vaš put.

Plaćanje produženog održavanja i puštanje u rad do 2030. Ka tome ide najveći deo tržišta. Trošak je doplata od dva poena; proverite sa SAP-om kako se primenjuje ako sistem pustite u rad usred perioda. Rizik je da se 2030. tretira onako kako je tretirana 2027: kao daleka, dok iznenada ne postane bliska.

Private edition transition option do 2033. To znači RISE with SAP ugovor, HANA, sistem preseljen na SAP ERP, private edition pre 31. decembra 2030, max success plan i minimum od 2 TB. Za srednju kompaniju to retko je najjeftiniji način da se kupi vreme.

Napuštanje SAP-a. Za neke srednje proizvođače i distributere manji ERP je stvarna opcija. Posao sa interfejsima i podacima se ne smanjuje. Postaje najveći deo projekta.

Narednih šest meseci, koji god put izabrali

Od sada do kraja marta 2027. sve ovo se isplati na svakom putu:

1. Potvrdite polaznu tačku. Enhancement paket, baza podataka, ugovor o održavanju. Od svog SAP account tima pismeno tražite uslove produženog održavanja koji se odnose na vas.
2. Uključite beleženje upotrebe sada, kako bi obuhvatilo godišnje zatvaranje za 2026.
3. Uradite analizu prilagođenog koda i iz nje izađite sa brojem, a ne utiskom: koliko objekata, koliko ih je u upotrebi, koliko ih dira izmenjene delove modela podataka.
4. Napravite popis interfejsa, uključujući sve što ide kroz PI/PO, sa vlasnikom i odlukom za svaki interfejs.
5. Počnite čišćenje matičnih podataka, prvo kupaca i dobavljača.
6. Prestanite da dodajete modifikacije. Novi razvoj od danas prati clean core.
7. Uvećanje troška održavanja za 2028. stavite u budžet za 2027. kao poznat trošak, a ne kao iznenađenje.
8. Rezervišite kapacitete: partnera, svoj interni SAP tim i programere koji održavaju sisteme oko SAP-a. Nedostatak stručnjaka je jedan od razloga koje članovi DSAG-a navode za kašnjenje rasporeda.

Računajući unazad od puštanja u rad 2030: ciklusi testiranja i probe prelaska 2030, izrada i ispravke 2029, dizajn i čišćenje podataka 2028, analiza sada. U tome ima manje rezerve nego što izgleda.

Gde potražiti pomoć

Nismo SAP funkcionalna konsultantska kuća i ne vodimo S/4HANA konverzije; radimo uz partnera koji ih vodi, na popisu i ponovnoj izradi interfejsa, na kodu za migraciju podataka i njegovom usaglašavanju i na aplikacijama izgrađenim oko ECC-a koje moraju da prežive selidbu. Taj posao opisan je na našoj stranici o modernizaciji ERP-a, a održavanje nasleđenih sistema pokriva sisteme koji ostaju gde jesu dok se ne preselite. Ako želite da se sistemi oko vašeg ERP-a prebroje pre nego što potpišete program, pišite na office@c9group.dev.