Egy szoftver bevezetésének szarvashibái

Amikor Murphy még a közelben sincs

Egy új szoftver bevezetése – legyen szó egy chat programról vagy komplex vállalatirányítási rendszerről – mindig nagyon izgalmas, kihívásokkal teli feladat. Ugyanakkor szinte borítékolható, hogy érni fognak bennünket kellemetlen meglepetések az úton.
Ebben a posztban arról lesz szó, hogy mik az általánosan elkövetett, legnagyobb baklövések egy ilyen folyamatban, és hogyan tudjuk kivédeni őket.

Tájékoztatás hiánya

Kinek kell tudnia arról, hogy ilyen fejlesztésre adtuk a fejünket? Magától értetődőnek gondolhatjuk a választ, sajnos sok esetben elmarad ez a lépés már házon belül is. Szóval alapvetően mindenkinek, aki valamilyen formában érintett, hatással lesz a mindennapjaira, munkavégzésére. De nem ördögtől való az az elképzelés sem, hogy minden alkalmazottnak, sőt szerintem van helye egy ilyen információnak a céges hírlevélben is. Hallottunk már olyan munkavállalóról vagy ügyfélről, aki azért vetett véget a kapcsolatnak, mert megjelent az innováció egy cégnél? Én sem hiszem.

Rossz projektcsapat

Amikor évekkel ezelőtt az első ilyen projektbe belevágtam, sokat olvastam a témában, és majdnem minden írásban volt egy fontos, közös pont: a legjobb embereket kell ráállítani a projektre minden érintett csapatból. Igen, az azt fogja jelenteni, hogy a projekt lezárásáig ki kell őket vonni heti néhány órára a termelésből. Talán nem nagy ár ahhoz viszonyítva, hogy milyen eredménnyel záródna egy ilyen folyamat, ha egy próba- vagy felmondási idejét töltő kollégára bíznánk a szakértői szerepet.

Ezt a tanácsot megfejelem azzal, hogy a felelősségen túl fel is kell jogosítanunk a csapat tagjait, hogy a többiektől bármilyen, releváns segítséget kérhessenek, esetleg ajánlatokat gyűjtsenek be, a cég nevében bizonyos körökben eljárhassanak.

Na és legyen a csapatnak vezetője, aki kézben tartja a dolgokat, ha úgy tetszik, projektmenedzsere, aki nyomon követ, kér, követel, beszámol, kézben tart.

Ja, és a csapattagok folyamatos cseréje sem jelent semmi jót az álmoskönyv szerint.

Azt sem tudjuk, mit keresünk

Szükségünk van egy új szoftverre. Könnyedén (akár könnyelműen is) hangzik el sokszor. De tisztában vagyunk azzal, hogy mit keresünk? Milyen problémákat akarunk megoldani, kiküszöbölni? Milyen elvárásaink vannak az új programmal szemben? Ár, üzemeltetés mikéntje, elengedhetetlen és vágyott funkciók… Megannyi szempont, amit előre meg kell határoznunk. Érdemes mellettük kitartanunk – esetleg minimálisan finomhangolnunk -, különben könnyedén az egész folyamat elején találhatjuk magunkat újra és újra. Nem biztos, hogy a folyamatosan változó szempontrendszer miatt a hatodik alkalommal is ugyanolyan lelkesedéssel kezd kutatásba a csapatunk, mint tett az első alkalommal.

Elhúzódó döntés

Gyönyörűséges, okos táblázatokba gyűjtve megvan minden releváns infó, a kedvezményes ajánlatok sorakoznak, a gyártók sales-esei már naponta keresik telefonon a kollégákat. És akkor a menedzsment elköveti az egyik legnagyobb hibát, nem dönt. Tolódik, húzódik, a frusztráció nő, az ajánlatok érvényüket vesztik. Ha elég sokáig nem születik döntés, kezdődhet szinte elölről a folyamat, ami nem segíti a bizalom vagy a lelkesedés intézményét sem.

Rosszul összerakott/kivitelezhetetlen terv és a magára hagyott csapat

Egy jó ábra már a megoldás fele.” – mondogatta mindig a fizikatanárom. Valahogy így van ez a projekttervvel is. Ha minden résztvevő és felelős tisztában van a fázisokkal, lépésekkel, azok egymásra hatásával, ki vannak jelölve mérföldkövek, és kellő (akár időbeli) rugalmasságot hagyunk az egészben, nem érhetnek nagy meglepetések.
Ehhez képest egy következetlen, rugalmatlan terv maximum folyamatos frusztrációhoz és kudarcélményhez vezethet igen gyorsan. Esetleg teljesen bedönti az egész folyamatot – láttunk már ilyet is sajnos.

Érdemes rendszeresen beszámoltatni a projektcsapatot vagy annak vezetőjét a haladásról, kihívásokról, és szükség szerint módosítani a terven, bevonni több erőforrást, vagy bármilyen intézkedést hozni, amivel biztosítható a projekt sikere.

Piszkos adatok és rossz konfiguráció

Sajnos ezekre is több példát láttunk már, mint jól esett volna. Ha olyan szoftverről van szó, ami adatokat fog használni akár korábban használt, hasonló szoftverből vagy valamilyen gyűjteményünkből, akkor az adattisztítás egy sarkalatos pont. Egyszerűen használhatatlan lesz az új program minden funkciója, ami erre építene. Nem jó üzlet.

Ki kell fejtenem, milyen hátrányokkal járhat, ha nincs a folyamatainkra szabva, megfelelően konfigurálva az új program, és mennyi plusz munkát jelent majd a használata a kollégáknak? Ugye nem kell?!

Felkészületlen csapat

Amikor egyszerűen a felhasználók nincsenek felkészülve az új szoftver használatára. Ebből sem keveset láttunk, sőt ezeket további kategóriákra is tudom bontani (sajnos):

a) Túl rövid leírás, nem megfelelő betanítás

Amikor az átadott tudásanyag nem kielégítő mélységű, több funkciót vagy folyamatot nem fed le, amit a kollégáknak használniuk kellene készségszinten. Vagy annak az esete, amikor például videós oktatóanyagot adunk tanulmányozásra, amikor gyakorlatra lenne szüksége a csapatnak.

b) Túl hosszú leírás

Ilyen is van, bizony. Az az eset, amikor minden is le van írva a használati útmutatóban, és egész egyszerűen nem lesz kedve a kollégáknak egyetlen rövidke kérdés miatt egy 1000 oldalas doksiban túrni. Inkább megkérdezik a mellettük ülőt, és csak reménykedhetünk abban, hogy helyes választ kap, és nem épp egy helytelen gyakorlat elterjedésének és beépülésének az okozói voltunk a szószátyár leírással.

c) Nemtörődöm kolléga

Az pedig már sokkal inkább a vállalati kultúráról árulkodik, ha pénz, paripa, fegyver, leírás, oktatóanyag, gyakorlati lehetőség ellenére sem hajlandó egy-egy kolléga a szoftver használatának elsajátítására – és ez ki sem derül a bevezetés pillanatáig, ugye.

Utánkövetés hiánya

A szoftver bevezetés projekt nem az élesítés/használatba vétel pillanatában ér véget. Néhány hétig/hónapig még gyűjteni kell a visszajelzéseket a felhasználóktól. Ellenkező esetben az ilyenkor természetesen bekövetkező produktivitás csökkenése nem csak átmeneti jelenség lesz.

Az első napokban “fogni kell a kezüket”, aztán pedig rendszeresen gyűjteni kell a visszajelzéseket, hogy finomhangolni lehessen a szoftver működését – nem mellesleg a kollégák sem fogják úgy érezni, hogy magukra lettek hagyva.

Tisztázatlan támogatás a gyártótól

Ez az a kérdéskör, aminek még a döntés előkészítésekor, az adatgyűjtés fázisában kellene előkerülnie, mégis sokan figyelmen kívül hagyják. A szoftvergyártó sales-ese ígér fűt-fát, bármit, hiszen az eladás a célja, aztán amikor elakadás van a projekt bármely szakaszában, akkor döbbennek rá sokan, hogy milyen konkrétumokat rejt a szerződés Support bekezdése, és milyen, órabérben jelentkező plusz költségekkel kell kibővíteni a projekt költségvetését. Ne feltételezzünk, kérdezzünk rá, hogy melyik fázisban milyen és mennyi segítségre számíthatunk tőlük!

Bevallom, sokkal hosszabb lett a lista, mint amire a poszt írásakor számítottam. Egyenesen rosszul esett ennyi hibát végig gondolni, kifejteni, mert közben előjöttek az emlékek, amikor át is éltem őket valamilyen szerepben. És ez csak a top lista.

Kíméljük meg magunkat némi fejfájástól, a csapatunkat pedig egy nagy adag frusztrációtól, kudarcélménytől, és ne kövessük el a fenti hibákat, tanuljunk mások eseteiből! Ha pedig szükségét érezzük, egyáltalán nem ciki egy külsős szakértő bevonása egy ilyen projektbe. Ne felejtsük el, hogy a kollégáink közül valószínűleg kevesen foglalkoznak rendszeresen ilyen projektekkel, ne várjunk tőlük lehetetlent!

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük