Maatwerkkoppelingen hebben een matige reputatie, en vaak is dat verdiend. Bij veel maakbedrijven draait ergens nog een koppelscript waarvan niemand precies weet wat het doet, geschreven door iemand die er al lang niet meer werkt. Het werkt, tot het een keer niet werkt, en dan durft niemand erin te kijken.
Toch is er soms geen standaardroute. Dat ene ERP met eigen maatwerkvelden, de zelfgebouwde planningstool, het klantportaal dat documentpakketten in een eigen structuur verwacht: wie daarmee wil koppelen, komt uit bij een maatwerkkoppeling tussen CAD-software en het eigen systeem. Dat hoeft geen hoofdpijndossier te worden. Het verschil tussen een koppeling die jaren meegaat en een die na oplevering al kraakt, zit vrijwel volledig in de aanpak. Die aanpak, in vier afspraken, is waar dit artikel over gaat; een platform als Thundercad speelt daarin de rol van onderhouden basis.
Eén ding behandelen we hier niet opnieuw: de afweging of je zelf bouwt of koopt. Daarover schreven we eerder in iLogic of een kant-en-klare toolbox: wanneer kies je wat. Hier nemen we aan dat de conclusie maatwerk is, en gaat het over de vraag hoe je dat traject klein en beheersbaar houdt.
Controleer eerst of het echt maatwerk is
Een flink deel van de wensen die als maatwerk binnenkomen, blijkt met standaardgereedschap te dekken. Tekenpakketten in bulk exporteren, stuklijsten in een eigen Excel-sjabloon aanleveren, artikelen uit het ERP raadplegen tijdens het samenstellen: daarvoor hoeft niemand iets te laten programmeren. Loop daarom eerst de standaardroute af en bepaal waar die ophoudt; in Inventor aan je ERP koppelen: waar begin je? staat een ladder van koppelniveaus die daarbij helpt.
Echt maatwerk begint waar jouw proces een overdracht vraagt die geen standaardfunctie dekt. Denk aan een planningstool die per bewerkingsstap uren wil ontvangen, of een klantportaal dat bij elke levering een documentpakket met eigen mappenstructuur en naamgeving verwacht. Dat zijn overdrachten die specifiek zijn voor jouw bedrijf, en precies daar is maatwerk op zijn plek.
Begin bij de dataset die al klopt
Een koppeling verplaatst gegevens; ze maakt ze niet beter. Koppel je een bron waarin de helft van de artikelnummers ontbreekt of dubbel is, dan verspreid je die rommel voortaan automatisch, en dat sloopt het vertrouwen in de koppeling sneller dan welke storing ook. De eerste vraag van een koppeltraject is dus niet technisch maar inhoudelijk: welke dataset is bij ons al betrouwbaar?
Bij een machinebouwer is dat bijvoorbeeld de stuklijst van een vrijgegeven samenstelling, met artikelnummers en omschrijvingen die al onder discipline staan omdat inkoop ermee werkt. Dat is een prima eerste overdracht. iProperties waarover nog geen afspraken bestaan, zijn dat niet; die maak je eerst op orde voordat er een systeem aan gaat hangen. Klein beginnen met schone data geeft bovendien beide kanten, engineering en de beheerder van het andere pakket, snel een succes om op voort te bouwen.
Definieer één overdracht: velden, moment, richting
Het verschil tussen een beheersbaar traject en een moeras zit in één zin. Niet "de systemen moeten met elkaar praten", maar bijvoorbeeld: "bij vrijgave van een samenstelling gaan deze acht velden van de stuklijst naar het planningspakket, één richting op." Zo'n zin dwingt alle keuzes af die ertoe doen:
| Vraag | Voorbeeld van een antwoord |
|---|---|
| Welke velden | artikelnummer, omschrijving, materiaal, gewicht, aantal |
| Welk moment | bij vrijgave, niet continu synchroniseren |
| Welke richting | van CAD naar het andere systeem, éénrichting |
| Wie is de bron | CAD voor geometrie en gewicht, ERP voor commerciële velden |
| Wat bij twijfel | de koppeling meldt, een mens beslist |
Alles wat niet in dit lijstje staat, bestaat in de eerste versie niet. Tweerichtingsverkeer, extra velden, live synchronisatie: allemaal prima ideeën voor later, nadat de eerste overdracht zich in de praktijk heeft bewezen. Scopebewaking is bij maatwerk geen bureaucratie maar zelfbescherming.
Zien hoe zo'n overdracht er in de praktijk uitziet? In de proefmaand van Thundercad verken je hoe de standaardtools met je ERP samenwerken, nog voordat er iets gebouwd is.
Probeer 30 dagen gratisBouw op een onderhouden basis, niet op los scriptwerk
De klassieke valkuil is het losse script: snel gebouwd, precies goed voor nu, en volledig afhankelijk van die ene auteur. Bij elke nieuwe Inventor-versie is het afwachten of het nog draait, documentatie is er zelden, en een tweede paar ogen heeft er nooit naar gekeken. Zo ontstaan de spookkoppelingen uit de eerste alinea van dit artikel.
Het alternatief is maatwerk als dunne laag op een basis die al onderhouden wordt. Binnen Thundercad is het Dashboard daarvoor de plek: daar beheer je de tools en koppel je ze aan je ERP of andere software. Een voorbeeld is Article Manager, waarmee engineers artikelen uit het ERP raadplegen zonder Inventor te verlaten; die tool aansluiten op jouw artikeldatabase is een kleine, afgebakende klus vergeleken met een compleet eigen bouwwerk. Het maatwerk beperkt zich dan tot de vertaalslag naar jouw systeem, terwijl updates en onderhoud van de basis gewoon doorlopen.
De vuistregel: hoe kleiner het deel dat uniek voor jou gebouwd is, hoe kleiner het deel dat alleen jouw leverancier of die ene collega begrijpt. Het A4 uit de vorige sectie moet het maatwerkdeel volledig kunnen beschrijven.
Spreek af wie de koppeling beheert
Koppelingen sneuvelen zelden op techniek en bijna altijd op beheer. Iemand hernoemt een veld in het ERP, de mappenstructuur op de server gaat om, en drie weken later blijkt de planning al die tijd met oude gewichten te hebben gerekend. Niet omdat de techniek faalde, maar omdat niemand zich eigenaar voelde.
Leg daarom vóór de bouw vijf afspraken vast:
- één eigenaar met naam voor inhoudelijke vragen: klopt wat er overkomt;
- één onderhoudspartij voor de techniek, met een afspraak over wie wanneer bijwerkt;
- het A4 met de veldenlijst als levend document: wijzigt een veld, dan eerst het A4 bijwerken;
- een vast testmoment na elke wijziging in het ERP of de CAD-omgeving;
- een terugvalroute: hoe werkt de afdeling door als de koppeling stilligt, en wie merkt dat als eerste.
Krijg je het beheer niet belegd, begin dan niet aan de bouw. Dat klinkt streng, maar een koppeling zonder eigenaar wordt onvermijdelijk het script waar niemand meer in durft te kijken.
Veelgestelde vragen
Hoe lang duurt een maatwerktraject?
De doorlooptijd zit zelden in het programmeren en bijna altijd in datawerk en keuzes: de dataset schoon krijgen, de veldenlijst vaststellen, testgevallen doorlopen. Met een schone bron en een overdracht die op één A4 past, blijft het een overzichtelijk project; met een vervuilde bron begint het traject feitelijk bij het opschonen.
Moeten we zelf kunnen programmeren?
Nee. Jouw rol als klant is inhoudelijk: bepalen welke velden overgaan, wanneer, en wat er bij twijfel moet gebeuren. De bouwer, je leverancier of een collega met ontwikkelervaring, verzorgt de techniek. Zorg vooral dat de inhoudelijke keuzes op papier staan voordat er gebouwd wordt; dat scheelt discussie achteraf.
Kunnen we klein beginnen zonder meteen een traject te starten?
Ja, en dat is zelfs verstandig. Begin met de standaardtools en kijk waar je zonder maatwerk al uitkomt; wat overblijft, is de echte maatwerkvraag. Download de proefversie van Thundercad, verken het Dashboard en leg pas daarna de resterende wensen naast een bouwer.