För att skapa ett system med hög operationell tillgänglighet behöver vi, som beskrivits i tidigare blogginlägg, både ha ett tekniskt system och ett underhållssystem som tillsammans kan åstadkomma den önskade operationella tillgängligheten. Det ställer krav på det tekniska systemets inneboende tillgänglighet (Ai) men också på underhållssystemets förmågor. Vi behöver då ta hänsyn till såväl det tekniska systemets driftprofil som befintligt underhållskoncept. Genom ett antal analyser kan vi få fram kraven på underhållslösningens olika komponenter och påverka den tekniska lösningens RAM-egenskaper så att tillgänglighetskravet kan mötas. Med målet att uppnå denna tillgänglighet på ett så kostnadseffektivt sätt som möjligt behöver vi hitta den lösning som ger lägst livscykelkostnad.
I takt med att fler och fler system blir uppkopplade kan vissa analyser ersättas av erfarenhetsdata. Framförallt gäller det RAM-egenskaperna hos det tekniska systemet, men det finns även möjligheter att registrera och analysera ex.vis verkstadsdata, hanteringstider för reservdelar m.m. Det viktiga här är inte hur, utan att, informationen tas fram och används för att utveckla underhållslösningen.
Utifrån beskrivningarna av ILS, LSA och underhållslösning som gjorts i tidigare blogginlägg kan nedanstående övergripande RAM-processbild formas. Även om beskrivningen är linjär sker en kontinuerlig feed-back och förfining av såväl den tekniska lösningen som underhållslösningen efterhand som dessa utvecklas.
Översiktlig RAM-process
Design Influence
Baserat på kontraktuella krav och givna förutsättningar som driftprofil och underhållskoncept görs analyser av existerande systemlösningar för att se hur de övergripande tillgänglighetskraven möts. Dessa analyser omfattar, utöver funktions- och andra egenskapskrav, såväl RAM-egenskaperna hos det tekniska systemet som befintlig underhållslösning. Behov av nyutveckling dokumenteras. Alternativa lösningar analyseras. När analyserna ger vid handen att det finns en möjlig systemlösning som tillgodoser kraven kan systemkravspecifikationen frysas.
Viktigt här är att ta med kraven för hela systemet och inte bara för det tekniska systemet. Det är ju, som vi diskuterat tidigare, genom en kombination av det tekniska systemets egenskaper och underhållslösningens dito som den operationella tillgängligheten uppnås. Den vanligaste typen av produktutveckling handlar om att vidareutveckla redan befintliga system. Att lägga till ytterligare funktionalitet eller ett nytt gränssnitt. Att förbättra ett befintligt systems prestanda. Därmed kan produkt- och systemutveckling också handla om att förbättra underhållslösningen. Alltifrån bättre inbyggd felutpekning (testability) i det tekniska systemet till bättre underhållsmetoder.
Candidate Identification
Det fortsatta RAM-arbetet baseras på det tekniska systemets nedbrytning. Möjligheterna att utföra underhållsåtgärder på systemet kommer ju att se helt olika ut om hela systemet är en monolit eller om det är modulärt uppbyggt. Vi tar fram kandidater för det fortsatta analysarbetet baserat på urvalskriterier; hur djupt ska analysen gå för att kunna identifiera alla reservdelar, vilka analyser behöver göras på respektive komponent, är någon komponent extra kritisk ur tillgänglighetssynpunkt, är någon komponent extra utsatt för potentiell skada, etc.
Tidigast här kan systemarkitekturen frysas.
Task Identification
Genom analyser (Scheduled maintenance analysis, Damage & special event analysis, Operations analysis, Software support analysis) identifieras de underhållsåtgärder som finns för det tekniska systemet – såväl förebyggande som avhjälpande. En LSA-FMEA kan utföras som skiljer sig från design-FMECA i det att olika felmoder kan grupperas ihop om de leder till samma underhållsåtgärd.
Maintenance Planning
Efter att underhållsåtgärderna har identifierats utvecklas underhållsplanen genom Maintenance task analysis och Level of repair analysis (LORA). Behovet av utbildning analyseras genom en Training needs analysis.
Support Solution Development
Slutligen tas alla komponenter som utgör underhållslösningen fram; teknisk dokumentation, utbildning, försörjning av reservdelar och förbrukningsvaror, personal, datorresurser, faciliteter, hanterings- och förpackningslösningar, support- och testutrustning. Här kan olika aktörer vara inblandade: systemleverantören kanske ansvarar för att ta fram teknisk dokumentation, utbildning, o.s.v. medan kunden upphandlar en underhållsleverantör som har personal och faciliteter. Datorresurser finns ofta hos flera aktörer; övergripande underhållsplanering sker i kundens system, leverantören har sitt uppföljningssystem och underhållsleverantören jobbar i sitt eget system mot flera kunder. Ofta knyts dessa system ihop på något sätt, genom mer eller mindre sofistikerad dataöverföring.
Vill man jobba riktigt strukturerat kan man med fördel ta fram en kravspecifikation för underhållslösningen baserat på samtliga analyser som genomförts.
Livscykelkostnad
Under systemets hela livslängd byggs livscykelkostnadsmodellen på med data. Analyser görs på alternativa lösningar för att minimera livscykelkostnaden. Är det bättre, ur ett livscykelkostnadsperspektiv, att konstruera det tekniska systemet så att färre underhållsåtgärder behövs? Kan vi öka intervallet mellan förebyggande underhållsåtgärder eller riskerar vi då dyra stoppande fel? (Stoppande fel kan i LCC-modellen ansättas kostnader i form av förlorade intäkter, hyra av ersättningslok för att klara produktionen, etc. Traditionellt räknas dock enbart direkta kostnader i form av reparationskostnader. Detta riskerar dock därigenom att underskatta kostnaden för avhjälpande underhåll.)