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