Autor: V Plzni 15.12.2009
Obsah 1 Struktura dat vyšší pizpsobení požadavk koncernu... 3 2 Integrace informací... 5 2.1 Dávková výmna dat... 5 2.2 Integrace volných e informací... 6 2.3 Integrace volných znalostních informací... 6 3 Zavedení work-flow vyšší podmínnost proces... 7 4 User - friendly pístup... 9 5 Poskytnutí relevantní informace v reálném ase... 9 6 Zkvalitnní informací formální správnost poízených dat... 11 7 Výmna informací s okolím (CRM, SCM)... 11 8 Zlepšení výkaznictví efektivní rozhodovací nástroje... 12 9 Zkvalitnní uživatelské a programové dokumentace... 13 10 Závr... 13 2
1 Struktura dat vyšší pizpsobení požadavk koncernu Oproti pvodnímu systému i24 byla struktura UDS pizpsobena více (skoro bych ek maximáln) požadavkm dalšího zpracování. Více než kdy pedtím docházelo ke komunikaci s jednotlivými oddleními formou mapy informaních poteba, která dala vznik pátení struktue databáze. Zmny jsou patrné takka ve všech modulech systému, nejvíce však v modulu pro zpracování zakázky vetn jejích podružných struktur. Definice nkterých vlastností zakázky byla zredukována na dležitá data (návoz tisku, zahájení a ukonení práce atp.) Pedevším tzv. koncernové oznaení bylo z vlastností verze pesunuto do vlastností celé zakázky, což výrazn zjednodušuje zmnové ízení. Obr. 1-1 Optimalizované vlastnosti zakázky Další dležitou zmnou oproti i24 je definice struktury jednotlivých díl, která je koncipována nyní do dvou na sob závislých struktur. V prvé ad je to definice kompletní sady díl, které bude teba ke zpracování všech verzí. Data je možné peddefinovat ješt v dob, kdy není žádná znalost o koncepci jednotlivých verzí, což umožuje vasnou evidenci materiálového toku ze strany oddlení logistiky. Formáln jde o to, že manažer zakázky ješt pedtím, než dostane požadavek na definici verze, mže zadat strukturu díl pro evidenci návoz tohoto materiálu. Je zejmé, že byla struktura jednotlivých díl koncipována jako vázaná tabulka k záznamu celé zakázky s kardinalitou 1:N, což znamená, že k zakázce je možné pidružit celkem N záznam jednotlivých díl. 3
Teprve v okamžiku definice jednotlivých verzí dochází k založení struktury bloku pro konkrétní z nich. Manažer tak definuje tzv. snášecí mustr, tedy pesné poadí a výet složek, které patí ke zpracování píslušné veze. Tyto položky pitom vybírá z pedem definované tabulky pedlohy díl. Zmna v dílu (tabulka pedlohy díl) se pak automaticky promítá do struktury bloku verze. Výrazná zmna postihla také definici tzv. výrobních proces, které souží ke specifikaci zakázky v množin možných technologických zpracování. Pvodní koncepce definovat tuto strukturu pro každou verzi zvláš byla chybná. UDS adí tuto definici k celé zakázce. Je tedy možné definovat procesy ješt bez detailní znalosti vlastností dílích verzí, což opt umožuje pružnjší zpracování zakázky. Tabulka proces je opt vázána vždy ke konkrétní zakázce s kardinalitou 1:N, takže není systémem omezen poet definovaných proces pro zakázku. Obr. 1-2 Definované výrobní procesy Pedevším pro píjem materiálu je teba, aby byla zakázka definována vas. Pvodní koncepce, která vycházela s definice zákaznického materiálu v jednotlivých verzích toto znemožovala, protože v okamžiku, kdy bylo teba definovat píchozí materiál, nebyla znalost ohledn vlastností verze dostatená. Docházelo tak ke zbyteným dodateným opravám ve struktue, což výrazn protahovalo zpracování dat. Nyní, kdy je definice tvoena ze zakázky (kde uživatel definuje skuten minimum atribut) je píjem možno provádt vas a bez dalších oprav vycházejících z chybné definice struktury bloku. Uživatel mže dokonce pedlohu jednotlivých díl, která je výchozí tabulkou pro zpracování materiálových transakcí, definovat postupn. Systém uživatele nikterak nesvazuje nutností kompletní definice pedlohy. Je tedy možné definovat jednotlivé díly postupn tak, jak jsou importovány z dodavatelských spoleností. 4
Obr. 1-3 ást tabulky pedlohy díl Nkteré další moduly byly pepracovány kompletn. (Modul logistiky, výroby a fakturace ) 2 Integrace informací 2.1 Dávková výmna dat Stejn jako i24 také UDS disponuje nástrojem pro dávkovou výmnu dat se systémem SAP. Pedevším kmenová data zakázek, která jsou zpracovávána ve velmi detailní struktue v UDS jsou jednoduchým mstkem pevádna do SAP. Zde se jedná pouze o základní atributy zakázky, systém v tomto ohledu nepracuje s verzí. Pesto dochází k dlení zakázky definované v UDS jediným záznamem na takový poet zakázek SAP, kolik je v UDS definováno výrobních proces. Pestože není opodstatnno, pro v SAP musí vznikat taková struktura, systém UDS množí záznamy pro SAP podle definovaných proces proto, aby nebylo nutné definovat stejný poet zakázek v UDS. V praxi to znamená, že pokud uživatel definuje zakázku se temi výrobními procesy, exportuje systém tuto strukturu jako ti zakázky do SAP, aby bylo možné monitorovat jednotlivé procesy zvláš. Výmna dat se mezi UDS a SAP týká následujících oblastí: Kmenová data zakázky 5
Kmenová data spotebního (skladového) materiálu Spoteby materiálu (transakce) Statistika výkonu Statistická ísla Nov také sluujeme systém UDS a AISYS pro sledování spoteby energie na jednotlivých strojích a pedáváme pomrn detailní a rozsáhlý soubor vstupních dat pro statistiky v podob informací získaných z terminál zadávání denních výkaz. 2.2 Integrace volných e informací Systém UDS eší tuto ást projektu (a to je teba oteven podotknout) pouze ásten. Nepodailo se ani díky rozsáhlé analýze dat podchytit všechny pípady, kdy takové informace vznikají. Systém, UDS obsahuje pro tuto ást požadovaných a oekávaných pínos modul pro archivaci externích dokument, které je možno pidružit vždy ke konkrétní zakázce, neeliminuje však existenci tchto dokument úpln. Minimáln však vytváí strukturu pro snazší a lepší manipulaci s takovými dokumenty, které patrn i nadále vznikat budou. Existuje ovšem snaha udržovat tyto informace pouze ze strany zadavatele zakázky a tyto archivovat, ostatní dokumenty však generovat systémem UDS. Obr. 2-1 ást tabulky externích dokument zakázky Nestává se tedy, že by vznikaly dokumenty jako dodací listy (pokud nejsou dodávány spolen s materiálem a už z jakéhokoli dvodu), zakázková dokumentace, faktury atp. Dokonce ve srovnání s i24 disponuje UDS komplexnjší adou tiskových výstup, které vznikaly na základ analýzy informaních poteb a dále pi samotném vývoji. Využití výstup UDS bylo více pizpsobeno koncovým uživatelm a to i v pípad pomrn složitých tiskových sestav exportovaných v tomto pípad vtšinou do formátu XLS. (expedice hotových výrobk, pehled vyrobeného množství, rozpracovanost zakázek, výpoet prémií ) Lze oekávat, že vývoj pinese nové požadavky na systémové výstupy a postupn tak vymizí i nkteré další elektronické informace, které zatím kolují závodem nezatídné v UDS. To ovšem nikterak neruší fakt, že i nadále bude existovat správa externích dokument formou jejich archivace pidružením ke konkrétním zakázkám. Tato oblast vývoje si po prvotní bilanci vývoje celého systému stále zasluhuje pozornost a nabízí prostor k doešení. 2.3 Integrace volných znalostních informací Znalostní informace, které vyplývají pedevším ze zkušeností jednotlivých pracovník, se zatím do systému zapracovat nepodailo. Snad až na výjimky, které tvoí funkce pro výpoet výkonu stroje, která byla pevzata z i24 a také funkce pro výpoet potu len osádky stroje, která je klíová pro stanovení kapacit jednotlivých stroj. Ob funkce vycházejí z prvotní pedstavy optimalizovat nastavení funkní závislosti jednak mezi nkterými parametry zakázky a výkonem stroje, jednak mezi stanovením potu len osádky s pihlédnutí na nkterý z parametr zakázky (zde poet zpracovávaných díl). 6
Nastavení takové funkce zatím nebylo vyešeno, pestože jen tato v systému zapracována. 3 Zavedení work-flow vyšší podmínnost proces Už prvotní datová analýza poítá se zvýšením podmínnosti nkterých výrobních proces. Systém byl pesto nastaven na nižší úrove podmínnosti nkterých vnitropodnikových proces, co se logistických proces obecn týe, zde zaruuje podmínnost vlastní struktura dat a poadí záznam, které v ní vznikají. Pedevším v oblasti správy zakázky je systém nastaven na nižší úrove omezení. Je teba zajistit vyšší vzdlanost v oblasti užívání UDS, nebo práv oblast správy zakázky obsahuje také široký okruh povolení dalších transakcí související pedevším se správou i kmenových dat. Toto nastavení bylo koncipováno na základ uvážení vedoucích pracovník, kteí intervenovali za širší oblast povolených transakcí a úkon. Ve své podstat tak manažer zakázky spravuje i nkterá kmenová data, pedevším pak spoleností, které definuje pro rychlé zpracování napíklad definice transport atp. Vlastní podmínnost proces zde ovšem existuje a ve srovnání s pvodním systémem i24 v mnohem propracovanjší podob, která výrazn zvyšuje dosažení konzistence dat. Napíklad výbr zákazníka v zakázce je omezen atributem, který zákazníka oznauje jako tzv. debitora (potenciálního píjemce faktury) což nahrává v kmenové výmn dat mezi UDS a SAP. Výraznji se work-flow projevuje v dalších fázích zpracování informací: V logistice jsou transakce pohybu materiálu (zákaznického) podmínny definicí pedlohy díl, kterou vytváí manažer zakázky. V praxi tak pracovník skladu nemže pijmout jiný než peddefinovaný materiál a provádt s ním rzné operace (píjem, vývoz, peskladnní atp.) I pomrn složitý výrobní proces je monitorován a zaznamenáván formou denního výkazu, jehož založení je podmínno správnou definicí výrobního procesu v zakázce, který definuje manažer zakázky. V praxi tak není možné zapisovat denní výkaz na vyrábnou verzi, jejíž zakázka nemá definovaný proces shodný s definicí stroje, na kterém se záznam výkazu poizuje. Obr. 3-1 Chyba pi nekonzistenci výrobního procesu v zadání výkazu produkce Vyrobené kusy pipravené k expedici se oznaují pro vývoz skenováním na pedem ureném pracovišti. Pracovník expedice nemže provést vývoz palet, které nebyly na tomto pracovišti oznaeny k expedici. S paletovými lístky expedovaného množství již není možné manipulovat ve smyslu zmny. Systém umožuje samozejm zmnu jejich stavu pro opakovanou manipulaci s nimi, napíklad návrat zpt do výroby k úelu peskládání hotových výrobk na palet atp. 7
Výdej zákaznického materiálu je nyní též realizován na ureném pracovišti, píjem pedem definovaných složek je doprovázen operací založení paletových lístk, které jsou skenovány a tím vydávány do výroby. S takovým materiálem není možné dále ve skladu manipulovat, systém však opt umožuje transakn materiál zpt naskladnit a manipulaci opakovat. Transakce skladového materiálu (lepidla, fólie a ostatní spotební materiál) pispívají k vyjádení spoteb tohoto materiálu. Pouze množství, které sklad vydá do výroby je možné zpracovat ve prospch spoteby na uritou zakázku. To zajišuje svou funkcí datový terminál, který krom zápisu denního výkazu zaruuje kontinuální a opakovanou rutinu vedení tzv. inventární spoteby. Systém rozdílem aktuálního stavu a stavu systémového provádí generování transakcí spoteby a to vždy po skonení smny, tedy celkem 3x denn. Tím se zvyšuje pesnost a minimalizuje se chyba v odhadu odeítaného množství pi inventue. Stav, který eviduje systém pitom podmiuje vyízení materiálové žádanky ze strany mistra (návrh na peskladnní ) a skladníka (vyízení požadavku), ímž se uritý materiál naskladní na produkní sklad, odkud je pak možné jej odepsat do spoteby. Tu provádí strojmistr pouhým odetením skuteného stavu tohoto materiálu na svém sklad. Správa úetních doklad je zatím jedním z nejpropracovanjších modul co se ízení a podmínnosti jednotlivých proces týe. Napíklad faktura je nejprve vyhotovena jako schvalovací návrh, který v okamžiku jeho dokonení bývá patin oznaen. Získáním stavu jako kompletní (stále ve smyslu návrhu) odesílá systém o založení nového návrhu e-mail definovaným adresátm (pracovníci oddlení útárny). Tím je zajištno rychlé vyízení faktury, která je po kontrole a schválení oznaena jako vyízená a tím je záznam uzamen. Pokud faktura obsahuje nkteré externí pílohy ve form jiných soubor, mohou být tyto pidruženy k dokumentu a odeslány spolen se zprávou jako pílohy e-mailem. Pracovník útárny tím získává kompletní balíek informací jednak ke kontrole, jednak k vyízení. Tisková podoba faktury je možná také ve formátu PDF, který mže být adresátovi odesílán elektronicky a doruen prakticky okamžit. Obr. 3-2 e-mail: Zpráva o vytvoení pedlohy faktury v. píloh 8
4 User - friendly pístup Nebylo zatím provedeno detailní zkoumání formou przkumu spokojenosti koncových uživatel. Objektivn (miteln) tedy nelze posoudit, zda jsou uživatelé více i mén spokojeni s výsledkem vývoje UDS. Vlastní koncepce pomocí Delphi ovšem jednoznan nabízí lepší ovládací prvky, než které byly použity pi vývoji i24. Za vše mluví jist editovatelné zobrazení tabulka pomocí komponenty TDBGrid. Posoudit vzhled a uživatelskou dostupnost koncepce by bylo možné až po provedení przkumu. V porovnání s i24 však systém nabízí lepší nejen zobrazovací a zadávací možnosti, ale pedevším lepší stabilitu a hospodaení s pamtí. Funknost hlavní nabídky vetn nov vytvoených panel nástroj je zatím 100%. Od doby prvotního spuštní systému UDS neregistrujeme žádné reklamace z ady uživatel, které by poukazovaly na nefunknost nkterého ze zobrazovacích prvk nebo dokonce programových funkcí jako takových. Pesto, že se eší nkterá vylepšení a optimalizace, nejsou vesms požadavky konených uživatel reklamací ani vzhledu ani funknosti. Nkteré úpravy jsou zpracovávány prost proto, že jsou podloženy dobrou argumentací o dalším zvýšení uživatelského komfortu. V poslední ad je pevážná vtšina uživatelských požadavk orientována spíše na stavbu nových datových (tiskových) výstup. 5 Poskytnutí relevantní informace v reálném ase Samotná koncepce klient-server umožuje sdílení dat v reálném ase. Databáze umožuje transakní zpracování operací nad daty, uložení dat je provedeno ihned po ukonení transakce metodou commit na server, odkud mohou data využívat další uživatelé. To samo o sob není pevratnou zmnou oproti pedchozímu systému i24. Data jsou ovšem distribuována na klientské stanice, kde jsou aplikací zobrazena, takže tato ást práce serveru odpadá a ten tím pádem není tolik zatžován. Pestože toto zobrazení mže probíhat na nkterých klientských stanicích pomaleji, zkušenost ukazuje, že je toto zobrazení výrazn rychlejší než vykazovaly pedchozí zkušenosti s i24. Pevážná vtšina datových výstup pro uživatele eší tzv. stavy. To znamená, že zobrazují njakou skutenost ve stavu práv aktuálním. Pokud to jde, umožuje systém zobrazovat i stavy starší, tedy njakým zpsobem asov omezené. Z takových výstup bychom mohli zmínit nkolik: Aktuální stav skladu zákaznického materiálu Aktuální stav skladu materiálu spotebního Aktuální stav skladu hotových výrobk Aktuální stav expedovaného množství atp. O všech výstupech platí, že zobrazují aktuální stav reality. Každá zmna, která je posléze uložena na serveru, se projevuje všem ostatním uživatelm. V nkterých fázích ízení dokonce výrazn ovlivuje další možnosti správy tchto dat (podmínné procesy). Objem dat, které UDS zpracovává, je pomrn veliký. Objem informací, které pomocí systému získáváme zatím nebyl zmen. Jak mžeme tedy posoudit, zda data uložená a spravovaná pomocí UDS mohou poskytovat ješt vtší okruh informací? Zatím každý požadavek na získání njaké informace byl zpracován tém bez dalšího zásahu do 9
struktury databáze (až na nkteré výjimky, které byly spíše návrhem na dopracování nkteré ásti z definovaných modul). Ukazuje se, že model datové struktury byl navržen správn. Požadavky na nové informace a dotazy na to, jak je získat jsou vesms zpracovány jako tiskový výstup, tedy s využitím SQL dotazovacího jazyka, který pln využije stávající strukturu k získání požadované informace. UDS umí poskytnout informace napí celým logistickým etzcem: od vlastností zakázky a verze, pes logistické operace s materiálem až po složitjší výstupy hodnotící výrobu a pracovníky. (Množina výstup, tedy zpracovaných dat do podoby informací, je neúplná a vyvíjí se tak, jak picházejí požadavky ze strany koncového uživatele.) I zde je zatím pomrn rozsáhlá oblast vývoje: koncipovat další výstupy a poskytovat ješt vtší množství informací jednak napí závodem (mezi oddleními), ale také s ohledem na okolí. Jednou dosud neuzavenou kapitolou vývoje je terminálové on-line sledování prbhu výroby. Zatím se podailo koncipovat terminálové zadávání denních výkaz tak, aby informace z výroby ohledn práv probíhajícím procesu na uritém pracovišti, byly k dispozici v reálném ase. Zbývá ovšem ješt doešit pružnjší evidenci vyrábného nebo zpracovávaného množství pomocí série poítacích zaízení, která by byla schopna prbžn ukládat hodnoty do databáze. Stávající koncepce umožuje sice sledovat vyrobené množství ale pouze na stran skladu, kde jsou hotové výrobky skenovány (nebo až zápisem strojmistra) a aktualizován tak stav vyrobeného množství. Tady ovšem dochází ke zpoždní (transport hotové palety do skladu) a navíc ne každá vyrobená paleta je ihned pevezena do skladu (v pípad dalšího zpracování na jiném stroji). Obr. 5-1 Aplikace UDS terminál Pesto lze ze systému okamžit odeítat stav práce na pracovišti. Dojde-li ke zmn pracovního režimu, je tato ihned ukládána pomocí terminálu do databáze a mže být zobrazena uživateli. Již nyní tak lze sledovat v jakém režimu stroj pracuje a s jakým objemem lidské práce (evidovaný jmenovitý poet len osádky). 10
6 Zkvalitnní informací formální správnost poízených dat Získávání dat je provováno jednak vlastní databází, která kontroluje formou nkterých integritních omezení formální správnost a zajišuje tak jejich konzistenci, na nkterých místech je kontrola provádna na stran uživatele. Za zmíku stojí jist kontrola vystavovaných dokument fakturace, která je z velké ásti automatizována, takže nedochází k chybám ve výpotech a stanovení dílích datum dokladu (vystavení, DUZP atp.). V pípad fakturace je ped uložením zmn zaazena celá ada kontrol, které vyluují hrubé chyby v zadávání. Není možné napíklad definovat fakturu s nepovoleným rozsahem data vystavení dokladu a DUZP. Datum splatnosti se poítá automaticky podle zvolené platební podmínky. Vyjádení dan popípad nkterých skont vychází jednak ze zvoleného pedmtu fakturace (definice opt vyluuje chyby) jednak také z platební podmínky, která definuje, jaké skonto mže zákazník uplatnit pi uhrazení do limitního potu dní pro uplatnní skonta. Hodnota je zobrazena na dokladu, ástka je pepoítána pro definované skonto. I zde se podailo chyby tém úpln potlait. Ze strany oddlení útárny tedy nedochází k reklamaci pipravených doklad z dvod datum nebo chybn vypoítané ástky po uplatnní skonta. Stejn jako v modulu fakturace, i v dalších místech ízení podnikových proces pomocí UDS je nastavena kontrola správnosti dat. Protože napíklad denní výkazy vznikají na pracovišti, je jejich zadání dodaten kontrolováno a v pípad poteby opraveno. Zde je systém z velké ásti odkázán na schopnosti uživatele a jeho pelivého pístupu k zápisu. Pedpokládá se zvýšení kvality tchto poízených dat ješt dodateným peškolením pracovník, kteí s terminály pracují. Obecn ovšem platí: Pístup k datm je omezen uživatelskými právy. Každý uživatel má vymezená práva na modifikaci nebo vkládání nkterých dat. Destruktivní operace mazání je povolena jen ve výjimených pípadech (napíklad manažerm zakázky je umožnno mazat položky struktury díl vlivem jejich asté úpravy). Navíc integritní omezení databáze znemožuje mazání záznam, které jsou cizím klíem k jiným tabulkám. To znamená, že pokud napíklad faktura (její návrh) obsahuje již položky, není možné ji smazat ani ze strany administrátora, pokud nejsou nejprve odstranny všechny její položky. Zejména v definici zakázky je toto omezení jistou kontrolou nad nechtným smazáním zakázky. Pokud existuje jen jediný záznam napíklad v definici pedlohy díl, zakázku již není možné smazat. 7 Výmna informací s okolím (CRM, SCM) Zatím se ve vývoji UDS nepistupovalo k ešení otázky CRM a SCM. Toto ešení je ovšem jedním z dalších cíl vývoje tohoto informaního systému. Chceme zákazníkm nabídnout službu, která by jim umožnila (a nejen jim, ale i ostatním stranám dodavatelsko odbratelského etzce) sdílet naše data, respektive nkteré informace, které by pomohly ke zlepšení dynamiky externích logistických operací, ale pedevším k lepšímu asovému plánování jednotlivých dodávek. Moduly CRM a SCM by mly pispt k vtší orientaci na zákazníka, zmnit chápání zakázky a posunout hranici zamení pozornosti ne na výrobu samotnou (což by mlo být chápáno jako samozejmost) ale pedevším na dobrý odhad požadavk zákazníka ješt než je vysloví, na poskytnutí informace, než se na ni zákazník zeptá. 11
Vývoj modul, které by umožnily sdílení nkterých informací, ásten z výroby, ale pedevším informací o stavu zakázky (sledování pedevším vyrobeného množství, expedovaného množství atp.), by se ml zamit na možnosti zobrazení pomocí dynamických webových stránek. V našem pípad se nabízí spojení API (Apache PHP - Interbase). K databázi bude uživatel (zákazník) pistupovat pes webové rozhraní a to k informacím, které budou formou tabulkových sestav, výstup. Zmiovaná technologie (API) je dobe popsána a také byla již testována. 8 Zlepšení výkaznictví efektivní rozhodovací nástroje Ve srovnání s i24 došlo v pípad definice denního výkazu k pomrným zmnám. Pedevším se zjednodušil mechanismus zadávání denního výkazu a to pedevším hlavn ve struktue as. Pvodn používaný model, kdy se produkní as zapisoval jako celkový a všechny pomocné a ztrátové asy jako jeho podmnožiny, byl nahrazen mnohem pijatelnjší variantou tzv. postupných as, která se používá obecn všech aplikacích mení asu (napíklad chronometráž). Postupné asy, jak název napovídá, se zapisují sekvenn a to vždy v pípad, kdy nastane njaká zmna. Tu chápeme my jako zmnu pracovního režimu. Strojmistr, který pijde na pracovišt a zapisuje svj denní výkaz pomocí terminálu, nezadává žádné asové údaje. Pouze zaznamenává jednotlivé pracovní kódy, tak jak v prbhu smny následují a systém jim sám pidluje tzv. asovou známku. Databáze tedy ukládá as v reálném sledu. Na základ dvou takových po sob jdoucích záznam se poítá tzv. as jednotlivý, který je udáván v hodinách. Rozdílem dvou po sob jdoucích as postupných získáme as jednotlivý (08:00 12:00 4 hod.) navíc systém z tohoto asu automaticky odeítá pestávku podle definice smny, na kterou se strojmistr pihlásil. V pípad zápisu denního výkazu na pedtištný formulá, zaznamenává strojmistr spolen s pracovními kódy také již zmiované postupné asy. Pestože koncepce chápání as a zápisu denního výkazu byla po formální stránce zjednodušena, staré zvyky z minulých systém zpsobovaly zpoátku potíže s novou formou zápisu. Dnes již mžeme íci, že tento problém nenastává. Výrazným pínosem byly datové terminály, které zápis denního výkazu nejen zrychlují, ale pedevším zpesují. Strojmistr má pak více asu vnovat se obsluze stroje a koordinace inností osádky. Data, která jsou on-line zpístupnna uživateli tvoí dobrou základnu pro rychlé rozhodování. V oblasti sledování produkce disponuje UDS nástrojem pro její pímé monitorování. Jedná se o pravidelnou, v krátkých intervalech se opakující získávanou informaci o základních parametrech probíhající výroby. Systém se dotazuje pedevším na pracovní režim, který je strojmistrem zadáván formou pracovního kódu, na aktuální poet len osádky, vyrábné množství, dodržování pedepsaného nákladu atp. 12
Obr. 8-1 Monitorování produkce Tato ást prochází stále vývojem a dopracováním. Pesto lze íci: Data získáváme vas. Data mžeme vyhodnocovat vas. Díky absenci pepisu denních výkaz, který možnost rozhodování o stavu produkce prodlužoval o dalších 24 hodin, mžeme data vyhodnocovat prakticky okamžit. Po formální kontrole správnosti lze také využívat soubor nkterých tabulkových výstup, které slouží pedevším pro vzájemné porovnání stavu produkce v koncernu. Výstupy jsou upraveny tak, aby je bylo možné provádt srovnání podle vybraných ukazatel ve všech dceiných spolenostech koncernu schlott gruppe. V tomto pípad se jedná pedevším o statistiku tzv. AVG ísel, tedy souboru definovaných ukazatel pro srovnání urité míry produktivity práce v jednotlivých závodech. Není možné stavt UDS na úrove nkterých profesionálních rozhodovacích systém typu Business-Intelligence. V tomto ohledu patrn nemá UDS ani dostupná data, ani schopnost je takovým zpsobem vyhodnotit. Snaží se splnit poteby a požadavky ze strany uživatel tak, aby mohli podávat potebné informace vas. 9 Zkvalitnní uživatelské a programové dokumentace. Programová dokumentace zatím ásten chybí. K dispozici je pouze databázový model a jeho fyzický popis. Zatím se upustilo i od tvorby uživatelské dokumentace, protože byl systém UDS stále pomrn asto modifikován podle požadavk koncových uživatel. Tvorbu dokumentace oekáváme v roce 2010. 10 Závr Tato zpráva obsahov kopíruje kapitoly projektu vývoje informaního systému a ukazuje výsledky v prvním období jeho realizace. Rozhodn musím pipomenout, že vývoj UDS není 13
možné chápat jako ukonený. V zásad jsem chtl poukázat na skutenost, že základní prvky systému fungují a byly úspšn zavedeny do praxe. V roce 2010 je teba zamit systém na optimalizaci v oblasti monitorování produkce a poskytnout i nkteré další informace v ase, kdy ješt mžeme operativn hodnotit a pistupovat ke zmnám v produkci. Stejn tak je teba posunout aplikaci smrem k zákazníkm dodavatelsko odbratelského etzce. V neposlední ad je teba systém detailn popsat. dalším subjektm 14