Az alábbi megállapítások alapja nem módszeres felmérés, hanem saját és ismerősöktől, kollégáktól valamint IPMA vizsgázóktól szerzett tapasztalatok. Ezek nem csak a bankszektorban figyelhetők meg, de az informatika komplexitása miatt itt vetődik fel a legélesebben.

A probléma

„In-sourcing” ide, „beszállító-konszolidáció” oda, a közelmúlt ilyen és hasonló jelszavai, sőt, a megtett lépések ellenére sok esetben továbbra sem biztosított az elvárt méretű és hozzáértésű szakértői csapat a pénzügyi szektor szereplőinél folyó jelentősebb méretű projektekben. A kisebb és közepes kezdeményezésekkel ellentétben ezek megvalósítására a vállalatok továbbra sincsenek felkészülve belső erőforrásokkal – ez persze nem is lenne célszerű, – de a megfelelő külső erőforrások bevonása sem mindig egyszerű feladat. A kevés vagy nem elég felkészült erőforrással elindított vagy futtatott projektek emiatt előbb-utóbb bajba kerülnek és megcsúsznak időben, vagy nem tudják az elvárt terjedelmet vagy minőséget leszállítani. Márpedig egy szervezet nagyprojektjei a projekt porfolió meghatározó „zászlóshajói”, amitől számos más kezdeményezés, projekt vagy üzleti cél függ, ezért ezek változásaira kiemelten érzékeny a szervezet és a vezetés.

A közelmúlt szervezeti változásai és hatásuk

1. A válság kitörését követően a pénzintézetek is költségcsökkentési akciókba kezdtek. A beruházások elhalasztása mellett a működési költségek (OPEX) érdemi lefaragását is megcélozták. Ennek egyik eszköze a szervezeti karcsúsítás volt, aminek keretében számos olyan kollégától is megváltak, akiknek korábban szerepe volt a projektek megvalósításában: üzleti elemzők, minőségügyi szakemberek, rendszerszervezők, projektvezetők, – és ha volt házon belül – fejlesztők is. Ezzel természetesen a projekt-leszállítási képesség lényegesen csökkent. A válság éveiben azonban nem emiatt fájt legjobba a döntéshozók feje.

2. Elsősorban a válságra válaszul adott költségcsökkentési lépések egyike volt a beszállítók „konszolidációja”. Ennek legfőbb célja szintén a költségcsökkentés volt a szerződések újratárgyalásával, de emellett – jobb esetben – megjelent a működési kockázatok csökkentésének célja is a kisebb, kevésbé stabil partnerek kiváltásával, vagy alvállalkozói státuszba kényszerítésével. Ezt a folyamatot tipikusan a beszerzési szervezet vezényelte le, melynek során beszerzési elvek érvényesültek: azok a beszállítók kerültek előtérbe, akiknek az árai felfelé kilógtak a mezőnyből, vagy nem tudták/akarták vállalni a szigorodó, már-már extrém fizetési feltételeket. A tőkeerősebb, és létszámban, kompetenciakörben jelentősebb partnerek felé való elmozdulás általánosságban segíti a projektek leszállítását, hiszen ezektől a partnerektől rugalmasabban és szélesebb körben lehet erőforrásokat bevonni, és ezek pótolhatják a leépített belsősöket. Az árakban is jelentős – számukra kedvező, csökkenő irányú – elmozdulást könyvelhettek el a bankok. A „vendor-konszolidáció” során azonban a partnerség pénzügyi és szerződéses jellemzői mellett a szakmai szempontok általában nem kerültek figyelembe vételre, pl. hogy az adott partner csapatával mennyire kritikus üzleti folyamatot, alkalmazást, vagy azt futtató infrastruktúrát támogatott, ill. fejlesztett tovább. Így megesett, hogy az üzletmenet szempontjából kritikus területen megmaradt a kiszolgáltatottság egy kisebb, szakmai és kapacitás-korlátokat jelentő, ezáltal kockázatosabb partner irányában. Ennek következményeit elsősorban a nagyprojektek viselik, melyekben jelentős – olykor több tíz – elemzői, tervezői, fejlesztői, tesztelői erőforrásra lenne szükség. A belső szervezet karcsúsítása után ugyanis ilyen szakemberek belsőleg szinte egyáltalán nem, és egy kisebb partnertől is csak nagyon korlátozottan állnak rendelkezésre. A beszállító-konszolidáció tehát sokszor jó a projekteknek, de nem mindig, egyúttal indokolatlan várakozásokat kelthet a vezetésben, mondván „túl vagyunk a konszolidáción, most már csak válogatott jó partnereink vannak”. Ez nem mindig áll fenn.

3. Az utóbbi időszakban elsősorban az informatikai szervezeteken végigsöpört „in-sourcing” láz egyrészt annak a bevallása, hogy a korábbi kiszervezéssel átestek a ló túlsó oldalára, ugyanis: (a) ha a külsős szakembereket szinte folyamatosan kell igénybe venni, akkor persze már drágábbak, mintha belül lennének és (b) a partnerek felé megnőtt a kiszolgáltatottság, ami növeli a működési kockázatokat. Az ismét vagy újonnan létrehozott státuszok lehetőséget adnak a kisebb projektek, követő fejlesztések belső „staff-olására”, azonban ez a részleges visszaszervezés nem fedheti le a nagyprojektek erőforrásigényét. Ugyanakkor ott a veszély, hogy a korlátozott insourcing lépések után a vezetésben hamis várakozás alakuljon ki: „Most vettünk fel X embert, hogyhogy nincs elég erőforrásotok???”

Mit ne tegyünk?

Projektvezetőként, projekt szponzorként …

1. Semmiképpen ne dugjuk homokba a fejünket! Megfelelő erőforrások biztosítása előtt ne indítsuk el, vagy ne futtassuk tovább a jelentős projekteket! Vegyük észre, kezeljük, szükség esetén eszkaláljuk, ha a belsősök és a meglévő partner(ek) csapata(i) várhatóan kevés lesz a leszállításhoz.

2. További erőforrások bevonásához lehetőleg ne növeljük a bevont partnerek számát a projektben! Például egy konkrét rendszer továbbfejlesztéséhez a fejlesztőtől függetlenül bevont folyamat-tanácsadók, sőt rendszertervezők munkája az egymásra épülés helyett az eltérő módszerek, gyakorlatok miatt rendszerint végül egymásra mutogatáshoz vezet. Természetesen kivétel ez alól a minőségbiztosítási szerepben lévő tesztelői erőforrások.

Mit lehet tenni mégis?

Gondoskodni kell arról, hogy a projekt életciklus minden fázisában van vagy lesz hová nyúlni megfelelő felkészültségű szakemberekért. Arra, hogy a komplex projektek legtipikusabb szerepeiből mit melyik félnek kellene lefednie megfelelő minőségű erőforrással, használható az alábbi ajánlás. Ez arra a legelterjedtebb governance modellre vonatkozik, amikor a megrendelő a szükséges alkalmazásokat saját infrastruktúráján ő maga üzemelteti. A színessel kiemelt szerepek a szállítói oldalon gyakran elsikkadnak, ami a projektekben erőforrás- és/vagy kompetencia-hiányt okoz.

Mi lehet az erőforrás-bevonás formája?

Ha el akarjuk kerülni annak nehézségeit és kockázatát, hogy egyetlen fejlesztési feladathoz több beszállítónk legyen, akkor …

1. Rábízhatjuk a feladatot – célszerűen a konszolidált partnerek közül – egy alkalmas fővállalkozóra, aki képes a fenti kompetenciájú szakemberek maradéktalan bevonására, akár saját csapatából, akár alvállalkozói körből. Például ha Z rendszer szállítója erőforrás- vagy kompetencia-hiány miatt nem alkalmas egy nagy projektben a rendszeréhez felvetett új igények részletes elemzésére és a tervezésre, legfeljebb a fejlesztésre, akkor bízzuk másra a fővállalkozói feladatot, akár Z rendszer szállítójának fejlesztői alvállalkozása mellett. Ilyen esetben időt kell szánni arra, hogy ehhez megversenyeztessék a minősített szállítókat, hiszen ez biztosítja a végül kiválasztott elkötelezettségét, és probléma esetén azt, hogy van kire lecserélni.

2. Hiányzó kompetencia vagy erőforrás egyedi szakemberként is bevonható erőforrás-kölcsönző cégektől vagy szakértői közösségből. Fontos, hogy ezt ne a megrendelő, hanem a fővállalkozó tegye meg, felelősséget vállalva a teljes külsős csapatért.

3. Végül megbízhatunk cégek olyan csoportjában is, akik rendszeres és kipróbált partnerségben dolgoznak együtt, a kompetenciákat (pl. elemző/fejlesztő) egyeztetetten felosztották, módszereiket összehangolták. Ez lehet egy klaszterbe tömörült cégcsoport, vagy egyéb, létező és referenciával rendelkező együttműködés. A felelősség egyértelmű vállalása azonban ebben az esetben is fontos, amit fővállalkozói típusú szerződéssel lehet biztosítani.

Konklúzió

A folyamatos piaci változásoknak kitett és komplex informatikát, számos kapcsolódó alkalmazást használó ágazatok – kiemelten a pénzügyi ágazat – szereplőinek a nagyprojektjeik támogatására olyan beszállítókat célszerű kiválasztani, akik az adott projekt legtöbb szükséges szerepében képesek és hajlandók szakemberek bevonására. Így biztosítható a szűkös belső erőforrások kiegészítése bármely területen, egyúttal a szállítói felelősség egy kézben tartása.

Császár György

Projekt- és program menedzser

IPMA vizsgabiztos