TECHNICKÁ UNIVERZITA V LIBERCI
Ekonomická fakulta
BAKALÁŘSKÁ PRÁCE
2013 Ondřej Bejbl
TECHNICKÁ UNIVERZITA V LIBERCI
Ekonomická fakulta
Studijní program: B 6209 – Systémové inženýrství a informatika Studijní obor: Manažerská informatika
Informační podpora pro preventivní údržbu v podniku
Information support for preventive maintenance in the company
BP – EF – KIN – 2013 – 03 Ondřej Bejbl
Vedoucí práce: doc. Ing. Jan Skrbek, Dr., katedra informatiky Konzultant: RNDr. Ivo Šálek, PREGIS, a.s.
Počet stran: 63 Počet příloh: 0
Datum odevzdání: 10. května 2013
Prohlášení
Byl(a) jsem seznámen(a) s tím, že na mou bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb. o právu autorském, zejména § 60 – školní dílo.
Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.
Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom(a) povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.
Bakalářskou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.
V Liberci dne 10. května 2013 Ondřej Bejbl
5
Anotace
Práce pojednává o preventivní údržbě v podniku a její podporu v informačním systému SAP R/3. Čtenář se dozví informace o různých typech preventivní údržby. Bude také seznámen se základními objekty, které pro vykonávání údržby informační systém SAP R/3 využívá. Součástí této práce je také praktická část ukazující využití údržby pomocí aplikace pro sledování vyměnitelných mechanických částí na brusírenských strojích. V této části bude popsán celý proces od samotné přípravy projektu po jeho realizaci. Jsou zde popsány jak analýzy včetně schémat, tak návrhy řešení, změny celkového postupu a vyhledání s následným řešením a opravou chyb, které mohou během celého procesu nastat.
V závěru práce je také uvedena možnost využití podpůrné aplikace PalStat – Evidence měřidel.
Klíčová slova
SAP, údržba, preventivní údržba, technické místo, vybavení, hlášení, zakázka, CRM, ERP, informační systém
6
Annotation
This work is focused on preventive maintenance in companies and its support with SAP R/3. Informations about diferent types of preventive maintenance are also provided here.
Basic objects of preventive maintenance with SAP are also shown in this work. We will also look on creating application for monitoring mechanical parts installed on grinding machines. In this part information about analysis of whole process is provided. I will focus on preparations, realization and correcting possible mistakes, which can happen. In the end, possibility of using software PalStat – Evidence měřidel is shown.
Key Words
SAP, plant maintenance, preventive maintenance, functional location, equipment, notification, order, CRM, ERP, information system
7
Obsah
Seznam zkratek ... 10
Seznam tabulek ... 11
Seznam obrázků ... 12
1. Úvod ... 13
2. Teoretická část ... 14
2.1 Úvod ... 14
2.2 Preventivní údržba ... 15
3. Podnikový informační systém ... 18
3.1 Typy ERP systémů ... 18
3.2 Vývojové trendy ERP systémů ... 18
4. Informační systém SAP ... 22
4.1 Architektura informačního systému SAP ERP ... 22
4.2 Základní objekty preventivní údržby v podnikovém informačním systému SAP 23 4.3 Časově založená údržba ... 30
4.4 Údržba orientovaná na výkon ... 32
4.5 Kombinace času a výkonu ... 33
5. Praktická část ... 35
6. Zadání ... 36
7. Analýza celého procesu ... 37
7.1 Řešení pomocí materiálového hospodářství ... 38
7.2 Řešení pomocí modulu údržby ... 40
8. Výběr správného řešení ... 42
8.1 Realizace řešení ... 42
8.2 Data na pozadí... 44
8.3 Tvorba aplikace ... 45
9. Ukázka hrubého řešení aplikace a její výstup ... 46
10. Finální řešení ... 47
10.1Poloha volné ... 48 8
10.2Poloha nasazené ... 48
10.3Poloha omyté ... 49
10.4Poloha rozbité ... 49
10.5Poloha v opravě ... 49
10.6Pohyb volné-nasazené ... 50
10.7Pohyb nasazené-omyté... 52
10.8Pohyb omyté-volné ... 53
10.9Pohyb omyté-rozbité ... 53
10.10Pohyb rozbité-v opravě ... 54
10.11Pohyb v opravě-volné ... 55
11. Nasazení do skutečného provozu ... 56
12. Možné chyby a jejich opravy ... 58
12.1Chybně provedený materiálový pohyb ... 58
12.2Nasazení části na jiné místo ... 58
13. PalStat ... 60
13.1Analýza použití ve Skupině PRECIOSA ... 60
14. Spolupráce ERP SAP a PalStatu... 61
15. Závěr ... 62
Seznam použité literatury ... 63
9
Seznam zkratek
SAP Systems – Applications – Products in data processing ERP Enterprise Resources Planning
SAP R/3 SAP 3 vrstvá architektura IS Informační Systém
10
Seznam tabulek
Tabulka 1 - Možnosti založení zakázky ... 28
11
Seznam obrázků
Obrázek 1 - Optimální náklady na údržbu... 16
Obrázek 2 - Řešení pomocí materiálového hospodářství ... 38
Obrázek 3 - Řešení v modulu PM ... 40
Obrázek 4 - Struktura strojů ... 44
Obrázek 5 - Hlášení ... 45
Obrázek 6 - Schéma pohybu části ... 48
Obrázek 7 - Vzhled aplikace ... 50
Obrázek 8 - Nasazení části ... 52
Obrázek 9 - Možnosti pohybů ze stavu Omyté ... 54
12
1. Úvod
Během třetího ročníku bakalářského studia máme možnost absolvovat jednoletou praxi v nějaké společnosti. S velkým zájmem jsem si vybral společnost PREGIS, a.s. a nastoupil na pozici konzultanta v modulu údržby informačního systému SAP. Tento modul mi byl svěřen především z důvodu, že ve skupině PRECIOSA není až tak rozšířený a má velký potenciál především v úspoře provozních nákladů. Cílem této práce je seznámit čtenáře s jednou částí tohoto modulu, a tím je preventivní údržba. Budu se zabývat jak teorií, k čemu samotná preventivní údržba slouží a praxí popisující aplikaci preventivní údržby pro sledování vyměnitelných mechanických částí na brusírenských strojích. Dále se také zmíním o pomocném produktu PalStat – Evidence měřidel, který do preventivní údržby až tolik nezasahuje, ale má přímou návaznost na opravy těchto dílů; především při hlídání kalibrací měřidel nápomocných při těchto opravách. Výstupem této práce je tedy analýza a praxe při využití informačního systému SAP při preventivní údržbě a dále využití podpůrného softwaru při aplikaci údržby v podniku. V této práci budu vycházet především z knihy Plant Maintenance with SAP, ve které jsou uvedeny aktuální informace k dané problematice.
Vzhledem k omezenému používání systému PalStat ve skupině PRECIOSA a nemožnosti se dostat k testovací verzi systému jsem omezil práci především na podporu preventivní údržby v informačním systému SAP R/3 a zanalyzoval všechny dostupné informace o jediném používaném modulu PalStat – Evidence měřidel.
13
2. Teoretická část
2.1 Úvod
Stálý vývoj technologií produkce kombinovaný se stále narůstající automatizací výrobních procesů představuje stěžejní bod chodu a kvality výroby v celém podniku. Údržba těchto technických systémů má přímý dopad na konkurenceschopnost moderních společností na trhu a velmi napomáhá ke zlepšení finančního výsledku v podniku.
Údržba celkově nemá za cíl pouze zajišťovat, aby byly technické systémy v pořádku a dostupné; zároveň se zde projevují i jiné ukazatele jako bezpečnost provozu, kvalita produktu a ochrana životního prostředí.
Moderní styl údržby je daleko účinnější než klasická údržba a týmy opravářů jsou nyní začleněny přímo do procesů celého životního cyklu technických systémů; včetně plánované údržby, přestaveb a modernizací systémů. Tyto týmy se postupem času vyvinuly a tím zachycují změny v údržbě. Rostoucí podíl komplexních technických systémů a zvyšující se popularita elektronických zařízení tlačí na poptávku po specialistech z oblasti elektroniky, informačních systémů a technologií, ale stále jsou potřeba i znalci z oblasti strojírenství. Ve spoustě případů je potřeba i externích servisních poskytovatelů vlastnících své údržbáře a techniky, kteří se starají o celé technické systémy.
Tato řešení pomáhají řídicím systémům reagovat na změny podmínek týkající se vybavení, poskytují flexibilitu při změně struktury technických systémů a jsou schopna pracovat s různými typy procesů, jak pro vlastní tak externí údržbu.
Procesy v údržbě jsou v různých formách uplatňovány v různých odvětvích průmyslu.
Každý průmysl má svá specifika pro opravy, kontroly a postupy. Některé mohou být společné pro více odvětví, ale některé jsou naprosto unikátní pro specifická odvětví. Poté do procesu můžeme zahrnout i speciální schvalovací procedury (proces k povolení provozu elektrických generátorů), komplexní techniky na plánování údržby (například při údržbě letadel) a projektově založené plány údržby (generální údržba).
14
Cílem této práce není popsat celou údržbu, nýbrž jednu velmi důležitou část – preventivní údržbu.
2.2 Preventivní údržba
Proces preventivní údržby je charakterizován vytěžováním požadovaných zdrojů (pracovní úseky, materiál, externí opravy atd.) v souladu s potřebou plánu údržby.
2.2.1 Základní principy preventivní údržby
Preventivní údržba je vždy spojena s plánováním a následným realizováním dané akce.
Tento typ údržby se používá ve spoustě případů:
• Právní regulace – vždy existuje spojení s legislativními předpisy, které se týkají například bezpečnosti práce či hygieny. V tomto případě se musí údržba dodržovat, aby nedošlo k porušení zákona
• Důraz na kvalitu – Kvalita výsledných produktů záleží především na stavu strojů a vybavení, na kterých je produkt vyráběn
• Minimalizace četnosti poruch – jedním z důležitých cílů preventivní údržby je stálá dostupnost a funkčnost strojů a dalších vybavení. Efektivní využití preventivní údržby zajišťuje, že se celý technický systém neporouchá a s tím se minimalizují potřebné náklady na opravy a také se snižují ztráty při výpadku.
• Ochrana životního prostředí – efektivní preventivní údržba může napomáhat k poruchám, které by měly přímý dopad na poškození životního prostředí.
• Doporučení výrobce – výrobce technického systému může doporučit procedury, které zajišťují optimální provoz daného systému.
• Snížení nákladů na údržbu – snížení nákladů na údržbu závisí především na správném nastavení preventivní údržby. Pokud je nastavena optimálně, úspory jsou největší.
15
2.2.2 Optimální náklady na preventivní údržbu
Obrázek 1- Optimální náklady na údržbu
Preventivní údržba musí být v podniku samozřejmě správně nastavena. Dle grafu je vidět, že nejnižší celkové náklady na údržbu jsou v bodě, kde se protíná křivka nákladů na preventivní údržbu s náklady na údržbu neřešenou preventivním způsobem. Proto je vhodné se tomuto bodu přiblížit. Na grafu je také vidět, že s rostoucími náklady na preventivní údržbu klesají náklady na údržbu běžnou a naopak.
2.2.3 Typy preventivní údržby
2.2.3.1 Časové rozlišení
Úloha v preventivní údržbě je spuštěna, když je dosaženo určitého časového limitu (například kontrola stroje každých šest měsíců).
16
2.2.3.2 Výkonové rozlišení
Úloha údržba je spuštěna, když je dosaženo určité hodnoty (například kontrola vozidla po každých 10 000 kilometrech).
2.2.3.3 Rozlišení dle stavu
Úloha je spuštěna v případě, že nějaká diagnostická hodnota nebyla splněna či byla překročena (například tlak menší než 15 barů či teplota přesahující 85°C).
17
3. Podnikový informační systém
Podnikový informační systém, označovaný také jako ERP (Enterprise resource planing), je komplexní nástroj automatizující a integrující nesčetné množství procesů. Tyto procesy souvisí především s produktivní činností podniku. Typickými procesy jsou logistika, výroba, distribuce, účetnictví, fakturace, údržba vybavení či správa majetku. Pomocí těchto informačních systémů jsme schopni definovat a řídit klíčové procesy v podniku na všech jeho úrovních architektury. Mezi klíčové procesy obvykle řadíme výrobu, logistiku, finanční analýzy a ekonomiku, zakázkové zpracování, správu majetku nebo údržbu.
Hlavním cílem přechodu na ERP je zvýšení efektivity ve všech klíčových procesech. Dle řídících úrovní informačních systémů se ERP systémy obvykle prolínají všemi úrovněmi;
hlavním bodem však bude úroveň strategického a taktického řízení společnosti.
Pomocí tohoto typu informačního systému se budeme dále v teoretické i praktické části zabývat modulem údržby a jak již bylo zmíněno v úvodu návrhem a realizací řešení pro sledování náhradních mechanických částí na brusírenských strojích. Nyní se podíváme na ERP systémy více podrobně.
3.1 Typy ERP systémů
• Komplexní (SAP, Karat, K2 a další)
• Problémově orientované (ELO, VEMA)
• Systémy pro střední a malé firmy (Money S4)
3.2 Vývojové trendy ERP systémů
V minulosti se ERP specializovaly na dosažení maximální funkcionality systému. Tímto krokem vysoce rostla složitost samotného systému.
Dnešním trendem ERP systémů druhé generace je především integrace – ponechání primární funkce, tedy podpory klíčových procesů, a ostatní funkce jsou řešeny pomocí
18
specializovaných produktů (nástroje podporující reporting, nástroje analytické, oblast workflow, správy dokumentů a další). Tím se přesouvá celý koncept směrem k mobilitě.
Toto řešení je výhodné především pro obchodníky, pro které je mobilní přístup ke komponentám nezbytný pro výkon jejich povolání. Jak je ve skutečnosti vidět, vývoj ERP směřuje do cloudu a tím se vydává moderní cestou. V rámci bezpečnosti systému se do clouového prostoru nezařazují jen komponenty výroby a logistiky.
3.2.1 Oblasti integrované se systémem ERP
3.2.1.1 Podpora uživatelů
Významná část podpory uživatelů je tvořena nástroji Business intelligence. Jejím úkolem je monitorování, analyzování a plánování podnikových procesů.
Tyto analytické nástroje nezobrazují pouze aktuální stav v podniku, snaží se především odpovědět na otázky, proč daná situace nastala, jaké jsou její hlavní příčiny a pomocí dalších analýz se pokouší určit předpokládaný vývoj do budoucna.
3.2.1.2 Sledování stavu podniku
Pro monitorování stavu podniku slouží především rozsáhlý reporting všech činností a také sledování klíčových ukazatelů výkonnosti (scorecarding). Ten zajišťuje okamžitý pohled na stav podniku v předem definovaných ukazatelích založených na porovnávání plánu se skutečností.
3.2.1.3 Plánování financí
Funkcionality v této oblasti mají za úkol vytvářet finanční a obchodní plány, rozpočty a plány investic. Jsou to tedy činnosti typické pro MIS – manažerské informační systémy.
Tyto systémy mohou na základě údajů z předešlých období generovat plány, extrapolovat je a dle trendových analýz vypracovat simulaci různých scénářů.
19
3.2.1.4 Správa dokumentů
Data jsou uložena jak v ERP systému, tak v systému pro správu dokumentů. Tím máme možnost sledovat tok těchto dokumentů. Dokumenty lze také archivovat, verzovat a především zálohovat. Dle nedávného průzkumu má do ERP systému přímý přístup zhruba jen 15% zaměstnanců.
3.2.1.5 CRM (Customer Relationship Management)
Tento modul je buď součástí samotného ERP systému, popřípadě je integrován s jiným CRM systémem. Umožňuje nám spravovat vztahy se zákazníkem, který je klíčovým cílem jakékoli výrobní společnosti či podniku orientovaného na služby. Společnost bez klientů ve většině případů nemá na trhu šanci uspět. Její produkt může být na vynikající úrovni, vysoké kvality, ale bez klientů není možné prodat a společnost obvykle zaniká. Dá se tedy říci, že tento nástroj je v rámci ERP jeden z nejdůležitějších.
3.2.1.5.1 Operativní CRM
Operativní CRM je především podporou business procesů pro „front office“. Zahrnuje prodej, marketing a služby zákazníkům. Veškerá komunikace s klientem je sledována a uchovávána v databázi a v případě potřeby je ihned poskytnuta uživateli. Hlavním přínosem pro obě strany obchodního styku je monitorování historie a následná možnost zvolit vhodný komunikační kanál v závislosti na klientovi. Operativní CRM je využíváno hlavně pro tvorbu a sledování marketingových kampaní, automatizaci a monitoring prodejního procesu.
Automatické podpory prodeje (SFA) je jeden z typů operativního CRM vytvořeného pro automatizaci a podporu prodejních aktivit ve společnosti.
3.2.1.5.2 Analytické CRM
Jak již název napovídá, analytické CRM analyzuje data o zákazníkovi pro dosažení potřebných cílů:
• Vyhodnocování a optimalizace marketingových kampaní pro získání co největší úspěšnosti a efektivity kampaně
20
• Vyhledávání potenciálních prodejních kanálů, cross-selling, up-selling, udržení a rychlá podpora pro zákazníka a další
• Analýza chování zákazníka – tvorba přiměřených cen, vývoj nových produktů
• Podpora při rozhodování – předpověď a analýza rentability zákazníka a další
Zde narážíme na hlavní problém funkčnosti CRM jako integrovaného prvku ERP. Tím je samotný princip – potřeba na jednoznačný popis situace.
3.2.1.5.3 Kolaborativní CRM
Kolaborativní CRM zahrnuje speciální funkcionalitu umožňující komunikaci společnosti a jejích klientů prostřednictvím různých kanálů za účelem dosažení vyšší kvality společné interakce. Operativní CRM nabízí informace vznikající při styku se zákazníkem a jednotlivými obchodními odděleními (prodej, technická podpora, marketing). Poskytují například informace o specifických požadavcích zákazníka, dotazy na nové služby z technické podpory. Cílem kolaborativního CRM je tyto informace získané ze všech oddělení sdílet, a tím zvýšit kvalitu poskytovaných služeb zákazníkovi.
21
4. Informační systém SAP
Praktická část této práce, tedy sledování vyměnitelných mechanických částí na brusírenských strojích, bude realizována v informačním systému SAP ERP ve verzi 6.0.
V první řadě bychom se měli s tímto systémem seznámit.
Název celého systému vznikl z německého „Systeme, Anwendungen, Produkte in der Datenverarbeitung“. Společnost sídlí v německém Walldorfu. Byla založena pěti bývalými zaměstnanci nadnárodní korporace IBM. V dnešní době je jedním z největších dodavatelů podnikových informačních systémů na trhu, specializuje se především na středně velké a velké podniky.
Mezi hlavní moduly systému SAP patří:
• MM (Materials Management) – Skladové hospodářství a logistika
• PP (Production Planning) – Plánování výroby
• QM (Quality Management) – Management kvality
• FI (Financial Accounting) – Finanční účetnictví
• CO (Controlling) – Controlling
• AM (Asset Management) – Evidence majetku
• PS (Project systém) – Plánování dlouhodobých projektů
• WF (Workflow) – Řízení oběhu dokumentů
• IS (Industry Solutions) – Specifická řešení různých odvětví
• HR (Human Resources) – Řízení lidských zdrojů
• PM (Plant Maintenance) – Údržba
• SD (Sales and Distribution) – Podpora prodeje
• EHS (Environment, Health and Safety) – Životní prostředí, zdraví a bezpečnost
4.1 Architektura informačního systému SAP ERP
SAP ERP 6 je client/server aplikace využívající třívrstvou architekturu. Klient či prezentační vrstva komunikují s uživatelem přes pracovní stanici. Aplikační vrstva je
22
tvořena business logikou a databázovou vrstvou zaznamenávající a ukládající všechna data, včetně dat konfiguračních a transakčních.
SAP ERP využívá pro tvorbu dalších funkcionalit, reportů či transakcí vlastního programovacího jazyka ABAP (Advanced Business Application Programming). Od roku 2003 je také možné použít programovací jazyk JAVA jako alternativu. Když se vrátíme zpět k jazyku ABAP zjistíme, že je programovacím jazykem čtvrté generace. Ten disponuje především tvorbou jednoduchých, ale výkonných programů. Jednou ze zajímavostí je, že pro ukončení příkazu se nevyužívá středník, jak to bývá obvykle v jiných programovacích jazycích, ale tečka. SAP ERP osahuje vlastní vývojové prostředí ABAP workbench, které umožňuje vytvářet a modifikovat existující programy a moduly systému SAP. Je samozřejmě možné vytvářet nové transakce, reporty a webové aplikace. Pro komunikaci s databází se využívají klasické SQL příkazy integrované přímo do jazyka ABAP.
Implementace systému je velmi složitá. Je potřeba dodržovat přesnou metodiku jak pro celý systém, tak pro jednotlivé komponenty systému. Pro každou společnost je implementace jedinečná, jsou pouze připraveny scénáře dle odvětví. S tím také přichází dlouhá doba samotného zavedení do produktivního provozu díky silné personalizaci a mapování unikátních procesů. V rámci rozšíření působnosti do oblasti malých a středních podniků nyní SAP zavádí i retailová řešení.
4.2 Základní objekty preventivní údržby v podnikovém informačním systému SAP
Pro správnou funkčnost a využití preventivní údržby v systému SAP je potřeba znát základní objekty, jejichž specifické funkce a vazby mezi nimi ovlivňují správný chod celé údržby. Jedná se tedy o základní kameny, bez kterých se nemůžeme v modulu údržby obejít.
23
4.2.1 Technické místo
Technická místa představují komplexní víceúrovňové objekty, se kterými nelze manipulovat, nebo představují určitou technologii či složitý systém. Používají se především k určení vertikální struktury celého systému. Lze je definovat například jako:
• Výrobní závody v chemickém, farmaceutickém či potravinářském průmyslu
• Automaticky řízené výrobní stroje
• Elektrické systémy, plynové systémy, vodní systémy, topné systémy
• Infrastruktury jako cesty, budovy, tunely, mosty
• Počítačové sítě
• Složité prostředky jako lokomotivy, rychlovlaky nebo letadla
4.2.2 Vybavení
Vybavení představuje manipulovatelné objekty či různé části celků například:
• Stroje
• Vybavení (pumpy, motory)
• Měřicí přístroje
• Vozidla
• IT komponenty (počítače, tiskárny, monitory, notebooky či projektory)
4.2.3 Funkční rozdíl mezi technickým místem a vybavením
Vybavení obvykle využíváme pro následující úlohy:
• Vybavení můžeme rozčlenit přiřazením materiálu a sériového čísla. Výsledkem je možnost inventarizace všech vybavení.
• Vybavení můžeme nainstalovat na jiné vybavení či na technické místo.
• Pokud se rozhodneme spravovat vozový park, můžeme vozidlo zavést jako vybavení a spravovat k němu dodatečná data.
24
• Nainstalované vybavení může zachytávat historii použití. Systém SAP automaticky doplňuje délku užití vybavení na daném umístění, což nám dovoluje sledovat kompletní historii užívání daného vybavení.
• V návaznosti na standartní data o vybavení lze také přiřadit data doplňková (prodejní data, data konfigurace) bez potřeby zásahu do nastavení systému SAP.
• Pokud máme vytvořené struktury, vybavení si nedokáže automaticky najít svoje umístění ve struktuře, musí být vždy manuálně přiřazeno.
• Po vytvoření vybavení nemůžeme dále měnit jeho identifikační číslo.
Technické místo může být na druhou stranu pro následující potřeby:
• Díky znaku struktury si technické místo vždy automaticky najde své správné umístění ve struktuře bez manuálního zásahu uživatele.
• Hierarchické uspořádání nám umožňuje sumarizovat data pro každou úroveň hierarchie (například náklady).
• Technické místo můžeme přímo zahrnout do správy investičního majetku. Tím pádem můžeme automaticky přiřadit zakázky k danému technickému místu.
• Při zakládání technických míst však musíme mít napaměti, že je vždy potřeba vytvořit alespoň jeden indikátor struktury v nastavení systému SAP. Obvykle se jich vždy využívá více v závislosti na typu technického místa.
• Technická místa mohou být naistalována pouze na jiná technická místa nebo mohou existovat jako samostatný objekt.
• Technické místo nainstalované na jiném nemůže ukládat historii použití. Můžeme dohledat pouze aktuální umístění.
• Pokud změníme strukturu, technické místo se automaticky nepřeřadí. Tuto úlohu musíme vykonat manuálně. K tomuto úkonu využíváme možnost změny identifikačního čísla technického místa, popřípadě můžeme ve struktuře toto místo přeřadit na jiné.
4.2.4 Hlášení
Hlášení jsou pomůckou, kterou používáme při řešení operačních zásahů během údržby:
25
• Popisují naléhavou technickou situaci objektu
• Zahrnují požadavky na opravy v procesech údržby
• Dokumentují vykonanou práci
Hlášení jsou zakládána buď přímo odpovědnými osobami v situacích, kdy je potřeba podat informaci o zařízení (porucha, potřeba kontroly stroje, kalibrace), popřípadě jsou do systému údržby vkládány další osobou, která se přímo neúčastní výrobního cyklu (předák, vedoucí, kontrolor).
Do hlášení se dají vkládat následující položky:
• Zodpovědná osoba
• Servisní středisko
• Objekt poruchy (technické místo i vybavení)
• Příčina poruchy
• Místo poruchy
• Provedené činnosti při opravě
• Spotřebovaný materiál
• Priorita opravy
Hlášení poté můžeme navázat na zakázky údržby.
4.2.5 Zakázka údržby
Všechna práce odvedená na opravách se musí vykázat a k tomu slouží právě zakázka údržby. Uchovává data potřebná k analýze celkových nákladů na opravu. Zakázka údržby má následující strukturu:
• Data hlavičky – slouží pro jasnou identifikaci a správu zakázky. Uvádíme zde odpovědné pracoviště, nákladové středisko, plánované náklady na opravu a také můžeme doplnit informace o referenčním objektu podléhajícímu údržbě
• Objekty – seznam obsahuje všechny objekty, kterých se údržba týká. Dají se vyplnit jak v datech hlavičky, tak jako samotný prvek. Do objektů je možné vložit
26
jak technické místo, vybavení, konstrukční celky, ale také hlášení poskytující informace o provedeném zásahu.
• Operace – tato položka se používá k popisu práce, která má být vykonána.
• Komponenty – seznam komponent obsahuje všechny díly potřebné k opravě. Při vložení skladových dílů je automaticky generována rezervace a pro neskladové díly naopak generován požadavek na objednávku.
• Zdroje/nástroje – pro samotný zásah je také potřeba nářadí, ochranné oblečení, vysokozdvižné vozíky a podobně. Ty na rozdíl o komponent nepodléhají spotřebě.
• Stanoviště – náklady vynaložené během opravy se také načítají na daná účtovací střediska. Proto je potřeba přiřadit účetní okruh, popřípadě zúčtovací zakázku.
• Náklady – slouží pro informaci, jak vysoká částka na opravu je odhadována, plánována a jaké je její aktuální čerpání. Náklady jsou rozpadnuty dle kategorií (vlastní práce, externí práce, spotřebovaný materiál a další).
27
4.2.6 Tvorba zakázky
Pro vytvoření zakázky existuje 6 různých možností.
1 Automatické vytvoření zakázky z položky údržby
2 Založení zakázky založené na hlášení
3 Sjednocení několika hlášení do jedné zakázky
4 Přímé vytvoření zakázky bez hlášení
5 Přímé založení zakázky včetně hlášení
6 Založení zakázky a dodatečné hlášení
Tabulka 1- Možnosti založení zakázky
Položka
údržby Zakázka
Hlášení Zakázka
Zakázka
Zakázka Hlášení
Zakázka Hlášení
Hlášení
Zakázka Hlášení
Hlášení
28
4.2.6.1 Případ 1
Uživatelem definovaný plán údržby automaticky vytvoří zakázku v pravidelných intervalech založených na informacích v plánu uložených (referenční objekt, typ zakázky, seznam úloh údržby).
4.2.6.2 Případ 2
Ve stavu, kdy je obdrženo jednorázové hlášení například z výroby, je potřeba z tohoto hlášení vytvořit zakázku
4.2.6.3 Případ 3
V systému je vedeno více hlášení, které by měla být spravována jednou zakázkou (například několik hlášení o poruše stejného technického systému). Tato hlášení je poté potřeba ručně vybrat a nechat je automaticky zahrnou do seznamu objektů v zakázce.
4.2.6.4 Případ 4
Je potřeba vytvořit samotnou zakázku bez nutnosti založení hlášení.
4.2.6.5 Případ 5
Podobně jako v předchozím případě se vytvoří přímo zakázka, ale je potřeba udržovat informace o poruše, její příčině nebo poruše.
4.2.6.6 Případ 6
Je vytvořena zakázka bez hlášení, ale při jejím kompletování vznikla potřeba sledovat technická data. Pokud není hlášení ještě založeno, lze tak provést přímo v zakázce.
29
4.2.7 Strategie údržby
Strategie údržby obsahuje chronologickou sekvenci všech činností údržby. Sama o sobě neuvádí žádné detaily o aktivitě, objektu nebo datu. Tato strategie se využívá především u údržby na ní založené.
4.2.8 Seznam úloh údržby
Seznam úloh údržby popisuje aktivity, obsahuje materiál a mezní termíny. Existují seznamy specifické pro daný objekt, ale také seznamy objektově nezávislé. Strategicky založené plány musí tyto seznamy úloh obsahovat.
4.2.9 Položka údržby
Položka údržby popisuje činnosti, které se mají vykonat v návaznosti na daný objekt a přiřazují se v nich i organizační struktury daných objektů.
4.3 Časově založená údržba
Jak již bylo zmíněno výše, tento typ údržby je spojen s aktivitami vykonávanými v pravidelných časových intervalech.
4.3.1 Plán jednotlivého cyklu
Tento typ údržby využíváme pro vykonávání opakujících se aktivit v plném rozsahu v pravidelných časových intervalech. Dle zkušeností autora knihy Plant Maintenance with SAP je právě tato možnost uplatňována v nejvíce případech.
Do plánu zanášíme především jeho popis, referenční objekt, typ hlášení/zakázky pro vykazování práce, zodpovědné pracoviště a skupinu postupů, pokud nějaká existuje.
30
Plán automaticky dopočítává datum, kdy se má údržba provést. Ve skutečnosti jsou ale vždy důvody, které brání danou údržbu provést. Například můžeme nabýt několikadenního zpoždění z důvodu naplánování na nepracovní den. Tyto prodlení obvykle nenarušují datum následující údržby. Z tohoto důvodu je také možné nastavit toleranci vyjádřenou v procentech, kdy se má daná aktivita provést.
Aktivita nemusí být opakována neustále, proto je možné nastavit dobu, po kterou se má cyklus opakovat (je potřeba po jeden rok sledovat měsíčně sledovat opotřebení součástek na stroji).
4.3.2 Strategická údržba
Na rozdíl od plánu jednotlivého cyklu lze do tohoto typu údržby zahrnout více opakujících se aktivit s různým časovým horizontem. Obvyklé užití přichází, pokud na sebe dané aktivity navazují nebo se ovlivňují. Například servisní manuál od výrobce obsahující různé činnosti za různou časovou jednotku – 3 měsíce, 6 týdnů, 12 měsíců a tak dále.
Pro tento typ údržby je potřeba mít nastavený seznam úloh údržby tak, aby aktivity časově odpovídaly plánu údržby. Opět je možné nastavit časovou toleranci provedení jednotlivých úloh. Tento parametr lze změnit samostatně pro každou dílčí úlohu. Tento způsob údržby nabízí také možnost vložení koeficientu časového plánu změn jednotlivých cyklů. To napomáhá především k rychlejší adaptaci plánu realitě. Tento koeficient může nabývat hodnot od 0,01 do 9,99. V základu je nastaven na hodnotu 1,00. Pokud proběhne úprava, koeficient menší než 1,00 cyklus zkracuje a naopak koeficient větší než 1,00 cyklus prodlužuje.
Pro nastavení priorit je možné využít i hierarchické uspořádání oprav. Zde funguje pravidlo, že pokud dojde k časovému střetu, je operace nižšího stupně nahrazena operací stupně vyššího. Při potřebě provedení obou aktivit, je možné činnosti nastavit na stejný stupeň. Například je naplánována výměna oleje každého půl roku a výměna olejového filtru každým rokem. Tyto aktivity si nijak neodporují, proto je vhodné je nechat na stejném stupni. Naopak v případě pololetního čištění startovacích svíček a jejich
31
každoroční výměny za nové je výhodné nastavit výměně vyšší stupeň, protože je nesmysl nové svíčky čistit.
4.4 Údržba orientovaná na výkon
Plán údržby je definován v závislosti na odpracovaném výkonu stroje (například 10 000 hodin) a datum servisního zásahu je odhadováno z hodnoty čítače daného stroje. Jako v předchozím případě můžeme definovat buď samostatný cyklus, nebo celkovou strategii.
4.4.1 Jednotlivý cyklus
Pokud nevyužíváme strategické plánování údržby, je vhodné využívat jednoduchých cyklů. Hlášení/zakázka je vytvořeno těsně před dosažením určitého výkonu, popřípadě ihned při jeho dosažení.
Před spuštěním je potřeba u daných vybavení/technických míst definovat body měření se správným číselným formátem a relevantní jednotkou (hodiny, kilometry, litry). Hodnota čítače lze také po dosažení určité hodnoty resetovat, například po 10 000 normohodinách.
Je také možné definovat odhad výkonu za rok. Systém SAP tuto hodnotu využívá k přesnějšímu určení data plánovaného servisního zásahu.
Po takto nastavených bodech měření lze nastavit samotný servisní cyklus. Místo čísla vybavení či označení technického místa se do plánu vkládá unikátní číslo bodu měření daného objektu.
Velmi nápomocný je časový horizont naplánování. Ten se vyjadřuje procentuálně a vyjadřuje moment, kdy se vytvoří hlášení/zakázka s datem plánovaného servisního zásahu.
Například horizont nastaven na 50% s cyklem 2 000 hodin rozhoduje, že se oprava naplánuje v 1 000 odpracovaných hodinách. Pokud tento horizont není nastaven, plánované datum zásahu je vytvořeno ihned po prvním načtení hodnot bodu měření. Tím je
32
plán zásahu méně přesný a ten může být uskutečněn moc brzy či naopak s velkým zpožděním.
4.4.2 Strategická údržba
Strategii opět používáme v případě, že na sebe dané servisní zásahy navazují nebo se nahrazují. Opět je možné, že v manuálu od výrobce je uvedeno, že určité úkony musí být prováděny každých 1 000, 2 000, 5 000 odpracovaných hodin. V tomto případě musíme opět stanovit seznam úloh údržby s identickým nastavením jako má požadovaná strategie.
Do strategického plánu opět vkládáme objekt, který má podléhat servisnímu zásahu.
Systém sám nabídne bod měření, ten však můžeme sami ručně změnit. Dále definujeme plánovací závod, zda je potřeba vytvořit hlášení/zakázku a jejich typ, seznam úloh údržby a odpovědné pracoviště starající se o údržbu daného objektu.
4.5 Kombinace času a výkonu
V některých případech je potřeba stanovit více parametrů pro kontrolu. Děje se tak například u vozidel. Dejme tomu, že je potřeba udržovat bagr. Musí se kontrolovat několik parametrů. Kontrola po každých 1 000 odpracovaných hodinách, 5 000 odjetých kilometrech a servisní prohlídka po 12 měsících. V tomto případě využijeme možnosti vytvoření plánu s více parametry.
Ve strategickém plánu opět definujeme objekt, na kterém se má údržba provádět a dále údaje jak o výkonu, tak pravidelných prohlídkách. Pro správnou funkčnost musíme opět zavést k danému objektu body měření. Systém po zadání parametrů automaticky doporučí odpovídající body. Pokud se liší od našich potřeb, není problém je změnit manuálně.
Tento plán je také možné rozšířit. Děje se tak například v automobilovém průmyslu.
Kontrola vozu má být vykonána buď po 15 000 odjetých kilometrech, nebo po dvou letech od poslední kontroly. Systém tedy vyhodnotí událost, která nastane dříve.
33
Opět zde funguje hierarchie procesů. Je možné definovat dva plány; například první na 5 000 kilometrů a 12 měsíců pro běžnou kontrolu, druhý na 15 000 kilometrů a 36 měsíců pro generální údržbu. Druhý plán nastavíme na vyšší hierarchický stupeň. Výsledkem jsou tedy naplánovány dvě běžné údržby a jedna generální.
34
5. Praktická část
V této části práce je uveden postup při zavádění preventivní údržby na opravitelné mechanické části brusírenských strojů. Popíšu zde jak fázi příprav na zavedení a následně samotnou realizaci v systému SAP pomocí aplikace BSP. Kvůli obchodnímu tajemství společnosti PRECIOSA budu místo skutečných názvů strojů a jejich součástí uvádět pouze termíny brusírenské stroje a opravitelné mechanické části. S tím bude v některých ilustracích, především snímků programu, souviset i grafická úprava jejich názvů. Proto budou některé ilustrace díky těmto úpravám vypadat nekonzistentně.
35
6. Zadání
Brusírenské stroje v podniku PRECIOSA se skládají ze spousty různých mechanických části, které je možné opravovat a tím prodloužit délku jejich životnosti. S tím také přichází vysoké úspory, protože se nemusí stále vyrábět nové. Tyto části se stále vyměňují a lze je mezi brusírenskými stroji volně přesouvat.
Zpracování a evidence údržby ve skupině PRECIOSA je realizována pomocí komponenty PM informačního systému SAP. Vzhledem k velice specifickým požadavkům sledování stavu vyměnitelných částí strojů se kvůli zvýšení efektivity management rozhodl objednat si aplikaci, která umožní sledovat a statisticky vyhodnocovat data, která doposud sice byla k dispozici, ale nebyla sbírána a používána.
Vedení výrobního úseku se proto rozhodlo sledovat, jak se tyto mechanické části v průběhu svého života pohybují a zda není možnost objevit i další slabá místa na strojích, která by následně mohla projít úpravami tak, aby tyto části vydržely déle. Proto jsem dostal za úkol vytvořit a realizovat takový postup, který by analyzoval tyto body:
• Zjištění pohybu náhradních části v celém procesu (na jakém stroji byl, jak dlouho tam byl)
• Analýza oprav z jiného závodu (chyba objevená seřizovačem a opravené části jiným závodem)
• Sledování všech osob a směn, které s danou částí manipulovaly
• Zpětná kontrola příčin jejich vyřazení
Vzhledem k vysokému počtu těchto částí bylo vhodné stávající řešení rozšířit tak, aby jeho nová verze pokryla všechny tyto požadavky.
36
7. Analýza celého procesu
Na začátku bylo potřeba zjistit a vysledovat všechny možnosti a způsoby, kterými se opravitelné mechanické části strojů mohou pohybovat. Proto jsme začali úzce spolupracovat se zadavatelem projektu a ujasnili jsme si všechny pohyby. Náhradní díl nasazený na stroji může být buď sundán mezi volné anebo vyhodnocen jako rozbitý. U rozbitých dílů se rozhoduje o vlastní opravě nebo opravě na jiném závodu. Opravené díly se vrací zpět a jsou volně použitelné. Volně použitelné díly mohou být poté nasazeny zpět na stroj. Na každém stroji je přesně daný počet pozic, na které může být díl nasazen.
Tento proces jsme opět ve spolupráci se zadavetelem analyzovali hlouběji a začali hledat možnosti, kterými by bylo možné do koloběhu napojit i potřebné informace o dílech.
V této fázi vznikly dva různé pohledy na celou situaci a tým byl rozdělen do dvou skupin.
První skupina se rozhodla tento koloběh řešit pomocí materiálového hospodářství v systému SAP a druhá skupina, ve které jsem byl i já, hledala řešení problému v modulu údržby systému SAP.
37
7.1 Řešení pomocí materiálového hospodářství
Obrázek 2- Řešení pomocí materiálového hospodářství
38
Řešení pomocí materiálového hospodářství spočívá v neustálých pohybech mezi sklady.
Díly přechází skladovými pohyby přes oddělené ocenění podle toho, kam přesně díl putuje.
Zároveň načítáme náklady na opravy na konkrétní stroj, proto můžeme sledovat i finanční náročnost na údržbu každého jednotlivého stroje.
39
7.2 Řešení pomocí modulu údržby
Montáž na zařízení IE02
01 Nasazení na stroj
IW21 - H6 STROJ
Demontáž IE02
02 Sundání ze stroje IW22
Montáž na TM IE02
B-01-01-P1 díly rozbité
Demontáž a přesun na další TM
IE02
03 Odeslání na Z15 IW22
B-01-01-P2 díly v opravě
Demontáž a přesun na další TM
IE02
04 Vráceno ze Z15 uzavření hlášení
IW22
B-01-01-P3 díly volné
Demontáž IE02
Obrázek 3- Řešení v modulu PM
40
V modulu údržby jsou stroje vedeny jako technická místa a na ně jsou navázána vybavení, na která lze připojit opravitelné mechanické díly také zavedené jako vybavení. Pro jednoznačné určení jsme opět využili číslo vyražené na dílu a zavedli ho do pole
„Technické identifikační číslo“. Výhodou zavedení dílů jako vybavení je i fakt, že na něj můžeme navázat skladový materiál tohoto stejného dílu a tím zautomatizovat i proces účtování nákladů na jednotlivé stroje. Pro sledování parametrů je na všechny pohyby navázáno hlášení. Ve výše znázorněném diagramu je proces pohybu dílů zobrazen oranžově, úprava hlášení znázorněna šedivě a možná místa, kde se díly mohou vyskytovat modře. Dále byla také zavedena technická místa označená jako díly rozbité, díly v opravě a díly volné. Tento krok jsme učinili především proto, aby mohl management sledovat historii použití daného dílu a byla přesně zobrazena všechna místa, na kterých se daný díl vyskytoval. Zároveň do budoucna je možné přes body měření každého jednotlivého kusu sledovat jeho zatížení.
41
8. Výběr správného řešení
Po dlouhé diskuzi obou realizačních týmů jsme se rozhodli celý proces řešit pomocí našeho řešení, tedy skrze modul údržby. Toto řešení přineslo mnohem více výhod než řešení přes materiálové hospodářství:
• Stroje již byly v modulu údržby připraveny
• Modul PM je pro tyto potřeby uzpůsoben
• Řešení neovlivňuje žádné peněžní toky a účetnictví, je však připraveno tak, aby bylo kdykoli možné finanční pohyby implementovat a tím celý proces plně zautomatizovat a tím ulehčit práci i účetním
• Toto řešení je připraveno pro použití nejen pro jeden druh náhradních dílů
• Existuje potenciál tuto aplikaci nabízet i v našem firemním portfoliu a tím její vytvoření zužitkovat u více zákazníků
• Aplikace se dá nadále rozšiřovat o další funkce a tím z ní udělat komplexní nástroj
8.1 Realizace řešení
Dále bylo důležité navrhnout vhodný a jednoduchý způsob, jakým tento proces aplikovat.
Nacházely se zde tři možnosti, kterými je možné celý koloběh obsluhovat.
8.1.1 Obsluha přímo v SAPu
Ruční obsluhou v SAPu by musel daný uživatel ručně vyplňovat každý krok celého procesu. To znamená, že by musel dokonale ovládat zhruba pět transakcí a v každém kroku alespoň tři použít. To znamená, že na každý díl by byla potřeba časové investice zhruba dvou minut a nebylo by možné díly přesouvat i hromadně po dávkách. Proto bylo toto řešení kvůli jeho náročnosti pro obsluhu zavrženo.
42
8.1.2 Obsluha pomocí excelu navázaného na SAP
Toto řešení již skladník pro základní sledování používá a pro stávající účely je dostačující, a proto jsme začali uvažovat o návázání na toto stávající řešení a jeho rozšíření. Samotný excelovský list je úzce napojen na systém SAP, který dělá materiálové pohyby na pozadí.
Ušetřili bychom tím práci přímo se SAPem, bohužel, u zhruba 1500 kusů dílů by začal vznikat chaos v orientaci, kde se který náhradní díl nachází. Proto i toto řešení bylo zavrženo.
8.1.3 Obsluha pomocí aplikace BSP
BSP aplikace je intranetový program úzce napojený na SAP. Jeho výhodou je spouštění přímo v internetovém prohlížeči a odpadá potřeba užívání systému SAP. Uživatel této aplikace nemusí v našem případě prakticky vůbec sahat na klávesnici a k obsluze mu stačí pouze myš. Lze totiž vytvořit seznamy dílů přesně podle pozice, kde se díl nachází, jeho označením a kliknutím na příslušné tlačítko a vyplněním potřebných informací, opět postupným klikáním, se automaticky posune na místo, kam je potřeba. Další nesmírnou výhodou je i dávkové zpracování několika dílů. Například pokud potřebujeme přesunout více dílů do opravy, stačí je jenom označit a kliknout. Dále se o všechno na pozadí postará systém SAP. Velkou nevýhodou je bohužel vysoká náročnost na naprogramování této aplikace a tudíž vyšší pořizovací cena tohoto řešení. Co se týká její využitelnosti v budoucnu, je krajně pravděpodobné nasazení do více podniků a pro různé díly. Právě proto jsme se pro toto řešení rozhodli, především díky jeho univerzálnosti a předpokladu několikanásobného návratu pořizovací investice.
43
8.2 Data na pozadí
Obrázek 4- Struktura strojů
Na pozadí je vše připraveno pro reálný pohyb mechanických částí. Celý stroj zavedený jako technické místo má na sobě navázány součásti, na které jsou dále navázány naše mechanické části stroje. Tyto položky jsou založeny jako vybavení. Dále jsme pro sledování pohybů zavedli pomocná technická místa pro sledování reálného pohybu částí.
44
Obrázek 5- Hlášení
Na pozadí také vzniká při jednotlivých pohybech částí hlášení, které informuje o osobách, které s částmi manipulovaly, popřípadě jsou v nich ukládány důvody, proč se musela daná část sundat.
8.3 Tvorba aplikace
S takto připravenými podklady pro samotnou aplikaci jsme do celého procesu zapojili programátory. Ti ihned zahájili práci a zhruba za měsíc byla připravena hrubá aplikace na prezentaci.
45
9. Ukázka hrubého řešení aplikace a její výstup
Po vytvoření první verze aplikace se základními ovládacími prvky jsme jeli ukázat výsledek naší práce vedení Preciosy. Co se týče funkčnosti, bylo vedení spokojené.
Bohužel jsme přišli na problém v celém procesu. Kvůli minimalizaci odstávky stroje není možné nejdříve náhradní díl sundat, odevzdat ho a nafasovat místo něj díl nový. Dále jsme, bohužel, byli obeznámeni s tím, že vlastní oprava obvykle neprobíhá, protože se všechny kusy nechávájí opravit na jiném závodě. Dokonce bylo zjištěno, že se náhradní díl sundaný ze stroje nedostává rovnou do skladu, ale nejdříve se posílá na omytí.
Tím pádem začalo být naše řešení zcela nepoužitelné, protože bychom ztratili šanci ihned evidovat sundané i nasazené díly. Po dlouhé diskusi našeho realizačního týmu jsme museli vymyslet nějaký kontrolní mechanismus, který by eliminoval možnost chyby.
46
10. Finální řešení
Pro celkové pochopení dané problematiky jsme si opět sestavili vývojový diagram se zavedenými změnami a začali provádět kroky
, které nám pomohou splnit zadání zákazníka. Modrými šipkami jsou znázorněny všechny možné pohyby mechanických částí. Názvy jednotlivých umístění kopírují strukturu rozložení dílů v dílčích tabulkách.
47
Obrázek 6- Schéma pohybu části
10.1 Poloha volné
V této poloze se nachází všechny části ležící ve skladě v daném výrobním závodu. Jsou tedy v případě poruchy ihned dostupné k použití na stroj. Jak již bylo řečeno výše, jsou navázané na technickém místě s označením P3.
10.2 Poloha nasazené
Zde nalezneme části nainstalované na strojích. Ve výpisu tabulky vidíme, na jakém stroji se část nachází, co je jejím nadřazeným vybavením a na jaké pozici daného vybavení část
NASAZENÉ
OMYTÍ
ROZBITÉ
V OPRAVĚ
VOLNÉ
48
je. Můžeme také sledovat, která část byla na daném umístění předtím a kdy proběhl poslední přesun. To slouží především ke kontrole při nainstalování na špatnou pozici.
10.3 Poloha omyté
Části jsou automaticky sundávány do mezistupně „omyté“. Důvod je prostý. Předtím, než se část dostane fyzicky do skladu, je omývána a teprve po tomto omytí jí máme opravdu fyzicky v ruce. Sledujeme její číslo, typ, jakou částí byla nahrazena (opět kvůli kontrole chybného zadání) a poslední změnu. Před samotným začleněním do dalších stavů vyplňujeme až tři závady, které byly na dané části nalezeny.
10.4 Poloha rozbité
K opravě se části posílají až v momentě, kdy jich je porouchaných více. Poloha rozbité nám tedy slouží k jejich kumulaci a evidenci. Odsud se poté hromadně přesouvají k opravě na jiný závod.
10.5 Poloha v opravě
Poloha slouží opět jako evidence všech částí, na kterých probíhají opravy. Při návratu je povinné vyplnit jeden až tři druhy oprav a následně je možné část opět zařadit mezi volné na sklad daného výrobního závodu.
49
Obrázek 7- Vzhled aplikace
10.6 Pohyb volné-nasazené
Pro přesun části mezi těmito polohami je potřeba vyplnit zodpovědnou osobu a směnu, na které zrovna je, dále je nutné vybrat část vydávanou ze skladu a definovat stroj a přesnou polohu, kam část nasazujeme. Jelikož je částí několik typů určených číslem materiálu, probíhá na tomto místě i kontrola, zda daný typ je možné nasadit na všechny části stroje.
Proto je utvořená dynamická tabulka, která se objeví po označení převodovky a kliku na tlačítko „nasadit“. V ní se zadá číslo stroje a následně se zobrazí všechny povolené polohy.
Poté probíhá samotný přesun. Jelikož je část na začátku cyklu, probíhá pomocí BAPI založení PM hlášení. Část je na pozadí demontována z pomocného technického místa P3 a následně instalována na stroj a danou pozici. Při instalování probíhá další kontrola, zda není na daném jiná část. Pokud ano, je nejdříve přesunuta do polohy „omyté“ a následně místo ní instalována část vydávaná ze skladu.
50
Při tomto pohybu také probíhá materiálový pohyb 261 na PM zakázku daného stroje tak, že další BAPI vloží do PM hlášení opatření H6-01 pod názvem „Nasazení na stroj“ včetně seřizovače, který část na stroj nainstaloval, dále je také do položek přidáno místo chyby (ve skutečnosti je to poloha, na které se část nacházela) a směna zodpovědná za nasazení.
Přidáváme samozřejmě i SAP číslo vybavení, což je identifikátor naší části. Díky tomuto se nám automaticky vyplní pole technické místo, tedy označení stroje, na kterém se část nachází. Technické místo se již po zbytek cyklu neaktualizuje, proto můžeme v každém jednotlivém hlášení sledovat na jakém stroji a místě se jaká část nacházela. Při úspěšně povedeném pohybu se také do textu opatření doplní číslo materiálového dokladu.
51
Obrázek 8- Nasazení části
10.7 Pohyb nasazené-omyté
Tento pohyb probíhá ve většině případů automaticky, a to v případě, že je část nahrazována částí jinou. Pohyb lze provést i manuálně, obvykle při odstavení stroje, kdy se z něj části odstrojují. Část je na pozadí demontována ze stroje a instalována na technické místo P4.
Pokud narazíme na chybný pohyb nebo na špatně opravený kus, kontrolujeme, zda byla část sundána za méně než 30 hodin. V tomto případě pohybem 262 na danou PM zakázku stroje a tím stornujeme náklady na opravy.
Technicky do hlášení přidáváme další opatření H6-02 s názvem „Přesun na omytí“ včetně seřizovače, který část sundal ze stroje, a definované následné akce provedou samotný přesun části a kontrolu storno pohybu. Při provedené storna se do textu opatření vypíše
52
materiálový doklad, který byl stornován. Do položek přidáváme také směnu zodpovědnou za sundání ze stroje.
10.8 Pohyb omyté-volné
Když, je potřeba odstavit stroj a části jsou v pořádku, používáme tento pohyb k přímému návratu na sklad. Probíhá opět demontáž a instalace na technické místo P3.
Na pozadí se provádí materiálový pohyb 261 na controllingovou zakázku všech strojů dané technologie. Do hlášení BAPI vkládá opatření H6-05 „Přesun do volných“ se skladníkem zodpovědným za fyzický přesun části do regálu a následná akce provádí přesuny a materiálové pohyby. Materiálový doklad se opět zapíše do textu daného opatření.
10.9 Pohyb omyté-rozbité
Jak již bylo řečeno, po sundání ze stroje přechází část fyzicky na omytí a teprve následně do skladu, kde se rozhoduje, zda je v pořádku či rozbitá. Ve většině případů se stává, že přijde na sklad s poruchou. V této fázi vyplňujeme až tři možné chyby a posíláme část na paletu, kterou následně odesíláme na jiný závod k opravě.
Na pozadí jsou akce totožné – demontáž z technického místa P4 a následná instalace na technické místo P1. Do hlášení je pomocí BAPI vloženo opatření H6-06 „Přesun do rozbitých“ se skladníkem, který reálně přesunul části na paletu připravenou k odeslání na opravu částí. Dále jsou do položek vkládány až tři druhy chyb.
53
Obrázek 9- Možnosti pohybů ze stavu Omyté
10.10 Pohyb rozbité-v opravě
V případě, že je paleta dostatečně naplněna, odesíláme části do opravy na jiný závod. Při tomto přesunu se automaticky tiskne průvodka, která obsahuje informace o daných částech, přesněji její číslo a odhadované chyby.
Jako v předchozích případech probíhá demontáž z technického místa P1 a instalace na místo P2. Do hlášení je pomocí BAPI vloženo opatření H6-03 „Odeslání na opravu“ se skladníkem zodpovědným za odeslání částí. Zároveň se také takto přesunuté části včetně odhadovaných chyb zobrazí v seznamu připraveném pro tisk. Ten slouží jako průvodka všech částí, které byly odeslány pryč.
54
10.11 Pohyb v opravě-volné
Posledním pohybem dokončujeme celý cyklus. Části, které se nám navrátily, jsou doloženy průvodkou s jejich číselným označením a proběhlými opravami. Opět provádíme demontáž a následnou instalaci na technické místo P3.
Na pozadí dále probíhá materiálový pohyb 261 na controllingovou zakázku strojů dané technologie. Jako v minulých případech se do hlášení vkládá opatření H6-04 „Vrácení z opravy“ a skladníka zodpovědného za přijetí částí. Do položek také přidáváme až tři opravy dané části. Tyto opravy je skladník schopen vyčíst ze seznamu, který se s částmi navrátil. Následné akce poté provádějí materiálový pohyb a přesun částí. Opět se do textu opatření zapisuje doklad materiálového pohybu na controllingovou zakázku. Po úspěšně provedených pohybech se celé hlášení uzavírá.
55
11. Nasazení do skutečného provozu
Samotnému nasazení do produktivního provozu předcházela série školení koncových uživatelů a testování aplikace. V rámci testování byly provedeny pouze úpravy vzhledu a uspořádání zobrazovaných položek tak, aby byla aplikace jednodušeji použitelná. Jednalo se pouze o záměnu sloupců v přehledech, přeskupení struktury informací v hlavičce aplikace a úprava jejich názvů v závislosti na používané terminologii daného odvětví.
Byla také určena strategie zavádění částí do procesu. Jak je zmíněno výše, na pozadí probíhají materiálové pohyby, proto bylo potřeba vytipovat klíčová místa v procesu, kde je možnost hladce přidávat části tak, aby nebyl nijak poškozen systém těchto pohybů a bylo na něj plynule navázáno právě touto aplikací. Řešením se stala příprava nasazování ve třech místech.
Před samotným spuštěním v produktivním provozu byly části připraveny tak, že neměly vyplněné technické místo, tudíž nebyly v aplikaci vidět. V den spuštění se ihned ráno prošel sklad a zaevidovaly se všechny části. Těmto částem bylo poté ručně v IS SAP nastaveno Technické místo P3, tedy volné části. V této fázi byly připraveny výdeje na stroje pomocí naší aplikace a náhrada ruční evidence.
V druhém bodě je potřeba nahradit materiálové pohyby jdoucí právě při návratu částí ze samotné opravy. Tím nám napomáhá hlášení, které je používáno jak aplikací, ale lze s ním manipulovat a pohyby provádět skrze opatření v IS SAP. Pro vkládání částí byl vyškolen vedoucí pracovník. Jeho úlohou je ruční zavedení částí skrze hlášení do aplikace. Jelikož následné akce navázané na opatření provádějí přesuny a materiálový pohyb, je možné pouhým založením nového hlášení, uvedením SAP čísla části a následným přidáním opatření H6-04 docílit jak zavedení části do oběhu, ale také jeho účtování.
Pro urychlení nasazování jsme využili ještě jednoho místa, jež mohlo být klidně vynecháno, a to návratu části z omytí. Zde se opět dostávají do ruky skladníkovi, který sepíše seznam jejich čísel a vedoucí pracovník je opět ručně zavede do systému. Princip je stejný jako v minulém případě. Vedoucí pracovník založí hlášení, zadá SAP číslo části a
56
přidá také opatření H6-02. Tím je opět uvedena do cyklu a je možné s ní dále v aplikaci manipulovat.
57
12. Možné chyby a jejich opravy
12.1 Chybně provedený materiálový pohyb
V ojedinělých případech je možné, že se neprovede materiálový pohyb. To je obvykle zapříčiněno blokací materiálu jiným uživatelem. V této chvíli následná akce obdrží chybovou zprávu a automaticky posílá vedoucímu pracovníkovi e-mail s postupem napravení chyby. Ta se obvykle napravuje otevřením hlášení uvedeném ve zprávě, uzavřením opatření a opětovným vložením stejného opatření s uložením hlášení. Dokud není tato chyba napravena, nelze s částí v cyklu dále pohybovat.
12.2 Nasazení části na jiné místo
Problém s lidským faktorem se nachází v jediném bodě. Původně stavěná aplikace nejdříve vyžadovala přinesení rozbité části a následná instalace nové. Prostoje mezi tímto úkonem by přinesly vysoké ztráty, proto se ihned nasazuje nová část a stará se automaticky demontuje. Tím pádem se stará část dostává do ruky skladníka až po návratu z omytí.
Aktuálně je proto proces nastaven tak, že seřizovač ví, odkud rozbitou část sundá, ale neví její číslo. Skladník tedy vydá novou na dané místo a následně porovnává části příchozí z omytí s těmi, které se automaticky sundaly v aplikaci a jsou v záložce „Na omytí“. Na konci směny by právě tato záložka měla být prázdná.
Pokud prázdná nezůstane, existuje relativně rychlá náprava tohoto problému. Skladník z informací uvedených v aplikaci při porovnání se skutečností je schopen najít chybně nasazené části a ty následně sundat přes omyté rovnou do volných, tím se provede storno materiálového pohybu. Vydaná se nasadí na správné místo a automaticky sundaná se vrátí na své původní umístění. Tím pádem se automaticky do omytých částí posune ta, kterou má skladních fyzicky v ruce.
Jedinou těžce zjistitelnou chybou je cyklická záměna. Jako příklad uvádím jednoduchou situaci: skladní vydá část A na stroj 1, část B na stroj 2 a část C na stroj 3. Seřizovač se
58
ovšem zmýlí a provede nasazení části A na stroj 3, části B na stroj 1 a části C na stroj 2.
V tomto stavu se vrátí ty správné části a chyba je objevena až v dalším cyklu. V té chvíli je potřeba zasáhnout individuálně přímo v systému SAP.
59
13. PalStat
PalStat je produktem stejnojmenné společnosti zabývající se problematikou řízení jakosti.
Obsahuje zhruba 15 modulů, které fungují samostatně, při pořízení více modulů však přinášejí vyšší synergický efekt než moduly samostatné. Moduly jsou spíše nadstavbou nad klasickým ERP. Software i jednotlivé moduly jsou dodávány v lokální i síťové verzi.
13.1 Analýza použití ve Skupině PRECIOSA
Skupina PRECIOSA využívá modul Evidence měřidel. Svou podstatou je to jednoduchá kartotéka měřidel evidující další informace o měřidlech, jako jsou termíny poslední kalibrace a kalibrační periody. Systém také upozorňuje na téměř prošlou kalibrační periodu a oznamuje uživateli, která měřidla by měla být znovu kalibrována. V návaznosti na předchozí problém s evidencí náhradních mechanických části mohu říci, že má Palstat uplatnění na závodě, kde se tyto části opravují.
60
14. Spolupráce ERP SAP a PalStatu
Z práce jasně vyplývá, že PalStat funguje pouze jako vysoce specializovaný doplněk rozsáhlých informačních systémů. Standart systému SAP nedokáže měřidla jednoduše spravovat jako modul Evidence měřidel od společnosti PalStat. Navíc lze ušetřit poměrně vysokou sumu použitím PalStatu oproti pořizování licencí SAPu a následného doprogramování funkčnosti, jakou PalStat nabízí.
61
