PLM (Product Lifecycle Management) podporuje celou řadu procesů v průmyslovém podniku. Jedním z nich je i podpora procesů jakosti, nebo chcete-li quality management. Podívejme se, jak k těmto procesům přistupuje například Škoda Power. Implementace Oracle Agile přinesla pro Škoda Power řadu pozitivních přínosů, mimo jiné i funkční a dobře uchopitelný nástroj podporující WorkFlow.
Původně byly tzv. Listy neshod vystavovány jako papírový dokument. Nevýhody jsou zřejmé: zdlouhavé vlastní vystavení dokumentu včetně tisku a přiložení všech příloh, vyšší pravděpodobnost chyby, nepružné řešení neshody vyžadující od pracovníků fyzický přenos formulářů mezi kancelářemi, ztráty formulářů, nutnost ručního statistického zpracování.
Řešení v Oracle Agile e6 umožňuje založení neshody pro každého pracovníka s oprávněným přístupem. Propojení mezi systémy Oracle Agile a BaaN V výrazně zrychluje vyplnění údajů formuláře, např. na základě vyplnění čísla výrobní objednávky v BaaN je automaticky vyplněno číslo zakázky, číslo a název projektu, identifikace a název součásti, připojen odpovídající zakázkový kusovník včetně výrobní dokumentace. Obsluha dále popíše neshodu, připojí pomocnou dokumentaci (fotografie, náčrtky…) a spustí proces WorkFlow (vzniklý automaticky na základě šablon procesů). Neshoda je následně řešena odpovědnými osobami (resp. skupinami osob) sledem definovaných aktivit.
Postupně se v Oracle Agile zpracovávaly také procesy externích neshod – tj. dodavatelské neshody obchodního zboží, hlášení o neshodách ze stavby, nákladové a termínové neshody, reklamace zákazníků v garanční době projektů…
Výhody jsou společné. Rychlé a pružné řešení neshody: v každém okamžiku lze jednoduše dohledat aktuální úkoly a osoby podílející se na řešení aktivit dané neshody, lze sledovat zpoždění. Je zachovávána historie rozhodnutí jednotlivých řešitelů, včetně jejich záznamů do formuláře neshody. Výsledkem procesu je vždy jednoznačné a úplné okamžité řešení, celkové ekonomické zhodnocení neshody, označení původců a návrhy na nápravná opatření. Je umožněno rychlé a přesné vytváření statistických sestav a reportů – vyhodnocení nejakosti projektů, nejakost dle středisek původců apod. Z hlediska servisu je významná jednoduchá dohledatelnost v rámci projektu, resp. zakázky.
List neshody může iniciovat vznik nápravného/preventivního opatření, další funkčnosti primárně využívanou úsekem Jakost (přestože řešení opatření může procházet napříč celou společností). Nápravné opatření je opatření řešící příčiny neshody, preventivní opatření řeší potenciální problém, který může k neshodě vést. Cílem těchto opatření je snížení neshod. Původně byla nápravná/preventivní opatření řešena vystavením papírového dokumentu. Řešení v PLM Oracle Agile v podstatě vychází z klasického 8D reportu. Oprávněný pracovník vypíše zadání do formuláře opatření a inicializuje proces WorkFlow. Je zkontrolováno a schváleno zadání, stanovena osoba provádějící rozbor a plánované datum termínu dokončení rozboru. Určená osoba provádějící rozbor popíše kořenovou příčinu, navrhne okamžitá a systémová opatření. Rozbor je následně kontrolován odpovědným pracovníkem jakosti a je buď schválen, nebo vrácen k přepracování. V případě schválení jsou stanoveny jednotlivé úkoly, zodpovědné osoby a termíny. Stanovení rozboru, plnění jednotlivých úkolů, upozornění na blížící se termín splnění úkolu, překročení termínu je hlídáno automaticky systémem, odpovědným osobám jsou zasílány informativní zprávy. Po splnění všech úkolů následuje posouzení jejich splnění, mohou být nadefinovány další úkoly, nebo je stanoven termín pro posouzení efektivnosti opatření. Po uplynutí stanovené lhůty je efektivnost zhodnocena a následně schválena, přičemž je stanoveno, zda opatření bylo, či nebylo účinné. Nástroje Oracle Agile i v tomto případě umožnují přímý monitoring stavu řešení opatření a jednotlivých úkolů, vyčlenění nesplněných úkolů a podobně. Globální pohled poskytuje report sledování a trend nápravných a preventivních opatření.
Vzhledem k neustále se měnícím normám prováděcích a hodnotících předpisů, ale i vzhledem k možnosti dodatečných změn projektových PZJ (změny rozsahů kontrol, účastí na kontrolách, způsobu protokolování…) musely být ručně vytvářeny a změnovány. S ohledem na význam dokumentu se to týkalo poměrně značného počtu útvarů, které musely schvalovat velké množství dokumentů. Aktuální komplexní řešení pojímá PZJ i PKZ jako strukturovaný dokument, ve kterém jsou odděleny prováděcí a hodnotící předpisy, kontrolní operace a samotné PZJ a PKZ. Umožňuje rychlé vytváření projektových PKZ na základě platné struktury projektového PZJ a platných vzorů PKZ.
V rámci kontrol (přejímek) se provádí tvorba velkého množství protokolů. Také zde byly papírové dokumenty nahrazeny elektronickou formou. Na základě uložených vzorů/šablon směrnic protokolů kontrol a zkoušek (formát MS Word/Excel) dochází k tvorbě předpřipravených protokolů v Agile. Technik jakosti doplní pro příslušný typ protokolu do jeho těla hodnoty (např. pro rozměrovou kontrolu v MS Word k náčrtku doplní naměřené hodnoty). Po schválení dokumentu dochází k automatickému vygenerování finálního pdf souboru. V Agile pak lze snadno dohledat a případně vytisknout potřebný protokol.
Samostatnou skupinou jsou elektronizované dokumenty typu: Prohlášení o shodě a Prohlášení dodavatele o shodě tvořící jednu z částí celkového balíku dokumentace předávané zákazníkovi.
Na příkladu Škoda Power jsme ukázali jedno z nejkomplexněji pojatých řešení procesů zajištění jakosti. Můžeme však jmenovat celou řadu dalších společností, kde jsme v menším či větším rozsahu podobné procesy realizovali. Pokud vás procesy zajištění kvality zdržují a nezajišťují dostatečnou transparentnost a rychlost, zkuste se obrátit na svého dodavatele PLM/DMS řešení.
Autor je vedoucím konzultantem ve společnosti TD-IS.
Schvalování výkresové dokumentace
Jedním z prvních procesů podporovaných tímto nástrojem byl proces schvalování aktuálních verzí výkresové dokumentace a položek. Již první zkušenosti s WorkFlow byly veskrze pozitivní. Doba nutná ke schválení (sekvence kontrol a požadavků na následné přepracování) výkresové dokumentace v elektronické podobě, položek a kusovníků, byla výrazně zkrácena, snížila se potřeba tisku papírových kopií pro účely schvalování, byla zvýšena transparentnost procesu. Vedoucím pracovníkům byl umožněn přehled kvality práce podřízených na základě rozboru procentuální míry požadavků na přepracování od jednotlivých schvalovatelů.Řešení neshod
Úsek Jakosti, rovněž zapojený ve výše uvedeném procesu, brzy rozpoznal potenciál funkčnosti a vznesl požadavek na implementaci řešení neshod interní výroby a nákupu pro interní výrobu v prostředí Oracle Agile s využitím WorkFlow. Bylo rozhodnuto podrobně analyzovat a procesně definovat tři základní procesy: Neshoda vnitřní – zachycená ve výrobě, Dodavatelská neshoda – zjištěná při příjmu v rámci vstupních kontrol a Dodavatelská neshoda - hlášená dodavatelem před dodáním do společnosti. Hlavním cílem vystavování neshod je nalezení nejvhodnějšího okamžitého řešení, dle rozsahu případné informování zákazníka a slouží jako podklad k provedení nápravných opatření pro zamezení neshody v budoucnu.Původně byly tzv. Listy neshod vystavovány jako papírový dokument. Nevýhody jsou zřejmé: zdlouhavé vlastní vystavení dokumentu včetně tisku a přiložení všech příloh, vyšší pravděpodobnost chyby, nepružné řešení neshody vyžadující od pracovníků fyzický přenos formulářů mezi kancelářemi, ztráty formulářů, nutnost ručního statistického zpracování.
|
Nápravné opatření |
Část struktury PZJ |
Řešení v Oracle Agile e6 umožňuje založení neshody pro každého pracovníka s oprávněným přístupem. Propojení mezi systémy Oracle Agile a BaaN V výrazně zrychluje vyplnění údajů formuláře, např. na základě vyplnění čísla výrobní objednávky v BaaN je automaticky vyplněno číslo zakázky, číslo a název projektu, identifikace a název součásti, připojen odpovídající zakázkový kusovník včetně výrobní dokumentace. Obsluha dále popíše neshodu, připojí pomocnou dokumentaci (fotografie, náčrtky…) a spustí proces WorkFlow (vzniklý automaticky na základě šablon procesů). Neshoda je následně řešena odpovědnými osobami (resp. skupinami osob) sledem definovaných aktivit.
Postupně se v Oracle Agile zpracovávaly také procesy externích neshod – tj. dodavatelské neshody obchodního zboží, hlášení o neshodách ze stavby, nákladové a termínové neshody, reklamace zákazníků v garanční době projektů…
Výhody jsou společné. Rychlé a pružné řešení neshody: v každém okamžiku lze jednoduše dohledat aktuální úkoly a osoby podílející se na řešení aktivit dané neshody, lze sledovat zpoždění. Je zachovávána historie rozhodnutí jednotlivých řešitelů, včetně jejich záznamů do formuláře neshody. Výsledkem procesu je vždy jednoznačné a úplné okamžité řešení, celkové ekonomické zhodnocení neshody, označení původců a návrhy na nápravná opatření. Je umožněno rychlé a přesné vytváření statistických sestav a reportů – vyhodnocení nejakosti projektů, nejakost dle středisek původců apod. Z hlediska servisu je významná jednoduchá dohledatelnost v rámci projektu, resp. zakázky.
|
Přejímka materiálů výroby |
Reklamace |
List neshody může iniciovat vznik nápravného/preventivního opatření, další funkčnosti primárně využívanou úsekem Jakost (přestože řešení opatření může procházet napříč celou společností). Nápravné opatření je opatření řešící příčiny neshody, preventivní opatření řeší potenciální problém, který může k neshodě vést. Cílem těchto opatření je snížení neshod. Původně byla nápravná/preventivní opatření řešena vystavením papírového dokumentu. Řešení v PLM Oracle Agile v podstatě vychází z klasického 8D reportu. Oprávněný pracovník vypíše zadání do formuláře opatření a inicializuje proces WorkFlow. Je zkontrolováno a schváleno zadání, stanovena osoba provádějící rozbor a plánované datum termínu dokončení rozboru. Určená osoba provádějící rozbor popíše kořenovou příčinu, navrhne okamžitá a systémová opatření. Rozbor je následně kontrolován odpovědným pracovníkem jakosti a je buď schválen, nebo vrácen k přepracování. V případě schválení jsou stanoveny jednotlivé úkoly, zodpovědné osoby a termíny. Stanovení rozboru, plnění jednotlivých úkolů, upozornění na blížící se termín splnění úkolu, překročení termínu je hlídáno automaticky systémem, odpovědným osobám jsou zasílány informativní zprávy. Po splnění všech úkolů následuje posouzení jejich splnění, mohou být nadefinovány další úkoly, nebo je stanoven termín pro posouzení efektivnosti opatření. Po uplynutí stanovené lhůty je efektivnost zhodnocena a následně schválena, přičemž je stanoveno, zda opatření bylo, či nebylo účinné. Nástroje Oracle Agile i v tomto případě umožnují přímý monitoring stavu řešení opatření a jednotlivých úkolů, vyčlenění nesplněných úkolů a podobně. Globální pohled poskytuje report sledování a trend nápravných a preventivních opatření.
Program zajištění jakosti
Přílohou smlouvy se zákazníkem je dokument PZJ – Program Zajištění Jakosti. Je to soubor všech zkoušek, které musí být provedeny na zakázce v průběhu projektu. Předepisuje normy a standardy, rozsahy, účasti a provedení kontrol a způsob jejich protokolace. Dokument se týká hlavních součástí rozsahu dodávky a je samozřejmě výsledkem dohody se zákazníkem. Na základě globálního dokumentu PZJ pak pro jednotlivé součásti vyráběné ve Škoda Power vznikají dokumenty PKZ – Programy Kontrol a Zkoušek.Vzhledem k neustále se měnícím normám prováděcích a hodnotících předpisů, ale i vzhledem k možnosti dodatečných změn projektových PZJ (změny rozsahů kontrol, účastí na kontrolách, způsobu protokolování…) musely být ručně vytvářeny a změnovány. S ohledem na význam dokumentu se to týkalo poměrně značného počtu útvarů, které musely schvalovat velké množství dokumentů. Aktuální komplexní řešení pojímá PZJ i PKZ jako strukturovaný dokument, ve kterém jsou odděleny prováděcí a hodnotící předpisy, kontrolní operace a samotné PZJ a PKZ. Umožňuje rychlé vytváření projektových PKZ na základě platné struktury projektového PZJ a platných vzorů PKZ.
Kontroly, hodnocení dodávek
Na základě PZJ jsou určeny kontrolní (zádržné) body, kdy se provádí kontrola (přejímka) obchodního zboží, materiálu pro výrobu, kooperací nebo zákazníkem ve Škoda. Dříve používanou papírovou evidenci všech těchto kontrol nahradila elektronická forma přejímky v PLM. Díky propojení Agile na IS BaaN lze na základě zadaného čísla nákupní objednávky rychle a přesně založit i předvyplnit nový dokument zápis z přejímky. Technik jakosti vyplní příslušná data (připravenost a výsledek kontroly, jednotlivé prováděné zkoušky a jejich výsledky včetně poznámek, hodnocení kontroly) a přiloží scan podepsaného protokolu o kontrole. Dále je provedeno hodnocení dodávky pomocí vážené průměrné známky za dodávku. Hodnocení dodávek je pak důležitý faktor pro hodnocení samotných dodavatelů.V rámci kontrol (přejímek) se provádí tvorba velkého množství protokolů. Také zde byly papírové dokumenty nahrazeny elektronickou formou. Na základě uložených vzorů/šablon směrnic protokolů kontrol a zkoušek (formát MS Word/Excel) dochází k tvorbě předpřipravených protokolů v Agile. Technik jakosti doplní pro příslušný typ protokolu do jeho těla hodnoty (např. pro rozměrovou kontrolu v MS Word k náčrtku doplní naměřené hodnoty). Po schválení dokumentu dochází k automatickému vygenerování finálního pdf souboru. V Agile pak lze snadno dohledat a případně vytisknout potřebný protokol.
Samostatnou skupinou jsou elektronizované dokumenty typu: Prohlášení o shodě a Prohlášení dodavatele o shodě tvořící jednu z částí celkového balíku dokumentace předávané zákazníkovi.
Resumé
Schopnost zajištění kvality je dnes jedním z klíčových parametrů při výběru dodavatele. Tlaky na její zvyšování neustále rostou. Vhodná implementace PLM systému výrazně přispívá k zjednodušení, zpřesnění a organizovanosti práce.Na příkladu Škoda Power jsme ukázali jedno z nejkomplexněji pojatých řešení procesů zajištění jakosti. Můžeme však jmenovat celou řadu dalších společností, kde jsme v menším či větším rozsahu podobné procesy realizovali. Pokud vás procesy zajištění kvality zdržují a nezajišťují dostatečnou transparentnost a rychlost, zkuste se obrátit na svého dodavatele PLM/DMS řešení.
Autor je vedoucím konzultantem ve společnosti TD-IS.