Detailní analýza AXIS Auto, s. r. o.

Transkript

1 Detailní analýza AXIS Auto, s. r. o. Verze Datum Vypracoval Úpravy Projektový vedoucí, Zástupce vedoucího projektu Projektový vedoucí Provedl Zástupce vedoucího projektu Zástupce vedoucího projektu Autoři práce Judita Hlinková Petr Kanta Pavel Groll Jiří Neumann Pavel Turčín Martin Vašek Jozef Klimko Hana Kuchařová Tomáš Veselý Petr Moravec Michal Malý Michal Vlček

2 Obsah 1. Úvod Hranice systému Diagram datových toků DFD prodej auta DFD získání auta Procesní modely Proces Prodej automobilu Získaní auta Class diagram diagram tříd Stavové diagramy STD třídy Auto STD třídy Protokol o nákupu STD třídy Protokol o prodeji Konzistence modelů Konzistenční tabulka Design informačního systému SW architektura HW architektura Závěrečné shrnutí Seznam obrázků a tabulek Obrázky Tabulky Přílohy

3 1. Úvod Detailní analýza vychází z analýzy globální. Cílem globální analýzy bylo zmapování fungování podniku a následné vytvoření návrhu budoucího informačního systému. Informační systém byl navržen jako skladba 7 subsystémů, které by měly efektivně podporovat všechny podnikové procesy a organizační složky, a zároveň podporovat důležitá strategická rozhodnutí. Podkladem pro etapu detailní analýzy je dokument Globální analýza AXIS Auto, s. r. o. zpracován dne Cílem detailní analýzy je podrobné rozpracování vybraných oblastí IS do takového detailu, který následně slouží jako podklad pro implementaci a design. V detailní analýze se nezaměřujeme na všechny subsystémy IS, ale pouze na takové, jenž podrobnější rozpracování vyžadují. Pro podrobnější analýzu byl vybrán subsystém Podpora nákupu a prodeje. Tento subsystém je zároveň klíčovým subsystémem, podporuje Core procesy firmy AXIS Auto a vzhledem k jeho povaze jej nelze realizovat pomocí hotového řešení, proto je vhodné jej podrobit další analýze. Tento subsystém je složen z procesů, které popisují získání a prodej auta ve společnosti AXIS Auto. Těmto procesům se dále věnujeme podrobně v dokumentu. Detailní analýza zahrnuje následující analytické modely: Detailní konceptuální model business objektů detailně specifikovaná soustava reálných objektů ve formě diagramu tříd a jejich vztahů. Oproti globálnímu návrhu jsou zde navrženy i metody objektů (reálné reakce, které objekt provádí nebo jsou na něm prováděny), Detailní model business procesů detailně specifikovaná soustava reálných procesů na úrovni elementárních událostí (popis chování reality), Detailní funkční model systému v podobě detailního diagramu datových toků, kterému předchází analýza událostí a reakcí na ně, Stavový model životních cyklů klíčových objektů popis životního cyklu klíčových tříd objektů. Životní cyklus je popsán jako proces následnost jednotlivých stavů objektu, dosahovaných vlivem jeho metod. Všechny analytické modely jsou tvořeny s cílem dosáhnout jejich úplnou konzistenci. Součástí dokumentu je konzistenční tabulka, která tuto konzistenci zajišťuje Hranice systému Tento dokument popisuje pouze jednu část systému. Proto cílem této etapy není jeho implementace a nasazení. V této etapě budou vytvořeny pouze podklady pro již zmíněnou část realizace nového informačního systému. Součástí není také návrh realizace systému. 2

4 2. Diagram datových toků Detailní analýza v rámci diagramu datových toků (Data flow diagram) je zaměřena na jeden subsystém: získání a prodej automobilu. V detailní úrovni se tedy neřeší subsystémy, jako je servis a spravování zaměstnanců. Z důvodu snadné orientace jsme vytvořili na základě předem stanovených procesů dva diagramy, které zahrnují datové toky a funkce v tomto subsystému. Data flow diagramy jsou vytvořeny v notaci Yourdon (DeMarco) a vycházejí z níže uvedeného globálního data flow diagramu. Obr. 2.1 Data flow diagram úrovně 0 (DFD_autabazar.png) 2.1. DFD prodej auta Byl vytvořen detailní diagram úrovně 1 (na úrovni činností) zabývající se prodejem aut zákazníkům. Tento diagram rozpracoval diagramy z globální úrovně (konkrétně Globální Data Flow Diagram a Kontextový diagram) rozvedením datových toků a funkcí v systému autobazaru souvisejících s vlastním prodejem aut zákazníkům. Podrobnější popis diagramu Diagram i nadále obsahuje 3 typy objektů: data store, funkce a terminátory. Všechny tyto objekty mezi sebou obsahují datové toky v daném směru. 3

5 Diagram obsahuje pouze tyto terminátory: Zákazníci a Banka Obr. 2.2 Data flow diagram Prodej auta (DFD_prodej.png) Zákazník při nakupování auta využívá spousty funkcí, které mu zajistí všechny potřebné služby a informace. Při různých typech nákupu se použijí pouze vybrané funkce a datové toky (například ne každý zákazník si kupuje auto na leasing, ale může si ho zaplatit najednou). Funkce Spravování zakázek se rozpadla na 6 funkcí. V tomto subsystému jimi jsou: Rezervování auta, Sjednávání ceny, Konzultování, Prodání auta, Zprostředkování financování a nakonec Editace zakázky, do které všechny předchozí funkce vstupují. Přičemž Editace zakázky je podmnožinou Spravování zakázek z úrovně 0. Klasický nákup vypadá tak, že zákazník nejdříve konzultuje svoje dotazy o nákupu automobilu. Následně vyjednává o ceně automobilu. Poté se rozhodne o jeho koupi a automobil mu je rezervován. Pokud to zákazník potřebuje, může dojít ke zprostředkování financování automobilu sjednání leasingu. Nakonec je podepsána kupní smlouva (představuje datový tok) a auto je prodáno. Funkce Editace zakázky v sobě integruje informace z předchozích funkcí a dále je zpracovává. Poté komunikuje s data store Zakázky, kam se výsledné informace o zakázce ukládají. Do tohoto data store vstupují také datové toky z funkce Účtování. Funkce Účtování dále komunikuje s terminátorem Zákazníci a terminátorem Banka. Pomocí funkce účtování provádí zákazník platbu za automobil. Funkce Účtování poté 4

6 vytvoří nezbytné platební interakce pro terminátor Banka. Platební interakce 2 znamená zpětnou informaci z banky o provedených transakcích či stavech účtů. Poslední funkcí je Správa automobilů, která komunikuje jednak s data store Zakázky a jednak s data store Automobil, který obsahuje databázi všech automobilů včetně jejich parametrů DFD získání auta Dále byl vytvořen další detailní diagram úrovně 1 (na úrovni činností) zabývající se získáním aut do autobazaru. Podrobnější popis diagramu Diagram i nadále obsahuje 3 typy objektů: data store, funkce a terminátory. Všechny tyto objekty obsahují mezi sebou datové toky v daném směru. Terminátory jsou zde: STK, Servis, Odtahová služba, Banka, Zákazníci, Provozovatel aukce a Obchodní partner. Obr. 2.3 Data flow diagram Získání auta (DFD_ziskani.png) Z důvodu různých možností získání vozů se funkce Spravování zakázek rozpadla na několik funkcí. V tomto subsystému jimi jsou Dovoz z ciziny, Aukce z ciziny, Klasický výkup, Editaci zakázky, Zajišťování odtahu a Vyřizování STK. 5

7 Funkce získání vozu Dovoz z ciziny, Aukce z ciziny, Klasický výkup zajišťují nabídku automobilů pro autobazar a stvrzují nákup vozu datovým tokem kupní smlouva. Funkce Editace zakázky edituje informaci o zakázce v data store Zakázky a tvoří integrační článek mezi tímto data store, již zmíněnými funkcemi získání vozu a terminátory Zákazníci, STK, Servis, Odtahová služba, Provozovatel aukce a Obchodní partner. Funkce Editace zakázky nekomunikuje s data store Zakázky jako jediná, dalšími též důležitými funkcemi jsou Správa automobilu a Účtování (jedná se o samostatný proces, který není na této úrovni dále specifikován). Terminátor Servis označuje interní servis autobazaru, který provádí vstupní prohlídku, proto je spojen s funkcí Editace zakázky datovými toky požadavek prohlídky a výsledek prohlídky. Funkce Zajišťování odtahu a Vyřizování STK propojuje datové toky s funkcí Editace zakázky zajišťující objednávku odtahu, následnou fakturu, požadavek kontroly a její výstup s příslušnými terminátory. Funkce Správa automobilu je propojena datovými toky údaje automobilu a údaje zakázky s oběma data story Zakázky a Automobil, které jsou nezbytné pro celý systém autobazaru. 6

8 3. Procesní modely Diagramy níže uvedené představují detailní procesní modely procesů z vymezeného subsystému. Jedná se o zachycení dynamiky skutečného fungovaní procesů v organizaci. Zachycen je přímo průběh procesů, sled jednotlivých činností, logické návaznosti a také ovlivnění průběhu příchozími událostmi. Použita byla notace BPMN (Business Process Modeling Notation). Vybraný subsystém zahrnuje dva procesy, které jsou oba pro analyzovaný podnik klíčové. Jsou jimi prodej a získání auta. Proces získání auta zde vystupuje ve dvojité roli. Většinou vystupuje v roli klíčového procesu, který přináší přímou hodnotu pro zákazníka, ale zároveň může vystupovat v roli prostředníka a de facto procesu podpůrného. Jedná se hlavně o případy, kdy zákazník využívá zprostředkovatelských služeb autobazaru a chce si koupit auto například ze zahraničí. Kromě tohoto je kvůli přehlednosti modelu rozdělen proces získání auta na dva modely model získání auta od zákazníka a získání auta z externích zdrojů. 7

9 3.1. Proces Prodej automobilu Obr. 3.1 Proces Prodej automobilu (BPM_prodej.png) Model prodeje auta je bezesporu nejdůležitějším procesem pro autobazar a jeho hladký průběh je tedy klíčovým pro správnou činnost podniku. Na rozdíl od poněkud složitého procesu získání auta, který měl několik možností realizace, je prodej auta v ideálním případě procesem jednoduchým. 8

10 Samotný proces začíná spouštěcí událostí Podání poptávky zákazníkem. Tato událost je startérem pro celý proces. Bez této události by proces nemohl začít. Životní cyklus toho procesu dále pokračuje činností Konzultace s prodejcem. Tato činnost patří do skupiny činností Nepostradatelných. Na základě této činnosti může celý proces skončit stavem Nelze vyhovět zákazníkovi. Proto je nesmírně důležité tuto činnost abstrahovat do modelu. Pokud proces neskončí, tak se dostává do další činnosti. Na základě této činnosti (upřesnění požadavku zákazníkem) se vyhodnocuje rozhodnutí, zda požadovaný automobil je k dispozici. Zde proces může jít dvěma směry. Pokud zákazník požaduje auto, které nemá autobazar k dispozici, tak lze požadované specifické auto získat pomocí události Požadavek na získání specifického automobilu. Jedná se většinou o případy, kdy má zákazník vybráno auto a chce využít autobazar pouze ke zprostředkování koupě. Než se tato událost spustí, musí předcházet činnost Zadání požadavků a zaplacení zálohy. Následně se čeká na dodání tohoto specifického auta. Druhý směr je očividný. Auto je k dispozici. Událost Činnosti předcházejí koupě spojuje oba směry dohromady. V tomto označení je myšlen soubor elementárních činností, často závislých na obsluhujícím prodejci, které provádí, než se zákazníkem začne sepisovat smlouva. Na základě této činnosti se vytvoří dokument Kupní smlouva, který je výstupem činnosti Sepsání kupní smlouvy. V této části procesu dále čeká na spouštěcí událost Zákazník se vyjádřil ke smlouvě o prodeji. Tato událost vždy musí nastat. Jejím výstupem může být kladný či negativní postoj ke smlouvě. Pokud se jedná o negativní postoj, je zákazníkovi nabídnuta upravená smlouva, pokud je akceptovatelná pro podnik. Pokud není, tak proces končí událostí Zákazník se vyjádřil ke smlouvě o prodeji (negativně)". Pozitivní postoj posouvá proces dále k činnosti Rezervace auta. Zde je výstupním dokumentem Rezervační formulář. V následující části procesu se odvíjí platba. Jak je asi vidět z procesu, tak platba patří do složitější části procesu. Zákazník má možnost si vybrat, zda chce platbu realizovat leasingem nebo z vlastních prostředků. V rámci leasingu je třeba projít činností Sepsání žádosti o leasing. Tato činnost je důležitá pro rozhodnutí, jestli leasing bude schválen. Pokud leasing schválen nebude, proces skončí. Něž se tak stane, provede se činnost Hodnocení neúspěchu získaní leasingu. Druhá možnost je pravděpodobnější, a tedy že leasing schválen bude. To znamená, že se vytvoří leasingová smlouva a realizace platby bude u konce. 9

11 U platby z vlastních prostředků je celý průběh o dost jednodušší. Zákazník si může vybrat, zda chce platit v hotovosti, či zda chce využít bankovní převod na pobočce banky. Jak bankovní převod, tak zaplacení hotovostně vytvoří výstupní Doklad o zaplacení. Platba je tedy realizovaná a přechází se na formality. Podepsání kupní smlouvy se realizuje až po platbě. Tato činnost se odvíjí od svého předchůdce Sepsání kupní smlouvy. Nyní auto může být fyzicky předáno majiteli. Realizováno činností Fyzické převzetí automobilu. Zákazník má 10 dnů na vyjádření, zda je s automobilem spokojen. Pokud není, následuje činnost Reklamační řízení, které má odhalit, zda je reklamace oprávněná. Jestli zákazníkovi bude vyhověno, tak si může vybrat, zda proces ukončí, nebo zda si vybere jiné auto. V případě, že se zákazník nevyjádří o spokojenosti a také v případě, že zákazníkovi reklamce nebude uznána, se životní cyklus procesu dostává do finále. V poslední fázi procesu se zkoumá, zda se jednalo o komisní prodej. Pokud tomu tak bylo, tak původní majitel dostane 98% financí z prodané ceny automobilu. Proces končí událostí Automobil úspěšně prodán Získaní auta Proces získání auta probíhá dvěma různými způsoby. První způsob - zákazník přijde přímo na pobočku a má zájem prodat auto. Druhý způsob - prodejce na pobočce zjistí potřebu zajistit daný druh automobilu. Stejný postup je také zvolen v případě rozhodnutí na základě přicházejících nabídek od externích zdrojů, kterými můžou být autosalony, autobazary, internetová nabídka, zahraniční aukce apod. 10

12 První způsob - Příchod zákazníka do autobazaru, probíhá následovně: Obr. 3.2 Proces Získání auta Příchod zákazníka do autobazaru (BPM_ziskani_int.png) 11

13 Proces začíná událostí "Přišel zákazník s nabídkou". Na pobočce se zákazníka ujme prodavač, se kterým je konzultován prodej. Prodejce se rozhoduje, zda je potřeba zakoupit automobil. Pokud prodejce dospěje k závěru, že daný typ automobilu je zapotřebí, následuje prohlídka technikem, který zjišťuje původ auta a jeho technický stav. Technik kontroluje, zda se auto nenalézá v "Databázi kradených aut" a rozhoduje o technickém stavu automobilu. Tím se dostane ke "Konkretizaci nabídky zákazníka". Následuje rozhodovací činnost, zda je "Cena větší než 2mil Kč?". Pokud ano, pak musí jeho koupi schválit ředitel autobazaru. V opačném případě následuje "Sepsání kupní smlouvy se zákazníkem". Pro uzavření smlouvy se čeká na vyjádření zákazníka, zda souhlasí s podmínkami smlouvy. V kladném případě dochází k "Uzavření smlouvy o prodeji se zákazníkem". Po uzavření smlouvy a fyzického předání auta je zákazník vyplacen hotovostně nebo převodem na bankovní účet, přičemž oba způsoby probíhají v bance na přepážce. Před samotným vystavením auta je provedena "Vstupní prohlídka". V případě potřeby je auto zasláno do servisu, kde jsou provedeny všechny nutné úkony, aby bylo auto připraveno k prodeji. Následují činnosti "Stanovení ceny", která je stanovena prodejcem. Ten následně zanese auto do evidence - činnost "Zanesení do systému". Automobil prochází posledními úpravami - činnost "Příprava auta k prodeji" - jako je mytí aut, popis apod. Když se jedná o "Specifické auto?", je kontaktován konkrétní zákazník, pro kterého bylo získáno. Specifickým autem je myšlenou auto, které bylo koupeno přímo pro konkrétního zákazníka. V opačném případě je "Auto získáno" a připraveno v autobazaru k prodeji. 12

14 Druhý způsob - Prodejce zjišťuje potřebu doplnění nabídky/příchozí nabídka od obchodních partnerů: Obr. 3.3 Proces Získání auta druhý způsob (BPM_ziskani_ext.png) 13

15 Proces v tomto případě může začít dvěma událostmi- "Zjištěna potřeba doplnit nabídku aut" prodejcem na pobočce nebo "Přišla nabídka auta od obchodního partnera", na základě které zhodnotí potřebu zakoupit dané auto. Mezi nejčastější způsoby patří "Koupě auta přes aukci" (ČR nebo zahraničí), "Koupě referenčních vozů", internetová nabídka či nabídka jiných autobazarů. Pokud je dané auto zajímavé pro koupi, dochází ke "Konkretizaci nabídky koupě auta z externích zdrojů". V tomto okamžiku může také být tato činnost spuštěna událostí "Požadavek na specifické auto" při objednávce z procesu Prodej auta. Stane se tak, když si zákazník přeje koupit automobil zprostředkovaně přes autobazar. Při ceně vyšší než 2 miliony Kč musí být koupě odsouhlasena ředitelem autobazaru. V případě souhlasu proces pokračuje činností "Sepsání kupní smlouvy s obch. partnerem". Zde se čeká na vyjádření obchodního partnera, zda danou smlouvu schválí. Po schválení se přistupuje k podpisu smlouvy. K získání auta zakoupeného v zahraničí je potřeba vykonat všechny "Činnosti potřebné k získání auta v zahraničí" je činnost, která může obsahovat celý soubor činností potřebných k převezení auta z ciziny. Konkrétní činnosti a zejména jejich složitost, se mohou lišit v závislosti na zemi vývozu, stavu auta, způsobu nákupu a dalších okolnostech. V každém případě, činnost končí stavem, ve kterém jsou zajištěny všechny potřebné formality. Nacházíli se auto mimo pobočku autobazaru, rozhoduje se o "Zajištění odtahu". Po dopravení auta na pobočku probíhají stejné procedury jako při nákupu od zákazníka. Jedná se o potřebu "Zaslání do servisu", "Stanovení ceny", "Zanesení do systému", "Příprava auta k prodeji" a jeho přípravě a kontrole, jestli nejde o "Specifické auto" na objednávku zákazníka. 14

16 4. Class diagram diagram tříd Obr. 4.1 Diagram tříd (Class_diagram.png) Tento diagram zachycuje modelovaný subsystém nákup a prodej z objektového pohledu. To znamená, že pro nás nejsou směrodatné popisy výměny informací v systému ani popis chodu systému, ale pouze objekty, které se v systému nacházejí. Dále zde modelujeme statické vztahy mezi objekty (například, že banka sídlí na určité adrese). Model tedy zachycuje konceptuální model nezbytné datové základny subsystému a vymezuje, jaké informace se budou v subsystému nacházet. V modelu se nacházejí pouze významné metody (z procesního hlediska), které můžete následně dohledat v konzistenční tabulce. Metody konstrukčního, alternujícího a destrukčního charakteru nejsou v modelu zachyceny. Třída Zákazník reprezentuje prodávajícího i nakupujícího zákazníka. Tento postup pomůže v budoucnu vést evidenci zákazníků pro potřeby marketingového oddělení. Jeden klient totiž může automobily nakupovat a následně i prodávat. Z takto získané evidence půjde snadno sestavit modul na řízení vztahů se zákazníky, aniž by to zadavatele stálo vysoké náklady navíc. 15

17 Nejvýznamnější třídy v modelu jsou Protokol o nákupu a Protokol o prodeji. Každá z těchto tříd reprezentuje jeden obchodní případ. Na těchto třídách lze nejlépe pozorovat jejich měnící se stavy. Každý obchodní případ se postupně vyvíjí a formuje, s tím se mění atributy příslušné třídy. Proto jsme tyto třídy detailně rozebrali v STD (viz kapitola 5. Stavové diagramy). Další důležitou třídou v modelu je Prodejce. Třída dědí základní atributy z třídy Zaměstnanec a přidává metody na vytváření instancí Protokolu o nákupu a Protokolu o prodeji a metody na interakci se zákazníkem. 16

18 5. Stavové diagramy Stavové diagramy popisují životní cyklus objektu a jeho změny vnitřních stavů v čase. Současně i zachycuje události (šipky), které vedou ke změně vnitřního stavu (v modrém obdélníku) objektu. Doplňují tak Class diagram, který je pouze statickým pohledem na jednotlivé objekty. Popisky u šipek vyjadřují události, metody jsou přiřazeny a jsou vidět v Power Designeru po rozkliknutí vazby. Pro vedení AXIS jsou názvy metod podle našeho názoru nepodstatné a programátoři vědí, kde je hledat STD třídy Auto Obr. 5.1 Životní cyklus třídy Auto (STD_auto.png) Životní cyklus třídy auto, začíná zařazením auta do nabídky prodeje. Zde setrvává, dokud si zákazník auto nerezervuje a následně nekoupí. Případně má možnost následně rezervaci zrušit. V případě, že není auto zařazeno do nabídky ani rezervováno, jeho stav je vždy Auto vyřazeno z nabídky. Z našeho pohledu je důležitá pouze informace o tom, jestli auto je potřeba prodat nebo již bylo prodáno. Po prodeji auta, jsou ještě určitou dobu v systému 17

19 drženy o autu údaje pro potřeby případné reklamace a možný analytický zájem marketingového oddělení nebo vedení autobazaru STD třídy Protokol o nákupu Obr. 5.2 Životní cyklus třídy Protokol o nákupu (STD_nakup.png) Protokol o nákupu je třída, obalující samotnou kupní smlouvu a ostatní přiložené dokumenty. Jedná se o případ, kdy autobazar nakupuje automobily do svého vlastnictví. Její životní cyklus je opět velmi přímočarý. V případě potřeby nákupu vozidla je formulován požadavek o parametrech vozidla. Na základě požadavku je vytvořena nabídka ze strany prodávajícího. Pokud se obě strany nedohodnou na podmínkách, protokol zaniká, v opačném případě, že tedy strany akceptují návrh, je podepsána smlouva. Poté se uhradí faktura a protokol o nákupu je archivován. 18

20 5.3. STD třídy Protokol o prodeji Obr. 5.3 Životní cyklus třídy Protokol o prodeji (STD_prodej.png) Protokol o prodeji se týká případu, kdy autobazar prodává auto zákazníkovi. V základu je životní cyklus toho objektu podobný Protokolu o nákupu. Dojde-li zákazník s přáním koupit vůz, prodejce s ním podle jeho požadavků sestaví nabídku. Pokud se obě strany nedohodnou na podmínkách, protokol zaniká, v opačném případě, že tedy strany akceptují návrh, je podepsána smlouva. Klient má ještě navíc možnost požádat o leasing. V případě nesolventnosti mu není schválen, pokud však ano, je ke smlouvě o prodeji vystavena leasingová smlouva. Poté se uhradí faktura a protokol o nákupu je archivován. 19

21 6. Konzistence modelů Jelikož je úplnost a konzistence návrhu kritickým faktorem této etapy, byla sestavena konzistenční tabulka, která zajišťuje konzistenci jednotlivých modelů detailní analýzy: procesního modelu, stavového diagramu, diagramu tříd a diagramu datových toků. Vzhledem k tomu, že se všechny modely týkají stejné činnosti, je nutné zajistit, aby všechny události, akce a stavy byly konzistentní napříč těmito modely. Z tohoto důvodu je v konzistenční tabulce pro každou událost, stav i akci uveden název použitý v každém z popisovaných modelů. Z tabulky je patrné, že všechny modely popisují danou činnost stejným způsobem Konzistenční tabulka Událost Akce Stav Č. V procesu V životním cyklu třídy (STD) Ve vstupu IS (DFD) V procesu V životním cyklu třídy (STD) Ve funkci IS (DFD) V procesu V životním cyklu třídy (STD) 1 Přišel zákazník s obecnou poptávkou 2 Zákazník chce koupit auto zvenčí zprostředkovaně přes autobazar Formulace požadavku Formulace požadavku Předán požadavek zákazníka prodejci Předán požadavek zákazníka prodejci Konzultace a porada od prodejce Získání auta Konstruktor třídy Protokol o prodeji Konstruktor třídy Protokol o prodeji Konzultování Prodání auta Čekání na souhlas s nabídkou Získáno specifické auto pro zákazníka Nabídka k protokolu o prodeji navržena Nabídka k protokolu o prodeji navržena 3 Zákazník se vyjádřil k nabídce Rezervace auta Předán požadavek zákazníka prodejci Rezervace auta Zarezervuj auto() Rezervování auta Čekání na rozhodnutí o využití leasingu Auto zarezervováno

22 4 Zákazník se vyjádřil k nabídce (negativně) 5 Přišlo vyjádření k žádosti o leasing 6 Přišlo vyjádření k žádosti o leasing (negativně) Neshodnutí se na podmínkách Schválení leasingu Neschválení leasingu 7 Faktura uhrazena Uhrazení faktury 8 Zákazník si přišel vyzvednout auto 9 Přišla nabídka auta z externích zdrojů (aukce, zahraničí, autosalony) Vyzvednutí auta Formulace nabídky Nesouhlas s nabídkou Schválení leasingu Neschválení leasingu Zákazník provedl platbu Předán požadavek zákazníka prodejci Příchozí nabídka auta z externích zdrojů Konečný stav Financování auta prostřednictv ím leasingu Konečný stav Zákazník zaplatil automobil a provedl platbu Předání automobilu Rozhodnutí o koupi z externích zdrojů Storno smlouvy() Poskytni leasing() Storno smlouvy() Přijmi platbu() Předej auto() Konstruktor třídy Protokol o nákupu Rezervování auta Zprostredkov ání financování Zprostredkov ání financování Účtování Editace zakázky Editace zakázky Zákazníkovi nebylo možné vyhovět Čekání na úhradu faktury Zákazník nemůže uhradit automobil Čekání na převzetí auta Auto prodáno Čekání na vyjádření obchodního partnera Ukončení cyklu Leasingová smlouva vystavena Ukončení cyklu Faktura k protokolu o nákupu uhrazena Auto vyřazeno z nabídky Nabídka k protokolu o nákupu navržena 10 Přišel zákazník s nabídkou Formulace nabídky Předána nabídka zákazníka prodejci Konzultace s prodejcem Konstruktor třídy Protokol o nákupu Editace zakázky Čekání na souhlas zákazník s kupní smlouvou Nabídka k protokolu o nákupu navržena 21

23 11 Zjištěna potřeba doplnit nabídku aut Formulace nabídky Příchozí nabídka auta z externích zdrojů Rozhodnutí o koupi z externích zdrojů Konstruktor třídy Protokol o nákupu Správa automobilu Čekání na vyjádření obchodního partnera Nabídka k protokolu o nákupu navržena 12 Zákazník se vyjádřil ke smlouvě o prodeji 13 Zákazník se vyjádřil ke smlouvě o prodeji (negativně) 14 Obchodní partner souhlasí s prodejem Akceptace nabídky Neshodnutí se na podmínkách Akceptace nabídky Podpis smlouvy o prodeji zákazníkem Změna smlouvy Podpis smlouvy o prodeji obchodním partnerem 15 Auto fyzicky získáno Získání auta Zapsání auta do evidence automobil Uzavření smlouvy o prodeji Konečný stav Uzavření kupní smlouvy s obchodním partnerem Vstupní prohlídka / stanovení ceny / zařazení do systému Podepiš smlouvu() Storno smlouvy() Podepiš smlouvu() Zařaď auto do evidence() Editace zakázky Editace zakázky Editace zakázky Správa automobilu Čekání na předání auta Zákazník nesouhlasí se smlouvou o prodeji Čekání na dodání auta Auto získáno a připraveno k prodeji Smlouva k protokolu o prodeji podepsána Ukončení cyklu Smlouva k protokolu o prodeji podepsána Auto připraveno k prodeji Tab. 6.1 Konzistenční tabulka 22

24 7. Design informačního systému V podnikatelském záměru společnosti AXIS Auto, s. r. o. nebyly evidovány žádné požadavky relevantní k designu systému přímo od zadavatele, nicméně vzhledem k jeho činnosti, postavení poboček a modulům navrhovaného systému jsou odvozeny následující obecné požadavky: Centrální úložiště dat Centralizované zpracování Malé nároky na HW na pobočkách Snadná implementace na dalších pobočkách Flexibilita pro další rozšiřování a napojování na systémy obchodních partnerů 7.1. SW architektura SW architektura bude vrstvená, se 3 vrstvami: DB server sloužící jako centrální úložiště dat Aplikační server zprostředkovávající funkcionalitu IS, řešený pomocí webového serveru Tencí klienti webové prohlížeče Jinými slovy navrhovaný informační systém bude obsluhován pouze pomocí webového prohlížeče. Tímto řešením se umožní především úspory nákladů spojené s nižšími požadavky na HW na straně klienta a snadné administrace a údržby systému. Další nespornou výhodou tohoto řešení je jednoduché propojení na standardizovaná řešení pro ostatní funkce podnikového IS, jakými je např. workflow, e-business nebo CRM. Kromě webového prohlížeče je počítáno se základním kancelářským softwarem HW architektura HW architektura je řešena DB serverem a webovým serverem. Doporučuje se vyčlenění speciálního webového serveru pro interní potřeby (zahrnující navrhovaný systém pro podporu nákupu a prodeje), přičemž webový server, na kterém by byl provozován zákaznický web, by byl ponechán zvlášť. Tímto vyčleněním se dosáhne většího zabezpečení a lepší alokace kapacit. Klienti budou moci k systému přistupovat pomocí jakéhokoliv zařízení obsahující webový prohlížeč.

25 8. Závěrečné shrnutí Etapa Detailní analýza a návrh je zaměřena na vymodelování části informačního systému pro společnost AXIS Auto, s. r. o. Celá etapa staví na výsledcích získaných v předcházející etapě - Globální analýza a návrh. Na základě této analýzy byl vybrán subsystém Podpora nákupu a prodeje, který je klíčovým pro společnost AXIS Auto, s. r. o. Jelikož je tento subsystém složen z procesů, které popisují získání a prodej auta, v detailní procesní analýze jsme se zabývali právě těmito dvěma procesy - Získání auta a Prodej auta, zachycujících dynamiku skutečného fungování procesů v organizaci (Kapitola 5). Získání auta v podniku vystupuje již v globálním modelu v roli klíčového procesu, který přináší přímou hodnotu pro zákazníka, ale zároveň může vystupovat v roli prostředníka (zákazník využívá zprostředkovatelských služeb autobazaru), proto i v detailní analýze rozlišujeme dva způsoby získání auta. V souladu s tímto byly navrženy i detailní diagramy datových toků, detailní diagram tříd a stavové diagramy. V souvislosti se všemi modely je součástí detailní analýzy i návrh SW a HW architektury. 24

26 9. Seznam obrázků a tabulek 9.1. Obrázky Obr. 2.1 Data flow diagram úrovně 0 (DFD_autabazar.png)... 3 Obr. 2.2 Data flow diagram Prodej auta (DFD_prodej.png)... 4 Obr. 2.3 Data flow diagram Získání auta (DFD_ziskani.png)... 5 Obr. 3.1 Proces Prodej automobilu (BPM_prodej.png)... 8 Obr. 3.2 Proces Získání auta Příchod zákazníka do autobazaru (BPM_ziskani_int.png) Obr. 3.3 Proces Získání auta druhý způsob (BPM_ziskani_ext.png) Obr. 4.1 Diagram tříd (Class_diagram.png) Obr. 5.1 Životní cyklus třídy Auto (STD_auto.png) Obr. 5.2 Životní cyklus třídy Protokol o nákupu (STD_nakup.png) Obr. 5.3 Životní cyklus třídy Protokol o prodeji (STD_prodej.png) Tabulky Tab. 6.1 Konzistenční tabulka

27 10. Přílohy Příloha č. 1 Použitá metodologie

28 Příloha č. 1 Použitá metodologie Pro lepší orientaci v diagramech detailní analýzy uvádíme notaci použitou při modelování. Pro modelování byl použit software Power Designer firmy Sybase. Použité konstrukty pro procesní modely. Použitá notace BPMN. Konstrukt Symbol Power Designeru Popis Událost Vnější podnět činnosti. Informace o skutečnosti nastalé mimo proces (nezávisle na něm). Stav procesu Vnitřní podnět činnosti. Výsledek činnosti logicky předcházející. Místo mezi činnostmi procesu. Koncový stav procesu. Činnost Základní element procesu zpracování vstupů na výstupy. Rozhodovací činnost Elementární činnost, jejímž výstupem je rozhodnutí o dalším postupu procesu. 27

29 Logická spojka Primitivní rozhodovací činnost, která nepotřebuje žádné dodatečné vstupy. Množina dat Množina údajů, či surovin, které slouží jako zdroj pro provedení činnosti procesu nebo je jejich výstupem (obecný zdroj). Základní prvky DFD diagramu. Pro modelování byla použita notace Yourdon (DeMarco). Konstrukt Symbol Power Designeru Popis Funkce Informační procesy (zpracování dat), jimiž je modelováno reálné dění. Transformace vstupu na výstup. Datový tok Data store Datový tok vyjadřuje přesun dat/informací z jedné části systému do jiné, nebo z okolí systému do systému, anebo ze systému do okolí. Data Store (skladiště dat) vyjadřuje "depozitář" dat (data uchovaná pro jejich pozdější použití). 28

30 Terminátor (externí entita) Představuje objekty, které nepatří do popisovaného systému, nýbrž do jeho podstatného okolí. Okolí systému, s nímž systém komunikuje. 29