De la SAP ECC la S/4HANA. Ghid pentru cei care vor să profite profesional de cea mai mare schimbare din ecosistemul SAP
De la SAP ECC la S/4HANA. Ghid pentru cei care vor să profite profesional de cea mai mare schimbare din ecosistemul SAP
Cea mai mare schimbare din ecosistemul SAP din ultimii douăzeci de ani creează, până spre 2033, o cerere de oameni pe care piața nu o poate acoperi. Iată cum arată harta — și cum intri pe ea, indiferent de unde pornești.
Numărătoarea inversă pentru SAP ECC
Există momente în care o industrie întreagă e obligată, simultan, să facă același lucru. În lumea software-ului de business, momentul acesta e acum: aproximativ 35.000 de companii din lume rulează SAP ECC, sistemul care le ține contabilitatea, stocurile, producția și facturile — iar producătorul a anunțat data la care nu-l mai repară. 31 decembrie 2027 pentru mentenanța standard, cu prelungiri opționale și condiționate până în 2030, respectiv 2033.
Fiecare dintre acele companii are nevoie de oameni care să facă tranziția. Nu de unul singur — de echipe, timp de unul până la trei ani fiecare. Iar oamenii aceia, la nivel global, nu există în număr suficient.
SAP de la R/1 la S/4HANA
Cinci generații de software, fiecare născută dintr-o limitare tehnică a epocii ei.
1972 — cinci ingineri și o idee simplă
În 1972, cinci ingineri părăsesc IBM Germania și fondează, la Weinheim, o firmă numită Systemanalyse und Programmentwicklung. Numele lor: Dietmar Hopp, Hasso Plattner, Claus Wellenreuther, Klaus Tschira și Hans-Werner Hector.
Ideea cu care pleacă la drum pare astăzi banală, dar atunci era erezie: în loc ca fiecare companie să-și comande un program scris pe măsură, de la zero, ar putea exista un software standard, cumpărat de-a gata și doar configurat pentru specificul fiecăreia. La acel moment, software-ul se scria la comandă, ca un costum.
A doua idee, la fel de importantă: prelucrarea în timp real. În epoca în care datele se strângeau pe cartele perforate și se procesau noaptea, în loturi, litera R din R/1, R/2, R/3 vine de la realtime — vezi rezultatul acum, nu mâine dimineață.
R/1 — contabilitatea, în 1973
Primul produs apare în 1973 și este o aplicație de contabilitate financiară. Nu se numea atunci „R/1” — numele a fost dat retroactiv, după ce a apărut succesorul. Rula pe un singur calculator, iar aplicația și datele stăteau împreună, pe aceeași mașină. Ceea ce, la prețul unui calculator în 1973, era singura variantă posibilă.
Până în 1975, firma adaugă verificarea facturilor și gestiunea stocurilor. Se conturează astfel logica de bază pe care SAP o va urma cincizeci de ani: module diferite, aceeași bază de date.
R/2 — generația de mainframe (1979)
Dezvoltarea celei de-a doua generații începe în 1979. R/2 rulează pe mainframe-uri IBM, la care utilizatorii se conectează prin terminale. E momentul în care SAP devine un produs serios pentru corporații: apar mai multe module integrate între ele, iar sistemul învață să lucreze cu mai multe valute și mai multe limbi — exact de ce aveau nevoie companiile germane care se extindeau în toată Europa.
În 1988, compania se listează la bursă. Are, la acel moment, câteva sute de clienți.
R/3 — momentul care a schimbat totul (1992)
Dacă există un an care explică de ce SAP e astăzi ce este, acela e 1992.
R/3 abandonează mainframe-ul și adoptă arhitectura client–server pe trei straturi: interfața pe calculatorul utilizatorului, logica de business pe un server de aplicație, datele într-o bază de date separată. Consecința comercială e enormă: sistemul poate rula pe hardware obișnuit, mult mai ieftin, și pe baza de date pe care o are deja clientul — Oracle, IBM Db2, mai târziu Microsoft SQL Server.
Brusc, SAP nu mai e un produs pentru cele câteva sute de companii care își permit un mainframe. E un produs pentru zeci de mii. Anii ’90 sunt deceniul în care SAP devine standardul de facto al corporațiilor din industrie, iar în jurul lui se formează o industrie întreagă de consultanță.
mySAP, NetWeaver și ECC (1999–2006)
La finalul anilor ’90, internetul schimbă așteptările. În 1999, SAP anunță strategia mySAP.com: sistemul nu mai e o insulă, ci trebuie să comunice cu clienții, furnizorii și angajații prin browser. Urmează, în 2003, platforma tehnică NetWeaver, care leagă între ele produsele SAP și le deschide spre exterior.
În 2004 apare SAP ERP (mySAP ERP 2004, cunoscut tehnic ca ECC 5.0), iar în 2005–2006 versiunea care avea să facă istorie: ECC 6.0. Numele complet e ERP Central Component — inima sistemului, în jurul căreia gravitează restul.
Aici se întâmplă ceva neobișnuit în industria software: ECC 6.0 rămâne ultima versiune majoră timp de aproape douăzeci de ani. În loc de versiuni noi, SAP livrează Enhancement Packages — pachete de îmbunătățiri opționale, de la EHP 1 în 2007 până la EHP 8 în 2016, care se instalează peste același nucleu.
Pentru clienți a fost o binecuvântare: două decenii de stabilitate, fără migrări dureroase. Pentru SAP a devenit, treptat, o problemă: nucleul rămăsese proiectat pentru hardware-ul din 1992, iar clienții îl umpluseră între timp cu adaptări proprii.
HANA — schimbarea de sub capotă (2010)
În 2010 SAP anunță HANA, o bază de date de tip nou: ține datele în memoria RAM în loc de pe disc și le organizează pe coloane în loc de pe rânduri. Primii clienți o folosesc în 2011.
Analogia utilă: un tabel clasic e ca un teanc de fișe de hârtie — ca să afli totalul unei coloane, treci prin toate fișele. O bază pe coloane e ca și cum ai avea fiecare coloană scrisă separat, pe o singură foaie lungă. Ca să aduni, citești doar foaia aia.
La început, HANA e folosită doar ca accelerator pentru raportare. Din 2013 se poate pune sub sistemul existent („Business Suite on HANA”). Dar potențialul real cerea altceva: nu să pui o bază rapidă sub un program vechi, ci să rescrii programul ca să profite de ea.
S/4HANA — a patra generație (2015)
În februarie 2015, la New York, SAP lansează S/4HANA. Numele: S de la simple, 4 de la a patra generație, HANA de la baza de date pe care rulează obligatoriu.
Ce se schimbă, în trei puncte:
- Modelul de date se simplifică radical. În ECC, fiecare document era copiat în zeci de tabele pre-calculate, ca să poată fi citit rapid. Dacă totalurile se pot calcula instantaneu, tabelele acelea nu mai au rost. Zecile de tabele din contabilitate devin unul singur, numit Universal Journal.
- Interfața se mută în browser. Ecranele gri, dense, cu coduri de tranzacție, sunt înlocuite treptat de Fiori: aplicații mici, orientate pe o singură sarcină, care merg și pe telefon.
- Analiza se face pe date vii. Nu mai e nevoie de un ciclu de noapte care copiază datele într-un sistem separat de raportare.
Versiunile se succed anual — 1511, 1610, 1709, 1809, 1909, apoi 2020, 2021, 2022, 2023 — până când, începând cu versiunea 2023, SAP trece la un ritm de o versiune la doi ani, cu o fereastră de mentenanță crescută de la cinci la șapte ani.
Cloud, abonamente și termenul din 2027
Ultimul deceniu adaugă un strat comercial peste cel tehnic. SAP cumpără o serie de companii de software în cloud — SuccessFactors pentru resurse umane, Ariba pentru achiziții, Concur pentru cheltuieli de deplasare, Qualtrics pentru sondaje — și își mută modelul de afaceri de la licențe cumpărate o dată la abonamente.
În 2021 apare RISE with SAP, un pachet care combină software, găzduire și servicii de tranziție într-un singur abonament; în 2023, GROW with SAP, echivalentul pentru companii mijlocii care pornesc direct în cloud public.
Și, peste toate, data care mișcă astăzi întreaga industrie: 31 decembrie 2027, sfârșitul mentenanței standard pentru ECC 6.0, cu prelungiri opționale și condiționate până în 2030, respectiv 2033. Aproximativ douăzeci de mii de companii au încă de făcut drumul.
Ce se schimbă?
Nu ai nevoie de detalii tehnice ca să înțelegi de ce apare cererea. Ai nevoie de patru propoziții.
SAP este sistemul în care companiile mari își desfășoară efectiv munca: comenzi, stocuri, producție, facturi, contabilitate — totul într-o singură bază de date, în loc de programe separate pe departamente. Genul de sistem numit ERP.
ECC este generația veche. Versiunea majoră a apărut în 2005–2006 și e construită pe o idee de inginerie din anii ’90: pentru că era prea lent să calculezi totalurile la cerere, sistemul le scria dinainte, în zeci de tabele paralele. De aici vin volumul, blocajele, reconcilierile eterne și faptul că raportarea serioasă se făcea într-un sistem separat, alimentat noaptea.
S/4HANA este generația nouă. Rulează obligatoriu pe o bază de date care ține totul în memorie, deci totalurile se pot calcula instantaneu — și atunci nu mai are rost să fie stocate. Zecile de tabele devin unul singur. Interfața se mută în browser.
Migrarea nu e un upgrade de weekend. E un proiect de 14 până la 30 de luni, care atinge fiecare proces al companiei, cere decizii de business la fiecare pas și consumă echipe mixte de zeci de oameni. Înmulțește asta cu douăzeci de mii de companii, comprimate într-o fereastră de șase ani.
Trei cuvinte pe care le vei auzi când se va discuta de migrarea către S/4HANA
- Brownfield — conversia sistemului vechi, cu tot cu date și obiceiuri. Rapid, ieftin, nu curăță nimic.
- Greenfield — sistem nou de la zero, cu procese reproiectate. Scump, lent, transformator.
- Bluefield — sistem nou, în care aduci selectiv ce merită păstrat. La mijloc, ca efort și ca preț.
Greenfield — o implementare nouă
Construiești un sistem S/4HANA de la zero, îl configurezi după procesele pe care le vrei (de obicei apropiate de standardul SAP), și aduci din vechiul sistem doar datele de bază și soldurile. Istoricul rămâne în sistemul vechi, păstrat pentru consultare sau arhivat.
Pentru cine: companii cu procese vechi și încâlcite, care au oricum nevoie de o reformă; fuziuni; grupuri care vor un model unic pentru toate țările.
Prețul real: este cel mai mare efort de management al schimbării. Utilizatorii primesc un sistem care nu doar arată altfel, ci se și comportă altfel.
Brownfield — conversia sistemului existent
Iei sistemul ECC existent, cu tot cu configurare, cod, date și istoric, și îl convertești tehnic în S/4HANA. Nu e o copiere; e o transformare pe loc, făcută cu un instrument al SAP numit SUM (Software Update Manager), cu opțiunea DMO care mută în același timp datele pe HANA.
Pentru cine: companii mulțumite de procesele lor, care vor în primul rând să iasă din zona de risc a suportului, cu buget și apetit de risc limitate.
Prețul real: muți în sistemul nou și toate păcatele vechi. Dacă aveai procese greoaie, le vei avea și după. Se numește frecvent, cu ironie, „lift and shift”.
Nu e „doar tehnic”
Brownfield e vândut adesea ca un upgrade tehnic care nu atinge business-ul. Nu e adevărat. Business Partner, Universal Journal, schimbările din SD și MM, ecranele Fiori — toate cer decizii funcționale și testare din partea utilizatorilor. Un brownfield fără implicarea business-ului eșuează la fel de sigur ca un greenfield.
Bluefield — transfer selectiv de date
Un sistem nou, gol, în care alegi ce aduci: aceste companii da, acelea nu; ultimii trei ani de istoric, nu toți cei douăzeci; aceste procese păstrate ca atare, acelea reproiectate. Se face cu instrumente specializate, de la SAP sau de la parteneri.
Pentru cine: grupuri mari care vor să facă și curățenie, și transfer de istoric; companii care se separă sau se împart (carve-out).
Prețul real: este cea mai complexă variantă de coordonat și depinde de instrumente și de consultanți cu experiență specifică. Costă mai mult decât brownfield și cere mai multă disciplină decât greenfield.
Cum se alege?
Patru întrebări te duc, în practică, foarte aproape de răspunsul corect:
- Procesele voastre actuale sunt un avantaj competitiv sau o povară? Dacă sunt o povară, greenfield. Dacă sunt bune și bine rodate, brownfield.
- Cât istoric trebuie să rămână în sistem? Dacă legislația sau business-ul cer zece ani de date interogabile, greenfield devine scump prin ușa din dos.
- Cât timp mai ai până la 2027–2030? Sub optsprezece luni, brownfield e adesea singura opțiune realistă.
- Ai capacitatea internă de a susține o schimbare de procese? Nu bugetul — oamenii. Greenfield consumă timpul celor mai buni oameni ai tăi din business, timp de un an.
De unde vine cererea?
Cum se citește: fiecare companie din barele acestea va cumpăra, în anii următori, între câteva sute și câteva mii de zile-om de consultanță. Bara închisă e o cifră măsurată; cele deschise sunt estimări ale analiștilor, care nu sunt de acord între ei.
Unde e piața în acest moment și de unde vine cererea de specialiști?
| Moment | Încă pe ECC | Natura cifrei |
|---|---|---|
| Final 2024 | ~21.000 | măsurat: circa 14.000 din 35.000 migraseră |
| 2027 | ~17.000 | estimare: 40–48% din bază rămâne pe ECC |
| 2030 | ~13.000 | estimare Gartner: circa 37% încă pe sistemul vechi |
Citește cifrele ca pe o piață, nu ca pe o statistică. Fiecare dintre acele companii va cumpăra, în următorii ani, între câteva sute și câteva mii de zile-om de consultanță. Iar oferta nu ține pasul: într-un sondaj al grupului britanic de utilizatori SAP, 92% dintre companii spuneau că lipsa de competențe S/4HANA le încetinește migrarea, în creștere de la 71% în 2021. O treime spuneau că instruirea primită de la parteneri în timpul implementării a fost „slabă sau foarte slabă”.
Aceasta din urmă e, de fapt, cea mai bună veste pentru tine. Nu doar că e nevoie de oameni — e nevoie de oameni care să explice lucrurile bine. E o piață în care un începător atent și articulat depășește rapid un veteran obosit.
Cererea mare nu înseamnă că vei fi angajat mâine. Piața SAP are o problemă structurală: aproape toate posturile deschise cer „3–5 ani de experiență”, pentru că un consultant slab pe un proiect de migrare costă clientul sute de mii de euro. Ușa de intrare există, dar e îngustă și trece aproape întotdeauna prin cineva care te ia sub aripă: un integrator cu program de juniori, o companie care te promovează din interior, sau un proiect în care ai intrat pe altă ușă. Restul articolului e despre cum ajungi la acele uși.
Harta rolurilor
„Lucrez în SAP” nu spune nimic. Ecosistemul are familii de roluri foarte diferite, cu bariere de intrare, ritmuri de învățare și plafoane diferite. Alege devreme — poți schimba mai târziu, dar primii doi ani îți dau identitatea profesională.
| Rol | Ce faci, concret | Ce trebuie să-ți placă | Intrare |
|---|---|---|---|
| Consultant funcțional FI, CO, MM, SD, PP… | Traduci felul în care lucrează compania în configurarea sistemului. Conduci ateliere, iei decizii de proces, scrii specificații, testezi. | Să vorbești cu oameni. Să înțelegi contabilitate sau logistică. Să scrii clar. | Medie — nu cere programare, cere cunoașterea unui domeniu de business |
| Dezvoltator ABAP / BTP | Scrii ce nu există în standard: rapoarte, interfețe, extensii. În lumea nouă, tot mai mult în afara nucleului, pe platforma cloud. | Programarea. Răbdarea de a citi cod scris de altcineva acum cincisprezece ani. | Medie dacă știi deja să programezi, mare dacă nu |
| Consultant Basis / operare | Ții sistemul în viață: instalări, conversii tehnice, performanță, actualizări, transporturi între medii. | Infrastructura, bazele de date, automatizarea, munca sub presiune de timp. | Mică pentru cine vine din sysadmin sau cloud |
| Specialist date migrare, MDG | Curăți, potrivești și muți datele. Definești regulile după care compania își ține datele de bază curate pe viitor. | Munca meticuloasă cu tabele, SQL, reguli. Toleranța la haos. | Mică–medie; cea mai subestimată ușă de intrare |
| Analist de test / calitate | Construiești planul de testare, urmărești defectele, decizi dacă sistemul e gata de go-live. | Structura, urmărirea detaliilor, comunicarea cu multă lume deodată. | Mică — una dintre cele mai realiste porți pentru începători |
| Securitate și autorizări | Cine ce are voie să facă. În noua interfață, munca aceasta crește mult față de sistemul vechi. | Gândirea în reguli, conformitatea, atenția la risc. | Medie; deficit real de oameni |
| Change & training | Pregătești oamenii: comunicare, materiale, sesiuni practice, sprijin în primele săptămâni. | Predarea, empatia, scrisul. | Mică — dar plafonul salarial e mai jos decât la rolurile tehnice |
| Arhitect de soluție | Ții imaginea de ansamblu: ce intră în sistem, ce rămâne afară, cum comunică totul. | Gândirea de sistem. Nu e un rol de intrare — e o destinație, la 8–12 ani. | Nu se intră direct |
Sfat: Majoritatea începătorilor vor să fie consultant funcțional FI, pentru că e rolul cel mai vizibil. E și cel mai aglomerat: FI/CO, SD și MM formează 70–80% din angajări, deci și 70–80% din concurență. Dacă vrei să intri repede, uită-te la ușile laterale — migrarea datelor, testarea, autorizările. Sunt sub-populate, se învață mai repede, te pun în mijlocul proiectului și îți dau, în doi ani, exact experiența pe care ceilalți o cer.
Cele patru rute de intrare
Drumul corect depinde aproape în întregime de unde ești acum. Iată cele patru rute reale, cu ce presupune fiecare.
Ruta scurtă: ești deja în interior
Dacă lucrezi într-o companie care are SAP — chiar dacă ești în contabilitate, în achiziții sau în depozit — ai avantajul cel mai mare din toată piața și, de obicei, nu îți dai seama. Tu știi deja partea care nu se poate învăța din cărți: cum funcționează compania în realitate, unde se rupe procesul, ce fac oamenii pe lângă sistem.
Ce faci concret: cere să fii key user în proiectul de migrare. Nu aștepta să fii ales. Scrie-i managerului tău că vrei să reprezinți zona voastră. E o poziție pe care companiile se chinuie să o umple, pentru că îi ține pe oameni ocupați suplimentar. Din key user, drumul spre analist de proces și apoi spre consultant funcțional e cel mai bine bătătorit din tot ecosistemul.
Vii din IT
Dacă programezi deja, ABAP se învață în câteva luni — e un limbaj cu sintaxă ciudată, dar cu concepte familiare. Partea grea nu e limbajul, ci contextul: ce înseamnă un document contabil, de ce există trei sisteme, ce e un transport. Ai avantajul că poți intra ca dezvoltator și absorbi contextul din interior, plătit.
Dacă administrezi sisteme, baze de date sau cloud, zona Basis e la o distanță foarte mică de ce faci deja, iar trecerea companiilor la modelul de abonament cloud creează constant nevoie de oameni care înțeleg și operarea, și SAP.
Vii din afara IT-ului
Aceasta e ruta cea mai lungă și cea mai des vândută greșit de școlile de cursuri. Se poate — mulți consultanți foarte buni vin din contabilitate sau din logistică — dar succesul depinde de un lucru pe care reclamele nu-l spun: ai nevoie de un domeniu de business pe care să-l stăpânești deja. Un contabil care învață SAP FI devine valoros repede. Cineva fără niciun domeniu, care învață doar clicurile din sistem, rămâne mult timp la ușă.
Dacă ești în situația asta, prima decizie nu e „ce modul SAP învăț”, ci „ce domeniu de business îmi asum”. Apoi înveți modulul care îl deservește.
Trecerea laterală din consultanță
Dacă lucrezi deja în audit, în consultanță de proces sau în management de proiect, ai jumătate din meserie făcută: știi să conduci o ședință, să scrii un document, să gestionezi un client. Îți lipsește doar produsul. E ruta cu cea mai rapidă rentabilitate, pentru că firmele mari de consultanță au programe interne exact pentru asta.
Ce înveți și în ce ordine?
Cea mai frecventă greșeală a începătorilor: încep cu tranzacțiile din sistem. Înveți douăzeci de ecrane, nu înțelegi niciunul, te plictisești și renunți. Ordinea corectă e inversă — procesul întâi, sistemul după.
Tipuri de angajatori pe SAP
| Unde | Cum e | Bun pentru |
|---|---|---|
| Integrator / partener SAP | Proiecte multe, industrii diferite, învățare rapidă, presiune de facturare, deplasări | Primii 3–5 ani. Aici se acumulează experiență de zece ori mai repede |
| Client final (compania care folosește SAP) | Un singur sistem, cunoscut în profunzime; ritm mai uman; mai puțină varietate | Intrarea prin ușa laterală (key user) și, mai târziu, echilibrul de viață |
| Freelance / contractor | Tarif mare, zero siguranță, zero formare plătită | Doar după 5–8 ani. Nu e o rută de intrare, oricât de tentant sună |
Schimbarea de la ECC la S/4HANA reprezintă oportunitate de carieră
Trecerea de la SAP ECC la S/4HANA nu este doar un proiect tehnic și nici o simplă schimbare de versiune. Pentru companii înseamnă procese redesenate, un model de date diferit și noi moduri de lucru. Pentru tine, poate însemna momentul potrivit să intri în ecosistemul SAP sau să îți repoziționezi cariera în interiorul lui.
Nu trebuie să înveți tot SAP înainte să începi. Mai important este să alegi o direcție și să construiești experiența în ordinea potrivită. Dacă vii din business, poți transforma experiența ta din financiar, controlling, logistică, achiziții, vânzări sau producție într-un avantaj pentru un rol funcțional. Dacă vii din IT, poți merge spre ABAP, BTP, integrare, Basis, HANA sau cloud. Dacă pornești de la zero, drumul este mai lung, dar principiul rămâne același: înțelegi procesele, alegi o zonă, înveți S/4HANA și începi cât mai repede să lucrezi practic.
Nu aștepta să devii „expert” ca să cauți primul proiect. Un sistem de test, un proiect intern, un rol de junior, o academie SAP sau implicarea într-o migrare ECC către S/4HANA îți pot oferi experiența pe care teoria singură nu o poate înlocui.
În următorii ani, întrebarea utilă pentru cariera ta nu este doar „Ce se întâmplă cu SAP ECC?”, ci „Ce rol vreau să am eu în această tranziție?”.
S/4HANA nu elimină valoarea experienței acumulate în SAP. O obligă să evolueze. Iar dacă începi să faci această tranziție înainte să fii obligat de piață, schimbarea din ecosistemul SAP poate deveni una dintre cele mai bune oportunități profesionale pentru tine.
