Welk werk wil je eigenlijk veranderen?

Begin met één terugkerende handeling, zoals een aanvraag verwerken, een werkbon doorgeven of een planning bijwerken. Volg een echt voorbeeld van begin tot eind. Wie doet wat? Waar wordt informatie opnieuw ingevoerd? Wanneer moet iemand navragen of corrigeren?

Schrijf de stappen op zoals ze nu gebeuren. Neem ook de uitzonderingen mee: een incomplete aanvraag, een wijziging na akkoord of een collega die afwezig is. Juist daar wordt zichtbaar waar mensen het systeem met extra handwerk overeind houden.

Hoe bepaal je wat als eerste aandacht verdient?

Kijk naar hoe vaak het werk voorkomt, hoeveel tijd het vraagt en wat er misgaat als informatie ontbreekt. Een eenvoudige telling helpt. Twintig handelingen van vijf minuten zijn samen honderd minuten. Dat is een rekenvoorbeeld, geen beloofde tijdsbesparing: controleer hoeveel daarvan werkelijk kan vervallen.

Kies één knelpunt dat belangrijk genoeg is én duidelijk af te bakenen. Spreek af wie straks moet kunnen beoordelen of de nieuwe werkwijze beter past.

Wanneer is bestaande software logisch?

Als een pakket de belangrijkste taken en uitzonderingen goed aankan, kan dat een passende start zijn. Laat de leverancier jouw echte voorbeeld doorlopen. Een algemene demonstratie zegt minder dan zien of je eigen aanvraag, planning of overdracht ermee werkt.

  • Kunnen de juiste mensen erbij, met passende rechten?
  • Past het bij de systemen die je al gebruikt?
  • Kun je je gegevens meenemen als je later wisselt?
  • Wie helpt bij inrichting, problemen en wijzigingen?

Vergelijk ook wat het van je team vraagt om ermee te werken. Software aanschaffen verandert op zichzelf je dagelijkse werkwijze nog niet.

Wanneer onderzoek je een koppeling of maatwerk?

Een koppeling is het onderzoeken waard als twee bruikbare systemen dezelfde informatie nodig hebben en mensen die nu overtypen. Bepaal eerst welk systeem leidend is en wat er moet gebeuren bij een fout of ontbrekend gegeven.

Maatwerk kan passen als het belangrijkste probleem overblijft of jouw manier van werken een specifieke oplossing vraagt. Begin ook dan met een beperkte eerste versie. Maak duidelijk wat erin hoort, hoe je het laat testen en wie verantwoordelijk is voor het vervolg.

Bij Opera begon de vraag met een werkbonnen-app. Door met Ashley naar zijn installatiebedrijf te kijken, ontstond de richting voor een breder bedrijfssysteem. Het project is in ontwikkeling. Dit voorbeeld laat een ontwerpkeuze zien, geen bewezen besparing.

Wat krijg je voordat je de bouw ingaat?

Vraag om een heldere beschrijving van het probleem, de gebruikers, de eerste versie en de manier waarop je die gaat beoordelen. Een schets of prototype kan helpen om te ontdekken of jullie hetzelfde bedoelen.

Ik help bij BOLD700 de vraag scherp krijgen, ontwerp de gebruikerservaring en begeleid de realisatie met technische partners. We spreken vooraf af wat de eerste stap oplevert en kost. Onderhoud, hosting en verdere ontwikkeling maken we afzonderlijk duidelijk. Zo kun je een besluit nemen zonder meteen je hele bedrijf te laten verbouwen.