Design Thinking en het nieuwe probleemoplossen

 
28 juni 2017

Tekst Marco Gianotten

Eind jaren 90 introduceerde het U.S. Army War College het nieuwe competentieraamwerk VUCA . Dit acroniem staat voor volatility, uncertainty, complexity en ambiguity. Het beheersen van militaire conflicten in een wereld van permanente dynamiek en fluïde vijandsbeelden vergt andere leiderschapskwaliteiten dan het top-down ontwikkelen van een strategie en de uitvoering ervan delegeren. In het leiderschap dat officieren nu wordt aangeleerd, is veel meer aandacht voor het motiveren van mensen, het creëren van consensus, het faciliteren van zelfsturende teams en het organiseren van adaptief vermogen.

Net als voor strijdkrachten geldt ook voor bedrijven en overheden dat hun wereld niet meer zo voorspelbaar en planbaar is als voorheen. Wendbaarheid, klantgerichtheid en constante vernieuwing van waardenproposities vormen het antwoord op veel nieuwe vraagstukken. Daarbij zoeken veel bedrijven naar betekenisvolle meerwaarde en naar het oplossen van ‘het probleem achter het probleem’. Innovaties in informatietechnologie scheppen daarvoor nieuwe kansen. Dat stelt bedrijven wel voor een dilemma: willen ze deze kansen kunnen benutten, dan moeten ze op zoek naar een nieuwe organisatievorm. Het ontwerpproces voor de toepassing van IT is namelijk technisch georiënteerd en procesmatig rigide. Voor het automatiseren van bedrijfsprocessen was dit tot voor kort geen probleem. Voor het ontwerpen van nieuwe digitale waardenproposities is die technische en rigide benadering echter niet geschikt. In de nieuwe wereld, waar problemen, vragen en feedback van klanten centraal staan, heb je incrementele en iteratieve ontwerpprocessen nodig die je in staat stellen doorlopend af te stemmen met de eindgebruiker.

Methoden zoals agile en DevOps lenen zich hier uitstekend voor. Maar agile en DevOps zijn niet voldoende om kansen te herkennen en te benutten die bij incrementeel veranderen gemakkelijk over het hoofd worden gezien. Om dubbelzinnige problemen en onverwachte oplossingen te verkennen en uit te werken, biedt design thinking een oplossing. Steeds meer IT-organisaties passen design thinking toe. Dit artikel gaat over de toepassing en bruikbaarheid van dit nieuwe denken en doen.

Welk probleem wil je oplossen?

De bedrijfscultuur, de structuur en de processen vinden hun reflectie in het bestaande IT-landschap van een grote organisatie. Dat landschap is een cumulatie van systemen en technologiegeneraties; daardoor kosten veranderingen veel tijd en relatief veel geld. Om aan de voorkant verandersnelheid te krijgen passen steeds meer ondernemingen agile en DevOps toe. De oude IT-kern wordt als een soort van Tsjernobyl-reactor ‘ingepakt’. Is het afschermen van je oude IT, het outsourcen daarvan en het vervolgens daar bovenop bouwen van je digitale toekomst wel zo’n goed idee? Of zijn er ook andere en betere opties? De uitdagingen waar IT-verantwoordelijken binnen grotere organisaties voor staan, zijn soms moeilijk te ontwarren. De belangen van stakeholders lopen uiteen en de vraagstukken zijn niet altijd helder. Een voorbeeld: een IT-afdeling is verantwoordelijk voor de totale beheerkosten van IT, maar heeft beperkte invloed op de kostendrijvers omdat de business niet bereid is te investeren in nieuwe versies of de modernisering van kernsystemen. De voordelen van uitstel voor de business (namelijk: geen upgradeprojecten) veroorzaken een kostenstijging voor de IT-afdeling (toename supportkosten voor oudere versies omdat deze ‘vervuilkosten’ niet worden doorbelast).

Een ander voorbeeld: bij het migreren naar nieuwe systemen en clouddiensten is een IT-afdeling verantwoordelijk voor de technische realisatie, maar niet voor het aanleren van nieuwe vaardigheden bij eindgebruikers. Dit leidt ertoe dat veel IT-projecten die eindgebruikers raken, op papier prima zijn geslaagd, maar volgens de eindgebruikers slecht zijn opgeleverd. Bij het ontwerp en implementeren van nieuwe applicaties of een nieuwe werkplek gaan sociale, didactische en emotionele ontwerpeisen een steeds grotere rol spelen: eindgebruikers worden niet alleen kritischer over gebruikersgemak, maar ook de functionele eisen worden steeds veelomvattender voor de verschillende doelgroepen aan gebruikers (persona’s). Ook klanten worden IT-stakeholder wanneer klantreizen via portals en apps lopen en waardenproposities steeds verder digitaliseren.

Design thinking maakt problemen en oplossingen vanuit meerdere stakeholders bespreekbaar. In de wereld van productontwikkeling heeft design thinking gezorgd voor het centraal stellen van niet-experts, ofwel gebruikers, in het gehele ontwerpproces. Design was lange tijd het exclusieve terrein van specialisten. Ontwerpers van producten en architecten van gebouwen waren net als kunstenaars ‘verheven’.

Design was het over de schutting gooien van iets nieuws waar de gebruiker maar aan moest wennen. Het beeld over design is echter aan het kantelen. Steve Jobs zei het passend: “Design is niet hoe het eruit ziet, maar hoe het werkt.” Design thinking levert ook een kader voor het oplossen van de vele uitdagingen waarvoor IT binnen grote organisaties staat.

De waarde van divergerend denken

Naar verluidt werd Albert Einstein ooit gevraagd naar wat hem onderscheidt van gewone mensen. Zijn antwoord: “Wanneer iemand gevraagd wordt om een naald in een hooiberg te zoeken, houdt hij doorgaans op wanneer de naald is gevonden. Ik ga verder met zoeken naar nog meer naalden.” Dit is een metafoor voor divergerend denken: je niet beperken tot die ene oplossing. Maar in plaats van deze verbredende stijl van denken, waarbij de uitkomst vooraf niet bekend is, staat in onze cultuur convergerend denken bovenaan qua aanzien. De basis daarvoor is al gelegd in de schoolbankjes, waar we worden getraind in het direct reageren op vragen: geef het juiste antwoord! Convergerend denken is ook de modus operandi in het bedrijfsleven. Ook van een manager wordt verwacht dat hij direct een antwoord heeft, met als doel: snel komen tot actiegerichte besluiten. Dit leidt tot besluitvormend denken, waarbij de kortste verbinding van ‘probleem naar vraag naar antwoord naar oplossing’ wordt gezocht: het antwoord staat gelijk aan de oplossing. Als problemen meer diffuus van karakter zijn, bestaat de kans dat inzichten en ideeën, die misschien voor een doorbraak hadden kunnen zorgen, worden uitgesloten. Een voorbeeld: om de problemen tussen de frontoffice en de backoffice op te lossen, hebben veel banken een midoffice opgetuigd. Dat leek destijds een goede oplossing, maar na verloop van tijd waren er niet één, maar twee communicatiekloven te overbruggen: tussen back en middle, en tussen middle en front.

We gunnen onszelf maar weinig tijd om vraagstukken van meerdere invalshoeken en vanuit meerdere stakeholders te bekijken en bespreekbaar te maken. Zowel problemen als oplossingen hoeven niet altijd direct aan elkaar te worden gekoppeld. Bij design thinking worden problemen en oplossingen apart behandeld en divergerend beschreven (het een sluit het ander niet uit). Pas daarna volgt convergentie – het naar elkaar toebrengen van probleem en oplossing. Een illustratief voorbeeld is fietsenfabrikant Van Moof die zijn (e-)bikes naar klanten over de gehele wereld verstuurt. Tijdens dit transport liepen fietsen regelmatig schade op, met als gevolg retourzendingen op kosten van Van Moof. De kortste route van probleem naar oplossing zou zijn: meer verpakkingsmateriaal, een extra verstevigde fiets of het straffen van de transporteurs bij retourzendingen. Het bedrijf kwam echter met een heel andere oplossing: het afdrukken van een afbeelding van een flatscreen-televisie op de zijkant van de doos, inclusief de opdruk ‘this side up’ en een ‘breekbaar’- symbool. Het resultaat: 75 procent minder schadegevallen tijdens het transport.

Als problemen meer diffuus van karakter zijn, bestaat de kans dat inzichten en ideeën worden uitgesloten

Problemen oplossen nieuwe stijl

Softwareontwikkeling, IT-projecten en IT-beheer zijn het domein van experts. Het technisch perspectief is daarbij dominant. Ook het begrip design heeft een technische connotatie – denk aan software design – of wordt geassocieerd met het ontwerpen van de front-end voor websites en mobiele apps. Om het eindgebruikersperspectief een plek te geven in de ontwikkeling van applicaties zijn in het IT-functiehuis functies gecreëerd voor het ontwikkelproces van de ‘voorkant’ van bedrijven, zoals user-interface designer en interaction designer. Echter, dit betekent niet dat er binnen het ontwikkelteam als geheel een gemeenschappelijk begrip bestaat over de eindgebruiker. Opgeleverde systemen kunnen dus nog steeds gebruiksonvriendelijk zijn, of vereisen veel aanleertijd. Dat kan gelden voor klanten die websites, mobiele apps en webapplicaties gebruiken, maar ook voor werknemers die eindgebruiker zijn: wie Lync gewend is, zit niet te wachten op Skype for Business. De risico’s van nieuwe tools die gepusht worden, zijn verlies van gebruikersproductiviteit, lange leercurves of zelfs afwijzing waarbij gebruikers het systeem negeren en alternatieven blijven gebruiken. Het centraal stellen van gebruikers is geen fase in het ontwikkelproces – zoals het ontwerp van een user interface – maar komt neer op het constant meewegen van de positie, belangen en feedback van eindgebruikers. Dat kan bijzondere resultaten opleveren. Bij een zorginstelling bijvoorbeeld keken veel eindgebruikers huizenhoog op tegen de nieuwe mobiele werkplek met selfservice apps. Het idee achter het nieuwe werken was dat zorgverleners meer zelf konden doen op hun tablet. Echter, gebruikers waren digitaal niet vaardig en bang voor ‘al die computers’. Verplichte cursussen bleken niet de oplossing, wel een besloten YouTube-kanaal waarbij de kinderen van IT-medewerkers zelfgemaakte instructiefilmpjes posten.

Bij een bank lukte het maar niet om het online selfservice portal te ‘verkopen’ aan eindgebruikers. Die grepen liever naar de vertrouwde telefoon. Pas na het invoeren van gamification op de servicedesk (waarbij agents werden beloond om bellers te motiveren en te assisteren bij het gebruik van het portal) werd selfservice populair.

Het goed laten landen van oplossingen zoals servicekanalen, online werkplekken en mobiele applicaties is pas goed mogelijk als je de gebruikers vanaf het prilste begin meeneemt in het analyseren van problemen en definiëren van oplossingen.

Oplossen van diffuse problemen

Het doel van design thinking is om concrete oplossingen te ontwikkelen voor complexe problemen, waarbij de mens centraal staat. Design thinking kent drie pijlers:

1. Verkennen van de problem space. Bij het onderzoeken van problemen gaat het om het verkrijgen van een intuïtief begrip van de problemen die de diverse stakeholders (zoals eindgebruikers, ontwikkelaars beheerders en helpdeskmedewerkers, dan wel klanten, ketenpartners en de klant van de klant) ervaren bij interne dan wel externe systemen. In plaats van je te beperken tot hypotheses of theorieën over ‘het probleem’, is er ruimte om het probleem te exploreren zonder het vraagstuk direct op te delen in behapbare stukken. Use cases ofwel hoe een gebruiker een handeling ervaart, zijn zeer bruikbaar om problemen te bespreken. Bijvoorbeeld de emotionele stress bij gebruik van nieuwe applicaties en andere ‘eerste-keermomenten’.

2. Verkennen van de solution space. Bij het formuleren van mogelijke oplossingen is het de bedoeling om een groot aantal alternatieve ideeën te ontwikkelen. Deze kunnen vervolgens stapsgewijs verder worden uitgewerkt met behulp van bijvoorbeeld visualisatie en/of prototypes. Verschillende oplossingsrichtingen kunnen parallel ontstaan; het is belangrijk om zoveel mogelijk oplossingen te bedenken – zonder daarover direct waardeoordelen uit te spreken en aan te sturen op een gewenste oplossing.

3. Iteratieve afstemming van beide ‘spaces’. Door het representeren van de ideeën en concepten in bijzijn van de gebruikers, eindklanten, experts, opdrachtgevers en het projectteam ontstaat een setting voor besluitvorming waarbij de problemen van klanten en/of gebruikers niet uit het oog worden verloren. Bij IT-projecten zoals softwareontwikkeling of uitbesteding gaan de belangen van de eindgebruikers vaak te snel verloren door de sterke focus op de technische en bedrijfsmatige businesscase. Naast feasibility (technische haalbaarheid) en viability (economisch nut) wordt desirability (wenselijkheid vanuit de gebruiker) de derde voorwaarde voor succesvolle oplossingen.

Design thinking vult DevOps aan

Bij DevOps is de requirements-analyse niet slechts een processtap, maar een parallel proces gedurende het gehele ontwikkeltraject. DevOps kent veel gelijkenis met design thinking, omdat er wordt gewerkt met uitgangspunten zoals user-centricity, interactief leren en multidisciplinair werken. Maar er zijn ook belangrijke verschillen. Kenmerkend voor DevOps is de incrementele verfijning: voor elk nieuw probleem volgt een aanpassing in de volgende release, totdat het is probleem is opgelost. Het probleem wordt klein genoeg gemaakt om ermee aan de slag te kunnen gaan. Deze vorm van beperking staat haaks op design thinking, waarbij problemen en meerdere oplossingen juist naast elkaar kunnen bestaan. Daardoor zijn er ook grote doorbraken mogelijk, iets dat met DevOps moeilijker is te realiseren. Leren omdenken is de kern van design thinking. Design thinking is daarom ook uitstekend toepasbaar op andere gebieden dan softwareontwikkeling: denk aan het vereenvoudigen van SLA ’s (Service Level Agreements), het positief versterken van gewenst gedrag bij multivendor outsourcing, het realiseren van contracten die kannibalisatie van omzet belonen wanneer leveranciers disruptie op zichzelf toepassen, of het verbeteren van digitale skills bij eindgebruikers. Om impactvolle doorbraken in IT te realiseren is design thinking een goede aanpak; de brede blik en de actieve betrokkenheid van de belangrijkste stakeholders dragen sterk bij aan succesvolle verandering en vernieuwing.

Outsourcing en design thinking

Wat is het probleem dat je wilt oplossen met outsourcing? ‘Te hoge kosten’ is het meest gegeven antwoord. Maar waarom zijn de kosten te hoog? Op welke kostendrijvers is er onvoldoende grip? Zijn de directe uitgaven aan IT het probleem of is er eerder een gebrek aan wendbaarheid waardoor veranderen te veel tijd en geld kost? Problemen in zakelijke IT worden steeds diffuser en dat geldt ook in toenemende mate voor het instrument outsourcing. Omdat voor veel ondernemingen nieuwe technologie dragend wordt voor hun waardenproposities en de klantbeleving, is IT meer dan een stafafdeling die interne processen automatiseert en systemen beheert of laat beheren. Verandersnelheid en de adoptie van innovaties wordt prioriteit. Het activeren van kennis en kunde van een derde partij om te transformeren, wordt belangrijker dan het vinden van een partij die goedkoop op de winkel kan passen en daarmee de kosten substantieel verlaagt. In het verleden hebben veel uitbesteders, in ruil voor een instant besparing, innovatie op slot gezet en zaten zij aan het eind van de contractperiode met een kaalgevreten en verouderd IT-landschap waardoor ze nieuwe kansen hebben gemist.

Er kan steeds meer in IT: sneller en betrouwbaarder code ontwikkelen en stabiel in productie nemen; flexibel integreren van systemen; zonder kapitaalinvesteringen snel opschalen van capaciteit of nieuwe toepassingen iteratief prototypen. Dit vergt een dynamische samenwerking en geen klassiek uitbestedingscontract waar alles op slot staat in een poging de serviceprovider direct en concreet aan te sturen. Tussen detachering en volledige uitbesteding van je bestaande IT-landschap, met mens-volgt werk, ligt een wereld van nieuwe mogelijkheden. Het begint met de vraag: welk probleem wil je oplossen? Met de inzet van design thinking leg je de basis voor het omdenken in outsourcing. Het laatste wat je anno nu wilt is een traditionele aanbesteding waarmee je een schijnbare instant besparing uitruilt tegen het verlies van wendbaarheid en het missen van kansen. Design thinking kan helpen om jezelf te dwingen om het bredere kader te zien en niet te gaan voor een oplossing die in werkelijkheid een schijnverbetering is. De Duitsers hebben hiervoor een mooi woord: Verschlimmbesserung, verbeteren wat leidt tot verslechteren. Dit voorkomen is de directe waarde van een design thinking sessie over je sourcingstrategie.