A DOFMEA módszertan szoftverének kifejlesztése

Átírás

1 A DOFMEA módszertan szoftverének kifejlesztése Dr. Bognár Ferenc, adjunktus, Pannon Egyetem Kolláth Attila, műszaki menedzser, Pannon Egyetem 1. Kutatási előzmények, célkitűzés A jelen tanulmány címében szereplő módszertan ötlete évekkel ezelőtt fogalmazódott meg a karbantartás menedzsment szervezési iskolájában. Az ötlet módszerré változott, mely módszer fejlődésének lépéseit az évente Veszprémben megrendezett Nemzetközi Karbantartási Konferencia résztvevői első kézből követhették nyomon. Az idő előrehaladásával lefektetésre kerültek a módszer szakirodalmi alapjai. A módszertan alkalmazását számos vállalati esetpéldán keresztül bemutattuk, ahol a tradicionális FMEA elemzés alkalmazhatóságának feltételei nem teljesültek. Az Alcoa esetpéldáján keresztül a DOFMEA módszertan tapasztalatait mutattuk be egy a termelési folyamatba integrált hőkezelő berendezésen keresztül. (Bognár et al, 2010) A rá következő évben szerzőtársaimmal bemutattuk, hogy a módszer, milyen megfontolások mellett alkalmazható karbantartási projektek tervezésére. (Bognár et al, 2011; Kiss et al, 2011) A Continental esetpéldájának tanulságán keresztül belátható volt, hogy a tradicionális FMEA elemzés RPN számai mögött meghúzódó mögöttes tartalmak nem deríthetőek ki egyértelműen és ezen tartalmak az elemzés hatékonyságát csökkenthetik. Ezzel szemben a DOFMEA módszertan alkalmazása során a szakértői döntéshozatal lépései visszakövethetőek és hatékonyságuk ellenőrizhető. (Bognár-Gáspár, 2012) A módszertan mérés-, és skálaelméleti alapokra építkező továbbfejlesztését szintén elvégeztük. Ezen fejlesztés következménye, hogy a módszertan pontosabban képes megadni az elemzés végtermékeként előálló RPN számokat. (Bognár, 2013) Jelen kiadványban szerepel legfrissebb munkánk az AUDI HUNGÁRIA MOTOR Kft. esetpéldáján keresztül bemutatott tapasztalatokkal. A korábbiakban elvégzett esettanulmányok elkészítése során, egyértelműen kirajzolódott, hogy az FMEA elemzések elvégzésének milyen elméleti és gyakorlati akadályai vannak. A módszerünkkel a tradicionális FMEA elemzés számos elvi problémája kiküszöbölhető, míg a gyakorlati alkalmazás tekintetében is számos pozitív hozadékról tudunk beszámolni. (Bognár-Gáspár, 2012) Az DOFMEA elemzés elvégzéséhez létrehoztuk a módszertan web szerveren keresztül működő szoftveres támogató programját, a további idő-, és költségcsökkentést helyezve a fókuszba. A szoftver használatával, nem kell egy időben egy helyen megjelenni az elemzés elvégzéséhez, automatikus eredményszámítás segítségével gyorsabban kaphatóak meg az elemzés eredményei, stb. Jelen tanulmány célja bemutatni a szoftver tulajdonságait, működését és felhasználhatóságának területét. 2. A szoftver elvi működése A szoftver alkalmazói szintű használatához csak internetkapcsolatra és egy böngészőre van szükség. Mint alkalmazó két felület áll rendelkezésre projektmenedzser és felhasználó kategóriákban. A projektmenedzser felületen keresztül végezhető el az egyes FMEA projektek teljes körű menedzsmentje, ide értve a projektek létrehozását, 1

2 projekttényezők definiálását, mérési skálák megadását, projekttagok meghívását, elemzési módszerek elvégzését, robusztusság vizsgálatot, a projekt fázisainak nyomon követését, stb. A felhasználói felület minden a projektbe meghívott szakértő számára elérhető, a szakértő fiókjába küldött egyedi linken keresztül. A felhasználói felületen a szakértők elvégezhetik az összehasonlításokat, melyek eredménye azonnal és automatikusan elküldésre kerül a web szerveren lévő adatbázis számára. A szakértői értékelések beérkezését követően azonnal elvégezhető az RPN szám értékeinek kalkulálása, mely részletes és összefoglaló eredményei exportálhatóak.xls illetve.txt formátumba, melyet a további felhasználási cél szerint be lehet állítani. 3. A szoftver projektmenedzser felületének felépítése A projektmenedzser felületre böngészőből lehet bejelentkezni felhasználónév és jelszó azonosítást követően, a felület három választható nyelven (angol, német, magyar) érhető el. A projektmenedzser felület hét tematikus területre bontható, ezek tükrében alapvetően hét képernyőn megjelenő beállítások segítségével koordinálhatóak a projektek. Az egyes területek közötti váltásban a képernyő felső részén horizontálisan elhelyezett gombok segítenek. Ezen hét terület ismertetése jelen fejezet célja. 3.1 Cég menedzsment A Cég management gombra kattintva definiálható azon szervezet, amelyben az adott projektet létre kívánjuk hozni. Megadható a szervezet neve és a projektmenedzser számára fontos információk a szervezetről. Életszerű, hogy több szervezetnél több projekt is kivitelezhető legyen, így a szervezeteket a program képes listában kezelni, adataikat tárolni, ahogyan ez látható az 1.ábrán. 1. ábra: a szervezetek rögzítése a szoftverben A szervezetekről tárolt információkban keletkező változásokat az Edit gombra kattintva lehet megtenni, míg egy szervezet listából történő kitörlését a Delete megnyomásával lehet elvégezni. Ha egy szervezet kitörlésre kerül az adatbázisból, akkor a hozzá rendelt projektek tárolt információi is kitörlődnek, így a program a törlés elvégzése előtt megerősítést kér. Az ezen felületen megadott céginformációkat tartalmazó adatbázis bemenetet képez a következő felületen ( Projekt management ). 2

3 3.2 Projekt menedzsment A Projekt management fül alatt elsőként megjelenik egy legördülő menü, amiből a korábbi fülön lévő szervezetek közül kiválasztható az, amelyhez a projektet definiálni szeretnénk. Ahogy a 2. ábrán látszik, jelen esetben a Minta Kft. szervezet került kiválasztásra. 2. ábra: a projektek definiálása és szervezetekhez történő hozzárendelése Új projektet létrehozni hasonlóan lehet, mint új szervezetet létrehozni, megadható a projekt neve és a projektmenedzser számára fontos információk a projektről. Ezen információk ugyanúgy módosíthatóak a későbbiekben, mint a céginformációk. Jelen példa esetén a Minta Kft. -hez három projekt rendeltünk hozzá, melyek a Teszt 1, Teszt 2, Teszt 3 nevet viselik. A további projektváltozók definiálása előtt ki kell választani az a projektet, amelyikkel foglalkozni akarunk, ezt a Kiválasztás gomb megnyomásával tehetjük meg. A kiválasztott projektet tartalmazó sor sötét színnel kiemelésre kerül, és megjelenik a képernyő tetején a menüsor alatt a projekt azonosítója, neve és leírása. Ez az emlékeztető a további összes fül képernyőképén megjelenik, emlékeztetve a projektmenedzsert, hogy melyik projekten dolgozik éppen. A következő lépésben a Projekt résztvevői fül alatt lehet definiálni a projektben résztvevőket. 3.3 Projekt résztvevői A Projekt résztvevői fül alatt megadhatóak azon szakértők, akiket az elemzésbe be kívánunk vonni. A Projekt résztvevői fül képernyőképét mutatja be a 3. ábra. 3

4 3. ábra: a projekttagok megadása és az ek küldésének lehetőségei A jelenlegi esetben a projekthez három szakértő hozzárendelése történt meg. A szoftver a továbbiakban a Név cellában lévő értékeket felhasználja a szakértőnek küldött e- mailhez, az üdvözlő sorba másolva a konkrét nevet. Az címek megadása kulcskérdés, mivel a program az adatbázisból kiemelt címre fogja küldeni a szakértői munka elvégzéséhez szükséges linket, ami a szakértőt a felhasználói felületre irányítja. A Meghívó ek küldése gomb megnyomásával a szoftver kiküldi a szakértők számára az eket. Ez csak akkor történik meg miután a projekt többi változóját is definiáltuk a további rendelkezésre álló füleken. Természetesen, ha idő közben a projekt új taggal bővülne, akkor az új tagot is fel lehet vinni a projektre és számára egyénileg is el lehet küldeni a feladatot, a projekt tagok sorában egyenként szereplő küldése gombbal. Ugyanígy végezhető el az esetleges egyénenkénti újraküldése. Ezen felületen követhető nyomon a szakértőknek kiküldött munkák visszaérkezése is. Amint egy szakértő végzett a számára kiküldött feladattal, úgy a végzett oszlopban megjelenik a szakértő sorában egy Kész felirat. Amint minden válasz beérkezett el lehet végezni a beérkezett információkból az elemzést az RPN számítás fül alatt, melynek a paraméterezési lehetőségeivel később foglalkozunk. A továbbiakban az Értékelési szempontok fül alatt megadhatóak az FMEA elemzéshez szükséges RPN számot alkotó tényezők. 4

5 3.4 Értékelési szempontok Ezen menüpont alatt megadhatóak azon tényezők, melyek értékeinek szorzatából az egyes hibatípusok, hiba okok, stb. számára előállnak az elemzés eredményeképpen kapott RPN számok. A számos eltérő gyakorlat ismeretében is kijelenthető, hogy általában az RPN szám három tényező értékeinek szorzataként szokott előállni, melyek a Gyakoriság, a Súlyosság és a Detektálhatóság, így jelen példában mi is ezeket a kategóriákat vettük alapul, ahogy az a 4. ábrán látható. 4. ábra: az RPN szám tényezőinek definiálása Az RPN szám tényezőinek számosságára, a korábbiakban írtakkal összhangban sok példa ismert. Léteznek olyan változatok, hogy kettő tényező, míg más esetekben akár öt tényező szorzatából áll elő az RPN szám. A szoftver teljes szabadsági fokot ad a projektmenedzser számára, ahány tényező definiálása szükséges, annyit lehet a projekthez hozzárendelni. A Szempontnév mezőbe beírva megadható a tényező megnevezése, míg a Szemponthoz tartozó kérdés mezőbe beírható, hogy a felhasználói felületen milyen kérdést vetítsen ki a szakértők számára a program az összehasonlító elemzés elvégzéséhez. Ahogyan a tényezők számossága is változatos lehet, úgy a gyakorlatban az egyes tényezők esetén fennálló pontozási rendszer is heterogén képet mutat. Bevett szokás, hogy az RPN szám értékei azonos skálaterjedelemmel és értékekkel rendelkeznek, jellemzően 1-től 10-ig terjednek. Azonban a skálaterjedelmek és értékek módosításával az egyes tényezők más tényezőkhöz viszonyított relatív fontossága megváltoztatható. A szoftver ebben az esetben is teljes szabadságot ad a projekt menedzser számára. Indokolt esetben, az elvégzendő feladattal összhangban módosíthat az egyes tényezők 5

6 skálaterjedelmein és skálaértékein. Jelen példa esetén mi mindhárom tényezőnek 1-től 10-ig terjedő skálaértékeket állítottunk be. 3.5 Értékelési tényezők Az Értékelési tényezők fül alatt beállíthatóak azon hibatípusok, meghibásodási okok, hibák, stb. (az FMEA elemzéstől függő változóként értelmezendőek), melyeket a szakértői csoport előzetesen az elemzés szempontjából relevánsnak és vizsgálandónak állapított meg. 5. ábra: az egyes meghibásodások, hibák, hiba okok megadása Ahogyan az 5. ábra is mutatja, jelen példában négy lehetséges hibát rendeltünk az elemzéshez, melyek összehasonlító vizsgálatát a szakértőknek el kell végeznie. Az egyes elemek megnevezésében szükséges módosításokat az Edit gombra történő kattintással lehet elvégezni. Egy elem kitörlése az elem sorában lévő Delete gombbal tehető meg. Miután ezeket az információkat is megadtuk a szoftver számára ki lehet küldeni a szakértők számára a meghívókat a 2.3 fejezetben leírtak szerint. 3.6 RPN számítás A 2.3 fejezetben bemutatott módon ellenőrizhető a szakértői munkák beérkezése. Miután minden eredmény megérkezett és a szoftvernek megadtuk a kiértékelés mechanizmusát, az RPN számok kiszámítása elvégezhető. Korábbi munkákban kifejtésre került az RPN számok kalkulálásának számos módszertani lehetősége a páros összehasonlítás módszertani bázisán, így jelen munkában ezekre a lehetőségekre csak alapjaiban tekintünk rá. A 6. ábrán láthatóak az RPN számítás fül alatti beállítások lehetőségei. 6

7 6. ábra: az RPN számok kalkulálásának lehetőségei A DOFMEA módszertan alapján a beérkezett szakértői vélemények megvizsgálhatóak és a vizsgálat alapján döntés hozható a vélemények szakértői relevanciájával kapcsolatban. Ezen döntés kimenetele a szakértői vélemény teljes elutasítása és teljes elfogadása szélsőértékek által határolt spektrumon értelmezhető. Az FMEA projektek függvényében a projektmenedzser számára jelenleg három módszertanilag indokolható eszközt ad a program. A három lehetőség bemutatásához ki kell térni a szakértői vélemények konzisztensségének számítására. Mivel a korábbi munkákban ez a terület is részletesen kifejtésre került, ezért jelen munka során elegendő annyit leírni, hogy a szakértői vélemények helytállósága, relevanciája, koherenssége vagy ahogy a szaknyelv hívja konzisztenciája egy mutatószám ( K ) segítségével jellemezhető. Az egyénileg készített szakértői vélemények aggregálásához ezen egyéni konzisztencia mutatók ismeretében aggregálási szabályok adhatóak meg, ahogy az a 7. ábrán látható. 7. ábra: aggregálási szabályok Az Ahol K nagyobb mint (%) szabály esetén a szoftver azon szakértői véleményekkel fogja az RPN számok kiszámítását elvégezni, melyek K értéke egy bizonyos százalék felett van. Ezen érték beállítható, ahogy a 6. ábra Érték nevű beviteli mezője is mutatja. Ha például K értékének 60%-ot állítunk be, akkor csak azon szakértői véleményekre fog az elemzés alapozni, ahogy K nagyobb, mint 60%. A Konzisztencia átlag feletti szabály esetén a program azon szakértői véleményekre fog alapozni, melyek az összes szakértő egyéni K értékeinek átlagánál nagyobbak. A Legjobb X db szabály esetén a program azokkal a szakértői véleményekkel számol tovább, amelyek a legnagyobb x db K értékhez tartoznak. Az x értéke szintén az Érték beviteli mezőben adható meg. Ezeken túlmenően a K-val súlyozás jelölőnégyzetének bepipálása esetén az egyes szakértői vélemények aggregálása minden konzisztens tudással bíró szakértő K értékével súlyozva történik, függetlenül attól hogy melyik aggregálási szabály lett kiválasztva. 7

8 Mindezek segítségével a projektmenedzser tájékozódhat a szakértők szakértelmének szintjéről és biztosíthatja, hogy csak egy bizonyos relevancia szint feletti vélemények kerülhessenek be az RPN számítás további folyamatába. Természetesen az elemzések akárhányszor lefuttathatóak bármelyik aggregálási szabály felhasználásával, így megállapítható az is, hogy a szakértői csoport közös tudása hozzávetőlegesen milyen szintre pozícionálható. Az Aggregált mátrixok elkészítése és RPN számítás gomb megnyomásával a szoftver elvégzi a számításokat. Ezt követően a fájlnév beviteli mezőbe beírható egy tetszőleges név, majd a szoftver az eredményeket exportálja Microsoft Excel (.xls) illetve szöveges dokumnetum (.txt) formátumban. Az exportált fájlban megtalálható az összes szakértő egyéni preferencia mátrixa, az aggregált preferencia mátrixok minden RPN tényezőre és az összes RPN szám minden hibatípusra. 3.7 Változók A szoftver utolsó menüpontja alatt szabhatóak testre a szakértőkkel történő formális kapcsolattartásra vonatkozó szövegezések. 8. ábra: A szakértőkkel történő formális kommunikáció beállítási lehetőségei Ahogy a 8. ábrán látható, testre szabható mind a meghívó , mind a felhasználói felületen megjelenő tartalmak egyaránt. A megszólítás megadása során elegendő a Tisztelt, Kedves szavak megadása a helyzettől függően, utána minden szakértő nevét egyénileg a program beilleszti a megszólítás mögé. Ha a projektmenedzser testre akarja szabni a meghívó szövegét, itt azt is megteheti, ahogy az elköszönés 8

9 formáját is szituációhoz illeszthetően kezelheti. A szakértők által használt felhasználói felület beköszönő és búcsúzó szövege szintén testre szabható. 4. A szoftver felhasználói felületének felépítése A szakértők számára kiküldött meghívó ben lévő egyedi linkre kattintva megnyílik az alapértelmezett böngésző, ahol megjelenik a szakértő számára a felhasználói felület köszönő képernyője. A Kérdőív kitöltése gomb megnyomását követően a szakértő megkezdheti a projektmenedzser által korábban megadott hiba típusok egymással történő páronkénti összehasonlítását. A képernyőn mindig egy-egy hibatípus pár jelentik meg, egy-egy gomb formájában, melyekbe a hibatípus neve van beleírva. A módszertan szerint a szakértőnek mindig azt a gombot kell megnyomnia, amelyiken az a hibatípus szerepel, mely a kérdés függvényében ( Melyik okoz súlyosabb hibát? Melyik fordul elő gyakrabban? Melyiket nehezebb detektálni? stb.) a szakértő számára relevánsabb. Ahogyan a szakértő végzett az összes összehasonlítással a szoftver elköszönő képernyőre vált. 9. ábra: Képernyőkép a szakértői felületről A 9. ábrán látható egy képernyőkép a szakértői felületről. Ahogy a feladatvégzésében halad előre a szakértő, úgy a képernyő alján látható csík világos része képernyőképenként egyre nagyobb részét teszi ki a sötét sávnak, míg végül a sötét sáv teljesen elfogy. 5. A DOFMEA szoftver használatának előnyei Az FMEA elemzés méretének nagyságát tekintve a méretet két fő komponens (az RPN összetevők száma és a hibatípusok száma) határozza meg a szakértők 5-20 perc alatt egyénileg el tudják végezni az összehasonlítást, vagyis az akár nagyon időigényes projektmeetingek helyett sokkal hatékonyabban tudnak dolgozni. Szervezési oldalról a módszer másik nagy előnye, hogy nem igényli a szakértők egy helyen történő közös munkáját, sem fizikálisan sem virtuálisan. A szakértők nincsenek rákényszerítve arra, hogy verbális kommunikáció során megvédjék álláspontjukat, nincsenek hangadók a projektmunka során és nincs ezredes hatás. A tudatos RPN szám tervezés lehetősége nagymértékben korlátozott a szoftver használatával, szemben a gyakorlatban alkalmazott direkt kommunikációval és abszolút skálán történő értékeléssel. Kiemelendő, hogy a módszer alkalmazásával direkt, számszerűsíthető információt lehet szerezni a szakértők tudásáról és ezen tudás 9

10 minősített felhasználásával a karbantartói, minőségügyi, valamint termékfejlesztői munka tovább mozdítható professzionális irányba. 6. Felhasznált szakirodalmak Bognár Ferenc Balogh Ágnes Szentes Balázs Thurzó Péter: Csoportos döntéshozatali módszerek alkalmazhatósága az FMEA elemzés során; in: XXII. Nemzetközi Karbantartási Konferencia kiadványa; A karbantartás kihívása A tudástőke felértékelődése; pp Veszprém, ISBN Bognár Ferenc Kosztyán Zsolt Tibor Kiss Judit Gáspár Miklós: Karbantartási folyamatok tervezése, mint többtényezős döntési probléma!?; in: XXIII. Nemzetközi Karbantartási Konferencia kiadványa; Új utak és kihívások a karbantartásban; pp Veszprém, ISBN Bognár Ferenc Gáspár Miklós: A döntésorientált hibamód és hatáselemzés (DOFMEA) kifejlesztése és alkalmazása; in: XXIV. Nemzetközi Karbantartási Konferencia kiadványa; Karbantartás a hatékonyság és a fenntarthatóság szolgálatában; pp Veszprém, ISBN Bognár Ferenc: A döntésorientált hibamód és hatáselemzés (DOFMEA) módszertani továbbfejlesztése; in: XXV. Nemzetközi Karbantartási Konferencia kiadványa; Tudomány a karbantartás versenyképességének szolgálatában; pp Veszprém, ISBN Judit Kiss Zsolt Tibor Kosztyán Anikó Németh Ferenc Bognár: Matrix-based methods for planning and scheduling maintenance projects; Proceedings of the 13th International DSM Conference, Cambridge, MA, USA, September, pp , ISBN