Een oplossing kiezen voordat je het probleem begrijpt is gevaarlijk omdat je investeert in iets dat het verkeerde probleem oplost. De technologie werkt misschien prima op zichzelf, maar sluit niet aan op de werkelijke oorzaak van de verstoring in je productieproces. Het resultaat: verloren tijd, overschreden budgetten en een team dat het vertrouwen in automatisering verliest. De vragen hieronder helpen je begrijpen waarom dit zo vaak misgaat en hoe je het voorkomt.
Wat gaat er mis als de oplossing vóór het probleem komt?
Als de oplossing vóór het probleem komt, los je het symptoom op in plaats van de oorzaak. Een bedrijf dat een cobot installeert omdat de lijn te langzaam is, kan ontdekken dat de vertraging eigenlijk zit in een slechte aanvoer van materialen. De cobot werkt, maar de bottleneck blijft.
Dit patroon komt vaker voor dan je denkt. Iemand ziet een demonstratie op een beurs, leest een artikel over PLC-besturing of hoort van een collega dat een visionsysteem zijn lijn heeft versneld. De enthousiaste conclusie is: dat willen wij ook. Maar wat die collega nodig had, is zelden precies wat jij nodig hebt.
Het gevaar zit hem niet in de technologie zelf. PLC-besturing, motion control en geautomatiseerde inspectie zijn krachtige middelen. Het gevaar zit in de volgorde: wanneer de keuze voor een middel voorafgaat aan een helder begrip van het doel, stuur je het project al bij de start de verkeerde kant op. En hoe verder je in dat traject komt, hoe duurder het is om terug te draaien.
Hoe weet je of je het productieprobleem goed genoeg begrijpt?
Je begrijpt een productieprobleem goed genoeg als je de oorzaak kunt benoemen, niet alleen het gevolg. “We produceren te langzaam” is een gevolg. “Onze omsteltijden zijn gemiddeld twee uur per shift door handmatige kalibratie” is een oorzaak. Pas als je op dat niveau zit, kun je beoordelen welke oplossing zinvol is.
Een paar vragen die helpen om te toetsen of je het probleem echt begrijpt:
- Kun je het probleem kwantificeren? Hoeveel stilstand, hoeveel uitval, hoeveel extra handelingen per dag?
- Weet je wanneer het probleem optreedt en wanneer niet?
- Heb je de oorzaak geverifieerd op de werkvloer, of ga je af op aannames?
- Zijn de mensen die dagelijks met het proces werken het eens over wat er misgaat?
Als je op een of meerdere van deze vragen geen concreet antwoord hebt, is de probleemanalyse nog niet klaar. Dat is geen zwakte, dat is eerlijkheid. En die eerlijkheid is precies wat een goed automatiseringsproject beschermt.
Waarom leiden automatiseringsprojecten zo vaak tot teleurstelling?
Automatiseringsprojecten mislukken vaak niet door slechte technologie, maar door slechte afstemming. De klant verwacht iets anders dan wat de leverancier heeft gebouwd, de integratie met bestaande systemen is onderschat, of de specificaties waren gebaseerd op aannames die halverwege het project niet meer klopten.
Een veelgehoorde situatie: een bedrijf koopt een automatiseringssysteem op basis van een globale beschrijving. De leverancier levert wat is afgesproken. Maar bij inbedrijfstelling blijkt dat het systeem niet goed communiceert met de bestaande PLC, dat de operatorinterface te complex is voor de mensen op de vloer, of dat de procesparameters anders zijn dan verwacht. Elke aanpassing kost extra tijd en geld, en de frustratie stapelt zich op.
De diepere oorzaak is bijna altijd hetzelfde: er was te weinig tijd besteed aan de fase vóór de technische uitwerking. Aan het begrijpen van het proces, het vastleggen van functionele eisen en het toetsen van aannames. In systems engineering heet dat de requirements-fase, en het is de fase die het meest wordt overgeslagen omdat ze geen zichtbaar resultaat oplevert. Totdat het misgaat.
Wat is het verschil tussen een uitvoerder en een engineering partner?
Een uitvoerder wacht op een kant-en-klare specificatie en bouwt wat is beschreven. Een engineering partner helpt je die specificatie te ontwikkelen, stelt kritische vragen bij aannames en denkt mee over de slimste weg naar het gewenste resultaat. Het verschil zit niet in de technische vaardigheden, maar in de betrokkenheid bij de probleemdefinitiefase.
Voor productiemanagers en operations managers die zelf geen technische achtergrond hebben in automatisering, is dit onderscheid cruciaal. Zij kunnen geen gedetailleerde specificatie aanleveren, omdat ze niet weten wat er technisch mogelijk is en wat de consequenties zijn van bepaalde keuzes. Een uitvoerder die wacht op die specificatie zet hen in een onmogelijke positie.
Wij werken bij Kruispunt Engineering niet met een vragenlijst die je zelf moet invullen. We beginnen bij jouw productieprobleem, stellen de vragen die nodig zijn om het te begrijpen, en maken vervolgens de vertaling naar een technische oplossing die aansluit op wat er werkelijk speelt. Dat is wat systems engineering in de praktijk betekent: de verbinding tussen het probleem en de oplossing bewust en zorgvuldig leggen, voordat er ook maar één regel code wordt geschreven.
Wanneer is het juiste moment om een technische oplossing te kiezen?
Het juiste moment om een technische oplossing te kiezen is nadat de probleemanalyse is afgerond, de functionele eisen zijn vastgelegd en de randvoorwaarden helder zijn. Pas dan kun je beoordelen welke technologie het beste past, wat realistisch is binnen je budget en tijdlijn, en welke risico’s er aan de implementatie kleven.
In de praktijk betekent dit dat je eerst antwoord geeft op vragen als: wat moet het systeem kunnen, onder welke omstandigheden, met welke bestaande infrastructuur, en wat is het minimale resultaat dat succes definieert? Pas als die vragen beantwoord zijn, is het zinvol om te kijken of de oplossing een Siemens TIA Portal-omgeving vereist, of een Beckhoff-architectuur beter past, of dat er helemaal geen PLC nodig is maar een aanpassing in het mechanische ontwerp.
Een goed gedefinieerd probleem maakt de oplossing vaak eenvoudiger dan verwacht. En soms blijkt dat de meest voor de hand liggende technologische ingreep helemaal niet nodig is. Dat inzicht is alleen mogelijk als je de stap naar de oplossing niet overslaat, maar bewust neemt op het moment dat je het probleem werkelijk begrijpt.
Frequently Asked Questions
Hoe lang duurt een goede probleemanalyse voordat we met een automatiseringsproject kunnen beginnen?
De duur van een probleemanalyse hangt af van de complexiteit van je productieproces, maar reken gemiddeld op één tot drie weken voor een gedegen analyse. Dit omvat werkvloerbezoeken, gesprekken met operators en productiemanagers, en het kwantificeren van de knelpunten. Die investering betaalt zich terug: een goed gedefinieerd probleem voorkomt kostbare bijsturingen tijdens de implementatie, die al snel het tienvoudige kunnen kosten van de tijd die je in de analysefase steekt.
Wat als we intern geen eenduidig beeld hebben van wat het probleem precies is?
Dat is een veelvoorkomende situatie en juist een signaal dat de probleemanalyse extra aandacht verdient. Verschillende perspectieven — van operators, planners en managers — onthullen vaak dat er meerdere onderliggende oorzaken spelen. Een goede aanpak is om alle betrokkenen apart te bevragen en de antwoorden naast elkaar te leggen: waar de verhalen uiteenlopen, zit meestal de kern van het probleem. Een externe engineering partner kan helpen om dit proces te faciliteren zonder interne politiek in de weg te laten zitten.
Kunnen we een bestaand automatiseringssysteem dat niet goed werkt alsnog redden, of is opnieuw beginnen beter?
Dat hangt volledig af van de oorzaak van het falen. Als het systeem technisch correct is gebouwd maar het verkeerde probleem oplost, helpt bijsturen weinig en is een herstart vanaf de probleemanalyse vrijwel altijd de verstandigste keuze. Als het systeem het juiste probleem aanpakt maar slecht is geïmplementeerd — door gebrekkige integratie, onvolledige specificaties of een mismatch met de bestaande infrastructuur — is het soms mogelijk om gericht bij te sturen. Een eerlijke technische audit is de eerste stap om te bepalen welke route het meest efficiënt is.
Hoe voorkom je dat leveranciers je richting hun eigen oplossing sturen in plaats van de beste oplossing?
De beste bescherming is een heldere set van functionele eisen die je opstelt vóórdat je met leveranciers in gesprek gaat. Als je alleen een probleem beschrijft zonder eisen, nodigt dat uit tot het aanprijzen van standaardoplossingen. Vraag leveranciers expliciet om te onderbouwen waarom hun oplossing beter past dan alternatieven, en toets die onderbouwing aan jouw vastgelegde randvoorwaarden. Een onafhankelijke engineering partner die geen belang heeft bij een specifiek platform of merk kan in dit proces een waardevolle rol spelen als objectieve sparringpartner.
Welke informatie moet je minimaal op orde hebben voordat je een automatiseringsproject aanbesteedt?
Minimaal heb je nodig: een beschrijving van het huidige proces inclusief meetbare knelpunten, de functionele eisen die de oplossing moet vervullen, de technische randvoorwaarden zoals bestaande infrastructuur en communicatieprotocollen, en een heldere definitie van wat succes betekent. Zonder deze informatie vergelijk je offertes die op verschillende aannames zijn gebaseerd, wat leidt tot verrassingen bij de oplevering. Hoe specifieker je dit vastlegt, hoe beter leveranciers kunnen offreren en hoe kleiner de kans op meerwerk achteraf.
Is systems engineering alleen relevant voor grote, complexe automatiseringsprojecten?
Nee, de principes van systems engineering — probleem begrijpen vóór oplossing kiezen, eisen vastleggen, aannames toetsen — zijn even waardevol bij kleinere projecten. Het schaalniveau bepaalt de diepgang, niet de relevantie. Juist bij beperkte budgetten is het cruciaal om de eerste keer de juiste keuze te maken, omdat er geen ruimte is voor kostbare herstart. Een kleinere scope rechtvaardigt een kortere analysefase, maar nooit het volledig overslaan ervan.
Hoe betrek je operators en productiemedewerkers het beste bij de probleemanalyse?
Operators zijn de meest waardevolle informatiebron in een probleemanalyse, omdat zij dagelijks zien wat er werkelijk gebeurt op de vloer — inclusief de workarounds en ongeschreven regels die nooit in een procesbeschrijving staan. Betrek hen vroeg, stel open vragen en luister zonder direct naar oplossingen te sturen. Praktisch werkt het goed om korte gesprekken op de werkvloer te combineren met directe observatie tijdens productie. Medewerkers die zich gehoord voelen in de analysefase zijn bovendien aanzienlijk gemotiveerder om een nieuw systeem succesvol te laten landen.
