SAP / ERP
Excel-ből SAP-ba KKV-knak: 6 hónapos roadmap
Mikor érdemes Excel-ből SAP-ba lépni? A 6 hónapos roadmap havonta lebontva, tipikus költségbecslés és 3 valós példa.
2026. február 28.9 perces olvasás
Olvasd elEgy nagyobb hazai cég SAP ECC → S/4HANA brownfield migrációja, amiben alvállalkozói kapacitásként vettünk részt. 8 hónapos projekt, 4 fős core team a megrendelő részéről + 2 fős mi. Ebben a cikkben az 5 legfontosabb tanulság, amit megosztva másoknak hasznos lehet. Plus a tényleges projekt időbontása, kihívások, és mit csináltunk volna másképp.
A 2027-es SAP ECC end-of-mainstream-support közeledése miatt 2026-2027 sok hasonló brownfield-migration éve. Ez a cikk konkrét tanulságokkal segít az előkészületekben.
Az ügyfél és a projekt
Anonimizálva: egy közepes-méretű hazai cég (250+ alkalmazott, 40+ Mrd Ft éves árbevétel), évek óta SAP ECC 6.0-n futott. A 2027-es ECC end-of-support miatt S/4HANA-ra kellett migrálni — brownfield (in-place upgrade) megközelítéssel, hogy a meglévő customizing és adat megőrződjön.
A projekt scope
- From: ECC 6.0 EHP7
- To: S/4HANA 2023 (later 2024 frissítve a projekt közben)
- Modulok: FI/CO/MM/SD
- Custom kódbázis: 80+ Z-program
- Integrációk: 12 külső interface (banki, webshop, partner, EDI)
- User-bázis: 180 named user
- Master data: ~30.000 cikk, ~5.000 vevő, ~2.000 szállító
A csapat
- Megrendelő: 4 fős core team (1 PM, 1 functional lead, 1 ABAP-developer, 1 BASIS-admin)
- Mi: 2 fő alvállalkozóként (1 senior functional, 1 ABAP-developer)
- SAP-konzulens partner: 3 fő külső (Premium support partner)
A háromszintű architektúra
Production (PRD) — élesben futó SAP ECC
↓ brownfield upgrade weekend
Production (PRD) — élesben futó SAP S/4HANA
Quality Assurance (QAS) — UAT, regression testing
Development (DEV) — customizing, transport
Sandbox (SBX) — kísérletek, proof-of-concept
A brownfield különbsége a greenfield-től: a meglévő customizing, master data, transaction history mind megőrződik. Greenfield = új tenant + adat-migráció külön.
A 9 hónap valós időbontása (8 + 1 csúszás)
| Hónap | Fázis | Megrendelő részéről | Mi részünkről |
|---|---|---|---|
| 1 | Discovery | Audit, scope, jóváhagyás | Audit-támogatás |
| 2 | Plan | High-level technical plan | Z-objektum-audit |
| 3-5 | Master data cleanup | 3 fő full-time | 1 fő part-time |
| 6 | Custom code migration | 2 fő (ABAP + functional) | 1 fő ABAP full-time |
| 7 | Integration testing | 3 fő | 1 fő part-time |
| 8 | UAT | 8 key user | UAT-support |
| 9 | Cutover + hyper-care | All hands | 2 fő full-time |
Az eredeti terv 8 hónap volt, a tényleges 9 hónap (1 hó csúszás, főleg master data + Z-objektum-átírás miatt — ld. 1. és 2. tanulság).
1. tanulság: A master data cleanup tovább tart, mint vártuk
A probléma
Eredeti becslés: 4 hét. Tényleges: 11 hét. Ez 177%-os túlcsúszás az adott workstream-en.
Az ECC 6.0-ban az évek alatt felhalmozódott „dirty" data:
- Duplicate vendor — ugyanaz a cég 3-4 különböző record-on (eltérő helyesírás, város, IBAN)
- Inaktív customer — 2010-ben létrehozott, 2018 óta nem használt; soha senki nem törölte
- Hibás cikk-kategória — egy partner export rosszul-mappelt, 2000+ cikk rossz kategóriában
- Formatting inkonzisztencia — IBAN-számok 4 különböző formátumban
- Missing values — kötelező mezők NULL-on, ECC tolerálta, S/4HANA nem
Miért S/4HANA-ban kritikusabb
A S/4HANA business partner-koncepciója szigorúbb: a régi customer + vendor + employee mind egy „Business Partner" entitásba kerül. Ha valaki egyszerre vevő és szállító (közvetítő-cégek), az ECC-ben 2 record volt, S/4HANA-ban 1 — harmonizálni kellett.
Plus a S/4HANA stricter validation-t alkalmaz (kötelező mezők, formátumok), amit az ECC-re feltöltött legacy data nem tudott teljesíteni.
Mit csináltunk?
1. Master data audit script (ABAP)
→ output: 12.000 anomália (duplicate, inkonzisztencia, missing)
2. Anomáliák kategorizálása:
- High priority (vevő, szállító, kritikus cikk): 3000 record
- Medium (inaktív, ritka): 6000 record
- Low (irreleváns historic): 3000 record
3. Cleanup execution:
- High priority: kézi, dedikált 3-fős team (megrendelő pénzügy +
logistics + IT)
- Medium: script-with-human-review
- Low: anonimizáció és archív
4. Test migration sandbox-ra:
- 3 iteration, mindegyik után új cleanup-batch
Tanulság
Brownfield migration master data-cleanup-jára tervezz 2-3x annyit, mint amit elsőre becsülsz. Ha a discovery-ben „4 hét"-et hallasz, planeld 10-12 hetet.
2. tanulság: Custom Z-objektumok migration-jának költségét alábecsültük
A probléma
80 custom Z-program. A SAP Custom Code Migration App felmérése szerint:
| SAP App eredeti becslés | Valós eredmény |
|---|---|
| 60 „green" (zökkenőmentes) | 35 green |
| 15 „yellow" (kisebb módosítás) | 30 yellow |
| 5 „red" (jelentős átírás) | 15 red |
A „yellow" és „red" sávban háromszorozta a tényleges effort-ot. Az SAP App a syntax-level breaking change-eket detektálja, de a runtime-szemantika és a side-effect-ek alábecsülve maradtak.
Mit csináltunk?
1. Priorizálás
→ 5 leg-business-critical Z-program azonosítva (pl. egyedi
számlázási-flow, vámkezelési riport)
→ ezek a release-blocker priority
2. Maradék 75 Z-program kezelése:
- 15 régi Z-program kivontunk (használaton kívüli, business owner
megerősítette)
- 30 yellow Z-program átírása (4-8 óra / db átlag)
- 15 red Z-program újraírása (40-80 óra / db átlag)
- 15 zöld Z-program automatic adaptation
3. Tech debt backlog
→ a kisebb prioritású 25 Z-program „post-go-live" phase-ba
4. Regression-test framework
→ unit testek + UAT-szintű regression minden Z-program-ra
A 5 critical Z-program
| Z-program | Funkció | Estimated → Actual |
|---|---|---|
| Z_VAT_REPORT_HU | Magyar ÁFA-bevallás export | 16h → 24h |
| Z_BANK_SFTP_INTEGRATION | Banki tranzakció-import | 24h → 48h (új OData-flow) |
| Z_CUSTOMS_DECLARATION | Vámkezelési riport | 32h → 60h |
| Z_INVENTORY_BARCODE | Vonalkód-alapú leltár | 40h → 56h |
| Z_PRICING_LOGIC | Egyedi árazási-szabály | 56h → 88h (legnagyobb átírás) |
Tanulság
A SAP Custom Code Migration App ad egy becslés-jelzést, de az alacsony szintű (yellow/red) kód-átírást alábecsüli. Tervezz +50%-ot a Z-objektum-átírási effort-ra.
3. tanulság: Integration mapping kritikus pont — sokkal több időt érdemel mint hittük
A probléma
12 külső interface:
- Banki SFTP (MasterCard, OTP, K&H, Erste — különböző formátumok)
- Webshop REST (Magento → SAP)
- Partner SOAP (3 nagy partner-cég, EDI)
- Beszállítói EDI (ENGDAT, X12)
- Mobil-app webhook (CRM-integráció)
- 3rd party logistika (DHL, GLS)
- Bérprogram-integráció (Nexon CSV-export)
- HR-portál (SuccessFactors → ECC → S/4HANA)
A felmérés szerint mind kompatibilis. Valóságban: 4 interface-en proprietary RFC-modulokat használt az ECC, amelyek S/4HANA-ban deprecated-ek.
A 4 problémás interface
| Interface | Issue | Megoldás |
|---|---|---|
| Magento webshop | RFC alapú custom BAPI | OData service-re átírás |
| K&H banki | Proprietary IDoc | XML-REST endpoint |
| Beszállítói EDI | Z-modul RFC | SAP Integration Suite |
| HR-portál (régi) | Custom RFC-DEST | RESTful endpoint |
Mit csináltunk?
1. Discovery (utólag): mind a 12 interface-en end-to-end test scenario
2. A 4 problémás-t OData/REST-fel cseréltük (egyúttal modernizáltunk)
3. Plusz 3 hét scope, de érdemes volt — a régi RFC-knek nem volt
long-term roadmap-juk
Tanulság
Integration mapping nem felmérés alapján működik — minden interface-t test-environment-en kell letesztelni a sandbox S/4HANA-n a discovery fázisban. A „papíron OK" gyakran „runtime-on bizonytalan".
4. tanulság: Cutover weekend 36 órás work, dokumentált runbook nélkül nem megy
A probléma
Sok kis lépés (35+), mindegyik szigorú sorrendben. Egyik elmaradás → rollback. Az első próba (test cutover) 42 órát vett igénybe; production-on nem férhetett bele 36 órába.
A cutover-runbook iterations
Próba 1 (sandbox): 42 óra
Optimalizálás 1:
- 6 lépés párhuzamosítható
- 3 lépés script-formába átírva
Próba 2 (sandbox): 35 óra
Optimalizálás 2:
- Master data cache pre-warm
- Index-rebuilds párhuzamosítva
- Cutover-cache invalidálás script-en
Próba 3 (sandbox): 31 óra
Production cutover: 28 óra
(Friday 16:00 → Sunday 20:00)
A 35 lépés főbb csoportjai
Phase 1: Pre-cutover (Friday 16:00 → 20:00)
- Old system frozen, user-communication
- Final data extracts
- Sandbox-validation
Phase 2: Database upgrade (Friday 20:00 → Saturday 12:00)
- HANA migration prep
- Schema-conversion
- Index rebuild (parallel where possible)
- Custom code activation
Phase 3: Master data load (Saturday 12:00 → 20:00)
- Business Partner harmonization
- Cleansed master data load
- Validation scripts
Phase 4: Integration test (Saturday 20:00 → Sunday 08:00)
- Each of 12 interfaces tested end-to-end
- Print queue, batch jobs verified
Phase 5: UAT sign-off (Sunday 08:00 → 14:00)
- 8 key user verification
- Critical scenarios run-through
Phase 6: Go-live (Sunday 14:00 → 20:00)
- User access enabled
- Hyper-care war room active
- Monitoring dashboard live
Tanulság
Test cutover legalább 2x, dokumentált runbook commit-olva git-be, párhuzamosíthatóság elemzése. A 35 lépés runbook-ja egy Notion-doc + git-version-elt SQL/ABAP-scriptek.
5. tanulság: Hyper-care 30 nap kevés volt — 60 napra terveztünk
A probléma
Az első 30 napban tipikusan 5-10 ticket / nap. A 31. naptól még mindig 4-5 ticket / nap volt. A scope-ban 30 napos hyper-care volt — extension-t kellett kérni.
Mit csináltunk?
Hyper-care timeline:
Day 1-30: hyper-care fázis 1 (full team, 5-10 ticket/nap)
Day 31-60: hyper-care fázis 2 (csökkentett team, 4-5 ticket/nap)
Day 61-90: warm-support (1 fő part-time, on-call)
Day 91+: standard maintenance contract
A post-go-live retro-call minden hét péntek — a felmerült ticket-eket review-zoltuk, prioritás-szerint kategorizáltuk, és a leggyakoribb 20 ticket-típusra run-book-ot írtunk (megrendelő supportja takeover utánra).
Top 10 hyper-care ticket-típus
| Rank | Issue | Resolution |
|---|---|---|
| 1 | „Régi tranzakciós kód nem található" | User-training-doc update |
| 2 | „Új jelentés-formátum értelmezés" | Új training-session |
| 3 | „Pénzügyi posting-hiba egyedi flow-n" | Customizing fine-tune |
| 4 | „Print form nem jó" | Form-template update |
| 5 | „Workflow approval lassú" | Performance-tuning |
| 6 | „Banki integráció elakad" | Interface-monitoring |
| 7 | „Készlet-leírás duplikációs" | Master data fix |
| 8 | „Riport-export Excel-ben formázás" | XLS-template fix |
| 9 | „RBAC: nincs hozzáférésem X-hez" | Authorization update |
| 10 | „Hibás vendor-adat számlán" | Master data correction |
Tanulság
S/4HANA brownfield migration-re tervezz 60 napos hyper-care-t. KKV-méretű projektre 30 elég lehet, enterprise-on nem.
Eredmények — 6 hónap a go-live után
| Metrika | Előtte (ECC) | 6 hó után (S/4HANA) |
|---|---|---|
| Critical incident (P1) | 1-2 / hó | 0 |
| High incident (P2) | 5-8 / hó | 1-2 / hó |
| Riport-készítés idő (pénzügyi havizárás) | 4-5 nap | 1-2 nap |
| Performance (kritikus tranzakciók p95) | 3-5s | 0.8-1.5s |
| User-elégedettség (internal NPS) | 5.2 / 10 | 7.2 / 10 |
| Master data accuracy | ~85% | ~98% |
| Audit-finding (ISO 9001) | 12 finding | 3 finding |
A performance-javulás a HANA in-memory database-nak köszönhető (30-50% gyorsabbak a kritikus tranzakciók). A user-elégedettség az új Fiori UI-nak.
Konkrét üzleti hatás
- Pénzügyi havizárás 4-5 nap → 1-2 nap. Ez a vezetői döntéshozatal +3 nap fórum-időt ad.
- Audit-finding 12 → 3. Az ISO 9001 audit-folyamat 50%-kal rövidebb.
- Real-time reporting — a heti vezetői dashboard most élő.
Mit csináltunk volna másképp?
1. Discovery-fázis hosszabb
Az 1-hónapos discovery 2-hónaposnak kellett volna lennie. A master data + Z-objektum + integráció felmérés mind alábecsült.
2. Master data team egy hónappal korábban
A 3 fős master data cleanup-team csak a 3. hónaptól indult. Ha az 1. hónaptól dolgozik, a teljes projekt-csúszás elkerülhető.
3. Integration testing dedikált sprint
A 12 interface tesztelése a build-fázis végén történt — 1 hét sprint dedikáltan az 5. hónapban segített volna.
4. Communication-plan a user-eknek
A 180 user 30 nappal a go-live előtt kapott training-meghívót. Ennek 2 hónappal előbb kellett volna jönnie — a tényleges training kezdés is 1 hónappal a go-live előtt indult.
5. „No-customizing" attitűd erősebben
A 25 yellow + 15 red Z-program közül 8-10 talán best-practice flow-val megoldható lett volna. A „de mi mindig így csináltuk" érv néha túl könnyen elfogadódott.
Mire vigyázz, ha most kezdesz S/4HANA brownfield projektet?
Pre-flight checklist
- Discovery 2 hónapra tervezve (nem 1)
- Master data audit script futtatva, anomáliák kategorizálva
- Custom code audit a SAP App-pal + manuális review
- Integration interfacek mind sandbox-on tesztelve
- Cutover runbook drafted (igen, már a discovery-ben)
- Hyper-care budget 60 napra
- Test cutover legalább 2x
- User-communication plan 8 héttel a go-live előtt
Budget contingency
- +15% time contingency a master data-cleanup-ra
- +25% effort contingency a Z-objektum-átírásra
- +1 hét contingency az integration testing-re
Hivatalos doc-ok és további olvasmányok
- SAP S/4HANA Conversion Guide — official
- SAP Custom Code Migration App — code-readiness analysis
- SAP Readiness Check — pre-migration audit
- SAP Activate methodology — implementation framework
- Hungarian SAP User Group — közösség
Témához kapcsolódó saját cikkeink: Excel-ből SAP-ba KKV-knak — greenfield-implementation roadmap. AI implementáció magyar KKV-knál — ERP + AI-pipeline integráció. Hogyan dolgozunk remote-ban — projekt-management.
Lezárás
S/4HANA brownfield migration nem egyszerű projekt. A „in-place upgrade" név félrevezető — az adatmigráció és a custom code refactoring akár 50%-át kiteszi a projekt-effortnak.
A legfontosabb tanulság ezekből az anonimizált projekt-tapasztalatokból: tervezz buffer-t mindhárom kritikus területen — master data, custom code, integration. Egyik sem becsülhető pontosan a discovery során, és mindhárom 2-3x annyi időt vesz igénybe, mint amit a SAP-tool-ok becsülnek.
Ha SAP S/4HANA migrációt tervezel, kezdjük egy discovery-call-lal — az első hónap pontosan a buffer-területek azonosítása. A 200-400k Ft-os discovery-cost gyakran megspóroltatja a 20-50M Ft-os utólagos scope-creep-et.