De aanname dat onze kennis volledig is en dat er niet meer te weten valt dan we weten, is vaak een grote hindernis in pakketselecties. In vrijwel elk offerte-verzoek zie ik eisen en wensen die letterlijk de detail-eigenschappen van het vorige systeem beschrijven: ‘het systeem moet widgets hebben’, ‘de message queue van het systeem moet kunnen worden gemanipuleerd’, ‘er moet een OTAP-straat bestaan voor de content’. In veel gevallen begrijpen we de omschrijving van de eis niet eens, laat staan dat we een bevredigende reactie kunnen formuleren.
Het is best logisch natuurlijk: degene die de eisen heeft opgesteld, kent natuurlijk vooral het systeem waar men afscheid van wil nemen. Geheel automatisch (want onvermijdelijk) wordt de aanname gedaan dat het nieuwe systeem ongeveer hetzelfde in elkaar zal zitten en dat de zaken die in de oude situatie normaal waren, ook in de nieuwe situatie normaal zullen zijn. Een andere wetmatigheid werkt hier ook nog flink mee: de menselijke geest heeft meestal aan één voorbeeld genoeg om hele complexe systemen te snappen: ‘Seen one, seen them all.’
De slagingskans van selecties kan heel eenvoudig worden vergroot: beschrijf niet wat het systeem moet doen, maar beschrijf wat u ermee wilt bereiken. Dat doet u als volgt. U bedenkt bij elke beschreven eis, waarom het voor u een eis is. Streep vervolgens de eis door en vervang hem door het waarom. Zo beschrijft u niet de handelingen van de gebruiker, maar het resultaat daarvan. U beschrijft niet de kenmerken van de tool, maar van het doel. U zult verrast zijn dat er systemen zijn die hetzelfde voor u kunnen bereiken, maar dan sneller, goedkoper en handiger. En u zult wellicht ook verrast zijn dat er ineens veel meer systemen door de selectie komen. En vooral: u zult verrast zijn dat er systemen zijn die allerlei dingen voor u kunnen betekenen, waar u nog nooit aan gedacht had.
Reacties
Goed stuk, nu maar hopen dat veel klanten dit ook gaan lezen. De vraag is niet "hoe", maar wat hij bereikt en onder welke voorwaarde.
Ik deel Ron's mening van harte. Specifieke (design) details van een nieuw systeem opnemen in een bestek heeft alleen zin als je er absoluut zeker van bent dat dat de 'best practise' implementatie is van het functionele doel. Tenzij je een echte specialist bent, kun je dat dus beter niet doen. Wat Ron voorstelt, ligt in het verlengde van 'Best Value Procurement'. Dat zou m.i. de standaard moeten zijn bij selectie/inkoop van complexe ICT-oplossingen. Zeker niet zelf het wiel uitvinden met weinig bruikbare detailbestekken.
@Jaap : Ondanks dat er wel wat in reactie zit voel ik een allergie reflex om hoe je het formuleert. Alleen al het woord "Best" van "Best practices". Hoe weet je dat iets het beste gebruik is?
On-topic : Het begin van je opinie vind ik maar matig, het einde erg interessant omdat je dat ook terug ziet in software: Imperative versus declarative.
Tenminste, dat lees ik hieruit:
"Zo beschrijft u niet de handelingen van de gebruiker, maar het resultaat daarvan."
Declaratieve code is meestal behoorlijk omdenken. Volgens mij breekt iedereen zijn nek er in het begin over totdat het begint de dagen.
Imperatief is vertellen tegen de computer wat hij moet doen; de handelingen.
Declaratief is definiëren wat het resultaat is en de onderliggende laag realiseert dit voor je.
Dit werkt in mijn ogen niet alleen goed in software en gewenste software beschrijvingen, maar ook in het aansturen van mensen. Niet vertellen wanneer ze wat moeten doen, maar welke resultaat je wilt en wanneer je dat resultaat nodig hebt. Geheid succesvoller.
Maar vooral de laatste alinea maakt dat ik de opinie sterk vind :-)
Resumerend zegt Ron, 'specificaties bestaan uit het opsommen van wat moderne modegrillen'. What else is new?
Ron,
Even een andere dementie van je verhaal:
Je bent op zoek naar een systeem. Volgens jouw artikel ga je:
- niet de handelingen maar het resultaat beschrijven,
- niet de kenmerken van de auto maar van het doel,
En kortom meer de functionaliteiten dan eigenschappen.
Iemand komt met een bekend merk X (dus duurder in aanschaf) en ik kom met een onbekend merk Y.....(voordeliger in aanschaf)
Maar ze doen exact hetzelfde. Hoe ga je gebaseerd op deze zaken mijn offerte beoordelen?
1- Je weet wat je al hebt, je bestaande merk X heeft zich al 5 jaar bewezen. Maar je weet niet wat je krijgt (het onbekend merk Y)
Durf je dit toch aan te schaffen voor de komende 5 jaar?
2- Je leveranciers in de keten ondersteunen je huidige merk. Wat ga je doen als ze geen support kunnen geven op je nieuwe onbekende merk?
3- Je beheerorganisatie kent het product al dus minder onderhoudskosten dan wanneer je externe mensen door gebrek aan kennis van het nieuwe merk moet inhuren (verborgen kosten),
4- Je krijgt nu ook support bij andere organisaties dan alleen je huisleverancier. Bij het onbekende merk ben je afhankelijk van ene leverancier waar het inhuren van een consultant 135 euro p/u kost.
En....... nog meer andere punten.
Nu ben ik benieuwd, durf je gebaseerd op dezelfde functionaliteit een investering voor de komende 5 jaar doen in een onbekend product?
Durf je in de komende 5 jaar je business en de hieraan gerelateerde zaken op dit product bouwen als je niet zeker bent van de supportorganisatie, kwaliteit van dienstverlening, kosten etc.?
Of ga je kiezen voor de veilige optie.......sturen op eigenschappen van wat je al hebt en dan misschien weer terugkomen in de "productgroep' van je initiële product?
@Reza:
Met de aanpak van Ron rollen er bekende en onbekende merken/producten uit. Eventueel gekoppeld aan werkwijzes waar je wellicht nog nooit aan gedacht had.
Van hieruit kan je keuzes maken. Als angst hierin leidend is kies je voor de bestaande olifanten paadjes.
Als een balans tussen risico's en resultaten (vernieuwing/innovatie?) leidend zijn maak je vrijwel zeker andere keuzes.
Kortom - aspecten die langskomen bij het runnen van een bedrijf (ondernemer zijn).
Waar ik nou benieuwd naar ben is het antwoord op de vraag "wat zou jij kiezen?". Zeker gezien de "andere dementie"... ;-)
@Pascal: al gaat mijn artikel er juist helemaal niet over, ben ik wel met je eens dat de specs in een RFP vaak een opsomming zijn van de laatste modegrillen en hypes. Dus: dank hiervoor, je reactie is op z'n minst inspirerend voor een volgend blogje.
@Reza en @Will: mijn Blog gaat specifiek in op de situatie dat men wel degelijk op zoek is naar iets nieuws. Je hebt gelijk dat aanbestedingen vaak als hinderlijk ervaren worden omdat men eigenlijk best tevreden is met het huidige product, maar het nu eenmaal weer tijd is geworden om aan te besteden. Maar nog steeds is het verstandig om de eisen dan zo te omschrijven dat je ook oplossingen ontdekt die je nog nooit had gezien.
@Jaap de Jonge: Je schrijft "Wat Ron voorstelt, ligt in het verlengde van 'Best Value Procurement". Ik zou bijna zeggen: "betrapt..." want BVP vormde inderdaad de inspiratiebron voor dit stukje. Waarmee ik overigens niet wil zeggen dat ik kritiekloos fan ben van BVP, maar dat ene aspect is erg waardevol.
Deze blog lijkt over ICT te gaan maar is van toepassing op elke klantrelatie in zowat elke markt!
@Will
Ik noem het niet snel "angst" maar wel wijsheid en de balans ( risico`s vs resultaten) was de basis van mijn reactie hierboven.
Het impact van een exotische CRM of ERP is zeer groot voor je bedrijfsvoering....niet alleen financieel maar ook functioneel waardoor je misschien veel klanten kwijt raakt, je klanttevredenheid beschadigt en nog meer ellende.
De uitkomst van de balans tussen risico vs resultaten (lees risico analyse, de 4 punten hierboven) is in dit voorbeeld duidelijk, denk ik.
Als we deze aanpak verder aanhouden dan blijft er weinig over voor Ron en zijn artikel!
Ict is flink en diep verweven in je bedrijfsvoering vandaag de dag. Het vervangen van een al bekend onderdeel/component door een onbekende iets kan de balans tussen resultaat/risico flink verstoren. Voor de duidelijkheid, de uitslag van risicoanalyse is voor mij leidend en als je dat angst noemt vind ik het ook prima :-)
P.s. ik heb een slimme editor die zelf denkt woorden te mogen corrigeren! Als je een andere dimensie aan dementie geeft dan kom je misschien uit bij wat mijn editor dacht correct te zijn :-)
@Ron
Mee eens dat je je aanbesteding anders moet opstellen. Kijkend naar de risicoanalyse (wat ik in die 4 punten probeerde duidelijk te maken) ben ik bang dat er geen ruimte over blijft voor onbekende en exotische dingen.
Opnieuw een boeiende blog van deze auteur waar dit keer wel heel wat opmerkingen over te maken zijn. En niet onverdeeld positief.
Allereerst kan ik mij al niet vinden in de titel: “Je weet niet wat je niet weet”. Ieder normaal mens weet heel goed wat hij niet weet en wat hij niet kan; daarom gaat hij met gezondheidsklachten naar de huisarts; voor autoreparaties naar de garage, etc. Op dat principe is eigenlijk de hele dienstensamenleving gebaseerd.
Je weet wat je weet en je weet niet wat je niet weet is precies wat een mens opsluit in narcistische zelfgenoegzaamheid: ‘Seen one, seen them all’; het absurde idee dat “één voorbeeld genoeg [is] om hele complexe systemen te snappen”. Het maakt zelfkennis onmogelijk (om over ethiek maar helemaal te zwijgen).
Een reden temeer om oude systemen niet te vervangen door nieuwe systemen, maar door bedrijfsapplicaties.
Laat de verrassende laatste alinea hierop nu juist uitzicht bieden!
Natuurlijk kun je de doelen die je nastreeft buiten het systeem houden; ze bevinden zich zelfs principieel buiten het systeem, aangezien doelen binnen een systeem niet zijn terug te vinden. Een koffiezetapparaat stelt zichzelf niet tot doel om koffie te zetten.
Software wordt vele malen flexibeler, intelligenter en eenvoudiger (!) als je de doelen hierin expliciet opneemt en deze “verwerkt” op een wijze die tegengesteld is aan orkestratie: van output naar input.
Bij het toepassen van procestechnologie ga je van input naar output door middel van een stapsgewijze verfijning van processen; bij het toepassen van kennistechnologie ga je van output naar input door middel van een stapsgewijze verfijning van doelen.
@Jack
Aangaande de titel, een slecht geheugen kun je tegenwoordig oplossen met Google. Wat betreft je voorbeeld is 'Je weet niet wat je kan' toepasselijker omdat dienstensamenleving gebaseerd is op een economische afweging tussen zelf doen of uitbesteden.
En daarom poneer ik - geheel vanuit een filosofisch perspectief - de stelling dat de dommen de gelukzalig zijn. Oftewel willen we weten wanneer we dood gaan?
Kortom, je slaat dus weer volledig los door aan een koffiezetapparaat een bewustzijn toe te kennen.