Aktuality ze světa BPM (39. týden)

Procesy a pravidla jsou dvě strany téže mince, říká Paul Harmon. Jejich společné používání může výrazně zjednodušit modelování a přispět k vyšší pružnosti procesů. Bruce Silver předpovídá další vývoj v oblasti ucelených platforem BPMS - budou rozšířeny o integrovanou správu datových modelů, pravidel podnikání a ukazatelů výkonnosti.

Paul Harmon: BPMN a pravidla podnikání
Namodelovat v notaci BPMN některé možné průběhy procesů může být velmi složité, zejména pokud obsahují řadu možných podmínek, podle kterých se větví. Přitom pokud tyto podmínky zachytíme v podobě pravidel a včleníme do rozhodovacích operátorů, ušetříme si složité konstrukce a zpřehledníme modely. Problém je, že lidé, kteří navrhují design procesů a lidé, kteří definují rozhodovací procedury, jsou často jiní. A ti se musí při takovémto přístupu potkat a domluvit.
zdroj: Business Process Trends Advisor, Volume 6, Number 16

Bruce Silver: Novinky v BPMS
Největší pokrok v BPM v posledních letech je spojení dříve odělených světů business analýzy (BA) a informační architektury (EA) do uceleného nástroje, který při designu procesů pamatuje i na jejich implementaci v informačních systémech. To se neobešlo bez kompromisů z obou stran - složité komplexní notace byly nahrazeny triviálním standardem BPMN, který sice nedovoluje zachytit všechny souvislosti architektury podnikání, ale je na druhou stranu dobře čitelný jak pro odborné uživatele, tak pro IT specialisty. A je poměrně jednoznačně převoditelný do spustitelné podoby. Takto ořezaná funkcionalita modelování ale postrádá 3 základní dimenze, bez kterých se do budoucna BPM jako manažerský prostředek neobejde - datové struktury, pravidla podnikání a ukazatele výkonnosti. A to vše v jednotném repository, kde budou sloužit jak ve fázi designu, tak ve fázi run-timu.
zdroj

Více.....

Aktuality ze světa BPM (37. týden)

David Frankel, který je zástupcem společnosti SAP v jedné ze dvou pracovních skupin BPMI.org, která připravuje 2. verzi standardu pro byznys modelování BPMN, referuje, jak postupují práce. Howard Smith zkoumá, jaký posun zaznamenaly komplexní BPM nástroje (BPMS) v letošním roce. Smysluplné nasazení BPMS nástrojů může podle Smity Sharmanové nastat jen ve firmě, která je na přijetí této technologie připravená. Christina Dickenová a Kirk Gould upozorňují, že procesy jsou možná těmi nejdůležitějšími nehmotnými aktivy, které společnost vlastní. Victor Howard a Clay Richardson považují vytváření pomínek pro kreativitu za jeden ze zásadních prvků firemní kultury.

David S. Frankel: BPMN 2.0
BPMN 2.0 má napravit tyto nedostatky předchozího standardu:

• bude obsahovat metamodel
• zahrne výměnný formát pro přenos modelů mezi různými nástroji (nahradí tak dnes převážně používaný formát XPDL)
• sémantika provádění procesu bude jednoznačná
• doplní prostředky pro choreografii a orchestraci procesů (zejména využitím plaveckých drah a bazénů)

Novou revizi lze očekávat během listopadu 2008. zdroj

Howard Smith: BPMS v roce 2008
Mapování a design procesů vyžaduje čas a náklady. Tyto náklady jsou dvojí - jednak na samotnou technickou změnu, jednak náklady na čekání, než se projeví výsledek. To nástroje BPMS radikálně mění - snižují požadavky na implementaci a přináší výsledky v reálném čase. Jenže vnímání procesů, které tečou napříč společností, není IT specialistům, kteří se celý svůj život věnovali vývoji funkčních celků, vlastní a snadno pochopitelné, potřebují kvalifikovaného partnera. A tak vidíme evoluci super uživatele z původního partnera programátora k architektu a dále až k manažeru změn. Platformy BPMS jsou již technologicky zralé. Kdo však znalostně zralý není, jsou ti, kdo je mají nasazovat. zdroj

Smita Sharmanová: Jak se pustit do BPM správně
Dobrá praxe velí využít tento postup:

• vzdělání - pro vrcholové i liniové manažery k pochopení základních principů procesního řízení a vytvoření uceleného systému řízení změn
• strategické zacílení BPM iniciativ
• mapování procesů, IT zdrojů a vyhodnocení dodavatelů BPMS
• nasazení BPMS na konkrétní řešení
• průběžné zlepšování

BPM je také manažerská disciplína, nejen zázračná technologie. Proto se jí bude dařit jen v procesně orientované společnosti s otevřenou kulturou. zdroj

Christina Dickenová, Kirk Gould: Procesy jako aktiva
Možná právě proto někteří manažeři procesy tak přehlížejí, že se jim neobjevují v jejich finančních výkazech, že nejsou voláni k zodpovědnosti za to, jak hodnoty jimi tvořené využívají a zhodnocují. Pokud se naučíme procesy jako aktiva počítat, získají automaticky respekt manažerů. zdroj

Victor Howard, Clay Richardson: Atmosféra pro inovace
BPM jako manažerská disciplína v sobě zahrnuje řadu technik pro rozvoj kreativity, která je nutná k překonání existujících omezení. Řada z nich je velmi jednoduchých:

• smějte se a podporujete uvolněnou atmosféru
• ponechávejte svobodu pro experimenty
• udržujte jednoduché (přímočaré) myšlení
• provokujte využití ostatních smyslů (vůně, hmat, chuť...)
• vytvářete pozitivní(!) konflikty

zdroj

zdroj: BPTrends

Více.....

Znalostní a datové procesy versus SOA

Je vhodné čas od času připomínat, že existují dva různé koncepty uplatnění BPM v systému řízení:

• První - strukturální - přistupuje k procesům jako k něčemu, co musí být definováno (a popsáno čili namodelováno) a následně realizováno (mj. také v IS), poté měřeno a podle výsledků znovu zlepšováno.
• Druhý - kolaborační koncept - říká: Definujme cíle, vytvořme vhodné prostředí včetně nutného omezení (pravidly) a nechme inteligentní lidi, ať cestu najdou sami.

Je jasné, že konkrétní přístup musí být volen podle charakteru procesu (znalostní procesy vyžadují kolaborační prostředí, ale třeba logistické strukturální) a že oba koncepty se vzájemně doplňují, nikoliv vylučují. Co je jasné méně? Že i znalostní procesy musí být součástí business modelu společnosti (BMS), pokud má sloužit jako platforma EA. A tedy že v BMS musíme mít různé formy zachycení znalostních a datových procesů. Nejen z hlediska úrovně detailu, ale i z hlediska jejich řízení.
Fórek je v tom, že v BPMS 2 běží oba typy procesů na stejném procesním serveru (ve stejném jazyce BPEL) a se stejným monitoringem. A tudíž že granule služeb pro datové procesy musí být mnohem menší a že naopak parametrizace služeb pro znalostní procesy musí být řádově širší. Což se nestane, pokud k tomu business analytici IT analytiky cíleně nenavedou.

Příspěvek byl poprvé publikován před dvěma roky.

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.

Příspěvek byl poprvé publikován před dvěma roky.

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.

Příspěvek byl poprvé publikován před dvěma roky.

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.

Příspěvek byl poprvé publikován před dvěma roky.

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.
Příspěvek byl poprvé publikován před dvěma roky.

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ů.
Příspěvek byl poprvé publikován před dvěma roky.

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?
Příspěvek byl poprvé publikován před dvěma roky.

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.
Příspěvek byl poprvé publikován před dvěma roky.

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.
Příspěvek byl poprvé publikován před dvěma roky.

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í.
Příspěvek byl poprvé publikován před dvěma roky.

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ůř.
Příspěvek byl poprvé publikován před dvěma roky.

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.
Příspěvek byl poprvé publikován před dvěma roky.

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ů.
Příspěvek byl poprvé publikován před dvěma roky.

Více.....

Byznys proces není IT proces

Už to musím napsat naplno. K expresi mě popíchl kolega z branže Ota na nedávném setkání BPM, kde se sešli ajtíci a bépémkáři.
Prapříčina toho, že si byznys uživatelé a potažmo byznys analytici nemohou porozumět s informatiky, je zásadně odlišné vnímání pojmu "proces". Tématem dalšího měsíce má být vztah BPM k SOA jako východisko k porozumění potenciálu druhé generace BPMS. A problém bude i s transpozici dalších původně byznys slov v IT prostředí - governance a compliance. Začněme ale u procesu a u češtiny. "Business process" překládáme česky jako proces podnikání, podnikatelský proces, přituple jako byznys proces, zkráceně prostě jen jako proces. Informatici s oblibou tento pojem překládají jako "podnikový proces". Což je ovšem řádově jinde, protože záměnou pojmu byznys za pojem podnik jsme současně zaměnili přidanou hodnotu jako základní atribut procesu za přináležitost k organizační struktuře. Čili pak je procesem všechno, co se ve firmě děje. V lepším případě opakovaně a organizovaně, v obzvlášť ujetém vnímání naprosto cokoliv včetně nahodilostí, jednorázových záležitostí a časově nesouvislých aktivit.
V ICT pojetí je procesem třeba informační tok či ve slovníku SOA tok zpráv. A systém monitoringu nám může zmapovat a graficky znázornit tento tok zpráv mezi jednotlivými službami včetně jeho uživatelských interakcí. Čili zobrazit proces. Myslí si informatici. Jenže možná ten podnikový, určitě ne ten podnikatelský - byznys proces. Přidaná hodnota ve většině branží se netvoří pouhým informačním tokem.
Takže křičím hlasitě na všechny byznys analytiky a osvícené manažery - Vaše procesy jsou úplně jiné procesy, než o jakých mluví informatici. Tento blog je určen Vám, ne informatikům. Bude podstatně náročnější vysvětlit informatikovi, co je přidaná hodnota, jak a kde se do ní transformují vstupy a co tyto vstupy jsou a jak je sekvence těchto transformací uspořádána v čase do řetězce zvaného (byznys) proces. Než vysvětlit Vám, abyste už nikdy neříkali před ajtíky pouze slovo "proces", ale vždy s adjektivem byznys nebo podnikatelský. A současně abyste informatikům odpustili to "znesvěcení" procesů, protože už s tím stejně nic nenaděláme. A nepokoušejte se v IT procesech hledat (vždycky) přidanou hodnotu.
Pokud si chcete vzájemně porozumět.
Příspěvek byl poprvé publikován před dvěma roky.

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

Příspěvek byl poprvé publikován před dvěma roky.

Více.....

Co ještě BPMS neumí pořádně

Pracovat s dědičností. Při designu procesů jsme na tom skoro jako při vývoji IS. Spousta procedur či dokonce subprocesů se opakuje, ale v různém kontextu, s jinými I/O a organizačními parametry. Pokud však chcete začít při modelování využívat pokrokových objektových metod, které vám zjednoduší modelování, dostanete se brzy do pasti - místo přehledné procesní linie odskakujete na různých místech a hloubkách a zase se vracíte nebo se začnete utápět ve scénářích a variantách. Nakonec zjistíte, že přehlednost je důležitější než eliminace duplicit, pokud chcete udržet jednotné analytické úrovně.
Příspěvek byl poprvé publikován před dvěma roky.

Více.....

Co BPMS neumí pořádně

Je podivuhodné, jak se rozrostla během několika let funkcionalita BPMS a jak málo se zlepšily schopnosti těchto nástrojů něco z podnikové reality jednoduše a pohodlně zaznamenat. Dodnes není na trhu modelovací nástroj, který by uměl generovat automaticky obstojný vzhled u složitějších diagramů. Nebo je to tím, že naše modely jsou pořád zbytečně složité?
Příspěvek byl poprvé publikován před dvěma roky.

Více.....

BPEL4People

BPMN resp. BPD mi nějak nechce přirůst k srdci, i když se velmi snažím. Těch několik málo objektů s ne zcela přesně vymezenou definicí na jedné straně zoufale svazuje, na straně druhé umožňuje namodelovat ještě větší zvěrstva než notace klasické (UML, EPC...). BPEL je jiné kafe. I když máte k dispozici jeho grafickou prezentaci (třeba v ARISu nebo v Intaliu), nemáte absolutně kam uhnout. Je to exaktní popis doslova programových kroků. Jenže to manažery nezajímá a nakonec byznys analytiky taky ne. Pro pochopení procesní logiky a případně její narovnání nemusím vědět o každém krůčku, naopak mi to může značně překážet. Takže abstrakce nedůležitého a sdružení podobného je pro analýzy nutná. Když do BPEL přidáme ještě dalších 30 nebo možná 50 příkazů pro interakci, vůbec si směrem k syntéze nepomůžeme. Naopak. Nevěřím, že BPEL (ani ten pro lidi) vytlačí abstraktnější notace. Ledaže by konečně někdo začal znovu přemýšlet, co lze z byznys pohledu vypustit a co sdružit (tak jako to bylo kdysi možné v ARIS4SAP u EPC). Přímou cestu takové syntézy mezi BPMN a BPEL ale nevidím.

Více.....