Одржувањето на SAP ECC завршува на 31 декември 2027: поскапување, а не исклучување

На 31 декември 2027 SAP го завршува редовното одржување (mainstream maintenance) за SAP ECC 6.0 и другите основни апликации на SAP Business Suite 7. Ништо не се исклучува на 1 јануари 2028. Вашиот систем продолжува да работи, вашите корисници продолжуваат да книжат фактури, а SAP и понатаму ќе ви продава поддршка. Се менува колку плаќате за неа и што добивате.

Таа разлика е важна, бидејќи голем дел од советите во оптек 2027 го третираат како бездна. За повеќето компании што сè уште се на ECC тоа не е, и тие го знаат тоа: најголемата група преостанати корисници на ECC планира за 2030. Вистинскиот ризик е друг. Работата што навистина го одредува датумот (сопствениот ABAP, интерфејсите, податоците) се дефинира доцна, и 2030 испаѓа исто толку тесна колку што беше 2027.

Ова е за CIO и SAP раководители во средни компании, повеќето на германојазичните пазари, што сè уште користат ECC и мора да одлучат како ќе изгледаат наредните три години.

На што навистина се обврза SAP

Условите се на страницата за стратегијата на одржување на SAP и за првпат беа објавени во февруари 2020:

• До 31 декември 2027: редовно одржување за основните апликации на Business Suite 7, меѓу нив и SAP ERP 6.0, на трите најнови пакети за подобрување (enhancement packages). Ако вашиот систем е на постар пакет за подобрување, проверете ја SAP Note 2881788 (со врска од таа страница) пред да градите план врз датумот од 2027.
• Од 1 јануари 2028 до 31 декември 2030: опционално продолжено одржување, со „премија од два процентни поени на основицата за одржување“. Едноставно кажано, стапката за одржување што ја плаќате денес расте за два поени.
• Ако не земете продолжено одржување: автоматски преминувате на одржување специфично за купувачот (customer-specific maintenance). Што покрива тоа е опишано во SAP Note 52505, со врска од истата страница. Прочитајте ја пред да претпоставите дека е доволно.
• За S/4HANA: SAP се обврза на одржување до крајот на 2040.

Постои и понатамошен пат за помала група. Во август 2025 SAP ја претстави опцијата за премин SAP ERP, private edition: временски ограничена претплата што го пренесува ECC од 2031 до 2033 во приватниот облак на SAP. Условите се строги. „Системите мора да се мигрираат на SAP ERP, private edition на SAP HANA пред 31 декември 2030.“ HANA е единствената поддржана база на податоци, опцијата доаѓа само заедно со планот max success за периодот од 2031 до 2033, а SAP поставува минимум од 2 TB за системите претплатени според неа. SAP вели дека е наменета за „нашите најголеми и најсложени купувачи на SAP ERP“. „Комерцијално еквивалентните услови“ што ги понуди SAP беа за купувачите што се обврзаа на private edition до крајот на 2025.

Кое и да е нивото што ќе го изберете, поставете им едно прашање на SAP и на вашиот партнер писмено: кои законски промени (даноци, плати, формати за е-фактурирање) ќе продолжат да стигнуваат до вашиот ECC систем и до кога. За германска компанија, само тој одговор може да одлучи дали останувањето е одржливо.

Што прави остатокот од пазарот

DSAG, германојазичната група на корисници на SAP, го спроведе својот Investment Report 2026 со 198 испитаници меѓу 8 декември 2025 и 21 јануари 2026. Од нив, 54 проценти сè уште користат ECC или постариот Business Suite, наспроти 68 проценти во 2024.

Што се однесува на времето, речиси половина од испитаниците планираат да преминат на S/4HANA до крајот на 2030, што, како што посочува DSAG, значи плаќање за продолжено одржување. Уште 37 проценти сакаат да преминат до крајот на 2027, а само 4 проценти целат кон 2033 и опцијата за премин на private edition.

Претседателот на DSAG, Јенс Хунгерсхаузен, ги кажа причините отворено: недостигот на кадри, паралелните проекти за трансформација и ограничените буџети ги туркаат распоредите наназад, „дури и ако тоа резултира со повисоки трошоци за одржување“.

И јавните набавувачи се движат. Нашето сопствено броење на огласите за јавни набавки во ЕУ покажува приближно 200 постапки за миграција на S/4HANA на секое полугодие низ 2025 и 2026, и повеќе од 300 во 2026 до почетокот на октомври, повеќето во Германија. Работата се случува. Распоредена е на подолга писта отколку што сугерираат насловите за 2027.

Каде е всушност работата

Техничкото претворање од ECC во S/4HANA е добро покриено со алатки од SAP и неговите партнери. Ако користите малку прилагоден ECC со неколку стандардни интерфејси, вашиот интегратор го направил ова многупати и поголемиот дел од она што следи не е ваш проблем.

Станува ваш проблем сразмерно на тоа колку сте изградиле сами.

Сопствен ABAP: каде проектите се лизгаат

S/4HANA не е ECC на нова база на податоци. Делови од моделот на податоци се сменија. Купувачите и добавувачите стануваат деловни партнери (business partners). Финансиските и магацинските книжења се консолидирани во помалку, но пошироки табели. Некои трансакции и функции се отстранети или заменети.

Сопствениот код што директно чита табели, се потпира на излезна точка (exit) што се преместила или тивко претпоставува редослед на сортирање (HANA не го гарантира освен ако барањето не го побара) може да ја помине синтаксната проверка и сепак да прави погрешна работа. Токму тој последен вид боли, бидејќи се појавува при интеграциското тестирање или по почетокот на работа, а не при скенирањето на кодот.

Процесот што функционира:

1. Прво измерете ја употребата. Вклучете евиденција на користењето во продукција (ABAP call monitor, трансакција SCMON) и оставете ја да работи низ цело годишно затворање. Во долговечните системи значителен дел од сопствените објекти често никогаш не се извршува. Кодот што никој не го извршува се брише, а не се мигрира.
2. Пуштете ги алатките за анализа врз она што останува. Проверките на SAP наоѓаат можни проблеми. Не можат да ви кажат кои се важни за бизнисот.
3. Класифицирајте го секој објект. Повлечете го, заменете го со стандардна функционалност, поправете го на место или изградете го повторно надвор од јадрото. Една одлука по објект, со именуван деловен сопственик.
4. Тестирајте по процес, а не по објект. Менувањето на кодот е евтиниот дел. Докажувањето дека процесот од нарачка до наплата и месечното затворање сè уште ги даваат истите бројки е скапиот дел.

Проектите тука се лизгаат од досадна причина: никој не избројал доволно рано. Обемот на сопствениот код е познат само грубо, луѓето што го напишале често заминале, а вистинските наоди пристигнуваат во вториот циклус на тестирање, откако датумот веќе е објавен внатре во компанијата.

Интерфејсите и PI/PO на истиот часовник

ECC ретко стои сам. IDoc до магацинот, RFC и BAPI повици од производството, рамни датотеки до банката и даночниот советник, портал за купувачи што чита поглед од базата што некој го создал во 2011. Секој од нив мора да се најде, да се тестира и во некои случаи да се изгради повторно.

Ако тие интерфејси минуваат низ SAP Process Integration или Process Orchestration, има втор рок на истите датуми. Architecture Center на SAP вели дека PI/PO се приближува кон „крајот на стандардното одржување во 2027“, дека купувачите можат да го продолжат одржувањето до 2030 и дека поддршката од SAP завршува потоа. SAP ги упатува купувачите на PI/PO кон SAP Integration Suite, кој доаѓа со процена за миграција и алатки за миграција водени со волшебник.

Алатките помагаат кај стандардните објекти. Не ви кажуваат кои интерфејси сè уште служат за нешто, а сопствената логика за мапирање и понатаму бара човек да ја прочита. Изградете го пописот од конфигурацијата на middleware, логовите и закажаните задачи, а не од прашалник. Потоа планирајте ги преселувањето на ERP и преселувањето на middleware заедно. Ако се прават едно по друго, секој интерфејс се тестира двапати.

Миграција на податоци

Кај конверзија на системот вашите податоци се преселуваат со системот, а со нив и нивниот квалитет. Претворањето во деловни партнери обично е првиот судир: дупликат-купувачи, добавувачи што се и купувачи, адреси во полиња со слободен текст, даночни броеви на погрешно место. Сето тоа мора да се исчисти пред конверзијата, а не за време на неа.

Кај ново воведување ги извлекувате, чистите, трансформирате и вчитувате податоците, а тешкиот дел е усогласувањето. Финансиите потпишуваат кога салдата и отворените ставки се совпаѓаат, а не кога задачата за вчитување ќе заврши. Изградете ја миграцијата како код што може да се повторува, што можете да го пуштите десетина пати врз сè почисти податоци, со автоматска споредба на резултатите при секое пуштање.

На кој било пат, прво архивирајте го она што повеќе не ви треба. Помалку податоци значи пократки извршувања на конверзијата и пократок прозорец на прекин.

Проширувања по принципот clean core

Искушението во проект воден од рок е секоја модификација да се пренесе и да се вети подоцнежно средување. Подоцна не доаѓа.

Името на SAP за алтернативата е clean core: стандардниот систем да остане немодифициран, а проширувањата да се градат наспроти интерфејси што SAP ги објавува и ги одржува стабилни, или во S/4HANA или покрај него на SAP Business Technology Platform. Не може сè да биде чисто од првиот ден. Правилото што навистина може да се одржи е поедноставно: ништо ново не се гради на стариот начин. Секоја модификација што ја избегнувате сега е една што нема да ја тестирате повторно при секоја идна надградба.

Рамка за одлучување

Постојат три реални патишта и четврти што добива помалку внимание.

Почеток на работа на S/4HANA до 31 декември 2027. Ова им одговара на компаниите што веќе почнале, користат главно стандарден систем и имаат резервиран партнер. Од денес тоа се петнаесет месеци, а малку финансиски тимови ќе прифатат преминување среде годишното затворање. Ако анализата на сопствениот код не е направена, ова најверојатно не е вашиот пат.

Плаќање за продолжено одржување и почеток на работа до 2030. Тука се упатува најголемиот дел од пазарот. Трошокот е премијата од два поени; потврдете со SAP како се применува ако почнете со работа во текот на периодот. Ризикот е 2030 да се третира како што се третираше 2027: како далечна, сè додека одеднаш не е.

Опцијата за премин на private edition до 2033. Тоа значи договор RISE with SAP, HANA, систем преселен на SAP ERP, private edition пред 31 декември 2030, планот max success и минимумот од 2 TB. За средна компанија тоа ретко е најевтиниот начин да се купи време.

Напуштање на SAP. За некои средни производители и дистрибутери помал ERP е вистинска опција. Работата со интерфејсите и податоците не се намалува. Таа станува најголемиот дел од проектот.

Наредните шест месеци, кој и да го изберете

Од сега до крајот на март 2027, сето ова се исплатува на секој пат:

1. Потврдете ја почетната точка. Пакет за подобрување, база на податоци, договор за одржување. Побарајте писмено од вашиот тим за сметка во SAP условите за продолжено одржување што важат за вас.
2. Вклучете ја евиденцијата на користењето сега, за да го фати годишното затворање за 2026.
3. Направете анализа на сопствениот код и излезете со бројка, а не со впечаток: колку објекти, колку се во употреба, колку ги допираат променетите делови од моделот на податоци.
4. Изградете го пописот на интерфејси, вклучително и сè што минува низ PI/PO, со сопственик и одлука за секој интерфејс.
5. Почнете со чистење на матичните податоци, прво купувачите и добавувачите.
6. Престанете да додавате модификации. Новиот развој го следи clean core од денес.
7. Ставете го поскапувањето на одржувањето од 2028 во буџетот за 2027 како познат трошок, а не како изненадување.
8. Резервирајте капацитет: партнерот, вашиот внатрешен SAP тим и развивачите што се грижат за системите околу SAP. Недостигот на кадри е една од причините што членовите на DSAG ги наведуваат за лизгањето на распоредите.

Сметајќи наназад од почеток на работа во 2030: циклуси на тестирање и проби на преминувањето во 2030, изработка и поправки во 2029, дизајн и чистење на податоците во 2028, анализа сега. Во тоа има помалку резерва отколку што изгледа.

Каде да побарате помош

Ние не сме функционална SAP консултантска куќа и не водиме конверзии на S/4HANA; работиме покрај партнерот што ги води, на пописот и повторната изградба на интерфејсите, кодот за миграција на податоците и неговото усогласување, и апликациите изградени околу ECC што мора да го преживеат преселувањето. Таа работа е опишана на нашата страница за модернизација на ERP, а одржувањето наследени системи ги покрива системите што остануваат каде што се додека не се преселите. Ако сакате системите околу вашиот ERP да бидат избројани пред да потпишете програма, пишете ни на office@c9group.dev.