
Abych pravdu řekl, pro naši generaci už není jednoduché tohle pochopit. Je tedy potřeba příklad. Něčím jednoduchým začít a pak to rozvíjet. Jenže představa je, že musím mít všechny datové balíky najednou, včetně snímání dat z pecí.
Opak je pravdou. Nemusím. Mohu začít zcela bez toho.
Obvykle celý proces evidence zakázky v ERP systému začínáme u RFQ, u poptávky. V praxi to znamená, že musíme vytvořit v ERP nabídkový výrobek, s nabídkovým výrobním postupem, ten validovat přes kontrolu proveditelnosti, přiřadit mu náklady a navrhnout margin, tedy celkovou prodejní cenu. Nakonec prokazatelným způsobem musíme tuto nabídku schválit a zaslat zákazníkovi včetně VOP.
Co k tomu potřebuji?
✔ ERP
✔ API (JSON request/response)
✔ Datová vrstva: dokumentové nebo souborové úložiště, SQL databáze/datový sklad a případně data lake nebo lakehouse.
V této konfiguraci není žádné propojení pecí, ale i tak AI umí: technologickou proveditelnost (feasibility), výběr pece, výběr procesu nebo výrobního postupu, predikci CHD, predikci tvrdosti, PPAP, predikci deformací, výpočet nákladů, výpočet termínu, auditní log, automatické vytvoření nabídky, automatické připojení VOP.
Protože v této fázi implementace není nutno komunikovat s pecemi, OPC UA zatím nepotřebuji. To nastane až v pozdější etapě, kdy již budu mít první praktické zkušenosti s AI a jejím využitím. Již nyní však musí existovat v ERP dostatečně kvalitní historická data o procesech a jejich výsledcích.
Protože hned na začátku si musím nadefinovat datovou strukturu, jednotlivá pole, pak mohu do datového skladu přenést řadu záznamů z ERP z existujících, realizovaných procesů, včetně příslušných identifikačních dat teplot, tlaků, průtoků, pokud je mám nastaveny ve výrobních postupech, jako požadavek na setup řídících systémů pecí.
Procesní záznamy o cyklech musí kalírna archivovat po dobu stanovenou zákaznickými, normativními, smluvními a právními požadavky; často jde o mnoho let. Obvykle ale tyto záznamy leží mimo ERP a nejsou nijak digitálně provázány.
Řada kalíren ale již snímání procesních dat má. Chybí ale jejich identifikace na cyklus. Jsou snímána a archivována jako nekonečný záznam. Najít proto konkrétní záznam z cyklu znamená identifikovat Cycle START a Cycle END v ERP systému, a následně pak vyfiltrovat konkrétní úsek dat v nekonečném záznamu. Abychom si tedy vylepšili budoucí pozici, pokud tento problém vyřešíme již dnes, zítra se nám to bude velmi a velmi hodit.
Protože většina úkonů, které AI bude v budoucnu provádět se bude vztahovat k dávce a k cyklu, je potřeba se s tím vypořádat. Opět je to vázáno na historický přístup managementu kalíren k této oblasti. Jsou kalírny, kde je toto již samozřejmostí, jsou ale kalírny, které se stále vzpírají. Ty ale o to horší budou mít budoucnost.
Když si to převedu do praxe, základem všeho je řízení cyklu v ERP. Pokud ho aplikuji, vím, kdy cyklus začal a kdy skončil, mám jeho ID, vím, jaké výrobky byly v cyklu zpracovány, jaké měly ID, jaké bylo JOB ID, za jakých podmínek se proces realizoval (teploty, tlaky, průtoky, poruchy), a s jakým výsledkem. Pokud k tomu budu mít ještě záznam dat z pece, spotřeb energie, plynů a jiného přímého materiálu, mám vše, co potřebuji a jsem schopen AI nasytit dostatečným množstvím reálných informací. Ta data z pecí ale v této úvodní fázi nepotřebuji.
Jenže tady je problém. Klasický komerční produkt ERP tohle neumí. Ani SAP, ani Navision, ani Microsoft Dynamic AX 2012 ani QI. Musí se to prostě nejdříve doprogramovat. Problém není v chybějící funkci, ale základní problémem je, že klasický cyklus v ERP systémech je stavěn např. pro obráběcí stroje, kde je vazba 1:1, jeden produkt, jeden stroj. V tepelném zpracování je ale cyklus s vazbou 1:X, tedy v jednom cyklu bude více zakázek, více výrobních objednávek, více produktů.
Kompromisem je např. řešení TTC-Informatik GmbH, kde všechny funkce potřebné pro tepelné zpracování existují, je to ale výrobní modul, mimo ERP. Abychom to tedy zprovoznili, musím vytvořit bridge mezi ERP a TTC. Možná je to pro programátory jednoduší, ale z hlediska firmy je lepší mít jen jeden systém. Údržba propojení bude náročná, protože změna v jednom systému bude nutně generovat i změnu v propojovacím můstku, někdy i v druhém systému.
Vyplývá ale z toho i to, že ERP systém je neodmyslitelným základem pro jakoukoliv budoucí AI. Jsou zde uloženi zákazníci, produkty, postupy, výrobní zakázky, cykly, data o jakosti, dodací listy, faktury, ale i reklamace a náklady na ně.
A tak vyvstává základní otázka. Dokáže nám AI s tím pomoci? Domnívám se, že jen pouze částečně. V analytice, predikci, statistice, v návrhu. Nepomůže nám ale s klasickou výrobou, ta je striktně zakotvena v zákaznických ujednáních, výrobních návodkách, v požadavcích na jakost, kdy nemáme obvykle oprávnění cokoliv měnit bez souhlasu zákazníka.
Pokud máme opakující se výrobek, pak vše je striktně definováno v ERP systému, a příjem zakázky je běžnou rutinou. AI nám ale pomůže kontrolovat spolehlivost výsledků, trendy, závislosti, může navrhovat změny přípravkování, optimalizaci dávek, může nám velmi kvalitně provádět plánování, ale nemá oprávnění provádět jakýkoliv přímý zásah do nastavení ERP. Stejně tak ale AI nesmí do SCADA nebo PLC!!
Především nám tedy může pomoci navrhovat novou výrobu. Tedy zúčastnit se procesu RFQ. K nabídkovému výrobku nám vybere nebo sestaví optimální postup, vybere pece, pomůže nám provést optimalizaci vsázek a tím i definovat nabídkovou cenu. Tato oblast je velice široká a zde je možno, resp. i nutno začít. Tady se ukážou její pozitivní vlastnosti, v návrhu, v predikci, v analytice.
Je tedy otázkou, jestli se vůbec tato investice vyplatí. Pokud si kupuji pec s AI metrikou, skvělé. Kupuji hotový produkt, nemusím se o nic starat, tato metrika mi ochrání kritické stavy pece, navrhne mi kroky preventivní údržby nebo mi omezení některé funkce tak, aby nedošlo k poškození pece.
Pokud se ale do vývoje vrhnu sám, jen příprava ERP systému pro AI bude stát velký balík peněz. A už na začátku s musím klást otázku: vím jak na to?
Teprve až projdu touto etapou, mohu se pustit do AI.
=======================================================================================================
Použité zkratky:
AI: Artificial Intelligence
API: Application Programming Interface: definované rozhraní a soubor pravidel, podle kterých si dva systémy předávají data a příkazy. Webové API může být dostupné prostřednictvím jedné nebo více URL adres, označovaných jako endpoints.
JSON: JavaScript Object Notation: textový formát pro strukturovaný přenos dat. Vznikl v prostředí JavaScriptu, ale dnes je nezávislý na programovacím jazyce.
Middleware: integrační vrstva, která propojuje systémy, transformuje data, řídí komunikaci, zabezpečení a auditní záznamy.
AI model: matematický nebo statistický model, který provádí klasifikaci, predikci, detekci odchylek nebo doporučení.
OPC UA: Open Platform Communications nebo OPC Unified Architecture
AI vrstva: řešení sestavené ze standardních platforem, konektorů, pravidel a individuálně nakonfigurovaných nebo vyvinutých modelů.
Document AI: Technologie využívaná k extrakci využívá k extrakci informací z tištěných i digitálních dokumentů, jako jsou obrázky, texty, znaky
DMS: Document Management System
FQ: Request For Quotation
APQP: Advanced Product Quality Planning
PPAP: Production Part Approval Process
ERP: Enterprise Resource Planning
=======================================================================================================
Are you solving a similar problem? I will help you with the analysis…
40+ years of experience in the field
30+ years of experience… HT-PROGRES, Bodycote, Galvamet
cooperation… VŠB, Czechimplant, ECM Technologies, TAV Vacuum Furnaces, GHC Invest
12+ years of expert activity
Want to ask for a solution or want a non-binding consultation? Click on this link, I will usually respond within 24 hours. Contact email
========================================================================================================
Jiří Stanislav, Ing. CSc.
Consultant and forensic expert
========================================================================================================
31/7/2026