ITÉlet

Mi is az outsourcing, azaz magyar szóval a kiszervezés? Egy számunkra kevésbé érdekes funkciót kiadunk egy külső partner kezébe, aki majd jobban és olcsóbban elvégzi azt. Legalábbis ezt ígérik az értékesítők a színes-szagos prezentációikban. De mi a valóság?

Mi is az outsourcing, azaz magyar szóval a kiszervezés? Egy számunkra kevésbé érdekes funkciót kiadunk egy külső partner kezébe, aki majd jobban és olcsóbban elvégzi azt. Legalábbis ezt ígérik az értékesítők a színes-szagos prezentációikban. De mi a valóság?

A szoftverfejlesztési területen az outsourcing már 12 éve jelen van. Mit is jelent ez az üzleti modell? Hogy a szoftverfejlesztés bizonyos lépéseit – tipikusan a kódolást, tesztelést és követelmény elemzést – valahol Indiában (vagy más LCC országban) végzik el. Egyes esetekben a teljes folyamat kikerül, tehát csak az üzleti igényt küldjük el, és kint elkészül az új funkciót/új szoftvert.

Esetleg a szoftver teljes üzemeltetése (hibajavítás, műszaki karbantartás, fejlesztési igények) külső kézbe kerül.

Milyen előnnyel jár ez az ügyfélnek? Az LCC országokban lévő erőforrások sokkal olcsóbbak (fele-harmada az onsite-nak), de ugyanakkor mégis képzettek ahhoz, hogy elvégezzék a munkát.

Az ügyfél a „mechanikus” munka helyett az értékteremtő lépésekre tud összpontosítani, vagyis arra, ami neki pénzt csinál. Egy autóipari multi például az ügyfeleire, az autógyártásra és az alkatrészekre tudja koncentrálni erejét, nincs szüksége drága pénzen fenntartani egy IT szervezetet.

Na és ez hogyan történik a valóságban?

Először is egy cikk a ComuterWorld-től: American Eagle Outfitters learns a painful service provider lesson

A cikk megemlít egy nagyon fontos dolgot: nem lehet mindent kiszervezni. A külső szolgáltató lehet bármilyen jó, de maga a kiszervezés óriási földrajzi, időzóna, kommunikációs és kulturális kihívásokat teremt. Ezek a problémák mind nem léteznének, ha a fejlesztő onsite ott ülne és nem szerveztük volna ki.
De mivel kiszerveztük ezért előre nem várt problémáink lesznek – amiket az ügyfélnek kell megoldani.
Az outsourcing partner – bármennyire is intelligensnek és proaktívnak hirdeti magát – nem ismeri ügyfele belső folyamatait és belső viszonyait, ezért előbb-utóbb rászorul arra, hogy csak a kiadott feladatot végezze el, se többet se kevesebbet. Többet nem is fog tudni, hiszen x időzónával és 1 kontinenssel arrébb ülve gőze se lesz a körülményekről.

Szóval az elvárhatjuk, hogy a külső IT cég azt csinálja, amit mondanak neki – lásd „droid” – de minden továbbit az ügyfélnek kell megoldania.

Ki lehet-e teljes egészében szervezni az IT support-ot? Nem, nem lehet, bármennyire is ezt bizonygatják az értékesítők és a tanácsadók.
Azért nem lehet, mert egy nagyvállalatnál nagy a függőség, a komplexitás és az egyének leterheltsége. A külső partner nem fogja látni a függőségeket, nem fogja átlátni a komplexitásokat, ezért folyamatosan a falnak szalad.

Az egyének, a „felhasználók” le vannak terhelve, ezért a kommunikáció nehézkes. Tipikus probléma, hogy a felhasználó küld egy hibajegyet, a fejlesztő visszakérdez, aztán a felhasználó nem válaszol. Ekkor mit tud csinálni egy Indiában ülő, angolul nehezen kommunikáló fejlesztő? Semmit. Nem fog telefonálni, nem tud odamenni a felhasználóhoz és megkérdezni, nem tudja ki a felhasználó munkatársa vagy főnöke akit el lehetne érni ilyen esetben.
Arról most nem is beszélek, hogy a felhasználó és a fejlesztő eltérő kultúrából jön, tehát még a sima egyszerű kommunikáció is nehézségbe ütközhet…

Tehát mindenképpen szükség lesz egy „belső” emberre, aki részt vesz a folyamatban. Ha pedig van egy belső ember, akkor az IT szolgáltató úgy fogja érezni, minél többet használja a belső embert, annál kevesebb kommunikációs probléma lesz – vagyis egyre több és több feladatot fog visszatolni az ügyfélre. Ami ugye ellentmondás az alaptételnek, hogy ez egy kiszervezés.

Most pedig csapjunk bele egyenes a lecsóba és tegyük fel a nagy kérdést: miért éri meg egy outsourcing partnernek, hogy a – saját elmondása szerint – világszínvonalú szakembergárdáját egy marék mogyoróért a rendelkezésünkre bocsássa?

Mert miből is él az outsourcing partner? Abból, hogy nagyon olcsón felvesz embereket, akiket aztán a lehető legdrágábban elad nekünk. Nyilván nem jószolgálati küldetést végez, hanem igazodva a kapitalista piacgazdasághoz, olcsón vesz és drágán ad.
Ezzel egyébként nincs semmi gond, mert hiszen így nem nekünk kell bajlódni az indiai jogi környezettel, nincsenek HR kérdések, nincs szakszervezet. A partner meg nyilván nem enged akárkit a munka közelébe, hanem megszűri az informatikusokat, fenntart egy bizonyos nívót, sőt továbbképzi az embereket.

De mivel ez kapitalizmus, semmi nem garantálja, hogy a kezdetben kiváló szolgáltatás utána hova alakul. Egy barátom mondta ki egyszer a kapitalizmus lényegét: amikor a még elviselhető legrosszabb szolgáltatást kapod.

Kezdetben ugyebár mindig minden szép. Kapunk egy csapatnyi Microsoft okleveles, 10 év tapasztalattal rendelkező fejlesztőt, akik a lelküket is kiteszik a projektért. Aztán amikor beindul a szekér és jól alakulnak a dolgok, akkor megjelennek az 5 és a 3 év tapasztalattal rendelkező fejlesztők. Ezzel ugye a piacgazdaság logikája szerint nincs semmi baj: az IT partner profitot akar csinálni, nekünk pedig jó lesz a kevésbé tapasztalt fejlesztő is. Az igazat megvallva egy 3 év tapasztalattal rendelkező fejlesztő is tud jó kódot írni.

De aztán jönnek a pályakezdők, akiknek ez lesz életük első (vagy második) projektje, és itt tanulnak meg programozni.
A veterán fejlesztők pedig továbbmennek a következő ügyfélhez, hogy ott meglegyen a buy-in és az elégedettség.

De ha maradnak is a veterán fejlesztők, sose felejtsük el, hogy nem mi vagyunk a főnökeik, hanem az IT cég. Ha ők azt mondják, hogy a projektnek el kell vinnie egy pályakezdőt, akkor el kell, hiába nem értenek vele egyet. És persze senki sem fogja elmondani az ügyfélnek, mennyire pályakezdők azok a fejlesztők.

Igaz, hogy könnyen ki tudunk rúgni valakit a projektből, de az IT partner számára ez veszteség. A kirúgott ember továbbra is az ő alkalmazottja, valamit kell vele kezdeni, valahol valakinek el kell adni. Még akkor is, ha az illető finoman szólva is nem motivált a munkavégzésben.
Szóval az IT partner mindent meg fog tenni, hogy a nem teljesítő ember is maradjon – ha másképp nem, akkor a veterán fejlesztőnek kell 2 helyett dolgoznia.

Hogyan lehet ezeket a típushibákat kiküszöbölni?

Először is saját magunkkal tisztázni kell, hogy mit szervezünk ki, és mik az elvárásaink. Onshore, nearshore vagy offshore? Ne csodákat várjunk, hanem tisztes iparosmunkát. Ha valaki csodákat akarna eladni, azt a céget felejtsük el.

A kiszervezés bizonyos körülmények között, bizonyos feladatokban nagyon sikeres tud lenni, ez tény. Ezért szerintem a leghatékonyabb a vegyes csapat, tehát amikor a csapat belsősöket és külsősöket is tartalmaz vegyesen, akik a feladatokat egymás között ésszerűen tudják felosztani.

A harmadik dolog a monitoring és KPI: tiszta, világos és mérhető célokat kitűzni, amiket aztán mérni is kell. Csak az lesz kész, amit mérünk, és ahol a nem-teljesítésnek következménye van.

A negyedik dolog a motiváció. Lehet, hogy az értékesítő szerint a részünkre közvetített fejlesztők egy szamuráj elszántságával fognak dolgozni, és az IT cég nagyon megmotiválja őket. De attól még nekünk is erősíteni kell a kapcsolatot és motiválni ezeket az embereket. A motivációval viszont óvatosan: a más kultúrkörből származó fejlesztőknek más motiváció vannak, és más dolgok hatására fognak lelkesen dolgozni.

Az ötödik dolog az, hogy a csapatunkba kerülő, projektünkre kerülő új embereket szűrjük meg. Ne bízzunk az IT partner szűrésében, hanem iktassunk egy „belső interjút” – ahol lehetőség van az oda nem illő emberek kiszórására.

A hatodik dolog annyira triviális, hogy majdnem elfelejtettem. Minden outsourcing partner rendelkezik saját folyamatokkal és módszertannal, ami ugyebár a világ legeslegjobbika, és nekünk csak jó lesz, ha azt követik. Na ezt ne hagyjuk! Az ügyfél módszertana szerint kell fejleszteni, és minden más folyamat vagy módszertan felesleges.
Már a megállapodás megkötésekor egyezzünk meg, hogy a nekünk dolgozó informatikusok a mi folyamataink szerint dolgoznak és jelentenek, és csak minimálisan legyenek kötelezve a saját folyamataikra és reporting-ra.

Hetedik – a bizalom. Bizalom nélkül nem fog működni. Annak ellenére, hogy nagyon oda kell figyelni, de teret kell adni kell az embereinknek – különösen a tapasztaltaknak -, hogy kibontakozhassanak.