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.* Üzletágak
Alapítva 1896 Fő adatok 2011 (IFRS, auditált) 2012 (IFRS, auditált)
Rába Futómű Kft.
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
Közepes sorozatú komplett futóművek, nagysorozatú futóműalkatrészek haszongépjárművek számára
Létszám:
Személygépjármű fém alkatrészek a régió piacára Jármű Alkatrész
21%
1 962 1 904
Speciális járműgyártás
* Budapesti Értéktőzsdén jegyzett
3
13%
Futómű 66%
Nem termelő ingatlanok hasznosítása
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
Oracle alkalmazások története és bevezetési tapasztalatok a Rábánál OF rendszer bevezetés, 1995-96
Oracle Hungary (első komoly magyar projekt)
OM bevezetés a Futóműben, 2000-2002 (COPICS lecserélése)
Konzorcium: Accenture – Oracle - Compaq
OF továbbfejlesztés, cash management, konszolidációs főkönyv, OFA fejlesztés, 2002-2003
Oracle + külső partnercég +Rába
OM kiterjesztés a többi leányvállalatra (Jármű, Motor, Sárvár), 2002-2003
Rába számítóközpont saját szakemberei
OM folyamataudit, 2004
Oracle Hungary
Oracle EAM (karbantartás), 2005
Integris (később IQSYS, ma T-Systems része)
Oracle 11i upgrade, 1. fázis 2007-2008
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
Iqsys
WMS modul bevezetése a Futómű Kft-ben, 2011
Iqsys
Oracle EBS R12 technikai upgrade, 2013
TSM fővállalkozás, Oracle projektvezetés, TSMOracle 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
Beszerzés igények
Anyagszükséglet tervezés
Beszerzési Rendelések
Gyártás ütemezés
Beszerzési bevételezések
Gyártás kiadása
Gyártás tervezés
Karbantartás
Gyártás lejelentés
MIBI Beszállítói konszignáció
Értékesítés Vevői igények
Vevői rendelés
Szállítás
Számlázás
MIBI Vásárolt és saját készlet
Vevői konszignáció
Alapadatok: Készlet - BOM - Költség 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
Pénzgazdálkodás Bankkivonat feldolgozás
Kifizetések
Főkönyvi könyvelés Számlatükör definiálása
Számlák kezelése
Szállítók karbantartása
Beszerzés SCM
Készpénz előrejelzés
Behajtási tevékenység
GL HUF Befolyások
IFRS
Konszolidálás és IFRS
Vevői számlák kezelése
Eszközgazdálkodás Eszközök nyilvántartása
Készlet SCM
Kinnlevőségek kezelése
Értékcsökkenés
Gyártás Operáció 8
Vevők karbantartása
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űipari Holding Nyrt. Üzletágak
Rába Járműalkatrészgyártó Kft.
Szállítók
FUT
KOV
Rába Futómű Kft.
Rába Jármű Kft.
Üzleti egység
Vevők
EKR
SZE
Rába Futómű Kft logisztikai struktúra
WMS MSCA
KAR
Raktár Tároló hely
9
OM, AR, PO, AP, CM
BKR
Raktár
Ingatlan
HR, GL, ASCP DBI, ECG
Tároló hely
Raktár Tároló hely
INV, CST, BOM MRP
Rába R12 projekt verzióváltás célja Oracle OR12 projekt - Fejlesztések verzióváltása
Oracle OR12 projekt - Technikai 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
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
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
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 Projektszponzorok
Rába funkcionális és területi vezetők:
Rába - Balog Béla T-Systems – Bonifert Csaba
Oracle képviselője
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
Projekt Irányító Bizottság
Oracle - Moczó István
Projekt vezetés T-Systems - Krausz Katalin Rába - Nagy Tamás
Technikai Támogató Team vezető Kósa György
Technikai Verzióváltás Team vezető Törő Krisztián
TSM Könyvelés vezető: Téringer Lajos
Minőségbiztosítási szakértő
Projekt Támogató Iroda Projekt Asszisztens Rába - Kantó Károly
Paár János
Műszaki Technikai Architekt T-Systems – Berecz Ákos
Fejlesztési Team vezető 1 Paárné J. Judit
Fejlesztési TeamPoint vezető 2 Törő Krisztián
Tervezési Funkcionális Tanácsadó
Pénzügyi funkcionális Pénzügyi Tanácsadókés Tanácsadók modulgazdák Rába pénzügy modulgazdák
Rába tervezési modulgazda
12
Termelési Point funkcionális Tanácsadók Rába Point termelési modulgazdák
Rendszer Változtatás Kezelési Team Baranyay Péter
Logisztikai Funkcionális Tanácsadók Rába logisztikai modulgazdák
DBI funkcionális Tanácsadó Rába DBI modulgazda
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
Kifizetések
Karbant. ktgek aktiválása
MOAC ADÓ SLA
Vevő Szállító
Munkaerőkezelő rdsz.
Készletállapot Sorozatjellemző
Sorozat alapú anyagigény
Raktári vezérlőpult Belső rend. Belső igény Beszerz. munkakp.
14
Keresztdokkolás
Összes Igényelt
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 Ado9 2013.04.22-‐én időpontban indult) nyito9 SR-‐ek 5-‐Nov 11-‐Nov 20-‐Nov 21-‐Nov 26-‐Nov 28-‐Nov 4-‐Dec 17-‐Dec 18-‐Dec 18-‐Dec 7-‐Jan 13-‐Jan 21-‐Jan 27-‐Jan 11-‐Feb 18-‐Feb 26-‐Feb 10-‐Mar
25 34 31 28 28 27 31 25 26 18 19 19 22 20 24 25 24 26
KriAkus
Fontos
Közepes
Új, vagy nem kategorizált bejelentés
3 3 2 2 1 1 1 1 1 1 1 0 0 0 0 0 0 0
13 20 17 14 13 15 16 12 13 5 4 6 6 7 6 7 5 5
9 11 11 12 11 11 14 12 12 12 14 16 16 13 18 18 14 21
20
Ado9 időpontban összes lezárt bejelentés 65 78 82 85 87 91 98 109 110 111 119 123 130 135 145 150 157 164
21
WMS/MSCA
WIP
TAX
RLM
QM
PO
OM
iSUP
INV
GL
FA
ENG
ECG
EAM
DBI
CST
ASCP
AR
AP
ALL
Létrehozott SR-ek száma modulonként
25
20
15
10
5
0
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
Projekt értékelése – tanácsadói és modulgazdai vélemények („Megszólal a projekttag”) Pozitívumok
Negatívumok
„A csoportok jól együtt tudtak dolgozni, a részletesen leosztott, egyértelműsített feladatok végrehajtása hatékony volt”
„E-mailes kommunikációban a Válasz mindenkinek gombot kevesebbszer kellett volna alkalmazni”
„Alapvetően jól tudtunk kommunikálni. Megtaláltuk a közös hangot és csatornát”
„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”
„Rába szakértők terhelhetőek voltak és segítőkészek”
„A tagvállalati szakértők nem minden esetben voltak együttműködőek”.
„Tanácsadóim szakmai, emberi hozzáállásával, segítőkészségükkel maximálisan elégedett voltam”.
„Funkcionális oldalon sok munkát kellett beletenni a kollégáknak, amire nem lehetett felkészülni”
„mindenki felelősségteljesen segítette a másik munkáját” (modulgazdákról)
„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”
„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”
„…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
