6.1 Implementace ERP a s ní spojený BPR (Bussiness Process Reengineering)
V souvislosti s implementací jakéhokoli podnikového software, ale také v souvislosti s procesním přístupem by bylo ještě vhodné zmínit pojem BPR (Business process reengineering)
Jak již bylo nastíněno v předešlých kapitolách, BPR se od procesního přístupu k řízení liší v tom smyslu, že BPR je jednorázová optimalizace business procesů, zatímco procesní řízení má kontinuální charakter. Nicméně při implementaci jakéhokoli aplikačního software typu ERP dochází právě k takové nárazové optimalizaci business procesů. Podle slov Vladimíra Prinke z I.F.T.
PROGRES a.s. by BPR mělo v ideálním případě probíhat ještě před implementací ERP. Bohužel se tak většinou neděje a k reengineeringu dochází až v momentě, kdy zákaznická firma implementuje nový software.
K určitým změnám v průběhu procesů zákaznické firmy musí při zavádění customizovat a tím přizpůsobovat stávajícím procesům zákaznické společnosti.
Právě v možnostech parametrizace najdeme mezi konkurenčními produkty na trhu ERP produktů největší rozdíly. Z praxe vyplývá, a je to i logické, že
možnosti parametrizace jsou přímo úměrné velikosti, nebo lépe řečeno
6.2 Procesní p ř ístup v rámci klasických ERP systém ů
Podpora procesního přístupu v rámci jádra klasických ERP systémů, čímž je myšlen ERP systém bez dodatečných nadstaveb a modulů jako například různé pokusy o přilepení workflow systémů nebo business inteligence a s použitím klasické, tedy ne-SOA architektury, spočívá především v tom, že každý takový ERP systém, jak už bylo jednou zmíněno, má v sobě zanesenu jistou představu o průběhu některých standardních business procesů jako například nákup, odbyt, materiálový management, výroba atd.
Záleží obvykle na velikosti, lépe na komplexnosti, daného řešení, do jaké míry je možné tyto částečně předdefinované procesy upravovat podle potřeb vlastníka systému. Samozřejmě platí přímá úměra mezi velikostí, komplexností a cenou na jedné straně a možnostmi správy a zásahů do průběhu procesů. Jednoduše čím menší, méně komplexní a hlavně levnější řešení, tím menší možnost procesy nějakým způsobem upravovat a korigovat.
V předešlé kapitole jsem zmiňoval, že při implementaci dochází k nárazové optimalizaci firemních procesů. Samozřejmě pouze v rozsahu, v jakém to implementovaný software dovoluje. Implementací a BPR však podpora procesního řízení prostřednictvím ERP zdaleka nekončí. Možnosti implementovaného ERP pozměňovat průběh podporovaných procesů se zavedením software nemizí, ale je možné je využívat i během provozu systému.
To umožňuje managementu upravovat podporované procesy podle potřeby.
Aby ovšem došlo k nějaké změně, která bude vést k nějakému zlepšení, musí vzniknout nějaký podnět. Tyto podněty vznikají díky dalším funkcionalitám ERP systémů. Tentokrát máme na mysli funkcionality umožňující sledovat průběh procesů a vyhodnocovat procesy.
Nejčastěji jsou používány statusy procesů, které se v průběhu procesu mění (např. „otevřeno“, „dodáno“, „vyfakturováno“ atd.). To umožňuje sledovat stav, ve kterém se daný proces nachází. Zároveň tento systém také dovoluje selekci a zobrazení pouze těch procesů, které uživatel vidět chce.
V předchozích kapitolách bylo zmíněno, že k procesnímu řízení organizací také patří sledování a správa práv a odpovědností za procesy a za jednotlivé činnosti v rámci procesů. Toho je v ERP systémech, jak o nich přemýšlíme v této kapitole, dosaženo tím, že systém umožňuje uchovávat informace o tom, která činnost byla provedena, kdy byla provedena a kým byla provedena. Dále pak samozřejmě také tím, že je možné nadefinovat přístup uživatelů nebo skupin uživatelů k jednotlivým funkcím nebo datům v systému. V lepším případě je tato problematika řešena tak, že práva jsou definována pro role a teprve tyto role jsou následně přiřazovány konkrétním uživatelům. funkcionalit, které původně nespadaly do standardu prodávaných softwarů, ale
bylo možné je dokoupit. V současnosti jsou tyto nadstavby často součástí definovat, kontrolovat a vyhodnocovat vlastní procesy. Rozsah funkcionalit je opět samozřejmě závislý na kvalitě daného modulu, ale možnost definovat další procesy je pro všechny takovéto nadstavby nebo moduly společná.
Jak už bylo zmíněno, existuje mnoho rozdílů mezi jednotlivými řešeními. Je tu však jeden aspekt, který je dle mého názoru natolik významný, že rozděluje jednotlivá řešení na dvě velké skupiny.
V té první skupině nalezneme takové softwary, které sice umožňují definování vlastních business procesů, jejich řízení a vyhodnocování, ale takto uživatelem nadefinované procesy nejsou fakticky provázány s vlastním systémem. Nově definovaný proces se pak nachází jakoby mimo systém, není v něm integrovaný. Je sice popsán sled činností, ale není vytvořena vazba mezi činností, funkcionalitou systému a daty. Systém tedy není schopen sám ověřit například to, jeli činnost se statusem „hotovo“ skutečně provedena či nikoli.
Pověřený uživatel provede požadovanou činnost a pak nastaví ručně status této činnosti, čímž dá impuls k dalším krokům. Kontrola, jestli stav procesu odpovídá skutečnosti, je prováděna manuálně. Typický příklad takového řešení je níže zmíněný „Workflow Management“ systému b2industry.
V druhém případě jsou nově nadefinované procesy provázané s vlastním systémem a jeho funkcionalitami. Stav procesu odpovídá skutečnosti, protože statusy jednotlivých činností nejsou zadávány uživateli, ale mění je sám systém podle aktuálních dat. Např. status vyřízení činnosti „založit díl XXXXX“ je nastaven na „hotovo“ až v momentě, kdy v datové tabulce číselníku dílů existuje záznam o dílu s názvem „XXXXX“. Toto provázání je poměrně do velké míry limitováno právě architekturou software. Zmiňovaná SOA architektura vytváří díky možnosti skládání jednotlivých komponent prostor pro takto koncipované workflow systémy, moduly a nadstavby. Možnosti takto koncipovaných řešení jsou samozřejmě daleko širší než v předchozím případě.
V předešlých kapitolách byly nastíněny požadavky na kvalitní workflow systémy. Další rozdíly mezi jednotlivými ERP řešeními spočívají v tom, kolika z těchto požadavků vyhovují.