- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
Tematické sekce


















Branžové sekce
![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Partneři webu
IT SYSTEMS 7-8/2005
Praktické zkušenosti z implementace systému TPV
Ing. Vojmír Kubíček
Doba vzniku specializovaných systémů pro přípravu výroby se datuje na počátek devadesátých let. Jejich základní funkcí v tomto období bylo vyplnit mezery, které měly systémy pro řízení výroby v oblasti přípravy dat, tedy tvorby konstrukčních kusovníků a postupů. Zejména to byla správa dat pomocí grafického klasifikačního systému, uživatelsky přívětivější prostředí pro práci konstruktérů a technologů a expertní podpora v oblasti strojařské výroby.
Jestliže se tento typ softwaru chtěl udržet na trhu, musely společnosti, které se vývojem těchto systémů zabývají, přijít s novými funkcemi. Stalo se tak ve druhé polovině devadesátých let, kdy se ve všech oblastech IT přecházelo na grafické aplikace, a stejně tomu bylo i v případě TPV systémů.
Mezi nové funkce, které se objevily, patří:
· Správa a archiv konstrukčních výkresů, komunikace s CAD - tuto funkci se snažili vývojáři přenést i do DOSovských verzí TPV systémů. Jenomže naráželi na problém kompatibility s různými typy CAD systémů a formátu souborů. S příchodem OLE technologie se stala tato funkce univerzální. Nastavení komunikace s CAD systémem a správu výkresů zvládne nastavit sám uživatel bez účasti dodavatelské firmy.
· Management nářadí - kompletní správa nářadí podniku, jeho propojení s operacemi technologického postupu, řízení objednávek nářadí a výdejny.
· Více kusovníků - v životním cyklu výrobku neexistuje pouze jeden pohled na kusovník, a sice konstrukční. Systém musí umět spravovat i kusovníky montážní, technologické, projekční a zvládat inverzní pohledy na tato data.
· Změnové řízení (workflow) - tento typ software se ze systému pro podporu práce technologa a konstruktéra transformoval na manažerský systém pracovní činnosti v technickém úseku. Řídí návrh, schvalování, oběh, vyřizování a archivaci změn. Veškerá činnost je synchronizována s tvorbou CAD výkresů, kusovníků, postupů a nářadí a dalšími dokumenty (MS Office, ...) pomocí správy úloh.
· Časová platnost dokumentace - na základě změnového řízení lze archivovat veškerá data o výrobku z hlediska časových platností dat a mít kdykoliv k dispozici historii výrobku a platná data v daném období.
· Správa dokumentů (DMS) - prvotní požadavek zákazníků na pouhé připojení souboru vytvořeného v jiném programu vedl k vývoji kompletní správy dokumentů, kdy systém spravuje soubory vytvořené v MS Office, speciální operační návodky, archiv fotodokumentace, skenované výkresy a další. Celý proces má svou schvalovací i archivační část.
· Exporty do libovolných formátů - systém ve své grafické podobě zvládá exporty výstupních sestav do různých formátů (XLS, HTML, ...).
Pokud tyto funkce nebyl schopen software pro TPV nabídnout, vedlo to většinou k jeho ztrátě pozice na trhu. Z výše uvedeného je patrné, že označení TPV pro tyto specializované systémy dnes není aktuální a software, který splňuje tuto funkcionalitu, je plnohodnotný PLM systém, tedy systém, který je schopen zachytit veškerá data z období životního cyklu výrobku včetně všech jeho vývojových a funkčních variant. Důvodem pořízení PLM systému a veškerých investic do IT je zlepšení prosperity výrobního podniku. Prosperita podniku závisí na více faktorech. Je to například dobrá obchodní strategie, hledání zákazníků pro stávající výrobky, technická podpora a péče o stávající zákazníky, efektivnost výroby. Toto jsou nástroje využití toho, čím podnik v dané chvíli disponuje. Dalším zdrojem pro zvýšení prosperity (tedy "jak peníze do podniku přinést" ) je zavedení nových výrobků nebo inovace a modifikace stávajících dle přání zákazníka. Na základě schopnosti zavádět nové a inovovat stávající výrobky získává podnik nové zakázky, zvyšuje prodej, tedy příjem a zisk.
Úskalí implementace TPV a PLM
Naše společnost se implementací PLM systému zabývá více než deset let a zkušenosti našich expertů byly aplikovány ve více než 200 výrobních podnicích se strojařskou a nábytkářskou výrobou. Víme tak snad dost o problémech, které mohou při implementaci PLM systémů nastat. Při implementaci PLM systému je nutné dodržet přesné postupy, aby výsledný efekt z hlediska přínosů pro podnik byl co největší. V podnicích, které jsou našimi zákazníky, se při implementaci systému setkáváme s řadou zažitých stereotypů a mylných úsudků uživatelů i managementu, jejichž překonání je rozhodující pro úspěšnou implementaci. Je velice zajímavé, že v těchto falešných předpokladech a chybách při zavedení systému se různé podniky příliš neliší a jako implementační firma se setkáváme se stále stejnými návyky a požadavky na modifikaci systému, jejichž splnění by sice vedlo k rutinnímu provozu, avšak rapidně by se tak snížily očekávané přínosy . V tomto článku bych chtěl dát návod budoucím uživatelům PLM systému, jak bezchybně proplout úskalím implementace a dosáhnout úspěšné realizace projektu zavedení takového informačního systému:
1. Výběrové řízení
V rámci výběrového řízení by se pracovníci odběratele měli podrobněji seznámit s nabízenými systémy. V závěru je vhodné vybrat dva až tři do závěrečného kola. V rámci tohoto kola je nutné navštívit referenční podnik, ve kterém je systém minimálně dva roky v rutinním provozu. Je vhodné vybrat podniky, kde byl systém implementován přesně dle harmonogramu a byly splněny všechny cíle implementace, které si dodavatel s odběratelem vytyčili. Při referenční návštěvě je nutné zjistit jaké přínosy zavedení systému přineslo. Jedno z hledisek představuje samozřejmě i hledisko finanční, nemělo by však být tím hlavním. Pro koncové uživatele odběratele je dobré poznat, že z uživatelského hlediska jejich kolegové v referenčním podniku systém zvládli. Ve výběrovém řízení se musí nejvíce angažovat vedoucí pracovníci a management potenciálního odběratele, kteří by měli posoudit hlavní přínosy a cíle implementace systému. Koncoví uživatelé potenciálního odběratele by měli mít v tomto procesu poradní hlas. Jedním z přínosů zavedení může totiž být i snížení počtu těchto pracovníků, což záleží na konkrétních podmínkách v daném podniku. Z tohoto důvodu pak názor koncových uživatelů nemusí být vždy objektivní.
2. Jasné stanovení cílů a odpovědnosti dodavatele i odběratele - úvodní studie
Jakmile vzejde z výběrového řízení vítěz, nastává možná nejdůležitější fáze implementace. Vzájemně stanovit jasné cíle a milníky implementace. Cíle by měly být stanoveny na základě úvodní analýzy, jejíž výsledky by se měly stát součástí smlouvy o dílo, nebo jejího dodatku, což záleží na vzájemné dohodě odběratele a dodavatele. Analýza (úvodní studie) musí stanovit nejen cíle, ale také konkrétně popsat, jak těchto cílů bude dosaženo. Musí být jasné, co pro splnění cílů musí udělat pracovníci dodavatele, ale zejména pracovníci odběratele. Pokud není jasně specifikována odpovědnost a kompetence pracovníků odběratele, je tento fakt při implementaci největším zdrojem problémů. Stává se velice často, že se vedoucí pracovníci managementu odběratele po podpisu smlouvy o dílo domnívají, že hlavní odpovědnost od tohoto okamžiku nese dodavatel. V úvodní analýze by měl být jmenován i společný tým pracovníků dodavatele a odběratele, který bude za implementaci zodpovědný. Odpovědnost by měla být rozepsána na konkrétní osoby. Dále by měl být stanoven harmonogram realizace opět se stanovením konkrétní odpovědnosti pracovníků odběratele i dodavatele za splnění jednotlivých bodů harmonogramu.
3. Implementace
Při implementaci je nutné udržet milníky a harmonogram schválený v úvodní studii. Až v této fázi se pracovníci odběratele seznamují podrobně s funkčností systému. Po úvodním školení a simulaci základních činností totiž pravidelně dochází ze strany uživatelů ke vznesení požadavků na změnu harmonogramu realizace a požadavků na programové úpravy, které ve velké většině případů nevedou k vylepšení funkcionality systému, ale snaží se kopírovat styl způsobu práce před zavedením PLM systému. Pracovníci odběratele v mnoha případech odmítají využít funkčnosti systému a chtějí aby se systém zcela přizpůsobil jejich návykům. Ty však mohou být právě příčinou neefektivní práce v předvýrobních etapách. Tyto požadavky by měli konzultanti a programátoři dodavatelské firmy odmítnout. Z praxe víme, že je to někdy velice těžké a tlak pracovníků odběratelské firmy bývá velký. Ne všechny požadavky na programové úpravy systému mohou být špatné. Ty, které jsou oprávněné by měly být v rámci implementace vyhodnoceny a rozděleny do dvou kategorií:
· programové úpravy bez nichž nelze spustit rutinní provoz,
· programové úpravy, které mohou být realizovány po rutinním provozu.
Programové, bez nichž nelze spustit rutinní provoz musí být začleněny do harmonogramu realizace. V případě, že by jejich rozsah byl vetší, je nutno harmonogram realizace přepracovat. Z praxe víme, že sebelépe provedená úvodní studie nedefinuje všechno, co musí být provedeno, a často se stává, že nutné programové úpravy objeví pracovníci odběratele až při implementačních školeních a simulaci procesu tvorby dat. Programové úpravy, které mohou být realizovány po spuštění rutinního provozu, jsou takové úpravy, které mají své opodstatnění, ale pouze zlepšují uživatelský komfort. Při jejich realizaci je nutné zvážit, zda takové zásahy do programu nebudou komplikovat upgrade a update na novější verze PLM systému.
4. Zkušební provoz
Po splnění všech milníků a harmonogramu realizace je nutné spustit zkušební provoz. Obvykle navrhujeme jeden měsíc, ale termín lze po dohodě obou stran zkrátit. V této fázi realizace probíhá proces tvorby dat jako v rutinním provozu. Data však ještě nejsou převáděna do ostré databáze ERP systému. Tato fáze je náročná pro uživatele, protože musí zadávat výrobní data dvakrát. Jednou do starého systému a jednou do nového.
5. Rutinní provoz
Rutinní provoz obvykle navrhujme třetí měsíc po počátku realizace. Přesný termín by měl být stanoven v harmonogramu implementace v úvodní studii.U některých složitějších projektů může být rutinní provoz spuštěn i půl roku po počátku realizace. V této fázi již běží proces přenosu dat do ostré databáze ERP systému.
6. Záruční a pozáruční servis
Po spuštění rutinního provozu by měl být vyřešen záruční a pozáruční servis systému. Obvykle je toto ošetřeno smlouvou o servisu systému. V této smlouvě jsou stanoveny paušální roční platby za maintenance, v jejímž rámci jsou stanoveny podmínky pozáručního servisu, upgrade a update systému.
Závěr
Po mnoha realizovaných projektech, které máme jako společnost za sebou, mohu říci, že velice záleží na tom, zda se dodavateli i odběrateli podaří dodržet dohodnutý harmonogram a zda dodavatel dokáže čelit požadavkům na neefektivní programové úpravy. Pokud se postupuje správně, dá se rutinní provoz spustit velice rychle. V podniku AMF Reece Prostějov, který je výrobcem průmyslových šicích strojů, se to podařilo za 29 dní po počátku realizace projektu. Stalo se to hlavně díky přístupu pracovníků odběratele.
Autor článku, Ing. Vojmír Kubíček, je obchodním ředitelem a konzultantem firmy Sysklass CZ.


Mezi nové funkce, které se objevily, patří:
· Správa a archiv konstrukčních výkresů, komunikace s CAD - tuto funkci se snažili vývojáři přenést i do DOSovských verzí TPV systémů. Jenomže naráželi na problém kompatibility s různými typy CAD systémů a formátu souborů. S příchodem OLE technologie se stala tato funkce univerzální. Nastavení komunikace s CAD systémem a správu výkresů zvládne nastavit sám uživatel bez účasti dodavatelské firmy.
· Management nářadí - kompletní správa nářadí podniku, jeho propojení s operacemi technologického postupu, řízení objednávek nářadí a výdejny.
· Více kusovníků - v životním cyklu výrobku neexistuje pouze jeden pohled na kusovník, a sice konstrukční. Systém musí umět spravovat i kusovníky montážní, technologické, projekční a zvládat inverzní pohledy na tato data.
· Změnové řízení (workflow) - tento typ software se ze systému pro podporu práce technologa a konstruktéra transformoval na manažerský systém pracovní činnosti v technickém úseku. Řídí návrh, schvalování, oběh, vyřizování a archivaci změn. Veškerá činnost je synchronizována s tvorbou CAD výkresů, kusovníků, postupů a nářadí a dalšími dokumenty (MS Office, ...) pomocí správy úloh.
· Časová platnost dokumentace - na základě změnového řízení lze archivovat veškerá data o výrobku z hlediska časových platností dat a mít kdykoliv k dispozici historii výrobku a platná data v daném období.
· Správa dokumentů (DMS) - prvotní požadavek zákazníků na pouhé připojení souboru vytvořeného v jiném programu vedl k vývoji kompletní správy dokumentů, kdy systém spravuje soubory vytvořené v MS Office, speciální operační návodky, archiv fotodokumentace, skenované výkresy a další. Celý proces má svou schvalovací i archivační část.
· Exporty do libovolných formátů - systém ve své grafické podobě zvládá exporty výstupních sestav do různých formátů (XLS, HTML, ...).
Pokud tyto funkce nebyl schopen software pro TPV nabídnout, vedlo to většinou k jeho ztrátě pozice na trhu. Z výše uvedeného je patrné, že označení TPV pro tyto specializované systémy dnes není aktuální a software, který splňuje tuto funkcionalitu, je plnohodnotný PLM systém, tedy systém, který je schopen zachytit veškerá data z období životního cyklu výrobku včetně všech jeho vývojových a funkčních variant. Důvodem pořízení PLM systému a veškerých investic do IT je zlepšení prosperity výrobního podniku. Prosperita podniku závisí na více faktorech. Je to například dobrá obchodní strategie, hledání zákazníků pro stávající výrobky, technická podpora a péče o stávající zákazníky, efektivnost výroby. Toto jsou nástroje využití toho, čím podnik v dané chvíli disponuje. Dalším zdrojem pro zvýšení prosperity (tedy "jak peníze do podniku přinést" ) je zavedení nových výrobků nebo inovace a modifikace stávajících dle přání zákazníka. Na základě schopnosti zavádět nové a inovovat stávající výrobky získává podnik nové zakázky, zvyšuje prodej, tedy příjem a zisk.
Úskalí implementace TPV a PLM
Naše společnost se implementací PLM systému zabývá více než deset let a zkušenosti našich expertů byly aplikovány ve více než 200 výrobních podnicích se strojařskou a nábytkářskou výrobou. Víme tak snad dost o problémech, které mohou při implementaci PLM systémů nastat. Při implementaci PLM systému je nutné dodržet přesné postupy, aby výsledný efekt z hlediska přínosů pro podnik byl co největší. V podnicích, které jsou našimi zákazníky, se při implementaci systému setkáváme s řadou zažitých stereotypů a mylných úsudků uživatelů i managementu, jejichž překonání je rozhodující pro úspěšnou implementaci. Je velice zajímavé, že v těchto falešných předpokladech a chybách při zavedení systému se různé podniky příliš neliší a jako implementační firma se setkáváme se stále stejnými návyky a požadavky na modifikaci systému, jejichž splnění by sice vedlo k rutinnímu provozu, avšak rapidně by se tak snížily očekávané přínosy . V tomto článku bych chtěl dát návod budoucím uživatelům PLM systému, jak bezchybně proplout úskalím implementace a dosáhnout úspěšné realizace projektu zavedení takového informačního systému:
1. Výběrové řízení
V rámci výběrového řízení by se pracovníci odběratele měli podrobněji seznámit s nabízenými systémy. V závěru je vhodné vybrat dva až tři do závěrečného kola. V rámci tohoto kola je nutné navštívit referenční podnik, ve kterém je systém minimálně dva roky v rutinním provozu. Je vhodné vybrat podniky, kde byl systém implementován přesně dle harmonogramu a byly splněny všechny cíle implementace, které si dodavatel s odběratelem vytyčili. Při referenční návštěvě je nutné zjistit jaké přínosy zavedení systému přineslo. Jedno z hledisek představuje samozřejmě i hledisko finanční, nemělo by však být tím hlavním. Pro koncové uživatele odběratele je dobré poznat, že z uživatelského hlediska jejich kolegové v referenčním podniku systém zvládli. Ve výběrovém řízení se musí nejvíce angažovat vedoucí pracovníci a management potenciálního odběratele, kteří by měli posoudit hlavní přínosy a cíle implementace systému. Koncoví uživatelé potenciálního odběratele by měli mít v tomto procesu poradní hlas. Jedním z přínosů zavedení může totiž být i snížení počtu těchto pracovníků, což záleží na konkrétních podmínkách v daném podniku. Z tohoto důvodu pak názor koncových uživatelů nemusí být vždy objektivní.
2. Jasné stanovení cílů a odpovědnosti dodavatele i odběratele - úvodní studie
Jakmile vzejde z výběrového řízení vítěz, nastává možná nejdůležitější fáze implementace. Vzájemně stanovit jasné cíle a milníky implementace. Cíle by měly být stanoveny na základě úvodní analýzy, jejíž výsledky by se měly stát součástí smlouvy o dílo, nebo jejího dodatku, což záleží na vzájemné dohodě odběratele a dodavatele. Analýza (úvodní studie) musí stanovit nejen cíle, ale také konkrétně popsat, jak těchto cílů bude dosaženo. Musí být jasné, co pro splnění cílů musí udělat pracovníci dodavatele, ale zejména pracovníci odběratele. Pokud není jasně specifikována odpovědnost a kompetence pracovníků odběratele, je tento fakt při implementaci největším zdrojem problémů. Stává se velice často, že se vedoucí pracovníci managementu odběratele po podpisu smlouvy o dílo domnívají, že hlavní odpovědnost od tohoto okamžiku nese dodavatel. V úvodní analýze by měl být jmenován i společný tým pracovníků dodavatele a odběratele, který bude za implementaci zodpovědný. Odpovědnost by měla být rozepsána na konkrétní osoby. Dále by měl být stanoven harmonogram realizace opět se stanovením konkrétní odpovědnosti pracovníků odběratele i dodavatele za splnění jednotlivých bodů harmonogramu.
3. Implementace
Při implementaci je nutné udržet milníky a harmonogram schválený v úvodní studii. Až v této fázi se pracovníci odběratele seznamují podrobně s funkčností systému. Po úvodním školení a simulaci základních činností totiž pravidelně dochází ze strany uživatelů ke vznesení požadavků na změnu harmonogramu realizace a požadavků na programové úpravy, které ve velké většině případů nevedou k vylepšení funkcionality systému, ale snaží se kopírovat styl způsobu práce před zavedením PLM systému. Pracovníci odběratele v mnoha případech odmítají využít funkčnosti systému a chtějí aby se systém zcela přizpůsobil jejich návykům. Ty však mohou být právě příčinou neefektivní práce v předvýrobních etapách. Tyto požadavky by měli konzultanti a programátoři dodavatelské firmy odmítnout. Z praxe víme, že je to někdy velice těžké a tlak pracovníků odběratelské firmy bývá velký. Ne všechny požadavky na programové úpravy systému mohou být špatné. Ty, které jsou oprávněné by měly být v rámci implementace vyhodnoceny a rozděleny do dvou kategorií:
· programové úpravy bez nichž nelze spustit rutinní provoz,
· programové úpravy, které mohou být realizovány po rutinním provozu.
Programové, bez nichž nelze spustit rutinní provoz musí být začleněny do harmonogramu realizace. V případě, že by jejich rozsah byl vetší, je nutno harmonogram realizace přepracovat. Z praxe víme, že sebelépe provedená úvodní studie nedefinuje všechno, co musí být provedeno, a často se stává, že nutné programové úpravy objeví pracovníci odběratele až při implementačních školeních a simulaci procesu tvorby dat. Programové úpravy, které mohou být realizovány po spuštění rutinního provozu, jsou takové úpravy, které mají své opodstatnění, ale pouze zlepšují uživatelský komfort. Při jejich realizaci je nutné zvážit, zda takové zásahy do programu nebudou komplikovat upgrade a update na novější verze PLM systému.
4. Zkušební provoz
Po splnění všech milníků a harmonogramu realizace je nutné spustit zkušební provoz. Obvykle navrhujeme jeden měsíc, ale termín lze po dohodě obou stran zkrátit. V této fázi realizace probíhá proces tvorby dat jako v rutinním provozu. Data však ještě nejsou převáděna do ostré databáze ERP systému. Tato fáze je náročná pro uživatele, protože musí zadávat výrobní data dvakrát. Jednou do starého systému a jednou do nového.
5. Rutinní provoz
Rutinní provoz obvykle navrhujme třetí měsíc po počátku realizace. Přesný termín by měl být stanoven v harmonogramu implementace v úvodní studii.U některých složitějších projektů může být rutinní provoz spuštěn i půl roku po počátku realizace. V této fázi již běží proces přenosu dat do ostré databáze ERP systému.
6. Záruční a pozáruční servis
Po spuštění rutinního provozu by měl být vyřešen záruční a pozáruční servis systému. Obvykle je toto ošetřeno smlouvou o servisu systému. V této smlouvě jsou stanoveny paušální roční platby za maintenance, v jejímž rámci jsou stanoveny podmínky pozáručního servisu, upgrade a update systému.
Závěr
Po mnoha realizovaných projektech, které máme jako společnost za sebou, mohu říci, že velice záleží na tom, zda se dodavateli i odběrateli podaří dodržet dohodnutý harmonogram a zda dodavatel dokáže čelit požadavkům na neefektivní programové úpravy. Pokud se postupuje správně, dá se rutinní provoz spustit velice rychle. V podniku AMF Reece Prostějov, který je výrobcem průmyslových šicích strojů, se to podařilo za 29 dní po počátku realizace projektu. Stalo se to hlavně díky přístupu pracovníků odběratele.
Autor článku, Ing. Vojmír Kubíček, je obchodním ředitelem a konzultantem firmy Sysklass CZ.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.
![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
IT Systems podporuje
Formulář pro přidání akce
Další vybrané akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |