Snel ontwerpen van gedetailleerde IT-processen. Businessprocesmanagementconcepten toegepast op IT-servicemanagement

Methoden en modellen Snel ontwerpen van gedetailleerde IT-processen

6.3

Snel ontwerpen van gedetailleerde IT-processen

371

Businessprocesmanagementconcepten toegepast op IT-servicemanagement TIL beschrijft wel een procesraamwerk maar bevat geen gedetailleerd procesontwerp voor de organisatorische inbedding en automatisering van IT-beheerprocessen. Jeroen Bronkhorst, Ruud Ligtenberg, Joost Veerman en Jeroen Wiebolt formuleren een aantal principes die als uitgangspunt dienen voor het gestructureerd ontwerpen van IT-beheerprocessen. Zij sluiten hierbij aan bij wat er in businessprocessmanagement (BPM) gebruikelijk is.

I

INLEIDING Meer en meer IT-organisaties maken gebruik van best practices zoals beschreven in de IT Infrastructure Library (ITIL) voor het structureren en organiseren van IT-processen. Hierbij wordt gestreefd naar bijvoorbeeld het verbeteren van de kwaliteit van de dienstverlening, het reduceren van IT-kosten, het behalen van ISO 9000/20000 certificering en/of het voldoen aan wet- en regelgeving.

Alhoewel ITIL een wereldwijd geaccepteerde standaard voor IT-servicemanagement is, geeft ITIL slechts een raamwerk en bevat het geen gedetailleerd ontwerp, nodig voor de organisatorische inbedding en automatisering van de beschreven IT-processen. Met andere woorden; ITIL beweegt hoofdzakelijk op niveau 1 van de ISO 9001 procesdocumentatiestandaard (zie Figuur 1).

Tiers

Management review records

Records at any level

Lot history records

I Quality manual Policies Objectives Organization Interaction of processes

Corporate manuals

Divisional manuals

II Process documents Standard operating procedures Quality plans III Work instructions Wall reference charts Instructional computer screens IV Forms – spec sheets – templates drawings – data sheets – blueprints

Process manuals; fact books; purchasing manuals; training manuals; design history files

6

Master manual

Master manual

Figuur 1 ISO 9001: 2000 Four-tier Operational Pyramid Concept IT Service Management, best practices, deel 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

372

Tegelijkertijd hebben organisaties en bedrijven de afgelopen jaren hard gewerkt aan het in kaart brengen, aanpassen en verregaand automatiseren van hun bedrijfsprocessen. Vandaag de dag worden organisaties geconfronteerd met veel veranderingen in bedrijfsprocessen veroorzaakt door internet- en webgerelateerde implementaties. Naast het optimaliseren van deze bedrijfsprocessen ter verbetering van de concurrentiepositie, wordt tegelijkertijd gewerkt aan kwaliteitsverbetering en kostenbesparing met betrekking tot de daarvoor benodigde ontwerpen implementatie-inspanning. Met name op het gebied van het modelleren van bedrijfsprocessen zijn er inmiddels grote vorderingen geboekt in termen van standaarden voor zowel het modelleren van bedrijfsprocessen als voor het automatiseren van processen met behulp van web-based (workflow)applicaties. Uit een recent gehouden onderzoek door BPTrends, beschreven in het rapport ‘state of BPM’, blijkt dat organisaties naast algemene standaarden zoals ISO9000, SOX en CMM(I) met name interesse hebben voor BPM-specifieke standaarden zoals Unified Modeling Language (UML), Business Process Modeling Notation (BPMN) en Business Process Execution Language (BPEL). Aangezien veel IT-organisaties worstelen met het ontwerpen, snel implementeren en onderhouden van een gedetailleerd en op ITILgebaseerd procesraamwerk, ligt het voor de hand om aan te sluiten bij de standaarden, best practices en hulpmiddelen die nu al gebruikt worden bij het ontwerp en de implementatie van bedrijfsprocessen. Doel en doelgroep Dit artikel formuleert een aantal principes die als uitgangspunt dienen voor het gestructureerd ontwerpen van IT-processen. Bij het formuleren van deze principes is aansluiting gezocht bij wat er binnen BPM gebeurt. De in dit artikel aangehaalde ontwerpstandaarden staan onder regie van onafhankelijke orga-

nisaties1 en betreffen niet de introductie van een nieuwe stroming. Het doel van deze IT-procesontwerpprincipes is om de leesbaarheid, consistentie en de integratiemogelijkheden van IT-processen te verbeteren. Door het aansluiten op de BPMstandaarden kan ook voor het automatiseren van IT-processen gebruik gemaakt worden van technieken die nu al voor web-based bedrijfstoepassingen worden aangewend. Dit artikel is bedoeld voor IT-architecten, proceseigenaren, procesadviseurs en IT-medewerkers (zowel beheerders als ontwikkelaars). Daarnaast kan dit artikel ook waardevol zijn voor IT-managers, organisatieadviseurs, technisch consultants alsook andere geïnteresseerden in het vakgebied IT-beheer. Reikwijdte Er zal niet diep worden ingegaan op specifieke (aspecten van) IT-processen, maar wel op het generieke raakvlak tussen IT-processen en procesontwerp ondersteunende hulpmiddelen. De onderwerpen zullen worden beschouwd vanuit de perspectieven van een procesontwerper, proceseigenaar en een procesuitvoerder. Leeswijzer Allereerst zal worden ingegaan op de noodzaak om IT-processen te ontwerpen. Vervolgens wordt uitgelegd hoe het ontwerp van IT-processen in de meeste organisaties momenteel wordt aangepakt, alsmede de typische problemen bij het ontwerpen van gedetailleerde IT-processen en welke consequenties dit heeft. Dit wordt gevolgd door een paragraaf waarin een introductie wordt gegeven op BPM-standaarden zoals Business Process Modelling Notation (BPMN) en Business Process Execution Language for Web Services (BPEL-WS). Vervolgens worden enkele principes gepresenteerd voor het toepassen van BPM-standaarden binnen IT-procesontwerp en het adresseren van de knelpunten. Het laatste deel van het artikel geeft een korte samenvatting en enkele conclusies.

1 The Object Management Group (www.omg.org), OASIS (www.oasis-open.org)

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


DE NOODZAAK VAN IT-PROCESSEN Zoals aangegeven in de inleiding zijn er allerlei redenen voor het structureren en organiseren van IT-processen. Deze paragraaf gaat dieper in op de context en noodzaak om IT-processen te ontwerpen en wat hiervan de (beoogde) voordelen zijn. Waarom een procesraamwerk? Het produceren en onderhouden van geautomatiseerde informatiediensten ter ondersteuning van de bedrijfsprocessen, vereist een samenspel van activiteiten die zich voltrekken binnen verschillende IT-domeinen: • IT-bedrijfsdomein - Op strategisch en tactisch niveau worden binnen het bedrijfsdomein de informatiestromen onderscheiden die de bedrijfsprocessen ondersteunen. Bepaald wordt op welke wijze deze stromen worden ontsloten, geregistreerd en verwerkt. Op operationeel niveau wordt de consistentie van de gegevensverzameling bewaakt en worden de stuurgegevens ten behoeve van de gegevensverwerking onderhouden. Gewenste veranderingen ten aanzien van de informatieverwerking worden gespecificeerd en uitgewerkt tot een verwerkbaar aanpassingsverzoek van het informatiesysteem. • IT-applicatiedomein - Op strategisch en tactisch niveau wordt bepaald op welke wijze en met welke middelen het te automatiseren deel van het informatiesysteem wordt gerealiseerd. Op operationeel niveau worden aanpassingen aan de applicatiecode gerealiseerd om de werking te optimaliseren dan wel te innoveren. • IT-infrastructuurdomein - Op strategisch niveau wordt in afstemming met directie en interne klanten de inhoud van de IT-dienstenportfolio bepaald. Op tactisch niveau worden de IT-diensten leveringsafspraken vastgelegd en bewaakt. Het operationele niveau omvat de dagelijkse beheeractiviteiten die noodzakelijk zijn om de continuïteit en stabiliteit van gegevensverwerkende systemen en ondersteunende IT-functies te borgen.

De noodzaak voor het organiseren van deze IT-domeinen middels processen wordt enerzijds ingegeven om de IT-organisatie in staat te stellen tijdig te anticiperen op bedrijfsontwikkelingen die steeds weer andere eisen stellen aan de exploitatie van een informatiesysteem. Door onderscheid te maken in strategische, tactische en operationele processen wordt het mogelijk om tijdig de plancycli binnen de verschillende domeinen op elkaar af te stemmen.

373

Anderzijds lenen processen zich bij uitstek voor het op efficiënte en effectieve wijze organiseren van zich herhalende operationele activiteiten. Sterker nog: een proces is een randvoorwaarde om activiteiten aantoonbaar en voorspelbaar te herhalen met eveneens voorspelbare en consistente output. Een proces benoemt activiteiten, verantwoordelijkheden en afhankelijkheden met andere processen. Hierdoor ontstaat er een besturingsstructuur. Ook wordt het mogelijk om op basis van ervaringsgegevens prognoses te geven van de effecten die veranderingen, zoals vervanging van hardware of modernisering van applicaties, met zich meebrengen. Automatiseren van procesactiviteiten Door activiteiten te structureren in IT-processen ontstaat de mogelijkheid procesactiviteiten te automatiseren met behulp van IT-procesondersteunende applicaties. Het automatiseren van activiteiten zonder een IT-procesontwerp werkt suboptimalisatie in de hand. Immers, tactische principes om het resultaat en de succesfactoren te sturen ontbreken. Dit effect wordt vaak versterkt doordat inrichtingskeuzes vanuit pragmatische overwegingen worden gemaakt. Ontwikkeling van een dergelijk systeem met een onsamenhangende set van functies is slecht te managen.

6

Om de diverse IT-procesondersteunende applicaties wel tot één samenhangend systeem te smeden zijn naast IT-processen ook conventies en standaarden vereist. Deze conventies en standaarden raken zowel het

IT Service Management, best practices, deel 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

374

bedrijfs-, het applicatie- als het infrastructuur IT-domein. Om in een veranderende omgeving deze conventies en standaarden overeind te houden zijn spelregels nodig die bepalen hoe deze afspraken tot stand komen, worden onderhouden en hoe de naleving wordt afgedwongen. Integratie van externe service providers In toenemende mate zijn delen van de productie en onderhoud van informatiediensten uitbesteed aan externe toeleveranciers. Het is hierbij zowel mogelijk dat de IT-organisatie de regie houdt over de processen die de uitbestede activiteiten regelen, alsook dat de regie van bepaalde processen aan de toeleverancier wordt overgedragen. Voor beide situaties geldt dat er alleen dan werkbare afspraken te maken zijn als activiteiten en verantwoordelijkheden zijn gedocumenteerd in een contract en/of een servicelevelagreement (SLA). Het werken volgens een procesmodel heeft in zulke situaties het voordeel dat voor beide partijen inzichtelijk is waar zich de koppelvlakken in de workflow bevinden, en wat er op die koppelvlakken wordt uitgewisseld. Ook is voor de IT-organisatie simpel vanuit het procesmodel vast te stellen welke stuurinformatie de service provider geacht wordt aan te leveren. IT-proces kwaliteitsysteem Een geïmplementeerd procesmodel met de daarbij behorende middelen en kennismanagement vormt een onvoorwaardelijk onderdeel van een kwaliteitssysteem. Er zijn verschillende kwaliteitsystemen in omloop zoals ISO 20000, Cobit, COSO, CMM(I). Op basis van zo’n systeem kan de kwaliteit van een IT-organisatie inclusief procesimplementatie worden bewaakt. Het omgekeerde geldt ook. Tijdens het ontwerp van een procesmodel geeft zo’n kwaliteitsysteem context aan wat er met de processen geborgd moet worden. Een beperking is dat niet elk kwaliteitsysteem alle IT-domeinen afdekt. Als dat wel het geval is worden niet alle procesdomeinen met eenzelfde mate van detail getoetst.

Automatisering van de IT-processen heeft meestal tot gevolg dat er meer gegevens worden geregistreerd op basis waarvan informatie kan worden gemaakt. Het kwaliteitssysteem definieert veelal de informatiebehoefte die nodig is om de processen in samenhang te sturen en te evalueren. Door het relateren van performance-indicatoren tussen de drie IT-domeinen ontstaat een IT-informatieperspectief waarin zowel de bijdrage van ieder IT-domein als hun onderlinge afhankelijkheid in de totale informatieproductieketen inzichtelijk wordt gemaakt.

HUIDIG IT-PROCESONTWERP, KNELPUNTEN EN CONSEQUENTIES In deze paragraaf wordt beschreven op welke manier veel organisaties vandaag de dag het maken en onderhouden van hun ITprocesontwerp hebben georganiseerd. Dit is beschreven met behulp van karakteristieken die de auteurs zijn tegengekomen binnen diverse IT-organisaties over de laatste tien tot twaalf jaar. Tevens wordt ingegaan op de problemen/knelpunten die hierbij naar boven komen en eventuele consequenties als deze knelpunten niet worden aangepakt. IT-proces context In de praktijk vormen knelpunten in de dagelijkse operatie vaak de aanleiding om een IT-procesimplementatie te starten. Hierdoor blijft de scope vaak beperkt tot inrichting van operationele processen en het servicelevelmanagementproces vanuit het tactische niveau. Knelpunt 1: Geen procesarchitectuur Tijdens de procesontwerpfase wordt vaak de stap overgeslagen om eerst een overkoepelende procesarchitectuur te definiëren. In een procesarchitectuur worden de processen en procesclusters geïdentificeerd, alsmede hun onderlinge afhankelijkheid/interacties, relatie tot de IT-organisatiestructuur alsook de IT-procesondersteunende applicatiearchitectuur. Informatie over de processen wordt nu vanuit de processen zelf ontwikkeld. Hierdoor ligt



teveel de nadruk op de performance per proces in plaats van op de toegevoegde waarde van IT als totaal voor de bedrijfsprocessen. Vaak ontbreekt een kwaliteitssysteem waarin de afhankelijkheid van processen ten opzichte van elkaar kwalitatief wordt beoordeeld. Hierdoor blijft onduidelijk welke proces prestatie-indicatoren kritische succesfactoren voor gerelateerde processen zijn. Zeker wanneer de processen zich in verschillende IT-domeinen (bedrijf, applicatie of infrastructuur) bevinden zien we vaak dat resultaten worden afgeschermd vanuit een wij-zij cultuurdenken. Door de focus op individuele processen zijn ook meestal de organisatorisch aspecten onderbelicht. De processpecifieke rolbeschrijvingen zijn opgebouwd uit vaardigheden en verantwoordelijkheden die per rol op verschillende wijze zijn samengesteld. Vanuit elk proces afzonderlijk zijn de consequenties van de rollen prima te overzien, maar voor een afdeling die een bijdrage moet leveren aan vijf processen ziet de wereld er veel ingewikkelder uit aangezien vaak meerdere processpecifieke rollen moeten worden gecombineerd in één functieprofiel. De proceseigenaar staat meestal op afstand tijdens het procesontwerp omdat er door het ontbreken van een procesarchitectuur de focus ligt op gedetailleerde praktische procesaspecten. Dit wordt dan overgelaten aan de procesmanager die als ervaringsdeskundige het meest competent wordt geacht. Consequenties: Onvoldoende managementsturing om het resultaat van de totale keten positief te beïnvloeden. IT-procesontwerp Meestal wordt er vanuit de operatie voor elk in te richten proces een procesmanager benoemd, die -al dan niet extern begeleid- een procesontwerptraject start. Meestal worden tijdens één of meer workshops schetsen gemaakt van de workflow die daarna verder door een werkgroep worden uitgewerkt en gedocumenteerd.

Knelpunt 2: Eigen standaarden en technieken Veelal wordt er gewerkt met ‘eigen’ workflow tekentechnieken en standaarden op basis van Office-pakketten zoals Microsoft PowerPoint of Microsoft Visio (technisch tekenpakket). Hierbij worden naar eigen inzicht symbolen en typen verbindingsconnectoren gebruikt. Diagrammen die op deze manier gemaakt worden zijn vaak niet eenduidig te interpreteren.

375

Consequenties: Niet of nauwelijks uitwisseling en hergebruik van (workflowdiagrammen in) procesdocumenten. Inconsistentie en fouten bij het uitleggen van workflowdiagrammen. Knelpunt 3: Inconsistentie Het is met gebruikmaking van Office-pakketten voor procesdocumentatie moeilijk en zeer bewerkelijk om de ontwerpen van de verschillende processen consistent ten opzichte van elkaar te maken en te houden. Bij het maken dient er handmatig al bijgehouden te worden of de diverse gehanteerde symbolen, begrippen en definities consequent gebruikt worden. Daarnaast is consistentie in de interfaces even belangrijk als moeizaam om bij te houden. Populair gezegd: komen de pijlen uit de beschrijving van het ene proces aan in het andere en wordt er dan hetzelfde mee bedoeld? Dit geldt overigens niet alleen voor de processen onderling, maar ook binnen de processen als er een hiërarchische opbouw met processtappen is en daarbinnen procedures. Ook de verdeling van wat in een procedure of eventueel een werkinstructie dient te worden opgenomen is niet volgens herhaalbare regels.

6

En als die consistentie al lastig is te bewaken bij ontwerp, op moment van aanpassingen later is het helemaal een ‘maintenance nightmare’. Consequenties: Up-to-date houden van procesdocumentatie met Office-pakketten is arbeidsintensief.


376

Knelpunt 4: One-size-fits-all De huidige procesdocumenten moeten vaak verschillende doelgroepen bedienen. Met aan de ene kant van het spectrum de proceseigenaren en procesontwerpers en aan de andere kant de procesuitvoerders. Procesdocumenten worden vaak niet alleen gebruikt als leidraad bij de implementatie en uitvoering, maar bijvoorbeeld ook als input voor functioneel ontwerp van procesondersteunende applicaties. Doordat meestal gebruik wordt gemaakt van arbeidsintensieve Office-pakketten wordt er in de praktijk slechts één beschrijving gemaakt die de verschillende doelgroepen moet bedienen. Consequenties: Een te summier document dat veel ruimte voor interpretatie overlaat, of een zeer lijvig document. In het laatste geval vraagt het een grote motivatie van de lezer om telkens de voor hem relevante informatie eruit te filteren. Knelpunt 5: Onvoldoende detaillering Het procesontwerp zelf kenmerkt zich vaak door het feit dat er alleen een ISO 9001 level I + II (zie Figuur 1) procesdocument is opgesteld. Hierdoor ontbreekt de detaillering van de werkinstructies. Ook komt het vaak voor dat detaillering van de workflow beperkt blijft tot het hoogste procesniveau waardoor ook de detaillering op procedureniveau ontbreekt. Consequenties: Onduidelijkheid en inconsistentie bij de uitvoering van dezelfde processen door verschillende personen. IT-procesautomatisering Er vind altijd een vertaalslag plaats van een ‘papieren’ IT-procesontwerp naar uitvoering op de werkvloer die interpretatie vereist. Hierbij geldt hoe eenduidiger de workflowdiagrammen, des te beter het resultaat. Knelpunt 6: IT-procesautomatisering wijkt af van IT-procesontwerp Zoals we eerder gezien hebben is er helaas vaak een gebrek aan standaardisatie

en samen met het feit dat er een (handmatige) interpretatie dient plaats te vinden, wordt ruimte geboden aan afwijkingen. Met andere woorden: de huidige situatie werkt (mis)interpretatie door de vertaler in de hand. Bij het implementeren van een IT-procesondersteunende applicatie zal de impact van het voorgaande nog groter zijn. Immers het procesontwerp wordt handmatig omgezet naar een functioneel en technisch applicatieontwerp met de voorgaande risico’s tot gevolg. Daarbij komt het risico dat de IT-procesondersteunende applicatie de ontworpen workflow niet ondersteund. Immers door gebrek aan standaardisatie van workflowstructuren zijn applicatieleveranciers niet vooraf te toetsen welke workflowstructuurvarianten hun product ondersteunt. Ook ontbreekt vaak de kennis om voor workflowtekenoplossingen gestandaardiseerde procesontwerppatronen te gebruiken. Hierdoor wordt de kans gemist om een betere aansluiting te maken op automatisering van procesactiviteiten. Steeds vaker zal dergelijke software standaardoplossingen bieden voor bestaande procesontwerp/patronen. Consequenties: Implementatie wijkt ongewild af van het oorspronkelijke ontwerp. IT-proces onderhoud Knelpunt 7: Versiebeheer Meestal zijn initieel de verschillende procesdocumenten binnen een bedrijf nog wel op elkaar afgestemd, dan wel gerelateerd aan een intern afgesproken structuur. Helaas is er meestal slecht of zelfs geen versiebeheer op procesdocumenten en doet de situatie zich voor dat bij fasering van de invoering van processen de documenten onderling gaan afwijken naarmate de tijd en inzicht vordert, en doordat er verschillende schrijvers aan de procesdocumenten hebben gewerkt. Zoals gezegd, een eenmaal ontworpen proces is onderhevig aan veranderingen. Doordat de procesdocumenten zelf vaak zijn opgemaakt met een tekstverwerker is de impact van wijzigingen in relatie tot andere gerela-



teerde processen niet inzichtelijk te maken. Vaak wordt er op basis van ervaringen in de dagelijkse praktijk wijzigingen in het proces doorgevoerd. Deze worden lang niet altijd gedocumenteerd. Een procesdocument vergelijken met de praktijk levert dan ook vaak verschilpunten op. Knelpunt 8: Moeizame procesintegratie bij uitbesteding of fusie Zoals we reeds eerder hebben gezien resulteert het gebrek aan standaarden in een diversiteit van procesbeschrijvingen. In geval van fusies of anderszins samenvoegen van bedrijven is een gebrek aan eenduidigheid en uitwisseling gegarandeerd en het meest voelbaar. Juist dan zou standaardisatie bijdragen aan een soepeler samensmelten van de beide organisaties. Hetzelfde geldt voor situaties waarin IT-activiteiten extern worden belegd. Veelal betekent dit weer dat er eerst een gemeenschappelijke proceskader moet worden gecreëerd. Dit met het risico dat dit weer een nieuwe variant procesbeschrijving oplevert als de mengvorm van twee werelden. Consequenties: Hogere kosten door meer procesconsultancy; langere doorlooptijd van de integratie; inbedden van nieuwe procesontwerpinzichten.

BPM-CONCEPTEN VOOR IT-PROCESONTWERP “If you’re looking for trouble, you came to the right place.” - Elvis Presley Zonder een gestructureerde ontwerpaanpak is het onderhouden van een procesarchitectuur te vergelijken met het bovenstaande citaat. In deze paragraaf zijn de BPM-standaarden opgenomen die een gestructureerd IT-procesontwerp afdwingen. Deze paragraaf geeft inzage in de essentie van de BPM-concepten Unified Modeling Language (UML), Business Process Modeling Notation (BPMN) en Business Pro-

cess Execution Language for Web Services (BPEL-WS). Tot slot wordt er ingegaan op de huidige ondersteunde BPM-functionaliteit door modelleringsapplicaties. 377

Businessprocesmanagement (BPM)concepten Business Process Modeling Notation (BPMN) BPMN is een grafische notatie voor het modeleren van de stappen in een bedrijfsproces. BPMN is bedoeld om de logische volgorde van activiteiten en berichtenuitwisseling binnen of tussen bedrijfsprocessen weer te geven. De BPMN-specificatie beschrijft tevens een afbeelding tussen de grafische elementen en de BPEL4WS-taal voor het automatiseren van bedrijfsprocessen. De primaire doelstelling van deze standaard is om een eenvoudig leesbare ‘notatie’ te bieden aan zowel proceseigenaren, procesuitvoerders als technische procesontwikkelaars die verantwoordelijk zijn voor het automatiseren van de bedrijfsprocessen. BPMN is derhalve bedoeld ter overbrugging van procesontwerp en (geautomatiseerde) procesimplementatie. Deze standaard is initieel gemaakt door het Business Process Management Initiative (BPMI.org). In Mei 2004 is BPMN versie 1.0 gepubliceerd hetgeen tevens de actuele specificatie is bij het schrijven van dit artikel. In Juni 2005 is BPMI samengegaan met de Object Management Group (OMG) in de Business Modeling & Integration (BMI) Domain Task Force (DTF). BPMN is tevens aangenomen als OMG-standaard.

6

BPMN bevat 4 categorieën objecten/symbolen, zoals weergegeven in Figuur 2 BPMNelementen. Deze symbolen vormen de bouwstenen voor procesdiagrammen van diverse soorten. Voor het gebruik van BPMN worden twee basistypes diagrammen onderscheiden: publieke ‘business-to-business (B2B)’ processen en private, interne bedrijfsprocessen. Het eerste basistype B2B-procesdiagram-


Core Set of BPMN Elements Flow Objects

Connecting Object

Events

378

Activities

Artifacts

Swimlanes

Data Object Pool

Sequence Flow

Name [State]

Text Annotation

Message Flow

Text Annotation Allows a Modeler to provide additional Information

Lanes (within a Pool) Gateways

Group

Association

Figuur 2 BPMN-elementen

Patient

men beschrijft de interactie tussen twee of meer organisaties/bedrijven. Dit type model is van algemene aard. Dit model beschrijft de interacties tussen deelnemende partijen die zichtbaar zijn voor de ‘buitenwereld’. Het tweede basistype diagram heeft meer detail en diepgang ten opzichte van de B2B-procesdiagrammen. Een voorbeeld van een B2B-procesdiagram is weergegeven in Figuur 3 BPMN.

Send Doctor Request

Het tweede type diagram betreft het intern bedrijfsproces en concentreert zich veelal op een enkele organisatie en activiteiten die over het algemeen niet zichtbaar zijn voor het grotere publiek. Bij dit type diagrammen is er een bedrijfsproces dat zich volledig afspeelt binnen een enkele ‘pool’ waarbij enkel gebruik wordt gemaakt van ‘messages’ om de interactie met andere processen weer te geven. Een bedrijfsprocesdiagram kan derhalve meerdere interne bedrijfsprocessen weergeven.

Receive Appt

Receive Prescription Pickup

Send Symptoms

Illness Occurs

Send Medicine Request

Receive Medicine

10) Here is your medicine

Receptionist

Receive Doctor Request

9) need my medicine

5) Go see doctor

Send Availability Request

Receive Doctor Availability

6) I feel sick Send Booking

Send Appt

2) Are you available?

8) Pickup your medicine and you can leave Receive Prescription Preparation

Receive Medicine Request

Send Medicine

7) Prepare this medicine

4) I’ll book you 3) I’m available

Doctor

Doctor’s Office

1) I want to see doctor

Receive Availability Request

Send Doctor Availability

Receive Booking

Receive Symptoms

Send Prescription Preparation

Send Prescription Pickup

Figuur 3 BPMN B2B-procesdiagram



Bij ontwikkeling van BPMN is het belangrijk om de fragmentatie tegen te gaan in de manier waarop procesmodellering wordt gedaan. BPMN kan worden gezien als een consolidatie van de beste onderdelen van diverse notaties, waaronder: UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, en Event-Process Chains (EPCs). Een andere reden voor het ontwikkelen van BPMN is dat traditioneel bedrijfsprocessen worden geschreven door mensen die relatief ver weg staan van de technologie die gebruikt wordt om bedrijfsprocessen te automatiseren. Het handmatig vertalen van bedrijfsprocessen levert veel fouten op en maakt het moeilijk voor proceseigenaren om de evolutie en prestaties van hun proces aan te sturen. Om het gat naar de onderliggende technologie te verkleinen, bevat BPMN tevens een eenduidige afbeelding van grafische objecten naar de componenten van de Business Process Execution Language for Web Services (BPEL4WS). Dit is een de facto standaard voor het geautomatiseerd uitvoeren van bedrijfsprocessen (zie na UML). Unified Modeling Language (UML) UML is een grafische benadering voor het modeleren en ontwikkelen van applicaties/ sofware. UML is gebaseerd op objectgeoriënteerde basisprincipes en kan worden gebruikt voor ieder type applicatie, functionerend op ieder type en combinatie van hardware, besturingssysteem, programmeertaal en netwerk.

Structure Diagrams Class Diagram Object Diagram Component Diagram Composite Structure Diagram Package Diagram Deployment Diagram

De afgelopen jaren heeft UML zich ontwikkeld als een taal voor het maken van ‘software blueprints’ door analisten, ontwerpers, programmeurs, et cetera. De primaire doelstelling van UML is om een gemeenschappelijke taal te bieden aan iedereen die betrokken is bij het ontwerpen van software/applicaties.

379

De UML standaard is gemaakt door de Object Management Group (OMG). In oktober 2004 is UML versie 2.0 gepubliceerd hetgeen tevens de actuele specificatie is bij het schrijven van dit artikel. UML versie 1.4.2 is tevens geadopteerd door de International Standards Organization (ISO) als ISO/IEC 19501. UML is gebaseerd op het principe van objectgeoriënteerde probleemoplossing, beginnende bij de constructie van een diagram. Een diagram is een abstractie van een onderliggend probleem en het domein is de wereld waarin het probleem bestaat. UML 2.0 beschrijft dertien types diagrammen, verdeeld in drie categorieën: ‘application structure’-diagrammen, ‘behavior’-diagrammen en ‘interaction’-diagrammen (zie Tabel 1 UML 2.0). Diagrammen bestaan uit objecten die elkaar berichten sturen. Een object bestaat uit attributen en een gedefinieerd gedrag. De status van een object wordt bepaald door de waarde van zijn attributen. Een Class is de ‘blueprint’ voor een object en beschrijft de attributen en het gedrag van een enkele entiteit. Objecten zijn instanties van classes. Een voorbeeld ter verduidelijking van deze basisprincipes is weergegeven in Figuur 4 UML class diagram voorbeeld.

Behavior Diagrams Use Case Diagram Activity Diagram State Machine Diagram

6

Interaction Diagrams Sequence Diagram Communication Diagram Timing Diagram Interaction Overview Diagram

Tabel 1 UML 2.0 diagrammen


Customer name address

Order 1

0..* data status

380

association calc Tax calc Total calc Totalweight Payment 1..* 1 abstract class

amount

1

role name

generalization

multiplicity

line item 1..*

Item

OrderDetail Credit number type expDate

Cash cash Tendered

Check name bankID

authorized

quantity taxStatus

0..*

calcSubTotal calcWeight

1

class name

shippingWeight description

attributes

getPriceFor Quantity getWeight

operations

authorized navigability Figuur 4 UML class diagram voorbeeld

Het verschil tussen UML en BPMN zit in het feit dat UML gericht is op objectgeoriënteerde applicatiemodellering, terwijl BPMN procesgeoriënteerde systeemmodellering ondersteund. Beide standaarden zijn niet concurrerend, maar kunnen worden beschouwd als verschillende benaderingen voor het ontwerpen van systemen. BPMN en UML zijn compatibel met elkaar. Een bedrijfsproces hoeft niet noodzakelijkerwijs altijd geautomatiseerd te worden. Het is mogelijk om met BPMN gemodelleerde bedrijfsprocessen af te beelden op UML concepten. Hiervoor zijn reeds diverse documenten gepubliceerd, waaronder het document “Use of UML and Model Transformations for Workflow Process Definitions” geschreven door Audris Kalnins en Valdis Vitolins. Business Process Execution Language (BPEL) BPEL is een taal (lees: XML notatie en semantiek) voor het beschrijven en uitvoeren van

een bedrijfsproces waarbinnen de meeste taken bestaan uit interacties tussen het proces zelf en externe web services. BPEL specificeert de volgorde waarin een verzameling web services wordt aangeroepen en wijst de verantwoordelijkheid voor ieder van de web services toe aan partners. Web services zijn in essentie applicaties die beschikbaar worden gesteld via het internet/intranet als services conform een Service Oriented Architecture (SOA). Zie ook Figuur 5 SOA en web. De BPEL standaard wordt beheerd door de ‘Organization for the Advancement of Structured Information Standards’ (OASIS). Dit is een consortium die de ontwikkeling, convergentie en adoptie van e-business en webservicestandaarden nastreeft. De meest recente versie van deze standaard is de WS-BPEL 2.0 die in September 2004 is gepubliceerd.



SOA Architecture

Implemented by Web Services

UDDI Service directory

Service directory

381

WSDL Find

Publish

SOAP

SOAP

Web service Service consumer

Bind

Service provider

Service Consumer

SOAP

Appli WSDL cation

Figuur 5 SOA en webservices

Op het hoogste niveau definieert een BPELproces de interactie tussen partners. Een BPEL-proces kent synchrone en asynchrone interactie met zijn partners. De bouwstenen voor een BPEL-proces zijn beschrijvingen van de partijen die deelnemen aan het proces, de data flow door het proces en de activiteiten gedurende de uitvoering van het proces. Een voorbeeld is weergegeven in Figuur 6 BPELcode voorbeeld. <sequence> Figuur 6 BPEL-code voorbeeld

Het BPEL-proces zelf is een webservice en wordt gerealiseerd door een BPEL-engine die de procesbeschrijving uitvoert. Er zijn bewust enkele limitaties in de processen die kunnen worden beschreven in BPEL, dus is het mogelijk om processen te definiëren in BPMN die niet kunnen worden afgebeeld naar BPEL-code. Enkele BPMN-concepten (zoals ad hoc subprocessen) kunnen derhalve niet worden geautomatiseerd. Er is geen grafische notatie voor BPEL. Sommige leveranciers hebben hun eigen notatie gemaakt, terwijl anderen BPMN hebben geadopteerd (zie Figuur 7 Voorbeeld BPMNmodel met bijhorende BPEL-code). Zoals eerder aangegeven maakt een afbeelding tussen BPMN en BPEL 1.1. deel uit van de BPMN-specificatie. Door enkele fundamentele verschillen is het echter erg moeilijk en in sommige gevallen onmogelijk om door mensen leesbare BPEL-code te genereren vanuit BPMN-modellen. Nog ingewikkelder is het synchroon houden van een BPMN-model en BPEL-code, waarbij het wijzigen van de één automatisch tot aanpassing van de ander leidt.

6

Samenvatting De standaarden die zijn beschreven in deze paragraaf bouwen op elkaar zoals weergegeven in Figuur 8 BPM-concepten.


Invoke receive_invokeUnitedLoan

invokeUnitedLoan

Receive

382

Flow

Flow

receive_ invokeUnited Loan

invokeUnited Loan

end

start R eceive Offers

Apply for Loan offers receive_ invokeStar Loan

invokeStar Loan

invokeStarLoan

receive_invokeStarLoan

Figuur 7 Voorbeeld BPMN-model met bijhorende BPEL-code

Professionele modellering applicaties De markt voor BPM-software kent een grote diversiteit aan applicaties. Dit omvat niet alleen applicaties voor procesmodellering, maar ook voor bijvoorbeeld processimulatie, procesautomatisering en procesbewaking. In deze sectie zal specifiek worden gekeken naar de kenmerken van applicaties die worden gebruikt voor het modelleren, analyseren en aanpassen van processen omdat dit het beste aansluit bij het onderwerp van dit artikel.

Business Analyst

Integration Developer

Activity

assign

invoke

Eenvoudige tekenprogramma’s (zoals Microsoft PowerPoint en Microsoft Visio) zijn hierin niet meegenomen, omdat zij niet geschikt zijn voor het maken en onderhouden van grote aantallen, nauw geïntegreerde modellen. Procesmodelleringapplicaties onderscheiden zich van tekenprogramma’s doordat zij modelgegevens opslaan in een objectgeoriënteerde databasestructuur. Dus een activiteit in een ‘flow’-diagram is meer dan een symbool; het is een object met attributen in een database.

Activity

receive

Activity

assign

Notation Layer BPMN or UML

Executable Layer BPEL

Business Services Web Services

Service Developer

Existing Systems

DATABASE

PACKAGED JAVA APPLICATIONS

MAINFRAME

Figuur 8 BPM-concepten overzicht



Het gevolg hiervan is dat wanneer een object wordt hergebruikt in een ander diagram, alle data die is gekoppeld aan dit object ook meteen beschikbaar is. Daarnaast zijn objectwijzigingen meteen zichtbaar in alle diagrammen/modellen waar het object in wordt gebruikt. Dit type applicaties ondersteunt drie primaire functies. In de eerste plaats worden ze gebruikt voor het documenteren van een bestaande situatie. Vervolgens helpen ze bij het analyseren van de effecten van mogelijke veranderingen. Tenslotte ondersteunen ze het documenteren van plannen om de veranderingen door te voeren. Het resultaat hiervan is dat modelleringapplicaties de mogelijkheid bieden om zowel diagrammen/modellen te maken van de huidige situatie (AS-IS) alsook de gewenste situatie (TO-BE). Door de relatief grote diversiteit aan applicaties in deze markt is de functionaliteit die wordt geboden sterk afhankelijk van de geselecteerde applicatie. Sommige applicaties zijn gericht op managers, terwijl andere bedoeld zijn voor analisten en/of applicatieontwikkelaars. Verder zijn er applicaties die generiek zijn en kunnen worden gebruikt voor iedere soort van architectuur en procesmodellering, maar ook applicaties die specifiek zijn voor bepaalde soorten van modellering en analyse (bijvoorbeeld SCOR, eTOM, Zachmann, etc.). Sommige modelleringapplicaties ondersteunen 20 of meer verschillende soorten diagrammen/modellen en een groot aantal verschillende notaties. Anderen ondersteunen enkel een paar notatie-, diagram- en modeltypes. Ten slotte is er een groep applicaties die het toestaan om eigen conventies en aanpassingen te maken op basis van bestaande notaties/diagrammen/modellen. Simulatie De meeste modelleringapplicaties bieden ook een vorm van simulatie, hetzij als onderdeel

van de applicatie zelf of als een aparte ‘addon’-module. Simulatiefunctionaliteit behelst onder andere het nabootsen van processen op basis van fictieve input en/of op basis van ‘real-time’-data, interactie met operationele systemen, rapportage van simulatie meetgegevens en de mogelijkheid om statistische analyse toe te passen op simulatie gegevens.

383

Er zijn twee methoden voor simulatie: systeemanalyse (gebaseerd op mathematische modellen en numerieke methodes) en ‘discrete events’ (gebaseerd op een ‘event’-afhandelingmethode en tevens de meest populaire onder leveranciers). Om simulatie te kunnen doen is een procesmodelleringapplicatie nodig die informatie opslaat voor iedere activiteit. Eenvoudige simulaties kunnen worden uitgevoerd met case data (scenario’s) en dan kijken hoe het proces deze cases afhandelt. De meeste simulatiefuncties bieden informatie over doorlooptijd, bottlenecks en kosten. Ondersteuning van BPM-Concepten Een groot aantal procesmodelleringapplicaties ondersteunt UML, BPMN en kunnen BPEL-code genereren. Bedrijven en organisaties die applicaties gebruiken die BPMN ondersteunen, maken in feite gebruik van een hulpmiddel voor zowel managers als ontwikkelaars waarmee zeer snel ‘flow’-diagrammen kunnen worden omgezet in code. Deze code wordt door BPM-applicaties gebruikt voor het continu bewaken, uitvoeren en beheren van processen.

6

Het moge duidelijk zijn dat de perfecte procesmodelleringapplicatie (nog) niet bestaat. De meeste leveranciers leveren een kernapplicatie plus een variëteit aan uitbreidingen en ‘add-ons’ waarmee de applicatie geschikt kan worden gemaakt voor één of meerdere specifieke doelgroepen. Daarnaast positioneren de leveranciers het liefst in meerdere (niche) markten.


384

Derhalve is het raadzaam voor eenieder om zelf te bepalen welke mix van functies nodig is en welke applicatie daar het beste bij past. Business Process Trends is een organisatie die uitgebreid onderzoek verricht op het gebied van BPM en diverse rapporten publiceert (en onderhoudt) met daarin onder andere gedetailleerde informatie over BPMapplicaties en leveranciers.

beeld door simulatie van ‘activity based costing’-modellen.

PRINCIPES VOOR IT-PROCESONTWERP

Principe 3: Hergebruik vooraf gedefinieerde en bewezen IT-processen Dit basisprincipe draagt in belangrijke mate bij aan het sneller en met minder risico en kosten ontwerpen en implementeren van ITprocessen.

Principe 1: Gebruik BPMN voor IT-procesmodellering Het belangrijkste voordeel van dit principe is een eenvoudig leesbare en toch eenduidige ‘notatie’ te bieden aan zowel proceseigenaren, ontwerpers en uitvoerders met als gevolg een verbeterde uitwisselbaarheid en communicatie rondom IT-processen. Daarnaast is er een aanzienlijk kleinere kans dat een IT-procesontwerp technisch niet haalbaar is, doordat de interpretatie en implementatie van het op BPMN-gebaseerde IT-procesontwerp verregaand kan worden geautomatiseerd. Dit basisprincipe komt derhalve het best tot z’n recht in combinatie met applicaties en een infrastructuur waar gebruik wordt gemaakt van BPEL en web services. De impact van dit principe is dat alle betrokkenen moeten worden getraind en eventueel gecoacht op het gebruik van deze standaard. Principe 2: Selecteer een professionele modelleringapplicatie Het consistent houden van grote aantallen aan elkaar gerelateerde IT-procesmodellen/ diagrammen en het snel en met minder risico’s (geautomatiseerd) vertalen naar uitvoerbare code zijn enkele van de belangrijkste voordelen van een professionele modelleringapplicatie. Afhankelijk van de geselecteerde applicatie kunnen er tevens beter geïnformeerde beslissingen worden genomen door het uitvoeren van gedetailleerde procesanalyses bijvoor-

Naast een aanschaf- en onderhoudsinvestering in de geselecteerde applicatie (en eventuele additionele hardware), moet tevens rekening worden gehouden met het trainen en eventueel coachen van alle betrokkenen in het gebruik van de applicatie.

Consequentie van dit principe is dat een gedegen onderzoek naar reeds beschikbare IT-procesdocumentatie (zowel intern als extern) moet worden uitgevoerd voor aanvang van een project waarin IT-procesontwerp en implementatie wordt geadresseerd. Een externe leverancier kan hierbij niet alleen een bron van procesdocumentatie zijn, maar tevens een rol spelen om te helpen de interne organisatorische weerstand tegen verandering (lees: IT-processen) te overbruggen.

SAMENVATTING EN CONCLUSIES IT-processen zijn nodig om vanuit een toekomstgericht perspectief te opereren en te anticiperen op veranderende omstandigheden. Daarnaast lenen IT-processen zich bij uitstek voor het op efficiënte wijze organiseren en automatiseren van zich herhalende activiteiten. Als belangrijkste knelpunten bij het maken en onderhouden van een IT-procesontwerp kunnen worden aangemerkt: het ontbreken van een strategie/context/procesarchitectuur, inconsistentie, onvoldoende detaillering, versiebeheer en relatief veel fouten bij procesimplementatie en procesautomatisering. Door het aanpakken van deze knelpunten kunnen investeringen in tijd en geld voor het ontwerpen, implementeren en onderhouden van IT-processen significant worden gere-



duceerd. Hiervoor raden wij aan om onder andere gebruik te maken van de volgende principes: • Gebruik BPMN voor IT-procesmodellering • Selecteer een professionele modelleringapplicatie • Hergebruik vooraf gedefinieerde en bewezen IT-processen Drs. Jeroen M.H. Bronkhorst is Programma Manager IT Service Management bij Hewlett-Packard en is verantwoordelijk voor het ontwikkelen, onderhouden en wereldwijd uitrollen en ondersteunen van HP IT Service Management diensten. Daarnaast is hij nauw betrokken bij het schrijven van de ITIL v3 boeken en modellen. Dhr. Ruud Ligtenberg is senior ITSM consultant bij Hewlett-Packard en is gespecialiseerd in opzetten en implementeren van Service Management oplossingen. Dhr. Joost L. Veerman is senior ITSM consultant bij Hewlett-Packard en is gespecialiseerd in ontwerp en implementeren van het HP IT Service Management Referentie Model. Heeft ervaring met ontwerp van geintegreerde servicemanagement systeemoplossingen op basis van HP OpenView applicaties. Is met name geïnteresseerd in ontwikkelingen van BiSL, ASL en ITIL tot een geïntegreerd procesframework. Ir. Jeroen Wiebolt (MiSM) is Managing Consultant IT Service Management bij Hewlett-Packard en is verantwoordelijk voor de inzet en ontwikkeling van een team van 25 ITSM-Consultants in Nederland. Daarnaast is hij nauw betrokken bij het ontwikkelen van oplossingen op het vakgebied van IT-beheer.

• Havey, Michael (2005), Essential Business Process Modeling, ISBN 0596008430, O’Reilly. • Holt, Jon (2001), UML for Systems Engineering: Watching the Wheels, ISBN 0852961057, Institution of Electrical Engineers. • Jog Raj (2004), BPEL and BPMN, Modeling Business requirements for BPMS Choreography, Global Business Process Forum 2004, BPMG.org. • OMG (2006), Unified Modeling Language: Infrastructure, version 2.0, formal/05-0705. • Piispanen, Tuomas (8.8.2006), BPEL & SOA Presentation. • Scheer, A.W. (1999 Third edition), ARIS Business Process Frameworks, ISBN 3540658343, Springer. • White, Stephen A. (2004), Business Process Modeling Notation (BPMN) version 1.0 – May 3, 2004, BPMI.org. • White, Stephen A. (2004), Introduction to BPMN. • White, Stephen A. (2005), BPMN Fundamentals. • Wolf, Celia and Paul Harmon (2006), The State of Business Process Management, BPTrends. • www.workflowpatterns.com • www.bptrends.com

385

6

BRONNEN Voor de totstandkoming van dit artikel is de volgende literatuur gebruikt: • Hall, Curtis and Paul Harmon (2006), The Enterprise Architecture, Process Modeling and Simulation Tools Report, version 2.0, September 2006, BPTrends.


386


Snel ontwerpen van gedetailleerde IT-processen. Businessprocesmanagementconcepten toegepast op IT-servicemanagement

Recommend Documents