''TAS u>»& DIPLOMOVÁ PRÁCE. Návrh a realizace systému pro řízení vztahu se zákazníkem

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

•P


X^ / •''TAS u>»&

DIPLOMOVÁ PRÁCE

Návrh a realizace systému pro řízení vztahu se zákazníkem

Jan Sedmidubský jaro 2006

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypra­ coval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování použí­ val nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Jaroslav Pelikán, Ph.D. 11

Poděkování Poděkování patří všem, kteří se jakýmkoli způsobem podíleli na vzniku této práce. Přede­ vším týmu spolupracovníků ze společnosti Draka Kabely za vstřícné jednání, vedoucímu práce za odborné rady, rodičům a přítelkyni za korekturu textu.

m

Shrnutí Dnešní doba přináší lidem velké množství produktů od mnoha různých výrobců. Konku­ rence na trhu neustále roste a soupeření o zákazníka hraje klíčovou roli. Každá společnost si chce udržet své zákazníky a poskytovat jim nejvýhodnější služby, což patří mezi hlavní úkoly CRM systémů. Tyto systémy evidují komunikaci se zákazníky a snaží se nejlépe za­ chytit jejich přání, stížnosti a potřeby. Celá práce se zabývá problematikou a vytvořením CRM systému pro společnost Draka Kabely. Cílem je analyzovat, navrhnout a implemento­ vat systém, který bude umožňovat kompletní správu komunikace se zákazníkem.

Klíčová slova CRM, SFA, Draka Kabely, Synop, analýza projektu, DFD, ERD, InterBase IV

Obsah 1

2

3

4

5

6

7 A

CRM 1.1 Co je to CRM? 1.2 Využití a přínos 1.3 Rizika 1.4 Historie 1.5 Současné systémy 1.5.1 IS Leonardo 1.5.2 Microsoft CRM 3.0 1.6 Použití ve společnosti Draka Kabely Analýza projektu 2.1 Sestavení týmu 2.2 Specifikace požadavků 2.3 Specifíkační dokument Návrh 3.1 Datový model systému 3.2 Důkaz normálních forem 3.3 Funkční model systému 3.4 Návrh GUI 3.5 Volba vývojového prostředí a vhodného hardwaru Implementace 4.1 Popis jednotek 4.2 Třídy pro spolupráci s databází 4.3 Třídy pro GUI 4.4 Globální modul 4.5 Správa úkolů 4.6 Dynamické sestavy 4.7 Zámky Testování 5.1 Vytvoření funkčních testů 5.2 Vyhodnocení testů Instalace a údržba systému 6.1 Předání 6.2 Rozšíření Závěr CD

4 4 5 6 7 8 8 10 12 14 15 15 16 20 20 26 27 29 31 33 33 36 38 40 41 42 44 45 45 45 47 47 47 50 52

1

Seznam tabulek 1.1 1.2

Využití SFA ERP oproti CRM

2.1 2.2 2.3

Funkce AddEvent Funkce OpenCustomerCard Funkce AddTask

5 6 17 18 18

Seznam obrázků 3.1 3.2 3.3 3.4 3.5

Datový model systému Kontextový diagram Správa událostí Úprava zákazníka Zákaznická karta

21 28 28 30 31

4.1

Třídy pro GUI

39

2

Úvod V současné době vzniká stále více firem, které nabízejí rozmanité druhy zboží a poskytují mnoho služeb svým zákazníkům. Zákazníci mají velkou možnost výběru mezi různými prodejci. Každá firma se proto snaží získat nové a udržet své stávající zákazníky, což je hlavní podstatou CRM systémů. První kapitola charakterizuje vlastnosti, využití, přínos a hlavní rizika při zavádění CRM systémů do zaběhnuté společnosti. Detailně popisuje dva zvolené profesionální produkty (IS Leonardo a Microsoft CRM 3.0). Druhá kapitola se zaměřuje na prvotní analýzu projektu. Poukazuje na problémy počá­ tečních fází, představuje tým spolupracovníků a uvádí část sestaveného specifikačního do­ kumentu. Specifikační dokument definuje požadavky na cílový systém (Synop byl zvolen jako oficiální název vyvíjeného systému). Ve třetí kapitole je popsán návrh systému. Především datový model, který je dopodrobna rozepsán až na úroveň atributů entit. Dále obsahuje důkaz normálních forem, část funkč­ ního modelu, návrh uživatelského rozhraní a volbu vhodného hardwaru. Čtvrtá kapitola zobrazuje strukturu systému z hlediska implementace. Popisuje základní funkčnost všech modulů, třídy pro spolupráci s databází a uživatelským rozhraním. Dále vysvětluje způsob realizace správy úkolů, dynamických sestav a zámků. Pátá kapitola poukazuje na všechny odhalené chyby během testování. Šestá kapitola za­ vádí systém do provozu a zobrazuje provedené změny od původní verze. Poslední kapitola hodnotí přínos a dosažené výsledky této práce.

3

Kapitola 1

CRM 1.1

Co je to CRM?

Zkratka CRM (Customer Relationship Management) obecně označuje systémy pro řízení vztahu se zákazníkem. Formálněji se jedná o systémy obchodních, marketingových, komu­ nikačních a servisních procesů ve společnosti a příslušných technologií pro jejich podporu a automatizaci. Názory na přesnou definici se velmi různí, většina se však shoduje v tom, že CRM neznamená pouze implementaci technologie, ale především kulturní změnu ve smyslu vnímání zákazníka. Hlavním úkolem těchto systémů je zvýšení produktivity obchodního procesu, věrnosti zákazníků a samozřejmě celkového profitu. Tohoto cíle se může dosáhnout prostřednictvím změny podnikové kultury, podnikových procesů a informačních technologií. Pro pochopení je však důležité mít na paměti, že řízení zákaznických vztahů, tak jak to dnes vyžaduje konkurenční prostředí, nespočívá pouze v implementaci specializovaného softwaru, jedná se především o změnu orientace zaměření celého způsobu podnikání. Tato problematika zasahuje velmi širokou oblast, zahrnuje všechny procesy týkající se zákazníků. Tedy nejenom poskytování služeb těm dosavadním, ale i podporu pro získávání všech nových zákazníků, pro vytváření nabídky služeb a produktů na míru. Firma, která vyřešila všechny zmíněné problémy, již není zaměřena jen na informační technologie, vý­ robu ani schopnost realizovat dodávku, ale i na zákazníka. K dosažení tohoto cíle je třeba, aby marketing, obchod a služby fungovaly jako jednotný celek, který sdílí stejné informace. A právě to je umožněno automatizovanou podporou CRM. Je proto velmi důležité si uvědomit, že CRM není pouze technologie, ale hlavně ob­ chodní strategie, založená na hlubším pochopení potřeb zákazníků a intenzivní orientaci na jejich spokojenost. Podle marketingové společnosti STEM/MARK tvoří CRM z: •

50 % práce s lidmi,

•

30 % definice a změna procesů,

•

20 % nástroje.

Jestliže je zapotřebí implementovat a zavést CRM systém do existujícího podniku, je nutné dát pozor na spoustu rizik, která s sebou přináší (viz. podkapitola 1.3). Vedení firmy společně s řešitelským týmem by se mělo hlavně zaměřit na nejdůležitější části systému a důkladně promyslet strategii pro jeho zavedení. Následující seznam popisuje sedmero rad, které je doporučeno dodržovat [9]. 1. Zaměřit se na klíčové zákazníky. 2. Určit prioritu cílů. 4

l.CRM 3. Kombinovat tvrdá 1 a měkká 2 data. 4. Nevytvářet jednu velkou databázi, ale účelně ji rozdělit na menší části. 5. Využít více různých zdrojů dat. 6. Organizovat dle zákaznických segmentů. 7. Implementovat procesy a nástroje, nejen definovat strategii. 1.2

Využití a přínos

Jednou z nejvíce diskutovaných otázek bývá debata ohledně pořizovací ceny. Jestli se vů­ bec vyplatí investovat nemalé peníze do takovýchto systémů. Pro malé společnosti, které řídí pouze několik lidí starajících se o pár svých zákazníků, to nemá větší význam. Zajíma­ vější to může být pro střední a hlavně velké společnosti, protože u nich se předpokládá, že mají hodně zaměstnanců pracujících v různých odděleních. Komunikace mezi nimi větši­ nou vázne a to může mít negativní dopad na stávající (i potencionální) zákazníky. Pokud se vedení nemůže stále rozhodnout, je vhodné si najmout analytika a prodiskutovat s ním všechny případné problémy. Investoři se obávají, že vynaložená částka se jim už nikdy nevrátí. Ale to není úplně pravda, CRM systémy mají konkrétní výsledky a přináší s sebou vyčíslitelné úspory a zlep­ šení. Následuje příklad využívající SFA (Sales Force Automation, systémy sloužící pro pod­ poru prodeje) [10]. Strávený čas

bez SFA

se SFA

Čas nutný na administrativu

55%

40%

Čas nutný na prodejní aktivity

45%

60%

Tabulka 1.1: Využití SFA Na příkladu je vidět, že použití SFA přináší společnosti zisk v podobě ušetřeného času (snižuje se doba nutná na vykonávání administrativy). Toho lze dosáhnout například po­ mocí předpřipravených sestav nebo podporou řízení prodejního týmu. Více času se tak dostává na to nejdůležitější, tj. na prodejní aktivity. Tím se i zároveň snižují náklady na komunikaci a cestování. Celý princip CRM systémů staví na získání a udržení zákazníků, pouze ti dodávají spo­ lečnosti finance. Je proto velmi důležité se zaměřit na jejich spokojenost. Následující seznam uvádí hrubou statistiku nespokojených zákazníků [10]. •

Průměrně pouze 1 z 26 nespokojených zákazníků si stěžuje u dodavatele.

•

91 % nespokojených zákazníků se už nikdy nevrátí.

1. Informace o transakcích zákazníků (např. účetnictví). 2. Informace o postojích a chování zákazníků.

5

l.CRM •

Nespokojený zákazník však řekne o svých problémech průměrně 6-18 dalším lidem (na Internetu to může být ještě mnohem více).

•

Pokud se ale vyřeší jejich stížnost, tak 82-95 % zůstane i nadále.

V každém okamžiku je alespoň 25 % zákazníků nespokojeno, ale přesto o tom řeknou společnosti pouhá 4 % z nich. 1.3

Rizika

Každý softwarový projekt s sebou nese určitá rizika, obzvláště pak CRM systémy, které bývají často neúspěšné. Hlavním důvodem neúspěchu bývá mylná představa toho, že si společnost koupí daný systém a tím se hned vyřeší všechny její problémy. Opak však bývá pravdou, zadluženost se zvýší a administrativa se stane nepřehlednou a složitější. Někteří manažeři si vůbec nepřipouští, že CRM projekt není pouze o implementaci, ale hlavně o fi­ remní strategii a transformaci. ERP 3

CRM

Transformace

10%

35%

Integrace

20%

30%

Implementace

70%

35%

Procesy

Tabulka 1.2: ERP oproti CRM To ale zdaleka není jediné riziko, se kterým se může podnik setkat. Existuje jich celá řada. Následující seznam ukazuje další typické důvody neúspěchu CRM projektů [10]. •

Nerealistický široký rozsah projektu.

•

Nedostatečné zadání cílů CRM projektu.

•

Podcenění komplikací při integraci.

•

Chybné nastavení priorit.

•

Nejsou stanovena žádná realistická měřítka úspěšnosti projektu.

Před několika lety (rok 2003) se hodně firmám investice do CRM systémů nevrátila. Pro­ jekty byly provázeny spoustou problémů. Následující statistika ukazuje kolik se jich nepo­ vedlo realizovat (případně s velkými obtížemi). •

Sedm z deseti projektů je předčasně ukončeno do 18 měsíců od jejich začátku.

•

70 % projektů překročí plánovaný rozpočet.

•

65 % projektů nesplnilo očekávání.

3. Běžné informační systémy.

6

l.CRM •

75 % manažerů nemá pro daný projekt definovány žádné měřitelné a ekonomicky podložené cíle.

Řada společností, aby se vyhnula výše uvedeným rizikům, zvolí často jen minimální rozsah projektu a tím si tak uzavírá cestu k využití plného potenciálu CRM [10]. 1.4

Historie

Pojem CRM se začal ve velké míře vyskytovat v posledním desetiletí dvacátého století a na počátku století jedenadvacátého. Už jsou pryč doby, kdy určité typy výrobků ovládala jedna monopolní značka. Dnes je takových značek spousta a proto mají mezi nimi zákazníci velkou možnost výběru. Znají už svou cenu a vědí, že právě jejich peníze udržují společnosti na trhu. Každá taková společnost, která chce uspět, musí dobře znát své zákazníky. Musí hlavně vědět, co chtějí a proč to chtějí. A to je celou podstatou CRM systémů [3]. Tyto systémy nejsou žádnou horkou novinkou, ale v poslední době získávají nebývalý zájem jak ze strany uživatelů, tak i dodavatelů. Zjednodušeně řečeno, ve stále více podni­ cích už poznali, že udržet si stávajícího zákazníka je levnější než hledat nové, ještě nezkla­ mané zákazníky. Více dodavatelů si současně všimlo, že se jejich zákazníci stále více starají o marketing a hledají pro něj vhodné nástroje. Po automatizaci ekonomické agendy a dal­ ších obchodních procesů, jako je logistika nebo řízení lidských zdrojů, prostě přichází na řadu automatizace kontaktů se zákazníky [4]. První předchůdci CRM systémů Za vůbec prvního předchůdce CRM se považuje PIM (Personal Information Manager). PIM měl omezené použití, připomínal spíše elektronický diář nabízející základní databázovou funkcionalitu. Umožňoval pouze organizovat jména, adresy a čas mezi ostatními záleži­ tostmi. Byl to vyhovující osobní nástroj, ale nemohl obstát v obchodním prostředí, ve kterém byly vyžadovány náročné požadavky. Postupem doby se PIM pomalu přeměnil do CMS (Contact Management System). Ten vznikl jako výsledek vzrůstajících nároků z oblastí obchodu a marketingu, začleňující v sobě více specifickou množinu požadavků. Zdál se být dobrým, pružným a výkonným nástrojem pro jednotlivce nebo organizaci. Byl rovněž hodně robustní, obsahoval vylepšený a poměrně rychlý databázový stroj, který lépe posloužil pro správu větších objemů dat. CMS se stal posléze předchůdcem SFA systémů, které dnes tvoří základ moderních CRM aplikací [7]. Historie IS Na počátku devadesátých let bylo používání informačních systémů (IS) ve znamení pod­ pory vnitřních procesů a uspokojování základních potřeb včetně požadavků finančních a daňových úřadů. Tyto systémy měly a mají za úkol zmapovat a zprůhlednit nákladovou strukturu společnosti a podpořit nejdůležitější procesy v ní probíhající. Po odstranění pro­ blémů v oblasti řízení výroby a logistiky se začala objevovat potřeba podpory prodejních 7

l.CRM procesů. Proto vznikly první SFA a systémy na podporu Call Center . Jejich vzájemnou integrací vznikly okolo roku 1995 první CRM řešení, které nabízely řadu výhod oproti stan­ dardním systémům. Další růst nákladů na získávání nových zákazníků, snižování marží a vznik nových komunikačních nástrojů (e-commerce) měl vliv na rozšíření funkcionality o oblasti marketingu a servisu [4]. 1.5

Současné systémy

Jelikož CRM není už dávno neznámým pojmem, vytvořila řada společností za několik let spoustu produktů řešících tuto problematiku. Pro představu, jak takové profesionální sys­ témy fungují, jsou v dalším vybrány a popsány dva z nich. Jeden ryze český produkt (IS Leonardo) a jeden zahraniční (Microsoft CRM 3.0). 1.5.1 IS Leonardo Informační systém Leonardo je vyvíjen společností DATASOFT, která působí již 10 let na českém trhu a věnuje se především podpoře obchodních a marketingových procesů. Na rozvoji tohoto produktu se podílí i marketingová agentura DATAMAR. Systém podporuje všechny nutné procesy pro zákaznickou orientaci firmy a marketingové řízení. Spadá tak do kategorie CRM systémů, a navíc v sobě zahrnuje strategické a taktické marketingové činnosti (řízení výrobků, značky, marketingu a prodeje včetně podpory analýzy v rámci marketingového plánu). Celý systém je implementován modulárně, skládá se z několika na sobě nezávislých částí. Dále následuje popis většiny z nich (dalšími jsou ještě Campaign Manager, Marketing Manager a Supply Manager). •

Brand Manager je modul podporující aktivity spojené s řízením značky. Používá se především pro vývoj značky a produktů pod značkou, sleduje náklady na uvedení a řízení, vyhodnocuje efektivnosti akcí a kampaní na její podporu. Dále umožňuje analýzu trendů, tržních pozic nebo dat z výzkumů (spojení interních a externích dat). V neposlední radě je to i tvorba strategických dokumentů.

•

Key Account Manager je modul sloužící pro zvýšení podpory nadstandardní péče o nejvýznamnější zákazníky. Eviduje kontaktní osoby, nové příležitosti a veškerou komunikaci se zákazníky včetně jejich potřeb. Dále se používá k řešení problémů, stížností a reklamací, pro vyhodnocení úspěšnosti nabídek, prodeje, plánu a neuhra­ zených pohledávek. Dovoluje monitorování konkurence a sledování informací, které jsou o zákazníkovi zveřejněny v tisku. Nedílnou součástí je řízení interních úkolů a obchodních cílů pro splnění požadavků zákazníka.

•

Product Manager je modul podporující řízení a optimalizaci produktového portfolia. Dovoluje vytvářet databanky námětů na produkty, sledovat a vyhodnocovat konku­ renční produkty. Podporuje jednotlivé fáze inovací (sběr a hodnocení námětů, posou­ zení potencionálních produktů podle norem) a projektové řízení při vývoji nových

4. Centrum pro zpracování hovorů.

8

l.CRM produktů (testování zájmu zákazníků, vyhodnocení úspěšnosti nabídek). Dále umož­ ňuje analýzu prodaného množství, cen, vývoje tržních segmentů a srovnání s před­ chozím obdobím nebo plánem. Řídí komunikaci mezi produktovými manažery a pra­ covníky obchodu. Project Manager je modul umožňující plánovat, sledovat a řídit projekty v reálném čase. Eviduje data a náklady (finanční náklady, hodnocení dodavatele a subdodava­ tele, zápisy z jednání a další) související s projekty. Ke každému projektu a úkolu udr­ žuje seznam zodpovědných osob a automaticky zasílá informace o přidělení úkolu členům projektového týmu. Dále se používá pro vedení projektové agendy, připojení relevantních dokumentů, tvorbu sestav (kritická místa, nesplněné úkoly, náklady) a vyhodnocení celého projektu. Report Manager je modul určený k tvorbě a modifikaci výstupních sestav z jednoho nebo více datových zdrojů. Pokrývá komplexně celý životní cyklus sestavy. Správci umožňuje navrhnout a organizovat dotazy, poté je analyzovat, třídit, komentovat, ar­ chivovat, distribuovat koncovým uživatelům a přenášet do redakčního systému na web. Sales Manager je modul, který využívá získaná data o zákaznících mimo danou spo­ lečnost. Je tedy především určen pro zástupce (manažery) na obchodních cestách. Pod­ poruje práci mimo kancelář, tj. technicky je aplikace řešena offline. Replikace dat se provede při přihlášení do podnikové sítě. Eviduje stávající i potencionální zákazníky, kontaktní osoby, plány schůzek, katalogy produktů včetně cen, aktuálních slev a bo­ nusů. •

Supply Manager je modul podporující řízení vztahu s dodavateli. Sleduje a vyhodno­ cuje dodavatele a nákupní položky podle realizovaných obchodních případů. Eviduje kontakty, nabídky, smlouvy a předchozí dodávky. Podporuje všechny etapy výběru dodavatele a řídí projekty při realizaci velkých investičních celků.

IS Leonardo WEB Portal Je jednoduchý nástroj pro realizaci webového intranetového portálu. Jako redakční systém nebo zdroj dat může posloužit Report Manager. Infrastruktura portálu zajišťuje především formátování obsahu do zákazníkem požadované formy. Neméně významnou funkcí je per­ sonalizace stránek pro jednotlivé uživatele v závislosti na nastavení přístupových práv. Na­ víc obsahuje nástroje pro vzájemnou komunikaci dvou online připojených uživatelů a ná­ stroj pro podporu diskusních skupin (včetně záznamu celého průběhu diskuse). Následuje seznam několika jeho významných funkcí. •

Možnost publikace většiny běžných dokumentových formátů (doc, xls, p p t , . . . ) a se­ stav z ostatních úloh systému.

•

Personalizace prezentovaného obsahu na základě přístupových práv.

•

Standardní nebo individuálně nastavený design navigačních stránek. 9

l.CRM •

Možnost připojení multimediálního symbolu a veřejného nebo soukromého komen­ táře k publikovanému dokumentu.

•

Automatické stažení a archivace dokumentu po termínu ukončení prezentace.

Architektura systému je založena na principu třívrstvého modelu. Funkčnost je zajištěna pomocí aplikačního serveru (MS Windows 2000/2003 server s podporou IIS), databázového serveru (MS Windows 2000/2003 server, MS SQL 2000) a jednotlivých klientů. Ti se ještě rozdělují podle různých typů modulů (online tlustý klient, online tenký klient a offline tlustý klient). Veškerou komunikaci mezi servery a klienty zajišťuje protokol TCP/IP [1]. 1.5.2 Microsoft CRM 3.0 Tento produkt pochází od společnosti Microsoft. Nabízí dostupné a snadno použitelné ře­ šení pro budování trvalých vztahů se zákazníky při prodejních, marketingových a servis­ ních aktivitách. Obsahuje moduly Prodej a Servis, které umožňují zaměstnancům sdílet in­ formace, což vede k růstu obchodních úspěchů a poskytování kvalitních a stálých služeb zákazníkům. Obchodní a servisní funkce zahrnují správu příležitostí a obchodního cyklu, komplexní přehled o historii spolupráce a komunikace se zákazníkem, automatizovanou správu událostí i správu znalostní databáze, ve které lze vyhledávat. Microsoft CRM Prodej Pomáhá obchodním týmům i obchodníkům řídit proces generování nových obchodních pří­ ležitostí a sledování obchodních případů, měřit a vytvářet kvalifikované obchodní předpo­ vědi a efektivně nastavuje proces komunikace se zákazníky. Výsledkem je zrychlení obchod­ ních procesů, vyšší procento uzavřených obchodů a zvýšení věrnosti zákazníků. Následující seznam popisuje významné funkce tohoto modulu. •

Kompletní přehled o zákaznících - prohlížení a správa aktivit a historie podle zákaz­ nických účtů, včetně kontaktních údajů, komunikace, otevřených nabídek, objedná­ vek, faktur, kreditních limitů a platební historie.

•

Směrování a správa příležitostí - sledování informací o perspektivních zákaznících, hodnocení a přiřazování průzkumů. Příležitosti mohou být automaticky směrovány ke správným obchodníkům nebo týmům. Snadný převod vyhodnocených příležitostí na obchodní případy a jejich sledování v průběhu prodejního cyklu.

•

Správa obchodního procesu - vytvoření, sledování a uzavření prodeje konzistentně a efektivně, pomocí pravidel workflow, která automatizují stavy v průběhu procesu prodeje.

•

Katalog produktů - práce s komfortními funkcemi katalogu produktů, které zahrnují podporu pro komplexní cenovou politiku, jednotky měření, slevy a cenová nastavení.

•

Správa objednávek - vytvoření a převod nabídek na objednávky, jejich změny a uklá­ dání dokud nejsou připraveny k odeslání. Pokud je integrována finanční aplikace, tak 10

l.CRM se faktury k objednávkám v Microsoft CRM publikují automaticky z tohoto finančního systému. •

Nabídky - nastavení nabídek tak, aby bylo možno sledovat výkonnost prodejců v po­ rovnání se stanovenými cíli.

•

Sestavy - prohlížení, třídění a filtrování. Široká škála sestav navíc umožňuje odhalovat trendy, měřit a předpovídat prodejní aktivity, sledovat prodejní proces a vyhodnoco­ vat efektivitu prodeje.

•

Prodejní literatura - vytvoření, správa a distribuce knihovny prodejních a marketingo­ vých materiálů, včetně brožur, letáků, příruček a dokumentů o konkurenci.

•

Sledování konkurence - sledování podrobných informací o konkurenci, knihovna do­ kumentů a přiřazování informací k příležitostem a prodejní literatuře. Sledování akti­ vit konkurence podle produktů, regionů nebo jiných kritérií.

•

Workflow - automatické směrování příležitostí, notifikace a eskalace. Pravidla work­ flow také zjednodušují generování a odesílání automatických odpovědí prostřednic­ tvím e-mailových zpráv na zákaznické požadavky.

Microsoft CRM Servis Poskytuje mimořádné funkce služeb zákazníkům a dovoluje zvýšit kapacitu pro zpraco­ vání požadavků bez nutnosti přijímat další zaměstnance. Microsoft CRM Servis pomáhá obchodníkům sledovat požadavky zákazníků, spravovat požadavky na podporu a servis od prvního kontaktu až po úspěšné vyřešení. Proto umožňuje poskytovat zákazníkům stá­ lou a efektivní podporu a tím zvyšuje i jejich spokojenost. •

Správa událostí - vytváření, přiřazování a správa zákaznických servisních požadavků od prvotního kontaktu až po úspěšné vyřešení, stejně jako správa všech příslušných komunikací a aktivit. Servisní požadavky - automatické přiřazení příchozích servisních dotazů s přísluš­ nými servisními případy. Razení do fronty - odesílání případů do fronty ke zpracování, odkud jsou snadno dostupné jednotlivcům i týmům. Směrování a workflow - automatické směrování servisních požadavků ke správným jednotlivcům nebo týmům, za účelem řešení, eskalace nebo přesměrování požadavku. Znalostní databáze - rychlé řešení běžných servisních požadavků s využitím znalostní databáze, kterou lze efektivně prohledávat. Zabudovaný proces revizí pomáhá zajistit, že jsou publikované informace kompletní, správné a správně označené k vyhledávání. Správa smluv - vytváření a správa servisních smluv pomáhá zajistit správnou fak­ turaci servisních případů. Pokaždé při úspěšném vyřešení případu se automaticky aktualizují odpovídající údaje o kontraktu. 11

l.CRM •

Správa e-mailů (včetně automatických odpovědí) - správa záznamů o komunikaci se zákazníky, automatické sledování e-mailových zpráv zákazníků. Generování a odesí­ lání odpovědí na zákaznické požadavky.

•

Katalog produktů - práce s komfortními funkcemi katalogu produktů, které zahrnují podporu pro komplexní cenovou politiku, jednotky měření, slevy a cenová nastavení.

•

Sestavy - použití vyčerpávajících nástrojů pro identifikaci běžných problémů při pod­ poře, vyhodnocení potřeb zákazníků, sledování procesu podpory a měření výkonnosti servisu.

Produkt byl navržen tak, aby splňoval různé požadavky na integraci se současnými ob­ chodními systémy. Nejenže umožňuje integrovat informace z nejrůznějších zdrojů v rámci organizace, ale zároveň spolupracuje s mnoha obchodními aplikacemi společnosti Microsoft i dalších výrobců [6]. 1.6

Použití ve společnosti Draka Kabely

Tato práce vznikla primárně pro společnost Draka Kabely, s.r.o., která sídlí ve Velkém Mezi­ říčí. Je zároveň součástí nadnárodního koncernu Draka Holding s hlavním sídlem v Amste­ rodamu. Zastoupení v České republice je zaměřeno především na výrobu vodičů a kabelů pro automobilový průmysl a stavebnictví. Podnik zaměstnává více jak 600 lidí a dosahuje ročního obratu tří miliard korun. Společnost je rozdělena na několik organizačních jednotek (nákup, prodej, marketing), mezi kterými nejsou předávány všechny informace, a proto reálně uvažuje o zavedení ně­ jakého profesionálního CRM systému. Jelikož vedení společnosti o tom není ještě přesvěd­ čeno, vznikla tato práce, která má za úkol simulovat takový systém. Zároveň má poukázat na problémy, které se při používání vyskytnou. Dále má sledovat ohlas a postoj uživatelů, je tedy jakýmsi prototypem CRM systému. V závěru je hodnocen přínos a hlavně problémy, které pomohla tato práce odhalit. Technické informace V této společnosti se pro řízení firmy používá ERP systém S21 od kanadské firmy GEAC, která má zastoupení i v České republice. Tento systém je postaven na platformě IBM AS/400 s 256bitovým procesorem 1503-RISC (umožňuje paralelně zpracovávat dávkové a interak­ tivní úlohy), operační pamětí 512 MB RAM a pevným diskem s kapacitou 100 GB. K serveru je připojeno přibližně 60 terminálů ve formě klasických PC, na kterých jsou nainstalováni klienti systému S21. Systém S21 obsahuje následující moduly [2]. 1. Finanční moduly - hlavní kniha, saldokonto dodavatelů a odběratelů, řízení financí. 2. Distribuční moduly - řízení skladového hospodářství, řízený sklad, nákupní poža­ davky, řízení nákupu a prodeje. 3. Výrobní moduly - technické plánování výroby, plánování materiálových požadavků, dlouhodobé plánování. 12

l.CRM S21 dále spolupracuje se systémem řízení výrobních linek a systémem pro řízení kvality. Dále je propojen s technologickým softwarem na výrobních linkách, který umožňuje řízení linek přímo z pracovišť plánovačů výroby a automatický příjem výrobků na sklady bez nutnosti dvojího pořizování dat. Současně s tímto softwarem vznikají i data pro systém řízení kvality. Automatický příjem a odesílání elektronických objednávek a dodacích listů ve formátu VDA zajišťuje systém EDI (od firmy Seeburger). Volba CRM systému Systém S21 je typickým představitelem ERP systému, který dovoluje evidovat pouze sta­ tická data o zákaznících. Jelikož společnost obchoduje s řádově stovkami zákazníků, je už velmi žádoucí využívat služeb některého z CRM systémů. Při takovém množství údajů se stává komunikace se zákazníky stále složitější, zaměstnanci si mezi sebou nedokážou předat všechny relevantní informace. Dalším problémem může být onemocnění zaměstnance. Volba vhodného CRM systému je do budoucna pro společnost Draka Kabely klíčovou záležitostí. Ke konci roku 2004 byla vedením společně s koncovými uživateli navrhnuta zá­ kladní koncepce systému, který napomůže pro případné zavedení jiného robustního CRM. Jako profesionální se nabízí oba výše zmíněné (IS Leonardo, Microsoft CRM 3.0) a produkt SAP Business One od společnosti SAP.

13

Kapitola 2

Analýza projektu Celá práce byla řešena v rámci projektového řízení. Každý větší projekt se řídí svými pravi­ dly a dodržuje předem definované postupy bez nichž se obejdou pouze jednodušší aplikace malého rozsahu. Všeobecně lze konstatovat, že životní cyklus většiny projektů splňuje ná­ sledující etapy. •

Vize

•

Specifikace

•

Návrh

•

Kódování

•

Testování

•

Předání

•

Údržba

Jednotlivé projekty se však od sebe mohou lišit v modelu vývoje, kterých existuje ně­ kolik. Každá varianta má své výhody a nevýhody a používá se pro určité typy projektů. Klasická metoda vývojového cyklu softwaru je označována jako vodopád. Ze začátku se specifikující a kontrolují veškeré požadavky na produkt, v dalších etapách je systém po­ stupně implementován, testován a v závěrečné fázi předán. V praxi se tato metoda příliš neuplatňuje, protože každá zjištěná chyba znamená návrat k předchozím etapám (na ta­ kové chyby se častokrát narazí až při předání systému). Kromě metody vodopád se nabízí použití několika dalších - spirálového, iteračního nebo inkrementálního modelu, které řeší tyto nedostatky [5]. •

Spirálový model se používá pro systémy, kde nejsou jasně stanoveny požadavky nebo pro vývoj od počátku. Model je vhodný pro větší systémy s vysokou pracností.

•

Iterační model je z části realizován pomocí prototypů (u rizikových oblastí), výsled­ kem každého cyklu vývoje je větší a lépe fungující část, kterou lze velmi brzy testovat.

•

Inkrementální model je vhodný pro vývoj velmi rozsáhlých systémů realizovaných i několika týmy. Základem je jádro, které se postupně rozšiřuje o jednotlivé přírůstky. Model je použitelný pouze v případě, že funkce lze rozdělit do samostatných celků.

Na počátku této práce byla vize společnosti Draka Kabely o vytvoření jednoduchého CRM systému, který se začal realizovat koncem roku 2004. Celý projekt se řídil výše zmíně­ nými etapami a postupoval podle iteračního modelu vývoje. 14

2. ANALÝZA PROJEKTU

2.1

Sestavení týmu

Sestavený tým pracovníků formuluje požadavky na cílový systém. Neosvědčuje se, když specifikaci požadavků dělá výhradně uživatel, často nezohledňuje vlastnosti počítačů a do­ stupného softwaru, nebo jen manažer, občas neschopný vžít se do práce řadových zaměst­ nanců. Následuje seznam členů týmu určených pro tento projekt (nejsou uvedeni ti, kteří se na vývoji nepřímo podíleli). •

Ing. Ladislav Sedmidubský, obchodní ředitel

•

Ing. Luděk Karásek, manažer prodeje

•

Ing. Lubomír Polášek, regionální manažer prodeje

•

Ing. Vladimír Pelikán, manažer marketingu

•

Mgr. Bohuslav Ludvík, vedoucí IT oddělení

2.2

Specifikace požadavků

Po úvodní vizi nastává doba na jednu z nejkritičtějších oblastí vývoje, na specifikaci po­ žadavků. Hlavní příčinou neúspěchu bývá většinou nesprávná formulace cílů, případné chyby, nesprávně pochopené požadavky stojí až 80 % prostředků na jejich nápravu. Tato etapa se často podceňuje kvůli tomu, že téměř vždy musí mít formu srozumitelného do­ kumentu v přirozeném jazyce. Řada požadavků tak má spíše intuitivní charakter. Proto je doporučeno dodržovat určité postupy [5]. •

Nezavádět systém jako zlepšení do nefungující organizace.

•

Orientovat se především na strategické cíle.

•

Vylučovat nepodstatné nebo zbytečné požadavky.

•

Brát v úvahu složitost dat a úkolu.

•

Minimalizovat okamžité organizační změny.

•

Spolupracovat s koncovými uživateli.

Základem úspěchu je tedy získání co nejdetailnějších informací od uživatelů. V praxi se pro formulaci požadavků používá několik strategií, v tomto projektu byla pro specifikaci požadavků zvolena metoda interview (zřejmě nejčastěji používaná metoda vůbec). Před­ připravený rozhovor vede dotazující (moderátor), který klade otázky obvykle jednomu re­ spondentovi. V praxi se tak často děje ve skupině, potom se hovoří o skupinovém interview. Důležité jsou přesné zápisy, doba trvání by neměla překročit čtyři hodiny, přestávky jsou nutnou součástí. Pokud jsou řešeny větší problémy, je vhodné rozložit interview do více dní, někdy se může dokonce celé opakovat. Následuje seznam několika dalších používa­ ných metod [8]. 15

2. ANALÝZA PROJEKTU

•

Dotazování - předpoklad stojí na tom, že uživatelé jsou schopni obejít vlastní ome­ zení a předsudky. Dotazování se může konat ve formě interview, brainstorming nebo dotazníku.

•

Odvození z existujícího systému - východiskem může být podobný systém v jiné or­ ganizaci, popis v knize apod. Je třeba vzít v úvahu zvláštnosti nového sytému.

•

Syntéza charakteristik okolí - hledají se existující vzory, postupy v okolí, ve kterých bude software používán.

•

Prototypování - z první sady požadavků se realizuje prototyp a odhalují se další po­ žadavky. Alternativou je použití scénářů.

Problém společného jazyka partnerů se většinou řeší formou odborného článku, jehož základem je přirozený jazyk. Rovněž se doporučuje zapsat požadavky v některém specia­ lizovaném specifikačním jazyku. Tento projekt ale není tak rozsáhlý, aby mělo cenu využít služeb některého z takových jazyků. 2.3

Specifíkační dokument

Každý projekt musí obsahovat specifíkační dokument, který sestává z několika částí a po­ pisuje cílový systém. Obsahuje stručný popis, přínos, všechny navrhnuté funkce, uživatel­ ská a softwarová rozhraní, bezpečnost, udržovatelnost a další. Zákazník tak dostane docela dobrou představu o tom, jak bude navrhnutý systém vypadat a fungovat. Následuje část takového dokumentu vytvořeného pro tento projekt. lÚvod 1.1 Účel Informační systém bude evidovat komunikaci se zákazníkem včetně jeho požadavků za účelem zlepšení vzájemných vztahů mezi ním a podnikem. Uživatelé získají podrobné in­ formace, které mohou využít pro další jednání. 1.2 Definice, akronymy a zkratky Text[x] Datum {x\,..., xn) [X]

textový řetězec délky maximálně x znaků datum právě jedna hodnota z množiny hodnot x\,... pole hodnot typu X

,xn

2 Celkový popis 2.1 Perspektiva produktu Se vzrůstající konkurencí na trhu se kladou vyšší cíle na kvalitu i cenu jednotlivých pro­ duktů. Je proto důležité neztratit své zákazníky, neboť by to mohlo vést k ekonomickým 16

2. ANALÝZA PROJEKTU

ztrátám. Stále více podniků se tak snaží zlepšit komunikaci se svými zákazníky a co nejvíce vyhovět jejich potřebám. Je tedy vhodné udržovat strukturovaný popis takové komunikace, která napomáhá ke zlepšení vzájemných vztahů. Díky tomu jsou v dnešní době podobné systémy stále více žádány a do budoucna se jim tak naskýtá velká možnost uplatnění. 2.2 Funkce produktu Systém bude evidovat komunikaci mezi zaměstnanci podniku a jejími zákazníky. Všechny události (návštěva, telefonát, e-mail nebo fax), které se se zákazníkem uskuteční, zapíše zú­ častněný uživatel do systému. U těchto událostí bude udržován jejich strukturovaný popis sloužící především zaměstnancům, kteří se už nemusí ptát ostatních na to, co se zákazní­ kem bylo dohodnuto a co ne. Bude obsahovat zúčastněné zástupce obou stran, jednotlivé body jednání, přiložené dokumenty a celkové hodnocení. Libovolný uživatel si může z takto zapsané události vygenerovat strukturovaný dokument. Ke každému zákazníkovi bude navíc k dispozici sada nepovinných údajů (speciální po­ žadavky, konkurence, přiložené dokumenty a mnoho dalších) pomáhajících lépe pochopit všechny jejich potřeby. Pro vzájemnou spolupráci mezi zaměstnanci bude sloužit správa úkolů. Pomocí dynamického vytváření sestav bude možno získat komplexní informace z ce­ lého systému, správa sestav bude zajišťovat export dat podle zadaných parametrů. 3. Specifické požadavky 3.1 Funkční požadavky

3.1.19 AddEvent Úvod:

Ke zvolenému zákazníkovi přidá novou událost (návštěva, telefon, fax, e-mail) s datem a místem konání (místo se uvádí pouze u návštěvy). Tuto událost pak vlastní příslušný uživatel.

Vstup:

zákazník: Zákazník typUdálosti: (Návštěva, Telefon, E-mail, Fax) datum: Datum místo: Text[35] vlastník: Uživatel

Zpracování:

Ověří se datum. Potom se k zákazníkovi (zákazník) přidá nová událost (typUdálosti) s datum (datum) a místem konání (místo), kterou vlastní daný uživatel (vlastník).

Výstup:

Nová událost (událost: Událost). Tabulka 2.1: Funkce AddEvent

17

2. ANALÝZA PROJEKTU

3.1.17

OpenCustomerCard

Úvod:

Pro zvoleného zákazníka otevře jeho příslušnou kartu se všemi informa­ cemi o vzájemné komunikaci mezi ním a uživateli.

Vstup:

zákazník: Zákazník

Zpracování:

Ověří se možnost uzamčení zákazníka (ostatní uživatelé k němu po dobu uzamčení nemohou přistupovat). Potom se otevře karta zákazníka včetně všech jeho poboček. Jinak se vypíše kdo a jak dlouho už pracuje se zvole­ nou zákaznickou kartou.

Výstup:

Otevřená (a uzamčená) zákaznická karta. Tabulka 2.2: Funkce OpenCustomerCard

3.1.27AddTask Úvod:

Ke zvolené události přidá nový úkol. Vlastník úkolu určí vedoucího a může zadat termín splnění a popis úkolu. Nakonec se vygeneruje e-mail pro vedoucího.

Vstup:

záznam: Záznam vlastník: Uživatel vedoucí: Uživatel termín: Datum popis: Text[30]

Zpracování:

Ověří se termín splnění (termín) úkolu. Potom se přidá vedoucímu (ve­ doucí) nový úkol s termínem splnění a celkovým popisem (popis). Tento úkol pak vlastní příslušný uživatel. Nakonec se ve standardním poštov­ ním klientovi vygeneruje e-mail pro vedoucího s daným úkolem.

Výstup:

Nový úkol (úkol: Úkol). Tabulka 2.3: Funkce AddTask

3.2 Požadavky na vnější rozhraní 3.2.1 Uživatelská rozhraní Prostředí celého systému bude uživatelsky komfortní a jednoduché na ovládání. Všechny obrazovky budou obsahovat komponenty typické pro aplikace typu MS Windows. Každý 18

2. ANALÝZA PROJEKTU

uživatel bude mít možnost si změnit vzhled celé aplikace podle svých představ. Nastaví si profil svého barevného schématu, který se bude při každém přihlášení automaticky načítat. 3.2.2 Softwarová rozhraní Celý systém bude navržen pro platformu MS Windows, každý klient musí mít operační sys­ tém řady alespoň MS Windows 98 nebo vyšší. Dále bude využívat databázového systému InterBase, který poběží na serveru. InterBase vyžaduje jeden z operačních systémů MS Win­ dows, Linux nebo Solaris. 3.3 Atributy 3.3.1 Bezpečnost Do systému se bude moci přihlásit pouze oprávněný uživatel, nikomu jinému nebude pří­ stup umožněn. Ověřování bude probíhat na databázovém serveru pomocí zadaného uživa­ telského jména a hesla. Nové uživatele bude moci přidávat pouze administrátor systému. 3.3.2 Udržovatelnost Systém bude navržen takovým způsobem, aby mohl být do budoucna postupně rozšiřován a upravován. Pokud se případně definují nové dílčí funkce, nesmí to znamenat přepraco­ vání celého systému, ale pouze část relevantní těmto požadavkům.

19

Kapitola 3

Návrh Po specifikaci všech požadavků se už může přejít k návrhu řešení celého systému. Tato etapa je rovněž významná, pokud není provedena důkladně a přikročí se k samotné implemen­ taci, bývá potom dosti nákladné se vracet zpět a restrukturalizovat původní návrh. Proto se používají některé modelovací nástroje, které umožňují nahlížet na systém ve formě růz­ ných diagramů a pomáhají tak odhalit logické chyby návrhu. Mezi nejvíce používané patří následující dva [8]. •

ERD (Entity Relationship Diagram) - zobrazuje systém z hlediska struktury dat (tzv. datový model systému). Vyjadřuje vztahy, které nejsou zachyceny v procesních mode­ lech (těm poslouží jako stabilní základ).

•

DFD (Data Flow Diagram.) - zobrazuje systém jako síť procesů, které plní určené funkce a předávají si mezi sebou data. Poskytuje funkčně orientovaný pohled na sys­ tém.

Základem návrhu je vytvoření datového modelu celého systému. Všechny dříve speci­ fikované požadavky je nutné převést do jednotlivých komponent tohoto modelu, to zna­ mená identifikovat entity (objekt, o němž se uchovávají informace) a vztahy (vztah mezi entitami). Data se musí uspořádat takovým způsobem, abychom se vyhnuli možným pro­ blémům, které se mohou vyskytnout během provozu systému. Řešením je normalizace dat, nebo-li jejich převedení do některé normální formy (nejčastěji do třetí normální formy, viz. podkapitola 3.2). Kromě návrhu datového a procesního modelu je třeba vzít v úvahu ještě další aspekty návrhu řešení. Jestli bude systém implementován objektově, je třeba navrhnout příslušný objektový model. Další nedílnou součástí je návrh uživatelského rozhraní, pokud nebude dobře navrženo, uživatelé nebudou chtít se systémem pracovat. Nesmí se opomenout ani volba vhodného programovacího jazyka a příslušného hardware. Následující podkapitoly jsou praktickou ukázkou řešení těchto problémů. 3.1

Datový model systému

Po analýze požadovaných funkcí byly sepsány všechny potřebné datové položky (atributy), ze kterých byl posléze vytvořen datový model systému. Identifikovaly se základní entity včetně jejich atributů, primárních a cizích klíčů, závislostí a vzájemných vztahů. Následující obrázek ukazuje model tohoto systému, obdélníkem jsou znázorněny entity obsahující atri­ buty, linkou pak vzájemné vztahy mezi entitami (1 : 0,0 : n, vztah m : n je zobrazen pomocí entity a dvou 0 : n vztahů). 20

3 Cu s) ID IDGroup.lD(FK| IDType.lD(FK! IDRegion.lD(FK) IDState.lD(FK) IDResponsibility.lD(FK) IDBill.lD(FK)

Repres _ o ^ IDPerson.lD(FK) IDCust(FK)

Cust CustDoc ID IDCust.lD(FK)

lust

\

Dial

Type Group State Region

Person

h

Person ID IDCust.lD(FK) IDFunction(FK)

Name Surname Heading Birthday -cX Telephone Mobil Fax Function Email - c X WWW PDes

Item CDDes Cust

Code Name ICO DIC Street City PostalCode Telephone Fax Email WWW

>°

Col Shortcut DDes

Responsibility

Person

i

ERepres IDEvent.lD(FK) IDPerson.lD(FK)

Function Cust

DKPerson ID IDFunction.lD(FK)

Custlnfo IDCust.lD(FK)

Name Surname Heading Birthday Telephone Mobil Fax Email WWW DKPDes Login Privilege Shortcut

InfoOl Info02 Info03 Info04 InfoOS InfoOe Info07 InfoOS Info09 InfolO lnfo11 lnfo12

V Task ID IDThing.lD(FK) -o< IDOwner(FK) -cX IDHead.lD(FK)

>cJ Head Owner Worker

Task

TDate S D ate C D ate TDes V

Owner

Thing

DKPerson

í

Lock IDOwner.lD(FK)

EDKRepres IDEvent.lD(FK) IDDKPerson.lD(FK)

Flag LAction LID LDate LTime

Event ID IDCust.lD(FK) IDOwner.lD(FK) Event S*>-

Cust -o<

EType E D ate Place Ratingl Rating2 Rating3 Rating4

PMG

ID IDTask.lD(FK) IDWorker.lD(FK) TDate S D ate CDate STD e s

Event

EventDoc ID IDEvent.lD(FK) Item EDDes

Owner

SubTask

>o-l Event

Thing ID IDEvent.lD(FK) IDPMG.ID(FK) TType Subject -cX Text

Event

Obrázek 3.1: Datový model systému

>o-i

3. NÁVRH

Pro pochopení modelu jsou v následujícím textu detailně popsány všechny jeho objekty Ke každé entitě (označena tučně) je uveden stručný popis jejího použití včetně seznamu jednotlivých atributů (atributy s názvem ID označují primární klíče, atributy začínající ře­ tězcem ID naopak cizí klíče s odkazem na příslušný primární klíč). Dial eviduje všechny typy číselníků (zkratky a popisy pro kraj, stát, funkci, PMG skupinu, skupinu a typ zákazníka). ID Col Shortcut DDes

jednoznačná identifikace číselníkové položky typ číselníku (kraj, stát, typ zákazníka,...) zkratka číselníkové položky (CZ) popis pro zkratku (Česká republika)

Cust eviduje zákazníky (včetně potencionálních). ID Code Name ICO DIC Street City PostalCode IDGroup IDType IDRegion IDState Telephone Fax Email WWW IDResPerson IDBillPerson

jednoznačná identifikace zákazníka kód zákazníka název zákazníka IČO DIČ adresa - ulice adresa - město adresa - poštovní směrovací číslo skupina zákazníka (dodavatel, maloobchodník, velkoobchodník), odkazuje na danou číselníkovou položku typ zákazníka (tuzemský, zahraniční, vnitropodnikový), odkazuje na danou číselníkovou položku adresa - kraj, odkazuje na danou číselníkovou položku adresa - stát, odkazuje na danou číselníkovou položku telefonní spojení faxové spojení e-mailová adresa webové stránky zákazníka osoba zodpovědná za zákazníka, odkazuje na daného uživatele osoba zodpovědná za fakturace zákazníka, odkazuje na daného uživatele

Custlnfo eviduje další informace o zákaznících (nepovinné údaje). IDCust InfoOl Info02

příslušný zákazník, odkazuje na daného zákazníka balení bubny 22

3. NÁVRH Info03 Info04 Info05 InfoOó Info07 Info08 Info09 InfolO Inf o i l Infol2

štítky platební podmínky speciální požadavky konkurence poznámka reklamní předměty majitel obrat základní kapitál počet zaměstnanců

Person eviduje zaměstnance všech zákazníků (jednatele, obchodníky a další osoby, se kte­ rými proběhla nějaká komunikace). ID IDCust Name Surname Heading IDFunction Birthday Telephone Mobil Fax Email WWW PDes

jednoznačná identifikace zaměstnance zákazníka zaměstnavatel, odkazuje na daného zákazníka jméno příjmení titul zastávající funkce, odkazuje na danou číselmkovou položku datum narození telefonní spojení mobilní spojení faxové spojení e-mailová adresa osobní webové stránky poznámka k osobě

DKPerson eviduje všechny uživatele systému. ID Name Surname Heading IDFunction Birthday Telephone Mobil Fax Email WWW DKPDes Login

jednoznačná identifikace uživatele jméno příjmení titul zastávající funkce, odkazuje na danou číselmkovou položku datum narození telefonní spojení mobilní spojení faxové spojení e-mailová adresa osobní webové stránky poznámka k uživateli přihlašovací jméno 23

3. NÁVRH Privilege Shortcut

oprávnění (dosud nevyužíváno) zkratka uživatele

Repres eviduje zástupce všech zákazníků (všechny jednatele, kteří zastupují jednotlivé zá­ kazníky). IDPerson IDCust

příslušný zaměstnanec, odkazuje na daného zaměstnance příslušný zákazník, odkazuje na daného zákazníka

Event eviduje všechny události (návštěva, telefon, e-mail, fax). ID IDCust EType EDate IDOwner Place Ratingl Rating2 Rating3 Rating4

jednoznačná identifikace události příslušný zákazník, odkazuje na daného zákazníka typ události (návštěva, telefon, e-mail, fax) datum založení události vlastník události, odkazuje na daného uživatele místo konání hodnocení sortimentu hodnocení cen hodnocení služeb hodnocení kvality

ERepres eviduje zástupce zákazníka všech událostí (všechny zaměstnance zákazníků, kteří se zúčastnili jednotlivých událostí). IDEvent IDPerson

příslušná událost, odkazuje na danou událost příslušný zaměstnanec, odkazuje na daného zaměstnance

EDKRepres eviduje zástupce uživatelů všech událostí (uživatele, kteří se zúčastnili jednot­ livých událostí). IDEvent

příslušná událost, odkazuje na danou událost

IDDKPerson

příslušný uživatel, odkazuje na daného uživatele

Thing eviduje záznamy všech událostí. ID jednoznačná identifikace záznamu IDEvent příslušná událost, odkazuje na danou událost TType typ záznamu (sortiment poptávaný, sortiment dodávaný, ceny, reklamace, ostatní) IDPMG PMG skupina, odkazuje na danou číselníkovou položku Subject předmět Text popis 24

3. NÁVRH Task eviduje úkoly, které si mezi sebou zadávají uživatelé. ID IDEvent IDOwner IDHead TDate SDate CDate TDes

jednoznačná identifikace úkolu příslušná událost, odkazuje na danou událost vlastník události, odkazuje na daného uživatele vedoucí události, odkazuje na daného uživatele datum vytvoření termín pro splnění datum splnění popis

SubTask eviduje jednotlivé části všech úkolů (dosud nevyužíváno). ID IDTask IDWorker TDate SDate CDate STDes

jednoznačná identifikace části úkolu příslušný úkol, odkazuje na daný úkol odpovědný pracovník, odkazuje na daného uživatele datum vytvoření termín pro splnění datum splnění popis

CustDoc eviduje přiložené dokumenty ke všem zákazníkům. ID IDCust Item CDDes

jednoznačná identifikace dokumentu příslušný zákazník, odkazuje na daného zákazníka úplná cesta k dokumentu popis

EventDoc eviduje přiložené dokumenty ke všem událostem. ID IDEvent Item EDDes

jednoznačná identifikace dokumentu příslušná událost, odkazuje na danou událost úplná cesta k dokumentu popis

Lock spravuje přístup k některým funkcím systému (funkce je přístupná pouze tehdy, když má nastavený příznak Flag na nulu). Flag LAction LID IDOwner LDate LTime

příznak přístupu (0 ... odemčeno, 1 ... uzamčeno) daná funkce uzamčené/odemčené samostatné záznamy funkce uživatel používající funkci, odkazuje na daného uživatele datum odemčení/uzamčení záznamu čas odemčení/uzamčení záznamu

25

3. NÁVRH 3.2

Důkaz normálních forem

Dobře navržený systém (přesněji řečeno datový model systému) musí splňovat určité vlast­ nosti, jednou z nich je normalizace dat. Znamená to organizovat data do logických celků tak, aby šla snadno a efektivně udržovat. Cílem je dosáhnout co nejvyššího stupně, nejčastěji se uvádí následující tři [8]. •

1. normální forma: v záznamech se nevyskytují opakující se skupiny položek.

•

2. normální forma: záznam R je ve 2. NF, pokud je v 1. NF a každá neklíčová položka v R je plně funkčně závislá na každém kandidátním klíči R.

•

3. normální forma: záznam R je ve 3. NF, pokud je ve 2. NF a každá neklíčová položka R je netranzitivně závislá na každém kandidátním klíči z R.

Datový model systému byl budován podle výše zmíněných pravidel, měl by tedy splňo­ vat třetí normální formu (až na tři výjimky, které jsou v dalším textu příslušně odůvodněny). Pro každou entitu je třeba ukázat, že je postupně v první, druhé a nakonec třetí normální formě. Proto následuje jejich podrobný popis (A => B značí, že atribut B je závislý na atri­ butu A). Person 1. V záznamech se nevyskytují opakující se skupiny položek => 1. NF. 2. Každý neklíčový atribut je plně funkčně závislý na kandidátním klíči ID => 2. NF. 3. Každý neklíčový atribut je netranzitivně závislý na kandidátním klíči ID => 3. NF. Entita Person je tedy v třetí normální formě, pro entity Custlnfo, DKPerson, Repres, Event, ERepres, EDKRepres, Thing, Task, SubTask, CustDoc, EventDoc, Lock platí totéž. Následují entity, které splňují druhou normální formu, ale nesplňují třetí. Dial 1. V záznamech se nevyskytují opakující se skupiny položek => 1. NF. 2. Každý neklíčový atribut je plně funkčně závislý na kandidátním klíči ID => 2. NF. 3. ID => Col, Col => Shortcut, potom atribut Shortcut je tranzitivně závislý na atributu ID =£> 3. NF. Řešením by bylo nahradit atribut ID primárním klíčem složeným z atri­ butů Col a Shortcut (tato dvojice jinak tvoří unikátní klíč entity). U mnoha atributů by ale musela být evidována dvojice klíčů (navíc řetězců), namísto jednoho klíče (čísla). Cust 1. V záznamech se nevyskytují opakující se skupiny položek => 1. NF. 2. Každý neklíčový atribut je plně funkčně závislý na kandidátním klíči ID => 2. NF. 26

3. NÁVRH

3. ID => ID State, IDState => ID Region, potom atribut ID Region je tranzitivně závislý na atributu ID =£> 3. NR Rozdělení na kraje (IDRegion) bývá jen u některých států (IDState). Řešením by bylo zrušení atributu IDRegion z entity Cust a vytvoření nové entity s cizími klíči IDCust (odkazujícím na příslušného zákazníka) a IDRegion (od­ kazujícím na příslušnou číselníkovou položku). Následné dotazy (využívající entitu Cust) by se ale mohly netriviálně zkomplikovat. Event 1. V záznamech se nevyskytují opakující se skupiny položek => 1. NF. 2. Každý neklíčový atribut je plně funkčně závislý na kandidátním klíči ID => 2. NF. 3. ID => EType, EType => Place, potom atribut Place je tranzitivně závislý na atri­ butu ID =£> 3. NF. Místo konání události (Place) se uvádí pouze u daného typu události (EType) - u návštěvy. Řešením by bylo zrušení atributu Place z entity Event a vytvoření nové entity s cizím klíčem IDEvent (odkazujícím na příslušnou událost) a atributem Place. Následné dotazy (využívající entitu Event) by se ale mohly jako v předešlém případě netriviálně zkomplikovat. Přestože uvedené entity nesplňují vlastnosti třetí normální formy, neznamená to, že sys­ tém je navržen špatně. Pro jeho činnost by nebylo efektivní upravovat dané entity jen kvůli tomu, aby splňovaly požadované vlastnosti. 3.3

Funkční model systému

Kromě datového modelu je nutné sestavit i funkční model, který bývá znázorněn ve formě diagramu. Model zobrazuje všechny specifikované funkce systému, předávání informací mezi funkcemi, uživatelské vstupy a výstupy procesů. Následuje seznam komponent pou­ žívaných při tvorbě modelu [8]. •

Proces - část systému, která transformuje určité vstupy na výstupy.

•

Tok - znázorňuje cestu, po které se pohybují data z jedné části systému do druhé.

•

Paměť - uchovává data, která jsou modifikována na žádost procesů. Tok vedoucí do paměti může mít význam zápisu, změny nebo zrušení.

•

Terminátor - reprezentuje externí entity, se kterými systém komunikuje. Leží vně sys­ tému, toky, které je propojují s procesy (nebo pamětmi), reprezentují rozhraní mezi systémem a vnějším světem.

Diagram datových toků bývá kvůli přehlednosti zobrazován do několika úrovní. Nej­ vyšší úroveň tvoří kontextový diagram, který zobrazuje všechny uživatelské role vyskytující se v systému. Jeden uživatel může mít i více rolí. Systém Synop ale rozlišuje pouze dvě role - běžného uživatele (Common user) a správce systému (Administrator). Následující obrá­ zek 3.2 zobrazuje kontextový diagram (procesy jsou znázorněny kruhem, toky směrovou šipkou, terminátory čtvercem a paměti zaobleným obdélníkem). 27

3.

User's queries

Common user

Administrator's queries

Administrator 1

Data for administrators

Data for users

Obrázek 3.2: Kontextový diagram

Data forthing manag sment

Manage thing I ERepres

Updated thing —

^, H H

Th . „ Thing min

9

]

J

Event ci stomer represe ntative

Customer representative

Common user

^

representative

Event

Data for event update

representative

Event

Set customer

\

event j Updated event

fc[ \

J

Set user representative

Event represe ntative

EDKRepres Data fqrtask management

Event

EVÍ

J

Obrázek 3.3: Správa událostí

nt

Updated task

Task

J

3. NÁVRH

Kontextový diagram tvoří nultou úroveň modelu. Znázorňuje pouze jediný proces Synop, který je dekomponován do několika částí (na první úrovni). Každá taková část je opět rozdělena na jednotlivé subsystémy v dalších úrovních. Obrázek 3.3 ukazuje činnost funkce pro správu událostí (na druhé úrovni, názvy pamětí odpovídají názvům entit datového mo­ delu). 3.4

Návrh GUI

Uživatelské rozhraní do značné míry ovlivňuje spokojenost zákazníka se systémem. Když pěkně vypadá, systém se pak lépe prodává. Kvalita návrhu značně ovlivňuje i počet chyb, které uživatelé vytvoří při práci (to samozřejmě ovlivňuje i celkové náklady na provoz). Proto by se mělo uživatelské rozhraní vyvíjet jako samostatná část (navíc metody návrhu a testování se značně liší od metod realizace vlastní logiky systému). Vytvořit dobré rozhraní bývá velmi složitý úkol, protože vývoj je hodně ovlivňován následujícími skutečnostmi [5]. •

Optimální vlastnosti se stěží odhadují, závisí především na psychologii, dovednostech a znalostech uživatelů.

•

Testovat mohou pouze budoucí uživatelé.

•

Vlastnosti uživatelů se během používání systému mění.

•

Je třeba počítat se začátečníky i pokročilými.

Uvádí se, že rozhraní ovlivňuje produktivitu uživatelů v řádu desítek procent (u velkých firem to může přinést značné úspory). Proto by se měl každý dobrý návrh řídit následujícími pravidly [5]. •

Používat čitelné barvy (barvy známé z malířství).

•

Formát obrazovky je uživateli přirozený (tak jak to dělal dosud).

•

Používat exity (za jakékoli situace jednoduše přerušit akci).

•

Ovládat systém jen za pomocí klávesnice (horké klávesy pro časté akce).

•

Zobrazovat nápovědu.

Návrh uživatelského rozhraní byl zaměřen především na barvu, styl a velikost jednotli­ vých komponent. Grafické rozhraní systému S21 vypadá jako klasická aplikace typu Micro­ soft Windows s některými specifickými funkcemi (např. maximalizace okna proporcionálně zvětší všechny v něm obsažené komponenty, krok zpět se vyvolá klávesou F12,...). Uživa­ telé si už na tyto prvky zvykli a vyžadují tak stejné ovládání i od ostatních aplikací. Barvy Všechny komponenty celého systému budou zobrazeny pomocí sedmi barev. Každý uživa­ tel bude mít možnost nastavení svého profilu (barevného schématu), který se mu aplikuje po přihlášení do systému. Vzhled se aplikuje pomocí následujících barev (v závorce za ní je uvedena výchozí barva). 29

3. NÁVRH

•

Barva písma (hnědá) - barva všech nápisů.

•

Barva písma tlačítek (hnědá) - barva písma použitého na tlačítkách.

•

Barva komponent (světle šedá) - barva pozadí komponenty.

•

Barva obrazců (stříbrná) - barva podkladu logicky seskupených komponent.

•

Barva pozadí (světle hnědá) - barva pozadí celé aplikace.

Styl Systém nebude kopírovat typické vizuální prvky komponent jako je např. okraj simulující vjem třírozměrného prostoru. Snahou je zobrazit všechny části jednoduše a přehledně, proto bude např. okraj u jednotlivých komponent ohraničen pouze jednoduchou linkou. Velikost Výška a šířka komponent bude odpovídat objemu v nich zobrazovaných informací. Při změně velikosti okna se všechny objekty proporcionálně zvětší, resp. zmenší. UM™—'M

^JSl_x| Jan Sedmidubský (SVSDBA)

rZákazníkKód: |l0000033

Telefon: +353 10 5661

|000 |

Název: |DRAKA NK Cables LTD

|

Fax: I+35S 10 566 3394

IČO: |i0000033

|

E-mail:

DIČ: |FI 16043929

|

WWW: www.nkcables.fi

Ulice: |p.o.Box269 Město: joulu

|

PSČ: go651

Skupina: C

|

Odpovědná osoba: DK dodávky:

I * Zástupci:

Typ: |lNT I Další Informace: Kraj: C

I *

Stát: [ŘT^j * Upravit

Zpět

Obrázek 3.4: Úprava zákazníka

30

3. NÁVRH 1 Zákazník

Události: Datum

Náhled: Vlastník | Typ události

7,11,2005

FIC

E-mail

27.6.2005

FIC

E-mail

22.6.2005

FIC

E-mail

25.5.2005

FIC

Telefon

4]

nabídka_Draka_AT_RG213_20020e|

Q

Nab_KTP_RG213_20.2.2006.pdf

Dokumenty:

±1)RG213

Přidat

Upravit

Smazat Zpět

Obrázek 3.5: Zákaznická karta

3.5

Volba vývojového prostředí a vhodného hardwaru

Pro vývoj celého systému byl zvolen produkt Borland Delphi 7. Vývojové prostředí Del­ phi používá jazyk Object Pascal, který plně podporuje objektově orientované programování a umožňuje vyvíjet aplikace typické systémům Microsoft Windows (to byl rovněž jeden z požadavků na uživatelské rozhraní). Dále je uvedeno několik výhod tohoto vývojového prostředí. •

Rychlý a výkonný, plně 32bitový optimalizační kompilátor.

•

Použití objektově orientovaného programování.

•

Vizuální dědičnost formulářů, což obnáší maximální spojení objektově orientovaného programování a vizuálního návrhu aplikací.

•

Velké množství volně přístupných komponent.

Kromě vývojového prostředí je nutné rozvážit způsob ukládání dat. Informační systémy využívají výhradně služeb databázového stroje. Organizace dat pomocí souborového sys­ tému je spíše výjimkou (použitelné u aplikací s malým objemem dat). Databázové systémy 31

3. NÁVRH

už v sobě zahrnují souběžné zpracování transakcí, řízení přístupu a rychlé vyhledávání dat. Některé jsou dokonce k dispozici zdarma (MySQL, PostgreSQL). Pro tento projekt byl zvo­ len produkt Borland InterBase 7.5, se kterým umí Delphi dobře spolupracovat. Další fází je návrh příslušného hardwaru, který musí během stanovené doby obsloužit všechny požadavky. Hlavními faktory pro volbu je objem zpracovávaných dat a počet uži­ vatelů k nim souběžně přistupujících. Společnosti většinou nechtějí investovat do nových zařízení, často tak využívají dosavadní prostředky, což není úplně výhodné a přináší to pouze omezené úspory. Tento systém nebude pracovat s velkým množstvím dat, nebude vyžadovat ani žádné složité dotazy. Jelikož počet naráz připojených uživatelů by se měl pohybovat průměrně okolo pěti, byl navrhnut následující hardware sloužící jako databázový server. •

Procesor Intel Pentium 4 s taktovací frekvencí > 2 GHz

•

Operační paměť 512 MB RAM

•

Pevný disk o kapacitě 80 GB

•

Operační systém Windows XP Professional

Taková konfigurace ale není nutnou podmínkou, bude postačovat server s nižšími para­ metry. Pro každého klienta připojujícího se k serveru postačuje běžný kancelářský počítač s operačním systémem řady Microsoft Windows 98 a vyšší.

32

Kapitola 4

Implementace Vývojové prostředí Delphi umožňuje vytvářet aplikace založené na principu objektově ori­ entované architektury. Tento způsob vývoje byl rovněž využit při implementaci systému, i když ne všechny části jsou řešeny objektově. Celá struktura systému je rozdělena na několik modulů (jednotek), které mezi sebou komunikují. 4.1

Popis jednotek

Systém se skládá celkem z 23 naprogramovaných jednotek, některé obsahují pouze da­ tové struktury (definice tříd), některé navíc ještě grafické uživatelské rozhraní. Následuje seznam, který stručně popisuje význam a funkce všech jednotek. Appearance Slouží pro nastavení vzhledu grafických komponent používaných v celém systému. U všech komponent nastavuje příslušné barvy (zadané uživatelem nebo výchozí), styl (pevně daný, bez možnosti změny) a velikost (podle současné velikosti okna). Custlnfo Spravuje nepovinné údaje zadané k jednotlivým zákazníkům. Ke každému zákazníkovi umožňuje uchovávat a zobrazovat dodatečné informace (speciální požadavky, konkurence, reklamní předměty, platební podmínky, počet zaměstnanců a další). Customer Karta zvoleného zákazníka, zobrazuje všechny jeho pobočky, základní informace (jméno, adresu, zástupce,...), uskutečněné události (typ události, datum, vlastníka) a přiložené do­ kumenty (ty lze přímo spustit v přidružené aplikaci). Dial Pro daný typ číselníku (kraj, stát, funkce, PMG skupina, zákazník, skupina a typ zákazníka) zobrazí a umožní zvolit jednu ze všech jeho příslušných hodnot. Document Spravuje všechny přiložené dokumenty (na úrovni zákazníka i události). Neuchovává sa­ motné dokumenty, ale pouze odkazy na ně (pokud někdo smaže dokument přímo na síťo33

4. IMPLEMENTACE

vém disku a nesmaže jej ze systému, potom zůstane uložen odkaz na neexistující soubor). Ke každému dokumentu umožňuje přidat krátký popis. Error Pomocí této jednotky jsou zobrazena všechna chybová hlášení. Eviduje nejčastější chyby vzniklé špatným zadáním vstupu. Ostatní (nepředpokládané) chyby jsou touto jednotkou rovněž zpracovány. Event Ke zvolené události zobrazuje její typ (návštěva, telefon, e-mail, fax), zástupce ze strany uživatelů a zákazníků, datum konání (případně i místo), příslušné záznamy, seznam úkolů pro uživatele, přiložené dokumenty a hodnocení. Celou událost umožňuje vygenerovat do prostředí Microsoft Word. Global Nevizuálni jednotka určená primárně pro práci s globálními proměnnými. Definuje některé konstanty, typy nebo třídy. Ze začátku inicializuje několik objektů nutných pro správu da­ tabáze, řízení přístupu, nastavení a dalších (většina jednotek jich posléze využívá). IBConnection Řídí přístup k databázi nebo uživatelským účtům. Po zadání přihlašovacích údajů se připojí k serveru a vrací výsledky spuštěných dotazů. Login Po zadání přihlašovacích údajů se pokusí připojit daným protokolem k serveru. Pokud při­ hlášení proběhne v pořádku, načte profil uživatele (vzhled včetně dalšího nastavení) a pře­ jde do hlavního menu. MainMenu Slouží jako hlavní rozcestník mezi jednotlivými částmi systému. Umožňuje přejít ke správě zákazníků, vlastních úkolů, dynamických sestav, číselníků, nastavení, uživatelů nebo SQL dotazů (z bezpečnostních důvodů určená pouze administrátorovi). Monitor Řídí přístup k některým funkcím systému, které může zpracovávat v daný časový okamžik maximálně jeden uživatel. Mezi takové funkce patří správa číselníků, uživatelů a dané zá­ kaznické karty. 34

4. IMPLEMENTACE

MyTask Zobrazuje a umožňuje editovat všechny úkoly přihlášeného uživatele (úkoly, které vlastní a úkoly, ve kterých je vedoucím). Podle nastavené varianty zobrazení filtruje úkoly na pouze nesplněné, pouze splněné, nebo všechny. Person Spravuje všechny osoby uložené v systému (uživatele i zaměstnance zákazníků). Uživatele může spravovat pouze administrátor, zobrazovat jejich vlastnosti však může každý. Report Generuje dynamické sestavy podle zadaných parametrů a umožňuje je ukládat do prostředí Microsoft Excel. Parametry se rozdělují do čtyř základních skupin (zákazník, událost, zá­ znam, úkol), každá z nich umožňuje nastavit několik parametrů, ze kterých se posléze vy­ tvoří a spustí dotaz. SelCustomer Spravuje vlastnosti zákazníků, základní a nepovinné údaje, zástupce a odpovědné osoby. Dále slouží pro výběr zákazníka a otevření jeho příslušné karty. SelPerson Zobrazuje a umožňuje zvolit jednu nebo více osob (podle situace b u ď uživatele, anebo za­ městnance daného zákazníka). Slouží například pro výběr vedoucího úkolu, odpovědné osoby za zákazníka, zástupců události a dalších. Setting Spravuje profil přihlášeného uživatele. Umožňuje nastavit vzhled aplikace, upozorňování (počet dnů před narozeninami všech osob, počet dnů před vypršením vlastních úkolů) a ostatní informace (zobrazení náhledu události). SQL Jednotka poskytující administrátorům spuštění libovolného dotazu nebo příkazu. Slouží především pro odemykání záznamů, speciální dotazy analyzující činnost uživatelů nebo stav zákazníků, které nelze postihnout dynamickým generováním sestav. Task Zobrazuje přidělené úkoly (stav, vlastníka, vedoucího, termíny, popis) v rámci události. Vlastníkům umožňuje úkoly spravovat, vedoucím splňovat a uživatelům přidávat nové. 35

4. IMPLEMENTACE

Thing Ke zvolenému záznamu zobrazuje jeho typ (sortiment poptávaný, sortiment dodávaný, ceny, reklamace, ostatní), PMG skupinu, předmět a popis. Libovolným uživatelům dovo­ luje vybraný záznam spravovat. UpdateDial Slouží pro správu všech typů číselníků (kraj, stát, funkce, PMG skupina, skupina a typ zá­ kazníka). Ke zvolené zkratce přidává její popis. User Jednotka obsahující jedinou třídu, která identifikuje přihlášeného uživatele. Eviduje jeho základní vlastnosti (login, jméno, příjmení, zkratku,...) a poskytuje funkce pro zjištění pří­ stupových práv. 4.2

Třídy pro spolupráci s databází

Téměř všechna data, se kterými systém pracuje jsou uložena v databázi na serveru (na sí­ ťovém disku jsou uloženy pouze konfigurační soubory pro zjištění adresy serveru a načtení uživatelských profilů). Zprostředkování přístupu k databází zajišťují třídy TIBConnection a TIBServiceConnection implementované v jednotce IBConnection. Proces přihlášení probíhá v následujících fázích. •

Otevření konfiguračního souboru Config.ini.

•

Načtení protokolu (standardně je použit protokol TCP/IP).

•

Načtení adresy serveru (jeho jména nebo IP adresy).

•

Načtení úplné cesty k databázi.

•

Inicializace spojení.

•

Nastavení uživatelského jména a hesla.

•

Ověření přístupu.

•

Otevření komunikačního spojení mezi klientem a serverem.

Bezpečnost je postavena na znalosti uživatelského jména a hesla. Systém sám o sobě ne­ udržuje žádný seznam hesel, autentizace se provádí pouze na úrovni databázového stroje. Ten ověřuje uživatele oproti hašovanému vzorku hesla uloženého ve své databázi. Proto ani administrátor nemůže zjistit heslo uživatele (může mu jej akorát změnit). Po úspěšném přihlášení je vytvořen zabezpečený kanál, který slouží pro komunikaci mezi klientem a da­ tabází (pro zadávání dotazů, správu uživatelských účtů a dalších). Všechny tyto funkce za­ jišťují následující dvě třídy. 36

4. IMPLEMENTACE

TIBConnection Tato třída má za úkol, po úspěšné autentizaci uživatele, spouštět SQL příkazy, dotazy a uložené procedury a poté vracet jejich případné výsledky Pod touto činností se skrývá spo­ lupráce několika následujících komponent. • • • • •

DataSource - nastavuje požadovanou datovou sadu. Database - zapouzdřuje komunikaci s databází. Transaction - poskytuje oddělenou transakční kontrolu nad databázovým spojením. Query - spouští SQL příkazy a dotazy. StoredProc - zapouzdřuje uloženou proceduru na databázovém serveru.

Obsahuje několik funkcí a procedur pro přihlášení a odhlášení z databáze, nastavení uživatele, zjištění výsledků spouštěných dotazů nebo uložených procedur. Nejpoužívanější je zřejmě následující funkce RunSQL, která spustí SQL příkaz (zadaný parametrem) a vrátí počet ovlivněných (změněných) řádků. function TIBConnection.RunSQL(const ASQL: s t r i n g ) : begin

Integer;

Query.SQL.Add(ASQL); Query.Close; i f Uppercase(Copy(TrimLeft(ASQL), 1, 6)) = 'SELECT' then begin Query.Open; Query.First; end else begin T r a n s a c t i o n . A c t i v e := True; try try Query.ExecSQL; Result := Query.RowsAffected; Transaction.Commit; except Transaction.Rollback; Raise; end; finally T r a n s a c t i o n . A c t i v e := F a l s e ; end; end; end; 37

4. IMPLEMENTACE

TIBServiceConnection Třída sloužící pouze pro správu uživatelských účtů. Po nastavení uživatele se zjistí jeho práva (jestli je administrátorem nebo běžným uživatelem) a pokud je administrátor, tak se mu povolí kompletní správa uživatelských účtů. V opačném případě dovoluje běžným uži­ vatele účty pouze zobrazit. Celou činnost zajišťuje jediná komponenta SecurityService umožňující zobrazovat in­ formace uživatelům a administrátorovi navíc přidávat, upravovat nebo mazat uživatelské účty uložené na databázovém serveru. 4.3

Třídy pro GUI

Grafická podoba jednotlivých formulářů je navržena v příslušných jednotkách systému. Po­ kud jednotka neslouží pouze pro definici datových typů, tak je v ní implementován kód, který představuje vizuální stránku jednoho formuláře (například jednotka Event zahrnuje grafický návrh formuláře pro správu události). Na každý formulář se při jeho vytvoření aplikuje výchozí motiv vzhledu (ten se sestává z barevného schématu a stylu komponent). Po úspěšném přihlášení se nastaví vzhled defi­ novaný příslušným uživatelem, který se načítá z daného konfiguračního souboru (jeho ná­ zev je určen uživatelským jménem a příponou .ini, např. NOVAK.ini). Následuje zkrácený výpis takového souboru, zobrazena je pouze sekce pro vzhled. [ColorSetting] FontColor=8388736 ButtonFontColor=l671168 0 ComponentColor=l6777215 ShapeColor=12 6322 5 6 B a c k g r o u n d C o l o r = - 1 6 7 7 72 01

Načtení těchto informací zajišťuje třída TAppearanceSetting, jejich nastavení pak třída TTheme. Další tři (TColorSetting, TStyleSetting, TSizeSetting) tvoří základ pro výše uve­ dené, v dalším jsou všechny popsány (i s příslušným diagramem spolupráce). •

TColorSetting - nastaví barvy všech komponent systému podle načteného profilu.

•

TStyleSetting - nastaví jednoduchý styl zobrazení (dvoudimenzionální vzhled na­ místo prostorového) pro všechny komponenty.

•

TSizeSetting - zvětšuje/zmenšuje velikost všech komponent podle aktuálně nastave­ ného rozměru formuláře.

•

TTheme - zapouzdřuje tři výše uvedené třídy do jednoho motivu.

•

TAppearanceSetting - načítá a ukládá vzhled přihlášeného uživatele, dále zajišťuje plynulý přechod mezi zobrazením dvou formulářů. 38

4. IMPLEMENTACE TColorSetting -DefaultFontColorTColor -DefaultButtonFontColorTColor -DefaultComponentColorTColor -DefaultShapeColorTColor -DefaultBackgroundColor:TColor -FontColorTColor -ButtonFontColorTColor -ComponentColor:TColor -ShapeColorTColor -BackgroundColorTColor

TStyleSetting

TSizeSetting

-DefaultCtl3D:Boolean -DefaultBevelInnerTBevelCut -DefaultBevelKindTBevelKind

-CanResizeComp:Boolean -PrevHeightlnteger -PrevWidthľlnteger

+TStyl e Setting +GetDefaultCtl3D:Boolean +GetDefaultBevellnner:TBevelCut +GetDefaultBevelKinci:TBevelKinci +ApplyStyleSetting:void

+TSizeSetting +SetCanResizeComp:voicl +GetCanResizeComp:Boolean +OnResizeForm:void +ApplySizeSetting:void

A

+TColorSetting +SetColors:void +SetDefaultColors:void +GetFontColor:TColor +GetButtonFontColor:TColor +GetComponentColor:TColor +GetShapeColor:TColor +GetBackgroundColor:TColor +ApplyColorSetting:void

TTheme -CSTColorSetting -SSTStyleSetting -SzSTSizeSetting TAppearanceSetting +TTheme +GetCS:TColorSetting +GetSS:TStyleSetting +G etSzS:TSize Setting +ApplyThemeSetting:void

/\

-FSettingTIniFile -WState:TWindowState -Theme:TTheme +TAppearanceSetting -AnimateFornrvoid +SetSettingFile:void +GetSettingFile:TlniFile +GetTheme:TTheme +ShowForm:void +SaveAII:void +LoadAII:void

X TSetting -DayNoticeView:Boolean -BirthdayNotice:lnteger -TaskNotice:lnteger -EventPreview:Boolean <-SetDayNoticeView:void ••GetDayNoticeViewBoolean <-SetBirthdayNotice:void <-GetBirthdayNotice:lnteger <-SetTaskNotice:void <-GetTaskNotice:lnteger <-SetEventPreview:void <-GetEventPreview:Boolean <-SaveAII:void t-LoadAII:void

Obrázek 4.1: Třídy pro GUI

39

4. IMPLEMENTACE

Třída TSizeSetting před spuštěním systému každému formuláři (přesněji události OnRe­ sizeForm každého formuláře) přiřadí proceduru OnResizeForm, která při změně velikosti okna zajistí i proporcionální změnu všech jeho komponent. Následující část kódu ukazuje změnu jejich rozměrů i písma.

{ Nastaveni velikosti a pisma všech komponent daného formuláre. } for J := 0 to Form.ComponentCount - 1 do begin if Form.Components[J].InheritsFrom(TControl) then with TControl(Form.Components[J]) do begin Left := Round(Left * WidthRatio); Top := Round(Top * HeightRatio); Height := Round(Height * HeightRatio); Width := Round(Width * WidthRatio); end;

{ TBitBtn } if Form.Components[J].ClassType = TBitBtn then with TBitBtn(Form.Components[J]) do if not ParentFont then Font.Size := Round(Font.Size * FontRatio);

4.4 Globální modul Jednotka Global deklaruje několik proměnných, které jsou globální a viditelné téměř ze všech dalších jednotek. Důvodem zavedení bylo jejich použití v každé části systému, ne­ mělo by tedy smysl je neustále předávat parametrem. Následuje seznam těchto proměnných společně s jejich příslušným typem a popisem. •

P a t h : s t r i n g - ú p l n á cesta ke zdrojovému adresáři systému.

•

E r r : T E r r o r -zobrazuje a spravuje chyby v systému.

•

FConf i g : T L n i F i l e - konfigurační soubor pro přístup k databázi na serveru.

•

F S e t t i n g : T L n i F i l e - konfigurační soubor s nastavením přihlášeného uživatele.

•

LBC: TLBConnect i o n - spouští dotazy, příkazy a uložené procedury.

•

User : TUser - vlastnosti přihlášeného uživatele.

•

U s e r S e r v i c e : T L B S e r v i c e C o n n e c t i o n - spravuje uživatelské účty. 40

4. IMPLEMENTACE

•

S y s t emF P : T S y s t emF P - spouští dokumenty v přidružených aplikacích.

•

SynopFP : TSynopFP - zajišťuje pomocné funkce.

•

Check: TCheck -kontroluje a převádí uživatelské vstupy.

•

Lock: TLock-uzamyká/odemyká funkce s výlučným přístupem.

•

Sett:

T S e t t i n g - spravuje uživatelský profil.

Kromě globálních proměnných obsahuje ještě deklarace konstant (typ události a zá­ znamu, hodnocení události), typů a tříd. Následuje popis funkčnosti jednotlivých tříd. TSystemFP Určená pro spolupráci s prostředím Microsoft Windows. Implementuje funkce pro spuštění zvoleného dokumentu v přidružené aplikaci. Dále pro vybraný soubor umožňuje zjistit a zobrazit jeho ikonu v různé velikosti. TSetting Spravuje nastavení aktuálně přihlášeného uživatele. To znamená, že načítá a ukládá vzhled systému, upozorňuje na různé události a ostatní nastavené záležitosti. TSynopFP Slouží pouze pro definici pomocných interních funkcí. Mezi takové patří například pro­ cedura BeíoreRunApplication (ta se provede pouze jednou před spuštěním systému a na­ staví výchozí vzhled pro všechny formuláře), procedura SetTreeView (do dané komponenty zobrazí příslušné dokumenty včetně jejich ikon) a řada dalších. 4.5

Správa úkolů

Správa úkolů je implementována na úrovni jednotlivých událostí. Libovolný uživatel může vytvořit nový úkol a zadat ho vedoucímu (každému úkolu odpovídá právě jeden vedoucí). Nepovinnými údaji je termín splnění úkolu a jeho popis. Celá funkčnost je realizována jed­ notkou Task s využitím čtyřech dalších jednotek (u nich jsou uvedeny použité typy, pro­ měnné, třídy nebo funkce). •

Appearance - typ TFormShowState určuje způsob přechodu mezi formuláři.

•

Error - typ T E r r o r T y p e eviduje chyby příslušné správě úkolů, funkce C a l l E r r o r je zobrazuje ve formě chybového hlášení.

•

SelPerson - třída T F o r m S e l P e r s o n vybírá vedoucího úkolu (jednoho z uživatelů).

•

Global - globální proměnné LBC (pro spuštění SQL příkazu nebo dotazu) a E r r (pro zobrazení případných chyb), třídy TSystemFP a TSynopFP pro generování e-mailu a převedení dotazu do interní datové struktury. 41

4. IMPLEMENTACE

V části datového modelu jsou všechny úkoly uloženy v entitě Task. Pro jejich načtení a zobrazení se v systému nejdříve spustí SQL dotaz (využívá entity Event a DKPerson pro zjištění příslušných úkolů a jejich vlastníků), výsledek je potom převeden do interní datové struktury a uživatelského rozhraní. Tuto posloupnost akcí zobrazuje následující kód. IBC.RunSQL('SELECT E.LDCust, E.LD, T.LD, PI.Name, PI.Surname, ' + 'P2.Name, P2.Surname, T.TDate, T.SDate, T.CDate, T.TDes FROM ' + 'Event E, Task T, DKPerson PI, DKPerson P2 WHERE T.LDEvent=' + Event ID + ' AND T.LDEvent=E.ID AND T.LDOwner=Pl.ID AND ' + 'T.LDHead=P2.ID;'); TaskArray := SynopFP.GetTaskArray(LBC); { Všechny úkoly se zaradi do seznamu ComboBoxTask, TaskArray uchováva jejich príslušne ID zakaznika, ID udalosti, ID ukolu. } ComboBoxTask.Items.Clear; IBC.GetQuery.First; I~:= 1; while not IBC.GetQuery.Eof do begin ComboBoxTask.Items.Add(IntToStr(I) + ') ' + IBC.GetQuery.Fields[10].AsString); Inc(I) ; IBC.GetQuery.Next; end;

Po přidání nového úkolu se uživateli automaticky vygeneruje e-mailová zpráva (ve stan­ dardním poštovním klientovi, např. Microsoft Outlook), kterou může poslat vedoucímu. Tato funkce je implementována ve třídě TSystemFP a využívá služeb Windows API. M a i l := ' m a i l t o : ' + A R e c e p i e n t + ' ? s u b j e c t = ' + A S u b j e c t + '&body=' + AText; ShellExecute(AHandle, ' o p e n ' , PChar(Mail), n i l , n i l , SW_SHOWNORMAL); 4.6

Dynamické sestavy

Jednotka Report slouží pro dynamické generování sestav. Dynamické proto, že sestavy nejsou pevně zadané a uživatel je skládá ze sady předem definovaných parametrů. Oproti tomu statické mají pevnou strukturu a používají se v celém systému k ukládání a načítání dat. Následuje příklad takové sestavy (spouštěné v jednotce Customer), která má za úkol zobrazit informace o daném zákazníkovi. 42

4. IMPLEMENTACE

{ N a s t a v e n i h l a v n í c h i n f o r m a c i o daném z a k a z n i k o v i . } IBC.RunSQL ('SELECT C I D , C.Code, C.Name, C.ICO, C.DIC, C . S t r e e t , ' + ' C . C i t y , C . P o s t a l C o d e , Dl.DDes, D2.DDes, T e l e p h o n e , Fax, E m a i l , ' + ' WWW FROM Cust C, D i a l Dl, D i a l D2 WHERE C.ID=' + CustID + ' + 'AND C . I D R e g i o n = D l . I D AND C . I D S t a t e = D 2 . I D ; ' ) ; Dynamické sestavy vznikají podle parametrů zadaných uživatelem. Ten má k dispozici výběr ze čtyř oblastí (zákazník, událost, záznam a úkol), z nichž každá obsahuje sadu para­ metrů (některé lze ještě omezit hodnotou). Zvolené atributy se mezi sebou logicky uspořá­ dají, poté je z nich vygenerována sestava a uložena do souboru ve formátu Microsoft Excel. Následující nastavení parametrů vytvoří sestavu, která zobrazí k tuzemským zákazníkům všechny události (konané od 1.11.2005 do 1.2.2006) s jejich vlastníky a příslušnými zá­ znamy (u nich bude uveden typ, předmět a popis). •

zákazník - název, stát (omezen na Českou republiku)

•

událost - datum (omezeno na časové období od 1.11.2005 do 1.2.2006), vlastník

•

záznam - typ, předmět, popis

Celá podstata spočívá ve vytvoření správného SQL dotazu. Postačuje vyplnit klauzule SELECT, FROM a WHERE, žádné další jako GROUP BY nebo HAVING nejsou využívány. Pří­ prava dotazu probíhá ve třech fázích. 1. fáze - analýza parametrů Všechny zvolené parametry se postupně doplní do klauzule SELECT, podle jejich umístění v datovém modelu se naleznou příslušné entity, které se přidají do struktury U s e d E n t i t y . Ke každému atributu se až do konce jeho vyhodnocení váže typ konverze (bez převodu, převod na datum, převod na text bez středníků,...). 2. fáze - nalezení závislostí mezi entitami Klauzule FROM se doplní entitami uloženými ve struktuře UsedEnt i t y . Dalším krokem je přidání jejich závislostí do SQL dotazu (např. entita EVenr je závislá na entitě Cust takto C u s t . ID=Event. IDCust). K tomu se používá konstantní pole E n t i t y D e p , které definuje pro každou dvojici entit jejich případnou závislost. 3. fáze - omezení výběru Všechny parametry omezené hodnotou se přidají do klauzule WHERE. Některé mohou být vymezeny jedinou hodnotou (skupina zákazníka, typ události,...), některé intervalem (da­ tum události, termín splnění úkolu,...), např. Cust .Code=' Z0000001000'. Po dokončení třetí fáze se už může sestavený SQL dotaz spustit. Výsledek je načten do interní struktury, sloupce atributů konvertovány do předem nastavených formátů a poté vše exportováno do uživatelem zvoleného souboru. 43

4. IMPLEMENTACE

4.7

Zámky

Některé funkce systému mohou být během jednoho časového úseku zpracovávány maxi­ málně jedním uživatelem. Pokud by tomu tak nebylo, mohlo by dojít k narušení konzis­ tence dat. Řeší se v podstatě problém přístupu do kritické sekce (libovolní dva uživatelé si mohou ve stejný okamžik požádat o zpřístupnění téže funkce). Následující seznam ukazuje všechny funkce vyžadující výlučný přístup. •

správa číselníků

•

správa uživatelských účtů

•

úprava zákazníka

•

smazání zákazníka

•

správa karty zákazníka (všech jeho poboček)

Řešení je poměrně jednoduché, na úrovni databáze je vytvořena entita Lock, která řídí přístup k takovým funkcím. Každá má své jedinečné identifikační číslo LAction a podle příznaku Flag (0 - odemčená, 1 - uzamčená) se určuje, zda může být zpracována. Kontrolu a případné uzamčení příznaku je potřeba provést jako atomickou akci. K tomu slouží třída TLock implementovaná v jednotce Monitor. Obsahuje dvě funkce Lock a Unlock pro uzamčení, resp. odemčení záznamu. Uzamčení funkce se provádí po­ mocí SQL příkazu UPDATE, který se pokusí nastavit příznak Flag na 1 (pouze v případě, že už tak není učiněno). Podle počtu ovlivněných záznamů se zjistí, jestli nastavení proběhlo úspěšně, či nikoliv. Tím je tedy zaručena atomicita a nemůže se stát, že dva uživatelé budou ve stejnou chvíli využívat jednu funkci. Pokud je záznam uzamčen a uživatel se k němu pokusí přistoupit, zobrazí se chybové hlášení s dočasným vlastníkem funkce a dobou používání.

44

Kapitola 5

Testování Každý nově vyvíjený systém obsahuje chyby Nutnou součástí vývoje je testování, které ověřuje správnou funkčnost nebo napomáhá naleznout případné chyby Princip je založen na testovacích datech, ta jsou spouštěna jednotlivými funkcemi a na nich se zjišťují patřičná selhání. Celý proces probíhá ve třech fázích [5]. •

Testování částí.

•

Testování při integraci - celku složeného z předem otestovaných částí.

•

Testování při předání - předvedení uživateli.

5.1

Vytvoření funkčních testů

Systém není tak rozsáhlý, aby mělo cenu vytvářet a plánovat složité testovací protokoly a implementovat řadu dalších funkcí. Stačí se zaměřit na všechny specifikované funkce a provést jejich neformální kontrolu. Základní testování jednotlivých částí bylo provedeno už na úrovni implementace, integrační testy vždy během kompletace několika jednotek. Samotné testování probíhalo za účasti všech členů týmu, každý z nich dostal přesné pokyny pro jejich vyhodnocení. Zjištěné chyby byly detailně dokumentovány podle následujících atributů: •

stručný popis,

•

vstupy,

•

očekávané výstupy,

•

skutečné výstupy,

•

pokusy o opakování včetně jejich výsledků,

•

doba zjištění,

•

testující osoba.

5.2

Vyhodnocení testů

1. Při určité posloupnosti akcí se během správy dokumentů na úrovni zákazníka zob­ razuje chybové hlášení s neplatným přístupem do paměti. Důvod: při výběru jedné a potom všech poboček zákazníka zůstaly zobrazeny všechny dokumenty (namísto pouze těch příslušných dané pobočce), zvolení některého tedy mohlo vyvolat chybu. 45

5. TESTOVÁNÍ

2. Někdy se při správě záznamů zobrazí chyba s neplatným SQL příkazem a úprava daného záznamu se neprovede (často vzniká při kopírování textu e-mailů do popisu záznamu). Důvod: pokud se v předmětu nebo popisu záznamu použil znak apostrofu, nebyl SQL příkaz správně sestaven (apostrofy se používají pro oddělení textových řetězců od struktury SQL příkazu). 3. Během výběru všech poboček zákazníka a posléze dané události se zobrazí chybové hlášení s neplatným přístupem do paměti. Důvod: totožný problém jako u správy dokumentů. 4. Chyba při generování e-mailu pro vedoucího - není vyplněna správná adresa pří­ jemce. Důvod: špatné přiřazení v implementaci této funkce za daných okolností vypl­ nilo e-mailovou adresu jiné osoby než vedoucího.

46

Kapitola 6

Instalace a údržba systému Závěrečnou fází projektu je instalace systému, školení uživatelů, konverze dat a jeho pře­ dání zákazníkovi. Poté nastává dlouhá doba na údržbu, která především zajišťuje přidání nových a změnu stávajících požadavků. 6.1

Předání

Instalace proběhla bez větších komplikací, přispěl k tomu rovněž fakt, že databázový sys­ tém InterBase už nějakou dobu běží na serveru jako služba. Uvedení do provozu spočívalo ve vytvoření prázdné databáze, nahrání aplikace na síťový disk a nainstalování klientů do osobních počítačů obchodníků. Bylo potřeba zajistit, aby do adresáře s aplikací měli přístup pouze příslušní uživatelé. Databáze, kterou tvoří jediný soubor, může být uložena mimo hlavní aplikaci a uživatelé k ní dokonce nemusí mít právo přístupu (InterBase je totiž spouš­ těn jako systémová služba). Dalším krokem bylo seznámení uživatelů se systémem. Skolení probíhalo celkem dva­ krát, poprvé pro vedení společnosti a nejzainteresovanější skupinu obchodníků, podruhé pro oddělení prodeje. Uživatelům byly vysvětleny všechny funkce systému, administrá­ torům pak správa běžných účtů, odemčení zablokovaných funkcí a datový model (kvůli hromadné úpravě dat). Ihned po instalaci mohl být systém spuštěn a používán, ovšem databáze byla prázdná a tak bylo zapotřebí ji naplnit daty. Nejdříve se do všech kategorií číselníku ručně zadaly relevantní zkratky a k nim příslušné popisy. Poté se ze systému S21 exportovala statická data o zákaznících a importovala se do databáze. Některé atributy využívající číselník (kraj, stát, skupina a typ zákazníka) se musely zadat posléze. 6.2

Rozšíření

Během jednoho roku provozu vzešla řada požadavků na změnu systému. To ale nezna­ menalo, že návrh byl proveden špatně, změny spočívaly spíše v rozšíření funkcionality a doplnění některých informací. Následující seznam ukazuje všechny úpravy provedené od původního návrhu. Verze 1.1 •

Přidáno nové pole Poznámka (Text[100]) do sekce dalších informací zákazníka.

•

Tlačítka Zrušit používané v celém systému byly nahrazeny tlačítky Zpět, lze je ovládat pomocí horké klávesy F12. 47

6. INSTALACE A ÚDRŽBA SYSTÉMU

Opravena chyba při výběru události nebo dokumentu v zákaznické kartě. Opravena chyba, která nedovolila zadat znak apostrofu do předmětu záznamu. Opravena chyba u generování adresy příjemce e-mailu. Opravena gramatická chyba textu v sekci Nastavení. Pokud má některý ze zaměstnanců zákazníka narozeniny, zobrazí se uživatelům upo­ zornění, na kterém je místo kódu zákazníka uveden jeho název. Přidán nový sloupec Popis do oblasti záznamu v sekci dynamických sestav. U přehledu vlastních úkolů příslušných k daným zákazníkům se místo kódu zákaz­ níka zobrazuje pouze jeho název. Zvětšena kapacita pole Předmět (z Text[30] na Text[60]) ve správě záznamu. Podle uživatelského nastavení se může v zákaznické kartě zobrazovat náhled dané události (zobrazují se všechny příslušné záznamy a přiložené dokumenty). Zvětšena kapacita pole Platební podmínky formací zákazníka.

(z Text[30] na Text[90]) v sekci dalších in­

Verze 1.2 U přehledu vlastních úkolů příslušných k daným zákazníkům se mohou úkoly spra­ vovat přímo, bez nutnosti otevření zákaznické karty. Přidána nová pole Majitel (Text[100]), Obrat (Text[50])„ Základní kapitál (Text[50]), Reklamní předměty (Text[300]) a Počet zaměstnanců (Text[50]) do sekce dalších infor­ mací zákazníka. Zvětšena kapacita polí Poznámka (z Text[100] na Text[600]) a Konkurence (z Text[30] na Text[300]) v sekci dalších informací zákazníka. Přidány nové dva atributy Odpovědná osoba (má na starosti firmu z hlediska jednání) a DK dodávky (má na starosti firmu z hlediska fakturace) na úrovni zákazníka. Po vytvoření nové události se její vlastník automaticky přednastaví jako jeden ze zá­ stupců uživatelů. Při úpravě události se kontroluje správnost vyplněného hodnocení (u návštěvy musí být vyplněno, u e-mailu nemusí, ale zobrazí se varovné hlášení, telefon a fax se nekon­ trolují). Přidáno nové zaškrtávací políčko Zobrazovat upozornění během nastaveného počtu dní. Pokud je zaškrtnuto, danému uživateli se zobrazuje upozornění na narozeniny každý den během nastavených x dní předem, v opačném případě pouze jednou - x dní předem. Jelikož výše uvedené změny měly pouze lokální charakter, nebylo žádným problémem takové funkce implementovat. Přidání nebo úpravy velikosti některých atributů vyžado­ valy změnu přímo na úrovni datového modelu. Databáze se vždy nejdříve zálohovala a poté se na ni pomocí SQL příkazů provedly příslušné modifikace. 48

6. INSTALACE A ÚDRŽBA SYSTÉMU

Budoucnost Současná verze Synop 1.2 je stabilní a během půlroku používání v ní nebyly zaznamenány žádné chyby. Objevily se však další požadavky na rozšíření systému. Několik obchodníků, kteří tráví hodně času na cestách, navrhlo vytvoření cestovní verze. Ta by měla být přístupná offline, po připojení k serveru by se data synchronizovala. Každý takový obchodník by mu­ sel mít uloženou lokální databázi na svém notebooku (to by znamenalo mít kromě klienta nainstalovaný ještě InterBase server). Tento přístup má hned dvě nevýhody: 1. synchronizace dat přináší řadu problémů - data nejsou aktuální, databázový model bude muset být upraven, modifikace nebo smazání záznamů může při synchronizaci způsobit kolaps systému, 2. licence na InterBase server je poměrně drahá (tu by musel vlastnit každý obchodník). Druhým způsobem řešení může být online připojení přímo k databázovému serveru. Tuto metodu ale nelze použít, protože to nedovoluje bezpečnostní politika společnosti. Pro­ blém cestovní verze tak zůstává prozatím nevyřešen. Dalším požadavkem o rozšíření systému je zobrazení všech pohledávek a závazků ke zvolenému zákazníkovi, resp. dodavateli. Uživatelům by se naskytla možnost posouzení důvěryhodnosti zákazníka (kolik faktur bylo zaplaceno před nebo po termínu splatnosti). Data by se musely exportovat ze systému S21 (třeba každý den po půlnoci), což by samo­ zřejmě vyžadovalo úpravu datového modelu a vytvoření pomocného programu pro jejich import do databáze.

49

Kapitola 7

Závěr Systém Synop umožňuje kompletní správu komunikace se zákazníkem. Každému uživateli poskytuje funkce pro správu zákazníků, událostí, přiložených dokumentů, úkolů a vlast­ ního vzhledu a chování aplikace. Dále umožňuje exportovat zápisy z jednání a dynamicky generovat strukturované sestavy z databáze. Prvotním záměrem této implementace bylo simulování činnosti profesionálních CRM systémů. Získat zkušenosti, ujasnit si nejdůležitější požadavky a cíle a pomocí nich stano­ vit kritéria pro případné zavedení jiného robustního systému. Nabízí se alternativy jako IS Leonardo, Microsoft CRM nebo SAP Business One (ta je prozatím nejpravděpodobnějším řešením). Během jednoho roku provozu se ale tento systém neustále rozšiřuje a tak není ani zavrhnuta možnost jeho uplatnění i nadále. Následující seznam ukazuje počty vybraných atributů databáze a jejich stav k 15.3.2006. •

26 evidovaných uživatelů

•

4142 událostí a k nim 5194 záznamů

•

725 zákazníků, z toho 478 potencionálních

•

2 740 přiložených dokumentů (dohromady na úrovni zákazníků a událostí)

•

1191 zaměstnanců (evidovaných u všech zákazníků)

50

Literatura [1] IS Leonardo. < h t t p : //www. d s i s . c z / p r o d u k t y - a - s l u z b y / l e o n a r d o / > . [2] Draka Kabely, < h t t p : / / w w w . d r a k a . c z > . [3] N. El-Lababidi. HP Services, < h t t p : / / w w w . h p . c z / s e r v i c e s / i n t e g r a c e / p d f / 2 0 0 4 - 1 2 - c r m - i m p l e m e n t a c e . pdf >, 2004. [4] L. Grásgruber. Historie CRM systémů, prehledy_systemu/crm/>.


[5] J.Král. Informační systémy - Specifíkace, realizace, provoz. tiny 212,1998.

SCIENCE, 68733 Vele-

[6] Microsoft Dynamics CRM. < h t t p : / / w w w . m i c r o s o f t . com/crm/>, 2006. [7] SmallBizCRM. CRM history, h t m l >, 2005.


[8] J. Sochor. Analýza a návrh systémů. < h t t p : //www. f i .muni . c z / ~ s o c h o r / P B 0 0 7 / >, 2002. [9] P. Zižka. CRM ve společnosti pro výzkum trhu. prezentace/STEM.ppt>,2004.


[10] P Čermák. Efektivní investice do CRM. < h t t p : / / e x p o r t n i k l u b . c z e c h t r a d e . cz/dokumenty/exportniklub/zari/zari-prezentace-Siemens.pdf>.

51

Příloha A

CD Součástí této práce je i přiložené CD, které má následující strukturu. •

\manual.txt - popis instalace systému Synop

•

\source\*.* - zdrojové kódy systému Synop

•

\Synop\ -

•

Config.ini - konfigurační soubor pro inicializaci spojení se serverem Synop.gdb - databáze naplněná testovacími daty Synop.exe - hlavní aplikace

\thesis\ -

pics\*.pdf - všechny obrázky použité v této práci ve formátu pdf thesis.pdf - tato práce ve formátu pdf

52