De voortgang van de productieprocessen in de fabriek is niet zichtbaar: hoe moet de bedrijfsvoering worden opgesplitst, hoe wordt de voortgang verzameld en hoe wordt dit afgestemd met de werkorders?

Inleiding: Waarom staat het “voortgangsbord” aan de muur van de werkplaats altijd twee dagen voor op het systeem

Lopen we een fabriek binnen die zich bezighoudt met machinale bewerking, dan zien we in de vergaderzaal een witbord met kleurrijke post-its, waarop elk een werkorder‑nummer, de bewerkingsstap van de dienst en het machine‑nummer vermeld staat. Elke avond wisselt de manager van dienst de post‑its. De volgende ochtend vraagt de eigenaar in de werkplaats: “Zijn alle taken van gisteren afgerond?” De werkplaatsdirecteur haalt het bord tevoorschijn en telt met half dichtgeknepen ogen de post‑its.

In dezelfde fabriek bestaan vaak twee soorten “voortgang”: één is het witbord met post‑its, de andere is de status van de werkorders in het ERP‑ of MES‑systeem. Het eerste geeft de werkelijke situatie ter plaatse weer, het tweede is de cijferlijke weergave voor financiën en klanten. Dat de twee niet overeenkomen, is normaal; dat ze wel overeenkomen, is nieuws.

Dit is geen uitzondering voor één specifieke fabriek. In alle werkplaatsen die wij hebben gezien – van kleine ateliers met slechts een tiental medewerkers tot grote assemblagefabrieken met duizenden werknemers – komen soortgelijke problemen voor:

• Productieplanning bereikt de werkplek niet: De planner stelt 30 werkorders in het systeem op, maar in de werkplaats zijn er slechts acht zichtbaar; de rest blijft “hangen in het systeem”.
• Voortgang wordt bepaald door vragen stellen: De dispatching‑medewerker belt dagelijks tientallen keren om te vragen “Hoe ver staat dit werk?”, en zelfs de teamleider weet niet meer precies bij welke bewerkingsstappen men gebleven is.
• Werkuren komen niet overeen met de werkelijkheid: De rapporterende medewerker vult elke vier uur een formulier in, maar voegt pas twee uur voor sluitingstijd de ontbrekende gegevens toe; de cijfers wijken 20% tot 40% af van de werkelijke productiesnelheid.
• Abnormale situaties worden niet opgevolgd: Een bepaalde bewerkingsstap wacht al drie dagen op materiaal, zonder dat iemand het merkt; pas wanneer de klant dringt, blijkt dat er een onderdeel ontbreekt.

Het probleem ligt niet bij de software die niet wordt gebruikt, maar bij de onderbreking in de informatie‑verzameling tussen “ter plaatse” en “systeem”. Het witbord aan de muur is echter realistischer dan het ERP‑systeem, omdat het direct naast de machine staat en wordt onderhouden door mensen die de werkelijke situatie kunnen waarnemen; het ERP‑systeem daarentegen gaat vaak via drie lagen: van teamleider naar groepsleider naar dispatching‑medewerker, waarbij op elke stap de gegevens opnieuw worden ingevoerd en elke laag een extra vertraging of fout kan veroorzaken.

Hieronder analyseren we hoe dit systeem moet worden ontworpen en geïmplementeerd, zodat het witbord langzaam geleidelijk overbodig wordt.

01 Hoe de bedrijfsprocessen moeten worden opgesplitst: “voortgang” opsplitsen in de kleinste meetbare handelingen

Veel projecten beginnen met het beschouwen van de term “procesvoortgang” als één enkele veldnaam. In werkelijkheid is “procesvoortgang” een samengestelde toestand: Op welke werkplek bevindt zich de werkorder; Wie is momenteel bezig met de uitvoering; Hoeveel is er al gedaan; Hoeveel arbeidstijd is er al gebruikt; Is de kwaliteit conform de eisen; Zijn alle materialen aanwezig. Deze zes dimensies moeten elk afzonderlijk worden verzameld; ze mogen niet in één veld worden samengevoegd.

Concreet ziet de opsplitsing er als volgt uit:

1. Werkplek: Elke machine of werkplek heeft een uniek nummer; door middel van scannen of pinnen kan exact worden vastgesteld “Welk werk wordt nu op deze machine uitgevoerd”.
2. Uitvoerder: Elke werkorder is gekoppeld aan een persoonlijke werknemerscode, zowel voor de start‑ als de overdrachts‑ en de afrondingsstap. Zelfs bij samenwerking tussen leerling en meester is de hoofdoperator de enige die de gegevens registreert.
3. Aantal uitgevoerde taken: Voor elke bewerkingsstap zijn er inspecties bij de eerste controle, tijdens de bewerking en bij de afronding. Aantal is geen toestand; het moet steeds worden bijgewerkt door op een knop te drukken of een code te scannen.
4. Werkelijke arbeidsduur: Het tijdsverschil tussen de start‑ en de afrondingsstap (automatisch verzameld), plus eventuele onderbrekingen (handmatig ingevuld om de reden van de vertraging te noteren).
5. Kwaliteitsstatus: Drie registraties – eerste controle, tussentijdse inspectie en eindinspectie – waarbij goedgekeurd, herwerkt of afgekeurd apart worden verwerkt; alleen het percentage goedkeuring mag niet worden ingevuld.
6. Volledige materialen: Elk materiaal op de BOM wordt ingedeeld in drie toestanden – compleet, incompleet of ontbrekend – en deze status wordt gekoppeld aan de werkorder.

Deze zes dimensies moeten worden omgezet in afzonderlijke “event‑streams”, in plaats van één gezamenlijke statusveld. Een event is een chronologische registratie: wie, wanneer, op welke machine, tot welke fase is er gewerkt, en welke abnormale situaties zijn opgetreden. De status is een weergave die uit de event‑stream wordt afgeleid; statusvelden mogen niet handmatig worden ingevuld.

02 Hoe het systeem moet worden ontworpen: De rollen, processen, data en grenzen van de gebruikersinterface duidelijk definiëren

De grootste valkuil tijdens de ontwerpfase is “een app maken waarin mensen alles zelf moeten invullen”; na twee jaar gebruik blijkt de app alleen nog maar een inlogpagina en een leeg wachtwoordveld te bevatten. Het probleem zit in de mismatch tussen rollen en interfaces.

Rolontwerp

In de werkplaats zijn vier soorten personen, en elk type gebruikt een andere interface:

• Operator: Gebruikt een terminal of tablet met grote knoppen op de werkplek; ziet alleen “Mijn huidige werkorder” met drie knoppen: starten, pauzeren, afronden. Er mogen geen tabellen op het scherm verschijnen.
• Teamleider: Gebruikt een mobiele telefoon of het werkplaatsbord; ziet de status van alle werkplekken in de dienst en kan binnen twee minuten achterhalen “Waar zit de bottleneck?”.
• Dispatching‑ of planningsmedewerker: Gebruikt een pc; bekijkt het Gantt‑diagram en de lijst met abnormale situaties van alle werkplekken in de fabriek, met nadruk op planningaanpassingen en reacties op abnormale situaties.
• Kwaliteits‑ of procesmanager: Heeft een aparte toegang; bekijkt de percentages van eerste keuring, herwerkingsgraad en SPC‑trends; mag de status van de werkorder niet rechtstreeks wijzigen, maar kan alleen “productielijn stoppen” of “goedkeuring verlenen” beslissen.

Gegevensmodel

Vier kerntabellen, plus enkele ondersteunende tabellen, zijn voldoende:

• work_order: Hoofdtabel voor werkorders, gekoppeld aan verkooporders, planningsorders en producten.
• work_order_route: Procesroute, met details over hoeveel stappen elke bewerkingsfase omvat.
• route_event: Event‑stream van elke bewerkingsstap (de kern van de chronologische registratie), met informatie over wie, wanneer, op welke machine en tot welke fase er is gewerkt.
• exception_log: Logboek van abnormale situaties (materiaaltekort, apparatuurfout, kwaliteitsherwerking).

Statusvelden (status、current_step、progress_pct) worden allemaal in realtime berekend op basis van route_event, en worden niet opgeslagen; alleen de events worden bewaard. Zo blijft de status altijd gebaseerd op de event‑stream, ongeacht wie de werkorder wijzigt.

Grenzen van de gebruikersinterface

De grenzen van de drie soorten terminals moeten duidelijk worden getekend:

• Terminal voor werkplekken: Scannen → Werkorder oproepen → Processchema weergeven → Grote knoppen voor starten/pauzeren/afronden; mag geen numerieke velden invullen, alle cijfers worden automatisch geschreven door PLC of scanapparaat.
• Bord voor teamleiders: Gestructureerd raster van alle werkplekken in de dienst; groen voor normaal, geel voor overmatige snelheid, rood voor abnormale situaties. Klikken op rood brengt direct naar de details van het abnormale logboek.
• 调度er PC: Gantt-diagram met resourcebelasting en afzonderlijke foutenwachtrijen, fouten moeten in aparte wachtrijen worden geplaatst, ze mogen niet door elkaar in het Gantt-diagram zitten, zodat mensen niet “op zoek moeten naar fouten”.

03 Hoe te ontwikkelen: drie barrières voor verzameling, interfaces en acceptatie

Het kernthema in de ontwikkelingsfase is “zorgen dat het terrein het wil gebruiken”. De voorwaarde om het terrein dit te laten doen, is dat het “met één druk op de knop werkt”, niet dat men “een heleboel moet invullen”. Achter dit staat een drievoudige barrière.

Verzamelingsbarrière

De verzameling bestaat uit drie lagen:

• Directe apparatuurverzameling: CNC, spuitgietmachines, SMT via OPC UA of Modbus; start-/stop-signalen, huidige programma‑nummer en telwaarden worden in real time in de eventstream geschreven. Dit onderdeel is het moeilijkst maar ook het meest waardevol; eenmaal gedaan hoeft men niet meer afhankelijk te zijn van handmatig werk.
• Scannen plus knoppen: Op menselijke werkplekken wordt een barcodelezer (voor materialen) + een grote knop (start/pauze/afronding) gebruikt. De barcodelezer werkt via USB HID en geeft als output een tekenreeks, er wordt geen OCR of beeldherkenning toegepast, want zodra het netwerk ter plaatse vastloopt, is het beeld onbruikbaar.
• Weeg-/tel-/lichtgordijn: materiaalweegschaal, onderdelen tellen, veiligheidslichtgordijn; allemaal via PLC-signaal naar OPC.

Drie verdiepingen delen één verzamelgatewayservice; de gateway normaliseert verschillende protocollen naar een uniform gebeurtenisformaat (JSON) en schrijft dit naar de berichtenwachtrij (Kafka of RabbitMQ), waarop abonnementsdiensten consumeren en vervolgens in de database schrijven. Op deze manier hoeft bij vervanging van apparatuur of bewerkingspositie alleen de gateway aangepast te worden, zonder dat het hoofdbedrijfssysteem opnieuw hoeft te worden geschreven .

Interfacepoort

Externe interfaces zijn van twee soorten:

• Upstream : ERP of MES stuurt werkorders, verkooporders en BOM’s door. Dit is de belangrijkste bron van stamgegevens , waarop dit systeem alleen leest en niet schrijft, om dubbele wijzigingen van werkorderstatussen tussen beide systemen te voorkomen.
• Downstream : het financiële systeem heeft arbeidstijd en kosten nodig; het klantsysteem wil de leveringsvoortgang weten; het leverancierssysteem moet de assemblagestatus kunnen controleren. Downstream gebruikt “event-triggering” of “periodieke ophaling”; het is niet toegestaan dat downstream de werkorderstatus in dit systeem terugwijzigt.

Principe van interfaceontwerp: Eventstromen gaan alleen uit, nooit in . Dit systeem is de bron van de waarheid (source of truth), terwijl externe systemen abonnees zijn. Als we ons aan deze regel houden, blijft er altijd maar één ware versie van de voortgang bestaan.

Acceptatiepoort

Acceptatie betekent niet “functies werken”, maar drie zaken:

1. Gegevensauthenticiteit : willekeurig vijf werkorders selecteren, vergelijken met het whiteboard of live beelden, en controleren of de systeemregistratie en de werkelijke start- en eindtijden binnen vijf minuten afwijken.
2. Afwijkingsgesloten kring : creëer een afwijkingsmelding vanwege materiaaltekort en verifieer dat vanaf het moment dat de teamleider de melding maakt, via de planner die de afwijking verwerkt, de inkoop het materiaal aanvult en uiteindelijk de werkpositie weer operationeel is, alles traceerbaar is en binnen vijf minuten in de afwijkingswachtrij zichtbaar wordt.
3. Ritmevergelijking : gedurende een week achtereenvolgens elke werkpositie meten en het werkelijke ritme vergelijken met de procesnorm; als het verschil meer dan 30% bedraagt, wordt automatisch een waarschuwingsrapport gegenereerd.

Pas als deze drie zaken zijn goedgekeurd, kan men zeggen dat “de voortgang van de productiestap echt zichtbaar is”.

Afronding: volgorde van implementatie, risico’s en meetpunten

Projecten van dit type worden in drie fasen ingevoerd; niet in één keer volledig:

1. Eerste fase (1–2 maanden) : eerst de werkstations met extra taken en het teamleidersbord, slechts één productielijn bedekken . Het doel is dat “80% van de notities op het whiteboard automatisch in het systeem gesynchroniseerd worden”.
2. Tweede fase (2–3 maanden) : toevoegen van de planner op de pc, de afwijkingswachtrij en directe inkoop van apparatuur, om alle belangrijke productielijnen van de fabriek te dekken. Het doel is dat “ter plaatse geen telefoontjes meer nodig zijn om de voortgang te vragen”.
3. Derde fase (naar behoefte) : integratie met ERP-, financiële- en klantsystemen voor ritmeoptimalisatie en SPC-analyse. Deze fase is niet verplicht; na afronding van de eerste twee fasen beslist men op basis van feedback van de werkvloer.

Veelvoorkomende risico’s:

• Ter plaatse tegenstand : angst voor controle en vergelijking. Oplossing: de interface toont alleen de werkpositie, niet de persoon; de meetpunten worden alleen op teamniveau vastgesteld, zonder individuele ranglijsten.
• Ontbrekende registratie van gegevens : oudere apparatuur heeft geen communicatiepoort, dus moet een barcodelezer als alternatief worden gebruikt. Bij acceptatie moet worden geverifieerd dat de onopgemerkte registratie niet meer dan 5% bedraagt.
• Vervorming van arbeidstijd : operators beginnen en stoppen herhaaldelijk om “cijfers te halen”. Als het systeem binnen vijf minuten meerdere starts op dezelfde werkpositie detecteert, wordt dit direct als afwijking geregistreerd.

Er zijn slechts drie indicatoren die bepalen of de inspectie slaagt:

• Aantal telefoontjes van de planner : na implementatie daalt dit met meer dan 50%.
• Gemiddelde reactietijd op afwijkingen : van uur tot minuut.
• Door klanten controleerbare voortgang : het aantal klachten over leveringsvertragingen daalt met meer dan 30%.

Zodra deze drie indicatoren op locatie zijn bereikt, kan het whiteboard aan de muur leeg worden, en dan kan men zeggen dat de voortgang echt is gerealiseerd.