Kehittyvä kunnossapito ohjelma (Julkaistu Kunnossapito 5/2006)

Transkriptio

1 Kehittyvä kunnossapito ohjelma (Julkaistu Kunnossapito 5/2006) Susanna Kunttu VTT Toni Ahonen VTT Jouko Heikkilä VTT Kunnossapidon tulee kehittyä saatujen kokemusten myötä ja vastata järjestelmässä tapahtuviin muutoksiin. Miten voidaan varmistaa, että käytettävä kunnossapito ohjelma vastaa nykyisiä kunnossapitotarpeita? Kokemuksia tarkasteltavasta järjestelmästä kerääntyy erilaisiin tietojärjestelmiin sekä käyttäjille ja kunnossapitäjille. Näiden kaikkien tietojen hyödyntäminen vaatii sekä kvantitatiivisten että kvalitatiivisten analyysimenetelmien hyödyntämistä. 1. Johdanto Optimaalisessa tilanteessa uuden järjestelmän kunnossapito ohjelman olisivat suunnitelleet laitetoimittaja ja käyttäjä yhdessä hyödyntäen soveltuvaa järjestelmällistä lähestymistapaa, esim. RCM. Lisäksi suunnitteluvaiheessa olisi käytössä laitetoimittajan eri laitoksilta keräämään aineistoon pohjautuvat vikajakaumat yksittäisille komponenteille. Uuden laitoksen käyttöönoton jälkeen kerätään kyseiseltä laitokselta kaikki kunnossapito ja käyttövarmuustieto komponenttitasolla määrämuotoisena tietokantaan. Tällöin ensimmäinen kunnossapito ohjelma on sellaisenaan käyttöönotettavissa ja myöhemmin kunnossapito ohjelman päivittämiseen tarvittavat tiedot olisivat yhdestä paikasta saatavilla, jolloin päivittäminen olisi mahdollista jopa osittain automatisoida. Käytännön kokemukset ovat osoittaneet, että edellä kuvatusta tilanteesta ollaan todellisuudessa vielä kaukana. Kunnossapito ohjelman päivittäminen on monivaiheinen prosessi, jossa tilanteen mukaan käytetään erilaisia menetelmiä. Tässä artikkelissa kuvataan Teollisuuden käynnissäpidon prognostiikka hankkeessa sovellettua lähestymistapaa, jossa keskeisenä ajatuksena on hyödyntää mahdollisimman laajasti tarkasteltavasta järjestelmästä olevaa tietoa soveltaen sekä kvantitatiivisia että kvalitatiivisia menetelmiä. Kuvassa 1 on esitetty pääpiirteissään käytetyn kunnossapitoohjelman kehitysvaiheet.

2 Kertyvä käyttökokemusdata kunnossapitohistoria ja tehdyt toimet TIETOJEN KUNNOSSAPITO YHDISTÄ MINEN Järjestelmän tavoitteet ja reunaehdot Laitevalmistajien ennusteet toimitettujen laitteiden kunnossapitotarpeista OHJELMA Laitekohtainen mittaustieto, prosessidata Järjestelmän rakenne Käyttöennuste Kunnossapitoohjelman päivittäminen Uudet ennusteet, mm. vikaantuvat kohteet kunnossapitokustannukset ennakoivan kunnossapidon tarve korjaavan kunnossapidon tarve Kunnossapitotoimet Kuva 1. Kunnossapito ohjelman kehittyminen (Kunttu&Kortelainen, 2004) Tässä artikkelissa kunnossapito ohjelmalla tarkoitetaan dokumenttia, jossa määritetään laitetasolla jokaiselle järjestelmän osalle soveltuva kunnossapitotehtävä; kuntoon tai aikaan perustuva ennakoiva kunnossapito tai korjaava kunnossapito. Ohjelmassa määritetään myös tarkemmin miten kohteen kuntoa valvotaan, esim. öljyanalyysit tai silmämääräiset tarkastukset, tai millaisin väliajoin aikaan perustuvaa kunnossapitoa tehdään. 2. Kunnossapito ohjelman päivittämisen vaiheet Kunnossapito ohjelman päivittämiseen sisältyvät vaiheet ja soveltuvat menetelmät riippuvat pitkälti kohteesta. Ensimmäistä systemaattista kunnossapito ohjelman päivitystä tehtäessä lähtökohtana on usein laitetoimittajan tekemä kunnossapito ohjelma, jota käyttäjät ovat muokanneet kokemustensa perusteella paremmin kyseiselle laitokselle soveltuvaksi. Tällöin osana kunnossapidon päivittämistä on tehdä vertailua laitetoimittajan ja käytössä olevan ohjelman välillä ja analysoida havaittuja eroja. Näin voidaan perustellusti poimia molemmista parhaat osat päivitettyyn kunnossapito ohjelmaan. Merkittävän järjestelmämuutoksen jälkeen ollaan tilanteessa, jossa tilastoitu vika aineisto kuvaa ensisijaisesti vanhaa järjestelmää, eikä uudesta vielä ole kokemuksia. Tällöin kannattaa ensisijaisesti käyttää kvalitatiivisia menetelmiä, kuten RCM, ainakin eniten muuttuneissa järjestelmän osissa. Näin saadaan selville mahdolliset vikamuodot ja niiden ehkäisyyn soveltuvat toimet. Toki tilastotietoja vanhasta järjestelmästä kannattaa soveltuvin osin käyttää tukena tässä työssä. Haluttaessa päivittää pääpiirteissään samanlaisena pysyneen järjestelmän kunnossapitoa voidaan pääasiallisesti käyttää kvantitatiivisia menetelmiä, joilla mallinnetaan esimerkiksi komponenttien vikajakaumia tai osajärjestelmien vikavälejä. Tämä edellyttää luonnollisesti sitä, että kunnossapidon tietojärjestelmistä on saatavissa riittävän kattavasti tietoja vikaantumisista. Jossain määrin puutteita tilastotiedoissa voidaan korvata asiantuntija arvioilla.

3 Kunnossapidon päivittäminen voi perustua esimerkiksi seuraavaan järjestelmälliseen etenemistapaan: 1. Valmistajan ja järjestelmän käyttäjän kunnossapito ohjelmien vertailu sekä havaittujen erojen, syiden ja vaikutusten analysointi 2. Vastaaminen järjestelmän muutosten aiheuttamiin uusiin kunnossapidon vaatimuksiin RCM menettelyn hyödyntämisellä 3. Vikatilastoinnin ja kunnossapidon kirjausten käyttö kunnossapidon muutosten tekemiseen Yllä olevien vaiheiden painoarvo ja järjestyskin voivat vaihdella kohteen tarpeiden mukaan Kunnossapito ohjelmien vertailu Uuden kohteen, tehtaan tai yksittäisen laitteen, kunnossapito ohjelma pohjautuu usein laitevalmistajan suosituksiin. Käytännössä kunnossapito ohjelma kehittyy koko ajan. Kunnossapitäjät ja käyttäjät muokkaavat laitevalmistajan kunnossapito ohjelmaa kyseiselle kohteelle sopivaksi jokapäiväisessä työssään saamiensa kokemusten perusteella. Vastaavasti päivitettyä kunnossapito ohjelmaa muokataan myöhemminkin järjestelmän ikääntyessä tai kunnossapitotarpeiden muutoin muuttuessa. Aika ajoin ja erityisesti suurempien muutosten jälkeen onkin tarpeellista arvioida järjestelmällisesti käytössä olevan kunnossapito ohjelman soveltuvuus nykytilanteeseen. Kunnossapidon kehittäminen on tehtävä yhteistyössä käyttäjien ja kunnossapitäjien kanssa. Heillä on paras tieto käytännön kunnossapidosta. Työpajatyöskentely (workshop) on osoittautunut hyväksi menetelmäksi tehdä yhteistyötä käyttäjien ja kunnossapitäjien kanssa. Lyhyesti kuvattuna työpajatyöskentely on ohjattua ja tavoitteellista keskustelua yhteisesti sovitusta aiheesta. Työpajojen sisältö luonnollisesti vaihtelee tilanteen mukaan. Yhteistä kuitenkin on se, että vetäjä muodostaa selkeät tavoitteet jokaiselle työpajalle ja suunnittelee kokoontumisten asialistan sen pohjalta. Ennen työskentelyn aloittamista tavoitteet ja asialista esitellään kaikille osallistujille. Kokemusten mukaan toimivin ratkaisu kunnossapidon kehittämiseen liittyvässä työpajatyöskentelyssä on osajärjestelmäkohtainen käsittely, jossa yhdistyy seuraavat tekijät: käyttäjien ja kunnossapitäjien kokemukset järjestelmästä nykyisten ennakkohuoltotoimenpiteiden käsittely uusien tilanteiden ja kunnossapidon vaatimusten huomiointi (uusi teknologia, uudet komponentit/järjestelyt) Työpajatyöskentely yhdistää edellä mainitut toisistaan poikkeavat lähteet ja lähestymistavat tavoitteen mukaisesti. Olennainen osa työpajatyöskentelyä on keskustelun dokumentointi. Kunnollinen dokumentointi sisältää ainakin tehdyt päätökset ja niiden perusteet. Etukäteen tehdyllä lomakepohjalla voi helpottaa olennaisen sisällön tallentamista käydystä keskustelusta. Hyvin suunniteltu lomake myös osaltaan edesauttaa sitä, että kaikki merkittävät asiat tulevat läpikäytyä ja kirjattua muistiin. Mitä paremmin työpajassa käsitellyt asiat dokumentoidaan, sitä paremmin ne ovat hyödynnettävissä seuraavalla kerralla kunnossapito ohjelmaa päivitettäessä Järjestelmämuutosten käsittely Järjestelmään tehtyjen merkittävien muutosten osalta kunnossapito on suunniteltava samaan tapaan kuin uudelle järjestelmälle. Eli lähtökohdaksi on otettava mahdolliset vikamuodot. Mitä paremmin

4 tiedetään mahdolliset viat ja niiden syyt, sitä paremmin voidaan löytää oikeat kunnossapitokeinot näiden ehkäisemiseksi ja toisaalta jättää turhat toimet pois. Esimerkiksi määräaikaistarkastuksia on helppo löytää pitkä lista, mutta ilman mahdollisten vikamuotojen tuntemista osa tarkastuksista saattaa olla turhia. Kattavaksi koetun tarkastuslistan noudattaminen voikin osoittautua resurssien hukkaamiseksi. Vika ja vaikutusanalyysi (VVA, eng. FMEA) on yksi hyväksi koettu menetelmä teknisen järjestelmän mahdollisten vikojen, niiden syiden ja seurausten tunnistamiseen. Hyvin tehdyn ja dokumentoidun VVA:n tuloksia voidaan hyödyntää myöhemminkin, eikä sitä tarvitse tehdä samassa laajuudessa jokaisen kunnossapito ohjelman päivityksen yhteydessä. Kunnossapidon toimien mitoittaminen oikein on olennainen osa onnistunutta kunnossapitoohjelmaa. Seurauksiltaan vähäisen vian ehkäisemiseen ei kannata panostaa mittavalla ennakoivalla kunnossapidolla vaan kannattavampaa voi olla valita korjaava kunnossapito. Yksittäisen vian seurausten suuruuden lisäksi on huomioitava kyseisen vian esiintymistaajuus arvioitaessa vian aiheuttamaa haittaa. Mikäli vian seuraukset ovat pääasiassa tuotannollisia menetyksiä, voidaan vian aiheuttamat vuosikustannukset määrittämällä, saada arvio paljonko resursseja vian ehkäisemiseksi kannattaa käyttää. Tällaista kriittisyysanalyysiä on hyvin tuloksin hyödynnetty myös tärkeimpien kunnossapidon kehityskohteiden tunnistamisessa (Kunttu, et. al, 2004). VVA:ssa tunnistetuille vikamuodoille soveltuvien kunnossapitomenetelmien valintaan voidaan käyttää esimerkiksi Moubrayn (1997) esittelemää RCM päätöksentekologiikkaa (RCM; Reliability Centered Maintenance, luotettavuuskeskeinen kunnossapito). Logiikan avulla haetaan soveltuva kunnossapitomenetelmä sen mukaan jääkö vika piileväksi vai ei. Ei piileville vioille kunnossapitomenetelmä valitaan sen mukaan vaarantaako vika henkilö tai ympäristöturvallisuutta tai pienentääkö se käyttövarmuutta Vikatilastojen hyödyntäminen Tyypillisesti vikatilastoihin on tallennettu vian ajankohta ja vikaantunut kohde sekä lyhyt vapaamuotoinen kuvaus viasta. Vian ajankohdan perusteella voidaan määrittää komponenttien ja osajärjestelmien vikaantumistodennäköisyyksiä ajan funktiona. Tämä kuitenkin edellyttää sitä, että vikaantunut kohde on kirjattu riittävän tarkasti, jotta vika voidaan yhdistää oikeaan komponenttiin tai osajärjestelmään. Kvantitatiivisen analyysin tulokset tukevat kunnossapidon suunnittelua parhaiten määritettäessä komponenttien vaihtovälejä ja tunnistettaessa kriittisiä osajärjestelmiä. Otettaessa uutta järjestelmää käyttöön tai jos muutoin ei ole sopivaa aineistoa, esim. komponenttien vikajakaumien määrittämiseen, ensimmäiset estimaatit jakaumista voidaan muodostaa asiantuntija arvioiden pohjalta. Aineiston kertyessä näitä estimaatteja voidaan tarkentaa ja sen mukaan esimerkiksi muuttaa alkuperäistä aikaan perustuvan kunnossapidon väliä. Kuvassa 2 on esimerkki yksittäisen komponentin vikaantumistodennäköisyyden kasvusta käyttötuntien mukaan. Esimerkkitapauksessa on pyydetty asiantuntijoita arvioimaan komponentin kestoikää. Näistä arvioista muodostettua vikajakaumaa on sen jälkeen päivitetty todellisilla kestoajoilla. Tässä esimerkissä asiantuntijat antoivat hiukan pessimistisemmän kuvan komponentin kestosta kuin mitä se todellisuudesta kesti. Mikäli komponentin vikaantumistodennäköisyys halutaan pitää pienempänä kuin 20 %, niin vaihtovälin pituus saisi olla asiantuntija arvioiden mukaan korkeintaan 500 h ja todellisen aineiston perusteella 1000 h.

5 1 Vikaantumistodennäköisyys 0,8 0,6 0,4 0, Aika (h) Asiantuntija arvioihin ja dataan perustuva vikaantumisaikojen kertymäfunktio Asiantuntija arvioihin perustuva vikaantumisaikojen kertymäfunktio Kuva 2. Esimerkki yksittäisen komponentin vikaantumistodennäköisyyden kehityksestä Aina ei ole mahdollista eikä edes tarpeellista viedä tarkasteluja komponenttitasolle asti. Tällöin käytetään toisentyyppisiä tilastollisia malleja, jotka soveltuvat osajärjestelmätason tarkasteluihin. Osajärjestelmätasolla voidaan määrittää esimerkiksi keskimääräinen vikaväli tai odotettavissa olevien vikojen määrä tietyn tarkastelujakson, esim. vuoden, aikana. Vikatilastointia suunniteltaessa on aina määritettävä miten kertyvää aineistoa on tarkoitus käyttää. Jos tämä jää tekemättä on vaarana, että saatava aineisto ei sisälläkään tarvittavia muuttujia eikä haluttuja tunnuslukuja pystytä laskemaan. Kerättävän tiedon pitääkin määräytyä sen perusteella mitä tiedoista halutaan irti; ei sen perusteella, mitä on helpointa kerätä. Tiedonkeruun suunnittelu ja toteuttaminen on iso työ, mutta palkitsee hyödynnettävyyden helppoutena. Usein on kuitenkin niin, että tilastointi on puutteellista, koska kirjausten tekijät eivät koe tilastointia hyödylliseksi työksi. Kirjausten tekijöiden motivoimiseksi on heillekin näytettävä miten heidän keräämänsä aineistoa hyödynnetään ja miten se tukee esim. kunnossapidon suunnittelua. Asianmukaisesti suunnitellulla ja toteutetulla tiedonkeruulla saadaan tietovarasto, josta on varsin yksinkertaista laskea esimerkiksi eri osajärjestelmien käyttövarmuus, vikamuotojen aiheuttamat kustannukset, määrittää vikajakaumia ja niiden pohjalta ennusteita komponenttien eliniästä tai osajärjestelmien vikamääristä. Kerättävän vikatilaston hyödynnettävyyden määrittää pitkälle se miten hyvä järjestelmähierarkia ja vikaluokitus tietokantaan on pystytty muodostamaan. Hyväkään tietokantarakenne ei tietenkään takaa tilaston käytettävyyttä, jos kirjauksia tapahtuneista vioista ei tehdä riittävän kattavasti. 3. Yhteenveto Kunnossapito ohjelman päivittämisen työvaiheet määräytyvät varsin pitkälle tarkasteltavan kohteen mukaan. Merkittävien järjestelmämuutosten jälkeen kunnossapito on suunniteltava lähes vastaavalla tavalla kuin kokonaan uudelle järjestelmälle. Olennaisilta osiltaan samanlaisena pysyneen järjestelmän kunnossapito ohjelman päivittämisessä voidaan hyödyntää käytönaikana saatuja kokemuksia.

6 Kunnossapidon päivittämisessä voidaan käyttää sekä kvalitatiivisia että kvantitatiivisia menetelmiä riippuen saatavilla olevan tiedon laadusta ja määrästä. Mitä enemmän tilastoaineistoa on käytettävissä, sitä paremmin on mahdollista hyödyntää kvantitatiivisia menetelmiä. Systemaattisten menetelmien, olivat ne sitten kvantitatiivisia tai kvalitatiivisia, käytöllä varmistetaan järjestelmän läpikäynti riittävän kattavasti. Näin voidaan tehdä perusteltuja päätöksiä kunnossapidon kehittämiseksi. Lähdeviitteet Kunttu S., Tolonen S., Reunanen M. ja Valkokari P. (2004) Kunnossapidon kehityskohteiden tunnistaminen. Kunnossapito 8/2004. pp Kunttu S., Kortelainen H. (2004) Supporting Maintenance Decisions with Expert and Event data. Kunnossapito 3/2004. pp Moubray, J. (1997). RCM II, Reliability centred Maintenance, 2 nd edition.