Přihlášení ERP news



Přihlaste se k odběru newsletteru ERP news, ve kterém pravidelně rozesíláme ty nejzajímavější články ze světa ERP.



Partneři webu

Jak správně definovat firemní požadavky na informační systém (seriál 2.díl)

Pondělí, 10 Leden 2011 15:30

2.dilserial01Středem pozornosti je při implementaci nového informačního systému vlastní realizační fáze obsahující zavádění a nastavování aplikace, ostatní fáze jsou mnohdy podceňovány a zjednodušovány. Pokud má firma definovat, co od budoucího nástroje bude požadovat, sklouzne často pouze k obecným formulacím typu „potřebujeme účetnictví, jsme standardní firma“. Tento přístup ovšem vede pouze k tomu, že při následné fázi výběru pomyslným sítem projde široký pelmel systémů a aplikací, které poskytují velký rozsah funkcionality. Z toho se pak odvíjí i cena těchto systémů a fáze výběru je pak záležitostí několika kol, řady týdnů či měsíců. Následně i po ukončení výběru zůstane v mnohých manažerech či klíčových zaměstnancích špatný pocit, zda opravdu zvolený systém je správnou volbou.

Úvodní fáze celého procesu je jednou z nejdůležitějších, na jejím zvládnutí závisí finální volba produktu. Managementu firmy dává tato fáze prostor k uspořádání svých představ a očekávání, co má informační systém pro potřeby společnosti plnit. Jak lze tedy tuto fázi absolvovat z pohledu firmy úspěšně?

 

Důležitým prvním krokem je stanovení odpovědné osoby za tvorbu zadání (vedoucího projektu) a definice pracovního týmu. Vedoucí projektu nemusí být nutně osoba z managementu firmy, pro správný průběh je ovšem nutné vytvořit „komunikační kanál na management“. Složení pracovního týmu bude záviset na celkovém rozsahu procesů a činností, které bude budoucí systém pokrývat. Pro každou oblast/proces společnost definuje klíčového zaměstnance (garanta), který je pak odpovědný za definování požadavků a který dle potřeby zajistí komunikaci dovnitř společnosti. Pro efektivní fungování je nutné udržet pracovní tým v rozumném rozsahu 6 až 10 lidí.

 

Hlavní úskalí tvorby zadání:

 

  • tvorbě zadání je potřeba věnovat dostatečný čas
  • do tvorby zadání je potřeba zapojit management firmy a znát jejich požadavky na systém
  • systém nebude existovat samostatně „v prostoru“, musí být začleněn do firemního prostředí
  • i v případě obměny informačního systému je nutné posoudit požadavky na danou funkcionalitu, argument „nyní to v IS máme“ je nedostatečný
  • snažte se provést rozumnou korekci množství požadavků na systém, dle zkušeností je většina systémů využívána jen z 30-50% svých možností, v budoucnu nevyužitá funkcionalita vás může stát nemalé peníze
  • součástí zadání by mělo být stanovení přínosů

 

Častým problém bývá opomenutí některých oblastí, jejichž zástupci v pracovním týmu často chybějí a jejich „požadavky“ se řeší až v průběhu implementace a to včetně všech návazných komplikací, které díky tomu vznikají. Jednou z nich jsou požadavky managementu, především v oblasti reportingu. Pokud se chcete vyvarovat následných komplikací, je potřeba při tvorbě zadaní stanovit i představu managementu o výstupech, které budou požadovat. Jedná se především o analytické a statistické reporty, případně různé stavové informace. Pokud je s těmito požadavky počítáno již v úvodu, je možné „bezproblémově“ připravit patřičnou strukturu dat a celé výstupy maximálně automatizovat. V opačném případě mohou následné požadavky znamenat celou řadu „ručních“ vstupů či úprav, o efektivní využívání systému v takovém případě nemůže být řeč.

 

Další z oblastí, která je často z úvodních diskusí vynechána nebo je řešena jen částečně, je vlastní oblast IT. Ve většině případů je tato oblast vyřešena stanovením základních technických podmínek pro provoz systému - serverová část, HW požadavky, typ a verze databázového serveru, operační systém na pracovních stanicích. Pod oblastí IT je ale potřeba řešit také celkové začlenění informačního systému do firemní infrastruktury. Je potřeba zvážit, jaké stávající systémy budou s novým nástrojem komunikovat a pro které bude potřeba vytvořit či modifikovat datová rozhraní. Součástí zadání musí být informace o využívaných standardních SW nástrojích, jako je typ a verze kancelářského balíku, jaký produkt firma využívá pro firemní emailovou komunikaci. V celé řadě projektů opomenutí těchto zdánlivě samozřejmých či jednoduchých věcí následně generuje vyvolané investice, jako je např. vynucená obměna kancelářského balíku na aktuální verzi.

 

 

2.dilserial02

 

Garanti za danou oblast v průběhu tvorby zadání zajišťují sběr dílčích informací a komunikaci uvnitř firmy, jejich hlavním úkolem je ovšem vytvoření a sumarizace požadavků. Velký důraz je nutno klást na stanovení důležitosti u jednotlivých požadovaných funkcionalit a stanovit přínosy jejich nasazení. Součástí by měla být stručná charakteristika činnosti a požadované výstupy.

 

Zakončením první fáze je vytvoření finální verze zadání. Pro tuto činnost je potřeba zajistit účast management firmy, který společně s vedoucím projektu a garanty projde sumarizované požadavky z jednotlivých oblastí. Snahou by mělo být udržet rozumný rozsah požadavků a posoudit, co všechno opravdu společnost od systému požaduje. Společnost často platí za funkcionalitu, která se pak v mnoha případech nevyužívá, nebo generuje výstupy „do šuplíku“. Účast managementu je vhodná z několika důvodů. Prvním je získání jasného povědomí ze strany managementu, co všechno firma od systému požaduje a možnost se k těmto požadavkům vyjádřit. Dále pak je možné za účasti vedení provést rozhodnutí o požadavcích, které nebyl schopen rozhodnout garant za danou oblast, např. z důvodu vazby na jiné požadavky, oblasti. V neposlední řadě pak účast managementu na tvorbě zadání dává jasný signál do firmy o důležitosti projektu a vytváří tak dobré podmínky pro následnou realizaci projektu.

 

Takto vytvořené zadání bude vstupním podkladem pro provedení výběru informačního systému, tato fáze bude probrána v následujícím pokračování tohoto seriálu.

Pavel Rek
Autor působí ve společnosti Infotea

 

 

 


 
další články o ERP

Na co se zaměřit při výběru ERP?

 

Výmluvy, proč nový ERP "nefunguje"

 

Proč neodkládat inovaci ERP