ITÉlet

Ki a Vendor Manager, mit csinál, és hogyan csinálja azt jól?

A 90-es évek vége óta dúló kiszervezési hajrá miatt amikor IT feladatokról, IT tevékenységről és informatikai projektekről beszélünk, akkor az a gyakorlatban azt jelenti, hogy valahol egy külsős mérnök, azaz egy beszállítónál dolgozó mérnök fogja a feladatot végrehajtani. (Rosszabb esetben a beszállító beszállítójánál egy szerződéses alvállalkozó)

Tehát arról van szó, hogy amikor user-informatikus kapcsolatról beszélünk, az egyúttal ügyfél-beszállító viszony is. Ami azt jelenti, hogy az IT megítélése akkor lesz megfelelő a vállalaton belül, ha a beszállító jól végzi a munkáját. Ehhez pedig elengedhetetlen, hogy jól legyen menedzselve.

Erről részletesebben írtam A multi és a kkv viszonyáról című cikkben. Ott az volt a vége, hogy „A sikeres munkához jó ügyfél és jó beszállító szükségeltetlik, ahol mindkét fél tisztában van jogaival és kötelezettségeivel”

Röviden: nem elég az informatikai feladatokat kiszervezni és nem elég ha hónap végén kifizetjük a beszállító számláit, hanem a beszállítót menedzselni is kell.

Mit kell és miért menedzselni? Miért ne lehetne egy nagyon okos beszállító „önjáró”?

1)    A belső folyamatokat csak részben, de leginkább egyáltalán nem ismeri – ezért folyamatosan hibázni fog

2)    Nincs tisztában a belső politikai helyzettel – ezért elefánt lesz a porcelánboltban

3)    Ha baj van, nem tudja kihez fordulhat

4)    Nem tud a pénzügy, a beszerzés és a jogi osztálynál erősen fellépni

Akárhogy is nézzük, a világ legjobb programozóiból álló kisvállalkozás sem fogja tudni önállóan, egyedül teljesíteni a megbízást. Illetve tudja, de sok lesz a zökkenő.

Ezeket az igényeket felismerve nagyvállalatok létrehozták a Vendor Manager pozíciót, ami (aki) nevéből adódóan a beszállítókat menedzseli.

Röviden talán úgy lehetne megfogalmazni a VM célját, hogy a teljesítés terv szerint, zökkenőmentesen haladjon. Vagy úgy is meg lehet, hogy az ügyfél jogai és érdekei ne sérüljenek. A kettő valahol ugyanaz, hiszen az ügyfél érdeke a zökkenőmentes teljesítés, e nélkül pedig mindegy, hogy mik a jogai.

Más megfogalmazás szerint a VM a megrendelő és a beszállító közötti kommunikációért, a két fél közötti kapcsolatért felelős.

A jó beszállító teljesítményt, a sikeres teljesítést nagyjából két irányból fenyegeti veszély:

1)    A beszállító nem úgy, nem akkora vagy nem olyan minőségben teljesít, ahogy az kell

2)    A beszállító tudna teljesíteni, de az ügyfél nem teszi hozzá a közös munkához a maga részét, és ezért mégse sikerül a projekt (pl. nem határozza meg pontosan az igényeket, vagy nem biztosít eszközöket a munkavégzéshez)

A VM szerepe tehát e két veszély elhárítása:

1)    A beszállító munkájának támogatása és ellenőrzése

2)    A beszállító érdekeit képviselni házon belül, azaz lehetővé tenné ügyfél oldalról, hogy a beszállító teljesíthessen

Mik azok a főbb területek, ahol segítségre van szükség?

Szerződés

Az ügyfél-beszállító kapcsolat sarkalatos pontja a szerződés, és ez elsősorban a VM feladata. Szerződésekről már sokat írtam (lásd Informatikai Szerződések sorozat). A lényeg az, hogy egy rossz szerződéssel egy amúgy jó munkakapcsolatot is tönkre lehet tenni.

Az is biztos, hogy a Jogi Osztály, a Beszerzés és a Pénzügy magától nem fog olyan szerződést írni, ami megfelelő keretet ad a munkához. Szakmai vezetőnek kell lenni ahhoz, hogy valaki feltölthesse a szerződés jogi kereteit valódi szakmai célokkal.

KPI meghatározása

Habár a szerződés része, de külön kiemelem, hogy egy jó együttműködés során meg kell találni és definiálni a teljesítés mérőszámait. Ez a legnehezebb, hiszen szakmai tudást igényel, egyúttal nagyon jól kell ismerni az ügyfél oldalt, átlátni az elvárásokat, és átlátni azt, hogyan fog az ügyfél és a beszállító közösen együtt dolgozni.

Ha nincs mérőszám meghatározva, akkor a teljesítés könnyen félrecsúszhat, és a beszállító nem az elvárások szerint teljesít.

Ha rossz mérőszám van meghatározva, akkor esetleg előfordul, hogy a beszállító a rossz cél mentén teljesít. (Klasszikus alapvicc, amit mindenki ismer: ha olyan szerződést kötsz, hogy a beszállítódnak a kijavított hibák után fizetsz, akkor egy idő után sok lesz a hiba a kódban.)

Pénzügyek

Talán nem tűnik fontos dolognak, de talán az egyik legfontosabb, hogy a beszállítók kapcsán a pénzügyek rendben legyenek.

Alapvető dolog, hogy a számlák ki legyenek fizetve. A beszállító csak annyit lát, hogy elküldte a számláját határidőre, a megadott módon, aztán vagy ki lesz fizetve, vagy nem. Simán előfordulhat, hogy a számla elkallódik, megakad valahol a jóváhagyási folyamatban, vagy esetleg valamilyen adatot rosszul írt rá és ezért egész egyszerűen elveszik. Márpedig ha a beszállító nincs kifizetve, az igen erősen lerontja a motivációját – és utána képtelenség lesz belőle normális teljesítést kicsikarni.

Ezeket a problémákat egy, a pénzügyi folyamatokat jól ismerő VM percek alatt megoldja.

A másik fontos dolog, hogy a vállalat költséghelyekkel, büdzsékkel és éves tervvel operál. Ebbe kell beleilleszteni a beszállítót, azaz biztosítani a büdzsét a munkájához, látni azt hogy mire van még pénz és mire nincs. Amire van azt megrendelni, amire nincs azt nem rendelni meg.

Ha a költségek változhatnak (például T&M elszámolás) akkor előre tervezni azt, meddig nyújtózkodhat a vállalat.

Döntéshozatal

A pénzügyek kapcsán szó volt róla, hogy fontos az: legyen valaki, aki döntésekez hozhat. A beszállító számára létfontosságú, hogy egy új fejlesztésre valaki rábólintson, hogy az mehet vagy nem mehet. A másik oldalon viszont a vállalaton belül egy-egy ilyen döntést meghozni nagyon összetett és időigényes, ezt valakinek kézbe kell vennie és végigvinnie. Ráadásul úgy, hogy a komplexitás és a bürokrácia ellenére a döntés gyorsan legyen meg.

És ez eszméletlenül fontos. Egy-egy üzleti döntést – tehát amikor arra várunk, hogy x és y igazgató rábólintson a projektre – gyakran tovább tart meghozni, mint magának a munkának a végrehajtása. Rossz VM-eknél simán előfordul, hogy mondjuk egy nagyobb fejlesztéshez 10 hónapig tart minden jóváhagyást összegyűjteni, aztán 4 hónap alatt gyorsan meg kell csinálni a 6 hónapos melót.

A másik fontos terület a műszaki, architektúrális kérdések eldöntése. Nem mindegy, hogy az új szoftvert JAVA-ban vagy C#-ban fejlesztik-e ki. A beszállító nyílván azt fogja preferálni amelyikhez emberei vannak, viszont a jó döntés abból fakad, milyen IT környezetben kell majd a szoftvert használni, és mik az elvárások vele szemben.

Ügyfélkapcsolat

A Magyarországon szokásos feudális alá-fölérendeltségi viszonyokkal szemben igenis fontos, hogy az ügyfél és beszállítója között jó legyen a viszony. Igaz, hogy ez elsősorban a beszállító munkája (lásd Az ügyfélnek mindig igaza van), de visszafelé is igaz. És ennek meglehetősen pragmatikus okai vannak!

Ha idegbeteg pszihoptát játszok a beszállítóm előtt azzal a céllal, hogy így majd többet tudok kisajtolni belőlük, az azt jelenti, hogy az ő szemükben én kockázati tényező leszek. És amikor ajánlatot adnak, akkor a kockázatot beárazzák. Azaz beárazzák azt, hogy ha megállapodunk x-ben, de én x+y munkát csináltatok meg velük, akkor az ajánlatot eleve x+y költségre fogják belőni. És még hozzácsapnak tartalékot, mert ki tudja mi történik.

Ezzel szemben ha a két fél között megvan a bizalom, ha tudják hogy baj esetén számíthatnak a VM-re, ha tudják mik a közös játékszabályok és hogy az ügyfél ezeket betartja, akkor ez a kockázati felár és az ajánlatba rakott tartalék kicsi lesz.

Arról nem is beszélve, ha váratlan helyzet adódik, akkor a második esetben a beszállító rugalmasabb lesz – és itt ne feledjük el, hogy a házon belül a VM képviseli a beszállítót, és ha a beszállító nem rugalmas, akkor annak a VM fogja meginni a levét…

Stratégia, hosszú távú tervek

Amire a beszállítónak biztosan nincs rálátása – mert üzleti titok – az a hosszú távú terv. A beszállító egyébként is a munkáját és szakértelmét adja „bérbe”: ha azt mondják neki hogy most ezt csináld meg, akkor megcsinálja legjobb tudása szerint. Viszont hosszabb távon nem tervez, és nem is tud tervezni, hiszen a belső üzleti stratégiára nem lát rá.

Ezért szükséges, hogy valaki a vállalaton belül – a Vendor Manager – végzi a stratégiai tervezést.

Sajnos típushiba, hogy VM nélkül az ügyfél abban a hitben él, hogy a beszállítónak van informatikai stratégiája. Csakhogy az ügyfél napi fejlesztési igényeket támaszt, egyik CR a másik után, a végén pedig a szoftver kinövi az eredeti kereteit és nem lesz fenntartható. Ami az üzemelteti költségek emelkedésében fog visszaütni az ügyfélre.

Koordináció több beszállító között

AZ IT Osztály nem egy beszállítót jelent, hanem többet. Sokat. A beszállító viszont csak a saját munkájára, a saját területére lát rá, a többiekre nem.

Ez miatt nem fogja tudni kihasználni a szinergiákat, és nem fog tudni segíteni a többieknek.

Ezen feladatok ellátása szakmai tudást, szakmai vezetést igényel az ügyfél oldaláról.

Ügyfél oldali feladatok koordinálása

Bármilyen projektet is nézünk, abban biztosan lesznek ügyfél oldali feladatok. Például meghatározni pontosan, hogy a megrendelésben szereplő fícsör alatt mit értünk. Vagy átadni az új rendelési folyamat leírását. Vagy ellenőrizni az átvett szoftvert.

Ezeket a beszállító nem tudja megcsinálni egyedül, és nem fogja tudni koordinálni a végrehajtásukat. Ezért kell segítség a belső embertől.

Együttműködési keretek meghatározása

Ahhoz hogy a fentiek jól és zökkenőmentesen haladjanak, szükség van a korábban említett „játékszabályok” lefektetésére. Azaz meg kell határozni, hogyan dolgozik össze az ügyfél és a beszállító. Nagyjából a következőkre van szükség:

-       Keretszerződés

-       Fejlesztési folyamat

-       Change Request folyamat

-       Rendelési folyamat

-       User Acceptance folyamat

-       Átadás, teljesítés és fizetés

-       Kommunikációs terv

Standardok meghatározása és ellenőrzése

A minőség relatív dolog. A félreértések elkerülése végett előre tisztázni kell, hogy az ügyfél szerint mi az elvárt minőség, mit és hogyan kell leszállítani ahhoz, hogy az „jó” legyen. Azért az ügyfélnek kell ezt meghatározni, mert a beszállító által készített szoftver vagy az általa nyújtott szolgáltatás a teljes IT portfolió részét fogja képezni, és ahhoz illeszkednie kell.

Naivitás lenne elvárni azt, hogy majd a beszállító mindent magától kitalál és majd az úgy jó lesz.

Viszont ha a beszállító tudja, mi az elvárás, akkor úgy fog szállítani.

A leszállítás során természetesen ezeket a standardokat ellenőrizni kell. Nem azért, mert a beszállító esetleg szándékosan rosszul szállítani, hanem azért, mert véletlenül lehet hogy valami nem sikerül megfelelően. És ezeket nyílván ők is ki akarnák javítani.

Az pedig közismert tény, hogy ha a minőséget ellenőrzik, akkor ott lesz minőség J

Alulteljesítő beszállító kezelése

Ritkán, de előfordul, hogy a beszállító nem teljesít megfelelően. Ezt ilyenkor minél gyorsabban kezelni kell, mert magától a dolgok ritkán javulnak meg.

Normális esetben az ügyfél-beszállító kapcsolata win-win, ahol mindkét fél beletesz valamit és ahol mindkét fél megkapja amit akar (elvégzett munkát, illetve fizetséget).

Viszont adódnak kivételes helyzetek. Például ha a beszállító már nem tekinti fontosnak az együttműködést, de az aláírt szerződés még köti. Vagy például ha a beszállító oldalán a vezető továbblép egy másik állásba, és a helyére a tulaj okoskodó unokaöccse kerül.

Ilyenkor pont ugyanazt kell tenni, mint egy alulteljesítő beosztottnál: kimutatni a minőség/teljesítmény romlását, szembesíteni a tényekkel (ezt vártuk, ezt kaptuk).

Viszont egy beszállítót nehezebb kirúgni, mint egy beosztottat. Például ha a beszállító kezében van a rendelési rendszer, annak leállásával gyakorlatilag megszűnik az értékesítés. Ezeket a helyzetek megfelelő odafigyeléssel, de ami még fontosabb, megelőzéssel kell kezelni. Például figyelni arra, hogy egyetlen beszállító se legyen nélkülözhetetlen. Vagy ha kritikus rendszert üzemeltet, akkor mi van a kezében és mi nincs, mennyi idő alatt és hogyan cserélhető le.

Elakadás kezelése

A legjobb fejlesztőkkel is előfordul, hogy egy problémát nem tudnak megoldani. Nem azért, mert ne értenének a szakmájukhoz, hanem tipikusan azért, mert az adott feladathoz külső (számukra külső) eszközt vagy információt kell használni, eselteg a hiba oka nem egyértelmű. Ilyenkora  VM-nek kell feloldania az elakadást (lásd Koordináció több beszállító között).

Összességében jól látható, hogy a Vendor Manager munkaköre sokrétű. Műszaki, jogi, pénzügyi, értékesítési, csapatvezetési és ügyfélkezelési feladatokat lát el. Ahhoz, hogy munkáját jól végezze, ehhez mindhez értenie kell. Ráadásul úgy, hogy az érdemi munkavégzést nem ő végzi, a babérokat nem ő aratja le.