Succesvol digitaliseren_2023_voorbeeldhoofdstuk_H5

5

Wat is de impact van ons digitaal initiatief op de organisatie?

1 Inleiding en leerdoel

Om het welslagen van een digitaal initiatief te ondersteunen, dient het altijd opgestart te worden vanuit een concrete businessvraag. Digitale oplossingen leveren immers ondersteuning aan bedrijfsprocessen en een digitaal initiatief kan pas zinvol worden genoemd als het resultaat ervan een directe positieve impact heeft op het functioneren van die bedrijfsprocessen of bijdraagt aan het realiseren van de bedrijfsstrategie. Naast het duidelijk in kaart brengen van de vereisten van de gebruikers, is het ook nodig om de bedrijfsprocessen en de impact van de digitalisatie op die processen te gaan analyseren en documenteren. We spreken daarbij van het opstellen van de process requirements. Uiteraard hangen de process requirements nauw samen met de andere vereisten die we in het hoofdstuk ‘Requirementsanalyse’ hebben bekeken. Omdat niet elk initiatief het uittekenen van process requirements vraagt en het uittekenen van de processen ook zeer relevant is binnen change management, is ervoor gekozen dat als een afzonderlijk hoofdstuk te behandelen.

Process requirements zijn de vereisten die een bedrijfsproces heeft ten aanzien van de ondersteunende digitale oplossing. Om die in kaart te brengen is het noodzakelijk de concrete bedrijfsprocessen uit te tekenen en te beschrijven zodat mogelijke optimalisaties in deze bedrijfsprocessen geïdentificeerd kunnen worden.

Op het einde van dit hoofdstuk:

… begrijp ik het doel en de verwachte resultaten van het opstellen van process requirements en het belang ervan voor de latere projectfases; onderscheid ik de verschillende rollen die bijdragen aan het opstellen van process requirements;

… kan ik de verschillende niveaus van bedrijfsprocessen benoemen.

2 Beschrijving en doel

Digitale oplossingen bieden in eerste instantie ondersteuning die ervoor zorgt dat een onderneming haar kernactiviteiten succesvol kan uitoefenen:

VOORBEELDEN

– In productiebedrijven worden de productielijnen en het warehousemanagement gestuurd door digitale toepassingen: order picking, voorraadbeheer, aansturen machines …

1. Initatie 2. Planning 3. Analyse 4. Implementatie 5. Test 6. Turnover

In transportbedrijven worden optimale bezetting en routes berekend.

In verkooporganisaties wordt het verkoopproces ondersteund door facturatieprogramma’s, online bestelmogelijkheden, CRM-systemen …

Niet enkel de kernprocessen maar ook andere ondersteunende diensten maken vaak gebruik van digitale toepassingen om hun taken te automatiseren of vlotter te laten verlopen:

– HR-toepassingen zorgen ervoor dat lonen worden berekend, vakantie kan worden aangevraagd en kandidaten online kunnen solliciteren;

– de boekhouding verloopt in elk bedrijf via gespecialiseerde software;

– de IT-dienstverlening wordt op haar beurt weer ondersteund door IT-toepassingen: opvolgen incidenten, aanvraag materiaal …

Zoals al in het deel ‘de context van projectmatig werken’ is aangehaald, zien we ook alsmaar meer dat digitale oplossingen deel gaan uitmaken van de diensten en producten die een onderneming aanbiedt aan haar klanten:

Banken zien een groot deel van hun diensten digitaliseren. Klanten komen niet langer aan het loket om verrichtingen te doen, maar doen dat via PC-banking of een mobile app.

Een speelgoedproducent levert via een app extra speelplezier door geboetseerde figuren tot leven te laten komen in augmented reality.

– Een onderneming gespecialiseerd in de opslag van documenten biedt nu ook de service aan om inkomende documenten automatisch te digitaliseren.

In die gevallen biedt de digitalisatie geen ondersteuning aan een intern businessproces, maar is er wel een proces dat de klant doorloopt als hij gebruikmaakt van die oplossingen.

Het is dus duidelijk dat de digitalisatie niet kan bestaan zonder de processen die ze moet ondersteunen of uitvoeren. Daarom is het ook zinvol om, liefst nog voor de aanvang van een project, te onderzoeken hoe de nieuwe toepassing de processen zo optimaal mogelijk kan ondersteunen of laten verlopen. In de gevallen dat de digitalisatie niet tot de kernactiviteiten van een onderneming behoort, dient ze ook winst te genereren vanuit de optimalisatie en/of mogelijke kostenbesparing bij het bestaande proces of de andere processen binnen het bedrijf. Een digitaal initiatief dat enkel kosten met zich meebrengt, is niet efficiënt voor een onderneming en zal op termijn niet kunnen overleven. Als de implementatie van de oplossing door een externe partij wordt uitgevoerd, wordt de noodzaak tot ‘winst’ nog groter. Geen enkele onderneming is immers bereid te betalen voor diensten die niets opbrengen op de lange termijn.

Het is dan ook duidelijk dat het bestuderen van de bestaande, huidige bedrijfsprocessen een aantal voordelen met zich meebrengt:

2.1 Input voor de mogelijke business case

In de initiatiefase wordt er typisch een business case voorgelegd aan het management en de eventuele sponsors van het project. Die business case bespreekt de kosten en baten van het project en moet aantonen wat de winst is die het project op middellange en lange termijn zal genereren. Een goede kennis van de businessprocessen en de specifieke noden van een bepaald proces zorgt ervoor dat de winsten voor dat proces zeer nauwkeurig kunnen worden bepaald.

2.2 Input voor het analysedocument

In de designfase van het project wordt er een analysedocument opgesteld dat heel gedetailleerd beschrijft wat de uiteindelijke resultaten van het project zullen zijn. Als de bedrijfsprocessen goed geanalyseerd werden, kan op basis daarvan geïdentificeerd worden wat er veranderd moet worden en op welke plaatsen in het proces dat moet gebeuren. Er wordt dan niet enkel een snapshot gemaakt van de huidige situatie, maar er zal ook een gedetailleerd beeld gegeven worden van de nieuwe situatie. Bovendien weten de ontwikkelaars ook wat er exact verwacht wordt van de applicatie en kunnen ze gebruik maken van deze procesbeschrijvingen om de ontwikkelingen te optimaliseren zonder altijd te moeten terugkoppelen naar de eindgebruikers. Het blijkt immers dat beschikbaarheid van eindgebruikers een van de grote struikelblokken is in een project en op deze manier kan er kostbare tijd gewonnen worden. Dat betekent echter niet dat alle communicatie met de eindgebruikers geschrapt kan worden!

2.3 Input voor de testfase

Bij het opstellen van de testscripts kan men zich baseren op de scenario’s die werden uitgeschreven in de procesbeschrijvingen. Op die manier wordt vermeden dat er delen van het proces vergeten worden tijdens het testen. Dat geldt zowel voor de testen uitgevoerd door de ontwikkelaars als door de eindgebruikers. Bovendien zullen de testscripts zeer herkenbaar zijn voor de eindgebruikers, ze zijn immers ook betrokken geweest bij het opstellen van de procesbeschrijvingen. In het hoofdstuk ‘Wat zijn de noden van onze klant? #requirements analyseren’ werden de user stories al besproken. Die dienden ook als input voor testscenario’s maar eerder in de vorm van een complete lijst van op te stellen scenario’s. De procesbeschrijvingen op taakniveau zullen de verschillende stappen van de testscenario’s voor een groot stuk kunnen bepalen.

2.4 Input voor change management

Door het opstellen van procesbeschrijvingen met toevoeging van swimlanes (swimlanes geven aan welke rol bepaalde taken in het proces zal uitvoeren) is het voor de change manager zeer snel duidelijk welke rollen in het proces door het project beïnvloed zullen worden.

De change manager kan identificeren welke rollen nieuwe taken zullen moeten uitvoeren en dus extra training nodig hebben, maar hij kan ook identificeren welke taken (en rollen) er geautomatiseerd zullen worden. Daardoor valt er dikwijls een groot deel van de taak van een bepaalde eindgebruiker weg en zal die persoon een nieuwe taak of nieuwe functie moeten krijgen in de organisatie. Door daar al bij het begin van het project op in te spelen, kan de weerstand ten aanzien van het project verminderd worden en is de kans op succes ervan groter.

Het is dus duidelijk dat een goede voorbereiding heel wat werk kan besparen in de latere fases van een project. Veelal wordt er niet voldoende of geen tijd besteed aan het identificeren van de process requirements waardoor er in de latere fases problemen ontstaan en de uitvoering van het project extra kosten met zich meebrengt of de vooropgestelde deadline niet gehaald wordt.

Het is duidelijk dat de voordelen van requirementsanalyse hetzelfde zijn als die van procesanalyse. In beide gevallen zorgen we ervoor dat we een duidelijk beeld hebben van de huidige situatie en van wat de klant/business verwacht van de nieuwe situatie en de oplossing. Waar we bij requirementsanalyse eerder stil staan bij de verwachtingen van de nieuwe applicatie en wat er allemaal in de oplossing moet worden opgenomen, kijken we bij procesanalyse vooral naar de manier van werken en de impact van

de oplossing op de organisatie. Waar requirementsanalyse input levert voor het totale kostenplaatje van de nieuwe oplossing, levert procesanalyse een inzicht in de eventuele kosten voor de organisatie (training, heroriëntatie van medewerkers, …) en in de mogelijke winst die gemaakt kan worden door optimalisatie en verbetering (tijdswinst, minder fouten, minder personeel, …).

3 Rollen en verantwoordelijkheden

Het opstellen van de process requirements gebeurt meestal door de eindgebruikers en de businessanalist. In één of meerdere workshops worden de processen doorlopen en worden de verschillende stappen en taken vastgelegd.

– De businessanalist is verantwoordelijk voor het opstellen van de procesbeschrijvingen op basis van de input die geleverd wordt door eindgebruikers en sleutelgebruikers tijdens de workshops. Hij kan zich eveneens baseren op al bestaande handleidingen, documenten en testbeschrijvingen indien beschikbaar. Naast het accuraat beschrijven van de huidige processen, is de businessanalist ook verantwoordelijk voor het identificeren van mogelijke optimalisaties. Die kunnen aangegeven worden door de eindgebruikers op basis van een duidelijk omschreven nood, maar de businessanalist kan ook gebruik maken van best practices om de bedrijfsprocessen te optimaliseren. In de procesanalyse speelt de businessanalist dus een grotere adviserende rol. Daar kunnen meestal grote winsten worden behaald door op de juiste plaatsen in het proces optimalisaties en verbeteringen aan te brengen.

Een best practice is een bepaalde manier van werken of een bepaalde opzet van een applicatie die op basis van verschillende eerdere implementaties tot stand is gekomen en de beste manier van werken identificeert binnen een bepaald domein, een bepaalde taak of applicatie.

– De process owner is binnen de onderneming verantwoordelijk voor een bepaald proces of deelproces. Deze sleutelgebruiker staat in voor de optimalisatie van het proces en moet ervoor zorgen dat eventuele problemen zo snel mogelijk geïdentificeerd en opgelost worden. Het is dan ook de process owner die de initiële input geeft over het proces en de finale beslissingen neemt bij mogelijke wijzigingen. Bij het maken van keuzes tussen verschillende opties, weegt de stem van de process owner zwaar door. Hij/zij moet eventueel knopen doorhakken als er geen overeenstemming kan worden gevonden.

– De eindgebruikers zijn de huidige of toekomstige uitvoerders in het proces. Ze voeren de taken uit in het proces en zullen in de toekomst met de nieuwe oplossing werken. Ze leveren input voor de opstelling van de procesbeschrijving en kunnen veelal meer detail geven dan de process owner. Het is ook vaak zo dat het effectief uitvoeren van de taken op de werkvloer kan verschillen van de opgestelde procedures en taakomschrijvingen. Het achterhalen van die verschillen kan zinvolle informatie opleveren voor het toekomstige proces. Het is immers zo dat afwijkingen van de procedures dikwijls het gevolg zijn van een slecht omschreven taak of een moeilijk haalbare procedure. Het opsporen en oplossen daarvan is al een optimalisatie van het huidige proces. Omdat het opzetten van een nieuwe applicatie de ruimte biedt om procedures te optimaliseren, is het zeer aangewezen om dit soort afwijkingen op te lossen bij de implementatie.

– Sleutelgebruikers zijn ook hier een specifieke groep van eindgebruikers die een zeer goede kennis hebben van het huidige proces, veelal door een jarenlange ervaring. Omdat niet alle eindgebruikers kunnen deelnemen aan het project, worden er dikwijls een aantal sleutelgebruikers geïdentificeerd die namens de hele groep eindgebruikers deelnemen.

4

Deliverables

Het eindresultaat van het opstellen van de process requirements is een procesbeschrijving aan de hand van gedetailleerde process fl owcharts. Een process flowchart beschrijft de verschillende stappen van een proces in een specifieke volgorde en geeft aan welke gegevens er worden doorgegeven en welke documenten of andere output er worden gegenereerd. Vaak worden er ook afhankelijkheden weergegeven met andere processen. Als men ook de rollen wil weergeven binnen een process flowchart, maakt men gebruik van swimlanes. Door die visualisatiemethode worden de taken horizontaal gegroepeerd per rol, zodat zeer snel duidelijk wordt welke rol de taken uitvoert en welke rollen het belangrijkst zijn in een bepaald proces.

In figuur 1 wordt een bestelproces weergegeven van een boekenwinkel. De verschillende rollen worden links weergegeven en op basis van de verschillende horizontale stroken (de swimlanes) worden de taken verdeeld over de verschillende rollen.

Figuur 1 Swimlane diagram.

Bestelling boeken

Het opstellen van een flowchart met swimlanes kan de tekening heel complex maken, zeker bij zeer grote processen. Het is aangewezen om een groter proces op te delen in kleinere deelprocessen of enkel gebruik te maken van swimlanes op bepaalde niveaus van de process flowchart (zie verder).

Het opstellen van een swimlane diagram kan met verschillende tools. Er bestaat gespecialiseerde software die automatisch rekening houdt met afhankelijkheden, rollen en outputmogelijkheden. Een voorbeeld daarvan is Signavio, een softwareprogramma specifiek ontworpen om aan business process modelling te doen. Een andere mogelijkheid is Bizagi, dat ook een gratis toolbox aanbiedt voor kleine projecten of om eenvoudige simulaties te doen.

Hoofdstuk 5 Wat is de impact van ons digitaal initiatief op de organisatie? #processen

Net zoals we de vereisten op verschillende niveaus kunnen voorstellen, kunnen we ook een bedrijfsproces op verschillende niveaus beschrijven, die elk een verschillende graad van detail voorstellen. Een mogelijke verdeling wordt hieronder weergegeven, maar de uiteindelijke definitie van de verschillende niveaus hangt sterk af van de gebruikte techniek, software en complexiteit van de processen in een project.

1 Niveau 1: ondernemingsprocessen

Op dit niveau worden enkel de grote processen van een onderneming besproken: productieproces, salesproces, warehousing … Het is een eerste beschrijving van de hele waardeketen van een onderneming en geeft vooral de volgorde en de afhankelijkheden van de verschillende processen weer. We kunnen hier nog niet spreken van rollen en bekijken de organisatie op niveau van de organisatie-eenheden. Op dat niveau kunnen we de link leggen met de business requirements, het is immers vaak op dat niveau dat de strategische doelstellingen worden bepaald.

2 Niveau 2: afdelingsprocessen

Op dit niveau bekijken we de verschillende processen per afdeling.

VOORBEELDEN – bestelling;

facturatie; – dienst-na-verkoop.

Elk van die processen bestaat meestal nog uit kleinere deelprocessen die in een volgend niveau besproken worden. Daar kan men dikwijls al op teamniveau bepaalde processen toewijzen. Er kunnen ook al outputs gedefinieerd worden zoals facturen, bestelbonnen … Op dit niveau zien we de features terugkomen: functionaliteiten die logisch gegroepeerd worden en een meerwaarde kunnen betekenen voor de organisatie.

3 Niveau 3: deelprocessen

Op dit niveau worden verschillende deelprocessen besproken.

VOORBEELD

Een bestelling kan bestaan uit:

– bestelbon opmaken;

– bestelling klaarmaken;

bestelling versturen.

Dit niveau is een meer gedetailleerde weergave van niveau 2 en bespreekt vooral activiteiten met hun actoren en outputs. Niveau 3 legt het verband met de verschillende functionaliteiten die binnen een bepaalde feature zullen worden opgenomen.

4 Niveau 4: taken

Op het laagste niveau worden de verschillende taken weergegeven met de uitvoerder en output per taak. Op dit niveau kan er zeker gebruik gemaakt worden van swimlanes. Het is daarbij ook mogelijk dat er een swimlane voorzien wordt voor ‘de digitale oplossing’ om aan te geven welke taken er geautomatiseerd uitgevoerd worden. Dit niveau vormt ook de input voor testscripts en kan gebruikt worden door de ontwikkelaars ter ondersteuning van hun werk. Op dit niveau is het

duidelijk dat de user requirements ook vorm krijgen, we beschrijven immers exact welke taken de gebruikers gaan uitvoeren.

Hoofdstuk

Als men gebruik maakt van een softwarepakket voor het beschrijven van de processen, heeft men als voordeel dat men eenvoudig een niveau dieper kan gaan in de processen door te klikken op een stapje in een hoger niveau. Er wordt dan automatisch gesprongen naar het niveau lager zodat dat stukje van het proces in meer detail bekeken kan worden. Ook de afhankelijkheden worden automatisch weergegeven en vaak kan er ook een voorbeeld toegevoegd worden van een outputdocument. De software zal de gebruiker ook wijzen op inconsistenties in de procesbeschrijving

5 Afhankelijkheden

In de eerste paragraaf van dit hoofdstuk werden er al een aantal afhankelijkheden weergegeven tussen de procesanalyse en andere activiteiten in het initiëren en opleveren van digitale oplossingen. Procesbeschrijvingen die in deze fase worden gemaakt, kunnen in de volgende fases gebruikt worden ter ondersteuning van de business case, het analysedocument, het change management en de testen. Het is dus een zeer belangrijke stap die, als hij overgeslagen wordt, tot extra kosten kan leiden in de volgende fases. Toch is het belangrijk een duidelijk onderscheid te blijven maken tussen het voorbereidende werk dat gebeurt tijdens de initiatie en het uiteindelijke projectwerk wanneer wordt besloten dat het project zal worden uitgevoerd.

Het opstellen van vereisten en processen is een belangrijk onderdeel van de designfase van het project. Het is dan ook niet de bedoeling dat dit al volledig gebeurt in deze fase. In de eerste voorbereidende fase is het vooral de bedoeling om te identificeren waar er opportuniteiten liggen voor optimalisatie en waar er dus mogelijkheden zijn om een project op te starten. In deze fase wordt er een nood vanuit de business geïdentificeerd alvorens er sprake is van een bepaalde digitale oplossing. Het is ook belangrijk die noden te identificeren vanuit het proces zelf en niet in het kader van een bepaalde softwaretoepassing. Enkel op die manier kunnen er juiste prioriteiten gesteld worden, die op termijn resulteren in het meest optimale resultaat en dus in de grootste winst voor een project.

Pas wanneer de software/oplossing geselecteerd is, zal er in de designfase gekeken worden naar de mogelijke oplossingen om zo goed mogelijk aan de noden van de eindgebruikers te voldoen. Er zal dan ook nog geen toekomstig proces op taakniveau worden omschreven in deze fase, omdat de volgorde van taken en zelfs de uit te voeren taken veelal samenhangen met de keuze van een specifieke software. Er wordt in dit hoofdstuk dan ook niet gesproken over designtechnieken zoals UML, omdat die gebruikt wordt om de nieuwe applicatie te beschrijven.

6 Aandachtspunten

1 Reserveer voldoende tijd voor de procesanalyse Het opstellen van een procesbeschrijving is niet altijd een gemakkelijke taak. Zeker voor processen die niet onderhevig zijn aan reglementering (verkoop, rekrutering, CRM …) kan het opstellen van de processen soms veel tijd in beslag nemen. Die processen worden vaak ingevuld door de eindgebruikers die ze moeten uitvoeren en daarbij is het niet altijd meer te achterhalen waarom bepaalde taken worden uitgevoerd op de huidige manier. Processen zijn ook veelal complexe verzamelingen van verschillende deelprocessen en taken waardoor er verschillende personen moeten deelnemen aan het in kaart brengen ervan. Er is bijna nooit één persoon die het volledige plaatje kent. Er moet dus voldoende tijd besteed worden aan het goed in kaart brengen van processen.

5 Wat is de impact van ons digitaal initiatief op de organisatie? #processen

2 Betrek opnieuw de juiste gebruikers

Wanneer eindgebruikers de kans krijgen om de huidige manier van werken te (her-)bekijken, zijn het vooral de ontevreden gebruikers die meewerken om eventuele veranderingen te verkrijgen. Het is daarom belangrijk alle betrokkenen te consulteren en goed te onderscheiden wat een procesprobleem en wat een persoonlijk probleem zou kunnen zijn.

3 Beheers de complexiteit

Het opstellen van procesbeschrijvingen kan heel complex worden. De procesbeschrijvingen zijn enkel bruikbaar als ze snel kunnen gelezen worden door zowel eindgebruikers als ontwikkelaars. Daarom is het van belang om de complexiteit te beheersen, onder andere door gebruik te maken van software of door een complex proces op te splitsen in deelprocessen. Maak ook zeker goede afspraken met alle betrokkenen over terminologie en gebruik van iconen zodat alle processen binnen een onderneming op dezelfde transparante manier gedocumenteerd worden.

4 Houd rekening met de vervaldatum

Procesbeschrijvingen hebben maar een beperkte houdbaarheidsdatum. Veelal hangt de invulling van een proces af van de betrokken eindgebruikers en mogelijke invloeden van buitenaf. Als er een reorganisatie plaatsvindt of de wetgeving verandert, kan het zijn dat het proces ook mee zal moeten veranderen. Als er dus een grotere tijdspanne zit tussen de voorbereidende fase en het uiteindelijke project, kan het zijn dat de procesbeschrijvingen herzien moeten worden.

5 Controleer afhankelijkheden met andere processen

Een proces staat zelden op zichzelf binnen een onderneming. Doordat alle processen samenwerken kan een onderneming succesvol functioneren en winst maken. Daarom is het belangrijk om aandacht te hebben voor de afhankelijkheden tussen het proces dat je bekijkt en de andere processen binnen de onderneming. Een interessante business case voor de optimalisatie van een bepaald proces kan plots een stuk minder interessant worden als de negatieve impact op een ander proces vrij groot is.

7 Methodologieën – BPMN

Er zijn uiteraard verschillende technieken om aan business process modeling te doen. Een van de technieken die de laatste jaren aan populariteit wint is BPMN, ofwel Business Process Model and Notation.

BPMN is een standaard in business process modeling ontwikkeld door de Object Management Group die tracht de kloof tussen het ontwerpen van bedrijfsprocessen en het implementeren ervan te overbruggen. BPMN maakt businessprocessen begrijpelijk voor zowel businessanalisten als ontwikkelaars en zorgt ervoor dat de processen gemakkelijk te onderhouden zijn door eindgebruikers en managers.

7.1 Evolutie van BPMN

BPMN werd in 2004 geïntroduceerd door het Business Process Management Initiative (bpmi.org) met als doel een standaard vast te leggen voor het modelleren van bedrijfsprocessen. In eerste instantie werd er een metataal ontwikkeld, met name BPML, die gevolgd werd door een grafische notitie, wat uiteindelijk resulteerde in BPMN.

7.2 BPMN 1.0 (2006)

De eerste versie van BPMN had als doel vast te leggen welke objecten er gebruikt zouden worden en hoe deze objecten met elkaar zouden interageren. Bij het selecteren van de grafi sche elementen werd er maximaal gekeken naar de herkenbaarheid van de elementen voor de verschillende betrokken partijen, maar werd er ook voor gezorgd dat er een zekere complexiteit kon worden beschreven. Figuur 2 geeft aan welke objecten gebruikt kunnen worden voor het modelleren van processen:

Figuur 2 BPMN 1.0-objecten (Object Management Group, 2006).

Flow objects

Connecting objects Event

7.2.1 Flow objects

Swimlanes

Flow objects zijn de bouwstenen van het proces. Hierbij wordt er een onderscheid gemaakt tussen drie verschillende objecten:

Events stellen een gebeurtenis voor in het proces, intern of extern.

– Activities zijn de deelprocessen of taken binnen een proces.

– Gateways zijn punten waar een proces wordt opgesplitst of terug samenkomt. Dit gaat meestal samen met een beslissing binnen het proces.

7.2.2 Connecting objects

Connecting objects zorgen voor de structuur van het proces en verbinden de bouwstenen met elkaar. Ook hier zijn verschillende ‘stromen’ te onderscheiden die elk een eigen functie vervullen binnen het proces:

Sequence flows geven de volgorde aan waarin de verschillende activiteiten worden uitgevoerd. Die sequence flows kunnen dan, afhankelijk van de voorwaarden die gesteld worden, nog verder opgedeeld worden in default flows (dit pad wordt standaard gevolgd), conditional flows (dit pad wordt enkel gevolgd als een bepaalde conditie vervuld wordt) en exception flows (dit pad wordt enkel gevolgd als zich een uitzonderlijk event voordoet).

Message flows geven de berichtenstroom weer tussen verschillende rollen.

– Associations geven de afhankelijkheden weer tussen verschillende objecten.

7.2.3 Swimlanes

Ook BPMN maakt gebruik van swimlanes om rollen en verantwoordelijkheden weer te geven.

Hoofdstuk 5 Wat is de impact van ons digitaal initiatief op de organisatie? #processen

7.2.4 Artifacts

Artifacts worden gebruikt om extra informatie op te slaan in het procesdiagram. Het kan bijvoorbeeld gaan over dataobjecten die weergeven welke specifieke data nodig zijn om een bepaalde activiteit uit te oefenen. Een ander voorbeeld zijn annotaties die elke andere vorm van extra informatie kunnen bevatten.

7.3 BPMN 1.1 (2008) en BPMN 1.2 (2009)

De update die werd doorgevoerd in BPMN 1.1 en BPMN 1.2 had vooral tot doel een aantal verduidelijkingen door te voeren. Er werden nieuwe subcategorieën toegevoegd binnen de objecten en hier en daar werd er een afbeelding gewijzigd om het proces duidelijker te maken. De update kon echter niet omschreven worden als een fundamentele wijziging in BPMN.

7.4 BPMN 2.0 (2011)

In 2011 werd de nieuwe versie van BPMN voorgesteld en die wordt tot op heden nog gebruikt. Deze versie had vooral tot doel de vorige versies te optimaliseren en een eenvormige standaard te ontwikkelen zodat procesmodellen eenvoudig uitgewisseld kunnen worden tussen de verschillende modelleringstools. Naast een wijziging in de naam (van Business Process Modelling Notation naar Business Process Model and Notation) werden er ook belangrijke wijzigingen doorgevoerd die de vertaling naar uitvoerbare talen zoals BPEL eenvoudiger zou maken. BPEL staat voor Business Process Execution Language en is een op XML gebaseerde taal die toelaat processen te beschrijven die verbonden zijn via webservices.

BPMN wordt momenteel ondersteund door verschillende tools en wordt wereldwijd in grote organisaties als de standaard gebruikt. Het dient wel opgemerkt te worden dat BPMN nog altijd vooral zijn toepassing vindt in het modelleren van bedrijfsprocessen. In deze context heeft BPMN zeker gezorgd voor een eenduidiger en transparantere manier van modelleren. Toch zijn er nog een aantal bedenkingen te maken bij BPMN:

– De vertaling van BPMN naar BPEL mag dan wel een van de objectieven geweest zijn in de nieuwe versie, het blijft een zeer moeilijke opdracht. Een eenduidige vertaling vereist immers eenduidige modellen. Daarnaast moet de vertaling ook exact weergeven wat er werd bedoeld bij het opstellen van het proces in BPMN. Gezien de opstelling nog altijd gebeurt met inmenging van een sterk menselijke factor, is het maar de vraag hoe correct dit automatisch vertaald kan worden.

– Een standaard blijft enkel behouden als hij altijd correct gebruikt wordt. De kwaliteit van de standaard is dus maar zo goed als de personen die de standaard hanteren. Daarom moet men bij hergebruik van modellen altijd kritisch bekijken of de standaard overal correct werd toegepast.

– Door de wijzigingen doorheen de verschillende versies op een relatief korte tijdspanne, moet men ook altijd goed in het oog houden in welke versie een proces werd beschreven.

VOORBEELD Context

Een klant bestelt een boek bij een onlineboekenwinkel. Wanneer de bestelling binnenkomt en de betaling geverifieerd is, zal de persoon die de bestelling behandelt nakijken of het boek in voorraad is. Als dat effectief het geval is, wordt het boek uit de voorraad gehaald en ingepakt voor verzending. Vervolgens wordt het boek verzonden. Als het boek echter niet meer op voorraad blijkt te zijn, moet de aankoopdienst verwittigd worden zodat er een nieuwe voorraad kan worden aangekocht.