Simulatie van het verloop van een verkooporderproces met Mida - Camunda

Een paar dagen geleden liep ik tegen het project MIDA van de University of Camerino aan.

MIDA (Multiple Instances and Data Animator) is het resultaat van een onderzoeksproject van de School of Science and Technology, Computer Science Division.

MIDA is een simulator die door middel van tokens laat zien hoe een proces doorlopen wordt. Onderstaande video laat als voorbeeld de simulatie van het ordering proces tussen een groothandel en leverancier zien. Dit proces wordt later in het artikel verder uit de doeken gedaan.

MIDA is een uitbreiding van de Camunda Modeler (bpmn.io) Token Simulation plugin.

MIDA kan zonder problemen geïnstalleerd worden. Ga naar de website http://pros.unicam.it/mida/ en selecteer download. Unzip het bestand en start dan de executable Mida.exe.

Simulatie ordering proces wholesaler - supplier

De Token Simulation plugin visualiseert de voortgang van activiteiten in een BPMN collaboration diagram door middel van tokens die zich voortbewegen in het procesmodel. De verwerking van gegevens en het uitwisselen van berichten worden niet ondersteund door de plugin zoals gezien kan worden in onderstaande simulatie van een procesmodel.

In dit procesmodel worden berichten uitgewisseld tussen een groothandel (lane: wholesaler) en een leverancier - fabrikant (lane: supplier).

[Note: lane wholesaler = bovenste swimlane, lane supplier = onderste swimlane]

MIDA, daarentegen, maakt het wel mogelijk om de gegevensstromen tussen deelnemers (swimlanes) aan het proces zichtbaar te maken en te laten zien wanneer nieuwe proces-instanties worden gestart.

[Note: een procesmodel is een beschrijving van / een blueprint van een proces, een procesinstantie (process instance) is de concrete uitvoering van een model. Op hetzelfde moment kunnen meerdere instanties van een proces actief zijn.]

Het zijn de gegevens in berichten tussen deelnemers die het gedrag van het proces beïnvloeden. De gegevens worden opgeslagen in data objecten die mede bepalen welke stappen daarna worden uitgevoerd.

In het bovenstaande procesmodel geeft de taak "Send purchase order" aan dat er een bericht (een inkooporder) van de groothandel naar de leverancier wordt gestuurd. Het bericht bevat onder andere volgende gegevens: ordernummer (PO_number), regelnummer (POLine_itemNumber), verzoek tot het ontvangen van een orderbevestiging (PO_confirmation), de identificatiecode van de inkopende organisatie - GTIN / EAN of UPC code (PO_buyerID). Deze gegevens worden overgedragen aan het data object "purchase order" en zijn input voor de taak "Validate order".

et veld PO_confirmation beantwoordt later de vraag die gesteld wordt door de exclusive gateway "Confirm order ?".

MIDA verplicht je om uitgebreider na te gaan denken over hoe informatie wordt overgedragen in het samenspel tussen verschillende participanten, hoe participanten samenwerken en hoe gegevens doorheen het model stromen. Wanneer de initialisatie van gegevensvelden en de overdracht van deze gegevens aan taken niet goed zijn gedefinieerd leidt simulatie van het model tot errors.

MIDA simulatie ordering proces wholesaler - supplier.

Wanneer de processimulatie start zien we in het logging-overzicht links onder dat er 1 instantie van het proces is gestart. Dit is het proces in de bovenste swimlane - het proces van de groothandel.

Create purchase order

Het proces in de bovenste swimlane start met een vraag of wens vanuit de organisatie voor een product, materiaal of grondstof. Deze behoefte leidt tot de creatie van een inkooporder.

Rechtsboven onder de drop down Data Panel zijn de gegevens zichtbaar van de behoefte en de inkooporder.

Send purchase order

Wanneer de purchase order wordt verstuurd worden de gegevens via het gele informatie-token met nummer 1 doorgezet naar de message start event in het proces van de supplier.

Gelijktijdig wordt het token doorgestuurd naar de event based gateway waar het zal wachten op een antwoord vanuit het proces van de leverancier. Bij aankomst van het eerste token bij de event based gateway krijgt het token een rode kleur. Deze kleur zal het token houden tot de melding komt of de order geaccepteerd is of niet.

Receive purchase order

Bij ontvangst van de purchase order in de swimlane van de leverancier start een tweede procesinstantie, het proces van de leverancier.

Validate order

Na validatie van de order in de onderste flow heeft de variabele orderAccepted de waarde True gekregen en gaat het tweede token naar de taak "Enter order".

Enter order

Tijdens de uitvoering van de taak "Enter order" wordt een verkooporder aangemaakt in het ERP-systeem van de leverancier.

Send acceptance

Nadat de order is vastgelegd in het ERP-systeem van de leverancier wordt de acceptatie van de order gemeld aan de groothandel via het gele informatie-token met nummer 2.

Het tweede token in de onderste flow vervolgt zijn weg naar het kruispunt - de exclusive gateway "Confirm order ?". Het antwoord op deze vraag is meegestuurd met de gegevens van de inkooporder in het veld PO_confirmation en opgeslagen in het veld SO_confirmation van de verkooporder in het ERP-systeem van de leverancier.

Gateway Wait for confirmation

Het eerste token in de bovenste flow verandert van kleur na het ontvangen van de melding dat de order is geaccepteerd. Daarna gaat het token verder naar het kruispunt - de exclusive gateway "Wait for confirmation ?". Het antwoord op deze vraag is opgeslagen in het veld PO_confirmation van de inkooporder.

Het tweede token in de onderste flow vervolgt zijn weg naar het kruispunt - de exclusive gateway "Confirm order ?". Het antwoord op deze vraag is meegestuurd met de gegevens van de inkooporder in het veld PO_confirmation en opgeslagen in het veld SO_confirmation van de verkooporder in het ERP-systeem van de leverancier.

Send confirmation

Wanneer de groothandel om bevestiging van levertijd (PO_confirmation = true) vraagt gaat het tweede token naar de taak "Confirm order". Deze taak verstuurt de orderbevestiging naar de groothandel via het informatie-token nummer 2.

Receive confirmation

Op het moment dat de order confirmation wordt ontvangen in de bovenste flow licht de taak "Receive confirmation" groen op en vervolgt het eerste token zijn weg naar de taak "Receive delivery".

In de onderste flow gaat het tweede token verder naar de taak "Create shipment".

Create shipment

Ship order

De taak "Ship order" zorgt dat de goederen fysiek worden verstuurd en informeert de groothandel via het gele informatie-token met nummer 2 over de inhoud van de levering.

In de bovenste flow kleurt het eerste token rood omdat het proces wacht op de ontvangst van de levering.

Receive delivery

Na ontvangst van het gele informatie-token met de informatie over de levering licht de taak "Receive delivery" groen op en vervolgt het eerste token zijn weg naar de taak "Receive invoice".

Ondertussen is in de onderste flow de taak "Create invoice" uitgevoerd en zal ik de volgende stap de factuur verzonden worden naar de groothandel.

Send invoice

Ook hier kleurt het eerste token rood omdat het proces wacht op de ontvangst van de factuur.

Receive invoice

Wanneer het gele informatie-token met de factuur is verwerkt door de taak "Receive invoice" licht deze processtap groen op en eindigt het onderste proces zoals linksonder te lezen valt.

Einde proces

Aan het einde van het proces zien we rechts dat beide instanties 1 en 2 beëindigd zijn.

Data panel

Tijdens de simulatie geeft het data panel een overzicht van de gegevens die worden uitgewisseld.

Simulation log

De simulation log geeft een overzicht van de stappen en de tijdstippen waarop deze doorlopen zijn.

Tags: BPMN, O2C

Continue!

High level verkoopproces in BPMN en Archimate

Een probleemloze ERP implementatie vraagt om inzicht in meer dan de (huidige - oude) processen en informatiestromen.

Het bestaande informatie- en applicatielandschap heeft een grote invloed op de haalbaarheid van ERP - misschien is het nodig om één ander te rationaliseren.

Ik raad bedrijven aan om toekomstige processen "ERP - applicatie neutraal" te beschrijven. Hierbij verplicht je gebruikers om na te denken over wat ze echt nodig hebben.

Zelf gebruik ik hiervoor een scala aan modelleertools en -talen - alle modellen binnen BPMN, Archimate, DMN. Dagelijks merk ik weerstand voor deze aanpak maar deze verdwijnt vrij snel wanneer de organisatie betrokken wordt in het beschrijven.

Learning-by-doing: leg samen interne processen en afhankelijkheden met applicaties vast

Welk tool (Signavio, Bizagi, Cawemo, Camunda, ...) gebruiken of welke taal (BPMN, Archimate) is niet echt relevant.

Ultimo gaat het om het proces van bewustwording aan de kant van de gebruiker.

Archimate of BPMN, voor high-level procesbeschrijvingen kan beiden zoals je hierna kunt zien: BPMN

BPMN

Archimate

Tags: BPMN, Archimate

Continue!

Gaan een taakstellend budget en een Agile implementatiemethodiek wel samen ?

Steeds vaker stellen implementatiepartners van bedrijfsinformatiesystemen (ERP, CRM, PLM, ...) hun klanten voor om te werken met een taakstellend budget welke gecombineerd wordt met een Agile implementatiemethodiek. De gewenste resultaten worden ondergeschikt gemaakt aan het budget. Het is in de optiek van de leverancier immers onmogelijk om deze resultaten vooraf te bepalen. Bovendien komen gaandeweg het project de teams van leverancier en klant tot andere inzichten. De leverancier gaat de omgeving van de klant beter begrijpen en de klant gaat de mogelijkheden van de oplossing doorzien.

Het mag echter duidelijk zijn dat een aanpak waarbij "Less Thinking & Designing Upfront" minder garanties biedt dat de wensen en eisen van de klant gerealiseerd gaan worden. Nog minder aandacht / ruimte is er voor het realiseren van de 'gain points' - de winstpunten - en het elimineren van de 'pain points' - pijnpunten - van de klant.

En laten we realistisch zijn, het zijn deze beloftes die gebruikers over de streep trekken om een bijdrage te leveren. Ja, we gaan participeren als we er ook wat voor terug krijgen.

Hoe haaks staat het idee van een taakstellend budget op deze aanpak?

Laten we beginnen met "wat is een taakstellend budget ?" De term wordt makkelijk in de mond genomen maar als we zoeken op Google zijn er weinig definities te vinden. Uit de zoekresultaten heb ik volgende definities geselecteerd:

1) Taakstellend budgetteren is een methode waarbij het budget wordt afgestemd op de te bereiken resultaten.

2) Taakstellend budgetteren gaat uit van het realiseren van vooraf afgesproken resultaten en het aanvaarden van de consequenties van het niet realiseren van deze resultaten.

3) Een taakstellend budget is een budget voor het realiseren van de van-tevoren afgesproken resultaten.

Uit al deze definities kunnen we een paar belangrijke zaken afleiden: allereerst de gewenste resultaten zijn vooraf in kaart gebracht en vastgesteld, het budget is afgestemd op deze resultaten en het kan zijn dat sommige resultaten niet gerealiseerd worden.

Nu weten we dat in een zuivere Agile benadering de resultaten van iteraties voorafgaande niet bekend zijn en dat de hoeveelheid werk die verzet kan worden beperkt wordt door het beschikbare budget.

Is een taakstellend budget met een Agile implementatiemethodiek niet een aanpak om te verdoezelen dat gebruikers (gebruikersorganisatie) niet gaan krijgen wat ze willen ? Er is immers een veel groter budget nodig om aan al de wensen en eisen van de klant te voldoen, om zoals dat zo mooi heet "de stip op de horizon" te realiseren.

De ervaring leert dat het merendeel van de implementatieprojecten die een zuivere Agile aanpak volgen leiden tot budget en scope discussies, tot ontevreden gebruikers, tot halfbakken oplossingen, en tot oplevering van minder functionaliteiten dan voorheen beschikbaar waren.

De oplossing ligt in een hybride aanpak bestaande uit een traditionele Business blue print fase, een Agile realisatiefase en een traditionele deployment - go-live fase.

Tijdens de Business blue print fase wordt de bestaande en toekomstige situatie geïdentificeerd, de gewenste resultaten beschreven / gemodelleerd en geprioritiseerd, en het benodigde budget daarop afgestemd.

Tijdens de Agile realisatiefase wordt de technische en functionele invulling van de gewenste resultaten door een multi-functioneel team vorm gegeven, de baseline gedefinieerd en in iteraties de gain- en pain-points weggewerkt. Voortschrijdend inzicht van leverancier en klant zorgt dat met minder kosten meer resultaten kunnen worden gerealiseerd.

Deze hybride aanpak voorkomt - mijns inziens op basis van actuele ervaring - dat het project een speelbal wordt van scope- en budgetdiscussies.

Tags: ERP, PLM, agility

de Auteur

Mijn aandachtsgebieden zijn: de uitdagingen waar bedrijven / managers en directeuren voor staan, het bieden van hulp bij de zoektocht naar antwoorden op deze uitdagingen, de technologische ontwikkelingen die de verhoudingen op zijn kop gaan zetten in de komende maanden / jaren, het begeleiden van adviestrajecten van concept tot realisatie.

Mijn passie ligt bij het integreren en innoveren van bedrijfsprocessen, informatiestromen, systemen en organisaties zodat medewerkers en bedrijven zich volledig kunnen richten op hun kerntaken en bedrijven hun ambities kunnen waarmaken onder het motto "Giving control back to Business".

Ik heb 30 jaar ervaring in de Maakindustrie, Bouw- en Installatiebranche bij internationale bedrijven op het gebied van proces-, project- en implementatiemanagement, ketenintegratie, ERP selectie en implementatie, stroomlijnen en implementatie van O2C en P2P processen.

Continue!