Aplikácia princípov manažmentu znalostí
Z Psychostudia
Úvod
Aplikovať princípy manažmentu znalostí som sa rozhodol na organizáciu U.S. Steel Košice - Labortest s.r.o., v ktorej momentálne pracujem. Konkrétne som zvolil odbor Kvantometrického laboratória nakoľko sa jedná o „vlajkovú loď“ spoločnosti. Zároveň v nej pracuje aj najviac zamestnancov, síce technicky pomerne zdatných, no podľa môjho názoru, aj najmenej informovaných o základných úkonoch pri výskyte technického problému, čo neraz spôsobuje odstavenie prístroja z prevádzky pre relatívne banálnu poruchu, ktorú je možné odstrániť jednoduchým úkonom vhodným aj pre poučeného pracovníka (v zmysle Vyhl.718/2002 §20). Cieľom je premeniť aktuálnu „Knihu porúch“ na komplexný systém na evidenciu porúch, opráv, materiálu a „učenie“ obsluhy prístrojov formou tipov na opravu pri zaevidovaní poruchy a zvýšiť tak efektivitu laboratória a kvalitu výstupných výsledkov objednaných zákazníkom.
Vyhodnotenie infraštruktúry
Zariadenia :
Medzi hlavné prístroje prístrojového parku Laboratória patria optoemisné a röntgenoflorescenčné spektrometre a deteminátory elementárnych prvkov (C, S, N2, O2). Ide o komplikované zariadenia. Ovládanie a údržba sa nezaobíde bez riadiaceho PC so špecializovaným softvérom. Keďže ide o zložité prístroje, je zrejmé, že množina prípadných problémov súvisiacich s prevádzkou bude rozsiahla. Všetky zariadenia disponujú prepracovaným systémom hlásení (WARNING) a chýb (ERROR). Hlásenia aj chyby sú v prípade potreby schopné odosielať zabudovaným sieťovým rozhraním. Aj napriek zložitosti zariadení je možné niektoré hlásenia odstraňovať jednoduchými úkonmi ako sú napr. reštart aplikácie, operačného systému PC, reset hardvéru, reset prúdovej ochrany a pod.
Kniha porúch :
Obyčajný zošit, do ktorého sa v prípade poruchy urobí záznam. Z tohto zošita sa obsluha nedozvie, či sa ním zapisovaná závada už nevyskytla, prípadne ako bola odstránená. Ďalšou nevýhodou aktuálneho stavu je vytvorenie prehľadu o výskyte porúch pre jednotlivé zariadenia. V prípade potreby je to mimoriadne pracné jednak preto, že informácie nie sú logicky utriedené a problémom je aj rukopis niektorých zamestnancov. Dôležitým faktorom z pohľadu kľúčového zákazníka (USSKE) je čas, za ktorý mu je dodaný výsledok objednanej analýzy. Tento čas sa výrazne predlžuje v prípade výskytu poruchy nie len na hlavnom zariadení ale aj na záložnom. Pričom väčšina porúch je odstrániteľná obsluhou prístroja. Samozrejme za predpokladu, že je táto dobre informovaná čo môže v prípade danej poruchy skúsiť pre jej odstránenie. Využitím sieťových rozhraní zariadení spolu so spoluprácou vedúcich zmien a metodikov pokúsiť sa vytvoriť systém, ktorý by nahradil už spomínaný zošit a v prípade potreby poučil obsluhu zariadenia a možno aj prispel k jej technickej zdatnosti.
Prepojenie MZ a stratégie organizácie
Prioritou spoločnosti je samozrejme spokojnosť zákazníka. Zákazník je spokojný vtedy, ak dostane to, za čo si zaplatil. Pri analyzovaní zloženia vzorky nie je vhodné spoliehať sa na jedinú metódu prípadne na jediní prístroj. Pre zabezpečenie čo najmenšej neistoty vo výsledkoch analýzy je nutné vzorku analyzovať rôznymi metódami a prístrojmi. Táto podmienka sa však nedá naplniť v prípade poruchy zariadení. Vzdelávanie pracovníkov pomocou navrhovaného systému, pevne verím, napomôže k rastu ich technických zručností a aj takto umožní poskytovať zákazníkovi hodnoverné výsledky. Ako zákazníci môžu byť chápané aj organizácie zaoberajúce sa vydávaním Certifikovaných Referenčných Materiálov (CRM). Práve tieto spoločnosti priamo vyžadujú overovanie výsledkov rôznymi metódami pri overovaní zložení CRM.
Návrh SMZ a integrácia s existujúcou infraštruktúrou
Keďže momentálne funguje kniha porúch ako obyčajný zošit, tak prvým krokom bude návrh rozhrania, prostredníctvom ktorého by obsluha dostávala informácie súvisiace s poruchou na konkrétnom zariadení a prípadne mohla pridávať vlastné postrehy. Navrhovaná aplikácia by taktiež poskytovala rozhranie pre údržbu, servis a metodikov, ktorý by, rovnako ako obsluha, pridávali informácie k danému zariadeniu. Informácie od metodikov, údržby a servisu, ohľadom konkrétneho prístroja a závady, ktoré sú vhodné pre obsluhu, by boli kumulované a ponúkané obsluhe pri každom ďalšom výskyte poruchy. Porucha je pri týchto zariadeniach chápaný aj stav, kedy výsledky, ktoré poskytuje po technickej stránke funkčné zariadenie, nie sú reprodukovateľné, resp. nespadajú do povoleného intervalu hodnôt pre konkrétny materiál. Zo skúsenosti vyplýva, že takéto poruchy sa vyskytujú častejšie ako poruchy technického charakteru. V takomto prípade je identifikácia problému na metodikovi daného zariadenia. Z tohto dôvodu je nutné, aby navrhovaný systém obsahoval, resp. bol napĺňaný aj dôležitými informáciami od týchto pracovníkov. Ďalším krokom by mal byť návrh štruktúry databázy, ktorá by predstavovala znalostný sklad, „podkrovie“, kde by sa zhromažďovali informácie o zariadení, o poruchách, spôsobe odstránenia, použitom materiály a taktiež kľúč na základe ktoré by sa aplikácia rozhodovala, či obsluhe posunúť informáciu o odstránení alebo nie. O tom, či je konkrétny úkon vhodný pre obsluhu, by pri zápise spôsobu odstránenia rozhodoval metodik, údržba alebo servis. Do časti databázy pre evidenciu porúch by mali prístup aj jednotlivé zariadenia prostredníctvom svojich sieťových rozhraní. Nemalým problémom pri evidencii porúch je jazyková bariéra. Riadiaci softvér zariadení je písaný v angličtine a rovnako tak aj databáza jeho chybových hlásení. Aby obsluha pochopila čo sa deje s prístrojom a mohla tak aplikovať informácie získane z Knihy porúch, je potrebné zabezpečiť zmysluplný preklad nielen do technickej slovenčiny ale aj „normálnej“ slovenčiny. Podľa môjho názoru je zbytočné učiť ľudí odstraňovať závadu ak nevedia, ani približne, o čo ide. Aby tento model fungoval je potrebné filtrovať informáciu o poruche od zariadenia. Filtráciu v tomto prípade chápem ako odstránenie textu a odchytenie len identifikačného čísla danej poruchy. Na základe tohto čísla by sa pre obsluhu prístroja vybral z databázy porúch slovenský preklad. Hierarchiu systému ilustruje obrázok 1 nižšie.
Ďalšou možnosťou, ako využiť nahromadené informácie je vytvorenie podrobného prehľadu o jednotlivých zariadeniach. Napríklad je tu možnosť plánovania MTZ (Materiálno Technické Zabezpečenie), keďže sa do databázy ukladá aj spotrebovaný materiál a takto je na jedno – dve kliknutia hotový prehľad o nákladoch na údržbu pre konkrétne zariadenie. Vyskytli sa aj prípady, kedy zákazník, akreditačná komisia prípadne komisia ISO chceli vidieť štatistiku poruchovosti pre jednotlivé zariadenia. V takýchto prípadoch, ako už bolo spomenuté, je veľmi pracné hľadať v aktuálnej knihe porúch a vytvoriť podľa nej štatistiku. Navrhovaný systém by to riešil omnoho elegantnejším spôsobom.
Pokus o začlenenie navrhovaného systému do modelu SECI ilustruje obrázok 2.
Analýza a audit existujúcich znalostí
Ako som uviedol vyššie, najčastejšie sa vyskytujúcimi poruchami sú nereprodukovateľné výsledky. Kľúčovými pracovníkmi sú teda metodici, ktorých úlohou je navrhovať metódy pre jednotlivé zariadenia a „vychytávať“ ich prípadné nedostatky. Dôležitým prvkom systému sú teda poznatky získané pri práci metodika transformované do zrozumiteľnej podoby pre obsluhu prístroja. Z pohľadu manažmentu znalostí ide o tacitné znalosti. Tieto by sa mali prostredníctvom navrhovaného rozhrania premieňať na explicitné ich ukladaním a vhodnou reprezentáciou v databáze. Tacitnými znalosťami, technického charakteru disponujú aj pracovníci údržby a servisu. Existujúcimi explicitnými znalosťami sú v tomto prípade informácie od konštruktérov zariadení vo forme odporúčaní pre konkrétnu poruchu.
Návrh tímu pre zabezpečenie manažmentu znalostí
V prvých krokoch pri zavádzaní manažmentu znalostí je dôležitá najmä spolupráca programátor rozhrania, databázy (môže to byť aj jeden človek) – metodik – údržba. Po ukončení fázy vývoja a začiatku implementácie systému budú rozhodujúcu úlohu hrať metodici a technická údržba zariadení. Ich úlohou bude formulovať aktuálne znalosti aj prípadne nadobudnuté nové poznatky tak, aby boli ďalej použiteľné pri vzdelávaní obsluhy. Keďže má údržba zariadení na starosti aj iné laboratória spoločnosti, zodpovednou osobou by mal byť metodik zariadenia pretože je v neustálom kontakte s obsluhou.
Analýza, návrh a vývoj SMZ
Pre funkciu systému je potrebný databázový server. Z hľadiska nákladov by som navrhoval Open Source projekt MySQL. Návrh databázy je uvedený na obrázku 3.
Tabuľka možných závad : Obsahuje popis porúch, ktoré sa vyskytli alebo môžu vyskytnúť. Obsahuje aj identifikátor poruchy, na základe ktorého sa priradí slovenský preklad popisu poslaného zariadením.
Tabuľka aktuálnych závad : Poskytuje údržbe a metodikovi prehľad o závadách, ktoré ešte neboli odstránené alebo ktoré sa práve odstraňujú.
Tabuľka závad, ktoré boli odstránené : Obsahuje informácie o poruche, čase výskytu, spôsobe odstránenia, čase odstránenia, použitom materiáli a takisto aj kľúč na základe ktorého bude môcť aplikácia rozhodnúť, pri opätovnom výskyte poruchy, či spôsob odstránenia je vhodný pre obsluhu alebo nie a ak áno tak ho ponúknuť obsluhe.
Voľba jazyka pre napísanie aplikácie by bola ponechaná na programátora. Pri vývoji aplikácie je nevyhnutné klásť dôraz na užívateľskú prívetivosť a ergonómiu. Už pred samotnou implementáciou je, podľa môjho názoru, potrebné informovať ľudí o pripravovaných zmenách a samozrejme zaujímať sa o ich názor a zdôrazňovať, že aj oni ako obsluha, sú neoddeliteľnou súčasťou systému. Na podávanie týchto informácii by bolo možné využiť pravidelné porady ráno, prípadne pri striedaní zmien. V prípade potreby zorganizovať pred zavedením systému prezentáciu, kde by sa znova vysvetlili dôvody zavádzania, prípadne poskytli odpovede na otázky a pod. Výber Open Source riešenia databázy je podstatný len z pohľadu nákladov. Ak by používaním systému vznikla potreba funkcií, ktoré neposkytuje OS riešenie vtedy vybrať vhodného adepta z komerčných databázových systémov. Osobne si ale myslím, že MySQL bude pre danú aplikáciu postačujúci. Napísanie vlastnej aplikácie namiesto výberu z už existujúcich riešení poskytuje možnosť „ušiť“ vlastnosti absolútne presne podľa potrieb laboratória, hoci môže byť časovo náročnejšie.
Samotná aplikácia by bola spustená na samostatnom PC, na ktorom by zároveň bežal databázový server. V prípade rozšírenia aj na ostatné organizačné zložky spoločnosti by sa tento server využíval aj pre ich potreby. Zapisovanie porúch musia podľa normy ISO vykonávať len vedúci pracovníci a nimi poverená obsluha. Na ošetrenie tejto skutočnosti by som navrhoval vytvoriť samostatnú tabuľku s osobnými číslami oprávnených zamestnancov. Pri každom pokuse o zápis, by sa najprv overilo osobné číslo a v prípade korektnosti by sa vykonal zápis.
Organizačné a manažérske aspekty navrhovaného riešenia
Nasadenie systému si vyžiada len minimálne zásahy do existujúcej infraštruktúry. Dôležitejšie bude zabezpečiť „osvetu“ hlavne medzi obsluhou prístrojov na jednotlivých zmenách. Bude potrebné neustále motivovať ľudí k používaniu systému a využívaniu informácií z neho získaných. Samotný systém mierne zvýši nároky na obsluhu prístrojov len v počiatkoch nasadzovania, pretože sa ho bude treba naučiť ovládať. Osobne si myslím, že po osvojení si logiky zápisu poruchy je z užívateľského pohľadu prívetivejšie klikať ako písať perom niekde do zošita.
Aj keď je snaha metodikov aby obsluha používala rovnomerne staršie aj novšie prístroje, nedeje sa to (bohužial) a najčastejšie sú využívané prístroje ktoré pribudli ako posledné. Je to samozrejme pochopiteľné, pretože sa ovládajú jednoduchšie. Ak sa však vyskytne porucha musia pracovať so staršími prístrojmi. Ak sa systém osvedčí, obsluha bude vedieť, kde hľadať tipy na opravu a ak budú chcieť pracovať na svojom "obľúbenom" zariadení budú sa musieť posnažiť pri odstraňovaní závady. Samozrejme ak to bude v ich silách. To či to v ich silách je, by im mal povedať práve navrhovaný systém.
Po nasadení systému očakávam stúpajúci počet porúch, pri ktorých bude spôsob odstránenia vhodný aj pre obsluhu. Postupom času, využívaním tipov, by sa mala obsluha naučiť jednotlivé kroky pri konkrétnej závade a počet porúch s prislúchajúcim spôsobom odstránenia vhodným aj pre obsluhu by mal klesať a v záznamoch by sa objavovali už len závažné poruchy odstrániteľné len vyškoleným personálom (metodik, údržba, servis).
