Hirdetés
 

Az SAP karbantartás modulja - 3. rész - Jelentéskezelés

PDF
Nyomtatás

„Ha jól mennek a dolgok, akkor valami el fog romlani…” - Chisolm első törvénye
A mostani részben az eszközparkunk olyan eseményeivel foglalkozunk, amelyek intézkedést igényelnek. Mik lehetnek ezek? Például meghibásodás vagy annak gyanúja, nem üzemszerű működés, esetleg bizonyos eltérések az optimális állapothoz képest.

A (be)jelentések kezelése a PM modulban

Az ilyen események jelzésére az úgynevezett karbantartási jelentéseket használjuk. (A SAP rendszerében a PM jelentés szoros rokonságot mutat a QM, vagyis minőségjelentéssel.)

Fontos megjegyezni, hogy a jelentés nem feltétlenül jelent elvégzendő javítási igényt. Biztosan találkoztunk ilyesmivel akár saját autónkban is, mondjuk, amikor felvillant az olajnyomást jelző figyelmeztetés. Felvillant, aztán rögtön ki is aludt. Ilyenkor általában ellenőrizzük, hogy mi az oka. Lehet, hogy semmi rendelleneset nem találunk (ekkor nincs teendőnk), de az is lehet, hogy javításra van szükség. Egy azonban biztos: a jelzéssel foglalkoznunk kell.

karbantartasi_jelentes.jpg

Az ábrán látszik, hogy a jelentés gyakorlatilag egy adott műszaki objektumra vonatkozó, pontos időponttal ellátott, valamint a tapasztaló által megfogalmazott esemény rögzítése. Nézzük meg, mit is jelent az objektumszint. Talán még emlékszünk az előző részben a műszaki hely és berendezés tagozódásra. Gyakorlatilag megmondjuk, hogy egy adott időpontban a jármű adott egységén (ABC123 rendszámú kamion sebességváltóján) mit tapasztaltunk (második fokozat nehezen kapcsolható).

Jogosan kérdezhetnék meg azt, hogy mindig minden esetben tudja a bejelentő a pontos helyet és jelenséget? Természetesen nem. Tökéletesen életszerű dolog, hogy a bejelentés vizsgálatakor derül ki: a műszaki objektum meghatározása nem volt pontos. Ilyenkor a jelentés-feldolgozó személy nyilván pontosítja majd a hivatkozási helyet.

A jelentések létrehozása

A rendszerben jelentést az arra feljogosított személyek tudnak létrehozni. Ez gondolom, senkinek nem okoz nagy meglepetést. Rögtön izgalmasabb lesz azonban a dolog, ha kibővítem a bejelentők körét.A személyek mellett automatikus jelentések létrehozására is van lehetőség, és ez sok bevezetésnél igény is szokott lenni. A lenti ábrán ezeket láthatjuk.

jelentesek_letrehozasa.jpg

Mik is ezek a lehetőségek? Amennyiben rendelkezünk olyan diagnosztikai rendszerrel (például a gépjármű motorvezérlő számítógépe) amely képes hibajelzéseket adni, akkor nagymértékben automatizálhatjuk a jelentés létrehozását. Ipari szint esetén természetesen a SCADA (Supervisory Control And Data Acquisition) folyamatfelügyelő rendszerek szintjében is gondolkodhatunk.

A másik lehetőséget maga az SAP adja. Bizonyos idő- vagy teljesítményszint elérésekor a rendszer automatikusan képes jelentést generálni. Többször említést tettem már erről a lehetőségről, ami nem más, mint a TMK. (Külön cikket fogok neki szentelni a jövőben.)

Előző cikkünkben már meghatároztuk, hogy képzeletbeli cégünk minden járműve el van látva egy PDA-val, ami GSM adapterrel képes a SAP rendszerünknek adatot küldeni. Így a sofőrök bármilyen, általuk észlelt jelenséget azonnal jelentésben rögzíthetnek a PM modulban. Így a telephelyre visszaérkezéskor - a feldolgozott jelentés hatására - a karbantartó munkatársak már felkészülten várják a járművet. Gondoljuk csak meg, mekkora fegyvertény, hogy közel 70 gépkocsiból álló járműparkunk állapotát a PM-ben folyamatosan nyomon tudjuk követni, és bármi zavar esetén felkészülten tudunk reagálni! (Azt is hozzáteszem, hogy egy nagyvállalat esetén, ahol bizony több ezer berendezés van, egy jól átgondolt mélységű PM modul nagyon komoly teljesítménynövekedést tud okozni.)

A jelentések feldolgozása

A fentiekben láttuk, hogy a jelentésen felvitelre kerül az igényelt karbantartási intézkedés célpontja (a műszaki objektum), a hibajelenség, és a hiba észlelésének és rögzítésének időpontja. A jelentés létrejötte után a jelentés feldolgozója (egy személy) a jelentést átnézi, tartalmát megvizsgálja, és valódi munkaigény esetén a megfelelő kiegészítésekkel az engedélyező személyhez továbbítja. Az engedélyezett (munkába adott) jelentésekre hivatkozva karbantartási rendelés, vagyis tényleges munkavégzést elrendelő dokumentum jön létre. (A rendelés, tehát a valódi munkaigény a következő cikk témája.) Az alábbi ábrán ezt a folyamatot látjuk.

karbantartasi_rendeles.jpg

A jelentések fajtái

A jelentéseket a rendszerben jelentésfajtákkal különíthetjük el. A jelentésfajtákkal tudjuk elkülöníteni az egyes folyamatokhoz tartozó feldolgozási láncot, valamint jelentés fajtánként szabályozhatjuk a jelentési képernyő felépítését és adatigényét.

Általában minimum három jelentésfajtát szoktunk használni, de nyilvánvalóan ez az adott terület üzleti folyamataitól is függ:

  • Azonnali beavatkozási igény: Üzemzavaros, termelés/szolgáltatás kiesést vagy kritikus csökkenést okozó hiba, a beavatkozás halasztást nem tűr.
  • Tervezhető beavatkozás: Nem kritikus hiba, a beavatkozás időpontja a jövőben van, a folyamatok előre tervezhetőek.
  • Tevékenységjelentés: Olyan beavatkozások, amelyek mértéke vagy költsége annyira jelentéktelen, hogy nem éri meg munkaigénnyé alakítani, mindazonáltal műszakilag vagy egyéb okból indokolt az adott műszaki objektumon az eseményt felvenni. Gyakorlatilag ez egy műszaki objektumra hivatkozó feljegyzés készítése. (elektronikus „kockás füzet”)

Ezzel a három jelentésfajtával a viszonylag kisebb üzleti folyamatok jól lefedhetőek.

Katalógusok használata

A PM jelentésen lehetőség van ún. katalógusok használatára, vagyis a rendszerben létrehozott kódok alapján a meghibásodás besorolására. A következő katalógusokat használhatjuk:

  • Objektum rész
  • Kárkép
  • Okok

Az objektum résszel behatárolhatjuk a katalógusba felvett berendezés részegységek közül a meghibásodás helyét (pl. futómű). Nem keverendő azonban a műszaki objektumokkal, ezeket a részeket külön, előre meg kell határoznunk.

A kárkép kódokkal besorolhatjuk a keletkezett károkat, míg az okok kódjával meghatározhatjuk a jelenséget előidéző okokat. Egy jelentésen több tételt is használhatunk, hiszen több oka lehet az adott jelenségnek, és természetesen több objektum-részt is érinthet.

Amennyiben a katalógusokat használjuk (és azok kellő műszaki igényességgel lettek összeállítva), akkor a statisztikai hibaelemzésre rendkívül alkalmas eszközt kapunk.

A rendszer által biztosított beszámolókkal megválaszolhatjuk például, hogy hány esetben fordult elő az elmúlt két évben adagoló hiba. Természetesen a műszaki objektum oldaláról is közelíthetjük a kérdést: Adott berendezésünkön az elmúlt két évben milyen okokból, milyen részegységek hibásodtak meg?

A katalogizálás a PM jelentéskezelő rendszer egyik nagyon hasznos szolgáltatása, megfelelő műszaki igényességgel összeállított kódokkal lehetőség nyílik a meghibásodások statisztikai elemzésére, és ezzel az összetettebb hibaláncok felfedezésére.

Zárszó

A cikkben a teljesség igény nélkül végigszaladtunk az eszközeinken tapasztalt rendellenes események bejelentési lehetőségeivel. A következő rész a ténylegesen elvégzendő valódi munkaigények PM-beli támogatási lehetőségeit mutatja meg, ezek pedig a PM rendelések.

A szerző üzemi területről technikusként indult, majd tanulmányai közben 2000-től energia-elszámolási, termelésirányítási és mérésadatgyűjtő rendszerekkel foglalkozott. Az SAP MM modullal 2004-ben került kapcsolatba, majd 2005 őszétől két éven át három PM bevezetési projektben tanulta a karbantartási modul bevezetését. A PM mellett ABAP fejlesztéseket is végez.

További cikkek a szerzőtől


Nincs hozzászólása.
A téma megvitatása a fórumon. (0 hozzászólás)