VYUŽITÍ METODY BORM PRO BUSINESS PROCESS REENGINEERING

Využití metody BORM pro business process reengineering.

Use of BORM method in business process reengineering

Vojtěch Merunka,

Adresa autora:

Ing. Vojtěch Merunka, PhD.

Katedra informačního inženýrství PEF ČZU.

Anotace:

Článek přináší popis metodiky BORM, která byla vyvíjena jako součást grantového projektu VAPPIENS Britské rady (British Council). Pozornost je zaměřena na úvodní fáze analýzy informačních systémů a na možnost jejího využití jako nástroje pro BPR. Je popisována metoda OBA (Object Behavioral Analysis), která je součástí BORMu, a procesní diagram business objektů. Součástí textu je také ukázka analýzy na konkrétním příkladě.

Summary:

Paper presents the description of the BORM methodology, which has been developed as a part of grant project VAPPIENS of the British Council. The text is focused at first stages of information systems analysis and at the ability of their use as a tools for BPR. The method OBA (Object Behavioral Analysis - a component of BORM) and business object process diagram are described. Practical example of BORM analysis is also included.

Klíčová slova:

BORM - Business Object Relation Modeling, BPR - Business Process Reengineering, OBA - Object Behavioral Analysis, business objekt, objektově orientovaný přístup.

Key words:

BORM - Business Object Relation Modeling, BPR - Business Process Reengineering, OBA - Object Behavioral Analysis, business object, Object-Oriented Paradigm.

Co je metoda BORM

Metoda BORM (Business Object Relation Modeling) byla vyvíjena postupně od roku 1993. Od počátku byla orientována na podporu tvorby objektově orientovaných softwarových systémů založených na čistých objektově orientovaných programovacích jazycích a vývojových prostředích, jakými jsou například prostředí Smalltalku (VisualWorks, VisualWave, VisualAge, ...) a objektové databáze (Gemstone, Artbase, ...). Během práce na této metodě bylo zjištěno, že některé její techniky a nástroje je možné využít k reprezentaci znalostí a modelování business procesů.

Práce na BORMu je od svého počátku součástí grantu VAPPIENS (research project Various Programming Paradigms in Integrated Environments), který je součástí programu "Know How Fund of Czech Academic Link Programme" Britské rady (British Council). Od roku 1996 je další vývoj také podporován firmou Deloitte&Touche Czech Republic and Central Europe, kde je tato metoda také používána.

Metoda BORM a především její možnosti analýzy v počátečních fázích vývoje projektu byla prakticky použita například v projektech pro pražské zdravotnictví, Ústav pro státní informační systém ČR, elektroenergetiku, zemědělství, telekomunikace a plynárenství. Ve všech těchto projektech se ukázalo, že BORM lze dobře využívat jako nástroj pro provádění business process reengineeringu. Výsledky takové analýzy také velmi dobře slouží pro podrobnou a úplnou specifikaci zadání softwarového projektu.

Jak se BORM liší od jiných metod

BORM byl navrhován jako metoda, která pokrývá všechny fáze vývoje softwaru. Velká pozornost je na rozdíl od jiných metod věnována úvodním fázím projektu. Nejpoužívanější metody se spoléhají jen na analýzu textového popisu zadání a odvozování objektů a jejich operací z podstatných jmen a sloves v jednotlivých větách. Technika "use-case", která je součástí dnes nejpoužívanějších metod OMT a UML, sice pomáhá při definování interakcí a členění systému, ale poskytuje jen malou podporu pro identifikaci objektů ze zadání. Z "use-case" diagramů se však přímo vytvářejí diagramy sekvencí a komunikací mezi objekty a třídní diagramy. U všech těchto následných diagramů se však již předpokládá, že objekty a třídy jsou již rozpoznány. Stručně řečeno, většina dnes používaných metodologií začíná nad množinou objektů, pro které se například vytvářejí nejrůznější softwarově orientované diagramy, ale sofistikovanější postupy, jak tyto objekty v zadaném problému najít a zkontrolovat jejich správnost, v nich chybějí.

Druhou odlišností od jiných metod je skutečnost, že BORM pro každou jednotlivou fází životního cyklu využívá v diagramech jen omezenou sadu pojmů. Předpokládá se totiž, že během projektování dochází k postupným přeměnám pojmů na jiné. Například ve fází analýzy se nepoužívají pojmy jako agregace, jednoduchá či vícenásobná dědičnost, protože tyto pojmy jsou relevantní až pro implementaci. Naopak pojmy jako stav, přechod či asociace jsou používány během analýzy, ale ve fázi implementace, kdy se snažíme model přizpůsobit cílovému implementačnímu prostředí, se s nimi již nepracuje. Nejde jen o postupné zvyšování úrovně detailu ve vytvářeném modelu, ale skutečně o řadu transformací modelu v průběhu životního cyklu. Na rozdíl od přístupu BORMu u metody OMT (a také UML) lze například do object-class diagramu libovolně vkládat kterýkoliv z pojmů bez ohledu na to, jestli se daný diagram týká fáze analýzy nebo návrhu.

Třetí a poslední specifickou vlastností BORMu je skutečnost, že metoda nevyžaduje oddělování od sebe statických a dynamické pohledů na systém do různých typů diagramů s rozdílnou notací a dovoluje je dokonce v jednotlivých diagramech kombinovat. V BORMu je každý pojem reprezentován shodnými symboly bez ohledu na to, jestli se jedná o diagramy datové struktury nebo komunikací mezi objekty. BORM používá pro znázorňování konceptuálních a softwarových pojmů většinu symbolů shodně s jazykem UML, ale dovoluje v jednom diagramu znázornit například posílání zpráv mezi metodami různých objektů v různých stavech. Tento přístup dovoluje vyjádřit konzistentním způsobem některé žádoucí detaily softwarové konstrukce, které lze výhodně aplikovat především při návrhu pro čistě objektově orientované programovací jazyky. Tento způsob je mnohem jednodušší než např. tvorba více od sebe oddělených třídních, stavových a kolaboračních diagramů a také dovoluje zobrazit větší množství informací. Na druhou stranu však samozřejmě platí, že samostatné stavové či interační diagramy jsou v BORMu také používány.

"Business" analýza I.S.

Pojem “business” analýza informačních systémů, jak jsou úvodní fáze analýzy I.S. často označovány, je poměrně novou a v současné době velmi rozvíjenou aplikací OOP v praxi. [1] Tato oblast modelování informačních systémů má dvojí na sobě poměrně nezávislý původ:

1. Prvním je potřeba formálního podchycení prvních fází vývoje informačního systému nástroji používajícími jiný pojmový aparát, než nástroje klasického softwarového inženýrství právě z výše popsaných důvodů. Tato potřeba vznikla na základě zkušenosti, že zahájení tvorby IS nějakou “klasickou” objektovou metodou zbavuje většinu zainteresovaných osob ze strany zadavatele schopnosti sledovat projekt již od samého počátku.

1. Jako druhá příčina rozvoje se považuje rozvoj tzv. “business process” reengineeringu (BPR) [2] právě v souvislosti se zjištěním, že myšlenky OOP jsou velmi přínosné pro konstrukci nástrojů a technik pro potřeby BPR.

Využití myšlenek OOP a znalostí a postupů známých z “klasických” metod tvorby softwaru [7,10] a aplikovaných ve fázi business analýzy činí z této fáze důležitou a novou poměrně ucelenou oblast nástrojů a technik, která je označována jako “business” modelování (jiní autoři používají též označení “esenciální”) v návrhu IS. Dochází zde k velmi zajímavému prolínání "business" inženýrství a softwarového inženýrství. Tento proces je někdy označován jako konvergenční přístup v informačním inženýrství. [1,6]

Je velmi zajímavé, že fáze “business” modelování je v procesu návrhu IS použitelná hned trojím možným způsobem:

1. Jako fáze, která předchází “klasické” konceptuální modelování. V tomto případě je využita jako předstupeň pro tvorbu konceptuálních modelů (které potom lze navrhovat podle OMT či UML). Zde “business” modelování plní úlohu spojovacího a komunikačního mezičlánku mezi zadavateli a tvůrci softwaru v úvodních fázích vývoje.

1. Jako fáze, která může být provedena jiným subjektem, než následná “klasická” analýza a návrh. V tomto případě je použita jako ucelená metoda pro tvorbu strukturovaných podkladů a dokumentace, která dále slouží jako výchozí bod tvorby IS prováděné jiným subjektem např. na základě následně provedeného výběrového řízení. [4]

2. Jako samostatná metoda, která slouží pro tvorbu informačního modelu pro potřeby BPR a to jak zmapování stávajícího stavu, tak i pro popis návrhu budoucího stavu jednotlivých modelovaných procesů a jejich potřebné změny [2]. Zde se objektové modelování dokonce jako metoda úplně osamostatňuje a vlastně nepřímo dokazuje větší uplatnitelnost myšlenek OOP než pouze v procesu tvorby programů, jak bylo naznačeno v úvodu článku.

Z našich zkušeností vyplývá, že varianta 2) a především varianta 3) je dnes v praxi nejvíce vyžadována, je součástí postupů např. velkých konzultačních firem a lze v blízké budoucnosti očekávat její další rozvoj.

BPR - Business Process Reengineering

Podnikovým reengineeringem se rozumí zamyšlení a zásadní přeměna nejhlubších principů fungování daného podniku a to především z hlediska zákazníka - jaké hodnoty mu organizace poskytuje a především, jakým způsobem tak činí. K takovému zamyšlení může mít management firmy několik zásadních důvodů:

o organizace je v tak špatném stavu, že zásadní změna struktur je jednou z mála cest k záchraně;

o dlouhodobě negativní trendy tržních ukazatelů společnosti - “něco není v pořádku”;

o organizace je vedoucí firmou ve své oblasti podnikání, a aby si toto postavení mohla udržet, musí se neustále zlepšovat a hledat způsoby, jak lépe sloužit svým zákazníkům;

o “ostatní to dělají také” - management firmy chce udržet postavení na trhu a má obavu, že jej ztratí.

Pracovníci účastnící se projektu reengineeringu si pokládají otázku “Jak by vypadala tato firma, kdybychom ji dnes - se současnými znalostmi a s využitím moderních technologií - budovali znovu?”

Zakladatel BPR Hammer definuje reengineering takto[1,2,3]:

“Reengineering znamená zásadní přehodnocení a radikální rekonstrukci (redesign) podnikových procesů tak, aby mohlo být dosaženo dramatického zdokonalení z hlediska kritických měřítek výkonnosti, jako jsou náklady kvalita, služby a rychlost.”

Pro lepší pochopení této definice je vhodné blíže vysvětlit význam klíčových slov z definice. Prvním takovým slovem je slovo “zásadní” - rozumíme tím, že pracovníci si musí o svých firmách klást nejzákladnější otázky: “Proč děláme to, co děláme?”, “Proč to děláme právě tímto způsobem?”. Podobné otázky vedou až k odhalení nevyslovených pravidel a předpokladů, na kterých je způsob podnikání organizace založen.

V současné převratné době se často ukazuje, že tyto pravidla jsou zastaralá, chybná či nevhodná. Z posloupnosti výše uvedených otázek vyplývá důležitá skutečnost charakteristická pro reengineering - jeho primární zaměření na to, copodnik dělá, či musí dělat, a teprve sekundárně na způsob zajištění těchto činností. Pracovníci pracující dle zásad reengineeringu tedy například nezačnou práci s otázkou “Jakým způsobem budeme zajišťovat skladové zásoby?”, ale “Proč vůbec jsou skladové zásoby nutné?”.

Druhým důležitým výrazem je “dramatické zdokonalení”. Nezajímají náš povrchní úpravy či přizpůsobování stávajících struktur. Jde o změnu, která bude znamenat zásadní obnovu podnikových činností. Požadujeme-li zlepšení výkonnosti určitého ukazatele o více něž několik desítek procent, nedosáhneme toho konvenčními technikami zlepšování výkonnosti. Máme-li proces vyřizování reklamací, který trvá průměrně řádově týdny a chceme jej zkrátit na pouhé dny, nemůžeme toho dosáhnout tím, že zachováme dosavadní poštovní styk s klientem, a ve firmě zavedeme dokonalejší systém oběhu dokladů.

Čtvrté klíčové slovo v definici je “proces”. Podnikový proces je soubor činností, který vyžaduje jeden nebo více vstupů a tvoří výstup, který má pro zákazníka hodnotu. Zákazník procesu může být jak interní, tak externí. Hlavní podnikové procesy dodávají produkt (hodnotu) konečnému zákazníkovi podniku. Podpůrné procesy jsou procesy, které zajišťují zdárný průběh klíčových procesů. Posledním druhem procesů, jsou procesy řídící, jejichž úkolem je zajistit řízení klíčových a podpůrných procesů tak, aby firma jako celek dosahovala cílů, která má vytýčeny.

Modelování procesů je tedy klíčovou technikou při provádění BPR. Provádí se ve dvou etapách:

1. V první etapě (etapa AS-IS = tak, jak to je) se podrobně modeluje stávající stav podnikových procesů. To je důležité pro exaktní vymezení předností a především nedostatků podniku. Bez této nepopulární fáze totiž nelze zodpovědně modelovat budoucí stav.

2. Po vyhodnocení výsledků první etapy se přistupuje k druhé etapě (etapa TO-BE = jak by to mělo být). Zde se navrhují a podrobně popisují nové procesy a z informací v nich uložených se nakonec provádí návrh nové organizační struktury.

Úvodní fáze analýzy - business inženýrství - v BORMu

Úvodní fáze analýzy jsou v BORMu podporovány technikou analýzy objektů podle chování (OBA - Object Behavioral Analysis) a nástrojem ORD (Object Relation Diagram).

Metoda OBA

Metoda OBA je první z šesti technik zahrnutých v BORMu, jak ukazuje obrázek č.2. Metoda vnikla počátkem 90. let na základě zkušeností s aplikacemi technik JAD (Joint Application Design) a CRC (Class-Responsibility-Collaborator) [9] pro potřeby objektové analýzy a návrhu a implementace v objektově orientovaných programovacích jazycích.

Jedná se o iterativní techniku začínající řízeným interview se zadavateli a pracující s různými typy formulářů, tabulek a modelových karet, ke kterým přísluší sada postupů a pravidel. Podrobnější popis OBA analýzy lze například nalézt v [5].

OBA pomáhá získávat strukturovaným způsobem potřebné podklady k sestavení prvotních objektových diagramů. Má však i další zajímavé přínosy do procesu tvorby I.S.:

1. poskytuje prostředky pro dokumentování projektu od samého počátku,

1. modelové karty a další výstupy OBA jsou znovupoužitelné v dalších podobných projektech [3] (například jako návrhové vzory) a

2. úsilí vynaložené při sestavování scénářů a životních cyklů objektů lze zužitkovat při návrhu optimální funkčnosti uživatelského rozhraní.

Metodu OBA lze provádět dokonce jen s tužkou v ruce a příslušnými předtištěnými formuláři a tabulkami na papíře. Samozřejmě lepším způsobem je použití CASE nástroje, který dokáže většinu rutinních operací (například různé vzájemné kontroly, udržování projektových dat v konzistentním tvaru a možnost tisku tabulek a formulářů) provádět automaticky.

CASE Nástroj pro BORM

Součástí vývoje metodologie BORM byl i výběr vhodného CASE nástroje. V současné době je metoda BORM již implementovaná v nástroji Metaedit Plus.

CASE Metaedit Plus je dle údajů firmy Metacase software kategorie CAME - Computer Aided Method Engineering. Znamená to, že obsahuje prostředky pro implementaci nových metod. Nová metoda se v Metaeditu Plus poměrně snadno implementuje pomocí definování jejího metamodelu, [11] k němuž se prostředky vizuálního programování přidají příslušné dialogy a vzhled a chování symbolů. Metaedit Plus je naprogramován nad objektově orientovanou databází. Informace uložená v databázi je prezentovatelná a zpracovávatelná nejen v podobě grafů, ale i jako tabulky a matice a také přímo uvnitř databáze pomocí různých browserů. Součástí Metaeditu Plus je i skriptový jazyk, ve kterém jsou předdefinovány různé výstupy ve formátu TXT, RTF, HTML, GIF a PCT. Protože systém je otevřený, je možné programovat další výstupní sestavy pro potřeby dokumentace.

Diagram ORD

Diagram ORD slouží k vizuální reprezentaci informace získané metodou OBA. Jedná se o velmi jednoduchý diagram, který obsahuje jen malý počet pojmů a symbolů, které jsou plně postačující pro prvotní popis modelovaných procesů. (V dalších fázích projektování je ORD transformován do podoby podobné diagramům UML výše naznačeným způsobem)

ORD dovoluje zobrazovat a modelovat jednotlivé procesy současně dvojím způsobem:

1. Sekvence stavů a přechodů každého objektu, na které lze nazírat jako na dílčí stavový diagram, vyjadřují roli daného objektu v modelovaném procesu. Tento pohled slouží ke kontrole celkového modelovaného procesu například při interview.

2. Sled komunikací mezi aktivitami různých objektů v různých stavech vyjadřuje průběh vlastního procesu. Celkový proces je tedy znázorněn jako propojení rolí objektů, které se tohoto procesu účastní. Nazíráme-li na participující objekty se svými stavy a přechody jako na automaty, jedná se vlastně o skládání automatů. [12]

Vzhledem k tomu, že modelovaný proces je konstruován jako propojení rolí (stavů a přechodů) účastnících se objektů, tak ORD dovoluje jednoduchým a nenásilným způsobem zachytit přesný průběh modelovaného procesu a poskytuje tím i prostředky pro ověřování jeho správnosti. (Do ORD totiž není například možné přidat aktivitu, která by nenavazovala na nějaký již přítomný stav nebo nebyla vázána nějakou komunikací s jinou aktivitou.) Tyto vlastnosti, které přímo vyplývají z použité teorie, jsou velmi dobře využitelné v interview, ve kterých se diagram sestavuje nebo kontroluje.

Podle našich zkušeností je takto navržený diagram vhodný pro podrobný popis business procesů a práci s nimi. Jedním z jeho největších přínosů je jeho velká srozumitelnost pro experty z problémové oblasti, kteří zpravidla nejsou vyškoleni v technikách softwarového inženýrství.

Literatura

1. Taylor, David A.Business Engineering with Object Technology, John Wiley 1995 ISBN: 0471045217

2. Darnton, Geoffrey, Darnton, Moksha: Business Process Analysis International Thomson Publishing 1997 ISBN: 1861520395

3. Partridge C.: Business Objects - Reengineering for Reuse, Butterworth-Heinemann 1996, ISBN 07506-2082X

4. Yourdon E.: Mainstream Objects - An Analysis and Design Approach for Business, Prentice Hall 1995 ISBN 0-13-209156-9

5. Goldberg Adele, Kenneth Rubin S.: Succeeding with Objects - Decision Frameworks for Project Management, Addison Wesley 1995, ISBN 0-201-62878-3

6. Finkelstein Clive.: An Introduction to Information Engineering - From Strategic Planning to Information Systems, Addison Wesley 1989, ISBN 0-201-41654-9

7. Satzinger John W, Orvik Tore U.: The Object-Oriented Approach - Concepts, Modelling and System Development, Boyd&Fraser 1996, ISBN 0-7895-0110-4

8. The Unified Modeling Language Documents, Rational Software Corporation, http://www.rational.com/ot/uml.html

9. Bellin, David; Simone, Susan Suchman: The CRC Card Book Addison-Wesley 1997 ISBN: 0201895358

10. Norman R.J.: Object-Oriented Systems Analysis and Design, Prentice Hall 1996, ISBN 0-13-242819-9

11. B. Henderson-Sellers, A.P. Bulthuis, Rijswijk, Object-Oriented Metamethods, Springer Verlag 1997, ISBN 0-387-98257-4

12. Mellor Stephen, Shlaer Sally: Object Lifecycles: Modeling the World in States, ISBN 0136299407