Poruchy v komunikaci na straně dodavatele a klienta
Komunikace jako taková, nestojí na prvním místě v přehledu úskalí a problémů při dodávce IS náhodou. Skutečnost, že se komunikace mezi dodavatelem a zákazníkem stane problematickou či dokonce přestane fungovat vůbec, je jednou z nejvážnějších, ne -li vůbec nejzávažnější porucha při zavádění IS. Pro tento stav existuje řada převážně subjektivních příčin z nichž lze jen namátkově jmenovat:

· organizační a kompetenční změny u obou subjektů
· ekonomické potíže
· personální změny
· přecenění vlastních sil
· tvůrčí potíže
ale také i
· osobní antipatie partnerů
· uražená ješitnost jednotlivců i firmy jako celku
· lajdáctví, liknavost a neochota jednotlivců apod.

Pokud jsme takto povrchně analyzovali kořeny poruch v komunikaci, nutně si musíme položit otázku, zda nejsou již systémové chyby v dohodnutém způsobu (definici) komunikace, který již svým principem může zakládat budoucí problémy. Mezi takové systémové chyby patří zejména:

· nebyly předem jasně stanoveny okruhy vzájemně komunikujících partnerů
· nebyla srozumitelně určena forma komunikace (dokumenty a způsob jejich transportu)
· nebylo jasně určeno, kdo dokumentování komunikace povede a jak bude s dokumenty dále zacházeno (např. ukládání na elektronických nosičích, listinná archivace)
· nebyla určena periodicita (plán) komunikace
· nebyly určeny orgány (osoby) projektu, které by kontrolovali průběh komunikace
· nebyly určeny rozhodčí orgány pro případ neshod či sporů

Předchozí naznačená analýza již částečně ukazuje určité cesty, jak poruchy v komunikaci odstranit. Jako primární je stanovit pravidla (systém) komunikace či jej opravit, pokud se dosavadní neosvědčil.

Jako druhý krok je reprezentativní schůzka kompetentních funkcionářů projektu, kteří budou nad přijatelným (funkčním) systémem komunikace společně řešit další problémy, které zapříčinily, že dobře nefungoval.

Součástí řešení problémů musí být i odvaha k razantnějším krokům tj. přiznat partnerovi skutečnou pravdu, byť by byla nepříjemná a učinit i nevyhnutelně personální změny v projektovém (realizačním) týmu, pokud se zjistí, že jedna či druhá strana spolu z nejrůznějších příčin nedokáže spolupracovat, byť jsou na jedné či druhé straně kvalitní odborníci ve svém oboru. Praxe již ukázala, že osoby, které se ne zcela osvědčily na některých projektech, byly velmi úspěšné na jiných projektech, protože právě zde velmi dobře fungovaly, resp. byly nastaveny tzv. komunikační kanály.

Neplnění termínů
Neplnění termínů je další z obvyklých a velmi frekventovaných poruch procesu zavádění IS.

Pokud rovnou vynecháme neplnění plynoucí z pracovní nespolehlivosti firem či jednotlivců, kterékoliv z obou stran, pak lze příčiny omezit zhruba na tento okruh:

· od samého počátku nerealisticky postavený harmonogram prací - práce nejsou "fyzikálně" zvládnutelné nebo je někdy i záměrně nerespektována hloubka a šíře řešené problematiky (obchodní trik)
· harmonogram s nevhodně postavenou posloupností kroků a úkonů - vzájemně podmiňující se kroky nesprávně navazují
· skluz některé z klíčových podmiňujících fází realizace dalších kroků
· kapacitní problémy na kterékoliv straně
· špatný odhad složitosti problémů - nekalkulované rezervy na možné problémy apod.

Vzhledem k tomu, že časové skluzy mohou značně devalvovat očekávaný efekt nasazení IS a nejenže oddalují rutinní používání, ale často i projekt jako takový prodražují, je nutné učinit z obou stran nápravné kroky, z nichž některé mají charakter preventivní charakter a jiné jsou operativního charakteru:

· předem stanovit ve smlouvě penalizaci za termínové neplnění klíčových fází projektu
· předem určit jednoznačné mechanismy hlídání důležitých časových milníků na obou stranách
· neprodleně zahájit jednání k problematice neplnění termínů - tj. nedopustit tzv. "skluzy skluzů" - paralela je shodná jako u zanedbané choroby, která nebyla podchycena na samém začátku
· vyvodit důsledky (i vztažené k jednotlivým osobám) z neplnění termínů

Nenaplněná očekávání
Nenaplněná očekávání většinou nepatří k nejfrekventovanější a skupině problémů zavádění IS, patří však rovněž mezi velmi závažné poruchy. Seriózní dodavatelé se tomuto problému snaží maximální měrou předejít, neboť není z obchodního hlediska nic horšího než zklamaný zákazník po vykonání velkého množství práce.

Pokud se však v průběhu implementace či na počátku rutinního provozu u zákazníka takový pocit vyskytne a týká se podstatných věcí, pak tato skutečnost významně ohrožuje nejen úspěšné budoucí používání SW produktu, ale i celkovou budoucí spolupráci obou partnerů.

Nenaplněná očekávání mají dva dominantní zdroje

· partneři si na samém začátku spolupráce nedokázali popsat a vysvětlit svá stanoviska - tj. definovat cíle a jejich očekávané splnění na straně zákazníka a možnosti jejich realizace ze strany dodavatele.
· dodavatel nesplnil ať již neúmyslně či částečně vědomě dohodnutá řešení

Zatímco v druhém případě lze zjednat nápravu velmi obtížně, i když částečně je možné dodavatele tzv. dotlačit k přislíbenému řešení nebo jej přimět ke slevě či penalizovat pokud to bylo dohodnuto ve smlouvě, pak první popsaný zdroj nenaplněných očekávání lze eliminovat prevencí. Definování požadavků (očekávání) je nutno provést nejméně na dvou úrovních:

· ve studii realizovatelnosti
· v implementační studii

Oba dokumenty procházejí přísnými interními i vzájemnými oponenturami a po jejich obhajobě jsou oba oběma stranami schváleny. Tím jsou již dostatečně eliminována rizika pozdějších nedorozumění či zklamání. Ze strany zákazníka je nutno vyvinout na dodavatele dostatečný tlak, aby možná řešení co nejsrozumitelněji vysvětlil, ale zejména i prakticky předvedl formou různých prezentací, instruktáží a školení.Rovněž je vhodné, aby celý proces zavádění SW byl rozdělen do určitých přiměřeně časově rozsáhlých etap s dostatečně hustými kontrolními body, aby bylo možné monitorovat vývoj projektu zákazníkem a případně včas počínání dodavatele usměrnit či dokonce zastavit.

Technické problémy
Pokud rovnou vyřadíme extrémní případ, kdy se SW produkt vůbec nedaří instalovat a provozovat ani v jakémsi minimálním rozsahu, pak lze zjednodušeně říci, že z pohledu zákazníka jsou technické problémy vnímány zejména jako:

· častá (opakovaná) a nahodilá poruchovost systému - systém se chová tak, že po určitý čas je použitelný bez jakýchkoliv omezení a po určitý čas je práce prakticky nemožná, tj. je bez odezvy
· systém má trvale uživatelsky nepřijatelné časové odezvy
· systém v některých svých subčástech je trvale nefunkční příp. nepodává korektní výsledky

Zatímco s posledním problémem je povinen si každý dodavatel SW poradit v přiměřeném čase a chyba je zcela jednoznačně na jeho straně, pak u prvních dvou specifikovaných problémů nelze tak jednoduše možné příčiny posoudit, tj. na čí straně je chyba.

V podmínkách dodavatele, tj. na jeho technickém zařízení se SW chová naprosto korektně a může to tak být i u řady jiných klientů, zatímco u inkriminovaného zákazníka jsou problémy zhruba popsaného rázu. Protože, technické problémy (po eliminaci všech lidských faktorů) mají vždy své exaktní fyzikální příčiny, je rovněž nutné k nim i z tohoto hlediska přistupovat tj.:

· provést analýzu příčin (např. technická měření a srovnávací testy)
· navrhnout příslušná technická opatření k eliminaci poruchových stavů

Z uvedeného plyne, že v rámci zpracovávání studie realizovatelnosti může být podcenění technické platformy na straně zákazníka osudové a účast příslušných technických odborníků od obou partnerů je v této etapě nezastupitelná.

Lze říci, že každý technický systém má své minimální hraniční parametry, při jejichž splnění je ještě schopen funkce. V zájmu bezproblémového fungování IS i z hlediska perspektivy řešení nelze však pohyb na těchto hraničních hodnotách doporučit, ale pracovat vždy s přiměřenou rezervou.

Přestože se nacházíme v epoše mohutného rozvoje oblasti IT, kdy na uživatelské hladině není prakticky nic co bylo technicky neřešitelné, musíme mít na paměti, že vážnější technické problémy, které byly dříve nesignalizovány dodavatelem a které event. povedou k dalším nutným investicím u zákazníka, jsou taktéž faktory, které patří k nenaplněným očekáváním.

Zákazník totiž očekává nejen funkcionalitu SW, ale i jeho bezproblémovou funkčnost.

Odpor ze strany uživatelské vrstvy
Problém, který je pojmenován jako odpor ze strany uživatelské vrstvy, je problémem většinou ryze interním a to na straně zákazníka a je možné jej zjednodušeně koncentrovat do zkratky odpor vůči novému a neznámému. Se zaváděním nového IS (předpokládá se, že zákazník nějaký IS již má) musí koncový uživatel často:

· vykonávat po jistou dobu práci navíc - spolupráce s dodavatelem při zavádění a jeho kmenové agendy
· seznamovat se s funkcemi a ovládáním nového systému
· změnit některé zažité pracovní návyky a rituály
· rozšířit své uživatelské znalosti o další poznatky z oblasti IT

Uvedené faktory mohou způsobit jisté potíže při zavádění systému, kdy jednotliví uživatelé podvědomě či zcela vědomě kladou určitý odpor, který tento proces může vážně komplikovat a brzdit.

Z tohoto důvodu je nanejvýš vhodné, aby se ihned na samém počátku uskutečnila diskuse mezi dodavatelem a vedoucími pracovníky zákazníka a byla specifikována míra nebezpečí, která se v této oblasti na uživatelské straně budou eventuálně vyskytovat a jaká opatření budou případně učiněna pro jejich omezení.

Odpor ze strany managementu
Odpor ze strany managementu je poněkud řidčeji se vyskytující, avšak závažnější odnoží problematiky popsané v předchozím bodě. Závažnější je proto, že firemní management má nemalé rozhodovací kompetence a často i autoritu ve firmě. Tato situace může nastat, pokud byla podceněna interní osvěta o užitečnosti používání IS v oblasti HR a to ještě před zahájením implementačních prací, dále pokud je management "přinucen" vlastníky či jiným strategickým partnerem pořídit nový IS, zatímco oni dosud preferovali jiné řešení a dále pokud je management nedostatečně "počítačově gramotný" a není přesvědčen o efektivnosti používání IT ve firemní práci.

Řešení této situace je značně delikátní záležitost, která bude patrně stát dodavatele nemalé úsilí a mravenčí diplomatické práce.

Vrcholovému managementu firem se jen velmi těžko cokoliv nařizuje, na rozdíl od skupiny uživatelů. Naklonění managementu na stranu "příznivců" aplikace IS pro řízení HR je však značně důležitý moment celého projektu..

Důležité je, aby dodavatel získal u zákazníka své spojence z úrovně středního managementu z oblasti personálního řízení a útvarů IT, kteří budou spolu s ním vrcholový management soustavně přesvědčovat o správnosti nastoupeného řešení. Vhodné jsou k tomu např. různé specializované prezentace pro vedení firmy a odborně zaměřené společenské akce.

Nesnáze při převodu dat
Převod dat ze stávajícího SW do nového SW je pro zákazníka jedno z významných rozhodovacích kritérií, zda vůbec změnu SW podstoupit. U rozsáhlejších datových souborů je prakticky nerealizovatelné, že by byla data byla při personálních možnostech zákazníka (pořizovatelé dat jsou současně pracovníci personálních útvarů) pořizována kompletně od základu znovu.

Přes skutečnost, že se většina dodavatelů SW k převodu hlásí, jedná se zpravidla o na míru a na klíč připravovanou operaci nestandardní povahy, která již ve svém technickém principu zakládá možnost vzniku jistých potíží a nepřesností.

Značné eliminace pozdějšího rozčarování z výsledku převodu lze dosáhnout přesným zdokumentováním převáděných dat v implementační studii, kdy na jedné straně se dodavatel zavazuje, že převede dohodnutá data a zákazník na straně druhé později nemůže reklamovat, že určitý rozsah dat převeden nebyl. Pokud se ponechá vše pouze na rámcové dohodě či dokonce ústním příslibu je založeno na velmi pravděpodobné nedorozumění a několikakolové opravování prvotního převodu.

Ve specifikaci, která je součástí implementační studie je nutné dohodnout minimálně

· zda bude převod jednorázový nebo opakovaný
· odkud a kam se bude převádět
· původní a nový datový formát
· specifikace nepřeváděných dat
· speciality převodu

Je praxí ověřeno, že čím detailněji se podařilo oběma stranám specifikovat parametry převodu, tím méně nesnází se objevilo po jeho provedení. Zákazník musí být vždy připraven na skutečnost, že jistou část dat bude muset pořizovat "ručně" a to většinou ze těchto příčin:

· formát originálu je natolik odlišný od formátu nové položky, že převod by vykazoval neúnosné množství chyb,
· data originálu byla vyplňována nesystematicky a nekorektně - nový systém by pak byl zatížen nežádoucími relikty nekvalitní minulé práce pracovníků zákazníka,
· nový IS obsahuje takové datové položky, které nevykazoval systém předchozí - jedná se o častý případ.

Zhruba takto omezenou množinu dat bude muset zákazník, bude-li mít na nich zájem, pořídit jiným než automatizovaným způsobem. I v tomto případě je nanejvýš vhodné pokud se obě strany předem dohodnou na specifikaci této "problémové" části dat a příslušní odborníci na straně dodavatele posoudí objem práce, který ještě bude zákazníka čekat.

Potíže při spolupráci s jinými IS
Jak již bylo dříve naznačeno, očekává se od informačního systému pro řízení lidských zdrojů, že bude bezproblémově koexistovat a komunikovat s jinými informačními systémy a programovými (systémovými) platformami u zákazníka. Pojmy koexistovat a komunikovat si můžeme velmi zjednodušeně vyložit tak, že očekáváme:

· IS nebude svým síťovým provozem narušovat chod jiných zákazníkových aplikací a naopak
· IS bude poskytovat jako výstup požadovaný objem a formát dat pro např. vnitřní ekonomický IS (účetnictví) i pro systémy externích subjektů (peněžní ústavy, státní správa apod.)
· IS bude umět zpracovat vstup dat z interních i externích systémů (např. SW pro evidenci docházky, evidenci stravování apod.)

Již z této povrchní specifikace je zřejmé, že se jedná o poměrně složitou úlohu, jejíž řešení ex post nemusí vést vždy k úspěchu.

Praxe dokonce ukázala, že při nedostatečné předchozí specifikaci očekávané spolupráce s jinými IS, byly pozdější zásahy provázeny jednak značnými objemy analytických, konzultantských a technických prací a v některých případech dokonce i dalšími vynucenými investicemi do HW a SW.

I v tomto případě platí, že dokonalá prevence (detailní popis a analýza možných problémů) ještě před započetím implementačních prací, je nutnou podmínkou eliminace budoucích potíží.

Vlivy konkurence
Poslední okruh problémů, které ovlivňují nebo se čas od času objevují při implementačních pracích je povahy spíše psychologického ovlivňování podvědomí realizačního týmu a managementu zákazníka.

V extrémním případě může vliv konkurenčních dodavatelů působit jako silný demotivační faktor. Vlivy takto působících faktorů se navíc jen velmi těžko odstraňují.

Přijmeme -li premisu, že konkurence nikdy nespí, pak je nutno vzít na vědomí, že i po uzavření obchodní smlouvy na dodávku IS, bude kolem zákazníka stále kroužit "neúspěšná" i jiná konkurence a všemi dostupnými prostředky monitorovat, jak si kontrahovaný dodavatel vede a čekat na jeho klopýtnutí.

Rovněž je nutno kalkulovat s tím, že i na straně zákazníka (často i mezi členy realizačního jeho týmu) jsou víceméně přívrženci IS jiného dodavatele, neboť v době výběrového řízení "hlasovali" pro jiné řešení a jejich postoj byl v té době tudíž zcela legitimní.

Je tedy zejména úlohou managementu zákazníka vysvětlit svým zaměstnancům, že bylo učiněno strategické rozhodnutí (volba IS je strategickým rozhodnutím) a zdůvodnit jej, a že od této chvíle začíná maximálně možný efektivní proces nasazení zvoleného IS, a to pokud možno bez zbytečné nostalgie za tím, co bylo dříve.

Zákazník se může konkurencí inspirovat (tlačit na řešení dodavatele tam, kde je konkurence jednoznačně lepší či diskutovat jakými jinými formami řešit to, co u konkurence existuje odlišného), leč není zcela fair a nepřispívá k dobré atmosféře spolupráce, pokud při každém nezdaru, nedorozumění či nesouhlasu dodavatele se zákazník dovolává konkurenčních firem.