Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Denken in problemen, niet in oplossingen

Afgelopen jaren heb ik me diverse malen bezig mogen houden met toolselectie en implementatietrajecten van tools. Wanneer je ooit bij zo'n traject betrokken bent geweest, herken je het volgende vast wel: de gebruiker weet precies te vertellen wat het tool moet doen, maar als je vraagt waarom dan blijft het of angstvallig stil, of je krijgt een antwoord waarvan je denkt: ja, maar wat is nu je echte probleem?

Een kleine bloemlezing uit antwoorden die ik regelmatig voorbij heb horen komen:

Omdat we het nu ook zo doen.
Wat nog wel eens vergeten wordt is dat de huidige manier van werken een onderliggend doel dient.  Bepaalde dingen waren bijvoorbeeld in het huidige tool niet mogelijk, waardoor er een manier van werken omheen is bedacht om toch het doel te kunnen dienen. Of omdat tools niet onderling konden samenwerken is er een implementatie gedaan die dit wel mogelijk maakte.

Het zou zo maar kunnen dat het nieuwe tool wel ondersteund wat destijds niet kon, of dat deze applicatie wel naadloos integreert met dat andere systeem. Her-implementatie van de huidige manier van werken levert in zo'n geval dus geen winst op, ergo, het nieuwe tool wordt niet optimaal benut waarmee het doel voorbij geschoten wordt.

Zo deden we dat bij mijn vorige werkgever ook.
Bij dit antwoord gaan mijn nekharen altijd een beetje overeind staan. Niet zozeer omdat 'het bij ons beter is dan bij een ander', maar vooral vanwege de naïviteit die soms ten toon gespreid wordt. Het ontwikkelen van een afspraken-app voor het plaatselijke gezondsheidsplein is toch echt wel even iets anders dan beeldverwerkings-software voor een geavanceerde elektronenmicroscoop. De logistieke keten rondom de wafersteppers van een bedrijf als ASML kent heel weer andere uitdagingen als de logistieke keten van bijvoorbeeld bol.com.

Hiermee wil ik overigens niet zeggen dat verschillende sectoren niet van elkaar kunnen leren, maar vanzelfsprekend is het evenmin.

Dit gebruikt iedereen momenteel.
Oké, dus jij rijdt een Volkswagen Golf VII , hebt een Samsung Galaxy S6, bent getrouwd, hebt twee kinderen en een labradoedel als huisdier? Immers, dat zijn de meest voorkomende kenmerken van iemand van jouw leeftijd. Zo'n antwoord doet me altijd een beetje denken aan de vele discussies op deze website. Waarom zou ik overgaan naar byo*, *aaS, de cloud, et cetera, et cetera.

Doorvragen
De grote kunst is om bij dit soort antwoorden door te gaan vragen. Waarom doen jullie dit proces op deze manier, welk probleem probeer je hiermee op te lossen, waarom deden jullie dit bij je vorige werkgever op deze manier, wat kan dat nieuwe tool dan wat het huidige niet kan, en welk probleem lossen we daar mee op?

Veel gebruikers, maar ook de mensen die de toolselecties en implementaties doen, hebben de neiging te denken in oplossingen. Echter, om de goede oplossing te kiezen moet je wel het probleem eerst goed onderkennen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5436502). © Jaarbeurs IT Media.
8

 

Reacties

Zullen we het op "de tool" houden?

Dit is overal het grote probleem: sympthonen beïnvloeden het denken van de meeste mensen.

Ik herken je punten. Men vraagt een vinkje erbij (denken in oplossing), maar als je doorvraagt is het vinkje helemaal niet nodig of is het symptoombestrijding en denkt men niet verder in de keten of ziet men de impact van dat kleine vinkje niet (business rules).

Doorvragen zou inderdaad de standaard tool zijn in de toolbelt van iedere consultant / ontwikkelaar, ofwel root-cause analysis.

@Henri: met je eens dat doorvragen standaard in de toolbelt zou moeten zitten. De root-cause analyse technieken kunnen daar zeker bij helpen, ondanks dat het doel ietwat verschillend is.

Als het middel (tool) een doel is geworden wordt het tijd voor een nieuw middel.

Ook bij ERP pakketselectie zoekt men vaak niet veel meer dan een orderbevestiging , leverbon, factuur, productiebon, inkoopbon als ingave en document, en een boekhouding. Dat zijn dan de business processen? Wat er aan echte 'automatisering' aanwezig is? Overbodig, Iedereen werkt toch graag met Excel? Namen noemen is overbodig meen ik.

Zoals een wijze dame (mijn vrouw) het verwoordt: "De oplossing is het probleem niet!" Anders gezegd, de oplossing zit in een goed begrip van het probleem.

Prachtig thema wat hier op de kaart wordt gezet.

Hoewel denken in problemen beslist een stap in de goede richting is ten opzichte van denken in oplossingen, is het mijns inziens in veel gevallen aan te bevelen nog een volgende stap te zetten, namelijk naar: denken in mogelijkheden.

Probleemdenkers lopen namelijk het gevaar in het verleden te blijven hangen in hun voortdurende vraag naar oorzaken wat de weg afsluit naar het creatief zoeken naar oplossingen.

Met name bij complexe problemen is het zinvoller om de huidige situatie als uitgangspunt te nemen (omdat eenduidige oorzaken toch niet zijn aan te wijzen) en je af te vragen welke mogelijkheden er zijn om in de gewenste situatie te komen (in termen van middelen en doelen).

Toch denk ik dat iedere denkvorm – denken in oplossingen, denken in problemen en denken in mogelijkheden – waardevol is; het is mijns inziens een glijdende schaal van louter consumeren naar (creatief, scheppend) produceren.

Geen enkel mens kan op elk terrein creatief zijn; er is dus helemaal niets mis met denken in oplossingen, zolang dit maar niet (al teveel) door sociale druk of machtsverhoudingen tot stand komt.

Als liefhebber van popmuziek heb ik alle soorten geluidsdragers in huis: LP’s, cassettebandjes, CD’s, minidisc, en nu dus MP3-spelers, en het zijn allemaal middelen die zich als oplossing hebben aangediend en die ik nog steeds als zodanig gebruik. Op dit terrein kan ik mijzelf nauwelijks enige creativiteit toedichten.

Het denken in problemen is zinvol bij veel technische problemen: het vinden van de oorzaak van een storing is vaak ook al de oplossing van het probleem, namelijk het repareren of vervangen van het onderdeel dat de storing veroorzaakt. Dit fenomeen wordt ook wel aangeduid met de formule “specificatie = implementatie” of “de oplossing is het probleem niet”.

Maar denken in problemen is ook zinvol bij de vraag wat de werkelijke situatie is en wat de werkelijke behoeften zijn (in plaats van de behoeften die als oplossingen door de omgeving worden opgedrongen), zoals in dit opiniestuk zeer treffend wordt gesteld. Maar vaak zijn dit soort problemen complex en dan is het zaak om door te schakelen naar: denken in mogelijkheden!

Computable Expert
Pa  Va Ke

Pa Va Ke
Configuration Management / Product Lifecycle Management, -. Expert van Computable voor de topics Development, Beheer en Zorg.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×