„Árnyék IT” vagy „shadow IT” alatt azokat a személyeket és csapatokat értem, akik nagyvállalatnál IT feladatokat látnak el, de a hivatalos IT osztályon kívül, azaz üzleti szervezet részeként.
„Árnyék IT” vagy „shadow IT” alatt azokat a személyeket és csapatokat értem, akik nagyvállalatnál IT feladatokat látnak el, de a hivatalos IT osztályon kívül, azaz üzleti szervezet részeként.
A témát már többször érintettem, például Az árnyékprojektek vagy Informatikai projekt az IT osztály nélkül? vagy legutóbb Olvasói levél: Architect a külső kkv-től
Kezdjük az alapokkal, azaz hogyan épül fel egy nagyvállalat informatikai támogatása?
A 21. századra informatikára szükség van, tehát a vállalatnak – ha működni akar – szüksége van informatikusokra. Az informatikusok fölé menedzserek kellenek, ők pedig valamilyen módon a felsővezetők felé jelentenek (CFO, CIO vagy CTO felé).
Nagyjából két modell létezik az IT osztály elhelyezésére a szervezetben: elosztott vagy központosított.
Az elosztott modell szerint a globális nagyvállalat főbb telephelyei saját IT osztállyal rendelkeznek, vagyis az erőforrások és a hatalom a helyi IT kezében van. Minden telephely saját fejlesztéseket futtat, saját szerveri vannak, és saját informatikai vezetője van. A helyi CIO-k a helyi vezetőknek jelentenek. A sok CIO laza kapcsolatban áll a többiekkel, kvázi függetlenek. Létezhet globális CIO, aki nem igazán szól bele a helyi CIO-k munkájába.
E modell előnye az, hogy az informatikus közvetlenül az üzlettel dolgoznak együtt helyi szinten, emiatt rugalmasak és gyorsak, jól ismerik az üzleti igényeket és jó a kommunikáció.
A központosított modell szerint a globális nagyvállalat globális, összevont IT osztállyal rendelkezik. Helyi IT nincs, vagy csak minimális. Mindent központilag, központi erőforrásból oldanak meg. A globális CIO kezében van minden.
A modell előnye, hogy olcsó és költséghatékony, illetve jobban ellenőrizhető. Talán nem kell bizonygatnom, hogy egy nagy IT osztály sokkal gazdaságosabb, mint sok kicsi. A hátránya pedig az, hogy az informatikusok nagyon távol vannak a felhasználóktól és üzleti szereplőktől, a fejlesztések lassan történik, a kommunikáció gyenge.
Az IT osztály finanszírozását tekintve is két fő modell létezik: a belső beszállító, illetve a cost center.
A belső beszállító modellben az IT osztály a pénzt az üzleti funkcióktól kapja, cserébe a nekik nyújtott informatikai szolgáltatásokért. Vagyis nem több, mint egy beszállító. Ez a modell biztosítja, hogy az üzlet pontosan azért fizet, amire szüksége van és amit kap. Illetve ez biztosítja, hogy az IT azzal foglalkozzon, ami az üzlet számára fontos.
A modellnek két fő hátránya van. Az egyik az, hogy az üzlet esetleg hajlamos lesz ár alapján dönteni és megversenyeztetni a belső IT-t egy külső beszállítóval (a minőséget felejtsük el). A másik hiba, hogy amint az IT partnerből beszállítóvá degradálódik, onnantól kezdve az üzlet IT támogatás nélkül fog maradni.
A cost center modell szerint az IT kap egy fix pénzkeretet éves szinten, amiből meg kell oldania a vállalat informatikai támogatását. Ez lehetővé teszi, hogy partnerként, a projektek aktív szereplőjeként lépjen fel, sőt saját maga is kezdeményezzen. A hátránya az, hogy a keret fix és korlátos, tehát csak annyi fejlesztést tud megtenni amennyire erőforrás van, nem többet – ezáltal sok értékes projekt vérzik el pénzhiány miatt.
Ezen kívül létezik a két modell ötvözete, amikor az IT kap egy fix pénzkeretet, de ezen felül lehetősége van beszállítóként is megjelenni belső projektekben. Ezt nem tudom, hogy mennyire elterjedt.
A mai trendek alapján úgy tűnik, hogy a cost center alapú elszámolás a divat. Az utóbbi évek gazdasági nehézségei pedig rákényszerítették a vállalatokat, hogy központosítsanak. Nem csak IT területen, de az IT az, ahol ezt nagyon hatásosan meg lehet tenni és költséget csökkenteni. Elmondható tehát, hogy napjaink IT osztálya központosított, és fix erőforrásokkal gazdálkodik.
Azonban a központosított, korlátos erőforrásokkal rendelkező IT osztálynak a nyilvánvaló előnyei mellett vannak hátrányai is. Például hogy lassan követi az üzleti igényeket, projekteket töröl, és üzleti igényeket utasít vissza. És ilyenkor az üzleti vezető más megoldást keres – az IT osztály kihagyásával.
Milyen okok vezethetnek egy üzleti vezetőt arra, hogy a saját IT-ját kihagyva külső beszállítónál keressen megoldást?
- A belső IT erőforrások túlterheltsége
- Belső IT tudás hiánya, pl. nincs megfelelő szakember
- Specializálódott beszállítók, pl. marketing agency
- Korrupció
- Rossz kapcsolat az IT-val
Igazából itt az a helyzet, hogy a pénz rossz helyen van. Az üzletnek lenne pénze a beruházásra, de nem teheti meg, mert ő nem IT. A másik oldalon az IT-nál megvan a szakértelem, de nincs pénz. Ezért van szükség pótmegoldásra: az IT háta mögötti fejlesztésre.
Mondok példát Tegyük fel, hogy ki kell fejleszteni egy új szoftvert, ami üzleti oldalon évi 70 millió forint megtakarítást vagy extra üzletet jelent. A szoftver kifejlesztése 120 millió forint beruházást igényel. Nem kell közgazdásznak lenni ahhoz, hogy lássuk: ez a cégnek megéri.
Azonban nem biztos, hogy az IT-nak van erőforrása. Lehet, hogy ennél jobb megtérülésű projektek sorakoznak, és a CIO azt mondja, hogy a következő 2 évben nem lesz lehetőség a fejlesztésre.
Az üzletnek ettől függetlenül most kellene a megoldás, mert nekik minél hamarabb költséget kellene csökkenteni. 120 millió forint nagy pénz, biztosan találnak egy tucat kkv-t, amelyik szíves örömmel, azonnal kifejlesztené a szoftvert.
(Esetleg még az is megoldható, hogy a pénz 10%-a visszacsorog a kkv-n keresztül az üzleti vezető zsebébe és mindenki jól jár. De ha ez nem lenne, akkor is látható, hogy az árnyék projektnek létjogosultsága van.)
Excel táblában ez nagyon szépen néz ki, és az üzleti vezető azt gondolja, hogy elég aláírni a szerződés és ezzel minden probléma megoldva. Pedig nem, és ahogy a projekt elindul, kiderül, hogy az üzletnek is dolgoznia kell a projekten – ha mást nem hát menedzselnie kell a kkv-t. Az is ki fog derülni, hogy ez a részvétel, ez a „járulékos munka” igen sok. Annyira sok, hogy a munkatárs ideje 100%-át elviszi, sőt nem csak 1 emberét, hanem többét. Szép lassan kialakul, hogy bizonyos emberek fő munkája az IT projekt és az IT beszállító lesz – azaz IT munkát végeznek, de üzleti oldalon.
Ahogy az idő telik, kiderül, hogy ilyen emberből – mármint üzleti oldalon ülő, de informatikai munkát végző – egyre több kell. Rengeteg üzemeltetési probléma lesz (ez normális egy ilyen méretű indulásnál), ezen problémák nagy része kommunikációs vagy műszaki jellegű lesz, tehát köze sem lesz az üzlethez. A nagyobbik baj az lesz, hogy az üzemeltetés jellegű feladatok nem tűnnek el, hanem folyamatosan jelen lesznek. Vagyis szükség lesz állandó headcount-ra az üzleti oldalon, akik kizárólag IT üzemeltetéssel foglalkoznak.
A másik oldalon viszont kiderül, hogy az üzlet maga folyamatosan változik, és a szoftveren is folyamatosan változtatni kell. Az üzemeltetési feladatok mellett tehát a fejlesztés is folyamatos lesz (Change Request-ek áradata). Ehhez úgyszintén főállású informatikusokra lesz szükség, akik az üzleti szervezeten belül dolgoznak.
Eljutunk oda, hogy a szoftver méretétől függő méretű informatikus csapat fog állandó jelleggel dolgozni. Messziről nézve úgy tűnik, minden sikeres: olyan, mintha informatikusok informatikai munkát végeznének, mintha fontos lenne a minőség, mintha a szakmai szempontok számítanának, ráadásul valós üzleti igényt elégítenek ki.
Mi jellemzi ezt a csapatot?
- Az informatikusok az üzleti menedzsereknek alárendelten dolgoznak
- Nem lesznek informatikai vezetők (vagy ha lesznek is, nem az IT tudásuk alapján lettek kiválasztva)
- Emiatt teljes lesz a fejetlenség, a hozzá nem értés, az inkompetens döntések, a spanyolviasz újrafeltalálása nap mint nap
- Mivel a projekt az IT szervezeten kívül zajlik, az IT szervezet (és a CIO) ellenségnek tekinti őket, semmiféle segítséget nem adnak
- Kontraszelekció: az üzleti vezetők olyan informatikusokat szeretnek, akik az üzlet nyelvét beszélik, ergo az IT tapasztalat háttérbe szorul
- Megtűrt rossz: az üzlet nem akar IT üzemeltetéssel foglalkozni, de már nincs visszaút
- Az IT minőségi sztenderdek ismeretének hiánya, illetve úgy egyáltalán a minőség koncepciójának hiánya (ugye a minőség nehezen szerepeltethető az Excel táblában)
Az árnyék-IT csapat a nehézségek ellenére mindent meg fog tenni, hogy jól végezze munkáját, és a produkció jól vagy rosszul, de menjen. Sajnos a közeg egyszerűen a minőségi szakmai munka ellen van.
A dolgok azokban egyre rosszabbul fognak menni. Ennek egyik oka a már emlegetett minőség, illetve annak hiánya.
A másik ok a pénzhiány. Az Excel táblából kifelejtették az elején, hogy a szoftver üzemeltetése, illetve a folyamatos változtatások állandó kiadást jelentenek az üzlet részére. Azt hitték, hogy majd kiadnak 120 millát, esetleg még némi pénzt, de majd egyszer a munka elkészül és nem kell tovább költeni rá. Meg egyébként is költséget kell csökkenteni, és a szoftverrel kapcsolatos kiadások az üzlet természetével ellentétesek. Szóval elfogy a pénz, és anyagilag összeomlik az egész.
A harmadik ok a beszállító. A beszállító abból él, hogy pénzért szoftver fejleszt vagy üzemeltet. 120 millió elköltésében nagyon szívesen segít, piros szalaggal átkötve nyújtja át a telepítő cd-t, és mindent megtesz az ügyfélért. De amint megkapja a 120 milliót, a lelkesedése is csökkenni fog. A szürke hétköznapok küzdelmei kevésbé vonzóak. Egy ideig nyilván segít a beszállító, de a gazdasági racionalitás azt diktálja, hogy valamiből meg kell élnie – az erőforrásokat át kell csoportosítania a következő ügyfélhez, ahol a következő 120 milliós fejlesztést kell végrehajtani.
Összefoglalom: a beszállító egyre kevésbé segítőkész, a pénz egyre kevesebb, de cserébe a szoftverrel egyre több a baj. A vége jól látható.
Az összeomlás után nagyjából a következők történhetnek:
- Belső IT átveszi a szoftvert
- Szoftver teljes újrafejlesztése vagy kész megoldás vásárlása
- Szoftver részleges, iteratív újrafejlesztése
Az biztos, hogy az árnyék IT csapat egyszer csak megszűnik.
Az életciklusuk nagyjából így írható le:
1) Üzleti igény megjelenése
2) Beruházás megindítása (kkv bevonása, belső IT kihagyása, saját IT csapat felépítése)
3) Elkészül a működő szoftver – mindenki lelkes
4) Sikeres évek, felfutás, ezzel együtt üzemeltetési és fejlesztési igények felfutása (we can do it)
5) Egyre több munka, egyre több probléma és egyre nagyobb lesz az árnyék IT
6) Az üzlet felismeri, hogy az állapot nem fenntartható, elkezdenek kihátrálni, új utakat keresni (Houston, we have a problem)
7) Válságértekezlet, stratégiai irányváltás
8) Átmeneti időszak, konszolidáció és átállás
9) Árnyék IT vége
Miért következik be minden esetben az árnyék-IT megszűnése, elvégre ha jól végzik a munkájukat, akkor nem lesz baj?
A helyzet az, hogy minőségben és költséghatékonyságban nem versenyezhetnek a belső IT-val.
Például a belső IT 200 alkalmazásért felelős, üzemeltet kb 1400 szervert és kiszolgál 5000 felhasználót. Ehhez képest a külső beszállító és az árnyék-IT 1 alkalmazást és 7 szervert üzemeltet.
A belső IT számára mindegy, hogy 200 vagy 201 alkalmazást tart karban, nincs szüksége túl sok extra erőforrásra. A szinergiák lehetővé teszik, hogy megfizesse a legjobb szakértőket és specialistákat, akikhez bármikor lehet fordulni. Az árnyék-IT csak magára van utalva.
A belső IT kiforrott folyamatokkal rendelkezik, követi az iparági szabványokat és legjobb gyakorlatokat. Az árnyék-IT és a kkv nem fogja követni a legjobb gyakorlatokat, és folyamataikat a nulláról kell felépíteni.
A hatékonytalanságot az elején elleplezi a nagymértékű befektetés, azonban hosszabb távon a pénz elfogyásával a problémák a felszínre kerülnek.
Ha ez igaz, akkor mindig mindent a belső IT-vel kell megcsinálni?
Mint említettem korábban, az IT osztály keretei magában hordozzák a tehetetlenséget. Lesznek helyzetek, amikor szükség lesz árnyék projektre – különben üzleti kár éri a céget, the show must go on. Vagyis kimondható, hogy a fentiek ellenére az árnyék projekteknek, a külső IT beszállítóknak van helye és létjogosultsága.
Azt kell megérteni, hogy az árnyék projektek sokba kerülnek a cégnek – mármint nem az elején, hanem a végén. Minél kevesebb az árnyék projekt és minél több a hivatalos projekt, annál hatékonyabb az informatika.
Miért ellenségesek a belső IT-sok az árnyék IT-sokkal?
Ennek több oka is van. Két érzelmi ok: mert a belső IT-sok konkurenciát látnak a külső IT-sokban, és mert feltehetőleg az árnyék-IT létrehozásához a belső IT-val való összeveszésen át vezetett az út.
A harmadik ok stratégiai: ha az Informatikai Osztály nekifogna segíteni az üzletnek az árnyék projekt végrehajtásában, akkor ezzel óhatatlanul is magukra vennék a felelősséget. De mit is kapnak cserébe? Semmit. Pénzt nem kapnak az üzlettől, viszont fel kell takarítaniuk azt a szemetet, amit az üzlet csinált. Normális CIO ilyenbe nem megy bele, és a lehető legnagyobb távolságot tartja a produkciótól.
Nálunk nincsenek árnyék projektek! – mondhatja valaki.
Nem igaz, árnyék projektek mindenhol vannak. Pontosan azért árnyék projekt (shadow project) a nevük a szakirodalomban, mert nem láthatóak. Elrejtőznek az árnyékban, az üzleti környezetben, a menedzserek nem verik nagydobra. Mintha nem is lennének – pedig vannak. A marketing például tipikusan az a terület, ahol ilyenek léteznek.
Soha ne feledjük: a legkeményebb ellenőrzés is kijátszható, ha a szereplők érdekeltek benne.
Hogyan lehet árnyék projekteket elkerülni?
Mivel a kemény ellenőrzés nem segít, inkább az együttműködésre kellene helyezni a hangsúlyt.
Ha már szükségszerű egy árnyékprojekt indítása, hogyan lehet jól csinálni?
Mindenképpen az IT osztály bevonásával és a belső informatikusok vezetésével. Azzal alapvetően nincs baj, ha egy kkv fejleszt a multinak, és üzleti keretből fizetünk érte. A baj akkor kezdődik, amikor az üzleti vezető elhiszi, hogy egyedül is meg tudja csinálni.
Szóval a legjobb út, amikor az üzleti vezetők ilyen irányú törekvését ha nem is megszüntetjük, de valamilyen módon segítjük és egyúttal igyekszünk azt irányítás alatt tartani. Az IT osztály szerepe ilyenkor koordináció és tanácsadás. Természetesen a felelősséget tisztázni kell még a legelején.
A legjobb megoldás egyébként az, ha az üzlet fizeti a számlát, de önkéntesen, bizalmi alapon átadja az irányítást az IT-nak.
Milyen szerepe lehet egy ilyen szituációban a kkv-nek?
Nos, a kkv sincs tökéletes helyzetben egy árnyék projektben. Ugye egyik oldalon ott az ügyfél egy valós üzleti igénnyel és sok pénzzel, de a másik oldalon ez az ügyfél nem ért az IT-hoz és rossz döntéseket hoz. A kkv nem tehet mást, mint követi az igényeket – még ha azok rossz irányba is mennek.
Bizonyára a kkv-ban megvan az igény a professzionális szoftverfejlesztésre és az IT legjobb gyakorlatok követésére, de az informatikus is pénzből él.
Ezeket a helyzeteket a kkv nem tudja megoldani, és felesleges összeveszni az ügyféllel.
Utolsó kommentek