ZADÁNÍ DIPLOMOVÉ PRÁCE

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

ZADÁNÍ DIPLOMOVÉ PRÁCE Student: Název:

Martin Veselý Vnitropodnikový informační systém

Pokyny pro zpracování: Analyzujte firemní procesy společnosti Asix s.r.o. Analyzujte stávající stav informačních systémů ve firmě, včetně účelnosti a použitelnosti dat, která obsahují, navrhněte optimální způsob jejich konverze. Navrhněte nový informační systém se zaměřením na efektivní používání systému uživatelem, vhodnou volbou datových struktur a realizací vhodného uživatelského rozhranní. Po dohodě se zadavatelem zrealizujte přiměřenou část vnitropodnikového informačního systému, v rozsahu odpovídajícím diplomové práci. Zbylá část bude realizována po skončení diplomové práce. Systém musí také řešit spolupráci se stávajícími specializovanými programy, nezbytnými pro obor činnosti firmy. Zaměřte se na podporu výroby, objednávání a nákup materiálu pro výrobu a evidenci skladu materiálu pro výrobu, mezivýrobků i hotových produktů.

i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Vnitropodnikový informační systém Martin Veselý

Vedoucí práce: Ing. Milan Vítek Magisterský studijní program: Elektrotechnika a informatika, strukturovaný Obor: Výpočetní technika - počítačové sítě a internet květen 2008

iii

iv

Poděkování Rád bych poděkoval mé rodině za podporu při studiu.

v

vi

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu § 60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 22. 5. 2008 …………………………………….

vii

viii

Abstrakt Tato práce popisuje analýzu a implementaci nového informačního systému pro firmu Asix s.r.o., včetně prvotní analýzy procesů ve firmě a stávajícího informačního systému, který bude novým systémem nahrazen. Nový systém se zaměřuje na podporu činností firmy, tedy na vývoj a výrobu elektronických zařízení a na podporu nákupů a prodeje.

Abstract Thesis describes analysis and implementation of the new information system for Asix s.r.o. company, including initial analysis of company processes and the original information system, which will be replaced by the new one. The new system focuses on support for company orientation, development and production of electronic devices, and for purchases and sales.

ix

x

Obsah 1

2

Úvod ...........................................................................................................................................1 1.1

Zadání .................................................................................................................................1

1.2

Úvod charakterizující kontext zadání ...................................................................................1

1.3

Popis řešeného problému ....................................................................................................1

1.4

Popis struktury práce ve vztahu k vytyčeným cílům..............................................................2

1.5

Rešeršní zpracování existujících implementací. ....................................................................3

Analýza .......................................................................................................................................5 2.1

Rozbor činností firmy ...........................................................................................................5

2.1.1

Výroba .........................................................................................................................5

2.1.2

Nákup zboží a materiálu ...............................................................................................7

2.1.3

Prodej výrobků a zboží .................................................................................................8

2.1.4

Vývoj ...........................................................................................................................8

2.2

Odborný článek ...................................................................................................................8

2.2.1

Výroba a nákup od dodavatelů.....................................................................................8

2.2.2

Prodej zákazníkovi ..................................................................................................... 10

2.3

Uživatelé ........................................................................................................................... 11

2.3.1

Vývojář ...................................................................................................................... 11

2.3.2

Pracovník výroby........................................................................................................ 13

2.3.3

Pracovník obchodu .................................................................................................... 14

2.3.4

Pracovník s přístupem k bankovnímu účtu ................................................................. 15

2.3.5

Pracovník pro komunikaci s dodavatelem .................................................................. 16

2.3.6

Manažer – kontrola nákladů....................................................................................... 17

2.4

Případy použití................................................................................................................... 18

2.5

Stávající informační systém................................................................................................ 23

2.6

Diskuze alternativ návrhu systému .................................................................................... 24

2.6.1

Volba implementačního prostředí .............................................................................. 24

2.6.2

Nákup a úprava některého systému vs. Návrh a výroba vlastního systému ................. 28 xi

2.7

3

Návrh podpory firemních procesů informačním ................................................................. 30

2.7.1

Podpora výroby ......................................................................................................... 30

2.7.2

Podpora nákupu zboží a materiálu ............................................................................. 30

2.7.3

Podpora prodeje ........................................................................................................ 31

2.7.4

Podpora vývoje .......................................................................................................... 31

2.7.5

Podpora vedení skladu ............................................................................................... 32

Návrh struktury systému ........................................................................................................... 33 3.1

Statická struktura a nasazení ............................................................................................. 34

3.2

Moduly systému ................................................................................................................ 35

3.3

Datový model .................................................................................................................... 36

4

Popis implementace systému .................................................................................................... 49

5

Výsledky testování. ................................................................................................................... 51

6

Zhodnocení splnění cílů práce ................................................................................................... 52

7

Závěr......................................................................................................................................... 53

8

Seznam obrázků ........................................................................................................................ 54

9

Seznam použité literatury ......................................................................................................... 55

10 Obsah přiloženého CD ............................................................................................................... 55 11 Přílohy ...................................................................................................................................... 56 11.1

Ukázky uživatelského rozhraní ........................................................................................... 56

11.2

Postup instalace ................................................................................................................ 59

11.2.1

Instalace serveru s databází ....................................................................................... 59

11.2.2

Instalace klienta na počítači uživatele ........................................................................ 60

xii

1 Úvod 1.1 Zadání Firma se zabývá především vývojem elektronických zařízení s jejich následnou výrobou a prodejem. V menší míře také nákupem a následným prodejem elektronických součástek. Pro vývoj se používají specializované návrhové systémy. Úkolem informačního systému (IS) bude především od nich přebírat a kontrolovat údaje, potřebné pro další činnosti. Výroba je řešena prakticky výhradně dodavatelsky (externími firmami), firma pouze zajišťuje materiál. Úkolem IS bude podporovat nákup materiálu, evidovat ho a sledovat jeho pohyb. Pro prodejní činnosti bude IS především opět evidovat výrobky a zboží, bude poskytovat podporu nákupu a prodeje včetně činností s tím spojených (evidence dodavatelů/odběratelů, objednávek, fakturace, atd.). Pro potřeby účetnictví bude používán externí program mimo IS.

1.2 Úvod charakterizující kontext zadání Firma vlastnila na počátku řešení vlastní informační systém, který se skládal z více navzájem propojených subsystémů. Jednotlivé subsystémy vznikaly postupně a většinou odděleně a byly teprve dodatečně propojovány. S měnícími se požadavky firmy v průběhu let však přestávaly stačit, což bylo většinou řešeno přidáním dalšího modulu, ale bez změny struktury ostatních modulů, čímž vznikaly duplicity dat, chyby při vzájemné výměně dat a další problémy. Proto bylo rozhodnuto o vytvoření nového systému zahrnujícího předchozí subsystémy s jejich restrukturalizací pro co nejlepší plnění současných požadavků firmy. Nový systém bude navíc plnit nové funkce, především podporu výroby a zlepšené obstarávání materiálu. Nový systém by ale neměl nahrazovat stávající používaný účetní systém. Ten by měl zůstat zachován a nový systém ho bude pouze doplňovat, především v podpoře výroby, správy nákupů materiálu a podpory obchodu všeobecně.

1.3 Popis řešeného problému První fází práce bude rozbor činností firmy a popis původního stavu ve firmě před započetím práce. Nejdůležitější na tomto popisu je rozbor činností jednotlivých pracovníků, jejich rozdělení do skupin podle vztahu k informačnímu systému firmy, popis, jak využívají stávající informační systém a popis jejich požadavků na nový systém.

1

Další částí je popis stávajícího informačního systému, jeho rozdělení do logických částí, hrubý popis obsažených dat. Důležitá data budou převedena do nového systému, s čímž bylo počítáno při jeho návrhu a jednou z částí práce je i návrh mechanizmů na jejich převedení do navrženého systému. Těžištěm této práce je pak vlastní návrh a implementace nového informačního systému dle zadání práce a požadavků zjištěných při analýze firemních procesů. Návrh se zabývá především vytvořením případů užití nového systému, rozdělením systému na jednotlivé funkční komponenty, návrhem datové struktury pro uložení všech potřebných dat a uživatelského rozhraní systému. Poslední fází práce je vlastní implementace přiměřeně velké části systému vzhledem k rozsahu diplomové práce, její otestování a nasazení do provozu.

1.4 Popis struktury práce ve vztahu k vytyčeným cílům. Při zahájení práce na projektu byl stanoven postup pro jeho realizaci: 1. rozbor činností firmy, stávajících firemních procesů 2. návrh podpory firemních procesů informačním systémem a návrh zlepšení firemních procesů pomocí nového informačního systému 3. návrh struktury systému, datového modelu 4. implementace systému 5. import stávajících dat do systému 6. testování systému 7. nasazení systému do provozu Ve firmě byl již delší dobu nasazen systém pro podporu prodeje. Ten byl ale vytvořen v rané fázi po vzniku firmy a požadavkům firmy již delší dobu nedostačoval. Neobsahoval navíc podporu výroby. Ta byla řešena pomocí strukturovaných textových souborů. Prvotní rozbory se tedy zaměřily především na tyto již používané systémy. Během rozboru byl nový systém diskutován s jednotlivými pracovníky, bylo zjišťováno, co si od nového systému představují a jaké funkce od něj očekávají. Během těchto diskuzí bylo vytvořeno mnoho diagramů – některé pouze zhruba načrtnuté na papíru, jiné byly vytvořeny podle normy UML. Dále byla vytvořena struktura celého systému a to především datový model a rozdělení systému na jednotlivé komponenty podle využití jednotlivými uživateli.

2

Vlastní implementace byla prováděna nejprve do šířky, kdy byly jednotlivé části implementovány pouze zhruba v míře nutné pro komunikaci s ostatními částmi a pak teprve byly jednotlivé části postupně implementovány do hloubky a testovány. Import stávajících dat byl proveden poměrně záhy po vytvoření struktury databáze a pro tento účel byl vytvořen zvláštní modul. To usnadnilo testování systému již od samého začátku, a také umožnilo uživatelům ukázat co nejdříve podobu nového systému s existujícími daty pro lepší představu. Import výrobních dat byl proveden ze strukturovaných textových souborů, import obchodních partnerů a obchodních dokumentů pak ze starého obchodního systému napsaného v aplikaci Access. Modul importu byl pak udržován po celou dobu vývoje systému kvůli zachování alespoň částečné zpětné kompatibility s původními zdroji dat.

1.5 Rešeršní zpracování existujících implementací. Před započetím práce jsem provedl rozbor komerčního řešení podobného systému: Aplikace „SAP Business One“ [5] od společnosti SAP [1]. S tímto systémem jsem přišel do kontaktu při předchozím zaměstnání a díky tomu jsem měl k dispozici kompletní technickou dokumentaci k tomuto systému, včetně databázového schématu a popisu funkce jednotlivých modulů. Tento systém ale bohužel nenabízí všechny funkce, které byly od systému zadavatelem očekávány. Zejména pak modul výroby je velmi nedostatečný a i modul objednávek neobsahuje všechny potřebné a vyžadované funkce. Prvky systému, které jsou stejné s aplikací „SAP Business One“: 

Políčka faktur – informační systém obsahuje téměř všechny políčka faktur systému SAP Business One a přidává některá další.



Řetězení navazujících dokumentů – při vytváření faktury z již dříve vytvořené objednávky dojde k navázání obou dokumentů pro jejich snadnou správu.



Obchodní partneři, adresy a jejich formáty – ze systému SAP Business One bylo téměř kompletně převzato evidování údajů o obchodních partnerech. Zvláště pak informace o adresách, neboť ty mohou být v různých formátech v závislosti na zemi původu. Rozdíly oproti existujícím systémům:



Požadavky – pro co nejsnadnější práci při objednávání zboží a materiálu byly zavedeny takzvané „Požadavky“. Jedná se o vytvoření záznamu o tom, že daný materiál je požadován objednat a dodat. Z požadavku pak například může vzniknout více poptávek u dodavatelů. Bez informace o tom, že všechny poptávky pocházejí z jednoho požadavku, by nebylo možno 3

je spojit a mohlo by docházet k vícenásobným objednáním stejného materiálu u více dodavatelů. 

Výroba – při výrobě byla požadována poměrně rozsáhlá podpora evidence materiálu a požadavků na chybějící materiál, kterou nenabízel žádný z nalezených komerčních systémů. Velmi podobně vyšlo srovnání i s dalšími systémy, které už ale bylo prováděno méně do

hloubky, neboť k těmto systémům již nebylo možno sehnat technickou dokumentaci (datové struktury, vnitřní dělení modulů). Systém TD-IS s.r.o. – EasyTechnology má velmi dobrou podporu výroby a výrobních postupů, ale nedostatečnou podporu obstarávání materiálu a funkce jednotlivých modulů neumožňuje podporu stávajících firemních procesů. Systémy dalších firem určené pro řízení výroby, jako jsou systémy od K2 amitec s.r.o. nebo LCS International, a.s. – Helios Orange, jsou většinou nad rámec možností firmy jak finančně, tak i velmi obtížným nasazením pro podporu stávajících firemních procesů.

4

2 Analýza Analýza se zabývá rozborem činností firmy a stávajících firemních procesů, diskusí různých alternativ řešení a volbou implementačního prostředí.

2.1 Rozbor činností firmy Firma se zabývá především těmito činnostmi: 

Prodej vlastních výrobků, které byly vyvinuty firmou a prodávají se pod značkou firmy



Výroba vlastních výrobků



Návrh nových vlastních výrobků



Zakázkový vývoj elektronických zařízení



Zakázková výroba vyvinutých zařízení



Prodej zboží (především elektronických součástek) od dodavatelů

Tedy zjednodušeně: 

Výroba



Nákup zboží a materiálu



Prodej výrobků a zboží



Vývoj Pro jednotlivé činnosti byl proveden rozbor možného využití informačního systému pro jejich

podporu. 2.1.1

Výroba

Při výrobě se vždy provádějí následující činnosti: 1. Obstarání potřebného materiálu pro výrobu. a. Pracovník zkontroluje, jaký materiál má skladem. b. Materiál, který je na skladě, přesune do výroby. c. Materiál, který není skladem, objedná, případně nejdříve poptá u více dodavatelů a pak objedná. d. Výroba čeká na dodání materiálů. Pracovník kontroluje, zda již byl dodán. e. V případě zdržení dodávky pracovník kontaktuje dodavatele a zjišťuje příčinu, případně zajišťuje náhradu.

5

2. Výroba a. Výroba probíhá podle výrobního postupu, který byl vypracován při vývoji. 3. Ukončení výroby a. Po dokončení výroby je hotový výrobek odeslán zákazníkovi nebo převeden na sklad. Koncový výrobek se přitom skládá téměř vždy z různých komponent (mezivýrobků), které je také třeba vyrobit. Při výrobě se pak postupuje tak, že se vyrobí jednotlivé komponenty, ty se pak složí a vyrobí se z nich koncový výrobek. Často se stává, že i komponenta se skládá z dalších komponent. Vzniká tak výrobní strom výrobku, kde listy jsou součástky kupované od dodavatelů a jednotlivé uzly jsou komponenty (mezivýrobky). Jedna komponenta může být navíc obsažena v různých koncových výrobcích. Jedná se tedy o obecný orientovaný acyklický graf.

X

Y

X se vyrábí z Y Koncový

výrobek

(prodejní) Komponenta (mezivýrobek)

Součástka (materiál)

Obrázek 1: Výrobní strom

6

2.1.2

Nákup zboží a materiálu Kvůli účetnictví se rozlišuje nákup zboží, které bude dále prodáváno a nákup materiálu pro

výrobu. Toto rozlišení je třeba provést již při nákupu. Některé zboží se vede skladem, jiné se nakupuje až při objednávce od zákazníka a při dodání je odesláno zákazníkovi. Nákup se provádí v těchto situacích: 

zboží na skladu došlo, nebo je ho na skladě již málo,



zákazník objednal zboží, které není vedeno skladem (při doručení je zboží přímo odesláno zákazníkovi),



je třeba objednat materiál pro výrobu. Součástky je většinou možno objednat u více než jednoho dodavatele. Jednotliví dodavatelé se

liší jak cenou, tak i dodacími podmínkami (doba dodání, poštovné). Ceny jednotlivých součástek se u jednotlivých dodavatelů často mění a závisí také na objednávaném množství. Z těchto důvodů se většinou před objednáním provádí poptání jednotlivých součástek u více dodavatelů a teprve podle nabídek se součástka objedná u dodavatele s nejlepšími podmínkami. Jednotliví dodavatelé mají často pro stejnou součástku rozdílné objednací značení. Při vytvoření poptávky nebo objednávky je tedy nutno ještě doplnit správné objednací značení pro jednotlivé položky z databáze objednacích značení pro daného dodavatele. Objednávky od zahraničních dodavatelů, kde poštovné může činit i převážnou část celkové ceny, se musí dělat teprve až při větším objednávaném množství nebo pro co nejvíce položek najednou. Proto je nutno požadavky vzniklé z výše vyjmenovaných situací uchovávat a vlastní objednávku odeslat až při nahromadění více položek. Při příchodu faktury za dodané zboží je nutné tyto zaplatit, většinou pomocí vytvoření příkazu k úhradě v bance nebo pomocí kreditní karty.

7

2.1.3

Prodej výrobků a zboží Prodávají se jak výrobky, tak i zboží kupované od dodavatelů. Některé často prodávané druhy

zboží se vedou skladem, jiné se objednávají u dodavatele až při příchodu objednávky od zákazníka. Při příchodu poptávky na zboží od zákazníka pracovník zkontroluje, zda je zboží skladem. V případě, že zboží skladem je, nebo pracovník zná dodací lhůtu dodavatele, odpoví zákazníkovi rovnou dodací podmínky a cenu zboží. Pokud zboží není skladem a pracovník nezná dodací podmínky dodavatele, odešle dodavateli poptávku, počká na její zodpovězení, a pak odpoví zákazníkovi. Při příchodu objednávky pracovník zkontroluje, zda je zboží skladem, a případně zboží pro zákazníka objedná. Při příchodu zboží ho pracovník odešle zákazníkovi. 2.1.4

Vývoj Vývoj elektronických zařízení spočívá především ve tvorbě schémat, kreslení desek plošných

spojů, kreslení technických výkresů jednotlivých mechanických součástek, programování firmware zařízení a programování software pro počítač pro komunikaci se zařízením a jeho obsluhu. Při tvorbě schémat a plošných spojů se používá databáze součástek. Tato databáze obsahuje informace o jednotlivých součástkách používaných ve firmě. Eviduje se typ pouzdra, schematická značka a popis součástky. Při vývoji se používá více různých specializovaných programů pro různé účely: 

tvorbu schémat



tvorbu desek plošných spojů



kreslení technických výkresů



tvorbu 3D modelů a dat pro NC frézy Každý z těchto programů poskytuje výstupy v jiném formátu, které se pak využívají při výrobě.

Některé navíc využívají databázi součástek, ze které čerpají informace.

2.2 Odborný článek 2.2.1

Výroba a nákup od dodavatelů Vývojář vyvine nové zařízení a do systému zadá nový postup výroby a materiálový list výrobku. Pracovník výroby z materiálového listu vytvoří nový výrobní proces. Výrobní proces má

uloženo, ze kterého materiálového listu vzniknul a může tedy zobrazit počet potřebných součástek (pokud se změní původní výrobní postup, bude proces zobrazovat nová množství součástek).

8

Do procesu je možno ze skladu převádět součástky. Proces obsahuje informaci o počtu součástek do procesu převedených. Pro součástky v procesu, které nejsou na skladě, umožňuje proces vytvořit požadavky na objednání součástky. Proces ví, které požadavky z něj vznikly a může tedy zobrazovat i počet poptaných a objednaných součástek (podle poptávek a objednávek, které z požadavku vznikly). Požadavek si zobrazí pracovník pro komunikaci s dodavatelem, označí součástky, které chce poptat/objednat a vytvoří z nich poptávku, objednávku, nebo přímo vloží do systému odpověď dodavatele – nabídku. Po vytvoření poptávky se poptávka odešle e-mailem dodavateli. Při příchodu nabídky (odpovědi na poptávku) do firmy si uživatel najde původní poptávku a vytvoří z ní nabídku nebo rovnou objednávku. Do ní vyplní údaje z nabídky (ceny, množství, dodací lhůty). Při vytvoření nabídky dojde ke změně stavu požadavku na zodpovězený a uživateli, který požadavek zadal, se odešle upozornění na vyřízení poptávky. Z uložené nabídky pak může uživatel později vytvořit objednávku. Na objednávku může dodavatel zareagovat zasláním Zálohové faktury (požaduje zaslání zálohy předem). Uživatel si najde objednávku, na kterou dodavatel takto reaguje a z ní vytvoří v systému Zálohovou fakturu. Vůči ní je pak možno vytvořit v systému platbu a tím fakturu označit jako zaplacenou. Pokud přijde zboží dříve než faktura, zadá se v objednávce došlé množství. Dále přijde od dodavatele faktura nebo paragon. Uživatel si najde objednávku a z ní vytvoří fakturu/paragon (dále jen faktura). Systém umožní vytváření i částečných faktur – pokud je fakturované množství nižší než objednané, objednávka nebude označena jako vyřízená, budou na ní zobrazeny ale již jen ještě nedodané položky. Pokud byla z objednávky vytvořena dříve zálohová faktura, která je označena jako zaplacená, vyplní se na faktuře automaticky příslušná částka do kolonky Placeno předem. Vůči faktuře je pak možno vytvořit platbu a tím fakturu označit jako zaplacenou. Při dodání zboží rovnou dojde k označení požadavku, ze kterého na počátku vznikla objednávka, jako vyřízený, pokud dodané množství souhlasí s požadavkem nebo je větší než na požadavku. Pokud požadavek obsahuje větší množství, než je objednáno, sníží se požadované 9

množství na požadavku a požadavek se označí jako nevyřízený, pokud uživatel neoznačí při vytváření nabídky požadavek manuálně za splněný. 2.2.2

Prodej zákazníkovi Zákazník vstoupí do kontaktu s firmou zasláním poptávky nebo objednávky. Při příchodu poptávky má systém podporu pro práci s poptávkou. V případě, že uživatel nechce

tuto podporu využít, může se zákazníkem komunikovat přímo a do systému zadat až objednávku nebo přímo fakturu. Při příchodu poptávky, pro kterou uživatel již ví odpověď, může uživatel v systému vytvořit přímo nabídku zákazníkovi. V opačném případě uživatel do systému zadá poptávku. Pokud není známa cena pro poptávané zboží, protože je ho nutné nejdříve poptat u dodavatele, označí uživatel dané položky na poptávce zákazníka a vytvoří z nich poptávku pro dodavatele. Pokud je nutné jednotlivé položky poptat u více dodavatelů, vytvoří postupně uživatel více poptávek pro jednotlivé dodavatele. Poptávka od zákazníka se tímto označí stavem čekající. Při příchodu nabídky od dodavatele zadá uživatel nabídku do systému tak, že najde uloženou poptávku pro dodavatele, vyplní ceny a vytvoří nabídku. Při uložení systém zjistí, že poptávka pro dodavatele vznikla na základě poptávky od zákazníka, označí původní poptávku od zákazníka jako nevyřízenou a vyzve uživatele, aby na zákazníkovu poptávku odpověděl. Uživatel přejde na zákazníkovu poptávku a zvolí vytvoření nabídky zákazníkovi z došlých nabídek dodavatelů. Systém automaticky z vyplněných nabídek dodavatelů vyplní v odpovědi cenu a množství, uživatel vyplní v nabídce cenu a množství pro ostatní položky, které nebyly poptávány a nabídku odešle zákazníkovi (prostřednictvím vygenerovaného emailu). Při příchodu objednávky od zákazníka uživatel najde nabídku odeslanou zákazníkovi v systému a z ní vytvoří objednávku nebo přímo fakturu zákazníkovi. V případě, že nabídka pro zákazníka není v systému (například proto, že zákazník zboží přímo objednává bez poptání), vytvoří uživatel přímo objednávku nebo rovnou fakturu (nebo paragon) zákazníkovi. Pokud je od zákazníka požadováno zaplacení zálohy předem, vytvoří uživatel místo fakturydaňového dokladu pouze Zálohovou fakturu, a to stejným postupem, jako se vytváří faktura obyčejná. Při příchodu platby od zákazníka uživatel do systému zadá platbu (případně se platba v systému automaticky objeví po importu dat z banky). Platba se spáruje s Fakturou nebo se Zálohovou fakturou. Ta se tímto označí jako zaplacená. Ze zálohové faktury je pak možno vytvořit konečnou fakturu, která se automaticky označí jako zaplacená. 10

V případě, že zákazník fakturu nezaplatí, nebo zaplatí jen její část, je možné fakturu stornovat. Tím se faktura označí jako uzavřená. Systém dále umožňuje vytváření Celních pro-forma faktur a Dodacích listů. Ty jsou vytvářeny samostatně bez návaznosti na ostatní dokumenty.

2.3 Uživatelé V následujících kapitolách jsou postupně vyjmenováni všichni prototypoví uživatelé systému a jsou popsány činnosti, které daný uživatel ve firmě vykonává se zaměřením na činnosti, ke kterým uživatel využívá informační systém firmy. 2.3.1 

Vývojář Stará se o návrh nových zařízení. K tomu využívá seznamy součástek používaných ve firmě a informace o nich. Výstupem vývoje při jeho ukončení je výrobní postup pro výrobu zařízení a jeho jednotlivých komponent.



Vývojář do systému zadává data potřebná pro výrobu zařízení, především nové součástky a informace o nich, materiálové listy.



Vývojář musí u nových součástek, které ještě nebyly použity v jiném zařízení, zadat objednací kódy pro objednání od dodavatele. Tuto činnost musí provést pracovník vývoje, neboť pouze on má odborné znalosti potřebné k nalezení součástky v katalogu dodavatele, protože značení součástky se u jednotlivých dodavatelů liší.

11

Systém Návrh zařízení

Editace výrobního postupu

Vývojář Přidání nové součástky

Změna objednacích značení součástky

Obrázek 2: Diagram užití - Vývojář

12

2.3.2 

Pracovník výroby Pracovník výroby musí vždy před vlastním zahájením výroby obstarat veškerý potřebný materiál, tedy objednat materiál, který není skladem. Dále pak postupuje podle výrobních postupů. Po dokončení výroby převede výrobky na sklad.

Systém Vytvoření výrobního procesu Zjištění postupu výroby

Přesun součástek ze skladu

Pracovník výroby Vytvoření požadavku na objednání

Vytvoření objednávky

Ukončení výrobního postupu

Obrázek 3: Diagram užití - Pracovník výroby

13

2.3.3

Pracovník obchodu



Stará se především o prodej výrobků a zboží a příjem nakoupeného zboží.



Dále se stará o platby za nakoupený materiál a příchozí platby za prodané zboží.



Součástí obchodu je i sklad zboží a hotových výrobků. Pracovník pravidelně kontroluje množství zboží a výrobků na skladu a v případě, že je některého zboží málo vzhledem k jeho prodejnosti, objedná u výrobního oddělení výrobu výrobku nebo zadá požadavek na objednání zboží od dodavatele.

Systém

Zadávání přijatých faktur

Vystavování faktur a paragonů

Pracovník obchodu

Poslání zboží zákazníkovi

Kontrola skladu

Zákazník

Vytvoření požadavku na objednání

Obrázek 4: Diagram užití - Pracovník obchodu

14

2.3.4

Pracovník s přístupem k bankovnímu účtu



Pracovník kontroluje přijaté platby od zákazníků a označuje vydané faktury jako zaplacené



Platí přijaté faktury za nakoupený materiál a zboží.



Přístup k bankovnímu účtu firmy je velmi omezen pouze na několik pracovníků firmy. Ostatní pracovníci nemají k účtu přístup, tedy nemohou odesílat peníze a platit tak přijaté faktury ani nemohou kontrolovat přijaté platby od zákazníků.

Systém

Kontrola plateb od zákazníků

Placení přijatých faktur Pracovník s přístupem k bankovnímu účtu

Obrázek 5: Diagram užití - Pracovník s přístupem k bankovnímu účtu

15

2.3.5 

Pracovník pro komunikaci s dodavatelem Pracovník má přiděleného určitého dodavatele a stará se o komunikaci s ním. Ne všichni dodavatelé jsou rozděleni mezi pracovníky pro komunikaci s dodavatelem. Jedná se jen o největší dodavatele, u kterých se objednává často, nebo o zahraniční dodavatele. U ostatních dodavatelů objednávají ostatní pracovníci (pracovník výroby nebo administrativní pracovník obchodu) přímo. Důvod zřízení pracovníka pro komunikaci s dodavatelem je nutnost slučovat co nejvíce položek objednávky do jedné objednávky z důvodu poplatků za poštovné. Dalším důvodem může být například nutná znalost cizího jazyka pro komunikaci, kterou nemají ostatní pracovníci výroby a obchodu.

Systém

Zpracování požadavku na objednání

Vytvoření objednávky

Odeslání objednávky dodavateli Pracovník pro komunikaci s dodavatelem

Zadání přijaté faktury

Zadání dodání součástek Dodavatel

Obrázek 6: Diagram užití - Pracovník pro komunikaci s dodavatelem

16

2.3.6 

Manažer – kontrola nákladů Úkolem managementu je především kontrola a řízení peněžních toků ve firmě. K tomu je nutné mít informace o nákladech na výrobu pro stanovení ceny výrobků, nákladech spojených s vývojem nových zařízení a kontrolu prodejnosti jednotlivých výrobků a zboží.



Pro kontrolu nákladů na vývoj je nutné u příchozích faktur spojených s vývojem tyto spojit s jednotlivými vývojovými projekty.



Pro kontrolu nákladů na výrobu je nutno příchozí faktury za materiál spojit s konkrétními výrobními procesy.

Systém

Kontrola nákladů na výrobu

Kontrola nákladů na vývoj

Manažer Statistika prodejů

Obrázek 7: Diagram užití - Manažer

17

2.4 Případy použití Založení výrobního procesu 

Výběr, který výrobní postup se bude realizovat – Podpora ANO



Zadání, kolik se bude vyrábět výrobků (počet) – Podpora ANO



Kontrola množství materiálu na skladu proti požadovanému množství – Podpora ANO



Vytvoření požadavku na objednání nedostatkového materiálu, případně přímo jeho objednání – Podpora ANO



Tisk seznamů součástek potřebných pro výrobu, štítků součástek – Podpora ANO



Vyhledání součástky ve skladu, odebrání ze skladu a převedení do výrobního procesu v množství potřebném pro výrobu – Podpora ANO



Převedení materiálu do procesu přímo zakoupeného, jeho fakturace – Podpora ANO



Kontrola, zda jsou všechny součástky připraveny – všechen materiál pro výrobu je dostupný – Podpora ANO



Poskytnutí výrobních podkladů a jejich vytištění – Podpora omezeně (odkaz na adresář, soubor)



Práce na zařízení – Podpora pro sledování postupu práce NE

Ukončení výrobního procesu 

Uložení hotových výrobků na sklad – Podpora ANO



Aktualizace počtu zbylých součástek – Podpora ANO



Přesun zbylých součástek zpět do skladu – Podpora ANO



Přesun součástek do jiného výrobního postupu – Podpora ANO

Vytvoření požadavku na poptání/objednání 

Nalezení objednávané/poptávané součástky v systému – Podpora ANO



Zadání požadavku – Podpora ANO



Rozřazování požadavků Pracovníkům pro komunikaci s dodavatelem, editace rozřazování – Podpora NE



Zobrazení požadavků Pracovníkem pro komunikaci s dodavatelem podle jednotlivých dodavatelů – Podpora ANO



Výpis objednávek/poptávek s prošlým datem očekávaného dodání – Podpora ANO



Oznámení o doručení dodávky/doručení odpovědi poptávajícímu – Podpora ANO

18

Vytvoření poptávky/objednávky z požadavků 

Vytvoření poptávky/objednávky z více požadavků najednou – Podpora ANO



Změna stavu požadavku, aktualizace data dodání – Podpora ANO



Při doručení odpovědi a poptávku vyplnění nabídky – cen, počtu kusů, značení – Podpora ANO

Dodání objednaného zboží, příchod faktury 

Možnost vytvoření faktury z objednávky – Podpora ANO



Možnost vytvoření zálohové faktury z objednávky – Podpora ANO



Dodání zboží (i bez přiložené faktury), záznam o dodaném zboží do systému – Podpora ANO



Při dodání faktury vytvoření faktury v systému, vyplnění dodaného množství, cen, značení, celkové ceny s DPH a bez DPH – Podpora ANO



Převedení součástek na sklad, do výrobního procesu nebo do projektu – Podpora ANO



Export dat z faktury v systému pro účetnictví – Podpora ANO

19

Vytvořit požadavek

Poptání u 1. firmy

Poptání u 2. firmy

Nabídka od 1. firmy

Nabídka od 2. firmy

Objednávka od levnější firmy

Dodání zboží

Dodání faktury

Uzavřít požadavek

Zaplacení faktury

Uzavřít objednávku

Uzavření faktury

Obrázek 8: Stavový diagram - Nákup zboží

20

Pracovník výroby

Modul požadavků

Pracovník pro komunikaci s dodavatelem

Modul dokumentů

Dodavatel

Vytvoření požadavku Přečtení požadavku Vytvoření poptávky Poslání poptávky

Nabídka

Vytvoření objednávky Poslání objednávky

Dodání zboží

Vytvoření faktury

Uzavření požadavku Informace o dodání

Obrázek 9: Diagram komunikace - Nákup zboží

Prodej zboží 

Při příchodu objednávky její zadání do systému – Podpora ANO



Výpis nevyřízených objednávek v systému – Podpora ANO



Vytvoření faktury (obsahuje údaje o odběrateli) nebo paragonu, možnost vytvoření faktury/paragonu z objednávky – Podpora ANO



Vyplnění údajů o odběrateli ze systému, pokud je již v systému zaveden – Podpora ANO



Aktualizace údajů o odběrateli (adresa, kontaktní osoba), případně zavedení odběratele do systému, pokud v systému ještě není – Podpora ANO



Tisk faktury – Podpora ANO



Evidence faktur: elektronicky se budou ukládat vytištěné faktury pro jejich opětovné vytištění ve formě PDF dokumentů – Podpora ANO

21

Přesun položek 

Přesuny položek je možno provádět mezi skladem, výrobním procesem a vývojovým projektem – Podpora ANO



Přesun více typů položek najednou (například všechny zbylé položky při skončení výroby) – Podpora ANO

Výpis skladových operací 

Výpis všech operací pro jednotlivé součástky za určité období – Podpora ANO



Ve výpisu budou následující typy položek: o

Vložení součástek na sklad při dodání dodavatelem – výpis bude obsahovat odkaz na fakturu

o

Přesun věci do výrobního procesu, projektu či zpět na sklad, pokud výrobní proces nespotřebuje všechny součástky.

o

Vložení vyrobené součástky na sklad po ukončení výrobního procesu.

o

Spotřebování věci výrobním procesem při výrobě s datem ukončení výrobního procesu

o

Spotřebování věci ve vývojovém projektu.

o

Prodejem věci – výpis bude obsahovat odkaz na vydanou fakturu nebo paragon

o

Inventurní položky – zvýšení/ snížení počtu položek na skladu tak, aby odpovídalo skutečnému stavu



U každé položky ve výpisu bude uvedeno: o

Datum

o

Množství

o

Kdo tuto operaci provedl

o

Při přesunu věci odkud a kam

o

U některých výše uvedených položek odkaz na fakturu nebo paragon (číslo faktury)

o

Cenu věci podle faktury s DPH a bez DPH se započítáním nákladů na dopravu, pokud již byla od té doby provedena inventura



Výpis bude obsahovat počet položek na skladu na začátku a na konci období, pro které je výpis určen. U položek, které budou mít provedenu inventuru, bude uvedena i celková cena položek na skladu podle nákupní faktury se započtením nákladů na dopravu

Sklad 

Přesun zboží mezi jednotlivými sklady – Podpora ANO



Inventura skladové položky – Podpora ANO

22

Bankovní modul 

Import dat z banky o pohybech na účtu – Podpora ANO



Zadávání nových příkazů k úhradě vůči příchozí faktuře – Podpora ANO



Přiřazování firem a faktur k pohybům na účtu – Podpora ANO, pokud možno automaticky



Označování přiřazených faktur jako zaplacené – Podpora ANO

2.5 Stávající informační systém Starý systém pro vydávání faktur a podporu prodeje, který je ve firmě nasazen již přibližně 10 let, byl napsán v prostředí Microsoft Access. Z toho vyplývají některá omezení například pro maximální počet řádků v tabulce.

Tento systém již delší dobu nevyhovoval nárokům na něj

kladeným. Podpora výroby byla řešena pomocí strukturovaných textových souborů. Ty obsahovaly nejen seznam všech součástek používaných ve firmě a technických informací o nich, ale především materiálové listy ke každému výrobku a ke všem meziproduktům výroby. Dále pak již v nestrukturalizované formě jsou popsány vlastní výrobní postupy a to buď ve formě textu, obrázků či jiných technických dat pro specializované programy. Schéma starého systému je na následujícím obrázku:

File server

Database server

Výrobní data v textových souborech

-End2

Obchodní data

1..1

1..1

-End3

Klientský počítač 0..*

-End1

Textový editor 0..*

Obchodní aplikace

-End4

Obrázek 10: Struktura původního systému

23

2.6 Diskuze alternativ návrhu systému Při návrhu systému bylo diskutováno několik variant, přičemž nejvíce diskutované byly následující možnosti:

Tenký klient (Webová aplikace)

Vs.

Nákup a úprava některého z prodávaných řešení 2.6.1

Tlustý klient (Aplikace běžící na počítači klienta)

Vs. Návrh a výroba vlastního systému

Volba implementačního prostředí Dalším rozhodnutím na počátku práce byla volba implementačního prostředí, přičemž hlavní

otázkou bylo, zda bude aplikace implementována jako webová aplikace (tenký klient), nebo standardní aplikace (tlustý klient). Ve firmě byla pro webovou aplikaci velká podpora, proto bylo v rámci úvodní studie zpracováno poměrně rozsáhlé porovnání obou typů řešení, které je uvedeno v této kapitole. V klasických aplikacích typu klient-server má každá aplikace svůj vlastní klientský program, který slouží jako její uživatelské rozhraní a musí být instalován na osobním počítači každého uživatele. Webová aplikace je aplikace poskytovaná uživatelům z webového serveru přes počítačovou síť Internet, nebo její vnitropodnikovou obdobu (intranet), prostřednictvím internetových stránek. Webové aplikace jsou populární především pro všudypřítomnost webového prohlížeče jako klienta. Ten se pak nazývá tenkým klientem, neboť sám o sobě logiku aplikace nezná. V následující části je srovnání obou typů aplikací s uvedením předností a nedostatků obou dvou typů řešení. Srovnání je rozděleno na části, kde každá popisuje jeden z rozdílů obou řešení. Aktuálnost Webové aplikace Schopnost

Klasické aplikace aktualizovat

a

spravovat

Aktuálnost klasické aplikace je zajištěna

webové aplikace bez nutnosti šířit a instalovat

pomocí updatů. Aplikace typicky po startu

software na potenciálně tisíce uživatelských

zkontroluje aktuálnost, a pokud je na serveru

počítačů je hlavním důvodem jejich oblíbenosti.

novější verze, aktualizuje se.

24

Webová aplikace běží na serveru, na

Aktualizace

může

být

dobrovolná

klientské straně je pouze internetový prohlížeč,

(uživatel se může rozhodnout, zda chce aplikaci

zodpovědný za zobrazení stránek – prezentaci

aktualizovat nebo nikoli), nebo vynucená

aplikace.

(aktualizace

Aktualizace aplikace na serveru se tedy okamžitě projeví. Pokud aktualizace mění některou

stránku,

kterou

právě

dostupná,

se

provede

uživatel

do

vždy,

pokud

procesu

je

nemůže

zasáhnout).

uživatel

Pokud dojde k aktualizaci serverové části

používá, může to způsobit jednorázovou chybu

aplikace (databáze, služby), může to způsobit

(nemožnost odeslání dat, nemožnost provedení

nefunkčnost klientské části aplikace zasažené

určité funkce). Po znovunačtení stránky již vše

aktualizací a to až do doby aktualizace (klientská

bude fungovat.

aplikace je znovu spuštěna, nebo provede aktualizaci na žádost uživatele).

Dostupnost Podstatnou výhodou vývoje webových aplikací stavějících na standardních funkcích prohlížeče je jejich schopnost pracovat podle určení bez ohledu na operační systém či jeho verzi instalovanou na daném klientském počítači. Místo psaní variant aplikace pro Windows, Linux, Mac OS X a další operační systémy stačí teoreticky aplikaci napsat jednou a nabídnout téměř kdekoliv. V praxi ale nekonzistentní implementace HTML, CSS, DOM a další specifikace jednotlivých prohlížečů způsobují problémy. Navíc mají uživatelé možnost nastavit způsob zobrazení ve svém prohlížeči (např. zvolit jiný řez či velikost písma, barvy či vypnout podporu skriptování), což může rušit jednotný vzhled aplikace. Oprávnění Webové aplikace

Klasické aplikace

Webové aplikace mají jen omezená oprávnění

Mohou přistupovat k souborům na lokálním

pro práci s prostředky počítače. Nemohou

disku, používat periferie. Jejich oprávnění závisí

přistupovat k datům na lokálním disku počítače

na

(lze pouze vyvolat dialog pro uložení/načtení

uživatele.

jednoho souboru), komunikovat s programy na počítači uživatele, komunikovat s periferiemi počítače (čtečky čárových kódů, klávesové zkratky, reakce aplikace na stisk klávesy)

25

nastavených

oprávnění

přihlášeného

Struktura Webové aplikace

Klasické aplikace

Jsou obvykle strukturovány jako třívrstvé.

Jsou klasicky dvouvrstvé nebo třívrstvé.

V té nejběžnější formě je webový prohlížeč

První vrstvou je vždy aplikace spuštěná na

první

pro

straně klienta a starající se o komunikaci

dynamické generování stránek (např. CGI, PHP,

s uživatelem. Tato vrstva pak komunikuje buď

javové servlety nebo ASP.NET) jsou vrstvou

přímo s databází, nebo s webovou službou,

střední (logickou) a databáze (SQL) je vrstvou

která obsahuje část logiky aplikace a stará se

třetí

posílá

také o bližší kontrolu oprávněnosti požadavků.

požadavky střední vrstvě, která je obsluhuje

Výhodou vložení střední vrstvy je tak jednak

prostřednictvím dotazů do databáze (resp. její

větší bezpečnost, za druhé pak možnost

aktualizací)

aktualizovat část logiky aplikace (webovou

vrstvou

(datovou).

rozhraní.

a

(prezentační),

Webový

nástroje

prohlížeč

generováním

uživatelského

službu), bez nutnosti aktualizací klientských aplikací (ty mohou běžet bez přerušení a o aktualizaci se ani nemusí dozvědět, pokud aktualizace nezmění komunikační interface).

26

User

User

Web Browser

User

Client Application

Client Application

Server HTTP, HTML

WEB Server

HTTP, SOAP

WEB Service

SQL

SQL Server

Uživatelské rozhraní Webové rozhraní v některých směrech omezuje funkčnost a možnosti klienta. Metody známé z desktopových aplikací, jako je například vykreslování na obrazovku či obecné techniky jako drag and drop, používání k ovládání klávesnice nebo klávesových zkratek, jsou velmi omezené nebo nejsou standardními technologiemi prohlížečů podporovány vůbec. Prvky pro komunikaci s uživatelem jsou limitovány na prvky implementované ve webových prohlížečích (textové pole, check box, radio buton, tlačítko). Tvůrci webů pro přidání funkčnosti nebo interaktivních prvků (vysouvací menu) často používají skriptování na straně klienta, zvláště pro vytvoření dojmu interaktivity bez nutnosti znovunačtení stránky, které řada uživatelů shledává rušivým. Používání skriptů ale naráží na různou implementaci v jednotlivých prohlížečích. To způsobuje problémy a často nutnost vytvořit různé verze skriptů pro jednotlivé webové prohlížeče či dokonce jejich verze.

27

Vývoj Webové aplikace Programování

Klasické aplikace webových

aplikací

Klasická

aplikace

musí

mít

komplikuje fakt, že protokol je bezestavový –

implementovány automatické aktualizace, musí

není možno si mezi jednotlivými požadavky

obsahovat uživatelsky přívětivou instalaci.

uchovávat informace v paměti. To dělá návrh a programování aplikace složitějším. Aplikace se v podstatě při každém požadavku znovu spustí, zkontroluje oprávnění uživatele, zpracuje jím vyplněná data a pošle mu k zobrazení novou stránku.

Po zvážení obou variant bylo rozhodnuto pro implementaci tlustého klienta (standardní aplikace). Dalším rozhodnutím pak byla vlastní volba programovacího jazyka, struktury aplikace a databázového serveru. 2.6.2

Nákup a úprava některého systému vs. Návrh a výroba vlastního systému Informačních systémů pro firmy je na trhu celá řada. Většina se zaměřuje především na prodej

a evidenci platebních údajů. Menší část obsahuje také podporu výroby, ale každé odvětví výroby je specifické a potřeby se liší i mezi firmami ve stejném odvětví. Diskuze, zda vytvořit nový informační systém speciálně pro potřeby firmy nebo zakoupit systém již existující probíhala ve firmě ještě před započetím diplomové práce. Výhody a nevýhody obou řešení se pokusím shrnout v této kapitole. Výhody nákupu již hotového produktu 

komplexní řešení obsahující i komponenty, které by firma nyní nevyužila, ale které by mohla využít v budoucnu



nižší cena v porovnání s vývojem vlastní aplikace



snadná aktualizace softwaru při novelizaci zákonů

Nevýhody nákupu již hotového produktu 

nutnost změny organizace práce ve firmě



obtížná implementace změn systému vyžadující komunikaci a školení od firmy vyrábějící systém

28

Výhody návrhu celého systému 

Systém navržen pro podporu současných firemních procesů



Není nutné provádět žádné změny ve fungování firmy a její struktuře



Systém pracuje podle představ jednotlivých pracovníků, neboť z nich vychází



Snížená nutnost školení pracovníků – systém vychází ze současných návyků pracovníků



Kompletní znalost struktury aplikace umožňující snadnější začlenění změn, které se v budoucnu objeví



Kompletní technická dokumentace systému



Systém v maximální míře podporuje činnosti pracovníků Z těchto důvodů bylo nakonec rozhodnuto pro vytvoření vlastního nového systému „na zelené

louce“. Rozhodujícím byla především podpora výroby, která je v komerčních systémech řešena zcela jinak, než bylo ve firmě zvykem a znamenala by nutnost restrukturalizace firmy nebo zásadní změny ve struktuře zakoupené aplikace, což by s sebou neslo velká rizika. V takovémto případě by se změna nemusela povést a zakoupený systém by se stal pro firmu bezcenným.

29

2.7 Návrh podpory firemních procesů informačním 2.7.1

Podpora výroby Podpora výroby se bude soustřeďovat na přípravné předvýrobní činnosti, tedy především na

obstarávání veškerého potřebného materiálu. Dále pak na správu výroby jednotlivých komponent konečného výrobku. Bylo rozhodnuto, že by bylo velmi obtížné, aby v systému byly ve strukturované formě uloženy výrobní postupy, protože ty se u jednotlivých typů výrobků velmi liší. Výrobní postup pro mechanické komponenty obsahuje zcela jiný typ dat než postup pro výrobu desky plošného spoje nebo osazovací postup plošného spoje. Proto budou výrobní postupy uloženy ve strukturovaných adresářích, kde každý výrobek nebo komponenta bude mít přidělen vlastní adresář, kde budou uloženy podklady pro výrobu a výrobní postupy. Pro co nejlepší podporu předvýrobních činností je nutné, aby systém obsahoval materiálové listy pro jednotlivé výrobky a komponenty. To umožní uživateli kontrolu materiálu nutného pro výrobu, zobrazení množství materiálu, který je skladem, který je objednaný a který je ještě třeba obstarat. Bude se evidovat množství materiálu, které bylo do výrobního procesu již převedeno, aby ho bylo možno porovnat s množstvím materiálu potřebným pro výrobu. Pokud se výrobek skládá z dalších komponent, které je nutno vyrobit, bude systém poskytovat stejnou podporu i pro jednotlivé komponenty. Navíc bude systém schopen zobrazit stav výroby celého výrobku na základě agregace údajů z výroby jednotlivých komponent. Například, pokud je pro některou komponentu třeba objednat materiál, bude u celého výrobku uvedeno, že je třeba pro dokončení celé výroby třeba obstarat další materiál. To je důležité, protože obstarávání materiálu má na starosti většinou jiný pracovník výroby než ten, který provádí vlastní výrobu. V systému tedy budou v elektronické podobě vedeny informace o probíhajících výrobních procesech a u jednotlivých procesů bude uvedeno, zda je pro výrobu dostupné dostatečné množství materiálu, kolik materiálu již bylo do výroby převedeno, zda je materiál na cestě od dodavatele a zda a jaké množství je ještě třeba objednat. 2.7.2

Podpora nákupu zboží a materiálu Podpora nákupu by měla zahrnovat:



Zadávání do systému poptávky a objednávky pro dodavatele

30



Automatické generování e-mailů a tištěných verzí poptávek a objednávek. E-maily by se měly generovat pomocí snadno měnitelných šablon.



Evidence odpovědí na poptávky (nabídek) a evidence došlého zboží Další funkcí, kterou by podpora nákupu měla zahrnovat, jsou „Požadavky“. Požadavek je

záznam o potřebě obstarat určité zboží nebo materiál. Požadavek nemusí obsahovat informaci o tom, od jakého dodavatele má být zboží objednáno. V takovém případě bude zboží objednáno od jednoho z dodavatelů, který je toto zboží schopen dodat. Položky vzniklé na základě požadavku budou na požadavek obsahovat odkaz, čímž bude možnost kontroly, jaké akce byly na základě požadavku provedeny. Proto například pokud požadované zboží dodává více dodavatelů, je možno z požadavku vytvořit několik poptávek pro jednotlivé dodavatele a zboží pak objednat u nejlevnějšího dodavatele. Požadavek přitom bude udržovat informaci o tom, že jednotlivé poptávky jsou pro jeden požadavek a tudíž má zboží být objednáno pouze u jedné z firem. Dále bude podpora nákupu zahrnovat i podporu placení za přijaté faktury. Tato podpora bude umístěna do samostatného modulu a bude k ní mít přístup jen někteří pracovníci. Podpora bude následující: 

Evidence plateb za faktury



Vytvoření příkazu k úhradě za fakturu pro import do banky

2.7.3

Podpora prodeje Podpora prodeje má za úkol především podporu těchto činností: 

Evidence objednávek od zákazníků.



Tisk faktur a paragonů za prodané zboží.



Vedení prodejního skladu zboží a výrobků.



Evidence ceníků a automatické doplňování ceny zboží z ceníku na fakturu.



Evidence plateb za prodané zboží

Evidence plateb za prodané zboží znamená především evidenci plateb za faktury neplacené hotově, tedy platby převodem na účet, na dobírku atd. Tato evidence se bude automaticky vytvářet z dat poskytnutých bankou o pohybech na účtu a bude součástí samostatného bankovního modulu. 2.7.4

Podpora vývoje Po provedené analýze bylo rozhodnuto, že vývoj bude vzhledem ke své rozmanitosti

podporován pouze velmi omezeně. Systém bude s vývojovými programy spolupracovat poskytnutím seznamu ve firmě používaných součástek s několika vybranými základními informacemi o nich. Od 31

vývojových programů pak bude především přebírat a do databáze importovat materiálové listy jednotlivých komponent a výrobků. Vývojář také bude do systému zadávat nově použité součástky, informace o nich a jejich objednací značení pro dodavatele. 2.7.5

Podpora vedení skladu Skladová evidence bude vést počet výrobků na skladu a evidovat se budou i všechny skladové

operace – přidání či odebrání ze skladu. Věc na sklad bude možno přidat pouze následujícími způsoby: 

Přidání věci při dodání věci dodavatelem. Při této operaci se bude evidovat odkaz na položku na faktuře, která odpovídá dané věci. Tento údaj bude povinné zadat. Pokud faktura bude doručena až dodatečně, vyplní se údaje nutné pro pozdější dohledání a odkaz na položku faktury se vyplní až při příchodu faktury.



Převedením věci zpět na sklad při skončení výrobního procesu, pokud některé součástky zbyly. Bude veden odkaz, ze kterého výrobního procesu byla věc převedena.



Převedením zpět z vývojového projektu, pokud již není ve vývoji tato součástka potřeba a nebyla vývojem znehodnocena. Bude veden odkaz, ze kterého vývojového projektu byla věc převedena. Bude se kontrolovat, zda tato věc byla do vývojového projektu zavedena.

Věc lze ze skladu odebrat pouze následujícími způsoby: 

Převedením věci do konkrétního výrobního procesu. Bude veden odkaz, na který výrobní proces byla věc převedena.



Převedením věci do konkrétního vývojového projektu. Bude veden odkaz, na který vývojový projekt byla věc převedena.



Prodání věci. Bude vytvořen odkaz na fakturu nebo daňový doklad pro zákazníka.



Inventurou, během které bylo zjištěno, že daná věc na skladu fyzicky není. Inventurou je možno věc do skladu i přidat, pokud bude zjištěno, že na skladu je fyzicky věcí více, než odpovídá údaji v systému. Při každé skladové operaci přidávání nebo odebírání věcí bude evidováno, který pracovník

danou operaci provedl.

32

3 Návrh struktury systému Činnosti firmy, které se dotýkají nového systému, lze rozdělit na následující skupiny: 

Vývoj



Výroba



Nákup a prodej

Hlavními požadavky na systém byla podpora výroby, nákupů a prodeje. Podpora vývoje se ukázala jako poměrně problematická, vzhledem k velkému množství různých druhů software, který je ve firmě při vývoji nových zařízení používán. Vývojová data se ale používají při výrobě, kde byla podpora vyžadována. Po dokončení vývoje se tedy do systému z vývojových programů importují data potřebná pro výrobu, případně při nemožnosti data automaticky importovat se potřebná data zadávají ručně. Jedná se přitom především o materiálové listy. Podpora výroby spočívá především v evidenci materiálových listů, zjišťování množství materiálu potřebného pro výrobu a jeho objednávání, pokud není na skladě. S tím souvisí podpora nákupů, kdy je materiál objednáván od dodavatele. Počítá se s možností mít pro jeden typ materiálu více různých dodavatelů, kteří dodávají materiál pod různým značením. Celý proces objednávání by přitom měl být co nejvíce automatický. Systém by také měl umožňovat kontrolu, zdali bylo již zboží dodáno.

33

3.1 Statická struktura a nasazení Program bude nasazen jako jako takzvaný „Tlustý klient“, tedy aplikace pro Windows. Program bude přímo přistupovat k SQL serveru prostřednictvím uložených procedur (Stored procedures) na SQL serveru. Vlastní obchodní logika bude z větší části implementována přímo v aplikaci na straně klienta, z menší části pak v uložených procedurách. Se serverem tedy bude aplikace komunikovat pomocí SQL příkazů a dále pak pomocí přístupu ke sdíleným síťovým diskům na serveru, kam se budou ukládat výrobní postupy (každý výrobek bude mít určen svůj adresář, kde budou uložena data s popisem jeho výroby) a také se zde budou ukládat ve formě PDF dokumentů všechny vytisknuté faktury a objednávky z důvodu archivace a možnosti jejich případného znovuvytištění ve stejné podobě.

Uživatel Klientská aplikace

Server Sdílení souborů

SQL

SQL Server

File Server

Obrázek 11: Diagram nasazení systému

34

3.2 Moduly systému Jednotlivé moduly vycházejí z logického rozdělení požadavků jednotlivých pracovníků do kategorií.

Výrobní postupy

Položky

Objednací značení

Ceníky

Skladová evidence

Obchodní partneři

Účetní software

Obchodní dokumenty

Bankovní platby

Účetní software již firma vlastní a není součástí navrhovaného systému

Obrázek 12: Statická struktura systému



Výrobní postupy, výroba o

správa materiálových listů

o

evidence a kontrola rozpracované výroby

o

zajišťování materiálu pro výrobu



Položky



Skladová evidence o

evidence nakoupeného zboží určeného pro další prodej, materiálu pro výrobu a hotových výrobků na skladu

o 

evidence ceny zboží na skladu pro účetnictví

Obchodní dokumenty o

registrace požadavků výroby na objednání materiálu

o

evidence a generování poptávek dodavatelům

35

o

evidence nabídek dodání materiálu od dodavatelů, jejich agregace pro snadné určení nejlepší nabídky

o

evidence a generování objednávek dodavateli

o

kontrola dodání objednávky

o

faktury a paragony přijaté

o

faktury a paragony vydané

o

vnitropodnikové faktury (mzdy)



Ceníky



Objednací značení o





správa dodavatelů a objednacích značení

Obchodní partneři o

evidence dodavatelů

o

evidence zákazníků

Bankovní platby o

správa odchozích plateb za přijaté faktury (nákup materiálu)

o

správa příchozích plateb za vydané faktury (prodej zboží)

o

export a import plateb z a do bankovního terminálu

3.3 Datový model Obchodní partneři Pro nákup materiálu a zboží od dodavatelů je třeba uchovávat informace o dodavatelích. Pro kontaktování dodavatele je třeba uchovávat e-maily, telefonní čísla a adresy poboček, pro platby je třeba uchovávat čísla účtů nebo údajů pro platby přes jiné systémy (kreditní karta, PayPal). Dále je třeba uchovávat informace o firmě jako takové, jako například DIČ, internetová adresu firmy a zda se jedná o zahraniční firmu. Tyto informace se použijí při vytváření poptávky, objednávky nebo faktury pro danou firmu, informace o platebních údajích pak při platbě za dodané zboží. Při vytvoření dokumentu a vyplnění dodavatele pak uživatel pouze vybere správné kontaktní údaje z nabídky, místo aby je musel znovu vyplňovat. Zároveň dojde k navázání dokumentu na vybranou firmu. To usnadní hledání uskutečněných nákupů od firmy v případě, že dojde například k jejímu přejmenování. Je vhodné také mít možnost udržovat stejné informace i o zákaznících, kteří u nás nakupovali pro případ opakovaného nákupu, kdy pracovník pouze zkontroluje aktuálnost údajů a nemusí je znovu vyplňovat.

36

Informací, které je o jednotlivých firmách možno udržovat, je ohromné množství. Konzultacemi s pracovníky a porovnáním s existujícími systémy byly vybrány ty nejdůležitější. Zde jsou některé základní informace, ke kterým se při konzultacích a porovnávání jednotlivých systémů dospělo: 

Každá firma by v systému měla být zavedena pouze jednou. Při jejím přejmenování by měla být v systému pouze přejmenována, nikoli vytvořena znovu. To umožní vytvoření přehledu všech faktur a všech plateb pro tuto firmu. V případě, že by jedna firma byla v systému zavedena vícekrát, byly by faktury a platby přiřazeny různým firmám a bylo by velmi obtížné je kontrolovat. To je rozdíl oproti stávající evidenci ve firmě, kdy při návrhu datové struktury nedošlo k normalizaci do 3. normální formy a v jedné tabulce byly obsaženy jak firmy a informace o nich, tak i jednotlivé adresy firmy, kontaktní osoby a telefony. Jedna firma tak byla v databázi uložena většinou vícekrát, mnohdy i pod jinými názvy. To znemožňovalo automatické dohledávání všech dokumentů pro danou firmu.



Další údaje jako kontaktní informace (jména osob, telefony, e-maily a faxy), adresy poboček a údaje pro platby budou uloženy v samostatných tabulkách.



Je vhodné označit jeden z kontaktních údajů jako výchozí. Ten se bude automaticky nabízet při vybrání firmy během vytváření obchodního dokumentu. To umožní provádět objednávky od této firmy i pracovníkům, kteří s danou firmou komunikují poprvé.



U adres se bude jméno ulice, města a PSČ zadávat do samostatných políček, což umožní v budoucnu lepší tvorbu statistik prodeje podle regionů a snazší hledání firem. Tento způsob ale komplikuje zadávání zahraničních firem, kdy má každá země jiný formát adresy. Tento problém bude vyřešen pomocí tabulky formátů adres, kde bude pro jednotlivé státy uloženo pořadí jednotlivých políček adresy při tvorbě výsledné adresy.

37

Obrázek 13: Datový model – Obchodní partneři

Obchodní dokumenty Obchodními dokumenty jsou souhrnně nazývány všechny dokumenty odeslané obchodnímu partnerovi nebo přijaté od obchodního partnera. Systém rozlišuje následující typy dokumentů: 

Nákup – Interní platba



Nákup – Poptávka vydaná



Nákup – Nabídka přijatá



Nákup – Objednávka vydaná

38



Nákup – Zálohová faktura přijatá



Nákup – Zahraniční zálohová faktura přijatá



Nákup – Faktura přijatá



Nákup – Paragon přijatý



Prodej – Poptávka přijatá



Prodej – Nabídka vydaná



Prodej – Objednávka přijatá



Prodej – Zálohová faktura vydaná



Prodej – Zahraniční zálohová faktura vydaná



Prodej – Faktura vydaná



Prodej – Zahraniční faktura vydaná



Prodej – Paragon vydaný



Prodej – Dodací list vydaný



Prodej – Celní faktura vydaná Rozdělení vychází z odlišných typů dokumentů a jejich odlišného chování v programu. Typy

dokumentů jsou přímo propojeny s chováním programu a jejich výčet musí být pevně stanoven přímo v kódu programu. Jednotlivé typy mají také mírně odlišné atributy. Odlišnosti atributů jsou ale jen poměrně malé, kdy některé atributy některým typům dokumentů chybí. Proto bylo rozhodnuto ukládat všechny typy dokumentů do stejné datové struktury, což umožnilo psát kód pro obsluhu obecných vlastností dokumentů pouze jednou. Následující diagram ukazuje datovou strukturu pro uložení obchodních dokumentů. Centrální tabulkou je tabulka „Docs“, která obsahuje jednotlivé dokumenty. Tabulka má celkem 50 atributů a je v tomto směru největší tabulkou v celém systému. Většina atributů je využívána všemi typy výše popsaných dokumentů, některé jsou ale využity pouze u některých typů dokumentů. Napříkad atribut „PrePaidAmount“ obsahuje částku placenou předem před vytvořením faktury. Tato částka se objevuje na faktuře a snižuje částku, kterou má zákazník ještě doplatit. Tento atribut tedy má smysl pouze u faktur přijatých, vydaných a zahraničních a nemá smysl u ostatních typů dokumentů, kde zůstává nevyplněn. Další v diagramu je tabulka „DocItems“, která obsahuje položky uvedené na dokumentu. Tabulka „DocItems“ je s tabulkou „Doc“ spojena vazbou 1:N, tedy jeden dokument (například faktura) obsahuje větší množství položek v tabulce „DocItems“ (například fakturované zboží). Na této tabulce je nejzajímavější vazba 1:N na sebe samu pomocí atributu „BaseDocItemID“, který odkazuje na primární klíč „DocItemID“ této tabulky. Tato vazba slouží pro ukládání návaznosti jednotlivých 39

dokumentů. Návaznost dokumentů je jednou z nejdůležitějších vlastností tohoto modulu a řeší se pomocí ní uzavírání již hotových dokumentů. Například pokud zákazník objedná zboží, je do systému zavedena objednávka. Když je objednávka zpracována, vytvoří se faktura zákazníkovi a tím dojde k automatickému označení objednávky jako vyřízená. Systém pravidel pro označování předchozích dokumentů jako vyřízené je poměrně složitý a závisí vždy na konkrétní kombinaci typů navazujících dokumentů. Z výše uvedeného vyplývá, že při vytváření navazujícího dokumentu se musí vytvořit vazba s předchozím dokumentem, což je řešeno v uživatelském rozhraní. Směr této vazby a její charakter 1:N, kdy více položek (například faktury) může navazovat na jednu položku původního dokumentu (například objednávky), je dán možností takzvané vícenásobné fakturace. Není-li všechno zboží uvedené na objednávce skladem, je odeslána alespoň část objednávky spolu s fakturou na odeslanou část a druhá část je odeslána při naskladnění zbylého zboží. Na jednu položku objednávky v takovém případě navazují 2 položky faktury. Zboží ale může být ale odesláno i ve více dodávkách. Až v průběhu implementace vyšel najevo fakt, že při objednávce od dodavatele může zboží příjít dříve než faktura, spolu s fakturou nebo i dodatečně po příchodu faktury. Obecně může pro jednu objednávku přijít více dodávek zboží i více faktur a to v libovolném pořadí a obecně v libovolném množství. Úkolem systému je tyto události zaznamenat, jednotlivá množství porovnat a upozornit na nesrovnalosti, například pokud celkové množství fakturované je vyžší než celkové množství dodané. Z tohoto vyplývá, že systém musí evidovat dodané množství zboží a to nezávisle na přijatých fakturách. Přestože z výše uvedeného vyplývá, že se nejedná o pravidlo, je příchod zboží spolu s fakturou v jednom balíku velmi časté a kvůli zjednodušení zadávání a lepší orientaci v došlém zboží je vhodné uložit i informaci spolu s kterou fakturou zboží došlo, pokud se jedná o případ příchodu zboží s fakturou najednou. Pro evidenci došlého zboží byla tedy zavedena speciální tabulka s názvem „Deliveris“, ve které jsou uloženy data doručení a množství doručeného zboží. U každého doručení je uveden odkaz na objednávku, na fakturu nebo na oba dokumenty, vůči kterým je doručení provedeno.

40

Jednou z největších odlišností současného systému oproti ostatním komerčním systémům je evidence takzvaných „Požadavků“ na obstarání zboží, které jsou ukládány do tabulky „Demands“. Požadavek je záznam o potřebě obstarat určité zboží nebo materiál od dodavatelů. Požadavek přitom většinou nespecifikuje, od kterého dodavatele bude zboží obstaráno, ale pouze určuje potřebné množství, účel, kam se má zboží po dodání uložit a kdo požadavek vydal. Požadavek vzniká v několika různých situacích: Kdo

Proč je požadavek vytvořen

Kam má být

požadavek

materiál

vytváří

doručen

Pracovník

Obstarání materiálu pro výrobu. Po založení výrobního procesu

Konkrétní

výroby

pracovník výroby zkontroluje, zda je materiál skladem a pokud

výrobní proces

není, vytvoří nový požadavek na jeho objednání a dodání. Pracovník

Doplnění nedostatkového zboží na sklad. Pokud je na skladu už jen

obchodu

malé množství zboží, vytvoří pracovník obchodu nový požadavek.

Pracovník

Objednávka od zákazníka. Pokud zákazník objedná zboží, které

obchodu

není vedeno skladem, vytvoří pracovník obchodu požadavek na

Sklad zboží

Expedice zboží

jeho objednání a dodání u dodavatele. Po dodání bude zboží odesláno zákazníkovi. Vývojář

Obstarání materiálu na prototyp. Součástí vývoje je často vytvoření prototypu, který vyrábí vývojář.

Vývojový projekt

Tabulka 1: Vznik nového požadavku

Z požadavku je následně vytvořena jedna nebo více poptávek pro dodavatele, nebo je rovnou vytvořena objednávka. Při vytvoření více poptávek je po příchodu všech odpovědí vyhodnocena nejvýhodnější nabídka a zboží je objednáno. Dále se čeká na doručení faktury a zboží. Požadavek je užavřen doručením požadovaného množství zboží, případně většího než požadovaného množství zboží. Požadavek umožňuje pracovníkovi, který ho vytvořil, snadno sledovat stav celého procesu poptání, objednání a dodání zboží, a to i v případě, že zboží bylo poptáno u více dodavatelů současně.

41

Obrázek 14: Datový model – Obchodní dokumenty

42

Bankovní platby Modul bankovních plateb se stará o evidenci příchozích a odchozích plateb a o vytváření nových plateb za příchozí faktury a paragony. Platby jsou automaticky importovány z jednotlivých zdrojů (bankovní terminál, v budoucnu modul pro PayPal, kreditní karty a další) a následně jsou přiřazovány k odpovídajícím dokumentům v systému. Tabulka „BankPayments“ obsahuje platby importované z jednotlivých zdrojů a nově vytvořené platby určené k provedení.

Obrázek 15: Datový model – Bankovní platby

Položky Položka je označení pro hmotnou nebo nehmotnou entitu, která se objednává, prodává nebo je vedena skladem. Příkladem hmotné položky může být výrobek, zboží nebo materiál. Příkladem nehmotné položky může být práce, poštovné, recyklační poplatek nebo nakoupená služba. Položkou rozumíme třídu dané věci, tedy označení jména výrobku nebo typ materiálu, nikoli konkrétní instanci věci. Evidence položek je uložena v tabulce „Items“. Položka je jednoznačně identifikovaná svým unikátním jménem a má vyplněnu kategorii, do které patří. Pro každou položku může být volitelně uložen její popis v českém a anglickém jazyce, poznámka a odkaz na podkategorii.

43

V evidenci položek jsou vedeny ty položky, které jsou skladem, nebo které se nakupují nebo prodávají tak často, že je vhodné o nich vést statistiku. V evidenci tedy nejsou položky z ojedinělých nákupů nebo prodejů, které se neopakují. Položky se dělí do kategorií podle typu. V současné době byly identifikovány a do systému zavedeny následující kategorie položek určených k prodeji nebo nákupu: 

Výrobky



Zboží



Služby



Elektronické součástky

Pro potřeby výroby byly dále zavedeny následující kategorie označující různé typy mezivýrobků určených pouze pro další výrobu: 

Práce



Součástky nepájitelné (mechanické)



Nálepky



Manuály



Desky plošných spojů



Osazené desky plošných spojů



Mechanická sestavy



Moduly



Vývozní sestavy výrobku

Každá kategorie má uvedeno, zdali položky této kategorie jsou hmotné nebo nehmotné. Nehmotné jsou pouze kategorie „Služby“ a „Práce“, ostatní kategorie slouží pro hmotné položky. Nehmotné položky nemohou být uloženy na sklad. Dále je možno volitelně položku začlenit do podskupiny, které dále dělí jednotlivé kategorie. Například kategorie „Elektronické součástky“ je dále rozdělena na podskupiny „R – Odpory“, „C – Kondenzátory“, „D – Diody“, atd.

44

Obrázek 16: Datový model – Položky a jejich třídění do skupin

Materiálové listy Materiálové listy jsou hlavním nástrojem podpory výroby v systému. Umožňují pracovníkovi zobrazit množství materiálu potřebného pro výrobu. Z modulu skladu je pro tyto jednotlivé položky načtena informace o materiálu již převedeném do daného výrobního procesu a z modulu dokumentů je načtena informace o objednaném množství. Pracovník tak přehledně vidí, kolik materiálu potřebuje, kolik ho již má, kolik je již objednáno a který materiál je ještě třeba obstarat pro započetí vlastní výroby. Tyto funkce jsou nezbytné pro ulehčení výroby, neboť ve firmě se vyrábí malosériově velké množství různých výrobků a jeden pracovník může mít na starosti i několik desítek různých výrobních procesů. Protože je ve firmě prováděna jak výroba, tak vývoj, je časté, že se materiálové listy a postupy výroby velmi často mění, obzvláště u nových výrobků. Vzhledem k zaměření firmy na malosériovou výrobu je ale nových výrobků většina a ke změnám postupu výroby tedy dochází velmi často. Z tohoto důvodu je nutné vést evidenci o těchto změnách a evidovat i starší výrobní postupy. Často se například stane, že je výrobní postup změněn v průběhu výroby jedné série výrobku a ještě před dokončením série je podle nového výrobního postupu zahájena výroba nové výrobní série. U ještě nedokončené série se ale předpokládá dokončení výroby podle starého výrobního postupu. Z toho vyplývá, že systém musí umožňovat uložení více verzí výrobního postupu pro jeden výrobek. 45

Každá verze výrobního postupu má záznam v tabulce „Production“, kde je uvedeno, pro který výrobek tato verze je, číslo verze, přibližné náklady na materiál pro výrobu, minimální výrobní množství a cesta k výrobnímu postupu na sdíleném disku. V tabulce „ProductionItems“ jsou pak uvedeny vlastní položky materiálového listu pro jednotlivé výrobní verze výrobku. U každé položky listu je uvedeno množství potřebné pro výrobu.

Obrázek 17: Datový model – Materiálové listy

Objednací značení Je častým jevem, že jedna součástka nebo jiná položka může být objednána od více různých dodavatelů. Většinou ale pod mírně různým značením, přičemž přesné značení při objednání je u elektronických součástek nezbytné. Celkem se navíc ve firmě používá několik tisíc různých součástek. Z tohoto důvodu je nutné mít evidenci objednacích značení pro jednotlivé položky. Objednací značení jednotlivých položek pro jednotlivé dodavatele jsou uvedena v tabulce „ItemSuppliers“. Každé objednací značení se skládá ze dvou polí „SupItemName“ a „SupItemDesc“, která se tisknou v objednávce. U položky je dále takzvaný převodní poměr („Qtyconversion“), který se použije, pokud jednotky používané ve firmě pro určování množství dané položky jsou jiné, než které používá dodavatel (například pokud ve firmě je uváděn počet šroubů, zatímco dodavatel dodává šrouby na kilogramy, je převodním poměrem průměrný počet šroubů v jednom kg). Další položkou, která byla vybrána jako vhodná pro ukládání, je výrobce dané položky dodávané od dodavatele. Někdy se totiž stává, že dodavatel dodává například stejné odpory od více různých výrobců pod různým značením. Jelikož jsou ale parametry všech odporů daného typu totožné, jsou ve firmě vedeny pod jedním značením a vzájemně záměnné. Pro jednu položku (součástku) a jednoho obchodního partnera (dodavatele) pak bude existovat i více možných objednacích značení. V tomto případě je vhodné evidovat pro objednací značení i výrobce, pro 46

kterého je dané značení určeno. Jednotliví výrobci jsou uloženi v tabulce „Manufacturers“ a u řádků objednacího značení je možno na konkrétního výrobce vytvořit odkaz.

Obrázek 18: Datový model – Objednací značení

Sklady Pro evidenci množství položek na skladu byla vytvořena jednoduchá struktura pro zaznamenávání skladových operací. Počet jednotlivých položek na skladě je pak při zobrazení vždy spočítán jako součet přes jednotlivé skladové operace. Tento způsob je poměrně náročný na výpočetní čas, ale protože je firma poměrně malá a množství skladových operací je pouze v řádu tisíců, je tento způsob dostačující. V budoucnu se počítá s ukládáním vypočtených hodnot do tabulek a jejich aktualizaci pouze při změně skladového množství novým výpočtem, tedy s vytvořením chache pro tyto hodnoty na databázové úrovni. Modul skladů umožňuje vést evidenci o více skladech. Sklady je navíc možno skládat do logického stromu, kdy jeden sklad je podřízen jinému skladu. To umožňuje členit sklady do logických celků například podle prostorového rozložení. Při návrhu bylo také zvažováno, jakým způsobem bude vedena evidence materiálu převedeného do výrobního procesu. U výrobních procesů je třeba zobrazit nejen množství potřebné pro výrobu, ale i množství materiálu, který byl již procesem alokován a množství materiálu, které ještě bude pro dokončení procesu potřeba. Bylo rozhodnuto, že na základě podobnosti s vedením materiálu ve skladu se mohou výrobní procesy i sklady uchovávat ve stejné datové struktuře, což zjednoduší implementaci a navíc umožní s procesy pracovat stejně jako se skladem. Při objednání

47

materiálu a jeho dodání tedy bude možné ho převést jak na sklad, tak do výrobního procesu a to stejným postupem, což aplikaci zpřehlední.

Obrázek 19: Datový model – Sklady

48

4 Popis implementace systému Během realizace byl vytvořen klientský program pro podporu výše zmíněných uživatelských případů. Aplikace je rozčleněna na jednotlivé části a to jak vertikálně do jednotlivých vrstev, tak horizontálně podle jednotlivých funkčních modulů, které byly popsány v kapitole „3.2 Moduly systému“. Strukturou byla aplikace rozdělena do tří vrstev: databáze, vrstva pro přístup k datům starající se o načítání dat do paměti a jejich ukládání a zobrazovací vrstva obsahující uživatelské rozhraní. Rozdělení ukazuje následující diagram:

Aplikace

Zobrazovací vrstva

Vrstva pro přístup k datům

SQL Server Volání uložených procedur

Uložené procedury

SQL

Data (tabulky)

Obrázek 20: Diagram nasazení – Rozdělení aplikace do vrstev

Aplikace dále ještě využívá server pro přístup k výrobním postupům jednotlivých výrobků a pro ukládání vytištěných faktur a objednávek ve formě pdf dokumentů, viz. kapitola „3.1 Statická struktura a nasazení“. 49

Jako programovací jazyk bylo zvažováno prostředí Microsoft .NET, Java, C++ a Delphi. Vybral jsem prostředí .NET z důvodu mé znalosti tohoto prostředí a snadnosti návrhu databázových aplikací v tomto prostředí. Jako SQL server byl vybrán MySQL server, a to především proto, že je zdarma, může běžet pod prostředím Linux, který je ve firmě instalován na File serveru a splňuje všechny nároky na něj kladené pro daný rozsah systému (tabulky v řádu desítek tisíc řádků, uložené procedury, triggery). Uživatelské rozhraní je členěno logicky podle rozdělení do jednotlivých modulů. Hlavní obrazovky jsou následující: 

Obchodní dokumenty (poptávky, objednávky, faktury) a evidence požadavků na objednání



Obchodní partneři – evidence dodavatelů, zákazníků a údajů o nich



Sklady, výrobní procesy a vývojové projekty – přehled evidence nákupů, prodejů a vnitropodnikových přesunů materiálu a zboží



Položky, jejich popis, zpráva materiálových listů a objednacích značení jednotlivých položek a komponent



Bankovní platby přijaté a platby za zboží a materiál Náhledy jednotlivých obrazovek uživatelského rozhraní jsou v příloze v kapitole „11.1 Ukázky

uživatelského rozhraní“. Při spuštění programu se uživatel identifikuje a jsou zkontrolována jeho oprávnění pro práci s programem. Dále může uživatel pracovat s jednotlivými moduly programu. Jednotlivé moduly jsou navzájem propojeny a odkazují se na sebe, což umožňuje snadnější pohyb uživatele celým programem. Jako důležitou vlastností se ukázalo řešení konkurenčního přístupu do databáze a to jak více uživatelů najednou, tak i jednotlivých částí programu při modifikaci položky otevřené více uživateli nebo více částmi programu v jednom okamžiku. Tento problém je navíc dále komplikován skutečností, že pro zrychlení programu je poměrně velké množství údajů ukládáno do lokální paměti (cache). To je nutné zejména například pro automatické doplňování jmen součástek a firem při jejich zadávání nebo při jejich výběru ze seznamu. Pokud je taková firma nebo součástka na jiném počítači změněna nebo smazána, musí se program s touto skutečností vyrovnat. S detekcí tohoto problému bylo počítáno již od začátku implementace, avšak v první fázi vývoje jsem předpokládal, že tento jev bude jen velmi ojedinělý a jako řešení bude stačit odepření přístupu k modifikované položce či varovná zpráva. Během testování se ale ukázalo, že způsob práce a využívání systému ve firmě

50

způsobuje, že se tento jev vyskytuje poměrně často, neboť na stejné položce velmi často pracuje více lidí najednou. Původní systém založený na databázi Microsoft Access byl navíc navržen jako on-line systém kdy veškeré provedené změny byly bez vyzvání ihned ukládány, což sice bylo uživatelsky velmi nepříjemné, ale z větší části se tímto přístupem řešily problémy s konkurenčním přístupem k databázi. Ukládání položek automaticky ihned po modifikaci ale bylo nepříjemné například při jejich změně omylem, a proto byl požadavek na nový systém, aby se změny do systému zapsaly až při žádosti uživatele o jejich uložení, tak jak to bývá zvykem. Bylo proto zvoleno poměrně robustní řešení, kdy se program snaží při zjištění konfliktu změněné položky z databáze znovu načíst a se změnami se, pokud je to možné, sám vyrovnat.

5 Výsledky testování. Systém byl 5. 4. 2008 nasazen do testovacího provozu a dne 1. 5. 2008 začal ostrý provoz. Díky provedené analýze se nevyskytly žádné větší systémové chyby návrhu, ale pouze chyby v uživatelském rozhraní a způsobu ovládání aplikace. Největším problémem, který se objevil v průběhu testování, byla reakce programu na klávesu Enter. Starý systém pro objednávky a systém účetnictví (pod systémem DOS) používají klávesu Enter pro přechod na další políčko pro zadávání. Nový systém používal pro přechod na další políčko klávesu Tab a klávesu Enter používal pro potvrzení zadání (Uložení) nebo pro přechod na další řádek. To se pro uživatele ukázalo jako nepřijatelné, zvláště kvůli umístění kláves na opačné straně klávesnice (klávesa Tab nelze mačkat pravou rukou). Tento problém byl vyřešen změnou způsobu ovládání aplikace klávesnicí.

51

6 Zhodnocení splnění cílů práce Byl proveden velmi detailní rozbor činností firmy a stávajících informačních systémů ve firmě. Původní stav a systémy byly popsány a byla provedena analýza dat, které obsahovaly. Z tohoto rozboru a z konzultace s jednotlivými pracovníky pak byl navržen nový informační systém. Ten zahrnuje funkce některých původních systémů firmy, které fungovaly špatně nebo již neposkytovaly potřebné funkce pro měnící se nároky firmy. Jedná se především o podporu nákupu zboží a materiálu a prodeje zboží a výrobků. Dále byly do systému přidány nové funkce a moduly pro lepší podporu firemních procesů – podpora výroby a objednávání materiálu pro výrobu. V rámci diplomové práce byla implementována větší část systému. Implementovány byly především nejdůležitější části nutné pro fungování firmy a vyřazení nevyhovujících systémů. Jedná se o vytváření, evidenci, tisk a posílání obchodních dokumentů, jako jsou poptávky, objednávky a faktury a to jak pro nákup materiálu, tak i prodej výrobků. Dále o podporu výroby spočívající především v evidenci materiálových listů, obstarávání materiálu pro výrobu a vedení evidence o materiálu ve výrobě. Dále bylo implementováno skladové hospodářství podle účetních standardů používaných ve firmě. Systém byl po celou dobu vývoje konzultován s pracovníky firmy a odhalené nedostatky v návrhu byly okamžitě zapracovávány. Nový systém byl nasazen a testován souběžně se starým systémem, což umožnilo najít a odstranit chyby vzniklé při implementaci. Díky detailnímu návrhu celého systému předem nebyly během testování odhaleny vážnější strukturální chyby a systém dobře podporuje ve firmě zažité procesy. Systém byl do fáze testování uveden postupně, jak byly dokončovány jednotlivé moduly. Nejdůležitější funkce systému byly dokončeny dle časového plánu cca jeden měsíc před plánovaným nasazením systému. Jeden měsíc před nasazením do ostrého provozu byl systém spuštěn do testovacího užívání. Během této fáze byly odstraněny poslední nedostatky. Systém byl pak uveden do ostrého provozu spolu se začátkem nového účetního roku. V současné době je systém využíván a implementovány jsou nejdůležitější funkce obsažené v návrhu. V blízké době se plánuje implementace zbývajících navržených funkcí, především zlepšení uživatelského rozhraní podpory výroby, implementace výstupů pro manažera a implementace různých druhů statistik prodeje a nákladů na výrobu a vývoj. Tyto části nebyly v rámci diplomové

52

práce implementovány, protože jejich náročnost přesahuje diplomovou práci, což je zmíněno i v zadání diplomové práce.

7 Závěr Byla provedena kompletní analýza firemních procesů a stávajících informačních systémů. Byl navržen nový informační systém s podporou pro jednotlivé činnosti firmy, hlavně pak pro výrobu a obstarávání materiálu pro výrobu. Větší část systému v rozsahu diplomové práce byla implementována a systém byl po otestování nasazen do ostrého provozu se začátkem nového účetního roku.

53

8 Seznam obrázků Obrázek 1: Výrobní strom ...................................................................................................................6 Obrázek 2: Diagram užití - Vývojář .................................................................................................... 12 Obrázek 3: Diagram užití - Pracovník výroby...................................................................................... 13 Obrázek 4: Diagram užití - Pracovník obchodu .................................................................................. 14 Obrázek 5: Diagram užití - Pracovník s přístupem k bankovnímu účtu ............................................... 15 Obrázek 6: Diagram užití - Pracovník pro komunikaci s dodavatelem ................................................ 16 Obrázek 7: Diagram užití - Manažer .................................................................................................. 17 Obrázek 8: Stavový diagram - Nákup zboží ........................................................................................ 20 Obrázek 9: Diagram komunikace - Nákup zboží ................................................................................. 21 Obrázek 10: Struktura původního systému ........................................................................................ 23 Obrázek 11: Diagram nasazení systému ............................................................................................ 34 Obrázek 12: Statická struktura systému ............................................................................................ 35 Obrázek 13: Datový model – Obchodní partneři ................................................................................ 38 Obrázek 14: Datový model – Obchodní dokumenty........................................................................... 42 Obrázek 15: Datový model – Bankovní platby ................................................................................... 43 Obrázek 16: Datový model – Položky a jejich třídění do skupin.......................................................... 45 Obrázek 17: Datový model – Materiálové listy .................................................................................. 46 Obrázek 18: Datový model – Objednací značení ................................................................................ 47 Obrázek 19: Datový model – Sklady .................................................................................................. 48 Obrázek 20: Diagram nasazení – Rozdělení aplikace do vrstev........................................................... 49 Obrázek 21: Uživatelské rozhraní – Seznam obchodních dokumentů podle typů dokumentu ............ 56 Obrázek 22: Uživatelské rozhraní – Detail obchodního dokumentu ................................................... 56 Obrázek 23: Uživatelské rozhraní – Seznam požadavků na objednání ................................................ 57 Obrázek 24: Uživatelské rozhraní – Obchodní partneři ...................................................................... 57 Obrázek 25: Uživatelské rozhraní – Sklady a položky na skladě .......................................................... 58 Obrázek 26: Uživatelské rozhraní – Správa položek, výrobních postupů a objednacích značení ......... 58 Obrázek 27: Uživatelské rozhraní – Bankovní platby .......................................................................... 59

54

9 Seznam použité literatury [1] Zákon č. 513/2001 Sb., Obchodní zákoník [2] Zákon č. 563/1991 Sb., Zákon o účetnictví [3] Zákon č. 235/2004 Sb., Zákon o dani z přidané hodnoty [4] SAP Česká republika. http://www.sap.com/cz [5] SAP Business One. http://www.sap.com/cz/smallbusiness/solutions/overview/features.epx

10 Obsah přiloženého CD Na přiloženém CD jsou k dispozici: 

Elektronická verze této diplomové práce



Zdrojové kódy klientské aplikace napsané ve Visual Basicu.NET



Instalační balíček klientské aplikace



Skripty pro vytvoření databáze na serveru

55

11 Přílohy 11.1 Ukázky uživatelského rozhraní

Obrázek 21: Uživatelské rozhraní – Seznam obchodních dokumentů podle typů dokumentu

Obrázek 22: Uživatelské rozhraní – Detail obchodního dokumentu

56

Obrázek 23: Uživatelské rozhraní – Seznam požadavků na objednání

Obrázek 24: Uživatelské rozhraní – Obchodní partneři

57

Obrázek 25: Uživatelské rozhraní – Sklady a položky na skladě

Obrázek 26: Uživatelské rozhraní – Správa položek, výrobních postupů a objednacích značení

58

Obrázek 27: Uživatelské rozhraní – Bankovní platby

11.2 Postup instalace Instalaci celého systému lze rozdělit na instalaci serveru s databází a na instalaci klientských počítačů. Od uživatelů se předpokládá pouze instalace klienta na svém počítači. Na tuto instalaci byly ve firmě kladeny speciální nároky a je popsána dále. Celý systém je určen výhradně pro použití ve firmě Asix s.r.o., pro kterou byl navrhnut a pro instalaci v jiné firmě by bylo nutno provést změny nastavení klientské aplikace, především adresy serveru v síti. 11.2.1 Instalace serveru s databází Je podporována databáze MySQL a pro vytvoření její struktury byly napsány SQL skripty, které jsou přiloženy na CD k diplomové práci. Postup instalace MySQL serveru je popsána pro daný operační systém na stránkách MySQL http://www.mysql.com, kde je možno instalaci zdarma získat. Jméno serveru se musí shodovat s nastavením jednotlivých klientů, kteří se k serveru připojují. Toto nastavení je uloženo v konfiguračním XML souboru klienta.

59

11.2.2 Instalace klienta na počítači uživatele Protože je klientská aplikace napsána v prostředí Microsoft .NET, vyžaduje ke svému běhu NET Framework, a to ve verzi 2.0 nebo vyšší. Dále aplikace používá pro vytváření tiskových sestav (například faktury) modul Crystal Reports od společnosti Business Objects. Výše zmíněné komponenty jsou součástí instalačního balíčku aplikace. Aplikaci tedy stačí instalovat spuštěním souboru „setup.exe“ z instalačního balíčku.

60