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.