OldJoe: Takže: obecně k referenčním modelům - poprvé jsem zařídil nákup RM od IDS v r.1998 . A od té doby mám k RM spíš diplomaticky řečeno "zdrženlivý" postoj. Je nyní něco na poměry dříve popsané firmy reálně použitelné?
kalenda: Omlouvám se, o který RM šlo?
OldJoe: Šlo o referenční model SAPu (tehdejší).
kalenda: Chápu, model SAPu od IDS nebyl určen k business modelování, ale pro podporu implementace. A ani pro to se pořádně nehodil, protože byl (a dodneška je) striktně procedurální, vymodelované transakce, bez business vrstvy. Tam, kde by měly být procesy, tak jsou funkční bloky.
Proces: Jaké zkušenosti máte s využitím RM? Já jsem je používal spíše marketingově a pro prezentaci záměrů. Vždy jsem měl představu, že RM byl měl sloužit k rychlé analýze odlišností od standardu. Na to však jsou potřeba RM asi jiné.
kalenda: Ano, akviziční použití RM je nejúčinnější:) Ale třeba SCOR je prakticky opravdu využitelný - máte tam univerzální metriky... Co je vždy u RM kruté - že ho (skoro) nikdy nemůžete použít bez "překreslení" do Vaší metodiky.
Proces: Existují RM (standardy) pro běžné agendy (účetnictví, mzdy, nákup apod.)? Jak je to s pracovními náplněmi, nebo funkčními místy?
kalenda: Obzvlášť slušné jsou modely pro společnosti využívající SAP. V RM, které jsou v ARIS, je organizační pohled vždy jen na úrovni rolí (třeba v Adonis je daleko lepší vazba na organizační struktury). Třeba přímé propojení na databáze Mercer.
Referenční model řízení znalostí
OldJoe: Takže možná zpět k původním otázkám – existuje referenční model KM?
kalenda: RM KM je otevřený projekt několika společností, které KM prakticky využívají. Co obsahuje - procesní pohled zejména správu znalostí (vyhledání zdrojů, očistění, uložení, distribuce, sdílené...). RM KM - ten obsahuje navíc velmi kvalitně zpracované struktury znalostí pro BPx.
cfk: Je RM KM, o ktorom hovorite, niekde pristupny?
kalenda: Pouze pro členy IIBA a tam je členství na bázi workgrupy, která to spoluvytváří. Ale teď bude vydán handbook, kde bude publikován znalostní manuál.
fram: Mluvíte o RM pro řízení znalostí. Dovedu si představit RM pro pořízení, uchování, správu a distribuci znalostí, správu kompetencí apod. Charakterem se jedná však o modely velice měkké, které vyžadují mnoho zkušeností.
kalenda: Procesní model pro správu znalostí je opravdu triviální nebo naopak velmi podrobný, pokud zachycuje i IS implementaci. Tam není jeho jádro. Jeho hodnota je v základních znalostních strukturách, které definuje a které se osvědčily jako hodnototvorné pro příslušné procesy.
fram: Existuje tedy model znalostních struktur pro jednotlivé procesy?
kalenda: Pomalu to k němu spěje. Provázání existuje pouze u metaprocesů BPx. Nakonec v jedné implementaci RM ITIL je taky znalostní pohled a docela využitelný.
OldJoe: Jedná se o znalosti pro role definované obvykle v modelech řízení změn (vlastník, business architekt, správce business modelu atd...?
kalenda: Ano.
Modely nebo flipchart?
lubos: Akú metodiku použič, aby so zákaznického modelu sa dal vyrobiť RM, a čo by mal všetko obsahovať, aby bol zrozumiteľný? Ako treba chápať model - len vybraný problém – proces?
kalenda: RM vždy bude účelový, parciální. Moje zkušenost praví, že rozumné je řezat po procesech. Musíme předem definovat, v jakém nástroji. Jiný BMS bude v ARISu a jiný v ProVision.
fram: Nedomnívám se, že problém RM je v nástroji. Musí se přece stanovit zobecněná struktura problému.
kalenda: Metodicky máte pravdu. Prakticky nikoliv. Když mi nástroj nedovolí nějaký pohled (řez) firmou vytvářet pohodlně a levně, tak ho neudělám:) Např. v životě už v ARISu nebudu simulovat variantní produkci. Raději to udělám v jiné db a bez grafiky.
fram: Souhlasím, dokonce si myslím, že tužka a papír na začátku strukturalizace problému jsou výhodnější než nástroje.
kalenda: Nemyslím. Namalovat problém v příslušném modelu je rychlejší a jistější. Protože strukturovanější. Jen nejsme tak zkušení, abychom si dopředu rámcově vyjasnili, jaký problém řešíme a co použít za model.
fram: Je to asi otázka zvyku, na flipchart nakreslené ideové schéma problému je k nezaplacení. Vzniká rychleji než model v počítači.
lubos: Pripájam sa k názoru, že zachytiť problém v nástroji je rýchlejší a spoľahlivejšie. Flipchart potom je potrebné aj tak dostať do modelu - pri jednoduchom modeli sa to dá, ale ak sa model štruktúruje je to už ťažšie sa oientovať na paieri
OldJoe: Hlavně - když donutím protějšek dodržet metodiku, tak je řešení pomocí nástroje určitě rychlejší a komplexnější. Jen ho k tomu nástroji dostat a naučit ho se v něm vyjadřovat a "číst".
cfk: Metody zalozene na "papieroch" mozu viest ku kreativnejsim napadom:)
kalenda: Takže zkusím uzavřít část - modelovat v nástroji nebo kreslit na flipchart. Pokud provádím identifikaci problému/potenciálu - flipchart. Pokud problém už strukturuji - nástroj.
Co má obsahovat RM
lubos: Mali by sme sa vrátiť k RM - ked sa pozerám na svoje modely, nemám dobrý dojem, že by sa dali použiť ako RM, chýba im všeobecný pohľad, vačšinou opisujú skutočnosť tak ako je - je tam veľa operatívnych pravidiel.
fram: Zpátky k obsahu RM. Existuje sjednocená metodika, co vše RM má mít?
kalenda: Obecně ve světě BPx ne.
fram: Není toto téma na diskuzi? Myslím si, že existuje zobecněný koncept pana prof. Scheera, který je možné vzít za základ.
kalenda: No ale ten je trošičku příííííliš široký! A myslím, že původní Scheerův domeček organizace - procesy - data - funkce (a později výkony) je už mimo. Navrhuji - procesy, strategie (+metriky), pravidla, rizika, organizace, znalosti, IS. Speciálně chci vypíchnout pravidla - viz Lubos. Proto je nutné pravidla separovat. Modeloval jste někdo pravidla?
Pravidla a procesy
fram: Myslíte business pravidla?
kalenda: Ano - teď už to překládáme jako "pravidla podnikání". Myslím hlavně strukturální pravidla, která nejsou procesně zachytitelná.
fram: Má je smysl modelovat? Pokud vím, v dostupných nástrojích není speciální typ modelu pro modelování pravidel.
kalenda: Touhle otázkou se vracím obloukem k KM. Tam je dost záležitostí, které je třeba definovat pravidly, protože procesní popis by byl příliš tvrdý.
OldJoe: Pravidla používám jako součást rozhodování a větvení v rámci eEPC... "Strukturální pravidla podnikání" modelovat zatím neumím.
fram: Model chápu jako abstrakci o nepodstatných aspektů reality, abych realitu pochopil. Má tedy smysl modelovat business pravidla? Ty musím mít popsaná přesně.
kalenda: Myslím, že je v BMS zachytit musíme - jde o vztahy těchto pravidel k ostatním prvkům BMS. IDS na to má speciální nástroj Business Rules Designer.
lubos: Čo potrebujeme, je praktické využitie existujúcich modelov na vytvorenie RM, ktoré by sa dali využiť. Pri svojej práci použivame metódu, že používame existujúce modely, ale vždy narážame na problém podrobnosti a operatívnych pravidiel. Len taká verejná správa – má rovnaké procesy (agendy) a na úrovni procesov je to vždy nový problém. Rovnosť je len na úrovni mapy procesov a subprocesov.
kalenda: Ano. Všichni máme nějaké modely. A neumíme je opakovaně využívat ani my sami. Čili téma - odseparovat operativní pravidla a tak zvýšit znovuvyužití. Příklad - likvidace faktury. Podle best practices zcela jednotný proces. A my ho znepřehledníme tím, že do něj natvrdo nacpeme, kdo jaký typ a jakou částku může uvolnit.
fram: Co to jsou operativní pravidla? Nejedná se o metodiku?
Modelování pravidel v ARIS
kalenda: Zopakuji definice pravidel podle Rosse. 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. Čili do procesních modelů jen neporušitelnou logiku podnikání. Například v KM. Tam je dost záležitostí, které je třeba definovat takto, protože procesní popis by byl omezující. A aby to uživateli k něčemu bylo, je nutné někde zachytit kompatibilně ty operativní pravidla. Používám upravenou metodiku, že jeden univerzální objekt používám jako pravidlo podnikání a zatím mám v metodě, že to lze připojit ke spoustě objektů. Následkem toho jsem začal výrazně zjednodušovat 3. úroveň procesů a ty už začínají vypadat univerzálně.
OldJoe: Zajímal by mě dopad oddělení pravidel z modelů procesů na procesní popisy pracovních pozic a na podpisová pravidla - dva obvykle existující požadavky vedení na výstupy z BMS.
kalenda: Mám to propojené na externí db, kde skladuji pravidla. Takže odtud lze tahat např. konkrétní oprávnění do popisů pozic.
OldJoe: Znamená zjednodušit 3.úroveň procesů tím, že se přidá čtvrtá úroveň = modelování pravidel?
kalenda: Ne - jsme pořád ve 3. úrovni - místo modelování rozhodovacích stromů maluji univerzální tok a k činnostem, kde je nutné rozhodovat, připojuji pravidla. Základ je odseparovat, jaký tok vyplývá z podstaty businessu a jaký je vnucen jeho organizační implementací.
OldJoe: Jak je k činnostem připojuji, když ne hierarchizací...? Jako další objekt?
kalenda: Stejně jako např. I/O data. Vazbou jako samostatný objekt. Pak stačí filtr a pravidla jsou fuč. Navíc to umožní vytvářet docela zajímavé specifické výstupy.
lubos:to je zaujímavý prístup - už konečne chápen, ako odstrániť z modelov zložitú štruktúru vetvenia a udalostí.
OldJoe: Ale u toku činností musím mít tedy napojeny i ty role, které vystupují jen u nejsložitějších a nejodpovědnějších větví původního rozhodování .....
kalenda:U rozhodovacích operativních pravidel to jde ošetřit dobře - přečtu připojené role a natáhnu je do db s pravidly. Ano, musím mít napojené všechny v úvahu připadající. Důležité je, že ty ROLE musí být standardní, logické, neporušitelné. Což je další důvod, proč do procesního pohledu používat role a ne přímo pracovní pozice.
Technická realizace modelování pravidel
OldJoe: Pravidlo jako univerzální objekt ARISu a databáze pravidel jako co - vůči všem těm objektům pravidel? Každý objekt pravidel jako jedna položka DB? Jak ta databáze (příklad) vypadá, jedná se o MDB?
kalenda: Je to složitější. K jednomu pravidlu uvnitř db řada odvozených vztahů. Technická realizace v MS-SQL.
lubos: Ako je realizované prepojenie pravidla na DB?
kalenda:Voláním uložené procedury. Ta se spouští buď na vyžádání (při modelování) nebo skriptem u sestav. Zásadní výhoda - údržba pravidel se stává non-ARIS.
lubos: Rozumiem - je to zaujímavé.
OldJoe: Já dokud neuvidím a neprojdu nějaké praktické užití, tak to na mne působí jako další nesourodé technologické zesložitění, a mám z toho obavu. Věcně je jasné, že je to pokrok. Ale působí to syrově, neusazeně......
kalenda: Mluvím o laborování, ne o produktu. Nikomu bych to neprodal:) Ale co dělat, když to jinak zatím ošetřit neumíme. A je menší zlo - zmatené modely zapatlané detaily nebo technický bastard?
OldJoe: Díky za Váš čas a názory - trochu jste mne znejistěl, že půlku modelů máme již po půl roce metodicky zastaralé a "out", ale jestli dokončím v mých podmínkách alespoň toto
lubos: Mám o čom premýšľať - je to nový posun
kalenda: Jsem rád, že jsme se společně nahlodali...
Více.....
Příspěvky
