Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

Vyšší odborná škola informačních služeb

Specifikace požadavků pro implementaci nových procesů do firemního CRM systému

Vypracovala: Dana Čapkovičová

Vedoucí práce: Ing. Marek Růžička

Rok vypracování: 2010

2

Čestné prohlášení:

Prohlašuji, že jsem tuto bakalářskou práci vypracovala samostatně. Veškeré

použité podklady, ze kterých jsem čerpala informace, jsou uvedeny v seznamu

použité literatury a citovány v textu podle normy ČSN ISO 690.

V................. dne .... Podpis: ..............................................

3

Poděkování:

Tímto bych chtěla poděkovat svému vedoucímu bakalářské práce Markovi

Růžičkovi, který mne plně podpořil při zpracovávání této práce, jak morálně, tak

i svými odbornými znalostmi. Také bych ráda poděkovala svému nadřízenému

panu Davidovi Pečenkovi, který mi pomohl získat mnoho informací k úspěšnému

zpracování mé bakalářské práce.

4

Anotace

Cílem této bakalářské práce je zpracovat na high-level úrovni požadavky

spojené s implementací nových procesů do existujícího CRM systému FX.

Konkrétně se jedná o procesy spojené se zpracovávání požadavků koncových

zákazníků (spotřebitelů) 2 významných leteckých přepravců. Požadavky se

týkají buďto rezervací letenek nebo podpory uživatelů webových stránek těchto

společností. Jsou podporovány následující komunikační kanály: telefonické

hovory, e-maily, faxy, požadavky získané z rezervačního systému Amadeus.

Výstupy této práce budou dále použity pro zpracování detailní analýzy procesů a

následný vývoj.

Tato práce je rozdělena do následujících tématických celků:

1. Úvod a teorie informačních systémů

2. Seznámení s prostředím společnosti XYZ a vztahy mezi zúčastněnými

stranami

3. High-level analýza požadavků

4. Závěr.

5

Anotation

The goal of this bachelor thesis is to define the high-level business

requirements related to implementation of new processes to already existing

CRM System FX.

There is needed to implement the processes related to processing requests

coming from the end clients of two international airlines. Requests can be

related to the flight tickets reservation process or to the support of the web

users. There are following supported communication channels: calls, e-mails,

faxes and requests retrieved from the reservation system Amadeus.

Outcomes of this bachelor thesis will be further used for deeper analyzing the

processes and further development.

This thesis is divided into following topics:

1. Introduction and theory of information systems

2. Introduction to the environment of the company XYZ and relations

between stakeholders

3. High-level analysis of the requirements

4. Conclusion.

6

Obsah

1 Úvod..............................................................................................................8

1.1 Struktura bakalářské práce.......................................................................8

1.2 Cíl bakalářské práce.................................................................................9

1.3 Předpoklady a omezení ............................................................................9

2 Informační systémy....................................................................................... 10

2.1 Aplikační Software ................................................................................. 10

2.2 CRM systém.......................................................................................... 11

2.2.1 Firemní CRM systém...........................................................................11

2.3 Reportingové nástroje............................................................................ 12

2.3.1 Firemní reportingové nástroje .............................................................12

2.4 Ostatní IS využívané ve společnosti XYZ.................................................. 13

3 Seznámení s prostředím................................................................................. 14

3.1 Představení společnosti.......................................................................... 14

3.1.1 Historie společnosti ............................................................................14

3.1.2 Organizační struktura společnosti ........................................................15

3.2 Prostředí vývojového týmu ..................................................................... 16

3.2.1 Metodika Scrum.................................................................................16

4 Úvod do situace ............................................................................................ 20

5 Analýza zúčastněných stran ........................................................................... 22

5.1 Definice pojmů...................................................................................... 22

5.2 Cibulový model analýzy zúčastněných stran ............................................. 22

5.2.1 Přehled zúčastněných stran ................................................................24

6 Vymezení oblastí pro implementaci ................................................................. 29

6.1 Agentské aktivity ................................................................................... 29

6.2 Manažerské aktivity ............................................................................... 30

6.3 Aktivity systémového administrátora ....................................................... 30

7

6.4 Spolupráce s externími systémy.............................................................. 31

7 Vymezení funkčních a nefunkčních požadavků ................................................. 33

7.1 Funkční požadavky pro jednotlivé oblasti ................................................. 33

7.1.1 Zavedení nového kontraktu do databáze..............................................34

7.1.2 Obsloužení telefonického kontaktu od spotřebitele ................................37

7.1.3 Zpracování písemného kontaktu od spotřebitele ...................................41

7.2 Nefunkční požadavky............................................................................. 56

7.2.1 Časový plán.......................................................................................56

8 Závěr ........................................................................................................... 57

9 Seznam použitých zkratek a vysvětlení některých pojmů................................... 58

10 Použitá literatura....................................................................................... 59

10.1 Ostatní čerpané zdroje........................................................................... 60

8

1 Úvod

Tato bakalářská práce se zabývá problematikou analýzy požadavků pro

implementaci nových procesů do již existujícího firemního CRM systému ve

společnosti XYZ. Společnost XYZ se zabývá outsourcovanou péčí o zákazníky

především evropských leteckých přepravců. Tato práce je vypracována

z pohledu „Product Ownera“ (dále specifikováno v kapitole 3.2.1 Metodika

Scrum).

Konkrétně se jedná o podporu koncových zákazníků dvou významných

světových leteckých přepravců (ABC a DEF) při rezervaci letenek (včetně

samostatné rezervace letenek). Dva základní požadavky na implementaci jsou:

• Umožnit agentům zpracovávání požadavků zákazníků.

• Dodat data potřebná pro fakturaci a interní firemní statistiky

(produktivita, efektivita, průměrná doba zpracovávání jedné stížnosti...).

Tyto dva základní požadavky budou v mé bakalářské práci dále rozvedeny,

rozčleněny do menších celků a analyzovány.

Tuto problematiku jsem zvolila, jelikož jsem jisté zkušenosti s implementací

nových procesů do firemního CRM systému získala již dříve a v rámci této

bakalářské práce bych si chtěla ověřit schopnost samostatně aplikovat

zkušenosti v praxi.

1.1 Struktura bakalářské práce

Práce je rozdělena do několika částí, které odpovídají jednotlivým fázím analýzy

požadavků:

• Seznámení s prostředím (historie společnosti, historie firemního CRM

systému, náplň aktivit v současné době zpracovávaných ve firemním

CRM systému)

• Výstup z fáze sběru požadavků – seznam funkčních a nefunkčních

požadavků na systém.

9

• Samotná analýza požadavků (identifikace nejasných či protichůdných

požadavků a následné vyjasnění).

1.2 Cíl bakalářské práce

Cílem této bakalářské práce je analyzovat na high-level úrovni požadavky

spojené s implementací nových procesů do existujícího firemního CRM systému.

Výstupy této práce budou sloužit jako podklad pro další analýzu a zpracování

technického designu budoucího řešení a následný vývoj.

Pro úspěšnou implementaci nových produktů (a souvisejících procesů) do CRM

systému, který mimo jiné slouží jako nástroj pro distribuci práce jednotlivým

agentům je nutno definovat také pravidla pro distribuci práce agentům a další

nastavení. Toto téma však není předmětem mé bakalářské práce, proto bude

v mé práci zmíněno jen okrajově.

1.3 Předpoklady a omezení

Jedním z předpokladů pro úspěšné zpracování této bakalářské práce je včasné

dodání podkladů klientem popisující procesy pro zpracovávání požadavků

koncových zákazníků. Vzhledem k tomu, že organizační struktura klienta

prochází v současné době reorganizací včetně změny stávajících procesů, klient

nebude schopen dodat požadované podklady včas.

Vzhledem k velmi napjatému časovému plánu (dodání systému je očekáváno ve

3. čtvrtletí 2010) a nedostatku podkladových materiálů budu muset z velké části

vycházet ze zkušenosti s předchozí implementací podobného procesu do

firemního CRM systému.

10

2 Informační systémy

V dnešní době jsou Informační Systémy (dále pouze jako IS) zavedeny v téměř

každé komerční i nekomerční organizaci. Informační systém se dá obecně

definovat jako jakákoliv kombinace informačních technologií (dále pouze jako

ICT) a lidských aktivit, které tyto informační technologie využívají k podpoře

produkce, managementu a rozhodování pomocí sběru, přenosu, uchovávání,

zpracovávání a prezentace dat a informací.

Do ICT technologií spadá: Software (programové vybavení) a Hardware

(technické vybavení). Do oblastí lidských aktivit pak spadá: Peopleware (lidský

faktor), Orgware (organizace společnosti). Tyto dvě oblasti pak ještě doplňuje

kontext prostředí okolo IS (legislativa, kvalitativní normy, dostupné informační

zdroje atd.).

V oblasti IS je nutné rozlišovat mezi dvěma základními pojmy:

• Informace – údaj o reálném prostředí, jeho stavu a procesech v něm

probíhajících. Informace se dá pokládat za sdělení eliminující nevědomost

či nejistotu.

• Data – informace vhodně formalizovaná pro komunikaci, interpretaci a

zpracovávání jak lidmi, tak automaty. Data zpravidla nemají vlastní

smysl, dokud nejsou nějakým způsobem interpretována, zpracována či

komunikována. V tento okamžik se z dat stávají smysluplné informace.

[1]

2.1 Aplikační Software

Aplikační Software (dále pouze ASW) je z oblasti ICT nejpodstatnější

komponentou pro podporu Businessu.

Základními typy ASW jsou:

• ERP (Enterprise Resource Planning) systém - SW pro plánování a řízení

podnikových zdrojů, jako např. prodej, nákup, sklady, finanční účetnictví,

controlling, majetek, mzdy, plánování a řízení výroby.

11

• CRM (Customer Resource Management) systém - SW pro řízení vztahů

se zákazníky. [2]

• SCM (Supply Chain Management) – SW pro zajištění zdrojů, výrobu nebo

přeměnu, skladování, distribuci a dodání výrobků k zákazníkům. [3]

• ECM (Enterprise Content Management) – podnikový SW používaný pro

organizaci, uchovávání a distribuci informací nezbytných k provozu

podniku. [4]

• ... a mnoho dalších...

2.2 CRM systém

CRM systém má mnoho různých definicí. Jedním z možných pojetí jak chápat

CRM systém (z pohledu IS) je jako nástroj pro správu vztahu mezi dodavatelem

a zákazníkem. Tento vztah prochází různými etapami - od prvotního kontaktu

(vytvoření záznamu zákazníka v CRM) přes různé epizody (spojené se

vzájemnou komunikací mezi dodavatelem a zákazníkem) až po ukončení tohoto

vztahu. Součástí CRM systému nemusí být pouze správa zákazníků, ale i správa

vztahů se subdodavateli, kteří např. dodávají své služby přímo zákazníkovi.

2.2.1 Firemní CRM systém

Dále v textu je označován pouze jako FX. FX je CRM systém pro zpracovávání

telefonické i písemné komunikace s koncovými zákazníky klientů společnosti

XYZ. Zpracovávání jednotlivých požadavků je řízeno workflow procesy kdy je

agent celým procesem zpracovávání požadavku spotřebitele proveden krok za

krokem. FX také umožňuje správu produktových a jazykových znalostí

jednotlivých agentů a prioritizaci jednotlivých úkolů dle mnoha různých kritérií.

Na základě těchto pravidel je pak práce distribuována agentům.

12

Obrázek 1 - Distribuce požadavků spotřebitelů v CRM systému FX

2.3 Reportingové nástroje

Pro efektivní management produkčních procesů je třeba mít k dispozici

informace získané z dat z produkčního systému. Toto je možné za použití

Business Intelligence (dále pouze BI) nástrojů, které slouží ke sběru, integraci,

analýze, interpretaci a prezentaci informací.

Jednou z oblastí BI nástrojů jsou Reportingové a dotazovací nástroje. Tyto

nástroje slouží k extrakci, setřízení, sumarizovaní a prezentování dat vybraných

dle zadaných kritérií z různých zdrojů dat ve člověku srozumitelné podobě.

2.3.1 Firemní reportingové nástroje

Ve společnosti XYZ se pro reportování používá řešení MS SQL Server Reporting

Services (dále pouze jako MS SQL SRSS). Toto řešení obsahuje nástroje a

služby pro tvorbu, publikování a správu reportů, stejně jako umožňuje rozšíření

a přizpůsobení funkcí jednotlivých reportingových nástrojů.

Data pro reporting jsou uložena v datovém skladu (dále pouze DWH), do

kterého jsou pravidelně nahrávána data z produkčních a podpůrných systémů.

DWH také umožňuje nahrávání dat z externích zdrojů mimo společnost XYZ

(např. předpovědi o objemu požadavků koncových klientů pro dané období a

daný produkt).

13

2.4 Ostatní IS využívané ve společnosti XYZ

Vzhledem k širokému portfoliu služeb a zákazníků, které společnost XYZ

obsluhuje, jsou ve společnosti využívány mnohé další IS. Některé z nich jsou

produkčními systémy, některé z nich systémy podpůrné (např. CRM systémy

dodané zákazníkem, znalostní databáze atd.).

14

3 Seznámení s prostředím

3.1 Představení společnosti

Společnost XYZ je outsourcingová společnost specializující se na poskytování

služeb „Péče o zákazníky“ koncovým zákazníkům mnoha významných leteckých

společností stejně tak jako jiných společností z jiných odvětví cestovního

průmyslu.

Společnost XYZ je dceřinou společností mezinárodní společnosti (JKL), která

patří do skupiny významné evropské letecké společnosti (GHI).

Po celém světě má společnost JKL dvě excelentní centra zákaznické podpory a

osm center servisních.

Obrázek 2 - Sídlo a pobočky společnosti JKL

3.1.1 Historie společnosti

Společnost XYZ byla zapsána do obchodního rejstříku v roce 2003. Společnost

vznikla jako dceřiná společnost mezinárodní společnosti pohybující se ve světě

pojišťovnictví a dceřinou společností významné evropské letecké společnosti

(GHI) zabývající se zákaznickou péčí o členy věrnostního programu této letecké

společnosti.

15

Oficiálně byla společnost otevřena koncem roku 2003. V době otevření měla

společnost 60 zaměstnanců a obsluhovala ve čtyřech světových jazycích

(angličtina, francouzština, španělština, němčina) telefonickou zákaznickou linku

pro společnost GHI poskytující informace o zpožděných, ztracených a

poškozených zavazadlech.

Společnost každým rokem rostla a rozšiřovala své portfolio obsluhovaných

produktů, jazyků a trhů. V roce 2005 se portfolio poskytovaných služeb rozšířilo

o nový typ produktu – řešení komerčních stížností pasažérů leteckých

společností.

V roce 2006 bylo učiněno rozhodnutí, že stávající produkční systém nahradí

systém nový – vyvinutý interně. V roce 2007 se naplno rozběhl projekt FX

(vývoj vlastního systému, který měl nahradit systém stávající, který vzhledem

k růstu portfolia společnosti již nebyl vyhovující). V květnu 2008 byl FX poprvé

nasazen do produkce. První produkční verze FXu pokrývala front-office procesy

pro řešení zavazadlových incidentů a back-office procesy pro řešení

zavazadlových a komerčních incidentů.

V roce 2008 se portfolio produktů rozšířilo o zákaznické centrum poskytující

služby pro členy věrnostních programů jak letecké společnosti tak

mezinárodního hotelového řetězce. V roce 2009 se otevřela pobočka v Austrálii,

kde byl jako produkční systém nasazen FX.

V roce 2010 společnost zaměstnává přibližně 250 zaměstnanců. Na podzim roku

2010 začne společnost obsluhovat rezervace a podporu zákazníků pro dvě

významné letecké společnosti (ABC, DEF) pro německý, rakouský a švýcarský

trh.

3.1.2 Organizační struktura společnosti

Společnost je rozdělena do pěti oddělení. Provozní oddělení je dále rozděleno

do 4 produkčních jednotek (většinou produkty s podobnými procesy nebo

spadající pod jednoho klienta). V každé z těchto produkčních jednotek je FX

nějakým způsobem využíván (i produkční jednotky využívající jiné produkční

16

systémy používají FX alespoň jako nástroj pro měření doby trvání specifických

aktivit).

Obrázek 3 - Organizační struktura společnosti XYZ

3.2 Prostředí vývojového týmu

IT / IS Manager

Business Analyst SW Development Manager

Senior SW Tester

SW Tester

SW Tester Senior SW Engineer II

Senior SW Engineer III

Senior SW Engineer I (SW Architect)

SW Developer I

SW Developer II SW Developer III

SW EngineerDatabase Developer I

Database Developer II

Obrázek 4 - Organizační struktura vývojového týmu

3.2.1 Metodika Scrum

Vývoj je veden dle metodiky Scrum. Ta se řadí mezi agilní metodiky

softwarového vývoje. Je zaměřena především na projektové řízení. Dle autorů

17

této metodiky (Ken Schwaber, Jeff Sutherland a Mike Beedle) musí být vývoj

chápán jako empirický proces, který není možno předvídat, ale je nutné jej

monitorovat. Scrum znamená v češtině skrumáž (mlýn) v rugby. Tento název

byl vybrán, protože tato metodika je stejně jako rugby adaptivní, rychlá a

postavená na samoorganizujících se týmech. Její princip spočívá ve specifickém

rozdělení rolí a krátkých vývojových obdobích – iteracích (anglicky Sprint) po

kterých tým dodá funkční produkt (nové či modifikované funkcionality systému).

Nejdůležitější praktikou této metodiky jsou denní porady (Scrum meetings)

které jsou důležité pro monitorování stavu projektu, identifikaci možných

omezení a překážek a koordinaci prací jednotlivých členů týmu. Tyto denní

porady se konají každý den ve stejnou dobu na stejném místě a optimální doba

jejich trvání je 15 až 30 minut a musí se jí účastnit všichni členové týmu.

Přizváni mohou být i manažeři a Product Owner, tito účastníci však do porady

nesmí nijak vstupovat. Porada je vedena Scrum Masterem. Během této krátké

porady musí každý člen týmu zodpovědět na 3 otázky:

1. Co udělal od poslední porady.

2. Co bude dělat teď.

3. Co jsou možná omezení a překážky pro řešení úkolů.

Scrum je rozdělen do 4 fází:

1. Plánovací fáze (anglicky Planning phase), během které se specifikují

požadavky a vytváří se plán pro příští iteraci.

2. Vynášecí fáze (anglicky Staging phase), během které se do seznamu

požadavků zařadí i nefunkční požadavky.

3. Fáze vývoje (anglicky Development phase), během které tým vyvíjí

funkcionality s nejvyšší prioritou; na konci každé iterace tým prezentuje

výsledky své práce demonstrací jednotlivých funkcionalit.

4. Fáze dodávky (anglicky Release phase), během které je produkt předán

uživatelům.

18

3.2.1.1 Rozdělení rolí dle metodiky Scrum

• „Scrum Master (dále SM)“ – člověk zajišťující správné fungování

vývojového týmu, společně s Product Ownerem se podílí na plánování

jednotlivých sprintů. V našem případě se jedná o development

managera.

• „Product Owner (dále PO)“ – člověk zajišťující komunikaci se zákazníkem

(tato role vystupuje jako zástupce zákazníka a hájí jeho zájmy) a

spravuje seznam požadavků (anglicky Product backlog) tak aby byla

hodnota projektu maximalizována. V našem případě se jedná o Business

analytika (já).

• „Scrum Team Member (dále STM)“ – člen vývojového týmu. V našem

případě se jedná o vývojáře, testery a Business analytika. [5], [6]

3.2.1.2 Fáze Scrumu v prostředí naší společnosti

Na počátku získá PO od zákazníka seznam požadavků setříděných podle jeho

priorit. Prioritizace požadavků probíhá na poradách, kterých se účastní zástupci

provozu z řad středního managementu. Porady jsou moderovány PO. Porady se

konají každý týden. Cílem těchto porad, na kterých PO prezentuje vybraných

několik požadavků, je ohodnotit dopad jednotlivých požadavků. Dopad je pak

vodítkem pro určení priority požadavku.

K požadavkům s nejvyšší prioritou PO sepíše „uživatelské příběhy“ (slovní popis

postupu, jak dosáhnout uspokojení požadavku zákazníka) a krátká dema, která

slouží k demonstraci funkcionality po dokončení vývoje (krok 1).

Jakmile je k dispozici seznam uživatelských příběhů, které mají momentálně pro

zákazníka nejvyšší prioritu, sejde se PO, SM a STM. PO prezentuje jednotlivé

požadavky a společně ohodnotí na základě uživatelských příběhů a dem

pracnost jednotlivých požadavků (krok 2 a 3). Takto ohodnocený seznam

požadavků se předloží zákazníkovi, který má možnost přehodnotit prioritu

jednotlivých požadavků (krok 4). Poté, co zákazník dodá finální verzi priorit

požadavků se naplánuje budoucí iterace (optimální délka iterace je 2 – 4 týdny).

19

Požadavky s nižší prioritou, které se do plánu iterace nedostaly se automaticky

přesouvají do iterací následujících (krok 5).

Každý uživatelský příběh je následně rozdělen do jednotlivých dílčích úkolů

(tasků) a rozdělen mezi členy týmu.

Na konci každé iterace se zákazníkovi předvádí demo vzniklých změn. Poté

většinou následuje předání produktu zákazníkovi, ale je možné zákazníkovi

najednou předat produkty za několik po sobě jdoucích iterací.

Obrázek 5 - Fáze plánování dle metodiky Scrum

20

4 Úvod do situace

Letecká společnost GHI, která vlastní společnost DEF uzavřela se společností

ABC dohodu o převzetí zákaznické péče na americkém a evropském trhu. Na

základě této dohody společnost ABC převezme péči o zákazníky společností DEF

a GHI na americkém trhu a společnost GHI převezme péči o zákazníky

společnosti ABC na evropském trhu.

Péče o zákazníky společnosti ABC by se měla na evropském trhu rozdělit mezi

několik kontaktních center patřících společnostem DEF a GHI. Dvěma z těchto

kontaktních center jsou společnosti XYZ a OPQ. Společnost OPQ se v současné

době stará o zákazníky společnosti DEF. Část těchto aktivit bude převedena do

společnosti XYZ. Jedná se o stejné aktivity, jaké společnost XYZ bude

poskytovat zákazníkům společnosti ABC.

Obrázek 6 - Distribuce požadavků mezi kontaktní centra

21

Vzhledem k dohodě o sjednocení procesů týkajících se rezervací letenek a

podpory zákazníků se všechny tři společnosti (ABC, DEF, GHI) dohodly, že se

tyto procesy budou řídit předpisy společnosti GHI.

Společnost XYZ proto musí o všech procesních záležitostech jednat se

společností GHI. Vzhledem k tomu, že však procesy ještě stále nejsou

společností GHI zcela definované, je mnoho požadavků na implementaci

procesů stále nejasných.

Společnost XYZ se zavázala, že bude zpracovávat jak telefonické tak písemné

požadavky spotřebitelů týkající se rezervací letenek společností ABC a DEF

stejně tak jako podpory uživatelů webu společnosti ABC a DEF. Na základě

porovnání systému Kana, který je využíván pro zpracovávání písemné

komunikace se spotřebiteli společnostmi ABC i DEF a systému FX, bylo

společností GHI nakonec rozhodnuto, že pro zpracovávání požadavků

spotřebitelů se použije systém FX.

Jelikož se jedná o zavedení zcela nových produktů do systému FX, je nutné

detailně analyzovat požadavky na zavedení procesů do systému FX.

22

5 Analýza zúčastněných stran

Jednou z podstatných myšlenek analýzy zúčastněných stran (známá také pod

anglickým názvem Stakeholders analysis) je myšlenka, že každý, kdo je

projektem ať už přímo či nepřímo nějak ovlivněn, má k projektu co říct. Aby se

k projektu měli příležitost vyjádřit všichni zúčastnění je prvně třeba je

identifikovat. K tomuto účelu právě slouží analýza zúčastněných stran.

5.1 Definice pojmů

Zúčastněná strana je někdo kdo jako důsledek projektu něco získá nebo

naopak ztratí.

Analýza zúčastněných stran je technika jak identifikovat zúčastněné osoby

obklopující projekt. Poskytuje informace o zúčastněných a jejich vztazích,

zájmech a očekáváních. Řádná analýza zúčastněných stran napomáhá

vybudovat správný přístup pro konkrétní podmínky a umožní lépe a efektivněji

jednat s jednotlivými zúčastněnými.

Cílem je určení zájmů a očekávání zúčastněných a přijmutí projektové

organizace a mechanismů pro zpětnou vazbu dle požadovaných výstupů.

5.2 Cibulový model analýzy zúčastněných stran

Cibulový model (anglicky Onion stakeholders analysis model) je jednou

z metod jak identifikovat zúčastněné strany softwarových projektů, jakým

způsobem mohou z produktu profitovat, či jaký mají vztah mezi sebou

navzájem.

Cibulový model se skládá ze čtyř vrstev zúčastněných stran. Zájmy různých

zúčastněných stran jsou reprezentovány různými rolemi, které jsou následně

přiřazené jednotlivým zúčastněným (či zástupci skupiny zúčastněných).

V ideálním případě by jedna role měla mít přiřazenu jednu zúčastněnou stranu.

V případě, že pro jednu roli je možné najít více zúčastněných stran, je velmi

pravděpodobné, že dojde ke střetu zájmů mezi těmito stranami. V případě, že

23

některá role nebude nikomu přiřazena se vystavujeme nebezpečí, že jsme

některou podstatnou zúčastněnou stranu opomenuli.

Každá vrstva v modelu odpovídá jisté rovině zainteresovanosti zúčastněných

v prostředí, kam bude produkt implementován.

První vrstva („Produkt“) reprezentuje samotný produkt, jehož doručení je

cílem projektu.

Druhá vrstva („Systém“) reprezentuje produkt a budoucí přímé uživatele

produktu (běžný operátor) a další role, které budou produkt nějakým způsobem

obsluhovat (např. administrátor produktu).

Třetí vrstva („Obklopující systém“) reprezentuje „celý Business“, tzn. Produkt,

Systém a zúčastněné strany, kteří patří do organizace implementující Produkt a

profitující z implementace produktu. Tito zúčastnění však Produkt sami

neobsluhují.

Čtvrtá vrstva („Širší okolí“) reprezentuje ostatní zúčastněné strany, které do

organizace implementující Produkt nemusí vůbec patřit. Typicky do ní patří

vývojový tým, zúčastněné strany, které profitují finančně či politicky a také

„záporné zúčastněné strany“. Typickým případem záporné zúčastněné strany

jsou budoucí uživatelé systému, kteří se budou snažit vyhnout používání nového

Produktu, jelikož jsou zvyklí na dříve užívané procesy a nástroje. Toto riziko je

více pravděpodobné u zaměstnanců, kteří již ve firmě pracují na jiných

produktech. Jedná se přibližně o jednu třetinu budoucích uživatelů. [7], [8]

24

5.2.1 Přehled zúčastněných stran

Na základě diskuse s projektovým manažerem a dalšími zúčastněnými stranami

jsem vypracovala schéma zachycující všechny zúčastněné strany, kterých se

projekt nějakým způsobem dotýká (Obrázek 7).

Obrázek 7 - Přehled zúčastněných stran (cibulový model)

Poznámka: Jelikož názvy mnoha rolí lze do češtiny přeložit pouze opisným

tvarem (což by značně snížilo přehlednost schématu), jsou ve schématu

ponechány anglické názvy. Dále v práci jsou tyto anglické pojmy vysvětleny.

5.2.1.1 1. vrstva – PRODUKT (anglicky „Product“)

Produktem je zde míněn již existující CRM systém (FX), který bude modifikován

takovým způsobem, aby pokryl funkční i nefunkční požadavky zúčastněných

stran kladených na implementaci nových procesů do FXu.

25

5.2.1.2 2. vrstva – NÁŠ SYSTÉM (anglicky „Our System“)

Druhá vrstva zahrnuje role, které systém přímo obsluhují. Může se jednat o

role, které s Produktem pracují, nebo o role, které mají na starosti běžnou

údržbu systému.

Do této vrstvy náleží aktéři mající následujíc role:

• Běžný obsluhovatel (anglicky „Normal operator“)

o Agenti (anglicky „Agents“), kteří Produkt používají při výkonu

své pracovní činnosti (zpracovávání úkolů).

o Supervisoři (anglicky „Supervisor“), kteří dohlížejí a

distribuují práci.

o Vedoucí týmů (anglicky „Team Leaders“), kteří dohlížejí,

distribuují práci, spravují agentské profily.

• Podpora provozu (anglicky „Operational support“)

o Business analytik (anglicky „Business Analyst“), který

dohlíží na správné používání produktu a je provozu k dispozici,

pokud je třeba. Business analytik má také na starosti některá

pokročilá Business nastavení systému.

• Správa a údržba systému (anglicky „Maintenance operator“)

o IT provozní podpora (anglicky „IT OPS Support“), který má

na starosti zajištění běžné údržby systému.

5.2.1.3 3. vrstva – OBKLOPUJÍCÍ SYSTÉM (anglicky

„Containing system“)

Třetí vrstva zahrnuje role, které z produktu nějakým způsobem profitují. Do této

vrstvy spadají zúčastnění mající role profitující z:

• Funkcionality (anglicky „Functional beneficiary“)

o Manažer Provozu (anglicky „Operations Manager“), který

potřebuje mít přehled o produkčních výsledcích, které získává ze

statistik získaných z produkčního systému.

26

o Manažer Reportingového a plánovacího oddělení (anglicky

„Planning and Reporting Manager“), který potřebuje mít

přehled o provozních výsledcích, v podobě kterou následně může

využít pro analýzu a optimalizaci výsledků (změna operativního /

produkčního modelu) a data pro fakturaci klientovi.

o Jiná pobočka (anglicky „Other site“), která potřebuje předat

část své agendy našemu provozu a výsledky průběžně

monitorovat.

Další role zastoupené v této vrstvě modelu jsou:

• Zadavatel (anglicky „Purchaser“)

o Projektový manažer (anglicky „Project Manager“), který je

zodpovědný za implementaci celého produktu do provozu (včetně

zajištění odpovídajících SW nástrojů).

Do druhé vrstvy spadají také IT / IS systémy, které poskytují svá rozhraní

produktu, případně kterým produkt poskytuje své rozhraní.

• Systémy poskytující / využívající rozhraní (anglicky „Interfacing

system“)

o Kana (SW používaný aerolinkou ABC i DEF pro zpracovávání

příchozích písemných kontaktů) distribuuje příchozí písemné

kontakty pomocí přednastavených klasifikačních pravidel (jazyk,

aktivita, země spotřebitele) do jednotlivých poboček.

o Emailový server Microsoft ExchangeTM, ze kterého FX stahuje

příchozí kontakty (přicházející jako e-maily) spadající do perimetru

společnosti XYZ.

o Amadeus (rezervační systém), který distribuuje úkoly zadané

přímo do Amadea mezi jednotlivé pobočky.

o Telco platforma, která umožňuje telefonickou komunikaci se

spotřebitelem.

27

5.2.1.4 4. vrstva – ŠIRŠÍ OKOLÍ (anglicky „Wider

environment“)

Do čtvrté vrstvy modelu spadají následující role:

• Sponzor projektu (anglicky „Sponsor“)

o Manažer provozu (anglicky „Operations Manager“), který je

zadavatelem projektu, produkční jednotka bude po uvedení do

provozu spadat pod něj.

• Vývojář (anglicky „Developer“)

o V tomto případě celý vývojový tým (konkrétně: Business

analytik, Manažer vývoje, SW Architekt, SW Vývojář, SW Tester,

Vývojář datového skladu), který má na starosti implementaci

procesů do Produktu.

• Negativní zúčastněná strana (anglicky „Negative Stakeholders“)

o Zaměstnanci (anglicky „Employees“), především agenti

pracující ve firmě delší dobu, kteří pod vlivem dřívějších zkušeností

nemusí Produkt (FX) přijmout dobře.

• Konzultant (anglicky „Consultant“)

o Tato role není v současné době pokryta. Předpokládá se, že

konzultantem bude v pozdější fázi projektu Business analytik

společnosti DEF.

Dále do širšího prostředí spadají zúčastněné strany, které z Produktu profitují:

• Finančně (anglicky „Financial beneficiaries“)

o Ředitel pobočky (anglicky „Site Manager“), který je

zodpovědný za hospodářský výsledek (navýšení zisku v případě

úspěšné implementace procesů).

o Klient (společnost ABC a DEF) (anglicky „Client“), kterému

zavedením procesů do Produktu (FX) odpadnou náklady na

pořízení a správu jiného SW.

28

• Z funkcionality (anglicky „Functional beneficiaries“)

o Spotřebitel (anglicky „Consumer“), který je patřičně

obsloužen.

o Klient (anglicky „Client“), který má k dispozici pro něj

potřebná data (na základě statistik, může Klient optimalizovat

některé procesy na své straně, např. pokud je mnoho dotazů

ohledně webové stránky, stránka je nejspíše nevhodně navržena

atd.).

• Politicky (anglicky „Political beneficiaries“)

o Vedoucí IS / ICT technologií (anglicky „Head of IS/ICT“),

který při úspěšné implementaci procesů získá uznání za práci

odvedenou jeho týmem. V případě neúspěšné implementace by

byl za neúspěch odpovědný.

o Ředitel pobočky (anglicky „Site Manager“), který při

úspěšné implementaci získá vyšší kredibilitu u Klienta i u mateřské

společnosti.

29

6 Vymezení oblastí pro implementaci

Na základě diskusí se zástupci zúčastněných stran, byly vymezeny následující

oblasti, které musí systém pokrývat, aby implementace nových procesů byla

úspěšná.

6.1 Agentské aktivity

Agenti jsou zodpovědní za zpracovávání písemných a telefonických požadavků

od spotřebitelů. Agenti jsou také zodpovědní za zpracování úkolů přidělených

našemu kontaktnímu centru systémem Amadeus. Samotné zpracování

požadavku spotřebitele se odehrává v externích systémech, proto nejsou ve

schématu zahrnuty.

Vzhledem ke komplexitě požadavků týkajících se agentských aktivit, bude tato

práce zaměřena především na ně.

Obrázek 8 - Vymezení agentských aktivit (Přehled případů užití)

30

6.2 Manažerské aktivity

Manažeři jsou zodpovědní za vedení agentů, správu agentských profilů,

monitorování agentů, plnění smluvních podmínek co se týče zpracovávání

požadavků spotřebitelů. Manažeři jsou také zodpovědní za distribuci

jednotlivých požadavků agentům a za prioritizaci požadavků tak, aby byl provoz

i provozní výsledky optimalizovány.

Po dotazování bylo zjištěno, že téměř všechny požadavky z oblasti

manažerských aktivit jsou zcela standardní a systémem již plně pokryty (správa

uživatelů, řízení provozu a agentských aktivit, správa šablon atd.).

Jediný speciální požadavek je mít možnost distribuovat práci agentům dvěma

způsoby (nikoliv současně, ale dle aktuální situace):

• 1 - Dle priority určené na základě parametrů příchozího kontaktu či úkolu

pro zpracování požadavku.

• 2 - FIFO (first in, first out) – nezávisle na parametrech příchozího

kontaktu, agentům musí být úkoly distribuovány v takovém pořadí,

v jakém přišly na ně navázané kontakty.

Systém umožňuje obě tyto možnosti, avšak přechod mezi těmito dvěma

způsoby není v současné době příliš uživatelsky přívětivý, proto se bude třeba

do budoucna zabývat i tímto požadavkem.

6.3 Aktivity systémového administrátora

Systémový administrátor je zodpovědný za správné nastavení systému co se

týče nastavení systému dle smlouvy s klientem (obsluhované jazyky atd.).

Většinu nastavení týkajících se správy systému je v současné době již možné

nastavit pomocí uživatelského rozhraní buďto přímo v aplikaci, v externích

konzolách určených pro správu systému nebo v konfiguračních souborech.

Vzhledem k tomu, že mohou vzniknout nové požadavky na správu systému poté

co bude zpracován technický design pro jednotlivé požadavky, musí toto téma

zůstat otevřené.

31

6.4 Spolupráce s externími systémy

Systém musí spolupracovat s externími systémy, tak aby byl schopen stáhnout

příchozí písemné kontakty od spotřebitele a aby byl schopen získat požadavky

na zpracování požadavků spotřebitelů z externího systému Amadeus.

To jakým způsobem budou do kontaktního centra XYZ distribuovány příchozí e-

maily je zachyceno na níže uvedeném schématu. Dále se jedná se společností

GHI o možnosti zpracovávat i příchozí faxy, ale toto v současné době nevypadá

pravděpodobně. O příchozích faxech (jejich získání a zpracování) nejsou

v současné době k dispozici žádné informace.

Obrázek 9 - Distribuce automatizovaných e-mailů do kontaktních center

32

Ohledně získávání požadavků z externího systému Amadeus nejsou v současné

době žádné informace. Je již potvrzeno se zadavatelem projektu, že informace

budou dodány nejdříve ve druhé polovině srpna 2010.

Vzhledem k tomu, že je známo jakým způsobem jsou zpracovávány požadavky

z rezervačních systémů pro jiné letecké společnosti, byl navrhnut následující

dočasný náhradní proces týkající se zpracování požadavků získaných ze systému

Amadeus (do doby, než bude možné přímé získávání požadavků z Amadea do

FXu).

Níže uvedené schéma zjednodušeně zachycuje možný proces zpracování

požadavků ve FXu, dokud nebude integrován systém Amadeus. Zpracování

požadavků v systému FX je nutné kvůli evidenci zpracovaných požadavků.

Ručně získat z Amadea seznam požadavků pro zpracování

Pro každý požadavek vytvořit e-mail a ten odeslat do FX

Klasifikovat jazyk a aktivitu požadavku

Vytvořit složku

Zpracovat požadavek ze systému Amadeus

Odeslat e-mail spotřebiteli. Zavolat spotřebiteli.

Obrázek 10 - Návrh dočasného řešení pro zpracovávání požadavků ze systému

Amadeus

33

7 Vymezení funkčních a nefunkčních požadavků

Ve své práci se zaměřím na specifikaci funkčních a nefunkčních požadavků.

Funkční požadavky (anglicky Functional requirements) popisují funkcionality,

které systém musí systém realizovat. Jsou základním kamenem specifikací

softwaru. Funkcionalita je zde popsána jako sada vstupů, chování a výstupů.

Vhodným způsobem jak zachytit požadavky na chování systému ve všech

případech, kde systém využívá funkční požadavky jsou případy užití.

Nefunkční požadavky (anglicky Non-functional requirements) v některých

zdrojích uváděné jako požadavky na kvalitu (anglicky Quality requirements) se

dají definovat jako kritéria pro posouzení kvality systému. Nefunkční požadavek

je např. jak má být jednoduché systém používat, jak rychle má systém

reagovat, jak má být systém spolehlivý, jaká má být dostupnost systému atd.

Velmi zjednodušeně se dá říct, že zatímco funkční požadavky definují CO má

systém dělat (aplikační architektura systému), nefunkční požadavky definují

JAKÝ má systém být (technická architektura systému). [9]

7.1 Funkční požadavky pro jednotlivé oblasti

Pro přiblížení procesu při specifikaci požadavků byly prvně definovány příběhy

uživatele. Příběh uživatele je požadavek na SW systém formulovaný do jedné

nebo více vět psaných v běžném jazyce či jazyce zákazníka.

Pro zdokumentování požadavků jsem zvolila CASE nástroj Enterprise Architect

8.0 společnosti SPARX (http://www.sparxsystems.com/). V této práci je uveden

pouze přehled požadavků a ukázka dokumentace jednoho balíčku funkčních

požadavků. Kompletní dokumentace je k nalezení na přiloženém CD.

Požadavky jsou dále rozšířeny o diagramy aktivit, jak by kontakty od

spotřebitelů měly být v systému FX zpracovávány.

34

7.1.1 Zavedení nového kontraktu do databáze

Kontrakt: GHI –Rezervace

letenek a podpora uživatelů webu

Klientský servis: ABC – Rezervace letenek a podpora uživatelů webu

Klientský servis: DEF – Rezervace letenek a podpora uživatelů webu

Jazyk:- angličtina- němčina- italština- francouzština

Jazyk:- angličtina- němčina- italština- francouzština

Perimetr:- Německo- Rakousko- Švýcarsko

Perimetr:- Německo- Rakousko- Švýcarsko

Aktivity:- ....- ....- ....

Aktivity:- ....- ....- ....

Obrázek 11 - Kontrakt: GHI - Rezervace letenek a podpora uživatelů webu

Poznámka: Seznam aktivit nebyl zatím dodán. S největší pravděpodobností se

budou lišit aktivity pro hovory, příchozí písemné kontakty i požadavky získané

ze systému Amadeus, např. Změna rezervace, Vytvoření nové rezervace atd.

Pro řešení písemných kontaktů je třeba rozlišovat 2 úrovně aktivit:

• Úroveň 1 – aktivity, které může zpracovat kterýkoliv agent.

• Úroveň 2 – aktivity, které může zpracovat pouze agent se speciálními

znalostmi.

35

Obrázek 12 - Aktivity pro klientské servisy ABC a DEF

Do systému mohou vstoupit požadavky z různých zdrojů (web –

automatizovaný e-mail, e-mail, fax, hovor, požadavek z Amadea). Vlastníkem

všech těchto požadavků je spotřebitel.

Možné výstupy ze systému (pouze směrem ke spotřebiteli) jsou pouze dva

(odchozí hovor a odchozí e-mail).

Obrázek 13 - Možné vstupy a výstupy ze systému FX (pro ABC a DEF)

Poznámka: Narozdíl od ostatních produktů zpracovávaných v systému FX,

nemůže být vlastníkem příchozího ani odchozího kontaktu třetí strana:

36

• Nejsou vyžadovány konzultace s třetí stranou.

• V případě, že kontaktní centrum společnosti XYZ nemůže zpracovat

požadavek spotřebitele, požadavek není přeposlán třetí straně.

V takovýchto případech bude spotřebitel informován, že má kontaktovat

odpovídající kontaktní centrum nebo bude požadavek zadán do systému

Amadeus v rámci kterého bude předán odpovídajícímu kontaktnímu

centru.

37

7.1.2 Obsloužení telefonického kontaktu od spotřebitele

7.1.2.1 Příběh uživatele: Obsloužit příchozí hovor od

spotřebitele

Agent přijme příchozí telefonát od spotřebitele. Agent zjistí od spotřebitele proč

volá a zpracuje jeho požadavek v externích systémech. Na konci telefonátu

zaznamená agent proč spotřebitel telefonoval. Agent vybere jeden nebo více

důvodů (důvod = aktivita; agent také může zaznamenat jeden důvod vícekrát).

(1) V případě, že se hovor přeruší, agent zavolá spotřebiteli zpět.

(2) V případě, že spotřebitel vyžaduje zaslání informací e-mailem, agent

zaznamená jméno, příjmení a e-mailovou adresu (pokud již nemá tyto údaje k

dispozici) a po ukončení telefonátu e-mail spotřebiteli odešle.

(3) V případě, že agent nemá dostatečné znalosti pro vyřízení požadavku, agent

zadá požadavek do Amadea a sdělí spotřebiteli, že bude kontaktován později.

req Obsloužit príchozí hovor

Obsloužit príchozí hovor od spotrebitele

Klasifikovat príchozí hovor

(from Klasifikovat príchozí hovor)

Zavolat zpet spotrebiteli

(from Zavolat zpet spotrebiteli)

Odeslat e-mail spotrebiteli (na základe príchozího hovoru)

(from Odeslat e-mail spotrebiteli)

Priradit hovor ke složce

(from Priradit hovor ke složce)

Obrázek 14 - Obsloužit příchozí hovor (souhrnné schéma)

38

req Klasifikovat príchozí hovor

Klasifikovat príchozí hovor

Automaticky klasifikovat klientský servis príchozího hovoru

Zaznamenat duvod hovoru

Zaznamenat telefonní císlo

Obrázek 15 - Obsloužit příchozí hovor: Klasifikovat příchozí hovor

req Priradit hovor ke složce

Priradit hovor ke složce

Priradit hovor k existující složce

Priradit hovor k nové složce

Priradit spotrebitele ke složce

Obrázek 16 - Obsloužit příchozí hovor: Přiřadit hovor ke složce

39

req Zavolat zpet spotrebiteli

Uskutecnit odchozí hovor

Nabídnout telefonní císlo

Upravit telefonní císlo

Zaznamenat stav odchozího hovoru

Provázat príchozí a odchozí hovoru

Uložit typ odchozího hovoru

Uložit stav odchozího hovoru

Uložit délku hovoru

Zaznamenat odchozí hovor

Zavolat spotrebiteli pozdeji

Zavolat zpet spotrebiteli

Obrázek 17 - Obsloužit příchozí hovor: Zavolat zpět spotřebiteli

40

req Odeslat e-mail spotrebiteli

Odeslat e-mail spotrebiteli (na základe príchozího hovoru)

Zaznamenat kontaktní údaje spotrebitele

Vybrat odpovídající e-mailovou adresu, ze které bude e-mail spotrebiteli odeslán.

Vybrat príjemce e-mailu.

Vybrat odpovídající šablonu.

Automaticky doplnit text.

Schválit odpoved spotrebiteli pred odesláním e-mailu

Odeslat e-mail pres SMTP Gateway spolecnosti DEF.

Obrázek 18 - Obsloužit příchozí hovor: Odeslat e-mail spotřebiteli

41

Přijmout příchozí hovor

Zpracovat požadavek zákazníka

Zaznamenat kontaktní údaje spotřebitele

[Kontaktní údaje nejsou k dispozici]

Zadat požadavek na odeslání e-mailu spotřebiteli

[Kontaktní údaje jsou k dispozici]

Ukončit hovor

Zaznamenat důvod hovoru

[Spotřebitel vyžaduje odeslání e-mailu]

[Spotřebitel nevyžaduje odeslání e-mailu]

[Hovor není přerušen]

Zavolat spotřebiteli zpět

[Hovor je přerušen]

Obrázek 19 - Diagram aktivit: Obsloužit příchozí hovor

7.1.3 Zpracování písemného kontaktu od spotřebitele

7.1.3.1 Příběh uživatele: Zpracovat písemný kontakt od

spotřebitele

Agent přijme úkol na zpracování příchozího e-mailu. Agent před samostatným

zpracováním kontaktu musí určit jazyk (1) příchozího kontaktu a jeho aktivitu

(2, 3). Zpracovávání příchozího písemného kontaktu je ve většině případů

ukončeno odesláním písemné odpovědi (e-mailem) spotřebiteli.

(1a) V případě, že agent nehovoří daným jazykem, poté co jazyk určí vrátí

kontakt do fronty pro další zpracování.

42

(1b) V případě, že agent hovoří daným jazykem, poté co agent určí jazyk

kontaktu určí i aktivitu(y) obsaženou v příchozím kontaktu.

(2a) V případě, že agent nemá dostatečné znalosti pro samotné zpracování

požadavku(ů) obsaženého v příchozím kontaktu, agent vrátí kontakt do fronty

pro další zpracování.

(2b) V případě, že agent má dostatečné znalosti pro samotné zpracování

požadavku(ů) obsaženého v příchozím kontaktu, agent kontakt zpracuje a

uzavře případ odesláním e-mailu spotřebiteli. Ve speciálních případech může být

případ uzavřen odchozím hovorem. Případ může být uzavřen aniž by agent

spotřebitele kontaktoval.

(3) Vzhledem k tomu, že většina příchozích kontaktů jsou automatizované e-

maily pocházející z webových formulářů obsahující data potřebná pro klasifikaci,

může být ve většině případů klasifikace jazyka a aktivity provedena

automaticky.

req Zpracovat príchozí písemný kontakt

Klasifikovat príchozí písemný kontakt

(from Klasifikovat príchozí písemný kontakt)

Priradit príchozí kontakt ke složce

(from Priradit kontakt ke složce)

Zpracovat príchozí písemný kontakt.

Uzavrení požadavku od spotrebitele

(from Uzavrení požadavku od spotrebitele)

Obrázek 20 - Zpracovat příchozí písemný kontakt (souhrnné schéma)

43

Obrázek 21 - Diagram aktivit: Zpracovat písemný kontakt od spotřebitele (1)

44

Vytvořit task pro klasifikaci jazyka

Vytvořit task pro klasifikaci aktivity

Vytvořit task pro zpracování příchozího kontaktu

Klasifikovat jazyk

Klasifikovat aktivitu

Zpracovat příchozí kontakt

[Agent má jazykové znalosti potřebné pro klasifikaci aktivity]

[Agent nemá jazykové znalosti potřebné pro klasifikaci aktivity]

[Agent má znalosti potřebné pro zpracování příchozího písemného kontaktu]

Ukončit task pro klasifikaci aktivity

Ukončit task pro klasifikaci jazyka

[Agent nemá znalosti potřebné pro zpracování příchozího písemného kontaktu]

Ukončit task pro zpracování příchozího písemného kontaktu

Obrázek 22 - Diagram aktivit: Zpracovat písemný kontakt od spotřebitele (2)

45

req Klasifikovat príchozí písemný kontakt

Klasifikovat jazyk príchozího kontaktu

Klasifikovat príchozí písemný kontakt

Automaticky klasifikovat klientský servis príchozího kontaktu

Automaticky klasifikovat vlastníka príchozího kontaktu

Klasifikovat aktivitu príchozího kontaktu

Vytvorit odpovídající typ tasku pro zpracování príchozího kontaktu

Obrázek 23 - Zpracovat příchozí písemný kontakt: Klasifikovat písemný kontakt

46

Obrázek 24 - Diagram aktivit: Klasifikovat jazyk příchozího kontaktu

47

Přijmout task pro klasifikaci aktivity

Určit aktivitu obsaženou v příchozím kontaktu

[Jazyk je správně klasifikován]

[Jazyk je nesprávně klasifikován]

Klasifikovat jazyk

[Agent je schopen klasifikovat aktivitu]

[Kontakt je relevantní]

Vrátit task do řady

[Agent není schopen klasifikovat aktivitu]

Vytvořit task pro zpracování příchozího písemného kontaktu

Ukončit task pro klasifikaci aktivity

[Kontakt není relevantní]

Obrázek 25 - Diagram aktivit: Klasifikovat aktivitu příchozího kontaktu

48

act Vytvorit odpovídající task na základe známých p arametru (jazyk, aktivita)

Start

Automaticky klasifikovatpríchozí písemný kontakt

Vytvorit task: Klasifikovatjazyk

Vytvorit task: Klasifikovataktivitu

Vytvorit task: Zpracovatpožadavek

Konec

[Aktivita klasifikována nesprávne]

[Jazyk - klasifikován; Aktivita - klasifikována]

[Jazyk - klasifikován; Aktivita - neklasifikována]

[Jazyk - klasifikován; Aktivita - klasifikována]

[Jazyk klasifikován; Aktivita - neklasifikována]

[Jazyk - neklasifikován; Aktivita - neklasifikována]

Obrázek 26 - Zpracovat příchozí písemný kontakt: Vytvořit odpovídající typ tasku

(1)

49

act Vytvorit odpovídající task dle typu klasifikova né aktivity

Start

Vytvorit task: Zpracovatpožadavek (úroven 1)

Vytvorit task: Zpracovatpožadavek (úroven 2)

Konec

Klasifikovat aktivitu

[Alespon jedna klasifikovaná aktivita: úroven 2][Všechny klasifikované aktivity: úroven 1]

Obrázek 27 - Zpracovat příchozí písemný kontakt: Vytvořit odpovídající typ tasku

(2)

Poznámka: Úroveň aktivity je nový parametr aktivity. Tento parametr vyjadřuje

obtížnost dané aktivity. Všeobecně se dá říct, že aktivitu úrovně 1 může řešit

kterýkoliv agent narozdíl od aktivity úrovně 2, kterou může řešit jen agent se

speciálními znalostmi.

50

req Priradit príchozí kontakt ke složce

Priradit príchozí kontakt ke složce

Priradit kontakt ke složce již existující

Priradit kontakt ke složce nové

Priradit spotrebitele ke složce

Obrázek 28 - Zpracovat příchozí písemný kontakt: Přiřadit kontakt ke složce

7.1.3.2 Zpracování požadavků (aktivit) obsažených

v příchozím kontaktu

• Samotné zpracování aktivit se odehrává v externích systémech, proto

tato fáze zpracovávání příchozích kontaktů nebude dále rozvedena.

51

req Uzavrení požadavku od spotrebitele

Uzavrení požadavku od spotrebitele

Odeslat e-mail spotrebiteli

Vybrat zpusob vytvorení odpovedi

Použít šablonu pro vytvorení odpovedi

Vložit automatický text do e-mailu

Schválit odpoved spotrebiteli pred odesláním e-mailu

Odeslat e-mail pres SMTP Gateway spolecnosti DEF

Uskutecnit odchozí hovor spotrebiteli

Uzavrít prípad bez odchozího kontaktu

Zvolit odpovídající odchozí e-mailovou adresu

Obrázek 29 - Zpracovat písemný kontakt: Uzavřít požadavek od spotřebitele

52

Obrázek 30 - Diagram aktivit: Zpracovat požadavek od spotřebitele

U této sady požadavků neuvádím pouze přehled jednotlivých požadavků, ale

také ukázku dokumentace vygenerované CASE nástrojem Enterprise Architect

8.0.

53

Obrázek 31 - Ukázka dokumentace z Enterprise Architect (1)

54

Obrázek 32 - Ukázka dokumentace z Enterprise Architect (2)

55

Obrázek 33 - Ukázka dokumentace z Enterprise Architect (3)

56

7.2 Nefunkční požadavky

7.2.1 Časový plán

Obrázek 34 - Časový plán implementace

Vzhledem k nedodržení termínů ze strany společnosti GHI, bude časový plán ve

spolupráci se společností GHI přepracován.

Poznámka: Kromě požadovaných termínů dodání, nebyl identifikován žádný

nefunkční požadavek, který by už systémem nebyl pokryt, proto nebudou

nefunkční požadavky dále rozebrány.

57

8 Závěr

V rámci vypracovávání mé bakalářské práce se mi podařilo analyzovat business

procesy společností ABC a DEF. Na základě zkušeností s dřívější implementací

podobných procesů bylo možné vypracovat analýzu požadavků i přesto, že

společnost GHI nedodala potřebné informace ve smluveném termínu. Během

analýzy bylo zjištěno, že některé požadavky, už jsou systémem FX

podporovány.

Vzhledem k nedodání podkladů ze strany společnosti GHI potřebných k analýze

požadavků, je pravděpodobné, že se některé z požadavků mohou v budoucnu

změnit.

Po konzultaci s business analytikem společnosti DEF a systémovým architektem

společnosti XYZ je již jisté, že případné budoucí změny nebudou velkým

zásahem do již existující analýzy.

Vzhledem k blížícímu se termínu dodání produktu, musí být vývoj zahájen v co

nejbližším možném termínu. Pokud do této doby společnost GHI nedodá

potřebné podklady, bude tato verze analýzy požadavků sloužit jako hlavní

podklad pro vývoj. Případné změny identifikované po začátku vývoje se budou

zpracovávat jako standardní požadavky na změnu.

58

9 Seznam použitých zkratek a vysv ětlení n ěkterých

pojm ů

ABC – letecká společnost, jejíž koncové zákazníky (spotřebitele) bude

společnost XYZ obsluhovat.

Agent – zaměstnanec společnosti XYZ, který využívá systém FX pro

zpracovávání příchozích kontaktů od spotřebitelů.

Amadeus – rezervační systém, využívaný společnostmi ABC, DEF, GHI pro

rezervaci letenek a s tím spojené aktivity.

DEF – letecká společnost, jejíž koncové zákazníky (spotřebitele) bude

společnost XYZ obsluhovat.

FX – produkční systém patřící společnosti XYZ do kterého budou procesy

implementovány.

GHI – letecká společnost, se kterou je uzavřen kontrakt pro zpracovávání

požadavků koncových zákazníků společností ABC a DEF.

JKL – mateřská společnost společnosti XYZ.

OPQ – kontaktní centrum společnosti DEF.

Spotřebitel – zákazník využívající služby letecké společnosti. Slovo spotřebitel

bylo použito v souladu s terminologií společnosti GHI.

XYZ – společnost, ve které budou požadavky koncových zákazníků společností

ABC a DEF zpracovávány.

59

10 Použitá literatura

[1] JONÁK, Zdeněk. Databáze Národní knihovny ČR [online]. 2005 [cit. 2010-

06-05]. KTD - Česká terminologická databáze knihovnictví a informační vědy

(TDKIV) . Dostupné z WWW:

<http://sigma.nkp.cz/F/E4SLMUH5V76J2IXYE1RNPPQ7N6E69RNIQMNEE12LA6

VCMFSHKC-04556?func=full-set-

set&set_number=010868&set_entry=000060&format=999>.

[2] WebSystem | CMS, WCM, redakční systém, publikační systém [online].

neuvedeno [cit. 2010-06-28]. Slovník pojmů - WebSystem | CMS, WCM,

redakční systém, publikační systém. Dostupné z WWW:

<http://www.websystem.cz/page/170.slovnik-pojmu/>.

[3] EW - logistické poradenství, supply chain, logistika, strategie, optimalizace

[online]. neuvedeno [cit. 2010-06-28]. EW > Supply chain management,

Integrace, Logistika, Distribuce. Dostupné z WWW:

<http://www.ewizard.cz/supply-chain-management.html>.

[4] Microsoft Software Management: Covering today´s topics on Microsoft

Software Management [online]. 08-09-2008 [cit. 2010-06-28]. What is

enterprise content management (ECM)? - Definition from WhatIs.com.

Dostupné z WWW:

<http://searchwinit.techtarget.com/sDefinition/0,,sid1_gci1328980,00.html>.

[5] BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. První.

Praha : Vysoká škola ekonomická v Praze, Nakladatelství Oeconomica, 2009.

9.4 Metodika Scrum, s. 206. ISBN 978-80-245-1540-3.

[6] DĚDEK, Vladimír. Blog o ASP.NET, C#, .NET a o nových technologiích

[online]. 13. 12. 2009 [cit. 2010-06-05]. Metodika Scrum. Dostupné z WWW:

<http://starec.blog.zive.cz/2009/12/metodika-scrum-2/>.

[7] DE BAAR, Bas. Software Project Management for A Global, Mobile, Virtual

And Multi-Cultural World [online]. 2006 [cit. 2010-06-28]. Using Stakeholder

60

Analysis in Software Project Management. Dostupné z WWW:

<http://www.softwareprojects.org/stakeholders.pdf>.

[8] ALEXANDER, Ian; ROBERTSON, Suzanne. Easynet Connect - Quality

Business Internet Access [online]. neuvedeno [cit. 2010-06-28]. Stakeholders.

Dostupné z WWW:

<http://easyweb.easynet.co.uk/~iany/consultancy/stakeholders_without_tears/

stakeholders_without_tears.htm>.

[9] 3SL Newsletters | Cradle from 3SL | www.threesl.com [online]. 2010, 28-

06-2010 [cit. 2010-06-28]. Non Functional Requirements . Dostupné z WWW:

<http://www.threesl.com/pages/webletter-

February06/Non_Functional_Requirements.php>.

10.1 Ostatní čerpané zdroje

ARLOW, Jim; NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací :

Objektově orientovaná analýza a návrh prakticky. První. Brno : Computer Press,

a.s., 2008. 565 s. ISBN 978-80-251-1503-9.

COCKBURN, Alistair. Use Cases : Jak efektivně modelovat aplikace. První. Brno :

CP Books, a.s., 2005. 262 s. ISBN 80-251-0721-3.

KANISOVÁ, Hana; MÜLLER, Miroslav. UML srozumitelně : 2. aktualizované

vydání. Brno : Computer Press, a.s., 2006. 176 s. ISBN 80-251-1083-4.

PALETA, Petr. Co programátory ve škole neučí : aneb Softwarové inženýrství v

praxi. První. Brno : Computer Press, 2003. 337 s. ISBN 80-251-0073-1.

SCHMULLER, Joseph. Myslíme v jazyku UML. První. Praha : Grada Publishing,

spol.s r.o., 2001. 360 s. ISBN 80-247-0029-8.

SVOZILOVÁ, Alena. Projektový management. První. Praha : Grada Publishing,

a.s., 2006. 356 s. ISBN 80-247-1501-5.