Je na palubě nějaký pilot? (dokument white paper)

Důležité :  Tento článek je strojově přeložený – přečtěte si toto upozornění. Anglickou verzi tohoto článku pro referenci najdete tady.

„Je na palubě nějaký pilot?“ Tak přesně tuto otázku nechce žádný cestující v letadle slyšet. Znovu si pročítám článek týkající se zrovna takové skutečné události, která se stala v prosinci roku 2013. Poté, co měl pilot letu z Des Moines v Iowě vážné zdravotní potíže, druhý pilot požádal o pomoc případné piloty na palubě letadla. Pomohl mu kapitán Mark Gongol, pilot bombardéru B1 letectva Spojených států. Letadlo s cestujícími a posádkou nakonec bezpečně přistálo.

Je to úžasný příběh. Ale vyhledal jsem si ho a znovu přečetl kvůli něčemu úplně jinému. Nedávno nám volal potenciální zákazník a ptal se, jestli bychom jim mohli poskytout „pilot“ našeho softwaru časových rozvrhů pro projekty organizací. Tento typ hovorů mě vždycky přiměje k zamyšlení. Když někdo v letadle řekne „pilot“, je naprosto jasné, koho tím myslí. Když ale podobné slovo použije někdo, kdo vyhodnocuje softwarové možnosti, nejsem si úplně jistý významem tohoto slova.

Termín „pilot“ se v softwarové branži často spojuje s jinými metodami náročného hodnocení, jako je třeba testování konceptu. Podívejte se tedy na to, co tyto termíny znamenají a jak se dají používat ve vašem vlastním podnikovém procesu hodnocení.

Testování konceptu

Tento výraz vznikl poměrně dávno a používá se hlavně v elektrotechnice. Jednalo se o vytvoření obvodu s cílem zjistit, jestli je takový obvod vůbec možný. Obvod neměl jít do výroby. Při testování konceptu pravděpodobně jste strávili víc času testováním než při vytváření výrobního obvodu. Při takové práci jste navíc mohli poškodit maximálně desku obvodu, kterou jsme měli před sebou. Byla to nenákladná metoda s minimálním rizikem, která dokazovala, jestli elektrický obvod může dosáhnout požadovaného výsledku.

V softwarovém jazyce je testování konceptu určeno k tomu, aby něco prokázalo. Když mi zavolá potenciální zákazník a požádá mě o testování konceptu pro řízení podnikových projektů nebo softwaru podnikového časového rozvrhu, položím mu vždycky tu stejnou otázku: „Jaké koncepty máme otestovat?“

Na druhé straně je obvykle rozpačité ticho.

Pokud chcete provést testování konceptu a nemáte žádnou představu o tom, co konkrétně chcete otestovat, jak zjistíte, jestli bude testování úspěšné nebo ne? Takhle to opravdu nefunguje.

Asi se chcete zeptat, proč by pak někdo chtěl provádět testování konceptu? Nejčastější odpovědí je, že žadatel pravděpodobně nevidí u managementu vůli implementovat jím vyvíjený software a doufá, že když ho managementu předvede živě, software se jim zalíbí a budou s jeho nasazením souhlasit. V tomto případě vlastně testujeme koncept, což je myšlenka podnikového softwaru, na managementu.

Kdyby bylo tak jednoduché, přesvědčit management o výhodách používání softwaru pro podnikové projekty a časový rozvrh, nasazovali bychom tohoto softwaru mnohem víc.

Tato metoda je problematická proto, že vaší práci při nasazování tohoto testování konceptu se nedostane ani zdaleka takové podpory, jakou byste získali pro produkční nasazení podnikového systému. Když organizace nasazuje podnikový systém, například časový rozvrh nebo systém řízení projektů, záleží jeho úspěch na mnoha věcech. Toto nasazení bude vyžadovat vstupy od managementu a zaměstnanců týkající se jakýchkoli aspektů organizace, které s nasazením souvisí. Dál bude vyžadovat určité časové období na konfiguraci, asistenci technických služeb při propojování s ostatními podnikovými systémy, čas na proškolení a v neposlední řadě také peníze.

Pokud vám něco z toho chybí, nebude se vám výsledek takového testování konceptu líbit. Bude jenom stínem toho, co je vaším skutečným cílem. Současnost žije cloudem a proto dost možná můžete získat přístup k plně hostovanému systému, takže si nemusíte dělat starosti s nákupem serverů a softwaru. Instalace systému je ale jenom zlomkem práce vyžadované k provedení alespoň základního nasazení vašeho systému testování konceptu.

Je snadno pochopitelné, proč organizace váhá s tím, použít spoustu peněz a zdrojů na implementaci něčeho, co potenciálně může ovlivnit celou organizaci. Je to obrovské riziko. Máme sklon software řízení podnikových projektů spíše vychvalovat, ale snadno si můžeme představit, že pokud se takový projekt nepovede, bude mít stejně negativní vliv. Samozřejmě je potřeba rizika zmírnit. Pokud je ale skutečnou výzvou přesvědčit management o výhodách systému, pak jsou tu určitě jiné cesty, jak to udělat. My v HMS Software používáme těchto několik postupů:

  1. Komunikujeme se skutečnými, už existujícími klienty.

    Podařilo se nám získat skvělé a spokojené klienty. Pokud má nový potenciální klient obavy z toho, do čeho se pouští, zkontaktujeme ho s naším stávajícím klientem. Mnohokrát se nám už stalo, že byl klient tak velkorysý, že dokonce nabídl osobní setkání. V ostatních případech se spojí telefonicky. Této komunikace se záměrně neúčastníme. Stávajícímu klientovi doporučujeme, aby se podělil s dobrými i špatnými zkušenostmi.

  2. Nechte nás to dokázat.

    Pokud opravdu máte koncept, který chcete prokázat, my vám s tím pomůžeme. Existují oprávněné důvody, proč je potřeba některé aspekty jistých implementací prokázat jako první. Nasazení bude zřejmě mít obrovské objemy dat určitého druhu. Jednou nás klient například požádal, abychom funkčnost našeho řešení předvedli na obzvlášť velkém projektu. Byli jsme požádáni, abychom předvedli, jak software spolupracuje s konkrétními prohlížeči nebo určitými databázemi, nebo jak se dá propojit s určitými verzemi konkrétních externích systémů. Pokud schválení brání takovýto druh konceptu, pak je nejlepší se obrátit na specialisty na danou problematiku.

  3. Můžeme vás trochu zaškolit.

    V případech, kdy potenciální klient musí za každou cenu vidět systém v provozu se svými daty, která používají jeho zaměstnanci, pomůžeme s načtením dat do hostovaného systému, pak provedeme minimální nezbytnou konfiguraci systému požadovanou klientem a vyškolíme zaměstnance, kterých se systém týká. Jsme moc rádi, když si nás do společnosti pozvou, abychom pomohli se samotnou demonstrací. Pokud to není možné, požádáme o možnost kontroly skriptu nebo demonstrace, kterou příslušní lidé použijí, a snažíme se ji přizpůsobit nebo k jejímu provedení zaměstnance proškolit.

Kde je ten pilot, když ho člověk potřebuje?

Tak co s tím pilotním projektem? To už zní líp, ne? Možná. Pokud jste byli požádáni o pilotní nasazení podnikového časového rozvrhu nebo podnikového systému řízení projektů, měli byste začít určením cílů. Pokud se cíle týkají jenom testování konceptu, pak nejde o pilotní program.

Pilotní projekt je skutečné živé nasazení v produkčním prostředí. Obvykle zahrnuje podmnožinu celkové základny uživatelů, která se použije pro vyhodnocení systému. Pilotní program bude pravděpodobně nějakou dobu trvat. Přestože jsou od začátku brány v potaz potřeby kompletní cílové základny uživatelů, pilotní program se zaměřuje na reálnou implementaci pro pilotní uživatele. Oni budou v novém systému skutečně řídit své projekty nebo zadávat skutečná data do svých časových rozvrhů.

Potíže, kterým bude čelit kompletní produkční nasazení, jsou stejné jako ty, kterým čelí pilotní implementace (až na objem nebo složitost dat). Mezi nejčastější potíže, kterým pilotní projekty čelí, patří chybějící sponzorská podpora, nedostatečný rozpočet, čas a zdroje a ,co je asi nehorší, nedostatečně formulované cíle, podle kterých by se dalo zjistit, jestli byl pilotní projekt úspěšný nebo ne.

To neznamená, že by pilotní projekt byl špatný. Udělat pilotní projekt může mít smysl a tento projekt může zmírnit rizika dopadu neúspěchu na celou společnost v případě nekompletního nebo špatně nakonfigurovaného nasazení. Aby byl pilotní projekt úspěšný, je potřeba se nad ním pořádně zamyslet.

Nedávno jsme začali pracovat na nasazení velkého rozsahu v organizaci veřejného sektoru. Potěšilo nás, že tato organizace už využila veškerý potřebný čas a vyhodnocení dokončila. Rozhodli se pro konkrétní podnikový systém. Naštěstí je to náš systém. Během loňského roku jsme pracovali s jejich hodnotícím týmem a odpovídali jsme na všechny jejich dotazy týkající se technologií. Teď se však pozornost upírá na to, jaký má systém dopad na každodenní procesy zaměstnanců této organizace.

Navrhli nám, abychom v průběhu 6 měsíců pracovali se skupinou, která ale (i když se dá její velikost měnit) tvoří jenom asi 10 % celé skupiny. Mají adekvátní rozpočet, pilotní projekt má podporu managementu na té nejvyšší úrovni a my máme dostatek času, abychom se ujistili, že se můžeme postarat o všechno, co je obvykle u takového nasazení potřeba. Skupina, které se projektu v prostředí sledování projektu a časového rozvrhu účastní, bude s tímto systémem v blízké budoucnosti opravdu pracovat. Takže to není jenom test. Je to spíš první fáze nasazení a ne cvičení typu „zkusme to, však se uvidí“. Díky všem těmto faktorům věříme, že nás na konci tohoto roku čeká velký úspěch.

Shrnutí

Pilot (ve smyslu pilotního projektu) a testování konceptu jsou ve světě podnikového softwaru běžnými věcmi. Když na ně v budoucnu narazíte, poučte všechny zainteresované osoby o těchto klíčových faktorech úspěchu:

  1. Nejdřív se ujistěte, že jste si jasně stanovili své cíle.

  2. Potom ověřte, že management vašim potřebám rozumí, podpoří je (ve smyslu financí, zdrojů a času) a pomůže vám těchto cílů dosáhnout.

  3. Nakonec nezapomeňte na plán projektu a spravujte ho stejně jako jakýkoli jiný projekt ve vašem portfoliu.

O autorovi:

Chris Vandersluis je prezidentem a zakladatelem společnosti HMS Software, certifikovaného partnera společnosti Microsoft, se sídlem v Montrealu v Kanadě. Má diplom z ekonomie z McGill University a více než 30 let zkušeností v oboru automatizace systémů řízení projektů. Je dlouhodobým členem institutu PMI (Project Management Institute) a skupině MPUG (Microsoft Project Users Group) pomáhal založit pobočky v Montrealu, Torontu a Quebecu. Mezi publikace, do kterých Chris přispěl svými články, patří Fortune, Heavy Construction News, Computing Canada, PMNetwork institutu PMI a Project Times. Na univerzitě McGill University učí pokročilý projektový management a často přednáší na konferencích asociace projektového managementu v Severní Americe a po celém světě. Společnost HMS Software publikovala systém projektových časových rozvrhů TimeControl a od roku 1995 je Microsoft Project Solution Partnerem.

Chrise Vandersluise můžete kontaktovat na e-mailové adrese: chris.vandersluis@hms.ca.

Pokud si chcete přečíst další články Chrise Vandersluise týkající se řízení podnikových projektů, podívejte se na jeho blog EPM Guidance (http://www.epmguidance.com/?page_id=39).

Poznámka : Upozornění ke strojovému překladu: Tento článek přeložil počítačový systém bez zásahu člověka. Společnost Microsoft nabízí tyto strojové překlady proto, aby umožnila uživatelům, kteří nemluví anglicky, získat informace o produktech, službách a technologiích této společnosti. Protože je tento článek strojově přeložený, může obsahovat slovní, syntaktické nebo gramatické chyby.

Rozšiřte své znalosti a dovednosti
Projít školení
Získejte nové funkce jako první
Připojte se k účastníkům programu Office Insiders

Byly tyto informace užitečné?

Děkujeme vám za zpětnou vazbu.

Děkujeme vám za váš názor. Vypadá to, že bude užitečné, když vás spojíme s některým z našich agentů z podpory Office.

×