Konkurenční výhoda skrze analýzu ICT incidentů: analýza nestrukturovaných dat

Konkurenční výhoda skrze analýzu ICT incidentů: analýza nestrukturovaných dat Ivan Jelínek Fakulta informatiky a statistiky, Vysoká škola ekonomická v Praze nám. W. Churchilla 4, 130 67 Praha 3 Email: [email protected] Abstrakt: Při řešení ICT incidentů se v podnikové praxi vytváří nezanedbatelný objem nestrukturovaných dat. S daty o postupu řešení nebo popisu příčin lze nakládat jako s typickými nestrukturovanými textovými daty. Tato práce se zaměří na možnosti, jak lze dosáhnout konkurenční výhody nasazením nástroje, který bude analyzovat logy ICT incidentů. ICT incidenty jsou kategorizovány podle jejich obsahu a způsobu řešení do generalizovaných šablon. Tyto šablony představující hlavní typy incidentů jsou pak pomocí řízených konzultací s experty rozděleny do jednotlivých segmentů. Jejich četnosti jsou prezentovány ve formě reportu. Report by měl obsahovat netriviální informace podložené daty, které by nebylo možné dovodit jinak, než touto analýzou. Klíčová slova: nestrukturovaná data, incident management, analýza, ICT incidenty Abstract: There is significant amount of unstructured data in ICT incident solutions in enterprise practice. One can deal with the data containing solution descriptions or fault descriptions like with any other unstructured textual data. This work is focused on how to get the competitive advantage in deployment of sucha a tool that will analyse these ICT incidents. ICT incidents will be categorized by their content and solution into a general templates. These templates declares main types of incidents. In cooperation with experts these types are segmentated. Frequences of such segments are presented in form of a report. Report should consist of untrivial information based on the data that are not deductible other way. Keywords: unstructured data, incident management, analysis, ICT incidents

1. Úvod Dosáhnout konkurenční výhody se snaží většina ekonomických subjektů na volném trhu. Výhody je možné dosáhnout různými způsoby – zefektivněním výroby, kvalitněji poskytovanou službou, vhodným business modelem apod. Další možností jak dosáhnout konkurenční výhody je udržovat vztah mezi businessem a ICT v organizaci v efektivní rovnováze (B/IT alignment). Dle (Voříšek et al. 2008) je klíčové pro získání konkurenční výhody vhodné propojení ICT s podnikovými procesy a podnikovou kulturou. Klasickým projevem problému ve fungování organizace jsou incidenty, potažmo problémy, které se vyskytují v běžném provozu. Ačkoli jsou incidenty chápány obvykle jako čistě ICT záležitost, značí situace, které nemusí být zaviněny jen ICT útvarem. Cílem této práce je proto na případové studii ukázat, že analýzou těchto incidentů je SYSTÉMOVÁ INTEGRACE 3/2015

91

Ivan Jelínek

možné sestavovat doporučení, která se mohou odrazit ve zlepšení B/IT alignmentu a v konečném důsledku zlepšit kvalitu poskytované služby a získat konkurenční výhodu.

1.1 B/IT Alignment a vliv na konkurenční výhodu Podle metodiky ITIL (Cannon et al. 2010) je po zadání ICT incidentu možné pokračovat v business procesu pouze ve chvíli, kdy existuje možnost jak chybu obejít (workaround). Existuje-li takový workaround, zákazník nemusí zhoršenou kvalitu služby vnímat. V opačném případě je jeho požadavek obvykle zastaven a musí počkat do vyřešení na straně ICT. Incidenty dle ITILu přechází mezi různými odděleními, dokud není identifikována a zjednána náprava. V průběhu řešení se zaznamenávají informace textového charakteru, které popisují zda a jak bylo případně zasaženo do dat, formulují se dotazy na jiné systémy nebo se při uzavření doporučuje uživateli konkrétní postup. Incidenty, které jsou způsoby např. SW chybou nebo datovou nekonzistencí není obvykle možné vyřešit jiným způsobem než nasazením opravy nebo ručním zásahem do DB. Naopak incidenty, které vznikly nedodržením business procesu, chybným zadáním ze strany uživatele nebo nerespektováním business rules, je možné napravit a dojde-li k jejich eliminaci, uvolní se zdroje ICT útvarů a dojde ke zlepšení kvality poskytovaných služeb.

2. Současné přístupy k analýze datových korpusů Literatura nejčastěji využívá pro analytickou činnost datové korpusy vytvořené ze sociálních sítí1 či lékařské záznamy (Champion et al. 2014). Narazit lze i na jiné datové korpusy, především obsahující přirozený nebo spontánní lidský projev (Crockett a Lee 2012). Literatura přistupuje k analýze obdobným způsobem, a to za použití konkrétních kroků při zpracování textu. Jde o automatickou indexaci textu a zpracování přirozeného jazyka (Strossa 2011), sentiment analýzu (Kamath et al. 2013; Turney 2002), named entity recognition (Waila et al. 2013), kategorizaci textu (Minier et al. 2007). Při automatické indexaci textu se dle (Strossa 2011) používají metody stop-slovníků, které vyřazují slova, která nenesou význam - obvykle spojky, předložky apod. Při indexaci je ale nutné slova o stejném základu indexovat jako jeden termín. K tomu se obvykle používá derivátor či lemmatizátor slov. Základním rozdílem mezi oběma přístupy je jejich výstup. Derivátory používají stemmovací algoritmy, které pomocí heuristických pravidel (či pravidel spojených se syntaxí daného jazyka) vrací něco co bychom mohli označit jako kořen slova. Lemmatizátory naopak používají algoritmy, které vrací základní tvar slova (např. první pád jednotného čísla u podstatných jmen). Úloha sentiment analýzy vychází z potřeby identifikovat emoční rozpoložení pisatele nebo emoční náboj příspěvku. Je často využívána při analýze sociálních sítí, kde lze obvykle rozhodnout, jestli je příspěvek pozitivní, neutrální nebo negativní. To je možné Literatura (Ediger et al. 2010; Keretna et al. 2013; Hassan et al. 2013) využívá sociální síť Twitter pro svoji dostupnost a obecný rozsah dat. Twitterová data jsou dostupná skrze REST API (Twitter 2015), což usnadňuje získávání dat. 1

92

SYSTÉMOVÁ INTEGRACE 3/2015

Konkurenční výhoda skrze analýzu ICT incidentů: analýza nestrukturovaných dat

na úrovni celé věty (aspect sentiment), nebo s ohledem na konkrétní podnět ve větě (aspect-related sentiment) (Brychcın et al. 2014) Literatura často uvádí i případy, kdy k obohacování nestrukturovaného textu dochází formou tzv. Named entity recognition úlohy. Při tomto zpracování dat dochází k „automatickému anotování entit z textových dokumentů. Na to může být pohlíženo jako na klasifikační úlohu nebo velmi známý problém tagování.“ (Waila et al. 2013). V tomto případě text obsahuje slova či fráze, které mají další význam – jsou entitou, která je rozpoznávána. Tento přístup je vhodný ve chvíli, kdy je nutné identifikovat známé osoby, místa, města, organizace apod. Poslední významnou úlohou, o které se literatura zmiňuje, je kategorizační úloha. Dle (Minier et al. 2007) je cílem kategorizační (klasifikační) úlohy snaha najít kandidáta, který nejlépe aproximuje objekt na základě trénovacích dat. Literatura popisuje různé způsoby jak ke kategorizační úloze přistoupit. Nejčastěji se jedná o support vector machine (SVM), naive Bayes (NB) a maximální entropií (ME) (Hrala a Král 2013).

3. Metoda analýzy ICT incidentů Tato část se věnuje návrhu metody analýzy ICT incidentů. Jedná se o specifický datový korpus, pro který je nutné připravit vlastní metodu analýzy. Cílem analýzy je vytvořit seznam typizovaných incidentů. Jelikož v běžném provozu existuje část incidentů, které se pravidelně opakují, je možné vytvořit seznam často opakujících se typů incidentů. Následně je možné stanovit četnosti těchto typů a z nich doporučovat opatření ke zlepšení B/IT souladu.

3.1 Popis dat Použitá data byla sbírána v průběhu roku 2013 a 2014 z interního systému velkého českého telekomunikačního operátora. Jedná se o incidenty, které byly řešeny jedním vybraným oddělením CRM. Zaměstnanci vybraného oddělení byly pro účely studie přizváni jako experti pro doplňující informace. Každý incident představoval datovou větu obsahující položky, jejichž výčet je uveden v Tab. 1. Incident obsahoval tedy jazyk dvou různých skupin – uživatelů a ICT odborníků. To se projevuje tím, že obvykle v Informacích od odesilatele je uvedeno chybové hlášení, slovní popis, zkratky a slang, který se mezi uživateli používá. Proti tomu pole Informace obsahuje poznámky vyměňované mezi zaměstnanci ICT útvaru. Toto pole tedy obsahuje všechna odborná vyjádření, žádosti o zásahy do IS případně další informace. Obsahuje také specifické zkratky, slang nebo fráze. Pole Řešení obsahuje konečné vyjádření od zaměstnanců ICT útvaru, které obvykle doporučuje následné kroky, nebo informuje o opravě a ukončení požadavku.


93

Ivan Jelínek

Tab. 1- Položky a jejich význam, zdroj: autor Název pole Čas zadání ID

Typ Datum Integer

Popis

Text

Informace od odesílatele Informace Řešení

Popis Datum a čas zadání incidentu uživatelem. Číselný primární klíč záznamu. Textový nadpis shrnující problém se kterým se uživatel (mimo IT) potýká.

Text

Podrobné textové informace od uživatele (mimo IT).

Text

Textový záznam řešení incidentu. (Především IT). Konečná informace pro uživatele obsahující informace co dále dělat, jaký je stav objednávky, nebo informace o uzavření incidentu.

Text

3.2 Metoda analýzy K typizování incidentů je nutné získaná data vhodným způsobem zpracovat a analyzovat. Vzhledem k tomu, že datové korpusy tvořené z přirozeného spontánního jazyka je možné pouze zaindexovat, aby v nich bylo možné vyhledávat, ke zpracování tohoto typu dat je nutné přidat některé další kroky, které zajistí vyšší přesnost vyhledávání a analýzy. To je způsobeno hlavně slangem dvou skupin uživatelů, které se v incidentech objevují. Postup je možné rozdělit do dvou hlavních částí – technického zpracování a analytické činnosti. Cílem technického zpracování je připravit platformu pro analýzu dat. Výstupem je tedy invertovaný index připravený pro analytickou práci. Cílem analytické fáze je identifikace maximálního možného počtu typů incidentů a odhad jejich četnosti.

3.3 Technické zpracování dat 1.

Předání dat, formální kontrola a předběžný průzkum 

2.

2

Předání dat je vhodné provést jasně definovaným formátem, např. CSV. Předání by mělo splňovat parametry zabezpečení v organizaci a předávaná data by měla být věrohodná. To je nutné ověřit formální kontrolou. Data by měla mít jednoznačné identifikátory, datum u každé položky, textová pole by měla být ve správném kódování. Konzultace s experty, stanovení synonym, konstrukce synonymického slovníku 

S experty z ICT útvaru je vhodné zkonstruovat seznam kandidátů na synonyma. Synonymum může být více druhů: slang – běžný výraz, slang – slang, zkratka - výraz a překlep – výraz. Posledním typem je možné „opravovat“ překlepy uživatelů2. V této fázi je podstatné vytvořit seznam synonym, které spojí slangová slova s běžnou mluvou nebo zkratky s jejich slovním významem.



Jedná se např. o: o „HROT“ (zkratka) – „zákaznické centrum“ (běžný výraz)

Např. místo Facebook zapsané slovo Facebok apod.

94



„Tesu“ (slang uživatelů) – „PS-TS“ (zkratka, slang ICT) – „technická podpora (běžný výraz) Parsování dat a definice datových typů jednotlivých polí o

3.



4.

Pro úspěšné zpracování dat je nutné každou datovou větu rozdělit podle jeho formátu a načíst do paměti k jejímu zpracování. Některé nástroje obvykle vyžadují předem definovat typ pole a způsob jeho zpracování. Zpracování přirozeného jazyka nad textovými poli a) Tokenizace (oddělení jednotlivých slov). 

b) 

c)  d) 

Obsah textových polí by měl být zpracován. Měl by být rozdělen podle oddělovačů slov – mezer, interpunkce, spojovníků a speciálních znaků. Každé slovo pak prochází dalším zpracováním. Odstranění stop slov podle předdefinovaného slovníku. Nástroj by měl odstranit stop slova, která jsou v dalším zpracování nežádoucí. Jedná se obvykle o spojky, předložky, zájmena apod. Zde je možné přiřadit některé zkratky nebo slova, které se často v datech objevují3. Zpracování slov do kořenů derivátorem. Derivací pomocí stemmingových pravidel je nutné zpracovat každé slovo v položce a stejné kořeny slov sloučit dohromady. Automatická indexace umožňující vyhledávání nad datovým korpusem. Vytvořit invertovaný index umožňující v nestrukturovaných textových datech.

různé

způsoby

vyhledávání

3.4 Analytická část 1.

Konzultace s experty – identifikace entit 

Identifikace prvotních entit je klíčovou částí procesu. Ze strukturovaného interview nebo formou workshopu s experty je nutné identifikovat entity, které se často vyskytují v incidentech - klíčová slova, která jsou charakteristická pro incidenty.



2.

Obvykle zde budou zahrnuty názvy produktů, názvy oddělení ICT útvaru, části IS, datové zdroje, jména vybraných zaměstnanců. Je možné v této fázi od expertů nechat definovat vybrané typy incidentů o kterých mohou experti prohlásit, že se často opakují. Vyhledávání známých entit a) Vyhledání v datech, generalizace incidentů, stanovení četností 

Entity, které byly identifikovány je nyní vhodné začít v datech vyhledat. Z výsledků hledání je nutné dotaz dále specifikovat a doplňovat dokud výsledné incidenty nemají stejné či velmi podobné popisy zadavatele, průběhy řešení nebo informaci pro zadavatele.

Pokud většina incidentů obsahuje slovo „problém“ nebo „objednávka“ je na místě uvažovat o přidání těchto slov do stop slovníku. Tato slova totiž nemají žádnou selekční váhu a dotaz s tímto slovem vybere většinu incidentů. 3


95

Ivan Jelínek



3.

V takové fázi je dotaz dostatečně specifický a je možné ho prohlásit za definici typu incidentů. Dotaz je vhodné uložit do paměti pro budoucí použití a zaznamenat četnost a konkrétní příklad incidentu. Vyhledávání neznámých entit 

Konzultace s experty není schopna odhalit všechny typy incidentů. Ani adhoc výběr není obvykle možný provést s ohledem na velké množství incidentů, které ICT útvar řeší. Proto je nutné využít jiné způsoby jak získat z dat nové entity.



Tento způsob představují shlukovací (clusteringové) algoritmy. Jejich výstupem je shluk, který představuje tematickou kategorii výsledků (Stefanowski a Weiss 2003). Tento způsob zpracování umožnuje identifikovat témata, která se často vyskytují v konotaci s dotazem. Některá témata lze po bližším zkoumání identifikovat jako nové entity a ty zpracovat podle původního postupu. Konzultace s experty – vyřazení témat

a) 

b)

Témata, která byla identifikována se tedy znovu vyhledávají a výsledky kontrolují k tomu, aby byly identifikovány nové entity. Tyto entity se konzultují s experty, protože obvykle analytik potřebuje doplnit kontext k nalezeným výsledkům. Stanovení četností nových entit



Nově identifikované entity se stejným způsobem dále analyzují. Dotaz, který je tvoří se dále specifikuje a upřesňuje aby odstranil incidenty, které sémanticky neodpovídají hledanému typu incidentu.



Konečný dotaz je vhodné uložit a zaznamenat četnost incidentů, které mu odpovídají.

4. Typizování incidentů a výsledky analýzy Výstupem analytické části je seznam typizovaných incidentů, struktura dotazu, který je použit, a četnost incidentu v datech. Následnou konzultací s experty byly jednotlivé typy incidentů verifikovány a byla popsána jejich obvyklá příčina, která je ilustrována v Tab. 2. Při konzultaci s experty bylo stanoveno, že v datech existuje jen omezený počet příčin. Jednalo se o: Datová nekonzistence. Chyby způsobené datovou nekonzistencí nebyly v minulosti způsobeny nedodržením procesního postupu. Jedná se o situaci, pro jejíž vyřešení je nutné zasáhnout do dat a stav napravit. Obvykle se jedná o nízkou datovou kvalitu, ačkoli to může být i průvodní jev SW chyby. Provoz. Incidenty způsobené provozem jsou obvykle způsobeny pozdním zpracováním nebo nedostatečnou integrací mezi aplikacemi IS. K jejich vyřešení obvykle stačí požadavek sledovat, případně zařadit do prioritní formy zpracování ručně. Chybné přidělení. Incident neměl být směřován na vybrané oddělení CRM.

96



-

-

-

SW chyba. Incident je průvodním znakem SW chyby. Zpravidla vyvolává reaktivní problem management proces a jeho oprava je zakončena nasazením nové verze kódu. Chyba uživatele. Incident je způsoben pochybením na straně uživatele, jeho chováním, které neodpovídá procesnímu postupu nebo metodickým pokynům. Ačkoli takový požadavek může vyvolat datovou nekonzistenci nebo potřebu ručního zásahu do dat, pro přiřazení do této skupiny je podstatný fakt, že byl způsoben chybou uživatele. Nelze zjistit. Typ incidentu může být způsoben více faktory, není možné expertně specifikovat příčinu incidentu. Tab. 2 – Popis vybraných typů incidentů, zdroj: autor

Název incidentu EBILL typ

Zpracování služby Dotace DATETO TKVR manipulace

Popis charakteristiky Chyba kdy klient má nastaven jiný typ fakturace než jakou obdržel (obvykle nastavena elektronická forma, odeslána byla papírová). Zákazníkovi byla aktivována služba v CRM. Provozní systém ji ještě zákazníkovi neumožnil využívat, ačkoli proběhla již delší doba. Chybou uživatele bylo se službou „Dotace“ manipulováno proti business procesu. Neoprávněná manipulace s tarifem zákazníka při probíhajícím přenosu čísla.

Četnost

Příčina incidentu

5,18%

Datová nekonzistence

10,24%

Provoz

3,68%

Chyba uživatele

0,384%

Chyba uživatele

V následujících měsících proběhlo monitorování četností incidentů a jejich příčin, ze kterých byla vyvozena doporučení, která byla prezentována vyšším manažerům společnosti. Časový vývoj příčin incidentů je ilustrován v Obr. 1., nebo blíže rozveden v Tab. 3. Pro lepší zachycení typů incidentů byl první běh analýzy byl proveden nad souborem 9085 incidentů z období 01/2013 – 04/2014. Další analýzy byly prováděny v měsíčních intervalech nad snímkem dat za předchozí měsíc. Pro porovnání jsou výsledky uvedeny v % vyjádření nově analyzovaného objemu. V dalších kolech nebyly nové typy incidentů stanoveny, ale pouze stanovena četnost nad novým incidenty pomocí dotazů, které již byly definovány.


97

Ivan Jelínek

Obr. 1 – Vývoj příčin incidentů, zdroj: autor Tab. 3 – Vývoj příčin incidentů v %, zdroj: autor Iterace

1

2

3

4

5

6

7

8

9

10

Nelze zjistit

1,6

0,30

0

0

5,49

0

0

7,71

0

8,69

SW Chyba

14,8

10,3

7,77

23,0

4,98

4,40

6,61

5,27

6,75

5,36

Chybné přidělení

5,58

3,23

4,44

2,49

3,32

0

3,47

0

0,12

2,89

Provoz Datová nekonzistence Chyba uživatele

16,0

13,9

42,2

4,88

4,62

9,24

6,77

5,35

15,1

13,1

15,8

13,5

2,22

3,57

7,65

1,58

3,47

3,70

5,06

3,91

29,1

36,6

43,3

21,3

25,7

22,1

27,2

26,1

14,8

22,8

4.1 Dílčí závěry Analýza provedená nad incidenty v rozmezí 01/2013 – 12/2014 v několika iteracích naznačuje několik závěrů a doporučení, které jsou diskutovány níže. První iterace proběhla v květnu roku 2014 a obsahovala data od začátku roku 2013. Z tohoto základního datového korpusu byly sestaveny typy incidentů, které byly následně v dalších 9 měsíčních iteracích sledovány do konce roku 2014. Z výsledků je patrné, že tento přístup je možné použít, ačkoli se ukazuje, že v průběhu času dochází k mírné změně obsahu ICT incidentů – dochází k vývoji jak se strany ICT (nasazení nových verzí aplikací), tak ze strany business uživatelů (nové business služby, procesy, ...). Tuto míru identifikovatelnosti incidentů ilustruje Obr. 2., který jasně stanoví klesající trend. Výjimkou z pravidla o klesající míře identifikovatelnosti je 98



3. běh analýzy. Tento měsíc byl velmi specifický, co se týče provozu zkoumaného oddělení. V rámci pilotního projektu byl testován odlišný přístup k řečení incidentů a celkový objem incidentů na tomto oddělení výrazně klesl. V ostatních měsících tento pilot prováděn nebyl a objem incidentů je obvyklý.

Obr. 2 – Míra identifikovatelnosti incidentů, zdroj: autor Proto je vhodné v přiměřených intervalech opakovat stanovení nových typů incidentů, které doplní stávající seznam. Tato činnost je náročná na expertní čas a proto není nutné ji opakovat častěji než po 3 – 6 měsících v závislosti na proměnlivosti incidentů. Dále bylo zjištěno, že podstatnou část ICT zdrojů způsobuje chyba uživatelů. Vzhledem k široké distribuční síti by proto doporučení mohlo být zavedení pružnějšího školícího systému, který reaguje na časté typy incidentů. Jelikož typy incidentů byly identifikovány a jejich četnost stanovena v průběhu jednotlivých analytických iterací, je možné tak uživatelům vytvořit aktuální školení. Úpravou chování uživatelů se proto může dojít k menšímu vytěžování ICT zdrojů, zlepšení B/IT alignmentu a konečně, ke zlepšení kvality poskytované služby. Dalším bodem jak zlepšit kvalitu ICT služeb je optimalizace vnitřního chodu a zpracování incidentů, který souvisí se skupinou chybné přidělení, která se objemově pohybovala na 5-10% přidělených incidentů ke zpracování. Zlepšení v řešení těchto typů incidentů bude mít za následek rychlejší zpracování incidentu a uvolnění zbytečně blokovaných zdrojů. Typy incidentů s příčinou datové nekonzistence jsou vhodnými kandidáty k revizi IS jak na úrovni logiky aplikace, tak na úrovni návrhu nebo datového modelu. Ukazují i na oblasti, které by se měly řešit v rámci projektů zlepšování kvality dat. Analyzovaná data byla velmi specifická a je možné, že v prostředí jiné firemní kultury, logy mohou být rozdílné. Navržená metoda ale reflektuje tento specifický datový korpus, na kterém byla ověřena a její kroky jsou obecně platné. Ze své podstaty předpokládá, že experti jsou schopni odhadnout příčinu vzniku incidentu a podle toho ho kategorizovat. Zároveň je teoreticky možné dojít i k více než 100% rozpoznaných incidentů. To by mohlo být způsobeno tím, že dotaz, který je použit k vyhodnocení četnosti zároveň vybírá i jiné incidenty, které logicky do tohoto typu nepatří a tudíž došlo k chybně zkonstruovanému dotazu.


99

Ivan Jelínek

5. Závěr Studie se věnovala možnostem analýzy nestrukturovaného textu z logů ICT incidentů velkého českého telefonního operátora. Tyto incidenty byly v průběhu několika měsíců analyzovány, byly sestaveny generalizované typy incidentů a těmto typům byla pomocí konzultace s experty přiřazena příčina jejich vzniku. Některé příčiny je možné ošetřit a doporučit na rovině strategického řízení informatiky kroky ke zlepšení B/IT vztahu jak na úrovni businessu, tak ICT útvaru. Na analyzovaných datech bylo identifikováno, že velká část incidentů byla zapříčiněna chybou business uživatele (např. nedodržení procesního postupu). Nástroj proto může doporučit např. školení business uživatelů na nejčastější problémy, kvůli kterým jsou zadávány incidenty. Jen toto opatření může snížit počet zadávaných incidentů a tím zvýšit kvalitu poskytované služby, protože zákazník nemusí čekat na konečně vyřešení incidentu a službu ihned využívat. Nasazení takového nástroje ale předpokládá úpravu stávajících metod a přístupů k analýze nestrukturovaných dat kvůli tomu, že text ICT incidentů často obsahuje celé chybové hlášení, zkratky, nebo profesní slang.

Literatura Brychcin, T., Konkol, M. A Steinberger, J., 2014: UWB: Machine Learning Approach to Aspect-Based Sentiment Analysis. SemEval, pp. 817-822 Cannon, D., Wheeldon, D., Taylor, S., 2010: ITIL: [IT service management practices; ITIL v3 core publications]. [4]: Service operation. 3rd edition, London: TSO. ISBN 978-0-11-331046-3 Crockett, S., Lee, C., 2012: Does it Matter What They Said? A Text Mining Analysis of the State of the Union Addresses of USA Presidents. In: [online]. B.m.: IEEE, p. 77–82. ISBN 978-1-4673-2120-4. Dostupné z: doi:10.1109/SNPD.2012.13 Ediger, D., Jiang, K., Riedy, J, Bader, D. A., Corley, C., 2010: Massive Social Network Analysis: Mining Twitter for Social Good. In: [online]. B.m.: IEEE, p 583–593, ISBN 978-1-4244-7913-9 Hassan, A., Abbasi, A., Zeng, D., 2013: Twitter Sentiment Analysis: A Bootstrap Ensemble Framework. In: [online]. B.m.: IEEE, p. 357–364, ISBN 978-0-7695-5137-1 Hrala, M., Král, P., 2013: Multi-label document classification in czech. In: Text, Speech, and Dialogue [online]. B.m.: Springer, p. 343–351 Dostupné z: http://link.springer.com/chapter/10.1007/978-3-642-40585-3_44 Champion, H., Pizzi, N., Krishnamoorthy, R., 2014: Tactical Clinical Text Mining for Improved Patient Characterization. In: [online]. B.m.: IEEE, p. 683–690. ISBN 978-1-4799-5057-7. Dostupné z: doi:10.1109/BigData.Congress.2014.101 Kamath, S.S., Bagalkotkar, A., Kandelwal, A., Pandey, S., Poornima, K., 2013: Sentiment Analysis Based Approaches for Understanding User Context in Web Content. In: [online]. B.m.: IEEE, pp. 607–611 ISBN 978-1-4673-5603-9. Dostupné z: doi:10.1109/CSNT.2013.130 Keretna, S., Hossny, A., Creighton, D., 2013: Recognising User Identity in Twitter Social Networks via Text Mining. In: [online]. B.m.: IEEE, p. 3079–3082, ISBN 978-1-4799-0652-9. Dostupné z: doi:10.1109/SMC.2013.525 100



Minier, Z., Bodo, Z., Csato, L, 2007: Wikipedia-Based Kernels for Text Categorization. In: [online]. B.m.: IEEE, pp. 157–164. Dostupné z: doi:10.1109/SYNASC.2007.8 Stefanowski, J., Weiss, D., 2003: Carrot2 and language properties in web search results clustering. In: Advances in Web Intelligence [online]. B.m.: Springer, pp. 240–249. Dostupné z: http://link.springer.com/10.1007/3-540-44831-4_25 Strossa, P., 2011: Počítačové zpracování přirozeného jazyka. Praha: Oeconomica. ISBN 978-80-245-1777-3 Turney, P.D., 2002: Thumbs up or thumbs down?: semantic orientation applied to unsupervised classification of reviews. In: Proceedings of the 40th annual meeting on association for computational linguistics [online]. B.m.: Association for Computational Linguistics, pp. 417–424 Dostupné z: http://dl.acm.org/citation.cfm?id=1073153 Twitter, 2015: REST APIs. Twitter Developers [online] [vid. 24. září 2015]. Dostupné z: https://dev.twitter.com/rest/public Voříšek, J., Basl, J. 2008: Principy a modely řízení podnikové informatiky. Praha: Oeconomica. ISBN 978-80-245-1440-6 Waila, Pranav, Singh V. K., Singh M. K., 2013: Blog text analysis using topic modeling, named entity recognition and sentiment classifier combine. In: Advances in Computing, Communications and Informatics (ICACCI), 2013 International Conference on [online]. B.m.: IEEE, p. 1166–1171Dostupné z: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6637342

JEL Classification: C80


101

Konkurenční výhoda skrze analýzu ICT incidentů: analýza nestrukturovaných dat

Recommend Documents