Hovoříme o nástrojích v množném čísle mimo jiné proto, že k plnému využití koncepce BPM je zapotřebí pokrýt celý životní cyklus práce s procesem:

• Návrh a modelování procesu – procesy musí být popsány, a to ideálně tak, aby jim rozuměli nejen lidé s technickou znalostí a specializovaní konzultanti. Důležitá je také možnost simulace, která ukáže, jaké dopady by měly různé změny na jednotlivé části procesu.
• Správa informací o procesech – mělo by existovat jednotné úložiště, kde jsou soustředěny aktuální informace o všech procesech a o vztazích mezi nimi.
• Propojení popisu procesu do IT podpory – popis procesu má být možné snadno převést v technologické požadavky na informační systémy, nebo přímo přimět informační systémy, aby tento proces začaly podporovat či vykonávat.
• Monitorování a analýza procesu – nástroje umožní sledovat průběh jednotlivých instancí procesu (například vyřizování jednotlivých objednávek) napříč infrastrukturou. Vidět odezvy informačních systémů a odezvy lidí. Zjišťovat, kde vznikají fronty, a kde jsou naopak nevyužité kapacity.
• Optimalizace – tím se dostáváme znovu k návrhu a modelování procesu, čímž se kruh uzavírá.

Při zaměření na procesy by nemělo uniknout, že je nasazován IT produkt, jehož bezchybné fungování bude pro firmu důležité, a že produkt musí pokrýt veškeré požadavky a potřebné komponenty architektury. Musí zajistit přehledné rozhraní pro administrátory, uživatelsky přívětivé manažerské rozhraní, nástroje pro podporu spolupráce a knowledge base pro sdílení poznatků, zkušeností a již pokrytých procesů. To vše ideálně v rámci uživatelského portálu s řízenými přístupy. Musí poskytovat nástroje pro relativně snadnou integraci. U BPM produktů je také podstatné, aby byly „SOA ready“, protože kombinace SOA–BPM většinou urychluje návratnost (toho jsme se dotkli již v minulém článku v IT Systems 4/2012). U některých technických rysů, bez jejichž zajištění nebude nasazení BPM úspěšné, se na chvíli zastavíme.

Škálovatelnost, vysoká dostupnost a výkonnost

BPM produkty musí být natolik škálovatelné, aby si dokázaly poradit s přibývajícími a měnícími se požadavky obchodních nebo výrobních útvarů. Dalším klíčovým rysem musí být vysoká dostupnost. Pokud by došlo k výpadku BPM, organizace nemůže pokračovat v činnosti, nebo se objeví nekonzistence mezi definovanými procesy a skutečným životem organizace. Výkonnost je důležitá, protože má přímý dopad na produktivitu práce zaměstnanců.
Dobré produkty proto důsledně respektují standardy pro vytváření serverových aplikací, zejména J2EE. Velmi důležitá je také podpora clusterového uspořádání, což umožní provozovat systém na skupině serverů. Pokud kterýkoliv z nich vypadne, bude okamžitě nahrazen, takže dostupnost nebude omezena. Pokud vzroste zatížení, do clusteru se prostě zapojí další stroj a růst požadavků nebude mít dopad na výkonnost.
Vysoká výkonnost zpravidla souvisí s důslednou optimalizací skutečně každého aspektu a každé komponenty BPM systému: databázového provozu, řízení událostí, řízení uživatelských sezení (komunikace uživatelů s procesy), zpracování úkolů i API rozhraní mezi komponentami. Není proto náhoda, že špičkové BPM produkty mají za sebou řádově deset let vývoje. Chcete-li dotáhnout vnitřní architekturu produktu k dokonalosti, vyžádá si to čas a zdroje.

Datová architektura

Dalším rysem, kterým se odlišují dobré BPM nástroje od těch druhořadých, je práce s daty. Vycházejí totiž z vědomí, že jsou důležité nejen procesy, ale také informace, jak to vyjadřuje koncept IPT (Information and Process Technology), který vyžaduje, aby produkty byly schopné pracovat s procesy i s informacemi a aby byly schopné využívat synergie mezi těmito oblastmi.
Když je definován sled procesních kroků, je zároveň také definován tok informací. Datové elementy mohou být zpřístupněny všem instancím procesu a všem procesním krokům nebo jednotlivému kroku v procesu. Mohou být uchovávány po dobu výkonu jedné instance procesu, nebo trvale jako součást informací o procesu. Jedná-li se o externí data, mohou být pro výkon procesu dostupná, ale není zapotřebí řešit jejich ukládání. Proto bývá součástí BPM řešení systém pro jednotné řízení datových typů, který je schopen zajistit jak jejich integritu, tak optimální způsob ukládání.

Agregace i granularita

Uživatelům by mělo být umožněno, aby pracovali s většími agregacemi dat, jako jsou objekty, dokumenty nebo XML soubory. Přesto musí systém podporovat granularitu dat, protože se tím významně zvyšuje výkonnost. Architektura musí také zajistit, že vytváření reportů nebude mít dopad na výkonnost a rychlost odezvy systému. Toho lze dosáhnout pečlivým řízením informací v řídicích a reportovacích tabulkách. Tyto tabulky by měly existovat samostatně pro každý proces, aby při nasazení nového procesu nedocházelo ke kolizím.

Taková architektura pak umožňuje bez problémů zpracovávat miliony instancí různých procesů zároveň. Spojení jemné granularity a optimalizace totiž znamená, že informace jsou snadno dostupné a zdroje poskytované prostředím (hardware, operační systémy, databáze) jsou využívány maximálně efektivně. Zároveň to umožní zajistit integritu informace během celého životního cyklu, čemuž mohou napomoci logické kontroly a kontroly konsistence, jaké jsou v pokročilých BPM řešeních vestavěny.

Otevřená architektura

BPM řešení bude důležitou součástí podnikové informatiky, ale rozhodně nebude součástí jedinou ani izolovanou. Optimálně by mělo být použito jako nástroj procesní integrace (izolovaných) informačních zdrojů. To znamená, že BPM produkty musí umožňovat snadnou spolupráci a integraci s dalšími informačními systémy v organizaci.
Pochopitelně, pokud je BPM založeno na proprietárních technologiích a vlastních formátech, integrace bude velmi obtížná. Pro organizaci to bude znamenat, že nedokáže využít synergie mezi dosavadními dovednostmi a zdroji, procesními řešeními a informacemi v BPM nástroji.
Proto pokročilé BPM nástroje nabízejí kompletní sadu API rozhraní v Java standardu a webové služby, které umožní společně používat v zásadě jakoukoliv funkcionalitu. Otevřená architektura založená na standardech také vede ke snížení celkových nákladů vlastnictví.

Nízké celkové náklady vlastnictví

Jedním z klíčových důvodů, proč podniky nasazují BPM, je snižování nákladů. Je důležité, aby tuto úsporu nepohltily náklady na BPM. Celkové náklady vlastnictví mají u BPM, stejně jako u jiných IT produktů, mnoho složek. Některé jsou jednorázové a jiné se periodicky opakují. Mají-li být celkové náklady vlastnictví nízké, je zejména důležité udržet na minimální úrovni opakující se položky.
V případě BPM bývají těmito opakujícími se náklady zejména:

• správa řešení,
• systémové zdroje potřebné pro realizaci zvyšujícího se počtu pokrytých procesů,
• čas zaměstnanců potřebný pro vybudování řešení,
• náklady na vylepšování a rozšiřování nasazení,
• migrace na vyšší verze.

Proto je součástí pokročilých BPM řešení takový administrátorský portál, který umožňuje systém snadno spravovat a řídit, například poskytuje nástroje pro migraci stávajících procesů do nové verze produktu.
Ve druhé části tohoto článku se k požadovaným vlastnostem BPM nástrojů vrátíme a ukážeme, jak jich mohou organizace využít.

Jiří Gregor
Autor je předsedou představenstva společnosti Galeos.