Wat bepaalt de kosten van engineeringautomatisering in prefab?

Een standaardprijs voor engineeringautomatisering bestaat niet. De kosten hangen af van vier factoren: de scope, de kwaliteit van je brondata, de gewenste output en het aantal koppelingen. Die vier kun je zelf eerst in kaart brengen, nog voordat je een leverancier spreekt.

Factor 1: de scope

Het verschil tussen één productfamilie en tien productfamilies is groter dan het lijkt. Elke familie heeft eigen regels, eigen uitzonderingen en vaak eigen output.

Een smalle scope betekent minder regels, minder uitzonderingen en een kortere testfase. Een brede scope vraagt meer afstemming, meer testwerk en een langere periode waarin de organisatie moet wennen aan de nieuwe werkwijze. Wie de scope klein houdt, verlaagt zowel de kosten als het risico.

Factor 2: de kwaliteit van de brondata

Dit is in de praktijk de duurste factor. Zijn definities eenduidig? Zijn eenheden consistent? Zijn er meerdere bronnen die hetzelfde beweren?

Ontbreekt die basis, dan gaan de eerste werkzaamheden naar opschonen in plaats van naar automatiseren. Dat is geen verkeerde besteding, maar het is wel werk dat je vooraf kunt beperken. Onze data-audit beschrijft hoe je dat in kaart brengt.

Factor 3: de gewenste output

Een model genereren is iets anders dan een productieklaar pakket genereren. Een 3D-model, een IFC-bestand, een werktekening, een stuklijst, een calculatie en een machinebestand vragen elk eigen validatie.

Hoe meer outputvormen, hoe meer controles en hoe meer afstemming met de afdelingen die die output gebruiken. Begin met de output die het meeste oplevert. Vaak is dat niet de meest volledige, maar de meest gebruikte.

Factor 4: integraties

Een koppeling met ERP, MES of een machine vereist afstemming over velden, eenheden, timing en foutafhandeling. Elke koppeling voegt een testmoment toe.

Het is verstandig om integraties gefaseerd aan te pakken. Eerst een werkende stroom van invoer naar output, daarna de koppelingen die die stroom versterken. Anders wordt een project onnodig complex voordat er iets werkt.

Zo bouw je zelf de businesscase

Een businesscase is geen schatting, maar een meting. Verzamel deze vijf gegevens uit je eigen administratie:

• Uren per variant: wat kost het engineeren van één standaardvariant gemiddeld?
• Aantal varianten: hoeveel varianten maak je per maand en per jaar?
• Correctierondes: hoeveel elementen vragen een tweede beoordeling of herstel?
• Doorlooptijd: hoeveel tijd zit tussen aanvraag en productieklaar model?
• Faalkosten: wat kost een gemiste of late wijziging, inclusief stilstand?

Met die vijf getallen kun je een voorzichtige inschatting maken van de jaarlijkse inspanning. Zet daar de verwachte tijdwinst tegenover en reken met een bandbreedte, niet met één getal. Reken altijd met code of spreadsheet, niet uit het hoofd.

Kijken naar totale kosten, niet alleen licenties

Een automatiseringsoplossing heeft meer kosten dan de licentie of het ontwikkelingstraject:

• Inrichting en configuratie van regels en output.
• Validatie met engineering en productie.
• Opleiding van de mensen die ermee werken.
• Beheer van regels bij wijzigingen in product of proces.
• Onderhoud van koppelingen als systemen worden bijgewerkt.

Het beheer is de post die het vaakst wordt onderschat. Regels die niet worden onderhouden, verouderen sneller dan het product zelf.

Waarom een pilot verstandig is

Een pilot met één productfamilie geeft antwoord op de vragen die vooraf niet te beantwoorden zijn: werkt het met onze data, accepteert productie de output, en hoeveel beheer vraagt het?

Dat antwoord is meer waard dan een prijsopgave op papier. Het maakt bovendien de stap naar een breder traject kleiner, omdat de eerste resultaten meetbaar zijn.

Wat je zonder investering al kunt verbeteren

Voordat je een traject start, zijn er verbeteringen die niets kosten en die de businesscase beter maken. Het eenduidig benoemen van elementen is er één. Het vastleggen van één bron als leidend is een tweede.

Ook het bijhouden van correctierondes kost niets, maar levert direct inzicht. Zodra je weet welke fouten terugkomen, weet je welke regels je moet vastleggen. En dat is precies de input die een automatiseringsproject nodig heeft.

Bedrijven die deze drie stappen eerst doen, beginnen een traject met een schonere basis en een scherper beeld van de winst.

Hoe je een pilot afbakent

Een pilot is bedoeld om te leren, niet om te bewijzen dat iets werkt. Bak hem daarom af op inhoud: één productfamilie, één outputvorm, één gebruiker per afdeling.

Spreek vooraf af wat je meet: doorlooptijd per variant, aantal correctierondes en de tijd die nodig is om een wijziging door te voeren. Meet die cijfers vooraf, niet achteraf uit het geheugen.

Leg ook vast wanneer de pilot geslaagd is. Zonder die afspraak wordt de uitkomst een mening in plaats van een meting, en duurt de beslissing langer dan het traject zelf.

Valkuilen in de businesscase

De eerste valkuil is rekenen met de beste maand. Gebruik een gemiddelde over een langere periode, inclusief de drukke en de stille maanden.

De tweede is vergeten dat engineeringsuren niet volledig verdwijnen. Er blijft werk over voor beoordeling, uitzonderingen en beheer. Reken met de tijd die werkelijk vrijkomt, niet met de totale tijd.

De derde is de kosten van niets doen buiten beschouwing laten. Fouten die nu handmatig worden hersteld, kosten ook geld, en de doorlooptijd die klanten ervaren is een commerciële factor. Wie die kosten niet benoemt, vergelijkt een investering met nul.

Hoe CADblanche hierin werkt

CADblanche richt oplossingen in op basis van je bouwconcept, productregels en productiemethode. De omvang van een traject volgt uit de scope die je samen afbakent, niet uit een vast pakket.

Een verkennend gesprek of demo is bedoeld om die scope te bepalen: welke productfamilie, welke output, welke koppelingen. Daarmee wordt de investering concreet zonder dat je vooraf hoeft te kiezen voor een volledig systeem.

Twijfel je tussen een configurator en maatwerkengineering? Lees Configurator, parametrisch model of maatwerkengineering voor de afweging.