Asset Management

Fortatter:
Jesper Pedersen
Advisory Key Expert, Maintenance & Integrity
Siemens Gamesa Renewable Energy A/S

Hvordan opretter man et enhedsregister?

Hvornår var det nu lige vi skiftede fødepumpen der sidder til højre inde i det lille skur bag tankene? Og var det kun pumpen - eller også motoren og koblingen?
Hvis dette lyder som en velkendt spørgsmål på værkstedet eller kontoret, så er ovenstående hændelse måske ikke registreret i vedligeholdssystemet. Oven i købet har man måske heller ikke helt styr på hvilken pumpe der er til højre og venstre i skuret - eller for den sags skyld i systemet. Så hvordan får man styr på det?
I forrige artikel skrev jeg om datakvalitet i vedligeholdssystemer set fra et overordnet perspektiv. Denne gang vil jeg prøve at blive lidt mere konkret omkring vedligeholdsinformation og hvordan man kan strukturere mængder af data. Som vi allerede ved er en af de fundamentale elementer/byggesten i pyramiden fra artikel 1 et enhedsregister, dvs. en oversigt over installerede aktiver.
Hvis vi fortsætter med eksemplet foroven, som kunne være fødepumper til vandforsyningen på en fabrik. Tre pumper som fælles udfører samme funktion, nemlig at levere et vist flow ved et givent tryk. Nogle gange kører kun en af pumperne for at holde trykket i anlægget oppe, mens andre driftssitautioner betyder et højt forbrug og at alle tre pumper kører ved fuld kapacitet. Så hvordan får man afspejlet disse pumper i IT-systemet på en måde så det giver mening for driften og vedligeholderne?
Man bør starte med en logisk nedbrydning af systemet og dets funktioner. Når man har kortlagt alle relevante funktioner kan man dernæst begynde at bryde det ned i mindre komponenter. Hvis hver pumpeenhed består af selve pumpehuset og en elmotor, og man kan skifte disse komponenter uafhængigt af hinanden, giver det mening rent teknisk at definere disse hver for sig. Hvis det er en sammenbygget enhed og man ikke kan skifte komponenterne indbyrdes, vil det sikkert ikke give mening at skelne mellem den ene eller den anden. Hverken set ud fra et økonomisk eller teknisk synspunkt.
Hvis pumperne er koblet op med frekvensomformer, så kan man oprette denne samt enhedens software som funktioner i sit enhedsregister. Dermed kan man holde styr på både installeret hard- og software. Dette kan være meget nyttigt, eksempelvis i forbindelse med fejlfinding og hvis man ikke umiddelbart har mulighed for at gå hen og kontrollere det.

Nedenstående er 5 steps man altid bør overveje:
1. Forstå hvorfor du behøver et enhedsregister og hvad det skal bruges til.
Ofte tager vi et hierarki for givet, da de fleste virksomheder allerede har det i en vis form. Men hvis man ikke gør sig klart hvad det skal bruges til, så er der en reel risiko for at registeret ikke dækker fremtidige behov.
Kunder eller interessenter til et enhedsregister er mange og herunder er blot et udpluk:
Vedligeholdsingeniører bruger registret til at oprette vedligeholdsplaner og aktiviteter til systemer og udstyr.
Kommercielt bruges registret koblet med vedligeholdstyper som en effektiv metode til at skabe transparens. Med andre ord, hvor er vedligeholdsbudgettet forbrugt og til hvilke aktiviteter?
Driftspersonalet udnytter registret til nemt at identificere udstyr med nummer, navn samt lokation.
Registeret muliggør en hurtig søgning i historikken på aktiverne.
Hvis det er rigtigt sat op, så er det muligt at benchmarke anlæg op mod hinanden.

2. Opret et logisk hierarki over aktiverne.
Nøglen til et brugervenligt register er at arbejde med hierarkier og systemer. Dette har flere fordele, da man kan ’folde’ sit register ud og lede efter aktivet hvis man ikke lige kender det eksakte nummer. Desuden kan man gruppere aktiver som rent funktionelt eller fysisk udgør systemer.
En udbredt metode til at strukturere sit hierarki kommer fra olie/gas standarden ISO 14224, hvor niveauinddelingen vises herunder:
Hvis man ikke umiddelbart vurderer at ens aktiver kan struktureres efter ovenstående principper, så kan 81346 betragtes som mere universelle principper man kan følge. Denne standard udstikker principper omkring funktionelle systemer og objekter i det samme. Sådan en tankegang spiller rigtig godt sammen med disciplinen Systems Engineering samt filosofien bag RCM, hvor man netop har fokus på igennem vedligehold at opretholde funktionerne i et system.
Nogle brancher er så heldige at der er lavet afsnit i 81346 som behandler netop deres felt, dette gælder eksempelvis elproducerende anlæg (kraftværker). Dette kaldes i daglig tale for RDS-PP (Reference Designation System - Power Plants). Fordelene ved at adoptere sådanne guidelines er at en stor del af arbejdet med at definere systemer og relevante funktioner allerede er gjort, så man behøver ikke opfinde hjulet igen.

3. Opret et struktureret og letforståeligt nummersystem samt navnekonventioner.
En vigtig overvejelse handler om navngivning samt nummerering af aktiverne. Grundlæggende bør det naturligvis være til at forstå og huske. Man kan godt strukturere sit system alene efter principperne i pkt. 2, men det vil kun øge brugervenligheden at kombinere dette med sigende navne.
Et eksempel på en fornuftig kodestruktur kender jeg fra vindbranchen, hvor vi også bruger RDS-PP, som er alfanumeriske koder og bygger på principperne fra 81346:
AANNNN = ANNN AAANN AANNN - AANNN AANNN
Dette er måske lidt volapyk, men herunder er en forklaring på hvilke dele af et anlæg enkeltdelene repræsenterer:
AANNNN: land og site (vindmølleparken)
NNN: Hovedsystem (eksempelvis en af møllerne i parken eller en substation)
AAANN: System og undersystem (oliesystemet til gearkassen)
AANNN: Basal funktion (pumpeenheden i ovenstående oliesystem)
AANNN: Enhed (motoren på ovenstående pumpeenhed)
AANNN: Komponent (klemkassen på ovennævnte motor)
Den sidste del af koden, komponent, har jeg endnu ikke set nødvendig at anvende. Men hvis man har at gøre med komplekse systemer og ønsker en høj grad af sporbarhed, så kan det give mening at gøre brug af det niveau også.
Hvis man opretter sådanne nummerkoder i sit system, så er det naturligvis altafgørende at disse er en hjælp for både kontorfolket men også teknikeren der arbejder på udstyret. Med andre ord, hvis der ikke er overensstemmelse mellem tagging i systemet og virkeligheden, så opnår man formentligt ikke det man ønsker.

4. Forstå og definer forskellene mellem funktioner, lokationer samt udstyr og komponenter.
Vedligeholds- og ERP-systemer skelner ofte mellem forskellige aspekter af ens aktiver. Dette kan være systemernes funktion, lokation og det man ofte kalder udstyr (equipment).
For at forstå hvordan disse adskiller sig fra hinanden kan vi kaste et blik på eksemplet fra pkt. 3 herover. Hvis man blot ønsker at registrere omkostninger og hvilken type vedligehold der er udført, så kan man med fordel gøre det på lokationen, systemet eller helt ned på den enkelte enhed.
Hvis man derimod ønsker at registrere hvad der er er sket med den fysiske enhed (i dette tilfælde pumpen) uanset hvor den er installeret, så er man nødt til at kreere et separat nummersystem for dette. Sådanne behov opstår som regel for relativt dyrt udstyr man ønsker at overhale og evt. installere på en anden lokation senere.

5. Indsaml og gem kun den information I faktisk vil bruge.
Størstedelen af vedligeholdssystemer har kapacitet til at lagre en masse information vedrørende aktiverne. Det tager dog lang tid at udfylde all felter, og den tid kan nogle gange være spildt, hvis man aldrig rigtigt får brug for det under driftsfasen. Eksempelvis giver det ikke meget mening at registrere garantiinformation hvis man ikke har systemerne til at registrere at komponenten rent faktisk er fundet defekt under garantiperioden og dernæst initiere en reklamationsproces.
Ambitionsniveau er altafgørende for hvordan man strukturerer sine data. Hvis man ‘blot’ ønsker at holde maskineriet kørende og nedetid ikke betyder så meget, så kan man godt nøjes med en meget simpel datastruktur. Med andre ord så skal man ikke bygge et stort garageanlæg hvis ens primære transportform er en cykel.
Hvis man derimod ønsker at arbejde med løbende optimering af drift og vedligehold, så kan betydningen af et ordentligt enhedsregister næsten ikke understreges nok. Denne oversigt over aktiverne bør naturligvis skabes i forbindelse med at man designer/specificerer og indkører et anlæg - ikke først når tingene er begyndt at fejle...
DDV, Den Danske Vedligeholdsforening har en række netværk, som løbende berører aktuelle emner.
Læs evt. mere om netværket på:
http://ddv.org/netvaerk