Oracle EBS R12 verzióváltó projekt tapasztalatai a Rábánál Nagy Tamás, Rába Járműipari Holding Nyrt. Baranyay Péter, T-Systems Magyarország Zrt. HOUG Konferencia, Siófok, 2014.03.24. 1
Tartalom Röviden a Rábáról és annak Oracle rendszeréről Az R12 projekt bemutatása Célkitűzések Terjedelem Szervezet Ütemezés Kihívások a bevezető csapat számára Verzióváltás Éles indulás utáni tapasztalatok A projekt értékelése tanácsadói szemmel Oracle támogatással kapcsolatos tapasztalatok Sikeres projekt feltételei Megszólal a projekttag Javaslatok a verzióváltó felhasználók, tanácsadók és az Oracle számára 2
A Rába Csoport Rába Járműipari Holding Nyrt.* Alapítva 1896 Fő adatok 2011 (IFRS, auditált) 2012 (IFRS, auditált) Rába Futómű Kft. Üzletágak Rába Járműipari Alkatrészgyártó Kft. Rába Jármű Kft. Ingatlan Árbevétel: 39 379 m HUF 42 346 m HUF EBITDA: 3 833 m HUF 3 490 m HUF Létszám: 1 962 1 904 Közepes sorozatú komplett futóművek, nagysorozatú futóműalkatrészek haszongépjárművek számára Személygépjármű fém alkatrészek a régió piacára Alkatrész 21% Jármű 13% Speciális járműgyártás Futómű 66% Nem termelő ingatlanok hasznosítása * Budapesti Értéktőzsdén jegyzett 3
Legjelentősebb vevőink 4
Röviden a Rába informatikáról 2004.01.01. óta outsourcing, teljes IT kiszervezésre került Hosszútávú, stratégiai szolgáltatási szerződés, SLA-k (Service Level Agreement szolgáltatási szint megállapodások) Rábánál 4 fős csapat maradt Fő feladat: szolgáltatásmenedzsment, biztonsági kérdések, fő Oracle üzleti folyamat felelősök (key user, modulgazda) Mintegy 500 számítógépes munkahely 3 telephelyen (Győr, Mór, Sárvár) Több, mint 200 Oracle felhasználó Főbb IT szoftverek: Microsoft, Oracle EBS, Piramis (bérelszámolás), artflow/artoffice (dokumentum- és számlakezelés), Creo/Windchill CAD-es tervezőprogram 5
OF rendszer bevezetés, 1995-96 OM bevezetés a Futóműben, 2000-2002 (COPICS lecserélése) Oracle alkalmazások története és bevezetési tapasztalatok a Rábánál OF továbbfejlesztés, cash management, konszolidációs főkönyv, OFA fejlesztés, 2002-2003 OM kiterjesztés a többi leányvállalatra (Jármű, Motor, Sárvár), 2002-2003 OM folyamataudit, 2004 Oracle EAM (karbantartás), 2005 Oracle 11i upgrade, 1. fázis 2007-2008 Oracle Hungary (első komoly magyar projekt) Konzorcium: Accenture Oracle - Compaq Oracle + külső partnercég +Rába Rába számítóközpont saját szakemberei Oracle Hungary Integris (később IQSYS, ma T-Systems része) Integris fővállalkozás, Oracle tanácsadók és Oracle projektvezetés 2-3. fázis, 2008-2009 Iqsys (EAM integráció, WMS) és Oracle (isp, RLM) Az OM bevezetése a móri gyárban, 2010 WMS modul bevezetése a Futómű Kft-ben, 2011 Oracle EBS R12 technikai upgrade, 2013 Iqsys Iqsys TSM fővállalkozás, Oracle projektvezetés, TSM- Oracle tanácsadók, TSM-Innovent technikai team 6
Rába Járműipari Holding Nyrt. és leányvállalatai Oracle folyamatai Pénzügy, Számvitel (GL, AR, AP, FA, CM) Beszerzés Gyártás Értékesítés Beszerzés igények Anyagszükséglet tervezés Gyártás tervezés Vevői igények Beszerzési Rendelések Gyártás ütemezés Karbantartás Vevői rendelés Beszerzési bevételezések Gyártás kiadása Gyártás lejelentés Szállítás Számlázás MIBI MIBI Beszállítói konszignáció Vásárolt és saját készlet Alapadatok: Készlet - BOM - Költség Vevői konszignáció Szállító BOM Cikkek Vásárlók Keret megállapodás Szállítmányozás Költségek Árlisták 7 7
Oracle Pénzügyi folyamatok Bank Kötelezettségek kezelése Bankkivonat feldolgozás Pénzgazdálkodás Készpénz előrejelzés Kinnlevőségek kezelése Kifizetések Számlatükör definiálása Főkönyvi könyvelés IFRS GL HUF Behajtási tevékenység Befolyások Számlák kezelése Konszolidálás és IFRS Vevői számlák kezelése Szállítók karbantartása Eszközök nyilvántartása Eszközgazdálkodás Értékcsökkenés Vevők karbantartása Beszerzés SCM Készlet SCM 8 Gyártás Operáció Megrendelések Értékesítés
Rába Nyrt. működési modell Oracle vállalati struktúra Vállalati struktúra Rába Járműalkatrészgyártó Kft. Rába Járműipari Holding Nyrt. Üzletágak Rába Futómű Kft. Rába Jármű Kft. Ingatlan HR, GL, ASCP DBI, ECG Szállítók Üzleti egység Vevők OM, AR, PO, AP, CM FUT KOV EKR SZE BKR KAR Rába Futómű Kft logisztikai struktúra WMS MSCA Raktár Raktár Raktár Tároló hely Tároló hely Tároló hely INV, CST, BOM MRP 9
Rába R12 projekt verzióváltás célja Oracle OR12 projekt - Technikai verzióváltása Oracle OR12 projekt - Fejlesztések verzióváltása Fejlett ellátási lánc tervezési rendszer Gyártásban lévő munkák rendszere Költséggazdálkodási rendszer EDI kapcsolatok kiterjesztése Minőségbiztosítási rendszer Szerszámüzemi gyártás Rendelés nyilvántartás Készpénzgazdálkodás Release management Készletgazdálkodás Fejlesztési rendszer Beszerzési rendszer Mobil alkalmazások Kötelezettségek Raktárirányítás Kinnlevőségek Anyagjegyzék Tárgyi eszköz Szállító portál Karbantartás Kiszállítás Főkönyv DBI A projekt teljesítette a Rába által korábban használt Oracle EBS 11.5.10.2 rendszerének technikai verzióváltását R12.1.3-es verzióra. 10 Külső rendszerek és kapcsolatuk az Oracle alkalmazással: Banki interfész (CIB, Commerzbank, KHB és Raiffeisen) PIRAMIS bérelszámolási rendszer: ArtOffice/ArtFlow dokumentumkezelő rendszer: Rába specifikus fejlesztések vállalatonként Gyártó- és mérőeszköz nyilvántartás (GYESZK-MESZK) Futómű Szerszámigény tervezés Futómű Befejezetlen leltár Rába csoport Műhelyhatékonysági rendszer Alkatrész Mór Rába egyedi fejlesztései/riportok: A fejlesztések felülvizsgálata során verzióváltásra kijelölt fejlesztések száma 335 Oracle által patch formájában biztosított ÁFA lokalizációk leszállítása
Rába Oracle EBS R12 verzióváltó projekt Időtartam: 2013. április 2014. február (Go live 2014.01.06. Támogatás az első hónap sikeres zárásáig) Fővállalkozó T-Systems, bevonásra került az Oracle Hungary és az Innovent Oracle projektvezetés, TSM (17 modul) és Oracle tanácsadók (7 modul), TSM és Innovent technikai és fejlesztő team, Rába modulgazdák és szakértők 112 fős projektcsapat Technikai átállás időtartama: 135 óra (5 nap, 15 óra), 58 fő dolgozott és/vagy tesztelt Projekt terjedelem: 4 Rába társaság, 20 készletszervezet, 6 pénzügyi modul, 18 sztenderd SCM modul, 4 Rába specifikus fejlesztett almodul, 3 szoftverinterfész (banki, bérelszámolás, dokumentumkezelés) Oracle részéről végig kiemelt figyelem a projekt irányában (konzultáció és támogatás is, Critical Account Manager) 11
Rába R12 Projektszervezet Oracle képviselője Oracle - Moczó István Projektszponzorok Rába - Balog Béla T-Systems Bonifert Csaba Projekt Irányító Bizottság Projekt vezetés T-Systems - Krausz Katalin Rába - Nagy Tamás Rába funkcionális és területi vezetők: Rába Farkas Ákos, Plutzerné Gacs Katalin Alkatrész Urbányi László Alkatrész Mór - Czetli Imre Alkatrész Sárvár - Bányik Sándor Jármű Torma János, Dr.Dimény Zsuzsanna Futómű Kocsis Sándor, Steszli Ádám, Polgár Szilárd TSM Könyvelés vezető: Téringer Lajos Technikai Támogató Team vezető Kósa György Projekt Támogató Iroda Projekt Asszisztens Rába - Kantó Károly Műszaki Technikai Architekt T-Systems Berecz Ákos Minőségbiztosítási szakértő Paár János Rendszer Változtatás Kezelési Team Baranyay Péter Technikai Verzióváltás Team vezető Törő Krisztián Fejlesztési Team vezető 1 Paárné J. Judit Fejlesztési Team Point vezető 2 Törő Krisztián Pénzügyi Pénzügyi funkcionális Tanácsadók Tanácsadók és modulgazdák Rába pénzügy modulgazdák Tervezési Funkcionális Tanácsadó Rába tervezési modulgazda Termelési funkcionális Point Tanácsadók Rába termelési Point modulgazdák Logisztikai Funkcionális Tanácsadók Rába logisztikai modulgazdák DBI funkcionális Tanácsadó Rába DBI modulgazda 12
Rába R12 Projektterv à Projekt feladatok végrehajtása 13
Kihívások a bevezető csapat számára 1 11i éles rendszer változások követése Ø A projekt kezdetétől május végéig a 11i rendszeren még 22 módosítást kellett végrehajtani + Rába arculatváltás Új funkciók használatba vétele Ø Az 1. fázisban összesen 48 új funkció lett meghatározva, melyekből Rába végül 33-t vett használatba 10 9 8 7 6 5 4 3 2 1 0 MOAC ADÓ SLA Keresztdokkolás Kifizetések Vevő Szállító Karbant. ktgek aktiválása Sorozat alapú anyagigény Sorozatjellemző Belső rend. Belső igény Beszerz. munkakp. Készletállapot Munkaerőkezelő rdsz. Raktári vezérlőpult Összes Igényelt 14
Kihívások a bevezető csapat számára 2 R12-ben történt változások megfeleltetése a 11i rábás folyamatokhoz Ø Adókezelés Ø Közös partner törzs Ø Szállítói számlák architektúra változása Ø Bankszámlák Ø Fizetési felszólítások Ø Kifizetések Ø SLA Egyedi fejlesztések verzióváltása Ø 4 ütemben, az üzletileg kritikus fejlesztéseknek el kellett készülnie az 1. felhasználói tesztelésre Külső rendszerkapcsolatok verzióváltása Ø Nagyobb technikai változások voltak a kapcsolódási pontokban (szállítói számla, vevő/szállító, kifizetések) Éles üzemi támogatás Ø Éles indulás után a kritikus hibák gyors elhárítása 15
Technikai verzióváltási feladat Kiinduló állapot: Oracle EBS 11.5.10.2-es verzió RDBMS 10gR2 Operációs rendszer: Red Hat Linux 4 x86 32 bit Összesen 24 CPU mag, 48 GB memória, 4 szerver node Cél állapot: Oracle EBS 12.1.3 RDBMS 11gR2 Operációs rendszer: Oracle Enterprise Linux 5.4 x86 64 bit, Összesen: 48 CPU mag, 192 GB memória, 4 szerver node Választott módszer: Adatbázis export a forrás rendszeren Adatbázis import a cél rendszeren, közben adatbázis verzióváltás 11gR2-re EBS technikai upgrade 12.1.1-re EBS patchelés 12.1.3-ra 16
Technikai verzióváltás folyamata Az E-Business Suite verzióváltása három iterációban/ szakaszban történt: 1. Teszt verzióváltás A ténylegesen elvégzendő illetve kihagyandó feladatok pontos összeállítása Tesztelés, lehetséges hibák felderítése, kerülő megoldások kidolgozása Feladat optimalizálás Eredményként előállnak: Ø a projekt fejlesztői és teszt környezetei Ø a performancia teszt verzióváltás nagyvonalú ütemterve, teendői 17
Technikai verzióváltás folyamata 2. Performancia teszt verzióváltás: A ténylegesen elvégzendő feladatok finomítása, véglegesítése Stopper a kézben Nagyon pontos és részletes dokumentáció készítése, kiadandó parancsokkal, manuális és gépi tevékenységek idejének dokumentálása Tesztelés, folyamat optimalizálás Top 10 időigényű feladat elemzése, átszervezése, párhuzamosítása, gyorsítása Eredményként előállnak: Ø a projekt frissített fejlesztői és elfogadó teszt környezetei Ø az éles teszt verzióváltás pontos és részletes ütemterve, teendői 18
Technikai verzióváltás folyamata 3. Éles verzióváltás: Lehető legrövidebb átfutási idő Feladatvégzés a részletes ütemterv és feladatlista alapján 3 műszakban, éjjel-nappali non-stop munkavégzés 2013. december 27-2014. január 3. között A projekt menedzsment és a földrajzilag különválasztott csapattagok folyamatos tájékoztatása az előrehaladásról Adatbázisok 11i 12 Növekmény ASCP adatbázis méret 132 GB 173 GB 41 GB ERP adatbázis méret 573 GB 715 GB 142 GB 4. Egyedi fejlesztések verzióváltása folyamatosan: A technikai verzióváltással csak a rendszer sztenderd komponensei kerültek át az új verzióra. A 11i verzióra fejlesztett 400 egyedi fejlesztés R12-ben való működőképességét külön biztosítani kellett. 19
Felmerült feladatok és feltárt hibák kezelése Oracle Supportnak bejelentett SR-ek száma (A projekt 2013.04.22- én indult) Ado9 időpontban nyito9 SR- ek KriAkus Fontos Közepes Új, vagy nem kategorizált bejelentés Ado9 időpontban összes lezárt bejelentés 5- Nov 25 3 13 9 65 11- Nov 34 3 20 11 78 20- Nov 31 2 17 11 82 21- Nov 28 2 14 12 85 26- Nov 28 1 13 11 87 28- Nov 27 1 15 11 91 4- Dec 31 1 16 14 98 17- Dec 25 1 12 12 109 18- Dec 26 1 13 12 110 18- Dec 18 1 5 12 111 7- Jan 19 1 4 14 119 13- Jan 19 0 6 16 123 21- Jan 22 0 6 16 130 27- Jan 20 0 7 13 135 11- Feb 24 0 6 18 145 18- Feb 25 0 7 18 150 26- Feb 24 0 5 14 157 10- Mar 26 0 5 21 164 20
Létrehozott SR-ek száma modulonként 25 20 15 10 5 0 ALL AP AR ASCP CST DBI EAM ECG ENG FA GL INV isup OM PO QM RLM TAX WIP WMS/MSCA 21
Telepített one-off patchek modulonként 25 20 15 10 5 0 22
Projekt értékelése tanácsadói szemmel Funkcionális működés sikeres verzióváltása (10 tanácsadó, 15 modulgazda): Ø 24 modul, 3 külső kapcsolat Ø ~100 fő üzleti folyamat, Ø ~3300 üzleti funkció, Ø 34 új funkció, Ø 400 egyedi fejlesztés Technikai verzióváltás sikeresen és elfogadható idő alatt (4 DBA) Ø 185 óra è 160 óra è 135 óra Egyedi fejlesztések verzióváltása sikeresen és időben (3 + 6 fejlesztő) Ø 400 egyedi fejlesztés, több mint 60 bonyolult 23
Oracle támogatással kapcsolatos tapasztalatok My Oracle Support (Knowledge) használata (setup beállítások, kész patchek letöltése) Oracle Configuration Manager használata Service Request bejelentések Eszkaláció kérések (első és másod szintű) Oracle Hotline Kiemelt SR kezelés (7*24 felügyelettel vagy anélkül) Oracle Web Conference szervezése Proaktív projekt monitorozási kérelem Critical Account Manager belépése Lokalizáció Fordítások, egyre rugalmasabban, helyi NLS szakértővel egyeztetve 24
Egy sikeres verzióváltási projekt feltételei A vállalat felső vezetésének elkötelezettsége a projekt iránt, megfelelő projektszponzor kinevezése A legjobb szakemberek delegálása a projektbe A kiemelt felhasználók elkötelezettsége és aktív részvétele a projektmegvalósításban Megfelelő kompetenciával rendelkező bevezető/tanácsadók rendelkezésre állása Projekt terjedelmének, célkitűzéseinek és ütemezésének betartása A projekt eredményességéhez fontos kérdések azonosítása Annak megvilágítása, hogy több és hatékonyabb információ kinyerése csak több és precízebb adatbevitellel érhető el Teljesíthető mérföldkőterv, időben történő döntéshozatal Világosan megfogalmazott célok, egyeztetett projekt-terjedelem Jó projektvezetés és módszertan Megfelelő munkafeltételek Oktatás az új folyamatokra és/vagy funkciókra Tesztelés, tesztelés..integrációs tesztelés 25
Pozitívumok A csoportok jól együtt tudtak dolgozni, a részletesen leosztott, egyértelműsített feladatok végrehajtása hatékony volt Alapvetően jól tudtunk kommunikálni. Megtaláltuk a közös hangot és csatornát Rába szakértők terhelhetőek voltak és segítőkészek Tanácsadóim szakmai, emberi hozzáállásával, segítőkészségükkel maximálisan elégedett voltam. mindenki felelősségteljesen segítette a másik munkáját (modulgazdákról) Dokumentáltság részletes Negatívumok E-mailes kommunikációban a Válasz mindenkinek gombot kevesebbszer kellett volna alkalmazni Az írásos kommunikáció alapos volt, de több esetben nem volt elég hatékony hatékonyabb lett volna több közös egyeztetés a Rába-tanácsadókfejlesztők között A tagvállalati szakértők nem minden esetben voltak együttműködőek. Funkcionális oldalon sok munkát kellett beletenni a kollégáknak, amire nem lehetett felkészülni Moduloktól függően voltak túl aprólékos és nagyon felületes adatteszt forgatókönyvek is Dokumentáltság részletes A riportok többsége határidőre elkészült a kimutatások átdolgozását másképpen csináltam volna alapos Projekt értékelése tanácsadói és modulgazdai vélemények ( Megszólal a projekttag ) de nem mindenre kiterjedő volt (a tanácsadói tesztelések hatékonysága) 26
Javaslatok a felhasználók számára egy jövőbeni projektre való hatékonyabb felkészüléshez Időbeni felkészülés a projekt testreszabással kapcsolatos igényeire (saját feldolgozások logolása, használati statisztika), és ezek minimalizálása További törekvés a csoporton (szervezeten) belüli üzleti folyamatok egységesítésére Az új verzió sajátosságainak időbeni megismerése (önképzés, tanácsadói konzultáció), felkészülés az esetleges változások, vagy más működés következményeire Szakértői csapat felkészítése (ne a projekt legyen a betanulási folyamat, ahogy néhány esetben előfordul) Az esetleges felhasználói oldali változtatási igények nagymértékű korlátozása Törekvés a legritkábban alkalmazott tranzakciók, üzleti folyamatok teljeskörű kitesztelésére is A legkülönbözőbb kapcsolódó folyamatokra,modulokra épülő integrációs tesztforgatókönyvek összeállítása 27
Javaslatok a tanácsadók számára egy jövőbeni projektre való hatékonyabb felkészüléshez A tanácsadók, mint erőforrások hatékony allokálása (szakértelem és feladat alapján) Több keresztfunkciós team megbeszélés a személyes kapcsolatok javítása és a közvetlenebb információáramlás érdekében Jobb felkészülés az új verzió újdonságainak, megváltozott funkcióinak megismerése érdekében, az esetleges változások, vagy másfajta működés következményeinek felmérése Az összefüggések előrelátása - a megváltozott tulajdonságok vagy újdonságok használhatóságának javítása érdekében (pl. MOAC és a riportok kérdése) Nagyobb proaktivitás, kevesebb sablon A vevőnek (felhasználónak) is lehet igaza elv elfogadása Törekvés a legritkábban alkalmazott tranzakciók, üzleti folyamatok teljeskörű kitesztelésére is Az integrációs tesztek fontosságának hangsúlyozása Az Oracle szupport hatékony használata 28
Javaslatok az Oracle számára (egy felhasználó szemszögéből) Termék: törekvés a ZDQ ( Zero Defect Quality ) alkalmazására (modulonként 10-20 javító patch egy upgrade projektben nagyon soknak tűnik) Támogatás: Célszerűnek tartjuk megfontolni, hogy magyarországi szupport legyen legalább a lokalizált moduloknál és/vagy funkcióknál (ÁFA-kérdés sok problémát okozott az R12 upgrade esetében, mai napig vannak nyitott kérdések) Konzultáció: Oracle szervezhetne felkészítéseket saját és partner tanácsadóknak verzióváltások előtt, ahol az új verziók újdonságaira, a legfontosabb változásokra, esetleg a megszűnő funkciókra felhívják a figyelmet Oktatás: Oracle alkalmazásokra is legyenek meghirdetett oktatások, amelyek testre szabhatóak (a meghirdetett oktatások főleg technológiai vagy adatbázis jellegűek) 29
Köszönjük a figyelmet! Kérdések?? 30