Mendelova univerzita v Brně Provozně ekonomická fakulta
Návrh a implementace webové aplikace pro podporu logistických procesů ve firmě FEI Bakalářská práce
Vedoucí práce: doc. Ing. Ivana Rábová
Marek Jakubec
Brno 2011
Rád bych poděkoval doc. Ing. Ivaně Rábové, Ph.D. za její konstruktivní připomínky a vedení práce. Mé rodině pak za velkou podporu nejenom při zpracovávání této práce, ale i během celého studia.
Prohlašuji, že jsem tuto práci vypracoval samostatně s použitím literatury uvedené v seznamu. V Brně dne 6. ledna 2012
_________________
Abstract Jakubec, M. Design and implementation of web application supporting logistic processes in the FEI company. Bachelor thesis. Brno, 2011. This thesis deals with the design and implementation of web application which provides support for further decisions and planning in logistic department to user or consumer. It’s based on an analysis of existing Data-flows in the company. It describes the used tools and implementation techniques. The practical part is a PHP application built on Oracle database. Keywords PHP, Oracle, Analysis, Database, Data flow.
Abstrakt Jakubec, M. Návrh a implementace webové aplikace pro podporu logistických procesů ve firmě FEI. Bakalářská práce. Brno, 2011. Bakalářská práce se zabývá návrhem a implementací webové aplikace pro podporu rozhodování a plánování logistického oddělení. Vychází z analýzy stávajících datových toků ve firmě. Popisuje použité implementační techniky a nástroje. Hodnotí přínos aplikace. Praktickou částí je PHP aplikace postavená na databázi Oracle. Klíčová slova PHP, Oracle, Analýza, Databáze, Datový tok.
Obsah
5
Obsah 1
Úvod a cíl práce
7
1.1
Úvod ...........................................................................................................7
1.2
Cíl práce .....................................................................................................7
2. Informační systémy
8
2.1 Pojem informace a data ................................................................................ 8 2.2 Podnikový informační systém...................................................................... 8 2.3 Životní cyklus IS ........................................................................................... 8 3. Charakteristika ERP
9
4. Charakteristika CRM
10
5. Strukturovaná analýza
11
5.1 Definice ........................................................................................................ 11 5.2 Strukturovaný přístup ................................................................................. 11 a) Funkční model .......................................................................................... 11 b) Model vnějšího chování systému .............................................................13 c) Datový model (Chen) ................................................................................13 d) Model řízení ..............................................................................................13 6. PHP
14
6.1 Popis.............................................................................................................14 6.2 Historie........................................................................................................14 7. SQL
15
7.1 Popis.............................................................................................................15 7.2 Historie ........................................................................................................15 8. Oracle
16
8.1 Definice ........................................................................................................16 8.2 Popis ............................................................................................................16 8.2.1 Databáze................................................................................................16
Obsah
6
8.2.2 Instance ................................................................................................16 8.3 Typy Oracle databází................................................................................... 17 8.4 Historie vývoje Oracle databáze ................................................................. 17 9. Vlastní práce
19
9.1 Charakteristika firmy...................................................................................19 9.1.1 Popis ......................................................................................................19 9.1.2 Historie ................................................................................................ 20 9.2 Současný stav ..............................................................................................21 9.3 Analýza datových toků ............................................................................... 23 9.3.1 Kontextový diagram............................................................................. 23 9.3.2 Systémový diagram ............................................................................. 25 9.3.3 Dekompozice procesu Sklad................................................................ 29 9.3.4 Dekompozice procesu Výroba..............................................................31 9.3.5 Dekompozice procesu Logistické oddělení ......................................... 33 9.4 Návrh .......................................................................................................... 35 9.4.1 Hlavní zaměření aplikace .................................................................... 35 9.4.2 Inovace 1 - Průběh prací (progress) .................................................... 35 9.4.3 Inovace 2 - Plánování s každým vložením nové objednávky.............. 36 9.4.3 Návrh databáze.....................................................................................37 9.5 Implementace............................................................................................. 38 9.6 Zhodnocení..................................................................................................41 10. Závěr
42
11. Literatura
43
Přílohy
44
A
Ukázka alokace materiálu
45
B
Ukázka výpisu a zadávání objednávek
46
C
Výpis pracovních příkazů (Work Orders) a jejich obsahu
47
D
Zkrácený výpis právě vyráběných produktů
48
E
Výpis a editace pracovního postupu (Flow)
49
Úvod a cíl práce
7
1 Úvod a cíl práce 1.1
Úvod
Jen těžko si v dnešní době dokážeme představit fungování firmy bez schopnosti automatizování každodenních úkonů pomocí informačních technologií. Je zapotřebí zpracovávat rychle a bezchybně velké množství informací a využít je jak k interní firemní komunikaci tak pro zajištění komunikace s vnějšími subjekty. Na poli konkurence je to právě efektivnost informačního systému, která se dnes již nemalou částí podílí na chodu celé firmy a definuje její konkurenceschopnost. Žijeme ve světě kde je nejen trendem ale již skoro povinností, aby firma nějaký ten systém do svého běhu přece jen integrovala. Vývojem a správou těchto systémů se zabývá množství společností nabízející různé spektrum řešení právě pro vaši danou problematiku. Hlavním aspektem však zůstává správná a hlavně srozumitelná forma implementace pro koncového uživatele. Integrováním informačních systému a přidáváním dalších a dalších aplikací způsobíme nejen případnou ztrátu efektivity z důvodu nemožnosti přenosu dat mezi informačními systémy či aplikacemi navzájem, ale také to může vést k roztříštěnosti informačního systému.
1.2 Cíl práce Cílem práce je návrh a implementace webové aplikace, která zlepší komunikaci mezi danými odděleními a povede tak ke zvýšení informovanosti a podpory logistického oddělení. Analyzován bude stávající stav a pomocí nástroje Power Designer budou namodelovány reálné informační toky ve firmě, zabývající se výrobou elektronových mikroskopů. Na základě této analýzy bude vytvořen návrh inovací a vypracováno ERD nutné k následné implementaci. Samotná implementace bude realizována za pomocí PHP a databáze ORACLE. Vzhled aplikace pak bude tvořen pomocí HTML a CSS. Chod serveru pro práci s webem bude realizován na serveru Apache běžícím na localhostu.
Informační systém
8
2. Informační systémy 2.1 Pojem informace a data Základem každého informačního systému jsou nějaká vstupní a výstupní data, se kterými systém či uživatel pracuje. Původ a obsah získaných dat pochází z informace. Informace může být sdělení, obsah zprávy či údaj o reálném prostředí nebo také vědění, které lze předávat. (Wikipedia, 2011)
2.2 Podnikový informační systém Skládá se z lidí zpracovávajících podniková data pomocí prostředků, jež mají k dispozici a předem daných postupů. Pod těmito prostředky si můžeme představit různé formuláře či podklady. Zpracováním prostředků je tvořena informační databáze získaných dat a znalostí sloužící k řízení nebo podpory rozhodování v podnikových procesech. Podnikový systém by měl: • Být hlavním integračním nástrojem spojujícím datové toky, procesy a komunikaci uvnitř firmy • Pozitivně ovlivňovat každodenní agendu a vytvářet standard pro způsob nakládání s daty • Poskytovat relevantní data pro podporu rozhodování (Sodomka, 2006)
2.3 Životní cyklus IS Rozhodnutí zavést informační systém bývá důsledkem potřeby řešit chod nebo problém podniku a to buď zavedením zcela nového produktu, nebo vylepšením stávajícího. Životní cyklus se skládá z těchto etap: • Specifikace požadavků • Analýza • Návrh • Implementace • Zavedení a testování produktu, dokumentace • Provoz, údržba a rozvoj produktu (Rábová, 2008)
Charakteristika ERP
9
3. Charakteristika ERP ERP (Enterprise Resource Planing) jsou chápány jako aplikace určené k řízení podnikových dat. Umožňují plánování a často automatizují podnikové procesy. ERP většinou tvoří základ podnikového informačního systému, který bývá rozšiřován o další aplikační moduly. Mezi hlavní odvětví, ve kterém se ERP využívá, patří logistika a finance. Finanční modul pokrývá investiční, nákladové a finanční účetnictví. V logistickém oddělení se využívají pro široké spektrum operací, od plánování nákupu přes přijetí zboží na sklad až po řízení vlastní výroby. Pokrývá tedy celé řízení logistiky v podniku. Systém ERP může svým sdílením a poskytováním podnikových dat představovat podnikovou databázi, do které jsou zanášena a zpracovávána podniková data a transakce. (Basl, 2007) Schematické rozložení základních funkčních modulů ERP je vidět na následujícím obrázku.
Obr. 1
Obr. 1 funkční moduly ERP produktu SAP R/3 (zdroj: Basl, 2007)
Charakteristika CRM
10
4. Charakteristika CRM CRM (Customer Relationship Management) jsou aplikace zajišťující komunikaci a zlepšování vztahů se zákazníkem např. Formou elektronické pošty, telefonické centrum pro řešení potřeb zákazníků atd. Základem je obsáhlá databáze podporující automatizaci procesů. Podle způsobu uplatnění dělíme CRM na: 1. Aktivní 2. Operativní - poskytuje podporu podnikových procesů v oblastech prodeje, marketingu a služeb. Spočívá v ukládání veškerých interakcí se zákazníkem do databáze. Tím se tvoří historie daných interakcí ze kterých je možné čerpat v případě potřeby. 3. Kooperační - zde se jedná o přímou komunikaci se zákazníkem, která je prováděna prostřednictvím pošty, internetu nebo dokonce hlasovým automatem na telefonní lince. 4. Analytické Provádí účelovou analýzu zákaznických dat pro: • Stanovení cen produktů, vývoj nových produktů • Určení směru marketingových kampaní a zvýšení jejich efektivnosti • Manažerské rozhodování pro např. určení předpovědi finančního zisku z dané skupiny potencionálních zákazníků CRM se také zaměřuje na komunikaci uvnitř daného podniku. V případě reklamování výrobku je daný problém popřípadě stav specifikován v systému a není potřeba nadále seznamovat ostatní personál s touto problematikou. Výhodou z pohledu zákazníka je možnost srovnání ceny pomocí CRM nebo komunikace o dodávkách s více dodavateli. Nevýhodou z pohledu dodavatele je pak fakt že zákazník často nakupuje od dodavatele, který nabízí ve většině případech výhodnější cenu či lepší podmínky. (Basl, 2007)
Strukturovaná analýza
11
5. Strukturovaná analýza 5.1 Definice Cílem je vytvořit logické modely informačního systém, definovat co musí systém splňovat a vyřešit případné problémy nebo překážky dříve než samotnou implementaci. Nevyskytují se pojmy typu tabulka, databáze nýbrž faktura, objednávka. Spočívá tedy zejména ve tvorbě modelů. Analýzu lze řešit dvěma přístupy, strukturovaným a objektově orientovaným. (Rábová, 2008)
5.2 Strukturovaný přístup Modely strukturovaného přístupu (Rábová, 2011) :
a) Funkční model Představitelem je Data Flow Diagram (diagram datových toků, DFD) Představuje datové toky, jejich transformace, uložiště a zdroje uvnitř informačního systému v hierarchické síti diagramů. Pro tvorbu DFD diagramů se využívá CASE nástroj PowerDesigner – ProcessAnalyst. CASE (Computer Aided Software Engineering) jsou nástroje a prostředky, díky kterým je možné plánovat projekty IS, dokumentovat stav vyvíjeného IS, integrovat návrhy nebo otestovat aplikaci. Výsledkem je standardizovaná forma dokumentace v podobě modelů, programových kódů, popisů databáze, řešení a možnost zpětného generování popisů z kódů (Reverse Engineering). Skládá se ze 4 složek: • Proces - pracuje se vstupními daty, která jsou konáním nějaké činnosti transformována na data výstupní. Pod takovou činností si můžeme představit např. ukládání objednávek nebo evidenci zboží ve skladě
Obr. 2 Ukázka procesu v nástroji Process Analyst
Strukturovaný přístup
12
Datový tok (Data flow) - je tok informací proudící daným směrem, jméno toku obvykle vyjadřuje o jaký druh informací či dat se jedná. Např. Dodací list mezi dopravcem a skladem
Obr. 3 Ukázka Datového toku v nástroji Process Analyst
•
Terminátor - je vnější subjekt v okolí informačního systému, se kterým se provádí výměna dat a informací. Např. zákazník, dopravce, banka.
Obr. 4 Ukázka terminátorů v nástroji Process Analyst
•
Datastore - místo kde se uchovávají informace, např. faktury a objednávky. Je základním podkladem pro tvorbu ERD. Přístup (zápis/čtení) do datastoru je možný pouze přes proces.
Obr. 5 Ukázka datastoru v nástroji Process Analyst
DFD diagram je možné rozdělit do více úrovní pomocí dekompozice. Jedná se o rozdělení problému do jednodušších podskupin. Např. dekompozice skladu bude obsahovat procesy jako příjem zboží, řízení reklamací, výdej zboží atd.
Strukturovaný přístup
13
Jednotlivé úrovně DFD jsou následující: • Kontextový diagram - nejvyšší úroveň, jež neobsahuje datastory ale pouze jediný proces a veškeré vnější okolí v podobě terminátorů (zákazníci, banky, dodavatelé) • Systémový diagram - vzniká dekompozicí onoho jediného procesu na úrovni kontextového diagramu. Obsahuje veškeré subsystémy v podobě procesů (Sklad, Logistické oddělení, Výroba atd.) • Klasické DFD - základní DFD vycházející z dekompozic jednotlivých subsystémů • Minispecifikace - tvořené v procesu na nejnižší úrovni, pro usnadnění a pochopení budoucího programování
b) Model vnějšího chování systému Reprezentován kontextovým diagramem spolu se seznamem událostí. Seznamem událostí máme na mysli různé podněty působící na sytém z jeho okolí. Typy událostí mohou být: • Flow oriented (F) charakterizují ji data vstupující do systému • Temporal (T) událost řízená časem, řízená vnitřními hodinami systému • Control (C) zvláštní případ T události, jež se neřídí hodinami, nebo zvláštní případ F události nesoucí binární informací.
c) Datový model (Chen) Prostředkem pro tvorbu je ERD (Entitně relační diagram). Tvoří jej entity se svými atributy a vzájemné vazby mezi nimi. Entitou může být libovolný objekt např. člověk, auto, atd. a atribut pak vyjadřuje jeho vlastnost jako věk či barva. Relační vazby mezi entitami jsou definovány kardinalitou a parcialitou, kde kardinalita udává počet výskytů entity např. 1:1, 1:N, M:N a parcialita pak povinnost čí naopak nepovinnost vazby. Je to jeden ze základních prvků pro návrh fyzické databáze. Ukázka ERD, kde „Učitel“ může vyučovat až pět předmětů zatímco „Předmět“ musí mít právě jednoho „Učitele“:
Obr. 2
Obr. 6 Ukázka ERD v nástroji Data Architect
d) Model řízení Využívá se k modelování časově závislého chování systému, odděluje návaznosti vstupních a výstupních dat spolu s jejich transformací (skrz procesy) od časových návazností daných procesů.
PHP
14
6. PHP 6.1 Popis PHP je skriptovací programovací jazyk, určený pro programování dynamických webových aplikací. Stejně jako webový server Apache je prezentován jako freeware a je platformě nezávislý. (Kosek, 1999)
6.2 Historie U zrodu stál Rasmus Lerdorf, který v roce 1994 vytvořil jednoduchý systém pro evidování přístupu k jeho stránkám psaný v jazyce Perl. Nadměrné vytěžování serveru si však vyžádalo přepsat systém do jazyka C. Systém se stal oblíbeným mezi dalšími uživateli a rychle se rozšířil. Přicházely požadavky na vylepšení celého systému. Systém pod názvem Personal Home Page Tools (později Personal Home Page Construction Kit) byl rozšířen a doplněn o dokumentaci. Autor poté vytvořil nástroj pro začleňování SQL dotazů do stránek s názvem Form Interpreter (FI). Propojením těchto dvou systému vznikl PHP/FI 2.0, programovací jazyk umožňující zápis do HTML stránek, který se později rozšířil po celém světě. V roce 1998 přišlo PHP 3.0 a proti stávající verzi přineslo rozšíření a zrychlení systému a nově i podporu Windows. V roce 2000 bylo vydáno PHP 4 s novým jádrem „Zend Engine“ jehož přínosem bylo velké zrychlení systému, podpora http relací, více webových serverů a další. Po dlouhém vývoji je v roce 2004 uvedeno PHP 5 s novým jádrem „Zend Engine 2.0“ s novým objektovým modelem a spoustou dalších novinek. PHP za dobu od svého vzniku přivítalo množství vývojářů a předpokládá se, že PHP je používáno ve více jak desítkách milionů domén. (Kosek, 1999)
SQL
15
7. SQL 7.1 Popis Structured Query Language zkráceně SQL je nejrozšířenější jazyk pomocí kterého můžeme tvořit databázové dotazy a komunikovat tak s relačními databázemi. SQL je neprocedurální a neřadí se tak po bok jazyků jako Pascal, Basic, C atd. Procedurální jazyk SQL je tvořen tzv. dotazem (query), což je požadavek na databázi. Po odeslání dotazu následuje odpověď ze strany databáze. Dotaz je tvořen předem danou posloupností příkazů spouštěných v určitém pořadí. Je určen právě pro správu a údržbu databází a není tedy vhodný k programování jako takovému. Výsledkem např. webové aplikace pak často bývá kombinace s procedurálními jazyky. (Oppel, 2008)
7.2 Historie Původ jazyka sahá do 70. let, kde výzkumníci společnosti IBM vyvinuli relační databázi s názvem Systém/R. Tato databáze vycházela z práce DR. E. F. Codda a její součástí byl jazyk SEQUEL (Structured English Query Language), umožňující manipulaci s daty v databázi. Kvůli ochranné známce jedné britské společnosti byl název jazyka zkrácen na SQL. Na trhu byla databáze IBM předstižena produktem ORACLE společnosti Relation Software a databází INGRES firmy Relational Technology. Roku 1986 a 1987 vznikly dvě standardizační komise (při Institutu ANSI a organizací ISO). Spoluprácí obou komisí vznikl v roce 1989 jednotný, obecně platný standard SQL-89. V následujících letech byl standard rozšířen a vznikl SQL-92. Následující standard SQL-99 označován jako SQL3 podporuje práci s objektově-relačními databázemi díky množstvím objektových funkcí. Nová rozšíření a podpora XML přichází se SQL:2003. (Oppel, 2008)
Oracle
16
8. Oracle 8.1 Definice Oracle je systém řízení báze dat (Oracle database management system – DBMS), moderní multiplatformní databázový systém s velice pokročilými možnostmi zpracování dat, vysokým výkonem a snadnou škálovatelností. Databázový systém Oracle je vyvíjen firmou Oracle Corporation. Oracle Corporation je největší společností na světě, která dodává podnikový software firmám a organizacím všech velikostí. Tato společnost, jejíž roční obrat činí 10,2 miliardy USD, nabízí kromě podnikových aplikací a nástrojů na jejich vývoj také databázi, aplikační server a nástroje pro podnikovou spolupráci. (Procházka, 2009)
8.2 Popis 8.2.1 Databáze Jak již bylo řečeno Oracle je relační systém řízení báze dat, ve kterém se data ukládají do tabulek definovaných pomocí sloupců. Každý sloupec je definován svým názvem a datovým typem obsažených dat, jež se poté ukládají do jednotlivých řádků dané tabulky. Spojování tabulek tzv. relace jsou realizovány prostřednictvím stejných informačních hodnot ve sloupci první tabulky, který nabývá stejných hodnot a má stejný datový typ, jako data obsažená ve sloupci druhé tabulky. Další možností jak přistupovat k datům je podpora objektově orientované struktury. Tabulkovými prostory chápeme všechna interní data databáze logicky mapovaná na soubory. Těmito daty pak mohou být objekty, objekty mezi sebou provázané či objekty obsahující další objekty. (Procházka, 2009) 8.2.2 Instance Je tvořena systémovou pamětí a procesy běžícími na pozadí. Je to nástroj potřebný k manipulaci s daty uvnitř databáze. Aby bylo možné manipulovat s daty je nejdříve databáze inicializována příkazem MOUNT a následně otevřena příkazem OPEN. Databáze může být otevřena (OPEN) nebo připojena (MOUNT) více jak jednou instancí, avšak instance může otevřít nanejvýš jednu databázi. (Kreines, 2006)
Oracle
17
8.3 Typy Oracle databází Standard Edition Verze pro servery obsahující základní funkce databáze Oracle. Nemá žádná paměťová omezení a dokáže využít až 4 procesory. Standard Edition One Stejná jako Standard Edition s podporou maximálně dvou procesorů. Enterprise Edition Úplná verze obsahující ve srovnání se Standard Edition další funkce, zejména v oblasti výkonu a zabezpečení. Není omezená paměťovým prostorem ani počtem procesorů. Express Edition Jedná se o výkonnostně limitovanou distribuci představenou v roce 2005. Paměťový prostor pro uživatelská data činí 4 GB, využití operační paměti je limitováno pomyslným stropem 1 GB a celá databáze může pracovat pouze s jedním procesorem. (Oracle, 2011)
8.4 Historie vývoje Oracle databáze Oracle V2 • Společnost Relation Software se zakladatelem Larry Elisonem představuje jeden z prvních komerčních relačně databázových systémů se základní podporou SQL. Oracle v3 • Přejmenovaná společnost Oracle Corporation vydává druhou verzi databáze, která je přepsaná do jazyka C a nově podporuje příkazy COMMIT a ROLLBACK. Oracle v4 • Další verze s podporou konzistence při čtení dat. Oracle v5 • Zahrnuje podporu modelu klient-server. Oracle v6 • Přechod na RDBMS a podpora jazyka PL/SQL. Oracle v7 • Podpora referenční integrity, procedur a triggerů. Oracle8 Database • Možnost objektově orientovaného vývoje a podpora multimediálních aplikací.
Oracle
18
Oracle8i Database • Přídavkem „i“ je definováno zaměření na poskytnutí lepších mezioperačních procesů s internetem, obsahuje Java virtual machine. Oracle9i Database • Spousta nových vylepšení, možnost zápisu a čtení z XML dokumentů. Oracle RAC pak nově umožňuje ukládat a tvořit databázová data na daném PC bez nutnosti provozovat Oracle Parallel Server. Oracle Database 10g • Zavádí podporu regulárních výrazů, označení „g“ pak umožňuje využití grid computingu. Oracle Database 11g • Další verze databáze s efektivnější, pružnější a snadněji spravovatelnou infrastrukturou, rozšířená o nástroje jako Real Application Testing simulující reálnou zátěž databáze pro eliminaci případných nedostatků či rizik. (Portugal, 2008)
Vlastní práce
19
9. Vlastní práce 9.1 Charakteristika firmy 9.1.1 Popis Firma FEI Czech Republic s.r.o. je jednou z poboček celosvětového lídra v oblasti výroby a vývoje elektronových a iontových mikroskopů. Společně s Brněnskou pobočkou nalezneme zastoupení v Nizozemí, Japonsku a Asii a to vše pod záštitou hlavního sídla firmy v Hillsboro, USA. Cíloví zákazníci jsou výrobní podniky, společnosti, instituce a školy z oblastí přírodních, technických a společenských věd. Brněnská divize se zaměřuje na výrobu, vývoj a servis elektronových mikroskopů řad SDB (Small Dual Beam), TEM (Transmition Electron Microscope) a SEM (Scaning Electron Microscope). V současné době brněnská divize zaměstnává více jak 400 zaměstnanců přičem a celkový počet zaměstnanců se pohybuje kolem 2000. Výroba těchto zařízení podléhá přísným podmínkám, co se čistoty týče. Zaměstnanci pracující ve výrobě mají předepsaný oděv ve formě bílých pracovních kombinéz s pokrývkou hlavy popř. rukou. Výrobní oddělení je rozdělené na tzv. čisté prostory, které se dále dělí na prostory s čistotou do 1000 prachových částic na stopu krychlovou a na prostory s čistotou do 10000 prachových částic na stopu krychlovou. Tyto prachové částice jsou odvětrávány a výrobní oddělení je proti možnosti znečištění z vnějšího okolí odděleno přechodovými filtry. Kompletní výroba jednoho mikroskopu je v řádu několika týdnů až měsíců v závislosti na daném typu. Hlavním odbytem pro FEI Czech Republic s.r.o. je pak evropský trh tvořící zhruba 40-50% distribuce v dalším pořadí pak USA a Kanada s 30-40% a nakonec Asie s 20-30%.
Obr. 7 Firmení logo (zdroj: databáze FEI)
Charakteristika firmy
20
9.1.2 Historie Před založením firmy roku 1965 je uveden první SEM (skenovací elektronový mikroskop) společností Cambridge Scientific Instrument Company. Tři lidé stojí u vzniku společnosti v roce 1971, Dr. L. W. Swanson, N. A. Martin a L. Swenson. V roce 1978 se ke společnosti připojuje Dr. J. Orloff. O tři roky později společnost pracuje na vývoji iontového zdroje na bázi tekutého kovu a o rok později jej představuje v prvních tubusech (posunovatelná trubice s objektivem umožňující zaostřování). V roce 1985 představen první FIB (Focused Ion Beam), zaostřený iontový svazek již v kompletní pracovní stanici. Spoluprací FEI a Philips Electron Optics vzniká roku 1993 první DualBeam™ stanice (FIB/SEM). Vznik brněnské pobočky začíná v roce 1996 kdy firma Philips Electron Optics kupuje Delmi Brno, někdejší část firmy TESLA. Akvizicí Philips Electron Optics v roce 1997 vzniká FEI Czech Republic s.r.o. V roce 1998 FEI představuje svůj Tecnai, TEM mikroskop a v následujícím roce získává společnost Micrion. Roku 2000 je představena první malá DualBeam stanice (SDB). V letech 20012008 dochází k akvizici dalších firem, FEI vyvíjí první monochromátor a představuje dva nové produkty a to TEM mikroskop Titan s rozlišením 0,5 angströmu a Magellan, SEM rastrovací mikroskop schopný vysokého rozlišení. (FEI, 2011)
Charakteristika firmy
21
9.2 Současný stav Firma provozuje velké množství informačních systémů pro různé činnosti. Od docházkového přes nákupní až po systém na podporu finalizace. Z pohledu logistického oddělení jsou systémy, jež nás zajímají, následující: • Systém CRM pro zasílání nabídek a příjem objednávek • Databázový program MS Access • Výrobní systém FinalTest • ERP systém MFG/Pro Životní cyklus mikroskopu pak začíná u systému CRM, jež ukládá do své databáze všechny objednávky a zákazníkům zasílá nabídky. Po přijetí objednávky se daná objednávka musí zaplánovat v programu MS Access, kvůli přehledu výrobního plánu, a MFG/Pro. Systém MFG/Pro slouží pro plánování a objednání materiálu, je-li tedy daný výrobek zaplánován, zobrazí se podle daného typu mikroskopu strukturovaný seznam dílů potřebných k objednání. Prostředí tohoto systému je znakové, což umožňuje díky vstupu z klávesnice rychlou interakci. Avšak díky tomu, že sdružuje ostatní oddělení jako je nákup, prodej nebo řízení zásob, může být pro některé uživatele nepřehledný. Přepínání mezi jednotlivými funkcemi, úseky daných oddělení a úrovněmi je realizováno sekvencí číselných identifikátorů oddělených tečkami. Evidence materiálu na skladu a jeho pohyby jsou rovněž realizovány v MFG/Pro. Přijetí materiálu na sklad je evidováno pracovníky skladu v tomto systému také. Pokyn k vydání materiálu na daný výrobek dává logistickéhé oddělení prostřednictvím tzv. Work Orderu. To je strukturovaný seznam materiálu s kusovníkem a uložením, generovaným pomocí MFG/Pro. O tom, že výroba převzala tento materiál, však neexistují žádná elektronická data, ale pouze podpis daného Work Orderu. Dalším krokem je systém FinalTest jež má různé stupně, jeden pro mechanickou montáž a další 4 pro finalizaci. Systém slouží pro zaznamenávání hodnot a fází rozpracovanosti, jak při mechanické montáži, tak ve finalizaci. Čerpá z databáze obsahující návody a pracovní postupy. Technik pracující na daném zařízení pak zaznamenává které procesy již dokončil a má možnost získat informace a návod k onomu procesu. Ostatní oddělení na rozdíl od systému MFG/Pro do tohoto systému nezapisují ani z něj nevyčítají.
Charakteristika firmy
Obr. 8 Ukázka systému FinalTest (zdroj: databáze FEI)
Obr. 9 Ukázka systému MFG/Pro (zdroj: databáze FEI)
22
Analýza datových toků
23
9.3 Analýza datových toků 9.3.1 Kontextový diagram Nejvyšší úrovní hierarchického dělení Data Flow Diagramu je kontextový diagram, obsahující terminátory představující vnější okolí firmy a jejich datové toky z firmy a do firmy.
Obr. 10 Kontextový diagram
Popis procesů: • Proces FEI - je nejvyšší úrovní Data Flow Diagramu a sdružuje pod sebou jednotlivé řídící úrovně (sklad, výroba, atd.), které mají vliv na logistické procesy firmy. Popis terminátorů: • Zákazníci - firma zasílá zákazníkům nabídky svých produktových řad a následně přijímá objednávky ze strany zákazníků. Tyto objednávky jsou po schválení potvrzeny zákazníkovi, který je informován o stavu ve
Kontextový diagram
24
kterém se jeho objednávka nachází. Nakonec je zákazníkovi zaslána faktura na sjednaný produkt. • Dodavatelé - firma má několik dodavatelů, průběžně u nich objednává požadovaný materiál. Každá objednávka je předem potvrzena a celá transakce je dokončena převzetím dodacího listu. V případě poškození je zboží reklamováno a dodavatel informuje o stavu reklamace. • Přepravci - pro expedici hotového produktu se sjednává přepravce, který potvrdí termín přepravy a následně zasílá firmě fakturu za vykonané služby. Tyto služby však mohou být, např. v případě poškození zboží na cestě k zákazníkovi, reklamovány. Přepravce pak informuje o průběhu reklamace. • Banka - finanční oddělení posílá bance platební příkazy a operace. Banka poté informuje o uskutečněných pohybech.
Systémový diagram
25
9.3.2 Systémový diagram Vzniká dekompozicí původního procesu FEI.
Obr. 11 Systémový diagram
Popis procesů: • Zpracování financí - úsek zabývající se zpracováváním a vyplácením faktur získaných od vnitřních firemních zdrojů, jimiž jsou jednotlivá oddělení, nebo od vnějších zdrojů, jež zasílají faktury přímo na finanční oddělení. • Logistické oddělení - řídí, plánuje, objednává a eviduje veškeré materiálové toky ve firmě. Vytváří časové plány pro výrobu produktů v souladu s ročním harmonogramem. Komunikuje s přepravci, dodavateli i zákazníky.
Systémový diagram
•
•
26
Zpracovává objednávky od zákazníků a dává skladu pokyny k vychystání materiálu pro výrobní oddělení. Rovněž zajištuje export hotových výrobků a plánuje jejich přepravu. Eviduje faktury za prodané výrobky a faktury požadované od dodavatelů. Sklad -stará se o příjem a patřičné uložení materiálu. Od dodavatelů přijímá dodací listy a řeší veškeré reklamace týkající se výroby, finalizace či dodavatelů. Eviduje veškerý přijatý či vydaný materiál a aktualizuje stav daného materiálu na skladě. Dále pak vychystává materiál podle tzv. Work Orderů, které jsou evidovány a potvrzovány výrobou. Faktury od dodacích listů zasílá na finanční oddělení. Výroba - od skladu přebírá výdejky spolu s materiálem a vrací potvrzení o přijetí. Se skladem řeší reklamace nebo výměny materiálu. Logistické oddělení vytváří časové plány pro koordinaci výroby. Formou vizit podává hlášení o stavu rozpracovaného výrobku.
Popis datový toků: • Potvrzení přepravy - potvrzení dostupnosti a objednání přepravy na požadovaný termín. • Faktura za přepravu - vyúčtování od přepravce obsahující náležitosti jako název firmy, termín transakce, termín přepravy, výsledná částka, atd. • Objednávka přepravy - logistické oddělení sjednává přepravu pro hotový produkt s daným přepravcem na základě formy přepravy a to na stanovený termín. • Reklamace přepravy - v případě je-li produkt při přepravě k zákazníkovi poškozen je zahájeno reklamační řízení s přepravcem. • Stav Reklamace přepravy - o stavu reklamace informuje přepravce elektronicky nebo telefonicky. • Nabídka produktu - zaslání produktových řad s výrobky formou katalogu, elektronická forma nabídky s cenovým odhadem. • Objednávka - sjednání objednávky na již určitý produkt nebo potvrzení předchozí nabídky. Obsahuje potřebné údaje o zákazníkovi, kontakty či dodací adresu. • Potvrzení objednávky - objednávka je potvrzena splňuje-li kritéria ročního výrobního plánu produktové řady. • Faktura pro zákazníka - při objednání určitého produktu je zaslána zákazníkovy faktura s číslem účtu, dobou splatnosti, atd. Za výrobek se kvůli jeho vysoké ceně a náročností na výrobu platí v předstihu. • Info o stavu objednávky - informace od logistického oddělení o zpožděních a pohybech termínů dodání. Informace získané na základě osobních vizit ve výrobním oddělení a emailovou komunikací uvnitř firmy. • Info o operacích - informace o stavu a průběhu vykonaných platebních operací.
Systémový diagram
• • • • • • • • • • • • • • • •
27
Platební operace - příkazy k úhradě a veškeré finanční pohyby a požadavky na banku. Pokyn k vychystání materiálu - pracovní příkaz pro vychystání materiálu do požadovaného termínu. Seznam zboží k nachystání - seznam materiálu, který se váže k pokynu k vychystání. Obsahuje údaje jako materiálové uložení na skladě, počet požadovaných kusů, popis a číslo materiálu nebo dílu. Informace o pohybu materiálu - informace o změnách a pohybech na skladě jako odepsání, příjem, vydání či změna uložení materiálu jsou dostupné logistickému oddělení. Faktury za dodaný materiál - faktury od dodavatelů přijaté s dodacím listem. Získávány při přijímání materiálu na sklad Potvrzení o přijetí výdejky - zaměstnanec výroby podepisuje převzetí výdejky spolu s vychystaným materiálem. Požadavek na reklamaci/výměnu materiálu - reklamace nebo nutná urgentní výměna materiálu ze specifikovaného důvodu. Stav dané reklamace - informace o stavech podaných žádostí na reklamaci. Výdejka - seznam zboží na daný typ výrobku s kusovníkem pro překontrolování zaměstnancem mechanické montáže. Faktura dodavatele - faktura za materiál přijatý na sklad s údaji o materiálu, počtu kusů a ceně. Reklamace zboží přijatého - okamžitá reklamace materiálu při přijímání na sklad, řešena s dodavatelem na místě. Stav Reklamace dodavatele - informace o průběhu, schválení reklamace, podmínkách vyrovnání. Dodací list - přebíraný s dodaným zbožím obsahuje informace o výrobku, výrobní označení, počet kusů, popis, datum dodání, atd. Potvrzení o převzetí - skladníkem podepsané potvrzení o převzetí objednaného materiálu. Informace o průběhu - souhrn informací o aktuálním stavu výrobku, popis závad, reklamací materiálu, důvody zpoždění kompletace, atd. Info o časových plánech - časové termíny a rozvrhy pro výrobu a finalizaci potřebné k sestavení výrobků v požadovaném čase a jejich následnému testování.
Systémový diagram
28
Popis datových uložišť a jejich toků: • Faktury vydané - evidence faktur, které již byly zaslané zákazníkům. o Datové toky: Evidence vydaných faktur - faktury sjednané na konkrétní typy výrobku s údaji o splatnosti, číslem účtu pro placení, podmínkami dodání, informacemi o zákazníkovi a o objednaném zařízení. Kontrola příchozích plateb - informace o uložených fakturách pro sledování úhrady. • Faktury přijaté - získané od dodavatelů a přepravců. Jsou to finanční požadavky k úhradě za materiál a služby, jež firma nakoupila. Tvoří podklady pro vystavování platebních transakcí. o Datové toky: Evidence přijatých faktur - ukládání přijatých faktur v elektronické podobě obsahující seznam zakoupených služeb či materiálu s koncovou cenou a podmínkami platby. Podklady pro platby - informace čtené z databáze, stejné jako při zadávání nové přijaté faktury. Slouží jako podklad k platebním operacím
Dekompozice procesu Sklad
9.3.3 Dekompozice procesu Sklad
Obr. 12 Dekompozice procesu Sklad
Popis procesů: • Příjem zboží - proces zprostředkovává příjem zboží na sklad, pro každý přijatý materiál eviduje dodací list a přijatý materiál zavádí do systému. Faktury za dodaný materiál jsou zaslány ke zpracování logistickému oddělení. • Výdej a správa materiálu - přijímá pokyny od logistického oddělení k vychystání materiálu podle daného seznamu. Provádí odpis materiálu v databázi. Na základě pracovních příkazů eviduje výdejky potvrzené výrobou při přebírání materiálu. Na základě pokynů od reklamačního úseku vydává náhrady za poškozený nebo chybějící materiál. • Řízení reklamací - zabývá se sběrem reklamací z celého podniku, komunikuje s dodavateli a informuje ostatní úseky o stavu probíhající
29
Dekompozice procesu Sklad
reklamace. Jednotlivé reklamace eviduje do systému a dává pokyn k vydání náhrad. Popis datových toků: • Evidence dodacích listů - seznam materiálu od dodavatele přijatého na sklad. Obsahuje název dodavatele, výrobní čísla, označení materiálu, popis někdy i cenu. • Evidence přijatého zboží - nově přijaté zboží je aktualizováno v databázi. Eviduje se počet přijatých kusů, datum naskladnění, identifikační číslo materiálu a zodpovědná osoba, která materiál přijímala. • Stav materiálu - veškeré dostupné informace o materiálu (počet kusů, uložení, datum odepsání položky, datum přijetí, atd.) • Aktualizace stavu po výdeji - odečtení daného počtu kusů vydaného materiálu přímo úměrnému počtu kusů vydaných do výroby. • Pokyn k vydání náhrady - identifikační číslo výrobku, důvod vydání, priorita, počet kusů. • Evidence a stav reklamací - vyřizovaná reklamace je zanesena do systému, eviduje se např.: na jaký typ produktu se sériovým označením patří, priorita reklamace nebo stav. • Informace o reklamaci - vyčítání informace o stavu v jakém se nachází daná reklamace. Popis datových uložišť: • Dodací listy - uložiště dokumentů převzatých při dodání zboží. Mimo jiné obsahují hlavně informace o počtu přijatého materiálu s výrobními čísly výrobce a datem dodání. • Díly skladem - databáze všech dílů se kterými sklad manipuluje a jsou využívány k výrobě. Nalezneme zde kompletní seznam dílů, jejich identifikačních čísel, počty kusů, data aktualizací, uložení, atd. • Výdejky - jsou to seznamy vydaných dílů obsahující data vychystání, čísla konfigurace produktů, počty vydaných kusů, identifikační čísla materiálu, typ pracovního pokynu, atd. Každá výdejka je také podepsána zaměstnancem výroby, který tím stvrzuje převzetí materiálu. • Stavy reklamací - databáze aktuálních, probíhajících a historických reklamací. Jsou zde všechny dostupné informace o průběhu dané reklamace.
30
Dekompozice procesu Výroba
9.3.4 Dekompozice procesu Výroba
Obr. 13 Dekompozice procesu Výroba
Popis procesů: • Finalizace - proces dostává od logistického oddělení informace o časových plánech. Při výrobních procesech získává ze systému data a postupy pro specifickou modelovou řadu, práce na zařízení je pak zanášena do systému. Dále generuje požadavky na výměnu nebo reklamaci materiálu. Stav reklamace pak získává ze skladu. Při přebírání mechanicky dokončeného zařízení vystavuje potvrzení o převzetí. • Mechanická montáž - proces dostává od logistického oddělení informace o časových plánech. Při výrobních procesech získává ze systému data a postupy pro specifickou modelovou řadu, práce na zařízení je pak zanášena do systému. Dále generuje požadavky na výměnu nebo
31
Dekompozice procesu Výroba
•
reklamaci materiálu. Stav reklamace pak získává ze skladu. Po dokončení mechanické montáže předává zařízení do finalizace a přebírá potvrzení. Zjišťování stavu - proces zabývající se zjišťováním informací o průběhu montáže a finalizace produktu. Bývá realizován elektronickou komunikací vně podniku nebo osobní návštěvou výrobního oddělení.
Popis datových toků: • Potvrzení o převzetí systému - stvrzenka o předání mechanicky dokončeného zařízení do další fáze výroby. • Stav a info o zařízení - evidování fáze rozpracovanosti daného zařízení, počtu pracovních hodin operátora, pracovního označení zařízení, atd. • Stav montáže a info o zařízení - evidování fáze rozpracovanosti daného zařízení, počtu pracovních hodin operátora, pracovního označení zařízení atd. • Postup a data pro finalizaci - strukturované pracovní postupy daného zařízení, popisy jednotlivých procesů • Postupy a data pro montáž - strukturované pracovní postupy daného zařízení, popisy jednotlivých procesů • Stav finalizace produktu - problémy vzniklé při finalizaci nebo testování zařízení, odhadované termíny dokončení jednotlivých procesů, důvody zpoždění • Stav mechanické montáže - problémy vzniklé při mechanické montáži, odhadované termíny dokončení jednotlivých procesů, důvody zpoždění Popis datových uložišť: • Postupy a stavy FinalTest - část informačního systému (FinalTest) s rozsáhlou databází pracovních postupů obsahující odkazy na návody a schémata sloužící k podpoře zaměstnanců výroby. Databáze eviduje pracovní označení, čas strávený na daném zařízení a seznam pracovních procesů. Každý pracovní proces daného zařízení je pak ukládán do databáze jako dokončený či nedokončený.
32
Dekompozice procesu Logistické oddělení
9.3.5 Dekompozice procesu Logistické oddělení
Obr. 14 Dekompozice procesu Logistické oddělení
Popis procesů: • Zpracování objednávek - proces řídící komunikaci se zákazníkem. Zasílá produktové nabídky zákazníkům, eviduje objednávky a stanovuje finanční kritéria vyúčtování, jež jsou obratem zasílaná zákazníkům ve formě faktur. • Plánování a logistika - přebírá informace o objednávkách a plánuje je. Časové plány následně poskytuje výrobnímu oddělení. Řídí a plánuje materiálové toky ve firmě, stará se o evidenci faktur. Objednává přepravu pro hotové výrobky a materiál pro výrobu. Informuje zákazníka o
33
Dekompozice procesu Logistické oddělení
termínech dodání a případných zpožděních či komplikacích. Vytváří tzv. Work Orders, které zanáší do systému a předává je spolu s pokynem k vychystání skladu. Popis datových toků: • Evidence objednávek - ukládání objednávek do systému. Eviduje se objednané zboží, zákazník, adresa, sjednaná cena, termíny dodání, doba splatnosti, datum vystavení, atd. • Informace o objednávce - vyčtení hodnot, které byly zadány při vkládání objednávky do systému. • Evidence produktu - vkládání nových produktů do databáze, eviduje se označení produktu, název, popis, cena a další údaje. • Informace o produktech - vyčtení informací o produktu (Název, označení, cena, atd.) • Údaje o objednávce - předání informací o objednávce pro zaplánování do výrobního procesu. Předávají se stejné informace jako při vyčítání. • Info o plánech - celoroční plány a rozvrhy montáží a finalizací daných produktů. • Plánování objednávek - uložení časových plánů a rozvrhů do databáze. • Evidence a tvorba WO - seznam materiálu s kusovníkem, termínem pro dokončení, pracovním označení zařízení, atd. • Informace o WO - veškeré údaje zadané při vkládání Work Orderu do systému. Popis datových uložišť: • Produkty - eviduje seznam nabízených produktů, jejich název, popis, cenu, produktovou řadu a produktové označení. • Objednávky - uchovává veškeré zaevidované objednávky. Jsou evidovány údaje o zákazníkovy, dodací adresa, termíny dodání, výsledná cena, označení produktu. • Plánovaní objednávek - obsahuje časové rozvrhy pro výrobu specifických zařízení pro určitého zákazníka v daném kalendářním roce. Každému zařízení je přiřazeno jeho pracovní označení v závislosti na produktové řadě. • Work orders - evidence příkazů k vychystání materiálu. Obsahuje seznam materiálu, kusovník, termín pro dokončení, uložení materiálu, pracovní označení zařízení, atd.
34
Návrh
35
9.4 Návrh 9.4.1 Hlavní zaměření aplikace Hlavním zaměření aplikace bude směřováno na zobrazení průběhu životního cyklu výrobku. Použitím a analýzou dat získaných z pracovních postupů systému FinalTest bude v přehledné formě provedeno zobrazení a výpis současného stavu sledovaného zařízení a průběhu prací. Aplikace bude také informovat o případných komplikacích. 9.4.2 Inovace 1 - Průběh prací (progress) Proces kdy logistické oddělení zjišťuje stav výrobku, aby bylo možné určit termíny dodání, vypočítat čas zpoždění a naplánovat dodání materiálu, či objednat přepravu je v současnosti realizován schůzkami zaměstnanců logistiky s výrobou, popř. e-mailovou komunikací uvnitř firmy. Logistické oddělení tak často pracuje s neaktuálními daty, což ztěžuje případnou informovanost zákazníka, je časově náročné a ovlivňuje schopnost přesného plánování exportu. Návrh čerpá z databáze systému FinalTest jež je součástí výrobního oddělení. Zaměstnancům slouží primárně pro evidování odpracovaných hodin na zařízení, kontroly zda proběhly všechny fáze montáže nebo finalizace. Stavy fází na konkrétním zařízení jsou však ukládány do databáze, naskýtá se tedy možnost zpracovat tyto data a analyzovat tak průběh dokončení zařízení.
Obr. 15 Inovace 1
Návrh
36
9.4.3 Inovace 2 - Plánování s každým vložením nové objednávky Při evidování objednávek pomocí systému CRM vzniká potřeba informace znovu vyčítat a předávat je plánování a logistice. Důvodem je potřeba zaplánování dané objednávky. Návrhem řešení je naplánování objednávky již v okamžiku vkládání objednávky do systému.
Obr. 16 Inovace 2
Návrh
37
9.4.3 Návrh databáze Pro návrh entitně relační databáze (ERD) byl použit nástroj Data architect programu Power designer
Obr. 17 Návrh ERD pro webovou aplikaci
Implementace
38
9.5 Implementace Webová aplikace je realizována v PHP a o uchování dat se stará databáze Oracle Express Edition 10g. PHP server je spuštěn na lokálním Apache serveru. Celý projekt obsahuje 33 PHP skriptů. Vzhled aplikace je implementován v HTML kódu za pomocí formátování CSS (kaskádovými styly). Aplikace vyobrazuje stav rozpracovanosti zařízení v jednotlivých fázích výroby. Umožnuje řazení podle výrobců nebo typu zařízení podle data. Dále odhaduje počet dní potřebný k dokončení výroby. Zčervenání procentuálního stavu v příslušné fázi výroby značí problém, jehož popis je dostupný po kliknutí. Z důvodu náročnosti na databázi jsou implementovány pouze dva typy výrobků.
Obr. 18 Podrobný výpis produktů pro zvoleného zákazníka
Dalšími funkcemi jsou: • Alokace materiálu (příloha A) • Vkládání objednávek, Zákazníků, Produktů a Příkazů k vychystání (Work Orders) (přílohy B, C D) • Vkládání a editace pracovních postupů jednotlivých fází výroby. (příloha E)
Implementace
Ukázky implementací: Trigger zajišťující vložení a inkrementaci id_objednavky: CREATE OR REPLACE TRIGGER "BI_IS_OBJEDNAVKY" before insert on "IS_OBJEDNAVKY" for each row begin select "IS_OBJEDNAVKY_SEQ".nextval into :NEW.ID_OBJEDNAVKY from dual; end;
Přidání cizího klíče: ALTER TABLE "IS_H650_MM" ADD CONSTRAINT "IS_H650_MM_FK" FOREIGN KEY ("PRACOVNI_OZNACENI") REFERENCES "IS_PLANOVANI_OBJEDNAVEK" ("PRACOVNI_OZNACENI")
PHP funkce pro výpočet globálního procentuálního stavu: function stavProgressu($p1,$p2,$p3,$p4,$p5) { //vahy // $p1 MM = 40dni 62,5% // $p2 Fs = 7dni 11% // $p3 FC = 14dni 22% // $p4 FA = 1dni 1,5% // $p5 FC = 2dni 3% // 1,56% = 1den $vysledek= (($p1*0.625)+($p2*0.11)+($p3*0.22)+($p4*0.015)+($p5*0.03)); return round($vysledek,2); }
PHP funkce pro výpočet dní zbývajících do dokončení: function stavDni($p1,$p2,$p3,$p4,$p5) { $vysledek= (($p1*0.625)+($p2*0.11)+($p3*0.22)+($p4*0.015)+($p5*0.03)); $vysledek=64-($vysledek/1.56); return round($vysledek,0); }
39
Implementace
Ukázka části PHP kódu pro editaci stavu pracovního postupu:
40
Implementace
41
9.6 Zhodnocení Přínos aplikace pro logistické oddělení můžeme předpokládat v každodenních situacích, kdy je potřeba co nejrychleji zjistit výrobní stav v jakém se výrobek aktuálně nachází. Tento stav, který je doposud zjišťován vnitřní podnikovou komunikací, je pak možné využít jako podklad pro naplánování exportu již hotového produktu nebo zaplánování nového zařízení do výrobního procesu místo zařízení právě dokončovaného. Díky využití dat ze systému FinalTest dochází ke zkrácení času potřebného k nalezení požadované informace. Snížena je i časová náročnost na získání těchto informací a obě oddělení, jak výrobní tak logistické, jsou ve výsledku méně zatěžována vlastním sběrem informací. Proces informovanosti logistického oddělení o stavu výrobku je tak prostřednictvím této aplikace automatizován. Aplikace také umožnuje zpracovávat základní logistické úkony jako vkládání objednávek, produktů, zákazníků, práci se stavy jednotlivých zařízení v jednotlivých fázích výroby, tisk a vkládání pracovních příkazů nebo třeba alokaci materiálu na skladu s výpisem chybějících dílů pro daný typ zařízení. Přínos pro zákazníka jako subjektu z vnějšího okolí není dán přímým užíváním aplikace, ale daty získanýmí z jejího používání. V logistickém oddělení pravidelně dochází k posouvání termínu exportů kvůli různým výrobním problémům čí zpožděním. Za každé nedodržení termínu je firma sankciována. Proto je důležité zákazníka pokud možno co nejpřesněji informovat o jeho objednávce resp. o změnách termínů dodání a učinit tak s co nejaktuálnějšími informacemi, aby nedocházelo k opakovanému upozorňování o změnách termínů. Lepší konečná informovanost je tedy pro zákazníka hlavním přínosem.
Závěr
42
10. Závěr Začátek práce seznamuje s technikami použitými při analýze a následné implementaci. Dále je provedena charakteristika firmy, krátké seznámení s její historií a analýza současného stavu. Webová aplikace byla vytvořena výhradně na základě analýzy reálných datových toků týkajících se logistiky ve firmě. Na základě provedené analýzy bylo vytvořeno schéma databáze v ERD a následně převedeno do datové podoby v databázi ORACLE. Aplikace tak pracuje s daty uvnitř této databáze. Velký důraz byl kladen na výslednou implementaci webové aplikace, kterou tvoří přes 30 skriptů. Pozadu však nezůstala ani estetická stránka aplikace, ta je realizována implementací HTML kódů uvnitř PHP skriptů a formátována pomocí CSS souboru. Vlastní realizace ve firemním prostředí by byla možná, ale kvůli rozmanitostem a chybějícím či nevyužitým vazbám mezi systémy, časově a implementačně náročná. PHP skripty by musely pracovat s daty z alespoň tří různých databází.
Literatura
43
11. Literatura SODOMKA, P. Informační systémy v podnikové praxi. 1. vyd. Brno: Computer Press, 2006. 351 s. ISBN 80-251-1200-4. LACKO, Ľ. Oracle: správa, programování a použití databázového systému. 1. vyd. Brno: Computer Press, 2002. 464 s. Rychle a jistě - databáze. ISBN 80-7226-699-3. BASL, J. BLAŽÍČEK, R. Podnikové informační systémy. 2. výrazně přeprac. a rozš. vydání. Grada, 2007 ISBN 978-80-247-2279-5. KOSEK, J. PHP - tvorba interaktivních internetových aplikací : podrobný průvodce. 1. vyd. Praha: Grada, 1999. 490 s. Průvodce. ISBN 80-7169-373-1. RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. Brno: Tribun CZ, 2008. 139 s. ISBN 978-80-7399-599-7. OPPEL, A. SQL bez předchozích znalostí. 1. vydání. Computer Press, 2008 ISBN: 978-80-251-1707-1 PROCHÁZKA, D. ORACLE Průvodce správou, využitím a programováním nad databázovým systémem. 1. vydání. Grada, 2009. ISBN: 978-80-247-2762-2 KREINES, D. Oracle DBA kapesní průvodce. 1. vydání. Grada, 2006. ISBN: 80247-1669-0 PORTUGAL, PAULO FERREIRA. The History of Oracle [online]. 8. dubna 2009. [cit. 2012-01-02]. Dostupné z WWW:
Oracle [online]. [cit. 2012-01-02]. Dostupné z WWW: FEI [online]. [cit. 2012-01-02]. Dostupné z WWW:
Přílohy
44
Přílohy
Přílohy
A
45
Ukázka alokace materiálu
Obr. 19 Ukázka alokace materiálu
Přílohy
B
46
Ukázka výpisu a zadávání objednávek
Obr. 20 Výpis a vkládání objednávky
Přílohy
C Výpis pracovních příkazů (Work Orders) a jejich obsahu
Obr. 21 Ukázka výpisu Work orderu
47
Přílohy
D Zkrácený výpis právě vyráběných produktů
Obr. 22 Zkráceny výpis vyráběných produktů
48
Přílohy
E Výpis a editace pracovního postupu (Flow)
Obr. 23 Pracovní postup pro FinalTest - standard
49
