Het afgelopen jaar heb ik verschillende discussies meegemaakt die voor een groot deel neerkwamen op “waarom is dit product zo dom? De domheid werd gedefinieerd door het gebrek van het systeem om te anticiperen op acties van gebruikers, het onvermogen om te leren om beter te functioneren in een specifieke context of de totale afhankelijkheid van de gebruiker die activiteiten initieert door het systeem, zelfs als het volkomen duidelijk was wat er gedaan moest worden. Enkele voorbeelden.
Een vertegenwoordiger van een bedrijf dat radars bouwt vertelde het verhaal van een klant die vroeg waarom de radar, eenmaal geplaatst op een specifieke locatie, na 2 minuten, 2 uur, 2 dagen en 2 maanden nog steeds hetzelfde functioneerde. Waarom leerde de radar niet van zijn context en verbeterde hij zijn vermogen om objecten te detecteren door te weten wat de statische elementen in de omgeving zijn en dat te gebruiken om nieuwe objecten beter te onderscheiden?
Een gebruiker van een routeplanningssysteem klaagde over het feit dat hij vaak te laat kwam op vergaderingen omdat hij niet proactief werd gewaarschuwd voor files die er niet waren toen hij de dag ervoor de verwachte reistijd opzocht. Waarom waarschuwt het systeem me niet, klaagde hij, voor een onverwachte file door een ongeluk of zo, zodat ik eerder kan vertrekken?
Een bedrijf dat dure, hightech apparatuur gebruikte, klaagde over het feit dat het systeem zich niet kon aanpassen en hun zeer voorspelbare werkschema niet onder de knie kreeg. De apparatuur had tijd nodig om zich aan te passen tussen verschillende soorten gebruik en ook al draaide het bedrijf dag na dag vrijwel hetzelfde schema, het systeem leerde niet om zelf de herconfiguratie en daaropvolgende aanpassing te starten.
Al deze systemen zijn gebouwd volgens de specificaties die werden opgesteld voordat de ontwikkeling begon. Ze zijn allemaal met vlag en wimpel geslaagd voor de validatie- en verificatietests. En toch slagen ze er niet in om klanten en gebruikers tevreden te stellen en bieden ze beduidend minder efficiëntie en effectiviteit dan ze zouden kunnen.
'We have a set of tools that can help address the stupidity of products'
In het tijdperk van AI hebben we een aantal hulpmiddelen in onze gereedschapskist waarmee we de domheid van producten kunnen aanpakken. Door verschillende vormen van leren en experimenteren te gebruiken, kunnen we gedrag in systemen opnemen om patronen te detecteren, hypotheses te ontwikkelen over de consistentie van deze patronen, experimenten uit te voeren met proactief systeemgedrag, het effect van het experiment te meten en er vervolgens van te leren.
Een theoretische AI-onderzoeker kan beweren dat dit reinforcement learning is en in de kern is dat een juiste conclusie. Het zou echter ook in strijd zijn met het Einstein-principe om alles zo eenvoudig mogelijk te maken, maar niet eenvoudiger. De belangrijkste uitdaging bij het slimmer maken van systemen is niet het basisprincipe van reinforcement learning, maar eerder ons vermogen om de bovengenoemde activiteiten en gedragingen in systemen te realiseren zonder veiligheids- of beveiligingsrisico’s te veroorzaken, zonder de gebruiker te irriteren (herinner je je Clippy?), de stochastische aard van feedback te beheren en ons te richten op die dingen die daadwerkelijk waarde toevoegen voor de gebruiker.
Toch verwachten klanten steeds meer dat hun producten elke dag dat ze ze gebruiken beter worden. Ik wil dat mijn auto, mijn telefoon, mijn computer, mijn apps en mijn wearables elke dag beter worden. Ik wil dat mijn apparaten van mij en mijn gedrag leren om mij meer waarde te bieden door zich daaraan aan te passen. Om dit te bereiken is het niet genoeg om DevOps in te voeren en A/B-tests uit te voeren, maar het vereist ook volledig autonoom experimenteren door systemen met snelheden waar R&D-organisaties simpelweg niet aan kunnen tippen.
Onze systemen moeten ons niet aansporen tot ander gedrag, zoals veel sociale media-apps geneigd zijn te doen, maar proactief handelen namens ons en in ons voordeel. Ik wil dat de systemen die ik gebruik en waar ik mee omga de leiding nemen en de last van het altijd maar onthouden en initiëren van activiteiten van mijn schouders halen, zodat ik me kan richten op de dingen waar ik uniek goed in ben. Stop alsjeblieft met het bouwen van domme systemen en concentreer je op het toevoegen van slim, proactief gedrag in plaats van de zoveelste functie.
High Tech Institute en Cydrill organiseerden op 6 oktober 2020 een 45 minuten durende sessie die je een grondig overzicht geeft van hoe ML-applicaties gehackt kunnen worden en wat je ertegen kunt doen.
Deze opgenomen webinar is een uittreksel van de gloednieuwe face-to-face of online cursus over machine learning beveiliging die High Tech Institute en zijn partner voor softwarebeveiliging Cydrill lanceren.
Bedreigingen uit de echte wereld:
– Enkele voorbeelden van misbruik in de echte wereld
– Omgaan met AI/ML-bedreigingen in softwarebeveiliging
Machine Leren Beveiliging
Adversaire ML-voorbeelden
– Aanvallen met vergiftiging en ontwijking
– Demo – ML-ontwijkingsaanval
– Casestudies
De ML-toeleveringsketen
– Beveiligingsproblemen en kwetsbaarheden van TensorFlow
Leren hoe je niet codeert
Conclusie, V&A
Presentator: Balázs Kiss
Balázs werkt al meer dan 13 jaar op het gebied van softwarebeveiliging als beveiligingsevaluator, onderzoeker en mentor. Recentelijk heeft hij zich gericht op het helpen van ontwikkelaars om te leren hoe typische kwetsbaarheden worden geïntroduceerd tijdens de ontwikkeling van software en hoe deze problemen bij de bron kunnen worden gestopt. Tot nu toe heeft hij wereldwijd meer dan 60 trainingen gegeven.
Met alle aandacht voor data en AI was het slechts een kwestie van tijd voordat de tegenbeweging op gang kwam. Als ik terugkijk op verschillende discussies die ik het afgelopen jaar over dit onderwerp heb gevoerd, lijkt het hoofdthema te zijn dat data en AI de toekomst voorspellen op basis van het verleden en zolang de toekomst op het verleden lijkt, werkt dit prima. De wereld is echter constant in beweging en deze technologieën veroorzaken stagnatie omdat we fundamentele verschuivingen en ontwrichtende innovaties niet kunnen voorspellen. Erger nog, we zoeken er niet eens naar omdat we kortzichtig naar gegevens kijken.
'Not exploiting the advantages of data and AI is tying one arm behind your back'
Hoewel ik zeer zeker geloof dat er een zeer belangrijke plaats is voor menselijke creativiteit en inzicht, denk ik ook dat het niet benutten van de voordelen die data en AI bieden simpelweg hetzelfde is als jezelf in de voet schieten of een arm achter je rug binden. Daar zijn verschillende redenen voor.
Ten eerste, ondanks alle kritiek op machine learning voor het voorspellen van de toekomst, is het een feit dat mensen daar in de meeste gevallen nog slechter in zijn. Zelfs voor zeer variabele gegevens slagen ML algoritmen er vaak in om patronen te ontdekken die mensen niet kunnen detecteren. Voor grote retailers was het voorspellen van de hoeveelheid te bestellen producten en deze vervolgens toe te wijzen aan elke individuele winkel vroeger een menselijke taak, maar het is duidelijk dat ML-algoritmen, gegeven voldoende gegevens, beter werk leveren. Een tegenargument dat de laatste tijd vaak wordt gebruikt is dat deze algoritmen de Covid-19 verstoring niet hebben voorspeld, maar mensen hebben dat natuurlijk ook niet gedaan, waardoor veel winkels met een aanzienlijk overschot aan goederen zitten.
Ten tweede ontmoet ik nog steeds mensen die overtuigingen blijven verkondigen over de wereld, hun sector, hun klanten of hun eigen prestaties die gewoon niet waar zijn. Hoewel sommigen, zoals Steve Jobs, bekend stonden om hun “realiteitsvervormingsveld”, geldt voor vrijwel iedereen dat alleen maar wensen dat iets waar is, het nog niet waar maakt. Zoals William Edwards Deming ooit zei: op God vertrouwen we; alle anderen moeten met gegevens komen.
Ten derde nemen datagestuurde werkwijzen de menselijke creativiteit niet weg, maar richten ze die juist op het formuleren van hypotheses. In traditionele organisaties kun je een carrière opbouwen door sterke uitspraken te doen die moeilijk te verifiëren zijn en daar luid over te spreken. Vaak zijn deze gebaseerd op individuele gevallen en storytelling, waar wij als mensen erg gevoelig voor zijn. Bij het invoeren van datagestuurde praktijken moet de focus liggen op het formuleren van testbare hypotheses en minder bezorgd zijn om ongelijk te krijgen. Zelfs hypotheses die creatief en nieuw zijn, maar niet uitkomen, bieden voldoende gelegenheid om te leren.
Ten vierde, als je datagedreven praktijken gebruikt, moet je weten waarvoor je optimaliseert. In vrijwel alle bedrijven waar ik mee werk, worden features geprioriteerd en ontwikkeld op basis van de overtuigingen van een of andere productmanager. Het effect van de geprioriteerde functie op het gedrag van de klant of het systeem en de manier waarop het waarde genereert, wordt vaak in kwalitatieve en vage termen beschreven. Het slechtste argument hier is dat het een “strategische investering” is. In plaats van het prioriteren van een te ontwikkelen functie op basis van de overtuigingen van een productmanager, is het veel beter om de functie te behandelen als een hypothese, het verwachte, kwantitatieve effect ervan te definiëren en vervolgens de impact ervan te meten terwijl je de functie stukje bij beetje ontwikkelt.
Datagestuurd werken maakt je niet saai. In plaats daarvan zorgt het voor een hogere mate van discipline in de organisatie, maakt het gebruik van technologie waar dat het beste past en richt het creatieve energie op de gebieden waar mensen de meeste waarde leveren. Het helpt organisaties om zogenaamde “schaduwovertuigingen” af te schudden (overtuigingen die iedereen in de organisatie als waar beschouwt maar die dat niet zijn) en daardoor hypotheses die niet kloppen uit de ideeënpool te verwijderen. Mensen noch machines kunnen de toekomst voorspellen. Maar hoewel de geschiedenis zich nooit herhaalt, rijmt ze vaak wel. En machine learning is beter in het detecteren van de rijmen dan jij.
Als die Sicherheitsforschung im Bereich des maschinellen Lernens noch in den Kinderschuhen steckt, ist es klar, dass barrierefreie Eingabemöglichkeiten die Bedrohungen erhöhen. Je hebt geen betere smaak nodig om een uitgebreid systeem te ontwikkelen. De Software-Sicherheitsexpert Balázs Kiss gaat in op een aantal punten in dit nieuwe gebied en geeft een overzicht van de belangrijkste Schutzmaßnahmen.
Net als software in de hele wereld zijn ook maschinelle Lernsysteme anfällig. “Voor een deel zijn ze net als pasgeboren baby’s, die zich volledig richten op hun ouders, om te leren hoe de wereld functioneert – einschließlich ‘Hintertüren’ zoals Märchen of der Weihnachtsmann”, zegt Sicherheitsexperte Balázs Kiss van Cydrill, een van de Softwaresicherheit-specialisten. “Andererseits sind maschinelle Lernsysteme wie alte Katzen mit schlechtem Sehvermögen – wenn eine Maus lernt, wie die Katze jagt, kann sie leicht vermeiden, gesehen und gefangen zu werden.”
Es sieht nicht gut aus, meint Kiss. “Die Sicherheit beim maschinellen Lernen wird zu einem kritischen Thema.” Hij zegt dat de meeste softwareontwikkelaars en experts voor het leren van computers de Angriffstechniken niet kennen. “Het zijn niet altijd diegenen die de Software-Sicherheitsgemeinschaft al lange tijd kennen. Ook de bijbehorende Best Practices kennen ze niet. Das sollte sich ändern.”
De Sicherheitsexperte en erfahrene Softwaretrainer Balázs Kiss heeft kürzlich een nieuwe cursus over die Sicherheit bij het leren van machines ontwikkeld, die in Kürze vom High Tech Institute in de Niederlanden wordt aangeboden.
Lösungen für maschinelles Lernen (ML) sind – wie Softwaresysteme – auf verschiedene Weise angreifbar und erhöhen den Sicherheitsbedarf. In het laatste jaar werd dit op een rechtlijnige en eenvoudige manier onderzocht door twee studenten uit Leuven. Yolo (You Only Look Once), een van de beste algoritmen voor het herkennen van objecten en personen, werd door hen in het leven geroepen. Als ze een Pappschild met een bunten Aufdruck van 40 mal 40 cm voor ihrem Körper trugen, maken ze Simen Thys en Wiebe Van Ranst als menschliche Personen unerkennbar. Een ander voorbeeld is afkomstig van McAfee-forschern, die het Tesla-Autopiloten onmogelijk maakten om de windrichting aan te passen, omdat ze de begrenzingen van hun auto’s op een falsch einordneten en de auto op 35 mijl per uur beschleunigen.
Kennen Sie Ihren Feind
“Eine wesentliche Voraussetzung für die Cybersicherheit ist: Kenne deinen Feind”, zegt Kiss, die zelf een erfahrener Softwaretrainer is en binnenkort een nieuwe cursus over ML-Sicherheit heeft opgezet, die in Kürze vom High Tech Institute in den Niederlanden zal worden uitgevoerd. “Het belangrijkste is dat je met de kop van je tegenstander denkt”, zegt hij.
Wij werven een blik op wat die Angreifer bij het leren in het openbaar moeten doen. Alles begint met de Erforschung dessen, wat Sicherheitsexperten omschrijven als “Angriffsfläche”: die Kombination aller verschiedenen Punkte in einer Softwareumgebung, an denen ein unbefugter Benutzer versuchen kann, Daten einzugeben oder zu extrahieren. Die Angriffsfläche so klein wie möglich zu halten, ist eine grundlegende Sicherheitsmaßnahme. Wie die Studenten aus Leuven bewiesen haben: Um ein ML-System zu täuschen, müssen Sie nicht einmal eine Tastatur anfassen.
'Garbage in, garbage out.'
Een eeuwenoude spreuk in de wereld van maschinellen Lernens luidt “Garbage in, garbage out”. Alle algoritmen maken gebruik van trainingsgegevens om hun verhoudingen te verbeteren. Schlechte gegevens leiden tot onvolledige gegevens. Das kann daran liegen, dass das Modell bei den Trainingsdaten gut funktioniert, aber die Ergebnisse nicht auf andere Beispiele verallgemeinern kann (Überanpassung), dass das Modell nicht in der Lage ist, die zugrundeliegenden Trends der Daten zu erfassen (Unteranpassung) oder dass es Probleme mit dem Datensatz gibt. Verkeerde, fehlerhafte of minder bruikbare trainingsgegevens zijn natuurlijk een groot probleem en er zijn mogelijkheden om dit op te lossen. Bijvoorbeeld door het gebruik van test- en validatiegegevens. Als een klant echter absichtlich slechte gegevens ontvangt, is dat een heel ander scenario, waarvoor we altijd speciale Schutzmaßnahmen nodig hebben.
Groothandelaren zijn slecht
Kiss: “We moeten nu meteen duidelijk maken dat we böswillige gebruikers hebben. Die Angreifer müssen nicht einmal besondere Privilegien innerhalb des Systems haben, aber sie können Roheingaben als Trainingsdaten bereitstellen und die Ausgabe des Systems sehen, typischerweise den Klassifizierungswert. Dat betekent dat ze absichtlich schlechte oder bösartige Daten kunnen versturen, um unbeabsichtigte ML-Fehler auszulösen.”
'Attackers can learn how the model works and refine their inputs to adapt the attack.'
“Aber das ist nur die Spitze des Eisbergs”, vindt Kiss. “Denken Sie daran, dass Angreifer immer auf ein Ziel hinarbeiten. Ze werden bestimmte Aspekte der ML-Lösung in Visier nehmen. Door de juiste Eingaben te kiezen, kunnen ze het model, de generierten Vorhersage en ook de verschillende codebestanden, die deze Eingaben verarbeiten, grote schade toebrengen. Angreifer zijn schlau. Ze zijn niet darauf beschränkt, statische Eingaben zu senden – ze kunnen leren hoe het model werkt en hun Eingaben verfeinern, um den Angriff anzupassen.”
In het kader van de überwachten Lernens umfasst es alle drei Hauptschritte des ML-Workflows. Voor de training kan een Angreifer Eingabedaten zur Verfügung stellen. Voor de Klassifizierung kan een Angreifer Eingabedaten bereitstellen en het Klassifizierungsergebnis lezen. Als het ML-systeem werkt met een feedback-functie, kan een gebruiker ook foutieve feedbackmeldingen geven (“falsch” voor een goede Klassifizierung en “richtig” voor een slechte), zodat het systeem kan worden verwirren.
Handgefertigte Eingaben
Veel Angriffe nutzen sogenannte gegnerische Beispiele. Die gemanipuleerde Eingaben nutzen entweder das implizite Vertrauen aus, das ein ML-System in die vom Benutzer erhaltenen Trainingsdaten setzt, um seine Sicherheit zu beeinträchtigen (Poisoning) oder das System dazu zu bringen, seine Eingaben falsch zu kategorisieren (Evasion). Derzeit gibt es keine narrensichere Methode, mit der diese Beispiele automatisch erkannt und herausgefiltert werden können. Alleen de beste oplossing, waarbij een systeem wordt gebruikt om negatieve beispiele te erkennen, is in haar rijkdom begrensd.
Als ze een Pappschild met een bunten Aufdruck van 40 x 40 cm vor ihrem Körper trugen, maken ze Simen Thys und Wiebe Van Ranst als menschliche Personen unerkennbar. Krediet: KU Leuven/Eavise
Natuurlijk zijn er Verteidigungsmaßnahmen om negatieve voorbeelden te herkennen of te negeren. Een intelligente analist kan echter oplossingen bedenken zoals die Verschleierung, als hij op een adaptieve manier een reeks gegenbeispielen erzeugt. Kiss verweist auf einige exzellente Arbeiten, die dies hervorheben, wie die von Nicholas Carlini und seinen Kollegen bei Google Brain.
Alles bij elkaar bevindt die ML-Sicherheitsforschung zich nog steeds in een frühen Stadion. Die aktuellen Studien konzentrieren sich hauptsächlich auf die Bilderkennung. Er zijn echter enkele Abwehrtechniken die bij afbeeldingen goed werken, maar bij tekst of audio niet. “Maar er zijn veel dingen die je kunt doen om je in de praktijk te helpen”, zegt Kiss. “Maar je kunt geen enkele van deze maatregelen volledig voor de goede doelen gebruiken. Al deze maatregelen bieden echter zusätzlichen Schutz und erschweren die Ausführung von Angriffen.”
Het belangrijkste, aldus de Cydrill-expert, is dat je met de kop van je tegenstander denkt. “Je moet neuronale netwerken trainen met gegnerische voorbeelden, zodat ze die informatie kunnen herkennen als vals.” Laut Kiss vindt het een goed idee, om gegnerische Muster aus allen derzeit bekannten Angriffstechniken zu erstellen und zu verwenden. Een Test-Framework kan deze Muster genereren, um den Prozess zu vereinfachen. Er zijn al Sicherheitstest-Tools die hierbij kunnen helpen – zoals die ML-Fuzz-Tester Tensorfuzzs en Deeptest, die automatisch ongültige of unerwartete Eingaben erzeugen.
Sanitätskontroller
Die Begrenzung der Möglichkeiten des Angreifers, gegnerische Proben zu senden, ist immer eine gute Abschwächungstechnik. Dit is moeilijk te verhelpen als je snel de hoeveelheid van de door een gebruiker geselecteerde gegevens kunt instellen. Het is natuurlijk niet eenvoudig om te erkennen dat elke gebruiker zich tussen een reeks van Eingaben bevindt. “Dit is de zelfde Herausforderung als bij verteilten Denial-of-Service-Angriffen, aber die gleichen Lösungen könnten auch funktionieren.”
Wie immer bei der Softwaresicherheit kan eine Eingabeüberprüfung helfen. Het is niet triviaal om automatisch goede en slechte Eingaben te verwijderen, maar het is in ieder geval een goede oplossing. We kunnen ook het maschinelle Lernen selbst nutzen, um anomale Muster in den Eingaben zu erkennen. “In het kleinste geval, als die gegevens van een niet vertrauenswürdigen Benutzer erhaltenen durchweg näher an der Klassifizierungsgrenze als am Durchschnitt liegen, können wir die Daten für eine manuelle Überprüfung markieren oder sie einfach auslassen.
Regelmatige Überprüfungen mit Testdaten können ebenfalls hilfreich sein. Als je bij elke nieuwe Trainingszyklus denselben Testdatensatz gegen das Modell lassen, kun je Vergiftungsversuche aufdecken. Kiss: “Ablehnen bei negativer Auswirkung, Roni, ist hier eine typische Verteidigung, um zu erkennen, ob sich die Fähigkeit des Systems, den Testdatensatz zu klassifizieren, nach der Umschulung verschlechtert.”
Die offensichtlichste Tatsache über die Sicherheit von ML wird oft übersehen, bemerkt Kiss. “Lösungen für maschinelles Lernen sind Softwaresysteme. We programmeren ze in Python – of möglicherweise in C++ – en daardoor weisen ze potenziell alle gängigen Sicherheitslücken auf, die für diese Sprachen gelten.” De Cydrill-trainer geeft ons vooral een indruk van punt 9 van de OWASP Top Tien. Das Open Web Application Security Project is een Dokument, dat diehn kritischsten Sicherheitsprobleme in Webanwendungen zusammenfasst, um das Bewusstsein zu schärfen und das Risiko von Angriffen zu minimieren. Punt 9 waarschuwt Entwickler voor het gebruik van componenten met bekannten Sicherheitslücken. “Jede Schwachstelle in einem weit verbreiteten ML-Framework wie Tensorflow oder einer einer vielen Abhängigkeiten kann weitreichende Folgen für alle Anwendungen haben, die es verwenden.”
Potenzielle Angriffsziele
Die Angreifer interagieren met dem ML-System, indem sie Daten über die Angriffsfläche einspeisen. Versetzen Sie sich in den Kopf des Angreifers und stellen Sie Fragen. Wie verdaut die Anwendung die Informationen? Welke soort gegevens? Bestaat het systeem uit afbeeldingen en audio- en videodata? Of zijn er Beschränkungen? Als dat zo is, hoe worden die types dan weergegeven? Heeft het programma de parsing of is het volledig geïntegreerd in een open source of erhältliche Medienbibliothek? En heeft het programma na de bewerking van de gegevens irgendwelche Annahmen (leeres Feld, Anforderungen an Werte)? Staan die gegevens in een relationele databank of in XML of JSON? Zo ja, welke bewerkingen voert de code uit met deze gegevens, wanneer ze worden bewerkt? Waar werden die Hyperparameter gespeichert en kunnen ze tijdens de gebruiksduur worden gewijzigd? Worden Bibliotheken, Frameworks, Middleware of Webservice-API’s van Drittanbietern gebruikt als onderdeel van workflows, die Benutzereingaben verarbeitet? Ja, welke?
Kiss: “Jede dieser Fragen kann auf potenzielle Angriffsziele hinweisen. Jede von ihnen kan Schwachstellen verbergen, die Angreifer ausnutzen können, um ihre ursprünglichen Ziele zu erreichen.”
Die Schwachstellen haben weniger mit dem maschinellen Lernen zu tun als vielmehr mit den zugrundeliegenden Technologien: der Programmiersprache selbst (wahrscheinlich Python), der Einsatzumgebung (mobil, Desktop, Cloud) und dem Betriebssystem. Maar die Gefahren, die door hen worden veroorzaakt, zijn net zo kritisch als de gegnerificeerde Beispiele – een erfolgreiche Ausnutzung kan leiden tot een vollständigen Kompromittierung des ML-Systems. Dit beschränkt sich nicht auf den Code der Anwendung selbst. Rock Stevens van de Universiteit van Maryland heeft onderzoek gedaan naar Schwachstellen in veelgebruikte platformen zoals Tensorflow en Pytorch.
Echte oplossingen
De belangrijkste eigenschap van Kiss is dat ML-Sicherheit veel nieuwe mogelijkheden biedt. Het is niet alleen een techniek van Cybersicherheit, maar het heeft ook veel te maken met de algemene softwaresicherheit. We richten ons niet alleen op bösartige samples en gegnerisches Lernen, maar ook op alle üblichen Schwachstellen der Software-Sicherheit. Het leren van machines is nu eenmaal software.
ML-Sicherheit is een nieuwe discipline. Die Forschung hat gerade erst begonnen, we fangen gerade erst an, die Bedrohungen, die möglichen Schwachstellen und die Anfälligkeiten zu verstehen. Daarom kunnen ML-experts veel leren over Software-Sicherheit. In de afgelopen jaren hebben we hier veel leermiddelen ontwikkeld.
Dit artikel is geschreven door René Raaijmakers, technisch redacteur van Bits&Chips.
Hoewel machine learning beveiligingsonderzoek zich nog in een vroeg stadium bevindt, is het duidelijk dat inputmogelijkheden zonder barrières de bedreigingen vergroten. Je hoeft geen toetsenbord meer aan te raken om een machine-leersysteem voor de gek te houden. Softwarebeveiligingsdeskundige Balázs Kiss behandelt een aantal punten op dit nieuwe gebied en geeft advies over de basisbeschermingsmaatregelen.
Net als software in het algemeen zijn machine-leersystemen kwetsbaar. “Aan de ene kant zijn het net pasgeboren baby’s die volledig op hun ouders vertrouwen om te leren hoe de wereld werkt – inclusief ‘achterdeurtjes’ zoals sprookjes of de Kerstman”, zegt beveiligingsexpert Balázs Kiss van Cydrill, een bedrijf dat gespecialiseerd is in softwarebeveiliging. “Aan de andere kant zijn machine-leersystemen als oude katten met een slecht gezichtsvermogen – als een muis leert hoe de kat jaagt, kan hij gemakkelijk voorkomen dat hij wordt gezien en gevangen.”
Volgens Kiss ziet het er niet goed uit. “Machine learning-beveiliging wordt een kritisch onderwerp.” Hij wijst erop dat de meeste softwareontwikkelaars en experts in machine learning zich niet bewust zijn van de aanvalstechnieken. “Zelfs niet degenen die al lang bekend zijn in de softwarebeveiligingsgemeenschap. Ook zijn ze niet op de hoogte van de bijbehorende best practices. Dit zou moeten veranderen.”
Beveiligingsexpert en ervaren softwaretrainer Balázs Kiss heeft onlangs een nieuwe cursus ontwikkeld over machine learning-beveiliging die binnenkort wordt uitgerold door High Tech Institute in Nederland.
Machine learning (ML) oplossingen zijn – net als softwaresystemen – op verschillende manieren kwetsbaar en vergroten de beveiligingsbehoeften. Vorig jaar werd dit op een vrij gênante en eenvoudige manier duidelijk gemaakt door twee studenten uit Leuven. Ze slaagden er gemakkelijk in om Yolo (You Only Look Once), een van de populairste algoritmes om objecten en mensen te detecteren, te misleiden. Door een kartonnen bord met een kleurrijke print van 40 bij 40 cm voor hun lichaam te dragen, maakten Simen Thys en Wiebe Van Ranst zichzelf ondetecteerbaar als menselijke personen. Een ander voorbeeld komt van McAfee-onderzoekers die erin slaagden de Tesla autopilot voor de gek te houden door snelheidsborden verkeerd te classificeren en de auto sneller te laten rijden dan 35 mph.
Ken uw vijand
“Een essentiële voorwaarde voor cyberbeveiliging is: ken je vijand”, zegt Kiss, die ook een ervaren softwaretrainer is en onlangs een gloednieuwe cursus over ML-beveiliging heeft ontwikkeld die binnenkort door High Tech Institute in Nederland wordt uitgerold. “Het belangrijkste is dat je moet denken met het hoofd van een aanvaller,” zegt hij.
Laten we eens kijken waar aanvallers zich op richten bij machine learning. Het begint allemaal met het onderzoeken van wat beveiligingsexperts “het aanvalsoppervlak” noemen, de combinatie van alle verschillende punten in een softwareomgeving waar een ongeautoriseerde gebruiker kan proberen gegevens binnen te komen of te extraheren. Het aanvalsoppervlak zo klein mogelijk houden is een basisveiligheidsmaatregel. Zoals de studenten uit Leuven bewezen: om een ML-systeem te misleiden hoef je niet eens een toetsenbord aan te raken.
'Garbage in, garbage out.'
Een veelgebruikt gezegde in de wereld van machine learning is “garbage in, garbage out”. Alle algoritmen gebruiken trainingsgegevens om hun gedrag vast te stellen en te verfijnen. Slechte gegevens resulteren in onverwacht gedrag. Dit kan komen doordat het model goed presteert op de trainingsgegevens maar niet in staat is om de resultaten te generaliseren naar andere voorbeelden (overfitting), doordat het model niet in staat is om de onderliggende trends van de gegevens vast te leggen (underfitting) of door problemen met de dataset. Vertekende, foutieve of dubbelzinnige trainingsgegevens zijn natuurlijk toevallige problemen en er zijn manieren om hiermee om te gaan. Bijvoorbeeld door geschikte test- en validatiedatasets te gebruiken. Een tegenstander die dergelijke slechte invoer opzettelijk invoert, is echter een heel ander scenario waarvoor we ook speciale beschermingsbenaderingen nodig hebben.
Aanvallers zijn slim
Kiss: “We moeten gewoon aannemen dat er kwaadwillende gebruikers zullen zijn. Deze aanvallers hoeven niet eens bepaalde privileges te hebben binnen het systeem, maar ze kunnen ruwe invoer leveren als trainingsgegevens en de uitvoer van het systeem zien, meestal de classificatiewaarde. Dit betekent al dat ze opzettelijk slechte of kwaadaardige data kunnen sturen om onbedoelde ML-fouten te veroorzaken.”
'Attackers can learn how the model works and refine their inputs to adapt the attack.'
“Maar dat is slechts het topje van de ijsberg,” vindt Kiss. “Houd in gedachten dat aanvallers altijd naar een doel toewerken. Ze richten zich op specifieke aspecten van de ML-oplossing. Door de juiste invoer te kiezen, kunnen ze veel potentiële schade aanrichten aan het model, de gegenereerde voorspelling en zelfs de verschillende stukjes code die deze invoer verwerken. Aanvallers zijn slim. Ze zijn niet beperkt tot het sturen van statische inputs – ze kunnen leren hoe het model werkt en hun inputs verfijnen om de aanval aan te passen.”
In het geval van supervised learning omvat het alle drie de grote stappen van de ML-workflow. Voor training kan een aanvaller invoergegevens leveren. Voor classificatie kan een aanvaller invoergegevens leveren en het classificatieresultaat lezen. Als het ML systeem feedback functionaliteit heeft, kan een aanvaller ook valse feedback geven (“fout” voor een goede classificatie en “correct” voor een slechte) om het systeem in de war te brengen.
Ambachtelijke input
Veel aanvallen maken gebruik van zogenaamde adversaire voorbeelden. Deze bewerkte invoer maakt gebruik van het impliciete vertrouwen dat een ML systeem stelt in de trainingsgegevens van de gebruiker om de veiligheid te schaden (vergiftiging) of verleidt het systeem om de invoer verkeerd te categoriseren (ontwijking). Er bestaat op dit moment geen onfeilbare methode die deze voorbeelden automatisch kan detecteren en filteren; zelfs de beste oplossing, waarbij een systeem wordt geleerd om voorbeelden van tegenstanders te herkennen, heeft een beperkte reikwijdte.
Door een kartonnen bord met een kleurrijke print van 40 bij 40 cm voor hun lichaam te dragen, maakten Simen Thys en Wiebe Van Ranst zichzelf ondetecteerbaar als menselijke personen. Krediet: KU Leuven/Eavise
Er zijn natuurlijk verdedigingen om tegenstrijdige voorbeelden te detecteren of te beperken. Een intelligente aanvaller kan echter oplossingen zoals obfuscation verslaan door op een adaptieve manier een set voorbeelden van tegenstanders te produceren. Kiss wijst op een aantal uitstekende artikelen die dit belichten, zoals die van Nicholas Carlini en zijn collega’s bij Google Brain.
Al met al staat het onderzoek naar ML-beveiliging nog in de kinderschoenen. De huidige onderzoeken richten zich vooral op beeldherkenning. Sommige verdedigingstechnieken die goed werken voor afbeeldingen zijn echter mogelijk niet effectief voor tekst of audio. “Dat gezegd hebbende, zijn er nog genoeg dingen die je kunt doen om jezelf in de praktijk te beschermen,” vertelt Kiss. “Helaas zal geen enkele je volledig beschermen tegen kwaadaardige activiteiten. Ze zullen echter allemaal lagen van bescherming toevoegen, waardoor de aanvallen moeilijker uit te voeren zijn.”
Het belangrijkste is volgens de Cydrill-expert dat je denkt met het hoofd van een aanvaller. “Je moet neurale netwerken trainen met aanvalsvoorbeelden om ze deze informatie expliciet als onjuist te laten herkennen.” Volgens Kiss is het een goed idee om adversarial samples te maken en te gebruiken van alle momenteel bekende aanvalstechnieken. Een testraamwerk kan zulke monsters genereren om het proces gemakkelijker te maken. Er zijn bestaande tools voor beveiligingstesten die hierbij kunnen helpen, zoals ML fuzz testers Tensorfuzzs en Deeptest, die automatisch ongeldige of onverwachte invoer genereren.
Gezond verstand controles
Het beperken van de mogelijkheden van de aanvaller om vijandige samples te versturen is altijd een goede beperkingstechniek. Dit kan eenvoudig bereikt worden door het aantal geaccepteerde inputs van een gebruiker te beperken. Natuurlijk kan het niet eenvoudig zijn om te detecteren dat dezelfde gebruiker achter een set inputs zit. “Dit is dezelfde uitdaging als in het geval van gedistribueerde denial-of-service aanvallen, maar dezelfde oplossingen zouden ook kunnen werken.”
Zoals altijd bij softwarebeveiliging kan invoervalidatie helpen. Het is misschien niet triviaal om automatisch goede van slechte invoer te onderscheiden, maar het is zeker het proberen waard. We kunnen ook machine learning zelf gebruiken om afwijkende patronen in de invoer te identificeren. “In het eenvoudigste geval, als gegevens die we ontvangen van een niet-vertrouwde gebruiker consequent dichter bij de classificatiegrens liggen dan bij het gemiddelde, kunnen we de gegevens markeren voor handmatige controle, of ze gewoon weglaten.”
Het regelmatig uitvoeren van controles met testgegevens kan ook helpen. Het uitvoeren van dezelfde testdataset tegen het model bij elke hertrainingscyclus kan pogingen tot een vergiftigingsaanval aan het licht brengen. Kiss: “Afwijzen bij negatieve impact, Roni, is hier een typische verdediging, die detecteert of het vermogen van het systeem om de testdataset te classificeren afneemt na de hertraining.”
Het meest voor de hand liggende feit over ML-beveiliging wordt vaak over het hoofd gezien, merkt Kiss op. “Machine learning-oplossingen zijn softwaresystemen. We programmeren ze in Python – of mogelijk C++ – en dus dragen ze potentieel alle veelvoorkomende beveiligingszwakheden met zich mee die op die talen van toepassing zijn.” De Cydrill trainer raadt ons vooral aan om bewust te zijn van punt 9 uit de OWASP Top Tien. Het Open Web Application Security Project is een document dat de tien meest kritieke beveiligingsproblemen in webapplicaties samenvat om het bewustzijn te vergroten en het risico op aanvallen te minimaliseren. Punt 9 waarschuwt ontwikkelaars voor het gebruik van componenten met bekende kwetsbaarheden. “Elke kwetsbaarheid in een wijdverspreid ML-framework zoals Tensorflow of een van zijn vele afhankelijkheden kan verstrekkende gevolgen hebben voor alle applicaties die het gebruiken.”
Mogelijke aanvalsdoelen
De aanvallers communiceren met het ML-systeem door gegevens in te voeren via het aanvalsoppervlak. Begin te denken met het hoofd van de aanvaller en stel vragen. Hoe verteert de applicatie de informatie? Wat voor soort gegevens? Accepteert het systeem afbeeldingen, audio- en videobestanden? Of zijn er beperkingen? Zo ja, hoe controleert het de types? Doet het programma enige parsing of delegeert het dit volledig aan een open-source of commercieel beschikbare mediabibliotheek? En heeft het programma na het voorbewerken van de gegevens aannames (lege velden, eisen aan waarden)? Worden de gegevens opgeslagen in een relationele database of in XML of JSON? Zo ja, welke bewerkingen voert de code uit op deze gegevens wanneer ze worden verwerkt? Waar worden de hyperparameters opgeslagen en zijn ze tijdens runtime aan te passen? Maakt de applicatie gebruik van bibliotheken, frameworks, middleware of webservice-API’s van derden als onderdeel van de workflow die gebruikersinvoer verwerkt? Zo ja, welke?
Kiss: “Elk van deze vragen kan wijzen op potentiële aanvalsdoelen. Ze kunnen allemaal kwetsbaarheden verbergen die aanvallers kunnen uitbuiten om hun oorspronkelijke doel te bereiken.”
Deze typen kwetsbaarheden zijn niet zozeer gerelateerd aan machine learning als wel aan de onderliggende technologieën: de programmeertaal zelf (waarschijnlijk Python), de implementatieomgeving (mobiel, desktop, cloud) en het besturingssysteem. Maar de gevaren die ze vormen zijn net zo kritiek als de voorbeelden van tegenstanders – succesvolle exploitatie kan leiden tot een volledige compromittering van het ML-systeem. Dit beperkt zich niet tot de code van de applicatie zelf. Onderzoeker Rock Stevens van de Universiteit van Maryland onderzocht kwetsbaarheden in veelgebruikte platforms zoals Tensorflow en Pytorch.
Echte bedreigingen
De belangrijkste boodschap van Kiss is dat ML-beveiliging veel echte bedreigingen omvat. Het is niet slechts een deelverzameling van cyberbeveiliging, het deelt veel eigenschappen van softwarebeveiliging in het algemeen. We moeten ons zorgen maken over kwaadaardige samples en adversarial learning, maar ook over alle gebruikelijke zwakke plekken in de beveiliging van software. Machine learning is tenslotte software.
ML-beveiliging is een nieuwe discipline. Het onderzoek is nog maar net begonnen, we beginnen nog maar net de bedreigingen, de mogelijke zwakke plekken en de kwetsbaarheden te begrijpen. Toch kunnen ML-experts veel leren van softwarebeveiliging. Daar hebben we de afgelopen decennia veel van geleerd.
Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.
Als projectmanager, systeemarchitect en crisismanager in de hightechindustrie heeft Luud Engels de reputatie om geen blad voor de mond te nemen. Naast zijn consultancywerk is hij onlangs begonnen als systeemarchitect(en)-trainer bij High Tech Institute. “Duidelijke communicatie is essentieel in complexe ontwikkelomgevingen.”
Je wilt niet met Luud Engels beginnen over hoe ruimdenkend en communicatief we in de Nederlandse hightech zijn als systeemarchitect. Hij zal krachtig reageren en benadrukken hoe hypocriet het is om dat te geloven. “Hier in Brabant zijn we helemaal niet zo open. Ga maar bij een koffieautomaat staan en luister. We praten niet met je, maar over je.”
Als het aankomt op directe communicatie – of beter gezegd confrontatie – heeft Engels een reputatie. Een paar maanden geleden werd hij de laan uitgestuurd nadat hij – volgens zijn klant – duidelijk had gemaakt wat er mis was binnen het bedrijf. “Ik ben ervan overtuigd dat je op het juiste moment alles tegen iedereen kunt zeggen – of het nu in een teamvergadering is of een discussie tussen twee mensen. Natuurlijk doen de meeste Nederlanders dat niet. Maar ik schijn er ook niet in uit te blinken, want ik zeg dingen soms zo bot dat mensen tegen me zeggen dat ik moet oprotten.”
Engels’ waardering voor feitelijke en heldere communicatie komt voort uit zijn jarenlange ervaring als projectmanager, systeemarchitect, crisismanager en lid van het managementteam bij ingenieursbureau TMC. Zijn advies voor ontwikkelomgevingen: “Zeg wat je denkt. Ook over persoonlijke zaken. Het is prima om iemand te vertellen dat zijn blauwe shirt je stoort. Maar uitspraken als ‘Microsoft zuigt en Apple is goed’ helpen niet. Maak het feitelijk: gaan we objectgeoriënteerd of procesgeoriënteerd werken? Gaan we glas of titanium gebruiken? Wat zijn de voordelen? Wat zijn de nadelen? Als we het over glas hebben, hoef ik niet de hele geschiedenis van de glasblazerij te kennen. Ik wil de vijf belangrijkste criteria – in getallen, niet in positieve en negatieve. Als je de belangrijkste parameters kent, weet je ook hoe je ze moet meten en kunnen we afspraken maken over de eerste ontwikkelingsstappen om de metingen mogelijk te maken.”
'Make sure the whole team is at least on the same path.'
Engels benadrukt dat bij de ontwikkeling van hightechsystemen meerdere wegen naar Rome leiden en dat het belangrijk is om bij de gemaakte keuze te blijven. “Zorg ervoor dat het hele team op zijn minst op dezelfde weg zit, in plaats van eindeloos te zoeken naar de enige juiste oplossing – die per definitie niet bestaat.”
Maar soms kunnen zelfs de eenvoudigste dingen misgaan. “Een keer, na een positief gesprek met een klant, ontving ik het rapport in spreektaal Nederlands. Ik vroeg of de vertegenwoordigers van de klant de tekst hadden goedgekeurd. Dat hadden ze natuurlijk niet. Dus stond ik erop om het in het Engels op te schrijven, het aan de klant voor te leggen en om goedkeuring te vragen. Het gaat tenslotte vaak om beslissingen met verstrekkende gevolgen. Toch bleek de synchronisatie met de klant een hele klus.”
De wetten van Luud
Als de financiële mensen het overnemen, wordt het technische belang secundair; als de ingenieurs de leiding nemen, gaat het financieel kapot
(Over het in evenwicht brengen van techniek en geld in hightech OEM’s)
De klant die vraagt om een crisis af te wenden is voor de helft de boosdoener of onderdeel van de crisis in kwestie (Over crisismanagement)
Ik geloof heilig in de kracht van de buitenstaander (Over de crisismanager)
We praten langs elkaar heen: de een praat in Newton per vierkante meter, de ander in bits per seconde (Over communicatie en samenwerking in hightech)
Een crisis verdwijnt niet door de mensen weg te sturen die de vinger op de zere plek leggen (Over gestrande ontwikkelingsprojecten)
Engels’ uitgebreide technische carrière begon met een studie elektrotechniek, waarna hij in dienst trad bij Sattcontrol, een Zweedse specialist in industriële automatisering. Hij programmeerde PLC’s voor eiersorteermachines, zuivelfabrieken en geautomatiseerde magazijnen. Later stapte hij over op Fortran voor PDP- en Vax-minicomputers.
Na vijf jaar stapte Engels over naar Cap Volmac (later Cap Gemini), waar hij projecten deed. Hoewel hij voornamelijk in engineering werkte, lag de kern van Cap bij bedrijfsautomatisering. “Ik heb veel geleerd over het ontwikkelen van computersystemen en software volgens de regels.”
Engels begon voor Cap bij ASML, daarna werkte hij aan snelwegsignalering bij Rijkswaterstaat en nam uiteindelijk leidinggevende functies op zich. Later kwamen daar audits bij. Hij schat dat hij ongeveer twintig projecten heeft beoordeeld. “Na een dag rondlopen weet je wat er aan de hand is en waar het project fout is gegaan”, zegt hij. Lachend: “En zeker niet omdat ik zo slim ben, of omdat ik zoveel gezien heb, maar vooral omdat ik een buitenstaander was.”
Engels gelooft heilig in de kracht van de buitenstaander. “Je komt bij bedrijven waar het helemaal mis is gegaan en dan mag je rondlopen en met 5-10 mensen praten. Ze hebben allemaal een mening over het crisisproject. Je krijgt het hele verhaal te horen. Mensen willen hun hart uitstorten. Je hoort wat er mis is en vooral: wat anderen niet mogen zeggen.”
De eigenwijze technicus
Technici zijn een koppig, eigenwijs type – en Engels kan het weten, want hij past zeker in dat plaatje. “We zijn ingenieurs, nietwaar? We denken zo: ‘Ik ben een elektrotechnisch ingenieur en volgens mijn berekeningen is het 5 volt. Als je het niet snapt, leg ik het nog een keer uit, maar de uitkomst blijft 5 volt. Jij bent gek, niet ik.’ Terwijl het in projecten vooral gaat om effectieve samenwerking. Dat is het moeilijke deel. De een praat in newton per vierkante meter, de ander in bits per seconde. De één praat over het doel, de ander over de oplossing. De hightech is één grote toren van Babel. Dat begint bij de requirements en loopt door tot het ontwerp, de integratie en het testen. Net zo goed: als ik een project zelf doe en er komt een buitenstaander, dan schiet die er ook gaten in.”
Engels komt het liefst tussenbeide als de crisis op zijn dieptepunt is. Neem het Fusion-project dat eind jaren negentig bij Philips liep. Het ambitieuze doel was om één platform te gebruiken voor de mechanische, elektrische en softwareconstructie van medische diagnosesystemen. Het idee was dat kostenbesparingen door hergebruik de omvangrijke operatie zouden rechtvaardigen. “De directeur schetste zijn probleem als volgt: elke maand kwamen er dertig nieuwe ontwikkelaars bij en elke maand vertelden ze hem dat de oplevering weer twee maanden vertraging opliep.”
'The outsider is allowed to speak up.'
Engels paste opnieuw de kracht van de buitenstaander toe. “De buitenstaander mag spreken. Hoe dieper de crisis, hoe ontvankelijker men is voor berichten van buitenaf. Meestal hebben andere mensen er al naar gekeken. Maar vaak legden ze de vinger op zere plekken die ze niet mochten aanwijzen en moesten ze uiteindelijk vertrekken. Ze vroegen me om de huidige projectleider te vervangen omdat hij de vertraging niet kon inhalen. Maar een crisis verdwijnt niet als je de mensen wegstuurt die de vinger op de zere plek hebben gelegd. In plaats daarvan ging ik de zittende projectleider helpen. Samen hielden we de crisis binnen de perken door de scope aan te passen en te werken met vroege feedback. Een van mijn wetten is: de klant die vraagt om een crisis af te wenden, is voor de helft de boosdoener of heeft er op zijn minst een dominant aandeel in.”
Is het tunnelvisie?
“Let wel: je hebt het over zeer competente mensen met zeer relevante argumenten en tonnen aan kennis. Maar gaandeweg is de oplossing of werkwijze in verschillende silo’s geplaatst. Zeer bekwame mensen slijten paden af en creëren loopgraven die zo diep zijn dat je nauwelijks over de rand kunt kijken. Iedereen heeft zijn loopgraaf en verdedigt die koppig. Je hoort mensen dingen zeggen als: “Hier valt niet over te onderhandelen! Als je dat hoort, wijst het je naar waar het fout is gegaan en waar een mogelijk begin van de oplossing ligt.”
Waar begint de oplossing?
“De eerste wet van crisismanagement is beheersing. Bij Fusion betekende dit dat ze moesten stoppen met het toevoegen van dertig mensen per maand. In plaats daarvan moesten ze er twintig per maand schrappen en de omvang beperken. De diepere oorzaak was volgens mij pure zelfoverschatting. Het platformidee voor software alleen is een grote uitdaging. Maar als je mechanica en elektronica erbij gaat betrekken, voor alle diagnostische producten, wordt het in één keer te veel. Het is al moeilijk genoeg om elektronica, software en mechanica samen te ontwikkelen voor één systeem, maar proberen om in één project één platform te ontwikkelen voor verschillende productlijnen is op zijn zachtst gezegd naïef. In die tijd moesten ze ook samenwerken met ontwikkelaars in Bangalore en wilden ze tegelijkertijd van CCM-niveau 2 naar niveau 3 gaan. Dat moest meteen stoppen. Je moet de reikwijdte van een project in crisis beperken en verbeterinitiatieven op lange termijn uitstellen.”
'It’s often the case that the technicians already know what’s wrong and so does management.'
“Het is vaak zo dat de technici al weten wat er mis is en het management ook. Beiden hebben gelijk, maar samen komen ze niet tot een oplossing. Veel later deed ik een klus bij Philips DPS, waar ik zag dat Philips grote vooruitgang had geboekt. Vingers op zere plekken leggen mocht echter nog steeds niet, helaas.”
Hoe wordt dit op de juiste manier gedaan?
Begin klein, zegt Engels. “Je hebt vroegtijdige feedback nodig, bij voorkeur van een launching customer. Ik heb het Martin van den Brink bij ASML vaak horen zeggen: zet alles in elkaar, laat me zien dat het werkt. Dan daagt hij mensen uit door te zeggen: ‘Je fysica werkt niet.’ Er was veel van dat soort dingen tijdens de vroege integratie. Veel later introduceerde de industrie er mooie woorden voor en noemde het Scrum, Agile en snelle ontwikkeling. Maar het punt is dat je feedback nodig hebt en het is belangrijk om daar in een vroeg stadium mee te beginnen. Het doel moet zijn om elke zes weken iets op te leveren dat echt werkt. Zo niet, dan heb je de middelen om uit te zoeken waarom het mislukte, waarom de fysica niet werkte. Op dat moment moet je misschien accepteren dat je je deadline niet gaat halen. Wat je zeker niet moet doen is meer mensen binnenhalen.”
“Als technici je vertellen dat ze meer tijd nodig hebben om iets te onderzoeken, moet je achterdochtig worden. Van den Brink is ook een meester in het inschatten of uitdagen daarvan.”
'Assign a person responsible to each problem, including deadlines for results and decisions.'
Een andere noodzaak: “Maak mensen eigenaar van een probleem. Zeker in omgevingen met complexe ontwikkelingen, waar nog niet eens een begin van een oplossing is en nieuwe uitvindingen nodig zijn, voelt iedereen zich de meester van zijn idee, met zijn persoonlijke inzicht. Wij Nederlanders zijn er ook heel goed in om elke gelegenheid aan te grijpen om hier heel breed over te praten. Maar je moet gewoon de volgende stap zetten. Dat is het enige waar een project baat bij heeft. Dus als je met dertig mensen in een kamer zit en er komen problemen, dan moet de projectmanager, de crisismanager of de systeemarchitect voor elk probleem een verantwoordelijke aanwijzen. Dit geldt ook voor deadlines voor resultaten en beslissingen.”
Volgens Engels zit het wel degelijk in de cultuur van ASML, maar is het daar op een gegeven moment uit de hand gelopen. “Ze stelden overal een eigenaar voor aan en noemden hem projectleider. McKinsey heeft ooit een analyse gedaan bij ASML van projectleiders en projectgroottes. Daaruit bleek dat er gemiddeld 1,2 mensen op elk project zaten, inclusief de projectleider! Dan loop je het risico dat deze eigenaren, deze projectleiders, gaan concurreren om de beschikbare middelen en het onderliggende probleem naar de achtergrond verdwijnt.”
Engels heeft uitgebreide ervaring als projectmanager, systeemarchitect en crisismanager in de hightechindustrie.
De productmanager definieert het product dat goed zal presteren in de markt. Hij bepaalt het beschikbare budget – vaak te weinig – en onderhandelt met de systeemarchitect of het voor dat geld gemaakt kan worden. Engels: “Het is een evenwichtsoefening. Bij volwassen producten werkt het anders, maar bij een eerste ontwikkeling wil je zo snel mogelijk een proof of concept. Of in ieder geval een bevestiging dat je ideeën kloppen en dat je op de goede weg bent.”
In hoeverre moet de systeemarchitect, net als de productmanager, rechtstreeks met klanten praten?
“In hightech staat dat buiten kijf. Daar komen de productmanager en de systeemarchitect samen. Ze moeten wel. De eerste is meer gericht op de business, de tweede kijkt naar de technologie en of het haalbaar is. Het zijn twee kanten van dezelfde medaille. Deze samenwerking tussen de productmanager en de systeemarchitect wordt steeds gebruikelijker. Toch zie ik nog steeds systeemarchitecten die de noodzakelijke afstemming met de projectmanager of het operationeel management bagatelliseren. Je loopt dan het risico dat een oplossing die perfect aan de behoeften van de markt voldoet, uiteindelijk toch mislukt in de realisatiefase.”
'The project manager sets hard deadlines and a system architect has to work with them.'
Bij kleinere ontwikkelprojecten, met tien tot twintig ontwikkelaars, kan één persoon de rol van zowel projectmanager als systeemarchitect op zich nemen. Bij grotere projecten, met tientallen of honderden ontwikkelaars en enkele tientallen leveranciers, is het belangrijk om je op te splitsen. Engels heeft ervaring in beide rollen. “De projectmanager stelt harde deadlines en een systeemarchitect moet daarmee werken.”
“De projectmanager moet bepalen welke problemen de systeemarchitect nog moet oplossen en met wie. Samen bespreek je de ins en outs, weeg je de voor- en nadelen af, bepaal je de belangrijkste parameters en dan belt de projectmanager de systeemarchitect: eind volgende week nemen we een beslissing! Het draait allemaal om richting, het bedenken van een format waarbij deskundige mensen betrokken zijn om tot gekwantificeerde uitspraken te komen waarmee je echt een beoordeling kunt maken.”
Een systeemarchitect heeft een grote invloed op productontwikkeling, maar heeft vaak een minder zichtbare rol.
“Hij is een ervaren technicus, maar zijn waarde ligt vooral in zijn kijk op de business. Negenennegentig van de honderd keer kent de systeemarchitect de markt waarin zijn product of systeem gaat landen. Dat is nodig om de markt- en producteisen te vertalen naar de systeemeisen en vervolgens het ontwerp te schetsen.”
Er is heel wat ervaring voor nodig om dat niveau te bereiken. Tegelijkertijd merkt Engels op dat het concept van een systeemarchitect aan inflatie onderhevig is. “Tegenwoordig zijn er overal architecten. Een software architect is meestal een senior software ontwikkelaar, een requirements engineer of iemand die verantwoordelijk is voor engineering. Ik wil niets ten nadele van zo’n lead engineer zeggen. Toch is het verschil met de systeemarchitect dat de laatste de business moet kennen, moet begrijpen hoe waarde wordt gegenereerd en dus moet begrijpen waarom het binnen een bepaalde hoeveelheid tijd en geld moet gebeuren.”
“Dit is ook het geval in de bouw. Je architect vraagt je wat je met je toekomstige huis gaat doen en past zijn ontwerp daarop aan. Ga je veel koken of wil je vooral wijn drinken? Daarom doet Van den Brink het zo goed bij ASML. Hij gaat naar klanten toe en legt uit wat voor lithosystemen ze nodig hebben. Hij kent de markt als geen ander. Sterker nog, hij dicteert de markt. Dat betekent dat hij als geen ander de doelen en de timing van chipfabrikanten begrijpt, inclusief hoe hun productieprocessen eruit zien. Als ze het hebben over kritieke afmetingen en overlay, kan hij uitleggen dat zijn machine dat kan en ook onderbouwen waarom.”
Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.
Recommendation by former participants
By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.5 out of 10.
Het gemeenschappelijke thema van de afgelopen weken, toen ik met steeds meer mensen in bedrijven begon te praten, is de moeilijkheid om digitale transformaties te realiseren. Toegegeven, ik werk met velen die verwachten of het op zich hebben genomen om de digitale transformatie van hun organisatie aan te sturen, maar ik denk dat de uitdaging wijdverspreid is.
Vooral in de embedded systems industrie is er een grote groep mensen die oorspronkelijk uit de mechanische of elektronica wereld komen en niet verder kunnen kijken dan de grenzen van hun technologisch perspectief. Met een digitaliserende business verdwijnen mechanica en elektronica niet – we hebben nog steeds een chassis en een computerplatform nodig. Het belangrijkste verschil is dat deze technologieën veranderen van differentiërend naar standaard (zie afbeelding). Dit zorgt voor een verschuiving in perspectief, omdat je innovatie stimuleert als iets onderscheidend is en je kijkt naar het minimaliseren van kosten als iets basisproduct is. Als de kostbare motor, het remsysteem of de aandrijfketen plotseling geoptimaliseerd moet worden voor kosten in plaats van innovatie, dan verzet iedereen die met die technologie werkt zich plotseling tegen verandering. Maar feit is dat in vrijwel elke industrie de differentiatie grotendeels wordt gegenereerd door digitale technologieën, dat wil zeggen software, data en AI.
Differentiërende versus standaard technologieën
We zien ook een verschuiving in het bedrijfsmodel. In industrieën die gedomineerd worden door ‘atomen’ is het primaire bedrijfsmodel meestal transactioneel. Je koopt een doos, gebruikt wat er in de doos zit tot hij oud is en dan koop je een nieuwe doos. Industrieën die zich voornamelijk richten op ‘bits’ hebben de neiging om continue bedrijfsmodellen te gebruiken, zoals abonnements- en servicemodellen. In deze sectoren verwachten klanten dat het aanbod dat ze gebruiken steeds beter wordt. Deze verschuiving lijkt misschien triviaal, maar heeft enorme gevolgen voor de architectuur van je producten, de manier waarop R&D wordt uitgevoerd, hoe je je klanten ondersteunt en zelfs het financiële model van het bedrijf.
Bij digitale transformaties zijn er volgens mij minstens zes gedragingen die kunnen worden geïdentificeerd. Ten eerste, het “het is niet mijn probleem” syndroom. Hierbij denkt de patiënt dat digitalisering te maken heeft met gegevens die heen en weer worden geschud tussen dozen die buiten zijn of haar verantwoordelijkheidsgebied vallen. Omdat het buiten zijn of haar bereik ligt, is het geen probleem waar hij of zij zich zorgen over hoeft te maken.
De tweede uitdaging is het “te ingewikkelde” geval. Ik las onlangs over een onderzoek waarbij mensen werd aangeboden om op een stoel te gaan zitten en na te denken zonder afleiding (zoals hun mobiele telefoon) of lichte elektrische schokken te krijgen terwijl ze zichzelf mochten afleiden met een app naar keuze. Interessant genoeg gaf een grote meerderheid de voorkeur aan elektrische schokken boven ‘gedwongen’ worden om na te denken. Digitale transformatie vertegenwoordigt een fundamentele paradigmaverschuiving en er is een aanzienlijke groep mensen in bedrijven die gewoon niet de moeite kunnen nemen om logisch na te denken over de gevolgen hiervan.
Zelfs als individuen en teams datagedreven praktijken accepteren, is een interessante observatie die we onlangs bevestigd kregen in verschillende bedrijven dat, hoewel veel organisaties KPI’s op topniveau hebben en veel teams lokale KPI’s hebben, er geen echt verband is tussen de twee. Het gevolg is lokale optimalisatie op basis van team meetwaarden, omdat er geen overeengekomen manier is om lokale en globale KPI’s met elkaar te verbinden. Omdat lokale KPI’s meestal op de korte termijn gericht zijn en gebaseerd zijn op de huidige, traditionele business, vertragen of stoppen ze elke digitale transformatie.
Een gevolg hiervan is de uitdaging van de “lokale verloedering van de globale strategie”. Aangezien de link tussen de bedrijfsstrategie en de acties van het team op zijn best zwak is, zullen teamleden een retoriek ontwikkelen over hoe wat ze vandaag doen eigenlijk de bedrijfsstrategie ondersteunt. Elke overduidelijke mismatch wordt dan wegverklaard door te verwijzen naar de lokale en kortetermijnuitdagingen die eerst overwonnen moeten worden.
Het vijfde gedrag dat ik veel tegenkom is het “het is te vroeg” argument. Hier beweert de hoofdpersoon het eens te zijn met alle punten die naar voren zijn gebracht met betrekking tot de gevolgen van digitalisering, maar in dezelfde zin beweert hij dat deze gevolgen zich pas jaren later zullen realiseren. Daarom is het te vroeg om veranderingen door te voeren.
'Customers won’t ask but simply vote with their feet'
Het laatste excuus dat bijna voortdurend wordt gebruikt is dat “klanten er niet om vragen”. Dit lijkt een redelijk argument tot je je realiseert dat alle bedrijven die wachtten tot klanten hen vroegen om nieuwe functionaliteit, bedrijfsmodellen of technologieën failliet zijn gegaan omdat ze werden verstoord door meer verlichte concurrenten of nieuwkomers. Klanten gaan gewoon ergens anders heen als je hun behoeften niet hebt voorspeld. Ze vragen het niet, maar stemmen gewoon met hun voeten.
Concluderend is de realisatie van digitale transformatie in veel bedrijven een langzame, brute, zware strijd die de voorstanders gefrustreerd, moe en getekend achterlaat. Ik heb zes typische gedragingen van zogenaamde “weigeraars” beschreven waar je je bewust van moet zijn als je enige hoop wilt hebben om deze weerstand te overwinnen. De digitale transformatie is reëel, maar veel gevestigde bedrijven gaan te langzaam om ontwrichting te voorkomen.
In de huidige hightechomgeving willen bedrijven van alle groottes voorop blijven lopen op het gebied van innovatie. Volgens teamleiders Martin Langkamp en Martijn Bouwhuis van het in Almelo gevestigde IMS is de vergelijking eenvoudig. Het komt neer op een paar sleutelfactoren: de werknemers geïnteresseerd houden, de werkplek licht houden en focussen op persoonlijke ontwikkeling door middel van training.
Nederlandse innovatie in de hightechsector komt van bedrijven van alle groottes. Grote namen als ASML en Philips worden wereldwijd erkend, maar er zijn ook verschillende kleine en middelgrote ondernemingen (MKB) in Nederland die een grote rol spelen in de wereldwijde hightech. Neem bijvoorbeeld IMS in Almelo. IMS bestaat iets meer dan 20 jaar en opende zijn deuren in 1999 nadat het was voortgekomen uit Texas Instruments via een management buy-out.
Nu, in 2020, heeft de automatiserings- en technologie-expert meer dan 750 productielijnen geleverd met de nadruk op medische apparatuur, slimme apparaten en de auto-industrie. “We zijn erg gegroeid sinds de begindagen. Nu zien we het als onze rol om onze wereldwijde klanten te helpen hun productiedoelen te realiseren”, legt Martin Langkamp, technisch verkoopcoördinator bij IMS, uit. “Dat doen we door onze innovatieve machines over de hele wereld te leveren, die uitblinken in de massaproductie van kleine, nauwkeurige en soms extreem complexe producten.”
Karakter
Hoewel het wereldwijde klantenbestand van IMS zeker groot is, heeft het bedrijf zelf een relatief kleine voetafdruk – het heeft meer dan 120 mensen in dienst op de locaties in Almelo en Groningen in Nederland. Ondanks zijn kleine omvang heeft het een grote invloed op consumentenelektronica. Op dit moment is de high-tech machinebouwer actief in het leveren van machines die gebruikt worden in het assemblageproces voor de smart device en automotive sectoren, naast de volgende generatie koplampen en sensoren voor auto’s.
“Het karakter van IMS is dat we altijd gericht zijn op innovatie, niet alleen lokaal, maar wereldwijd,” benadrukt Langkamp. “Dat betekent dat we veel internationale projecten doen, wat onze ingenieurs spannende mogelijkheden biedt om te reizen, te leren en kennis te delen. Dat maakt deel uit van ons DNA.”
'We use education-based developmental plans in our evaluation process, to help people and the company meet our goals.'
Een ander speerpunt in het karakter van IMS is de focus op de persoonlijke ontwikkeling van haar werknemers. “Een van onze belangrijkste aandachtspunten is permanente educatie voor onze werknemers. We vinden dat trainingen, workshops en conferenties een geweldige manier zijn voor onze technici om zich zowel persoonlijk als professioneel te ontwikkelen,” zegt Langkamp. “Als we naar de toekomst kijken en blijven innoveren, kunnen de noodzakelijke competenties van een functie zelfs uitbreiden en kunnen de technici naar specifieke cursussen worden geleid om hun vaardigheden te versterken. We gebruiken ontwikkelingsplannen op basis van opleiding in ons evaluatieproces om mensen en het bedrijf te helpen onze doelen te bereiken.”
Modulariteit
Onlangs vond IMS een gouden kans om gebruik te maken van training. IMS wilde blijven groeien en een voortrekkersrol blijven spelen op het gebied van de productie van complexe onderdelen. Daarom nam het bedrijf een nieuwe rol op zich voor zijn klanten, door hen te helpen bij het ontwerp van productiemachines door machines in serie aan te bieden in plaats van eenmalig.
“Jarenlang heeft R&D meer reactief aan ontwikkeling gedaan, door oplossingen te vinden voor de klanten wanneer die zich voordeden,” herinnert IMS R&D teamleider Martijn Bouwhuis zich. “Meer recent zijn we echter nieuwe methoden gaan gebruiken om proactiever te worden in het proces en hebben we onze inspanningen gericht op het maken van gestandaardiseerde producten die op maat gemaakt kunnen worden voor onze individuele klanten.”
Om deze gestandaardiseerde producten te krijgen, besloot IMS dat modulair denken de beste manier was om de nieuwe doelen te bereiken en het begon met het leggen van de basis om het personeel op één lijn te krijgen met het idee. Tijdens de Bits&Chips System Architecting Conference ontdekte het team echter dat hun modulaire aanpak perfect aansluit bij de principes van systeemarchitectuur. Langkamp: “We waren al een paar jaar bezig met het aanpassen van onze processen, maar we waren op zoek naar een betere structuur met meer continuïteit binnen het hele bedrijf.”
Volgens Martin Langkamp, coördinator technische verkoop, is een van de belangrijkste aandachtspunten van IMS de permanente educatie van onze werknemers. Krediet: Fotowerkt.nl
'It was time to update and professionalize our working methods.'
Bouwhuis: “Terwijl we onderzochten hoe we het beste verder konden gaan, ontdekten we dat we ons in het ontwerpproces vaak richtten op subsystemen omdat daar de waarde werd toegevoegd. Op de een of andere manier vergaten we te kijken vanuit systeemniveau. Maar nu de complexiteit van de onderdelen die onze machines maken blijft exploderen, is het duidelijk dat software-engineering belangrijker dan ooit is geworden en dat het tijd was om onze werkmethoden bij te werken en te professionaliseren.”
In plaats van een paar teamleden naar een relevante training te sturen, nam IMS contact op met High Tech Institute om een op maat gemaakte in-company editie van de System Architecting training te ontwikkelen, waardoor het in Almelo gevestigde bedrijf een brede en diverse groep van zijn team kon laten deelnemen. “Het is belangrijk in onze transitie om samenhang te creëren tussen alle verschillende disciplines en afdelingen,” zegt Langkamp. “Van mechanische tot elektrische en software engineers tot het verkoopteam, het doel was om iedereen op één lijn te krijgen, denkend op systeemniveau.”
“We hebben voor High Tech Institute gekozen vanwege de kracht van de docenten. Hun kennis en expertise sloot precies aan bij onze behoeften,” benadrukt Bouwhuis. “Wat we het meest waardeerden was dat de trainers manieren vonden om discussies op gang te brengen, waardoor onze groep van ongeveer 12 cursisten echt deelnam. Deze interactie tussen het team en de instructeurs, allemaal met verschillende perspectieven, geeft de training echt veel meerwaarde.”
“Deze interactie tussen het team en de instructeurs vergroot de training echt met veel toegevoegde waarde,” zegt IMS R&D teamleider Martijn Bouwhuis. Credit: Fotowerkt.nl
Maakt IMS gebruik van opleiding om haar bekwame ingenieurs aan te trekken of te behouden? Is het moeilijk om te concurreren met grotere bedrijven op hightechgebied?
“Ja en nee. Ja, opleidings- en scholingsmogelijkheden zijn een geweldig middel om onze ingenieurs aan te trekken en te behouden. Maar wat betreft het concurreren of het verliezen van onze geschoolde werknemers aan de grotere bedrijven, nee, dat is niet het geval. Sterker nog, ik denk dat de omvang van IMS, de reikwijdte van ons werk en onze aanpak iets is wat mensen naar ons toe trekt en ervoor zorgt dat ze willen blijven,” illustreert Langkamp. “In de regio Brabant is het vrij gebruikelijk dat ingenieurs van de ene plek naar de andere stuiteren, maar hier bij IMS en in de regio Twente in het algemeen is dat gewoon niet zo gebruikelijk.”
'Sometimes we refer to IMS as a high-tech playground for engineers.'
“Omdat we klein zijn, kunnen we het op de werkvloer luchtig en leuk houden. Natuurlijk werken we uiterst professioneel met onze klanten. Maar de mensen hier zijn meer dan een nummer en het omarmen van die mentaliteit betekent dat we als een familie kunnen opereren en plezier hebben,” voegt Bouwhuis gekscherend toe: “Soms noemen we IMS een high-tech speeltuin voor ingenieurs.”
“Ja, precies. Vanwege onze wortels in Texas Instruments grappen we wel eens dat mensen hier al 40 jaar werken, maar het bedrijf is pas 20 jaar oud,” lacht Langkamp. “Door onze mensen geïnteresseerd te houden met spannende projecten, een luchtige informele werkplek
en een focus op onze werknemers en hun ontwikkeling, heeft IMS een sterke positie om te blijven innoveren.”
Foto credit: Fotowerkt.nl
Dit artikel is geschreven door Collin Arocho, tech redacteur van Bits&Chips.
Recommendation by former participants
By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.5 out of 10.
Ik werk met veel collega’s uit verschillende culturen. De meesten van hen zijn niet gewend aan hoe we elkaar in Nederland feedback geven. Toch is het nodig om aan te geven wat iemand kan of moet verbeteren als iets niet goed gaat. Hoe pak ik dat aan?
De communicatietrainer antwoordt:
Feedback gaat over het overbrengen van een boodschap aan de ander zonder de relatie te verstoren. De directe ‘Nederlandse’ manier werkt misschien niet goed als je werkt met culturen die hier niet aan gewend zijn. De volgende tien punten zullen je helpen.
1) Om te beginnen is het altijd goed om bij jezelf na te gaan of je de feedback geeft om de ander te helpen en de situatie te verbeteren, en niet alleen om je autoriteit te bevestigen of iemand een schop onder zijn kont te geven.
2) Het is belangrijk om te investeren in het opbouwen van een vertrouwensrelatie met je medewerkers voordat je ze feedback geeft. De meest waardevolle feedback heb je waarschijnlijk zelf gekregen van mensen die dicht bij je staan. Het opbouwen van relaties gebeurt in veel landen vaak buiten werktijd. Het kan dus helpen om hier regelmatig aandacht aan te besteden.
3) In Aziatische en Arabische landen is het belangrijk om gezichtsverlies te vermijden. Het kan daarom nuttig zijn om te beginnen met subtielere feedback om dingen gedaan te krijgen. Stel dat je ziet dat één onderdeel in een rapport fouten bevat. Noem dan hoe goed een deel is. De ander zal oppikken dat het andere deel nog aandacht nodig heeft. Als je zoiets tegen een Amerikaan of Nederlander zegt, zal hij je feedback niet begrijpen en liever hebben dat je direct zegt wat er nog fout is, want dat gaat sneller. Begin eerst subtiel; als je boodschap dan niet wordt opgepikt, kun je altijd directer worden. Terugkrabbelen als de kat al uit de zak is, is moeilijker.
'Start subtly, you can always be more direct'
4) Richt je feedback op gedragingen en kenmerken van het werk in plaats van te oordelen. In plaats van “Je werk is slordig” zeg je “Deze presentatie heeft drie fouten”. In plaats van “Dit rapport is onvolledig” kun je zeggen “Ik zou graag een extra tabel zien”.
5) Om gezichtsverlies te voorkomen, kun je ook de passieve spreekmodus gebruiken in plaats van de actieve. Dit klinkt als het volgende: ”De balie was vanmorgen een kwartier onbezet” in plaats van ”U was te laat”. Dan vermijd je persoonlijke beschuldigingen. De aangesprokene kan uit de opmerking afleiden dat het zijn verantwoordelijkheid was om op tijd te zijn en dat de afwezigheid werd opgemerkt. In veel talen is dit passieve taalgebruik al ingebakken. Als je dit niet gewend bent, kan het moeite kosten.
6) Zeg wat je wel wilt in plaats van wat je niet wilt. Stop hiermee” klinkt als een standje, of je nu 2 of 52 bent. Dus, “Probeer het op deze manier te doen” in plaats van “Dit is niet de manier”.
7) Het hele team aanspreken op bijvoorbeeld het naleven van de nieuwe werkregels maakt de druk op het individu minder direct. Collegiale druk kan er dan voor zorgen dat die persoon zich toch aan de regels houdt zonder dat je hem of haar daar rechtstreeks op hoeft aan te spreken.
8) Spreek liever zacht dan hard. Een rustige stem kan een gespannen situatie ontspannen en maakt het makkelijker voor de werknemer om je boodschap te horen.
9) Het is vooral belangrijk om respect te tonen voor de persoon aan wie je feedback geeft. Je kunt dit laten zien door samen tijd door te brengen. Of door de ander om advies te vragen of iemand naar hem of haar toe te sturen voor advies. Ook jezelf betrekken bij de oplossing laat zien dat niemand alle antwoorden alleen heeft en dat je de visie van de ander waardeert. Je zegt bijvoorbeeld “Laten we eens kijken hoe we dit kunnen oplossen”.
10) Geef tot slot complimenten. Je werknemer kan zich ongemakkelijk voelen als er te veel specifieke aandacht is voor zijn persoonlijke prestaties. In dat geval is het beter om met de hele groep uit eten te gaan en iedereen op die manier te belonen. Een compliment kan dan gegeven worden in een één-op-één situatie.
Tijdens een vergadering deze week moest ik denken aan een beroemde uitspraak van Margaret Mead: “Twijfel er nooit aan dat een kleine groep bedachtzame, toegewijde burgers de wereld kan veranderen; sterker nog, het is het enige dat dat ooit heeft gedaan.” De twee senior leiders met wie ik sprak, klaagden over hun R&D-organisatie die op papier alles goed deed vanuit een Agile, data-gedreven perspectief, maar toch eindigde met het bouwen van gigantische, opgeblazen features die pas na vele maanden ontwikkeling werden vrijgegeven.
Dit is natuurlijk een klassiek voorbeeld van feature creep waar veel bedrijven in terecht komen. Toen we onderzochten hoe de situatie zich ontwikkelde, werd duidelijk dat een zeer klein aantal invloedrijke mensen in de R&D-organisatie de anderen ervan had weten te overtuigen dat het aanvankelijke plan om een minimale levensvatbare functie uit te brengen niet mogelijk was, omdat dit boze klanten zou veroorzaken.
Ik wil me niet richten op feature creep, maar eerder op de manieren waarop een vocale minderheid in een organisatie, of zelfs in de maatschappij als geheel, een impact kan hebben die de grootte van de groep ver overstijgt. In het algemeen ben ik een groot voorstander van een kleine groep individuen die de leiding neemt om veranderingen binnen een organisatie te initiëren. Zelfs als de senior leiders er prat op gaan dat ze grote veranderingen in hun organisatie leiden, zijn er bijna altijd wel een paar individuen die de verandering al geruime tijd hebben gepromoot en verdedigd voordat het werd opgepikt door het senior management.
Het probleem met “de vocale minderheid”, zoals ik het vaak noem, is dat hun succes vaak meer afhangt van het vermogen om retoriek en debattechnieken te gebruiken dan van de feitelijke, technische aard van de verandering die wordt bepleit. Het gevolg is dat individuen hartstochtelijk kunnen pleiten voor veranderingen die schadelijk zijn voor de organisatie en haar leden. Om de relevantie en geldigheid van de voorgestelde veranderingen te evalueren, pas ik gewoonlijk vier vragen of tactieken toe.
De eerste test waaraan ik een veranderingsvoorstel onderwierp, is het te toetsen aan de fundamentele principes die ik als waar beschouw. Een daarvan is dat snellere feedbackcycli beter zijn dan langzamere. Dit betekent dat pleiten voor het opblazen van een functie en dus het uitstellen van de release, evenals de bijbehorende feedback ingaat tegen het argument om meer in de functie op te nemen. Mijn algemene vuistregel is dat werkitems zo groot moeten zijn dat één team het in één sprint kan voltooien.
De tweede vraag die ik stel is of de voorstander van de verandering een voldoende brede reikwijdte van de impact heeft overwogen. Het is heel gemakkelijk om je bij het voorstellen van een verandering uitsluitend te richten op het onderwerp in kwestie en hoe dat aan te pakken, zonder rekening te houden met de bredere reikwijdte. Het uitbrengen van grotere functionaliteiten kan bijvoorbeeld relevantere functionaliteit bieden aan een grotere groep klanten, maar het kan ook de (gepercipieerde) kwaliteit van het systeem verlagen, omdat het moeilijker is om een groot stuk functionaliteit te testen dan om een klein stukje te testen.
De derde test is het onderzoeken van effecten van de tweede orde. In een beroemd verhaal beval Mao Zedong om alle mussen in China te doden omdat ze zaden aten. Het tweede-orde-effect was een explosie van de sprinkhanenpopulatie, die een hongersnood veroorzaakte met de dood van miljoenen mensen tot gevolg. In software engineering is een bekend geval het stimuleren van software engineers om code uit een gedeelde code bibliotheek te gebruiken om hergebruik van software te vergroten. Dit heeft allerlei interessante effecten veroorzaakt, zoals ingenieurs die eerst hun code inchecken in de gedeelde codebibliotheek en deze vervolgens “hergebruiken” om hun bonus te krijgen. Hoewel het vaak erg moeilijk is om tweede-orde effecten te voorspellen, is het over het algemeen mogelijk om relevante hypotheses te genereren die ofwel getest kunnen worden of waarvoor op zijn minst indirect bewijs verzameld kan worden.
'Complement the beliefs that underlie the reasoning with empirical data'
Het laatste mechanisme dat ik gebruik is om te onderzoeken of het mogelijk is om kleinschalige experimenten uit te voeren die aanvullend bewijs leveren voor de voorgestelde verandering. De uitdaging bij de eerste drie tests/vragen is dat deze gebaseerd zijn op argumenten en redeneringen en niet noodzakelijkerwijs gefundeerd zijn in de empirische werkelijkheid. Het is cruciaal om de overtuigingen die ten grondslag liggen aan de redenering aan te vullen met tastbare, empirische gegevens om het vertrouwen te vergroten dat de verandering het beoogde resultaat zal hebben en ongewenste neveneffecten zal vermijden.
Concluderend, mijn ervaring is dat vrijwel alle veranderingen in organisaties worden geïnitieerd door een “vocale minderheid”. Deze minderheid vertrouwt vaak op retoriek en debattechnieken om invloed te krijgen, in plaats van op de kwaliteit van hun voorstel. Dit vereist dat we allemaal kritisch nadenken over veranderingsvoorstellen. Ik heb vier technieken beschreven die ik gebruik om deze voorstellen te evalueren. In plaats van ons over te geven aan een vorm van kuddementaliteit, is het de verantwoordelijkheid van ieder van ons om onafhankelijk en kritisch te blijven denken, onafhankelijk van groepsdruk. Wees geen schaap!
Deze website maakt gebruik van cookies om te kunnen functioneren. Daarnaast willen we graag uw toestemming om cookies van derde partijen op te nemen. Lees voor meer informatie over onze cookies onze cookieverklaring. ACCEPTER
Privacy- en cookiebeleid
Privacy-overzicht
Deze website maakt gebruik van cookies om uw ervaring tijdens het navigeren door de website te verbeteren. Van deze cookies worden de cookies die zijn gecategoriseerd als noodzakelijk in uw browser opgeslagen, omdat ze essentieel zijn voor het functioneren van de basisfuncties van de website. We gebruiken ook cookies van derden die ons helpen te analyseren en te begrijpen hoe u deze website gebruikt. Deze cookies worden alleen met uw toestemming in uw browser opgeslagen. U hebt ook de mogelijkheid om deze cookies uit te schakelen. Maar het uitschakelen van sommige van deze cookies kan gevolgen hebben voor uw surfervaring.
Noodzakelijke cookies zijn absoluut noodzakelijk voor het goed functioneren van de website. Deze categorie omvat alleen cookies die basisfunctionaliteiten en beveiligingsfuncties van de website garanderen. Deze cookies slaan geen persoonlijke informatie op.
Alle cookies die niet specifiek noodzakelijk zijn voor het functioneren van de website en die specifiek worden gebruikt om persoonlijke gegevens van gebruikers te verzamelen via analytics, advertenties en andere ingesloten inhoud, worden aangeduid als niet-noodzakelijke cookies. Het is verplicht om toestemming van de gebruiker te krijgen voordat u deze cookies op uw website plaatst.
