De kracht van modellen in IT-ontwikkeling (en de kracht van koffie)
Door: Thije Nijhuis, Senior Business Analist bij Heeyoo
Stel je voor: je bent net begonnen bij een nieuwe klus en voor je het weet ben je verantwoordelijk voor het belangrijkste ritueel van de dag – koffie halen voor het hele team. Klinkt eenvoudig, toch? Maar wat als dit simpele proces volledig in de soep loopt? In deze anekdote laten we zien hoe je zelfs de meest dagelijkse taken kunt optimaliseren met slimme modellen. Benieuwd hoe modellen in IT-ontwikkeling niet alleen je koffieprocessen, maar ook je projecten een impuls kunnen geven? Lees het in dit blog!
Een nieuwe opdracht
Ik zit in het midden van de ons allen welbekende kantoortuin. Vandaag is mijn klus bij een nieuwe klant gestart. Om mij heen hoor ik het getik van toetsenborden, het geschuif van computermuizen en zacht overleg op de achtergrond. “De nieuweling haalt om 10 uur de koffie!” Ik kijk naar rechts en zie Linda, één van mijn nieuwe collega’s, glimlachend naar me kijken. “Die had ik even gemist in de inwerkdocumentatie, maar dat klinkt als een traditie waar ik graag aan mee doe”, zeg ik met een knipoog, vastbesloten om meteen een onuitwisbare indruk te maken.
Na alle koffiewensen opgehaald te hebben bij mijn collega’s loop ik naar de automaat. Tijdens mijn wandeling verwonder ik mij. Organisaties leggen soms tot in de puntjes de meest uitzonderlijke processen vast, maar dit bedrijfskritische proces – het halen van koffie – is naar mijn weten (bijna) nergens te vinden.
Even later vervolgt iedereen met een vers kopje koffie voor de neus het werk. Hoor ik nu echt het tikken van de toetsen 3% sneller gaan?
Ik zeg wel iedereen, maar Annemiek niet. Die was ik vergeten. En Daan en Layla heb ik het verkeerde drankje gegeven. Ik heb ook geen suiker meegenomen voor Yassin. Bij Steven goot ik per ongeluk wat koffie over zijn spierwitte overhemd. Ook moest ik drie keer lopen omdat het te veel was om in één keer te tillen. Het duurde tamelijk lang allemaal. Terug op mijn plek neem ik mij voor om dit proces grondig te verbeteren. Ik heb een onuitwisbare eerste indruk gemaakt, maar niet op een goede manier.
Het project en haar doelen
Om 11:30 uur is het volgende vaste gezamenlijke koffiemoment. Ik besluit om dit moment aan te grijpen om mijn wanprestatie van kort daarvoor te evalueren. Iedereen is het erover eens dat het beter moet. Mijn stakeholders hebben de neuzen dezelfde kant op; dat begint goed.
Bij het uitvragen van welke doelen ze willen bereiken bij het verbeteren van het halen van koffie, pak ik een flip-over erbij. Er worden mooie doelen genoemd. Ik vraag welke doelen het belangrijkst zijn en welke doelen achterwege gelaten kunnen worden, mocht er geen tijd meer zijn. “Alles is essentieel en moet direct gebeuren”, luidt het antwoord. Ik heb hier duidelijk te maken met een groep door de wol geverfde stakeholders.
Even later staat onderstaande doelendecompositie op papier. Het is een EN-decompositie geworden. We gaan het hoofddoel bereiken door alle drie de subdoelen te verbeteren. Een OF-decompositie teken je namelijk met rechte lijnen van hoofd- naar subdoelen. In één oogopslag schept onderstaande model dus duidelijkheid.
Bij modellen noemen we het gebruik van de elementen zoals blokken en lijnen de syntax en semantiek. De syntax is de structuur, bijvoorbeeld de gehoekte lijn. en de semantiek is de betekenis: het is een EN-relatie. In andere modellen kan syntax weer een andere semantiek hebben.
Modellen hebben een belangrijk voordeel ten opzichte van tekst: afbeeldingen zijn vaak makkelijker te begrijpen en onthouden. De ruimtelijke weergave helpt mensen zich een voorstelling te maken en daardoor makkelijker een mening te vormen over de inhoud. Dit is erg nuttig wanneer je met elkaar processen wil verbeteren. Vaak wordt een model dan ook een ‘praatplaat’ genoemd, doordat het gesprek op gang gebracht wordt.
Een ander groot voordeel van modellen is dat deze goed te begrijpen zijn door de focus op één perspectief. Goede IT-modellen gaat bijvoorbeeld óf over de doelen van een systeem, óf over het proces dat gebruikmaakt van een systeem, óf om de datastructuur binnen het systeem.
Een model reduceert daardoor informatie: je richt je ergens op en laat de andere informatie daarom niet zien. Denk bijvoorbeeld aan een atlas: je hebt kaarten waarbij alleen de grondsoorten worden weergegeven en rivieren niet. De scope van de kaart ligt dan bij de grondsoorten. Om een volledige weergave van het systeem en haar omliggende processen te krijgen zal je dus in de regel meerdere typen modellering moeten toepassen.
Geïnspireerd door de tekening op papier hebben mijn collega’s inmiddels de smaak te pakken. Er wordt unaniem besloten om dit serieus aan te vliegen: er wordt een projectgroep opgericht.
De as-is en de to-be
Om verder inzicht te krijgen in wat wij willen verbeteren stel ik aan het projectteam voor om een Business Process Model and Notation (BPMN) plaat te maken van het proces zoals die nu is (de as-is situatie). Deze kunnen wij als uitgangspunt gebruiken om te analyseren waar de kansen voor verbetering liggen.
BPMN is een gestandaardiseerde methode voor het modelleren van bedrijfsprocessen. Met een BPMN-diagram kun je de volgorde van activiteiten, beslissingspunten, parallelle processen, datastromen en interacties tussen verschillende partijen in kaart brengen. Zo’n diagram kan helpen om een duidelijk overzicht te krijgen van hoe een proces verloopt, inefficiënties of knelpunten te identificeren en communicatie te verbeteren tussen teamleden en afdelingen.
In het eerstvolgende projectoverleg leg ik het onderstaande BPMN-diagram voor. Ik nodig iedereen uit om hier kritisch naar te kijken. Wat roept vragen op? Kan iets anders? Wat hebben we daarvoor nodig?
De volgende knelpunten in het as-is proces blijken van belang:
- De bestelde drankjes moeten worden onthouden door de nieuweling. In de plaat staat niet dat er gebruik wordt gemaakt van een gegevensdrager. Er is al gebleken dat een mens niet betrouwbaar informatie op kan slaan. Er zit nota bene een lange looproute tussen, waarbij een mens geheid de helft vergeet.
- Er zijn eigenlijk altijd meer drankjes dan dat de nieuweling in zijn of haar handen kan houden. De nieuweling moet dus altijd meerdere keren lopen. Weer niet handig met de lange looproute van koffieautomaat naar kantoortuin.
- De nieuweling weet op basis van dit proces helemaal niet hoe laat van hem of haar verwacht wordt om koffie te halen.
Om deze knelpunten op te lossen doen we een brainstorm. Het resulteert in een aantal goede oplossingen die we besluiten op te nemen in een verbeterde versie van het BPMN-diagram (de to-be):
- We voegen een actie, een systeem en een tijd-event in een swimming lane1 toe: Collega’s (swimming lane) schrijven (actie) op werkdagen vóór 10 uur in de ochtend (tijd-event) hun gewenste bestelling in Microsoft Teams (systeem).
- We voegen een dienblad toe ((gegevens)drager), waardoor de nieuweling nooit meerdere keren hoeft te lopen. Hierdoor verdwijnt de actie om meerdere keren te lopen uit het diagram.
- We voegen nog een tijd-event toe: de nieuweling haalt iedere werkdag om 10 uur in de ochtend de drankjes.
1 Swimming lane: een visueel element dat wordt gebruikt om verantwoordelijkheden te scheiden binnen een procesdiagram. Swimming lanes zijn horizontale of verticale secties binnen een diagram die verschillende actoren, rollen, afdelingen of systemen vertegenwoordigen.
De stuurgroep van dit zeer ambitieuze project toetst onze verbeterpunten aan de gestelde doelen. De conclusie is dat deze inderdaad direct gaan bijdragen aan nauwkeurigheid, consistentie en communicatie die we eerder in onze doelendecompositie hebben opgenomen. We mogen door!
De inkoopafdeling wil uiteraard graag eerst een businesscase zien voordat ze overgaan tot aanschaf van het dienblad. Ook daar gaat de projectgroep mee aan de slag. Uiteindelijk blijkt: het is een positieve businesscase. Een dienblad kost € 4,99 en gaat 5 jaar mee. In 5 jaar levert gebruik van een dienblad naar schatting € 1733 aan productiviteit op2. Daan rekende uit dat het verschil hiertussen positief is. Inkoop vond het positieve verschil groot genoeg om het risico te aanvaarden: het dienblad werd aangekocht.
2 Berekening productiviteitswinst: 2 x 2 minuten x 5 werkdagen x 52 werkweken x 5 jaar / 60 minuten x €20 euro per uur = €1733,33
Extra perspectieven = extra inzicht = extra verbeteringen
Maar er zijn meer problemen om op te lossen die niet in ons BPMN-diagram naar voren zijn gekomen. Ten eerste, het halen van de drankjes duurt nog steeds erg lang. Met name de tijd die de nieuweling bij de koffieautomaat door moet brengen is uitzonderlijk. Nota bene, de eerste drankjes zijn alweer koud als het laatste drankje klaar is. Ten tweede, eenmaal met een tjokvol dienblad terug in de kantoortuin weet de nieuweling niet welk drankje van wie was.
We hebben dus meer perspectieven, en dus andere typen modellen nodig.
Werkgroep 1
Een aantal collega’s gaat in een werkgroep met het eerste probleem aan de slag. Ze vragen bij de leverancier de documentatie van de koffieautomaat op om te analyseren of het maken van drankjes sneller kan. Verrukt komt de werkgroep bij mij terug: de leverancier heeft een aantal Unified Modeling Language (UML) modellen van het systeem opgestuurd.
Waarom is dit zo mooi? Voor sommige modellen zijn wereldwijd afspraken gemaakt over het gebruik van de syntax en semantiek. Deze modellen worden getypeerd als Unified Modeling Language (UML): een gestandaardiseerde manier om softwareontwerpen te visualiseren, specificeren en documenteren die daardoor universeel begrepen wordt. Dit is bijzonder handig bij communicatie tussen verschillende organisaties, zoals in onze anekdote met de leverancier van de koffieautomaat.
Het is niet altijd vanzelfsprekend of je voor jouw situatie het beste een UML of een niet-UML model kunt gebruiken. UML helpt bij het inzichtelijk maken van complexe systemen, maar kan ook rigide zijn. Kiezen voor een niet-UML model biedt meer flexibiliteit en kan eenvoudiger zijn voor snel veranderende projecten, hoewel de communicatie minder gestandaardiseerd is en dit tot misverstanden kan leiden.
Gebruik UML voor duidelijke, gestandaardiseerde communicatie en goede documentatie, vooral in complexe projecten. Kies voor niet-UML modellen als flexibiliteit en snelle aanpassingen belangrijker zijn. Beide opties hebben hun plaats, afhankelijk van de projectbehoeften en teamervaring.
In de praktijk zien we regelmatig dat syntax en semantiek door de tekenaar worden aangepast en bij-bedacht gaandeweg het tekenen van een model voor een bepaald doeleinde. Dit lijkt voor de tekenaar van het model vaak een goed idee. Toch is het zo dat dit het gezamenlijke begrip van een model kan vertroebelen. Een organisatie krijgt zo een veelvoud aan varianten van hetzelfde type model die de rondte gaan, waarbij de lezers van het model iedere keer opnieuw eerst de syntax en semantiek moeten snappen. Dit gaat mis wanneer dezelfde syntax een andere semantiek krijgt, of wanneer er nieuwe syntax ontstaat voor bestaande semantiek.
Mag je dan nooit aanpassingen doen? Zeker wel. Kunnen aanpassen naar wat de situatie vraagt is een belangrijke kwaliteit. Wij willen vooral benadrukken om doordacht gebruik te maken van wijzigingen en bewust te zijn van de mogelijke impact. Kijk ook of jouw aanpassingen aansluiten bij het gebruik van hetzelfde type model in jouw organisatie. Consistentie binnen één organisatie is cruciaal. Wanneer je gebruik maakt van een model dat als UML te boek staat, raden wij eigen aanpassingen in de regel wel af.
De leverancier heeft twee modellen opgestuurd: een UML state-transition model en een UML Use Case Diagram.
Een UML state-transition model toont de verschillende toestanden van een systeem en de overgangen tussen die toestanden. De gebeurtenis die leidt tot een overgang van de ene naar de andere toestand schrijf je in het model bij de pijl tussen de twee toestanden.
Het model helpt bij het identificeren van mogelijke problemen en verbeterpunten en biedt gedetailleerde documentatie van het systeemgedrag voor toekomstige referentie. UML state-transition modellen worden in softwareontwikkeling vaak gebruikt voor het modelleren van overgangen tussen gebruikersinterfaces en embedded systems, maar kunnen ook bij veel andere toepassingen worden gebruikt.
Yassin is de eerste die een interessante mogelijkheid spot in het UML State-transition model (eerste afbeelding). Er blijkt namelijk dat wanneer het koffieapparaat in de ‘produceer koffie’-toestand is, er een ‘overige’ drank gekozen kan worden die dan geproduceerd wordt. Yassin vermoedt dat het apparaat dus meerdere soorten dranken tegelijk kan maken. Dat zou tijdwinst kunnen opleveren!
Annemiek keek ondertussen naar het UML Use Case Diagram (tweede afbeelding) en zij bevestigt wat Yassin concludeerde. Het Use Case Diagram laat vanuit een ander perspectief zien dat medewerkers direct toegang hebben tot de use-cases voor het maken van koffie, heet en koud water en het opschuimen van melk. Maar nog belangrijker: het maken van heet en koud water en het opschuimen van melk staan ook als een <<extend>> van het maken van koffie in het model. Dit betekent dat deze overige drankjes dus ook kunnen worden gemaakt wanneer iemand koffie aan het maken is. Door het juiste gebruik van UML-syntax en semantiek hebben we het model direct goed kunnen interpreteren.
Op basis van bovenstaande ontdekking stelt de werkgroep aan de projectgroep voor om vanaf nu zo veel mogelijk drankjes tegelijk te maken. Zo wordt veel tijd bespaard en koelen drankjes in de tussentijd minder af.
Werkgroep 2
De tweede werkgroep is ondertussen bezig geweest om een oplossing te bedenken voor het eerdergenoemde tweede probleem: dat eenmaal terug in de kantoortuin niet duidelijk is welk drankje van wie is. In een poging om met een nieuw perspectief nieuwe oplossingsrichtingen aan te boren heeft de werkgroep besloten een entiteit-relatiediagram te tekenen.
Een entiteit-relatiediagram (ERD) is een visueel hulpmiddel dat de relaties tussen verschillende gegevensentiteiten binnen een systeem, database of gegevensdrager weergeeft. Een ERD maakt het eenvoudiger om de gegevensvereisten te begrijpen en te communiceren, wat bijdraagt aan een efficiënter ontwerp en ontwikkeling van de database.
Entiteit-relatiediagrammen worden gebruikt tijdens de ontwerpfase van een database om de structuur en integriteit van de gegevens te waarborgen, om databasestructuren te documenteren en om dataprestaties te optimaliseren door inzicht te geven in de relaties tussen verschillende gegevensentiteiten.
Anja oppert: “We zouden het dienblad als een gegevensentiteit kunnen zien en onszelf als attribuut” (Anja zei dit niet echt, maar het zou wel briljant van haar zijn geweest als ze dat wel had gedaan). Enfin, we beginnen het model te tekenen. Doordat we het dienblad nu bekijken als een gegevensentiteit ligt het voor de hand om na te denken welke attributen (kenmerken) de gegevens hebben.
De oplossing die hieruit volgt, is dat we naast de koffieautomaat een bakje met naamkaartjes zetten. Ieder kaartje bevat de naam van een collega en voor iedere collega zijn er meerdere kaartjes (voor als iemand meerdere drankjes wil). Zodra een drankje klaar is zet de nieuweling het drankje op een positie op het dienblad en legt hier een naamkaartje bij. Nu vergeten we niet meer welk drankje van wie was.
Een dag later besluit ik het verbeterde koffieproces uit te proberen. Met een dienblad vol drankjes loop ik terug naar de kantoortuin, waar mijn collega’s vol verwachting zitten te wachten. Even voel ik de spanning, maar dan volgt het verlossende oordeel: alles is vlekkeloos verlopen — mijn eerste indruk is rechtgezet.
3 Functioneel requirement: Een requirement die betrekking heeft op een resultaat of gedrag dat door een functie van een systeem wordt bewerkstelligd. Kwaliteitsrequirement: Een requirement die betrekking heeft op een kwaliteitseigenschap die niet door de functionele requirements afgedekt wordt. Bijvoorbeeld: beveiliging, performance, beheerbaarheid, enzovoorts. Beperkingen: Een requirement dat de oplossingsruimte beperkt in aanvulling op de functionele en kwaliteitsrequirements.
Ben jij nieuwsgierig geworden hoe het inzetten van modellen jouw organisatie verder vooruit kan helpen? Voor een bakje koffie komen wij graag langs om met jullie mee te denken.
