ITÉlet

Még mielőtt a konkrét lépésekre térnénk, fontos beszélni a cégről magáról. A válságban a kisebb, de hatékonyabb cégek teljesítenek jól, tehát a kevesebb de tapasztaltabb kollégát alkalmazó végek előnnyel indulnak. A fizetések az átlagnál magasabbak. Kicsi csapatokban sok a munka, de nagyon hatékonyak vagyunk.
(Vannak helyek ahol ennek ellenkezőjére törekednek: nagy csapatok, hadseregnyi alulfizetett fejlesztő, pályakezdők.)

A válságnak ellenálló informatikai szervezet arra törekszik, hogy minél kevesebb (okosabb) munkával komolyabb eredményt érjen el. A cél nem a 100%, hanem egy gyors és olcsó 90%, aztán majd jöhet a maradék 10%.
Ezzel a módszerrel (illetve a kis csapatokkal) minimálisra csökkenthetjük a felesleges munkavégzést. Kevesebb az értelmetlen papírmunka és az adminisztráció.
(nem vagyok lead hívő, de egy lead szakértő sokat tudna segíteni)

Az a legjobb ha az informatikai szervezet központosított. Az erőforrások kompetencia központokba szerveződnek. Ez nagyon hatékony és olcsó lesz, de majd akadnak kommunikációs és minőségi problémák (növekszik a távolság az üzlet és az IT között).
(A másik véglet a helyi IT lenne, ahol mindenki közvetlenül rendeli meg projektjeit, sokkal jobb minőségben, de összességében sokkal drágábban)

Az informatikai beruházások költségvetését központosítottan a CIO kezébe tenném. Az üzleti funkciók nem ügyfelei hanem felhasználó lennének a szolgáltatásnak. Ez lehetővé teszi, hogy a projektek ne aprózódjanak el és ne essenek áldozatul a helyi politikának. Viszont óriási a kockázata hogy a helyi viszonyokat rosszul mérjék föl, és a megvalósult rendszer nem felel meg a helyi előírásoknak.
Összehasonlítva azokkal a multikkal, ahol az informatika a belső ügyfelek megrendeléséből él, ez sokkal gyorsabb és egyszerűbb.

Az informatikát úgy szervezném meg, hogy különválasztanám az üzemeltetést és a fejlesztést, illetve az egyéb funkciókat (pl. üzleti kapcsolat, PMO): a fejlesztés csökkentésével/növelésével dinamikusan tudunk reagálni az igényekre.

Mint látható egy ilyen szervezet eleve óriási előnnyel vágna neki a válságnak.

Most egy konkrét, fiktív akciótervet mutatok be, amit elméleti IT vezetőnk alkalmazhatna a túléléshez:

- 2008 év eleje: Már látható, hogy valami gond lesz, ezért enyhe korlátozások bevezetése, pl. az üzleti utazások visszafogása.
- 2008 év eleje: A távmunka informatikai feltételeinek megteremtése. Távmunka = költségcsökkentés. (Sajnos a vezetők nem fogékonyak rá)
- 2008 tavasz: Ekkor már egyértelműen látható volt a kereskedelmi adatokból, hogy gond van. Óvatosságból a jelentősebb informatikai beruházásokat elhalasztanám.
- 2008 tavasz: Hardware replacement leállítása az üzleti kritikus beszerzések kivételével. (Ha nyár során visszaáll az értékesítés, akkor újra lehet indítani a beszerzéseket.)
- 2008 tavasz: Nagyjából ezen a ponton a munkaerő felvételt is leállítanám. Ha elég korán megtesszük, akkor nem kell később leépíteni (a fluktuáció elvégzi a piszkos munkát). Ha pedig kiderül hogy vaklárma, akkor majd veszünk fel embereket.
- 2008 nyár: Még mindig baj, sőt egyre nagyobb. Elkezdeném jegelni az informatikai projekteket. Nem leállítani, csak elhalasztani.
- 2008 nyár: Process improvement és audit projekteket indítanék (belső erőforrásokból).
- 2008 ősz: Nagy a baj, az értékesítés és a pénzügy idegesen rohangál.
- 2008 ősz: További erőteljes takarékosságot vezetnék be, pl. teljes utazási tilalom
- 2008 vége: Na itt felfüggeszteném az összes IT projektet, ROI-tól függetlenül.
- 2008 vége: Elkezdeném a beszállítói szerződéseket felülvizsgálni.
- 2009 tavasz: Leépíteném a kiszervezett és offshore munkahelyeket (ahol szükséges, belső munkatárs venné át a külső helyét). A tanácsadókat is megtizedelném.
- 2009 tavasz: Ezzel párhuzamosan elkezdeném a minőségi cseréket, hiszen a munkaerő piacon nagy lett a választék. A cserénél ügyelnék, hogy a tudás azért maradjon házon belül.
- 2009 nyár: Minimális hardware replacement.
- 2009 vége: A fellendülés első jeleire elkezdenék néhány kisebb beruházást/projektet elindítani, ROI alapján rangsorolva.

Látható a folyamatosság, ahogyan óvatos lépésekkel próbálnék takarékoskodni. Elkerülném a pánikreakciókat, ügyelnék hogy ne alakuljon ki pánik.

A költségek osztályozásánál arra ügyelnék, hogy az üzlet szinten tartásán nem csökkentenék (pl. maintenance, license fee típusú költségek), a fő megtakarítást a fejlesztések könyörtelen leállítása adná.
Az üzleti partnereimmel tisztáznám, hogy 2009-ben ne emeljék áraikat mert nem tudunk többet fizetni, és az ötleteikre szükség van de egyenlőre rakják el a fiókba.

Az embereim számára világossá tenném úgy 2008 őszére, hogy ez a helyzet nem szokványos, és tegyenek meg minden tőlük telhetőt.

Ps. Igaz hogy a terv nem tartalmaz direktben leépítést (sőt számos elemet tartalmaz a feleslegessé váló munkatársak foglakoztatására), de a projektek teljes körű befagyasztása az ehhez szükséges erőforrások leépítését jelenti.

Ps2. Az ütemterv a korábban említett „ideális" felépítésre vonatkozik. Kevésbé ideális felépítésnél meg kell fizetnünk az árat: elkerülhetetlenek a radikális lépések.