A lendületes projektvezetés kockázatai

Tömörítvény

A kockázat nem feltétlenül üldözendő, rossz dolog, mivel ez minden projektnek eleme, általános jellemzője: a környezete, sajátosságai révén hordoz magában bizonytalanságot, bizonyos mértékű kockázatot. Azonban a kockázatok teljes mértékű megszüntetésére törekedni ésszerűtlenség, mivel egyrészt a véletlen események bekövetkezte miatt ez lehetetlen, másrészt a felismert kockázatok teljes megszüntetésének költsége horribilis összegeket jelenthet. A kockázatkezelés célja a projekt kockázati elemeinek azonosítása, kezelésükre alkalmas módszerek kidolgozása, és a kockázatkezelési tervben történő szerepeltetéssel a kockázatok - szándékunk ellenére törénő - megvalósulása valószínűségének minimalizálása.

Adott egy versenyhelyzet, egy technológia- és beruházásigényes iparág, amelyben a magyarországi piac néhány feltörekvő és példaértékűen működőnek ismert vállalkozás között oszlik meg. Az élmezőnyhöz tartozó egyik információ-technológiai vállalkozás sajátos tulajdonviszonyai, történelmi helyzete, és a piaci eredményekben is jelentkező elismertsége, valamint a sajátos fejlesztési, termelési mechanizmusa megállásra, gondolkodásra késztet: fenntartható-e, és ha igen, meddig tartható fenn az általa felmutatott teljesítőképesség, meddig marad ez az iram? Vajon csak a lendület viszi előre a vállalkozást, vagy van a megújuláshoz, az évek óta fokozatosan jelen lévő piacvesztés megállításához belső, mobilizálható tartaléka? Minden racionálisan gondolkodó gazdasági szakember igennel válaszolna az utolsó kérdésre, azonban képes-e helyzetét felismerni a vállalkozás, és tud-e eleget változni a megújuláshoz?

A piacon eladható termékek minősége, mennyisége meghatározó a jövő szempontjából. Álljon bár a legnagyszerűbb marketing-csapat is a vállalkozás rendelkezésére, ha a termelés egyre kockázatosabbá válik, és annak menedzselése, a bekövetkező kockázatok jelentős erőforrástól fosztják meg a vállalkozást, akkor a „napról-napra élés” súlyos szerkezeti és eredménybeli problémákhoz vezet.

Ezen információ-technológiai vállalkozásnak – a WMO-nak - a termékelőállítási folyamatában fennálló kockázatairól, a kockázatos működés különböző aspektusairól szól ez a dolgozat.

Az üzleti titokra vonatkozó szabályozások megsértésének elkerülésére torzított adatokat, neveket, megnevezéseket használok. A valósággal való egyezés csak a véletlen műve lehet

Tartalomjegyzék

I. Háttérismeretek

I.1. Fogalmak, definíciók

I.2. A VÁLLALKOZÁS

II.  Helyzetelemzés: A TERMÉK ELŐÁLLÍTÁSA

II.1. Mit nevezhetünk projektnek?

II.1.a. A projekt tervezett időtartama

II.1.b. Költségkeret

II.1.c. Projektcél fontossága

II.1.d. Projekt jellege

II.1.e. Projektcél bonyolultsága

II.1.f. Érintett szervezeti egységek száma

II.1.g. Igényelt projektszervezet mérete

III.  Megoldáskeresés

III.1. A termék előállításának elemei és a hozzájuk tartozó kockázat

III.2. Az Ötlet kialakulása, felvetése

III.3. Az Ötlet üzleti szempontú véleményezése, üzleti szempontú megfogalmazása, súlyozása, elhelyezése az éves szolgáltatás-fejlesztési tervben

III.4. Projekt kezdeményezése

III.5. Fejlesztési igény esetén a szolgáltatásfejlesztés tájékoztatása

III.6. A szolgáltatás-fejlesztési projektmenedzser kijelölése

III.7. A projekt költség-keretének ellenőrzése

III.8. Költségkeret létezése esetén a projektcél tisztázása, megfogalmazása, a projekt felhasználói specifikációjának elkészítése

III.9. A fejlesztési megvalósíthatósági tanulmányának elkészítése, véglegesítése

III.10. A projektcél megvalósíthatósága esetén a projekt beillesztése a projekt-portfólióba (erőforrások lefoglalása), a projekt tervezésének megkezdése

III.11. A projektcél megvalósítása, termék kifejlesztése, tesztelése, a projekt tervezése, ütemezése, vezetése

III.12. Termék átadása az üzemeltetőnek és a felhasználónak

III.13. Projekt-utógondozás, projektzárás

III.14. Szolgáltatás és hardvereszközeinek üzemeltetése

III.15. Módosítások, fejlesztések igényének jelzése

III.16. ISO kontra rugalmasság, projektvezető „alkotói szabadsága”

IV.  Megoldási javaslatok, összefoglalás

I.         Háttérismeretek

I.1.        Fogalmak, definíciók

Nemzetközi Központ – a nemzetközi konzorcium vezérképviselete

Amerikai Központ - a nemzetközi konzorcium amerikai vezérképviselete, az alapvető piaci, kultúrális különbségekből eredő okok miatt különválasztva a Nemzetközi Központtól

Európai Központ – a magyarországon bejegyzett Tulajdonos ágazati anyavállalata, részvénytöbbségének tulajdonosa, egy nemzetközi konzorcium európai vezérképviselete

Tulajdonos – a vizsgált vállalkozás 100%-os magyarországi tulajdonosa

WMO – a vizsgált vállalkozás, részvénytársaság neve (fantázianév).

Éves szolgáltatás-fejlesztési terv - az éves beruházási tervhez kapcsolódóan készülő, az előfizető szempontjait figyelembe vevő, a vállalati szolgáltatás portfólióba illesztendő új szolgáltatásokat, vagy a meglévő szolgáltatásokhoz kapcsolódó újabb szolgáltatásokat, a megvalósítás negyedéves-szintű ütemezését, a fejlesztéshez rendelkezésre álló beruházási keretet és a bevezetésért felelős területi vezetőt meghatározó dokumentum.

Megrendelő – aki a projektindító ötlet nyomán kialakult feladat elvégzését igényli. Reprezentálhatja a vezetője, de projektekben a kapcsolattartással megbízott képviselője is. Nem feltétlenül esik egybe az eredmény felhasználójával, gyakran az elkészült szolgáltatás „üzemeltetője”.

Felhasználói specifikáció – a megvalósítandó projektfeladat leírása a Megrendelő nyelvén, fogalmaival.

Informatikai specifikáció – a projektcél megvalósításához szükséges fejlesztések, változtatások megfogalmazása a kapcsolódó informatikai szakterületek szakvéleménye alapján, a feladatkiadáshoz, a teszteléshez szükséges részletességgel, azok nyelvezetét használva.

Kockázat - A dolgozatban a projektekkel kapcsolatos kockázat fogalmába „összemosom” a bizonytalanság kategóriájába tartozó és a kockázatos eseményeket [1], mivel vagy nem tudjuk pontosan meghatározni, vagy nem is ismerjük a hivatkozott események bekövetkeztének valószínűségét.

KPI – Key Performance Indikátor – kulcsfontosságú mutatószámok, amik a folyamatok bizonyos jellemzőinek időszakos vagy eseti mérésével, értékbeni ábrázolásával, kimutatásával, a tények rögzítésével lehetővé teszik a folyamat kontrollingját, a pillanatnyi, vagy utólagos értékelését.

I.2.        A VÁLLALKOZÁS

Ábra - . A WMO elhelyezkedése a nemzetközi környezetben,
főbb szervezeti egységei, és az IT-területek szétválása

A WMO több-ezer főt foglalkoztató, többtelephelyes, de elhelyezkedésében Budapestre koncentrálódó magyarországi sikervállalat. Tevékenységi köre jelenleg országos, emellett az idelátogató külföldiek számára is biztosít szolgáltatásokat.

Részvényeivel rendelkező Tulajdonosa szintén magyar vállalat. Az Európai Központ többségi tulajdonosa a Tulajdonos vállalatnak is, és azonos iparágban tevékenykednek, így a WMO-feletti adminisztratív irányítás és ellenőrzés nagyobbik részét a magyar Tulajdonos, kisebbik részét a Nyugat-Európában bejegyzett Európai Központ végzi, ugyanakkor a szakmai irányítás 99%-ban az Európai Központ kezében van. Ez a kettősség nem könnyíti meg az életet, két tulajdonosnak, két „parancsnoknak” nehéz egyidőben megfelelni, de előnyei is vannak.

A WMO évenként jelentős nyereséget könyvel el, ez teszi lehetővé, hogy „kétkulacsos” politikájával éljen. A „kartávolságra vagyunk az Európai központtól” kifejezés mögötti taktikázás lényege, hogy amennyiben szüksége van az Európai Központnak és leányvállalatainak kijáró előnyös besorolásra, akkor kartávolságra lemaradva kapaszkodik, de ha egy, az integritását sértő, vállalati politikájával ellentétes rendelkezés végrehajtásáról van szó, akkor a kinyújtott kéz távolságtartást jelez. Ugyanez a kettősség teremti meg a két tulajdonos egymás elleni kijátszásának politikus lehetőségét is.

Az elmúl évek divatos minőségbiztosítási díjszerzési versenyébe beszállva sorra kapta a hazai és nemzetközi elismeréseket.

Szervezeti felépítését, tulajdonosi kapcsolatait az 1. Ábra mutatja.

Fő tevékenysége széleskörű információ-technológiai szolgáltatások biztosítása, a szolgáltatások igénybevételére alkalmas eszközök kapcsolódó értékesítése, szervizelése mellett. A szolgáltatások és az értékesítés biztosításához is egyaránt országos hálózatot épített ki. Szolgáltatásai nagy részét maga fejleszti, saját szervezeti egységeivel állíttatja elő, kisebb részét pedig a kapcsolódó piaci beszállítóktól vásárolja és beépítteti a rendszerébe (implementálás). Ez a tevékenysége mind üzleti, mind pedig informatikai területekhez kapcsolódik.

A közelmúltban lezajlott változásokig az Informatikai Igazgatóság feladata az új szolgáltatások fejlesztése, az informatikai eszközök beszerzése, karbantartása, üzemeltetése, a szükséges informatikai kommunikációs hálózat kialakítása és karbantartása volt. A feladatok megoldására projektszemléletben kerül sor: ma is szinte minden feladatot „projekt”-nek tekintenek, az általános, rendszeres üzemeltetési feladatokat „overload”-ként, azaz „túlmunkaként” végzik, illetve ebben a kategóriában tartják nyilván.

Az üzemeltetési-, illetve az újabb szolgáltatások megvalósításához kapcsolódó feladatok megvalósítása más-más emberi tulajdonságokat követel. Az üzemeltetés „mechanikus” feladat, folyamatai utasításokkal szinte teljes mértékben szabályozhatók, azaz projektszemléletű munkavégzésre nincs, vagy csak ritkán van szükség. Ugyanakkor az újabb és újabb szolgáltatások kidolgozása, a célok megvalósítása kreatív gondolkodást, illetve az ágazati szakmai ismereteken túl alapos projektmenedzsment-felkészültséget igényel. A kétféle tevékenységi terület egymással való keveredését látszólag elősegítette, az állapotot konzerválta, hogy az egyes szakterületek vezetői maguk voltak mind az üzemeltetési feladat felelősei, mind pedig az új feladatok (szolgáltatások) projektmenedzserei is. Ezáltal leterheltségük jelentősen megnövekedett (éves szinten a szlgáltatásfejlesztési területen 2-400 „projekt” kidolgozott igénye jelent meg, emellett közel 2000 munkatárs informatikai hátterének biztosítása, az eszközök karbantartása, géptermek és berendezéseik üzemeltetése, fejlesztése…).

Mind az üzemeltetési feladatok dokumentáltsága, szervezettsége, hatékonysága, mind pedig a projektek vezetésének minősége elmaradt a minimálisan elvárhatótól. A tudás a szakértők, munkatársak fejében volt („humán adatbázis”: nem dokumentumokban, adatbázisokban, program-magyarázatokban), így a szakértők saját területük „rabjai” lettek: mozgásterük szűkült, szakmai fejlődésük a specializálódás és a leterheltség növekedése miatt megtorpant. Jellemző példa, hogy az Előfizetők mintegy 60%-át kiszolgáló, a cég éves árbevételének közel 1/3-át biztosító egyik fontos informatikai rendszer üzemeltetési, fejlesztési feladatait csupán 6 fő látja el: éjszakáznak, pihenőnapjaikat nem tudják kivenni, mert akkor a nappali időszakban nem marad szakértő, aki felügyeli a rendszert, beazonosítja a fellépő hibákat, és megkezdi azok elhárítását, hogy a hibák ne okozzanak jelentős arculati, piaci, és ezáltal üzleti veszetséget.

Az informatikai igények mennyiségi növekedése és a minőségi követelmények erősödése következtében megszületett a döntés: a reakcióképesség növeléséhez szükséges fejlesztést az Informatikai Igazgatóság szétválasztásával kell kezdeni, kialakítva az üzemeltetési (IT-Üzemeltetési Igazgatóság, IT-Operations and Support – IT_OPS) és a szolgáltatás-fejlesztési (Szolgáltatás-fejlesztési Divízió, Service Development – SD) területeket.

Az üzemeltetés megmaradt az addigi IT-igazgató irányítása alatt, és az üzemeltetési szakmai tapasztalat és rendszerismeret hatékonyan támogatja az állandóságot, rendszerességet, stabilitást igénylő munkát. A szolgáltatás-fejlesztési területre új vezető került. Az addig „kettős” szerepben lekötött (fejlesztő+üzemetető) szakértők feladatait szétválasztották: a folyamatok átszervezését a munkatársak maguk végezték, szervezett folyamatfelmérés és -racionalizálás nélkül.

A Szolgáltatás-fejlesztési Divízió feladatai közé tartozik az új szolgáltatások informatikai fejlesztése, az informatikai hálózat (bérelt vonalak, aktív és passzív rendszerelemek) és azon egyéb rendszerelemek fejlesztése, amelyeken - a szolgáltatások gyors evolúciója következtében - gyakran történnek változtatások. A hálózathoz közvetlenül kapcsolódó rendszerek üzemeltetése a „folyamatgazda” szervezeti hovatartozása miatt is a divízió feladata.

II.      Helyzetelemzés: A TERMÉK ELŐÁLLÍTÁSA

A WMO-nál a „termék” fogalmán általában különféle, az érdeklődő és előfizető felhasználók (továbbiakban Előfizetők) részére nyújtott szolgáltatások, illetve emellett a szolgáltatások igénybevételére alkalmas eszközök (forgalmazás, szervízelés) értendők. Emellett természetesen létezik az ún. „belső termék” is, amelyet a belső felhasználók – a WMO különféle szervezeti egységei – igényelnek. A dolgozatban ezeket nem választom szét, ugyanakkor nem érintem az eszközforgaslmazással kapcsolatos kérdésköröket sem.

A szolgáltatások elvileg az informatikai lehetőségekre alapozva készülnek, azaz megvalósításukhoz elengedhetetlen az informatikai háttér, a felhasználható technológiák ismerete, felhasználása. Az újabb technológiák kiválasztásakor a stratégiai döntések a Szolgáltatás-fejlesztési Divízió éppen akkor aktuális -a választást kikényszerítő - projektje során, az adott terület kijelölt projektvezetőjének (szakértőjének) előterjesztése alapján történnek. A döntést a technológiát tartalmazó hardver illetve szoftver megrendelésével a kifizetendő összeg szerint illetékes vezető hozza (ez adott esetben a pénzügyi vezérigazgató-helyettes is lehet).

Az Üzletfejlesztési- és a Szolgáltatásfejlesztési területek között erős rivalizálás tapasztalható. Az üzleti projektmenedzserek fogják össze a komplex projekteket, ugyanakkor nem rendelkeznek szakismerettel a részprojekteket vezető informatikai szakterületeken, illetve az informatikai területek nem rendelkeznek azokkal az üzletfejlesztési stratégiai információkkal, amelyek az új technológiák bevezetéséhez szükséges döntések megalapozottságához szükségesek lennének. Ezáltal megjelennek az egyoldalú piaci és az egyoldalú technológiai hajtás problémái is

II.1.      Mit nevezhetünk projektnek?

A WMO-nál projektnek neveznek, és projektként tartanak nyilván minden feladatot, ami minimum 10 embernapnál nagyobb munkaráfordítást igényel, és ezzel ki is merül a jelenleg hasz­nált besorolási lehetőség. A projektek egy speciális fajtája az üzemeltetési feladatokat magában foglaló, „Folyamatos” címkével ellátott tevékenység. A 10 embernapnál rövidebb feladatokat „overload”-ként, túlmunkaként veszik figyelembe, és éves átalányban figyelik.

Természetesen ez a „projekt”-meghatározás az irodalomban megadott definícióktól igen messze áll. Ami lényegében megkülönbözteti a projektet az általános munkafeladatoktól, hogy a projekt­tevékenység átmeneti, ideiglenes erőfeszítés egyedi termék, szolgáltatás megva­lósí­tásá­ra, vagy eredmény elérésére. Ideiglenes, mert definiált a kezdete és a vége, egyediségét pedig az jelzi, hogy a termék, szolgáltatás vagy végeredmény különbözik a vállalatnál megvalósított, létre­ho­zott bármelyik addigitól.

A definiálás rugalmasabb, ha a fogalmat sajátosságainak felsorolásával közelítjük:

a projektnek van végterméke, azaz megvalósítandó célja;

A szervezete ideiglenes, a projekt élettartamára alakították;

A projekt számos esetben egy nagyobb projektstruktúra részét képezi;

adott a projekt megvalósítására szánt időkeret;

adott a megvalósításra szánt pénzügyi keret;

léteznek felhasználható erőforrások, amelyek korlátosak is lehetnek;

a projektcélkitűzéseket és termékjellemzőket a projekt időtartama alatt folyamatosan lehet meghatározni és elérni;

léteznek a projekttermékkel szemben megfogalmazott, mérhető mennyiségi és minőségi elvárások, követelmények;

a projekttevékenységek közötti viszony összetett is lehet;

létezik a megvalósítást leíró projektterv;

létezik a projektidőre bontott költségterv;

létezik a projekt megvalósítását gátló bizonytalansági területek megjelölése, valamint

az esetleges kockázatok értékelése és a megfelelő reakció-változatok.

Az általános „projekt-definíciónak” megfelelő feladatok jellemzői igen széles skálán mozog­nak, azonban van néhány, ami WMO-n belül alkalmas lehet a módszertani változatok kiválasztásához szükséges kategorizálásra. Ezek a jellemzők egy­ben kockázati elemeket is meghatároznak.

II.1.a.     A projekt tervezett időtartama

A projekt időtartamával közel exponenciálisan arányos a kockázat mértéke. Rövidebb, 1-2 hóna­pos időtartam a mai piaci, technológiai körülmények között kis mértékű bizonytalanságot jelent, melyre egy kellően tanult, felkészített szervezet képes gyorsan és hatékonyan reagálni. Elméletileg a projektcél megváltozásának, a pénzügyi keret csökkenésének, vagy az erőforrásokban bekövetkező változásoknak ilyen rövid időn belül alacsony a valószínűsége.

Gyakorlatilag ennek a kockázatnak a bekövetkezte a WMO-nál nem az időtartamtól, hanem a projektötlet kidol­go­zott­ságától, üzleti szempontú alkalmasságától és annak támogatottságától függ. Előfordulhat az is, hogy a versenytársak a megvalósítási határidőn belül megjelennek olyan, a célzottal meg­egyező, vagy azt jelentős mértékben helyettesíteni képes szolgáltatással, ami – mivel csak „sokkal jobb”, vagy többet nyújtó megoldás jöhet ezek után szóba – gazdaságilag nem indokolja a szolgáltatás beve­zetését (gyakran ennek ellenére tovább folynak a fejlesztések, mert a projekt „apropójaként” a megva­lósítás során olyan technológiai változások történnek, amelyek a későbbi, magasabb minő­ségű szolgáltatásokhoz már szükségesek lesznek).

Kockázat:

Ha növekszik az időtartam, akkor egyrészt meg kell erősíteni a változásmenedzseléshez szüksé­ges tulajdonságokat, másrészt gördülő tervezést célszerű alkalmazni. A különféle területen bekövet­kező változások esetén a projekten belüli kommunikáció, az információk aktualizálása további erőfor­rásigényt jelent, ami akár a projektszervezet bővítését is igényelheti.

A pénzügyi éven túlnyúló projektek esetén fokozottabban jelentkezik a költségvetés rendel­kezésre-állásának kockázata.

A technológiai sajátosságoknak megfelelően vannak olyan feladatok, amelyek „folyamatos” jellegűek: ezek főként a szolgálatfejlesztési területen üzemeltetett rendszerekkel kapcsolatos, álta­lában igen rövid idejű, gyakran egy napon belül, de legfeljebb egy munkahét alatt elvégezhető felada­tokat jelenti. Ide tartoznak az újabb szolgáltatások megjelenésekor a támogató rendszerekben végre­hajtandó változások, például a tűzfal-konfigurációk, vagy az aktív hálózati eszközök konfi­gurá­cióinak, paraméterei változtatásának megervezése, kidolgozása, tesztelése, érvényesítése.

Javasolt kategóriák:

rövid távú , 1 hét 3 hónap, költségvetési éven belül,

középtávú , 3-nál több hónap, vagy két költségvetési évet érintő, illetve

hosszútávú , több költségvetési évet érintő.

II.1.b.    Költségkeret

A költségkeret alapján történő megkülönböztetés a döntési pontokhoz kötött pénzügyi korlátok, illetve a lineárisan növekvő gazdasági kockázat miatt történik. A határok kialakítása az egyes vezetői döntési keretekhez igazodhat, és ennek megfelelően kell kidolgozni a projekt monitoring szabályait is: ez a kockázat a projektindításkor jól becsülhető, és a projektvezető megbízólevelében, a projektmenedzser tapasztaltságának, képzettségének, és az ebből eredő kockázat függvényében a monitoring- és jelentési körülmények meghatározásánál (pl. kinek, milyen gyakran, milyen paramé­terek­ről kell jelenteni) figyelembe veendő.

Kockázat:

A pénzügyi szempontok belső koordináció hiánya esetén ellentmondanak a technológiai, fejlesz­tési igényeknek, és az utólagos egyeztetések miatt a piacra jutás ideje jelentősen megnö­vekszik.

Javasolt kategóriák: nincs, a megbízólevélben kell a pénzügyi fontosságtól függő mértékű ellenőrzési igényt érvényesíteni.

II.1.c.     Projektcél fontossága

A Megrendelő számára minden projekt fontos, de erőforrás-korlát esetén a saját projektjei között is fel kell állítania a rangsort. Különösen igaz ez, ha pénzügyi korlátról van szó, mivel az elő­ző év végén meghatározott keretszámok az akkori viszonyokat tükrözték, így egy újonnan jelent­kező projektfeladat megvalósításához az adott szervezeti egység előzetesen betervezett projektjeitől kell a pénzt elvonni. Ez azt eredményezi, hogy a tervezés során – annak kidolgozottságától, indo­koltságától függetlenül (!) - minden projektötlet megvalósítását betervezik, hogy legyenek „felál­doz­ható” sorok a költségvetésben. Amennyiben a projektötlet megvalósítása alátámasztottan válla­lati érdek, akkor ahhoz a meglévőn felül, külön költségkeretet allokálnak.

A Szolgáltatásfejlesztésnek a fizikai erőforrások korlátossága miatt kell a projekt-portfólióját folyama­tosan menedzselnie: az újonnan megjelenő, előzetesen nem jelzett projektek „beszúrása” a megvaló­sítási ütemtervbe sok problémát jelent. Több hónapra előre beütemezik a külső fejlesztői kapa­ci­tást és az outsourcing cégekkel is előre megkötik az egyes projekthez rendelt feladatokra a szerző­déseket. Ezek megváltoztatása jelentős szervezési többletmunkát igényel (megkezdett munkák esetén pénzügyi veszetséggel párosulva, melyet csak ritkán képes az outsourcing partner átvál­lalni), ugrásszerűen nő a kockázat a változtatások következtében, láncreakció-szerűen háttérbe szorulhatnak – például a tesztrendszerek igénybevételének átütemezése miatt – más, közvetlenül nem érintett projektek is.

Ha a szolgáltatásfejlesztésen évente megjelenő 50-60 új projektigényt és az általában 100-120 egyidőben futó aktuális projektet az előre tervezett 2-400 üzletfejlesztési vagy ügyfélszolgálati projekttel együtt vizsgáljuk, belátható, hogy ennek manuális egyeztetése jelentős szervezési, vezetési, egyeztetési erőforrást igényel, ráadásul a reakcióidő-igény a piaci dinamikából adódóan (főleg jelentősebb naptári időpontok, ünnepek előtti, értékesítési akciókkal teli időszakokban) gyakran igen rövid. Ezt a kocká­zatot megfelelő szervezet, módszertan és technikai támogatás nélkül nem lehet a szükséges mértékben csökkenteni.

Javasolt kategóriák: rangsorolás számokkal , 15-ig, illetve ennél beszédesebb, kifejezésekkel jelölt skála is alkalmas.

II.1.d.    Projekt jellege

A projekt célja lehet egy új szolgáltatás fejlesztése, egy már meglévő szolgáltatás módosítása, az informatikai támogató- rendszer (hálózat, számlázó-rendszerek, stb.) fejlesztése, más szervezeti egység infomatikához kapcsolódó igénye, vagy egyéb, esetleg ezek kombinációjából előálló feladat. A jelleg megrendelőnként is változhat: üzletfejlesztési, ügyfélszolgálati, pénzügyi, társszolgáltatói projektekről beszélhetünk. Magát a feladatvégzést alapjaiban nem határozza meg, azonban a projektvezető a megoldás kiválasztásában ezeket figyelembe kell vegye. A kategorizálásnak a nyilván­tartásnál, a költségbecslésnél, vagy feladatok személyhez kapcsolásánál van szerepe (az adott területtel foglalkozó projektmenedzser a kapcsolatrendszer kialakulásával és folya­matos­ságával hatékonyabban tud dolgozni).

Az univerzális projekt leírások hátránya, hogy az egyes projekt típusokat csak nagyon eről­tetetten lehet velük megfogalmazni. Gyakoribb - jellegükből adódóan elkülönülõ - típusok[4] :

rendszerfejlesztési és beruházási projektek;

az üzemeltetéssel kapcsolatos projektek;

tanulmányok;

oktatási programok;

egyéb projektek.

A fenti kategóriákból a WMO-nál rendszerfejlesztési, beruházási, üzemeltetéssel kapcsolatos és egyéb projektek találhatók meg.

Javasolt kategóriák: szervezeti egységenként, azok megnevezését, esetleg beszédes rövidítését felhasználva kialakított azonosítókkal.

II.1.e.     Projektcél bonyolultsága

Az egyszerű feladatok átláthatóságukkal elősegítik, hogy a projektvezető kellően fel tudja mérni az előtte álló feladatokat, át tudja tekinteni a megvalósítási folyamatot. Ahogy egyre bonyo­lultab­bá válik a feladat, a projektet akkora fázisokra kell bontani, amelyek még könnyen átláthatóak, kezel­hetőek maradnak. A bonyolultabb feladatok megfelelő segítség nélkül – projekt­menedzs­mentet támogató szoftver, egy megfelelő szervezettel rendelkező projektiroda - jelentős kockázati tényezőt jelentenének.

A WMO-n belüli projektvezető-kijelölési rend az egyszerű feladatoknál jól működik: a projektcél megvalósításán dolgozó szervezeti egység szakmai vezetője, vagy a szervezet egy kiug­ró­an jó képességű munkatársa válik jogosulttá a projektvezetésre. A bonyolultabb esetekben már mélyebb projektmenedzsment tudásra van szükség, amihez gyakran nem elég felkészültek az IT-szakértők, -munkatársak, ami jelentős kockázatot eredményez.

Javasolt kategóriák: A fázisok számával (egyfázisúnégyfázisú) megadott osztályozás

II.1.f.     Érintett szervezeti egységek száma

A koordinációs igényből és a szakmai terület sokféleségéből adódó kockázat szinje a szervezeti egységek számával arányosan növekszik. Természetesen itt nem darabszámra, hanem típusra, eltérő szakmai területekre kell gondolni. Előfordul, hogy a szervezeti egység egy külső szervezettel is együtt kell működjön a projekt végtermékének hasznosításában, ami az eltérő cégkultúrák, szerve­zeti sajátosságok miatt fokozott igényt támaszt a projektvezetés szakmai felkészültségével szemben.

Javasolt kategóriák: Egycsoportos, többcsoportos, külsős

II.1.g.    Igényelt projektszervezet mérete

A projektvezető dönthet arról, hogy a projektcél eléréséhez milyen projektszervezetre van szüksége, illetve az Őt a projektvezetésre kijelölő vezető - a kockázatok csökkentésére - ezt elő is írhat­ja. A WMO-nál – mivel a projektmenedzsment még csak kialakulóban van – csak a projekt­vezető által „felállított” virtuális, ideiglenes projektszervezet létezik.

Javasolt kategóriák: Ha megalakul egy projektiroda-jellegű szervezeti egység a WMO-nál, akkor lesz majd értelme egyszerű, illetve iroda-rendszerű projektszervezetről beszélni.

Kockázati besorlási lehetőségek: [5]

Amikor részletesen értékelve áttekintjük a projektek megvalósítási folyamatát, szót kell ejteni az előzőekben már többször említett, az eredményességet, a minőséget, illetve a projektmenedzsment „költsé­geit” befolyásoló kockázatokról is.

III.   Megoldáskeresés

A projektek sikeres megvalósításának egyik – az összetett projektknél különösen - fontos felté­tele azok folyamatainak biztonságos, alacsony kockázati szintű tervezhetősége, valamint és a kitű­zött céltól való minél kisebb eltérés, és ennek tervszerű megvalósíthatósága.

A projektek kialakításától az előkészítésen, a megvalósításon keresztül a lezárásukig igen nagy jelen­tő­sége van azon – felmért - tényezők számbavételének és tervszerű menedzselésének, melyek vára­kozásunk ellenére eltérést okoz(hat)nak, de bekövetkezésük, hatásaik egzakt, vagy legalábbis teljesen egzakt módon nem vetíthetők előre. Kezelésük az esetek részében előre programozható megoldások alkal­mazásával megoldható.

A megvalósításakor bizonytalanságot okozó másik tényezőcsoport az adott projektben előre nem valószínűsíthető, így fel sem mérhető, a projektfolyamatok során véletlenszerűen fellépő jelenségeket foglalja magába. Felmérésük még becslés szinten is nehéz, azonban döntő hatást is gyako­rolhatnak a projektek kimenetelére, ezért a körültekintő projekt-előkészítés ezeket sohasem hagyhatja figyelmen kívül. A projektmenedzsment tudásanyaga, az előző projektek tapasztalatai alap­ján váratlanságuk hatása csökkenthető, kezelésük azonban így is gyakran és főként „ad-hoc” módszereket kíván a projektvezetőktől.

A WMO termékfejlesztési folyamatának kockázatossága közvetlenül függ a folyamat egyes elemeinek és a folyamat közvetlen környezetének kockázatosságától, közvetve pedig a vállalati- és a gazdasági környezet kockázatosságától. A folyamatra, annak elemeire, illetve köz­vetlen környezetére koncentrálok, de szükségesnek érzem, hogy nagyobb anomáliák és hiányos­ságok esetén kitérjek a vállalati szintű elemekre is.

III.1.   A termék előállításának elemei és a hozzájuk tartozó kockázat

A probléma-terület feltáratlan, jelenleg a WMO-n belül szervezeti szinten nincs elegendő isme­ret az érintett területekről, ezért pl. Ishikawa-diagram segítségével jól láthatóan foglalható össze a termékelőállítás folyamata, elemei.

A kapcsolatrendszer feltérképezésénél a lehetséges „9M módszer” szerinti, illetve a folyamat alapján történő szerkesztési, ábrázolási eljá­rás közül az utóbbit választom, mivel ez azáltal, hogy magát az eljárást is megjeleníti, informatívabb.

A 9M módszer esetében az ok-okozati diagram a következő főbb elemeket tartalmazhatná[6]:

Emberi tényező (”Man”): ötletgazda; katalizátor; megrendelő; felhasználó; projektötletet fogadó; a projektvezetőt kijelölő személy; a projektvezető (szakmai-területi-külsős-belsős); a projekszponzor (kiválasztása, konfliktusok, feladata, jelentősége); a projekt szervezete, azaz a feladatvégzők típusonként (hajlandóság, képzettség, motiváció, ISO); további érintettek: a vállalat menedzsmentje, részvényesek, tulajdonos képviselői, stb.

Alapanyag (”Material”): A projektötlet; „Környezettanulmány”;

Vezetés, menedzsment (”Management”): a döntési mechanizmus; a felelősség-hatáskör-tevékenységi kör hármasa és érvényesülése; a WMO vállalati stratégiája; a WMO menedzsmentje, TQM/ISO;

Módszerek (”Methods”): Projekötletek kezelése, Tervezés (pénzügyi, erőforrás, időbeli ütemezés, munkafázisok, mérhető paraméterek), Projekt-menedzsment módszertan (achivement driven project management), Projekt-portfólió kezelése, Vállalati dokumentum-menedzsment, Képzések, Információ-áramlás és –menedzsment, KPI;

Eszközök (”Means”): Projekttervezési és –vezetési eszközök, Fejlesztési eszközök, Alkalmazott eszközök, technológiák;

Motiváció (”Motivation”): Ötletgenerálás, Projekt-szponzorálás, Projektvezetés, Részvétel a projektben, Üzemeltetés, Karrier-menedzsment, Vállalati kultúra;

Környezet, miliő (”Milieu”): Vállalati kultúra, Kapcsolatrendszer;

Rendelkezésre állás (”Maintenance”): Folyamatszabályozás, Személyi és technikai leterheltség;

Pénz (”Money”): Pénzügyi erőforrás tervezése, biztosítása, rendelkezésre állása, Döntési helyzetek, -pontok, -jogosultságok.

Jelen dolgozatomban a témakör tárgyalásához a folyamat-alapú részletezést választom, véleményem szerint a vizsgálandó probléma szemléltetéséhez ez megfelelőbb.

A szolgáltatás előállítási folyamatának lépései, a kockázat lehetséges forrásai a WMO-nál

Indító/ötletadó/megrendelői területnél:

Az Ötlet kialakulása: Vállalati és kultúrális környezet, ötletgazda személyi adottságai, projektek-, folyamatok publikussága, belső kommunikáció, csoporton belüli pozíciók.

Az Ötlet felvetése: Személyi adottságok, szakmai képzettség, ösztönzés, motiváció, belső kommunikáció, pozíciók.

Az Ötlet üzleti szempontú véleményezése (elvetés/továbbengedés): Vezetői, szakértői, véleményezői motivációk, személyi adottságok és szakmai képzettség, motiváció, vállalati kultúra, folyamatok szabályozottsága, dokumentációs rendszer.

Az Ötlet alapján a projektcél üzleti szempontú megfogalmazása: Értékelő személye, empátia-készsége, vállalati kultúra, folyamatok szabályozottsága.

Projektcél súlyozása, elhelyezése a Szolgáltatás-fejlesztési tervben: Értékelő személye, empátia-készsége, vállalati kultúra, folyamatok szabályozottsága.

Projekt kezdeményezése (saját projektmenedzser kijelölése): Szervezeti humánpolitikai adottságok, munkatársak szakmai képzettsége, leterheltség, motiváció.

A Szolgáltatásfejlesztésnél:

Fejlesztési igény esetén a Szolgáltatás-fejlesztés tájékoztatása: időtávok, ötlet előkészítettsége, vezetői támogatottsága, folymatelőírások betartása

A szolgáltatás-fejlesztési projektmenedzser kijelölése: vezetői adottságai, hozzáállása, módszertan megléte, vállalati kultúra, projekt fontosságának helyes meghatározása, dokumentálás.

A projekt költség-keretének ellenőrzése: költségmenedzsment, tervezési módszertan, költségvetés rugalmassága, pontossága.

Költségkeret létezése esetén a projektcél tisztázása, megfogalmazása: projektvezető szakmai felkészültsége és empátiája, szervezői affinitása, Megrendelő szakmai képzettsége együttműködési készsége

A projekt felhasználói specifikációjának elkészítése: Megrendelő hozzáállása, szakmai képzettsége, a projektfeladat szakmai összetettsége, időtáv, leterheltség.

A projekt megvalósíthatósági tanulmányának elkészítése, az ötletgazda szerv projektvezetőjének tájékoztatása: leterheltség, időtáv, szakértők szakmai felkészültsége, ‑ leterheltsége, technológiai igény, a projektfeladat összetettsége, szabványos elemek használata, külső kapcsolatok száma, Megrendelő együttműködési készsége.

A projektcél megvalósíthatósága esetén a megvalósítási tanulmány elfogadtatása, a projekt beillesztése a projekt-portfólióba (erőforrások lefoglalása), a projekt tervezése: projektvezető és a Megrendelő szakmai felkészültsége, reakcióidők, tervezési segédeszközök, előző projektekkel kapcsolatos információk.

Informatikai specifikáció elkészítése, értékelése, a projekt fázisainak, lépéseinek, feladatainak meghatározása, lebontása: feladat összetettsége, technológia újdonsága, szakértők szakmai felkészültsége, leterheltsége, dokumentálás.

A projektcél megvalósítása, termék kifejlesztése, tesztelése, a projekt ütemezése, -vezetése: projektvezető szakmai felkészültsége, projektszervezet összetétele, szakmai kvalitásai, erőforrások rendelkezésre állása, projekt módszertani- és eszköztámogatása, szponzorok együttműködő-készsége, külső kapcsolatok, beszállítói magatartás, dokumentáltság.

Termék átadása az üzemeltetőnek és a felhasználónak: dokumentáltság, időtáv, Megrendelő szakmai felkészültsége, oktatás színvonala.

Projekt-utógondozás, projektzárás: a projektvezető szakmai felkészültsége, projekt­vezetési adatok megléte, dokumentálási rendszer, KPI-ok folyamatos vezetése, folyamat-kontrolling állapota

Az Üzemeltetőnél:

Szolgáltatás és hardvereszközeinek üzemeltetése: dokumentáltság, együttműködés a fejlesztőkkel a megrendelővel, valamint a felhasználókkal (HelpDesk)

Módosítási, továbbfejlesztési igények generálása: üzemeltetők szakmai felkészültsége, monitoring rendszer, felhasználói adatok elemzése, folyamat-kontrolling.

A projektekben előforduló kockázatok súlyosságának és gyakoriságnak függvényében összetett módon értékelhetők és sorolhatók csoportba[7]:

Vizsgáljuk meg az egyes termékfejlesztési lépéseket, főként, hogy azok milyen tényleges kockázati elemeket tartalmaznak, és ezek hogyan viszonyulnak a WMO termékfejlesztési tevékenységéhez! Nem fogok - terjedelmi okok miatt - minden egyes lépésnél a triviális, szakirodalom által az átlagprojekteknél felsorolt kockázati elemekre kitérni, mint pl. vállalati kultúrából fakadó, környezeti tényezők következtében jelentkező, személyi adottságok kiváltotta, vagy véletlen események, stb. okozta kockázatok, inkább a WMO fejlesztési folyamatában általam jellemzőnek tartott sajátosságokat emelem ki.

III.2.   Az Ötlet kialakulása, felvetése

Az Indító/ötletadó/megrendelői területnél alakul ki a feladat csírája: az Ötlet. Ehhez szorosan kapcsolódik az Ötlet felvetésének módja, lehetősége.

Honnan származhat az Ötlet?

Spontán módon indíthatja egy esemény, egy átélt élmény, egy környezeti benyomás, vagy a mindennapi életben felmerült igény észlelése. Kevésbé spontán módon kerül képbe, de feltétlenül gyors reagálást követel az újabb piaci igények megjelenése, és a versenytársak megjelenő újabb szolgáltatásai.

A WMO-n belül jelenleg ezzel ki is merül a források listája. 2003-ban történt meg először, hogy értékesítési területen ötletbörzét szerveztek, azonban a meghívottak körének kiválasztása az értékesítési szakterület látókörébe kerülőkre korlátozódott: a belső kommunikáció hiánya, a lokális kezdeményezések kordinálatlansága következtében értékes szellemi erő- (és ötlet-) forrásokat kerültek el.

A WMO Intraneten egy létrehoztak egy Ötletláda elnevezésű webes felületet (régebben OracleOffice felületen már működött, kevés publicitással), ahol a munkatársak az ötleteiket megjelentethetik, s a területi felelősök, szakértők ezekre a felvetésekre válaszolnak. Az Ötletláda egy moderált webes fórum, menedzselését a TQM Igazgatóság végzi. A szakmai válaszok sokszor hónapokat késnek, ha egyáltalán megérkeznek, illetve a kritikusabb felvetésekre történő vezetői reagálás kultúrája is kialakulatlan: sok a ledorongoló, „Szülő” szereppozícióban íródott válasz. Mivel a WMO-n belül ez az egyetlen kommunikációs fórum, amely nem ’spam’-jellegű (mint ahogy egy ’everybody’ címzésű belső e-mail az), az ötletek mellett egyre szaporodnak a kritikus hangvételű felvetések, reklamációk, amelyek kellő vezetői odafigyelés esetén alkalmasak lehetnek a hiányosságok kiszűrésére. Ezek adott esetben akár projektfeladatot is generálhatnak, de sajnos jelenleg még nem ez a jellemző. Az Ügyfélszolgálati területen dolgozók saját fórumot hoztak létre, mely igen aktívan és hatékonyan működik, de csak lokális szerepe van.

Az ötlet felvetése (az Ötletládán kívül) a saját szakmai vezető felé, igen ritka esetben pedig – amennyiben sikerül kideríteni, kihez is tartozik a kapcsolódó szakterület – a területi szakértők felé történhet. A Feltételes módot azért használom, mert ha az Ötlet nem a saját szakterületét érinti, akkor a szakmai vezető gyakran kézlegyintéssel elintézi az „ötlet-menedzselést”. Kedvezőbbek az arányok, ha az Ötlet e-mailben érkezik a vezetőhöz, és sikerült kideríteni a szakértőt, mert akkor - ha a közvetlen szakmai vezető szűrőjén átment az ötlet - van rá esély, hogy eljusson a szakterülethez.

A szakterület felelősének megállapítása azért nehézkes, mert ugyan van a WMO munkatársakat tartalmazó elektronikus telefonkönyvnek szakterületi rovata, de nagyon kevés szakmai vezető tünteti fel itt a saját beosztottainak kompetenciáját: mivel a kizárólagos jogosultság miatt ez neki munkát jelent, hajlamos az elodázására. „Üzemi vak” vezető esetén pedig a felvetett ötletek továbbjutási esélye elenyésző.

III.3.   Az Ötlet üzleti szempontú véleményezése, üzleti szempontú megfogal­ma­zása, súlyozása, elhelyezése az éves szolgáltatás-fejlesztési tervben

Ha az Ötlettel kapcsolatban az ötletadó bevételszerzési lehetőséget tud kimutatni, vagy a szakértő úgy gondolja, hogy a célzott (vagy annak vélt) eredmény beleillik a vállalat célrendszerébe, stratégiájába, illetve magát az Ötletet valamilyen szempont alapján megvalósítandónak értékelik, akkor az a szakterület befogadása révén az ötlet átlényegül „ottani” feladattá. Amennyiben az Ötlet üzleti területet érint, akkor az Üzletfejlesztési igazgatóság hatáskörébe kerül, majd ott - az elérni kívánt felhasználók száma, köre, fontossága függvényében - egy alapszintű megvalósíthatósági értékelést készítenek róla, és ha ez pozitív, akkor bekerül a megvalósítandó feladatok listájára. Ezután a megvalósításhoz pénzügyi forrást kell találni, és be kell illeszteni az éves szolgáltatásfejlesztési tervbe: fontosságától függően pótlólag az aktuálisba, vagy előjegyeztetni a következő évibe. Negatív esetben az Ötlet elvetésre kerül, mindenféle dokumentálás, a jövőbeni esetleges újragondolási lehetőségének biztosítása nélkül!

Kockázat:

Hiányzik az Ötletek utógondozása, nincs lehetőség azok gyűjtésére, későbbi elemzésére, hasznosítására. Az üzleti vagy a szakmai terület ötletet vizsgáló szakértőjének empatikus készsége, szakmai felkészültsége, tájékozottsága, sok esetben motiváltsága meghatározza az Ötlet további sorsát.

III.4.   Projekt kezdeményezése

Amennyiben nem üzleti projektről van szó, hanem a szakterületen kell fejlesztési vagy egyéb feladatot végrehajtani, akkor kétféle kimenettel találkozhatunk: ha az adott szakmai területnek van projekvezetésre alkalmasnak tartott munkatársa, és az megbízható ezzel a feladattal (van szabad munkakapacitása), a projektvezetéssel Őt bízzák meg. Előfordul, hogy nincs ilyen munkatárs: ekkor „kölcsön kérnek”, azaz a megvalósításhoz kapcsolódó informatikai feladatokra utalva az informatikai, szolgáltatásfejlesztési területről kérnek projektvezetőt.

Ekkor jön létre a Megrendelői szerepkör.

Ha a szakterület nem a saját szervezetén belül valósítja meg a projektjét, hanem az kapcsolódik a szolgáltatásfejlesztési divízió termékfejlesztési folyamatához, akkor vagy

üzleti/ügyfélszolgálati projektről van szó (szolgáltatásfejlesztési tervbe kerül), vagy

a szakmai terület a szolgáltatásfejlesztéstől kér projektvezetési segítséget, vagy

a projektet a Szolgáltatásfejlesztési divízióban kezdeményezik, illetve

speciálisan szolgáltatás-fejlesztési, -módosítási feladatról van szó (a szóba kerülő problémák ugyanúgy jelentkeznek a „nem-IT” területeken is).

Kockázat:

A hiányos folyamatszabályozás, a belső kommunikáció problémái a projektötlet időérzékenysége esetén annak elévülését okozhatják.

III.5.   Fejlesztési igény esetén a szolgáltatásfejlesztés tájékoztatása

A tájékoztatás történhet az éves szolgáltatásfejlesztési terven keresztül, illetve közvetlen megkereséssel (év közben).

Amennyiben a feladat effektív pénzügyi kiadással jár, a szolgáltatásfejlesztési divízió vezetéséhez kell eljuttatni a kérést (ők kezelik a fejlesztésre fordítható pénzügyi keretet), míg ha „kisebb”, vagy tényleges pénzmozgással nem járó igényről van szó, a folyamatot, az esetleges szűrőket megkerülve megesik, hogy a Megrendelők nem a szolgáltatásfejlesztési menedzsmentet, hanem közvetlenül a szolgáltatásfejlesztési területi szakértőket keresik meg. Ennek „oka”, hogy a projektmenedzserek, azaz a megrendelő szempontjából a munkát irányító „felelősök” a szakértők csoportvezetői közül kerülnek ki (ritkán az agilisebb szakértők is kapnak ilyen feladatot), és egy más szervezettől érkező, de igazgatói szintű levélre (a tekintélyelv alapján) könnyen egy - bármilyen felső engedélykérés nélküli - elfogadás a válasz: vagy válaszlevélben, megkezdve a végrehajtáshoz szükséges kommunikációt, vagy - ha a szakértő/csoportvezető szerint minden információt tartalmazott már az eredeti levél, és pillanatnyilag van szabaddá tehető kapacitása, - „ráutaló magatartással”, azaz a feladat végrehajtásával. Az előírások következetes betartásának megsértése nem von semmiféle súlyosabb szankciót maga után.

Kockázat:

A szolgáltatásfejlesztés vezetése nem értesül az adott erőforrás lekötöttségéről, és „ráterveznek” újabb feladatokat, ami munkatorlódást okoz.

Fellazul a fegyelem, ami áttevődik más folyamatokra is.

A feladat alapjai, részletei nincsenek a szükséges mértékig feltárva, illetve a koordinálatlanság következtében felesleges, jobb esetben párhuzamos munkavégzés történik.

Bármilyen probléma esetén a felelősség megállapítása nehézkes, alapértelmezésként a feladat végrehajtása miatt a szakértői csoport „vétkességét” vélelmezik.

A nyilvántartásba teljes körűen nem kerül be a rendszerben a kérésre végrehajtott végrehajtott módosítás.

III.6.   A szolgáltatás-fejlesztési projektmenedzser kijelölése

Amennyiben elérkezett az információ a vezetéshez, sor kerülhet a projektmenedzser kijelölésére.

Mint jeleztem, a gyakorlat az, hogy a feladathoz legközelebb álló szakterületek csoportvezetői, - „fontosabb” projektek esetén a terület vezetői - egyben a projektek vezetői is. A több, mint 200 fős szolgáltatásfejlesztési divízión csak 5 fő „függetlenített” projektirányító van: 1 főosztályvezető, 2 WMO-s projektmenedzser, 1 „külsős” (külső válallkozás által delegált, outsourcing-) projektmenedzser, és egy fiatal projektkoordinátor. Ez a létszám természetszerűleg elenyésző az éves szinten a 400-at közelítő projektszámhoz képest, a tendencia csak a folyamatok alapos felülvizsgálata és átalakítása révén tud csak megváltozni.

A kijelölés menete egyszerű: vezetői értekezleten a területek vezetői között elosztják a fela­datot, illetve ha olyan projektről van szó, ami több területet átfog, vagy valamilyen paramétere miatt kiemelt fontosságú, akkor a „függetlenített” projektmenedzseri csoport vezetője kapja meg a lehetőséget. Az így érte­sített vezetők – ha úgy ítélik meg, hogy „leadható” a feladat, - jelölik ki az adott projekt veze­tőjét, ellenkező esetben nekik kell a projektvezetést felvállalniuk. Ennek következtében elő­fordul­hat, hogy tucatnyi aktuális projekt „nyomja” egyes, rátermett szakértőkkel kevésbé ellátott szak­mai csopor­tvezető vállát, de olyan erőforrás-pazarlás is tapasztalható, amikor 4 független projektmenedzser dolgo­zik a főosz­tályvezető irányításával egyetlen, bár kiemelt fontosságú projekten!

A kijelölés majd’ mindig szóban - ritkább esetben e-mailben megfogalmazott „ráutaló szövegezéssel” - történik.

Kockázat:

A projektmenedzser kijelölése a projekt alapparaméterei rögzítésének, valamint a felelősség átru­házásának a pontja. A megbízólevél a projektszemléletű munkavégzés igen fontos eleme, melynek tartalmaznia kell többek között (a bővebb, részletesebb anyagot a megbízólevél mellék­leteként csatolva):

a projekt főbb adatait (megnevezés, azonosító, rövid leírás, megrendelő);

a megbízásról szóló jogi érvényű szöveget;

a vonatkozó szabályozásokat, speciális körülményeket, amelyek meghatározzák, korlátozzák a projekt vezetőjének hatáskörét;

a projektről rendelkezésre álló vezetői- és indító információkat;

a monitoring-feladatokat, jellemzőket, paramétereket (összeghatárok, hatáskörök, ismert kockázatok, gyakoriság, speciális résztvevő, stb.);

a kapcsolattartó(k) meghatározását, aki(k) felé a projektvezetőnek jelentenie kell;

az előre meghatározott egyéb jellemzőket.

Ez a feladatkiadás egyik alapköve, enélkül nem lehetne egyetlen projektet sem felelősséggel elkezdeni. A WMO-n belül sajnos jellemző, hogy a feladatkiadás is – bár igen erős levelező-kultúra van kialakulóban – elkerüli az írásbeliséget! Bárminemű probléma esetén az írásbeliség hiánya a közreműködők szintjén egymásra mutogatást, vagy a beosztott mély hallgatását, a vezetői „ledorongolás” elviselésének kényszerét eredményezi. A vezetők egyik, a hozzáállásukra jellemző véleménye,: „Ez egy félkatonai szervezet: itt vagy befogod a szád, vagy elmész!” (Szolgáltatásfejlesztési Divízió vezetője egy értékeléshez kapcsolódó reklamációs esetben).

Írásbeli feladatkiadás nélkül a teljesítés értékelése is problémába ütközik, hisz nem létező követelmények teljesítéséről kell meggyőzni a vezetőt, illetve a ki nem mondott igények teljesítésének hiánya, annak számonkérése is nyomasztóan hat a feladatvégzőkre. Különösen igaz ez akkor, ha az adott munkatárs a projektfeladatokat nem a szolgáltatásfejlesztési területről, hanem más WMO-s terület vezetőitől kapja: ilyenkor nem marad nyoma a teljesítés minősítésének!

A projektek vezetése jelentős mértékű projektvezetői ismereteket igényel, melyek egy szakmai szakértőnél ritkán érik el a kívánt szintet: a csoportvezetők az elvégzett projektek során a „trial-and-error” módszerrel tapasztalatot szerezhetnek ugyan, de ez nem elegendő a korrekt, alacsony szakmai kockázatot jelentő projekttervezéshez, -irányításhoz, ‑menedzseléshez. A WMO-n belül nincs projektmenedzsment-oktatás (az MSProject szoftver használatának oktatásával kimerül a képzés), így csak önképzéssel, vagy tanulmányi szerződéses egyetemi képzéssel sajátíthatóak el a szükséges ismeretek:

A projekt-menedzselés tudáshalmaza

≈ 6/8 rész Általánosan elfogadott projektmenedzsment tudás és gyakorlat

≈ 1/8 rész Általános menedzsment-tudás és gyakorlat

≈ 1/8 rész Alkalmazási területekhez kötődő ismeretek és gyakorlat

Ez is jelzi, mennyire kockázatos, amikor szakmailag magasan képzett munkatársakat emelünk ki – akár csak egyes feladatra is – projektvezetői státuszba: nem elegendő a saját illetve ágazati szakterületük ismerete az adott kérdéskörben, annál a szakmai tudáshalmaznál nagyságrendekkel nagyobb, szélesebb körű tudásanyagra van szükség egy összetett projekt esetén. Ez ugyan korlátozza csak, de nem zárja ki az adott szakértő projektvezetési képességeit, azonban megnöveli a kockázatot, valamint az ellenőrzés-, és a megfelelő módszertan kidolgozásának, alkalmazásának igényét. Ez a „kisebb” projektek esetében az adminisztrációs kötelezettségek növekedéséhez vezet, tehát a módszertanban kell megtalálni a szükséges optimumot: hol kell „receptkönyvet” használni, és mikor, mely fázisokban, melyik projektmenedzsment-területen elegendő a rugalmas előírások bevezetése, használata.

Amit a projektmenedzsernek -a szűkebb ágzat sajátosságain túl- ismernie kell 

Projekt-integráció menedzsment: Projektterv elkészítése, menedzselése, végrehajtása, változás-menedzselés

Projekt hatókör menedzselése : Indítás, Hatókör-tervezés, -definiálás, -ellenőrzés, -változás menedzselése

Idő-menedzsment : Tevékenység definiálása, sorbaállítása, tevékenységidők becslése, tevékenység-menetrend tervezése, -ellenőrzése

Projekt-költség menedzselése : Erőforrás-tervezés, költségbecslés, költség-költségvetés beosztás, költség-kontroll

Projekt minőség-menedzselése : Minőség tervezése, minőségbiztosítás, minőség-kontroll

Emberi erőforrás-menedzselés: Szervezet-tervezés, projekttagok kiválasztása és bevonása, csapatépítés,

Kommunikáció menedzsment: Kommunikáció tervezése, információ “terítése”, státusz-riportolás, befejezés dokumentációja

Kockázat-menedzsment: Kockázat azonosítása, kockázat mértékének meghatározása, kockázatra való reagálások tervezése, kockázatkezelés ellenőrzése

Beszerzés-menedzsment: Beszerzések tervezése, megrendelések tervezése, bonyolítása, a beszállítói lehetőségek és források értékelése, szerződések kezelése, adminisztrálása, teljesítése, lezárása.

Hogyan lenne célszerű a WMO-nál – a sajátosságok figyelembe vételével - egy projektet kezdeményezni?

Eset-1. A szolgáltatás IT üzemeltetője vagy más IT szerv, szakmai vezető véleménye/igénye/utasítása alapján, a jelentkező körülmények (új eszköz vagy új alapfolyamat megjelenése, hardver- vagy szoftver- „upgrade”, stb.) miatt ki kell dolgozni, vagy jelentős mértékben át kell dolgozni egy adott szolgáltatást. Az igény megjelenése, felmerülése lehet az indító esemény.

Eset-2. A szolgáltatás IT üzemeltetője vagy más IT szerv, szakmai vezető véleménye/igénye/utasítása alapján, a jelentkező körülményekben létrejött változások, kisebb módosulások (eszköz vagy alapfolyamat kisebb változása, stb.) miatt kisebb mértékben módosítani kell az adott szolgáltatást. Az igény megjelenése, felmerülése lehet az indító ok.

Eset-3. Az éves szolgáltatás-fejlesztési tervben meghatározott projektek esetében a projektet indító szervezet által készített feladat-megnevezés a projekt kiinduló momentuma.

A Szolgáltatásfejlesztési divíziónál úgynevezett „end-to-end projektmenedzsment” van, azaz a szakértői projektmenedzser-kijelölés következtében az a munkatárs, aki az adott szolgáltatást a projektteam-mel projektmenedzserként kifejleszttette, az lesz kijelölve a későbbiekben is az ehhez a szolgáltatáshoz kapcsolódó további projektek vezetésére.

III.7.   A projekt költség-keretének ellenőrzése

Adott a projektfeladat, és meg kell vizsgálni, mekkora költségkeret rendelhető hozzá!

Az éves költségkeretet a Szolgáltatásfejlesztési divízió tartja nyilván, a Pénzügyi és Kontrolling igazgatóság irányításával végrehajtott előző évi tervezés eredményeként. A tervezés mondhatni elnagyolt: a költségvetésben azon feladatokra, amelyekre készült megvalósíthatósági tanulmány, szakértői véleménnyel már alátámasztható összeg szerepel, a többi feladatra szakértői becslésekkel („ex-has”, azaz hasraütésszerűen) megadott összegeket „pántlikáznak fel”. Az elnagyoltságra jellemző pl. a következő generációs technológia majdani bevezetésére vonatkozó tervezés: 20 évre előre meg kellett adni a főbb tervszámokat (!) az Európai Központ felé akkor, amikor a műszaki elavulás sebessége az iparágban 2-5 év, és 5-10 éven belül újabb generációs technológiák robbanásszerű megjelenése várható (!): a chipek már elérték a „zsugorítási” határukat, emiatt a teljesen új, szerves alapú technológiák fejlesztése (bio-chipek) rohamléptekkel folyik (megjelentek az első bíztató kísérleti eredmények), az információ-technológia túlhaladta a rácsodálkozás és kezdeti ismerkedés fázisát, beépült a mindennapi életbe, egyre tisztábban körvonalazódnak a különféle társadalmi, munkaköri, jövedelmi rétegek igényei, stb.

Ha az adott feladathoz nincs előre meghatározott költségkeret, akkor vagy a tartalékból, vagy pedig első lépésben a Megrendelő egyéb projektjeitől, illetve amennyiben azok startégiailag fontosabbak más területek projektjeinél, akkor ezen területek kisebb fontosságú projektjeinek keretéből történik az átcsoportosítás. Az új vezetés törekvése már, hogy ez valóban így is történjen.

Kockázat:

A költségmenedzsment és a projekt-nyilvántartás Excel táblái külön kézben, más-más szakértőknél, ráadásul teljesen eltérő bontásban és szerkezetben taglalják a feladatokat, emiatt az egyeztetés, összefuttatás igen körülményes: csak a különböző költségcsoportok csoportok vizuális egyeztetésére, „visual”-táblás, értekezleten lezajló „portfólió-menedzsmentre” van lehetőség. Megoldást a szemléletváltás mellett az egységes, de kellően rugalmas projektmódszertan, egy felkészült, 15-20 fős központi projektmenedzsment szervezet, illetve ehhez kapcsolódóan egy testre szabott, az adottságoknak és a kívánalmaknak, feladatoknak megfelelő szoftver biztosíthat.

III.8.   Költségkeret létezése esetén a projektcél tisztázása, megfogalmazása, a projekt felhasználói specifikációjának elkészítése

A kijelölt projektvezető megkapta a megbízást, az alapadatokat és a Megrendelő paramétereit, és ekkor megkezdődhet a projektcél tisztázása. A jelenlegi folyamatban egy felhasználói specifikációt vár a projektmenedzser, amelynek tartalmaznia kell minden olyan információt, adatot, meghatározást, amit a felhasználó a projekt szempontjából fontosnak tart. Amennyiben nem megfelelő, akkor egy iterációs „kérdés-felelet” alapú pontosítás következik, amíg a projektvezető úgy nem érzi, hogy a projekt megtervezéséhez már minden információval rendelkezik.

Kockázat:

A Megrendelő nem feltétlenül rendelkezik azokkal a szakmai ismeretekkel, amelyek az igény teljesítési lehetőségeinek kidolgozásához, az alternatívák értékeléséhez kell, így a feladat a Megrendelő megfogalmazásában - nyelvezetben, részletességben, megfogalmazódott, de le nem írt igényekben - el fog térni attól, amit az anyagból a projektvezető kiolvas.

Az ebből származó eltérések kiküszöbölésére a projektvezetőnek képesnek – és megfelelően motiváltnak - kell lenni a tényleges projektcél feltárására, azaz megfelelő irányított kérdésekkel kell meghatározni a projekt esetleg ki nem mondott célját, a megvalósítás kritériumrendszerét. A Megrendelőnek írásban meg kell határoznia azokat a mérhető és teljesítendő célokat, amelyeket a projekt során a megoldásoknak el kell érniük. Ezek lesznek a további lépések alapjai, ezek a „világítótornyok”, amik felé haladni kell. Minden eltérést, módosítást ezek fényében kell értékelni. Jelenleg mindez a projektek majd’ mindegyikénél hiányzik.

III.9.   A fejlesztési megvalósíthatósági tanulmányának elkészítése, véglegesítése

A projektvezető elkészíti, illetve a technológiát a saját ismereteinél mélyebben érintő esetben - a kapcsolódó területek szakértőinek bevonásával - elkészítteti az informatikai megvalósíthatósági tanulmányt.

Megvizsgálják, hogy a Megrendelő által a felhasználói specifikációban megfogalmazott célt a rendelkezésre álló eszközökkel, technológiákkal milyen módon lehet megvalósítani, és ez a megoldás megközelítően milyen költségvonzatot jelent. Ha nem áll rendelkezésre a szükséges technológia, akkor a projektvezetőnek fel kell mérnie a piaci lehetőségeket, és javaslatot kell tennie a választandó megoldásra.

A megvalósíthatósági tanulmányt a szolgáltatásfejlesztési vezetők részére a projektvezetőnek prezentálnia kell, majd beépítve az esetleges vezetői változtatásokat, a véglegesnek szánt verziót a jogosult vezetővel elfogadtatni. A véglegesített verziót, azaz a megvalósíthatóság értékelését el kell juttatni a Megrendelő kijelölt képviselőjéhez

A Megrendelő elfogadhatja a tanulmányt, alternatívák esetén kiválasztva a számára elfogadható megoldást (dokumentálva a választást), vagy amennyiben nincs elfogadható alternatíva, újragondolja a projektcélt, esetleg lemond a projektről.

Kockázat:

A termékfejlesztési folyamat ezen lépésének sikere és kockázata nagyrészt a projektvezető szakmai adottságaitól függ: megfelelő módszertan szabályozás hiányában, túlzott önbizalom esetén a szakértők megkeresése nélkül önmaga dönt, ha pedig határozatlan, akkor a szakértők a technológia oldaláról helyette eldöntik, hogy mi a „helyes” megoldás. Az időkorlátok szűkössége, valamint a projektvezető és a szakértők minél kisebb energiafelhasználásra való hajlama miatt az alternatívák kidolgozására nem feltétlenül kerül sor, így a megrendelő képviselőjének nem a projektcélnak – az aktuális ismereteik szerint - legjobban megfelelő, hanem az elsőként megfelelőnek talált, „kielégítő megoldást” javasolják [11].

A megfelelő szakértő megtalálása is kockázati tényező, kritikus pont: nem a szakértői csoport vezetője jelöli ki, hanem a projektvezető leggyakrabban a „felderítés” eredményeként fellelt szakértőtől kérdez. Ez a WMO-nál még nem a projekt keretei között történik, és így sok minden múlik (főleg a válaszadás időpontja és részletessége) a szakértő hajlandóságán és a projektvezető rámenősségén, munkatársi kapcsolatain.

Ha nem megfelelő a kommunikáció a Megrendelő és a projektvezető, illetve a szakértők között, hogy a döntésekhez szükséges kérdésekre megfelelő választ adhassanak, az jelentősen növeli a kockázatot. Általában a szakértői közreműködés a projekt ezen szakaszában nem olyan mélységű, mint az informatikai specifikáció meghatározásánál, csak a lehetséges technológiai, haladási irányok kitűzése a cél. Emiatt lehetséges, hogy később, a részletesebb elemzés során a javasolt, illetve a Megrendelő által kiválasztott megoldás zsákutcának bizonyul, vagy jelentős mértékű módosítást igényel (határidő, pénzügyi keret, elérhető célértékek).

Problémát okozhat az is, ha a Megrendelő nem nyilatkozik írásban a számára megfelelő alternatíva elfogadásáról, mert ekkor nincs olyan elfogadott dokumentum, amely felelősséggel alapját képezheti bármilyen későbbi változtatási igénynek („mozgó célra lőnek a fejlesztők”). Előfordulhat, hogy a Megrendelő nem is látja a kiegészített tanulmányt, csak a projekt eredményében - jobb esetben részeredményében - tapasztalja a hiányosságokat: ekkor jöhet a változásmenedzsment.

III.10.         A projektcél megvalósíthatósága esetén a projekt beillesztése a projekt-portfólióba (erőforrások lefoglalása), a projekt tervezésének megkezdése

Ha a Megrendelő elfogadta a megvalósíthatósági tanulmányban leírt javaslatot, megkezdődik a projekt tervezése. Első lépésként a megvalósíthatósági tanulmány és a rendelkezésre álló információk alapján a projektvezető meghatározza a bevonandó szervezeti egységeket, szakértőket. Ezután – a szakértői csoportokkal, illetve a felkérésre a projekthez rendelt szakértőkkel együttműködve - elkészíti az Informatikai Specifikációt, amely már részletesen tartalmazza a projektcél eléréséhez szükséges fejlesztés technológiai folyamatát, és a feladatkiadáshoz szükséges adatokat. Ez az alapja a projekt további tervezésének.

Kockázat:

A Megrendelő nem érti a megvalósíthatósági tanulmányt, nem az ő nyelvén készül. Előfordul, hogy csak egy, a szakértők részvételével zajló értekezlet világosíthatja meg számára a dokumentum tényleges tartalmát. Az ilyen – „laikusokat győzködő” – értekezleteket a szakértők szakmai magasságukból értékelik, nem szeretnek ilyenen részt venni. Tulajdonképpen igazuk is van, mert a dokumentum összeállításánál a projektvezető feladata a két (több) szakmai terület közötti tolmácsolás, amit az érintett szakterületekkel kapcsolatos ismeretek tesznek lehetővé számára. Sajnos a WMO-nál nincs lehetőség, rászánt és engedélyezett idő, hogy a speciális területekkel időben megismerkedjen a projektvezető. „WMO-akadémia” néven megkezdődött egy szakmai ismertető előadássorozat, de az előadások eltérő célja, megközelítése miatt elkerüli az eredeti célt: van ahol túl szakmai, míg a másik véglet a populáris elemek ismétlése.

III.11.         A projektcél megvalósítása, termék kifejlesztése, tesztelése, a projekt tervezése, ütemezése, vezetése

A projektvezető elkészíti a projekttervet, majd megkezdi a megvalósítását. A monitoring jelenlegi működése egyszerű: ha beosztott szakértőről, vagy kiemelt projektmenedzserről van szó, ő a közvetlen vezetőjének jelent, a vezetője által éppen igényelt módon és gyakorisággal. Ha csoportvezetőről van szó, akkor ő csak a hatáskörén kívüli problémákat jelzi a vezetőjének.

A felmerülő problémákat, a valamilyen szempont szerint kiemeltnek számító projekteket a heti rendszerességgel megtartott osztályvezetői értekezleten beszélik meg a Szolgáltatásfejlesztési divízió jelen lévő vezetése, csoportvezetői, projektmenedzserei. Pozitív kezdeményezés, hogy a dolgozók (fejlesztők, tesztelők) képviselői is jelen vannak, jegyzetelhetnek, így továbbadhatják az információkat.

Kockázat:

A projekt tervezése, annak részletessége, pontossága, teljessége kizárólag a projektvezetőn, annak felkészültségén múlik. Ellenőrzése a vezetői hozzáállás következtében sajátosan kettős: ha már volt a projektvezetőnek „sikeres” projektje, akkor erősen lanyhul a vezetői kontroll, ugyanakkor a közvetlen vezető gyakran a projekt megvalósításának operatív szintjén utasít változtatásra, akkor már, amikor a projektfeladat a végrehajtási szakaszba ért.

Nincs projekttervezési módszertan, a „ki hogy tudja” elv érvényesül: a „Prince”, az „SSADM” fogalmakat legtöbben csak hallomásból ismerik a projektvezetők, azokat, vagy azok bármelyik módszertani részét csak elvétve alkalmazzák.

Projekt szponzorok felkérése nem történik meg, azok általában „csak úgy adódnak”: automatikusan „generálódnak” a Megrendelő szervezet vezetőjéből, illetve a Szolgáltatásfejlesztés valamelyik kapcsolódó vezetőjéből. Projekt Irányító Bizottság csak elvétve, a vállalati stratégia szempontból kiemeltnek minősülő projektek némelyikénél fordul elő.

Az emberi erőforrás-menedzselés ad-hoc jellegű: a szakértői csoport vezetője jelöli ki a projekttagot. Nincs szakértői nyilvántartás arról, kinek milyen szakismerete, tapasztalata van a különféle technológiákban. Nem elérhető a humán adatbázis, hogy a szerződő külső cégről egy esetleg ott dolgozttól információt lehessen beszerezni, stb.

A projektterv leggyakrabban egy MSWord dokumentum, vagy Excel tábla. Ritka a MSProject ismerete, illetve használata, más projektmenedzsmentet támogató szoftver nincs használatban (a szoftverfejlesztők megelégelték az „eszköztelenséget”, és ismerettségi körből „beszereztek” egy ClearQuest példányt néhány felhasználóra). Ennek következtében a dokumentummenedzsment, illetve a változásmenedzsment is csak a projektvezető körültekintő tevékenységén múlik, támogatás nincs. A dokumentumok verziózása ad-hoc jellegű, változtatásuk rendszere, nyilvántartásuk, az elavultak visszavonása teljességgel hiányzik, így gyakran előfordul, hogy az egyes szereplők más-más érvényességű dokumentumokból dolgoznak.

A projektek erőforrás-tervezése tervszámok szintjén létezik, azaz egy erre a célra készített web-es felületen elérhető nyilvántartásba a projektvezető felveszi a projektek adatait, itt igényel (humán‑) erőforrásokat az általa kapcsolódónak gondolt szakértői csoportoktól. A szoftver e‑mailben tájékoztatja a szakértői csoport vezetőjét az igényről, aki ezt - Excel, Word, ClearQuest rendszereket használva - betervezi a saját erőforrás-nyilvántartásába. Összefuttatási lehetőség nincs, így a részterveknek szinte semmi köze nincs a divízió szintű erőforrás-tervezéshez, vagy a projektportfólió-menedzsmenthez, hiányzik az átgondolt, egységes menedzselés lehetősége. Nem humán erőforrások menedzselése kaotikus: a rendszererőforrásokat, pl. tesztelési környezetet a szakterület munkatársának projektbe hívásával, vagy külön egyeztetéssel kell lekötni. Mivel „off-line”, azaz közvetlenül el nem érhető az erőforrás-nyilvántartás, a változásmenedzselés igen kockázatos és körülményes: előfordulhat, hogy sikertelen tesztelés esetén a következő tesztelési időpont a projekt határidejénél későbbre áll csak rendelkezésre. Ezt a körültekintő, belső tapasztalattal rendelkező projektvezetők már tartalék-tesztelések betervezésével megkísérlik csökkenteni, de ezzel a tesztelési környezetben okoznak relatív túlterhelést, esetleges egyéb tesztelési munkák elutasítását.

Pénzügyi erőforrásmenedzsment kizárólag a külső cégektől megvásárlásra tervezett eszközök, szolgáltatások tekintetében tapasztalható.

A belső erőforrások költsége nincs meghatározva, így csak a rendelkezésre-állásuk az egyetlen felhasználási korlát. Ennek következtében a végtermék bekerülési értéke meghatározhatatlan.

Követelménnyé vált, hogy a beszerzési javaslatnak lehetőség szerint legalább 3 alternatív lehetőséget kell tartalmaznia. A javaslatot a Beszerzési Igazgatóság vezetője ellenőrzi, majd a szakmai vezetés véleményét figyelembe véve engedélyezi vagy átdolgozásra visszaküldi.

A szerződések kezelése projktmenedzserenként változik, nincs nyomonkövetési előírás. A szolgáltatásfejlesztési divízió pénzügyi referensei a pénzügyi nyilvántartó rendszerbe bevezetik a megrendeléseket, de az áruk beérkezését már a projektvezetőknek telefonon kell lekérdezni, a kifizetések megtörténtét a pénzügyi osztályon úgyszintén, nincs automatikus értesítés. Az ISO9001:2000 bevezetése révén látszanak a csírái egy beszállítói minősítő rendszernek, de ez is inkább adminisztratív célokat szolgál (engedélyezési eljárás támogatása), mintsem a megfelelő szállító kiválasztását, ami eddig is leggyakrabban tendereztetés során történt: amelyik pályázó a kiírásban szereplő direkt, és a szubjektív indirekt kívánalmaknak leginkább megfelel, az a nyer. Azonban a meghívottak körének kiválasztása egyrészt a projektvezető infrormáció-gyűjtő képességén és piacismeretén múlik, de jelentős befolyásuk van a „házi beszállítóknak” is: botrányos felelősségrevonással végzőhet, ha valamelyik felső menedzsment-tag ismerős válallkozása nem kerül be a meghívottak közé.

A szerződésekre nincs szerkezeti irányelv, nincsenek sablonok, minták, vagy „modulok”, amelyekből azokat fel lehetne építeni. Ez különösen azért fontos, mert a megkötött szerződések kb. 90%-a angol nyelvű, és a WMO‑n belül csak egyetlen jogász van (a jogi osztály vezetője), aki angol nyelvű anyagokkal való munkára jogosult. A munkakörökhöz nem előírás a nyelvismeret, ugyanakkor a hivatalos dokumentációs nyelvként az amerikai angol lett előírva! Magyar nyelvű helyesírás-ellenőrző nincs is a jogtiszta szoftverkészletben! Ezek következtében a jó szerződés csak tapasztalt projektvezető kezéből kerül ki, aki „össze tudja ollózni” az elérhető, régebbi szerződésekből az éppen szükséges részeket. Ugyanakkor az angol nyelvtudás előírásának és oktatásának hiánya miatt az angol nyelvű szerződések elkészítése megvalósult kockázatok esetén jelentős jogi hiányosságokat takarhat, nem beszélve a jogi szövegek útvesztőiről! A Szolgáltatásfejlesztési divíziónál a kockázatot felismerve külső jogi szakértő cégeket alkalamznak a fontosabb szerződések kidolgozásához. Ez jelentős többletköltséget jelent, költségkeret-csökkenése révén rontva az érintett projektek eredményességét.

A projektek során teljesen hiányzik a kockázatmenedzsment: nem azonosítják a kockázati elemeket, nincs súlyozás, ézékenységi elemzés, hiányzik reagálások tervezése (döntési fák, kockázat elkerülése, -elfogadása, -elhalasztása, -áthárítása, -csökkentése, stb.). Az esemény bekövetkeztekor, a környezet adta lehetőségek között kezelik a megvalósuló kockázat következtében létrejött problémákat.

Nincs projektminőség-menedzsment, a minőségbiztosítási alapelveket a vonatkozó vezérigazgatói utasítások tartalmazzák. Ezeket már az ISO 9001:2000-nek való megfelelés jegyében kellett létrehozni: 2003. elejéig csak az ügyfelekkel, azaz a szolgáltatásokra előfizetőkkel közvetlen kapcsolatban álló szervezeti egységek tevékenységére létezett szabályozás. A szabályozás elkészítésénél az „ISO-sítási” folyamatok során az auditorok számára jól ismert vállalati viselkedés volt tapasztalható: az utasítások kidolgozásánál „alapelv” volt, hogy az ne tartalmazzon mást, mint amit jelenleg is végeznek a munkatársak, azaz ne legyen benne minőség-szempontú új előírás, folyamatmódosítás, ezzel látva biztosítottnak az auditon való megfelelést. Az utasítások igazgatóságonként és speciális területenként elkészültek ugyan, de egymáshoz való illesztésük, WMO-szinten egységes folyamattá alakításuk hiányzik. Fogalomrendszereik, nyelvezetük különbözik, ugyanakkor a WMO-nál nagy hangsúlyt fektetnek az újabb utasítások megjelenéséről történő tájékoztatásra. Az utasítások ismeretéről azonban senkinek sem kell számot adni.

A projektekkel kapcsolatos kommunikáció-menedzsment sem létezik. Szinte kizárólag a projektbe bevont munkatársak, a tájékoztatást megkapó vezetők szereznek tudomást a projektről. Ez ugyan biztonságtechnikai szempontból jó lenne, azonban ez ebből a szemszögből hasznos véletlen, mivel ilyen célú biztonsági rendelkezés nincs. Ugyanakkor a projekt elfogadtatása, az oktatás és bevezetés megkönnyítése, szélesebb körű információ biztosítása igényelné a kommunikációt. Kizárólag a projektcél elérése, a projektek során megszabott feladatok elvégzése az, ami számított a munkavégzésnél. Vajon miért?

A projektek során a tisztázatlan feladatkiadás, a projektmenedzseri feladatok írásbeli megjelölésének, kiadásának hiánya, a munkatársak bevonásának módja, és mindennek vezetői szintű támogatása az oka, hogy az eredményesség számít. Az a védekezés, miszerint „a piaci igények gyors teljesítése nem tette lehetővé, hogy a célon kívűl szélesebb körben is törődjünk a projektekkel, dokumentáljuk, esetleg elemezzük azokat” – teljességgel káros és értelmetlen: csak a mának élő gondolkozást jelent.

A „felelősök” széles – és meghatározhatatlan - köre lehetetlenné teszi a felelősségrevonást, a dokumentációk, minőségi előírások hiánya pedig mindezek rögzítését, elemzését, bizonyítását. Ha határidőcsúszással, tervezettnél magasabb költséggel, sok vezetői beavatkozással folyik le egy projekt, vagy ellenkezőleg mindez gyorsan, frappánsan, pontosan megszervezve történik, az a projektmenedzserre, vagy a projekttagokra nézve szinte semmi különbséget nem jelent: legfeljebb az utóbbi esetben a projektvezetőben és a Megrendelő képviselőjében jelentkezik bizonyos sikerélmény, de egyéb módon nem marad nyoma.

Hiányzik a vezetők általi elismerés, nincs semmilyen külső motiváció. A teljesítmény = f( képesség * motiváció) képletet a WMO termékfejlesztési folyamatára megvizsgálva az eddigiek alapján látható, hogy a szükséges helyen a képességek nagy része hiányzik, és a vállalkozás – legalábbis projektvezetői és végrehajtói szinten - motivációs elemekben sem bővelkedik. Az átlagosnál magasabb jövedelmi szint és a cégkultúra magas szintje miatt az elbocsátás elkerülésére törekvés, és a saját munka sikeressége: igen szűkös motivációs készlettár. Persze a szakértők számára bizonyos fokú előrelépési lehetőséget jelenthet az, hogy rátermettségüket - a szakterületükön kívül mást nem érintő projektek sikeres vezetése esetén - közvetlen vezetőik felé bizonyíthatják, és ezzel (a 2-300 fős divíziólétszámhoz mérten elenyésző mértékben) évente egyikük talán magasabb beosztásba kerülhet.

Teljesítményértékelés létezik a WMO-nál: évente egyszer a vezetők (elvileg célkitűzések, gyakorlatilag saját szubjektív véleményük alapján) egy elektronikus rendszerben értékelik a beosztottaikat. Ezt az értékelést konszenzussal kell zárni, és a dolgozónak következő periódusra vállalásokat is kell tennie, amelyek a következő értékelés alapját kell képezzék. A rendszerben azonban nics semmiféle kontroll: a vezetők szubjektív véleménye ellen a rendszeren keresztül felszólaló dolgozó reklamációját hónapok múlva sem „veszik észre”, miközben az így kapott „értékelés” képezi az alapját az azt követő, általában rendszeresen megjelenő fizetésemelésnek, és a jutalmazásnak. A jutalmazás egyik része a válallati eredménytől függ, és a maradék az egyéni teljesítménytől, de ha az egyéni teljesítményt a vezető alacsonyra értékeli, akkor se fizetésemelés, se saját jogú-, sem pedig vállalati jutalomrész nem illeti a dolgozót.

Ellentmondási lehetőség a dolgozói képviselet hiánya miatt nincs: van ugyan a Felügyelő Bizottságnak két, dolgozók által beválasztott, úgynevezett „dolgozói képviselője”, azonban mindkettőt egy, a WMO vezetése által összeállított listáról kell megválasztani, és mindkettő munkáltatói jogokat gyakorló igazgató.

Ennyit érdemes volt megemlíteni a maslowi biztonsági szükségletek kielégítettségéről, ami pedig alapját, korlátait képezi a „magasabbrendű” szükségleteknek[13] is.

III.12.         Termék átadása az üzemeltetőnek és a felhasználónak

A sikeres tesztek után a termékek, fejlesztett szolgáltatások átadása a szolgáltatási felületek elérhetőségének biztosításával megtörténik. Amennyiben ez egy meglévő rendszerhez annak elemeként közvetlenül kapcsolódik, akkor a termék üzemeltetője az adott rendszer addigi üzemeltetője lesz, a fejlesztés eredményét feléjük is kommunikálni kell.

Ha a végtermék egy önálló informatikai egység, akkor az informatikai hardverelemek, adatbázisok üzemeltetése az IT Támogatási igazgatóság munkatársai közül erre kijelöltek feladata lesz. A kijelölés az üzemeltetési csoport belső ügye, az eredményt közlik a Megrendelővel. A terméknek, mint szoftvernek az üzemeltetése azonban a Megrendelő feladata. Ha ezt nem képes felelősen ellátni, akkor külsős céget kell ezzel megbízniuk.

Kockázat:

Az üzemeltetés kritériuma az üzemeltethetőség: ha az elkészült termék menedzselése körülményes, nem illik bele a megszokott környezetbe, esetleg nem köthető össze a meglévő Help-Desk rendszerrel, akkor az üzemeltetők hozzáállása is negatív lesz. A projekt tervezésébe már be kell vonni az üzemeltetők képviselőit is, mivel a megvalósíthatóság nagyrészt az ő véleményükön is múlik.

A dokumentáltság a gyors és hatékony üzemeltetéshez elengedhetetlen: már a projekt részeként el kell készíteni az üzemeltetés számára szükséges információkat tartalmazó dokumentumot, amiből majd az Üzemeltetési dokumentáció elkészíthető. Már a projekt elején ki kell alakítani az Üzemeltetés és a Megrendelő, illetve a Megrendelő által kijelölt esetleges szoftverüzemeltető közötti kapcsolatot, lehetőséget kell adni a projekt vonatkozó részének megismerésére.

III.13.         Projekt-utógondozás, projektzárás

Egy hosszú távra tervezett szolgáltatásnál elképzelhetetlen, hogy a projekt befejezéseként ne végezze el a projektvezető a befejező munkálatokat: a dokumentációk archiválását, a projekt folyamatának elemzését, értékelését mind saját, mint pedig a többi projekttag vonatkozásában. Ekkor célszerű a kockázatkezelési terveket is a tapasztalatokkal kiegészítve karbantartani.

Kockázat:

A WMO-n belül a projektzárás elmulasztása „bocsánatos bűn”-nek tekinthető. Ennek több sajnálatos oka van, például:

A projektvezetői felhatalmazás és felelősség hiánya;

A monitoring rendszer működésének hánya;

A dokumentálási kötelezettség és az ellenőrzés hiánya;

Nincs projektelemzés, nincs tapasztalati adatbázis, nem őrizték meg az elmúlt projektek adatait, amiből esetleg tanulságot, következtetéseket lehetne levonni;

Vezetők sem igénylik az elemzéseket, értékeléseket.

Pozitív jelenég, hogy az új vezetés néhány projektet (3-4-et havonta) teszt-jelleggel prezentálásra kötelez, egyelőre szűk és zárt körben. Az elemzéshez azonban több év adatára lenne szükség, és ezt előállítani sem lehet, hiszen nincsenek megfelelő dokumentációk, amikből a szükséges adatok kinyerhetők lennének. Egy javasolt, az elemzést támogató KPI-lista:

Az Üzemeltetőnél:

III.14.         Szolgáltatás és hardvereszközeinek üzemeltetése

Az Üzemeltetés menetének kidolgozása az Üzemeltető felelőssége, de beszámolási kötelezettséggel a Megrendelő szervezet felé is tartozik.

III.15.         Módosítások, fejlesztések igényének jelzése

A módosítások, további fejlesztések a műszaki és az üzleti éelt velejárói. Dokumentáció hiányában a rendszer „drótozása” valósul meg, azaz nem az eredeti szerkezetbe illesztik a módosítást, hanem pl. ideiglenes megoldásokat véglegesen bennehagynak a termékben, vagy teljesen más logikával oldják meg, mint ahogy az az eredeti megoldás szerint történt. Dokumentáció hiányában a módosítás is csak a kuszaságot növeli. Egyes rendszerek érzékenységi és konzisztencia-vizsgálata katasztrófáli sállapotokra figyelmeztette a vezetést, de ijedtségre és változtatási szándékra kevés jel mutat.

Kockázat:

A rendszer elbonyolódik, módosításakor az átláthatatlansági szint növekedése során egyre szélesebb körű tesztelésre lesz szükség, ami a piacra jutási időt, ezáltal a versenyképességet csökkenti. Elérhetik azt a szintet, amikor lehetetlen lesz úgy beilleszteni egy változtatást, hogy az ne okozzon más, már meglévő rendszerelemekben kárt, váratlan működésbeli eseményeket.

III.16.         ISO kontra rugalmasság, projektvezető „alkotói szabadsága”

Az ISO szabályozás miatt elkészített folyamatleírások – Vezérigazgatói szintű utasítások – szövegesek, megértésük és követésük értelmezésbeli különbségek miatt személyenként eltérhet. A rugalmasságot nem az értelmezésben, hanem a döntési pontokon kell biztosítani.

Az utasítások könnyebb érthetőségét – különösen, mivel műszaki szemléletű munkatársakról van szó – folyamatábrákkal lehetne biztosítani: amikor megváltozik egy folyamat, a folyamatgazda –a ki felelős az adott folyamat működéséért – azonnal megteszi a módosítást egy központi, mindenki által elérhető folyamat-felületen. Mivel a WMO-nál jelenleg is használják az ARIS szoftvert folyamat-ábrázolásra, az ARIS eszközeivel leképezett folyamathalmaz hatékonyan támogathatná a munkavégzést: mindenki a mukájához ezt venné figyelembe. Ez az egységesítés mellett lehetővé tenné az új belépőknek a minél gyorsabb „szinterhozását”, csökkentve a képzési, betanulási időt és kockázatot. A változásokat az elektronikus levelezőrendszeren az érintettek számára elérhető módon (pl. Publikus folderben, levelező-listán, stb.) közé kell tenni.

IV.  Megoldási javaslatok, összefoglalás

A WMO termékelőállítási folyamatának vezetői többszörös nyomás alatt állnak, melyek egymás ellen hatnak:

Meg kell feleljenek a magyarországi Tulajdonos és az Európai Központ egymással gyakran nem egyirányba mutató elvárásainak

Teljesíteniük kell a WMO vezetősége által kitűzött célokat

Megbízhatóan, sikeresen kell dolgozzanak, hogy karriercéljaik megvalósuljanak

Eleget kell tegyenek a beosztotti elvárásoknak.

A termékfejlesztést végző szervezet jelenleg átalakulás alatt áll: az ad-hoc, szakértői projekt-vezetők kijelölésétől rövid időn belül el kell jusson egy stabilan működni képes, dedikált projektmenedzserekből és projektkoordinátorokból, munkaszervezőből és adminisztratív munkatársakból álló projekt-szervezetig, ami lehet egy projektirodár aalapozott szervezet is, amely csökkenthetné a jelenlegi projektmenedzsment-eljárásokban meglévő kockázatokat. Ehhez át kell alakítani a folyamatokat, a beosztott vezetők és munkatársak gondolkodását, el kell fogadtatni, fel kell ismertetni a WMO felső vezetésével a szorosabb együttműködés szükségességét, és meg is kell azt valósítani. Az átalakításhoz sok idő és sok munka kell, emellett a WMO-nak válallatszinten (is) fel kell ismernie, és fel kell vállalnia, hogy ezt a hatalmas munkát nem képes egyedül elvégezni: megfelelő külső szakértőkre van szükség, akik - együttműködve a folyamatosan kialakuló állandó projektszervezettel - megtervezik, kommunikálják, bevezetik a változtatásokat, megtanítják a vállalatot az „új módira”.

A jelenlegi folyamatok igen sok féle, a WMO-ra erősen jellemző kockázatot tartalmaznak, melyek költségnövekedést vagy bevételkiesést jelentenek. A legjelentősebbek:

A projektmenedzsment ismeretek alacsony szintje;

Hiányzik a megfelelő, testreszabott projekt-menedzsment módszertan, és ennek támogatottsága;

A dokumentáltság szintje elégtelen, az elkészült dokumentumok szerkezetben és minőségben projektenként és projektvezetőnként eltérő értékűek;

Nincsenek „történelmi” adatok, így a visszatekintő elemzést lehetetlen alkalmazni;

A folyamatleírásokat csak az ISO-auditra történő megfelelés feltételének tekintik;

Nincs kialakult, a vállalati startégiát támogató minőségszemlélet sem a munkatársak, sem pedig a vezetés szintjén;

A megvalósítási folyamat, szervezés közepesen hatékony, minőségre törekvés nem tapasztalható;

A „standard” kockázati helyzetek:

résztvevők kiválasztása, együttműködési rendszere (cégek, személyek);

finanszírozás, pénzügyi háttér;

erőforrás allokáció (beruházási, dologi, humán);

ütemezés (határidők, interdependes tevékenységek beillesztése);

szerződések (megvalósítási, együttműködési, finanszírozási, megbízási, szállítási, vállalkozási-műszaki-gazdasági-jogi feltételek);

minőségbiztosítás;

kontrolling-monitoring, jelentés rendszer;

kommunikáció (külső, belső);

szállítói eredetű kockázatok : mindent beígérünk a szerződés elnyeréséért - majd csak fejlesztünk valamit ennyi idő alatt, legfeljebb késünk; szerződés tartalmának beszállítói vitatása; szerződésektől eltérő (olcsóbb, elavultabb) megoldások; többletek jóval drágábban; csak a szállító tud a rendszerhez hozzányúlni; kevés az erőforrás (túlvállalta magát); kilép a szerződésből, felfüggeszti a teljesítést, fázisokban szállít

projekt személyzet cserélgetése;

korlátozott szakértői időkontingens;

nincs idő dokumentáció készítésre;

számlázási problémák;

oktatás (tematika, személyek, módszerek, ütemezések, helyszínek);

dokumentálás (célcsoportok, tartalom, ütemezés, adathordozó);

tesztelés, próbák, átadás-átvétel. [14]

A kockázat felmérése és kezelésükre felkészülés súlypontja a projekt kialakításának és előkészítésének az időszakára esik, ami az IT típusú, összetett projektek esetén a legkörültekintőbb elemzést igényli. Elhagyása vagy lekicsinylése az egész projektet veszélyeztetheti, esetenként sok millós beruházás sikerét kockáztatva. Számolni kell azzal, hogy a kialakítási és előkészítési fázis időtartama elérheti akár a projekt megvalósításét (!) is, ami összetett projektek esetében önmagában is jelentős, több hónapos időigényű lehet.

Először a projektben bárhol megjelenő, jelentősebb kockázattal járó, belső- és külső eseményekhez kapcsolódó folyamatelemeket kell felmérni, rögzíteni, majd a jellemzőik alapján azonosítva csoportokat kell belőlük képezni, ezáltal a hasonló jegyek alapján megkönnyítve elemzésüket és a kezelési javaslatok kidolgozását. Azonban nem szabad elfelejteni, hogy a kockázati elemek azonosítása a hatásos kezelésnek szükséges, de nem elégséges feltétele: a kockázatok alapos elemzése nélkül a kezelési mód megválasztása mind nehezebbé válik. Fel kell mérni a tényezők műszaki jelentőségét, a stratégiai- és más részcélokra való hatásukat, az emberi-, pénzügyi erőforrásra, a finanszírozási folyamatra, a határidőkre, ütemezésre, a minőségre, az együttműködés különböző szintjeire, majd súlyozni kell ezeket a majdani kezelés módjának megválasztásához.

A hibák fellépésének valószínűségére, érzékenységvizsgálatokra, költségkihatásokra vonatkozó elemzésen keresztül 'láthatóvá tett' kockázatokat értékeljük: az értékelés során felállítható egy kozkázati prioritási sorrend, összevethetőek az értékben megállapított közvetlen és közvetett károk, a kockázatkezelés különféle erőforrásigénye, valamint az ezek kompenzálására fordítható különféle szankciók pénzértéke (kötbér, kártérítés, biztosítási díjak, stb.).

A tervekben rögzítettekhez képest eltérések jelentkezhetnek a célkitűzésekben (stratégiai és részcélok), a projekt stratégiákban, a tervezési paraméterekben (műszaki tartalom, szállítási volumenek, kapcsolódó munkák, hatósági többletek, költségbecslés, stb.), a szállítói-kivitelezői körülményekben (műszaki tartalom megvalósítása: nem tudja/nem akarja/véletlen, a dokumentálás, számlázás, kifizetés problémái), a lebonyolítási szakaszban ( ütemezésbeli-, sorrendiségi-, műszaki eltérések, pénzügyi-számlázási és együttműködési-szervezeti anomáliák). Jelentkezhetnek személyek közötti, csoport szintű és cégszintű (megrendelői, szállító-kivitelezői) konfliktusok, valamint tervezési, lebonyolítási, vállalkozói teljesítések során észlelt, kijavítandó hibák.

A kockázatkezelés általánosan ismert, a WMO-n belül azonban egyáltalán nem használt lehetőségei:

A kockázat elfogadása. Az azonosított, hatáselemzéssel megvizsgált és kiértékelt kockázatok kezelése, amely például a különböző, de főként a projekt stratégiájába történő beépítés révén valósulhat meg.

A kockázat elkerülése. E kezelési módszer alkalmazásával az adott kockázati tényező különösen nagy mértékű hatását a szerződésekbe építve, vagy a műszaki tartalmat megfelelően korrigálva lehjet kizárni, pl. eredményfelelősség szerződéses kikötése.

A kockázat csökkentése.

Vezetői támogatásnak már a projekt indításakor történő „megszerzésével”;

tájékoztatás, oktatás, megfelelő kommunikáció révén;

a megfelelő projekt szponzori szint megválasztásával; hatékony projektszervezet kialakításával, működtetésével;

a belső erőforráshiány fel- és elismerésével, valamint éppen ezért a WMO-tól független szakértők, szakértő-irodák bevonásával;

megfelelő tartalékok beépítésével a projekt szükségesnek ítélt területein;

korrekt versenyeztetéssel;

alternatívák kidolgozásával, forgatókönyvek előkészítésével.

A kockázatok áthárítása, megosztása. Történhet - többek között - szerződéses szankciókkal, fizetési feltételek szigorításával, biztosításokkal, illetve a résztvevőkkel egyeztetett intézkedési tervek útján lehetséges.

A változások és eltérések kezelése egymáshoz hasonló eljárást igényel:

Észlelésük módszeres jogszabály-figyelésre, projekt monitoring-, projekt értekezleti- és jelentésrendszerre alapozható. Kezelésükhöz fontos rögzítésük helye és módszere (pl. szoftveres úton kezelt hibalisták, folyamatosan vezetett eltéréslisták, műszaki tárgyalások-, projekt értekezletek jegyzőkönyvei, a vezetői tárgyalási emlékeztetők, papíralapú és/vagy elektronikus levelezés). Mindezekből könnyen átlátható tevékenységi listák készíthetők, melyek a megoldások teendőit, felelőseit is dokumentálják.

A beavatkozás módja lehet: szoftveres dokumentált hibafelszámolás, műszaki tartalom módosítása (növelés vagy redukálás), szerződésmódosítások, számlák kifizetésének visszatartása, kötbérezések, jóteljesítési garancia, többlet erőforrások aktivizálása,

A döntések szintjei:

Menedzsment, vagy cégvezetés;

Projekt Irányító (vagy Koordinációs) Bizottság, projekt-szponzorok;

Projektmenedzser.

Ezt követi a beavatkozás időpontjának meghatározása, időtávjának, hatásterületének, a szükséges erőforrásoknak a felmérése, majd a beavatkozás végrehajtása és az ellenőrzés, valamint a dokumentációkon való átvezetéssel, illetve a projektkockázatok kezelési folyamata a projekt zárását követően az utólagos elemzéssel, kockázati lista kiegészítésével zárul.

Hogyan történhet mégis, hogy a WMO az eddigiekben feltárt kockázatos folyamatelemek jelenléte ellenére mineddig sikeresen piacra vitte a termékeit, saját ágazatában meg tudta őrizni piacvezetői pozícióját (bár a részesedése szintje évről-évre folyamatosan csökken)? Mi kompenzálta, mi akadályozta a kockázatok bekövetkezését?

A beszállítók projektmenedzsment-módszertana a partneri kapcsolat létesítésének alapfeltételei (pl. ISO 9001: 2000 minősítés) miatt létezik, és legtöbbször a WMO-énál határozottabb. Így a külső cégekkel való együttműködés során a „külsős” projektmenedzser készíti el a dokumentumokat, a minőségbiztosítási tervet, gyakran a projekttervet is, ő méri fel a kockázatokat, megtesz mindent, ami az ő magasszintű munkájához szükséges. Ebből természetszerűleg ( az eljárások átvételével, de az aktuális projekt zökkenőmentesebbé tételével) profitál a WMO-s projektvezető is.

Sokáig az ágazatban a legmagasabb fizetési szint jellemezte a WMO-t, amely nimbusz napjainkra elhalványult: vannak ugyan munkahelyi közérzetet javító intézkedések (közös ünnepélyek, a vezérigazgató sportcentrikusságából adódóan a sportolás széleskörű támogatása: sportnap, saját fitness-center, egészségügyi támogatás, stb), de ezek jelentősége megszokottságuk és mindenki számára elérhetőségük miatt csökken. A jövedelmek már nem annyira piacvezetők, mint voltak évekkel ezelőtt, és teljes mértékben hiányzik a dolgozók részére munkával kapcsolatos dolgokba való beleszólás lehetősége („félkatonai szervezet: vagy befogod a szád, vagy mehetsz” - szolgáltatásfejlesztési igazgató), nincs üzemi tanács, nincs szakszervezet (üldözött bármiféle erre való utalás).

A projektmenedzsmenttel kapcsolatos zűrzavar csökkenthető és csökkentendő is.

Ennek egyik eleme a folyamatok vállalati szintű összehangolása rugalmas, mindenki által elérhető szabályozásokon keresztül.

Az Üzletfejlesztési- és a Szolgáltatásfejlesztési Divízió között erős rivalizálás tapasztalható. Az üzletfejlesztési projektmenedzserek fogják össze a komplex, piaci igényt kielégítő projekteket, ugyanakkor nem rendelkeznek szakismerettel a részprojekteket vezető informatikai szakterületekről, és viszont: az informatikai területek nem rendelkeznek azokkal az üzletfejlesztési stratégiai információkkal, amelyek az új technológiák bevezetéséhez szükséges döntések megalapozottságához szükségesek lennének. Megoldást jelenthetne a projektfejlesztési módszertan közös kidolgozása, a folyamatok „összegyúrása”, illetve olyan projektszervezet kialakítása, amelyben mindkét terület szakértői egymás mellett dolgozva végeznék a projektekkel kapcsolatos feladatot.

A „csapatépítések” jelenleg igen divatosak, azonban az informatikai csoportok (átlagéletkor 25 év alatti!) összetartóak, számukra ezek az összejövetelek már kirándulás-számba mennek. Hatékonyabbá tehetők ezek a rendezvények, ha a közvetlenül együttműködő területek munkatársait hívnák össze a többnapos, célirányos „összekovácsoló” tréningekre.

A második szükséges intézkedés a munkatársak motivációs lehetőségeinek kidolgozása, a projektmunka sikerességének megfelelő kmmunikálása, elismerése, honorálása. Ez a vállalati politika, ezen belül is a humán-stratégia szerves része kell legyen.

A harmadik szükséges intézkedés a projektmenedzsment folyamatok harmonizálása a vállalati stratégiával, folyamatokkal, valamint a piaci és külső-/belső vevői igényekkel.

Ennek javasolt megoldása egy kellően magas létszámmal dolgozó projektiroda létrehozása. A kizárólag egyetlen szakterületet érintő, egyszerűbb projektek, feladatok menedzselése – karriermenedzselési szempontokkal összekötve – maradhat szakértői projektvezetők feladata, azonban a projektmenedzseri szakmai hiányosságokból eredő kockázatok csökkentésére szoftveres támogatás szükséges.

A szoftvernek tudnia kell támogatni a Szolgáltatásfejlesztési divízió összes projektjét egyidejűleg és egyedenként, a WMO-s projektportfóliót menedzselni, az erőforrásokat nyilvántartani, -kezelni, a monitoring feladatokat ellátni, valamint a dokumentációs rendszert is megvalósítani amellett, hogy megfelelően rugalmas, de korlátok közé szorított szabadosságú alternatívákat ajánl fel a különböző projekt-típusok kezelésére.

A WMO környezetének elemzése alapján 3 szoftveres alternatívát vázolhatok fel:

a.       A NIKU6 projekt-portfólió menedzsment szoftvert ( https://www.niku.com/02-eBusiness_Applications/index.html ) az Európai Központ előírására, a Központtal közös nemzetközi projekteknél kötelező használni. Az adatbázis a Központnál van, az alkalmazók (így a WMO munkatársak is) webes felületen keresztül érik el adataikat. A szoftver valójában csak egyes projektek menedzselésére alkalmas, workflow-rendszere szegényes, portfólió-kezelése igen korlátozott.

b.      A Primavera Enterprise projekt-portfólió menedzsment szoftvert ( https://www.primavera.com/products/enterprise.html ) a Detecon&Diebold Con­sul­tants (https://www.detecon.com/en/?sid=3f5e3eebcd463d7d067fe5c0f56313d7) cég a WMO számára 2002-ben készített elemzésében (amelyben 12 hasonló méretű vagy azonos iparágban tevékenykedő európai válallatot vizsgált meg és hasonlított össze) az összes többi használt szoftverrel szemben előnyben részesítette. Az értékeléssel nem értek teljesen egyet, mivel a vitathatatlanul korszerű szoftver alkalamsságának vizsgálatánél figyelmen kívül hagyta a kapcsolódó WMO-s infrastruktúrát és a felhasználók képzettségét: a WMO-n belül mindenki Microsoft Office-szal dolgozik, erre épül a teljes back-office folyamat szoftverellátottsága, ezt a felületet szokták meg a felhasználók, ennek elektronikus összekötése várhatóan kevesebb problémát tud okozni.

A Detecon felmérésére 2 okból került sor: egyrészt védekezésül, mivel igazolni kellett a Tulajdonos és a Nemzetközi központ felé, hogy a nemzetközi tapasztalatok alapján nincs egyértelműen jó projekt-portfólió kezelő szoftver, ezáltal alátámasztva a WMO eddigi „hezitálását”, továbblépésének elmaradását. Másrészt - felismerve a jelenegi állapot tarthatatlanságát - ötletet, megoldási javaslatot kerestek egy nemzetközi hírű cég anyagában a továbblépéshez (a nemzetközi hírnevet megerősítette, hogy „udvari beszállítója” az Európai Központnak).

c.       Részemről egy harmadik, a Microsoft MSProject Pro és Szerver megoldását tartom a WMO számára az előző kettőnél megfelelőbbnek: egyrészt a biztosított szolgáltatásai a Primavera Enterprise-szal azonos szinten vannak, másrészt a WMO-ban alapszoftverként használt Microsoft Exchange+MicrosoftOutlook levelezési rendszerrel integrálva munka- és költséghatékony megoldást kaphat a cég (Az első MSProject szoftververziók csak az egyes projektek nyilvántartására, tervezésére voltak alkalmasak, nem támogatták a portfólió-kezelést, de a csoportmunkát sem).

A szoftver önmagában nem elégséges a továblépéshez, szükség van a megelőző folyamat-racionalizálásra, valamint az említett, korszerűbb projektszervezet, egy projektiroda létrehozására. Nincs igazán jó vagy rossz módja egy projektiroda létrehozásának, és nagyon sok modell szerint megvalósítható .

A projektiroda gyors eredményességének 7 alapfeltétele Tom Block szerint:

Szorosra fogni az elszabadult projekteket;

Segítően közreműködni a projektindításnál, és megvalósítani az előrejelzési és kockázatkezelési feladatokat;

Projektportfólió áttekintése és kezelése;

A projekt-felülvizsgálatokat irányítani, projektbeszámolókat ellenőrizni;

Az erőforrás- halmaz szervezése, menedzselése;

Kiválasztani és továbbképezni a projektvezetőknek alkalams munkatársakat;

Megtervezni, létrehozni és keresztülvinni a projektmenedzsment módszertant.

A sikeresség az, ami megmutatja, helyes volt-e a döntés: persze csak akkor, ha megfelelő munkakörnyezetet, felelősségi-, tevékenységi-, döntési- és hatásköröket biztosított számára a szervezet vezetése.

Ennek megértése azért fontos, mert egy helyesen megválasztott hatáskörű projektiroda nem csak a projektvezetőkön, hanem a szervezet, a vállalkozás minden kapcsolódó vezetőjének munkájában jelentős segítséget jelent.

A projektiroda-rendszerű szervezeti egység bevezetésének várható pozitív hatásai:

Folyamatrendszerű működés hatékonyságának növelése;

Megnövekedett jövedelmezőség a gyorsaság és kockázatcsökkentés révén;

Optimalizált és „egy kézben” tartott projekt-portfólió;

Csökkenő projekt-költségek (kockázatok költségei mellett a belső költségek is csökkennek);

Megnövekedett és ellenőrizhető minőségi jellemzők;

Csökkenő piacrajutási idő;

A projektcélok változásának ritkulása;

Minimalizált projekt-kockázatok ;

Dokumentummenedzsment rendszer hatékony működtetése: verziókarbantartás, archiválások, egyöntetű jelentések statisztikák (jelenleg a WMO-n belül nincs egységes, több területet lefedő iktató-rendszer: néhány terület saját folyamatot dolgozott ki. Az informatikai semmiféle dokumentum-nyilvántartás, archiválás nincs!);

Felgyorsul a piaci lehetőségekre való reagálás sebessége ;

A projektek jobban igazodhatnak a válallati- és szervezeti stratégiához ;

Hatékonyabb együttműködési- és erőforrás-menedzsment szervezeten belül, valamint más szervezetekkel együtt, azaz a vállalatszintű projekttevékenységek hatékonyabb felügyelete;

Hangsúlyosabb team-munka és –együttműködés a projekt minden fázisában ;

Központosított tapasztalat és összehangolt tevékenységek ;

A szervezeti elképzelések, célok eredményesebb kommunikációja ;

Előrelátás és magas szakmai színvonal biztosítottságának képe a vállalaton belül (is).

Tagjai közé delegálni kell – a rendelkezésre álló humán-erőforrás kapacitástól függően – minél több szakképzett projektmenedzsert, akiknek a WMO vállalati folyamataival történő minél gyorsabb megismerését az ARIS rendszerben leképezett és megjelenített folyamtrendszer mellett rotációs elven lefolytatott bevezető ismerkedéssel kell segíteni (jelenleg nincs rotációs gyakorlat, egyhetes „orientációs” tréningen ismertetik meg az ágazati technológiák és a WMO működésének alapjaival az új belépők mindegyikét, pozíciótól és szakképzettségtől függetlenül). Adminisztratív létszámmal támogatva a háttértevékenységet, és megfelelően szakképzett, kiemelkedő empatikus képességgel rendelkező rendszerszervező vagy munkaszervező munkatársat alkalamzva az összetett projektek indítási körülményeinek mélyebb és részletesebb feltárására. Nem hiányozhat egy prezentációra és oktatásra alkalmas munkatárs sem, aki a projektek kommunikációs részét menedzselné, levéve a terhet a szakértőkről.

Így talán lehetségessé válik, hogy nagyobb belső emberi erőforrás-szerkezeti változtatás nélkül a projek­tek minőségbiztosítási igényének, a Megrendelő által kimondottan vagy hallgatólagosan el­várt feltételeknek megfelelően tervezzék és hajtsák végre a helyesen kiválasztott és megfelelően – a saját szakterületükön túl is – képzett projektvezetők a WMO Szolgál­tatás­fej­lesz­tési divíziójánál is a projektfeladatokat.

Hivatkozások

] A Guide to the Project Management Body of Knowledge (PMBOKa Guide) 2000 Edition. Project Mana­gement Institute, Newton Square, Pennsylvania, USA. ISBN: 1-880410-25-7 (CD-ROM)

[ 2 ] Dr. Baracskai Zoltán - Döntés, Oktatási segédanyag, Budapest, 2002.

[ 3 ] Dr. Baracskai Zoltán - Problémamegoldás, Oktatási segédanyag, Budapest, 2002.

[ 4 ] Tom Block: The Seven Secrets of a Successful Project Office. https://www.projectmanagementarticles.com/project_management_software3.asp (letöltve: 2003.09.07)

[ 5 ] Dr. Gyökér Irén – Szervezeti Viselkedés, Oktatási segédanyag, Budapest, 2001.

[ 6 ] Dr. Pataki Béla – Technológiamenedzsment, Oktatási segédanyag, Budapest, 2003.

[ 7 ] Dr. Szabó Gábor Csaba – Minőségmenedzsment módszerek, Oktatási segédanyag, Budapest, 2003.

[ 8 ] Útmutató a projekt előkészítő dokumentumok kialakításához. MeH IKI, 1996. (Készítette a Minisz­ter­elnöki Hivatal Informatikai Koordinációs Iroda megbízásából az MTA Információtechnológiai Alapítvány).

[ 9 ] TenStep Project Management Process, Risk Management https://www.tenstep.com/7.0 ManageRisk.htm (letöltve: 2001.10.06)

[10] Skobrics Tibor: Bevezetés a PRINCE projektirányítási módszertanba. MTA Információtechnológiai Ala­pítvány, 1993.

[11] Eric Berne: Games People Play. The Psychology of human Relationships. Andre Deutch Ltd., London, 1968. Fordította: Hankiss Ágnes. Gondolat Könyvkiadó, Budapest, 1984.

[12] Kovács György: Kockázatkezelés, változás- és eltérésmenedzsment multiprojektekben. A HTE 6. Távközlési és Informatikai Projektmenedzsment Fórumán elhangzott előadás. 2002.

Megjegyzések