Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod
MS Dynamics CRM v nadnárodní společnosti
Diplomová práce
Autor:
Bc. Jan Moravec Informační technologie a management
Vedoucí práce:
Praha
Ing. Aleksandar Antonovič
Duben, 2015
Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze, dne 13.4.2015
Jan Moravec
Poděkování Tímto bych chtěl poděkovat svému vedoucímu diplomové práce Ing. Aleksandaru Antonoviči za odborné vedení při vypracování této práce. Poděkování patří i vedení společnosti Heidelberger Druckmaschinen AG, která je předmětem případové studie praktické části této práce.
Anotace Tato diplomová práce se zabývá moţností zlepšení přímé komunikace se zákazníky v prostředí nadnárodní společnosti, zavedením jednotného CRM systému ve všech jejich regionálních pobočkách. V teoretické části práce jsou uvedeny základní vlastnosti a součásti CRM systémů. Praktická část práce je případovou studií implementace CRM systému ve společnosti Heidelberger Druckmaschinen AG a jeho vyuţití nejen v oblasti automatizace obchodních procesů, ale i v oblasti servisních sluţeb. Práce dále popisuje efekty zavedení CRM systému ve společnosti. Závěrečná část práce je věnována projektu upgrade systému a jeho konkrétní realizaci v prostředí nadnárodní společnosti.
Klíčová slova: CRM, případová studie, nadnárodní společnost, MS Dynamics CRM, zákaznické úpravy, upgrade, servisní služby
Annotation This thesis deals with the possibilities of improving direct communication with customers in a multinational company, by the introduction of a unified CRM system in all its regional offices. The basic characteristics and components of CRM systems are described in the theoretical part. Practical part is a case study of the implementation of CRM system in the company of Heidelberger Druckmaschinen AG and its use not only in the automation of business processes, but also the possibility of usage of CRM system in customer service area. The thesis also describes the effects of the introduction of CRM system in the company. The final part is devoted to the system upgrade and its implementation in the environment of a multinational company.
Key words: CRM, Case Study, Multinational Company, MS Dynamics CRM, Customization, Upgrade, Customer Service
Obsah ÚVOD .................................................................................................................................. 8 1
CO JE TO CRM?..................................................................................................... 10
1.1
Architektura CRM ................................................................................................. 10
1.2
Procesní pohled a CRM koncepce ......................................................................... 12
1.2.1
Procesní pohled na CRM: ........................................................................................................... 12
1.2.2
CRM koncepce ........................................................................................................................... 12
1.3
Moduly a funkce .................................................................................................... 13
1.3.1
SFA – řízení prodeje................................................................................................................... 14
1.3.2
Aktivity a plánování ................................................................................................................... 14
1.3.3
Marketing ................................................................................................................................... 14
1.3.4
Servis a podpora ......................................................................................................................... 15
2
IMPLEMENTACE CRM SYSTÉMŮ ................................................................... 16
2.1
Analýza potřeb a výběr vhodného systému ........................................................... 16
2.2
Proces implementace ............................................................................................. 17
2.3
Překáţky a problémy při implementaci ................................................................. 19
3
CHARAKTERISTIKA MS DYNAMICS CRM ................................................... 21
3.1
Zařazení aplikačního softwaru ............................................................................... 21
3.2
Technologie............................................................................................................ 21
3.3
Licenční podmínky a cenové charakteristiky ........................................................ 22
4
PŘÍPADOVÁ STUDIE ............................................................................................ 24
4.1
Profil společnosti ................................................................................................... 26
4.2
Struktura společnosti .............................................................................................. 27
4.3
Struktura IT ............................................................................................................ 28
5
HEIDELBERG CRM .............................................................................................. 30
5.1
Standardizace CRM ............................................................................................... 30
5.1.1
Výběr CRM systému .................................................................................................................. 31
5.1.2
Implementace systému ............................................................................................................... 32
5.2
Architektura SW .................................................................................................... 34 5
5.2.1
Celková koncepce návrhu SW, výčet a uspořádání modulů ....................................................... 34
5.2.2
Podpora podnikových procesů a oblastí ..................................................................................... 35
5.2.3
Podpora řízení............................................................................................................................. 36
5.2.4
Otevřenost architektury .............................................................................................................. 36
5.2.5
Podpora správy a monitoring provozu ........................................................................................ 36
5.3
Specifikace provozního prostředí .......................................................................... 36
5.3.1
Specifikace HW, OS serverů a pracovních stanic, LAN/WAN .................................................. 36
5.3.2
Specifikace DB systému ............................................................................................................. 37
5.3.3
Zajištění provozu systému, vč. bezpečnosti ............................................................................... 37
5.4
Uţivatelské úpravy................................................................................................. 38
5.4.1
Prodej ......................................................................................................................................... 38
5.4.2
Servis .......................................................................................................................................... 39
5.4.3
Workflow ................................................................................................................................... 39
5.4.4
Integrace s ostatními aplikacemi ................................................................................................ 40
5.5
Reporty ................................................................................................................... 41
5.5.1
MS CRM reporty ........................................................................................................................ 42
5.5.2
Qlikview reporty......................................................................................................................... 42
5.6
Podpora systému a změnové řízení ........................................................................ 43
5.7
Efekty zavedení CRM ............................................................................................ 45
5.7.1
Finanční výnosy ......................................................................................................................... 45
5.7.2
Ekonomické efekty ..................................................................................................................... 45
5.7.3
Zákaznické či trţní efekty .......................................................................................................... 45
5.7.4
Personální efekty ........................................................................................................................ 45
5.7.5
Zvýšení procesní výkonnosti ...................................................................................................... 46
5.7.6
Zvýšení analytické výkonnosti a kvality řízení podniku ............................................................ 46
5.7.7
Skutečné efekty podnikové informatiky ..................................................................................... 46
6
CRM A SERVISNÍ SLUŢBY ................................................................................. 48
6.1
Heidelberg servis ................................................................................................... 48
6.2
Business procesy v oblasti zákaznického servisu .................................................. 48
6.3
Vyuţití CRM pro servisní sluţby .......................................................................... 50
6.3.1
Zakázka – Case ........................................................................................................................... 51
6.3.2
Servisní aktivity – Kalendář ....................................................................................................... 52
6.3.3
Servisní list ................................................................................................................................. 53
6.3.4
Časové výkony ........................................................................................................................... 55
6.3.5
Schválení a fakturace.................................................................................................................. 55
6
6.3.6
Reporting .................................................................................................................................... 56
6.3.7
Web portál .................................................................................................................................. 57
6.4
Přínosy a další rozšíření ......................................................................................... 59
6.4.1
Přínosy zavedení servisní části systému ..................................................................................... 59
6.4.2
Další rozšíření systému............................................................................................................... 60
7
UPGRADE SYSTÉMU ........................................................................................... 61
7.1
MS CRM 2013 ....................................................................................................... 62
7.2
Příprava upgrade .................................................................................................... 65
7.3
Vývoj a úpravy systému......................................................................................... 66
7.4
Testování ................................................................................................................ 68
7.4.1
Integrační testování a systémové testování (SIT) ....................................................................... 68
7.4.2
Akceptační testování (UAT)....................................................................................................... 69
7.5
Migrace a uvedení do provozu ............................................................................... 69
7.6
Školení uţivatelů .................................................................................................... 71
7.7
Dokumentace ......................................................................................................... 72
7.7.1
Uţivatelská dokumentace ........................................................................................................... 72
7.7.2
Systémová dokumentace ............................................................................................................ 73
ZÁVĚR.............................................................................................................................. 74 SEZNAM POUŢITÉ LITERATURY ............................................................................ 76 SEZNAM POUŢITÝCH ZKRATEK ............................................................................ 77 SEZNAM OBRÁZKŮ ..................................................................................................... 79 SEZNAM TABULEK ...................................................................................................... 80 SEZNAM PŘÍLOH .......................................................................................................... 80
7
Úvod Snaha získávat nové zákazníky a zejména udrţet si je se v dnešní době dostává stále více do popředí. Systémy řízení vztahů se zákazníky CRM tak patří k nejpopulárnějším oblastem podnikové informatiky. Právě tyto aplikace pomáhají firmám a institucím ke zkvalitnění komunikace se zákazníky a zvyšování jejich spokojenosti. Jako student kombinované formy studia se ve svém zaměstnání věnuji implementaci a správě CRM systému, a proto jsem i jako téma své diplomové práce volil problematiku CRM systémů. Cílem této práce je analýza moţností vyuţití systému Microsoft Dynamics CRM v nadnárodní společnosti, způsobem jeho implementace a zákaznických úprav, procesu upgrade a rozšíření systému v oblasti servisních sluţeb. Praktická část práce je případovou studií procesu standardizace CRM systému ve firmě Heidelberger Druckmaschinen AG (dále Heidelberg) se sídlem v Německu, která je předním výrobcem zařízení pro polygrafický průmysl. Hlavním cílem této implementace bylo především zlepšení komunikace se zákazníky a zvýšení jejich spokojenosti, dále pak zavedení jednotného informačního systému napříč jednotlivými pobočkami společnosti, a tím zjednodušení správy systému a zlepšení informovanosti globálního managementu společnosti o komunikaci se zákazníky v jednotlivých pobočkách. Dále si shrneme výsledné efekty zavedení CRM systému, ukáţeme si jakým způsobem je řešena automatizace procesů v oblasti servisních sluţeb vyuţitím CRM a v závěru práce popíšeme projekt upgrade systému. Celá práce je rozdělena na dvě části, část teoretickou a část praktickou. Teoretická část poskytuje obecnou charakteristiku systémů pro řízení vztahů se zákazníky, přehled jejich hlavních částí, dále přístup k systémům z pohledu procesního a pohledu CRM koncepce. Závěr teoretické části je věnován procesu implementace CRM systémů, faktorům úspěchu a moţným problémům při zavádění systému. V praktické části, která je tvořena případovou studií, se stručně seznámíme se společností Heidelberger
Druckmaschinen,
její
organizační
strukturou
a
IT
organizací.
V následujících kapitolách je provedena analýza současného stavu jak v oblasti IT infrastruktury, tak i v oblasti informačních systémů a aplikací. Další část práce je
8
věnována úpravám a přizpůsobení systému a jeho integraci s ostatními systémy. V závěru páté kapitoly si shrneme výsledné efekty zavedení systému CRM ve společnosti Heidelberg. Následující kapitola demonstruje moţnost vyuţití CRM systému v oblasti servisních sluţeb a poprodejní péče o zákazníka. Popisuje business procesy v servisní oblasti a jejich automatizaci pomocí zákaznických úprav systému. V závěru práce si ukáţeme postup při realizaci projektu upgrade systému CRM verze 4.0 na verzi 2013. Popíšeme jednotlivé fáze projektu od přípravy, přes vývoj a zákaznické úpravy, testování, školení uţivatelů a tvorbu dokumentace aţ po uvedení do provozu. Tato práce by měla slouţit jako příklad moţnosti vyuţití systému Microsoft Dynamics CRM v nadnárodní společnosti zabývající se prodejem zařízení a jejich následným servisem a poprodejní péčí. Při psaní této práce byla jako hlavní metoda zvolena demonstrace této na příkladu konkrétní případové studie.
9
1 Co je to CRM? Hovoříme-li o CRM (Customer Relationship Management), máme na mysli marketingovou strategii firmy, kde v centru pozornosti stojí zákazník. Veškeré aktivity nejsou tedy zaměřeny na hledání zákazníků pro naše produkty, ale na hledání vhodných produktů pro kaţdého zákazníka. „Řízení vztahů se zákazníky umožní společnosti lépe zjistit „kdo“ jsou její zákazníci, jaká jsou jejich očekávání, jak se chovají a především poskytovat jim určitou hodnotu – obvykle ve formě individualizovaného produktu či služby. Základem je rychlá zpětná vazba od zákazníka, její kvalitní analytické zpracování a následně využití takto získaných informací k zefektivnění interakcí s nimi, s cílem poskytnutí požadované hodnoty.“ (1) Cílem CRM je kromě zlepšení komunikace se zákazníkem na venek i její koordinace uvnitř podniku. Sdílení informací získaných jednotlivými pracovníky při interakcích se zákazníky patří mezi hlavní úkoly CRM systémů z hlediska vnitropodnikové komunikace. Jde o to, aby například při reklamování výrobku či nutnosti servisního zásahu nebylo nutné postupně opakovaně objasňovat tytéţ skutečnosti a podrobnosti ostatním pracovníkům firmy. Na místo toho by veškeré tyto informace měly být velmi jednoduše dostupné všem zaměstnancům, kteří s nimi následně pracují. Funkce nejnovější generace systémů CRM přesahují jednoduché systémy pro prodej a marketing. Tyto nové programy se zaměřují na „celopodnikové“ řešení. Důleţitou vlastností těchto systémů je schopnost jejich přizpůsobení tak, aby bylo moţné je nasadit v nejrůznějších prostředích a situacích (2). CRM systémy jsou navrţeny tak, aby mohly slouţit všem zaměstnancům firmy, kteří komunikují se zákazníky, ať uţ se jedná o pracovníky oddělení marketingu, obchodu, servisu nebo například asistentky, recepční, dispečery, ale i manaţery podniku.
1.1 Architektura CRM CRM systémy se obvykle člení na tři části, část operativní, kooperativní a analytickou (3). Schéma architektury CRM systému je zobrazeno na obrázku 1-1. Operativní část CRM realizuje předem definované obchodní procesy. Je to ta část CRM řešení, která podporuje interakci se zákazníkem prostřednictvím různých komunikačních
10
kanálů (call centra, elektronické kanály, poštovní zásilky, prodejní místa). Součástí operační části CRM mohou být i aplikace Back-office (podpůrné aplikace, které nemají přímý vliv na kontakt se zákazníkem), ale hlavní část tvoří Front-office (aplikace vyuţívané při přímém kontaktu se zákazníkem). Mezi hlavní moduly operační části CRM patří především: Sales Force Automation (aplikace podporující práci obchodníka) Enterprise Marketing Automation (automatizace marketingu) Customer Service and Support (aplikace zákaznických sluţeb a podpory) Kaţdá interakce se zákazníkem (schůzka, tel. hovor, email, atd.) je zaznamenána do historie komunikace s tímto zákazníkem, odkud můţe následně kaţdý zaměstnanec v případě potřeby čerpat potřebné informace. Obrázek 1-1: Architektura CRM
Zdroj: SystemOnline (4)
Kooperativní část CRM navazuje na část Front-office a představuje přímou interakci se zákazníkem pomocí různých komunikačních kanálů (osobní kontakt se zákazníkem, písemná korespondence, elektronická pošta, faxová komunikace, telefonický kontakt, komunikace přes internet). Analytická část CRM analyzuje zákaznická data z různých pohledů. Do působnosti analytické části CRM patří např. segmentace klientů, analýzy chování zákazníků, analýzy a řízení marketingových kampaní.
11
1.2 Procesní pohled a CRM koncepce Dále se podíváme na systém CRM z pohledu jeho podpory firemních procesů a volby moţné koncepce jeho implementace.
1.2.1 Procesní pohled na CRM: Jako CRM procesy označujeme veškeré procesy ve firmě, které jsou součástí obchodního cyklu, poprodejní podpory a zákaznického servisu nebo jinak přímo či nepřímo ovlivňují komunikaci se zákazníky. Podle Sodomky (5) patří mezi klíčové procesy v oblasti CRM především: „Řízení kontaktů – spočívá v řízení vícekanálové komunikace se zákazníky dovnitř i vně organizace. Jedná se tedy o průřezový proces, který zahrnuje všechny ostatní CRM procesy. K automatizaci řízení kontaktů se využívají technologie kontaktního centra (Contact Center) Řízení obchodu – zahrnuje objednávkový cyklus (řízení kontaktů, zaznamenávání a vyřízení objednávky a její převzetí zákazníkem) a prolíná se s dalšími dvěma CRM procesy, kterými jsou řízení marketingu a servisní služby. K automatizaci obchodních činností je určena funkcionalita SFA (Sales Force Automation). Řízení marketingu – spočívá v řízení marketingových zdrojů, plánování, realizace a vyhodnocování marketingových kampaní. Cílem marketingového procesu je identifikovat potenciální zákazníky a vytvořit tak nové obchodní příležitosti. K automatizaci marketingového procesu se využívá funkcionality označované jako EMA (Enterprise Marketing Automation). Servisní služby -
slouží k zajišťování záručního i pozáručního servisu, nabídce
doplňkových produktů a služeb s cílem posílit spokojenost zákazníka. Zasahují obchodní cyklus ve všech fázích, a proto je také dělíme na předprodejní, prodejní a poprodejní. Servisní služby jsou v rámci CRM řízeny funkcionalitou, která se označuje jako CSS (Customer Service and Support).“
1.2.2 CRM koncepce K CRM koncepci patří technologické řešení (CRM systém) a lidé, kteří danou strategii za pomocí nasazeného systému prosazují. CRM systém lze tedy definovat jako nástroj pro řízení CRM procesů. 12
V praxi se nejčastěji uplatňují následující typy CRM koncepce (5) : „Globální CRM koncepce – typická pro velké společnosti a nadnárodní korporace podnikající na celosvětovém trhu. Je charakteristická jednotným typem všech CRM procesů, nevyžaduje úpravu datového modelu pro jednotlivá teritoria týkající se produktů, servisu, klientů s výjimkou legislativních odlišností. Vyznačuje se minimem požadavků na lokalizaci. Úspěšná globální CRM koncepce je podmíněna tím, že strategické cíle a rozhodnutí jsou „diktována shora“ a jsou prováděny bez zásahu lokálních poboček. Globální, lokálně uzpůsobená koncepce – je uplatňována velkými korporacemi i středně velkými společnostmi tam, kde je potřeba zohlednit specifické podmínky lokálních trhů, byť jejich nabídka je činěna globálně. Je charakteristická globálním CRM řešením, které vyžaduje podstatné místní úpravy v oblasti CRM procesů. Jsou zde i rozdíly v požadavcích na charakteristiku produktu, zákazníků a servisu, a proto se využívají odlišné datové modely. Lokální CRM koncepce – je využívána všemi typy organizací, vyžaduje specifické CRM řešení pro každý lokální trh. Katalogy zákazníků i produktů jsou spravovány v rámci místních CRM aplikací. Centrálně jsou určována pouze pravidla pro CRM strategii, ostatní činnosti jsou decentralizovány na místní pobočky.“
1.3 Moduly a funkce CRM jako informační systém, je modulový systém skládající se z jednotlivých aplikací, které jsou vzájemně propojeny a navázány k záznamu o obchodních partnerech. Přehled obecných modulů systému CRM: evidence obchodních partnerů a kontaktů obchodní případy a příleţitosti marketing komunikace plánování analýza a vyhodnocení
13
1.3.1 SFA – řízení prodeje Modul kontaktů je páteřním modulem kaţdého CRM systému, umoţňuje sdílení a komplexní správu informací o zákaznících, dodavatelích, partnerech a jejich kontaktních osobách. Kromě základních údajů o společnosti, obsahuje i podrobné informace o konkrétních osobách, jejich postavení v rámci hierarchie firmy, vliv na rozhodovací procesy ve firmě nebo informace o jejich zálibách. Veškeré tyto informace jsou následně vyuţívány zejména při plánování marketingových aktivit, jako jsou direct mailové kampaně atd. Část obchodního případu spojuje veškerou související komunikaci (e-maily, záznamy o schůzkách, telefonáty a úkoly), spravuje informace o vytvořených cenových nabídkách, smluvních podmínkách nebo aktivitách konkurence. Tyto údaje jsou cenným podkladem pro následné vyhodnocování úspěšnosti marketingových kampaní či prognóz vývoje trţeb.
1.3.2 Aktivity a plánování Modul pro správu aktivit zahrnuje základní funkce pro plánování schůzek, telefonátů a úkolů, jak je to obvyklé u systémů pro organizaci času. Veškeré aktivity bývají svázány s kontakty, obchodními případy nebo aktivitami v servisním modulu. Schůzky a úkoly je moţno sdílet s ostatními uţivateli v rámci pracovní skupiny, a tím výrazně zefektivňovat komunikaci uvnitř společnosti. Emailové zprávy lze vytvářet přímo v aplikaci CRM, ty jsou potom automaticky svázány s konkrétním zákazníkem či osobou a uloţeny jako součást historie komunikace s tímto zákazníkem. Ve většině CRM systémů podporuje modul pro správu aktivit integraci s běţně pouţívanými aplikacemi pro organizaci času, jako jsou kalendář Google nebo MS Outlook. Výjimkou není ani moţnost integrace s TAPI1 kompatibilními telefonními systémy pro přidruţení telefonních hovorů nebo podpora synchronizace s mobilními zařízeními jako jsou chytré telefony nebo tablety.
1.3.3 Marketing Řízení marketingových aktivit obsahuje nástroje pro plánování, přípravu a spravování cílených emailových, telefonních či mailingových marketingových kampaní nebo
1
TAPI (Telephony Application Program Interface – sluţba v systému Windows pro spolupráci s telefonní
ústřednou)
14
automatické rozesílání informací o novinkách, včetně jejich následného vyhodnocování na základě zpětné vazby od zákazníka. Součástí jsou dále i nástroje pro segmentaci zákazníků a vytváření distribučních seznamů.
1.3.4 Servis a podpora Servisní část CRM řeší kompletní proces záručního a pozáručního zákaznického servisu, od příjmu servisních poţadavků na centrálním dispečinku, přes operace s náhradními díly, plánování servisních zásahů, evidence pracovních úkonů a času servisních techniků aţ po vyúčtování nákladů na provedený servisní zásah. Součástí servisního modulu je mimo jiné i kompletní správa servisních smluv, analýzy vytíţenosti servisních techniků atp.
15
2 Implementace CRM systémů 2.1 Analýza potřeb a výběr vhodného systému Při zavádění CRM systémů je stejně tak jako u všech informačních systémů důleţité, aby bylo zajištěno optimální vyuţití implementované technologie k plnění obchodních cílů. Proto je nezbytné vědět, na které vlastnosti a funkce CRM systému je potřeba se zaměřit, a které naopak není nezbytně nutné do systému zahrnovat. Úvodní analýza poţadavků na systém společně formulací obchodních cílů společnosti patří ke klíčovým krokům při výběru a specifikaci CRM. Podle Burnetta (2), patří mezi hlavní oblasti, které mohou mít největší vliv na úspěch nasazení CRM systému zejména: Schopnost integrovat vstupy zákazníka a vnitropodnikové procesy „K dosažení efektivního řízení vztahů se zákazníky je potřeba zabezpečit propojení mezi vnějšími procesy podniku (kontakt se zákazníky) a vnitřními procesy podniku (vyřizování objednávek, reklamací atd.). Proto je potřeba hledat takový systém, který je schopen spolupracovat a sdílet informace o zákaznících s jinými systémy ve firmě (zejména ERP) nebo systémy třetích stran.“ Komunikační kanály Dalším důleţitým aspektem je flexibilita při volbě vyuţívaných komunikačních kanálů. S rostoucím vyuţíváním nástrojů elektronické komunikace (e-mail, web portály, atd.) je potřeba umoţnit integrovat i tyto komunikační kanály do informačního systému bez narušení
existujících
obchodních
procesů
či
nutnosti
přebudování
dosavadní
infrastruktury. (2) Inteligentní správa procesů „Existují dva přístupy k řízení zákazníků: přístup orientovaný na data a přístup orientovaný na procesy. Řešení orientovaná na data fungují v homogenních jednoúčelových aplikacích určených pro jedno oddělení. Naproti tomu řešení CRM jsou orientovaná na procesy. Tato řešení využívají zákaznické a systémové informace v každé fázi určitého procesu, a tak umožňují inteligentní správu workflow. Díky tomu mohou všichni zaměstnanci na všech úrovních lépe plnit své úkoly při obsluze zákazníků. Implementace CRM orientovaná na procesy je nejvhodnější metodou především 16
v globálních organizacích, kde jednotlivá interakce se zákazníkem vyvolá řadu procesů v různých úsecích organizace.“ Snadný přístup k informacím „Informace o zákaznících jsou obvykle v rámci podniku rozloženy v systémech mainframe, ERP systémech či samostatných databázích. Dalším úkolem CRM systému je tak poskytování rozhraní pro přístup k těmto různým zdrojům informací. Cílem však není pouhé mapování dat z jedné aplikace do druhé, ale především možnost použití těchto informací v kontextu daného obchodního procesu tak, aby bylo dosaženo efektivního zpracování požadavku.“ Nástroje pro přizpůsobení systému včetně nástrojů pro definici procesů Ţádné dvě společnosti nejsou stejné, a proto neexistuje ţádné zaručeně nejlepší univerzální řešení. Kaţdý podnik má jiná pravidla, popisy práce, metody a postupy. Toto všechno se musí v pouţité technologii odrazit. Proto je důleţité, aby pouţitý CRM systém byl dobře přizpůsobitelný, otevřený a schopný integrace s jinou existující infrastrukturou, včetně moţnosti definovat a přizpůsobit procesy. (2) „Škálovatelnost“ „Obecným trendem je, že se podniky rozšiřují. S tím jak se rozšiřují, je důležité mít jistotu, že i instalované systémy se budou s rostoucí poptávkou podniku také schopny rozšiřovat. Škálovatelnost systému je významným faktorem dlouhodobého úspěchu projektu CRM.“ „Investice do CRM a nového nastavení procesů budou mít jen zanedbatelnou návratnost, pokud projekt a implementace CRM nebude příležitostí k tomu, že v rámci řízení lidských zdrojů změníme kulturu firmy. Obchodníci a pracovníci marketingu by měli mít stanovenou jako jednu z metrik výkonu právě zákaznickou spokojenost. Ani sebelepší CRM software a špičkové vybavení kontaktního centra bude k ničemu, pokud všichni zaměstnanci nebudou informace o jakémkoli kontaktu se zákazníkem do společné databáze důsledně vkládat a následně ke své práci využívat „(6).
2.2 Proces implementace „Implementace systému CRM musí především respektovat priority firmy, je závislá na tom, zda se firma potřebuje zaměřit na získání nových zákazníků nebo na zabránění odchodu současných a posílení jejich loajality (7). Mezi základní předpoklady úspěšného
17
projektu implementace CRM systému patří atmosféra podniku, ve kterém se o všech změnách v souvislosti se zavedením CRM systému a navazujících organizačních opatřeních otevřeně hovoří na všech úrovních. Výsledkem je, ţe systém má plnou podporu podniku včetně jeho vedení a zároveň všechny existující či nově zavedené podnikové procesy byly otestovány a schváleny jako vyhovující (6). Burnertt (2) uvádí následující klíčové faktory úspěšné implementace systému CRM: Určit funkce/činnosti, které je potřeba automatizovat „Efektivní implementace CRM by měla začít podrobnou analýzou a auditem procesů, na základě kterého se identifikují ty funkční úseky podniku, které by se měly automatizovat, a specifikují se technické parametry, které by měl systém CRM splňovat.“ Jako nástroje tohoto auditu je moţné vyuţít dotazníků, individuálních rozhovorů nebo návštěv s obchodními zástupci u zákazníků. Zároveň je vhodné automatizovat pouze to, co automatizaci potřebuje. Získat závazek a podporu vedení podniku Pro úspěšnou automatizaci funkcí souvisejících s řízením vztahů se zákazníky je potřeba získat podporu vrcholového vedení společnosti a dále si ji udrţovat. Tuto podporu je moţné získat zejména tím, ţe prokáţeme, ţe automatizace prodeje podporuje obchodní strategii podniku, bude mít měřitelný pozitivní vliv na ekonomické výsledky (např. zlepšení procenta úspěšnosti, zvýšení marţe, zvýšení trţeb nebo vyšší úroveň spokojenosti zákazníků) a povede k výraznému sníţení nákladů. (2) Zajistit účast uţivatelů „Do celého procesu implementace systému je vhodné co nejdříve zapojit budoucí uživatele systému, aby se zajistilo, že systém CRM bude vyhovovat jejich potřebám. Uživatelé budou mít zájem o uvedení systému do života, pokud budou mít pocit, že se jedná o „jejich“ systém a ne o další výmysl „těch nahoře“.“ Vybrat vhodnou technologii Dalším důleţitým faktorem úspěšné implementace CRM systému je výběr vhodné technologie. „Vybíráme informační technologie a systémy, které využívají otevřenou architekturu, aby bylo možné systém do budoucna rozšiřovat a zvětšovat. Vhodné jsou takové aplikace, které jsou modulární, a které lze snadno integrovat a propojovat se stávajícími systémy.“ 18
Zaškolení uţivatelů „V rámci
školení
uživatelů
je
potřeba
předvést
uživatelům,
jak
přistupovat
k požadovaným informacím a jak je používat, zajistit vhodnou uživatelskou dokumentaci a její pravidelnou aktualizaci, nabídnout možnost individuální konzultace, zajistit telefonickou linku pro podporu uživatelů a zajistit řádné proškolení klíčových uživatelů, aby byli noví uživatelé schopni rychle se systémem začít pracovat.“ Motivovat pracovníky „Systém CRM uspěje pouze tehdy, pokud budou jeho uživatelé dostatečně přesvědčeni o tom, že jim systém CRM může pomoci splnit jejich cíle. „ Pokud se uţivatelé rozhodnou, ţe do nich nebudou vkládat informace, pak se systém stane neaktuálním a nepouţitelným i pro ostatní pracovníky organizace. (2) Důsledná správa systému „V podniku musí být stanoven zodpovědný pracovník nebo oddělení, které bude dohlížet na kvalitu dat a celkový stav systému. Tento pracovník bude zodpovědný za to, že informace v systému jsou aktuální, relevantní a snadno přístupné. Pro uživatele je totiž demotivující, pokud jsou například mimo firmu, potřebují použít CRM systém a najdou v něm zastaralé nebo nesprávné údaje.“
2.3 Překáţky a problémy při implementaci Rutinní provoz CRM systému následující po jeho implementaci přináší další nároky a poţadavky na jeho uţivatele. Kaţdý informační systém je úspěšně nasazen aţ teprve tehdy, kdyţ všichni jeho uţivatelé dokáţou správně interpretovat, a bezchybně do něj vkládat data (5). Právě problémy s uţivateli jsou nejčastější překáţkou při zavádění systému CRM, ať uţ se jedná o problémy při samotném procesu implementace nebo neochotu uţivatelů nově implementovaný systém přijmout a pouţívat. Často se setkáváme se skutečností, kdy zaměstnanci zaujímají odmítavý postoj k zavádění CRM ve společnosti. Důvodem tohoto postoje bývá zejména obava z nebezpečí ztráty kontroly a omezení svobodné volby a to především proto, ţe firmy nutí zaměstnance, aby své pracně získané informace sdělovali prostřednictvím CRM systému ostatním. Zejména 19
obchodní zástupci se logicky pouţívání těchto systémů brání, reportování jim bere čas, musí akceptovat, ţe jim management “vidí do karet“ a současně jim bere pocit bezpečí a nepostradatelnosti. Důleţité je rozpoznat odpor zaměstnanců včas a diskutovat s nimi o těchto problémech, pak je moţno nebezpečí zaţehnat jiţ u svého zrodu. Rozhodující je vzbudit v zaměstnancích zájem a důvěru v nový systém, jelikoţ jsou to právě oni, kdo s ním bude pracovat (8). Některým těmto jevům lze předcházet například tím, ţe implementaci informačního systému budeme komunikovat s uţivateli a zejména obchodními zástupci dopředu, a zároveň jim vysvětlíme, ţe výhody plynoucí z pouţívání systému převýší jeho negativa. Stimulem obchodních zástupců k aktivnímu pouţívání systému můţe být například implementace výpočtu provizí přímo do samotného CRM systému a zohlednění některých aktivit zanesených do CRM do výpočtu těchto provizí. Pokud bude CRM systém místem, kde si můţe obchodní zástupce sám zkontrolovat výši provize (bonusu), můţe to mít pozitivní vliv na jeho vyuţívání. „Dalšími častými důvody neúspěchu při implementaci CRM systémů jsou nerealistická očekávání, špatná kvalita dat v systémech, nedostatečná technologická podpora, malá znalost technologií nebo přemrštěné nároky na zákaznické úpravy“ (7). Kromě výše uvedených překáţek v zavádění informačních systémů jsou i situace, ve kterých se implementace CRM systému důrazně nedoporučuje. Mezi ně patří především situace, kdy: obchodní cíle firmy nejsou jasně definované, navrhované CRM řešení neřeší hlavní obchodní problém firmy, neexistuje jasná představa o výši celkové investice do projektu CRM, neexistuje reálný časový rámec implementace.
20
3 Charakteristika MS Dynamics CRM V následující kapitole si detailněji popíšeme informační systém Microsoft Dynamics CRM, jehoţ ukázka moţnosti nasazení v prostředí nadnárodní společnosti je předmětem praktické části této diplomové práce. Popíšeme si jeho určení, pouţité technologie, verze sytému, cenovou politiku a licenční podmínky.
3.1 Zařazení aplikačního softwaru Aplikace podnikové informatiky můţeme dle jejich typu rozdělit na: infrastrukturní aplikace, celopodnikové transakční aplikace, řízení externích vztahů, e-podnikání, analytické aplikace, řízení podnikové výkonnosti a inovací, speciální aplikace pro různá odvětví. Produkt Microsoft Dynamics CRM je moţné, z hlediska tohoto členění podnikových informačních systémů, zařadit mezi systémy pro řízení externích vztahů, v tomto případě se jedná o řízení vztahů se zákazníky – Customer Relationship Management.
3.2 Technologie Microsoft Dynamics CRM je moderní aplikací vyuţívající nejnovější technologie. Aktuální verze 2013 byla doplněna o funkce pro sociální sítě a mobilní přístup. Svým designem uţivatelského rozhraní je navrţena také pro pouţívání na mobilních zařízeních, jako jsou tablety nebo chytré telefony. Řešení Microsoft Dynamics CRM je vybudováno na sadě technologií společnosti Microsoft a dovoluje vyuţít moţnosti sytémů Windows Server, Microsoft SQL Server a architektury .NET Framework. Systém dále poskytuje plnou podporu propojení s Microsoft Office, Office 365, Microsoft SharePoint, Windows Azure, Skype, Bing maps, Yammer a dalšími aplikacemi. Přínosem pro koncové uţivatele je i moţnost vyuţití aplikace CRM klient pro Outlook, který integruje veškeré funkce CRM systému přímo do prostředí Microsoft Outlook.
21
3.3 Licenční podmínky a cenové charakteristiky Pro definování cenové charakteristiky je nutné systém Microsoft Dynamics CRM rozdělit dle pouţité verze na verzi online a on-permise. a) Verze online je kompletně provozována v cloudu a organizace platí stálé měsíční poplatky a poplatky dle aktuálního počtu uţivatelů systému. Pro provoz systému v reţimu online (cloud) je nutné mít pro kaţdého uţivatele tzv. USL (User subscription license), ceny jednotlivých USL jsou rozděleny dle rozsahu pokryté funkcionality systému a pohybují se v rozsahu 15-65 USD za USL za měsíc. Podrobný přehled cen jednotlivých licencí pro verzi online najdeme na obrázku 3-1. Obrázek 3-1: Přehled cen uţivatelských licencí pro MS Dynamics CRM 2013 online
Zdroj: MSDN (9)
V ceně této klientské licence je zahrnuto pouţívání 1 produkční a 1 testovací (pokud je zakoupeno více neţ 20 uţivatelských licencí) instance systému CRM. Cena dále obsahuje 5GB uloţného prostoru na disku, který se automaticky zvyšuje s kaţdým přírůstkem 20 licencí v kategorii professional o 2,5GB aţ do výše 50GB.
22
V případě potřeby je moţné dokoupit další instance nebo dodatečný diskový prostor za následující měsíční poplatky: Tabulka 3-1: dodatečné poplatky za MS Dynamics CRM Online
Název
Cena za měsíc
produkční instance
549 USD
testovací instance
150 USD
diskový prostor
9,99 USD / 1 GB
Zdroj: Microsoft (9)
Licence je moţné zakoupit v rámci licenčních programů Volume Licensing (Enterprise Agreement, Enterprise Subscription Agreement nebo Enrollment for Education Solutions) nebo jednotlivě pomocí MOSP (Microsoft Online Subscription Program) (9). b) Ve verzi on-permise se jedná o nákup licence k pouţívání systému (server) a licencí pro jednotlivé uţivatele CAL (Client Access License). Uţivatelské licence jsou opět rozděleny do tří skupin podle funkcionality, stejně jako je tomu v případě licencí pro Online systém (viz. Tabulka 3-2). Licence pro server zahrnuje pouţívání jedné produkční instance systému běţící na jednom fyzickém nebo virtuálním operačním systému. Kompletní přehled cen licencí systému Microsoft Dynamics CRM 2013 on-permise jsou uvedeny v následující tabulce. Tabulka 3-2: Ceny licencí MS Dynamics CRM 2013 on-permise
Název
Cena licence
Microsoft Dynamics CRM Server 2013
4922 USD
Microsoft Dynamics CRM Professional User CAL
983 USD
Microsoft Dynamics CRM Basic User CAL
342 USD
Microsoft Dynamics CRM Essential User CAL
79 USD
Zdroj: Microsoft (9)
Licence je moţné zakoupit v rámci licenčních programů Volume Licensing nebo prostřednictvím certifikovaných partnerů Microsoft Dynamics.
23
4 Případová studie Praktická část této práce demonstruje zavedení CRM systému ve společnosti Heidelberger Druckmaschinen AG (dále Heidelberg). Společnost Heidelberg je nadnárodní společností zabývající se výrobou a dodávkami zařízení pro polygrafický průmysl. Následující část práce je rozdělena do tří hlavních kapitol. V jednotlivých kapitolách je popsán nejprve projekt standardizace CRM systému ve společnosti. Přechod od jednotlivých lokálních aplikací pro správu kontaktu se zákazníky v jednotlivých pobočkách k jednotnému globálnímu CRM systému. Popisuje jednotlivé kroky zavedení systému, od příprav a analýz, přes samotnou implementaci systému, školení uţivatelů a tvorbu dokumentace k předání do provozu a zavedení změnového řízení. V závěru kapitoly je provedeno zhodnocení přínosů zavedení informačního systému členěno dle jednotlivých oblastí. Dále případová studie popisuje vyuţití CRM systému v oblasti servisních sluţeb. Rozšíření CRM systému o oblast evidence servisních zásahů, instalací, servisních smluv poskytuje nejen nástroj pro řízení servisních zakázek, dispečink servisních techniků nebo jejich sdílení v rámci regionu, ale zároveň doplňuje obchodní informace o zákaznících o informace z oblasti servisu a tvoří tak komplexní databázi interakcí se zákazníkem. Poslední kapitola praktické části je věnována následnému projektu aktualizace systému na vyšší verzi. Důvodem této aktualizace byla jednak samotná technická aktualizace systému z důvodu ukončení podpory systému MS CRM 4.0 ze strany výrobce, ale také revize a úprava podnikových procesů, stanovení pravidel pro pouţívání systému a dokumentaci jednotlivých kroků firemních procesů v systému. Praktická část této práce je zpracována na základě osobních zkušeností z působení v projektových týmech pro CRM ve společnosti Heidelberg. V této společnosti působím na různých pozicích v oblasti IT od roku 2001. Posledních deset let se zabývám problematikou CRM systémů, v současné době zastávám pozici vedoucího týmu CRM pro region EMEA- East.
24
V projektech standardizace CRM systémů, zákaznických úprav pro oblast servisních sluţeb a upgrade systému jsem byl zodpovědný a aktivně pracoval zejména na následujících úkolech: Představení CRM systému vedení jednotlivých poboček v regionu společně s regionálním manaţerem IT, customizace systému včetně klientských Java scriptů, Workflow a nastavení systému, migrace dat z původně pouţívaných CRM systémů a ostatních zdrojů, tvorba reportů, školení klíčových uţivatelů a lokálních IT pracovníků v regionu.
25
4.1 Profil společnosti Heidelberger Druckmaschinen AG je celosvětově vedoucí firma v oblasti výroby a dodávek technologií pro tiskový průmysl. Firma jiţ 150 let reprezentuje výzkum, vývoj, výrobu, obchod a sluţby se stroji a zařízeními pro komerční tiskárny. Heidelberg nabízí ucelená řešení v oblasti archového ofsetového tisku, digitálního tisku, flexotisku, předtiskové přípravy a knihařského zpracování pro komerční i obalářskou produkci. Nabídka firmy je tvořena především stroji vlastní produkce a doplňkově také zařízeními partnerských firem - např. Polar-Mohr, Gallus, RICOH, atp. Tradice a těţiště produkce Heidelbergu je tvořena ofsetovými tiskovými stroji malých, středních a velkých formátů. Produkce tiskových strojů je oblast, kterou si Heidelberg získal celosvětovou reputaci. Postupem času, ale byl záběr Heidelbergu rozšiřován a dnes pokrývá naprosto komplexní nabídku, co se vybavení komerčních tiskáren týče. Produkční portfolio Heidelbergu dnes tvoří CtP systémy vč. softwarů na zpracování dat, ofsetové stroje, digitální tiskové stroje, flexotiskové stroje, skládací stroje, řezací stroje, výsekové automaty a další stroje a zařízení pro komerční tiskárny. Vedle strojů nabízí Heidelberg rozsáhlou škálu sluţeb. Jejich součástí jsou servisní sluţby zajišťované celosvětově více neţ 1.500 servisními techniky, dále náhradní díly, veškeré spotřební materiály pro polygrafickou výrobu, softwarové vybavení, vč. systémů integrace strojů do výrobního workflow a systémy řízení procesů v tiskárně. Sídlo a administrativní centrum Heidelbergu je v Německu. Výzkum, vývoj a produkce je rozdělena do celkem 12 výrobních závodů v 5 zemích světa. Celkově Heidelberg zaměstnává téměř 12.500 zaměstnanců, z toho asi 2/3 v Německu. Obchod a sluţby zajišťuje síť asi 250 prodejních a servisních zastoupení ve více neţ 150 zemích světa vč. České republiky. Celosvětově obsluhuje Heidelberg asi 200.000 zákazníků. Heidelberg si dlouhodobě udrţuje zhruba 40% podíl na světovém trhu mezi dodavateli strojů a zařízení pro komerční tiskárny. Regionálně se ale podíly liší. Největšími konkurenty jsou výrobci z vyspělých průmyslových zemí jako je Německo (KBA, Manroland), Japonsko (Komori, Sakurai) a Švýcarsko (Bobst, Müller Martini) a stále silnější rozvíjející se státy jako Čína. V současnosti čelí Heidelberg také výrazným technologickým změnám - především nástup digitalizace a digitálního průmyslového
26
tisku. V této oblasti jsou hlavními konkurenty tradiční firmy digitálního tiskového průmyslu - Canon, Konica Minolta, Fuji, Xerox atp.
4.2 Struktura společnosti Heidelberg má právní formu akciové společnosti s akciemi volně obchodovatelnými na burze. Mezi hlavní akcionáře firmy patří pojišťovací a finanční skupiny. V roce 2013 dosáhla firma obratu 2,43 mld. Euro a hrubého zisku 143 mil. Euro (EBITDA). Před vlnou ekonomické krize, která výrazně zasáhla polygrafický průmysl, dosahoval obrat Heidelbergu 3.803 mil. Euro (r. 2007) a hrubý zisk 491 mil. Euro (r. 2007). Dlouhodobě tvoří prodeje strojů a zařízení asi 60% obratu firmy a sluţby tvoří zhruba 40% podíl, přičemţ podíl sluţeb má rostoucí tendenci. Zhruba 15 % obratu je tvořen na domácím trhu (Německo), 85 % je tvořen v zahraničí. Heidelberg je tak naprosto proexportně orientovaná firma. Hlavními regiony, co se odbytu a obratu týče, jsou: střední Evropa, Blízký východ a Afrika, Asie a pacifická oblast, Východní Evropa, Severní a Latinská Amerika. V současné době tvoří páteř obchodu Heidelbergu rostoucí trhy rozvojových zemí, které tvoří plných 45 % obratu firmy. Z hlediska geografického, je Heidelberg rozdělen do čtyř hlavních regionů NAM (státy severní a jiţní Ameriky), EMEA – West (země západní Evropy, Velká Británie a Skandinávie), EMEA-East (země Východní Evropy) a APA (Asie a země pacifické oblasti), jednotlivé regiony jsou dále členěny na regionální oblasti. Kaţdá pobočka společnosti (SSU) je rozdělena do několika oddělení podle nabízených produktů nebo sluţeb. Základní schéma členění většiny poboček je na obrázku 4-1. Obrázek 4-1: Členění prodejní jednotky (SSU)
Stroje a zařízení
Služby
Finance
Předtisková příprava (Prepress)
Servis
Finance a controlling
Spotřební materiály
Informační Technologie
Tiskové stroje (Press) Dokončujicí zpracování (Postpress)
Zdroj: autor
27
4.3 Struktura IT IT organizace ve společnosti prošla v posledních letech radikální obměnou. Ještě před několika lety byla postavena na modelu lokálního IT oddělení v kaţdé z poboček, které bylo zodpovědné za veškeré sluţby a vybavení v oblasti IT, od nákupu vlastního HW, instalace operačních systémů a aplikací, přes provozování vlastních serverů, zálohování dat, aţ po podporu uţivatelů. S nástupem ekonomické krize došlo k výraznému sníţení počtu zaměstnanců společnosti, které se nevyhnulo ani IT oddělení. V souvislosti se sniţováním počtu zaměstnanců došlo k zavádění konceptu globální IT organizace, kdy byly zavedeny globální či regionální týmy, zodpovědné za určitou oblast IT infrastruktury nebo aplikací s působností v celém regionu. Dále byl postupně zřízen helpdesk, jako přímá podpora uţivatelů s provozem 24x7, data centra pro provoz a správu serverů a zajištění síťových sluţeb nebo regionální aplikační centra. V souvislosti s tím se změnila i struktura IT organizace ve společnosti Heidelberg, jejíţ blokové schéma najdete na obrázku 4-2. Zavedením tohoto modelu došlo k efektivnějšímu vyuţívání a především zvýšení specializace jednotlivých zaměstnanců, kdy uţ není potřeba obsáhnout celé spektrum IT sluţeb, ale je moţné specializovat se pouze na určitou část a té se věnovat detailněji. Tento typ IT organizace bylo moţné zřídit hlavně díky standardizaci celé IT infrastruktury, především zavedením jednotných modelů pouţívaných klientských stanic a standardní konfigurace klientských systémů. Obrázek 4-2: Blokové schéma IT organizace
CIO
IT-I (Infrastruktura)
IT-PS
IT-C
IT-PA
(Servis, Prodej, Marketing)
(Architektura, Datacenter)
(Administrativa, Finance, HR)
IT-PP (Výroba)
Zdroj: autor
Za implementaci, správu a provoz CRM systémů ve společnosti Heidelberg je zodpovědná skupina IT-PS4. Jedná se o mezinárodní tým sloţený z 12 zaměstnanců. V týmu jsou 4 zástupci pro jednotlivé regiony (EMEA-West, EMEA-East, NAM, APA), dále 3 programátoři, pracovníci provádějící školení klíčových a koncových uţivatelů 28
a konzultanti. V rámci projektů spolupracuje IT-PS4 i s ostatními IT týmy, ať uţ z oblasti infrastruktury (správa serverů, zálohování, atd.) nebo z oblasti aplikační (integrace s ERP systémy, atd.).
29
5 Heidelberg CRM 5.1 Standardizace CRM Způsob řízení vztahů se zákazníky byl aţ do roku 2012 zcela v reţii jednotlivých lokálních poboček a obdobná situace byla i v oblasti systémů určených pro CRM. Ve společnosti Heidelberg bylo pouţíváno asi sedm různých CRM systémů. Nasazení jednotlivých systémů se lišilo dle regionů a velikosti poboček. Většinou se jednalo o produkty společností působících v daném regionu. V Severní Americe byl pouţíván systém Clarify, v oblasti Jiţní Ameriky bylo vyuţíváno CRM řešení Salesforce, v Asijských zemích to byl CRM systém Elite. Obdobná situace byla i v Evropě, kde v zemích západní Evropy byl pouţíván vlastní systém společnosti Heidelberg, ve Skandinávských zemích byl implementován systém Super Office a ve východní Evropě to byl Saleslogix společnosti Sage. Geografický přehled v minulosti pouţívaných CRM systémů je uveden na obrázku 5-1. Některé, především menší, pobočky nevyuţívaly CRM systémy vůbec a pro správu interakcí se zákazníky pouţívaly aplikace sady Microsoft Office (sdílený adresář v Outlooku, tabulky v Excelu, atd.). Obrázek 5-1: Mapa dříve pouţívaných CRM systémů
Zdroj: autor
Vzhledem k tomu, ţe neexistoval ţádný globální standard pro CRM systémy ani ţádné společné definice procesů pouţívaných při interakcích se zákazníky, byly tyto CRM systémy pouţívány v nejrůznějších uţivatelských úpravách a pokrývaly rozdílný rozsah 30
firemních procesů. Jakýkoli globální reporting nebo jednoduchý společný přehled o aktivitách v různých regionech byl jen těţko realizovatelný. Dalším slabým místem tohoto řešení byla i správa a údrţba těchto systémů. Na základě uvedených skutečností se vedení společnosti rozhodlo implementovat jednotný systém s vyuţitím globální CRM koncepce. V následujících dvou letech byl vybrán globální systém a tento byl postupně implementován ve všech zastoupeních společnosti.
5.1.1 Výběr CRM systému Při samotném výběru CRM systému, byly zohledňovány jak aktuálně pouţívané systémy (Sage Saleslogix, Salesforce, atd.), tak i produkty současných dodavatelů jiných SW produktů společnosti Heidelberg. Ve výběrovém řízení byla například oslovena i společnost SAP se systémem SAP CRM, jako současný dodavatel ERP řešení pro firmu Heidelberg. Konečné rozhodnutí o dodavateli systému CRM ve společnosti Heidelberg byl v reţii mateřské společnosti v Německu. Kromě obecných poţadavků na informační systém bylo přihlédnuto i ke zkušenostem a připomínkám současných uţivatelů doposud pouţívaných CRM systémů a to především obchodních zástupců, kteří tvoří klíčovou skupinu uţivatelů těchto systému. V případě, ţe by zvolený systém nebyl „uţivatelsky přívětivý“ pro koncové uţivatele, mohlo by to váţně zkomplikovat celý proces implementace CRM. Na
základě
zkušeností
těchto
uţivatelů,
byl
kromě
uţivatelské
přívětivosti
a jednoduchosti práce se systémem, zohledněn i poţadavek na moţnost práce offline v terénu (bez nutnosti připojení k síti), moţnost synchronizace kontaktů a schůzek mezi CRM systémem a aplikací Microsoft Outlook, která je standardní součástí SW vybavení všech klientských stanic. Dalším důleţitým poţadavkem byla moţnost synchronizace dat a přístup z mobilních zařízení, jako jsou tablety či chytré telefony. Právě tato moţnost synchronizace byla slabým místem většiny dosud pouţívaných CRM systémů, buď byla tato funkcionalita řešena pomocí produktů třetích stran, nebo nebyla k dispozici vůbec. To bylo způsobeno především tím, ţe současně pouţívané systémy byly implementovány před několika lety a nebyly pravidelně aktualizovány, jsou pouţívány v starších verzích, kde některé funkce, které jsou v současné době samozřejmostí, nebyly v těchto verzích dostupné.
31
5.1.2 Implementace systému Projekt implementace systému začínal vţdy úvodní schůzkou s vedením dané pobočky a klíčovými uţivateli budoucího systému. Cílem této schůzky je také představit a upřesnit časový plán implementace systému, definovat zodpovědné osoby v dané pobočce jak v oblasti IT, tak v oblasti obchodu a servisu, které budou dále k dispozici v průběhu procesu implementace a budou klíčovými partnery pro implementační tým. Následovala analýza dosud pouţívaného systému, jeho hlavních funkcí, které jsou aktivně pouţívané v konkrétní pobočce, dále analýza obchodních a servisních procesů a zdokumentování lokálních odlišností. Další pozornost je v této fázi věnována poţadovaným výstupům ze systému, jako jsou různé reporty, sestavy či formuláře. Po analýze současného stavu přecházíme k nastavení a uţivatelským úpravám systému. Pro zpřehlednění a kontrolu provedení všech nastavení je vytvořen seznam všech kroků, s uvedením jejich popisu a osoby zodpovědné za provedení daného nastavení. Všechny kroky procesu nastavení systému jsou zaznamenány v tomto kontrolním seznamu. Součástí nastavení systému je i import uţivatelů a nastavení jejich přístupových práv, vytvoření a úpravy všech standardních workflow nebo například úpravy a tvorba uţivatelských reportů a sestav. Dalším nezbytným krokem implementace je i import historických dat z dosud pouţívaných systémů. Během přípravy jsou vytvořeny všechny datové mapy, kde je definováno propojení jednotlivých polí mezi původním a novým CRM systémem. Zároveň jsou upraveny a nadefinovány formáty dat, hodnoty rozbalovacích seznamů, atp. Tento vzorek dat je následně importován do testovacího systému, kde je provedena kontrola importu a zdokumentovány a opraveny případné chyby. Následně je proveden export všech dat určených k převodu, tato data jsou předána odpovědným osobám k finálním úpravám, doplnění chybějících informací a poté jsou, za pouţití vytvořených datových map, importována do nového CRM systému. Po importu dat a proškolení uţivatelů je původní systém odpojen, odinstalován a záloha jeho databáze je archivována. Závěrečná fáze implementace CRM systému zahrnuje školení uţivatelů, klíčových uţivatelů a jejich následnou podporu. Samotné školení bylo rozděleno do dvou fází, v první proběhlo detailní školení tzv. klíčových uţivatelů (zástupců jednotlivých
32
poboček), kteří se následně sami podíleli na školení koncových uţivatelů. Školení koncových uţivatelů probíhalo v jednotlivých pobočkách společnosti a kromě funkcionality a ovládání systému bylo zaměřeno především na zpracování firemních procesů pomocí Microsoft CRM. Všechna školení uţivatelů jsou prováděna interaktivně v testovacím prostředí a za aktivní účasti uţivatelů. Školení je rozděleno do několika bloků a na konci kaţdého z nich je uţivatelům zadán praktický úkol pro ověření jejich znalostí. V této první fázi je systém uţivatelům předveden z pohledu funkčních prvků a jednotlivých modulů. Dále je systém demonstrován z pohledu procesního včetně tzv. typických příkladů pouţití. Zde jsou názorně předvedeny běţné postupy práce se systémem pro jednotlivé skupiny uţivatelů, například práce obchodního zástupce obsahující proces od naplánování schůzky u zákazníka, zapsání záznamu z jednání, jeho distribuci, popřípadě vytvoření obchodní příleţitosti. Na závěr je zaznamenána zpětná vazba od uţivatelů. Poslední fází je předání systému do ostrého provozu společně s předáním uţivatelů oddělení podpory uţivatelů, které zajišťuje následnou péči o ně. Následná podpora zahrnuje pravidelné zasílání novinek a pořádání telefonních konferencí pro klíčové uţivatele, kde jsou informování o připravovaných úpravách, rozšířeních systému a dalších aktivitách v oblasti CRM. Celý projekt implementace systému Microsoft Dynamics CRM byl realizován interním týmem deseti specialistů ze sedmi zemí světa pod vedením jednoho manaţera projektu. Systém byl zaváděn postupně v jednotlivých pobočkách společnosti souběţně v několika regionech (Amerika, Evropa, Asie). Během 18 měsíců byl systém zaveden v 11 pobočkách v regionu východní Evropy.
33
5.2 Architektura SW V následující kapitole si přiblíţíme celkovou koncepci návrhu CRM systému, výčet a uspořádání jednotlivých modulů. Dále se podíváme, jaká je provázanost systému s podporou podnikových procesů a podporou řízení společnosti.
5.2.1 Celková koncepce návrhu SW, výčet a uspořádání modulů Schéma jednotlivých částí Microsoft Dynamics CRM po uţivatelských úpravách pro společnost Heidelberg je znázorněno na obrázku 5-2. Obrázek 5-2 :Přehled částí Heidelberg CRM po úpravách systému
Service Time
contacts products
JobSheets
activities
Change request
campaign Account
Consumabl e Supplies
opportunity
Installed Base
cases Sales specialist
Contact report
Marketing List
Zdroj: autor
Jádro kaţdého CRM systému tvoří modul evidence zákazníků („Accounts“). Zeleně označené části jsou standardně nabízené moduly systému MS CRM, které byly více či méně upraveny a přizpůsobeny potřebám společnosti Heidelberg. Mezi tyto moduly patří správa kontaktů („Contacts“), aktivit („Activities“), přehled produktů („Products“), kompletní sada nástrojů pro řízení marketingových aktivit a kampaní („Campaign“ a „Marketing list“), přehled a správa obchodních příleţitostí („Opportunities“) nebo správa reklamací a servisních zásahů („Cases“). Uţivatelsky vytvořené moduly, které pokrývají specifickou část obchodních a servisních procesů společnosti Heidelberg, jsou na schématu označeny modře. 34
Seznam uţivatelsky vytvořených modulů: Contact Report – slouţí primárně obchodním zástupcům pro dokumentaci kontaktů se zákazníkem a správě záznamů z jednání. Sales Specialist – přiřazení obchodních zástupců pro jednotlivé divize k zákazníkům a jejich správa. Tyto informace jsou synchronizovány ze systému ERP. Installed Base – (instalované stroje a zařízení) – v tomto modulu jsou evidovány veškeré stroje a zařízení, které jsou nainstalované u zákazníků. Consumables Supplies – modul určený primárně pro obchodní zástupce oddělení spotřebních materiálů, slouţí k evidenci informací o typu, mnoţství a portfoliu spotřebních materiálů kaţdého zákazníka. Jobsheet, ServiceTime - tyto moduly tvoří společně s upraveným vestavěným modulem Cases základ servisní části CRM. Jsou zde evidovány veškeré instalace, servisní zásahy a reklamace. Moduly umoţňují správu pracovních výkazů techniků, evidenci pracovní doby a servisních úkonů.
5.2.2 Podpora podnikových procesů a oblastí Díky poměrně rozsáhlým zákaznickým úpravám systému bylo z jednotlivých modulů vytvořeno ucelené řešení pokrývající většinu firemních procesů v oblasti prodeje a servisu. CRM pomáhá obchodním zástupcům při plánování kontaktů se zákazníky, pracovníkům marketingu při segmentaci zákazníků a jejich cíleném oslovování s obchodními nabídkami či pozvánkami na firemní akce. Managementu poskytuje přehled o potenciálních obchodních příleţitostech a stavu rozpracovaných obchodních případů. V oblasti servisních sluţeb podporuje jak kaţdodenní operativní kontakt se zákazníky při řešení servisních zásahů, tak analýzu servisních úkonů pro servisní management. Uţivatelským úpravám a vyuţití CRM systému v oblasti servisních sluţeb se blíţe věnuje kapitola 6 této práce. Heidelberg CRM je propojen se systémy ERP pouţívanými ve společnosti Heidelberg. Tato integrace je zaloţena především na synchronizaci databáze zákazníků, údajů o platební morálce jednotlivých zákazníků, informacích o instalovaných strojích a zařízeních a údajích o servisních zásazích. Společně tak integrace těchto systémů doplněná o nástroje BI pro potřeby managementu tvoří ucelený systém pokrývající všechny podnikové procesy. 35
5.2.3 Podpora řízení Systém Heidelberg CRM je pouţíván na úrovni operativního řízení, registruje kaţdodenní kontakt se zákazníky, jak v oblasti prodeje, tak i servisu. Zároveň je systém pouţíván vedením jednotlivých místních poboček společnosti Heidelberg, především k analýze a přehledu o vývoji obchodních případů, atp. Ve spojení s aplikacemi BI a reportingovými nástroji je taktéţ pouţíván regionálním managementem společnosti.
5.2.4 Otevřenost architektury Microsoft Dynamics CRM je ve firmě Heidelberg propojen se stávajícími ERP systémy (SAP a iScala) a poskytuje tak komplexní řešení pro podporu všech podnikových procesů. Díky otevřenosti systému a moţnosti uţivatelských úprav, lze systém do budoucna neustále rozšiřovat o případnou novou funkcionalitu. V současné době slouţí databáze systému CRM společně s databází ERP systému jako hlavní zdroj dat pro nástroje BI.
5.2.5 Podpora správy a monitoring provozu Pro optimalizaci výkonu a případné rozšiřování systému, ale i pro zajištění spolehlivosti systému je důleţité sledovat statistiky vyuţívání jednotlivých funkcí a modulů systému. K tomuto účelu pouţívá společnost Heidelberg reportingové aplikace QlikView, které na základě dat získaných za systémové databáze CRM poskytuje přehledné statistiky o vyuţívání jednotlivých funkcí CRM systému koncovými uţivateli.
5.3 Specifikace provozního prostředí 5.3.1 Specifikace HW, OS serverů a pracovních stanic, LAN/WAN Z hlediska vývoje, úprav a testování systému i školení uţivatelů je důleţité mít k dispozici simulované prostředí, kde je moţné nově vyvinuté funkce otestovat nebo umoţnit uţivatelům vyzkoušet nové funkce systému. Z tohoto důvodu není moţné vystačit pouze s jedinou instalací CRM systému a je nutné mít k dispozici několik na sobě nezávislých instalací. Implementace MS CRM ve společnosti Heidelberg pokrývá celkem čtyři instance (izolované instalace) systému: Sandbox (SBX) – prostředí pouze s ukázkovými daty, slouţí primárně vývojářům při vývoji a odladění jednotlivých částí.
36
Development (DEV) – prostředí pro vývoj uţivatelských úprav systému. Slouţí programátorům ke skutečnému vývoji aplikace, obsahuje vzorová data. Staging (STG) – testovací prostředí, obsahuje většinu dat z produkčního prostředí a slouţí k testování nových funkcionalit a úprav systému před jejich uvolněním do produkčního systému. Production (PRO) – produkční prostředí s ostrými daty. Po otestování funkcionality provedených uţivatelských změn v systému STG jsou tyto změny importovány do produkčního prostředí. Z hlediska architektury systému jsou jednotlivé instance instalovány na samostatných serverech, které jsou rozděleny dle příslušných rolí. Veškeré součásti systémů SBX a DEV jsou instalovány na jednom fyzickém serveru pro kaţdý systém. Toto neplatí pro systémy STG a PRO, kde vzhledem k počtu uţivatelů (několik tisíc) a nepřetrţitému vytíţení systému (vyuţívání ve všech časových pásmech) je nutné rozloţit zátěţ do několika serverů. Pro systém STG je instalován samostatný “platform server“, databázový server, dva aplikační servery a „load balancer“ pro rozdělení zátěţe mezi tyto aplikační servery. Stejný model je pouţitý i pro instalaci produkčního prostředí. Jako klientských stanic vyuţívá společnost Heidelberg desktopů, notebooků a ultrabooků společnosti Dell s vlastním jednotným SW balíčkem zaloţeným na OS Microsoft Windows 7 x64. Z hlediska síťové infrastruktury má Heidelberg celosvětově tři přípojná místa (huby) v jednotlivých kontinentech (Amerika, Evropa, Asie). Jednotlivé pobočky jsou pak prostřednictvím VPN připojeny vţdy k příslušnému hubu.
5.3.2 Specifikace DB systému Systém Microsoft Dynamics CRM implementovaný ve společnosti Heidelberg je provozován na databázové platformě Microsoft SQL Server 2008. Pro produkční a testovací instanci je jako databázový server pouţit dedikovaný server. Pro vývojovou (development) instanci je pouţit společný HW pro databázový i aplikační server.
5.3.3 Zajištění provozu systému, vč. bezpečnosti Všechny servery, na kterých je systém Microsoft Dynamics CRM ve společnosti Heidelberg provozován, jsou fyzicky umístěny v globálním datovém centru v centrále
37
společnosti, kde jsou nepřetrţitě monitorovány. Na provoz serverů dohlíţí oddělení IT infrastruktury a zabezpečení CRM serverů, tak jako všech ostatních serverů zajišťuje specializované oddělení pro bezpečnost IT. Detaily zabezpečení nejsou veřejnou informací.
5.4 Uţivatelské úpravy Dále si stručně popíšeme uţivatelské úpravy (customizace) systému, které byly provedeny za účelem přizpůsobení systému business procesům v oblasti obchodu a servisu. Závěr této kapitoly je věnován integraci systému CRM se systémy ERP.
5.4.1 Prodej Uţivatelské úpravy CRM systému v oblasti prodeje zahrnují i nástroj pro kompletní prodejní proces, počínaje záznamem z jednání přes obchodní příleţitosti aţ k objednávce. Modul „Contact Reports“ je kompletně uţivatelsky vytvořený modul pro správu aktivit obchodních zástupců a zpracování a distribuci záznamu z jednání. Tyto záznamy jsou pravidelně sestavovány obchodními zástupci na základě jejich naplánovaných aktivit pro kaţdý významný kontakt se zákazníkem. Strukturovaně se zde uvede obsah jednání a zejména všechny důleţité informace pro ostatní oddělení (např. servis, spotřební materiál). Hotové zprávy jsou potom za pomocí workflow, na základě daných pravidel, automaticky distribuovány ostatním zaměstnancům (více o workflow v kapitole 5.4.3). V případě, ţe zákazník na základě jednání projeví zájem o některý z produktů či sluţeb, lze na základě záznamu v modulu „Contact Reports“ vytvořit novou obchodní příleţitost („Opportunity“). V modulu obchodních příleţitostí jsou specifikovány údaje o nabízeném stroji či zařízení, konfiguraci stroje, předpokládané ceně, předpokládanému datu instalace, konkurenci, pravděpodobnosti atd. Data z modulu obchodních příleţitostí slouţí mimo jiné i jako podklad pro plánování prodejů. V případě, ţe dojde k objednání zařízení, je záznam v modulu obchodních příleţitostí uzavřen jako „vítězný“ a na základě těchto údajů je automaticky zaloţen záznam v modulu objednávek („Orders“). Zde je obchodní případ doplněn o další údaje o financování, dodatečných nákladech, servisu, atd. Okamţikem dodání zařízení je záznam v modulu objednávek uzavřen a tento obchodní případ přechází do modulu servisních sluţeb, kde je zdokumentována instalace zařízení a následný servis.
38
Další uţitečnou vlastností vyuţitelnou právě v nadnárodních společnostech je moţnost sdruţování zákazníků do skupin s vyuţitím hierarchie. Pro nadnárodní zákazníky působící ve více zemích světa je moţno vytvořit jeden společný záznam - „Parent Account“ a všechny jeho pobočky se propojí k tomuto záznamu jako jeho podřízené záznamy - „Sub-Accounts“. Výhodou u takto propojených záznamů je především moţnost sledování jednotlivých aktivit za celou skupinu, coţ je vhodné zejména z pohledu regionálního managementu. Segmentace zákazníků je jednou z klíčových vlastností CRM systému. Při uţivatelských úpravách systému ve společnosti Heidelberg byly zvoleny dvě, na sobě nezávislé, úrovně segmentace zákazníků. První - globální (kalkulovaná) segmentace vychází z „tvrdých dat“ získaných z ERP a CRM systémů, jako jsou obrat, počet zaměstnanců, portfolio instalovaných strojů, atd. Na základě těchto dat je automaticky vyhodnocena kategorie pro kaţdého zákazníka a takto získané kategorie zákazníků jsou zohledňovány v globálních reportech. Kromě kalkulované segmentace zákazníků je dále vyuţívána i segmentace na lokální úrovni, která je zákazníkům přiřazena ručně na základě pravidel platných v dané pobočce.
5.4.2 Servis Oblast podpory a sluţeb zákazníkům je v systému Heidelberg CRM zaloţena na modulu servisních případů a plánování servisních aktivit, doplněna o uţivatelsky vytvořené moduly pracovních listů servisních techniků a evidence servisního času. Servisní modul tvoří významnou část systému a doplňuje obchodní informace o kompletní evidenci instalací, reklamací a servisních zásahů na zákaznických zařízeních. Tyto informace mohou být klíčové například při jednáních obchodních zástupců o dodávkách nových zařízení, spotřebních materiálů nebo při aktivním prodejí originálních náhradních dílů nebo servisních smluv. Podrobněji o vyuţití Heidelberg CRM v kapitole 6 této práce.
5.4.3 Workflow Workflow je ucelená sada činností, která je prováděna na základě specifikovaných podmínek. V CRM systému slouţí k automatizaci některých opakujících se procesů. Ve společnosti Heidelberg se tato workflow pouţívají především pro různé automatické emailové notifikace, automatické vytváření záznamů, změny stavů, atp. Mezi workflow pro automatické emailové notifikace patří například rozesílání nově vytvořených záznamů
39
z jednání obchodních zástupců na základě předem definovaných distribučních seznamů a pravidel nebo zasílání e-mailových avíz při vytvoření nových záznamů v modulech obchodních příleţitostí, servisních objednávek, atp. Další moţnosti vyuţití workflow se nabízí všude tam, kde je potřeba na základě změny určitých dat v systému vyvolat nějakou akci. Příkladem můţe být situace, kdy v případě prohrané obchodní příleţitosti je automaticky přidáno konkurenční zařízení do modulu instalovaných strojů nebo v případě „vítězné“ obchodní příleţitosti je automaticky zaloţen příslušný záznam v modulu objednávek. Všechna workflow v systému jednak automatizují procesy, a tím zvyšují efektivitu zaměstnanců, dále díky e-mailovým notifikacím zlepšují informovanost a komunikaci mezi jednotlivými zaměstnanci.
5.4.4 Integrace s ostatními aplikacemi Důleţitým bodem implementace CRM systému je integrace s ostatními informačními systémy podniku a především se systémem ERP. V případě, ţe uţivatelé budou nuceni vkládat stejná data do více systémů, povede tato situace jednak k tomu, ţe data v jednotlivých systémech nebudou aktuální a konzistentní, ale také ke značné neefektivitě zaměstnanců. Ve společnosti Heidelberg je CRM systém integrován s ERP systémy SAP a iScala. Následné ukládání dat členěných dle jednotlivých dimenzí do datových skladů pro následné vyuţití pro generování komplexních reportů je zajištěno aplikací QlikView. Řídicím systémem pro správu aktivních zákazníků je v tomto případě ERP systém. Veškeré změny v klíčových údajích o zákaznících jako je název firmy, adresa, atd. nebo zaloţení nových zákazníků v systému ERP jsou okamţitě synchronizovány do CRM. Jelikoţ primárním správcem údajů o zákaznících je obchodní zástupce, který typicky není uţivatelem ERP systému, je pro účely aktualizace a správy údajů o zákaznících v CRM zřízen modul pro správu poţadavků na změnu nazvaný „Change Request“. V případě, ţe obchodní zástupce poţaduje změnu základních údajů o zákazníkovi, zaloţí v tomto modulu svůj poţadavek, tento poţadavek je následně automaticky předán pracovníkům Back-office, kde je změna v ERP systému provedena a automaticky aplikována do CRM. Poté je poţadavek na změnu uzavřen a ţadateli je automaticky zasláno oznámení o jeho zpracování a uzavření. Další oblastí, kde je vyuţíváno propojení CRM systému s ERP, je oblast instalovaných strojů. Veškeré údaje o instalovaných strojích a zařízeních, prodané firmou Heidelberg, 40
jsou na základě dat z ERP systému (zákazník, místo instalace, datum instalace, sériové číslo, atd.) automaticky odeslány do CRM, kde jsou evidovány v modulu Instalovaných strojů („Installed Base“). Pro kaţdou vytvořenou obchodní příleţitost je obchodním zástupcem vţdy specifikováno i konkurenční zařízení, vstupující do výběrového řízení, v případě, ţe je tento obchodní případ uzavřen jako „prohraný“, je aktivován automatický proces, který vytvoří záznam v modulu instalovaných zařízení pro toto konkurenční zařízení. Integrace s ERP systémem je vyuţíváno i v oblasti servisního modulu. Kaţdá přijatá servisní zakázka je zaevidována v systému, kde je sledován její průběh, plánovány aktivity servisních techniků a evidovány veškeré úkony provedené na této zakázce. Po schválení příslušným vedoucím oddělení jsou tyto údaje automaticky předány do ERP systému, kde je vytvořena servisní zakázka a faktura, která je následně společně se servisními listy techniků odeslána ve formátu PDF zákazníkovi. Právě moţnost zpracovávat veškeré pracovní listy servisních techniků on-line a předávat tyto informace okamţitě do ERP systému, výrazně zkracuje dobu od ukončení servisního zásahu do vystavení faktury zákazníkovi. Tímto se nejen zlepšuje komunikace mezi společností a zákazníkem, ale hlavně dochází k minimalizaci prodlevy mezi dokončením servisního zásahu a přijetím platby za servisní sluţby od zákazníka. Pro správu dokumentů v systému CRM je vyuţíváno integrace se „Sharepoint“ serverem. Pro kaţdého zákazníka v CRM systému je automaticky zřízena sloţka na „Sharepoint“ serveru, kde jsou následně spravovány veškeré dokumenty související s tímto zákazníkem, ať uţ se jedná o nabídky, pozvánky, smlouvy nebo jiné dokumenty. Výhodou integrace je především to, ţe uţivatelé pracují stále v prostředí CRM systému a mohou vyuţívat dobře známého prostředí klienta pro Outlook.
5.5 Reporty Velmi důleţitou kapitolu v implementaci CRM systému tvoří reporty. Pouze v případě, ţe systém poskytuje uţivatelům, ať uţ manaţerům, obchodním zástupcům nebo pracovníkům marketingu, dokonalou zpětnou vazbu, budou tito uţivatelé motivování k pravidelné a pečlivé práci se systémem. Reporty zaloţené na datech ze CRM hrají klíčovou roli při rozhodování manaţerů. Především v prostřední nadnárodní společnosti je důleţité poskytnout manaţerům nejen analýzy lokálního trhu, ale i analýzy celého regionu nebo celé společnosti.
Právě tyto globální reporty mohou být poměrně jednoduše 41
vytvořeny díky pouţití společných uţivatelských úprav a globálního standardu pouţitého ve všech pobočkách (SSU). Ve společnosti Heidelberg je vyuţíváno dvou různých technologií pro vytváření reportů zaloţených na datech ze CRM systému.
5.5.1 MS CRM reporty Jedná se o reporty vytvořené pomocí SQL reporting services, tyto reporty jsou součástí CRM systému, mezi hlavní výhody těchto reportů patří především jejich uţivatelské přívětivost, dále dostupnost reportů „offline“ a moţnost navrţení vzhledu pro tisk nebo export do PDF. Tyto reporty naopak nejsou vhodné pro hlubší analýzy a modelování na základě měnících se parametrů. Reporty integrované přímo do CRM systému jsou ve společnosti Heidelberg vyuţívány především jako výstup pracovních listů servisních techniků nebo rychlý přehled o zákazníkovi a jeho přidruţených aktivitách, jako příprava pro obchodní zástupce.
5.5.2 Qlikview reporty Další technologií vyuţívanou pro analýzy a reporty je vyuţití systému Qlikview společnosti Qliktech. Jedná se o robustní nástroj pro analýzu dat z libovolných zdrojů. Ve společnosti Heidelberg je této technologie vyuţíváno pro veškeré reporty ze všech datových zdrojů, ať uţ je to CRM, ERP systém nebo speciální systémy pro HR, atp. Obrázek 5-3: Ukázka přehledu obchodních příleţitostí z reportu CRMquick
Zdroj: Qlikview reporting system Heidelberg
42
Veškeré takto vytvořené reporty jsou potom publikovány na firemním intranetu a jednoduše dostupné vybraným uţivatelům prostřednictvím webového rozhraní a instalovaného modulu plug-in pro Internet Explorer, který je součástí systému „Heidelberg client“. Systém Qlikview je vhodný všude tam, kde je potřeba s daty aktivně pracovat, vybírat na základě vstupních parametrů a okamţitě sledovat změny výstupu. Další výhodou tohoto systému je také moţnost analyzovat data z různých systémů (CRM, ERP) v jednom reportu. Tato technologie není vhodná pro pouţití offline a pro reporty určené k tisku. Ukázka reportu obchodních příleţitostí vytvořeného v prostředí Qlikview je na obrázku 5-3.
5.6 Podpora systému a změnové řízení Během provozu systému dochází také k jeho pravidelné údrţbě, opravám a vylepšení. Veškeré poţadavky na změny nebo zavedení nové funkcionality do systému jsou průběţně zaevidovány v centrálním systému správy poţadavků a řešení problémů (Servicedesk). Jednotlivé poţadavky jsou v prvním kroku posouzeny a případně schváleny jako oprávněné klíčovými uţivateli. Všechny takto předem schválené poţadavky jsou posouzeny globálním CRM týmem sloţeným jak ze zástupců IT, tak i zástupců obchodu a marketingu. Všem schváleným poţadavkům je dále přiřazena příslušná priorita a jsou předány oddělení IT k realizaci. Obrázek 5-4: Proces realizace poţadavků na změnu
Zdroj: autor
43
Veškerý vývoj a zakázkové úpravy systému probíhají výhradně ve vývojovém prostředí. Jednotlivé realizované změny nejsou do produkčního systému aplikovány postupně, ale sdruţené do jednotlivých vydání (release). Tato vydání jsou plánována pravidelně několikrát ročně a v případě nutnosti jsou zařazena i mimořádně. Proces realizace poţadavku je znázorněn na obrázku 5-4. Testování v DEV: Členové globálního CRM teamu provedou první kontrolu realizace ještě ve vývojovém prostředí (DEV). V případě nedostatků či chyb upozorní vývojáře. Nastavení: Během tohoto období vývojáři odstraní případné chyby a připomínky po prvním testování ve vývojovém prostředí (DEV) Uvolnění do STG: Přenesení všech provedených úprav z vývojového prostředí (DEV) do testovacího prostředí (STG) Testování v STG: Kontrola a testování úprav v testovacím prostředí (STG) zadavatelem poţadavku. V případě, ţe provedená změna nebo úprava neodpovídá poţadavkům, zadavatel změnu nepotvrdí a vrátí zpět k dopracování s komentářem. V případě, ţe provedená změna odpovídá poţadavku, autor změnu akceptuje. Finální doladění: Všechny připomínky na základě testování v testovacím prostředí jsou zpracovány a chyby odstraněny. Tvorba dokumentace: Veškeré změny provedené v systému, v souvislosti s realizací poţadavku, jsou zpracovány ve vlastní dokumentaci a v případě, ţe došlo ke změně v souvislosti s realizací poţadavku, je současně aktualizována všechna existující dokumentace. Veškerá dokumentace je zpracovávána v anglickém jazyce. Telekonference pro klíčové uţivatele: Globální CRM team organizuje telekonferenci pro klíčové uţivatele ze všech poboček. Během této telekonference jsou prezentovány změny systému v souvislosti s uvolněním nového vydání do produkčního systému a diskutovány případné dotazy klíčových uţivatelů. Následně je všem distribuována příslušná dokumentace. Překlad dokumentace a školení koncových uţivatelů: V případě potřeby zařídí klíčoví uţivatelé jednotlivých SSU překlad dokumentace a provedou školení koncových uţivatelů v souvislosti s provedenými změnami.
44
Uvolnění do ostrého provozu: Převedení všech úprav provedených v souvislosti se zpracování poţadavku z testovacího (STG) prostředí do ostrého provozu (PRO).
5.7 Efekty zavedení CRM V následujících sedmi pod-kapitolách jsou popsány efekty zavedení systému Microsoft Dynamics CRM ve firmě Heidelberg. Jednotlivé efekty jsou zde rozděleny dle jednotlivých oblastí vlivu. S ohledem na obor podnikání můţe být vliv v jednotlivých oblastech různý.
5.7.1 Finanční výnosy Přímé finanční výnosy v souvislosti se zavedením systému pozorovat nelze. Finanční výnosy lze pozorovat především v případě IT společností, kde dochází k přímému prodeji SW nebo HW.
5.7.2 Ekonomické efekty I kdyţ ještě nelze s ohledem na nedávné ukončení projektu implementace ekonomické efekty přesně vyčíslit (např. v podobě nárůstu objemu prodeje, atd.), lze pozorovat druhotné pozitivní ekonomické efekty. Především v oblasti prodeje náhradních dílů a příslušenství lze pozorovat nesrovnatelně větší efektivitu přímého prodeje, která ve svém důsledku vede k navýšení obratu firmy.
5.7.3 Zákaznické či trţní efekty Oblast zákaznických a trţních efektů je oblastí, kde lze pozorovat největší pozitivní vliv zavedení CRM systému. Tato oblast je pro systém typu CRM typická. Moţnost okamţité informace o zákaznících a především moţnost jejich segmentace nebo znalosti báze instalovaných strojů většiny zákazníků, umoţňuje provádět selektivní marketingové kampaně s mnohem větším zásahem na cílovou skupinu. Další oblastí kde dochází k výraznému zlepšení informovanosti, příkladem je oblast sledování obchodního případu, analýza konkurence atp.
5.7.4 Personální efekty V personální oblasti zatím nelze pozorovat výrazný efekt a to především díky tomu, ţe případná zvýšená produktivita práce, je kompenzována počáteční neochotou uţivatelů
45
pracovat se systémem pravidelně a zadávat potřebná data do systému a současně ne ještě zcela zaţitými pracovními postupy v souvislosti se zavedením systému.
5.7.5 Zvýšení procesní výkonnosti Společně se zavedením systému Microsoft Dynamics CRM ve společnosti Heidelberg došlo také k revizi dosavadních procesů v oblasti předprodejní fáze, prodeje i servisu. Tato revize společně s případnými změnami dosavadních procesů s cílem
jejich
zefektivnění byla definována jiţ před samotným nasazením systému jako jeden z dílčích cílů. Jedním z viditelných efektů v této oblasti je např. standardizace procesu „Lead2Order“, který zajišťuje firemní postup od získání potenciálního zákazníka aţ po jeho objednávku zařízení či sluţeb. Jednotlivé kroky tohoto procesu jsou po zavedení CRM systému jednotné ve všech pobočkách společnosti.
5.7.6 Zvýšení analytické výkonnosti a kvality řízení podniku Dalším z cílů definovaných ještě před zavedením systému bylo i zlepšení v oblasti analýzy zákaznických dat na úrovni regionu i globálního managementu. Zavedením jednotného CRM systému ve všech pobočkách společnosti došlo i ke standardizaci BI aplikací. Příkladem můţe být zlepšení plánování výroby na základě zpřesnění evidence potencionálních objednávek zákazníků. Další oblastí, kde lze pozorovat výrazné zlepšení je segmentace zákazníků. Díky precizní segmentaci zákazníků v jednotlivých pobočkách, je moţné lépe analyzovat např. trţní podíl v celém regionu.
5.7.7 Skutečné efekty podnikové informatiky Jak jiţ bylo uvedeno, byl projekt zavedení CRM systému ve společnosti Heidelberg globálním projektem řízeným mateřskou společností. Z tohoto důvodu mi veškeré očekávané efekty zavedení tohoto systému, definované vrcholovým managementem společnosti, ještě před jeho zahájením nejsou známy. Některá očekávání lokálních poboček, jako například zkvalitnění dostupných informací o zákaznících, zvýšení efektivity marketingových kampaní, díky moţnosti cíleného oslovení zákazníků, revize a zkvalitnění firemních procesů nebo zkvalitnění poprodejní péče o zákazníka v oblasti servisních sluţeb, se více či méně podařilo naplnit. Z hlediska třídění jednotlivých efektů zavedení tohoto systému je nejvýraznější oblast zákaznických či trţních efektů společně se zvýšením procesní výkonnosti. Na hodnocení přínosu v oblasti personální je vzhledem k tomu, ţe od nasazení systému uběhla poměrně krátká doba a uţivatelé nejsou dosud se 46
systémem zcela sţiti, příliš brzo. Na druhou stranu je však potřeba poukázat i na některé slabé stránky v souvislosti se zavedením systému. Jednou z nejvýznamnějších překáţek při zavádění systému byla neochota uţivatelů, především obchodních zástupců, přijmout fakt, ţe jimi shromáţděná data o zákaznících jsou vlastnictvím společnosti a ne jejich osobním vlastnictvím a je tedy potřeba data poskytnout i ostatním zaměstnancům firmy prostřednictvím CRM systému.
47
6 CRM a servisní sluţby 6.1 Heidelberg servis Jak bylo popsáno v předchozích kapitolách této práce, je oblast prodejních aktivit ve společnosti Heidelberg po zavedení jednotného CRM systému jiţ plně standardizována. Jiná situace je v oblasti zákaznické podpory a servisních sluţeb. Regiony vyuţívající jako ERP systém SAP vyuţívají servisní modul tohoto systému ve spojení s vlastní aplikaci pro mobilní zařízení, která je vyuţívána servisními techniky v terénu. Pobočky regionu východní Evropy, které vyuţívají systému iScala, dosud pouţívaly různé aplikace pro podporu servisních sluţeb, od vlastních aplikací, přes původní CRM systémy aţ po jednoduché tabulky v aplikaci MS Excel. V souvislosti s tím bylo v období standardizace CRM rozhodnuto o sjednocení sytému pro podporu servisních sluţeb v regionu východní Evropy a vyuţití systému MS CRM. V následujících kapitolách je popsáno vyuţití a uţivatelské úpravy servisní části CRM systému ve společnosti Heidelberg.
6.2 Business procesy v oblasti zákaznického servisu Základním procesem pokrývajícím oblast servisních sluţeb a zákaznického servisu ve společnosti je proces „Call2Fix“, pokrývající oblast firemních aktivit od okamţiku kdy zákazník kontaktuje servisní oddělení, po okamţik vyřízení a uzavření poţadavku zákazníka. Schéma procesu Call2Fix je na obrázku 6-1. Obrázek 6-1: Schéma procesu Call2Fix
Call Intake
Time and Expense Management
Technical Clarification
Resource Management
On-Site Intervention
Financial Closure / Technical Debriefing
Zdroj: autor
Funkcionalita modulu pro servisní sluţby je navrţena na základě dílčích procesů, aktivit a jednotlivých kroků tohoto procesu. 48
Call Intake V úvodní fázi je přijat zákaznický poţadavek a následně je zaevidován v systému. Poţadavek zákazníka je přijat pracovníkem servisního dispečinku a můţe pocházet z různých zdrojů, jako je telefonní hovor, e-mailová zpráva, fax nebo on-line poţadavek zadaný prostřednictvím webových stránek. Při zaloţení poţadavku je identifikován zákazník, kontaktní osoba, zařízení, kterého se poţadavek týká a obsah poţadavku. Po zaevidování je zákazníkovi zasláno e-mailem potvrzení přijetí poţadavku s jeho identifikátorem pro pozdější ověření stavu. Průběţně můţe zákazník sledovat stav svého poţadavku on-line na webových stránkách, e-mailovým dotazem nebo telefonicky na servisním dispečinku. Technical Clarification Po úvodním zaregistrování zákaznického poţadavku pracovníky servisního dispečinku dojde k jeho technickému posouzení přijímacími techniky a klasifikaci. Klasifikace poţadavku je rozhodující pro jeho další zpracování. Zde se můţe jednat o objednávku náhradních dílů, technickou podporu po telefonu, vzdálenou podporu (Remote Service), výjezd servisního technika, plánovanou instalaci nebo deinstalaci, atd. Současně s klasifikací je poţadavku přiřazena i příslušná priorita. Resource Management V okamţiku, kdy je zákaznický poţadavek klasifikován a je mu přiřazena příslušná priorita, dochází k přiřazení konkrétního servisního technika (techniků), který bude zodpovědný za řešení poţadavku. Přiřazení probíhá jednak na základě volných kapacit jednotlivých techniků a zároveň s ohledem na jejich specializaci. Při plánování zdrojů pomáhá i grafické zobrazení servisního kalendáře. Tyto servisní aktivity jsou technikům odeslány a automaticky synchronizovány jako události do jejich osobních kalendářů v Microsoft Exchange a dále do mobilních telefonů. On-Site Intervention V případě potřeby výjezdu technika k zákazníkovi je technik informován o termínu výjezdu a detailech zakázky. Po ukončení servisního zásahu servisním technikem je vytvořen servisní list, kde je uveden popis práce, pouţité náhradní díly a jednotlivé údaje o odpracovaném čase nebo ujeté vzdálenosti. Tento výkaz je zákazníkem na místě odsouhlasen a podepsán přímo v systému pomocí podpisového tabletu a následně odeslán zpět na servisní dispečink s kopií zákazníkovi. 49
Time and Expense Management Po úspěšném vyřešení jsou pracovníky servisního dispečinku vyhodnoceny všechny servisní listy techniků přiřazených k danému poţadavku. Dochází ke schvalování jednotlivých servisních výkonů vzhledem k jejich časové náročnosti, uvedení případných dalších vedlejších nákladů a předání zakázky k fakturaci. Financial Closer Po schválení jednotlivých servisních úkonů dochází k exportu dané zakázky z CRM systému do systému ERP, kde je následně pracovníky fakturačního oddělení vystavena faktura a zaslána zákazníkovi. V případě záručních oprav dochází pouze k zaúčtování příslušných nákladů. Technical Debriefing Po fakturaci je pracovníky servisního dispečinku zakázka v systému CRM uzavřena a zákazníkovi je zaslán přehled o řešení zakázky ve formátu PDF.
6.3 Vyuţití CRM pro servisní sluţby Oblast podpory a sluţeb zákazníkům je v systému Heidelberg CRM zaloţena na modulu servisních případů (Case) a plánování servisních aktivit (Service Activity, vyuţitých následně při grafickém zobrazení v Service Calendar), doplněna o uţivatelsky vytvořené moduly pracovních listů servisních techniků (Jobsheet) a evidence časových výkonů (Service time). Pro schválení a přenesení dat k následné fakturaci slouţí modul servisní objednávky (Service Order). Tyto čistě servisní moduly jsou doplněny o sdílené společné moduly zákazníků (Accounts), kontaktních osob (Contacts), instalovaných strojů (Installed Base) a servisních techniků. Kompletní přehled modulů servisní části CRM systému najdete na obrázku 6-2.
50
Obrázek 6-2:Schéma modulů servisní části
Zdroj: autor
6.3.1 Zakázka – Case Základním modulem servisní části CRM systému je modul servisních zakázek „Case“. Veškeré poţadavky zákazníka od plánovaných instalací strojů a zařízení, přes objednávky servisních zásahů, pravidelné servisní prohlídky, aţ po stíţnosti a reklamace jsou zaregistrovány v systému jako servisní zakázky. Tyto zakázky jsou zaloţeny pracovníky servisního dispečinku, následně jsou klasifikovány s ohledem na druh poţadavku a jeho prioritu. Modul servisních zakázek „Case“ vychází ze standardního modulu CRM systému, který byl drobně upraven pro potřeby společnosti Heidelberg, jedná se zejména o úpravy v oblasti spojení s ostatními entitami (Instalovaná báze, servisní listy a servisní objednávky) a úpravy vzhledu formuláře.
51
Po zaevidování zakázky v systému a její klasifikaci je zákazníkovi automaticky e-mailem odeslána informace o přijetí zakázky. Automatické e-mailové zprávy jsou ze systému odesílány pomocí workflow. Modul servisních zakázek neslouţí pouze k evidenci oprav a instalací strojů, ale slouţí i ke sledování ostatních poţadavků zákazníka, jako jsou reklamace, poţadavky na školení obsluhy nebo ţádosti o zpracování komplexních nabídek na servisní sluţby. Tyto zakázky jsou následně přiřazeny k dalšímu zpracování osobám zodpovědným za řešení dané oblasti.
6.3.2 Servisní aktivity – Kalendář Po zaloţení a klasifikaci servisní zakázky, jsou pracovníky servisního dispečinku přiřazeni konkrétní technici dle momentální dostupnosti a poţadované kvalifikace. Nespornou výhodou unifikovaného systému v celé organizaci je moţnost zobrazení dostupnosti servisních techniků i z ostatních zemí regionu. V případě, ţe v dané zemi není momentálně k dispozici technik poţadované odbornosti, lze vyuţít a přímo naplánovat servisní zakázku i pro technika z jiné země regionu. Pro plánování aktivit servisních techniků se vyuţívá standardní funkcionality modulů servisních aktivit a servisního kalendáře. Tyto moduly byly opět nepatrně upraveny a přizpůsobeny potřebám servisního oddělení společnosti. Jedná se zejména o rozšíření modulu servisních aktivit o adresu místa výkonu nebo uvedení informací o stroji. Servisní kalendář byl upraven o rozšíření barevného zobrazení jednotlivých aktivit dle typu (servis u zákazníka, vzdálená podpora, nepřítomnost, dovolená, atd.). Po přiřazení servisní aktivity k zakázce je kaţdému technikovi zasláno e-mailem oznámení kde najde veškeré potřebné informace o plánovaném zásahu (zákazník, adresa, kontaktní telefon, stroj nebo zařízení, popis závady, atd.). Zároveň je tato aktivita synchronizována s kalendářem daného servisního technika v MS Outlook a následně i s jeho chytrým telefonem. Všichni servisní technici mají přístup k servisnímu kalendáři prostřednictvím klienta CRM systému pro MS Outlook. Mohou tak sledovat všechny servisní zakázky přímo z prostředí MS Outlook. V případě, ţe je naplánovaná aktivita pracovníky servisního dispečinku změněna nebo zrušena, je technikovi opět odesláno oznámení. Ukázka obrazovky servisního kalendáře je na obrázku 6-3. .
52
Obrázek 6-3:Obrazovka servisního kalendáře pro plánování servisních techniků.
Zdroj: CRM systém společnosti Heidelberg
6.3.3 Servisní list Po naplánování a zaloţení servisní aktivity dochází k samotnému servisnímu zásahu. Kaţdý servisní technik zaloţí v systému svůj servisní list přiřazený k zakázce (Case). V seznamu přiřazených zakázek vyberou příslušnou zakázku a vloţí nový servisní list. V případě, ţe na jedné zakázce pracuje více servisních techniků, zaloţí kaţdý z techniků vlastní servisní list přiřazený k téţe zakázce. Po zaloţení servisního listu provede technik kontrolu daného stroje nebo zařízení, především zkontroluje stav počítadla kopií (v případě tiskového stroje) a tento zapíše do servisního listu. Počítadlo u tiskového stroje slouţí obdobně jako tachometr u auta, uvádí celkový počet výtisků od prvního spuštění stroje. Tento údaj je pro servisní oddělení důleţitý především s ohledem na následné plánování pravidelných servisních prohlídek či objednávání náhradních dílů. V servisním listu dále technik uvede detailní popis provedené práce, seznam a časovou náročnost jednotlivých úkonů (blíţe v kapitole 6.3.4 - časové výkony) a seznam pouţitých náhradních dílů nutných k dokončení opravy. V případě, ţe jsou zákazníkovi doporučeny k výměně některé další náhradní díly, uvede to technik do servisního listu. Seznam těchto doporučených náhradních dílů je potom společně s kopií servisního listu systémem automaticky odeslán do oddělení náhradních dílů, které zpracuje a odešle zákazníkovi cenovou nabídku na tyto náhradní díly.
53
Po dokončení opravy a vyplnění servisního listu a jeho odsouhlasení ze strany zákazníka je servisní list zákazníkem podepsán a uzavřen. Podpis zákazníka je realizován elektronicky přímo v aplikaci pomocí podpisového tabletu. Tento zachycený psaný podpis je zašifrován a uloţen k danému servisnímu listu přímo do databáze systému. Jakmile je servisní list uzavřen, je zákazníkovi zasláno e-mailové upozornění s kopií tohoto listu ve formátu PDF v příloze e-mailu. Ukázka servisního listu je v příloze 1. Obrázek 6-4:Ukázka formuláře servisního listu
Zdroj: CRM systém společnosti Heidelberg
V případě, ţe se nejedná o servisní zásah přímo u zákazníka, ale například o servisní podporu po telefonu nebo vzdálenou diagnostiku, je postup obdobný s tím rozdílem, ţe servisní list je odsouhlasen a potvrzen zákazníkem na základě kopie listu zaslané zákazníkovi e-mailem. Modul servisních listů (Jobsheet) byl vytvořen jako uţivatelská entita s propojením na servisní zakázky (Case) a záznamy časových výkonů (Service Time). Náhled obrazovky modulu servisních listů je na obrázku 6-4.
54
6.3.4 Časové výkony Vykazování časové náročnosti jednotlivých úkonů je klíčové jak pro následnou fakturaci servisního zásahu zákazníkovi, tak pro vykazování nákladů společnosti a také pro vykazování časového vytíţení techniků. Veškeré časové údaje o jednotlivých výkonech jsou zaznamenány v modulu časových výkonů (Service time). Jednotlivé úkony vztahující se přímo k servisnímu zásahu jako například cestovné, demontáţ, montáţ, nastavení, školení obsluhy, atd. jsou vykazovány do časových výkonů prostřednictvím jednotlivých řádků přímo v servisním listu. Následně jsou tyto úkony přenášeny do servisních objednávek a dále potom do systému ERP pro fakturaci zákazníkovi. Ostatní aktivity jako je dovolená, návštěva lékaře, příprava na montáţ, školení techniků, atd. jsou vykazovány samostatně přímo v modulu časových výkonů. Záznamy o nepřítomnosti jsou také přenášeny do servisního kalendáře k zohlednění časové disponibility jednotlivých techniků. Veškeré tyto záznamy jsou následně vyuţívány pro generování reportů slouţících při výpočtu mezd servisních techniků. Modul časových výkonů je uţivatelská entita s propojením na servisní listy.
6.3.5 Schválení a fakturace Posledním funkčním modulem servisní části CRM systému je modul servisních objednávek. Po kompletaci všech servisních listů dané zakázky, je pracovníky servisního dispečinku k dané zakázce zaloţena servisní objednávka. Součástí servisní objednávky jsou údaje potřebné k zaúčtování dané zakázky v ERP systému (střediska, projekty a ostatní dimenze). Další částí servisní objednávky je schválení časových výkonů servisních techniků vykázaných na jednotlivých servisních listech. Zde pracovníci dispečinku odsouhlasí, případně upraví vykázané časové výkony, které mají být exportovány do ERP systému. Po konečném schválení je servisní zakázka uzavřena a servisní objednávka exportována do ERP systému. Po uzavření servisní zakázky je zákazníkovi opět odesláno e-mailem oznámení o uzavření servisní zakázky. Součástí tohoto oznámení je souhrnný report obsahující detaily zakázky a souhrn všech servisních listů přiřazených k dané zakázce včetně souhrnu časové náročnosti jednotlivých výkonů. Ukázka tohoto reportu zasílaného zákazníkům v maďarské pobočce je v příloze 2. Po exportování servisní objednávky je v systému ERP zaloţena objednávka a do ní jsou ze systému CRM přeneseny veškeré detaily. Na základě toho je zákazníkovi vystavena faktura, která je následně zaslána e-mailem. 55
Obrázek 6-5: Ukázka modulu schvalování servisních objednávek
Zdroj: CRM systém společnosti Heidelberg
Modul schvalování a servisní objednávky je uţivatelská entita s propojením na servisní zakázky. Náhled obrazovky této entity je na obrázku 6-5.
6.3.6 Reporting Stejně tak jako v případě „obchodní“ části systému CRM, je i v případě servisní části vyuţíváno různých reportingových nástrojů. Systém samotný obsahuje reporty jako vzory formulářů nebo souhrnné reporty zasílané zákazníkům. Pro generování servisních listů jsou pouţity reporty SQL reporting services. Systém obsahuje šablony servisních listů pro jednotlivé pobočky, příslušná šablona je potom zvolena automaticky podle dané organizační jednotky v systému. Důvodem pouţití vestavěných reportů je především moţnost jejich pouţití offline a nutnost jejich dostupnosti pro servisní techniky přímo v MS Outlook. Pro potřeby analýzy servisních činností je stejně tak jako v části obchodní vyuţíváno reportů aplikace QlikView. Kromě všech reportů slouţících pro analýzu servisních zakázek, servisní historii jednotlivých instalovaných strojů, atp. jsou tyto reporty pouţívány i jako podklady pro personální oddělení. Pravidelně jsou všem technikům zasílány e-mailem týdenní reporty časových výkonů, kde mohou technici ověřit, zda
56
v systému vykázali všechny časové výkony v rámci pracovní doby a případných přesčasů. Reporty aplikace Qlikview jsou pouţívány také jako měsíční výkazy pracovní doby slouţící jako podklad pro personální oddělení při zpracování mezd servisních techniků. Další oblastí vyuţití těchto reportů je analýza knowledge base, kde mohou servisní technici nebo zaměstnanci dispečinku vyhledávat v systému řešení jednotlivých problémů, které byly v minulosti zaznamenány v servisních listech.
6.3.7 Web portál Jak uţ bylo zmíněno v úvodu této kapitoly, zákazník má moţnost sdělit svůj poţadavek na servisní zásah prostřednictvím telefonu, faxu nebo e-mailu. V rámci zavedení CRM systému pro správu servisních zakázek ve společnosti Heidelberg, došlo také k zavedení webového portálu pro správu servisních poţadavků. Obrázek 6-6: Náhled obrazovky webového portálu pro správu servisních poţadavků
Zdroj: web portál service.heidelberg.hu (10)
Tento portál je v současné době v provozu pro zákazníky z Maďarska a Finska s tím, ţe do jednoho roku bude rozšířen i pro zákazníky z ostatních zemí regionu včetně České republiky. Portál je součástí webových stránek dané pobočky a je přístupný pouze
57
registrovaným zákazníkům. Po přihlášení do portálu má zákazník moţnost zobrazení seznamu svých instalovaných strojů a zařízení. V případě, ţe potřebuje zadat nový servisní poţadavek, můţe tak učinit přímo prostřednictvím tohoto portálu. Dále má zákazník moţnost on-line sledování stavu svých servisních poţadavků a to nejen zadaných přes tento portál, ale všech poţadavků evidovaných v CRM systému. Náhled webového portálu pro maďarské zákazníky je na obrázku 6-6 a 6-7. Obrázek 6-7: Detail servisní zakázky na webovém portálu
Zdroj: web portál service.heidelberg.hu (10)
Zavedení tohoto webového portálu jako dalšího komunikačního kanálu pro zadávání a kontrolu stavu servisních zakázek bylo zákazníky hodnoceno pozitivně a zároveň vedlo ke sníţení rutinních telefonních hovorů odbavovaných pracovníky servisního dispečinku.
58
6.4 Přínosy a další rozšíření Následující kapitola popisuje přínosy zavedení CRM systému pro podporu servisních procesů a zároveň ukazuje oblasti vhodné pro jeho další vývoj a rozšíření.
6.4.1 Přínosy zavedení servisní části systému Stejně tak, jak tomu bylo v oblasti obchodu před zavedením globálního CRM systému, byla i situace v oblasti servisu nadále neudrţitelná. Servisní modul ERP systému, který byl do té doby pouţíván, nepokrýval kompletní správu servisních zakázek, ale pouze oblast servisních objednávek a fakturací. Evidence servisních poţadavků zákazníka, dispečink servisních techniků a dokumentace servisních zásahů byla realizována v různých pobočkách různě pomocí lokálních aplikací nebo nejrůznějších dílčích tabulek v MS Excelu. Zavedením jednotného systému pro kompletní správu servisních zakázek a dispečink techniků v rámci CRM vedlo především ke standardizaci procesů v oblasti servisu (více v kapitole 6.2). Zavedení jednotných procesů a postupů napříč všemi pobočkami regionu vedlo především ke zjednodušení řízení z pohledu regionálního managementu a zlepšení operativních činností na úrovni lokálních poboček. Příkladem můţe být sdílení servisních techniků v rámci regionu CEE1. Další přínos můţeme sledovat v automatizaci do té doby ručně prováděných aktivit. Příkladem můţe být automatické zasílání poţadavku na nabídku náhradních dílů na základě doporučení servisních techniků. Zlepšení informovanosti zákazníka o stavu servisních poţadavků například zavedením servisního webového portálu nebo zasíláním e-mailových oznámení o stavu zakázky. V souvislosti se zavedením flexibilní pracovní doby některých servisních techniků bylo nutné detailně evidovat veškeré časové výkony těchto techniků a následné moţnosti automatického reportování pro potřeby personálního oddělení. Zavedením systému dochází automaticky k evidenci těchto výkonů, notifikaci techniků a exportu těchto reportů pouţívaných pro výpočet mezd. Vyuţitím společného systému pro obchodní i servisní činnosti ve společnosti vede i ke zlepšení informovanosti obchodních zástupců o komplexní situaci u zákazníka včetně
1
CEE – regionální sdruţení poboček České republiky, Slovenska, Maďarska a Rakouska
59
stavu otevřených servisních zakázek. Tyto informace mohou být cenné při vyjednávání obchodních zástupců o dodávkách nových zařízení nebo spotřebních materiálů. Výrazným přínosem zavedení servisní části CRM systému je především celkové zkrácení doby od fyzického provedení servisního zásahu do zaplacení tohoto zásahu zákazníkem. Servisní technik okamţitě po provedení zásahu zadá servisní list přímo do systému, pracovník dispečinku tak můţe prakticky okamţitě provést schválení a export do ERP systému, kde můţe být okamţitě vystavena faktura a zaslána zákazníkovi prostřednictvím e-mailu. V neposlední řadě je nutné zmínit vyuţití QlikView reportů jako znalostní databáze pro servisní techniky. Moţností vyhledávání v databázi všech historických řešení problémů pomáhá technikům šetřit čas potřebný pro nalezení správného řešení problému.
6.4.2 Další rozšíření systému Po nasazení servisní části systému do provozu nastal čas na analýzu dalších poţadavků uţivatelů a managementu na jeho rozšíření. Jak bylo zmíněno v kapitole 6.3.7 jednou z plánovaných moţností doplnění systému je rozšíření servisního webového portálu pro sledování servisních poţadavků do zbývajících zemí regionu. Vzhledem ke skutečnosti, ţe oblast servisních sluţeb se neomezuje jen na řešení jednorázových oprav u zákazníka, ale dochází také k aktivnímu prodeji servisních sluţeb prostřednictvím servisních kontraktů pokrývajících nejrůznější servisní prohlídky, prodlouţené záruky či balíčky servisní péče, je jedním z dalších poţadavků na moţné rozšíření systému moţnost začlenění těchto servisních kontraktů do systému. Jednou z funkcionalit nové verze CRM systému je také podpora alternativních webových prohlíţečů a mobilních zařízení. Vzhledem k současnému rozšíření a cenové dostupnosti těchto zařízení, je jednou z dalších moţností rozšíření systému o podporu těchto zařízení především pro servisní techniky. Zavedením podpory pro tablety bude moţné nahradit zpracování servisních listů a zejména nahrazení podpisových zařízení pro zachycení psaných podpisů na noteboocích například tablety. Tyto a mnohé další rozšíření jsou zaevidovány jako poţadavky na rozšíření systému a budou postupně zapracovány do dalších vydání servisní části CRM.
60
7 Upgrade systému V předcházejících kapitolách této práce jsme se postupně věnovali jednotlivým fázím ţivotního cyklu podnikového informačního systému. Prošli jsme fází analýzy, plánování a výběru informačního systému, implementace, školení uţivatelů a uvedení do provozu. Neméně důleţitou fází celého ţivotního cyklu je závěrečná fáze rozvoje a inovace, zahrnující aktualizace systému. Jiţ v závěru projektu zavádění systému MS CRM verze 4.0 ve společnosti Heidelberg stál projektový tým před otázkou moţného upgrade na verzi 2011. Společnost Microsoft oznámila ukončení podpory pro MS Dynamics CRM 4.0 k dubnu 2013. K dokončení projektu zbývalo v té době zavedení systému v 6 zbývajících zemích regionu APA včetně Číny. Otázkou bylo, zda dočasně přerušit projekt standardizace systému ve verzi 4.0, systém aktualizovat na verzi 2011, která byla v té době aktuální verzí, a poté pokračovat v zavádění systému ve zbývajících zemích. Další moţností bylo pokračovat v zavádění verze 4.0, dokončit tak celý projekt standardizace a následně aktualizovat systém na verzi 2013. Obě moţnosti měly své pro i proti, v případě aktualizace na verzi 2011 by sice bylo moţné provést upgrade jednoduše přímo pomocí dodávaných nástrojů, jelikoţ se jedná o verzi přímo následující po verzi 4.0, na druhou stranu by došlo ke zpoţdění projektu standardizace. Nevýhodou druhé varianty, byla především obtíţnější aktualizace na verzi 2013, jelikoţ se nejedná o verzi přímo následující po verzi 4.0 a není tedy moţné aktualizovat přímo z verze 4.0 na 2013. Dalším kritériem v rozhodování bylo i to, ţe verze 2011 obsahovala řadu zásadních změn v pouţívání scriptování na straně klienta, coţ by vedlo k nutnosti revize všech scriptů v poměrně rozsáhlých zákaznických úpravách systému. Toto by mohlo vést ke zpoţdění projektu standardizace o 6-12 měsíců. Po zváţení všech argumentů bylo rozhodnuto nejprve dokončit projekt standardizace s verzí 4.0 ve všech zemích a následně provést upgrade na verzi 2013. Vzhledem k zásadním změnám mezi verzemi 4.0 a 2013 a náročnosti upgrade, bylo rozhodnuto vytvořit samostatný projekt pro aktualizaci CRM systému na verzi 2013. Projekt odstartoval na podzim roku 2013 s předpokládaným termínem uvedení do provozu v létě 2014.
61
7.1 MS CRM 2013 Hlavním důvodem pro upgrade systému MS CRM 4.0 na verzi 2013 bylo oznámení ukončení podpory produktu ze strany výrobce. Toto bylo jedním nikoli však jediným důvodem pro upgrade. Verze 2013 přináší řadu nových uţivatelských funkcí, změnu v oblasti skriptování na straně klienta, změny v oblasti klientské aplikace v MS Outlook, podporu mobilních zařízení a v neposlední řadě nové uţivatelské rozhraní. V této kapitole se s některými z nich seznámíme detailněji. Nový design aplikace Design nové verze aplikace byl kompletně přetvořen do jednoduchého a čistého prostředí, kompletně přizpůsobeného pro pouţití na dotykových zařízeních jako jsou mobilní telefony, tablety či notebooky s dotykovou obrazovkou. Navigace je tvořena pásem ikon v horní části obrazovky, který je automaticky skrytý v případě, ţe není pouţíván. Ukázka srovnání původního a nového uţivatelského prostředí je na obrázku 7-1. Obrázek 7-1: Srovnání uţivatelského rozhraní verze 4.0 a 2013
Zdroj: autor
Společně s novým designem aplikace najdeme i některé uţitečné funkce jako poslední zobrazené záznamy (například firmy či kontakty), moţnost nastavení výchozích pohledů pro jednotlivé uţivatele, funkci autosave apod.
62
Mobilní zařízení Podpora mobilních zařízení je v dnešní době jiţ naprostou nutností. Verze 2013 přichází s plnou podporou tabletů a chytrých telefonů a to v reţimu online i offline. Obrázek 7-2: Náhled uţivatelského rozhraní verze 2013 pro mobilní zařízení
Zdroj: Microsoft Dynamics CRM 2013 Migration (11)
Aplikace pro mobilní zařízení jsou k dispozici pro všechny dostupné platformy (iOS, Android i Windows Mobile). Moţnost vyuţití CRM aplikace na mobilních zařízeních je neocenitelným přínosem především pro obchodní zástupce, kteří tak mohou mít všechny důleţité informace okamţitě k dispozici kdekoli. Náhled uţivatelského rozhraní verze 2013 pro mobilní zařízení je na obrázku 7-2. Podpora business procesů Vizuální podpora business procesů je další novinkou ve verzi 2013. Toto rozšíření umoţňuje uţivatelům snazší orientaci ve vývoji a aktuálním stavu procesů. Zároveň pomáhá udrţovat potřebnou kvalitu dat v systému tím, ţe například pro kaţdou fázi business procesu umoţňuje vybrat pole, která jsou v dané fázi povinná, a zároveň umoţňuje kontrolu logiky vkládaných dat. Tato funkce byla při implementaci ve společnosti Heidelberg vyuţita především v modulu obchodních příleţitostí, kde slouţí jako průvodce jednotlivými fázemi celého procesu.
63
Obrázek 7-3: Zobrazení business procesu v CRM 2013
Zdroj: CRM systém společnosti Heidelberg
Vylepšená podpora business procesů nabízí mimo jiné i moţnost vyuţití několika různých procesů a jejich přiřazení konkrétnímu uţivateli podle jeho rolí. Například proces obchodního případu je různý pro obchodní zástupce z oddělení strojů a zařízení, oddělení spotřebních materiálů či servisních sluţeb. Konkrétní proces je pak přiřazen uţivateli na základě jeho uţivatelských rolí. Podpora vývoje Kromě nových funkcí pro uţivatele a změny uţivatelského rozhraní přináší verze 2013 i řadu změn pro vývoj a uţivatelské úpravy systému. Moţnost vyuţití samostatných řešení (solutions) značně zjednodušuje vývoj systému především s ohledem na týmový vývoj aplikace. Rozdělení vývoje na jednotlivé části a jejich uzavření do řešení umoţňuje snadnější kontrolu při následném aplikování hotových řešení do testovacího nebo produkčního systému. V případě scriptování na straně klienta je velkým přínosem moţnost vyuţití web resources. Toto umoţňuje vytvoření sdílených knihoven s Java skripty provádějícími základní funkce pro manipulaci s daty, operacemi na formulářích, atp. a jejich následné opakované vyuţití v jednotlivých klientských scriptech. Outlook client I v oblasti klientské aplikace pro MS Outlook přichází verze 2013 s řadou vylepšení. Jedná se především o oddělení procesu sluţby CRM od samotného procesu aplikace Outlook. To má za důsledek především zlepšení stability aplikace Outlook při přechodu CRM z reţimu online do offline a opačně. Především uţivatelé chytrých telefonů vyuţívající synchronizaci s MS Exchange serverem ocení moţnost synchronizace CRM na straně serveru (server-side synch). V případě, ţe je povolena a nastavena tato funkce, nedochází k synchronizaci dat (kontakty, kalendář, úkoly) mezi CRM a MS Outlook přímo, ale data se synchronizují mezi CRM a Exchange serverem. To umoţňuje uţivateli automaticky synchronizovat tato 64
data dále mezi Exchange serverem a mobilním telefonem bez nutnosti spouštění aplikace Outlook. Vyuţití této funkce značně zjednoduší plánování servisních techniků tím, ţe se záznam o jejich plánované aktivitě, zaloţený servisním dispečinkem, přímo synchronizuje jako událost do MS Outlook a zároveň do jejich mobilního telefonu.
7.2 Příprava upgrade V případě, ţe se rozhodneme aktualizovat systém Microsoft Dynamics CRM, výrobce nám doporučuje dva moţné způsoby provedení upgrade. „In-place“, kdy přímo aktualizujeme produkční systém nebo „migrace“, kdy vytvoříme kopii systému a tu následně aktualizujeme. Vlastnosti obou postupů jsou uvedeny v následující tabulce. Tabulka 7-1: Metody upgrade
In-place upgrade
Migrace
Aktualizuje se přímo produkční systém
Preferovaný způsob aktualizace
Není moţné se vrátit zpět k původní verzi Je moţné se vrátit zpět k původnímu v případě selhání
systému v případě selhání
Rychlejší, ale riskantnější
Nenarušuje současný produkční systém Je
moţné
předem
otestovat
průběh
aktualizace Zdroj: autor
V našem případě byla zvolena migrace především z důvodu vyšší bezpečnosti a zachování přístupu k původnímu systému. Stejně tak jako v případě systému CRM 4.0 bylo potřeba vytvořit několik instancí systému 2103. Jako vývojové prostředí slouţí instance 2013 DEV (development), systém pro testování 2013 STG (staging) a produkční systém 2013 PRO (production). Jak bylo zmíněno v úvodu této kapitoly, aktualizaci systému verze 4.0 na verzi 2013 není moţné provést přímo pomocí nástrojů pro upgrade dodávaných výrobcem, jelikoţ se nejedná o po sobě následující verze. Celý proces aktualizace systému bylo tedy nutné rozdělit do několika kroků. Nejprve byl původní systém verze 4.0 dočasně aktualizován na verzi 2011 a následně byla tato verze aktualizována na finální verzi 2013.
65
Pro instance systému 2011, jako dočasného systému, bylo vyuţito virtuálních serverů a to jednak z důvodu úspory fyzického HW, ale především z důvodu moţnosti uloţení jednotlivých fází migrace a moţnosti rychlého návratu k bodu obnovení v případě selhání. Prvním krokem bylo vytvoření vývojového a testovacího prostředí 2013 (DEV a STG) pro následný vývoj a úpravy systému. Původní produkční systém 4.0 byl zkopírován jako 4.0 DEV a aktualizován dočasně na verzi 2011 a následně na verzi 2013. Tím byl vytvořen systém 2013 DEV určený pro vývoj a uţivatelské úpravy. Následným zkopírováním tohoto systému byl vytvořen systém 2013 STG určený pro následné testování.
7.3 Vývoj a úpravy systému Fáze vývoje a úprav systému byla nejnáročnější fází celého procesu upgrade. V tomto případě bylo potřeba zrevidovat a upravit více neţ: 50 uţivatelských entit, 20.000 řádku klientského kódu v Java scriptu, 200 workflow, 30 modulů plug-in Jak jsme si ukázali v kapitole 7.1 jedním z hlavních rozdílů mezi systémy verze 4.0 a 2103 je design uţivatelského rozhraní. Po aktualizaci systému jsou automaticky upraveny i všechny formuláře z původní verze včetně uţivatelských, i přesto je potřeba provést následnou revizi a úpravu formulářů. V našem případě se nejednalo pouze o technický upgrade systému, ale také o revizi business procesů ve firmě a s tím spojené úpravy systému. Z tohoto důvodu byly všechny formuláře revidovány a upraveny do jednotného designu. Pro uţivatelské úpravy formulářů byla navrţena jednotná předloha obsahující jednotlivé sekce formuláře a jejich vzhled. Šablonu pro návrhy formulářů najdeme v příloze 3. Nejen formuláře, ale i klientské skripty a moduly plug-in bylo nutné upravit tak, aby bezproblémově fungovaly ve verzi 2013. Jak uţ bylo uvedeno, verze 2013 umoţňuje pouţívání sdílených knihoven v podobě web-resources a zároveň mění přístup k prvkům na formulářích. Z tohoto důvodu bylo nutné provést důkladnou revizi současných scriptů a provést nutné změny.
66
Pro revizi klientských Java scriptů vytvořil Microsoft nástroj Microsoft custom code validation
tool
dostupný
zdarma
na
stránkách
http://www.microsoft.com/en-
us/download/details.aspx?id=30151. Pomocí tohoto nástroje je moţné zkontrolovat
kompatibilitu scriptů se systémem Microsoft CRM 2013. Náhled uţivatelského rozhraní aplikace je na obrázku 7-4. Obrázek 7-4: Nástroj Custom Code Validation Tool
Zdroj: MSDN Blogs (12)
Barevně označené části scriptů jsou vyhodnoceny jako nekompatibilní s verzí 2013 a musí být přepracovány. Při úpravách scriptů byly nejprve za pouţití SDK vytvořeny společné knihovny obsahující často pouţívané procedury a funkce, které byly následně vyuţity v jednotlivých formulářích. Jednalo se o základní knihovny pro manipulaci s daty, obsluhu formulářů, operace SOAP nebo operace s metadaty. Následně byly zrevidovány a upraveny všechny klientské skripty především s ohledem na vyuţití sdílených knihoven a úpravy indikované validačním nástrojem. Poté byly obdobným způsobem upraveny moduly plug-in, workflow a reporty. Při úpravách a nastavování systému bylo pouţito několika uţitečných nástrojů od různých výrobců. Za zmínku stojí například nástroj Ribbon Workbench pro jednoduchou úpravu uţivatelských menu a to jak pro webové rozhraní, tak pro menu v aplikaci MS Outlook nebo soubor nástrojů XRM Toolbox for Dynamics CRM společnosti CodePlex. Tento 67
nástroj lze vyuţít například pro správu a hromadné nastavování uţivatelských rolí, hromadné nastavování synchronizačních filtrů v aplikaci MS Outlook nebo editaci site map. Oba tyto nástroje jsou k dispozici ke staţení zdarma. Samostatnou kapitolou při upgrade systému byla příprava SW balíčku klientské aplikace. Jak bylo uvedeno v předchozích kapitolách, jednou z výhod systému Microsoft Dynamics CRM je plná integrace klientské aplikace do prostředí MS Outlook. Stejně tak jako serverovou část systému, ani klientskou aplikaci nebylo moţné aktualizovat přímo z verze 4.0 na verzi 2013. Z tohoto důvodu bylo nutné vytvořit samoinstalační balíček klientské aplikace, který byl následně distribuován konečným uţivatelům. Součástí tohoto balíčku byla automatická odinstalace klienta verze 4.0, instalace klienta 2013 a následná instalace jazykových balíčků (language pack) a service packů. Po automatické instalaci SW balíčku byl spuštěn konfigurační script pro nastavení instance systému. Klientské balíčky byly distribuovány krátce před uvedením do provozu prostřednictvím sluţby SCCM. Celkem bylo instalováno více neţ 900 klientských aplikací pro uţivatele ze všech zastoupení celosvětově.
7.4 Testování Velmi důleţitou fází projektu aktualizace systému bylo testování. Samotné testy probíhaly ve dvou krocích. Prvním z nich bylo integrační a systémové testování (SIT). Následně byl systém předán skupině klíčových uţivatelů k provedení uţivatelských akceptačních testů (UAT). Obě fáze testování probíhaly v testovací instanci systému STG. Nalezené chyby byly opravovány ve vývojovém prostředí DEV a následně aplikovány do STG v denních cyklech.
7.4.1 Integrační testování a systémové testování (SIT) Integrační a systémové testování bylo prováděno po ukončení vývoje a prvotním otestování vývojáři. Testy byly naplánovány předem testovacím týmem a realizovány v rámci společného workshopu vývojářů a testovacího týmu. Obsahem těchto testů bylo ověření funkčnosti jednotlivých komponent a především komunikace mezi nimi a návaznosti v rámci business procesů. Testy byly prováděny na základě připravených případů uţití vycházejících z operací uţivatelů. Případy uţití byly testovány různými testery v několika kolech. Chyby nalezené při testování byly okamţitě zaevidovány do
68
sdíleného seznamu. Skupina vývojářů průběţně opravovala nalezené chyby a opravené případy uţití předávala zpět k opětovnému testování.
7.4.2 Akceptační testování (UAT) Po ukončení integračních a systémových testů a opravení nalezených chyb byl systém předán k otestování „zákazníkovi“. Za „zákazníka“ v tomto případě povaţujeme zadavatele projektu, kterým je v tomto případě Sales Process Council (SPC) společnosti Heidelberg. Akceptační testy byly provedeny skupinou klíčových uţivatelů systému a členy SPC podle předem připravených scénářů. Tyto scénáře byly připraveny na základě běţných akcí prováděných uţivateli systému a to jak v oblasti prodeje, servisu i backoffice. Chyby nalezené při těchto testech byly opět zaevidovány v seznamu, kde jim byla následně přiřazena priorita (1-3). Na základě priority byly chyby opravovány a opět předávány k testování. Po ukončení akceptačních testů byl sepsán protokol o testování a akceptaci systému.
7.5 Migrace a uvedení do provozu Ve fázi kdy je dokončen vývoj a zákaznické úpravy systému a vše je otestováno přecházíme k fázi uvedení systému do provozu. Celý proces migrace fyzickému upgrade systému byl v tomto případě vzhledem k časové náročnosti jednotlivých kroků naplánován na jeden týden. V tomto období byl původní systém 4.0 ponechán uţivatelům k dispozici v reţimu pouze pro čtení. Vlastní migrace systému pak probíhala v následujících fázích: Migrace databáze a organizace Prvním krokem této fáze bylo vytvoření záloţní kopie databáze organizace produkčního systému verze 4.0. Tato záloţní kopie byla následně obnovena jako testovací systém 4.0 STG. Obrázek 7-5: Schéma postupu při migraci z verze 4.0 na verzi 2013 4.0 PRO -> 4.0 STG vytvoření kopie systému pro migraci
úpravy 4.0 STG – deaktivace uživatelských úprav
4.0 STG -> 2011
Zdroj: autor
69
úpravy 2011 (deaktivace web resources)
2011 -> 2013 PRO
V tomto systému pak byly deaktivovány veškeré uţivatelské úpravy (ty budou následně aplikovány z vývojového prostředí systému verze 2013). Následně byl proveden import této instance do nově nainstalovaného dočasného systému 2011 a její upgrade na verzi 2011. Do systému 2011 by doinstalován update rollup 14 (nutná aktualizace k následnému upgrade na verzi 2013) a byly deaktivovány vytvořené sdílené knihovny (web resources). Dalším krokem byla instalace systému verze 2013, import dočasné instance verze 2011 a její upgrade na verzi 2013. Tím byla dokončena první fáze migrace a technicky vytvořena instance produkčního systému verze 2013. Příprava systému V další fázi byly nejprve deaktivovány uţivatelské účty v systému 2013 (mimo IT uţivatelů). Následně byly importovány uţivatelské úpravy (solutions) z vývojového systému 2013 DEV a provedeny úpravy uţivatelských workflow. Dále byla provedena veškerá nastavení systému. Jelikoţ se nejednalo pouze o technický upgrade, ale zároveň byly provedeny i některé úpravy systému reflektující změny business procesů, bylo potřeba provést i některé konverze dat. Pro tyto konverze byly předem připraveny jednorázové konzolové aplikace. Konverze dat tvořila závěrečný krok této fáze přípravy systému. Dodatečné kroky po migraci Po dokončení technické migrace a nastavení systému bylo potřeba provést ještě několik dodatečných kroků ke zprovoznění systému. Mezi ně patří především změna nastavení všech reportů vyuţívajících jako zdroje dat CRM systém a to jak technické nastavení zdroje dat, tak i provedené změny obsahu reportů v souvislosti se změnami CRM procesů. Dále je to pak aktivace funkce auditu systému CRM, který je následně vyuţíván pro sledování změn v systému a aktivace a spuštění uţivatelských workflow. Následně byla provedena kontrola a nastavení uţivatelských práv jednotlivých uţivatelů, nastavení přístupu pouze pro čtení a aktivaci těchto uţivatelských účtů. Uvedení do provozu Závěrečnou fázi potom tvoří samotné uvedení do provozu, kdy jsou aktivovány uţivatelské účty, nastavení práv pro zápis a publikovány nové přístupové linky pro systém CRM 2013.
70
Celý tento proces upgrade systému byl předem kompletně otestován „nanečisto“, aby bylo moţné ověřit časovou náročnost a návaznost jednotlivých kroků a následně upravit časový harmonogram jednotlivých akcí. Souběţně s aktualizací serverové části systému byl uţivatelům distribuován SW balíček s klientskou aplikací pro MS Outlook. Po uvedení do provozu aktualizovaného systému 2013, zůstává původní systém 4.0 dočasně v provozu po dobu následujících dvou měsíců s tím, ţe případný přístup pro uţivatele do původního systému byl nastaven pouze pro čtení.
7.6 Školení uţivatelů Školení uţivatelů hraje v celém projektu klíčovou roli. Jak bylo uvedeno v úvodu této kapitoly, obsahuje verze 2013 kompletně nové uţivatelské rozhraní a řadu nových funkcí pro uţivatele. Zároveň s technickou aktualizací systému, byly provedeny i některé změny v business procesech a způsobu práce se systémem. Z toho důvodu bylo nutné provést detailní proškolení uţivatelů pro práci s novou verzí systému. V době aktualizace měl systém více neţ 1500 uţivatelů po celém světě. Z toho důvodu bylo nutné řešit otázku, jakým způsobem zajistit efektivně školení pro tuto skupinu uţivatelů. Ideální moţností bylo školení přímo na místě s osobní účastí všech uţivatelů, coţ se vzhledem k počtu a umístění jednotlivých uţivatelů zdálo nereálné, především s ohledem na to, ţe v projektovém týmu byly pouze 4 osoby provádějící školení uţivatelů. Důleţité bylo také načasování školení, vzhledem k tomu, ţe celý upgrade byl realizován najednou s jediným datem uvedení do provozu, bylo důleţité provádět školení co nejblíţe tomuto datu. V případě, ţe by školení uţivatelů proběhlo s velkým předstihem nebo naopak se zpoţděním, nebylo by dostatečně efektivní. Jako alternativou ke školení na místě byla moţnost vyuţít telekonference či videokonference nebo e-learningu. Tato varianta nebyla příliš podporována především s ohledem na nedostatečnou interakci s uţivateli nebo sníţení jejich pozornosti. Výsledné řešení bylo jakýmsi spojením obou variant. Prvotní představení nové verze systému a změn v business procesech bylo realizováno pomocí dvou úvodních telekonferencí několik měsíců předem. Tyto úvodní informace byly prezentovány skupině klíčových uţivatelů současné verze systému. Skupina klíčových uţivatelů je tvořena 1-2 zástupci uţivatelů z kaţdé pobočky společnosti, kteří jsou zodpovědní za správu uţivatelů a kvalitu dat v dané pobočce.
71
Následné bylo z těchto klíčových uţivatelů vybráno několik zástupců ze všech regionů a tito zástupci byli důkladně proškoleni a pověřeni realizací školení koncových uţivatelů v jejich regionech. Závěrečné školení tak probíhalo přímo na místě v jednotlivých pobočkách a bylo rozděleno přibliţně do intervalu 2-3 týdny před uvedením do provozu aţ v týden uvedení do provozu. Při těchto školeních byl systém demonstrován především z pohledu procesního včetně tzv. typických příkladů pouţití. Zde byly názorně předvedeny běţné postupy práce se systémem pro jednotlivé skupiny uţivatelů, například práce obchodního zástupce obsahující proces od naplánování schůzky u zákazníka, zapsání záznamu z jednání, jeho distribuci, popřípadě vytvoření obchodní příleţitosti. Všechna školení uţivatelů byla prováděna interaktivně v testovacím prostředí a za aktivní účasti uţivatelů. Školení bylo rozděleno do několika bloků a na konci kaţdého z nich byl uţivatelům zadán praktický úkol pro ověření jejich znalostí a zaznamenána zpětná vazba. Jako následná podpora pro uţivatele slouţila kromě elektronické dokumentace i moţnost vyuţití i e-learningu prostřednictvím firemního intranetu.
7.7 Dokumentace Dokumentace systému hraje při implementaci jakéhokoli informačního systému důleţitou roli, přesto bývá často podceňována. Při implementaci a upgrade systému Microsoft CRM ve společnosti Heidelberg byla zpracována jak uţivatelská dokumentace, která byla následně vyuţita při školeních klíčových a koncových uţivatelů, tak dokumentace systémová.
7.7.1 Uţivatelská dokumentace Uţivatelská dokumentace je vedena pouze v elektronické podobě a skládá z několika částí. Základ tvoří sada PDF dokumentů s kompletním popisem jednotlivých funkčních komponent. Kromě těchto PDF dokumentů, se při školení a následně při pouţívání systému osvědčilo vyuţití tzv. „How to“. Jedná se o jednoduché, několikastránkové elektronické dokumenty s názornými návody (doplněnými o snímky obrazovek), jak postupovat v konkrétních případech. Při tvorbě uţivatelské dokumentace byl v tomto případě kladen důraz také na popis business procesů a vysvětlení důvodů proč je důleţité tu či onu aktivitu evidovat v systému a jaké z toho plynou výhody pro samotného uţivatele. Kaţdý jednotlivý 72
dokument popisující danou oblast systému obsahuje také souhrn pravidel pro pouţívání daného modulu (tzv. business rules). Tyto dokumenty jsou dále doplněny o krátká ukázková videa, jak pracovat se systémem v konkrétních situacích (např. zaloţení nového obchodního případu, atd.). Veškerá uţivatelská dokumentace včetně ukázkových videí je uloţena na CRM webovém sharepoint portále přístupném všem uţivatelům systému.
7.7.2 Systémová dokumentace Stejně tak jako uţivatelská dokumentace hraje neméně důleţitou roli i dokumentace systémová. Tato dokumentace pokrývá kompletní popis systému, jeho infrastruktury, popis jednotlivých entit, provedené uţivatelské úpravy systému včetně klientských scriptů a modulů plug-in. Vyuţití této dokumentace je moţné nejen následně při dodatečných úpravách systému, ale především při týmové spolupráci skupiny vývojářů. Kromě nejrůznějších elektronických dokumentů uloţených na sdíleném sharepoint portále, bylo vyuţíváno i aplikací pro sdílení zdrojových kódu, jejich verzování, atd. V našem případě se jedná o aplikaci Apache Subversion s klientským rozhraním TortoiseSVN, kde jsou uloţeny veškeré zdrojové kódy aplikace. Součástí systémové dokumentace pro vývojáře je také Wiki portál s popisem funkcí jednotlivých sdílených knihoven včetně jednoduchých příkladů pouţití. Veškeré poţadavky na změnu jsou evidovány v systému pro správu těchto poţadavků a následně zpracovány jako případy uţití. Tato dokumentace byla také pouţita při testování systému a dále při akceptačních testech.
73
Závěr Hlavním cílem této diplomové práce bylo demonstrovat moţnosti vyuţití systému Microsoft Dynamics CRM v prostředí nadnárodní společnosti, způsobem jeho implementace a zákaznických úprav, rozšíření systému pro vyuţití v oblasti servisních sluţeb a moţnosti jeho upgrade. V úvodu práce byl představen pojem CRM jednak jako marketingová strategie podniku a zároveň označení systémů, které slouţí jako nástroj její realizace. Z pohledu architektury CRM systémů, byl vysvětlen obsah a význam jejich jednotlivých částí, dále byly popsány funkce hlavních části společných pro všechny CRM systémy a to především modulů pro řízení kontaktů, obchodních procesů, marketingu a sluţeb zákazníkům. V případě, ţe se organizace rozhodne pro zavedení CRM systému, hraje důleţitou roli příprava a plánování, je nezbytné předem vědět, na které funkce a vlastnosti systému se zaměřit a které naopak není nutné do systému zahrnovat. Zavedení tohoto systému musí být chápáno jako začlenění dalšího prvku do celého informačního systému společnosti a proto je důleţité, aby bylo moţno zvolený systém jednoduše přizpůsobit a integrovat s existujícími systémy v organizaci, zejména se systémem ERP. Pro úspěšné zavádění systému je vhodné se drţet některých doporučení, především získat a udrţovat si podporu vedení podniku, zajistit účast budoucích uţivatelů na procesu implementace a především nepodceňovat závěrečné fáze jako je školení uţivatelů, jejich následná podpora a správa systému. Zároveň je dobré se předem připravit na případné překáţky, které s sebou zavedení kaţdého informačního systému přináší, jako je neochota uţivatelů přijmout nový systém nebo jejich obava ze ztráty svobody a kontroly zaměstnanců. Při standardizaci CRM systémů v nadnárodních společnostech hraje důleţitou roli i příprava a standardizace stávající podnikové IT infrastruktury, klientských systémů nebo zavedení helpdesku. Všechny tyto aspekty zjednodušují následný proces implementace CRM. Praktická část této práce dále demonstruje moţnost vyuţití systému CRM nejen pro automatizaci obchodních procesů, ale také pro podporu servisních sluţeb a poprodejní péče o zákazníka. Pomocí uţivatelských úprav se podařilo zefektivnit proces servisu strojů a zařízení, od centrálního plánování a moţnosti sdílení servisních techniků v celém regionu, přes zlepšení informovanosti zákazníka o aktuálním stavu zakázky aţ po zkrácení doby od uzavření zakázky po následnou fakturaci. 74
V poslední kapitole praktické části je popsán projekt aktualizace jiţ implementovaného systému. Jedná se nejen o technický upgrade na vyšší verzi MS Dynamics CRM, ale po více neţ roce pouţívání CRM 4.0 jako globálního CRM, také aplikaci změn dosavadních business procesů a nástrojů pro jejich podporu. Závěrem lze říci, ţe na základě dosavadních zkušeností a zpětné vazby poskytnuté uţivateli systému, vedlo zavedení jednotného CRM systému v různých pobočkách společnosti, a jeho rozšíření o podporu servisních sluţeb v regionu východní Evropy, k automatizaci business procesů, zkvalitnění výstupů určených pro manaţerské analýzy a zefektivnění vyuţití lidských zdrojů. Samotné nasazení CRM systému v místech, kde dosud nebyl ţádný systém vyuţíván, vedlo ke zlepšení informovanosti zaměstnanců o interakcích se zákazníky, sdílení těchto informací mezi zaměstnanci jednotlivých oddělení a zefektivnění nabídky v oblasti sluţeb a zákaznické podpory. Na druhou stranu je nutné přiznat, ţe i po více neţ dvou letech od zavedení CRM systému je potřeba neustále působit na uţivatele a motivovat je k zodpovědné práci se systémem, především v oblasti kvality dat. Udrţování kvality dat na poţadované úrovni je nepřetrţitý proces vyţadující neustálou pozornost a kontrolu. Stále totiţ platí, ţe: „Produkty CRM jsou užitečné pouze natolik, nakolik jsou užitečné informace, které obsahují“. (2)
75
Seznam pouţité literatury 1. CRM portál, zpravodaj z oblasti CRM. Potřebujeme CRM ?. [Online]. 2014, [cit. 201411-22]. Dostupné z: http://www.crmportal.cz/redakcni/potrebujeme-crm. 2. BURNETT, Ken. Klíčoví zákazníci a péče o ně. 1. vyd. Překlad Eva Nevrlá. Praha: Computer Press, 2002. ISBN 8072266551. 3. BASL, Josef a Roman BLAŢÍČEK. Podnikové informační systémy: podnik v informační společnosti. 2., výrazně přeprac. a rozš. vyd. Praha: Grada, 2008. ISBN 97880-247-2279-5. 4. SystemOnLine. Co je a není CRM.[Online]. ©2001-2015 [cit. 2015-02-13]. Dostupné z: http://www.systemonline.cz/crm/co-je-a-neni-crm.htm. 5. SODOMKA, Petr a Hana KLČOVÁ. Informační systémy v podnikové praxi. 2., aktualiz. a rozš. vyd. Brno: Computer Press, 2010. ISBN 978-80-251-2878-7. 6. DOHNAL, Jan. Úvod do CRM v informační společnosti. Vyd. 1. Praha: Vysoká škola ekonomická, 2001. ISBN 80-245-0139-2. 7. TVRDÍKOVÁ, Milena. Aplikace moderních informačních technologií v řízení firmy: nástroje ke zvyšování kvality informačních systémů. 1. vyd. Praha: Grada, 2008. ISBN 978-80-247-2728-8. 8. CRM portál, zpravodaj z oblasti CRM. Překážky při zavádění CRM. [Online]. 2014, [cit. 2014-11-22]. Dostupné z: http://www.crmportal.cz/redakcni/prekazky-pri-zavadenicrm. 9. MSDN. Licenční programy Microsoft Dynamics CRM. [Online] 2014, [cit. 2015-0215]. Dostupné z: http://blogs.msdn.com/b/crm/archive/2013/10/30/license-types-inmicrosoft-dynamics-crm-2013-and-microsoft-dynamics-crm-online.aspx. 10. Heidelberg Magyorszag. Servisní portál. [Online]. 2015, [cit. 2015-03-30]. Dostupné z: http://service.heidelberg.hu. 11. Prodware. Microsoft Dynamics CRM 2013 Migration.[Online]. 2014, [cit. 2015-0115]. Dostupné z: http://www.dynamics-crm-2013-migration.com/en/what-s-new. 12. MSDN Blogs. The Microsoft Dynamics CRM Blog. [Online]. 2014, [cit. 2015-02-15]. Dostupné z: http://blogs.msdn.com/b/crm/archive/2012/06/21/microsoft-dynamics-crm2011-custom-code-validation-tool-released.aspx . 76
Seznam pouţitých zkratek APA
(Asia Pacific American) – označení regionu asijských zemí
BI
(Business Inteligence) – souhrn nástrojů umoţňující uţivatelům ucelený přístup k datům v podnikových informačních systémech a jejich analýzu
BU
(Business Unit) – organizační jednotka
CAL
(Client Access License) – klientská licence pro přístup
CEE
(Central Eastern Europe) – Země střední východní Evropy (ČR, SR, Maďarsko a Rakousko)
CIO
(Chief Information Officer) - vedoucí útvaru IS/IT
CRM
(Customer Relationship Management) – systém řízení vztahu se zákazníky
CSS
(Customer Service and Support) – automatizace servisních sluţeb
CTP
(Computer to Plate) - technika záznamu z digitální předlohy na tiskovou desku bez potřeby filmu
DEV
(Development system) – instance CRM systému určena pro vývoj aplikace
EBITDA
(Earnings before Interest, Taxes, Depreciation and Amortization) – Zisk před započtením úroků, daní a odpisů
EMA
(Enterprise Marketing Automation) – automatizace marketingových procesů
EMEA
(Europe, Middle East and Africa) – souhrnné označení regionu Evropy, zemí středního východu a Afriky
ERP
(Enterprise Resource Planning) – podnikový informační systém integrující klíčové podnikové procesy – výrobu, logistiku, personalistiku a ekonomiku
HR
(Human Resources) – oblast personalistiky a řízení lidských zdrojů
HW
(Hardware) – fyzicky existující technické vybavení počítače
IT
(Information Technology) – Informační technologie
LAN
(Local Area Network) – lokální počítačová síť
MOSP
(Microsoft Online Subscription Program) – program předplatného online sluţeb společnosti Microsoft
NAM
(North America) – označení regionu zemí Severní Ameriky
PDF
(Portable Document Format) - formát pro popis dokumentů Adobe Acrobat
PRO
(Production system) – instance produkčního CRM systému s reálnými daty 77
OS
(Operation System) – operační systém
SBX
(Sandbox) - instance zkušebního CRM systému pro testování
SCCM
(System Center Configuration Manager) – software spol. Microsoft pro správu SW instalací na klientských stanicích
SDK
(Software Development Kit) - sada vývojářských softwarových nástrojů, obsahuje runtime knohovny
SFA
(Sales Force Automation) – automatizace procesu řízení obchodu
SIT
(System Integration Testing) – systémové integrační testy
SOAP
(Simple Object Access Protocol) – protokol pro výměnu zpráv XML pomocí protokolu HTTP
SPC
(Sales Process Council) – řídící orán pro firemní procesy
SQL
(Structured Query Language) - strukturovaný dotazovací jazyk vyuţitý v práci s databází
SSU
(Sales and Service Unit) – prodejně-servisní jednotka, jedná se o lokální pobočku společnosti
STG
(Staging system) – instance CRM systému určena pro školení uţivatelů
SW
(Software) – veškeré programové vybavení počítače
TAPI
(Telephony Application Program Interface) – sluţba v systému Windows pro spolupráci s telefonní ústřednou
UAT
(User Acceptance Testing) – akceptační testy na straně zákazníka
USL
(User Subscription License) – uţivatelská licence pro přístup k online sluţbám
VPN
(Virtual Private Network) – virtuální privátní síť
WAN
(Wide Area Network) – počítačová síť pokrývající rozlehlé území
78
Seznam obrázků Obrázek 1-1: Architektura CRM ....................................................................................... 11 Obrázek 3-1: Přehled cen uţivatelských licencí pro MS Dynamics CRM 2013 online .... 22 Obrázek 4-1: Členění prodejní jednotky (SSU) ................................................................. 27 Obrázek 4-2: Blokové schéma IT organizace .................................................................... 28 Obrázek 5-1: Mapa dříve pouţívaných CRM systémů ...................................................... 30 Obrázek 5-2 :Přehled částí Heidelberg CRM po úpravách systému.................................. 34 Obrázek 5-3: Ukázka přehledu obchodních příleţitostí z reportu CRMquick .................. 42 Obrázek 5-4: Proces realizace poţadavků na změnu ......................................................... 43 Obrázek 6-1: Schéma procesu Call2Fix ............................................................................ 48 Obrázek 6-2:Schéma modulů servisní části ....................................................................... 51 Obrázek 6-3:Obrazovka servisního kalendáře pro plánování servisních techniků. ........... 53 Obrázek 6-4:Ukázka formuláře servisního listu ................................................................ 54 Obrázek 6-5: Ukázka modulu schvalování servisních objednávek ................................... 56 Obrázek 6-6: Náhled obrazovky webového portálu pro správu servisních poţadavků ..... 57 Obrázek 6-7: Detail servisní zakázky na webovém portálu............................................... 58 Obrázek 7-1: Srovnání uţivatelského rozhraní verze 4.0 a 2013 ...................................... 62 Obrázek 7-2: Náhled uţivatelského rozhraní verze 2013 pro mobilní zařízení ................. 63 Obrázek 7-3: Zobrazení business procesu v CRM 2013 ................................................... 64 Obrázek 7-4: Nástroj Custom Code Validation Tool ........................................................ 67 Obrázek 7-5: Schéma postupu při migraci z verze 4.0 na verzi 2013 ............................... 69
79
Seznam tabulek Tabulka 3-1: dodatečné poplatky za MS Dynamics CRM Online .................................... 23 Tabulka 3-2: Ceny licencí MS Dynamics CRM 2013 on-permise .................................... 23 Tabulka 7-1: Metody upgrade ............................................................................................ 65
Seznam příloh Příloha 1:Ukázka servisního listu pouţívaného tureckou pobočkou Příloha 2: Report rekapitulace servisní zakázky Příloha 3: Vzor pouţívaný při návrhu formulářů
80
Příloha 1 Ukázka servisního listu pouţívaného tureckou pobočkou
Příloha 2 Report rekapitulace servisní zakázky
Příloha 3 Vzor pouţívaný při návrhu formulářů Fixed heading info (max 3 column).
Entity: Information
Header info (1): xxxxxx
<Title>
Owner: xxyyzz
Summary Tab (fixed wording) i.e "General" tab on CRM4.0
Summary SUBTITLE (1)
..
POSTS ACTIVITIES NOTES(0)
SUBTITLE (3)
Social Pane to be place as middle column alwayss
SUBTITLE (2) Field 1 Field 2
Account: xxxxxxxxxxx
..
SUBGRID 1 Column1
Column2
Column3
Column4
Subgrid heading in CAPS Letter and no Line is needed.
.. Value 1 Value 2
For frequently use entity try to start the Summary tab with 3 column formatting (even without Social Pane)
Details (1) SUBTITLE (1)
..
Field 1
Value 1
Field 2
Value 2
SUBTITLE (4) Field 1
Value 1
Field 2
Value 2
SUBTITLE (2)
..
SUBTITLE (3)
..
Field width to be align In the case that the label wording is way too long, that the width are about 220, try to use alternate display method,e.g.: display label on top
..
Section headingUPPER CASE, with Line & Aligned
Details (2)
Other Info / Associated Entity info (if any)
Others
Notes
For entity without Social Pane always put the notes in a seperate Tab & Expand by default(Second last from bottom), otherwise the counter will not show
Every Entity should have Administration Tab & Do not Expand by default (Always at the bottom on screen )
Adminstration SYSTEM INFORMATION Created On: Created By: Status:
. Modified On: Modifed By: Status Reason:
OTHERS Lead: xxxx Currency: xxxx
As system default a status, do not need footer. Case by case display the Modifiied By and Modified On in certain entity
.
Tab formatting: 2 column Fixed Section heading: (CAPITAL): SYSTEM INFORMATION and OTHERS (to accomodate non front end critical
