POINT.X (2018-19)
CAD - online trafika
Google překladač: English Deutsch

Exkluzivní partner sekce

Siemens
Dytron
Siemens - CAM webinar
SolidWorks

GOPAS - CAD kurzy

Více kurzů

StreamTech.tv

streamtech tv-logo

Jak popsat požadované chování systému údržby dat výrobku

Tags: PLM

PLMJedním z hlavních úkolů implementačního týmu při implementaci systému je dosáhnout toho, aby výsledný systém odpovídal skutečným potřebám podniku. V tomto ohledu nelze nechat aktivitu pouze na firmě, která systém implementuje. I když každá tato firma postupuje podle osvědčené metodiky, je třeba, aby dostávala kvalitní podklady, které skutečně popisují procesy a objekty podniku.

Cegra - Graphisoft ARCHICAD 22

Výše uvedené předpoklady ovšem u tak složitého systému, jako je např. PLM systém, není tak snadné zaručit.

 

V mnoha podnicích se vyskytují skryté zdroje rizik neúspěšné implementace:

  • Nejsou vyjasněny potřeby sdílení dat, zejména s externími řešiteli.
  • Není jasné, jaké objekty mají být klasifikovány a jak.
  • Není dostatečně nadefinován proces změnového řízení ani procesy změn jednotlivých dokumentů.
  • Obecné projektové řízení nezohledňuje odlišnosti vývoje výrobku.
  • Nejsou dostatečně jasné vztahy mezi jednotlivými strukturami výrobku (výrobní, konstrukční, obchodní, expediční) a organizační stránka procesů konverze z jedné struktury na druhou.
  • Není jasná koncepce variant výrobku.
  • Není jasné, jaké všechny typy dokumentu existují, jak jsou spravovány, jaký je jejich oběh podnikem.
  • Nejsou jasné vazby nástrojů zpracování dokumentů.

Takovéto skutečnosti mají pak za následek neschopnost držet se odhadnutých nákladů, dodržet požadované datum dokončení a dosáhnout požadované kvality a splnit požadavky na provoz. Implementace PLM systému se pak stává neúspěšnou.
Aby se takovýmto rizikům předešlo, je třeba vytvořit model požadovaného chování systému. Bude-li tento model udržován i po implementaci, významně napomůže skutečně koncepční správě systému.
Následující text popíše model chování PLM systému spravujícího data výrobku.

Jak již bylo naznačeno, Model chování systému je vytvářen, aby splnil dva základní cíle:

  • Minimalizace některých rizik implementace PLM nástrojů
  • Systematická správa systému PLM v podniku

Aby model splnil výše uvedené cíle, musí mít následující vlastnosti:

  • Měl by být nezávislý na použitých informačních systémech, HW i SW nástrojích.
  • Měl by být snadno udržovatelný a jednoduše rozšiřovatelný.
  • Měly by z něj být snadno odvoditelné všechny následující návrhy, popisy, koncepce, které slouží optimální správě know-how.


Model chování systému PLM v podniku je charakterizován jednotlivými úrovněmi. Ty vycházejí z objektů zájmu PLM nástrojů, uvažujeme-li tvorbu a správu dat výrobku. PLM nástroje napomáhají efektivně řídit a provádět celopodnikové procesy spojené s projekty vývoje a realizace výrobku, jenž je popisován dokumenty spravovanými různými řídicími systémy, nástroji.
Schematicky znázorněný model chování systému je na obr. 1. Přirovnává podnik k plachetnici, která pro svůj pohyb potřebuje plachty správně zavěšené na pevném stěžni. Tyto dva prvky ovlivňují dění na palubě a v kajutě a naopak, toto dění zpětně ovlivňuje i stav plachet a stěžně.
Obr. 1 Schematické znázornění modelu chování systému
Obr. 1 Schematické znázornění modelu chování systému

V každé úrovni jsou rozebírány jednotlivé objekty, procesy s nimi pracující i vykonavatelé tyto procesy vykonávající. Dále budou popsány jednotlivé úrovně modelu podrobněji.

Úroveň podniku

Na této úrovni je třeba popsat:

  • Vykonavatelé
  • Klasifikační systém
  • Sdílení informací
  • Změnové řízení
  • Procesy správy dat výrobku

Předně je zapotřebí zachytit tzv. role pracovníků, tj. typické představitele pracovníků určitých schopností. Protože se jedná o pracovníky v liniové i projektové struktuře podniku a je žádoucí zachytit i jemnější dělení, než postihuje tradiční organizační struktura podniku, není vhodné zakreslovat klasický organigram. Je lépe vytvořit strukturu rolí pracovníků, která definuje role a vazby mezi nimi.
Dále je třeba kategorizovat partnery (zejména dodavatele, odběratele, obchodní zástupce) z pohledu jejich potřeb dat výrobku. Tím vzniknou zástupci externích partnerů, kteří jsou pak užiti při posuzování vazeb podniku na okolí.
Klasifikační systém umožňuje klasifikovat z mnoha hledisek, tj. přiřadit objektům hodnoty určitých parametrů a pak následně vyhledávat všechny podnikové objekty, tj. vybrat ty objekty, jejichž parametry splňují zadané podmínky. Proto je modelován na úrovni podniku, přestože podklady pro něj vznikají a jsou i znázorněny v úrovních PROJEKT, VÝROBEK, DOKUMENT. Na úrovni podniku jde o sjednocení pohledů a principů.
Předně jsou zde zachyceny podnikové objekty, které jsou klasifikovány, a jejich případné vzájemné vztahy. U těchto objektů je třeba definovat, jakými hledisky budou klasifikovány (funkční hledisko, technologické, obchodní atp.). Tato hlediska mohou být totožná pro objekty více úrovní (PROJEKT, VÝROBEK, DOKUMENT). Každému hledisku je třeba přiřadit klasifikační strom. Uzly tohoto stromu jsou ohodnoceny výčtem parametrů, které rozhodují o kategorii na nižší úrovni. Hrany pak hodnotami, výčtem či rozsahem hodnot těchto parametrů. Na základě hledisek jsou shromážděny parametry klasifikačního systému. Hlediska je třeba definovat velmi uvážlivě, neboť musí splňovat následující požadavky:

  • Musí být jednoznačná, tj. nesmí být žádné pochyby o tom, jak konkrétní objekt zaklasifikovat
  • Musí být vyvážená, tj. výsledkem klasifikace musí být rozumný počet vybraných objektů, který lze jednoduše vyhodnotit
  • Nesmí být příliš pracná, protože jinak je velké riziko, že nebudou naplňována


Model sdílení informací s okolím sestává z data flow diagramu, jehož uzly jsou podnik a externí partneři. Hrany jsou ohodnoceny typy dokumentů, které daná skupina partnerů potřebuje pro svou práci. Kromě typů dokumentu může být hrana ohodnocena navíc omezením dle parametrů typu dokumentu.

Pro popis změnového řízení je třeba nadefinovat především kategorizaci změn, přičemž jednotlivé kategorie by měly vést na jiné procesy změn. Příkladem této kategorizace může být rozdělení změn dle původce změny, protože v takovém případě může mít změna jako celek jiný průběh schvalování i následného zpracování. Z pohledu procesů změn je velmi významným hlediskem rozdělení změn:

  • Typická změna – poměrně velká četnost, průběh lze standardizovat, řízení změny lze silně zautomatizovat
  • Netypická změna – nízká četnost, průběh změny je do určité míry jedinečný, na vlastní zpracování změny je tedy nutné striktně dohlížet


Kategorie může být charakterizována omezením druhů dokumentu, typů výrobku nebo projektu, kterých se může týkat. Lze také připojit kalkulační vzorec, jímž se bude změna kalkulovat.
Ke každé kategorii změn vznikne diagram procesu, nejlépe EPC diagram.
Jako další je žádoucí popsat všechny procesy, které souvisí se správou znalostí (kontrolní mechanismy, dolování znalostí atp.). K popisu je vhodné použít EPC diagram (viz obr. 2).
obr. 2 Ukázka EPC diagramu
obr. 2 Ukázka EPC diagramu

Úroveň projektu
V prvé řadě je nutné projekty kategorizovat (např. dle typů výrobků či dle toho, do jaké kategorie patří zákazník atp.) a určit tak typy projektů. Ke každé kategorii je pak třeba popsat:

  • Role pracovníků projektu (organizační struktura projektu)
  • Klasifikace projektu (hlediska a parametry, které se vztahují k projektu a které jsou popsány na úrovni podniku)
  • Struktura projektu
  • Vazby na výrobky (jaké výrobky jsou tímto projektem vyráběny)
  • Vazby na a dokumenty (jaké dokumenty jsou s projektem spjaty)
  • Procesy plánování a realizace projektu

Úroveň výrobku

V prvé řadě je nutné výrobky kategorizovat a určit tak typy výrobku. Ke každé kategorii je pak třeba popsat:

  • Klasifikace výrobku
  • Konfigurace výrobku
  • Struktury výrobku
  • Vazby na dokumenty
  • Procesy plánování a realizace výrobku

Pro každý typ výrobku je nutné určit hlediska klasifikace výrobků. Hlediska byla popsána na úrovni podniku. Na této úrovni se jedná pouze o výčet.
Seznam parametrů výrobku je sjednocení parametrů vyskytujících se v jednotlivých hlediscích. Ke každému parametru samozřejmě patří i výčet možných hodnot. Bylo by nanejvýš žádoucí, aby podnik měl rozmyšleno, které hodnoty považuje za standardní řešení a které jako atyp. Je to výchozí podklad pro stanovení koncepce variant výrobku.
Protože pro různé procesy vývoje a realizace výrobku je zapotřebí jiných struktur (konstrukční, výrobní, obchodní, expediční atp.), je žádoucí navrhnout dané struktury. Na druhé straně je ovšem nutné si uvědomit, že používání různých struktur vede bez striktně dodržované správy dat a bez všeobecné znalosti jednotlivých struktur k nižšímu vzájemnému pochopení různých rolí pracovníků a bez procesní orientace podniku může vést k destabilizaci celého procesu vývoje a realizace výrobku, neboť konverze jedné struktury na druhou vyžaduje součinnost všech zúčastněných.
Proto před návrhem typů struktur je třeba provést zevrubnou analýzu, v jakých případech se struktura liší a do jaké míry vadí fakt, že některá struktura nahrazuje jinou. Např. obvykle konstrukční struktura nahrazuje výrobní. Tato praxe vede k jakémusi hybridu, který obvykle rozporují obě role pracovníků. Tento fakt je pak třeba porovnat s konkrétní mírou nebezpečí destabilizace procesů a uvážlivě rozhodnout.
Dalším předpokladem je fakt, že výrobek musí být modulární. To je nutná, nikoliv postačující podmínka, neboť bez toho se nemůže podařit struktury a vazby mezi nimi nadefinovat.
Každá taková struktura je charakterizována variantním kusovníkem, jehož uzly jsou ohodnoceny parametry, které generují různé varianty daného celku (viz obr. 3).
V kusové výrobě je bezpodmínečně nutné, aby existovala koncepce variant výrobku, tj. aby se jasně oddělil standardní výrobek od nestandardního. Varianty standardní (se standardními parametry) budou udržovány v základních datech struktur a budou východiskem pro konfigurátor výrobku, příp. šablonou pro atypické řešení. Nestandardní varianty budou k dispozici v datech projektu, kde vznikly. Kdyby nedošlo k systematické selekci variant, bylo by variant buď příliš mnoho a pak by byl problém s údržbou a algoritmickým popisem konfigurátoru výrobku, anebo příliš málo a vše by bylo v projektových datech, konfigurátor výrobku by neměl data.
U každého typu výrobku musí být dále známé průběhy procesu realizace a následné údržby výrobku. K zachycení poslouží EPC diagram procesu (viz obr. 2).
Kromě toho je nutné pro typ výrobku popsat pravidla plánování výrobku. Tím je míněno:

  • Časové plánování
  • Nákladové plánování

Obr. 3 Schématické znázornění jednoúrovňového variantního kusovníku
Obr. 3 Schématické znázornění jednoúrovňového variantního kusovníku

Úroveň dokumentu
V prvé řadě je nutné dokumenty kategorizovat a určit tak typy dokumentu. Ke každé kategorii je pak třeba popsat:

  • Správci dokumentů (kdo typ dokumentu může zakládat, měnit, rušit, zobrazovat či jinak s ním nakládat)
  • Klasifikace dokumentu (hlediska a parametry popsané na úrovni podniku a popisující typ dokumentu)
  • Struktura dokumentu (vztahy k ostatním typům dokumentu)
  • Procesy zakládání, údržby, archivace, ostatních speciálních činností (popsané EPC diagramem, případně stavovým diagramem – viz obr. 4)

Obr. 4 Ukázka stavového diagramuvariantního kusovníku
Obr. 4 Ukázka stavového diagramu

Úroveň nástrojů

Na úrovni nástrojů je třeba dát do souvislostí HW prostředky, řídicí systémy, úložná archívní média, dokumenty a klíčové činnosti. Z popisu musí být jasné vazby:

  • HW prostředky
    • Systémy operující na HW
    • Uložené typy dokumentu (kromě těch, které jsou spravovány systémy operujícími na HW)
    • Spravovaná úložná média
  • Systémy
    • Spravované typy dokumentů
    • Klíčové činnosti podniku prováděné v systému
  • Úložná média
    • Uložené typy dokumentu

V každém případě je nutné vytvořit data flow diagram, který zachytí nutné datové toky mezi systémy (viz. obr. 5), tj. jaká data z jednoho systému jsou zapotřebí v druhém systému. Uzly tohoto grafu představují systémy, hrany dokumenty.
 Obr. 5 Ilustrativní ukázka data flow diagramu popisujícího datové toky mezi systémy
Obr. 5 Ilustrativní ukázka data flow diagramu popisujícího datové toky mezi systémy

Je zřejmé, že podnik popisuje ty prvky, které chce systémem PLM řídit.
Závěrem je třeba říci, že zcela podle přísloví „Těžko na cvičišti, lehko na bojišti“ platí, že čím bude takovýto model zpracován pečlivěji, tím bude jednodušší se s pracovníky implementující firmy domluvit, jaké jsou skutečné potřeby podniku, a tím také bude jednodušší dělat nutné zásadní zásahy do systému.


Mohlo by vás zajímat:
 

Přidat komentář

Bezpečnostní kód
Obnovit