ITÉlet

A legnagyobb projektem 2009-ben, érdekes fordulatokkal és számos tanulsággal. És végre a barátnőm is megtudja, mivel töltöttem az időt tavaly J

A legnagyobb projektem 2009-ben, érdekes fordulatokkal és számos tanulsággal. És végre a barátnőm is megtudja, mivel töltöttem az időt tavaly J

2009 elején számos projekt-lehetőséget emlegetett a főnököm, nagyrészt Afrikában, illetve volt egy Kelet-Európában is. Az egyik esetben a startvonalról táncoltunk vissza. Aztán jött a kinevezésem, ezzel együtt megkaptam ezt a tunéziai projektet. Biztos hogy a kettő között összefüggés van, de ma sem tudom melyik az ok és melyik az okozat.

A részletek nem voltak ismertek, úgyhogy rögtön adatgyűjtésbe kellett kezdeni.
Röviden az a lényeg, hogy a cégünk tunéziai leányvállalatánál használnak egy mainframe logisztikai rendszert (SAP-pal integrálva), melynek fenntartásáért az IBM nagyon sok pénz kér. Ha bevezetnénk a már létező és használatban lévő európai logisztikai rendszert, akkor egyrészt megúsznánk az üzemeltetési költséget, másrészt az új funkciók bevezetésével üzleti előnyhöz jutnánk. Alsó hangon is kb 4 millió eurós NPV-ről van szó.
Feladatok: európai rendszerek testreszabása, integráció a helyi rendszerekkel (ez elsősorban SAP), adat migráció, training, bevezetés, támogatás.
A projektet globális szinten jóváhagyták.

Főbb játékosok:
- Egyik európai rendszer fejlesztőcsapata Angliában (cég saját belső csapata)
- Másik európai rendszer fejlesztőcsapata Spanyolországban (külső cég, nevezzük őket MAX-nak)
- IT csapat Angliában
- Európai üzleti csapat Belgiumban
- Tunéziai leányvállalat helyi szakértői (iroda 2 külön városban)
- SAP fejlesztő csapat Tunéziában (külső partner)
- és én Magyarországon J

Határidő október, és ebben nincs rugalmasság – a régi rendszer támogatási szerződése ekkor járt le, és csak hosszú időre lehet újat kötni.
(Ha áprilisban még sehol nem állunk, és októberre át kell adni, akkor az hány hónapnyi idő? Mínusz a nyári szabadságolások, ugyebár! )

Mivel a projekt nem európai, hanem globális döntés volt, ezért az európai management számára presztízskérdés volt jól teljesíteni. Ez nem azt jelentette, hogy kőbe véstük a határidőt és „ha törik - ha szakad bevezetünk”, hanem azt, hogy rendszeresen informáltam a vezetőséget, illetve a lelkemre kötötték, ha valamivel gond van, akkor szóljak.

Azonnal összegyűjtöttem az összes lehetséges dokumentációt a projektről. Nem volt túl sok, kb annyi, mint fentebb. A dokumentumokat a repülőn Anglia felé átolvastam, és felkészültem a találkozóra az ottani csapatvezetővel.

Az idős angol úr (nevezzük Tom-nak) úgy mutatkozott be, mint a projekt vezetője. Ezzel én rögtön projekt asszisztenssé avanzsáltam J
Kiderült, hogy Tom egy nagyon tapasztalt mérnök, akinek a kisujjában van a rendszer oda-vissza. Mint a csapat elismert tagja, a véleményét mindenben kikérik és tisztelik. Tom már egyeztetett a szereplők többségével a műszaki megoldásról, és fejében össze is álltak az interfészek és a fejlesztés. Viszont nem tudta, hogyan kezdjen neki a munkának – és kellően öreg róka volt hozzá, hogy lássa, mennyire nehéz lesz.

A részletes beszélgetéseken kiderült, hogy én pont azon a területen vagyok jó, ahol ő gyenge – egy ilyen projekt adminisztrációja és menedzsmentje. Megállapodtunk, hogy ő vezeti a projektet és én támogatom az adminisztrációval, de papíron én leszek a projekt vezetője. Így ő arra koncentrálhatott, hogy elkészüljön a fejlesztés, én pedig arra, hogy ne legyenek problémák.

Beszéltünk a PMO-val, illetve kapcsolatba léptem minden szereplővel.

Az első probléma az volt, hogyan strukturáljuk a projektet. Ki kinek az alvállalkozója, ki kinek mit fizet, ki kinek jelent? És úgy egyáltalán, kiket kell bevonni?
Végül a munkát felbontjuk 4 különálló projektre:
- MAX a tunéziai leányvállalat direkt alvállalkozója lesz, saját projekttel és scope-pal, így velük nem kell foglalkoznunk
- Mi biztosítjuk az infrastruktúrát és a fejlesztést a belső rendszeren, mint alvállalkozó. (Szerződést nem kötöttünk, hiszen ugyanaz a cég vagyunk, de az egyik költséghely számláz a másiknak)
- A tunéziai üzleti projekt felelős az üzleti követelményekért, tesztelésért, oktatásért és bevezetésért.
- A tunéziai informatikai projekt felelős az integrációért és a SAP illesztésért.

A projekteket egy program fogja össze, amit a tunéziaiak vezetnek. A tunéziai Project Manager-nek jelentünk és eszkalálunk, illetve ő piszkál bennünket, hogy haladunk-e a terv szerint. Mi pedig vezetjük a saját projektünket, és piszkáljuk a fejlesztőinket.

Következő probléma: mindenkinek megvan a saját módszertana és standard-ja a dokumentációra, melyiket kövessük?
Megoldás: a saját projektünkben a saját standardot követjük, de a munka összességében a tunéziai standard szerint történik.

Hogyan koordináljuk a különböző csapatokat?
Heti meeting, ahol részt vesz mindegyik csapat vezetője/helyettese. Erről jegyzőkönyv készül, amit megkap minden érintett, plusz a felsővezetők minden oldalon.
Steerco havonta a döntéshozók részére (informatikai és üzleti döntéshozók Európából és Tunéziából)
Közös Master Plan, ami egyesítve tartalmazza az összes projektet, és ezt frissítjük hetente az elért eredményeknek megfelelően.
Közös projekt portál, ahol dokumentumokat osztunk meg.

Ezután következett egy hosszú, bürokratikus, unalmas, ámde fontos munka: a mi projektünket el kellett indítani. Igaz hogy az egész ügyet már valaki legfelül eldöntötte, de ettől még alul azok az emberek, akiknek meg kellett csinálni a melót, nem tudtak róla.

Írni kellett egy projekt összefoglalót, aztán jóváhagyatni.
Csinálni egy kick-off-ot, felmérni a projektet különböző szempontból.

Elkészítettük a Project Charter-t, és összeszedtük azokat az embereket, akikre szükség lesz. Kb 11 fős volt a csapat, plusz még apró szívességek innen-onnan. Persze ez a 11 fő nem teljes időben dolgozott a projekten, a kemény magot mi ketten, 2 offshore fejlesztő és egy IT koordinátor jelentettük.
Mivel a projekt komplex volt, sok embert be kellett vonni. Tom aggódott, hogyan fogjuk a más csapatokhoz, más manager-hez tartozó kollégákat rávenni, hogy a projektünkön dolgozzanak. Ehhez le kellett bontani a problémákat egyszerű feladatokra, felelősöket meghatározni, aztán átbeszélni velük a felelősséget. És természetesen jóváhagyatni a tervet a fejük fölött lévőkkel.

A Charter után jött a Projekt Indító Dokumentum. Itt már konkrétan kellett írni a műszaki megoldásról, és Tom egyre inkább rákényszerült, hogy a fejében lévő képet papírra vesse (bár ezen a szinten még csak felülnézetből).
A dokumentumot azután széles körben átnézetni és jóváhagyatni. Mivel a review-knak formálisan meg kellett történnie, ezért ez igen sokáig tartott. A nyári szabadságolás jelentősen keresztülhúzta a tervünket – amint az egyik döntéshozó visszatért szabadságról, a másik ment el.

Közben elkészült a részletes munkaterv, a design, és megindult a fejlesztés is.

Nagyjából itt kezdődtek el a problémák. Rájöttem arra, ha Tom valamivel megakad, akkor áll a fejlesztés – hiszen nem tudja a fejlesztőknek megmondani, mit csináljanak. Másrészt pedig Tom mérnökember volt – mindig alaposan és jól akart dolgozni, nem tudott egy problémán átlépni vagy megkerülni. Ezért alaposan figyelnem kellett, és ha valami váratlan történt, akkor erővel elvenni tőle a problémát és megoldani. Akkor is, ha gőzöm se volt róla, hogyan.

Néhány példa:
- Kiderült, hogy az integrációs eszközhöz a licensz nem lett megrendelve, sőt nem is lett a budget-be betervezve. Na akkor hirtelen egy beszerzési process indítása, európai beszerzési vezető bevonása. Normál esetben az ilyesmi minimum 4 hónap, nekünk volt rá 1
- A fejlesztők nem ismerték az integrációs eszközt, és doksit kértek. A rendszerintegrációs szakértő nem akarta, hogy a fejlesztők okoskodjanak, ezért direkt nem adott doksit. Utána kellett nézni, hogy korábbi projektekben ez hogyan működött, és elmondani a fejlesztőknek.
- Nézeteltérés támadt Tom és az IT koordinátor között, kezdtek hűvös angol urakhoz nem illő hangnemet megütni. Közbeléptem, átbeszéltük a dolgokat, megegyeztünk ki mit csinál, és megint szent lett a béke.
- Nem volt elérhető a szükséges web service a tesztelés alatt, ezért nem ment a rendszerek közötti kommunikáció. Valahol egy hálózati beállítás nem volt megfelelő. Kiderült, hogy a hálózati architektúrára felirt ip címeket mindegyik rendszergazda a saját szemszögéből értelmezte (azaz összekeveredtek a belső és külső ip címek).
- Számos esetben Tomnak gondjai voltak azzal, hogy mennyi részletesen vagy mennyire tömören írjon meg egy projektvezetéshez kapcsolódó dokumentumot. Sokat segítettem neki magyarázattal és példákkal.
- Kiderült, hogy a security csapat nem engedélyezi az alkalmazásban meglévő biztonsági modellt, viszont a szabvány biztonsági megoldás az üzletnek okozott volna elfogadhatatlan nehézségeket. Az álláspontok nem közeledtek. Mindkét fél többszöri meghallgatása és néhány izzadtságszagú meeting után sikerült megtalálni a kiskaput: elindulunk a már meglévő biztonsági beállítással mint ideiglenes megoldás, aztán átállunk a szabványosra.

Mivel az infrastruktúráért is mi voltunk felelősek, ezért nem tisztán fejlesztési feladataink voltak, és a többi csapat is tőlünk függött. Problémák pedig akadtak. Szerencsére mindig csak annyi, hogy le tudjam kezelni őket. És sokat segített az, hogy a cégünket, folyamatainkat igen jól ismertem, lévén nem ez volt az első projekt. Ismertem az embereket, tudtam kihez kell fordulni, és nem is féltem megtenni.
Néhány esetben eszkaláltam, ilyenkor azonnali és hathatós segítség érkezett.

Mindezekkel együtt valahogy az a kép alakult ki a csapatban (mármint a többi PM között), hogy az alprojektek közül a miénk halad a leglassabban, és mi vagyunk a legnagyobb kockázat az állandó problémáinkkal. Emiatt a mi csúszásaink is súlyosabb megítélés alá kerültek. Mindenki azon a véleményen volt, hogy az éles indulásnál biztosan sok ballépésünkre fény derül.

Igazából a legnagyobb problémánk az éles indulás előtt nem sokkal derült ki, amikor a felhasználói adatbázist kellett feltölteni. Ekkor a security csapat megkérdezte: ezek a derék tunéziaiak, akik a belső hálózatunkhoz és rendszereinkhez akarnak hozzáférni, külsősök vagy belsősök? És hogy van-e joguk a belső hálózatunkhoz? Mert ugye külső személyt nem akarunk a cégünk belső rendszereihez közel engedni. Egy munkatársat viszont igen.

Itt most egy kis magyarázat. Ugyebár a multinacionális cégek globális világában nem cégek, hanem cégcsoportok léteznek. Például Toyota nevű cégből nem csak egy létezik, hanem sok. Először is minden országban létezik egy. Ahol gyár van, ott az is egy külön cég. Vannak regionális Toyoták és globális Toyoták. Sok-sok Toyota. Ezek keresztbe kasul birtokolják egymást, több szinten és néha egymással keresztbe. Ha két Toyota alkalmazott találkozik a reptéren, akkor ugyan mindkettőnek ugyanaz a logo lesz a névjegykártyáján, de külső szemlélő nem fogja tudni eldönteni, ők most ugyanannak vagy két külön cégnek az alkalmazottai-e.

Szóval annak az eldöntése, hogy egy tunéziai felhasználó hozzáférhet-e egy angol szerverhez, sokkal nehezebb, mint az ember gondolná.
Beszéltem a HR-rel, az ERP-sokkal, Helpdesk-el, IT vezetőkkel, PMO-val, gurukkal és nagy öregekkel, auditorokkal, vezérigazgatókkal és jövendőmondókkal. Odáig sikerült eljutni, hogy az európai cégcsoport olyan vállalatokból áll, amikben az európai központ tulajdonos. A „belsős” azokat a cégeket jelenti, akik felett közvetlen irányítása van, pl gyár vagy régióközpont. A „külsős” azokat a cégeket jelenti, amelyeket birtokol ugyan de nem irányítja közvetlenül (ilyenek pl a helyi importőr cégek). A tunéziai cég viszont egy teljesen új fajta volt: az európai központ semmilyen mértében nem birtokolta, és nem volt beleszólása az ott zajló dolgokba. (Mert a tunéziai cég egy másik cégcsoporthoz tartozott, és valahol a gráf tetején a két cégcsoportnak közös a tulajdonosa)

Na szóval a projekt ezen a pontján heteket töltöttem annak kiderítésével, a cégcsoport milyen cégekből áll, és a cégek részvényei hány százalékban kinek a kezén vannak. Nem éppen testhezálló feladat egy informatikai menedzsernek!

A kérdést pedig meg kellett oldani, ezért áthidaló megoldást kerestem. Egyrészt evidenciát szereztem, hogy a meghatározó informatikai vezetők nem ellenzik, hogy a tunéziaiak külsősként a rendszerre kerüljenek. Másrészt mindenki belátta, hogy valamilyen megoldásnak lennie kell, és nincs másik. Abban mindenki egyetértett, hogy biztosan nem belsősök.

A legnagyobb gondot inkább az okozta, hogy amíg ez nem dőlt el, addig nem sikerült minden projekt doksit jóváhagyatni, a jóváhagyás pedig közvetlenül az indulás előtt érkezett.

A tesztelés lement, voltak hibák amiket ki kellett javítani, de a nagy részük a rendszer/folyamat nem-ismeretéből adódott. Aztán valahogy keresztül lett verve a tesztelés, és elindultunk. Itt már lehetett sejteni, hogy bajok lesznek, nem velünk és nem a mi fejlesztésünkkel.

A Go-NoGo meeting „conditional Go” döntéssel végződött – 1 hét csúszással ugyan, de pár hibát kijavítva elindultunk.

Az oktatás és indulás lépésekben történt. Nem egyszerre engedtünk a rendszerre mindenkit, hanem fokozatosan, egyszerre mindig csak a felhasználók egy kis csoportját. A régi rendszer párhuzamosan üzemelt.

Maga az indulás szinte zökkenőmentes és sima ügy volt, különösebb informatikai esemény nélkül. A bajok csak azután kezdődtek, hogy mindenki a rendszeren volt, és elkezdte komolyabban használni.

Elkezdtek jönni a hibabejelentések a felhasználóktól, egyre komolyabb mértékben. Tudtuk hogy lesznek hibák – ennél a méretnél elkerülhetetlen. A hibák arról tanúskodtak, hogy a rendszerrel járó új folyamatokat nem sikerült a helyieknek teljesen megérteni és átvenni – illetve nem adták át nekik teljesen.

Kiderült, hogy bár a migráció és adattisztítás sikeres volt, de a különböző rendszerekben lévő törzsadatok helyenként eltértek – ettől az adatok értelmezése eltérő lett a különböző rendszerekben.

Érdekes összehasonlítani a MAX és a saját projektunk státuszának alakulását időben: MAX-ék igen gyorsan elkezdték a fejlesztés, gyorsan eljutottak egy 100% közeli állapothoz, és égig nagyon professzionális képet mutattak. Eközben a mi fejlesztésünk lineárisan haladt, lépésről lépésre, ami csak a végére ért el 100%-ot. Közben nálunk sokféle hiba került elő, miközben MAX-éknál kevés. Az indulás után MAX-ék 100%-a megkérdőjeleződött, és elkezdtek hibák felbukkanni, miközben mi lazsáltunk.

Decemberben befejeztük az utolsó simításokat, kijavítottuk az utolsó hibákat, és lezártuk a projektünket. A projekt dokumentáció a PMO szerint tökéletes. A cég újságja külön beszámolt az eseményről, és számos gratulációt kaptunk.

Igaz, hogy lehetett volna itt és ott jobban csinálni, de egy rendkívül összetett munkát sikerült az elvárásoknak megfelelően leszállítani, a megadott időintervallumon belül. Ahhoz képest, hogy mennyire sehol nem voltunk az elején…

Mindez azért sikerülhetett, mert Tom a hátán vitte az egészet. A legelején felismertem, hogy ő és csakis ő képes műszakilag összerakni a megoldást, ha a saját dolgaival foglalkozhat. Sikerült jól összedolgozunk és kiegészíteni egymást, pedig elég ellentétesek voltunk. Tom mindent tudott a műszaki dolgokról, én pedig tudtam, hogyan kell a projektet végigvezetni az elejétől a végéig.
Fontos volt a már korábban említett „corporate knowledge”, mivel kihez hogyan fordulhatunk hogy másnapra megoldás legyen belőle.
Végül de nem utolsósorban, jól együtt tudtunk dolgozni a többi csapat vezetőjével. Kiengedtük a kezünkből az irányítást, átadtuk a tunéziaiaknak, cserébe ők jól vezették és összehangolták a produkciót.

A képhez sajnos hozzátartozik, hogy a folyamat-jellegű problémákat mind a mai napig nem sikerült megoldani, és ezeken még mindig dolgoznak. Ebből mindenki vonja le a tanulságot saját maga számára – ami talán megér egy másik post-ot.