Hlavní práce4314_xhofa04.pdf, 1.7 MB Stáhnout

Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

Katedra systémové analýzy

Student : Albert Höfer

Vedoucí bakalářské práce : doc. Ing. Vlasta Svatá, CSc.

TÉMA BAKALÁŘSKÉ PRÁCE

Procesní p ř ístup k ř ízení organizací a jeho podpora v ERP systémech

ROK : 2006

Prohlášení

Prohlašuji, že jsem bakalářskou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).

V Praze dne ………. ... ...

podpis

Poděkování:

Tímto bych chtěl poděkovat doc. Ing. Vlasta Svaté, CSc. za její ochotu a pomoc, kterou mi poskytla během tvorby mé bakalářské práce.

Albert Höfer

1 Abstrakt

V této práci se autor zabývá procesním řízením organizací a podporou tohoto přístupu v podnikových systémech typu ERP (Enterprise Resource Planning).

Autor si klade za cíle stručně charakterizovat současnou situaci procesního řízení na poli IS/ICT, poukázat na požadované vlastnosti ERP řešení vyplývající z procesního přístupu, přiblížením možností a funkcionalit dvou ERP řešení z různých kategorií (b2industry - pro malé a střední podniky, mySAP ERP – pro střední a velké podniky) názorně demonstrovat zohlednění zmíněných požadavků v praxi a porovnáním zjištěných vlastností ukázat na rozdíly v podpoře procesního přístupu mezi jednotlivými ERP systémy.

Z práce je patrné, že na trhu lze nalézt jak velmi kvalitní řešení, která jsou ve velké míře ovlivněna myšlenkami procesního řízení, tak řešení, která stále ještě vycházejí ze starých koncepcí a podpora procesního řízení je u takových řešení značně omezená. Z toho také vyplývá druhý závěr, že lze nalézt markantní rozdíly mezi dvěma podnikovými systémy typu ERP především pak ve vyšších funkcionalitách podpory procesního přístupu. Část funkcionalit souvisejících s podporou procesního řízení v produktu b2industry je rozepsána do větší podrobnosti, aby byla vidět nedokonalost tohoto řešení.

2 Obsah

1 ABSTRAKT 4

2 OBSAH 5

3 ÚVOD 7

PROCESNÍ ŘÍZENÍ 9

3.1CO JE TO PROCESNÍ ŘÍZENÍ 9

3.2PROCESNÍ MODEL 11

3.2.1 BUSINESS PROCES MODELING NOTATION 13

3.2.2 BUSINESS PROCESS EXECUTABLE LANGUAGE 14

3.3NEVÝHODY PROCESNÍHO ŘÍZENÍ 16

4 SERVICE-ORIENTED ARCHITECTURE (SOA) 16

4.1CO JE PŘESNĚSOA 17

4.2VLASTNOSTI SOA 19

4.3IMPLEMENTACE SOA 20

4.4PŘÍNOSY SOA 21

4.5NEVÝHODY SOA 22

5 WORKFLOW SYSTÉMY 22

6 IMPLEMENTACE FUNKCIONALIT PROCESNÍHO PŘÍSTUPU V ERP 25

6.1IMPLEMENTACE ERP A SNÍ SPOJENÝ BPR(BUSSINESS PROCESS REENGINEERING) 25 6.2PROCESNÍ PŘÍSTUP VRÁMCI KLASICKÝCH ERP SYSTÉMŮ 26

6.3PODPORA PŘ VPODOBĚ NADSTAVEB/MODULŮ 27

7 PODPORA PROCESNÍHO ŘÍZENÍ V ERP B2INDUSTRY 29

7.1SAGEBÄURER A JEHO B2INDUSTRY GENERATION 5.0 29 7.2PROCESNÍ ŘÍZENÍ VB2INDUSTRY – ZÁKLADNÍ FUNKCIONALITY 30

7.2.1 KALKULACE 30

7.2.2 SIMULACE 31

7.2.3 PRŮBĚH HLAVNÍHO PROCESU 31

7.3MODUL „WORKFLOW MANAGEMENT“ VB2INDUSTRY 34

7.3.1 OBECNÁ NASTAVENÍ (BV958000) 34

7.3.2 SPOOL AKTIVIT (BV95800) 35

7.3.3 SESKUPOVÁNÍ AKTIVIT (BV95805) 36

7.3.4 SPOOL AKCÍ (BV95804) 37

7.3.5 DEFINOVÁNÍ ŠABLON (BV958100) 38

7.3.6 POLOŽKY ŠABLON (BV958110) 39

7.3.7 PROCESY, ŠABLONY – GRAFIKA (BA958110) 40

7.3.8 TISK PRŮVODKY (BJ958100) 41

7.3.9 SESKUPOVÁNÍ PROCESŮ, ŠABLON (BV958103) 41

7.3.10 SPUSTIT PROCES (BV958120) 42

7.3.11 P^ŘEHLED PROCESŮ(BE958100) 43

7.3.12 ZPĚTNÉ HLÁŠENÍ – GRAFIKA 44

7.3.13 ZPĚTNÁ HLÁŠENÍ AKTIVIT PROCESU (BV958130) 44

7.3.14 TERMÍNOVÁNÍ WORKFLOW 45

8 PODPORA PROCESNÍHO ŘÍZENÍ V SAP 45

8.1O SPOLEČNOSTI SAP 45

8.2PLATFORMA SAPNETWEAVER 46

9 ZÁVĚR 49

10 LITERATURA 52

11 SEZNAM OBRÁZKŮ 53

12 PŘÍLOHY 54

3 Úvod

Stále rychlejší podnikatelské prostředí vytváří veliký tlak na přizpůsobivost ekonomických subjektů. Firmy se musí vyrovnávat stále častěji se změnami a reagovat dostatečně rychle z důvodu zachování konkurenceschopnosti. Právě v oblasti přizpůsobování se změnám a měnícím se požadavkům naráží mnoho podniků na hranice možností, které jim poskytuje dosavadní způsob řízení. Díky tomuto vývoji se v posledních letech velmi často hovoří o problematice procesního řízení, které by mělo být řešením stávající situace mnoha podniků, a přechodu od funkčního řízení k procesnímu. Neočekává se, že by tento zájem nebo tendence měla v brzké době polevit.

Vzhledem k faktu, že řízení podniku poměrně úzce souvisí s jeho informačním systémem, promítá se tento přístup k řízení i do informačních systémů. Pro správné fungování firmy by měl IS/ICT poskytovat dostatečnou podporu používaného přístupu k řízení. Tato práce se zabývá právě podporou procesního řízení prostřednictvím IS/ICT a zaměřuje se konkrétně na oblast podnikových systémů typu ERP (Enterprise Resource Planning).

Vzhledem k tomu, že jde o velmi složitou problematiku, část práce stručně charakterizuje i vybrané aspekty s hlavním tématem související (například softwarovou architekturu SOA, která je pro podporu procesního přístupu prostřednictvím IS/ICT velmi důležitá, standard v oblasti modelování podnikových procesů Business Process Modeling Notation (BPMN) a jazyk Business Process Execution Language (BPEL)).

Cílem práce je ukázat, jaké požadavky by měl software splňovat, aby o něm mohlo být prohlášeno, že dostatečně podporuje procesní přístup k řízení organizací. Následně také názorně ukázat, jak může v podnikových softwarech typu ERP vypadat podpora procesního přístupu ve skutečnosti a jak velké rozdíly mezi jednotlivými ERP řešeními ve smyslu podpory procesního přístupu můžeme nalézt.

Vzhledem k relativně velkému množství ERP produktů na trhu, nebo alespoň produktů, které jsou svými tvůrci označovány jako ERP, a markantní rozdílnosti

nákladů na jejich pořízení a provoz, je možné očekávat, že vzájemná odlišnost jednotlivých řešení nebude v žádném případě zanedbatelná.

Tuto rozdílnost bych chtěl demonstrovat na příkladech dvou podnikových informačních systémů typu ERP. Konkrétně b2industry, který je vyvíjen společností SAGEbäurer a svým rozsahem, komplexností, funkcionalitami a samozřejmě i cenou spadá mezi řešení střední úrovně. Protikladem budou produkty společnosti SAP s platformou SAP NetWeawer, která je základem integračních a procesních přístupů těchto podnikových systémů.

K porovnávání jsem si vybral právě tyto dva produkty, protože jsem působil jako junior consultant řešení b2industry a v současnosti se zabývám produktem společnosti SAP mySAP ERP.

Procesní ř ízení

3.1 Co je to procesní ř ízení

Co je to procesní orientace systému řízení? Čím se liší od funkčního přístupu?

Co přinese nového? Jaký užitek poskytne procesní model? Co všechno se musí udělat, aby mohl fungovat?

Pokud se podíváme do historie tohoto pojmu, nalezneme v literatuře většinou zmínku o tom, že procesní řízení se vyvíjelo ve třech vlnách. První vlna spadá do doby okolo roku 1920 a je s ní spojeno jméno Frederic Winslow Tylor.

Procesy, které byly součástí pracovních postupů, se měly oddělit do samostatných manuálů. Process management byl v té době nazýván „analýza metod a procedur“.

Druhá vlna, která skončila přibližně v minulém desetiletí, předpokládala, že by u procesů měl proběhnout ruční reengineering jako jednorázová akce. V této fázi vývoje procesní orientace s důrazem na BPR působili Champy a Hammer.

Již na začátku 90-tých let tito autoři zdůrazňovali přechod k novému způsobu řízení organizací. Zjednodušeně a tudíž i ostře je tento trend popsán doc.

Řepou takto: „Organizace, aby splňovala nové nároky musí změnit především základní pojetí podstaty svého fungování; za základ musí přestat být považována organizační struktura jako pevně definovaná struktura činností a vztahů, a z toho vyplývající pravomoci, odpovědnosti, komunikační procesy, odměňování, karierní postupy apod. Namísto toho je základem organizace nového typu představa podnikových procesů jako „souboru činností, který vyžaduje jeden či více vstupů a tvoří výstup, jenž předurčuje hodnotu pro zákazníka“ (Hammer 1993). Ale sám Dr. Michael Hammer už v listopadu 1996 ve Wall Street Journal sebekriticky přiznává: „Nebyl jsem dost moudrý ….

Použil jsem inženýrský přístup a nebyl jsem dost citlivý k lidské dimenzi. Ale zjistil jsem , že právě ta je kritická…Narazil jsem na odpor.“

Třetí vlna, o které se hovoří v souvislosti s dnešní situací, by měla nabízet tvorbu podnikových procesů za pochodu. Je už poměrně dost zkušeností z procesního modelování a jsou vytvořeny základní standardy. Jsou už známy

dopady při přechodu na procesní řízení. Nedrží se extrémní pohledy, kdy by ustoupila úplně do pozadí organizační struktura a profese. Rozhodující se stále ukazuje to samé tj. lidská dimenze (převážně motivace lidí a jejich vzdělanost).

Prozatím se ale v organizování vnitřních činností podniků stále používá především funkční řízení vyjadřované pomocí organizačního schématu. Toto schéma zachycuje většinou jenom menší část pracovníků podniku tzv.

pracovníky technicko-hospodářské, kteří tvoří jen asi 10 – 25% osazenstva podniku. Záleží na podrobnosti schématu, ale často v něm není uvažováno s pracovníky dělnických profesí, kteří tvoří poměrně často většinu zaměstnanců podniku.

Organizování tímto funkčním způsobem řeší především otázku dělby práce v podniku, specializaci pracovníků a jejich kompetencí. Mimo to je v organizačním schématu vyjádřen vztah podřízenosti a nadřízenosti mezi jednotlivými pracovníky a organizačními jednotkami. Vzniká mnoho komunikačních a kompetenčních bariér v důsledku ohraničených organizačních jednotek.

Pod pojmem procesní orientace systému řízení bychom si měli představit filozofii řízení, změnu způsobu spolupráce a chování všech (nejdříve řídících) pracovníků ve firmě. Převod zodpovědnosti na správná funkční místa.

Odstranění všech odstranitelných bariér rozvoje a komunikace. Eliminaci všech neproduktivních a zbytečných činností.

Procesní směr v organizování podniků vychází ze skutečnosti, kdy na organizaci nahlížíme jako na systém, který produkuje nějaké výrobky nebo služby, které uspokojují potřebu zákazníků organizace a že každý produkt (výrobek nebo služba) vzniká určitým sledem činností tedy procesem. Tomu je přizpůsoben i nový způsob zobrazování organizačních vztahů pomocí procesního (postupového) diagramu zahrnujícího všechny potřebné činnosti, vazby mezi nimi, jejich souslednost a zodpovědné pracovníky a jejich informační potřeby. Tento způsob organizování také zahrnuje všechny pracovníky, kteří se na procesech podílejí, tedy i dělníky. Snižuje se také potřeba řídící práce, protože pracovníci jsou organizováni mezi sebou a řešení

řady situací je vyznačeno předem. Jsou stanoveny rozhodovací činnosti a pracovníci zodpovědní za jejich řešení.

Požadavkem dnešní doby je pružnost, která by umožnila uspokojit individuální potřeby zákazníka. Cílem podniků se stala maximální přidaná hodnota pro zákazníka s co nejnižšími náklady. Organizaci tedy hodnotíme podle spokojenosti jejich zákazníků a ne podle objemových ukazatelů. Tento princip hodnocení se uplatňuje i uvnitř organizace. Například normotvorný útvar nebudeme hodnotit podle toho, kolik nových norem vyprodukuje, ale podle toho, jak jsou normy použitelné a používané zaměstnanci.

Tohoto je možné dosáhnou právě pomocí procesů, protože čím je proces integrovanější, tím má rychlejší průběh a zákazník může být kvalitněji uspokojen. Procesní řízení tedy vychází z principu integrace práce: sestavit z jednotlivých činností co nejefektivněji probíhající proces za předpokladu, že optimalizace procesů nebude nárazová záležitost jako v případě reengineeringu, ale jedná se o kontinuální činnost zefektivňující podnikové procesy za pochodu. znamená to, že neřešíme např. personální oddělení, ale procesy oblasti personalistiky. Je to rozdíl, protože procesy přecházejí mezi různými organizačními jednotkami a tím, že bychom zasáhli pouze do jedné z nich, bychom mohli celý proces zhoršit.

Abychom mohli procesy optimalizovat, musíme je být schopni nejdříve vyhodnocovat. To nám umožní procesní model a controlling na procesní bázi.

3.2 Procesní model

Procesní model je formalizovaný a pravdivý popis toho, co se ve firmě skutečně děje. Může být základem pro účelný rozvoj (optimalizaci) činností firmy. Díky modelu bude každá změna uspořádání (funkčních míst, pravomocí a odpovědností, materiálových a informačních toků) konzistentní, na žádné důležité souvislosti nebude možno zapomenout. Pomůže odstranit neproduktivní a zbytečné činnosti, eliminovat zjevné neefektivnosti. Umožní

"narovnání" (zrychlení a zefektivnění) původně nepřehledných činností a lepší pochopení nejdůležitějších souvislostí. Definované činnosti jsou nutnou

podmínkou pro to, aby se začal plánovat a měřit výkon každého jednotlivce na reálném a smysluplném základě. Tím, že definujeme materiálové a informační vazby mezi jednotlivými procesy a činnostmi, získáváme dokonalé podklady pro návrh ekonomické struktury firmy - jak a proč budeme sledovat aktiva a pasiva, ale především náklady a výnosy. Hlavním přínosem procesního modelu (vyjma toho, že by měl business analytikům umožnit věcnou optimalizaci podnikových činností) by měla být také definice informačních potřeb. Model určuje místa, kde se měří vstupy a výstupy, kvalita a ostatní parametry. Určuje co, jakým způsobem a v jakých jednotkách se bude sledovat. Vynucuje si zaevidování a zdůvodnění všech pohybů lidí, materiálu a financí. Nedojde k nepřípustnému zjednodušování. Ukáže, že ve skutečnosti je ekonomická efektivnost určována chováním lidí, nikoli čísly ve výkazech a vybídne k nasazení odpovídajících metod motivace.

Z podrobných popisů procesů je možné:

přesně vyčíst hranice procesů v podobě spouštěcích a ukončovacích událostí,

o spouštěcí událost – to co vede k tomu, že se celý proces rozběhne,

o ukončovací událost – nastane-li tato událost, můžeme říct že proces byl dokončen. Ukončovací událost jednoho procesu bývá často spouštěcí událostí jiného procesu,

identifikovat jednotlivé činnosti, které musí být provedeny k tomu, aby byl splněn účel procesu (vše co se musí udělat, abychom mohli říct

„kniha byla vydána“),

zjistit jaká je podpora probíhajících činností z hlediska IT. To znamená jaké systémy se používají – pak lze porovnat s tím co je koupeno a nepoužívá se, lze porovnat zda se neudržuje více licencí, než je skutečných uživatelů. Zjistíme, které činnosti nejsou IT podporovány a mohly by být,

vyčíst jaké dokumenty se používají – pak lze kvalifikovaně optimalizovat jejich množství i obsah podle toho kde se využívají,

vyčíst jaké jsou požadované znalosti, dovednosti a jiné předpoklady pro vykonávání jednotlivých činností. To nám pomůže při personálních změnách,

vyčíst jakými předpisy (tzv. dokumentovanými znalostmi ) je výkon procesu upraven. Tak získáme přehled o používaných normách,

navrhnout ukazatele pro hodnocení účinnosti procesu, procesy měřit a vylepšovat jejich průběh,

vyčíst jaké zdroje proces pro své fungování potřebuje,

vyčíst jaké procesní role se na jednotlivých činnostech procesu podílí, zjistit pro každé funkční místo jaké procesní role zastává a s využitím

předchozí informace vygenerovat popisy náplní práce jednotlivých funkčních míst a ve vazbě na požadované znalosti i kvalifikační předpoklady,

určit kontroly, které zajistí průkaznost a správnost procesu.

Obrázek 1 – Odpovědnost profesí za jednotlivé etapy procesního řízení

3.2.1 Business Proces Modeling Notation

Standardem v oblasti modelování podnikových procesů, zveřejněným v květnu 2004, je Business Process Modeling Notation (BPMN). Jeho vývoj zastřešuje organizace Business Process Management Initiative (BPMI). Skutečnost, že

BPMI sdružuje téměř všechny světové společnosti zabývající se nástroji pro modelování podnikových procesů, znamená, že BPMN má šanci stát se obecně uznávaným standardem. Proto se o něm alespoň v krátkosti zmiňme.

Obrázek 2 - Příklad diagramu procesu znázorňující alokaci zdrojů pomocí tzv. pools (pruhy představující různé organizace) a lanes (pruhy představující zdroje v rámci organizace); notace BMPN

Standard BPMN vznikl s cílem vytvořit sjednocený popis procesů tak, aby byl srozumitelný všem uživatelům – od analytiků navrhujících procesy, přes vývojáře, kteří je implementují, až po řídicí pracovníky, kteří je budou řídit . Dalším faktorem, který stál u zrodu BPMN, byla skutečnost, že modely procesů používané analytiky ve fázi návrhu byly v minulosti technicky odděleny od reprezentace procesů v té formě, jakou vyžadují systémy určené k jejich implementaci a následnému provádění. Proto bylo vždy nutné ručně převádět výchozí modely na prováděcí modely. Při takové transformaci je nebezpečí vzniku chyb a navíc vlastníci procesů nemohli žádným jednoduchým způsobem sledovat výkonnost vyvíjených a postupně upravovaných procesů. Standard BPMN byl navržen tak, aby odstranil tuto bariéru mezi analyticky orientovanými modely procesů a jazyky XML, používanými k jejich implementaci v informačních systémech. Grafické objekty BPMN a jejich atributy byly vyjádřeny prostředky jazyků BPEL4W (Business Process Execution Language for Web Services) a BPML (Business Process Modeling Language).

3.2.2 Business Process Executable Language

Koncept webových procesů je jedním z východisek a motivací pro vznik BPEL.

Smyslem je zjednodušit interakci aplikací mezi jednotlivými společnostmi,

dodavateli, zákazníky. Umožňuje integraci sužeb a aplikací bez ohledu na technologické platformy.

Webové procesy popisují, jak jsou propojeny jednotlivé webové služby a nezáleží na tom, kde je daná služba umístěna a jak je implementována - jestli jde o interní (vnitropodnikové), nebo externí služby. Tyto vztahy jsou modelovány prostředky pro modelování business procesů, které jsou z hlediska abstrakce vůči BPEL nadřazeny, a jejichž užití je zpravidla nutnou podmínkou pro vytvoření účelné a smysluplné aplikace.

Specifikace BPEL na úrovni exekutivního jazyka definuje, jakým způsobem mají být webové služby kombinovány a skládány do rozsáhlejších business procesů. S jeho pomocí mohou vývojáři aplikací a systémoví integrátoři modelovat, jakým způsobem proudí informace mezi jednotlivými webovými službami v rámci webových procesů, umožňuje automatizaci webových procesů. Ke standardizaci byl předložen skupinou firem v čele s IBM a Microsoftem. V současné době se o rozvoj standardu stará konsorcium OASIS.

Jazyk BPEL je založen na principech XML a vychází z těchto základních standardů: WSDL 1.1, XML Schema 1.0 a XPath 1.0. Z těchto standardů je nejtěsněji svázán s jazykem WSDL. Procesní model vytvořený jazykem BPEL funguje jako vrstva, která je nadřazena modelu služeb definovanému standardem WSDL 1.1.

Na samém základě modelů v BPEL jsou služby specifikované ve WSDL a jejich peer-to-peer interakce. BPEL pak slouží k určení, jak mají koordinovány interakce mezi instancemi služeb s jinými službami a jak mají být tyto služby sdružovány do business procesů. Toho BPEL dosahuje definicí message exchange protokolů mezi jednotlivými službami a určením chování a pozice dané služby v rámci business procesu. V tomto smyslu BPEL definice procesu využívá jednu nebo více WSDL služeb a poskytuje popis chování a interakcí instance daného procesu vůči jeho partnerům a zdrojům skrze interface webových služeb.

Obrovskou výhodou BPEL je, že samotný skript může obsahovat volání mnoha webových služeb, avšak ty jsou pomocí BPEL zapouzdřeny a prezentovány jako jediná nová služba, která může být rozsáhlým procesem, se svým vlastním

rozhraním, ke kterému mohou přistupovat vnější aplikace. Takto vytvořená webová služba pak může být nejen aplikací využívána, ale může se stát její samostatnou komponentou, která je poskytována dalším aplikacím.

3.3 Nevýhody procesního ř ízení

Procesní řízení má samozřejmě také své nevýhody, které jsou velmi často spojeny s přechodem z liniového na procesní řízení. Takový přechod není v žádném případě jednoduchou záležitostí. Je potřeba překonat funkční způsob myšlení a kromě technologických změn je nutné také změnit podnikovou kulturu, což je velmi zdlouhavé (udává se, že až v horizontu několika let) a náročné a je to také často příčinou nedotažení přechodu na nový způsob řízení do konce.

Další překážkou se může stát neochota zaměstnanců popisovat a předávat své know-how. V ČR jsou tyto tendence stále ještě velmi patrné. Někteří zaměstnanci si uvědomují, že pokud by ztratili tuto svou výhodu, mohli by se stát snadno nahraditelnými.

Procesní řízení předpokládá modelování a optimalizování procesů. V literatuře se udává, že tuto činnost mají na starosti zaměstnanci označovaní jako Business Analyst nebo Process Designers. V našich podmínkách však nejsou tyto pozice běžné a to může tedy také vést ke komplikacím.

4 Service-Oriented Architecture (SOA)

Většina analytiků předpokládá, že Service-Oriented Architecture se stane vybranou architekturou pro eterprise computing a že její implementace povede k nárůstu výkonnosti a pružnosti, a významně zlepší návratnost investice. Podle Gartner Research, se SOA stane běžnou praxí při navrhování software do roku 2008. (Originální znění: SOA will be the prevailing software engineering practice by 2008). V poslední předpovědi IDC odhaduje, že celosvětové výdaje na externí služby založené na principech SOA dosáhne 8,6 miliard dolarů v roce 2006 a téměř 34 miliard v roce 2010. (Originální znění: Worldwide spending on SOA-based external services will reach $8,6 billion in 2006 and aomost $34 billion by 2010).

4.1 Co je p ř esn ě SOA

Existuje mnoho různých definic SOA, které se nepříliš často shodují v tom, co přesně Service-Oriented Architecture představuje. Například, WC3 (World Wide Web Consortium) definuje SOA jako typ distribuované architektury systémů obvykle charakterizované oddělením služeb, zaměřením na služby, součinností založenou na obsáhlých a komplexních zprávách a neutralitou na platformě. (Originální znění: „form of distributed systems architecture that is typically characterized by service abstractions, message orientation, with interadtions based on large and complex messages, and platform neutrality.“) Forrester Research definuje SOA jako styl designu, distribuce a řízení aplikací i softwarové infrastruktury, ve které jsou aplikace uspořádány do business služeb charakterizovaných atributy QoS (Quality of Service). (Originální znění: „style of design, deployment, and management of both applications and software infrastructure in which applications are organized into business services characterized by Quality of Service (QoS) attributes.“) V dalších definicích od prof. Jandoše rozumíme pod pojmem SOA softwarovou architekturu orientovanou na služby. Službou rozumíme programovou komponentu schopnou provedení určité služby ve smyslu činnosti (task). Služba přijímá požadavky na (své) provedení a odesílá výsledky provedení těchto požadavků prostřednictvím standardního rozhraní. Služby navzájem komunikují prostřednictvím zpráv. Současná SOA využívá pro implementaci služeb technologii webových služeb (WS – Web Services).

Webové služby realizují SOA architekturu s využitím otevřených standardů/protokolů jejichž množina se trvale rozšiřuje. Za základní se považují standardy XML, SOAP, WSDL, UDDI.

WS je softwarová aplikace, identifikovaná pomocí URL, jejíž rozhraní a vazby je možno definovat, popsat a prozkoumat pomocí nástrojů XML. WS podporuje přímé interakce s jinými WS za použití zpráv, založených na XML a předávaných pomocí standardních protokolů. Službou může být objekt, sada objektů, proces složený z mnoha objektů, nebo proces skládající se z dalších procesů, mající jeden výstup. Navenek se služba tváří jako jedna entita, ale uvnitř může být velice komplexní.

Rozdíl mezi SOA a webovou službou by se dal popsat asi takto: SOA nedefinuje jak konkrétně mají služby komunikovat a spolupracovat, ale říká, jak se mohou dorozumět. Webové služby, na druhé straně, přesně určují pravidla jak mají služby komunikovat, jak posílat zprávy atd. (technologie SOAP). V podstatě by se dalo říct, že webové služby jsou podmnožinou SOA, konkrétní technickou implementací SOA modelu.

Výše uvedené specifikace SOA a WS jsou pouze jedním z možných pojetí dané problematiky, Pro různé pracovníky např. v podnikové hierarchii má SOA zcela odlišný význam.

Pro vedoucího pracovníka (manažera) – představuje zejména množinu služeb (pojatých na globální podnikatelské úrovni), které je daný podnik připraven poskytnout svým partnerům (zákazníkům, spolupracujícím organizacím).

Zajímá se zejména o podnikatelské přínosy (měřené nejraději podnikatelskými metrikami) implementace těchto služeb s využitím SOA, náklady na zajištění těchto podnikatelských služeb s využitím SOA a návratností investic (obdobně jako v případě, že podnikatelské aktivity jsou podporovány ICT tradičním – tj. ne SOA – přístupem).

Pro softwarového architekta – představuje SOA množinu architektonických principů, koncepcí, kriterií a charakteristik jako např. opakované použití (reuse) služeb (chápaných nyní již v konceptu SOA tj. v zásadě jako programové komponenty zajištující určitou (často podnikatelskou) funkčnost), volnou vazbu služeb, vytváření složených služeb (composite services) atd. Rovněž tak koncepty metodiky analýzy a návrhu orientovaného na služby.

Pro programátora – představuje SOA určitý programovací model zahrnující standardy, nástroje a technologie – u současné SOA technologická prostředí pro implementaci Webových služeb.

SOA není zcela nový koncept. Velice podobný princip komunikace objektů přes jasně definovaná rozhraní byl navržen už v architektuře CORBA (Common Object Request Broker Architecture).

4.2 Vlastnosti SOA

Pro současnou SOA využívající WS lze dle prof. Jandoše uvést následující základní vlastnosti

• je založen a na otevřených (tj. veřejných) standardech. Tím, že využívá otevřené (tj. na dodavateli nezávislé) komunikační prostředí s využitím zpráv pro komunikaci služeb,

o podporuje volnou vazbu služeb (na rozdíl od těsné vazby u jiných přístupů),

o vytěsňuje proprietární technologie (které by mohly vnášet heterogenitu) do úlohy implementace a hostování aplikační logiky, která je prezentována jako služba,

• trvale se rozvíjí ve směru k vyšší dokonalosti/úplnosti; ve směru zajištění širšího okruhu atributů ovlivňujících kvalitu služeb např. bezpečnost, transakční zpracování,

• schopná zvyšovat kvalitu služeb; přijetím standardů, které upravují příslušné atributy služeb (např. při transakčním zpracování),

• využívá abstrakci v modelu služeb. Tento model obsahuje hierarchické vrstvy – vrstva podnikatelských procesů, vrstva skládání služeb, vrstva podnikatelských služeb, vrstva aplikačních služeb. Každá vrstva modeluje (a řeší) pouze jí příslušnou problematiku (tj. abstrahuje od související problematiky řešené jinými vrstvami). Tím se dosáhne i urychlení reakce na změny v podnikatelském prostředí, které se promítnou jako změny do vrstvy podnikatelských procesů – a které lze řešit se silnou účastí podnikatelských (tedy ne IT) managerů – a v následné podpoře změnami v nižších vrstvách služeb (WS), které provádějí architekti IT a případně programátoři a to i s využitím možnosti implementace kompozitních služeb. Tímto podporuje SOA

„podnikatelskou agilitu“,

• podporuje volnou vazbu služeb, která se promítá i do modelu služeb.

Volná vazba spočívá mj. v tom, že jednotlivé služby jsou v zásadě autonomní a jejich komunikace s využitím otevřeného standardního

komunikačního prostředí (v zásadě XML zpráva) nevyžaduje znalosti jejich vnitřních implementací,

• podporuje vytváření nových složených (kompozitních) služeb ze služeb, které jsou již jako samostatné autonomní prvky k dispozici. S jejich vytvářením na základě WS souvisí koncept orchestration, kdy je pouze jedna organizace/podnik výhradním vlastníkem logiky určující složenou službu, a koncept choreography rozšiřuje působnost SOA ve směru standardizace mezi-podnikové (B2B) spolupráce,

• podporuje opakované využití služeb, kdy určitou službu lze využívat v různých scénářích mj. též jako součást několika různých složených služeb,

• podporuje interoperabilitu a integraci na úrovni služeb jako svoji základní vlastnost. Vychází se z nalezení (adresace) služby, jejího popisu (bez ohledu na detaily vnitřní implementace) včetně popisu zpráv pro její vyvolání a pro předání výsledku provedení služby; to vše ve standardním komunikačním prostředí WS založeném na otevřených standardech.

Není však řešena otázka sémantiky.

4.3 Implementace SOA

Implementace SOA s využitím webových služeb zahrnuje několik znalostních oblastí – základní koncepty WS (vyjádřené zejména ve specifikacích WS), metody a metodiky pro analýzu a návrh WS, technologické prostředky a prostředí, která podporují analýzu, návrh, implementaci a provoz řešení založených na WS – označované obvykle jako development či run-time environment. Při tom metodiky i technologické prostředky mohou v některých případech podporovat pouze určitou podmnožinu základních konceptů WS, v závislosti na dodavateli těchto metodik a prostředků. Kromě implementace konceptů WS v souladu se specifikacemi WS zahrnují často dodavatelé do své implementace i vlastní (nestandardní, proprietary) části řešení ( proprietary tools).

Pro programátorskou implementaci podnikových řešení založených na WS se v současné době využívají zejména dvě platformy – J2EE (Java 2 Enterprise Edition) a Microsoft .NET.

4.4 P ř ínosy SOA

Studia Aberdeen group uvádí následující oblasti možných přínosů současné SOA

Přínosy pro IT:

• řízení složitosti IT,

• opakované využití (re-use) aplikací (v uvedené studii je hlavním důvodem pro využívání SOA u 57% respondentů),

• rychlosti implementace IT,

• snížení IT integračních nákladů (v uvedené studii je využití SOA pro integraci nejčastěji využívanou oblastí aplikace SOA, 72% respondentů).

Přínosy pro podnikání:

• rychlejší reakce na změny,

• zvýšení konkurenceschopnosti,

• (v uvedené studii je pro více než 67% respondentů hlavním důvodem využívání SOA možnost (rychlého a relativně snadného) rozvoje nových podnikatelských možností nebo nových služeb).

Sdílené přínosy:

• soustavné sladění IT a podnikání,

• nižší celkové náklady na IT

• nižší náklady na údržbu IT,

• přínosy pro řízení podnikových procesů (BPM),

• vývoj nových podnikatelských aktivit podporovaných IT.

4.5 Nevýhody SOA

Při implementaci SOA je nutné brát v úvahu i některé negativní aspekty,

• celá oblast zahrnující standardizaci, metodiky analýzy i návrhu, i technologie na trhu je ve stadiu soustavného vývoje,

• pro implementaci řešení SOA jsou zapotřebí jiné znalosti (a kvalifikace pracovníků) než pro implementace s tradičním (tj. „ne SOA“) přístupem,

• vzhledem k tomu, že většina podniků již provozuje tradiční řešení, není vždy zcela snadné určit strategii zavádění SOA řešení,

• současná SOA neřeší otázku sémantiky (např. zpráv) což může ztěžovat vytvoření kompozitních služeb (ze služeb z různých zdrojů) i otázku integrace (zejména mezi-podnikové) služeb. Může být zapotřebí jejích konverze např. s využitím dalších prostředků jako např. ESB (Enterprise Software Bus),

Kromě toho některé přínosy (např. rychlejší reakce na změny v podnikatelském okolí) se mohou projevit až po delší době od ukončení implementace SOA řešení.

5 Workflow systémy

V souvislosti s realizací procesů je úzce spjat pojem workflow. Lze ho přiblížit jako tok informací v podnikovém procesu a jejich automatizované řízení. Dle definice znamená automatizaci celého nebo části podnikového procesu, během kterého jsou dokumenty, informace nebo úkoly předávány od jednoho účastníka procesu k druhému podle sady procedurálních pravidel tak, aby se dosáhlo nebo přispělo k plnění celkových/globálních podnikových cílů. Uvážíme-li vývoj informačních systémů v posledních čtyřech desetiletích, je nástup workflow systémů jeho přirozeným vyústěním. V šedesátých letech byly informační systémy tvořeny několika navzájem oddělenými aplikacemi. Každá aplikace měla vlastní datovou základnu a jiné uživatelské rozhraní. V sedmdesátých letech byla oddělena data od aplikací, byly vyvinuty první databázové systémy.

Užitím databázových systémů byly aplikace zbaveny velkého břemene – řízení a správy dat. V osmdesátých letech došlo k podobnému zlomu i u uživatelského

rozhraní. Systémy pro návrh uživatelského rozhraní umožnily vývojářům aplikací vytlačit návrh uživatelské komunikace mimo aplikace. Devadesátá léta jsou obdobím workflow systémů, které vedou k vytlačení procesní logiky mimo podnikové aplikace a k jejich vzájemnému propojení. Workflow systémy obvykle pokrývají nejenom fázi realizační (řízení průběhu procesu), ale i fázi přípravnou (definici procesu) a v neposlední řadě i fázi monitorování a vyhodnocování reálného průběhu procesu. Úzce proto souvisí s referenčními modely podnikových procesů obsaženými v ERP aplikacích i s metodami, nástroji a technikami procesního modelování. Všechny tyto oblasti se vzájemně prolínají a doplňují. Aby se investice vložené do vývoje workflow systémů v důsledku nekompatibility s dalšími komponentami zbytečně neztrácely, byla v roce 1993 založena nezisková mezinárodní organizace Workflow Management Coalition, jejíž snahou je připravovat a prosazovat standardy pro interoperabilitu a konektivitu workflow produktů.

Infrastrukturu podniku vytváří kombinace všech jeho procesů. Obvykle však tato infrastruktura není kompletně dokumentovaná, protože její velikou část představují postupy, které jsou zkonstruovány a udržovány pouze v hlavách zaměstnanců nebo jsou roztroušeny v různých směrnicích, případně jsou respektovány v rámci neformálních pravidel. Některé jsou předávány mezi zaměstnanci pouze ústním podáním.

Na výkon podniku má velký vliv rychlost procesů. Moderní řídící metody vždy kladou do centra pozornosti rychlost jednotlivých podnikových cyklů, jako je vývoj produktu či zásobování, a všímají si informací o procesech typu zpráva pro vedení atd. Jde-li o rozhodující procesy, bude jejich rychlejší a efektivnější provedení příznivě ovlivňovat rozvoj podnikání a boj s konkurencí. Je třeba předpokládat, že konkurence již může mít pro řadu procesů workflow implementováno.

Vzhledem k tomu, že workflow je již několik let v popředí zájmu uživatelů, reaguje na tuto skutečnost mnoho dodavatelů tím, že integrují do jimi vyvíjených systémů některé workflow funkcionality. Výsledkem je, že na trhu najdeme mnoho dodavatelů, kteří potenciální zákazníky ujišťují o tom, že součástí jejich systému je i plně funkční workflow. V mnoha případech se však

jedná pouze o složku informačního systému, která však nepokrývá kompletně všechny základní charakteristiky workflow.

Vývoj ERP systémů tedy vede k tomu, že i když jsou již teď procesně orientovány, budou i nadále obohacovány o další funkcionality z workflow systému, které budou napomáhat managementu řídit společnost procesním způsobem. Následující možnosti by měl podle ing Cardy a ing Kunstové poskytovat produkt, který se chce považovat za skutečný workflow systém.

Postupně zjistíme, že ERP systémy již splňují některé z požadavků. Záleží pouze na tom, jak kvalitní ERP řešení vybereme.

− Grafický návrh procesů: mapy, které definují tok činností a úkolů, jež musí být od startu do cíle vykonány.

− Role: schopnost přiřadit jednotlivým činnostem role nebo pracovní funkce, aby definice workflow nemusela být změněna vždy, se změnou pracovníka.

− Pravidla: schopnost vložit do definice workflow logiku procesu bez potřeby programování.

− Řešení výjimek: možnost řešit výjimečné situace (dlouhodobá nepřítomnost odpovědného pracovníka apod.).

− Monitoring: monitorovat jednotlivé výskyty procesů, ideální je řešení, kdy je tato funkce přístupná všem účastníkům průběhu procesu a administrátorovi workflow.

− Měřitelnost: schopnost generovat statistické zprávy, které jsou podkladem pro zjištění časového průběhu procesu a jeho nákladů.

− Simulace: možnost testovat procesy workflow na jednom počítači před jeho spuštěním v síti.

− Aktivita: workflow musí uživatele informovat o nových úkolech, upozorňovat je na termíny úkolů a případně přesměrovat úkoly na jiné uživatele.

− Databázové rozhraní: řada workflow procesů buď využívá informací z databází, aby uživatel mohl učinit patřičné rozhodnutí, nebo naopak

informace do databáze ukládá – často však potřebujete obojí, proto musí workflow řešení poskytovat kvalitní databázové rozhraní.

− Připojování dokumentů: dokumenty jsou klíčovou součástí řady podnikových procesů, a proto musí systém poskytovat efektivní prostředky pro jejich integraci do workflow.

6 Implementace funkcionalit procesního p ř ístupu v ERP

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í nového ERP řešení dojít. Důvodem je především to, že v ERP software jsou procesy již definovány. „V praxi se neohýbají aplikační software podle zákaznické firmy, ale procesy zákaznické firmy se ohýbají podle implementovaného ERP řešení.“ (Prof. J. Basl – přednáška IT575 LS2006).

Samozřejmě většina ERP software se dá různými způsoby parametrizovat a 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 komplexnosti, ERP řešení.

V zásadě platí, že implementace aplikačního software typu ERP donutí díky výše zmíněným faktům zákaznickou společnost zamyslet se nad svými business procesy a pokusit se je popsat a optimalizovat. V ideálním případě proběhne tedy fáze analýzy a optimalizace firemních procesů ještě před vlastním zavedením nového systému, který je následně naparametrizován a přizpůsoben tak, aby průběh již optimalizovaných firemních procesů co nejvíce podporoval.

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.

Obvyklým způsobem hodnocení procesů je kalkulace a sledování nákladů vztažených k jednotlivým výskytům procesů nebo k jejich částem. Standardně bývá k dispozici předběžná, průběžná a zpětná kalkulace a schopnost přiřazovat náklady k různým nositelům nákladů. Nemusí to být ovšem vždy podmínkou a rozmanitost těchto funkcionalit opět závisí na komplexnosti a ceně.

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.

V této kapitole byly uvedeny některé příklady podpory procesního přístupu v ERP systémech. Myslím si však, že je patrné, že firma, která implementuje klasický ERP, nemůže říci, že by podpora procesního přístupu byla dostačující.

6.3 Podpora P Ř v podob ě nadstaveb/modul ů

Další možnosti podpory procesního řízení prostřednictvím ERP systémů je možné nalézt v různých modulech a nadstavbách. Jedná se o rozšíření 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í standardu.

Asi největší rozdíl mezi podporou procesního přístupu v klasických ERP, viz předešlá kapitola, a podporou procesního přístupu v nadstavbách a modulech spočívá v tom, že v klasických ERP se tato podpora týká pouze procesů, které vývojáři integrovali do systému, ale v případě nadstaveb a modulů je možné 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í.

7 Podpora procesního ř ízení v ERP b2industry

7.1 SAGEbäurer a jeho b2industry Generation 5.0

O systému b2industry

V případě b2industry vyvinula společnost SAGEbäurer ERP software orientovaný na potřeby zákazníků, který se díky své otevřenosti a objektové stavbě snadno přizpůsobí jejich obchodním procesům. b2industry je výsledkem neustále prohlubovaného oborového know-how a mnohaletých zkušeností firmy SAGEbäurer na poli řízení výroby a materiálového hospodářství. Vývojové prostředí nezávislé na platformě navíc vytváří předpoklady pro otevřenost, flexibilitu a svobodu při utváření procesů. V b2industry lze úzce propojit oblasti jako management, plánování, výroba, odbyt a účetnictví. Oborové funkcionality integrované do b2 dávají uživateli značnou konkurenční výhodu a vedou ke zkrácení vnitropodnikových rozhodovacích procesů.

O společnosti SAGEbäurer GmbH

SAGEbäurer nabízí oborově zaměřená ERP řešení pro podniky střední velikosti. Enterprise Resource Planning (ERP) software b2 společnosti SAGEbäurer GmBH je komplexní řešení otevřeného podnikového systému.

Software je v současnosti lokalizován pro dvanáct zemí v osmi jazycích. Vedle přímého odbytu a dceřinných společností ve Švýcarsku a Rakousku je za distribuci a podporu produktů b2industry, b2trade, b2wincarat a b2power odpovědných dalších dvacet lokálních a mezinárodních partnerů. Generací

„dynamic“ produktové rodiny b2, představené u příležitosti veletrhu CeBIT 2004, vsadila firma SAGEbäurer na obecnou podporu a integraci technologií Open Source.

Celá skupina dnes může doložit více než 1200 instalací po celém světě, větší částí v německy mluvících zemích. Coby dodavatel komplexních řešení

zahrnuje firma do svého portfolia vedle softwarových produktů i consulting, projektové řízení a školení pro koncerny i středně velké podniky.

7.2 Procesní ř ízení v b2industry – základní funkcionality

7.2.1 Kalkulace

Na dalších řádcích se budu věnovat kalkulacím. Uvádím je zde z důvodu, že kalkulace je možné brát jako jeden ze způsobů vyhodnocování probíhajících procesů a jak již bylo zmíněno v předešlých kapitolách, tak právě vyhodnocování procesů je jedním z důležitých aspektů procesního přístupu k řízení organizací.

Kalkulace v systému b2industry se týkají především výrobních nákladů. Neutrální kalkulace vyjadřuje náklady na základě kmenových dat a zakázkově zaměřené kalkulace jako předběžná, průběžná a následná kalkulace, vycházejí samozřejmě ze zakázkových dat.

Neutrální kalkulací jsou vypočítávány výrobní náklady na základě množství v kusovnících, cen, pracovních postupů s jednicovými a přípravnými časy a jednotlivých pracovních operací se zohledněním počtu zapojených pracovníků a veškerých použitých strojů. Jednotlivé druhy nákladů (strojní, personální, přípravné, náklady externího zpracování) jsou pak vztahovány ke konkrétním pracovištím a mzdovým skupinám. Způsob výpočtu nákladů a zohledněná vstupní data jsou řízena nastavením příslušných parametrů.

Základem pro výpočet nákladů vztažených ke konkrétnímu dílu jsou ceny vypočítané hromadnou kalkulací s různými pevně vymezenými kritérii, které lze přednastavovat podle potřeby. Na tomto principu parametrizace jsou v b2industry vypočítávány i ostatní kalkulace. Od výpočtu výrobních nákladů celé struktury nezávisle na konkrétní zakázce pomocí rozpadu kusovníků a pracovních postupů, přes výpočet přirážek a nabídkových kalkulací, až po výpočet prodejních a nabídkových cen. Nabídková kalkulace také mimo jiné podporuje výpočet s neúplnými daty v kmenových záznamech nebo s informacemi vloženými do systému pouze pro potřebu nabídkových kalkulací.

Může být také spuštěna s výrobními daty a v souvislosti s tím je pak možné její výsledky použít jako výsledky neutrální kalkulace.

U kalkulací vztažených na zakázku jsou podklady pro výpočet tvořeny zaplánovanými výrobními zakázkami a informacemi z jejich zpětných hlášení. U kalkulací výrobních zakázek můžeme pomocí příslušných parametrů nastavit stupeň přesnosti výpočtu. Toto nastavení určuje, jestli mají být díly, ať už vlastní výroby nebo externího pořízení, vyrobené na sklad nebo na zakázku, oceněny náklady založenými na kmenových datech nebo skutečnými náklady. U druhého způsobu jsou v případě, kdy ještě nejsou známy přesné výdaje, použity předběžné hodnoty a až v momentě, kdy jsou získány přesné výdaje (příjem faktury, výpočet podřízené výrobní zakázky atd.), jsou náklady přepočítány podle reálných hodnot a do rozhraní pro účetnictví jsou vygenerovány příslušné rozdílové zápisy.

7.2.2 Simulace

Simulace obecně umožňuje otestovat průběh firemních procesů a odhalit tak případné problémy dříve než k nim skutečně dojde. Management je tedy schopen upravit proces tak, aby vyhovoval potřebám firmy.

Simulace b2industry paralelně plánuje a vzájemně propojuje všechny zdroje výrobního procesu. Na základě dat odbytových zakázek jsou zakládány, upravovány a hlášeny výrobní zakázky za současného sledování úzkých míst ve výrobě. rozpadem kusovníků a výrobních postupů při simulovaném plánování výroby vznikají hypotetické potřeby, které jsou porovnávány s dostupnými zdroji. Jsou vypočítány termíny potřeby vychystání jednotlivých materiálů a hlášeny případné chybějící položky nebo úzká místa výrobních kapacit. Dále simulace prověří dodržení termínu dodání a zobrazí situaci zakázky v její struktuře v kontextu aktuální výroby.

7.2.3 Průběh hlavního procesu

V této části je popsáno, jaké možnosti přehledu o stavu a průběhu procesu dává b2 zainteresovaným pracovníkům. Toto je také důležité pro vyhodnocování procesu a pro možnost jeho optimalizace za běhu.

Systém b2industry je navržen pro výrobní podniky a jeho základním kamenem je tedy výrobní proces. Samozřejmě však také neopomíjí i další podprocesy,

které spolu s výrobním procesem vytvářejí poměrně rozvětvenou strukturu procházející celým podnikem, viz příloha č. 1

Systém používá pro rozlišení stavu, v jakém se zrovna ta která odbytová zakázka nachází, statusy. A podle těchto statusů, uvedu pro příklad status dodacího listu, potvrzení zakázky, status faktury atd., si lze i nechat zobrazit zakázky podle zadaných kritérií. Například, pokud budeme chtít vidět všechny otevřené odbytové zakázky, zadáme pouze jedno výběrové kritérium – status faktury = nefakturováno (v terminologii b2 to znamená, že tato odbytová zakázka ještě nebyla uzavřena). Dále pak jednoduchým výběrem konkrétní zakázky si můžeme zobrazit veškeré podrobnosti o této zakázce. Vyhledávání v b2 je poměrně propracované, takže použitím vhodných výběrových kritérií jsme schopni vyselektovat přesně ty zakázky, které chceme.

Co se týče průběhu odbytové části hlavního firemního procesu, je ho možné parametrizovat poměrně rozmanitým způsobem a tím tedy měnit podobu firemního procesu. Některé kroky je možné pomocí parametrů úplně vynechat.

Typický příklad je krok potvrzení zakázky, kdy záleží pouze na zákazníkovi, zda je tento krok povinný a nebo není systémem vůbec vyžadován. Jiné kroky je zase možné zcela automatizovat, zde uvedu jako příklad uvolnění odbytových zakázek k zaplánování. V tomto případě je možné nastavit systém tak, že zakázka je uvolněna k zaplánování hned v momentě, kdy je uložena do systému. Z mé zkušenosti bývá toto nastavení častější. Ale pokud má zákazník zájem oddělit od sebe uložení zakázky a její uvolnění pro zaplánování, například z důvodu, že uživatelé, kteří mají uživatelská práva na zakládání odbytových zakázek, nemají již práva na jejich uvolňování, je samozřejmě možné toto parametricky nastavit. Toto je jeden z příkladů, kdy dochází k prolínání řízení procesu a podnikové koncepce uživatelských práv. Zcela automatizovat je možné i další krok, vlastní zaplánování. Automatizace tohoto kroku již není tak běžná a pokud se u nějakého zákazníka zavádí, tak až po relativně dlouhé době od uvedení do ostrého provozu, kdy je systém již dostatečně odladěn, aby automatizace takto důležitých kroků nevedla k problémům.

Zde se již dostáváme do výrobní části hlavního firemního procesu. Zde jsou také používány statusy stejně jako v odbytové části, ale pravděpodobně poroto,

protože je výroba stěžejním podprocesem hlavního procesu, nabízí b2insustry ještě jednoduchou grafiku, která ukazuje kromě stavu, ve kterém se výrobní zakázka nachází, i například kritický materiál (chybějící), a ve vyobrazování stavu jde až na jednotlivé pracovní operace. V rámci této grafiky jsou od sebe jednotlivé stavy odlišeny symbolikou a barvami a jednoduchým kliknutím je samozřejmě možné zobrazit podrobnější informace o materiálu, pracovní operaci atd. Přehled o stavu výrobní zakázky funguje principielně stejně, pomocí statusů, jako je tomu u odbytové zakázky.

Je možné sledovat i časový harmonogram, který je systémem vypočítáván na základě časových údajů z pracovních postupů, kde se sledují časy jednotlivých pracovních operací, z časových údajů v číselníku dílů, kde jsou zaznamenány informace o předpokládaných dobách dodání. V průběhu konkrétní výrobní zakázky jsou údaje průběžně přepočítávány podle aktuálních informací z výroby, nákupu atd. Tato aktualizace je nejčastěji prováděna prostřednictvím CronJobu každou noc, ale je možné ji spustit i v libovolný časový okamžik. Je tedy možné mít představu nejen o současném stavu probíhajícího procesu (zakázky) reprezentovaného statusy, ale i o přepokládaném vývoji tohoto procesu v budoucnosti. To dává střednímu managementu možnost zjistit případné nesrovnalosti, adekvátně zasáhnout, ovlivnit vhodným způsobem průběh procesu a následně nechat systémem celou situaci přehodnotit, aby bylo možno vidět, jak provedené změny skutečně ovlivnily proces. Díky výše zmíněným simulacím, je možné toto odlaďování provádět již v simulačním režimu a skutečně spustit až takto vyladěný proces.

V průběhu všech procesů v rámci b2 jsou z důvodu sledování odpovědnosti vedeny záznamy o tom, který uživatel provedl kterou akci. V důležitějších případech jako například u jednotlivých nákupních, odbytových, výrobních zakázek, dodacích listů, faktur, skladových pohybů, storna, změn měnových kurzů atd jsou odpovědní uživatelé uvedeni u těchto datových objektů. Všechny v systému provedené činnosti od těch již zmíněných až po ty méně důležité úkony typu změna výstupní tiskárny jsou spolu s uživatelem, který úkon provedl, uvedeny v tak zvaném „JobSpooleru“. Je tak možné dohledat původce jakéhokoli provedeného úkonu v systému. Vzhledem k množství úkonů prováděných v systému je možné samozřejmě nastavit určitá opatření

zabraňující zahlcení serverů těmito daty. Naskýtá se možnost záznamy po určité době automaticky mazat nebo data zálohovat na externí datové nosiče.

7.3 Modul „Workflow Management“ v b2industry

7.3.1 Obecná nastavení (bv958000)

Obrázek 3 – Obecná nastavení

V této masce Jsou nastavovány obecné parametry a údaje, které jsou následně společné pro všechny procesy nadefinované prostřednictvím „Workflow Managementu“.

Nastavuje se zde, jakými barvami má být zobrazena činnost s tím kterým statusem, jaký text se má zobrazovat uživatelům v jejich ToDo listech, zda může provádět zpětná hlášení libovolný uživatel, nebo k tomu má oprávnění pouze uživatel explicitně uveden u konkrétní činnosti.

Dále je zde možné nastavit údaje, které slouží pouze jako předloha pro pozdější definování procesů. Tyto údaje je možná později změnit podle potřeby konkrétního případu.

7.3.2 Spool aktivit (bv95800)

Obrázek 4 – Spool aktivit

Nejprve je samozřejmě potřeba, aby byl definován průběh konkrétního procesu až na úroveň jednotlivých aktivit podporovaných informačním systémem. Tyto aktivity pak musejí být zaneseny pomocí masky bv95800 do systému

Společností bäurer je doporučováno, aby uživatelská práva k této činnosti (zakládání aktivit) měl pouze omezený počet uživatelů. Je to kvůli případným pozdější problémům a komplikacím a odpovědnosti za ně.

Každá aktivita má samozřejmě své číslo, toto číslo je možné zadat buď ručně, nebo ho nechat automaticky vygenerovat systémem. To umožňuje ikonka vedle pole „číslo aktivity“ (Aktivitätnummer).

Pole „aktivita“ (Aktivität) obsahuje text, který je pak primárně zobrazován v dalších maskách workflow managementu a v To-Do seznamu jednotlivých uživatelů.

Do pole „popis“ (Beschreibung) je možné vložit podrobnější informace o jednotlivých aktivitách. Tyto informace je pak možné podle potřeby zobrazit v dalších krocích.

V části masky týkající se odpovědných osob za danou aktivitu je možné zvolit buď konkrétního uživatele, nebo skupinu uživatelů. Jedno z těchto dvou polí musí být vyplněno. Odpovědnou osobu je na základě rozhodovacích tabulek například v závislosti na skupině produktů (viz níže) možné měnit.

Původce, datum a číslo poslední změny dané aktivity je možné vidět v nejspodnější části masky.

7.3.3 Seskupování aktivit (bv95805)

Obrázek 5 – Seskupování aktivit

Pro usnadnění manipulace s Aktivitami během dalších kroků například při vytváření šablon a definování vlastních procesů je možné aktivity libovolně seskupovat. Výsledná struktura je vidět v levé části obrazovky. Tato struktura může mít libovolný počet úrovní a jedna aktivita může být přiřazena i většímu počtu skupin, které představují jednotlivé složky. Pořadní aktivit zde slouží