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
Č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: ..............................................
2
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.
3
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.
4
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.
5
Obsah 1
2
Ú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
Informační systémy ....................................................................................... 10 2.1
Aplikační Software ................................................................................. 10
2.2
CRM systém.......................................................................................... 11
2.2.1 2.3 2.3.1 2.4 3
Firemní CRM systém...........................................................................11 Reportingové nástroje............................................................................ 12 Firemní reportingové nástroje .............................................................12 Ostatní IS využívané ve společnosti XYZ .................................................. 13
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 3.2.1
Prostředí vývojového týmu ..................................................................... 16 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 6
Přehled zúčastněných stran ................................................................24
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 6
6.4 7
Spolupráce s externími systémy .............................................................. 31
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 10.1
Použitá literatura....................................................................................... 59 Ostatní čerpané zdroje........................................................................... 60
7
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.
8
•
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.
9
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. 10
•
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]
•
2.2
... a mnoho dalších...
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.
11
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).
12
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.).
13
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.
14
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í
15
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
SW Development Manager
Business Analyst
SW Tester
Senior SW Tester
Senior SW Engineer I (SW Architect)
Senior SW Engineer II
SW Tester
Senior SW Engineer III
SW Developer I
SW Developer II
SW Developer III
Database Developer I
SW Engineer
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ů 16
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.
17
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). 18
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
19
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
20
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.
21
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
22
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]
23
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.
24
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. (anglicky „Team Leaders“), kteří dohlížejí,
o Vedoucí týmů
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. 25
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.
26
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. 27
•
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.
28
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í)
29
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é. 30
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í emaily 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
31
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
Zavolat spotřebiteli.
Odeslat e-mail spotřebiteli.
Obrázek 10 - Návrh dočasného řešení pro zpracovávání požadavků ze systému Amadeus
32
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.
33
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
Jazyk: - angličtina - němčina - italština - francouzština
Perimetr: - Německo - Rakousko - Švýcarsko
Klientský servis: DEF – Rezervace letenek a podpora uživatelů webu
Jazyk: - angličtina - němčina - italština - francouzština
Aktivity: - .... - .... - ....
Perimetr: - Německo - Rakousko - Švýcarsko
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.
34
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: 35
•
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.
36
7.1.2 7.1.2.1
Obsloužení telefonického kontaktu od spotřebitele 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 (fromKlasifikovat príchozí hovor)
Priradit hovor ke složce (fromPriradit hovor ke složce)
Zavolat zpet spotrebiteli (fromZavolat zpet spotrebiteli) Odeslat e-mail spotrebiteli (na základe príchozího hovoru) (fromOdeslat e-mail spotrebiteli)
Obrázek 14 - Obsloužit příchozí hovor (souhrnné schéma)
37
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
38
req Zavolat zpet spotrebiteli Zavolat zpet spotrebiteli
Nabídnout telefonní císlo
Upravit telefonní císlo
Uskutecnit odchozí hovor
Zaznamenat stav odchozího hovoru
Zaznamenat odchozí hovor
Provázat príchozí a odchozí hovoru
Uložit typ odchozího hovoru
Uložit stav odchozího hovoru
Uložit délku hovoru
Zavolat spotrebiteli pozdeji
Obrázek 17 - Obsloužit příchozí hovor: Zavolat zpět spotřebiteli
39
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
40
Přijmout příchozí hovor
[Hovor je přerušen]
[Hovor není přerušen] Zavolat spotřebiteli zpět Zpracovat požadavek zákazníka
[Spotřebitel vyžaduje odeslání e-mailu]
[Kontaktní údaje nejsou k dispozici]
[Spotřebitel nevyžaduje odeslání e-mailu]
Zaznamenat kontaktní údaje spotřebitele [Kontaktní údaje jsou k dispozici]
Zadat požadavek na odeslání e-mailu spotřebiteli
Ukončit hovor
Zaznamenat důvod hovoru
Obrázek 19 - Diagram aktivit: Obsloužit příchozí hovor
7.1.3 7.1.3.1
Zpracování písemného kontaktu od spotřebitele 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í. 41
(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é emaily 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 Zpracovat príchozí písemný kontakt.
Klasifikovat príchozí písemný kontakt (fromKlasifikovat príchozí písemný kontakt)
Priradit príchozí kontakt ke složce (fromPriradit kontakt ke složce)
Uzavrení požadavku od spotrebitele (fromUzavrení požadavku od spotrebitele)
Obrázek 20 - Zpracovat příchozí písemný kontakt (souhrnné schéma)
42
Obrázek 21 - Diagram aktivit: Zpracovat písemný kontakt od spotřebitele (1)
43
Vytvořit task pro klasifikaci jazyka
Klasifikovat jazyk
Vytvořit task pro klasifikaci aktivity
Ukončit task pro klasifikaci jazyka
[Agent má jazykové znalosti potřebné pro klasifikaci aktivity]
Klasifikovat aktivitu
Vytvořit task pro zpracování příchozího kontaktu
Ukončit task 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]
Zpracovat příchozí kontakt [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)
44
req Klasifikovat príchozí písemný kontakt Klasifikovat príchozí písemný kontakt
Automaticky klasifikovat klientský servis príchozího kontaktu
Automaticky klasifikovat vlastníka príchozího kontaktu
Klasifikovat jazyk 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
45
Obrázek 24 - Diagram aktivit: Klasifikovat jazyk příchozího kontaktu
46
Přijmout task pro klasifikaci aktivity
[Jazyk je nesprávně klasifikován]
[Jazyk je správně klasifikován] Klasifikovat jazyk
[Agent není schopen klasifikovat aktivitu] [Kontakt je relevantní]
[Kontakt není relevantní] Vrátit task do řady [Agent je schopen klasifikovat aktivitu]
Určit aktivitu obsaženou v příchozím kontaktu
Vytvořit task pro zpracování příchozího písemného kontaktu
Ukončit task pro klasifikaci aktivity
Obrázek 25 - Diagram aktivit: Klasifikovat aktivitu příchozího kontaktu
47
act Vytvorit odpovídající task na základe známých parametru (jazyk, aktivita)
Start
Automaticky klasifikovat príchozí písemný kontakt
[Jazyk - neklasifikován; Aktivita - neklasifikována]
Vytvorit task: Klasifikovat jazyk
[Jazyk klasifikován; Aktivita - neklasifikována]
[Jazyk - klasifikován; Aktivita - klasifikována]
[Jazyk - klasifikován; Aktivita - neklasifikována] Vytvorit task: Klasifikovat aktivitu
[Jazyk - klasifikován; Aktivita - klasifikována]
[Aktivita klasifikována nesprávne]
Vytvorit task: Zpracovat požadavek
Konec
Obrázek 26 - Zpracovat příchozí písemný kontakt: Vytvořit odpovídající typ tasku (1)
48
act Vytvorit odpovídající task dle typu klasifikované aktivity
Start
Klasifikovat aktivitu
[Všechny klasifikované aktivity: úroven 1]
[Alespon jedna klasifikovaná aktivita: úroven 2]
Vytvorit task: Zpracovat požadavek (úroven 1)
Vytvorit task: Zpracovat požadavek (úroven 2)
Konec
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.
49
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.
50
req Uzavrení požadavku od spotrebitele Uzavrení požadavku od spotrebitele Odeslat e-mail spotrebiteli
Vybrat zpusob vytvorení odpovedi
Zvolit odpovídající odchozí e-mailovou adresu
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
Obrázek 29 - Zpracovat písemný kontakt: Uzavřít požadavek od spotřebitele
51
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.
52
Obrázek 31 - Ukázka dokumentace z Enterprise Architect (1)
53
Obrázek 32 - Ukázka dokumentace z Enterprise Architect (2)
54
Obrázek 33 - Ukázka dokumentace z Enterprise Architect (3)
55
7.2 7.2.1
Nefunkční požadavky Č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.
56
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.
57
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.
58
10 Použitá literatura [1] JONÁK, Zdeněk. Databáze Národní knihovny ČR [online]. 2005 [cit. 201006-05]. KTD - Česká terminologická databáze knihovnictví a informační vědy (TDKIV) . Dostupné z WWW:
. [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:
. [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:
. [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:
. [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: . [7] DE BAAR, Bas. Software Project Management for A Global, Mobile, Virtual And Multi-Cultural World [online]. 2006 [cit. 2010-06-28]. Using Stakeholder
59
Analysis
in
Software
Project
Management.
Dostupné
z
WWW:
. [8] ALEXANDER, Ian; ROBERTSON, Suzanne. Easynet Connect - Quality Business Internet Access [online]. neuvedeno [cit. 2010-06-28]. Stakeholders. Dostupné
z
WWW:
. [9] 3SL Newsletters | Cradle from 3SL | www.threesl.com [online]. 2010, 2806-2010 [cit. 2010-06-28]. Non Functional Requirements . Dostupné z WWW: .
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.
60
