Waarom is het gevaarlijk om een oplossing te kiezen voordat je het probleem begrijpt?

Een oplossing kiezen voordat je het probleem begrijpt, is gevaarlijk omdat je dan investeert in technologie die het verkeerde vraagstuk oplost. De kans op een mislukt project neemt sterk toe, budgetten worden overschreden en de verwachte productiewinst blijft uit. Dit geldt in het bijzonder bij complexe automatiseringsvraagstukken, waar de verleiding groot is om snel naar bekende oplossingen te grijpen. In dit artikel beantwoorden we de meest gestelde vragen rondom probleemanalyse en systems engineering.

Wat gaat er mis als je direct een oplossing kiest?

Als je direct een oplossing kiest zonder het onderliggende probleem te begrijpen, los je het symptoom op in plaats van de oorzaak. Het resultaat is een investering die technisch misschien prima werkt, maar die de productieuitdaging niet wegneemt. In de praktijk leidt dit tot stilstaande machines, onnodige aanpassingen na oplevering en medewerkers die het systeem omzeilen omdat het niet aansluit op hun werkelijkheid.

Neem een productiebedrijf dat klaagt over te veel uitval op een lijn. De eerste reflex is vaak: “We hebben een betere PLC nodig” of “We moeten meer automatiseren.” Maar als de werkelijke oorzaak een inconsistente grondstofkwaliteit of een slecht gekalibreerd meetpunt is, lost nieuwe besturingssoftware niets op. Je hebt dan een dure oplossing gekocht voor het verkeerde probleem.

Binnen systems engineering is dit een klassieke valkuil. De discipline schrijft voor dat je eerst het systeem als geheel begrijpt, inclusief alle interacties en randvoorwaarden, voordat je technische keuzes maakt. Wie die stap overslaat, bouwt op drijfzand.

Waarom is een goede probleemanalyse zo moeilijk in de praktijk?

Een grondige probleemanalyse is moeilijk in de praktijk omdat de druk om snel te handelen groot is en omdat het echte probleem zelden duidelijk aan de oppervlakte ligt. Productiemanagers worden afgerekend op output en uptime, niet op de tijd die ze nemen om een vraagstuk grondig te doordenken. Dat maakt analyse voelen als vertraging, terwijl het in werkelijkheid de snelste route naar een werkende oplossing is.

Daar komt bij dat de mensen die het dichtst op het proces zitten, het probleem vaak al als vanzelfsprekend beschouwen. Ze hebben er dagelijks mee te maken en zijn gewend aan bepaalde workarounds. Daardoor worden aannames niet meer uitgesproken en komen cruciale details nooit op tafel.

Ook de organisatiestructuur speelt een rol. Technische kennis zit versnipperd over afdelingen. De operator weet wat er op de vloer misgaat, de engineer kent de machine, de manager ziet de cijfers. Maar niemand heeft het totaalplaatje. Zonder een gestructureerde manier om al die perspectieven samen te brengen, blijft de analyse onvolledig.

Hoe ziet een grondige probleemanalyse er in de praktijk uit?

Een grondige probleemanalyse begint met het stellen van de juiste vragen aan de juiste mensen, gevolgd door een systematische verkenning van het systeem als geheel. Binnen systems engineering betekent dit: eerst het probleem volledig definiëren voordat er ook maar één technische keuze wordt gemaakt. Dat klinkt eenvoudig, maar vergt discipline en structuur.

Stap 1: Breng het systeem in kaart

Begin met een overzicht van het volledige productieproces, niet alleen het onderdeel waar de klacht vandaan komt. Welke stappen zijn er? Waar zitten de interfaces tussen mens, machine en software? Welke variabelen hebben invloed op het eindresultaat? Door het systeem visueel in kaart te brengen, worden afhankelijkheden zichtbaar die anders verborgen blijven.

Stap 2: Onderscheid symptomen van oorzaken

Vraag bij elk gesignaleerd probleem door: is dit een symptoom of een oorzaak? Een machine die te vaak stilvalt, is een symptoom. De oorzaak kan mechanisch, elektrisch, softwarematig of zelfs operationeel zijn. Pas als je de worteloorzaak hebt gevonden, kun je een oplossing ontwerpen die het probleem structureel wegneemt in plaats van tijdelijk maskeert.

Wanneer is het slim om een externe partij bij de analyse te betrekken?

Het is slim om een externe partij bij de analyse te betrekken zodra de interne kennis of capaciteit onvoldoende is om het probleem objectief te doorgronden. Dit is het geval wanneer een vraagstuk meerdere disciplines raakt, wanneer eerdere oplossingen niet het gewenste resultaat hebben opgeleverd, of wanneer de organisatie te dicht op het proces zit om het nog neutraal te beoordelen.

Een onafhankelijk ingenieursbureau brengt twee dingen mee die intern vaak ontbreken: afstand en breedte. Afstand zorgt ervoor dat aannames worden bevraagd die intern als vanzelfsprekend gelden. Breedte betekent dat ervaringen uit andere sectoren en projecten worden ingezet om het probleem vanuit een frisse invalshoek te bekijken.

Wij bij Kruispunt Engineering beginnen elk automatiseringstraject dan ook niet bij de code of de technologie, maar bij het productieprobleem zelf. Door werktuigbouwkunde, elektrotechniek en software onder één dak te combineren, kunnen we het volledige systeem doorgronden zonder afhankelijk te zijn van externe specialisten die elk slechts een stukje van het plaatje zien. Bekijk onze aanpak voor PLC en industriële automatisering voor meer informatie over hoe wij dit in de praktijk brengen.

Wat zijn de signalen dat een project op de verkeerde aannames is gebouwd?

De signalen dat een project op verkeerde aannames is gebouwd, zijn vaak al vroeg zichtbaar, maar worden pas laat herkend. Het meest voorkomende signaal is dat de opgeleverde oplossing technisch werkt, maar het oorspronkelijke probleem niet heeft opgelost. Operators passen hun werkwijze aan om het systeem te omzeilen, of de verwachte efficiëntiewinst blijft volledig uit.

Andere waarschuwingssignalen zijn:

De scope van het project groeit voortdurend omdat steeds meer randvoorwaarden pas tijdens de uitvoering aan het licht komen
Er ontstaan conflicten tussen afdelingen over wat het systeem nu eigenlijk moest doen
De opdrachtgever en de uitvoerende partij spreken over hetzelfde project maar bedoelen duidelijk iets anders
Wijzigingsverzoeken stapelen zich op nog voor de oplevering
Het projectteam werkt aan oplossingen voor problemen die in de originele briefing niet voorkwamen

Al deze signalen wijzen op hetzelfde: de probleemanalyse was onvoldoende. In een goed systems engineering proces worden aannames expliciet gemaakt, gedocumenteerd en gevalideerd voordat de technische uitwerking begint. Zo voorkom je dat een project pas halverwege de uitvoering zijn zwakste punt onthult, op het moment dat bijsturen het duurste is.

Veelgestelde vragen

Hoe lang duurt een goede probleemanalyse gemiddeld voordat je kunt starten met de technische uitwerking?

De duur van een probleemanalyse hangt sterk af van de complexiteit van het systeem en de beschikbaarheid van de juiste mensen binnen de organisatie. Voor een gemiddeld automatiseringsvraagstuk in een productieomgeving ligt dit tussen de één en vier weken. Deze investering in tijd verdient zichzelf altijd terug, omdat een goed gedefinieerd probleem de kans op dure wijzigingen en herwerk tijdens de uitvoering drastisch verkleint.

Welke mensen binnen onze organisatie moeten betrokken zijn bij de probleemanalyse?

Een effectieve probleemanalyse vereist input van minimaal drie niveaus: de operator die dagelijks met het systeem werkt, de technisch engineer die de machine en installatie kent, en de manager of proceseigenaar die de bedrijfsdoelstellingen bewaakt. Juist de combinatie van deze perspectieven voorkomt dat er blinde vlekken ontstaan. Wordt één van deze groepen overgeslagen, dan blijft de analyse per definitie onvolledig.

Wat is het verschil tussen een systems engineering aanpak en een traditionele projectaanpak bij automatisering?

Bij een traditionele projectaanpak wordt vaak direct gestart vanuit een technische specificatie of een al gekozen oplossing, waarna de uitvoering wordt ingepland. Systems engineering draait deze volgorde om: eerst wordt het probleem volledig gedefinieerd, inclusief alle randvoorwaarden, interfaces en stakeholderbehoeften, voordat er een technische keuze wordt gemaakt. Dit leidt tot oplossingen die beter aansluiten op de werkelijke behoefte en minder afhankelijk zijn van kostbare aanpassingen achteraf.

Hoe voorkom ik dat aannames tijdens een project onuitgesproken blijven?

De meest effectieve manier is om aannames actief en expliciet te documenteren aan het begin van het traject, bijvoorbeeld in een zogenaamd 'assumptieregister' of als onderdeel van de projectdefinitie. Stel tijdens sessies met stakeholders gerichte vragen zoals: 'Wat nemen we hier als vanzelfsprekend aan?' en 'Wat zou er moeten veranderen om deze aanname ongeldig te maken?' Door aannames zichtbaar te maken, kunnen ze worden gevalideerd voordat ze een risico vormen voor het project.

Kunnen we een probleemanalyse ook intern uitvoeren, of is een externe partij altijd noodzakelijk?

Een interne probleemanalyse is zeker mogelijk, mits de organisatie beschikt over voldoende methodische kennis, multidisciplinaire betrokkenheid en de bereidheid om kritisch naar eigen aannames te kijken. In de praktijk lukt dit het best bij organisaties met ervaring in gestructureerde probleemoplossing, zoals Lean of Six Sigma. Is het vraagstuk echter complex, heeft het meerdere eerdere oplossingen overleefd, of zit de organisatie te dicht op het proces, dan voegt een externe partij aantoonbaar waarde toe door objectiviteit en breedte van ervaring.

Wat doe je als je halverwege een project ontdekt dat de probleemanalyse onvolledig was?

Stop dan zo snel mogelijk met bouwen en investeer eerst in het alsnog correct definiëren van het probleem, ook al voelt dat als verlies van tijd. Doorgaan op een verkeerde basis vergroot de schade alleen maar. Plan een gestructureerde sessie met alle betrokkenen om te achterhalen wat er is gemist, pas de scope en het ontwerp aan op basis van de nieuwe inzichten, en documenteer de gewijzigde aannames zodat het projectteam opnieuw op één lijn zit. Een tijdelijke vertraging is altijd goedkoper dan een volledige herimplementatie na oplevering.

Welke tools of methoden worden het meest gebruikt bij probleemanalyse in een systems engineering context?

Veelgebruikte methoden zijn onder andere de 5x Waarom-analyse voor het blootleggen van worteloorzaken, Functional Analysis voor het in kaart brengen van systeemfuncties en hun onderlinge relaties, en FMEA (Failure Mode and Effects Analysis) voor het identificeren van risico's in het systeem. Visuele hulpmiddelen zoals processtroomdiagrammen en systeemblokschema's helpen om het totaalplaatje inzichtelijk te maken voor alle betrokkenen. De keuze voor een specifieke methode hangt af van de aard van het probleem en de fase waarin het project zich bevindt.