Hvad kan et vedligeholdssystem og får du det ud af det du skal…
Når jeg skal forklare udenforstående hvad man bruger sit vedligeholdssystem til, ender jeg ofte med at sige: planlægge vedligeholdet. Men det er naturligvis meget mere end det. En lidt bedre term er måske at sige: Her styrer vi vedligeholdet. I dette opslag vil jeg tage nogle af de moduler vi kender fra vores CMMS og kigge lidt på hvordan vi bruger det og effekten. Det er igen ud fra præmissen omkring behovet.
Anlægsregister:
Beskrivelse: Vores anlægsregister skal give os overblikket over vores ”fabrik”. Dette er vores spejlbillede af virkeligheden, hvor vi kan søge viden om udstyret. Her er et hierarkibaseret overblik over hele produktionslinjer, enkelte maskiner og ned til de enkelte komponenter på udstyret. Det er stammen i vores system, der er her vi binder de yderligere attributter op til.
Udfordringer: Dette er som sagt vores stamme på vedligeholdssystemet. Så vi kunne kalde det stamdata eller master data. Det er her vi har vores anlæg i dataform. De data skal være korrekte og indeholde opdateret information om udstyret. Det kan selv fra udstyrets fødsel være svært at have korrekt data i systemet. Et eksempel kunne være at man modtager As-built dokumentation før de sidste tests er afsluttet og der oplever nogle ting, som man retter til, men ikke får rettet i anlægsdokumentationen i CMMS. Derefter går vi i drift med udstyret og får lavet nogle forbedringsprojekter i opstartsfasen. Du kender måske denne historie… Der er i hvert fald mulighed nok for, at anlægsdokumentationen ikke er helt up to date når vi skal bruge den. Vi kan også opleve at komponenter opdateres over tid og tagnummerering skrider. Der er behov for at disse master data vedligeholdes.
Arbejdsopgaver:
Beskrivelse: Vores forebyggende vedligehold skal være i systemet. Her bør der være en skabelon der bliver kaldt ud i vores vedligeholdsstyring, som en arbejdsopgave. Den enkelte opgave skal indeholde hvad der skal gøres, hvor og hvornår det skal udføres og hvad der skal til, såsom eksterne resurser, reservedele eller special værktøjer osv.
Udfordringer: Den største bekymring jeg ser, er muligheden for at gøre det ordentligt. Det der alt for ofte sker er, at man har noget udstyr og benytter udstyrsleverandørens anbefalinger 1:1. Man får ikke lavet en vurdering af hvor kritisk udstyret er og den operative kontekst. Dette leder til en masse vedligehold, der ikke er nødvendigt, eller i den anden grøft ikke nok vedligehold og med et havari til følge.
Arbejdsordrer:
Beskrivelse: Dette er her vi planlægger vores vedligehold. Det er her de fleste er mest hjemmevant. Det er også her de flest arbejder i systemet. Nogle trækker deres jobkort ud, andre lukker opgaver og nogle opretter nye arbejdsordrer.
Udfordringer: Med mange der har adgang til dette modul, giver det større risiko for at få lavet fejl. Eks. lukke opgaver der ikke er udført, oprette jobkort på forkerte anlægsaktiver osv. Her er det særligt vigtigt at dem der har adgang til systemet også er trænet i brugen og kender til risikoen. Det er desuden vigtigt at kun dem der har behov for adgang, har adgang. Flere med adgang er mere masterdata der skal vedligeholdes.
Historik:
Beskrivelse: Dette modul gemmer historikken på udstyret. Det er denne data der bruges til at lave analyser og rapporter med til optimering af vedligeholdet.
Udfordringer: Historikken i systemet er produkt af det indtastede. Så her er det især vigtigt at påpege at kommer der dårlige data ind så får man dårlige analyser ud af det. Det er især vigtigt at påpege at man igen kun spørger efter det man gerne vil vide. Da desto større indtastninger man spørger efter desto større er risikoen for at man ”glemmer” at indtaste.
Arbejdsleverandører:
Beskrivelse: Dette modul finder man data på sine leverandører af arbejde. Det er de interne resurser og eksterne samarbejdspartnere. De enkelte leverandører kan også indgå i grupper så arbejde kan fordeles til hele gruppen ved planlægning af arbejde.
Udfordringer: Arbejdsleverandørerne er masterdata, der skal opdateres og holdes vedlige. Der kan også i implementeringen være inkluderet sensitive data, både fra interne medarbejdere, hvor det kan være personfølsomdata, eller fra eksterne leverandører hvor det kan være fortrolige oplysninger inkluderet. Vær opmærksom på det.
Reservedele:
Beskrivelse: Her har vi masterdata på vores enkelte reservedele. Det indeholder oplysninger omkring delen, producent, leverandør, specifikationer og så har de en masse link rundt i systemet til andre moduler. Dette kan være link til komponenter, som sagt leverandører, lagerstyringsmodulet og masterdata til/fra ERP-systemet for indkøb.
Udfordringer: Alle disse link til øvrige moduler kan skabe mange konflikter i databasen hvis ikke der holdes styr på data og relationer.
Lagerstyring:
Beskrivelse: I dette modul styrer man primært reservedele. Her har man lagerlokaliteter og mængder og evt. genbestillingstidspunkter mm.
Udfordringer: I dette modul oplever man ofte udfordringer med opdatering af mængder af eksisterende dele og derudover kommer der hele tiden nye dele til der skal registreres.
Resurseplanlægning:
Beskrivelse: Dette modul er oftest noget der er et tillæg til mange CMMS/EAM. Dette er modulet hvor man kan vurdere arbejdsmængden og opgavemængden fra dag til dag og over tid. Dette kræver noget data omkring de arbejdsopgaver der skal udføres, især forventet tidsforbrug.
Udfordringer: Da dette er et analyseværktøj, der benytter data fra øvrige moduler, oplever man at værktøjet kun hjælper og kan bruges i det omfang at datakvaliteten er brugbar. Igen ”Garbage in – Garbage out”.
Der er mange flere moduler og interaktioner mellem de forskellige moduler som jeg ikke har nævnt.
Hvis du er kommet helt her til så vil jeg spørge:
Hvilke moduler bruger du? Og synes du får nok ud af dit CMMS? Kommenter her i bloggen eller kontakt mig på SoMe eller ring.
Stenderup Pedersen 