Bewijs vóór belofte

Een werkende demo is nog geen klantresultaat.

Frits maakt onderscheid tussen een synthetisch voorbeeld, een technische smoke-test, een pilotacceptatie en bewijs uit echt gebruik. Zo weet je precies wat al aangetoond is en wat nog moet worden gevalideerd.

Laag 1

Synthetische demonstratie

Een fictief dossier toont interactie, datastroom en controlegrens. Het bewijst geen koppeling, snelheid, besparing of klantresultaat.

Open WB-1048 →
Laag 2

Technische validatie

Een live read-test bewijst tenant, bron en datavorm. Een aparte gecontroleerde test is nodig voor foutpad, toestemming, schrijfgrens en herstel.

Laag 3

Pilotacceptatie

De afgesproken procesvariant wordt met echte bronnen beoordeeld op volledigheid, uitzonderingen, menselijk akkoord en stopconditie.

Laag 4

Praktijkbewijs

Pas gebruik in een echt kantoor kan onderbouwde uitspraken geven over doorlooptijd, herstelwerk en operationele waarde. Zulke claims publiceren we alleen met verifieerbare bron en toestemming.

Wat we vóór go/no-go vastleggen

Geen groen vinkje zonder grens.

Acceptatiecheck

Welke invoer wordt herkend, welke output wordt verwacht en hoeveel uitzonderingen mogen nog menselijk herstel vragen?

Veiligheidscheck

Welke actie is alleen lezen, welke bereidt Frits voor en welke mag pas na expliciet akkoord worden uitgevoerd?

Herstelcheck

Wat gebeurt er bij een verkeerde bron, ontbrekende context, time-out of onverwachte wijziging in een gekoppeld systeem?

Eigenaarschap

Wie beheert de procesregels, wie beoordeelt uitzonderingen en wie mag de workflow stoppen of uitbreiden?

Praktijk

Hoe we aantonen dat een workflow werkt.

Bewijs begint bij een test die je vooraf hebt beschreven. Deze pagina laat zien wat we vastleggen, hoe we meten en welke uitspraken we wel en niet doen op basis van een pilot.

01

Testcase staat vooraf op papier

Voordat er iets draait, beschrijven we per testcase de invoer, de verwachte uitkomst en de grens waarbij een medewerker moet ingrijpen. Zo is achteraf niet te discussiëren over wat er bewezen is. Een testcase die pas na de uitvoering wordt opgeschreven, zegt weinig over de werking.

02

Uitzonderingen tellen mee in de uitkomst

We meten niet alleen de posten die automatisch goed gaan, maar ook hoeveel herstelwerk per honderd posten nodig was. Een proces dat veel vraagt maar zelden fout gaat, kan bruikbaar zijn. Een proces met weinig volume en veel uitzonderingen levert meestal geen winst op.

03

Hetzelfde proces twee keer toetsen

Een uitkomst is pas bruikbaar als dezelfde test met dezelfde invoer opnieuw hetzelfde resultaat geeft. Wijkt de tweede uitvoering af, dan zoeken we de oorzaak voordat we verdergaan. Ook leggen we vast welke versie van de procesregels is gebruikt, zodat een verschil herleidbaar blijft.

04

Resultaten delen zonder overdrijven

Praktijkcijfers publiceren we alleen met een verifieerbare bron en toestemming van het kantoor. Geen klantnamen, geen omzetcijfers en geen tijdsbesparing zonder onderliggende meting. Waar nog geen praktijkbewijs is, benoemen we dat als openstaand punt in plaats van het als resultaat te presenteren.

Veelgestelde vragen

Veelgestelde vragen over bewijs en toetsing.

Vragen die terugkomen wanneer een kantoor wil weten waarop een uitspraak over werking is gebaseerd.

Is een demonstratie genoeg om te beslissen?

Nee. Een demonstratie laat zien hoe een proces bedoeld is en welke grenzen er zijn, maar bewijst geen koppeling, geen volume en geen resultaat bij een echt kantoor. Je kunt er wel een eerste richting aan ontlenen. Besluiten over uitbreiding horen te volgen uit een pilot met echte bronnen en vooraf beschreven acceptatiecriteria.

Wat is een technische validatie precies?

Dat is een gecontroleerde test waarin we met echte bronnen nagaan of de verbinding klopt: juiste administratie, juiste gegevensvorm en de verwachte leesroute. Daarna volgt een aparte test voor foutpad, toestemming, schrijfgrens en herstel. Pas wanneer die stappen herhaalbaar zijn, is er een basis om een pilot met klantwerk te starten.

Wie bepaalt of de pilot geslaagd is?

Het kantoor bepaalt dat, op basis van criteria die vooraf zijn vastgelegd. Wij leveren de meting en de onderbouwing, maar de acceptatie is een besluit van de proceseigenaar en de betrokken medewerkers. Wijken de uitkomsten af van de afspraak, dan zijn de opties stoppen, aanscherpen of een kleinere scope kiezen.

Wat als de pilot niet slaagt?

Dan is dat een uitkomst en geen mislukking. We leggen vast welke stap niet voldeed, of dat aan de bron, de procesregels of de verwachting lag, en wat er nodig zou zijn om het opnieuw te proberen. Een proces dat niet aantoonbaar werkt, breiden we niet uit naar andere administraties of workflows.

Eén proces. Duidelijke grens.

Maak jouw acceptatiecheck concreet.

De Processcan geeft een eerste procesrichting. In het gesprek leggen we bron, uitzondering, menselijke grens en go/no-go vast.