HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

„Á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.

Címkék: multi árnyékprojekt

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr225211572

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

bpelhos 2011.08.23. 14:37:47

Ámen, jól összeszedett írás lett. Bennem sokszor csak az a kérdés, hogy hol kezdődik az informatika az árnyékban. Mármint ha egy marketinges Excel makrót gyárt, akkor az már shadow IT? Ha egy távközlési mérnük Access form-okat rak össze? Ha mindezt átrakja egy MS SQL szerverre? Ha ennek továbbfejlesztéséhez igénybe vesz egy kkv-t? Magammal beszélgetve próbáltam meg is válaszolni ezt a kérdést: Amíg ez a barkács fejlesztés nem a napi munkavégzéshez kell (és elengedhetetlenül szükséges), addig nem shadow IT. (Jó esetben ez a barkács egy prototípusa lesz egy tisztességes IT fejlesztésnek.) Vagy van más megközelítés is?

Ismeretlen_102125 2011.08.23. 16:22:47

Szerintem az MS SQL szerver már informatikai szolgáltatás, és mint ilyen a standard IT keretein belül kell történnie. Az Access határeset. Sok Access alapú üzleti alkalmazás van, ami része az üzleti folyamatnak, üzleti döntéseket hoznak a benne tárolt adatok alapján, tehát igen erős biztonsági és minőségi szintre lenne szükség. Ehelyett ezek az Access adatbázisok mindenféle publikus helyeken, közös meghajtókon és pen drive-okon forognak. Egy totálisan idealista, utópisztikus és rózsaszín jövőben nincs Access és nincs Excel macro, helyettük kész célszoftverek vannak az IT osztály közreműködésével.

Dave 2011.08.24. 10:33:59

Én elég sok ilyen Access/Excel "quick and dirty" megoldást készítettem és azt látom, ezek nagyon hasznosak tudnak lenni bizonyos keretek között. Az ilyen jellegű üzleti árnyékprojektek hasznát én abban látom, hogy segít az üzletnek az igényeit összeszedni, átgondolni és prototípusként funkcionálni a későbbi megoldáshoz. Ez a modell persze csak akkor működik, ha a "prototípus" nagyon alacsony költséggel és elég rövid időre készül. De ha az IT mindig leterhelt marad, akkor jön el a csúnya világ...

Viktor 2011.08.26. 15:53:46

"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." Szerintem ezt máshogy is meg lehet közelíteni. A költségkeret egy szűrő, ami rákényszeríti az üzleti oldalra, hogy adjon prioritást, rendeljen fontosságot a projektekhez, mert az IT prioritási sorrendben fog haladni. Így a kevésbé fontos projektekre nem kell pénzt kiadni, mert nem fog velük senki sem foglalkozni. Ami fontos, az utat tör magának, úgy is. Ha az üzleti oldal úgy érzi, hogy túl sok projektje "elvérzik" pénzhiány miatt, akkor egyszerűen növelnie kell az IT méretét vagy ha ez csak ideiglenes állapot, akkor persze igénybe lehet venni külső segítséget.
süti beállítások módosítása