Het verschil zit in ons vertrekpunt. Wij grijpen niet meteen naar technologie. Sterker nog: we stellen het code schrijven even uit. Niet omdat we geen zin in hebben om er meteen in te vliegen, maar omdat technologie pas waardevol wordt als je ze gebruikt om het juiste probleem op te lossen.
Daarom starten we altijd met begrijpen hoe jouw organisatie écht werkt. Niet hoe het proces officieel beschreven staat, maar wat er gebeurt op de vloer wanneer er uitzonderingen zijn, wanneer er drukte is, wanneer mensen moeten improviseren, wanneer er fouten optreden en wanneer een workflow eigenlijk al jaren knarst. Dat soort inzichten vind je zelden in managementslides. Je ontdekt ze pas wanneer je met de mensen praat die het échte werk doen. En dat is exact waar wij van start gaan.
Process Driven Design: eerst de werkelijkheid, dan pas de software
Wij noemen die aanpak Process Driven Design. In mensentaal: we duiken diep in jouw bedrijfsprocessen voor we één regel code schrijven. We willen weten welke processen écht draaien in je organisatie:
- Wat zijn de toptaken die dagelijks terugkomen?
- Wie doet wat, wie beslist wanneer en waarom?
- Welke termen gebruiken jullie intern en waar ontstaan misverstanden omdat teams verschillende woorden gebruiken voor hetzelfde?
- En vooral: waar zitten de uitzonderingen die in werkelijkheid een groot deel van de tijd opslokken?
Dat klinkt intens, maar het doel is eenvoudig: we willen niet zomaar digitaliseren, we willen verbeteren. Als je te snel bouwt, is de kans groot dat je een digitale kopie maakt van een gedateerde flow, met dezelfde frustraties… maar dan in een nieuw jasje. Liever niet dus.
Door het proces eerst zichtbaar en bespreekbaar te maken, kunnen we samen bepalen wat écht beter kan: wat moet eenvoudiger, wat moet geautomatiseerd worden, waar moet je uitzonderingen slim opvangen en waar levert maatwerk waarde op.
Dat is ook hoe we het doen in onze projecten. Bij Epsilon Cities, bijvoorbeeld, startten we met een functionele analyse waarbij de volledige procesflow in kaart werd gebracht. Die flowchart werd letterlijk de ruggengraat van het platform: pas daarna bouwden we de applicatie waarin gemeenten eenvoudig bestellingen kunnen plaatsen, documenten uploaden en elke stap digitaal opvolgen.
Een vergelijkbaar patroon zie je bij de Democo-case: daar werd de oplossing afgetoetst op de vloer met arbeiders en werfleiders. Door die gesprekken zagen we hoe belangrijk het was om de app bewust “clean” te houden, met zo weinig mogelijk stappen. Ook dat is Process Driven Design: zoeken naar een tool die past bij hoe mensen werken.
Waarom wij hier 100% achterstaan
Deze manier van werken maakt het verschil tussen software die “werkt” en software die écht gebruikt wordt. Process Driven Design zorgt ervoor dat je oplossing niet alleen klopt in theorie, maar ook in het dagelijkse leven van je organisatie. Het zorgt dat je team sneller mee is, dat fouten dalen, dat je minder afhankelijk wordt van individuele kennis (“die ene collega die het systeem begrijpt”) en dat processen schaalbaar worden.
Bovendien helpt het je om niet in symptomen te blijven hangen. Soms komt een klant binnen met een vraag als “we hebben een app nodig” of “we moeten een portaal bouwen”, maar wanneer je doorvraagt blijkt het echte probleem elders te zitten: in foutgevoelige overdrachten, in dubbele input, in uitzonderingen die nergens gedocumenteerd zijn of in een proces dat ooit logisch was maar nu gewoon verouderd is. Als je dat niet ziet, bouw je sneller… maar je bouwt verkeerd. Als je het wél ziet, bouw je misschien minder, maar je bouwt wel het juiste. En dat is uiteindelijk goedkoper, duurzamer én aangenamer voor iedereen.
Elke sector is anders (is dat echt zo?)
Een sterke aanpak is één ding. Ervaring met verschillende sectoren maakt dat je sneller vooruitgaat, omdat je typische processen, valkuilen en integraties al herkent nog vóór ze op tafel komen. Bij Wisemen hebben we doorheen de jaren een brede laag aan sectoren bediend - van productie en logistiek tot dienstverlening, energie en afvalverwerking - waardoor we snel kunnen meedenken, ook wanneer jouw context net wat anders is.
Maar minstens even belangrijk is dit: de meeste operationele problemen zijn verrassend universeel. Of je nu in een kmo werkt of een grotere organisatie, of je nu werkt met machines, mensen of diensten: veel frustraties hebben dezelfde kern. Overdrachten die telkens mislopen. Uitzonderingen die nooit gedocumenteerd zijn maar wél dagelijks voorkomen. Data die onderweg vervuilt. Dubbel werk omdat systemen niet met elkaar praten. Of processen die ooit logisch waren, maar door groei en “tijdelijke” workarounds intussen volledig zijn dichtgeslibd. Dat soort patronen zijn sectoroverstijgend en herkennen we snel. Meer nog: we maken ze zichtbaar en we bouwen oplossingen die ze structureel aanpakken.
En dan is er nog het bedrijfsspecifieke stuk: de nuances die jouw organisatie uniek maken. Die leren we niet door de bestelbon te ondertekenen, ons zes maanden terug te trekken om te coderen en dan een platform op te leveren dat “in theorie” klopt. Wij werken net heel dichtbij. We praten met de mensen die het echte werk doen, testen onderweg, sturen bij en bouwen samen. Zo ontstaat er geen software van buitenaf, maar een oplossing die past bij hoe jullie organisatie écht draait en die teams ook effectief willen gebruiken.
Het resultaat: minder misverstanden, sneller vooruit
Als je software bouwt op basis van echte processen, verdwijnen typische frustraties bijna automatisch: eindeloze uitleg, misverstanden tussen teams, data die niet klopt, of workflows die vooral het systeem tevreden houden, maar niet de mensen. Je krijgt een oplossing die meewerkt met je organisatie, niet tegenwerkt.
Wil je weten hoe dat er bij jouw organisatie zou uitzien? Let's talk. We starten met een gesprek over jouw processen. Want daar begint echte vooruitgang.
* Zoals de Tōhoku tsunami in 2011.
