Pozvánka na odpolední seminář BPM 12.11.2009

Vážení přátelé procesního řízení a BPM,
dovolujeme si Vás pozvat na odpolední seminář
Business Process Management
2. generace,
který se koná 12.11.2009 od 14:00
v hotelu SONÁTA (mapa), Sokolská 68, Praha 2.
(metro Muzeum, 150 m Sokolskou ulicí směr I.P.Pavlova)
Setkání moderuje ing. Václav Kalenda.
Více informací najdete v pozvánce.
Vzhledem k omezené kapacitě je nutná Vaše včasná registrace zde.

Setkejme se a mluvme s těmi, kteří mají s BPM praktické zkušenosti.

Více.....

První ARIS zadarmo

Pokud jste stále slýchali o ARISu od IDS Scheer a Váš rozpočet nebo jiná omezení Vám zabraňovala si ho pořídit, neváhejte alespoň vyzkoušet ARIS Expres 1.0. Co nabízí? 7 typů modelů (EPC, model tvorby přidané hodnoty, organigram, datový model, model IT infrastruktury, model IS a univerzální diagram na vše ostatní). Umí importovat modely z Visia a exportuje do pdf a rtf. A co nemá? To hlavní - repository.

Více.....

Jak může vypadat modelování v blízké budoucnosti

Gravity je zatím pouze testovací nástroj, který vyvinulo vývojové centrum SAP v Brisbane. Využívá zcela nové ucelené kolaborativní prostředí Google Wave a naznačuje směr, kam se bude modelování nepochybně vyvíjet.

Více.....

Architektura podnikání

Josef Basl

Raději od začátku - co je to BPM?
Business Process Management (BPM) jako vědecká i manažerská interdisciplína a zároveň i technologie trpí chybějící obecně přijímanou ontologií. Její vymezení se pohybuje od pohledu na BPM jako na systém správy komplexních interakcí mezi podnikovými entitami [1], přes její pojímání jako formy řízení či manažerské filosofie [2] a vnímání BPM jako inženýrského nástroje managementu [3], formy firemní kultury [4] až po označení BPM jako řízení cyklu podnikání prostřednictvím jeho procesů. [5]

Do teoretických pohledů na systémy řízení podniků navíc vstupují zájmy komerční, neboť BPM je a ještě bude veliký byznys. V letošním roce dosáhne pouhý prodej nástrojů, kterého ho podporují, objemu 2 mld. USD a poroste ročně 40% tempem, [6] přitom služby s BPM přímo spojené činí odhadem sedminásobek prodeje produktů. Ve vnímání klíčových hráčů trhu je BPM buď technologie, která umožní lépe využít technologii (k automatizaci), pak jen opatrně připouštějí nutnost zahrnutí lidské dimenze řízení. Nebo je informatickým nástrojem informační společnosti a management znalostí je redukován na kvalitativní zpracování informací. Čest výjimkám, které podnikový svět netechnokratizují (např. IBM [7] ).

V češtině je akronymu BPM sémanticky nejbližší slovní spojení procesní (systém) řízení (podniku a jeho podnikání). Použité závorky naznačují, že překlad či použití termínu musí vždy vycházet z jeho kontextu v textu. A protože pojem procesní řízení má v naší zemi už patnáctiletou tradici, je dobré se ho přidržet, i když se dnes na něj nabaluje související vrstva nástrojů (BPM Suite) a ta je technologicky i základním prostředkem systémové, aplikační a potažmo i procesní integrace.

Jedno však mají všechny úhly pohledů na BPM společné – vždy je jejich základem strukturované uchopení řízení firmy a jejího podnikání, opření tohoto řízení o model těchto struktur a jeho účinná podpora informačními systémy. [8] A o tom je téma tohoto měsíce.

Vymezení tématu Architektura podnikání
Přímo s pojmem architektura podnikání (Enterprise Business Architecture) přišel v roce 2005 Ralph Whittle [9], když se pokoušel sladit odlišný pohled na struktury podniku z hlediska logiky jeho řízení (Business Architecture) a jeho informačních struktur (Enterprise Architecture). Dodnes se však používá i obou dílčích pojmů se značným významovým překrytím až zaměnitelně. [10] Přesnější vymezení pojmu včetně specifikace nezbytných standardů se očekává od OMG, která na sklonku loňského roku založila pro tento účel zvláštní pracovní skupinu. [11] Tématu se trvale věnuje i BPM Institute. [12] Ten definuje architekturu podnikání takto: „A formal blueprint of governance structures, business semantics and value streams across the extended enterprise".

I český překlad tohoto pojmu má opět potíže, protože podnikání (Business) jako důvod existence jakéhokoliv podnikatelského subjektu je některými IT odborníky překládáno chybně jako obchod (a tak najdeme ještě dost často slovní spojení obchodní procesy ve významu všech procesů firmy), naštěstí dnes už v odborných IT textech většinou zůstává jen počeštěno (byznys). A termín Enterprise není vnímán jako organizační vymezení podnikatelského subjektu nebo entity (podnik, firma, organizace), ale je zužován na soubor informačních systémů a technologií podniku (pro vymezení firmy je pak používáno adjektivum Corporate). Pokud se chceme vyhnout výše uvedeným významovým zúžením a posunům, můžeme pojem Architektura podnikání definovat takto:

• Architektura podnikání je formalizace jeho komplexních struktur, sémantiky a hodnotového řetězce.

Business model
Velmi zjednodušeně můžeme říci, že architektura podnikání je to, co dnes v podniku z hlediska jeho struktur umíme popsat modelem a inženýrsky řídit[13]. Práce s modelem reality je v samém jádru celého BPM a čím lépe dokážeme model podnikání realizovat prostředky IS, tím důležitější bude jeho úloha. S transformací monolitických uzavřených aplikací vzájemně propojených šílenou sítí přímých vazeb do dílčích služeb s vysokoúrovňovým rozhraním (SOA) propojených jedinou sběrnicí (ESB) se otevírá zcela jiná možnost promítnout model podnikání do chování informačních systémů. Model se stává vykonavatelným. Včetně zpětné vazby, tedy možnosti analyzovat v modelu skutečná data, dokonce v reálném čase. Vzniká tak nové prostředí reálné simulace reality[14], možnosti ovlivňovat chování systému v reálném čase na základě reálných výsledků.

• Takže za prvé: Architektura podnikání je o business modelu (podniku a jeho podnikání).

Záměrně hovořím o podnikání obecně, ne pouze o procesech, které vytváří jeho hodnotu. Ty jsou samozřejmě základem takovýchto systémů a mají proto v architektuře podnikání čestné místo. Pozor – modely procesů, tedy průběhu tvorby přidané hodnoty, ne souhrny aktivit podle odborností a už vůbec ne podle organizačních útvarů. Tato samozřejmost vůbec samozřejmá není. Je totiž znovu a znovu provázena velkým neporozuměním jak u manažerů, kteří vidí svůj podnik jedině organizační optikou, přes kterou řídí lidi, tak u informatiků, zvláště těch, kteří si v posledních letech konečně osvojili objektové vidění světa[15].

• Za druhé: Business model musí obsahovat popis procesů.

Průběhy procesů jsou ovšem jen málokdy striktně sekvenční, většinou obsahují řadu větvení a tedy i bodů rozhodování. Jednoduchá rozhodování lze automatizovat podle pravidel. Ale i pro ta složitější, svěřená výhradně lidem, je vhodné pravidla formalizovat. [16] Dobrými pravidly se výrazně zjednoduší nutný procesní popis[17], jasně se deklarují odpovědnosti[18]. Dokumentaci rozhodování včetně jeho podkladů lze analyzovat, poučit se z ní, ba dokonce nalézt závislosti nové, nepredikované. Systémy Business Intelligence (BI) toho využívají a stroje pro řízení pravidel se stávají součástí BPM platforem, protože rozhodování má smysl jedině v kontextu, tedy v procesech[19].

• Proto za třetí: Součástí business modelu musí být pravidla podnikání.

Čím méně je možné předem předepsat, jaký má průběh procesu přesně být, tím více je proces znalostně (ne jen informačně) náročný. Vstupy do aktivit procesu, které se transformují na přidanou hodnotu, už pak nejsou materiální, dokonce už nemusí stačit ani znalosti jedince a vlastní transformace musí probíhat formou sdílení, sociálně. [20] I tento rozměr musí umět architektura podnikání zachytit, aby mohla management znalostí účinně podpořit.

• Tedy za čtvrté: Nutným rozměrem modelu podnikání musí být znalosti.

Organizační uspořádání podniku je základem a formalizací jeho řízení. Nakolik se odchyluje kanonizovaná organizační struktura a její řídící vazby od skutečného mocenského uspořádání podniku, natolik vzniká ve firmě řídící schizofrenie a roste nejistota pracovníků. [21] Proto je jedním z cílů BPM vyloučit nebo alespoň omezit tuto ditochomii a proto…

• Za páté: Business model musí zachycovat i organizační struktury.

Firmy podnikají kvůli přidané hodnotě, veřejně prospěšné organizace státní nevyjímaje, jen u firem je snáze vyčíslitelná finančně. Jenže potřeba a forma této hodnoty se dynamicky mění a čím dál tím rychleji. Schopnost zacílit úsilí podniku a měnit jeho struktury tak, aby prosperoval i v budoucnosti a přitom dosahoval potřebnou dnešní výkonnost tvoří strategický rozměr BPM. [22]

• Za šesté: Řídícím vrcholem business modelu musí být strategické cíle a měřitelné ukazatele výkonnosti.

Velká část procesů ve firmě je dnes alespoň částečně podpořena informačními systémy, v některých oborech (třeba ve finančních službách nebo u mobilních operátorů) jsou to dokonce velmi významné části. BPM ve spojení se SOA aspiruje na to, aby přemostil propast, která se rozevřela mezi byznysem a jeho informatickou podporou tím, že ze strany jedné udělá potřeby podnikání srozumitelné IT, čili je strukturovaně popíše, ze strany druhé vytvoří tak flexibilní strukturu komponent, že bude možné na běžné změny reagovat jen jejich parametrizací, přenastavením či alespoň částečným znovupoužitím. A že služby na sebe budou navazovat v byznysem definovaném hodnotovém řetězci, že budou procesně integrované a bude tak možné měřit i dosahované procesní parametry (KPI’s). Proto dnes tolik dříve dílčích řešení se postupně integruje, proto probíhá v oblasti podpůrných manažerských nástrojů tak silná integrace trhu. Cílová BPM platforma (BPMS) má totiž sdružit nástroje řídící průběhy procesů (workflow) i prostředky kolaborace, znalostní systémy včetně business intelligence a ECM (Enterprise content management), celou škálu dnešních analytických i budoucích monitorovacích nástrojů typu BAM (Business activity monitoring) a poskytnout manažerská rozhraní či tabla (MIS) včetně podpory benchmarkingu na přehledové i podrobné úrovni. [23] Na straně druhé bude tato platforma schopná snadno integrovat nové služby včetně externích nejen webových služeb a řešení poskytovaných formou SaaS (software as a service). A bude kontinuálně podporovat cyklus vývoje funkcionality služeb nových bez ztráty zpětné vazby k požadované byznys funkcionalitě.

• Proto za sedmé: Business model se musí stát řídící metavrstvou informačních systémů.

K uvedeným požadavkům je třeba dodat, že všechny zmíněné objekty a součásti podnikové reality musí business model zachycovat ve vzájemných souvislostech.
Co k řízení architektury podnikání potřebujeme
Architektura podnikání se od architektury klasické, která má poměrně statický charakter, přece jen liší. Musí totiž zvládat i dynamiku času – řízení své vlastní změny. To je úkol nejtěžší. Pak teprve můžeme mluvit o holistickém řízení.[24]

Výše naznačená složitost podnikových struktur, které potřebujeme uchopit a řídit, dává tušit, že business model není možné od určité velikosti podnikatelské jednotky udržet v souvislostech v hlavě manažera a budovat tak mrakodrap podle ústních pokynů stavitele. [25] Pokud připočteme jejich proměnlivost, nelze je účinně zachycovat ani technikou tužka – papír, zejména pokud chceme změny přímo promítnout do nastavení IS. K řízení architektury podnikání potřebujeme proto ještě dvě věci – sémantiku kódování či zachycování těchto objektů a jejich vztahů, čili notaci pro business model. A pak potřebujeme samozřejmě také nějaký nástroj či prostředí, které nám to umožní, a vhodné postupy.

Obrázek 1: Věcný obsah architektury podnikání




Standardní notace? Ještě dlouho ne!
Pokud člověk sleduje jen radostné vyhlídky BPM v ekonomických magazínech, snadno podlehne dojmu, že BPM má první podmínku, totiž mít k dispozici metodu, dávno vyřešenu. Opak je pravdou. Přestože pro řízení architektury podnikání se vyvíjí frameworky už dobrých dvacet let, ani jeden z nich se nestal průmyslovým standardem. Většinou proto, že byly příliš složité na široké uplatnění nebo si je výrobce tak dlouho držel jako svou konkurenční výhodu pod pokličkou, až si ostatní našli cestu vlastní.

BPMN jako dnešní standard vznikl v roce 2005 naopak z minimální nezbytné množiny objektů a vazeb, které jsou zapotřebí k popisu procesů. A proto slavil okamžitý komerční úspěch. Dnes se k němu hlásí všichni velcí BPMS hráči, i když někteří značně neradi. V BPMN totiž popíše pouze procesy, a to ještě bídně a ne zcela jednoznačně. Takže si stejně každý dodavatel doplňuje tuto notaci o vlastní objekty a jejich atributy, zejména ty, které vážou na jeho specificky doplněný BPEL. Bohužel BPMN dodnes nemá oficiální XML schéma, podmínku to portability sine qua non, takže celý standard jazyka pro business modelování se najednou stává pouhým pidgin-process.

Pokud pro správu architektury podnikání využijete pokročilých frameworků, které vše výše řečené umí, vystavujete se nebezpečí věčného uzavření do svého nástroje. A to by integrující platforma v samém srdci podnikání i IT být neměla.

Text článku vznikl za podpory projektu GA CR 201/08/0663.

Odkazy



[1] Howard Smith, Peter Fingar; Business Process Management: The Third Wave; 2003; ISBN 0929652339; kniha
[2] Roger Burlton; Search Of BPM Excellence: Straight From The Thought Leaders, chapter III; 2005; ISBN 0929652401; kniha
[3] Paul Harmon; Business Process Change – 2. vydání; 2007; ISBN 0123741521; kniha
[4] Andrew Spanyi; Business Process Management is a Team Sport; 2003; ISBN 0929652029; kniha
[5] August-Wilhelm Scheer; ARIS - Business Process framework; 2000; ISBN 3540658343; kniha
[6] Ken Vollmer, Colin Teubner; Forrester Research: BPMS Market; 2007; excerpt
[7] Douglas W. McDavid; Standard for business architecture description; IBM Journal of Research and Development, Volume 38, Number 1; 1999; článek
[8] Josef Basl, Roman Blažíček; Podnikové informační systémy – 2. vydání; 2007; ISBN 8024722795; kniha
[9] Ralph Whittle, Conrad B. Myrick; Enterprise Business Architecture: The Formal Link between Strategy and Results; 2006; ISBN 0849327881; kniha, doplňující informace.
[10] Wikipedia, srov. heslo Business architecture a heslo Enterprise Architecture, úplné heslo Enterprise Business Architecture Wikipedia neobsahuje. Wikipedia v této oblasti není spolehlivý zdroj, řada hesel je zpracována profesionály z řad velkých dodavatelů hlavně IT.
[11] OMG Business Architecture Working Group (BAWG); stránka pracovní skupiny
[12] Business Architecture Section of BPMInstitute.org, domovská stránka sekce
[13] Jeanne W. Ross, Peter Weill, David Robertson; Enterprise Architecture As Strategy: Creating a Foundation for Business Execution; 2006; ISBN 1591398398; kniha
[14] Sebastien Stadil; Process Simulation versus Real Run Technology; 2007; blog
[15] Martin van den Berg, Marlies van Steenbergen; Building an Enterprise Architecture Practice; 2006; ISBN 1402056052, kniha
[16] Markus Schacher; Moving from Zachman Row 2 to Zachman Row 3: Business Rules from an SBVR and an xUML Perspective; 2006; whitepaper
[17] Barbara Von Halle, Larry Goldberg; Business Rule Revolution: Running Business the Right Way; 2007; ISBN 1600050131; kniha
[18] BPM portál; Vymahatelnost pravidel - součást tématu 01/2007; 2007; ISSN 1802-5675; článek
[19] Tom Debevoise; Business Process Management with a Business Rules Approach: Implementing The Service Oriented Architecture; 2007; ISBN 1419673688; kniha
[20] Tojo Joseph Thatchenkery, Dilpreet Chowdhry; Appreciative Inquiry and Knowledge Management: A Social Constructionist Perspective; 2007; ISBN 1845425901; kniha
[21] John Schermerhorn, James G. Hunt, Richard N. Sborn; Core Concepts of Organizational Behavior; 2003; ISBN 0471391824; kniha
[22] David Parmenter; Key Performance Indicators: Developing, Implementing,and Using Winning KPIs; 2007; ISBN 0470095881; kniha
[23] Aberdeen Group; BPM Convergence; 11/07; studie
[24] Marc Lankhorst; Enterprise Architecture at Work: Modelling, Communication and Analysis; 2005; ISBN 3540243712; kniha
[25] James F. Chang; Business Process Management Systems: Strategy and Implementation; 2005; ISBN 0849323102; kniha

Klíčová slova (anglicky): Business Process Management; BPM; BPM Suite; Enterprise Architecture; Business Architecture; Business Modeling; Knowledge Management; SOA; ESB; Business Intelligence; Business Framework; BPMN; Enterprise Governance.

Shrnutí: Business Process Management (BPM) je manažerská disciplína i technologie opřená o uchopení struktur firmy – její architektury - a její řízení prostřednictvím business modelu. Ten musí zachytit základní rozměry podnikání – jeho cíle, hodnototvorné procesy, jejich organizační, znalostní i IT zajištění ve všech jejich vazbách a dynamice změn. pro tento business model není dnes k mání notace, která by byla jak dostatečná, tak obecně přijímaná.

Standardní citace tohoto příspěvku: Josef Basl; Architektura podnikání; BPM portál – téma měsíce, 1/2008; ISSN 1802-5675; URL: http://bpm-tema.blogspot.com/2008/01/architektura-podnikani.html

Více.....

Architektura podnikání

Geary Rummler, Alan Ramias

Architektura podnikání (Business Architecture - BA, pohled na strukturu podnikání) a architektura podniku (Enterprise Architecture - EA, pohled na strukturu IT) jsou dvě vrstvy téhož modelu. Podnik je třeba pojmout uceleně jako jeden supersystém. Ten musí být adaptivní a snadno udržitelný. Je třeba především se zaměřit na vrstvy, která vytváří hodnotu (Value Creation Hierarchy - VCH). Je však třeba mnohem více pohledů, aby byla architektura popsána uceleně.

Pohled na tvorbu hodnoty
Hodnototvorných vrstev je celkem 5:

1. celopodniková úroveň (Enterprise Level) - zachycuje podnikatelské jednotky, které generují a dodávají hodnotu zákazníku a vytváří obrat, přitom společně fungují jako jeden ucelený systém
2. úroveň tvorby hodnoty (Value Creation Level) - podrobnější pohled na tvorbu jednotlivých produktů a služeb
3. primární procesní úroveň (Primary Processing Systems Level) - pohled na základní skupiny procesů
4. procesní úroveň (Process Level) - vlastní zachycení end-to-end procesů
5. úroveň subprocesů (Sub-Process/Task/Sub-Task Level) - dekompozice na úroveň činností

Obrázek 1: Hodnototvorné vrstvy

Generická business architektura
Na řadě úrovní koresponduje s pohledem na tvorbu hodnot.



Obrázek 2: Generická business architektura

Systémová mapa
Je pohledem na podnik jako super-systém a reflektuje proměnné z okolí (zákazníky, trh, konkurenci, zdroje atd.)



Obrázek 3: Systémová architektura

Funkční dekompozice
Je příčným pohledem na tvorbu přidané hodnoty a její modely (Cross-Functional Value Creation System Map) a zohledňuje její organizační zajištění.



Obrázek 4: Funkční dekompozice

Procesní rámec
Tento rámec (Business Process Architecture Framework) zachycuje vazby mezi hlavními, řídícími a podpůrnými procesy.



Obrázek 5: Procesní rámec

Podrobný procesní rámec
Podrobný rámec (BPA Detail Chart) zachycuje zajištění jednotlivých procesů a jejich interakci navzájem. Mapuje takto nejen hlavní, ale i řídící a podpůrné procesy.



Obrázek 6: Podrobný procesní rámec

Funkční procesní mapa
Funkční mapa (Cross-Functional Business Process Map) využívá klasické plavecké dráhy (swimline) k zachycení personálního zajištění procesů, jejich IT podpory, metrik, zdrojů a dalších prvků jejich kontetu.



Obrázek 7: Funkční procesní mapa

Mapa subprocesů
Podrobný pohled na procesní sekvence na úrovni činností a jejich kontextu.



Obrázek 8: Mapa subprocesů

zdroj (pdf)
Srov. téma měsíce Architektura podnikání

Více.....

Zralost architektury podnikání

Václav Kalenda

Jaký je stav řízení naší firmy?
Když v roce 2006 vydal Gartner svůj model (či spíše postupové schéma ovlivněné CMM) zralosti BPM [1], zdálo se, že pevný základ pohledu na architekturu podnikání je bezpečně založen, neboť čeho se dodavatelé více bojí, než gartnerovských magických kvadrantů. Šestifázový model totiž na přehledové úrovni definoval jak její základní rozměry, tak dynamiku jejího vývoje:

Obrázek 1: Model zralosti řízení podnikání [2]

Tento vzorový postup, který byl původně zamýšlený jako sebehodnotící nástroj, je už více než rok konfrontován s praxí a tvrdě ze všech stran kritizován, doplňován o další dimenze i postupové kroky a zase nazpět redukován k jednoduchosti, rozhodně se však stal základem, na které dnes lze budovat standardizované řešení. Jednu zásadní výhodu totiž má – rámcově podle něj lze určit, jak na tom firma z hlediska procesního řízení aktuálně je a na co by se měla v blízké budoucnosti zaměřit.

Cesta k procesně řízenému podniku začíná v bodě 0 připuštěním vlastní nedostatečnosti, pochopením vrcholového managementu, že řízení firmy z hlediska její výkonnosti vyžaduje změnu. To je signalizováno snahou managementu o reálnou zpětnou vazbu o dosahovaných výsledcích a jejich příčinách, často formou doplňování věcných ukazatelů do systému controllingu.

Vlastní první fáze procesního řízení již směřuje k architektuře podnikání – jsou modelovány a analyzovány procesy podnikání, vzniká reálný základ holistického řízení – business model. A následně je v první řadě doplněn o dimenzi měření výkonnosti, které je základem pro možnost přidělení organizační odpovědnosti za procesy jako celek – vlastnictví procesů.

Druhá fáze je zaměřena na procesní optimalizaci uvnitř podniku. První její podmínkou je zajištění přímé vazby mezi procesem a jeho promítnutím a dodržováním v praxi, což mimo jiné zahrnuje nutnost zavedení ověřování, např. formou procesních auditů. Dalším krokem je využití výhod, které business model nabízí, v terénu – jde zejména o tvorbu a testování (včetně např. simulačního ověření) nejrůznějších variant a scénářů a teprve jejich následnou implementaci. Výsledkem celé fáze je kontrola nad životním cyklem procesů – od jejich návrhu a testování až po zavedení do praxe. To také znamená konec manažerských ad hoc zásahů, které nejsou předem ověřeny na business modelu a nový pohled na rozpočtování či controlling vůbec. [3]

Ve třetí fázi podnik zvládá integrované řízení jak procesů navzájem, tak procesů, které společností pouze procházejí, pokud je firma součástí delšího hodnotového řetězce.

Vybalancování procesů navzájem prováděné napříč jdoucími řídícími procesy vytváří podmínku pro dynamickou hodnotovou alokaci zdrojů, která pak může být řízena shora strategickými a operativními cíli. Výsledkem čtvrté fáze tak je řiditelná strategie, kdy definované cíle se promítají do nastavení procesů a jejich zdrojů.

Cesta k procesnímu řízení je završena v páté fázi úplnou schopností podniku řídit své struktury dynamicky v souladu se svými byznys potřebami, prakticky v reálném čase.

Pozoruhodné na modelu zralosti je také to, že jednotlivé fáze vývoje nelze nikdy dosáhnout natrvalo, ke všem z nich je třeba se trvale vracet a znovu oživovat jejich hodnoty. Jde tedy spíše o cyklus budování procesního řízení, který se neuzavírá, ale ve svém dalším průběhu postihuje stále větší části podnikových struktur a zvyšuje dynamiku jejich řízení.

Zralost manažerů využít architekturu podnikání
Vlastní dimenze architektury podnikání jsou dnes již přehledně vymezeny. [4] Podívejme se proto ještě, jak váže jejich formalizace na stupeň zralosti podnikání jako takového čili na fázi prosazení BPM v podniku.

Pochopením, že business model je nutný základ pro řízení, vlastně celé BPM ve firmě začíná. Až do třetí fáze vystačíme se statickým modelem, který promítáme do praxe pomocí řídících úkonů (např. z business modelu generujeme řídící dokumentaci a její dodržování kontrolujeme). Nutnost semiautomatického propojení business modelu s praxí – fyzicky s nastavením IS – nastává až ve čtvrté fázi, která již vyžaduje dynamické řízení změn. A tam je nejpozdější bod, kdy je třeba nasadit BPM Suite 2. generace, které dokážou řídit chování procesů (a tedy IS) v praxi. [5]

Ve vztahu k business modelu jsou tedy jen 4 úrovně uvědomění managementu:

• 0. úroveň – Business model není zapotřebí. Typické postoje jsou charakterizovány výroky: Dosud jsme řídili bez modelu a šlo to, jistě to půjde i v budoucnu. Máme natolik jednoduché podnikání, že model nepotřebujeme. Lidi jsou důležitější než modely. Model komplikuje život a zdržuje...
• 1. úroveň – Business model je potřebný, protože usnadňuje poznání reality a její uchopení. Tento stupeň poznání je často provázen patologií – business model sice vytvoříme, ale tam, kde by nás omezoval, ho stejně sami nebudeme respektovat.
• 2. úroveň - Business model je závazný. Tato úroveň je dosahována většinou dříve ve firmách, které potřebují prokazovat shodu (ISO 9000, SOx..) a business model tvoří základ jejich řídících aktů.
  
  3. úroveň – Business model je užitečný. Ta nastává tehdy, pokud se management přesvědčí o výhodách, které mu business model poskytuje pro jeho řídící praxi a dosahování jeho osobních cílů.

Architektura podnikání má proto v praxi právě takový význam, jaký vezme na vědomí její vrcholový management.


[1] Michael James Melenovsky, Jim Sinur; BPM Maturity Model Identifies Six Phases for Successful BPM Adoption; 2006; studie
[2] Původní Gartnerův model zralosti byl syntetizován podle jeho dalšího upřesňování, jak probíhá v pracovní skupině OMG BAWG, dále byl doplněn o pravidla podnikání podle závěrů BRCommunity s přihlédnutím k reakcím na blozích J. Sinura a dalších a přeložen.
[3] John O'Connell, Jon Pyke, Roger Whitehead; Mastering Your Organization's Processes: A Plain Guide to BPM; 2006; ISBN 0521839750; kniha.
[4] Josef Basl; Architektura podnikání; BPM portál – téma měsíce, 1/2008; ISSN 1802-5675; článek.
[5] Dan Madison; Process Mapping, Process Improvement and Process Management; 2005; ISBN 1932828044; kniha.

Klíčová slova (anglicky): Business Model; Business Process Management; BPM; BPM Suite; Business Architecture; Business Modeling; BPM Maturity Model; CMM.

Shrnutí: Využití BPM v praxi předpokládá ujasněnou představu, jaká cesta podnik při jeho nasazování čeká. K tomu může napomoci model zralosti, který popisuje jednotlivé úrovně řízení, jak si je podnik při zavádění BPM osvojuje. Nezbytnou podmínkou však je nasazení business modelu a jeho postupné prosazení jako základu řídící praxe.

Standardní citace tohoto příspěvku: Václav Kalenda; Zralost architektury podnikání; BPM portál – téma měsíce, 1/2008; ISSN 1802-5675; URL: http://bpm-tema.blogspot.com/2008/01/zralost-architektury-podnikani.html

Více.....

Konference Process World poprvé v Praze

Konference ARIS ProcessWorld, největší světové fórum pro procesní manažery a top IT manažery, představí letos poprvé svůj tradiční mix teorie a praxe také v Praze. Druhá zastávka ARIS ProcessWorld on Tour 09, uznávané konference nejen o řízení podnikových procesů, se uskuteční 8. a 9. června v hotelu Corinthia Towers.

Pod heslem „Discover the Value of Business Process Management – Objevte hodnotu řízení podnikových procesů“ se účastníci z celé Evropy budou moci seznámit s nejnovějšími trendy v oblasti procesního managementu. Důraz bude přitom kladen na témata jako je podnikový BPM, Enterprise Asset Management (EAM. řízení podnikových zdrojů), procesní implementace SAP, Service-oriented Architecture (SOA), Process Intelligence a Performance Management či Governance, Risk & Compliance Management (GRC). Prostor dostanou jak praxí prověřené scénáře řešení, tak výsledky vědeckých výzkumů a samozřejmě i diskuse o nových výzvách v oblasti procesního řízení a IT.

Tak jako v předchozích letech budou mezi přednášejícími nejen specialisté ze společnosti IDS Scheer, ale také celá řada jejích partnerů a významných zákazníků z různých oblastí průmyslu a obchodu, mezi nimi například firmy jako Accenture, SAP, Oracle, E.ON, Akbank T.A.S., Infineon Technologies, Pepsico, SE Bordnetze – Slovakia, a Wyeth.

Společnost IDS Scheer sama na ARIS ProcessWorld on Tour `09 představí nové softwarové produkty ARIS, a seznámí účastníky se svými konzultačními přístupy a inovativními best practice, zaměřenými na zvýšení výkonu svých klientů. Kromě jiného bude také v Praze možné prakticky otestovat inovace stávajících produktů, které budou široké zákaznické základně k dispozici od září. Mezi nimi bude ARIS Governance Engine, ARIS Mashzone (mashup technology), ARIS Express (ARIS přístupný volně na internetu) and ARIS Process Performance Manager 5.0.

Společnost IDS Scheer ČR může nabídnout pro pražské zastavení speciální slevu, kdy vstupné na oba dny činí 450 euro (200 euro sleva), resp. 250 euro instituce veřejné správy. Více informací o této nabídce a speciální registrační formulář naleznete na www.ids-scheer.cz/processworld.

Více o programu naleznete na: http://www.processworld.com/.

Více.....

Pravidla podnikání

Pravidla podnikání (business rules) nejsou buzzword. Jsou tu s námi od nepaměti, stejně jako procesy. A byla byznysu tohoto světa zjevena takřka totožným způsobem, jako se to stalo u reinženýringu - manifestem (viz dole). Je-li Hammer praotcem BPR, je otcem zakladatelem pravidel podnikání Ronald G. Ross. A přichází se stejně geniálně triviálně tezí: Pravidla musí být abstrahována z procesů - procesy zůstávají, pravidla se mění podle podnikatelské situace.
Proč je toto doporučení tak zásadní a jak nám změní firmu, pokud ho budeme respektovat?

Více.....

Typy pravidel podnikání

Podle Rosse existují 2 typy pravidel pravidel:
- strukturální pravidlo - popisuje základní logiku podnikání a jako taková nemůže být porušeno, může být jen nepochopeno.
- operativní pravidlo - popisuje logiku rozhodování, vyjadřuje příkazy nebo zákazy a může být porušováno

Pokud tuto klasifikaci chceme prakticky použít v modelování a analýze podnikových procesů, musíme si ji rozšířit o metapravidla - které objekty, vztahy či jevy reálného světa budeme považovat za natolik relevantní, abychom se jimi zabývali.

Strukturální pravidla, protože zachycují základní logiku tvorby přidané hodnoty v daném oboru podnikání resp. procesu, jsou relativně konstantní, protože se mění výhradně se změnou podnikání. Naproti tomu operativní pravidla jsou dočasná, reagují na aktuální obchodní potřeby. Pokud operativní pravidla vyseparujeme z procesů a budeme je schopni rychle aktualizovat, budou naše procesy velmi trvalé a přitom vitální.

Podívejme se na hodně zjednodušený příklad posouzení žádosti o úvěr:

Finanční instituce může na základě informací v předložené žádosti buď úvěr poskytnout, odmítnout nebo si může vyžádat dodatečné informace. To jsou pravidla strukturální.

Operativní pravidla, kterých v praxi může být i několik stovek, jsme pro daný příklad zjednodušili na tyto:
- úvěr je poskytován pouze v rozmezí od 10 do 100 tis. Kč
- pro úvěry do 20 tis. Kč stačí, když žadatel nemá záznam v registru dlužníků
- pro úvěry od 20 do 50 tis. Kč musí mít žadatel navíc trvalý příjem
- pro úvěry od 50 do 100 tis. Kč musí žadatel předložit další podklady

Operativní pravidla, která tvoří vnitřní logiku rozhodování, mohou mít charakter:
- výpočtu. Logika výpočtu může být naprogramována a může být vysoce komplexní. Pokročilé systémy dnes využívají i fuzzy logiku. Velmi často se pro doplňování takovýchto pravidel používají analytické nadstavby nad datovými sklady využívající dolování dat a znalostí nebo jsou budovány systémy jako otevřené, které umožňují pravidla průběžně doplňovat či modifikovat podle rozšiřujícího se poznání a konkrétní obchodní situace.
- posuzování smyček a iterací. Např. žádost o úvěr nesmí být starší oproti doplňujícím údajům klienta o více než 10 dní.
- odvozování a vzájemných vztahů. Tato pravidla mohou sahat od jednoduchých otázek typu "Má tento klient u nás účet?" až po velmi komplexní vazby - pokud jde o opakovaný úvěr nad 50 tis. Kč, musí mít klient přiděleného osobního bankéře.

Právě poslední typ operativních pravidel je velmi zrádný. Kde končí operativní a začíná strukturální? Jde o trvalou business logiku nebo jen o obchodní rozhodnutí? Jde o otázku dost zásadní z hlediska BPM (např. pokud budeme modelovat výhradně strukturální pravidla a udržíme operativní logiku separátně, budou mít naše modely výrazně vyšší životnost a přitom budeme schopni rychle reagovat na obchodní požadavky) a IS (která logika bude "zadrátovaná", která customizovatelná a která vytvářená uživatelsky).

Pravidla vzájemných vztahů jsou zrádná ještě z jednoho důvodu. Často v sobě implikují závazky nebo podmínky, které nejsou ze zkoumané procesní logiky zřetelné. V našem případě např. ošetření vazeb mezi osobním bankéřem a bankou. Co se stane, když osobní bankéř dá výpověď?

Více.....

Vymahatelnost pravidel

Pokud základní rozdíl mezi strukturálními a operativní pravidly je v tom, že strukturální pravidla nemohou být porušena, stojí za to zkoumat i to, nakolik jsou operativní pravidla závazná a jaké sankce jejich porušení přináší. Existuje 6 úrovní vymahatelnosti pravidel, které lze samozřejmě kombinovat:

- absolutní pravidlo. Pokud je porušení pravidla zjištěno, vždy automaticky následuje trest.
- vyšší rozhodnutí. Porušení pravidla je oznámeno pracovníku s vyšší pravomocí a ten má právo udělit trest.
- oprávnění k porušení. Pracovník se specifickým oprávněním může pravidlo porušit.
- výjimky. Pracovník může v konkrétním případě výjimečně rozhodnout, že pravidlo poruší.
- zdůvodnění. Pracovník může pravidlo porušit, ale musí toto porušení zdůvodnit.
- doporučení. Pokud pracovník porušuje pravidlo, je mu to připomenuto.

Dobrou praxí je důsledné oddělování vlastních pravidel od nápravných procedur, které jsou spuštěny při porušení pravidla.

Více.....

Manifest pravidel podnikání

(The Business Rules Manifesto)
Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Article 1. Primary Requirements, Not Secondary
1.1. Rules are a first-class citizen of the requirements world.
1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them
2.1. Rules are explicit constraints on behavior and/or provide support to behavior.
2.2. Rules are not process and not procedure. They should not be contained in either of these.
2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product
3.1. Rules build on facts, and facts build on concepts as expressed by terms.
3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.
3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.
3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural
4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.
4.2. If something cannot be expressed, then it is not a rule.
4.3. A set of statements is declarative only if the set has no implicit sequencing.
4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.
4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.
4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.
4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc
5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.
5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.
5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation
6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.
6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.
6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
6.4. Rules are based on truth values. How a ruleís truth value is determined or maintained is hidden from users.
6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming
7.1. Rules define the boundary between acceptable and unacceptable business activity.
7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.
7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology
8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.
8.2. Rules always cost the business something.
8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.
8.4. More rules is not better. Usually fewer good rules is better.
8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People
9.1. Rules should arise from knowledgeable business people.
9.2. Business people should have tools available to help them formulate, validate, and manage rules.
9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms
10.1. Business rules are a vital business asset.
10.2. In the long run, rules are more important to the business than hardware/software platforms.
10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.
10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

Originál pravidel "The Principles of Rule Independence" je uveřejněn zde:
http://www.businessrulesgroup.org/brmanifesto.htm

Více.....