Artikel

Business Process Management en Enterprise Architectuur: een gelukkig huwelijk

In dit artikel wordt de stelling geponeerd dat de beste manier om Business Process Management (BPM) in een bedrijf te implementeren, langs de as van Enterprise Architectuur is. Met name de benadering van Enterprise Architectuur zoals die door het The Open Group Architecture Framework (TOGAF) wordt gepropageerd is een ideaal vehikel om BPM op een planbare en iteratieve manier continu waarde te laten toevoegen. Dit artikel beschrijft hoe Business Process Management op basis van TOGAF geïmplementeerd kan worden in de onderneming en welke rol de enterprise architect hierbij heeft.

BPM als onderscheidende factor

In een globaliserende wereld leggen bedrijven zich in toenemende mate toe op het optimaliseren van hun hele procesketen, met de klant als uitgangspunt. De managementdiscipline die hieraan uitdrukking geeft wordt Business Process Management (BPM) genoemd. Omdat BPM in dit kader de gehele waardeketen van de onderneming omvat, inclusief de relaties met business partners (leveranciers, co-engineers en co-makers) is steeds vaker de term Enterprise BPM van toepassing, ter onderscheiding van lokale en tactische procesverbeteringen.

Initiatieven om BPM ondernemingsbreed uit te rollen zijn op zijn minst ambitieus en altijd risicovol. Een onderzoek van het gezaghebbende instituut BPTrends in 2010 onder een groot aantal bedrijven leverde een complex beeld op van initiatieven waarbij strategievorming, competentieontwikkeling, implementatie van tactische procesverbeteringen en automatiseringsprojecten in allerlei combinaties werden opgepakt en uitgevoerd.

Opvallend in het onderzoek was dat maar liefst 49% van de respondenten aangaf dat het opzetten en inrichten van Enterprise Architectuur als onmisbaar onderdeel werd gezien van het BPM programma van hun bedrijf. De belangrijkste reden hiervoor is dat Enterprise Architectuur bij uitstek een holistische discipline is. BPM vereist inspanning op strategisch, tactisch, organisatorisch en implementatieniveau, en overschrijdt individuele disciplines. Het toepassen van Enterprise Architectuur op basis van bijvoorbeeld TOGAF1 vormt dan ook een perfect raamwerk voor het ontwikkelen van BPM binnen een organisatie.
Wat wellicht nog opvallender is in het onderzoek van BPTrends, is dat meer dan de helft van de bedrijven (51%) blijkbaar nog niet tot het inzicht is gekomen dat Enterprise Architectuur kan helpen bij het ontwikkelen van BPM binnen hun organisatie. Als reden hiervoor zou kunnen gelden dat de afstand die bij veel bedrijven tussen business en IT bestaat een gelukkig huwelijk in de weg staat.

Het ideaal: end-to-end procesmanagement

De kwaliteit van de bedrijfsprocessen bepaalt voor een belangrijk deel het succes van een bedrijf. Het vermogen om de bedrijfsprocessen integraal te kunnen managen en optimaliseren draagt bij tot die vereiste hoge kwaliteit. Door het hanteren van actuele managementconcepten en het toepassen van de beschikbare tools op de juiste manier wordt end-to-end procesmanagement mogelijk.

Bedrijfsprocessen zijn in de hedendaagse economische context in hoge mate veranderbaar en moeten flexibel zijn. In een toenemend aantal processen zijn externe partners verantwoordelijk voor de uitvoering van delen van het proces. Ieder bedrijf moet echter controle houden op de uiteindelijke dienstverlening aan de eindklant waarbij de gehele keten in ogenschouw moet worden genomen, dus ook die delen van het proces waar een externe partij verantwoordelijk voor is.

De regiefunctie moet in eigen hand gehouden worden, hetgeen betekent dat de procesorchestratie en choreografie door het bedrijf zelf moet worden bewaakt. Om dit mogelijk te maken is een groot aantal gerelateerde zaken noodzakelijk:

  • Gedeelde procesdefinities (Procesarchitectuur)
  • Gedeelde data- en begripsdefinities (Informatie architectuur)
  • Beschikbaarheid van integrale BPM platform tooling (applicaties, infrastructuur)
  • Overeenstemming over te bereiken verbeteringen (business case)
  • Overeengekomen scope en fasering voor implementatie van de gehele keten (roadmap planning)
  • Programma- en projectimplementatiemethodieken die recht doen aan BPM als specifieke materie en discipline
  • Competentieontwikkeling voor BPM voor alle verschillende stakeholders

Al deze elementen zijn onderdeel van een integrale Enterprise Architectuur.

De Enterprise Architect als BPM regisseur

Wie de bovenstaande aspecten even op zich laat inwerken en probeert zich een beeld te vormen van wie hiervoor binnen een bedrijf de aangewezen persoon of groep is om zich hierop te richten en verantwoordelijkheid te nemen, zal tot de conclusie komen dat veel verschillende belanghebbenden ieder voor een deel verantwoordelijk zijn. Juist daarom is het cruciaal dat die verschillende belanghebbenden hun activiteiten en beslissingen op elkaar afstemmen. Enterprise Architectuur levert de conceptuele aanpak, evenals de concrete producten en best practices die het mogelijk maken zo’n complex onderwerp als BPM op een gestructureerde manier in een bedrijf in te voeren.

Het is hierbij ook de taak en verantwoordelijkheid van de enterprise architect om de verschillende betrokkenen ieder vanuit hun eigen rol in beweging te krijgen om de juiste activiteiten te ontplooien die passen bij de BPM roadmap. In feite is de enterprise architect vanuit zijn discipline de enige betrokkene die alle verschillende aandachtsgebieden met elkaar in verbinding kan brengen en de regie te kunnen voeren over de uitvoering van de noodzakelijke stappen.

Waar te beginnen

In de managementtheorie wordt veelal uitgegaan van een ’top down‘ benadering, waarbij de tactische en operationele stappen gezet worden op basis van een gedegen strategische basis. Een nadeel hiervan is dat het nog wel eens tegenvalt om een heldere top down BPM strategie op te leveren en vooraf buy-in te verkrijgen voor een BPM roadmap. Zonder duidelijke criteria en aantoonbaar succes is investeren lastig te motiveren.

Eén van de grote voordelen van een architectuurbenadering als TOGAF is dat het niet per se noodzakelijk is om top down te beginnen. TOGAF is het leidende architectuurraamwerk binnen de Enterprise Architectuur discipline en blinkt uit in het in verband brengen van verschillende aandachtsgebieden en het faseren van de inrichting van een holistische Enterprise Architectuur. Omdat het raamwerk van TOGAF daarbij veel houvast biedt is het mogelijk overal in de Architectuur Ontwikkel Methodiek (ADM)–cyclus van TOGAF te beginnen en daar voortgang te boeken waar de grootste kans op succes aanwezig is. Mensen komen pas in beweging als er aantoonbaar voordeel te behalen is. De praktijk wijst uit dat er altijd wel een stakeholder is die gemotiveerd is vanuit zijn of haar deelbelang om stappen vooruit te zetten.

Figuur 1: TOGAF Architectuur Ontwikkel Methodiek (ADM)-cyclus

Realisatie van een door allen gedeelde roadmap

Bij het realiseren van een BPM roadmap bewijst TOGAF de grote meerwaarde die dit raamwerk kan leveren. TOGAF gaat uit van een incrementele en iteratieve implementatie van Enterprise Architectuur. Dezelfde incrementele benadering is van toepassing op de ontwikkeling en uitvoering van een BPM roadmap. Waar de enterprise architect expliciet de rol van BPM regisseur op zich neemt kan deze een door alle betrokkenen gedeelde roadmap definiëren en realiseren in een aantal afgestemde iteraties.

Een dergelijke Roadmap kent daarbij drie belangrijke dimensies: de fasering volgens de fasen van TOGAF, de “capabilities” die vanuit de BPM theorie moeten worden ontwikkeld en ten slotte de ambities van het bedrijf zoals vertaald in een te hanteren maturity model.

Ontwikkeling van een BPM Roadmap onder architectuur

In de verschillende fasen van TOGAF komen in wisselende samenstellingen de stakeholders van BPM aan de beurt om stappen te zetten en beslissingen te nemen. Kern hierbij is dat TOGAF dan wel expliciet van “Fasen” spreekt, maar dat hier niet per se een vaste volgorde in tijd en oplevering van deliverables bij hoeft te horen. Die automatische volgtijdelijkheid van de TOGAF fasen is eigenlijk alleen van toepassing bij bedrijven die een zeer hoge maturity hebben bereikt in hun Enterprise Architectuur proces. In verreweg de meeste gevallen is dit echter niet het geval. De fasen van TOGAF zijn daarom eerder aandachtsgebieden c.q. domeinen die wel elkaars producten gebruiken, maar niet in een vaste volgorde worden doorlopen. Juist omdat de producten per fase bekend zijn, kun je zonder gevaar voor foute stappen in iedere fase voortgang boeken, zolang je die producten en gezichtspunten per fase blijft respecteren.

Fase Business Architectuur

De Business architectuur van een onderneming wordt volgens TOGAF gevormd door de bedrijfsstrategie, de governance, de organisatie en de belangrijkste bedrijfsprocessen. In termen van BPM vindt men hier dus een grote mate van overlap. Ross en anderen beschrijven in het standaardwerk “Enterprise Architectuur als Strategie” (2006) [1] hoe een Enterprise Architectuur een “platform voor executie” moet opleveren dat het business model van het bedrijf optimaal ondersteunt. Von Rosing (2010) [2] benadrukt vanuit zijn BPM gedachtegoed dat de business architectuur opgebouwd moet worden vanuit de kerncompetenties en “capabilities” van een bedrijf. Daarbij maakt hij onderscheid tussen enerzijds kerncompetenties die noodzakelijk zijn om überhaupt te kunnen concurreren en kerncompetenties die ook echt een concurrentievoordeel opleveren. Het zijn die laatste competenties die in de inrichting van een Enterprise Architectuur tot bijzondere investeringen en oplossingen kunnen en mogen leiden. Competenties die slechts dienen om volgens industriestandaard te leveren (en derhalve geen concurrentievoordeel opleveren) dienen in zijn ogen te worden ondersteund met standaard IT “best practices” zoals geleverd door bijvoorbeeld Commercial Off the Shelf (COTS) standaard (ERP) pakketten.

Door deze benadering van bedrijfsprocessen als implementatie van onderliggende competenties en “capabilities” wordt ook het flexibele en veranderlijke van de bedrijfsprocessen expliciet gemaakt. In end-to-end procesketens zullen meer en meer veranderingen optreden, zoals het uitvoeren van delen van het proces door externe business partners, of het radicaal verkorten van een procesketen door de introductie van een internetgebaseerde procesafloop. De processen moeten dus vooral niet in “elektronisch beton” worden gevangen, maar moeten “orchestreerbaar” zijn.

Fase Informatiearchitectuur

Informatietechnologie speelt tegenwoordig een dominante rol in vrijwel alle bedrijfsprocessen en is daarom ook cruciaal met betrekking tot BPM. Enterprise Architectuur zorgt voor een heldere mapping van IT oplossingen en platforms op de eisen die vanuit de BPM filosofie aan IT gesteld worden.

BPM gaat uit van end-to-end procesketens. In termen van IT architectuur betekent dit dat applicaties en data de gehele procesketen moeten ondersteunen. De begrippen Orchestratie en Choreografie staan hier centraal. De ondersteuning van een gehele procesketen over afdelingen, systemen en business partners heen vereist dat data in de gehele procesketen beschikbaar is. Een ander vereiste is dat de benodigde IT-resources in het gehele proces beschikbaar zijn ongeacht in welke applicatie de functionaliteit is opgesloten. Een Service Oriented Architecture (SOA) is daarom een natuurlijke bondgenoot van BPM.

Het bekende CORA-model (Common Reference Architecture) [3], zie figuur 2, geeft helder weer hoe een op Service Oriented Architecture gebaseerde IT applicatiearchitectuur BPM kan ondersteunen. De gelaagdheid van een architectuur conform het CORA-model maakt het mogelijk de verschillende aandachtsgebieden efficiënt en effectief te verdelen en zorgt ervoor dat bij het ontwerp en de implementatie een zo flexibel mogelijk resultaat wordt bereikt. Omdat echter de intrinsieke complexiteit van een dergelijke architectuur groot is, kan alleen een goed resultaat bereikt worden als alle componenten ervan ook onder Enterprise Architectuur worden gemanaged en ontwikkeld.

Figuur 2: CORA-model

Fase Technische Infrastructuur

Hoe een BPM programma ook wordt ingestoken, op een zeker moment zullen feitelijke implementaties van BPM op basis van een Business Process management System (BPMS) plaats gaan vinden. In de meeste grotere bedrijven is de keuze voor een dergelijk BPMS geen sinecure. Omdat de in de markt beschikbare BPMS systemen van oorsprong uit verschillende domeinen zijn ontwikkeld (Workflow- en Case Management systemen, EAI-middleware platforms, Document management systemen) is de kans groot dat zich in het platformportfolio van een bedrijf reeds verschillende kandidaat-BPMS systemen bevinden. Het is de verantwoordelijkheid van de enterprise architect om hierbij de juiste technologische keuzes te maken. Overwegingen hierbij kunnen onder andere zijn de relatieve kwaliteit van de betreffende BPMS-tooling, de mate waarin het BPMS integreert met het bestaande applicatielandschap (zoals de ERP-systemen), de aanwezige kennis binnen de organisatie, de geldende licentiekosten en uiteraard de prioriteiten die binnen het bedrijf bestaan, omdat die uiteindelijk de business case moeten waarmaken.

Business Process Management levert meer waarde naarmate ook onderwerpen als integrale procesmonitoring, Business Activity Monitoring en Dashboard rapportages worden meegenomen. In veel gevallen zijn de beschikbare applicaties die deze (niet per se in het BPMS aanwezige) functionaliteit leveren afkomstig van producten van verschillende leveranciers en daar zal dus ook een enterprise architect de samenhang moeten bewaken.

Ten slotte is het heel waarschijnlijk dat uiteindelijk meerdere BPMS systemen tegelijkertijd binnen een organisatie zullen worden gebruikt. Het voorkomen van meerdere “inboxen” voor de eindgebruiker leidt dan tot een integratie- en federatie behoefte met betrekking tot de verschillende tools.

Deze infrastructurele en platform gerichte aspecten hebben te maken met de levenscyclus van de applicaties en infrastructuur en hebben daarom ook impact op c.q. worden geraakt door beschikbare investeringsbudgetten evenals het operationele beheer. In TOGAF termen wordt hier een sterke nadruk gelegd op het zogenaamde “Enterprise Continuüm” waarmee de maturity van aanwezige componenten en oplossingen kan worden gestuurd en continu afgestemd met de ambities van een bedrijf. Hoe snel een bedrijf kan bewegen in de richting van BPM wordt dus mede bepaald door de aanwezige basisarchitectuur.

Fase Opportunities & Solutions

In veel gevallen begint een Roadmap voor BPM niet vanuit een formeel architectuurproces of een top down BPM visie, maar vanuit een concrete behoefte die binnen het bedrijf leeft en waarvoor “toevallig” BPM een passende oplossing is. In de TOGAF fase ‘Opportunities & Solutions’ worden de methoden en middelen aangereikt waarmee kandidaat-processen voor BPM(S) kunnen worden geëvalueerd en in prioriteit en aantrekkelijkheid gemeten.

Met behulp van een “Process Discovery” methodiek wordt expliciet gemaakt welke waarde een BPMS-oplossing zal toevoegen aan de bestaande procesarchitectuur van een bedrijf. Het gaat hierbij vooral om procesoptimalisatie op basis van hogere transparantie, efficiency en effectiviteit, het verlagen van het aantal fouten in het proces, het wegautomatiseren van handmatige processtappen en het vereenvoudigen van invoerschermen voor de eindgebruiker.

In de regel zoekt men in een beginfase van BPMS implementaties naar processen die een hoge zichtbaarheid hebben voor de business, maar relatief laag in complexiteit zijn. Daarmee kan dan ervaring worden opgedaan die later kan worden gebruikt om de complexere processen aan te pakken.
Het zal duidelijk zijn dat bij het bepalen van de mogelijkheden en de verwachte voordelen ook de maturity op het gebied van IT tooling en de bestaande IT Roadmaps moet worden meegewogen. Ook wordt in deze fase gekeken naar de onderhoudbaarheid van een voorgestelde oplossing. De meeste BPMS implementaties worden immers gekenmerkt door een relatief hoge infrastructuur- complexiteit, waarbij tools uit verschillende lagen van het CORA-model gezamenlijk worden ingezet om een proces te stroomlijnen.

Het is de enterprise architect die de technische haalbaarheid van de voorgestelde oplossing toetst en de ontwerp- en architectuurprincipes aandraagt waar potentiële projecten zich aan moeten conformeren om het geheel consistent te houden.

Fasen Migratieplanning, Implementatie en Change Management

De TOGAF fasen Migratieplanning, Implementatie en Change Management hebben betrekking op de feitelijke executie en operatie van processen. Dit zijn de gebieden die normaliter het domein zijn van respectievelijk het Programma Management en de Beheer organisatie. Enterprise Architectuur helpt een BPM programma in deze fasen op de volgende gebieden:

  • Scheiding van verantwoordelijkheden en bepaling van de bewegingsvrijheid voor definitie van projecten met een BPM component.
  • Bewaking van afhankelijkheden en impact bij veranderingen.
  • Opzetten van Proces en Scenario-gebaseerd testen over de gehele procesketen.
  • Meten van feitelijke proces performance ten opzichte van Proces Performance Indicatoren.
  • Versnelling bij het oplossen van procesknelpunten en -issues.
  • Ondersteunen van management en eindgebruikers door middel van BPM Monitoring Dashboards.
  • Verlaging van de werkdruk bij operationeel beheer door het leggen van bepaalde procestaken bij eindgebruikers in de business (bijvoorbeeld het bijhouden van business rules).

BPM implementaties kunnen bij uitstek op incrementele en iteratieve manier worden opgezet. Dit betekent dat de doorlooptijd van de projecten aanzienlijk lager kan liggen dan men doorgaans gewend is. Door steeds nieuwe functionaliteit toe te voegen op basis van de intrinsieke flexibiliteit van BPM als gescheiden orchestratie- en choreografielaag bovenop de bestaande applicatiearchitectuur kan daarbij continu waarde worden toegevoegd. In de regel worden BPMS implementaties “agile” uitgevoerd, door middel van het gebruik van implementatiemethodieken als SCRUM, ATERN en RUP.

Tot slot

In dit korte bestek kon natuurlijk slechts in vogelvlucht ingegaan worden op de meerwaarde die bestaande concepten en “best practices” uit de Enterprise Architectuur kunnen bieden bij het “best practice”ontwikkelen en uitvoeren van BPM programma’s.

BPM begint in de business en niet binnen IT. Zowel bij strategische (top down) als tactische (op procesoptimalisatie gerichte) BPM initiatieven is het op de juiste manier verbinden van business en IT een belangrijke succesfactor. Top down BPM (van Business Model naar Capabilities naar Procesarchitectuur) past naadloos in de meer op governance en business architectuur gerichte fasen van TOGAF.

Procesoptimalisatie ondersteund door implementatie van BPMS systemen vereist een gedegen en goed doordachte IT architectuur, zowel wat betreft applicaties, data als infrastructuur. De brugfunctie van de enterprise architect is hierbij cruciaal.

De architect speelt ook een belangrijke rol in het stellen van de randvoorwaarden en ontwerpprincipes in de fase waarin mogelijke projecten worden vastgesteld op basis van business prioriteiten.

In de Implementatie- en Operatiefase bewaakt de architect de voortdurende aansluiting van oplossingen en technologische mogelijkheden. Tevens zorgt de architect ervoor dat de samenhang van de deliverables en producten uit de gehele TOGAF cyclus op elkaar blijven aansluiten en dat de maturity levels van iedere fase een logisch verband blijven houden.

Alleen de enterprise architect heeft de ervaring, capaciteiten en methodische expertise in huis om, geholpen door een raamwerk als TOGAF, de business optimaal te kunnen ondersteunen in een BPM programma en is onmisbaar om dit uiteindelijk tot een succes te maken.

Voetnoten
1 Een algemene kennis van TOGAF wordt in dit artikel voorondersteld; zie www.opengroup.org voor meer informatie.

Categorie:   
Auteur(s)
afbeelding van hansdiepstraten
Hans Diepstraten
Creetion - Enterprise Architect

Hans Diepstraten (1958) is enterprise architect bij Creetion, een consultancy bedrijf gespecialiseerd in BPM en Enterprise Architectuur. Hij heeft meer dan 20 jaar ervaring in (SAP) ERP- omgevingen en is gecertificeerd TOGAF 9 architect en Certified SAP Professional Business Process Expert.

 
Reacties
Walter Bril op woensdag 3 juni 2015 15:32

Beste Hans,

Geweldig artikel! Toeval is gebrek aan informatie zeg ik vaak; heb net deze week zelf een artikel op Linkedin gepost welke mijnsinziens goed aansluit op jouw verhaal uit 2011 (notabene). Maar wat mij betreft nog altijd actueel; dank daarvoor.

Vriendelijke groet,

Walter Bril

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.