Van pilóta a repülőgépen? tanulmány

Fontos : Ez a cikk gépi fordítással lett lefordítva, lásd a jognyilatkozatot. A cikk angol változatát itt találhatja meg.

Egy repülőgépen utazva a „Ha van a fedélzeten pilóta, kérjük, hogy jelezzen a hívógombjával” mondat az utolsó dolog, amit bárki is hallani szeretne. Újraolvastam egy megtörtént esetről szóló lebilincselő történetet, amely 2013 decemberében esett meg. Miután az Iowa államban található Des Moines nemzetközi repülőtérről felszálló járat pilótája rosszul lett, a másodpilóta megkérdezte, hogy van-e az utasok között pilóta. Mark Gongol százados, az amerikai légierő B-1-es bombázópilótája épp a fedélzeten tartózkodott, és vállalta a beugrást. A repülőgép, az utasok és a személyzet biztonságosan földet ért.

Bár ez egy felemelő történet, egészen más oka volt annak, hogy újból elolvastam. Nemrég felhívott egy potenciális ügyfelünk, és megkérdezte, hogy egy „pilótaprogram" keretében kipróbálhatják-e vállalati projektmunkaidő-nyilvántartási szoftverünket. Az ilyen jellegű hívások mindig elgondolkodtatnak. Amikor egy repülőgépen valaki a pilótáról beszél, pontosan tudjuk, mire gondol, de ha egy szoftverbeállításokat tanulmányozó személy használja ugyanezt a szót, az már nem annyira egyértelmű.

A „pilóta” szó a szoftveres világban gyakran más tanulmányozási módszerekkel (pl. a bizonyító próbával, POC) együtt használatos. Nézzük át, hogy mit is jelentenek ezek a kifejezések, és hogyan használhatja őket a saját cégénél a tanulmányozási folyamat során.

Feltevés bizonyító próbája

A kifejezés régi keletű, és gyakran használják az elektrotechnikában. Az áramkörök „deszkamodelljének” elkészítése azt a célt szolgálta, hogy megnézzék, megvalósítható-e az áramkör, és nem azért, hogy gyártásra készítsék elő. A feltevés bizonyító próbája valószínűleg időigényesebb, mint a gyártásra kész áramkör megépítése, de ha valami mégsem működik megfelelően, legfeljebb a munkaasztalon lévő áramköri lap sérülhet meg. Ez egy olcsó és alacsony kockázatú módszer annak bizonyítására, hogy az adott elektromos áramkör az elvárt módon működik-e.

Szoftveres környezetben a megvalósíthatósági példák valaminek a bizonyítására szolgálnak. Amikor a potenciális ügyfelek felhívnak, és megkérdezik, hogy tudnék-e nekik segíteni egy vállalati projektvezetési vagy munkaidő-nyilvántartási szoftver megvalósíthatósági példájának létrehozásában, mindig ugyanaz a válaszom: „Milyen koncepciókat szeretnének bizonyítani?”

Erre általában csönd és zavart kifejezés a válasz.

Ha megvalósíthatósági példát szeretnének létrehozni, és nincs elképzelésük arról, hogy mit kívánnak bizonyítani, honnan tudják majd, hogy az eredmény siker vagy kudarc-e? Természetesen erre nincs mód.

Megkérdezheti, hogy akkor miért szeretne valaki megvalósíthatósági példát létrehozni? A leggyakoribb válasz az, hogy azért kérheti valaki a próbát, mert a vezetés valószínűleg még nem támogatja a viszgált szoftver implementálását, és azt reméli, hogy ha élőben látják, talán beleszeretnek az ötletbe, és beleegyeznek a telepítésébe. Ebben az esetben a „próba” az a rész, ami a vezetésnek szól, a „feltevés” pedig maga a vállalati szoftver ötlete.

Ha ilyen könnyű lenne meggyőzni a vezetést, hogy a vállalati projektvezetési és munkaidő-nyilvántartási szoftver kiváló lenne számukra, rengeteget telepítenénk belőle.

Az a probléma ezzel a módszerrel, hogy a feltevés bizonyító próbája nem kap annyi támogatást, amennyit egy vállalati rendszer üzemi környezetbe való telepítése kapna. Amikor egy szervezet vállalati rendszert, például munkaidő-nyilvántartási vagy projektvezetési rendszert telepít, számos dolog szükséges a sikerhez. Először is a vezetésnek és a munkatársaknak meg kell adniuk a szervezet minden szempontját a telepítéshez. Ezt követően szükség lesz időre a konfigurációhoz, segítségre a technikai szolgáltatásoktól az összekapcsoláshoz a többi vállalati rendszerrel, a vezetés támogatására, betanulási időre, és igen, pénzre.

Ha ezek közül egyikkel sem rendelkezik, milyen lesz az a rendszer, amelyet a megvalósíthatósági példában elkészíthet? Sajnos a legjobb esetben is csak közelíthet ahhoz, amit szeretne. Napjaink felhőalapú korában valószínűleg hozzájuthat teljes mértékben üzemeltetett rendszerekhez is, így nem kell kiszolgálók és szoftverek vásárlásával bajlódnia, és egy telepített rendszer a munka törtrészét jelentené a feltevésbizonyító próbarendszer alapszintű telepítéséhez képest.

Könnyen érthető, hogy a szervezetek miért haboznak sok pénzt és erőforrást szánni valami olyan bevezetésére, ami a teljes szervezetre hatással lehet. Ez a gyakorlat nagy kockázatot rejt. Hajlamosak vagyunk a vállalati projektvezetési szoftvereknek csak az előnyeit kiemelni, de könnyen elképzelhető, hogy egy rosszul sikerült projektnek legalább ugyanilyen negatív hatása lehet. Nyilvánvaló szempont lehet ezért a kockázat csökkentése. Ha azonban a legnagyobb kihívás a vezetés meggyőzése a rendszer előnyeiről, akkor bizonyosan vannak erre jobb módszerek is. A HMS Software vállalatnál az alábbi technikák némelyikére összpontosítottunk:

  1. Érdeklődés egy valódi, már meglévő ügyfélnél

    Szerencsére van néhány kiváló ügyfelünk, akik elérhetők, és nagyon elégedettek. Amikor egy lehetséges új ügyfél aggódik, hogy mibe fog bele, összehozzuk egy már meglévő ügyféllel. Számos esetben a meglévő ügyfél nagyvonalúan felajánlja, hogy személyes találkozón fogadja a potenciális ügyfelet. Máskor telefonon beszélnek egymással, amiben mi szándékosan nem veszünk részt. A meglévő ügyfélnek azt javasoljuk, hogy a jó híreket és a kihívásokat is ossza meg.

  2. Bizonyítás

    Ha valóban van egy elgondolása, amely bizonyításra szorul, segítünk benne. Jogos indokai lehetnek, hogy miért kell először bizonyos megvalósítások szempontjait igazolni. Előfordulhat, hogy a telepítés bizonyos típusú adatból nagy mennyiséggel rendelkezik. Egyszer például arra kértek bennünket, hogy mutassuk be, hogyan működik a megoldásunk különösen nagy projektterheléssel. Azt kérték, hogy mutassuk be a szoftver működését bizonyos böngészőkkel vagy adatbázisokkal, illetve az összekapcsolását egyes külső rendszerek adott verzióival. Ha az ilyen típusú aggodalmak gátolják a kiértékelést, ennek elhárítására a legalkalmasabb személyek az adott téma szakértői.

  3. Részt vehet képzésben is az adott témában

    Abban az esetben, amikor a potenciális ügyfélnek meg kell mutatni, hogy a saját munkatársaik által használt rendszer működik az adataikkal, segítünk betölteni az adatokat egy üzemeltetett rendszerbe, majd elvégezzük annak minimális konfigurálását az ügyfél kívánalmai szerint, és kiképezzük a megfelelő személyeket. Előnyösebbnek tartjuk, ha a vállalatnál segítünk magában a bemutatóban, de ha ez nem lehetséges, kérjük, hogy nézzék át azt a parancsfájlt vagy bemutatót, amelyet az érintett személyek fognak használni, és megkérjük őket, hogy segítsenek a módosításában, illetve kiképezzük az azt biztosító munkatársakat.

Hol egy pilóta, amikor szükség van rá?

Mit szól a próbaprojekthez? Ez beválhat, ugye? Lehet. Ha arra kérnék, hogy állítson fel egy vállalati projektvezetési vagy munkaidő-nyilvántartási rendszert, a célok meghatározásával kellene kezdenie. Ha a célok mind a megvalósíthatósági példára vonatkoznak, akkor ez nem nevezhető próbaprogramnak.

A próbaprojekt egy valódi, üzemi környezetben megvalósított élő telepítés, amely általában az értékelendő rendszerhez számításba veendő összes felhasználók egy részét magában foglalja, ezért valószínűleg némi időt igénybe vesz. Bár a kezdetektől számításba vesszük a megcélzott összes felhasználó igényeit, a próbaprogram a próbafelhasználók számára történő valós bevezetésre összpontosít. A próbafelhasználók ténylegesen kezelni fogják a projektjeiket, illetve valóban kitöltik a munkaidő-nyilvántartásokat az új rendszerrel.

A próbabevezetés esetén az adatok mennyisége vagy összetettsége kivételével ugyanazokat a problémákat kell megoldani, mint a teljes üzemi telepítések esetén. Az általam látott próbaprojektek esetén a leggyakoribb nehézségek közé tartozott a támogatás hiánya, az elégtelen költségvetés, idő és erőforrások, és mind közül talál a legrosszabb, a pontos célok hiánya, amelyekkel meg lehetne állapítani, hogy a próbaprojekt sikeres-e.

Ezzel nem azt mondjuk, hogy a próbaprojektek rosszak. Ésszerű lehet egy próba elvégzése, és arra is szolgálhat, hogy csökkentsük vele a teljes szervezetre gyakorolt hatás kockázatát, amelyet a hiányosan vagy gyengén konfigurált telepítés okozhat. A próbaprojekt sikerességéhez azonban átgondolásra van szükség.

Nemrég egy állami szervezet számára megvalósítandó, jelentős méretű telepítésen kezdtünk el dolgozni. Örömteli tény, hogy a szervezet már elvégezte az értékelést. Meghozták a döntést a vállalati rendszerről. Elégedetten mondhatjuk, hogy a mi rendszerünket választották. Az elmúlt év során az értékelő csapatukkal dolgoztunk a technikai kérdések megoldásában, és most már arra lehet koncentrálni, hogy milyen hatást gyakorol a rendszer a szervezetben lévő személyek napi folyamataira.

Azt javasolták, hogy 6 hónapon keresztül dolgozzunk együtt egy csoporttal, amely bár nagy méretű, mégis csak körülbelül 10%-át teszi ki a teljes csoportnak. Megfelelő költségvetés áll rendelkezésre, a próba legfelső szinten bírja a vezetés támogatását, és elég időt kaptunk arra, hogy meggyőződjünk arról, mindenben tudunk segíteni, amiben egy ehhez fogható telepítés során normál esetben tudnánk. Az ebbe a projektkövetési és munkaidő-nyilvántartási környezetbe helyezendő csoport fogja a közeljövőben élesben használni, ez tehát nem csupán egy tesztet jelent. Ez sokkal inkább a bevezetés első szakasza, és nem a „próbáljuk ki, aztán meglátjuk, mi lesz” típusú gyakorlat. Mindezen tényezők ismeretében ez év végére várunk sikeres eredményt.

Befejezés

A próba- és a feltevésbizonyító próbaprojektek a vállalati szoftverek esetén tényként kezelendők, de az esetleges jövőbeli projektet sikeressé teheti, ha a résztvevők figyelmét felhívja néhány kulcsfontosságú tényezőre:

  1. Először is pontosan tűzze ki a célokat.

  2. Ezután gondoskodjon arról, hogy a vezetés tudatában legyen annak, hogy mire van szüksége, és támogassa Önt pénz, erőforrások és idő tekintetében, hogy elérhesse ezeket a célokat.

  3. Végül készítsen projekttervet, és a portfóliójában lévő többi projekthez hasonlóan kezelje azt.

A szerzőről

Chris Vandersluis a montreali, kanadai székhelyű és Microsoft Certified Partner minősítésű HMS Software elnöke és alapítója. Közgazdasági diplomáját a McGill egyetemen szerezte, és 30 éves tapasztalattal rendelkezik a projektirányítói rendszerek automatizálásában. Hosszú ideje a Project Management Institute (PMI) tagja, és segített a Microsoft Project Users Group (MPUG) Montreal, Toronto és Quebec fejezetének létrehozásában. Chris írásai a következő kiadványokban jelentek meg: Fortune, Heavy Construction News, Computing Canada magazin, PMI’s PMNetwork és Project Times. Haladó projektmenedzsmentet tanít a McGill egyetemen, és gyakran tart előadást projektirányítási funkciókról Észak-Amerikában és szerte a világon. A HMS Software a TimeControl projektszintű munkaidő-nyilvántartási rendszer létrehozója és a Microsoft Project Solution Partner tagja 1995 óta.

Chris Vandersluis a következő e-mail-címen érhető el: chris.vandersluis@hms.ca

Ha el szeretné olvasni Chris Vandersluis további EPM-mel kapcsolatos cikkeit, keresse fel az EPM Guidance nevű blogját (http://www.epmguidance.com/?page_id=39).

Megjegyzés : Gépi fordítás jognyilatkozata: Ez a cikk számítógép által, emberi közreműködés nélkül lett lefordítva. A Microsoft ezeket a gépi fordításokat azért nyújtja, hogy az angol nyelvet nem beszélők minél több tartalomhoz tudjanak hozzáférni a Microsoft termékeivel, szolgáltatásaival és technológiáival kapcsolatban. A gépi fordítás miatt előfordulhat, hogy a szöveg szóhasználati, szintaktikai vagy helyesírási hibákat tartalmaz.

Ismeretek bővítése
Oktatóanyagok megismerése
Új szolgáltatások listájának lekérése
Részvétel az Office Insider programban

Hasznos volt az információ?

Köszönjük a visszajelzését!

Köszönjük visszajelzését. Jobbnak látjuk, ha az Office egyik támogatási szakemberéhez irányítjuk.

×