Zet vier collega’s rond een tafel en vraag hoe een nieuwe klant bij jullie binnenkomt. Je krijgt vier verschillende antwoorden. Niet omdat iemand het verkeerd doet, maar omdat het proces nergens staat opgeschreven.
Zolang dat zo is, kan je er weinig aan verbeteren. Je kan niets aanpakken dat je niet kan zien.
Wat is journey mapping?
Journey mapping is één proces uittekenen zoals het vandaag loopt, van begin tot eind, op één blad. Niet vanuit je software gezien, maar vanuit de persoon die het werk doet.
Boven de tekening staat het doel van die persoon, in haar eigen woorden: "ik wil een nieuwe klant kunnen opstarten". Daaronder loopt de kaart van links naar rechts in vier rijen. De stappen die ze doorloopt. Wat ze bij elke stap effectief doet. Waar dat gebeurt: welk systeem, welk scherm, welke mailbox. En onderaan waar het stroef loopt.
Meer is het niet. Geen software, geen methode met een certificaat erachter. Een tekening op een muur of een groot blad papier, gemaakt in een paar uur met de mensen die het werk echt doen.
Afbeelding: illustratie van een journey map voor een recruitment bedrijf.
Wat haal je eruit?
Om te beginnen: iedereen ziet voor het eerst hetzelfde. In een KMO doen drie mensen hetzelfde werk elk net iets anders, en dat komt pas boven wanneer het naast elkaar op één blad staat. Dat gesprek alleen al is goud waard.
Daarna wordt zichtbaar waar tijd wordt verloren. Vooral het werk dat buiten je systemen gebeurt — het telefoontje, de mail naar een collega, het Excel-bestand op iemands bureaublad. Dat zijn meestal de grote tijdsvreters. Dat werk ontstaat zelden toevallig: het is bijna altijd de omweg rond een tool die niet past bij hoe mensen echt werken.
Als je die pijnpunten nummert (P1, P2, P3) verandert het gesprek erna volledig. In plaats van "we hebben iets nieuws nodig" krijg je "P3 kost ons twintig minuten per dossier en gebeurt dertig keer per week". Dan kan je bewust kiezen om er iets aan te doen en kan je achteraf uitleggen waarom het geld naar dat stuk ging.
Soms is de conclusie dat je helemaal geen nieuwe software nodig hebt. Dat een bestaande tool volstaat, of dat het probleem niet met software op te lossen valt.
Wat is het verschil met een flowchart?
Een flowchart begint bij het proces zoals het systeem het ziet: welke statussen doorloopt een dossier, welke beslissingen zitten erin, wie moet goedkeuren. Een journey begint bij een mens met een doel.
Dat bepaalt wat je te zien krijgt. Een flowchart toont wat er in je software gebeurt. Een journey toont ook alles daarrond: de omweg, het dubbele werk, het moment waarop iemand toch even belt om te controleren. Precies daar zit meestal het probleem.
Een flowchart is daarom niet slecht, hij beantwoordt gewoon een andere vraag. "Hoe loopt dit proces?" is een flowchartvraag. "Waar loopt het stroef en waarom?" is een journeyvraag. Voor de meeste KMO's is de tweede vraag de nuttigste, omdat het antwoord daarop bepaalt waar je geld naartoe gaat.
Er is nog een praktisch verschil. Omdat een journey in de taal van de gebruiker geschreven staat, blijft hij bruikbaar als je van tool verandert. De stappen om een klant op te starten blijven dezelfde. Alleen de schermen veranderen.
Hoe pak je dit aan in de praktijk?
Probeer niet heel je bedrijf te mappen. "Onze processen in kaart brengen" is te groot en levert een spaghetti op waar niemand nog iets mee doet. "Een nieuwe klant opstarten" of "een factuur klaarzetten" werkt wel. Eén doel, één blad. Heb je er meer nodig, dan teken je een tweede.
Zorg ook dat je de juiste mensen rond tafel zet. Niet enkel de zaakvoerder en de teamleider, maar vooral de persoon die de stappen elke dag onderneemt. Die kent de omwegen.
Bij Tandem is dit altijd de eerste stap. We tekenen eerst uit hoe het vandaag loopt, dan pas hoe het zou moeten lopen, en pas daarna komt er software bij kijken. Die volgorde — eerst het model van hoe je bedrijf werkt, dan de code — is de kern van hoe we bouwen. Wil je weten waar er tijd verloren gaat in jouw bedrijf? Stuur ons een bericht, we denken graag mee.
