Daugelyje gamybos įmonių techninė priežiūra veikia sklandžiai tol, kol operacijų mastas nepradeda išryškinti tam tikras ribas. Augantis įrenginių skaičius, didesnis spaudimas užtikrinti jų prieinamumą ir vis trumpesnis reakcijos laikas lemia tai, kad modelio, pagrįsto telefonų skambučiais, „MS Excel“ lentelėmis ir darbuotojų asmeninėmis žiniomis, nebepakanka.
Įmonė „Tatra Spring“ atsidūrė būtent tokioje situacijoje. Procesai egzistavo, tačiau jie buvo fragmentiški, sunkiai kontroliuojami ir didžiąja dalimi priklausomi nuo konkrečių asmenų patirties. Trūko vieningos sistemos, kuri leistų susisteminti užklausas, sukaupti gedimų istoriją ir atlikti realią techninės priežiūros skyriaus darbo analizę.
Todėl CMMS sistemos diegimas „Tatra Spring“ buvo natūralus žingsnis. Tačiau tikslas buvo ne tiesiog įdiegti įrankį, o pakeisti darbo pobūdį.
Organizacijos kontekstas ir atskaitos taškas „Tatra Spring“
„Tatra Spring“ yra gamykla, kurioje techninė priežiūra turi tiesioginę įtaką gamybos tęstinumui. Situacija, su kuria įmonė pradėjo projektą, nebuvo išskirtinė – daugelyje įmonių ji atrodo labai panašiai.
Procesai veikė, tačiau buvo išsibarstę ir sunkiai kontroliuojami:
- užklausos buvo teikiamos telefonu,
- ataskaitos daugiausia buvo popierinės,
- dokumentacija buvo iš dalies skaitmeninė, iš dalies fizinė,
- gedimų istorija egzistavo, bet ją buvo sunku atkurti,
- atsarginių dalių sandėlio valdymas rėmėsi „MS Excel“ lentelėmis ir vieno asmens žiniomis.
Operaciniu požiūriu tai reiškia viena: sistema veikia tol, kol darbuotojai yra pasiekiami ir prisimena, ką darė anksčiau. Padidėjus krūviui arba pasikeitus darbuotojams, prasideda problemos.
Kodėl CMMS buvo būtina?
Sprendimas diegti CMMS sistemą buvo priimtas ne dėl noro tiesiog atlikti patobulinimus, o dėl realių tuometinio darbo modelio ribotumų.
Techninės priežiūros komanda įvardijo kelias pagrindines problemas:
- Istorinių žinių trūkumas: Informacija apie gedimus buvo perduodama žodžiu arba užrašoma skirtingose vietose. Rezultatas – tos pačios problemos vėl ir vėl buvo analizuojamos nuo nulio.
- Ilgas remonto laikas: Istorijos ir veiklos standartų trūkumas reiškė ilgesnes prastovas. Kiekvienas sudėtingesnis gedimas reikalavo pakartotinės analizės.
- Chaosas gamybos užklausose: Užklausas buvo sunku sekti. Trūko informacijos, kurie pranešimai yra pagrįsti, o kurie atsiranda dėl operacinių klaidų.
- Neskaidrus sandėlis: Sandėlio likučiai buvo tvarkomi „MS Excel“ programoje. Žinios apie dalis buvo sutelktos vieno žmogaus rankose. Praktikoje tai reiškė prastovų riziką jam nesant darbe.
- Planinių patikrų trūkumas:Darbų planavimas buvo vykdomas„rankiniu“ būdu. Tvarkaraščius „MS Excel“ failuose reikėjo nuolat atnaujinti, juose pasitaikydavo klaidų.
- Efektyvumo rodiklių trūkumas: Komanda neturėjo įrankių, leidžiančių įvertinti, ar techninė priežiūra veikia optimaliai.
Kaip matyti, pagal ankstesnį modelį techninė priežiūra veikė reaktyviai ir nekontroliavo pagrindinių sričių – techninių žinių, užklausų bei dalių prieinamumo. Duomenų ir standartizacijos trūkumas tiesiogiai lėmė ilgesnes prastovas, pasikartojančias klaidas ir augančias operacines sąnaudas. Todėl CMMS diegimas buvo sprendimas sutvarkyti procesą ir susigrąžinti kontrolę, o ne tiesiog įvesti dar vieną įrankį.
Projekto prielaidos ir laukiami rezultatai
Diegimo tikslai buvo aiškiai apibrėžti ir išplaukė tiesiogiai iš operacinių problemų. Svarbiausi iš jų:
- perėjimas nuo popierinių prie skaitmeninių dokumentų,
- gedimų ir prastovų laiko sutrumpinimas,
- analitikos ir KPI (pagrindinių veiklos rodiklių) įvedimas techninės priežiūros skyriui,
- gamybos užklausų susisteminimas,
- komunikacijos tarp skyrių pagerinimas,
- sandėlio ir pirkimo procesų sutvarkymas,
- techninių žinių bazės sukūrimas.
Tai yra standartiniai CMMS sistemų tikslai, tačiau jų svarba auga didėjant gamybos mastui ir įrenginių parko sudėtingumui.
ZMT sistemos diegimo apimtis
CMMS diegimo projektas apėmė kelis pagrindinius komponentus, kurie kartu sudaro vientisą techninės priežiūros valdymo sistemą.
ZMT STD kaip sistemos branduolys
Centrinė CMMS sistema yra atsakinga už:
- užklausų registravimą,
- darbo užsakymų valdymą,
- turto apskaitą,
- gedimų ir veiksmų istoriją. Tai vieta, kurioje pradedama kurti sutvarkyta duomenų aplinka.
Modulis „eMobile“ kaip įrankis darbui lauko sąlygomis
Naudodamiesi „eMobile“ moduliu, mechanikai gavo prieigą prie sistemos per mobiliuosius įrenginius. Praktikoje tai užtikrina:
- prieigą prie užsakymų realiuoju laiku,
- galimybę iškart teikti ataskaitas apie atliktą darbą,
- popierinių ataskaitų atsisakymą.
NFC kaip planuojama prisijungimo funkcija
Buvo numatyta supaprastinti prisijungimą naudojant NFC technologiją. Ši funkcija turi pagreitinti darbą vietoje ir sumažinti sistemos įsisavinimo barjerus naudotojams.
„Scheduler“ darbų planavimui
Modulis „Scheduler“ yra atsakingas už:
- užduočių priskyrimą,
- komandos darbo planavimą,
- išteklių naudojimo optimizavimą.
SSO (Vieningas prisijungimas)
Tai vieninga prisijungimo prie sistemos sistema, kuri supaprastina prieigos valdymą ir padidina saugumą.
Diegimo realybė įmonėje „Tatra Spring“
Kiekvienas projektas atrodo gerai planavimo etape. Praktikoje iškyla dalykų, kurių neįmanoma numatyti 100 procentų. Šis atvejis nebuvo išimtis.
Prieiga prie IT infrastruktūros
Pagal planą, prieiga prie serverio turėjo būti suteikta po dviejų savaičių. Galiausiai tai užtruko šiek tiek ilgiau. Priežastis buvo tipiška didelėms organizacijoms – IT komanda buvo įsikūrusi ne gamykloje, o kitoje šalyje (šiuo atveju – Italijoje). Tai sukuria dvi problemas:
- ilgesnį reakcijos laiką,
- tiesioginės įtakos sprendimams nebuvimą. Praktikoje tai reiškia, kad diegimo grafikas nebėra visiškai priklausomas nuo projektų komandos.
NFC ir sistemos versijos problema
NFC prisijungimo funkcija buvo parduota kaip sprendimo dalis. Techniškai ji buvo prieinama, tačiau tik programėlės „eMobile“ 6-ojoje versijoje. Iššūkis diegimo metu buvo tas, kad 6-oji versija dar neturėjo viso reikalingo verslo funkcionalumo. Sprendimas buvo gana paprastas, nors ir neidealus:
- paleisti 5-ąją versiją be NFC,
- atidėti NFC funkciją, kol stabilizuosis 6-oji versija. Tai įrodo vieną dalyką: funkcionalumas produkto vystymo plane (angl. roadmap) nereiškia, kad jis yra paruoštas naudoti gamybiniame projekte.
„Scheduler“ modulis, reikalavęs aplinkinių kelių
Darbo planavimo modulis pasirodė esąs ne visiškai ištobulintas. Užuot automatizavęs planavimą, jis reikalavo:
- papildomo rankinio darbo,
- kelių asmenų įtraukimo,
- sistemos apribojimų apėjimo. Tai svarbi pamoka – planavimo įrankiai gerai veikia tik tada, kai organizaciniai procesai yra sutvarkyti, o sistema – stabili.
Kaip buvo išspręstos pagrindinės projekto problemos?
Nepaisant apribojimų, projektas buvo tęsiamas, o sprendimai buvo priimami remiantis operacijų tęstinumu ir realiu sistemos naudingumu.
- Darbas su „eMobile“ 5-ąja versija:Diegus verslo požiūriu nebrandžią funkciją, buvo paleista stabili programėlės versija. Prioritetas buvo suteikti naudotojams įrankį, kuris palaiko kasdienį darbą be trikdžių rizikos.
- Planuojamas atnaujinimas iki 6-osios versijos: NFC funkcija buvo sąmoningai atidėta. Jos diegimas suplanuotas tam momentui, kai sistema pasieks tinkamą parengties lygį darbui gamybinėje aplinkoje.
- OLAP diegimas kaip projekto vertę subalansuojantis elementas: Klientui be papildomų mokesčių buvo suteikta prieiga prie OLAP ataskaitų serverio. Tai leido lygiagrečiai su sistemos diegimu kurti analitinį lygmenį, palaikantį ataskaitų teikimą ir operacinius sprendimus.
- Operacinis požiūris į „Scheduler“ apribojimus: Užuot stabdžiusi diegimą, komanda dirbo su turimomis planavimo modulio funkcijomis. Jo naudingumas buvo išlaikytas tokiame lygmenyje, kuris padeda organizuoti darbą, nepaisant sisteminių apribojimų.
CMMS sistemos diegimas „Tatra Spring“ – pirmieji rezultatai
Šiame etape dar anksti kalbėti apie visišką optimizavimą. Tačiau darbo pobūdžio pokyčiai jau yra akivaizdūs:
- Geresnė užklausų kontrolė – kiekviena užklausa yra registruojama, ją galima atsekti.
- Prieiga prie istorinių duomenų – komanda pradeda kurti žinių bazę, kuri ateityje sutrumpins diagnostikos laiką.
- Popieriaus naudojimo mažinimas – ataskaitų teikimas persikelia į sistemą. Duomenys tampa prieinami visai organizacijai.
- Didesnis techninės priežiūros darbo skaidrumas – vadovai mato, kas vyksta techninės priežiūros skyriuje. Tai leidžia priimti sprendimus remiantis duomenimis.
Projekto išvados
Šis projektas puikiai parodo, kur dažniausiai kyla problemų ir kas realiai lemia diegimo sėkmę.
- CMMS yra organizacinis projektas
Sistema sutvarko darbo pobūdį, bet nesukuria jo nuo nulio. Jei užklausos, atsakomybės ir informacijos srautai yra nenuoseklūs, CMMS juos tik atkartos ir išryškins problemas. Tik sutvarkius procesus gaunamas masto efektas, kuris pateisina investicijas.
- Duomenys yra svarbesni už funkcijas
Sistemos funkcionalumas daro įspūdį pardavimo etape, tačiau kasdieniame darbe svarbiausia yra duomenų kokybė. Be nuoseklios turto struktūros, gedimų istorijos ir ataskaitų teikimo standartų sistema tampa tik tuščiu įrankiu informacijai suvesti. Tik geri duomenys leidžia pereiti nuo įvykių registravimo prie sprendimų priėmimo.
- IT gali tapti „butelio kakliuku“
Pramoniniuose projektuose priklausomybė nuo centrinio IT padalinio diegimo tempą dažnai veikia labiau nei pati sistema. Vėlavimai suteikiant prieigas, atliekant konfigūraciją ar priimant infrastruktūros sprendimus tiesiogiai koreguoja grafiką ir sąnaudas. Neįvertinus šios rizikos pačioje pradžioje, sunku realiai planuoti projektą.
- Produkto planas (roadmap) nėra tas pats, kas įdiegimas
Tai, kad funkcija egzistuoja sistemos plėtros planuose, nereiškia, kad ji yra tinkama naudoti gamybinėje aplinkoje. Skirtumas tarp „prieinama“ ir „paruošta darbui“ išryškėja tik diegimo metu. Praktikoje tai reiškia būtinybę priimti sprendimus, kurias funkcijas diegti iš karto, o kurias – atidėti.
- Planavimui reikalinga procesų branda
Darbo planavimo įrankiai neišsprendžia organizacinių problemų. Jei nėra aiškių prioritetų, darbo standartų ir atsakomybių, planuoklis (scheduler) pradeda viską komplikuoti, užuot supaprastinęs. Planavimas pradeda duoti realią operacinę naudą tik esant stabiliems procesams.
Kada CMMS diegimas įgyja verslo pagrindimą?
CMMS sistemos diegimo poreikis paprastai atsiranda konkrečiu organizacijos vystymosi momentu. Dažniausiai tada, kai esamas modelis nustoja būti keičiamo masto ir pradeda generuoti operacines sąnaudas, kurių anksčiau nebuvo matyti.
Praktikoje tai aktualu įmonėms, kuriose:
- pagrindiniai techninės priežiūros procesai yra išsibarstę tarp „MS Excel“, popierinių dokumentų ir neformalaus bendravimo,
- trūksta rodiklių, leidžiančių įvertinti techninės priežiūros skyriaus darbo efektyvumą,
- techninės žinios nėra fiksuojamos ir lieka darbuotojų galvose,
- patikrų ir inspekcijų darbų planavimas reikalauja rankinio koordinavimo,
- veiksmai dažniausiai yra reaktyvaus, o ne planinio pobūdžio.
Tokioje aplinkoje problema yra ne įrankio trūkumas, o proceso kontrolės nebuvimas. CMMS susistemina duomenis, standartizuoja veiksmus ir suteikia pagrindą priimti sprendimus, pagrįstus faktais, o ne atskirų asmenų patirtimi.
„Tatra Spring“ projektas gerai parodo, kaip atrodo perėjimas nuo šio modelio prie labiau sutvarkyto požiūrio. Be pagražinimų ir be idealaus scenarijaus. Su realiais apribojimais iš sistemos, organizacijos ir IT infrastruktūros pusės. Dėl to šis atvejis yra daug artimesnis daugumos gamyklų realybei nei įprasti, standartiniai diegimo aprašymai.