Wat zijn de voordelen van werken met een regionaal softwarebedrijf?
Regionaal softwarebedrijf kiezen? Ontdek waarom korte lijnen en maatwerk écht het verschil maken.
Lees verder
Bedrijfsprocessen in kaart brengen vóór je software laat bouwen doe je door met de mensen die het werk doen stap voor stap te doorlopen wat er nu gebeurt, waar informatie vandaan komt, waar het naartoe gaat en wat er misgaat. Dat hoeft geen formeel project te zijn, maar het vraagt wel om gerichte gesprekken en een concrete beschrijving van de werkelijkheid, niet de ideale situatie.
Voor MKB-bedrijven die software op maat laten maken is dit de voorbereiding die het verschil maakt tussen een applicatie die écht werkt en een die na oplevering alweer om de werkelijkheid heen wordt gewerkt. In dit artikel beantwoorden we de meest gestelde vragen over hoe je die voorbereiding aanpakt.
Welke processen moet je documenteren vóór je software laat bouwen?
Documenteer de processen die direct raken aan het probleem dat je wilt oplossen: de stappen waarbij informatie wordt ingevoerd, doorgegeven of omgezet in een beslissing of actie. Denk aan orderverwerking, planningslogica, klantcommunicatie of voorraadbeheer. Begin niet met alles, maar met de kern van wat dagelijks misgaat of te veel tijd kost.
In de praktijk werken veel MKB-bedrijven met een combinatie van losse systemen, Excel-bestanden en mondelinge afspraken die ooit zijn ontstaan en nooit zijn vervangen. Niet elk van die systemen of afspraken hoeft gedocumenteerd te worden vóór de bouw begint. Prioriteer de processen die:
- Meerdere mensen of afdelingen raken
- Regelmatig leiden tot fouten of dubbele invoer
- Afhankelijk zijn van kennis die alleen in iemands hoofd zit
- Meegroeien met het bedrijf en daardoor steeds meer tijd vragen
Processen die volledig buiten de nieuwe software vallen, kun je later documenteren. Wat je nu nodig hebt is een helder beeld van de kern, zodat de software op de juiste plek kan beginnen.
Hoe breng je een bedrijfsproces stap voor stap in kaart?
Een bedrijfsproces breng je in kaart door te beginnen bij de trigger, de actie die het proces in gang zet, en dan stap voor stap te volgen wat er daarna gebeurt tot het resultaat bereikt is. Doe dit samen met de mensen die het proces dagelijks uitvoeren, niet alleen met de manager die denkt te weten hoe het gaat.
Een werkbare aanpak in vier stappen:
- Benoem de trigger: Wat zet het proces in gang? Een binnenkomende order, een klantverzoek, een melding uit een ander systeem?
- Beschrijf elke stap: Wat doet wie, met welke informatie, in welk systeem of op welk formulier?
- Markeer de uitzonderingen: Wat gebeurt er als iets niet klopt, ontbreekt of afwijkt van de standaard?
- Noteer wat er misgaat: Waar wordt informatie opnieuw ingevoerd? Waar wacht iemand op iemand anders? Waar gaat kennis verloren?
Je hoeft hier geen duur procesmodelleringsprogramma voor te gebruiken. Een whiteboard, een vel papier of een eenvoudig schema in een tekstdocument is voldoende. Het gaat om de inhoud, niet om de vorm. Het doel is dat iemand die het proces niet kent, na het lezen begrijpt wat er gebeurt en waarom. Als je op dit punt wilt weten welke web applicaties een softwarepartner op basis van zo’n beschrijving kan bouwen, is dat een goed moment om dat te verkennen.
Wat is het verschil tussen een procesanalyse en een functioneel ontwerp?
Een procesanalyse beschrijft hoe het bedrijf nu werkt, inclusief de knelpunten en workarounds. Een functioneel ontwerp beschrijft wat de software moet doen om die processen te ondersteunen of te verbeteren. De procesanalyse gaat over de werkelijkheid van vandaag; het functioneel ontwerp gaat over de gewenste situatie van morgen.
Veel bedrijven slaan de procesanalyse over en gaan direct naar het functioneel ontwerp. Dat is een veelgemaakte fout. Als je niet weet hoe het nu werkt, inclusief alle uitzonderingen en informele afspraken, dan bouw je software die past bij een ideaalplaatje dat niemand herkent.
De procesanalyse is de input voor het functioneel ontwerp. Een goede softwarepartner gebruikt de procesanalyse om samen met jou te bepalen wat de software precies moet doen, in welke volgorde, en voor wie. Bij de aanpak van WEAP begint elk traject dan ook bij het probleem en de bestaande werkwijze, niet bij de technologie.
Welke fouten maken bedrijven bij het beschrijven van hun processen?
De meest voorkomende fout is dat bedrijven beschrijven hoe het proces zou moeten werken in plaats van hoe het werkelijk werkt. Andere veelgemaakte fouten zijn: alleen de directie betrekken en niet de uitvoerders, uitzonderingen weglaten omdat ze “zelden voorkomen”, en processen beschrijven op zo’n hoog niveau dat er geen bruikbare informatie overblijft.
Concrete fouten die softwareprojecten vertragen of doen mislukken:
- De ideale situatie beschrijven: Op papier klopt alles, maar in de praktijk werkt niemand zo. De software wordt dan gebouwd voor een werkelijkheid die niet bestaat.
- Uitzonderingen negeren: Juist de uitzonderingen bepalen hoe complex de software moet worden. Vijf procent afwijkende gevallen kan vijftig procent van de bouwkosten bepalen.
- Geen uitvoerders betrekken: De directeur weet wat het resultaat moet zijn, maar de medewerker op de werkvloer weet hoe het écht gaat. Beide perspectieven zijn nodig.
- Te veel tegelijk willen: Bedrijven schrijven een waslijst aan wensen op. Daardoor wordt onduidelijk wat echt noodzakelijk is en wat later kan.
Hoe weet je wanneer je processen goed genoeg zijn gedocumenteerd?
Je processen zijn goed genoeg gedocumenteerd wanneer iemand die het bedrijf niet kent, op basis van de beschrijving kan begrijpen wat er wanneer gebeurt, wie wat doet en wat er misgaat. Als je de beschrijving aan een nieuwe medewerker zou geven en die ermee aan de slag kan, dan is het voldoende.
Een praktische toets: laat iemand buiten het proces de beschrijving lezen en vraag hem of haar om de stappen in eigen woorden terug te vertellen. Waar die persoon vastloopt of vragen stelt, ontbreekt informatie. Je hoeft niet te streven naar perfectie. Documentatie die goed genoeg is om een gesprek te voeren met de mensen die de software gaan bouwen, is al een stuk verder dan de meeste bedrijven komen.
Onthoud ook: de documentatie is een startpunt, geen eindpunt. Tijdens het bouwproces komen altijd nieuwe inzichten naar boven. Een goede softwarepartner stelt de juiste vragen om die inzichten boven tafel te krijgen. Neem contact op als je wilt sparren over hoe ver je documentatie moet gaan voordat je een eerste gesprek kunt voeren.
Wie moet er betrokken zijn bij het in kaart brengen van processen?
Bij het in kaart brengen van processen moeten minimaal twee groepen betrokken zijn: de mensen die het werk dagelijks uitvoeren en de persoon die verantwoordelijk is voor het resultaat. De uitvoerders kennen de details en de uitzonderingen; de verantwoordelijke kent de doelen en de prioriteiten. Zonder beide perspectieven mist de beschrijving altijd iets wezenlijks.
In de praktijk betekent dit voor een MKB-bedrijf:
- De directeur of operationeel manager: Bepaalt wat het probleem is en wat het doel van de software is.
- De medewerkers die het proces uitvoeren: Beschrijven wat er werkelijk gebeurt, inclusief de handigheidjes en workarounds die nergens zijn opgeschreven.
- Eventueel een sleutelpersoon per afdeling: Als het proces meerdere afdelingen raakt, is het nuttig om per afdeling iemand te betrekken die het overzicht heeft.
De softwarepartner die je kiest speelt hier ook een rol. Bij WEAP praat je direct met de developers die de software bouwen. Zij stellen de vraag achter de vraag en helpen je om processen te beschrijven die je zelf als vanzelfsprekend beschouwt, maar die voor een buitenstaander volstrekt onduidelijk zijn. Dat directe contact voorkomt het stille-posteffect dat bij grotere bureaus met accountmanagers als tussenschakel zo vaak tot misverstanden leidt. Of het nu gaat om een mobiele applicatie voor je buitendienst of een webplatform voor interne processen, een heldere procesbeschrijving is in beide gevallen de basis voor een geslaagd traject.
