Rizika a rizikové faktory

Rizika se hodně často s rizikovými faktory pletou. Riziko je nahodilá škodní událost, rizikový faktor stav objektu nebo také událost, která zvyšuje pravděpodobnost, že riziko nastane. Kauzalita musí být prokázaná. A přesto riziko nastat nemusí. U žádného rizika nemůže být pravděpodobnost rovna jedné. Pak už nejde o riziko.

Mám spočítáno na dobré dvoustovce jízd, že na D1 za suchého počasí je pravděpodobnost ucpání kvůli bouračce 0,2. Za deště 0,45, za mlhy, sněhu a jiného nečasu dokonce 0,7. Počasí zde funguje jako jasný rizikový faktor. Dalším faktorem je čas. Pokud stihnu dojet do 6:15 k Jihlavě, je pravděpodobnost, že uvíznu, minimální. Vše samozřejmě v pracovních dnech.

Na tomto příkladu lze dobře demonstrovat další potíž spojenou s riziky a jejich počítáním. Pokud dojde k havárii, můžu se jen o nějakou hoďku zdržet, ale také mě může zezadu rozmačkat kamion, takže příště už bude psát blog jenom vdova. Jde o stejné riziko Incident na D1? Nebo jde o dvě různá rizika, protože mají zcela odlišné důsledky, byť stejné rizikové faktory a některé další znaky. Jakou používat terminologii a jaký zvolit analytický přístup? A máme postupovat při analýze od rizik k jejich rizikovým faktorům nebo naopak?

Tolik náměty k promyšlení, o dobrou praxi se podílíme v tématu měsíce. Tak ještě jeden kvíz na závěr. Tvrdím - ani počasí a ani čas nejsou na D1 nejsilnějšími rizikovými faktory. Jaký faktor to tedy je?

Více.....

Proč se pouštíme do řízení rizik

Do ucelenějších projektů řízení rizik se společnosti pouští ze 3 důvodů. První možností je ten, že rizika jsou pro společnost součástí jejího hlavního byznysu. Jde o všechny finanční instituce - od bank přes pojišťovny až po splátkové a leasingové společnosti. Druhou motivací pro spuštění projektu řízení rizik může být to, že nás některá rizika začínají nepříjemně ohrožovat nebo nám aspoň mohou zkomplikovat život. Třetí důvod je "pro jistotu". Sice se zatím nic mimořádného neděje, ale co kdyby.

U těch "co kdyby" rizik je velká potíž. S jejich kvantifikací. S odhadem jejich pravděpodobnosti i oceněním možné výše škody. U rizik, s nimiž má firma nějakou historickou zkušenost, jsou odhady přece jen snažší a reálnější (nejlepší zdroje dat o málo častých, zato pěkně škodících rizicích mají pojišťovny, které se právě jimi živí).

U projektů "pro jistotu" můžeme vidět dvě destruktivní tendence. První je snaha zmapovat rizika všechna, čím víc rizik, tím lepší projekt. Tendence druhá - velmi nepravděpodobná rizika raději nadsadit, ať je vidět, jak jsou nebezpečná. Tato rizika však mohou díky své obří škodě rozhodit celé ocenění rizik (stačí k tomu desetinka promile pravděpodobnosti) a poslat celou politiku řízení rizik pod drn. Protože nebudeme mít pro ní finanční zajištění.

Více.....

Rizika a nekvalita

Příští měsíc začínáme s tématem řízení rizik. V řadě společností se do rizik zahrnují dvě lehce nespojité oblasti - finanční rizika a havárie. Jakmile se začnou mapovat i ostatní rizika, začne vznikat mírný zmatek - co je riziko a co je nekvalita? Nebo přesněji - co je ještě nekvalita a co už je riziko?

Docela se mi líbí tato jednoduchá definice rizika: Nahodilá událost vedoucí ke vzniku škody v nebo z podnikání společnosti. Protože uvádí výčet 4 nejdůležitějších atributů rizika:

• riziko je událost
• tato událost musí být nahodilá (pravděpodobnostní)
• událost je škodní
• událost souvisí s podnikáním

Nekvalita je odchylka od standardu. Může vyvolat řadu rizik - chová se tedy jako rizikový faktor. V riziku je vždy obsažen prvek náhody. Když spadne do láhve šroubek, je možné, že si konzument:

• ničeho nevšimne
• šroubu všimne a přesto to nechá být
• bude stěžovat a celá věc se dostane do médií (reputační riziko)
• bude stěžovat a prodejní řetězec udělá z přejímky dodávek peklo nebo to využije k tlaku na snížení ceny
• šroub polkne a budou následovat soudy o náhradu....

Variant rizik plynoucích z tohoto jediného rizikového faktoru je mnoho a záleží na náhodě. Ano, tím nejzajímavějším na celém řízení rizik je nutnost pracovat s náhodností.

Více.....

BPM*blogání trochu jinak

Už je načase, abyste si také přečetli občas názor někoho jiného. Takže v rozporu s filosofií blogu jako osobního deníčku v BPM*blogu bude blogat lidí více. Uvidíme, co to udělá. Pokud byste se chtěli také přidat, napište mi (a pokud se neznáme osobně, přidejte pár řádek o sobě).

Více.....

Proces Řízení změn podnikání podruhé

Když už jsem nakousl proces Řízení změn podnikání, měl bych do něj zatnout zuby více. Je totiž pro firmu existenční. Musí být bezešvě napojen nejen na strategické řízení a business development, ale i na monitoring operativní výkonnosti a řízení rozpočtu. A na stranu druhou nejen na projektové řízení, ale i na řízení průběžného zvyšování výkonnosti, řízení kompetencí potažmo řízení organizačních změn a také na řízení rizik. Jde o nejkomplexnější proces ve firmě vůbec.

Za podstatné považuji dva aspekty, které často unikají. První. Ač jde o vysoce znalostní proces, přesto jde o proces. Tedy definovaný a řízený řetězec hodnototvorných činností, byť často nesekvenční ale holistický. A jako proces musí být popsán (namodelován), optimalizován, prováděn, měřen a trvale zlepšován nejen na základě zpětné vazby, ale i proaktivně.

Druhý aspekt. Jde o proces řídící. Tedy procházející napříč celou firmou, ostatními procesy, strukturami a zdroji, proces řídící jejich chování, nastavující jejich business pravidla.

Z druhého aspektu plyne, že tento proces (resp. usměrnění jím vynucená, byť vesměs dopředná) nebude příliš oblíben. Značně totiž komplikuje manažerskou zvůli a volby řešení cestou nejmenšího odporu. Činí průhledným hierarchii rozhodování a umožňuje nastavit vazbu na odpovědnost za takovéto rozhodování.

Nastavit takový proces ve firmě se může podařit jen s úplnou podporou jeho top managementu. Tedy managementu plně znalého BPM jako manažerské disciplíny a vnitřně ztotožněného s jejími zásadami. Šafránu je víc než takových firem. Pokud nepatříte mezi vyvolené, nezoufejte.

Tento řídící proces má smysl nastavit a využívat i po jeho jednotlivých částech (subprocesech). I to přináší obrovská zlepšení a zjednodušení. Je dobré začít tam, kde je to právě nejvíc zapotřebí nebo se napojit tam, kde už je část funkční (např. od projektového řízení dopředu). Business architekt společnosti však musí znát tento řídící proces celý, i když se implementuje jen jeho kousek. Aby později onen kousek zapadl do celku. Znát zde znamená - mít jeho to-be design.

Má ale Vaše společnost business architekta? A pokud ne, kdo se této klíčové role ujme?

Více.....

Proces Řízení změn podnikání

Dnes jsem si opět v jedné velké finanční instituci potvrdil, že metodické odtržení byznys útvarů a firemního IS&IT je spíše pravidlem než výjimkou. Dva různé nástroje, dvě odlišné metodiky modelování, dvě samostatné procedury řízení změny, které se potkají jen dvakrát - při zadání požadavku, který si IT překreslí do svých modelů. A podruhé při testování a náběhu, kdy už je cyklus změny podnikání úplně bez metavrstvy.

Někde se tato separace byznysu a IT docela pracně v posledních letech budovala. Odstínila totiž na jednu stranu informatiky od rozplizlých a neustále měněných požadavků, na stranu druhou dala jasný rámec pro odezvu na uživatelský požadavek - v čase i nákladech.

Ano, čím čitelněji a měřitelněji je stanoveno rozhraní, tím se zjednodušuje řízení procesu. Jenže tady nejde o dva separátní procesy ale o jeden end-to-end proces. Dokonce i tehdy, když máme vývoj IS outsourcován. Rozhraní může zůstat čitelné a měřitelné a přesto v něm nemusí probíhat zoufalá ztrátová transformace informací bez zpětné vazby způsobená nekonzistencí metodik a neexistencí společných pravidel a politik.

Chce to začít trošku jinde - od designu řídícího procesu Řízení změn podnikání.

Více.....

Chvála kolečka

Včera jsem naťukl téma kolečka - povinné stáže nového pracovníka v jednotlivých odborných útvarech. Zdá se, že jeho absence litují všichni. Noví lidé nemají ani přehledovou znalost toho, co kdo kde dělá a proč, zavrtání nového člověka přímo do jeho domovského týmu posiluje nebezpečí vzniku subkultur. Je také jasné, proč k tomu došlo. Není čas. Pokud je průměrná životnost specialisty ve firmě 36 měsíců, nemůže pětinu z této doby strávit neproduktivně. Potřebujeme ho přece teď a tady. Navíc - nemůžeme nového člověka pustit do kolečka dřív, než skončí zkušební doba, kvůli ochraně informací.

Ve skutečnosti největším nepřítelem povinného kolečka je střední management. Nemá zájem, aby se v jeho oddělení potuloval někdo cizí, kdo nepatří do party. Kdo jen vyžaduje pozornost, ničemu nerozumí, s ničím pořádně nepomůže a stejně - až se trochu rozkouká, půjde o dům dál.

Prosadit pro pracovníky povinné kolečko alespoň v rámci svého procesu je jeden ze stěžejních úkolů vlastníka procesu.

Více.....

Role pro BPM / SOA

Šéfanalytik od Forresterů Ken Vollmer nedávno definoval tři role, které musí být znalostně obsazeny, pokud chceme úspěšně propojit iniciativy BPM a SOA. Jsou to:

• business analyst - česky byznys analytik čili procesní specialista, který odpovídá za věcnou správnost řešení a návrh správných procesů podnikání
• service designer - česky vývojář služeb, který odpovídá za funkcionalitu jednotlivých služeb včetně jejich schopnosti naplňovat požadavky stanovené příslušnými politikami
• service architect - pro kterého nemáme zatím nejen ustálený český pojem, ale většinou ani žádné personální obsazení

Architekt služeb (?) má být odpovědný za přiřazení služeb jednotlivým činnostem v procesu včetně jejich kontextu a možná i za nastavení chování infrastruktury SOA, tedy definici příslušných politik. Nikoliv na technologické, ale na logické úrovni, protože tyto politiky úzce souvisí s celkovým konceptem řízení. Takže tento člověk potřebuje nejen velmi kvalitní technologický backgroud, ale i dost dobrý přehled o architektuře podnikání. Ideální architekt služeb je ten, který již zvládl roli jak procesního, tak IS analytika.

Což vzhledem k chybějícímu "kolečku" ve většině firem, při kterém pracovník prochází postupně odbornými útvary, půjde zařídit těžko.

Více.....

Kdo řídí outsourcera?

Hezká a vlídná vrátnice či recepce dělá s návštěvníky divy. Kupodivu není taková zdaleka všude. Zejména ne vlídná. Obzvlášť záludní bývají vrátní ve velkých business centrech, kde slouží pro více firem a tak si také více troufají. Navštívenou osobu je nutné požádat o vysvobození z recepce vlastním mobilem, též strpět vstupní přiskřípnutí v turniketu a při odchodu ponižující povykování, do kterého otvoru odhodit návštěvní kartu.

Nebudeme snad kvůli vrátným outsourcovat facility? Nebo strávíme pár hodin jejich skrytým pozorováním či najmeme pár studentů na mystery shopping, abychom poskytovateli takovýchto služeb mohli na konci měsíce napálit penále, pokud nám to uzavřené SLA dovolí? A kdo vlastně to udělá? Kdo řídí tohoto dodavatele? Ten, kdo je odpovědný za firemní kulturu? Sotva.

Protože i u cizí firmy je to o lidech a jejich kultuře. Máme-li my ve firmě jinou, než jakou prezentují vrátní našim zákazníkům, zřejmě nebude ideální hození plných kompetencí na našeho technika, který se přece stará i o naše auta, telefony, nábytek, kancelářské potřeby...

Více.....

Boj o granularitu služeb

Integrované BPM&SOA projekty nejsou jen idylou, kdy spojené síly byznys uživatelů a IT valí firmu k šťastným zítřkům. V těchto projektech na sebe také zájmy byznys analytiků a zájmy vývojářů IS pravděpodobně narazí. A hned při návrhu celkové architektury řešení - při volbě granularity budoucích služeb.

Obzvlášť je to patrné při "separaci" služeb ze starších IS. Informatik se při návrhu dá cestou nejmenšího odporu - pokud možno vůbec nezasahovat do kódu existující aplikace, do služby zabalit stávající procedury. Byznys analytik chce, aby služba měla nějaký byznys užitek jako taková - ideálně aby odpovídala definici činnosti (tedy její IS podpoře).

Příklad z praxe. V prastaré aplikaci napsané ještě v Cobolu chtěl IS analytik jako službu definovat Aktualizace adresy zákazníka, bynys analytik požadoval službu Aktualizace profilu zákazníka. Přičemž profil sestával nejen z adresy, ale i z jiných dat o zákazníku, která však byla mimo onen cobolovský systém.

Může tomu ale být i naopak. Pokud je původní systém budován objektově, bude IS analytik nutit procesního specialistu ke službám typu Aktualizace adres - tedy nejen zákazníků, ale i oděratelů atd. Samozřejmě by ideální byznys služba byla Aktualizace profilů volaná ve více procesech vždy s příslušným kontextem. Tu ale sotva navrhne vývojář, který zná především (nebo dokonce jenom, protože udržuje a má dokumentovánu v hlavě) onu cobolovskou aplikaci.

Více.....

Základní přínosy SOA

Asi by bylo užitečné zkusit stručně vyjádřit také přínos SOA pro BPM:

1. SOA vytváří abstraktní služby a tím je činí srozumitelnými pro byznys.
2. Služby je možné procesně uspořádat prostřednictvím byznys modelů.
3. Procesy takto realizované jsou monitorované a měřené procesně.

To, že SOA částečně skrývá složitost informačních systémů neznamená, že se komplexita IS snižuje, spíš naopak. Ale nemusí do ní pronikat byznys uživatelé. BPM v SOA získává implementační a měřené prostředí pro vládu nad celým životním cyklem procesů.

Více.....

Bílá procesní vrána

O tom, co je v BPM důležité více, co méně a co je úplně nejdůležitější jsem dnes přemýšlel celý den. Na konferenci IDS o procesním řízení ve státní a veřejné správě. Výborná organizace, účastníci ze všech klíčových institucí, pěkné přednášky. Ta nejlepší přišla nakonec. Tomáš Hüner, nestor restrukturalizace Severomoravské energetiky, aktuálně náměstek MPO a ředitel sekce pro průmysl a energetiku se vrátil k jádru konference. Poutavě, provokativně. Předvedl prototyp manažera (a nyní dokonce vysokého státního úřadníka), který už ví, o čem a k čemu BPM je a umí to sdělit.

Více.....

O čem je BPM

Na včerejší nářek nad složitostí a nepřehledností BPM jako manažerské disciplíny navážu parafrází prvního přikázání Jefa Immelta - každý business analytik musí umět jasně vysvětlit 3 klíčové věci, o kterých BPM je. Zkusím to:

1. Procesy - srdce firmy, které má přednost před organizační strukturou.
2. Řízení změn podnikání - od redefinice strategie přes redesign procesů a implementaci až po měření - vše v ucelené smyčce a na inženýrské bázi (business model).
3. Změna myšlení - k normalitě svobodných, odpovědných a spolupracujících lidí.

Moc s tím spokojen nejsem, zvlášť s č. 3. Vystihuje to možná lépe pojem "metanoia" (řec. metá=změna a noein=myslet).

Více.....

O nesrozumitelnosti BPM

V pátek jsem na semináři o procesním řízení dostal od jednoho z účastníků pěknou ťafku. Přišel k metodologii BPM teprve před několika týdny a nyní zkoumá, zda je to vhodný prostředek k řešení jeho podnikatelských problémů. A jak se pokouší v této oblasti samovzdělat, je silně zmaten - nalézá newspeek, kterému nerozumí, uzavřené myšlení, charakteristické spíš pro sektu než pro manažerskou disciplínu, zmatečné informace místo prakticky použitelných návodů.

Toto vyjádření je děsivě pravdivé. Z části zapříčiněné naší neschopností o BPM mluvit lidsky a manažersky srozumitelně. Z části dané objektivně tím, že opravdu jde o "novou" disciplínu a ta potřebuje svůj slovník a určitý objem znalostí k pochopení kontextu (viz článek BPM jako zkušenost). Své přidává i skutečnost, že výrobci a poradenské firmy newspeek používají jako marketingový nástroj a použitelné techniky dodávají jen v rámci svých draze placených služeb.

Především však BPM chybí pořádná sémiotika, možná ontologie vůbec.

Více.....

Vyluštění hádanky

Debata, která se strhla okolo identity onoho zlotřilého podniku, mě vyděsila. Že nás manažeři těch tipovaných podniků zažalují, v lepším případě že si v oněch firmách už nadosmrti nezakonzultačíme. Naštěstí jsem diskusní board nesledoval, takže jsem nemohl podlehnout chuti ho zatípnout (a až příště zase něco podobného napíšu, už si nechám názory přeposílat pro jistotu na mobil).

Zadání hádanky nebylo, přiznám se, nějak obzvlášť propracované. Ale úloha řešení má. Je fantastické, jak zodpovědně a analyticky k jeho hledání diskutující přistoupili. Velmi rychle vytáhli podstatné:

1. Jde o velkou firmu s řadou poboček po celé zemi - hledání proto omezili na TOP100, později rozšířili na TOP500. Poznámka - ta firma mohla být i v jiné zemi než Česku, vyloučené to v textu nebylo. Ale budiž.
2. Jednotlivé závody vyráběly různé produkty a jen částečně na sebe navazovaly.
   V začátku diskuse jsem napověděl, že jde o služby.
3. Firma měla monopol.
4. Každý závod měl nejen vlastní podpůrné procesy, ale i IT.

Padly tipy fakt zajímavé - banky, energetiky, telekomunikační firmy, železnice, lesy, pošta, speciální stavební firmy, televize... Návrhy byly vlastně průběžně oponovány a negovány, protože nesplnily některé z kritérií.

Samozřejmě moje hádanka měla nějakou souvislost s probíraným tématem SOA. A to zmatení jazyků. Stačí v daném kontextu zaměnit jedno slovo a vyluštění je na světě. Jediné slovo vytvořilo hranici myšlení, za níž bylo řešení vnímáno jako nepřípustné.

To slovo je "podnik". Tím "podnikem" jsem myslel stát a ostatní si dosadíte sami. Radši ani nebudu číst, jaké se teď na mou hlavu snesou od diskutujících kletby:) Berte to jako mou převíkendovou rozpustilost.

Více.....

Hádanka

Byl jeden převeliký podnik. Měl několik po zemi spoustu roztroušených závodů a každý z nich měl svůj vlastní nákup, personální služby, účetní a daňaře, údržbáře zařízení i areálu a samozřejmě své vlastní IT oddělení s vlastními aplikacemi. Ony ty závody nedělaly tak úplně totéž ba ani společně nevytvářely homogenní navazující a zhodnocující řetězec. Přesto spoustu informací nejen navzájem sdílely, ale dokonce řada end-2-end procesů procházela více závody. Když vrcholový management vymyslel nový produkt, hned se toho některý ze závodů ochotně ujal. Přijal lidi, naplánoval činnosti, zajistil si na všechno peníze v rozpočtu, nechal vyvinout informační systémy, vytrénoval lidi. Lidí bylo však pořád málo, protože procesy vznikaly a měnily se chaoticky, výše postavení pracovníci lpějící na tradicích seděli pevně na svých židlích a metodou znalostních monopolů uměli odstavit ze hry i úsporné nápady vrcholových manažerů. K zákazníkům se chovali všichni zaměstnanci podniku lehce arogantně, protože to, co podnik dodával, se jinde na trhu koupit nedalo.

Ten podnik dosud nezkrachoval. Otázka do pléna - jak se onen podnik jmenuje?

Více.....

Apologie SOA

Nedalo mi to - musel jsem se s ostatními čtenáři podělit o Pucherovu kritiku SOA. Nejen pro její obsah, ale i pro její formu. Zkusme probrat nejprve věcná (?) tvrzení. Vypíšu je v pořadí, jak je do nás pere sám autor:

1. SOA nevede k obchodní pružnosti, protože sice vyváže uživatele ze svázání aplikacemi, ale sváže ho svými službami (navíc v Javě).
2. SOA je jen prázný marketingový pojem.
3. SOA je slepá ulička objektové orientace, protože metadata jsou v souboru (XML) a ne v databázi a chybí prostředky pro řízení životního cyklu.
4. Procesní fragmenty podpořené proprietárními aplikacemi není schopna SOA defragmentovat. Blátivá koule nepřestane být blátem tím, že ji rozdělíme na více malých kuliček.
5. SOA je myšlenkovým pokračovatelem Taylorismu postaveném na specializaci a pevném řízení. Procesní modely zachycují jen povrch procesů, jejich podstata tkví v nezachytitelné dynamice podnikání tvořené komunikací v mnoha vrstvách.
6. Uživatelé chtějí sami řídit způsob své práce, což SOA činí velmi složitým.
7. Uživatele zajímá jen rozhraní a chtějí nesmyslnou dostupnost systémů, kterou neumí využít.
8. Business intelligence je posvátná kráva - tupná, protože kodifikací se znalost zničí. Skutečné znalosti mají emoční vrstvu, proto jejich hodnota vysoce převyšuje pouhá logická pravidla.
9. Zdánlivá jednoduchost SOA se v technickém řešení ukazuje jako nesmírně komplikovaná.
10. SOA má kvazistandardy, které činí zákazníka závislého na konkrétním dodavateli.

K tvrzením 5, 6 a 8: Jako červená niť se námitkami táhne úvaha - chybou už je byznys proces strukturovat, už jen tím je mrtý. Jenže právě tato premisa je chybná, protože nebere v úvahu rozdílný charakter procesů - od znalostních (kde platí plně) až po datové (kde neplatí vůbec).

K tvrzením 1, 4 a 9: Pucherovi zde nahrává i empirické zjištění o poměrně malé míře znovupoužitelnosti komponent - uvnitř podniku se pohybuje od 10 do 30%. Jenže kouzlo SOA je v jednotném způsobu integrace těchto blátivých kuliček.

K tvrzení 3: Které se také v textu několikrát objevuje v různé podobě - totiž že SOA není architektura dostatečně strukturovaná, resp. její technické implementace umožňují značně heterogenní řešení. Inu - OO databáze také skončily na smetišti a nic jim platná nebyla jejich konceptuální dokonalost.

K tvrzení 2: Dá se skoro souhlasit. Jenže poučení uživatelé tohle dávno ví a počítají s tím. Pokud integrační projekty SOA nebudou schopné vykázat ROI, nebudou už dnes schvalované. A ROI nevykážou, pokud nebudou zacíleny na konkrétní byznys problém a nevyužijí prostředky BPM.

K tvrzení 10: Hra o standardy je jedna z nejúčinějších forem konkurečního boje v technologiích. V praxi se prosazují řešení založená na nejmenším společném jmenovateli a tuto podmínku SOA splňuje bezezbytku.

Více.....

Něco málo o bíplu

Kouzelný jazyk BPEL - můžeme ho vizualizovat, můžeme ho spustit. Slušný byznys analytik se však k němu raději ani nepřibližuje - kódování už je přece práce pro ajtíky! My pracujeme na jiné úrovni abstrakce. Nejméně o dvě patra výše, maximálně ještě tak BPMN.

Bohužel BPEL nesnáší ani IT lid. Především proto, že si v obecném standardu neumí poradit s transakcemi, databázemi a ani s jinými službami než webovými. Hodí se leda tak na řízení dlouhých asynchronních toků dat, kde se vyžijete ve větveních, cyklech nebo ošetření výjimek. Nyní po přidání 4P (for people) sice zvládne i interakce s uživateli, ale stále postrádá podporu přímého měření. Navíc každý producent má stále svou lehce doplněnou verzi. A implementační platforma (engine) může s BPEL pracovat taky různě (někdy je přímo interpretován XML, někdy je XML před spuštěním zkompilován).

Můj názor bude znít drsně - pokud od IT analytiků chceme, aby přečetli naše notace byznys procesů (EPC/BPMN...), musíme umět přečíst my ty jejich. A BPEL je na řadě první. Možná, že pak také do byznys modelů nenamalujeme takové hlouposti.

Více.....

Registr služeb

Další slůvko, které bude možná vyvolávat neporozumění mezi lidmi z byznysu a lidmi z IT, je pojem repository. Jednou z charakteristických vlastností SOA je, že má služby katalogizovány v centralizovaném repository metadat, ze kterého jsou podle nastavených politik generovány a distribuovány jejich instance. Čili registr služeb.

Business model je také uložen v repository. Také představuje metadata. Jeho základem jsou business modely (nejen procesů, ale i dalších důležitých byznys struktur a jejich vazeb na procesy). V nějakých manažersky čitelných notacích (komplexně x typů modelů ARIS, pouze procesně BPMN, o UML nemluvě). Plus v 2. generaci BPMS ony struktury potřebné pro propojení se světem IS - definice pravidel podnikání a importované repository dostupných služeb (WSDL), abychom z procesního byznys modelu mohli vygenerovat spustitelný popis procesu v BPEL, který předáme run-time platformě SOA.

Jak by to bylo krásné, kdyby to bylo takto jednoduché. Onen registr služeb v infrastruktuře SOA není bohužel úplně tentýž, ze kterého přiřazujeme služby do byznys procesu. Je zde zásadní rozdíl v potřebné granularitě, ale i v nastavení podmínek pro služby (přiřazení dat atd.). A tak se pro potřebu byznys procesů provádí určitá abstrakce služeb, abychom se z přiřazování nezbláznili.

Více.....

Jak přeložit governance?

Moudří nepřekládají. Když nemusí. Pojmu governance jsem se už dotkl, když jsem uvažoval o rozdílech mezi vnímáním určitých pojmů byznys a IS lidem. Máme u něj na výběr tyto české pojmy: vládnutí (což zní strašně), politika, řídící akty, správa, řízení... Jedno je jisté - pojmy SOA governance a BPM governance bychom neměli přeložit stejně. Protože:

U SOA governance jde o - cituji: "řízení služby v průběhu jejího celého životního cyklu počínaje návrhem a vývojem přes nasazení a provoz až po vyřazení služby z používání" (viz popis technické implementace SOA governance od Jiřího Melichny). Čili vnucení určitých pravidel (politik?) jednotlivým službám plus jejich celková správa. Protože jak pravil klasik analytik Plummer: "You only need one service to destroy your business."

A o co jde u BPM governance? Není to jen organizačně-kompetenční začlenění procesního pohledu a systémového řízení změn do struktur firmy, ale promítnutí BPM do celého systému řízení. Cítíte ten řádový rozdíl mezi SOA a BPM governance?

Na slušné SOA governance potřebujete především dobré nástroje plus trochu metodiky. Budiž zde slovo politika namístě. BPM governance nevynutíte žádnými nástroji. Ba ani jenom řídícími akty. BPM governance rovná se totiž samotný systém řízení.

Více.....

BPM je manažerská disciplína

Včera jsem jen tak naokraj napsal výše uvedené tvrzení a nečekal jsem, že se mě hned dnes uraženě jeden manažer zeptá, jak jsem to myslel. Zda když neumí BPM, není dobrým manažerem. Inu když někdo neumí anglicky, taky může být dobrým manažerem. Jen do té doby, než jeho firmu koupí zahraniční investor a bude chtít reportovat v jazyce, kterému rozumí. Nebo dokud firma nebude mít přímé zákazníky tamtéž. S BPM je to dnes hodně podobné. Řídící architekturu není třeba dělat sofistikovaně, stačí ji udržet v hlavě. Dokud se firma nerozroste. Zlepšení je možné dělat intuitivně. Dokud se nesáhne na dno rezerv a na strop rizik. I IT je možné ponechat vlastnímu životu a čekat, jaké služby nám naservírují. Bez BPM jde skoro všechno. Jen většinou o dost hůř.

Více.....

Proč SOA touží po BPM a naopak

Proč vlastně IT se svou metodologií (či spíše architekturou) SOA tak touží po spojení s BPM, čili s čistě manažerskou disciplínou? Za prvé - aby vůbec mohla navrhnout smysluplné služby. Dokonce aby mohli vývojáři stanovit správnou granularitu služeb. Protože pokud udělají služby jemné, je sice větší šance na jejich znovupoužití někde jinde, ale jednak zvýší složitost jejich zapojení do byznys procesu, jednak mohou při jejich návrhu pominout nějakou podstatnou byznys logiku, kterou už v orchestraci služeb nedoženou. A je po integraci.
Je-li první důvod technický, je ten druhý politický. Máloco je dnes tak pozorně top manažery sledováno jako ROI informatických projektů. Už nelze šetřílky přesvědčit měkkými přínosy či nutností jednotné IS/IT architektury či bezpečností. Nalepením IS projektu na konkrétní byznys problém (či lépe výzvu) tato zdůvodňování padají na hlavu liniového managementu.
Z druhé strany je politická motivace také jasná - změny procesů bez možnosti jejich promítnutí do IS jsou nejen bezzubé a demotivující, ale často předem mrtvé. Přes lidi a jejich řízení se dá dokázat mnoho, ale ne natrvalo.
A ta technická motivace je taky jasná - malovat modely, které už v okamžiku jejich vzniku mohou být nepravdivé, je frustrující.
K vzájemnému propojení obou světů dochází v konceptuální technické vrstvě, kdy se napojují jednotlivé služby na reálné činnosti (byznys funkce). A jsme zpátky u granularity služeb, která musí být výsledkem shody byznys a IS pohledu. Z hlediska přínosu byznys analytika je výsledek součinem dvou jeho kompetencí - analytické schopnosti udržet správnou podrobnost a věcné znalosti podstaty konkrétního byznysu. Čili z hlediska požadavků na analytiky nic nového, tohle se už po nás chce přece dávno. Jenže pokud dřív naše modely snesly (skoro) všechno, teď to na nás praskne.

Více.....

Jak se byznys a IT v BPM potkali

Možná že nebude na škodu trochu si připomenout, jak vlastně došlo k prolnutí aktivit řízení změn byznysu a řízení vývoje IS v druhé generaci BPMS.

Inženýrské řízení změn byznysu se zaměřením na procesy začíná někde v osmdesátkých letech minulého století u systémů na zprocesování dokumentů, které dále pokračuje ve vývoji do workflow systémů. Nezávisle se v té době objevují i ucelenější frameworky a první nástroje na modelování nejen do té doby obvyklých datových struktur, funkčních rozpadů a informačních toků, ale i procesů. Procesní pohled je silně pod vlivem reinženýringových přístupů, na přelomu tisíciletí změkne a obrátí svou pozornost k celému životnímu cyklu procesu (CPI - trvalé zlepšování) a integruje řadu obdobných metodik (SixSigma, Kaizen, Lean, TOC...). Dnes je tato větev reprezentována nástroji BPMS, které dávají do popředí lidský faktor (human-centric) a metodikami kladoucími důraz na kompetence a systém řízení.

Vývoj ze strany IT tlačený v devadesátých letech nasazováním komplexních ERP (a následně CRM, SCM...) se kolem roku nula začíná zaměřovat na vzájemnou aplikační integraci (EAI), která má už částečně procesní zaměření. Objektová orientace ve vývoji postupně směřuje výš -ke kompozitním aplikacím, které mají již většinu parametrů dnešních služeb, které můžeme nezávisle použít pro podporu procesů. Tato vývojová řada dává do popředí integrační roli (integraton-centric) a částečně i zaměření na automatizaci procesů s využitím pravidel.

V BPM 2.0 se tyto větve spojují v jednotné repository - společném úložišti metadat. Obě větve - byznysu i IS musí ve svém životním cyklu řešit stejné fáze - design, implementaci, provádění a měření. A opět - v druhé generaci BPMS máme v celém životním cyklu repository jednotnou. V jádru leží procesy - přesněji byznys procesy. Což je také důvod, proč moudré IT firmy tolik volají po nutnosti využít pro implementaci SOA management procesů. Byznys procesů.

Více.....

Není pravidlo jako pravidlo

Naposledy jsem psal o tom, že byznys proces jako sekvence tvorby přidané hodnoty není (většinou) totožný s IS procesem tvořeným informačním tokem nebo sekvencí zpráv předávaných mezi službami. Čili příklad zmatení jazyků mezi byznys analytiky a ajtíky. A máme tady další slovo se sémantickým problémem - business rules, česky pravidla podnikání. Jak už v několika příspěvcích na tomto webu zaznělo (např. zde), pod pravidly si také něco jiného představují informatici a něco jiného manažeři. Pro IS musí být pravidlo formulováno do automaticky vyhodnotitelného tvaru na základě existujících dat (pocházejících např. z BI) nebo jiných pravidel (v poslední době se objevily BRE, které již umí i fuzzy logiku).
V pochopení manažerů jsou pravidla podnikání cosi, co se daleko více blíží k pojmu governance či politika - vymezený rámec případně doplněný úrovní vymahatelnosti. Ty raději uvedu:

• 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.

Proto na závěr opět malé doporučení pro byznys analytiky - pokud se chcete domluvit s ajtíky, nemluvte o pravidlech, když máte na mysli zásady. Používejte pojem politika, tomu rozumíte stejně.

Více.....