UDS podnikový informaní systém

UDS podnikový informa ní systém Zpráva o vývoji systému

Autor:

Ing. Jaroslav Halva

V Plzni 15.12.2009

reus s.r.o., schlott gruppe Ing. Jaroslav Halva


Obsah 1

Struktura dat – vyšší p izp sobení požadavk koncernu ............................................... 3

2

Integrace informací ........................................................................................................ 5 2.1

Dávková vým na 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ín nost proces ........................................................ 7

4

User - friendly p ístup ................................................................................................... 9

5

Poskytnutí relevantní informace v reálném ase............................................................ 9

6

Zkvalitn ní informací – formální správnost po ízených dat ........................................ 11

7

Vým na informací s okolím (CRM, SCM).................................................................. 11

8

Zlepšení výkaznictví – efektivní rozhodovací nástroje................................................ 12

9

Zkvalitn ní uživatelské a programové dokumentace. .................................................. 13

10

Záv r......................................................................................................................... 13

2



1 Struktura dat – vyšší p izp sobení požadavk koncernu Oproti p vodnímu systému i24 byla struktura UDS p izp sobena více (skoro bych ek maximáln ) požadavk m „dalšího zpracování“. Více než kdy p edtím docházelo ke komunikaci s jednotlivými odd leními formou mapy informa ních pot eba, která dala vznik páte ní struktu e databáze. Zm ny jsou patrné tak ka ve všech modulech systému, nejvíce však v modulu pro zpracování zakázky v etn jejích podružných struktur. Definice n kterých vlastností zakázky byla zredukována na d ležitá data (návoz tisku, zahájení a ukon ení práce atp.) P edevším tzv. koncernové ozna ení bylo z vlastností verze p esunuto do vlastností celé zakázky, což výrazn zjednodušuje zm nové ízení.

Obr. 1-1 Optimalizované vlastnosti zakázky

Další d ležitou zm nou 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 t eba ke zpracování všech verzí. Data je možné p eddefinovat ješt v dob , kdy není žádná znalost o koncepci jednotlivých verzí, což umož uje v asnou evidenci materiálového toku ze strany odd lení logistiky. Formáln jde o to, že manažer zakázky ješt p edtím, než dostane požadavek na definici verze, m že zadat strukturu díl pro evidenci návoz tohoto materiálu. Je z ejmé, ž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é p idruž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 p esné po adí a vý et složek, které pat í ke zpracování p íslušné veze. Tyto položky p itom vybírá z p edem definované tabulky p edlohy díl . Zm na v dílu (tabulka p edlohy díl ) se pak automaticky promítá do struktury bloku verze. Výrazná zm na postihla také definici tzv. výrobních proces , které souží ke specifikaci zakázky v množin možných technologických zpracování. P vodní 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ž op t umož uje pružn jší zpracování zakázky. Tabulka proces je op t vázána vždy ke konkrétní zakázce s kardinalitou 1:N, takže není systémem omezen po et definovaných proces pro zakázku.

Obr. 1-2 Definované výrobní procesy

P edevším pro p íjem materiálu je t eba, aby byla zakázka definována v as. P vodní 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 t eba definovat p íchozí materiál, nebyla znalost ohledn vlastností verze dostate ná. Docházelo tak ke zbyte ným dodate ným opravám ve struktu e, což výrazn protahovalo zpracování dat. Nyní, kdy je definice tvo ena ze zakázky (kde uživatel definuje skute n minimum atribut ) je p íjem možno provád t v as a bez dalších oprav vycházejících z chybné definice struktury bloku. Uživatel m že dokonce p edlohu 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 p edlohy. Je tedy možné definovat jednotlivé díly postupn tak, jak jsou importovány z dodavatelských spole ností.

4



Obr. 1-3 ást tabulky p edlohy díl

N které další moduly byly p epracovány kompletn . (Modul logistiky, výroby a fakturace…)

2 Integrace informací 2.1 Dávková vým na dat Stejn jako i24 také UDS disponuje nástrojem pro dávkovou vým nu dat se systémem SAP. P edevším kmenová data zakázek, která jsou zpracovávána ve velmi detailní struktu e v UDS jsou jednoduchým m stkem p evád na do SAP. Zde se jedná pouze o základní atributy zakázky, systém v tomto ohledu nepracuje s verzí. P esto dochází k d lení zakázky definované v UDS jediným záznamem na takový po et zakázek SAP, kolik je v UDS definováno výrobních proces . P estože není opodstatn no, 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ý po et zakázek v UDS. V praxi to znamená, že pokud uživatel definuje zakázku se t emi výrobními procesy, exportuje systém tuto strukturu jako t i zakázky do SAP, aby bylo možné monitorovat jednotlivé procesy zvláš . Vým na dat se mezi UDS a SAP týká následujících oblastí: •

Kmenová data zakázky

5



•

Kmenová data spot ebního (skladového) materiálu

•

Spot eby materiálu (transakce)

•

Statistika výkonu

•

Statistická ísla

Nov také slu ujeme systém UDS a AISYS pro sledování spot eby energie na jednotlivých strojích a p edáváme pom rn 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 t eba otev en podotknout) pouze áste n . Nepoda ilo 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 o ekávaných p ínos modul pro archivaci externích dokument , které je možno p idružit vždy ke konkrétní zakázce, neeliminuje však existenci t chto 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 spole n s materiálem a už z jakéhokoli d vodu), zakázková dokumentace, faktury atp. Dokonce ve srovnání s i24 disponuje UDS komplexn jší adou tiskových výstup , které vznikaly na základ analýzy informa ních pot eb a dále p i samotném vývoji. Využití výstup UDS bylo více p izp sobeno koncovým uživatel m a to i v p ípad pom rn složitých tiskových sestav exportovaných v tomto p ípad v tšinou do formátu XLS. (expedice hotových výrobk , p ehled vyrobeného množství, rozpracovanost zakázek, výpo et prémií…) Lze o ekávat, že vývoj p inese nové požadavky na systémové výstupy a postupn tak vymizí i n které další elektronické informace, které zatím kolují závodem nezat íd né v UDS. To ovšem nikterak neruší fakt, že i nadále bude existovat správa externích dokument formou jejich archivace – p idruž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 do ešení.

2.3 Integrace „volných znalostních“ informací Znalostní informace, které vyplývají p edevším ze zkušeností jednotlivých pracovník , se zatím do systému zapracovat nepoda ilo. Snad až na výjimky, které tvo í funkce pro výpo et výkonu stroje, která byla p evzata z i24 a také funkce pro výpo et po tu len osádky stroje, která je klí ová pro stanovení kapacit jednotlivých stroj . Ob funkce vycházejí z prvotní p edstavy optimalizovat nastavení funk ní závislosti jednak mezi n kterými parametry zakázky a výkonem stroje, jednak mezi stanovením po tu len osádky s p ihlédnutí na n který z parametr zakázky (zde po et zpracovávaných díl ). 6



Nastavení takové funkce zatím nebylo vy ešeno, p estože jen tato v systému zapracována.

3 Zavedení work-flow – vyšší podmín nost proces Už prvotní datová analýza po ítá se zvýšením podmín nosti n kterých výrobních proces . Systém byl p esto nastaven na nižší úrove podmín nosti n kterých vnitropodnikových proces , co se logistických proces obecn tý e, zde zaru uje podmín nost vlastní struktura dat a po adí záznam , které v ní vznikají. P edevším v oblasti správy zakázky je systém nastaven na nižší úrove omezení. Je t eba zajistit vyšší vzd lanost v oblasti užívání UDS, nebo práv oblast správy zakázky obsahuje také široký okruh povolení dalších transakcí související p edevší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 n která kmenová data, p edevším pak spole ností, které definuje pro rychlé zpracování nap íklad definice transport atp. Vlastní podmín nost proces zde ovšem existuje a ve srovnání s p vodním systémem i24 v mnohem propracovan jší podob , která výrazn zvyšuje dosažení konzistence dat. Nap íklad výb r zákazníka v zakázce je omezen atributem, který zákazníka ozna uje jako tzv. debitora (potenciálního p íjemce faktury) což „nahrává“ v kmenové vým n dat mezi UDS a SAP. Výrazn ji se work-flow projevuje v dalších fázích zpracování informací: • V logistice jsou transakce pohybu materiálu (zákaznického) podmín ny definicí p edlohy díl , kterou vytvá í manažer zakázky. V praxi tak pracovník skladu nem že p ijmout jiný než p eddefinovaný materiál a provád t s ním r zné operace (p íjem, vývoz, p eskladn ní atp.) • I pom rn složitý výrobní proces je monitorován a zaznamenáván formou denního výkazu, jehož založení je podmín no 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áb nou verzi, jejíž zakázka nemá definovaný proces shodný s definicí stroje, na kterém se záznam výkazu po izuje.

Obr. 3-1 Chyba p i nekonzistenci výrobního procesu v zadání výkazu produkce

• Vyrobené kusy p ipravené k expedici se ozna ují pro vývoz skenováním na p edem ur eném pracovišti. Pracovník expedice nem že provést vývoz palet, které nebyly na tomto pracovišti ozna eny k expedici. S paletovými lístky expedovaného množství již není možné manipulovat ve smyslu zm ny. Systém umož uje samoz ejm zm nu jejich stavu pro opakovanou manipulaci s nimi, nap íklad návrat zp t do výroby k ú elu p eskládání hotových výrobk na palet atp.

7



• Výdej zákaznického materiálu je nyní též realizován na ur eném pracovišti, p íjem p edem 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 op t umož uje transak n materiál zp t naskladnit a manipulaci opakovat. • Transakce skladového materiálu (lepidla, fólie a ostatní spot ební materiál) p ispívají k vyjád ení spot eb tohoto materiálu. Pouze množství, které sklad vydá do výroby je možné zpracovat ve prosp ch spot eby na ur itou zakázku. To zajiš uje svou funkcí datový terminál, který krom zápisu denního výkazu zaru uje kontinuální a opakovanou rutinu vedení tzv. inventární spot eby. Systém rozdílem aktuálního stavu a stavu systémového provádí generování transakcí spot eby a to vždy po skon ení sm ny, tedy celkem 3x denn . Tím se zvyšuje p esnost a minimalizuje se chyba v odhadu ode ítaného množství p i inventu e. Stav, který eviduje systém p itom podmi uje vy ízení materiálové žádanky ze strany mistra (návrh na p eskladn ní ) a skladníka (vy ízení požadavku), ímž se ur itý materiál naskladní na produk ní sklad, odkud je pak možné jej odepsat do spot eby. Tu provádí strojmistr pouhým ode tením skute ného stavu tohoto materiálu na svém sklad . • Správa ú etních doklad je zatím jedním z nejpropracovan jších modul co se ízení a podmín nosti jednotlivých proces tý e. Nap íklad faktura je nejprve vyhotovena jako schvalovací návrh, který v okamžiku jeho dokon ení bývá pat i n ozna en. 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át m (pracovníci odd lení ú tárny). Tím je zajišt no rychlé vy ízení faktury, která je po kontrole a schválení ozna ena jako vy ízená a tím je záznam uzam en. Pokud faktura obsahuje n které externí p ílohy ve form jiných soubor , mohou být tyto p idruženy k dokumentu a odeslány spole n 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 doru en prakticky okamžit .

Obr. 3-2 e-mail: Zpráva o vytvo ení p edlohy faktury v . p íloh

8



4 User - friendly p ístup Nebylo zatím provedeno detailní zkoumání formou pr zkumu spokojenosti koncových uživatel . Objektivn (m iteln ) 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 jednozna n nabízí lepší ovládací prvky, než které byly použity p i 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í pr zkumu. V porovnání s i24 však systém nabízí lepší nejen zobrazovací a zadávací možnosti, ale p edevším lepší stabilitu a hospoda ení s pam tí. Funk nost hlavní nabídky v etn nov vytvo ených panel nástroj je zatím 100%. Od doby prvotního spušt ní systému UDS neregistrujeme žádné reklamace z ady uživatel , které by poukazovaly na nefunk nost n kterého ze zobrazovacích prvk nebo dokonce programových funkcí jako takových. P esto, že se eší n která vylepšení a optimalizace, nejsou vesm s požadavky kone ných uživatel reklamací ani vzhledu ani funk nosti. N které ú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 p evážná v tš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 transak ní zpracování operací nad daty, uložení dat je provedeno ihned po ukon ení transakce metodou commit na server, odkud mohou data využívat další uživatelé. To samo o sob není p evratnou zm nou oproti p edchozí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. P estože toto zobrazení m že probíhat na n kterých klientských stanicích pomaleji, zkušenost ukazuje, že je toto zobrazení výrazn rychlejší než vykazovaly p edchozí zkušenosti s i24. P evážná v tšina datových výstup pro uživatele eší tzv. stavy. To znamená, že zobrazují n jakou skute nost ve stavu práv aktuálním. Pokud to jde, umož uje systém zobrazovat i stavy starší, tedy n jakým zp sobem asov omezené. Z takových výstup bychom mohli zmínit n kolik: • Aktuální stav skladu zákaznického materiálu • Aktuální stav skladu materiálu spot ební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á zm na, která je posléze uložena na serveru, se projevuje všem ostatním uživatel m. V n kterých fázích ízení dokonce výrazn ovliv uje další možnosti správy t chto dat (podmín né procesy). Objem dat, které UDS zpracovává, je pom rn veliký. Objem informací, které pomocí systému získáváme zatím nebyl zm en. Jak m žeme tedy posoudit, zda data uložená a spravovaná pomocí UDS mohou poskytovat ješt v tší okruh informací? Zatím každý požadavek na získání n jaké informace byl zpracován tém bez dalšího zásahu do 9



struktury databáze (až na n které výjimky, které byly spíše návrhem na dopracování n které á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 vesm s 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 et zcem: od vlastností zakázky a verze, p es logistické operace s materiálem až po složit jší 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 p icházejí požadavky ze strany koncového uživatele.) I zde je zatím pom rn rozsáhlá oblast vývoje: koncipovat další výstupy a poskytovat ješt v tší množství informací jednak nap í závodem (mezi odd leními), ale také s ohledem na okolí. Jednou dosud neuzav enou kapitolou vývoje je terminálové on-line sledování pr b hu výroby. Zatím se poda ilo 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 ur itém pracovišti, byly k dispozici v reálném ase. Zbývá ovšem ješt do ešit pružn jší evidenci vyráb ného nebo zpracovávaného množství pomocí série po ítacích za ízení, která by byla schopna pr b ž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žd ní (transport hotové palety do skladu) a navíc ne každá vyrobená paleta je ihned p evezena do skladu (v p ípad dalšího zpracování na jiném stroji).

Obr. 5-1 Aplikace UDS terminál

P esto lze ze systému okamžit ode ítat stav práce na pracovišti. Dojde-li ke zm n 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ý po et len osádky).

10



6 Zkvalitn ní informací – formální správnost po ízených dat Získávání dat je prov ováno jednak vlastní databází, která kontroluje formou n kterých integritních omezení formální správnost a zajiš uje tak jejich konzistenci, na n kterých místech je kontrola provád na 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ýpo tech a stanovení díl ích datum dokladu (vystavení, DUZP atp.). V p ípad fakturace je p ed uložením zm n za azena celá ada kontrol, které vylu ují 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ád ení dan pop ípad n kterých skont vychází jednak ze zvoleného p edm tu fakturace (definice op t vylu uje chyby) jednak také z platební podmínky, která definuje, jaké skonto m že zákazník uplatnit p i uhrazení do limitního po tu dní pro uplatn ní skonta. Hodnota je zobrazena na dokladu, ástka je p epo ítána pro definované skonto. I zde se poda ilo chyby tém úpln potla it. Ze strany odd lení ú tárny tedy nedochází k reklamaci p ipravených doklad z d vod datum nebo chybn vypo ítané ástky po uplatn ní 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í dodate n kontrolováno a v p ípad pot eby opraveno. Zde je systém z velké ásti odkázán na schopnosti uživatele a jeho pe livého p ístupu k zápisu. P edpokládá se zvýšení kvality t chto po ízených dat ješt dodate ným p eškolením pracovník , kte í s terminály pracují. Obecn ovšem platí: P ístup k dat m je omezen uživatelskými právy. Každý uživatel má vymezená práva na modifikaci nebo vkládání n kterých dat. Destruktivní operace mazání je povolena jen ve výjime ných p ípadech (nap íklad manažer m zakázky je umožn no 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 odstran ny všechny její položky. Zejména v definici zakázky je toto omezení jistou kontrolou nad necht ným smazáním zakázky. Pokud existuje jen jediný záznam nap íklad v definici p edlohy díl , zakázku již není možné smazat.

7 Vým na informací s okolím (CRM, SCM) Zatím se ve vývoji UDS nep istupovalo k ešení otázky CRM a SCM. Toto ešení je ovšem jedním z dalších cíl vývoje tohoto informa ního systému. Chceme zákazník m nabídnout službu, která by jim umožnila (a nejen jim, ale i ostatním stranám dodavatelsko odb ratelského et zce) sdílet naše data, respektive n které informace, které by pomohly ke zlepšení dynamiky externích logistických operací, ale p edevším k lepšímu asovému plánování jednotlivých dodávek. Moduly CRM a SCM by m ly p isp t k v tší orientaci na zákazníka, zm nit chápání zakázky a posunout hranici zam ení pozornosti ne na výrobu samotnou (což by m lo být chápáno jako samoz ejmost) ale p edevší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í n kterých informací, áste n z výroby, ale p edevším informací o stavu zakázky (sledování p edevším vyrobeného množství, expedovaného množství atp.), by se m l zam it 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) p istupovat p es webové rozhraní a to k informacím, které budou formou tabulkových sestav, výstup . Zmi ovaná technologie (API) je dob e 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 pom rným zm nám. P edevším se zjednodušil mechanismus zadávání denního výkazu a to p edevším hlavn ve struktu e as . P vodn používaný model, kdy se produk ní as zapisoval jako celkový a všechny pomocné a ztrátové asy jako jeho podmnožiny, byl nahrazen mnohem p ijateln jší variantou tzv. postupných as , která se používá obecn všech aplikacích m ení asu (nap íklad chronometráž). Postupné asy, jak název napovídá, se zapisují sekven n a to vždy v p ípad , kdy nastane n jaká zm na. Tu chápeme my jako zm nu pracovního režimu. Strojmistr, který p ijde na pracovišt a zapisuje sv j denní výkaz pomocí terminálu, nezadává žádné asové údaje. Pouze zaznamenává jednotlivé pracovní kódy, tak jak v pr b hu sm ny následují a systém jim sám p id luje 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á p estávku podle definice sm ny, na kterou se strojmistr p ihlásil. V p ípad zápisu denního výkazu na p edtišt ný formulá , zaznamenává strojmistr spole n s pracovními kódy také již zmi ované postupné asy. P estož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 zp sobovaly 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 p edevším zp es ují. Strojmistr má pak více asu v novat se obsluze stroje a koordinace inností osádky. Data, která jsou on-line zp ístupn na 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 p edevším na pracovní režim, který je strojmistrem zadáván formou pracovního kódu, na aktuální po et len osádky, vyráb né množství, dodržování p edepsaného nákladu atp.

12



Obr. 8-1 Monitorování produkce

Tato ást prochází stále vývojem a dopracováním. P esto lze íci: Data získáváme v as. Data m žeme vyhodnocovat v as. Díky absenci p episu 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 n kterých tabulkových výstup , které slouží p edevším pro vzájemné porovnání stavu produkce v koncernu. Výstupy jsou upraveny tak, aby je bylo možné provád t srovnání podle vybraných ukazatel ve všech dce iných spole nostech koncernu schlott gruppe. V tomto p ípad se jedná p edevším o statistiku tzv. AVG ísel, tedy souboru definovaných ukazatel pro srovnání ur ité míry produktivity práce v jednotlivých závodech. Není možné stav t UDS na úrove n který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 zp sobem vyhodnotit. Snaží se splnit pot eby a požadavky ze strany uživatel tak, aby mohli podávat pot ebné informace v as.

9 Zkvalitn ní uživatelské a programové dokumentace. Programová dokumentace zatím áste n 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 pom rn asto modifikován podle požadavk koncových uživatel . Tvorbu dokumentace o ekáváme v roce 2010.

10 Záv r Tato zpráva obsahov kopíruje kapitoly projektu vývoje informa ního systému a ukazuje výsledky v prvním období jeho realizace. Rozhodn musím p ipomenout, že vývoj UDS není

13



možné chápat jako ukon ený. V zásad jsem cht l poukázat na skute nost, že základní prvky systému fungují a byly úsp šn zavedeny do praxe. V roce 2010 je t eba zam it systém na optimalizaci v oblasti monitorování produkce a poskytnout i n které další informace v ase, kdy ješt m žeme operativn hodnotit a p istupovat ke zm nám v produkci. Stejn tak je t eba posunout aplikaci sm rem k zákazník m dodavatelsko odb ratelského et zce. V neposlední ad je t eba systém detailn popsat.

14

dalším subjekt m

UDS podnikový informaní systém

Recommend Documents