Onderhoud Proof of Concept

Maak Kritiek Onderhoud Meetbaar Vóór Het Opschalen

Begin met het proces dat vandaag faalt — melding, reactie, uitvoering, documentatie — op uw kritieke assets. Conditiebewaking wordt alleen toegevoegd waar sensoren en voldoende observatietijd daadwerkelijk bestaan, en storingsvoorspelling wordt alleen geclaimd waar gelabelde storingshistorie dat ondersteunt.

Beoordeel mijn kritieke assets Spreek een productie-engineer

Gebruikelijke doorlooptijd6–12 weken

Omvang van de pilotGeselecteerde kritieke assets en één onderhoudsteam

Belangrijkste gesprekspartnerOnderhoudsmanager

Beslissing aan het eindUitrolplan en, waar gerechtvaardigd, een roadmap voor bewaking

Is dit het probleem dat u moet oplossen?

Storingsafhandeling loopt via telefoontjes en een whiteboard, dus de reactietijd is onbekend.
Preventieve plannen bestaan op papier en verschuiven stilletjes zodra de productie druk is.
Dezelfde storing herhaalt zich en niemand kan het bewijzen, omdat de historie in notitieboekjes staat.
Reserveonderdelen blijken te ontbreken juist op het moment dat de technicus ze nodig heeft.

Belangrijkste gesprekspartner: Onderhoudsmanager · Reliability manager · Fabrieksmanager · Engineeringmanager · Manager operational excellence

Wat deze PoC aantoont

Kunnen melding, reactie, uitvoering en documentatie digitaal draaien in elke ploeg, inclusief nachten?

Wat is de werkelijke MTTR en reactietijd zodra deze gemeten worden in plaats van geschat?

Hoeveel van het werk van het team is storingswerk, en hoeveel preventief werk staat eigenlijk al te lang open?

Vullen technici de documentatie in, of stort de naleving in week drie in elkaar?

Waar sensoren binnen scope zijn: komt het alarm vroeg genoeg om erop te kunnen reageren?

Aanbevolen omvang van de pilot

Geselecteerde kritieke assets — degene waarvan een storing de productie daadwerkelijk stopzet.
Eén onderhoudsteam, met het storings- en meldingsproces dat het vandaag gebruikt.
Preventieve plannen, werkorders en, waar relevant, de reserveonderdelen erachter.
Assethiërarchie, kriticiteit en de storingshistorie die bestaat.
Sensoren alleen voor afgesproken conditiebewakingscasussen, nooit als algemene aanname.

Wat er tijdens de PoC live draait

Digitale storingsmelding met reactie, toewijzing en escalatie.

Preventieve plannen die op schema en op meterstanden werkorders genereren.

Uitvoering van werkorders met documentatie, gebruikte onderdelen en geboekte tijd.

Onderhoudsdashboard met nulmeting: storingswerkaandeel, achterstallig werk, herhaalde storingen.

Zo verloopt deze PoC

Week 1–2

Verkenning en definitie van de beslissingDe assethiërarchie en kriticiteit doornemen, het huidige melding- en uitvoeringsproces in kaart brengen, en vaststellen welke assets en welke KPI-definities de PoC gebruikt.Doorgangscriterium: Assetomvang, proces en KPI-definities overeengekomen.

Week 2–4

NulmetingDe huidige MTTR, reactietijd, storingswerkaandeel en preventieve naleving vaststellen op basis van bestaande gegevens, en eerlijk aangeven waar de nulmeting een schatting is en geen meting.Doorgangscriterium: Nulmeting overeengekomen, met de onzekerheid ervan vastgelegd.

Week 3–6

ConfiguratieAssets, plannen, werkordertypes, rollen en mobiele uitvoering configureren; waar conditiebewaking binnen scope valt, de afgesproken sensoren installeren en valideren.Doorgangscriterium: Technici voeren een echte werkorder end-to-end uit op hun eigen apparaten.

Week 6–11

Gecontroleerd live gebruikHet team draait het onderhoud op het systeem. Reactie, uitvoering en documentatievolledigheid worden gevolgd; sensordata bouwt op naar een bruikbaar observatievenster.Doorgangscriterium: Een volledige onderhoudscyclus inclusief minstens één echte storing is in het systeem afgehandeld.

Week 11–12

Uitrolbeslissing en business caseDe gemeten nulmeting versus de pilotperiode, het kriticiteits- en hiatenrapport, de sensorbevindingen waar van toepassing, en het uitrolplan presenteren.Doorgangscriterium: Doorgaan, bijstellen of stoppen.

Doorlooptijden zijn gebruikelijk, niet gegarandeerd. Wat de planning verlengt: ontbrekende of onvolledige data, security- en netwerkgoedkeuringen, levertijden van hardware, het verzamelen van monsters, toegang voor de installatie, het productieplan, toegang tot de ERP-testomgeving en de tijd die uw team nodig heeft om resultaten te beoordelen.

Een ongeplande stilstand is niet voorzien. Elk installatievenster of gecontroleerde onderbreking wordt vooraf met u afgestemd en rond de productie gepland.

Hoe succes wordt gemeten

Hoe succes wordt gemeten
Meetwaarde	Hoe die is gedefinieerd	Waar het getal vandaan komt	Soort
Tijd van melding tot reactie	Tijd tussen het melden van een storing en de acceptatie ervan door een technicus, gemeten op de pilotassets.	Data uit het MSF-platform	Operationeel
MTTR	Gemiddelde reparatietijd voor de pilotassets tijdens de liveperiode, op basis van de in de verkenningsfase afgesproken definitie.	Data uit het MSF-platform	Operationeel
MTBF-nulmeting	Vastgestelde gemiddelde tijd tussen storingen voor de pilotassets — een nulmeting, geen doel, over dit observatievenster.	Afgesproken nulmeting	Operationeel
Storingswerkaandeel	Aandeel onderhoudsuren besteed aan ongepland werk versus gepland werk.	Data uit het MSF-platform	Operationeel
Preventieve naleving	Aandeel vervallen preventief werk dat binnen de termijn is voltooid, en de achterstallige achterstand aan het einde van de periode.	Data uit het MSF-platform	Operationeel
Documentatievolledigheid	Aandeel werkorders dat wordt afgesloten met oorzaak, actie en onderdelen geregistreerd, in plaats van leeg afgesloten.	Data uit het MSF-platform	Gebruik
Herhaalde storingen	Storingen op dezelfde asset met dezelfde oorzaak binnen de periode — het bewijs dat een oplossing niet heeft standgehouden.	Data uit het MSF-platform	Operationeel
Alarm-doorlooptijd	Alleen waar sensoren binnen scope vallen: tijd tussen een conditiealarm en de gebeurtenis waarvoor het waarschuwde, met valse alarmen apart geteld.	Sensor-, meter- of apparaatdata	Technisch

Vóór de implementatie spreken MSF en uw team af hoe elke meetwaarde wordt berekend, waar de nulmeting vandaan komt, welke data buiten beschouwing blijft en welk resultaat een uitrolbeslissing rechtvaardigt. Deze pagina noemt wat er gemeten wordt; de concrete streefwaarden horen in de schriftelijke PoC-scope, niet in een marketingbelofte.

Wat u aanlevert

Assethiërarchie, kriticiteitsrangschikking en de bestaande storingshistorie, in welke vorm die ook bestaat.
Huidige onderhoudsplannen, meterstanden en, waar relevant, reserveonderdelendata.
Technicusrollen, ploegdekking en de apparaten die zij realistisch zullen gebruiken.
Toegangs- en veiligheidsregels voor elke sensorinstallatie binnen scope.

Wie doet wat

Meta Smart Factory levert

Verkennende workshop en begeleiding bij het bepalen van de scope
Configuratie van de oplossing voor de afgesproken scope
Integratie- en koppelwerk binnen die scope
MSF-hardware zoals vermeld in de offerte
Training van de pilotgebruikers
De KPI-definities en de validatiemethode
Issuebewaking en ondersteuning tijdens de pilot
Het eindrapport en het uitrolontwerp
Geconfigureerde assetstructuur, preventieve plannen en mobiele werkorderuitvoering voor het pilotteam.
Een eerlijke classificatie van welke conditiebewakingscasussen de beschikbare data daadwerkelijk kan ondersteunen.

U levert

Een benoemde business-eigenaar en een benoemde technisch eigenaar
Tijdige toegang tot gebruikers, lijn, machines en goedgekeurde systemen
Een correcte toelichting op het proces en de stamdata
Toegang voor netwerk, voeding, montage en veiligheid
ERP-, PLC- en leveranciersdocumentatie plus de experts die deze kennen
Representatieve monsters of historische data
De bevestiging dat de nulmeting eerlijk is
Terugkoppeling en de acceptatiebeslissing
Technici die het systeem gebruiken tijdens echte storingen, niet alleen tijdens training.
Welke storingshistorie er ook bestaat — ook onvolledig bepaalt die wat geclaimd kan worden.

Vastgelegd in de schriftelijke offerte

Panel-pc’s, tablets, servers en GPU-servers
Camera’s, lenzen, verlichting en behuizingen
Scanners, printers, RFID-apparatuur, meters en sensoren
Reizen, installatie, transport, invoerrechten en lokaal elektrotechnisch werk
Of hardware wordt gehuurd of gekocht
Of een PoC-bedrag wordt verrekend met een uitrol

Commerciële voorwaarden, eigendom van hardware, reizen, integratiescope en een eventuele verrekening met de uitrol worden vastgelegd in de schriftelijke PoC-offerte. Ze zijn niet voor elk product gelijk en deze pagina belooft ze niet.

Wat u aan het eind krijgt

Een levend onderhoudsproces dat uw team gebruikt bij echte storingen.
Geconfigureerde assethiërarchie, kriticiteit en preventieve plannen.
Dashboard met nulmeting versus pilotperiode op de afgesproken KPI-definities.
Sensorbevindingen en een beoordeling van de databasis waar conditiebewaking binnen scope viel.
Kriticiteits- en hiatenrapport — wat de pilot niet kon dekken en waarom.
Uitrolplan voor de resterende assets en teams.

Randvoorwaarden, uitsluitingen en grenzen

Deze PoC is afhankelijk van

Beschikbaarheid van technici tijdens de liveperiode, ook op de ploegen waar daadwerkelijk storingen optreden.
Voor conditiebewaking: veilige montagepunten en voldoende observatietijd om de data betekenis te geven.

Niet inbegrepen in deze PoC

Fabrieksbrede opschoning van assetdata en digitalisering van historische registraties.
Inkoop van reserveonderdelen en magazijnimplementatie, dat is de WMS-PoC.

Wat deze PoC niet beweert

Waar gelabelde storingshistorie of voldoende observatiedata ontbreekt, wordt deze PoC gepositioneerd als conditiebewaking, afwijkingsdetectie en opbouw van een databasis — niet als storingsvoorspelling. Een voorspellingsclaim zonder storingen om van te leren is geen claim, maar een hoop.

Doorgaan, bijstellen of stoppen: het beslismoment

DoorgaanDoorgaan: het proces houdt stand onder reële omstandigheden en de gemeten hiaten rechtvaardigen uitrol naar de overige assets.

BijstellenBijstellen: naleving of assetdata moet eerst worden verbeterd; het hiatenrapport is het werkpakket.

StoppenStoppen: de restrictie is onderhoudscapaciteit of beschikbaarheid van reserveonderdelen — een systeem maakt dit zichtbaar, maar lost het niet op.

Veelgestelde vragen

Kunnen jullie voorspellend onderhoud bewijzen in een PoC?

Alleen waar voldoende gelabelde storingshistorie en een voldoende lang observatievenster bestaan, en beide worden gecontroleerd voordat er iets wordt beloofd. Ontbreekt dit, dan is het eerlijke programma conditiebewaking plus het opbouwen van de databasis die een latere voorspelling later mogelijk maakt.

Hebben we sensoren nodig?

Niet voor de proceskant van deze PoC, waar het grootste deel van de meetbare waarde ligt. Sensoren worden toegevoegd voor specifieke, in de verkenningsfase afgesproken conditiebewakingscasussen, op specifieke assets, voor een specifieke vraag.

Onze storingshistorie staat in notitieboekjes. Is dat een blokkade?

Nee, en dat komt heel vaak voor. Het beperkt wat over voorspelling geclaimd kan worden, niet wat gemeten kan worden over reactie, naleving en herhaalde storingen. De PoC start de gestructureerde historie die een latere voorspellingsstap zou nodig hebben.

Hoe meten jullie MTTR eerlijk ten opzichte van ons huidige cijfer?

Door de definitie in de verkenningsfase af te spreken, inclusief wat telt als start, wat telt als einde, en welke stilstanden worden uitgesloten. Twee organisaties kunnen MTTR op drie verschillende manieren meten; de vergelijking is alleen eerlijk als beide partijen dezelfde definitie gebruiken.

Bijbehorende producten en PoC-programma’s

Deze Proof of Concept aanvragen

Vertel welke scope u voor ogen heeft, dan komen wij terug met een schriftelijk PoC-plan: wat er gekoppeld wordt, wat u aanlevert, hoe succes wordt gemeten en hoe de beslissing aan het eind eruitziet.