Mind az SAP, mind a bevezető cégek kommunikációjában hangsúlyos elem, hogy a meglévő R/3-as verzió támogatása várhatóan 2025-től megszűnik. Elindult a találgatás: a 2025 valóban 2025? És ha megszűnik a támogatás, akkor vajon leáll az SAP-nk?
Természetesen a határidő lejártát követően is lehet még egy darabig üzemeltetni a meglévő rendszereket. Még akkor is, ha komoly vállalatok számára jelentős működési és megítélésbeli kockázatot jelent támogatás nélküli alaprendszerrel üzemelni. És az is elképzelhető, hogy egy-két évvel kitolják majd a 2025-ös végdátumot.
Ugyanakkor az is legalább ekkora veszély, hogy lesz-e elég tanácsadói kapacitás a piacon, amikor a határidő lejárta előtt hirtelen észbe kapnak a cégek, és tömegével indítanak S/4HANA projekteket. Ez egy olyan kényszerítő erő, ami miatt egyre több vezető ismeri fel, hogy időben kell előkészíteni a transzformációs programokat.
De ez a kényszer lehetőség is. Az S/4HANA bevezetés, ha jól csinálják, egy igazi transzformációs program. Olyan beavatkozás, mely lehetőséget ad a szervezet alapvető működésének újragondolására.
A legtöbb vállalatnál meglévő ERP rendszerek a 20-30 évvel ezelőtti üzleti sajátosságokat képezték le. Ezek a rendszerek mára elavultak, hiszen a legtöbb cég a „menet közben ne cseréljünk kereket” elv alapján csak minimális változtatásokat hajtott végre. Most azonban itt a lehetőség, hogy a bokszutcába kiállva ne csak a kereket, hanem a motort is kicseréljük.
Rossz hír viszont, hogy a lehetőség mellett van egy jelentős veszély is: ha a meglévő állapotokat konzerváljuk. Ha az S/4HANA bevezetés semmi másról nem szól, mint hogy a szoftver névjegyén R/3 helyett most már S/4 szerepeljen. Ha az új rendszerben ugyanazokat az elavult folyamatokat és struktúrákat képezzük le, mint ezelőtt 20-30 évvel.
Ha az S/4HANA bevezetés előtt nem gondoljuk újra a működésünket, akkor a marketinganyagok százaiban hangoztatott előnyök közül leginkább csak az fog megvalósulni, hogy a HANA adatbázismotor miatt gyorsabban futnak majd a meglévő funkciók.
A kérdés tehát ez: miként kerülhetjük el a veszélyt, hogy nem tudjuk maradéktalanul kihasználni a lehetőséget?
Az S/4HANA bevezetési projektek egyik legfontosabb lépése, hogy meghatározzuk a rendszerben leképezni kívánt üzleti folyamatokat. Módszertani szempontból nagy jelentősége van annak, hogy a célállapot (to-be) meghatározását honnan indítjuk:
A legtöbb cég az S/4HANA bevezetés előtt célként tűzi ki, hogy minél kevésbé térjen el az SAP standardoktól. Ez a bevezetés során kevesebb rendszerfejlesztést, az üzemeltetés során könnyebb karbantarthatóságot jelent. Ugyanakkor sokan közülük úgy járnak el a „to-be” folyamatok meghatározásakor, hogy előtte hónapokat fordítanak a meglévő állapot felmérésére és dokumentálására. A pszichológiából ismert horgonyhatás miatt ez a megközelítés azt eredményezi, hogy a leendő megoldás, bár elmozdul a legjobb gyakorlatok felé, mégis a jelenlegi állapothoz marad közel.
Ha tehát a jelenlegi folyamatokból vezetjük le a célállapotot, azzal a meglévő problémák többségét is konzerváljuk. Ráadásul mind a folyamatfelmérés, mind a fejlesztés sok ideig fog tartani, s végül egy egyedi fejlesztésekkel teli, nehezen karbantartható rendszert kapunk.
Ehhez képest sokkal kívánatosabb eredményt hoz, ha a legjobb gyakorlatokból kiindulva határozzuk meg a kialakítandó folyamatokat. A módszer elméletileg egyszerű: a legjobb gyakorlatot valósítjuk meg, kivéve azokat az eseteket, ahol a vállalat stratégiája és üzleti modellje feltétlenül indokolja, hogy eltérjünk attól.
Ez a megközelítés lehetővé teszi, hogy tiszta lappal kezdjünk: fejlesszük a folyamatainkat, és egy olyan rendszert valósítsunk meg, mely a standardhoz közel áll, és biztosítani tudja, hogy az ígért előnyök (pl. kevesebb modulközi egyeztetés, gyorsabb hóvégi zárás, valós idejű beszámolók) .
Persze két dologra mindenképp szükség van, hogy a legjobb gyakorlatoktól indított megközelítés működhessen:
Érdemes ezek meglétét a bevezetést támogató partnertől is elvárni.
Sok vállalati terület van, ahol a folyamatok, az egyes tevékenységek egymásutánisága alapvetően határozzák meg a vállalat működőképességét. Egyes területeken viszont a rendszerben leképezendő struktúráknak is legalább akkora jelentősége van.
E struktúrák egy része olyan, hogy az S/4 bevezetési projekttől függetlenül is újragondolhatták (volna) a cégek. Gondoljunk csak bele, hány vállalat küzd azzal, hogy az évek során túlszaporodtak a termékei és átláthatatlanná vált a cikktörzs. Olyan eset is előfordult, hogy nem tudtak új költségnemet létrehozni, mert kimerült a számkör. Az is gyakori, hogy a különböző adatbázisokban, leányvállalatoknál meglévő törzsadatok nem állnak egymással összhangban.
Az ilyen struktúrák rendbe tételéhez nincs szükség S/4HANA projektre. Ugyanakkor kétségtelen, hogy a bevezetés van akkora beavatkozás, ami egyben lehetőséget nyújt a régóta halogatott feladatok pótlására is.
Az átgondolandó struktúrák másik része viszont kifejezetten az új rendszerhez kapcsolódik. Az S/4HANA megalkotásakor az SAP radikálisan átalakította az adatmodellt. A rendszer mélyén új alapokra helyezett logikák dolgoznak, melyekhez újfajta struktúrák is kapcsolódnak. Erre jó példa a controlling területéről a kalkulatív (costing based) és a számviteli (account based) eredménykimutatás dilemmája. Korábbi cikkünkben részletesen foglalkoztunk vele, miért alapvető fontosságú, hogy tudjuk-e alkalmazni a számviteli típusú eredménykimutatást.
Az ilyen rendszerspecifikus eldöntendők alapjaiban határozzák meg, hogy a leendő S/4HANA rendszerünk milyen előnyöket tud majd biztosítani számunkra. Ezért nagy felelősség hárul a bevezetést támogató partnerre, hogy ezeket a döntési pontokat kellő körültekintéssel segítsen előkészíteni.
Cikkünkkel azt is szeretnénk érzékeltetni, hogy az S/4HANA bevezetés nem ott kezdődik, amikor a fejlesztői környezet előáll, és a feltelepítik a szoftvert. Az S/4HANA bevezetés a vállalat elmúlt éveinek legnagyobb transzformációs programja. Kulcsfontosságú, hogy jól átgondoltan vágjunk bele, hiszen a program puszta mérete miatt is könnyű belebukni.
Az előkészítés egyik hasznos eszköze, ha egy külön projekt keretében meghatározzuk a program terjedelmét. Egy ilyen scoping során ki lehet jelölni azokat a folyamatokat, melyekkel egyáltalán foglalkozni szeretnénk, ugyanis nincs minden vállalati tevékenységnek SAP-érintettsége. A terjedelemben maradt folyamatok feldolgozását pedig érdemes munkacsomagokba, ütemekbe sorolni. Ez segít megfoghatóbbá tenni az egyébként nagy és összetett kérdést.
Szintén jó ötlet már a program indulásakor tréninget, konzultációs lehetőséget biztosítani a vezetők, munkatársak részére. Ez segít abban, hogy megismerjék az S/4HANA nyújtotta lehetőségeket, és a rendszertervezés során tudatosan hozhassanak döntést meghatározó kérdésekben.
Magát a folyamatok és struktúrák újragondolását pedig érdemes összekötni egy átfogó programtervezéssel. Az a cél, hogy a következő évekre rendelkezésre álljon egy útiterv, mely bármely negyedévre megmutatja, hol kell tartanunk, mivel kell foglalkoznunk. Cél az is, hogy a határidőt tartva, megfelelő üzleti tartalommal indulhasson el az új rendszerünk és működésünk.
A szerző az IFUA Horváth & Partners vezető tanácsadója
