Eerst zien, dan beslissen

Bij software word je gevraagd te beslissen over iets wat je nog nooit hebt gezien, op basis van een demo met andermans gegevens. Dat is een rare afspraak en het verklaart waarom zoveel technische bedrijven dit soort projecten jarenlang uitstellen.

Vraag een eigenaar van een installatiebedrijf waarom hij al drie jaar nadenkt over het vastleggen van kennis en nog niets heeft gedaan en het antwoord gaat zelden over de kosten. Het gaat over het beeld dat hij erbij heeft: een traject van maanden, een implementatiepartner, een projectplan en aan het eind een omgeving die zijn mensen niet gebruiken. Dat beeld is niet onterecht, genoeg bedrijven hebben precies dat meegemaakt.

Wat dat beeld in stand houdt, is de volgorde. Eerst beslissen, dan pas zien. Je krijgt een offerte, een planning en een demo met de gegevens van iemand anders en op basis daarvan moet je een handtekening zetten. Alles wat je te weten wilt komen, kom je pas te weten nadat je hebt betaald.

Draai de volgorde om

Wij bouwen eerst. Op basis van wat er al aan documentatie ligt, plus één kort interview, staat er binnen een week een werkende kennisbank met jullie eigen inhoud erin. Geen mockup, geen presentatie met schermafbeeldingen: iets waar je een vraag in kunt typen en waar een antwoord uit komt dat over jouw bedrijf gaat.

Pas daarna komt de vraag of je verder wilt. En als het antwoord nee is, houd je het prototype.

Als wij niet binnen een week iets kunnen laten zien dat de moeite waard is, ligt dat aan ons. Dan hoort de rekening ook bij ons.

Waarom dit voor ons werkt en niet alleen voor jou

Dit is geen weggeefactie. Er zitten drie redenen achter die net zo goed ons belang dienen en het is eerlijker om die te benoemen dan te doen alsof het pure vrijgevigheid is.

Het filtert. Een bedrijf dat na het zien van zijn eigen kennis in een werkend systeem nog steeds twijfelt, was waarschijnlijk geen goede klant geweest. Beter dat we dat in week één weten dan in maand vier.

Het dwingt ons scherp te zijn. Als je binnen een week iets moet laten zien, kun je niet eerst drie weken vergaderen over de structuur. Je moet meteen naar de vragen die er echt toe doen. Die beperking maakt het resultaat beter, niet slechter.

Het maakt het gesprek concreet. Praten over een kennisbank in het algemeen levert vage instemming op. Praten over een scherm waar het antwoord op een echte vraag van een echte monteur staat, levert opmerkingen op als "dit klopt niet helemaal" en "hier mist nog iets" en dat is precies de input die je nodig hebt.

Wat een prototype níét is

Waar je op moet letten bij zo'n prototype

Niet elk gratis proefproject is een goed teken. Er zijn er genoeg die vooral bedoeld zijn om je in een traject te trekken. Drie dingen die het onderscheid maken en waar je ook bij ons naar mag vragen:

1. Staat er jouw eigen inhoud in? Een demo met verzonnen voorbeelden vertelt je alleen iets over de software, niet over de vraag of het bij jouw bedrijf gaat werken. Dat laatste is de enige vraag die telt.
2. Mag je het houden als je nee zegt? Zo niet, dan is het geen risico-omkering maar een langere demo.
3. Is duidelijk wat er daarna gebeurt? Wat het kost, wat je krijgt en wat je zelf moet doen. Als dat pas na het prototype ter sprake komt, is het prototype het lokkertje en niet het bewijs.

De kleinste eerste stap die er is

Het echte obstakel bij kennisborging is zelden geld en zelden overtuiging. Het is dat de eerste stap te groot lijkt: een project, een traject, iets waar je tijd voor moet vrijmaken die je niet hebt. Zolang die stap groot voelt, blijft hij liggen, jaren, vaak, tot er iemand vertrekt en het opeens urgent is.

Een week en één gesprek is de kleinste eerste stap die we konden bedenken. Klein genoeg om hem gewoon te zetten en groot genoeg om daarna een beslissing te kunnen nemen die ergens op gebaseerd is.