Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Informační systém pro správu reklamačního řízení Andreas Rolli
Vedoucí práce: Ing. Dana Vynikarová, Ph.D.
7. května 2015
Poděkování Chtěl bych poděkovat paní Ing. Daně Vynikarové, Ph.D. za cenné rady, které mi poskytovala při vypracování této práce. Také bych chtěl poděkovat rodině a přátelům, kteří mě podporovali v průběhu studia.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou, a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla, a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
V Praze dne 7. května 2015
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2015 Andreas Rolli. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Rolli, Andreas. Informační systém pro správu reklamačního řízení. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2015.
Abstrakt Cílem této bakalářské práce je analýza, návrh a implementace informačního systému pro správu reklamačního řízení. Na základě současného stavu řešení je navržen systém, který může použít jakákoliv firma, či organizace. Přínosem systému je úplný přehled pro výrobce i spotřebitele o reklamačním procesu. Dále systém generuje reklamační protokol a uchovává všechny informace o reklamaci. V příloze bakalářské práce lze nalézt zdrojové kódy a obrazovou přílohu. Součástí práce je i ekonomicko-manažerské zhodnocení. Klíčová slova reklamace, reklamační řízení, informační systém, správa reklamace, řízení procesů, komunikace
Abstract The objective of this bachelor’s thesis is analysis, design and implementation of information system for managing warranty claims. Based on current solutions the designed information system can be used by any firm or organization. The system gives full overview about warranty process to the benefit of both customers and manufacturers. The system generates complaint protocol and stores all of the information about complaint. Source codes, diagrams and ix
additional graphics are included in the appendix. The thesis also constains assessment from economic and management points of view. Keywords complaint, complaint procedure, information system, complaint managment, process management, comunication
x
Obsah Úvod
1
1 Cíl práce
3
2 Analýza současného stavu 2.1 Kastner STEREO . . . 2.2 Helios . . . . . . . . . . 2.3 POHODA . . . . . . . . 2.4 INOVIO . . . . . . . . . 2.5 Hodnocení . . . . . . . .
řešení problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
5 5 6 6 7 7
3 Analýza 3.1 Řešení . . . . . . . . . . . . 3.2 Proces reklamačního řízení . 3.3 Doménový model . . . . . . 3.4 Funkční požadavky . . . . . 3.5 Uživatelské role . . . . . . . 3.6 Případy užití . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
9 9 10 11 12 16 17
4 Vývojové nástroje 4.1 HTML . . . . . 4.2 CSS . . . . . . 4.3 Bootstrap . . . 4.4 PHP . . . . . . 4.5 MySQL . . . . 4.6 C# .NET . . . 4.7 PHP Mailer . . 4.8 mPDF . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
23 23 23 23 24 24 24 24 25
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 Realizace
27 xi
5.1 5.2 5.3 5.4 5.5 5.6
Databázový model . . . . . . Třívrstvá architektura webové Popis webové aplikace . . . . Popis desktopové aplikace . . Řešené problémy . . . . . . . Testování . . . . . . . . . . .
. a . . . .
. . . . . . . . . . . . desktopové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Ekonomicko-manažerské zhodnocení 6.1 Připravenost prostředí . . . . . . . . 6.2 Změna podnikových procesů . . . . . 6.3 Způsob pořízení systému . . . . . . . 6.4 Přínosy realizovaného systému . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
27 33 33 37 42 44
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
47 47 48 48 51
Závěr
53
Literatura
55
A Obrazová příloha
57
B Seznam použitých zkratek
69
C Obsah přiloženého CD
71
xii
Seznam obrázků 2.1 2.2
Helios Red - modul reklamace . . . . . . . . . . . . . . . . . . . . . INOVIO - Reklamační řízení . . . . . . . . . . . . . . . . . . . . .
6 7
3.1 3.2 3.3
Business Process Model - reklamace . . . . . . . . . . . . . . . . . Doménový model reklamačního řízení . . . . . . . . . . . . . . . . Reklamace - stavy . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 11 12
5.1 5.2 5.3 5.4 5.5
Databázový model část 1 . . . . . . . Databázový model část 2 . . . . . . . Adresářová struktura webové aplikace Vývojové prostředí MS Studio 2013 . . Struktura projektu v MS Studio 2013
. . . . .
28 29 33 38 39
6.1
Cloudové řešení - cloud computing . . . . . . . . . . . . . . . . . .
49
. . . . .
. . . . .
A.1 Web App - Přihlašovací stránka . . . . . . A.2 Web App - Nová reklamace . . . . . . . . A.3 Web App - Seznam reklamací . . . . . . . A.4 Web App - Zobrazení reklamace . . . . . A.5 Vygenerovaný reklamační protokol v PDF A.6 Web App - Komunikace s pracovníkem . . A.7 Web App - Úprava údajů . . . . . . . . . A.8 Windows App - Seznam reklamací . . . . A.9 Windows App - Nová reklamace . . . . . A.10 Windows App - Zobrazení reklamace . . .
xiii
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . . . . . . .
58 59 60 61 62 63 64 65 66 67
Seznam zdrojových kódů 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12
Reklamace zákazníka - complaints.php . . . . . . . . . . . . . . Reklamace zákazníka - ComplaintsController . . . . . . . . . . Reklamace zákazníka - ComplaintsView . . . . . . . . . . . . . Reklamace zákazníka - /templates/complaints.phtml . . . . . . Reklamace zákazníka - business vrstva . . . . . . . . . . . . . . Reklamace zákazníka - datová vrstva . . . . . . . . . . . . . . . Nový reklamační případ - událost Button_OnClick . . . . . . . Nový reklamační případ - přidání reklamace PresentLayer . . . Nový reklamační případ - přidání reklamace BusinessLayer . . Nový reklamační případ - přidání reklamace DataLayer . . . . Ukázka WebAPI - získání reklamačního protokolu . . . . . . . Ukázka WebAPI - zaslání reklamačního protokolu od webové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
35 35 35 36 36 36 40 40 41 41 43 44
Úvod Dnešní výrobci jakéhokoliv zboží potřebují řešit reklamace svých dosud prodaných produktů. Aby práce spojená s reklamací byla co nejjednodušší a pro všechny strany komfortní, je zcela nezbytný informační systém (dále IS), který by zahrnoval správu reklamačního řízení. Moje práce se bude zabývat řízením procesu reklamace a tvorbou IS, součástí bude také ekonomicko-manažerské zhodnocení. Produkty známých značek se nejčastěji kupují přes prodejce, kteří odebírají zboží od výrobců. Pokud se stane, že zboží potřebujeme reklamovat z důvodu závady, tak je možnost jít přímo za prodejcem, anebo je tu druhá možnost, reklamovat zboží přímo u výrobce v jeho autorizovaném servisu. Druhá možnost je ovšem rychlejší, protože první způsob reklamace přes prodejce je velice zdlouhavý proces, prodejci v 99% případů vadné zboží odešlou výrobci. Jsou výrobci, kteří reklamační proces mají špatně řešený. Spotřebitel někam odešle své zboží a jediná komunikace je možná po telefonu s operátorem, nemá tedy možnost si přes webové rozhraní zjistit stav reklamace, další potřebné informace a spojení s pracovníkem na straně výrobce, který reklamaci řeší je při řešení netypického problému nemožné. Hlavní nevýhoda je, že zákazník nemá žádný přístup do systému a informace zpravidla získá pomocí automatizovaných e-mailových zpráv. Mnou zvolené řešení může využít kterákoliv firma, či organizace, která prodává své produkty koncovým spotřebitelům. IS lze použít nezávisle na ostatních podnikových systémech, protože pak je pouze potřeba implementovat tzv. middleware, který zajistí propojení systémů. K výběru tématu mě motivovala zkušenost z praxe, když jsem reklamoval notebook u známé společnosti, kterou nebudu jmenovat.
1
Kapitola
Cíl práce Cílem bakalářské práce je analýza, návrh a implementace IS pro správu reklamačního řízení, který usnadní řízení přístupu k evidenci a správě reklamací. Součástí práce bude také ekonomicko-manažerské zhodnocení. IS řadíme do kategorie typu CRM (Customer relationship management je systém, pro řízení vztahu se zákazníky, cílem je udržet zákazníka spokojeného), jelikož účastníci systému budou také samotní spotřebitelé. Pro stranu výrobce bude vytvořena desktopová aplikace, přes kterou může pracovník na straně výrobce spravovat reklamaci, a to jak zadat, tak zobrazit veškeré informace spojené s reklamací. Spotřebitel bude mít přístup do systému pomocí webového rozhraní. Celý proces začne tím, že spotřebitel, který zakoupil produkt chce provést reklamaci. V případě, že-li zboží nikdy nereklamoval, je potřeba provést registraci přes webové rozhraní a po té reklamaci zadat do systému. Jakmile je v systému provedena a aktivována registrace, zákazník získá údaje, které budou sloužit pro vstup do IS. Po přihlášení do systému, bude již možné zadat nové reklamace a také je spravovat. Úkolem IS je šetřit lidské zdroje a proces reklamace zautomatizovat. Po zavedení IS není potřeba každou reklamaci řešit telefonicky, vše je možné zadat online. Reklamace může být záruční, pozáruční, nebo mimozáruční. Záleží na typu produktu, který zákazník reklamuje může se jednat o nehmotné či hmotné produkty. Systém bude primárně vyřizovat reklamaci hmotných produktů, například zboží. Po zahájení reklamace je potřeba reklamovaný produkt doručit do místa určení (např. servisní středisko, v případě se jedná např. o zboží). Jednou z možností je přepravní služba, anebo osobně. Reklamační oddělení (pracovník firmy) potvrdí přijetí zboží a nyní je potřeba přidělit konkrétní reklamaci technika, či pracovníka reklamačniho oddělení, který provede likvidaci. Během průběhu reklamace, může spotřebitel kdykoliv zjistit stav reklamace a potřebné informace, také je možnost zahájit komunikaci s pracovníkem, který má danou reklamaci na starost. Může nastat situace, že spotřebitel, který chce reklamovat produkt nemá přístup k internetu (případně nevlastní e-mailovou adresu) a nemá možnost 3
1
1. Cíl práce se do systému registrovat a vše zadat a sledovat elektronicky, pro tyto případy se nabízí zadat reklamaci osobně na pobočce, nebo telefonicky. Pracovník na straně firmy zadá informace do systému a má na výběr, zda-li bude vytvořen elektronický účet pro zákazníka. Reklamaci lze sledovat přes webové rozhraní bez přihlášení a to zadáním čísla reklamace, systém pak zobrazí informace v omezené podobě. Zákazník obdrží vygenerovaný reklamační protokol (RMA). Informační systém není implementován pro konkrétní firmu, součástí práce je obecné řešení s důrazem na standardizaci. Pokud by systém chtěla použít konkrétní organizace, je pravděpodobné, že systém bude potřeba přizpůsobit na míru daným podmínkám a procesům firmy.
4
Kapitola
Analýza současného stavu řešení problematiky Na trhu je současně možnost výběru z široké škály informačních systémů na pomezí ekonomických a ERP (Enterprise resource planning je typ informačního systému, který je schopen pokrýt všechny procesy (řízení, plánování) v organizaci) systémů. Pokud se zaměříme na výrobce např. elektroniky, existuje velká řada firem, které mají proces reklamace řešený nedostatečně. Vadné zboží spotřebitel odešle do autorizovaného střediska v ČR, někdy i do zahraničí. Stav reklamace se spotřebitel dozví formou automatizované mailové zprávy, anebo telefonickou komunikací přes operátora; v případě, že zákazník má s produktem netypický problém, není zde možnost komunikace s pracovníkem, který reklamaci řeší. Pro konečného spotřebitele je daleko komfortnější, když může do systému vstoupit. O podobné problematice a tvorbě informačního systému se zabývá ve své bakalářské práci například [1]. Takto zvolené řešení vidím jako neyhovující, jelikož informační systém je navržen a implementován monolitickou architekturou v podobě jedné webové stránky, která se špatně udržuje. V této kapitole se zaměřím na často používané ekonomické systémy na pomezí ERP a jejich použitelnost pro řízení procesu reklamace ve firmě.
2.1
Kastner STEREO
STEREO je ekonomický software určený pro podnikatele a malé firmy. Nabízí kompletní účetní agendu, včetně modulu pro formuláře zvaný FORM Studio. Software STEREO umí například správu zákazníků, skladu, faktur, účetnictví a podobně. Pokud se zaměříme na reklamační modul, tak jediný způsob řešení, který aplikace nabízí je reklamační protkol, nebo-li formulář v rámci FORM modulu. Ten je možné vyplnit, uložit, případně také vytisknout.[2] 5
2
2. Analýza současného stavu řešení problematiky
Obrázek 2.1: Ukázka Helios Red - modul reklamace
Další nevýhoda je, že systém neumožňuje integraci s jinými systémy a není možné propojení.
2.2
Helios
Známý výrobce informačních systémů Helios nabízí řadu produktů pro malé, střední či velké firmy. Jsou to ekonomické a účetní systémy, ERP či CRM, ale také různá oborová řešení. Systém obsahuje modul pro reklamace, nicméně jak je možné vidět na obr. 2.1 reklamace je pouze interního charakteru a systém nenabízí žádné online rozhraní pro své zákazníky. Není vyloučeno, že IS zasílá informace o stavu reklamace pomocí automatizované e-mailové zprávy (tyto informace už výrobce neuvádí).[3]
2.3
POHODA
Informační systém POHODA je konkurent Heliosu, je také určen pro všechny typy firem. Jak je možné vidět v [4] POHODA také nabízí reklamační modul pro správu reklamačního procesu. Podle online příručky POHODY [5] je vidět, že reklamace je řešena stejným principem jako u IS Helios, zákazník zde také nemá přístup do systému. 6
2.4. INOVIO
Obrázek 2.2: INOVIO - Reklamační řízení
2.4
INOVIO
INOVIO je produkt na trhu, který nabízí organizacím zlepšení a podporu konkrétních procesů. Nabízí jednotlivá softwarová řešení např. pro schvalování došlých faktur, nebo také reklamační řízení. Jak je možné vidět na obrázku 2.2 systém řídí reklamační proces, ale zákazník získá pouze protokol a automatizovanou notifikaci e-mailem. Zde tu opět není možnost jako v předchozích případech, aby zákazník v libovolném čase vstoupil do systému, mohl si zjistit veškeré informace a aktuální stav, nebo také komunikovat s pracovníkem, který reklamaci řeší.[6]
2.5
Hodnocení
Zaměřil jsem se na ekonomický software Kastner STEREO, robustní ERP řešení Helios a POHODA a také inviduální řešení pouze pro řízení procesu reklamace INOVIO. Informace jsou v systému uchovány interně uvnitř firmy, zákazník má šanci získat bližší informace pomocí generovaných e-mailů. Z plno nabízených produktů jsem nenanšel obecné řešení, které by problematiku řešilo a tedy systém plně zahrnul i zákazníka.
7
Kapitola
Analýza Aby bylo možné informační systém realizovat a implementovat, je potřeba provést důkladní analýzu, to znamená v první řadě popsat (případně vymodelovat) typické podnikové procesy, které v organizaci probíhají, dále vytvořit doménový model, specifikaci a požadavky, uživatelské role a také případy užití. Veškerý popis v této kapitole není uvažován vzhledem ke konkrétní firmě, např. popis procesů, specifikace, atd... je psán obecně a je zde snaha o standardizaci.
3.1
Řešení
Přestože existuje plná řada informačních systémů, jak je uvedeno v 2, nepodařilo se najít řešení, které by splnilo všechny požadavky. Jediný způsob řešení je tvorba nového informačního systému, který bude pokrývat typické procesy v organizaci a zahrne i zákazníka, který bude mít přístup do systému například přes webové rozhraní. Navržené řešení pak může využít v podstatě jakákoliv firma, která reklamace musí ze zákona řešit nezávisle na podnikovém systému, který využívá. Ještě se zde nabízí řešení implementovat pouze webové rozhraní, kam bude mít přístup zákazník a to integrovat např. s POHODOU, která modul pro reklamace obsahuje, i to je samozřejmě možné, nicméně bylo by potřeba vytvořit uživatelské rozhraní i pro firmu, kde bude potřeba minimálně spravovat účty pro přístup do webového rozhraní atd., proto je lepší navrhnout a implementovat samotný systém, který bude řídit proces reklamačního řízení a bude řešit výše uvedenou problematiku a pak je teprve vhodné navrhnout automatizovaný middleware, který zajistí integraci dat např. pro POHODU a mnou navržený systém. 9
3
3. Analýza
Obrázek 3.1: Business Process Model - reklamace
3.2
Proces reklamačního řízení
Proces reklamačního řízení začíná tím, že záklazník, který v minulosti zakoupil produkt, chce provést reklamaci. Je potřeba reklamaci nahlásit výrobci (případně autorizovanému partnerovi), který produkt vyrobil. Produkt společně s dokladem o zakoupení je nutné doručit do místa určení výrobci. Zaměstnanec firmy přijme, nebo nepřijme reklamovaný produkt nezávisle na datu zakoupení, jelikož existují produkty, kde na některé případy je záruka například doživotní, či délší jak 24 měsíců, nebo také i kratší (většinou nastává případ, že na celý produkt je celkem záruka 24 měsíců). Pak přijde na řadu další část a to je řešení dané reklamace. Pracovník, který má na starost reklamaci musí určit, zda-li popisované vady jsou v záruční lhůtě, mimozáruční či pozáruční. Pokud se jedná o mimozáruční, nebo pozáruční variantu, pak je jediná možnost řešení a to placená oprava, zákazník s tímto úkonem musí souhlasit. Jestliže pracovník určí, že se jedná o projevení vady v záruce, pak nastává bezplatná výměna, oprava, nebo vrácení peněz (záleží jaké jsou reklamační podmínky konrétní firmy v souladu se zákonem). Opravené, či vyměněné zboží je vrá10
3.3. Doménový model
Obrázek 3.2: Doménový model reklamačního řízení
ceno zákazníkovi. Celý proces reklamačního řízení je vymodelován pomocí diagramu na obr. 3.1 Musíme také uvažovat situaci, kdy produkt byl zakoupen přes prodejce, zde se v drtivé většině případů reklamace posílají opět výrobci. Pro zákazníka, jako spotřebitele je daleko výhodnější reklamovat produkt u výrobce.
3.3
Doménový model
Doménový, nebo-li také jinak nazývaný konceptuální model reklamačního řízení je vymodelován na obr. 3.2 za účelem analýzy specifikace a požadavků pro informační systém. Je potřeba podotknout, že se nejedná o přesný model určen pro implementaci, ale o myšlenkové znázornění objektů a vazeb mezi nimi, které v doméně probíhají.
3.3.1
Stavy reklamace
Na obr. 3.3 je možné vidět diagram stavů, ve kterých se může konkrétní reklamace nacházet. Reklamace může mít tyto stavy: Nová Nová reklamace, o kterou požádal zákazník s cílem reklamovat vadný produkt. Čekání na doručení vadného produktu. 11
3. Analýza
Obrázek 3.3: Reklamace - stavy
Čekání na pracovníka Reklamace je zaevidována na straně firmy a čeká se na přidělení pracovníka, který reklamaci vyřeší. Firma již obdržela reklamovaný produkt. Řešení Zaměstnanec firmy je přidělen ke konkrétní reklamaci, reklamace je ve fázi řešení. Vyřešena Reklamační případ je vyřešen (pro zákazníka kladně či záporně). Zrušena V případě, že zákazník nahlásí reklamaci a zboží nedoručí, firma označí reklamační případ jako zrušený.
3.4
Funkční požadavky
Na základě aktuálního stavu řešení, popisu procesu reklamačního řízení a doménového modelu jsou stanoveny funkční požadavky na nový informační sys12
3.4. Funkční požadavky tém.
3.4.1
Správa reklamačních případů
Systém bude umět zadat, uchovat a zobrazit reklamace firmy. Pro každou reklamaci bude potřeba uchovat následující údaje: 1. unikátní číslo reklamačního případu 2. údaje o zákazníkovi, který reklamuje produkt 3. doklad o koupi (paragon, záruční list, faktura, výpis z bankovního účtu) a datum 4. preferovaný způsob řešení (oprava, výměna, vrácení peněz) 5. název a typ produktu 6. číslo (sériové) reklamovaného produktu 7. popis vady na reklamovaném produktu 8. stavy reklamace (nová, čekání, řešení, vyřešený, zrušený) 9. výsledek reklamace (otevřený, uzavřený) 10. typ reklamace (záruční, pozáruční, mimozáruční) 11. jméno pracovníka, který je ze reklamaci zodpovědný 12. vyjádření pracovníka (technika) k reklamaci a způsob řešení Zadat reklamační případ bude moci pracovník firmy na základě podání reklamace od zákazníka (zákazník může zboží reklamovat např. osobně někde na pobočce). Pracovník firmy, který bude reklamaci řešit bude v systému určovat stav reklamace, výsledek reklamace, typ reklamace a také vyjádření a způsob řešení. Pokud se bude jednat o placenou opravu produktu, je potřeba souhlas zákazníka. Při každé změně reklamačního případu bude zaslán zákazníkovi e-mail s informacemi, že došlo ke změně (samozřejmě pokud je e-mail vyplněn).
3.4.2
Správa zákazníků
Systém bude uchovávat zákazníky, které již po zavedení systému někdy reklamovali, anebo reklamují produkt. Uchovány budou následující údaje: 1. jméno 2. příjmení 13
3. Analýza 3. adresa 4. kontakt 5. e-mail Každá reklamace bude určena konkrétním zákazníkem.
3.4.3
Webové rozhraní pro zákazníka
Zákazník bude mít přístup do systému přes webové rozhraní. Bude možné provést online registraci, kterou bude nutné aktivovat přes e-mail, aby nedošlo k situaci, že se na stránce budou registrovat roboti. Pokud zákazník nemá přístup k internetu, reklamaci provede osobně, nebo telefonicky a informace do systému zadá pracovník firmy. Ten bude mít možnost vytvořit, nebo nevytvořit přihlašovací účet (pro konkrétního zákazníka) do systému k webovému rozhraní. Na webové rozhraní pro zákazníky jsou kladeny další požadavky: 1. systém bude umožňovat zákazníkům zadávat přes webové rozhraní nové reklamace 2. zákazníkům zobrazit veškeré informace spojené s jejich reklamací 3. ke každé reklamaci IS umožní vzájemnou komunikaci zákazníka s pracovníkem firmy, který byl k reklamaci přidělen 4. možnost zobrazení stavu reklamace (bez přihlášení do systému) v omezené podobě a to jen na základě čísla reklamace 5. zákazník může změnit svoje údaje (jméno, příjmení, adresa, kontakt, e-mail) včetně hesla 6. v případě, že e-mail s aktivací nedorazí, systém umožní opětovné zaslání 7. pokud zákazník zapomene, nebo ztratí přístupové heslo, systém umožní opětovné zaslání
3.4.4
Desktopová aplikace pro firmu
Aby firma mohla se systémem pracovat, je potřeba vytvořit desktopovou aplikaci s uživatelským rozhraním, které bude přátelské k účastníkům. Do systému se budou zaměstnanci přihlašovat pomocí loginu a hesla. Když se aplikace zapne proběhne ověření a pokud jsou údaje zadány špatně, systém nepustí uživatele do aplikace.
14
3.4. Funkční požadavky Na desktopovou aplikaci jsou kladený následující požadavky: 1. cílem je zajistit kompletní správu a to zadávání a úpravy všech reklamačních případů 2. správa všech zákazníků spojených s reklamací 3. možnost vytvořit přihlašovací účet k zákazníkovi, který jej nemá 4. možnost přidělení konkrétního pracovníka k dané reklamaci 5. možnost komunikace všech pracovníků se zákazníkem skrz reklamační případ 6. přidělení nové reklamace k již existujícímu zákazníkovi
3.4.5
Sledování reklamovaného zboží
Informační systém bude uchovávat informace o reklamovaném produktu. A to například: 1. čekání na přijetí reklamovaného zboží 2. zboží přijato na reklamační oddělení 3. zboží ve fázi reklamace 4. zboží odesláno zpět zákazníkovi, nebo připraveno k vyzvednutí na pobočce Zákazník zobrazí informace ve webové aplikaci. Zaměstnanci reklamačního oddělení budou mít možnost kompletní správy v desktopové aplikaci.
3.4.6
Správa systémových proměnných
V systému budou při instalaci uloženy, tzv. systémové proměnné, které budou uchovávat hodnoty a sloužit např. pro výpis informací, nebo splnění různých podmínek, protože každá firma může mít jiné informace. Hodnoty bude možné za běhu systému i změnit. Jsou to například: 1. proměnné, které uchovají informace, přes které se aplikace připojí do datového úložiště 2. časový limit do kdy musí být doručen produkt k reklamaci od založení reklamace 3. data sloužící pro synchronizaci webové aplikace a desktopové aplikace (integrace bude pravděpodobně vhodná přes datovou úrověň) 4. SMTP informace, přes který se budou odesílat automatizované e-mailové zprávy 15
3. Analýza
3.4.7
Generování dokumentů ve formátu pdf
Systém bude umět generovat reklamační protokol (RMA). Informace v RMA protokolu budou stejné, jako v kapitole 3.4.1, jinými slovy se jedná pouze o převedení informací o reklamaci do pdf dokumentu. Dokumenty bude systém umět generovat v libovolném čase. Zákazník bude mít možnost (po přihlášení do systému) rma protokol kdykoliv nechat zaslat na e-mail. Pracovník na straně firmy bude také mít reklamační protokol k dispozici, protože zákazník může zboží reklamovat osobně. RMA protokol bude generován v libovolném čase i po vyřešení reklamačního případu. Na začátku reklamace bude RMA vyplněn jen z části, v konečné fázi (reklamace je ve stavu vyřešena) bude prokol úplný.
3.5
Uživatelské role
Každý uživatel v systému bude mít roli a z toho plynou i omezené, či neomezené pravomoce.
3.5.1
Neregistrovaný zákazník
Jedná se o osobu, která má aktuálně u firmy reklamační případ, ale zákazník nemá přihlašovací údaje do systému, protože např. nemá e-mailovou adresu. Neregistrovaný zákazník zjistí stav reklamace v omezené podobě pomocí webového rozhraní na základě čísla reklamace.
3.5.2
Registrovaný zákazník
Osoba, která reklamuje či reklamovala produkt u firmy. Bude mít přístup do systému skrz webové rozhraní, dále možnost vytvoření nových reklamací a také sledování informací.
3.5.3
Pracovník firmy (zaměstnanec)
Pracovník firmy používající informační systém. Bude se jednat o skupinu uživatelů, kteří mají do systému přístup. Budou mít veškeré pravomoce co se týče správy reklamací a zákazníků. V aplikaci může změnit tyto nastavení: 1. proměnné pro připojení do datového úložiště 2. svoje přihlašovací jméno a heslo
3.5.4
Systémový uživatel
Pracovník ve firmě, který bude mít všechny pravomoce jako běžný zaměstnanec, ale ještě navíc bude mít tyto pravomoce: 16
3.6. Případy užití 1. měnit časový limit do kdy musí být doručen produkt k reklamaci od založení reklamace 2. možnost správy přihlašovacích údajů do desktopové aplikace pro zaměstnance
3.6 3.6.1
Případy užití Webové rozhraní pro zákazníka
Kapitola popisuje typické scénáře při použítí webového rozhraní, které je určeno pro zákazníky firmy. 3.6.1.1
Registrace zákazníka
Umožňuje zákazníkovi se přes webové rozhraní registrovat do systému. Na základě registrace získá uživatel přístupové údaje. 1. Začíná v okamžiku, kdy zákazník se chce registrovat přes webové rozhraní do systému za účelem zadání nové reklamace. 2. Uživatel klikne na tlačítko registrace. 3. Vyplní potřebné údaje jako je jméno, heslo, e-mail, adresa, kontakt a klikne na potvrzovací tlačítko. 4. Pokud nastane případ, že v systému již uvedená e-mailová adresa existuje, systém vypíše chybu. 5. V opačném případě přijde na e-mail zpráva s aktivačním kódem, který zákazník zadá na uvedeném odkazu a tím dojde k aktivaci účtu. 3.6.1.2
Přihlášení zákazníka
Umožní zákazníkovi se přihlásit do systému přes webové rozhraní. 1. Scénář začíná, když zákazník má již vytvořenou a aktivovanou registraci a chce se do systému přihlásit pomocí webového rozhraní. 2. Uživatel na úvodní stránce vyplní přihlašovací údaje a to e-mail s heslem, po té klikne na tlačítko přihlásit se. 3. Aplikace provede verifikaci uživatele a v případě, že li jsou údaje zadané správně, systém uživatele přihlásí. 4. Pokud jsou přihlašovací údaje zadané chybně, pak systém vypíše chybovou hlášku. 17
3. Analýza 3.6.1.3
Odhlášení zákazníka
Webové rozhraní umožní zákazníkovi se ze systému odhlásit. 1. Případ nastává, kdy zákazník je v systému již přihlášen a chce se odhlásit. 2. Uživatel klikne na tlačítko (odkaz) odhlásit se. 3. Aplikace uživatele odhlásí a zobrazí mu úvodní stránku, kde je možné se přihlásit. 3.6.1.4
Vytvoření nové reklamace zákazníkem
Zákazník vytvoří v systému pomocí webového rozhraní nový reklamační případ. 1. Scénář začíná v okamžiku, kdy zákazník je již přihlášen v systému a chce zadat novou reklamaci svého produktu. 2. Zákazník klikne na tlačítko zadat novou reklamaci. 3. Systém zobrazí formulář, kde zákazník vyplní potřebné údaje, jako číslo reklamovaného produktu, popis vady, preferovaný způsob řešení, údaje (datum, číslo) o dokladu zakoupení zboží (faktura, záruční list, paragon, výpis z účtu). 4. Po vyplnění údajů klikne na tlačítko vytvořit novou reklamaci. 5. Proběhne kontrola zadaných údajů a pokud nejsou všechny informace vyplněny správně, systém zahlásí chybu. 6. V opačném případě je reklamace uložena do systému a je ve stavu nová. 3.6.1.5
Zobrazení informací o reklamaci
Zákazník zborazí informace, které se vztahují k jeho reklamacím. 1. Scénář začíná ve chvíli, kdy zákazník je přihlášen do systému a chce zobrazit informace k reklamačním případům, které aktuálně probíhají, anebo již proběhly. 2. Zákazník klikne na tlačítko zobrazit reklamace a zobrazí se mu seznam všech reklamací (vypsány jsou jen klíčové informace), které jsou seřazené podle datumu založení reklamace. 3. Pokud zákazník chce zobrazit podrobnosti k reklamačnímu případu, pak je potřeba kliknout u konkrétní reklamace na tlačítko zobrazit detaily a systém zobrazí uživateli kompletní informace. 18
3.6. Případy užití 3.6.1.6
Komunikace s pracovníkem
Umožní zobrazit a napsat zprávy směrem k pracovníkům reklamačního oddělení, kteří mají reklamační případ na starost. 1. Scénář začíná ve chvílí, kdy zákazník si zobrazí detaily o reklamaci ve webové aplikaci a chce komunikovat s pracovníkem reklamačního oddělení. 2. Uživatel klikne na tlačítko komunikace s pracovníkem. 3. Uživateli se zobrazí seznam zpráv spojených s reklamací. 4. Pokud chce zákazník napsat zprávu, je potřeba vyplnit editační pole a kliknout na tlačítko odeslat zprávu. 3.6.1.7
Získání reklamačního protokolu
Zákazník, nebo-li uživatel webového rozhraní získá reklamační protokol ve formátu PDF. 1. Scénář začíná ve chvílí, kdy zákazník si zobrazí detaily o reklamaci ve webové aplikaci a chce získat reklamační protokol ve formátu PDF. 2. Zákazník klikne na tlačítko získat reklamační protokol. 3.6.1.8
Zapomenuté, nebo ztracené heslo
Systém uživateli webového rozhraní vygeneruje nové heslo. 1. Uživatel klikne na tlačítko zapomenuté heslo. 2. Do editačního pole zákazník vyplní svůj e-mail a svoje příjmení. 3. Pokud systém vyhodnotí verifikaci jako úspěšnou, na e-mailovou adresu se zašle nové heslo. 3.6.1.9
Opětovné zaslání aktivačního klíče
Systém uživateli zašle aktivační odkaz s klíčem pro aktivaci účtu. 1. Uživatel klikne na nepřišla mi aktivace. 2. Do editačního pole zákazník vyplní svůj e-mail a svoje příjmení. 3. Pokud systém vyhodnotí verifikaci jako úspěšnou, na e-mailovou adresu se zašle aktivační link s novým klíčem. 19
3. Analýza 3.6.1.10
Změna osobních údajů
V systému proběhne změna osobních údajů. 1. Scénář začíná v okamžiku, kdy uživatel se rozhodne změnit osobní údaje a je potřeba, aby byl přihlášen. 2. V editačních polích bude možné změnit jméno, příjmení, e-mail, adresu, kontakt a případně také heslo. 3. Změny se potvrdí kliknutím na tlačítko změnit údaje.
3.6.2
Desktopová aplikace pro firmu
Kapitola popisuje scénáře při použití aplikace, která je určena výrobci produktů. 3.6.2.1
Změna přihlašovacích údajů pracovníka
Umožní zadat informace, které budou budou sloužit pro zalogování pracovníka do aplikace. 1. Scénář začíná ve chvíli, kdy pracovník chce nastavit přihlašovací údaje do desktopové aplikace. 2. Uživatel v menu klikne na ikonu nastavení. 3. Do editačního pole pracovník vyplní login a heslo. 4. Klikne na tlačítko uložit, tím dojde k uložení údajů. 5. Kliknutím na tlačítko ověřit dojde k ověření údajů a vypíše se pomocí dialogu informativní hláška. 3.6.2.2
Zobrazení všech reklamací
Umožní zobrazit aktuální, nebo již proběhlé rekllamace v systému. 1. Scénář začíná ve chvíli, kdy pracovník chce zobrazit všechny reklamace. 2. Kliknutím na tlačítko správa reklamací se vypíše seznam reklamačních případů. Reklamace bude možné filtrovat dle parametrů (např. i reklamace které jsou již expirované). 20
3.6. Případy užití 3.6.2.3
Přidání nové reklamace
Umožní přidat do systému novou reklamaci a zároveň případně i nového zákazníka. 1. Scénář začíná ve chvíli, kdy pracovník chce přidat do systému nový reklamační případ. 2. Uživatel klikne v menu na správa reklamací a po té na tlačítko zadat novou reklamaci. 3. V systému bude potřeba vybrat již existujícího zákazníka, nebo přidat nového zákazníka (jméno, příjmení, adresa, kontakt, případně email). E-mail bude nepovinný atribut, protože ne každý zákazník vlastní emailovou adresu. Součástí bude také možnost vytvořit účet do webového rozhraní, pokud je vyplněn unikátní e-mail. 4. Systém zobrazí formulář, kde pracovník vyplní potřebné údaje, jako číslo reklamovaného produktu, popis vady, preferovaný způsob řešení, údaje (datum, číslo) o dokladu zakoupení zboží (faktura, záruční list, paragon, výpis z účtu). Součástí formuláře bude možnost zobrazit ve formátu pdf reklamační protokol ihned po vytvoření. 5. Uživatel klikne na tlačítko vytvořit reklamaci a aplikace zobrazí v dialogu informace o výsledku. 3.6.2.4
Vytvoření webového účtu k již existujícímu zákazníkovi
Umožní vytvořit účet do webového rozhraní pro zákazníka, který již v systému existuje. 1. Scénář začíná ve chvíli, kdy pracovník chce vytvořit k již existujícímu zákazníkovi přístup do webového rozhraní. 2. Pracovník klikne v menu na správa zákazníků. 3. Uživatel zobrazí detaily o zákazníkovi. 4. Pokud není u zákazníka vytvořen účet, systém zobrazí tlačítko vytvořit účet do webového rozhraní. 5. Uživatel klikne na tlačítko vytvořit účet do webového rozhraní a systém zobrazí dialog, zda skutečně se účet vytvořil, či nikoliv. 6. Systém zašle na e-mail zákazníka vygenerované heslo a aktivační odkaz. 21
3. Analýza 3.6.2.5
Získání reklamačního protokolu
Umožní získat reklamační protokol k reklamaci, která již v systému existuje. 1. Scénář začíná ve chvíli, kdy pracovník chce získat reklamační protokol ve formátu pdf. 2. Systém zobrazí všechny reklamace a uživatel klikne v menu na tlačítko správa reklamací a zobrazí detaily konkrétní reklamace. 3. Uživatel klikne na tlačítko získat reklamační protokol. 4. Systém vygeneruje a spustí pdf dokument reklamačníh protokolu. 3.6.2.6
Změna informací k reklamačnímu případu
Umožní změnit informace o reklamaci jako např. ty, které zadal zákazník, nebo řešení reklamace. ID a datum reklamace nebude možné editovat. 1. Scénář začíná ve chvíli, kdy pracovník chce změnit informace k reklamačnímu případu. 2. Systém zobrazí všechny reklamace a uživatel klikne v menu na tlačítko správa reklamací a aplikace zobrazí detaily konkrétní reklamace. 3. Informace budou zobrazena v přívětivém formuláři a bude možná jejich editace. 4. Pro uložení klikne uživatel na tlačítko uložit a systém uloží informace. 3.6.2.7
Změna časového limitu pro expiraci nové reklamace
Umožní změnit systémovou proměnou-časový limit, který určí do kdy musí být doručen produkt k reklamaci od jejího založení. 1. Scénář začíná ve chvíli, kdy pracovník chce změnit systémovou proměnnou. 2. Aplikace musí ověřit, zda zalogovaný pracovník je systémový administrátor, po té zobrazí možnost systémového nastavení. 3. V menu uživatel vybere možnost nastavení - systémová nastavení. 4. Systém zobrazí aktuální časový limit s možností editace, kde uživatel může změnit hodnotu. 5. Po kliknutí na tlačítko uložit, systém uloží informaci do databáze a zobrazí dialog, zda byla hodnota uložena.
22
Kapitola
Vývojové nástroje V této kapitole popíšu vývojové nástroje, které použiji pro realizaci informačního systému. Vývojové nástroje jsem zvolil na základě zkušenosti a oblíbenosti mezi vývojáři. Na internetu a v nápovědě lze najít širokou škálu ukázkových příkladů a tutoriálů jak s daným nástrojem pracovat.
4.1
HTML
HTML (Hyper Text Markup Language) je značkovací jazyk pro popis webových dokumentů (webové stránky) a obashuje značkovací sadu. Stránka v HTML se skládá z tagů, kde každý tag je specifický a každá značka určuje jiný obsah dokumentu. Pomocí HTML můžeme vkládat nadpisy, odstavce, formuláře, odkazy, obrázky a podobně.[7]
4.2
CSS
CSS (Cascading Style Sheets) v překladu kaskádové styly. CSS styly definují jak má webová stránka vypadat. Přesněji řečeno jak budou elementy v prohlížeči uživatele zobrazeny. CSS kód bývá zpravidla umístěn v externím souboru ve formátu .css a do HTML souboru se připojuje. Jeden CSS soubor je možné připojit do více HTML souborů a tím zajistíme jednotný vzhled pro více stránek. Výhody v použití CSS stylů je přehlednost a časová úspora, jelikož html soubor zůstane zachován beze změn a vzhled definujeme v odlišném souboru. Pomocí kaskádových stylů je možné měnit písmo, obrázek, odstavec, tabulku, nadpisy a podobně.[8]
4.3
Bootstrap
Bootstrap framework je sada CSS, javascriptových a font souborů, které slouží vývojáři webových aplikací. Obsahuje předpřipravené designy tlačítek, tabu23
4
4. Vývojové nástroje lek, textů, formulářů a plno dalšího. Pomocí bootstrapu je možné jednoduše a rychle vytvořit hezky a moderně vypadající webovou stránku, aniž by dotyčný vývojář musel být grafik. Výrobce poskytuje širokou škálu typických examplů a použití je velice snadné.[9]
4.4
PHP
PHP (Hypertext Preprocessor) je skriptovací jazyk určený pro tvorbu dynamických webových stránek. PHP soubory generují např. obyčejný HTML text, ale prováděny jsou na straně webového serveru. Krom toho PHP umí pracovat s databázemi, soubory, sbírat a odesílat data, anebo také šifrovat. PHP je spustitelný na různých platformách, podporuje širokou škálu databází, je zdarma a také je kompatibilní se všemi webovými servery.[10]
4.5
MySQL
Jedná se o databázový server, sloužící k uložení dat. Využívá standarty SQL a je velice často používána pro webové aplikace. Použití je možné u velkých i malých aplikací. MySQL poskytuje knihovny pro širokou škálu programovacích jazyků (jejich vývojové prostředí), z toho plyne že s databází můžeme pracovat prakticky kdekoliv. Velice často se MySQL instaluje spolu s aplikací phpMyAdmin, která je napsaná v php a obsahuje grafické prostředí pro práci s databázovým serverem. Je zde možné spravovat tabulky, dotazy, oprávnění uživatelů a také veškerá další nastavení.[11]
4.6
C# .NET
C# je moderní, elegantní, bezpečný a objektově orientovaný jazyk, který umožňuje vývojářům vytvářet bezpečné a robustní aplikace, které pracují na .NET Framework. Vývojové prostředí podporující jazyk C# je Microsoft Visual Studio. V C# je možné tvořit i desktopové aplikace, hlavní výhodou je zabudovaný modul pro návrh GUI (grafické rozhraní pro uživatele) aplikace. Aplikace pracují pouze na platformě Windows, ale protože se jedná o stejného výrobce, tak je zde zajištěna perfektní kompatibilita. .NET nástroje jsou zcela určitě vhodné pro tvorbu informačních systémů.[12]
4.7
PHP Mailer
PHP Mailer je knihovna v PHP obsahující nástroje pro odesílání e-mailových zpráv. Je možné nastavit konkrétní SMTP server s přihlašovacími údaji, přes který se e-mail odešle. Nástroj je zcela vhodný pro automatické generování zpráv a jejich zaslání na příslušný e-mail.[13] 24
4.8. mPDF
4.8
mPDF
mPDF je knihovna napsaná v PHP, která umí vygenerovat z HTML souborů PDF dokument. Takto vytvořené řešení je ideální na tvorbu reklamačních protokolů pro zákazníky. Vzhled PDF dokumentů je možné ovlivnit pomocí CSS souborů.[14]
25
Kapitola
Realizace Kapitola se zabývá popisem implementace informačního systému pro správu reklamačního řízení. Celý informační systém se skládá ze tří částí: 1. Webová aplikace pro zákazníky 2. Desktopová aplikace pro pracovníky firmy 3. Databázový model pro data
5.1
Databázový model
Webová a desktopová aplikace získávají a ukládají data do databáze MySQL. Každá tabulka je typu InnoDB, kde hlavní výhoda je podpora cizích klíčů, která například u MySQL MyISAM není možná. Na obrázku 5.1 a 5.2 je pomocí diagramu vymodelován databázový model informačního systému. Ve třídách je použit datový typ ENUM, kde se jedná o výčet prvků s pevně danou množinou. Každý prvek reprezenuje konkrétní vyjádření. Stavy reklamace 1. new - stav nové reklamace ihned po založení, jedná se o inicializační stav reklamačního případu 2. waiting_employee - zboží je již doručeno na pobočku a čeká se na přidělení pracovníka 3. inprogress - pracovník k reklamaci je již přidělen a reklamace je ve fázi řešení 4. solved - reklamace již vyřešena např. záruční oprava, pozáruční oprava, apod. 5. canceled - reklamační případ je zrušen a nebyl řešen 27
5
5. Realizace
Obrázek 5.1: Databázový model část 1
28
5.1. Databázový model
Obrázek 5.2: Databázový model část 2
Výsledek reklamace 1. opened - reklamace je otevřena a s reklamačním případem je možné provádět změny 2. closed - reklamace je uzavřena Typ reklamace 1. warranty - jedná se o záruční případ 2. nonwarranty - mimozáruční případ (např. vada, či problém není na straně výrobce) 3. afterwarranty - pozáruční případ (např. na vadu je záruka pouze 2 roky) Stavy reklamovaného zboží 1. waiting_accept - zboží je ve stavu, kdy se čeká na přijetí 2. accepted - zboží je přijato 3. inprogress - zboží se reklamuje 4. sent - zboží odesláno zpět zákazníkovi 5. waiting_pickup - zboží je připraveno na vyzvednutí zákazníkem Způsoby řešení reklamace 29
5. Realizace 1. repair - oprava zboží 2. change - výměna zboží 3. money_back - vrácení peněz
5.1.1
Třída customers
Jedná se o třídu, která reprezentuje zákazníky, kteří reklamují, nebo reklamovali produkt. 1. customer_id - identifikační číslo zákazníka v procesu reklamačního řízení 2. name - jméno zákazníka 3. surname - příjmení zákazníka 4. address - adresa zákazníka 5. contact - telefonní kontakt 6. email - kontaktní e-mail
5.1.2
Třída users
Entita ukládá přihlašovací účty do webové aplikace ke konkrétním zákazníkům. 1. user_id - identifikátor přihlašovacích účtů 2. passwd - hash otisk hesla 3. activate_sign - unikátní aktivační klíč pro aktivaci účtu 4. activated - informace, zda je účet aktivován 5. customer_id - cizí klíč na zákazníka, ke kterému se webový účet vztahuje
5.1.3
Třída employees
Entita ukládá údaje o zaměstnancích reklamačního oddělení, kteří mají do systému přístup. 1. employee_id - identifikační číslo 2. employee_name - jméno pracovníka 3. login - přihlašovací login do systému 4. passwd - hash otisk hesla 5. system_admin - informace, jestli je pracovník administrátorem 30
5.1. Databázový model
5.1.4
Třída complaints
Entita uchovává data o reklamacích, které jsou v informačním systému. 1. complaint_id - unikátní 10 místné identifikační číslo reklamačního případu ze znaků 0-9 2. c_state - udává výčet prvků, ve kterých se reklamace může nacházet, jsou to hodnoty new, waiting_employee, inprogress, inprogress, canceled 3. result - obsahuje výčet prvků opened, closed výsledků reklamace 4. c_type - hodnota určuje typ reklamace warranty, nonwarranty, afterwarranty 5. goods_state - atribut je zaměřen na stav reklamovaného zboží, které se může nacházet ve stavech waiting_accept, accepted, inprogress, sent, waiting_pickup. Typ atributu je ENUM 6. customer_prefer - preferovaný způsob řešení zákazníka ENUM(repair, change, money_back) 7. solution - způsob řešení reklamace, který určuje pracovník, hodnoty jsou ENUM(repair, change, money_back) 8. document - hodnota určuje jaký doklad o koupi určuje reklamaci, příkladem může být faktura, záruční list, paragon, výpis z bankovního účtu 9. document_number - číslo dokladu o koupi 10. document_date - datum zakoupení zboží 11. customer_id - cizí klíč na zákazníka, který reklamuje produkt 12. product_number - číslo vadného produktu 13. description - popis problému, či vady 14. create_date - datum založení reklamace 15. employee_id - cizí klíč na pracovníka reklamačního oddělení, který má reklamaci na starost 16. comment - komentář od pracovníka k reklamaci 31
5. Realizace
5.1.5
Třída messages
Entita ke každé reklamaci uchovává všechny komunikace mezi zákazníkem a pracovníkem. 1. message_id - identifikační číslo zprávy 2. complaint_id - id reklamace, ke které se komunikace týká 3. employee_id - id pracovníka, který zprávu napsal. Pokud hodnota je null, automaticky se bere, že zprávu napsal zákazník, který založil reklamaci 4. message - text zprávy 5. message_date - datum a čas, kdy byla zpráva napsána
5.1.6
Třída api
Třída uchovává tzv. requesty na webovou aplikaci informačního systému, kterou využívá desktopová aplikace. 1. api_key - klíč, kterým se aplikace verifikuje 2. what - jakou akci má webové rozhraní vykonat. jedná se o prvky: get_rma_pdf, create_user 3. params - parametry k požadavku, který se má vykonat
5.1.7
Třída settings
Třída reprezentuje systémová nastavení informačního systému. Momentálně je možné pouze nastavit jeden prvek. 1. var - atribut obsahuje název parametru, jedná se o výčet prvků: timetolive_new_complaint 2. value - hodnota pro parametr
32
5.2. Třívrstvá architektura webové a desktopové aplikace www .................................. kořenový adresář webové aplikace architecture .......... zdrojové kódy vrstvené architectury aplikace BusinessLayer ......... servisní třídy aplikace pro business logiku classes.............................základní třídy DTO objektů DataLayer.....................datová vrstva pro práci s databází Factory Factory.php................továrna singleton na instance tříd PresentLayer ................. prezentační vrstva dle vzoru MVC Controller View config config.php ........................... nastavení webové aplikace external_libs ........... externí knihovny např. mPDF, PHPMailer include autoload.php ....................... obsahuje autoload pro třídy pdf_generator...........html a css šablona pro reklamační protokol system...........................adresář pro zalogovaného uživatele templates...........................html šablony, které zobrazí PL *.phtml index.php .................................... indexový php soubor Obrázek 5.3: Adresářová struktura webové aplikace
5.2
Třívrstvá architektura webové a desktopové aplikace
Datová vrstva (DAO) je zodpovědná za práci nad datovým úložištěm. Má na starost volání dotazů typu SELECT, INSERT, UPDATE, DELETE. Vrstva zajistí uložení a získání dat z MySQL databáze. V případě, že by došlo ke změně databáze, proběhne pouze úprava datové vrstvy a ostatní části kódu zůstanou bezezměn. Business vrstva obsahuje třídy a metody, které realizují chování aplikace z pohledu business logiky. Jedná se o můstek mezi prezentační a datovou vrstvou. Data sbírá a předává prezentační i datové vrstvě. Probíhají zde veškeré výpočty, zpracování, rozhodování a podobně. Prezentační vrstva zajišťuje prezentaci dat a informací uživateli v přívětivé podobě a naopak sbírá data od uživatele a předává je business vrstvě.
5.3
Popis webové aplikace
Webové rozhraní je určeno pro zákazníky, kteří mají v systému reklamační případ. Architektura aplikace je zvolena vrstvená a skládá se ze 3 vrstev pre33
5. Realizace zentační, business a datová. Na obrázku 5.3 je znázorněna adresářová struktura webové aplikace.
5.3.1
/architecture/classes
Adresář obsahuje třídy (jinými slovy strukturované proměnné) určeny pro přenos mezi vrstvami. Jedná se o třídy Complaint, Customer, Message, ApiRequest.
5.3.2
/architecture/DataLayer
Zde jsou umístěny soubory *DAO.php pro práci s databázovou vrstvou. Třídy mají na starost získávání a ukládání dat do MySQL databáze. Data jsou předány a získány od business vrstvy.
5.3.3
/architecture/BusinessLayer
Obsahuje soubory *Manager.php které mají na starost zpracování dat, rozhodování a veškeré výpočty. Data jsou předány a získány od prezentační a datové vrstvy.
5.3.4
/Factory/Factory.php
Obsahuje třídu Factory, která zajistí správu instancí všech objektů. Má na starost i připojení a odpojení od databáze, datové vrstvy si pouze vyžádají instnanci. Návrhový vzor je singleton (jedna instance v celém programu).
5.3.5
/architecture/PresentPlayer/Controller
Třída *Controller má na starost volání metod třídy *View, kterou získá v konstruktoru. Při volání metody Action(...) jí jsou předány proměnné, které by měla šablona *.phtml mít zavedenou a případně ji použít k výpisu. Více v ukázce 5.3.10
5.3.6
/architecture/PresentPlayer/View
Třída *View má na starost vypsání šablony *.phtml, kterou jí předá třída *Controller spolu s ostatníma proměnnými.
5.3.7
/templates/*.phtml
Soubory obsahují HTML stránky, které jsou prezentační vrstvou zobrazeny uživateli. Jedná se o veškeré uživatelské rozhraní resp. výpisy, menu, formuláře, tlačítka a podobně. 34
5.3. Popis webové aplikace
5.3.8
/config/config.php
V souboru jsou uvedeny data pro připojení do MySQL databáze, dále SMTP data mailového serveru pro odesílání e-mailových zpráv.
5.3.9
/system
Adresář přístupný zalogovaným uživatelům webové aplikace. Obsahuje soubory jako např. complaints.php, profile.php, newcomplaint.php apod.
5.3.10
Ukázka zdrojových kódů výpisu reklamací
Ukázka implementace zobrazení všech reklamací uživateli na adrese /system/complaints.php kliknutím na tlačítko zobrazit reklamace. Jedná se o průřez částí ze zdrojového kódu z hlediska klíčové funkčnosti a použití architektury aplikace. $Service = Factory :: getInstance () - > buildComplaint (); $complaints = $Service - > G e t C o m p l a i n t s B y E m a i l ( $param ); $View = new ComplaintsView (); $Controller = new C o m p l a i n t s C o n t r o l l e r ( $View ); echo $Controller - > Action ( $complaints ); Zdrojový kód 5.1: Reklamace zákazníka - complaints.php public function Action ( $complaints ){ $data = .... return $this - > ComplaintsView - > render ( ’ ../ templates / complaints . phtml ’ , $complaints , $data ); } Zdrojový kód 5.2: Reklamace zákazníka - ComplaintsController public function render ( $path , $complaints , $data ){ ob_start (); require ( $path ); return ob_get_clean (); } Zdrojový kód 5.3: Reklamace zákazníka - ComplaintsView
35
5. Realizace
< html > < head > < meta charset = " UTF -8 " > < body > < div > GetAttribute (); ? > Zdrojový kód 5.4: Reklamace zákazníka - /templates/complaints.phtml public function G e t C o m p l a i n t s B y E m a i l ( $e ){ if (! filter_var ( $e , F I L T E R _ V A L I D A T E _ E M A I L )) return null ; $ComplaintDAO = $this - > factory - > Buil dCompl aintDA O (); $complaints = $ComplaintDAO - > Ge t C om p l a in t s By M a il ( $e ); if ( count ( $complaints ) == 0) return null ; else return $complaints ; } Zdrojový kód 5.5: Reklamace zákazníka - business vrstva public function G e tC o m pl a i nt s B yM a i l ( $email ){ $mysqli = $this - > factory - > getConnection (); $stmt = $mysqli - > prepare ( " SELECT * FROM ( customers natural join complaints ) WHERE email = ? ORDER BY create_date DESC " ); $stmt - > bind_param ( " s " , $email ); $stmt - > execute (); $result = $stmt - > get_result (); if ( $result - > num_rows == 0) return null ;
36
5.4. Popis desktopové aplikace $complaints = array (); while ( $row = $result - > fetch_assoc ()){ $complaint = new Complaint (); $complaint - > SetAttribute ( $row [ ’ column_name ’ ]); array_push ( $complaints , $complaint ); } $stmt - > close (); return $complaints ; } Zdrojový kód 5.6: Reklamace zákazníka - datová vrstva
5.4
Popis desktopové aplikace
Desktopová aplikace pro pracovníky reklamačního oddělení je napsána v jazyku C#, vývojovém prostředí Microsoft Visual Studio 2013. Výhoda v použití takto zvoleného vývojového prostředí je pohodlná tvorba grafického uživatelského rozhraní za pomocí design modeláře, jak je uvedeno na obr. 5.4. Následující 4 podkapitoly se vztahují k obr. 5.5.
5.4.1
/BL /DAO /classes /factory
Implementace je myšlenkově stejná jako ve webové aplikaci jazyka PHP. Pouze je použita jiná syntaxe a implementovány jsou třídy a metody, které jsou v aplikaci skutečně použity, stejně jako v PHP.
5.4.2
/App.config
Jedná se o XML soubor vygenerovaný od prostředí MS Studio 2013. Uchovány jsou údaje. • ip adresa, login, heslo, jméno databáze pro připojení do datového úložiště • login a heslo pracovníka, které slouží jako verifikace pro vstup do systému • adresa API rozhraní k webové aplikaci 37
5. Realizace
38
Obrázek 5.4: Vývojové prostředí MS Studio 2013
5.4. Popis desktopové aplikace IS_Complaint ........................................ kořenový adresář BL .................................... implementace business vrstvy ComplaintManager.cs ........ servisní třída pro správu reklamace CustomerManager.cs..........servisní třída pro správu zákazníků EmployeeManager.cs.......servisní třída pro správu zaměstnanců classes ................................................ třídy DTO DAO .................................... implementace datové vrstvy factory Factory.cs...........................továrna na správu instancí App.config.........................hodnoty pro nastavení prostředí main_form.cs......formulář, spustí se jako první po zapnutí aplikace *_form.cs ...... formuláře - okna která jsou zobrazena uživateli (PL) Obrázek 5.5: Struktura projektu v MS Studio 2013
5.4.3
/main_form.cs
Hlavní formulář, který představuje hlavní okno celé aplikace. Je spuštěn ihned po zapnutí, obsahuje menu, tabulku, tlačítko pro novou reklamaci, filtrovací editační pole, apod.. Stejně jako je uvedeno na obr. 5.4.
5.4.4
/*form.cs
Ostatní formuláře, které se spouští až za běhu programu na základě interakce od uživatele. Jedná se o formuláře: • správa konkrétní reklamace • přidání nové reklamace • zobrazení a správa zákazníků • nastavení aplikace a systémová nastavení • komunikace se zákazníkem reklamace Ve vývojovém prostředí MS Visual Studio 2013 existují na formuláře dva pohledy 1. Designer - návrhový modelář pro tvorbu grafického rozhraní pro uživatele (GUI) 2. Source code - zdrojový kód, kde je možné implementovat inicializace, zachycení všech událostí, změnu hodnot ve formuláři, apod. 39
5. Realizace
5.4.5
Vytvoření funkčního prvku v aplikaci
Implementace desktopové aplikace probíhala iterativně po částech. Vždy bylo předem rozhodnuto, která funkčnost se bude do aplikace implementovat. Iterace měla tyto kroky: 1. Vytvoření nového formuláře v designeru vývojového prostředí MS Studio 2013. 2. Přidání nových komponent, jako např. tlačítka, editační pole, tabulky, labely, apod.. a nastavení výchozích hodnot. 3. Implementace metod na datové vrstvě. 4. Implementace metod na business vrstvě. 5. Vytvoření událostních funkcí za pomocí modeláře, který vygeneruje funkci a programátor funkci implementuje. Např. se může jednat o událost když uživatel klikne na tlačítko. 6. Implementace událostní funkce a spolupráce se servisní třídou z business vrstvy. 7. Otestování funkčnosti
5.4.6
Ukázka zdrojových kódů zadání nové reklamace
Ukázka implementace funkčnosti, která zajistí přidání nového reklamačního případu. Opět se jedná o výběrový průřez zdrojových kódů, tak aby čtenář pochopil jak je provedena realizace s použitím architektury a frameworku .NET. Úplný zdrojový kód lze nalézt v příloze bakalářské práce. private void button_Click ( object sender , EventArgs e ){ /* metoda se vykona kdyz uzivatel klikne na tlacitko zadat novou reklamaci a ~ zobrazi novy formular , kde uzivatel */ fo rm _n ew _c om pl ai nt form = new f or m_ ne w_ com pl ai nt (); form . ShowDialog (); this . refresh (); // obnoveni aktualniho formulare } Zdrojový kód 5.7: Nový reklamační případ - událost Button_OnClick private void buttonSave_Click ( object s , EventArgs e ){ ComplaintService ComplaintManager = null ; ComplaintService = Factory . Instance . BuildComplManag (); 40
5.4. Popis desktopové aplikace Complaint new_complaint = new Complaint (); .. new_complaint . ProductNumber = t ex tB ox_ pr od uc tN um . Text ; new_complaint . PreferText = comboBox_prefer . Text ; .. string complaint_id = ComplaintService . CreateComplaint (... , new_complaint ); } Zdrojový kód 5.8: Nový reklamační případ - přidání reklamace PresentLayer public string CreateComplaint ( Customer customer , Complaint complaint ) { ComplaintDAO ComplDAO = factory . B uildC omplai ntDAO (); DateTime date ; if ( DateTime . TryParse ( complaint . DocumentDate , out date )) { .. complaint . ProductNumber = complaint . ProductNumber . Trim () ... if ( String . IsNullOrEmpty ( complaint . ProductNumber )) return null ; return ComplDAO . AddComplaint ( complaint , customer . ID ); } } Zdrojový kód 5.9: Nový reklamační případ - přidání reklamace BusinessLayer public string AddComplaint ( Complaint complaint , int customer_id ) { string query = " INSERT INTO complaints VALUES ( @val ,..); " string c = this . factory . g et C o nn e c ti o n St r i n g (); try { using ( MySqlConnection conn = new MySqlConnection ( c )) { using ( MySqlCommand cmd = new MySqlCommand ( query , conn )) { connect . Open (); cmd . Prepare (); 41
5. Realizace cmd . Parameters . AddWithValue ( " @val " , " string " ); int result = cmd . ExecuteNonQuery (); if ( result != 0) return ID ; } } } return null ; } Zdrojový kód 5.10: Nový reklamační případ - přidání reklamace DataLayer
5.5 5.5.1
Řešené problémy bcrypt v C#
V PHP pro ukládání hesel je použita funkce crypt(), která vytvoří otisk (hash) hesla za pomocí Blowfish algoritmu (použitím správné soli), který je relativně bezpečný a od verze 5.5.0 je v PHP nahrazena funkcí password_hash() a password_verify(). Nicméně prostředí MS Studio 2013 takové funkce neposkytuje a bylo potřeba stáhnout externí modul BCrypt.Net, který má bcrypt funkci BCrypt.Net.BCrypt.HashPassword() implementovanou. [15]
5.5.2
Odesílání e-mailů v C# použitím ssl/465
V případě, že pracovník vytvoří již existujícímu zákazníkovi přístup do webového rozhraní, je potřeba zaslat vygenerované heslo a aktivační odkaz na email zákazníka. Jelikož je v e-mailu zasíláno heslo, je zcela nezbytné použití šifrované e-mailové komunikace. Zpravidla se využívá port 465 a je potřeba v e-mailovém klientu nastavit parametr SmtpClient.EnableSsl. Pro testování systému byl použit SMTP gmailu na portu 465 s kterým má C# problémy; e-mail se neodešle a skončí chybou na vypršení timeoutu. Z diskusních serverů vyplynulo, že tento problém mají i e-mailoví klienti MS Outlook pod Windows a v prostředí MS Studio C# jsou funkce špatně implementovány. Odesílání pomocí SSL na portu 465 (za použití SMTP gmail.com) jsem provedl v PHP pomocí knihovny PHPMailer, kde nebyl zjištěn žádný problém s odesláním e-mailu. Chyba je tedy s největší pravděpodobností na straně vývojárů .NET.
5.5.3
C# - HTML to PDF Converter
Pro generování reklamačních protokolů jsem v PHP využil dostupnou knihovnu mPDF, která konvertuje HTML soubor do PDF dokumentu. Pro jayzk C# jsem se pokusil nalézt ekvivalent k mPDF a žádný jednoduchý nástroj jsem nenašel, který by byl bezplatně k použití. 42
5.5. Řešené problémy
5.5.4
Řešení
Jediné řešení pro odesílání e-mailových zpráv a generování PDF dokumentů, se nabízelo vytvořit ve webové aplikaci API rozhraní, ze kterého bude desktopová aplikace implementovaná v jazyku C# získávat data na základě požadavku. Jak je uvedeno v 5.1.6 v databázovém modelu je vytvořena entita api, kde se uloží unikátní api klíč (MD5 hash náhodného řetězce) a požadavek s parametry. Po té si aplikace stáhne výstup z adresy /system/api.php?api_key=string_api_key. Aplikace na webovém serveru ověří, že klíč je správný a pak teprve vrátí data, které přijme aplikace v C#. Po přijmutí požadovaných dat, ale i v případě neúspěchu se z databáze smaže požadavek, aby se zabránilo zneužití třetí stranou. Příklad použití API rozhraní v ukázce 5.11 5.12. public string GetRMApdf ( Complaint complaint ) { WebApiDAO WebApiDAO = this . factory . BuildWebApiDAO (); string api_key = null ; api_key = WebApiDAO . Ge ne ra te Ap iR equ es t ( " get_rma_pdf " , " complaint_id = " + complaint . ID ); if ( api_key != null ) { try { using ( System . Net . WebClient Client = new System . Net . Client ()) { webClient . DownloadFile ( " http :// " + IS_Complaint . Properties . Settings . Default . web_api + " ? api_key = " + api_key , " rma " + complaint . ID + " . pdf " ); } } catch { /* MessageBox . Show ( ERROR ); */ ; } WebApiDAO . DeleteApiRequest ( api_key ); return " rma " + complaint . ID + " . pdf " ; } return null ; } Zdrojový kód 5.11: Ukázka WebAPI - získání reklamačního protokolu
43
5. Realizace
.. . $file = $DocManager - > GenerateRMAPdf ( $complaint ); header ( ’ Content - Description : File Transfer ’ ); header ( ’ Content - Type : application / octet - stream ’ ); header ( ’ Content - Disposition : attachment ; Filename = ’ . $file ); header ( ’ Content - Length : ’ . filesize ( $file )); readfile ( $file ); unlink ( $file ); .. . Zdrojový kód 5.12: Ukázka WebAPI - zaslání reklamačního protokolu od webové aplikace
5.6
Testování
Během implementační fáze byly po naimplementování třídy vždy provedeny základní Unit testy, jako ověření že objekt správně funguje a pracuje dle specifikace. Po naimplementování funkčnosti (např. výpis reklamací, přidání reklamace, apod.) proběhla sada testů, která zahrnovala následující. 1. testování na základních datech 2. testování krajních hodnot (prázdné řetězce, nedodržení pravidel, špatné syntaxe např. datumu, e-mailu) 3. testování na prázdných datech v databázi 4. testování na nedostupné databázi 5. v případě API rozhraní testování na nedostupném webovém serveru Po testovací fázi bylo také provedeno zpětné přezkoumání zdrojového kódu. Primárně byly zkoumány tyto vlastnosti: 1. V případě neúspěchu zobrazení chybových hlášek a v případě úspěchu informování uživatele. 2. Zkoumání vzhledem k architektuře systému a opodvědnosti tříd. Např. není možné aby výpočetní operace prováděla prezentační vrstva, takový proces by měla provést business vrstva. 44
5.6. Testování 3. Zkoumání tzv. mrtvých zón (uváznutí v cyklu apod.) V konečné fázi byly provedeny scénáře dle případů užití 3.6 a provedena verifikace všech požadavků 3.4.
45
Kapitola
Ekonomicko-manažerské zhodnocení Kapitola popisuje zhodnocení informačního systému pro správu reklamačního řízení z ekonomicko-manažerského hlediska. Firma může použít řešení vytvořené na míru, nebo případně cloud řešení, kde se zpravidla účtuje tzv. paušální poplatek.
6.1
Připravenost prostředí
Před výběrem každého systému (např. pro správu reklamačního řízení), který bude uživatele podporovat v podnikových procesech je potřeba si položit následující otázky. 1. Potřebuje firma, či organizace informační systém? 2. Jsou budoucí uživatelé schopni se naučit systém používat? 3. Budou uživatelé systém používat a jsou dostatečně motivováni? 4. Je připraveno prostředí?
6.1.1
Úvodní studie
Při volbě nového systému je vhodné si nechat vypracovat úvodní studii. Výstupem je dokument o analýze firmy ze všech možných pohledů. Není vhodné, aby úvodní studie byla zaměřena pouze na realizaci systému pro správu reklamačního řízení. Pokud pořizovací cena za systém je několikanásobně (např. 20x) vyšší než cena za vypracování úvodní studie, pravděpodobně se vyplatí úvodní studii (ÚS) nechat vypracovat, protože může nastat situace, že na základě ÚS je zjištěno, že firma systém vůbec nepotřebuje a jediné co je potřeba je např. změna některého procesu ve firmě. 47
6
6. Ekonomicko-manažerské zhodnocení
6.2
Změna podnikových procesů
V případě, že firma pořídí informační systém pro správu reklamací, minimálně bude potřeba trochu změnit podnikové procesy. Uživatelé budou muset do systému zadávat aktuální data a informace. Stejně tak jako informace a data ze systému číst. Tedy pokud budeme uvažovat modelový příklad, že firma veškeré informace k reklamaci zaznamenává v papírové podobě (případně v tabulkovém programu), pak tedy nastane po nasazení informačního systému změna, že se veškeré informace budou uchovávat právě do IS. Samozřejmě tím dojde ke zjednodušení práce a přehlednosti.
6.3 6.3.1
Způsob pořízení systému Implementace systému na míru
Podobně, jako je realizován systém v této bakalářské práci, může si poptávající firma nechat systém implementovat na míru. To ale ovšem u agilního způsobu metodiky vývoje softwaru zahrnuje využití lidských zdrojů (zaměstnanců) pro tvorbu s realizačním týmem. Zaměstnanci, jako budoucí uživatelé se pak obtížně věnují běžné pracovní činnosti a vzniká práce navíc. Je skutečně potřeba takové zaměstnance dostatečně finančně motivovat. Další z hlavních faktorů je vstupní cena za pořízení systému. Záleží kdo systém realizuje, jestli střední či velká firma, anebo jedna osoba jako podnikatel (osoba samostatně výdělečně činná - OSVČ). Nemusí vždy platit pravidlo, že realizace systému od střední firmy bude obecně kvalitnější, než realizace od OSVČ. 6.3.1.1
Realizace od střední IT firmy
Pokud budeme u střední či velké firmy uvažovat cenu 9600 Kč za man-day (člověkoden = 8 hodin práce) a pracnost realizace systému 360 hodin v rozsahu BP. Do vstupní ceny je vhodné také zahrnout podporu a údržbu pro první rok používání systému, přibližně asi 4 hodiny za měsíc. V stupCena1 = (360 × 1200) + (4 × 12 × 1200) = 489 600 Kč Na základě výpočtu je možné tedy cenu odhadnout na 489 600 Kč 6.3.1.2
Realizace od OSVČ
U osoby OSVČ můžeme uvažovat cenu za man-day 500 Kč, náročnost také 360 hodin. V stupCena2 = (360 × 500) + (4 × 12 × 500) = 204 000 Kč 48
6.3. Způsob pořízení systému
Obrázek 6.1: Cloudové řešení - cloud computing
6.3.1.3
Zhodnocení
Protože se jedná o jednoúčelové řešení, nikoliv o robustní ERP řešení, je určitě reálné, že realizaci systému od analýzy po implementaci a nasazení s údržbou by mohla provést OSVČ. P omer =
V stupCena1 489 600 = = 2,4 V stupCena2 204 000
Cena za realizaci od střední firmy je 2,4 krát vyšší než u OSVČ.
6.3.2
Cloud řešení
Další způsob realizace systému může být využití cloudového řešení (cloud computing). Jedná se o výrobce, který systém tzv. pronajímá a zákazník platí za to co skutečně využije. S cloudovými řešení se setkáváme jako běžní uživatelé denně, jedná se např. o bezplatné služby od Googlu (drive, docs, gmail, apod.). Jinými slovy se jedná o poskytnutí softwaru, který je uložen někde na serverech a uživatelé ke službě přistupují obvykle pomocí webového prohlížeče, nebo klienta pro daný server. Příklad je uveden na obrázku 6.1. [16] 49
6. Ekonomicko-manažerské zhodnocení Použití cloudového řešení má následující výhody: • kolik zákazník využije, tolik zaplatí • úspora financí • software je vždy aktuální, zákazník se nemusí zajímat o aktualizace, ty zajistí na straně serveru poskytovatel. • přístup odkudkoliv přes internet Nevýhody: • služba je neustále závislá na poskytovateli • je zajištěna bezpečnost dat? • je zajištěna stabilita? • datové úložiště na straně poskytovatele Odhad ceny systému pro správu reklamačního řízení může přibližně začínat na částce 1700 Kč za jeden kalendářní měsíc. Protože v kapitole 2 není zmíněno o žadném cloudovém řešení a ani taková služba nebyla nalezena, částku je tedy možné jen odhadnout. Cena1 = 1700 × 12 = 20 400 Kč Za jeden kalendářní rok získá poskytovatel služeb částku asi 20 400 Kč.
6.3.3
Zhodnocení P omer2 =
204400 = 10 20400
Pokud budeme přibližně počítat s výše uvedenými částkami, pak za 10 měsíců se cena za pronájem cloudové služby dostane na cenu realizace systému osobou OSVČ. Jelikož cloudové řešení systému pro správu reklamací nebylo na internetu nalezeno, je vhodné zvolit tvorbu nového informačního systému. 50
6.4. Přínosy realizovaného systému
6.4
Přínosy realizovaného systému
Výhoda v používání systému pro správu reklamačního řízení. 1. Podpora podnikových procesů. 2. Usnadnění práce zaměstnancům firmy. 3. Řešení nezávisle na ostatních informačních systémech. 4. Kompletní pokrytí procesu reklamace. 5. Zákazníci firmy mohou ke svým reklamacím přistoupit pomocí webového rozhraní. 6. Protože proces reklamace je dostatečně řešený za použití informačního systému, lze očekávat menší pravděpodobnost, že zákazník bude nespokojený. Je možné, že zákazník si v budoucnu zakoupí další produkt a zkušenosti předá svému okolí.
51
Závěr Cílem bakalářské práce byla analýza, návrh a tvorba informačního systému, který bude řešit správu reklamačního řízení. Na základě analýzy je vytvořen nový systém, který je schopen pokrýt všechny procesy v organizaci, které se týkají reklamačního řízení. Součástí systému je desktopová aplikace pro firmu a webová aplikace pro zákazníky, kteří reklamují produkt. Zákazník má možnost získat informace o reklamovaném produktu, zadat novou reklamaci, anebo komunikovat s pracovníky. Řešení, které zahrne i zákazníka nebylo na trhu nalezeno. Architektura softwaru je rozdělena do tří vrstev a zdrojový kód je členěn do mnoha tříd. To umožní pohodlné budoucí rozšíření a úpravy. Řešení je vytvořeno obecně vzhledem k typickým procesům a požadavkům a není přizpůsobeno ke konkrétní firmě. Pokud by systém měl být nasazen v konkrétním prostředí, bylo by pravděpodobně potřeba aplikaci upravit tak, aby řešení odpovídalo konkrétním požadavkům. Nicméně při tvorbě specifikace a následné implementaci byla snaha o standardizaci. Návrh na vylepšení systému je import a export dat ve formátu XML a následně implementace middlewaru, který zajistí integraci dat mnou vytvořeného systému s některým ekonomickým softwarem (např. velice známý software POHODA). Data do obou systémů se mohou posílat ve formátu XML přes řízení, které zajistí middleware.
53
Literatura [1]
Dubnová, V.: CRM systém pro evidenci reklamací a oprav zákazníků [online]. April 2008, [Cited 2015-01-27]. Dostupné z: http://is.muni.cz/th/140479/fi_b/CRM_system_pro_evidenci_ reklamaci_a_oprav_zakazniku
[2]
KASTNER software: STEREO a FORM Studio [online]. 2015, [cit. 201501-27]. Dostupné z: http://www.kastnersw.cz
[3]
Helios Red JTV CZ: Funkce reklamace pro HELIOS Red modul SKLAD [online]. 2015, [cit. 2015-01-27]. Dostupné z: http://www.heliosred-jtv.cz/2012/04/27/funkce-reklamacepro-helios-red-modul-sklad/
[4]
Stormware: POHODA Komplet [online]. 2015, [cit. 2015-01-27]. Dostupné z: http://www.stormware.cz/pohoda/komplet.aspx
[5]
Stormware: Online příručka k programu POHODA [online]. 2013, [cit. 2015-01-27]. Dostupné z: http://www.stormware.cz/prirucka-pohodaonline/Sklady/Agendy_Reklamace_a_Servis/
[6]
INOVIO: INOVIO ZRYCHLENÍ VAŠEHO ŘÍZENÍ [online]. 2015, [cit. 2015-01-28]. Dostupné z: http://www.inovio.cz/
[7]
W3C: HTML Introduction. [online]. 2015, [cit. 2015-02-27]. Dostupné z: http://www.w3schools.com/html/html_intro.asp
[8]
W3C: CSS Introduction. [online]. 2015, [cit. 2015-02-28]. Dostupné z: http://www.w3schools.com/css/css_intro.asp
[9]
Bootstrap: Getting started. [online]. 2015, [cit. 2015-02-28]. Dostupné z: http://getbootstrap.com/getting-started/
[10] W3C: PHP 5 Introduction. [online]. 2015, [cit. 2015-02-28]. Dostupné z: http://www.w3schools.com/php/php_intro.asp 55
Literatura [11] W3C: PHP MySQL Database. [online]. 2015, [cit. 2015-02-28]. Dostupné z: http://www.w3schools.com/php/php_mysql_intro.asp [12] Microsoft: Úvod do jazyka C# a rozhraní .NET Framework. [online]. 2015, [cit. 2015-02-28]. Dostupné z: https://msdn.microsoft.com/cscz/library/z1zx9t92.aspx [13] Worx International Inc.: PHP Mailer. [online]. 2009, [cit. 2015-02-28]. Dostupné z: http://phpmailer.worxware.com/ [14] Back, I.: mPDF. [online]. 2013, [cit. 2015-02-28]. Dostupné z: http:// www.mpdf1.com [15] Miller, D.: BCrypt.Net R7. [online]. 2013, [cit. 2015-05-05]. Dostupné z: http://bcrypt.codeplex.com [16] UC SOLUTIONS: Cloud computing . [online]. 2015, [cit. 2015-0314]. Dostupné z: http://www.uc-solutions.net/index.php/solutions/ cloud-computing
56
Příloha
Obrazová příloha
57
A
A. Obrazová příloha
Obrázek A.1: Web App - Přihlašovací stránka
58
Obrázek A.2: Web App - Nová reklamace
59
A. Obrazová příloha
Obrázek A.3: Web App - Seznam reklamací
60
Obrázek A.4: Web App - Zobrazení reklamace
61
A. Obrazová příloha
Reklamační protokol Číslo reklamace: 1958437478 Reklamující: Petr Vzorek Adresa: U Kameného dvoru 25, Pardubice, 45402 Kontakt: +420755222111 Email:
[email protected]
Datum reklamace: 02.01.2015 Číslo produktu: SN254889632112 Přístroj přestal fungovat, nejde zapnout a na Popis problému: nic nereaguje. Dle manuálu vše vyzkoušeno a stále nefunkční. Preferovaný způsob řešení: Oprava
Doklad o koupi produktu: faktura Číslo dokladu: 521848747482 Datum dokladu: 01.01.2014
Informace k řešení reklamace: Přidělený pracovník: Tomáš Novák Vyjádření pracovníka:
vyadný zdroj, výměna zdroje. otestováno a funkční.
Typ reklamace: Záruční Řešení reklamace: Oprava
Dne: 12.04.2015 10:30:04
Vygenerováno ze systému IS Complaint
Obrázek A.5: Vygenerovaný reklamační protokol v PDF
62
Obrázek A.6: Web App - Komunikace s pracovníkem
63
A. Obrazová příloha
Obrázek A.7: Web App - Úprava údajů
64
Obrázek A.8: Windows App - Seznam reklamací
65
A. Obrazová příloha
Obrázek A.9: Windows App - Nová reklamace
66
Obrázek A.10: Windows App - Zobrazení reklamace
67
Příloha
Seznam použitých zkratek API Application Programming Interface CRM Customer relationship management CSS Cascading Style Sheets ERP Enterprise Resource Planning GUI Graphical user interface HTML Hyper Text Markup Language IS Informační systém PDF Portable document format PHP PHP: Hypertext Preprocessor SMTP Simple Mail Transfer Protocol XML Extensible markup language
69
B
Příloha
Obsah přiloženého CD
readme.txt...................................stručný popis obsahu CD src impl...................................zdrojové kódy implementace web_app_impl ....... zdrojové kódy implementace webové aplikace win_app_impl . zdrojové kódy implementace aplikace pro Windows mysql_scripts......create a insert script pro inicializaci databáze create.sql..........sql soubor pro import struktury databáze insert.sql .............. sql soubor pro import vzorových dat ea ..... soubor pro Enterprise Architect, kde jsou vytvořeny diagramy thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce BP_Rolli_Andreas_2015.pdf ...........text práce ve formátu PDF 71
C