Zavádění informačních systémů a motivace personálu

Asi každá firma už někdy zažila situace, kdy se zavádí nějaký informační systém, pro který hoří management, avšak zaměstnanci jsou nadšeni podstatně méně. A řada firem se v praxi potkala s tím, že zavádění různých systémů narazilo na více nebo méně manifestovaný odpor. Někdy zaměstnanci byli pouze pasivní a pro nový systém nehořeli nadšením, jindy se odmítali aktivně podílet na jeho návrhu a konstrukci a pak byli nespokojeni s výslednou podobou.

Výjimkou však nejsou ani situace, kdy zaměstnanci nejenže odmítli aktivně nový systém přijmout, ale hledali cestu, jak se mu vyhnout, a kde to šlo, setrvávali u starého.

Uživatel není okrajový problém

Systém – ať už je to jednoúčelový softwarový nástroj, skladový, či logistický program, účetní aplikace, CRM, či komplexní ERP, či SAP, nebo něco mu podobného, je pracovní pomůcka. Její využívání vyžaduje čas a úsilí, uživatelé se ho musí naučit a musí ho akceptovat. Zavádění takového systému, nebo dokonce jeho změna, přechod firmy z jednoho na jiný je pro každou firmu náročný a komplikovaný proces.

Fakt, že systém má své uživatele, bývá z pohledu implementátorů většinou jen okrajový problém, protože se počítá s tím, že poté, co se lidé naučí systém používat, jej budou automaticky akceptovat. Přitom právě uživatelé – zaměstnanci – jsou nejčastěji zdrojem problémů při implementaci systémů, a jak varovné příklady ukazují, také velmi častou příčinou selhání nového systému. Protože software funguje, jak má, ale lidé jej odmítnou akceptovat.

Z výše uvedeného vyplývá, že motivování personálu je klíčovým faktorem úspěchu při zavádění jakéhokoli systému. Nestačí jej lidem předložit s tím obligátním „Tady to máte!“ Pak proškolit a doufat, že budou stoprocentně používat. Tato cesta je hazardem vedoucím k selhání. Jak tedy zapojit zaměstnance do zavádění nového systému?

Jak zajistit, aby se při jeho zavádění stali přirozenou součástí? Popišme si ideální postup.

Dříve, než začnete

Pokud ve firmě padne rozhodnutí o zavedení nového IT nástroje, předchází mu obvykle analýza potřeb. Tato analýza by již měla zahrnovat ty, kteří s případným novým systémem budou pracovat. Budoucích uživatelů bychom se měli ptát, co potřebují, co by mělo být jinak (v případě, že měníme starší systém za nový) či jak jej vytvořit tak, aby jim při práci co nejméně vadil (pokud doplňujeme nový systém do stávajících procesů).

Lidem je také třeba dávat jasně najevo, že případný nový systém bude uzpůsoben jejich práci a potřebám a hlavně že firma – stejně jako dodavatel – naslouchá jejich názorům.

Vývoj a implementace

Pokud už jsme se rozhodli pro zavedení systému, měli bychom o něm začít mluvit s budoucími uživateli. Jde-li o sektorovou pomůcku, pak s příslušnými zaměstnanci, pokud celofiremní systém, pak se všemi.

Zaměstnancům by mělo být jasně řečeno, že se management rozhodl pro nový systém, měli by znát termín, ke kterému bude zaváděn, a mělo by jim být opět sděleno i to, že bude zaváděn tak, aby jim sloužil. I když tato informace patrně nebude úplně příjemná, překonat implementační odpor pomůže, pokud budou mít lidé jistotu, že takováto změna proběhne.

V rámci vývoje a testování systému bychom měli následně sbírat zpětnou vazbu. Především ty části systému, s nimiž budou lidé v každodenním kontaktu, by měly být co nejvíce intuitivní a přátelské. I když se softwarové firmy snaží tvořit uživatelská rozhraní ergonomicky, měli bychom si uvědomit, že tuto činnost jim nemůžeme plně delegovat a že poté, co bude systém zaveden, budeme pravděpodobně čelit značné neochotě na něm cokoli měnit.

Proto je potřeba, aby vývoj probíhal skutečně ve spolupráci. Velmi osvědčenou cestou je, když mezi zaměstnanci vybereme konkrétní jednotlivce, kteří budou sloužit jako testeři a současně sběratelé zpětné vazby ostatních.

V průběhu implementace systémů často dochází ke stavu, kdy lidé pracují s takzvanou zdvojenou agendou. V praxi to znamená, že jedna činnost je vykonávána ve starém i v novém systému, případně elektronicky a papírově. Je to velmi náročné období, a proto zaměstnanci, které změna postihne, by měli dostat odměnu.

Současně by toto období mělo trvat jen tak dlouho, jak je to nezbytně nutné. Vedle odměny je ale nutná důsledná kontrola, protože zvláště v případě, kdy se toto období protahuje, nastává často situace, kdy lidé mají pocit, že se dělají věci zbytečně.

Den změny

I když moderní softwarový vývoj a implementace se spíše snaží vyhýbat principu tlustých čar za minulostí, v praxi nastane okamžik, kdy musíme zcela opustit starý systém a nahradit jej novým, či kdy je použití nového pro všechny dotčené zaměstnance povinné. Tento moment by měl být jasně definován, stojí za to spojit i jej s malou odměnou.

Musíme se ujistit, že nejpozději k němu jsou skutečně všichni proškoleni, a hlavně že existuje systém uživatelské podpory, na který se kdokoli může obrátit v případě, že něco nebude fungovat. Nikdy nespoléhejme na to, že lidé „si nějak poradí“.

V praxi se osvědčilo, když na každém pracovišti existuje jeden nebo několik pokročilých uživatelů, kteří výměnou za vhodnou odměnu či benefit pomáhají všem ostatním, přinejmenším po nějakou dobu.

Jakmile se nový systém stane naostro fungujícím, je potřeba se zbavit starého. Existují určité přísně vymezené situace, kdy je z motivačního hlediska výhodnější nechat zaměstnancům alespoň iluzi toho, že je možné se ještě vrátit k předchozímu systému, ale v naprosté většině případů to nedoporučujeme.

Odpor a řešení

Zaměstnancům bychom používání nového systému v době, kdy již je zaveden, měli maximálně zjednodušit a zpříjemnit. Měli by být součástí jeho vývoje i testování, měli by mít příležitost se k němu pravidelně vyjadřovat, měli by mít k dispozici podporu, která jim pomůže, když cokoli nefunguje, a měli by za jeho úspěšné zvládnutí dostat odměnu. I tak se ale může stát, že se někteří obrátí proti němu. V praxi existují tři strategie.

První je pasivita. Zaměstnanec nový systém jednoduše ignoruje, pokud má možnost, používá předchozí, a je-li mu to vytýkáno, vymlouvá se na dlouhou řadu rádoby objektivních důvodů.

Druhou obrannou strategií je švejkování. Zaměstnanci systém používají, ale tak, aby důsledkem byl pravý opak jeho účelu. Neplní v něm úkoly, zadávají nesprávná data, poukazují na chyby, a i když říkají, že dělají vše, co se od nich chce, realita vypadá jinak.

Třetí strategií, nejvzácnější a nejnebezpečnější, je otevřený odpor. Uživatelé řeknou, že systém nebudou respektovat. Většinou argumentují pracovním vytížením, nepotřebností, neužitečností, nebo dokonce bezpečností. Někdy mají na své straně odbory nebo jiného silového hráče.

Nejlepší obranou proti pasivitě je nesnažit se o konfrontaci, ale vytipovat ty uživatele, kteří se novému systému brání nejméně, a aktivně je zapojit do stimulace ostatních. Měli by ukázat, že má smysl, je užitečný a funguje. Pokud můžeme, přidejme přímo do systému Honey pot, tedy funkci, kterou lidé skutečně chtějí. To je donutí jej začít používat. Postupem času se přidají i ti méně motivovaní a nakonec všichni.

Pokud čelíme švejkování, je možnou cestou omezení funkcionality nového systému na nezbytné minimum a následně sice pozitivní, avšak velmi důsledná kontrola toho, že se nový systém skutečně naučili. Školení, ověřování, stínování, kontrola a benchmarking jsou naše cesty. Ty, kteří přistoupí na používání a budou konstruktivní, odměníme, a jakmile se nám takto povede přimět většinu, rozšíříme funkcionalitu.

Otevřený odpor nemá řešení, které by šlo nabídnout univerzálně, ale zejména pokud mají zaměstnanci na své straně onoho silového hráče, je potřeba ho dostat na naši stranu. Nejosvědčenější cestou není konfrontace, ale navázání dialogu.

Rozum, cit a asistence

Nejlepší a v důsledku nejlacinější cestou, jak implementovat nový systém po personální stránce, je již od samotného začátku počítat s lidmi. Mnoho manažerů se domnívá, a někdy v tom bývají dodavateli utvrzováni, že toto je práce dodavatele systému, ale pro mnoho softwarových dodavatelů není motivace uživatelů tématem, protože počítají s tím, že budou dobrovolně a zcela automaticky spolupracovat.

Jednoznačné doporučení proto zní: zapojte do implementace od samotného začátku také HR oddělení, personálního manažera nebo odborného poradce.

Převzato z časopisu Komora. Autor článku: Vojtěch Bednář