![]() |
Afbeelding via Pixabay |
Na twee jaar gaan we weer mondjesmaat naar kantoor. En daar had zich een
verandering voltrokken die je niet had zien aankomen. Er waren nieuwe toiletrolhouders
geïnstalleerd.
Even voor kantoorloze lezers: zo’n houder is niet het eenvoudige
dingetje dat bij jou en bij mij thuis hangt, maar een gesloten doos met een
gleuf onderaan de voorkant. In de doos zitten twee rollen boven elkaar en het
papier komt door de gleuf naar buiten. Althans, dat is de bedoeling. Maar daar
gaat het bij deze nieuwe dingen nou precies mis. De rollen ondervinden teveel
wrijving. Als je aan het papier trekt, dan scheurt het af – binnen in de
houder. Waardoor je iedere keer opnieuw op zoek moet naar het begin door je
vinger in de houder te steken en de rol moeizaam rond te draaien – vaak
meerdere keren – tot je het uiteinde van het papier te pakken hebt. En dan
voorzichtig trekken, want voor je het weet scheurt het wéér af. Soms heb je
opeens de uiteinden van beide rollen te pakken en ervaar je de luxe van
dubbellaags wc-papier.
Er is een fabrikant die deze dingen maakt. Niet zomaar uit het niets,
maar volgens een ontwerp. Ze maken er eerst eens eentje, of een handjevol: de
prototypes. Die worden getest, er komen een paar kinderziektes aan het licht,
het ontwerp wordt aangepast, er komt een nieuw prototype en uiteindelijk (na
misschien nog een paar iteraties) is de houder rijp voor productie.
Waar ging het bij dit product zo vreselijk mis? Hebben ze alleen onder
laboratoriumomstandigheden getest? Is niemand op het idee gekomen om een
prototype aan de muur te schroeven, er twee rollen wc-papier in te doen, op de
pot te gaan zitten en volgens de een of andere Europese norm dan wel naar
behoefte papier te gebruiken? Kortom, is er geen veldtest gedaan?
Maar ook aan onze kant ging het mis. Het zal wel een rijksbrede aanbesteding
zijn geweest. Daarbij wordt gekeken welke offerte, die aan de vooraf opgestelde
eisen voldoet, de goedkoopste oplossing biedt. Misschien zijn de inkopers
vergeten om als eis op te nemen dat het papier er soepel uit moet komen. En ik
vraag me af hoe de acceptatietest is uitgevoerd.
Jaren geleden hebben we een softwarepakket aangeschaft om ons information security management system
(ISMS) te beheren. Het leek een geweldig product en we gingen met een paar
man op cursus bij de fabrikant. We zagen een product met een heldere structuur
en we konden alle oefenopdrachten soepeltjes uitvoeren. En toen moesten we het
product in onze organisatie implementeren. Het lukte maar niet om onze
inrichting te verenigen met die van het product. Ik heb toen zelfs nog het
datamodel van het product ge-reverse-engineered*, met andere woorden: ik heb
uitgetekend hoe het product in elkaar zat. Vervolgens hebben we geprobeerd om
onze organisatie en onze werkwijze hierop te plotten. We hebben een paar keer
de fabrikant erbij gehaald en na zo’n consult dachten we telkens dat we het
hadden gevonden. Uiteindelijk hebben we het opgegeven en tot op de dag van
vandaag werken we met de oude, vertrouwde spreadsheets.
Daar is overigens niets mis mee. Op een conferentie vroeg een spreker
eens wie er allemaal Excel gebruikte voor dit soort dingen. Talrijke handen
gingen omhoog en daar werd besmuikt bij gelachen. Tegelijkertijd golfde een
gevoel van opluchting door de zaal omdat in één klap duidelijk werd dat het
helemaal niet ongebruikelijk was om zo te werken. Soms heb je nu eenmaal
functionele behoeftes die je niet goed kunt uitdrukken in eisen en wensen en
waar je om die reden geen inkooptraject voor kunt starten. Je gaat dan zelf wat
knutselen of je leent iets wat ze elders hebben gemaakt. Qua beheer is dit overigens
een nachtmerrie: als zo’n zelfgemaakte tool ingeburgerd raakt en de maker ervan
is niet meer beschikbaar, dan heb je een probleem.
Ik heb zelf ook zoiets in elkaar geknutseld. En om mijn collega’s niet
met de handen in het haar te laten zitten als ik onder de tram mocht komen, heb
ik daar een technische handleiding bij gemaakt, die precies beschrijft hoe het
er onder motorkap van mijn spreadsheet aan toe gaat. Of ze daar ook mee uit de
voeten kunnen, moet op het uur U blijken. Want we zijn natuurlijk veel te druk
om zoiets te testen. Bovendien weet niemand waar de handleiding staat. Ruimte
voor verbetering dus. Hoe zit dat eigenlijk bij jou? Is de continuïteit van de
belangrijke hulpmiddelen van jouw team gewaarborgd?
*) Reverse
engineering houdt in dat je kijkt hoe iets werkt en daaruit afleidt hoe het
is ontworpen.
En in de grote boze buitenwereld …
- biedt dit artikel een zeldzaam inkijkje in de onderhandelingen tussen de Mediamarkt en de criminelen die de systemen van de winkelketen gegijzeld hadden.
- heeft ransomware maar weinig tijd nodig om veel bestanden te versleutelen.
- werft hackersbende LAPSUS$ medewerkers van grote bedrijven om hen toegang tot het bedrijfsnetwerk te verschaffen.
- is een tiener mogelijk het brein achter LAPSUS$.
- heeft de Londense politie (een deel van) deze hackersbende opgerold.
- becijfert de FBI de schade door cybercrime op meer dan 6,9 miljard dollar.
- moet je je kinderen (en desnoods jezelf) aansporen om een paar instellingen in TikTok aan te passen.
- roept president Biden Amerikaanse bedrijven op om zich te beschermen tegen Russische cyberaanvallen.
- mogen Britse soldaten WhatsApp niet meer gebruiken, uit vrees voor Russische hackers.
- acht het NCSC het mogelijk dat de Nederlandse digitale weerbaarheid op de proef wordt gesteld naar aanleiding van de oorlog in Oekraïne.
- zijn banken nog vaak coulant als klanten zijn benadeeld door fraude middels phishing, maar er zijn grenzen.
- trapt gelukkig niet iedereen in de trucs van criminelen.
- helpt het Britse NCSC programmeurs met een toolkit om veilig te programmeren.