Implementace CRM systému v podniku případová studie

Masarykova univerzita Fakulta informatiky

Implementace CRM systému v podniku – případová studie Diplomová práce

Mgr. Tomáš Zdvořilý Brno, květen 2014

[oficiální zadání] [prohlášení autora školního díla]

Na tomto místě bych rád poděkoval Ing. Leonardovi Walletzkému, PhD. za vedení práce a cenné rady při jejím vypracování. Poděkování patří také všem pracovníkům společnosti XYZ za pomoc, kterou mi při psaní práce poskytli. Dále bych rád poděkoval své rodině za neutuchající podporu po celou dobu mého studia.

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Mgr. Tomáš Zdvořilý

Vedoucí práce: Ing. Leonard Walletzký, Ph.D.

Shrnutí Diplomová práce má za cíl porovnat teoretické principy řízení projektů implementace podnikových informačních systémů s praktickým projektem zavádění CRM systému do společnosti XYZ. Teoretická část práce je věnována řízení vztahů se zákazníky a popisu CRM systémů. Druhým stěžejním tématem je řízení projektů. To je nejprve popsáno obecně, poté podrobněji pro projekty implementace podnikových informačních systémů, a nakonec jsou zhodnoceny některá specifika pro implementaci CRM systémů. Praktická část nejprve čtenáře seznamuje se samotnou společností XYZ, její organizační strukturou a informačním systémem. Následuje podrobná analýza konkrétního projektu zavádění CRM systému. Ta proběhla formou studia projektových dokumentů a rozhovorů s vedoucím projektu a uživateli CRM systému. V poslední části práce je celý projekt zhodnocen z pohledu autora a jsou popsána pozitiva i negativa vztahující se k celému projektu. Dále je projekt porovnán s teoretickými principy a jsou navrženy jak úpravy teoretického aparátu, tak návrhy pro vylepšení řízení projektů ve společnosti XYZ.

Klíčová slova Řízení vztahů se zákazníky, CRM, projekt, řízení projektů, Microsoft Dynamics CRM, případová studie

Obsah Úvod ................................................................................................................ 1 1 Řízení vztahů se zákazníky ..................................................................... 4 1.1

Definice CRM ..................................................................................... 4

1.2

Základní dimenze CRM ................................................................... 5

1.3

Životní cyklus CRM .......................................................................... 6

1.4

Vztah marketingu a CRM ................................................................ 8

1.5

Procesy CRM a obchodní cyklus................................................... 13

2 CRM systémy .......................................................................................... 17 2.1

Postavení CRM systému v podnikovém IS ................................. 17

2.2

Klasifikace CRM systémů .............................................................. 19

2.3

Koncepce CRM systémů ................................................................ 20

2.4

Architektura CRM systému ........................................................... 22

2.5

Přínosy implementace CRM systému .......................................... 25

2.6

Kvalita CRM systému ..................................................................... 27

2.7

Měření výkonnosti CRM systému ................................................ 30

2.8

CRM systémy v ČR a ve světě ....................................................... 32

3 Řízení projektů ........................................................................................ 38 3.1

Projekt ............................................................................................... 38

3.2

Projektové řízení .............................................................................. 43

4 Projekt implementace informačního systému do podniku .............. 49 4.1

Základní charakteristiky projektu ................................................ 49

4.2

Životní cyklus projektu .................................................................. 50

4.3

Rizika projektu................................................................................. 58

4.4

Specifika projektů implementace CRM systému ........................ 59

5 Představení společnosti XYZ ................................................................ 65 5.1

Organizační struktura..................................................................... 65

5.2

Softwarová výbava společnosti ..................................................... 66

6 Projekt implementace CRM systému v XYZ ...................................... 69 6.1

Důvody pro změnu systému ......................................................... 69

6.2

Projektový záměr............................................................................. 71

6.3

Zadání projektu ............................................................................... 75

6.4

Prvotní fáze projektu ...................................................................... 77

6.5

Aktualizace obchodního procesu.................................................. 84

6.6

Výběr dodavatele a systému.......................................................... 91

6.7

Implementace systému ................................................................... 98

6.8

Školení uživatelů ........................................................................... 105

6.9

Kontrolní mechanismy ................................................................. 106

6.10

Spuštění systému a jeho převzetí .......................................... 109

6.11

Post-implementační fáze projektu ......................................... 112

7 Zhodnocení projektu ............................................................................ 113 7.1

Důvody pro změnu systému ....................................................... 113

7.2

Projektový záměr........................................................................... 113

7.3

Zadání projektu ............................................................................. 115

7.4

Prvotní fáze projektu .................................................................... 116

7.5

Nový obchodní proces .................................................................. 117

7.6

Výběr dodavatele a systému........................................................ 121

7.7

Implementace systému ................................................................. 122

7.8

Ostatní části projektu .................................................................... 124

7.9

Shrnutí............................................................................................. 125

Závěr............................................................................................................ 128 Použité zdroje............................................................................................. 131 Seznam zkratek .......................................................................................... 137 Seznam obrázků......................................................................................... 138 Přílohy ......................................................................................................... 139

Úvod Zákazníci jsou nejdůležitějším kapitálem každého podniku. Ten může produkovat skvělé výrobky nebo nabízet kvalitní služby, ale bez zákazníků, kteří by nabízené produkty poptávali a nakupovali, by stejně rychle zkrachoval. Doby, kdy na malém městě fungoval jediný koloniál, majitel si osobně pamatoval všechny své zákazníky a dokázal jim vyjít vstříc službami na míru, jsou již dávno pryč. Současné podniky musí čelit globálním výzvám, které přináší moderní svět. Jsme svědky posunu marketingových strategií od masových k vysoce personalizovaným, kdy se podniky snaží zjistit co nejvíce o svých zákaznících a následně tyto informace využít při nabídce svých produktů. Uspějí pouze ti, kdo zachytí tuto zásadní změnu paradigmatu, a dokáží se jí přizpůsobit. Samozřejmě žádný z podniků nechce skončit v propadlišti dějin, a proto dříve či později každý z nich sáhne po některém z řešení podporujícím řízení vztahů se zákazníky. Specializované systémy zaměřené na tuto oblast se v poslední době stávají ne strategickou výhodou, ale nezbytně nutnou součástí komplexního podnikového informačního systému. Mnoho podniků si ale neuvědomuje, že nestačí nasadit nějaký informační systém a vše půjde samo. S implementací jakéhokoliv informačního systému jsou úzce spjaty také významné procesní změny, které se dotknou většiny zaměstnanců příslušného podniku. Na tento fakt se bohužel často zapomíná, a nesoulad mezi očekáváními top managementu podniku a reálnými potřebami změn vedou k tomu, že velké procento projektů implementace CRM systému selže. V roce 2007 selhalo 56 % projektů implementace CRM, v roce 2009 47 % a nejaktuálnější nalezený údaj hovoří dokonce o 63 % neúspěšných projektů implementace CRM [1], [2]. Právě implementace CRM systému do podniku je stěžejním tématem této diplomové práce. Motivací k jejímu vypracování byl reálný požadavek ze strany společnosti, která se musela vyrovnat s odchodem

1

klíčového zaměstnance na pozici specialisty CRM systému. Následoval požadavek na přesunutí podpory, údržby a rozvoje CRM systému z oddělení CoreIT do oddělení Business softwarové podpory. V rámci tohoto přesunu došlo ke zhodnocení celého projektu implementace CRM systému a proběhla analýza aktuálního využívání systému, aby následně mohl být systém převzat ve stavu, který odpovídá realitě. Cílem diplomové práce je porovnat tento konkrétní projekt implementace CRM systému do podniku s teoretickými principy projektového managementu se zaměřením na zavádění podnikových informačních systémů. Výstupem práce je zhodnocení daného projektu a návrhy na úpravu teorie projektového managementu tak, aby byla použitelnější pro praktické využití. Teoretická část práce vychází zejména z monografických publikací, kterých bylo na téma řízení vztahů se zákazníky (ať už obecně, nebo za podpory specializovaného systému) napsáno a vydáno velké množství. Informace jsou doplněny aktuálními internetovými zdroji. Výzkum v rámci praktické části byl založen na studiu projektové dokumentace – akčního plánu projektu, smluv mezi dodavatelem a zákazníkem, e-mailové komunikace v průběhu projektu, zápisků členů týmu, a dalších dokumentů. Výzkum byl dále doplněn osobními rozhovory s vedoucím projektu a samotnými uživateli systému. První kapitola práce je věnována obecnému vymezení pojmu „řízení vztahů se zákazníky“. Tento český pojem je téměř doslova přeložen z více používaného a mezinárodně uznávaného anglického pojmu „Customer Relationship Management“ (zkráceně CRM). V rámci celé práce budu používat oba výrazy jako synonyma. Kromě definice samotného pojmu je součástí této kapitoly také popis životního cyklu CRM, vztahu mezi CRM a marketingem a na závěr jsou krátce nastíněny základní procesy CRM. Druhá kapitola se již zabývá CRM systémy a jejich postavením v komplexním informačním systému podniku. Jsou popsány různé

2

koncepce CRM systému, jeho obecná architektura, přínosy zavedení systému do podniku, a je definována kvalita CRM systému a přístupy, jak ji měřit. Na závěr jsou představeny některé důležité CRM systémy, které jsou využívány jak ve světě, tak na českém trhu. Třetí kapitola krátce nastiňuje obecné základy projektového řízení. Vzhledem k tomu, že tato oblast je velice rozsáhlá, informace v mé práci jsou opravdu pouze základní. Dále jsou rozvedeny v kapitole čtyři, která se více zabývá konkrétní kategorií projektů zavádění informačního systému do podniku. V této kapitole je podrobně rozepsán životní cyklus projektu implementace podnikového informačního systému, potenciální rizika, a také různá specifika projektů implementace CRM systému do podniku. Pátá kapitola stručně přestavuje společnost XYZ, ve které byla provedena praktická část této diplomové práce. Popsána je organizační struktura společnosti a také softwarová výbava jak z hlediska podnikového informačního systému, tak z pohledu koncových stanic. Šestá kapitola se již věnuje samotnému projektu implementace CRM systému do společnosti XYZ. Podrobně jsou popsány jednotlivé fáze projektu a podstatné dokumenty, vztahující se k projektu. Poslední kapitola práce je věnována zhodnocení projektu popsaného v kapitole šesté. Stěžejní součástí je mé vlastní hodnocení daného projektu a popis pozitiv i negativ, která dle mého názoru celý projekt provázela. Dále je projekt porovnán s teoretickými principy, jsou navrženy jejich úpravy, a také některé podněty pro vylepšení případných budoucích projektů ve společnosti XYZ. Z důvodu ochrany citlivých údajů a interních záležitostí společnosti, díky které bylo možné zpracovat praktickou část této práce, došlo ke změně veškerých údajů, které by mohly vést k její přesné identifikaci. Místo reálného názvu společnosti tedy používám zkratku XYZ, pro informační systémy jsou použity zkratky ADG a ERP a zároveň byly záměrně změněny přesné názvy pozic a jednotlivých oddělení.

3

1 Řízení vztahů se zákazníky 1.1 Definice CRM Definovat, co „řízení vztahů se zákazníky“ znamená, není úplně jednoduché. Neexistuje všeobecně uznávaná a používaná definice a každý z autorů pohlíží na danou problematiku trochu jinak. Volnou definici nabízí ve své publikaci Šašek [3, str. 20]: „Řízení vztahů se zákazníky je tvořeno řadou navazujících aktivit (činností), směřujících k identifikaci (personalizaci), získávání a dlouhodobé stabilizaci vybraných zákazníků, nastavení systému péče o tyto zákazníky, s cílem efektivního rozvoje jejich hodnototvorného procesu a profitu (hodnoty) pro obě strany.“ Podobně volně definuje CRM Chlebovský [4, str. 23] jako „interaktivní proces, jehož cílem je dosažení optimální rovnováhy mezi firemní investicí a uspokojením zákaznických potřeb. Optimum rovnováhy je determinováno maximálním ziskem obou stran.“ Lošťáková ve své knize [5, str. 20] nabízí podrobnější pohled na CRM: „Diferencované řízení vztahů se zákazníky (CRM) umožňuje lepší poznání zejména klíčových zákazníků a spotřebitelů, pochopení jejich jednání i potřeb a požadavků i definování vhodných aktivit, vedoucích k udržení těchto zákazníků. CRM je proces neustálého shromažďování údajů ze všech míst kontaktů se zákazníky a jejich následná transformace do podoby strategických znalostí pro vybudování dlouhodobého ziskového vztahu s klíčovými zákazníky. CRM pomáhá firmám vytvořit více profitabilní vztah se zákazníky a snížit operativní náklady. … Díky CRM mohou organizace zkrátit prodejní cyklus a zvýšit klíčové ukazatele výkonu.“ Všechny uvedené definice CRM mají mimo jiné společnou jednu základní věc – nezahrnují využití informačních technologií. Zde bych rád poukázal na to, že ačkoliv v současné době si většina manažerů a uživatelů pod pojmem CRM představí některý z řady softwarových nástrojů, CRM je ve své podstatě zejména proces – což ostatně mají také všechny výše uvedené definice společné. Informační technologie jsou

4

samozřejmě v současné době velice důležitou a již i nedílnou součástí CRM, ale softwarové nástroje samy o sobě nebudou účinné, pokud je v podniku špatně nastavený proces řízení vztahů se zákazníky. Informační technologie ve své definici CRM uvádí Dohnal [6, str. 18]: „Řízení vztahů se zákazníky (CRM) zahrnuje pracovníky, podnikové procesy a technologii IS/ICT s cílem maximalizovat loajalitu zákazníků a v důsledku toho i ziskovost podniku. Je součástí podnikové strategie a jako takové se stává součástí podnikové kultury. Technologicky stále více využívá potenciálu a možností internetu.“ Podobně včetně technologií definuje CRM i Wessling [7, str. 16] jako „aktivní tvorbu a udržování dlouhodobě prospěšných vztahů se zákazníky. Komunikace se zákazníky je přitom zajištěna vhodnými technologiemi, které představují pro akcionáře i pro zaměstnance firmy samostatné procesy s přidanou hodnotou.“ Osobně bych výše uvedené definice shrnul tak, že CRM je proces poznávání a udržení zákazníků podniku, což v dlouhodobém horizontu vede ke zvýšení zisků a snížení operativních nákladů. Tento proces je důležitou součástí podnikové kultury a v současné době je stále více podporován informačními technologiemi.

1.2 Základní dimenze CRM Jak je vidět z výše uvedených definic, existuje několik hlavních prvků, bez nichž by se CRM neobešlo. Tím prvním a nejdůležitějším jsou lidé, a to jak samotní zákazníci, ke kterým celé CRM směřuje, tak zaměstnanci podniku a další lidský kapitál, který do procesu vstupuje. Druhým významným prvkem jsou obchodní procesy a jejich vzájemné prolínání. Pokud jsou jednotlivé procesy optimalizovány, CRM je efektivnější. Nedílnou součástí CRM se již také staly technologie, ať již se jedná o telefon, e-mail, internet, nebo o specializovaný komplexní CRM systém. Jednotlivé nástroje potom umožňují uplatnění personalizovaného přístupu i při vysokém počtu zákazníků. Poslední dimenzí CRM je obsah, neboli data o jednotlivých zákaznících, konkurenci, situaci na trhu

5

atd. Do této kategorie patří nejenom sběr dat, ale také jejich uchování, možnost v nich vyhledávat, třídit je, a v neposlední řadě také možnost je analyzovat a získávat z nich informace vedoucí k lepšímu pochopení zákazníků [4, str. 25], [7, str. 16]. Všechny tyto základní prvky jsou navzájem provázané, a aby se dal proces CRM provádět správně, není možné se detailně zaměřit pouze na některé z nich, a ty ostatní potlačit. Pokud tedy chce podnik vylepšit proces CRM, musí se zabývat jak zvyšováním kvalifikace personálu, tak aktualizací technologického vybavení, správou dat a také je potřeba aktualizovat a vylepšovat samotné obchodní procesy. Pouze pokud jsou všechny čtyři dimenze sloučeny do jednoho celku, je možné s implementací či inovací CRM uspět [7, str. 16 – 17]. Provázanost jednotlivých prvků je vidět na obr. 1.1.

obr. 1.1 Prvky CRM a jejich provázanost, zdroj: [7, str. 17]

1.3 Životní cyklus CRM Počátkem každého vztahu se zákazníkem je iniciativa podniku, která vede k vytvoření image mezi potenciálními zákazníky. Pro vytvoření image mohou být použity masové marketingové kampaně (ať už v médiích, pomocí webových stránek nebo jakoukoliv jinou formou) nebo přímé oslovení telefonem, dopisem či e-mailem [7, str. 18 – 19]. Následuje navázání kontaktu, které naopak většinou iniciuje potenciální zákazník. Kontakt může být navázán různými formami, ať už

6

telefonicky, e-mailem, nebo třeba vyplněním interaktivního formuláře na webové stránce podniku [7, str. 18]. Po navázání kontaktu dochází k rozvoji vztahu mezi podnikem a zákazníkem. V této fázi dochází k vyjednávání podmínek vztahu (resp. podmínek navázání kontraktu) a vzájemnému poznávání se. V průběhu fáze rozvoje vztahu se může ukázat, že další spolupráce není vhodná pro jednu, pro druhou, či pro obě strany. Z pohledu zákazníka může dojít ke ztrátě zájmu o nabízený produkt, nebo není ochoten přistoupit na podmínky nabízené podnikem. Podnik naopak může zjistit, že spolupráce s daným zákazníkem nepřináší kýžený efekt, nebo je dokonce ztrátová. V obou případech následně dojde k ukončení vztahu [7, str. 18]. Ukončení vztahu v dané chvíli ale neznamená, že v budoucnu se situace nemůže změnit. Podnik může vyvinout nový produkt, který zákazníkovi bude přínosem. Zákazník se může dostat do fáze, kdy podmínky nabízené podnikem pro něj budou akceptovatelné. V budoucnu tedy může dojít k navázání nového kontaktu mezi zákazníkem a podnikem. Pokud je spolupráce zákazníka s podnikem vzájemně prospěšná, dochází ke konsolidaci vztahu. Podnik dodává produkt a zákazník využívá servisu, pokud je potřeba. V rámci této fáze také může podnik zákazníkovi nabízet další produkty, případně nadstandardní služby a nadále s ním komunikovat. Hlavním cílem je spolupracovat se zákazníkem co nejdéle [7, str. 18 – 19]. I v průběhu spolupráce ale může nastat situace, kdy její pokračování není pro některou ze stran výhodné. Každý vztah, pokud není udržován,

časem

upadá.

Tento

úpadek

vztahu

může

nastat

z nejrůznějších důvodů – podnik již dodal kompletní produkt a zákazník nechce další nabízené produkty, situace na trhu se změnila a podmínky pro dodávku nejsou pro některou ze stran přijatelné, nebo se zákazník s dodavatelem dohodli na ukončení spolupráce. V takovém případě by opět mělo dojít k ukončení vztahu, který již nadále nemá vý-

7

znam za každou cenu udržovat [7, str. 18 – 19]. Opět ale může nastat situace, že v budoucnu spolu zákazník a podnik naváží další spolupráci, i když v tomto případě je to méně pravděpodobné. Celý životní cyklus CRM je graficky znázorněn na obr. 1.2.

obr. 1.2 Životní cyklus CRM, zdroj: autor, inspirováno [7, str. 18]

1.4 Vztah marketingu a CRM Marketing se dá definovat jako „společenský proces, v němž jedinci a skupiny získávají to, co potřebují a chtějí, a během něhož vytváříme, nabízíme a svobodně směňujeme s jinými výrobky a službami, které mají hodnotu“ [9, str. 44]. Základním cílem marketingu je získání konkurenční výhody na trhu a její následné udržení po co nejdelší dobu. Konkurenční boj je čím dál tím tvrdší, k čemuž přispěla i globalizace trhů a také rozvoj internetu a moderních technologií [4, str. 8]. Marketing se tedy musí posouvat neustále dopředu, a právě CRM je jedním z nejdůležitějších aspektů, které mohou být rozdílem mezi úspěchem a neúspěchem podniku na vysoce konkurenčním trhu.

1.4.1 Vztah marketingu a CRM dle historického vývoje Jeden z pohledů na vztah marketingu a CRM nabízí Chlebovský [4]. Ten se zabývá jeho vývojem, přičemž historii marketingu rozděluje na tři základní etapy. Historický marketing je přístup, kdy firmy vyrábějí to, co umí, a nezajímají se o situaci na trhu. Produkty jsou prodávány za cenu nákladovou, a nikoli za cenu tržní. Tento přístup není úplně ideální, protože nereflektuje reálnou situaci na trhu [4, str. 8].

8

Druhou etapou je klasický marketing založený na marketingovém mixu, tzv. 4P – z angličtiny Product (výrobek), Price (cena), Place (místo) a Promotion (propagace), který by se dal označit jako produktově orientovaný. Na tomto principu v současné době funguje naprostá většina společností [4, str. 10]. Ovšem s postupující globalizací se tento klasický přístup setkává se vzrůstajícím množstvím problémů. Aby mohl fungovat správně a pomáhal dosáhnout cílů společnosti (nemusí jít jen o maximalizaci zisku, ale třeba i o maximalizaci obratu, počtu zákazníků nebo ovládnutí trhu), musí být jednotlivé proměnné správně namixované. V globálním prostředí je ovšem nemožné si cíleně vybrat místo (tím se stává celý svět) a produkt může být buď vhodně připraven pro lokální trh, nebo pro globální trh, přičemž tyto dvě varianty jsou většinou v přímém rozporu. Marketingový mix je tedy významně omezen na dvě zbylé veličiny, a navíc dochází k dalším omezením (např. regulace některých komodit). Zároveň je velice náročné získat rychlou (ideálně okamžitou) zpětnou vazbu od zákazníků, kteří jsou rozmístěni po celém světě [4, str. 18]. Aby podniky překonaly nedostatky klasického marketingu, začaly hledat nové způsoby propagace a nyní se dostávají do fáze moderního marketingu, který se dá označit za zákaznicky orientovaný. Základem moderního marketingu jsou tří pilíře, tzv. 3C – opět z angličtiny „Customer Benefits“ (prospěch pro zákazníka), „Total Customer Cost“ (celkové náklady na nákup produktu) a „Convenience“ (pohodlí zákazníka). Mezi základní principy moderního marketingu patří snaha o dosažení oboustranně prospěšného vztahu mezi dodavatelem a zákazníkem, navození dlouhodobé spolupráce s každým konkrétním zákazníkem a jeho udržení, kvalita produktu i zákaznické podpory definovaná zákazníkem, nabídka komplexních služeb (ne pouze jednoho produktu), co nejvyšší rychlost odezvy, či intenzívní osobní kontakt a pravidelná oboustranná komunikace mezi dodavatelem a odběratelem. Stěžejním přístupem této etapy je právě CRM [4, str. 12 – 13].

9

Hlavní změnou v marketingu v několika posledních desetiletích je tedy zejména přesun orientace z produktu, který podnik produkuje a nabízí na trhu, na zákazníka, který daný produkt poptává. Tento přesun je znázorněn na obr. 1.3.

obr. 1.3 Změna orientace z produktu na zákazníka, zdroj: [4, str. 46]

1.4.2 Vztah marketingu a CRM dle míry personalizace Trochu jiný pohled na vztah marketingu a CRM nabízí Lošťáková [5]. Ta se zaměřuje na vývoj jednotlivých marketingových strategií, které jsou založené na míře personalizace marketingu. Prvotní strategie masového marketingu nerespektuje prakticky žádné rozdíly mezi jednotlivými zákazníky a ke všem přistupuje stejně. V praxi je použitelná ve chvíli, kdy jsou rozdíly v potřebách jednotlivých zákazníků minimální a nejsou mezi nimi významné demografické rozdíly [5, str. 14 – 15]. Druhou strategií je cílení na vybrané segmenty trhu, kdy jsou zákazníci na základě podobností (demografických, geografických atd.) rozděleni do různých segmentů a v rámci segmentu je na ně nahlíženo jako na celek. Cílení může mít různé přístupy, od cílení na velký segment (zaměří se na segment trhu s největší poptávkou), přes cílení na sousední segmenty (podnik již obsluhuje jeden segment, jehož potenciál byl vyčerpán, a zaměří se na podobný segment), mnoho segmentů (snaha podchytit co nejvíce různých segmentů trhu, přičemž

10

ke každému z nich se přistupuje jinak), malý segment (ignorovaný velkými konkurenty, kde ale podnik má velké možnosti ho ovládnout), tržní mikrosegment (jakýsi „výklenek“ uvnitř jednoho segmentu, kdy někteří zákazníci sice spadají do daného segmentu, ale vybočují v rámci některých vlastností, např. geograficky), až po cílení na subsegmenty (dělení segmentů na další časti dle jiných kritérií, než podle kterých byl trh rozdělen na hlavní segmenty) [5, str. 15 – 18]. Poslední strategií, používanou v marketingu, je strategie řízení vztahu s jednotlivými zákazníky (CRM). Ta se vyznačuje individuálním přístupem ke každému zákazníkovi, zejména v přizpůsobení produktu a zvláštních službách s produktem spojených, individuální komunikací a také zvláštních cenových nabídkách. Tato strategie vyžaduje vyšší úsilí a také zvyšuje náklady alokované pro marketing. Proto je nesmírně důležité, aby přinášela odpovídající výnosy. I tato strategie má několik typů, přičemž je běžné, že se používá kombinace všech a míra přizpůsobení se jednotlivým zákazníkům se liší podle aktuálního či celkového očekávaného přínosu pro podnik [5, str. 18]. Masová personalizace rozpoznává jednotlivé zákazníky podle jména, adresy a předchozího nákupního chování. Na základě těchto údajů jsou zákazníkovi nabízeny standardní produkty, ale zákazník má dojem, že je o něho pečováno individuálně. Tento přístup je vhodný pro méně významné zákazníky, kteří jsou pro podnik z dlouhodobého hlediska teoreticky postradatelní [5, str. 18]. O úroveň výše je masová customizace, díky které podnik rozpozná zákazníky ochotné připlatit si za zvláštní služby či konfiguraci výrobků, a ty jim následně nabídne výběrem z množiny standardních produktů. Tento přístup se hodí pro zákazníky, kteří jsou z pohledu podniku středně důležití [5, str. 18]. Posledním přístupem je diferencovaná customizace, která stojí na vrcholu pomyslné pyramidy úrovně personalizace. Jednotlivým zákazníkům jsou upraveny jak produkty, tak i způsob jejich distribuce

11

a forma komunikace. Zákazník úzce spolupracuje s producentem a významně se podílí na tvorbě výsledného produktu, takže ten přináší zákazníkovi výrazně vyšší přidanou hodnotu, než produkt standardní. Tento přístup se používá pro spolupráci se zákazníky, kteří mají z pohledu podniku velmi významné postavení a jsou pro podnik z dlouhodobého hlediska nepostradatelní [5, str. 18 – 19]. Každá z výše popsaných marketingových strategií přináší různě vysokou hodnotu pro zákazníka, a ovlivňuje také hodnotu a výkonnost podniku. Vztah mezi těmito veličinami a grafické znázornění jednotlivých strategií je na obr. 1.4. Z obrázku je na první pohled vidět, že strategie diferencované customizace z dlouhodobého hlediska přináší jak nejvyšší hodnotu pro zákazníka, tak nejvíce podporuje výkonnost a hodnotu samotného podniku.

obr. 1.4 Strategie marketingu dle míry personalizace, zdroj: [5, str. 14]

12

1.5 Procesy CRM a obchodní cyklus 1.5.1 Základní obchodní cyklus Obchodní cyklus ve společnosti sestává ze čtyř základních kroků, které jsou na sebe navázány tak, jak je znázorněno na obr. 1.5.

obr. 1.5 Obchodní cyklus, zdroj: autor, inspirováno [6, str. 34]

Celý cyklus začíná marketingovými aktivitami, jejichž cílem je oslovit potenciální zákazníky a zjistit zájem o nabízené produkty. Mezi základní marketingové aktivity patří řízení kampaní (resp. jejich celého životního cyklu), řízení zdrojů (čas, peníze a lidské zdroje) a využívání různých komunikačních kanálů (masmédia, telefon, e-mail, klasická pošta atd.). Výsledkem této fáze by měl být seznam potenciálních zákazníků, kteří projevili o produkt zájem, a se kterými je možno dále pracovat [6, str. 33]. Následně probíhá mezifáze, kdy dochází k výběru obchodních příležitostí ze seznamu potenciálních zákazníků. Tato fáze je v některých společnostech součástí marketingových aktivit, jinde jde již o aktivitu prodejní – proto je zařazena na rozhraní obou těchto fází. Zároveň se jedná nejspíš o nejdůležitější fázi celého procesu, která rozhoduje o jeho úspěchu či neúspěchu. Zkoumá se např. míra projeveného zájmu, finanční situace zákazníka (alespoň rámcově), a také se hodnotí schopnost podniku vyhovět všem požadavkům zákazníka [6, str. 33].

13

Po výběru vhodných obchodních příležitostí začínají prodejní aktivity. Pokud jde podniku o větší a dlouhodobější kontrakt, může dojít k několika schůzkám s potenciálním zákazníkem, na kterých se dolaďují detaily kontraktu, podmínky dodávky produktu (či produktů), a obecně se hledá řešení, které bude vyhovovat oběma stranám. Ideálním zakončením této fáze je podpis kontraktu mezi (nyní již) zákazníkem a dodavatelem [6, str. 34]. Ve chvíli, kdy je podepsána smlouva, může dojít k samotnému plnění objednávky. Tato fáze se liší případ od případu, kdy plnění může být jednorázové, opakované, dlouhodobé i krátkodobé – záleží na konkrétní smlouvě a podmínkách, které si zákazník vyjednal. Závěrečnou fází obchodního cyklu je servis. Nejedná se pouze o servis ve smyslu záručních oprav, ale zejména o udržování kontaktu se zákazníkem. Je možné zákazníkovi posílat informace o nově nabízených produktech, zajišťovat nadstandardní služby (takové, které nebyly předmětem kontraktu), nebo mu nabídnout nový kontrakt [6, str. 34].

1.5.2 Komplexní obchodní cyklus Výše popsaný obchodní cyklus je řešen zejména z pohledu front-office. V reálném prostředí do celého cyklu vstupuje daleko více faktorů a stále častěji jsou zapojeny i procesy back-office (např. fakturace, logistika, interní právní služby atd.). V rámci CRM by měly být všechny tyto procesy dostatečně propojeny, aby vycházely vstříc zákazníkovi a nekomplikovaly jeho nákup. Zároveň by jednotlivé procesy měly navzájem komunikovat, a to jak uvnitř podniku, tak s externím zákazníkem. Zjednodušené znázornění komunikace všech procesů je na obr. 1.6. Aby celý proces fungoval, musí být splněno několik základních předpokladů. Prvním je schopnost dodavatele přizpůsobit se zákazníkovu nákupnímu cyklu – tedy být flexibilní. Druhým předpokladem je co nejkratší doba, kterou průběh celého obchodního cyklu zabere, aby byl kontrakt dokončen co nejrychleji. Proto je důležité zejména mít podrobně definované a dokumentované jednotlivé podprocesy, které je

14

třeba mezi sebou efektivně koordinovat. Velice také záleží na úrovni a rychlosti komunikace mezi jednotlivými pracovníky a odděleními podniku [6, str. 35 – 37].

obr. 1.6 Komplexní procesy CRM, zdroj: [6, str. 35]

1.5.3 Vývoj procesů CRM Procesy CRM, podobně jako jakékoliv jiné procesy, nejsou statické a v čase se vyvíjí. Úroveň procesů můžeme rozdělit do tří kategorií. Nepropojené procesy jsou většinou na počátku zavádění CRM do podniku. Nemají stanoveného vlastníka, jsou vágně definovány a mnohdy si i vzájemně protiřečí, nemají jasně stanovené metriky pro jejich hodnocení, nespolupracují navzájem (jsou izolované), nemají jednoznačně stanovená pravidla (dochází k jejich různorodým variacím) a nereflektují reálný business či strategii podniku [6, str. 45 – 46]. O něco lepší jsou pragmaticky uspořádané procesy. Ty mají většinou stanoveného vlastníka i základní cíle a definice, jsou vesměs dodržovány (pokud není k jejich porušení dobrý důvod), mají stanoveny

15

základní metriky pro hodnocení jejich výkonu, alespoň částečně navzájem komunikují a reflektují reálný stav podniku [6, str. 46]. Nejvýše postavené jsou integrované procesy. V tomto případě mají všechny procesy vlastníka, jsou stanoveny cíle motivující ke spolupráci s ostatními procesy (i zákaznickými), mají stanovené metriky i pro měření výkonnosti kombinací jednotlivých provázaných procesů, procesy jsou mezi sebou vysoce integrovány a aktivně podporují strategii a vizi podniku [6, str. 46].

16

2 CRM systémy Na rozdíl od obecné definice CRM jsou definice CRM systému poměrně jednotné. Podle kolektivu autorů [10, str. 210] CRM systém „představuje komplex aplikačního a základního software, technických prostředků, podnikových procesů a personálních zdrojů určených pro řízení a průběžné zajišťování vztahů se zákazníky firmy, a to v oblastech podpory obchodních činností, zejména prodeje, marketingu a zákaznických služeb.“ Jak z definice vyplývá, stěžejním úkolem CRM systému je podpora obchodních procesů. K tomu využívá základních funkcionalit, mezi které patří průběžné sledování požadavků zákazníků a jejich chování, evidence současných zákazníků a jejich hodnocení, vytváření nových obchodních příležitostí, udržování dlouhodobých vztahů se zákazníky, analýzy zákazníků na základě všech možných hledisek, a řízení marketingových kampaní na základě výše uvedených analýz a informací o zákaznících [10, str. 210].

2.1 Postavení CRM systému v podnikovém IS CRM systém v podniku není izolovaný od ostatních systémů, ale naopak by s nimi měl být úzce integrován tak, jak znázorňuje obr. 2.1. Jak je z tohoto schématu patrné, CRM systém spojuje samostatné aplikace pro řízení marketingu, prodeje produktů a řízení služeb zákazníkům do jednoho komplexního systému. Obdobně ERP systém integruje dříve samostatné aplikace pro zpracování objednávek, řízení logistiky (interní uvnitř podniku i externí k zákazníkům) či řízení výroby produktů. V současné době do rámce ERP systému většinou spadá také fakturace, účetnictví a řízení plateb (přijatých i odesílaných). Další aplikace, jako jsou systémy pro řízení lidských zdrojů, systémy pro řízení administrativy či systém pro řízení nákupu, mohou stát mimo ERP systém, ale aktuálním trendem je pokrytí všech těchto částí jedním komplexním systémem. Systém pro řízení dodavatelských řetězců zajišťuje spolupráci s obchodními partnery a dodavateli pomocí analýzy tržní

17

poptávky, sledováním zdrojů kapacit a plánováním potřeby zdrojů. Obdobně systém pro řízení prodejních řetězců pomáhá spolupráci s distributory a dealery pomocí řízení cenové a smluvní politiky či automatizovaným řízením nabídky. V centru celého podnikového IS se nachází aplikace pro integraci podnikových aplikací (EAI), která zajišťuje sběr dat z jednotlivých součástí celého systému. Nad těmito daty potom mohou probíhat různé analýzy a predikce vývoje, které zajišťuje systém pro aplikaci řízení znalostí, pro který se v současné době více používá pojem Business Intelligence. Na základě informací z tohoto systému může vrcholový management společnosti přijímat strategická rozhodnutí, která se týkají celého podniku [6, str. 26 – 28], [11].

obr. 2.1 Postavení CRM v podnikovém IS, zdroj: [11]

18

2.2 Klasifikace CRM systémů Kompletní nabídku CRM systémů na trhu můžeme rozdělit do tří skupin na základě komplexnosti a oborového zaměření. První skupinou jsou All-in-One systémy, které pokrývají veškeré klíčové procesy CRM. Mezi výhody těchto systémů patří vysoká úroveň integrace procesů a vysoká nabídka různých funkcí. Nevýhodou je mnohdy nízká využitelnost všech nabízených funkcionalit, a také vysoké náklady na pořízení. Do této skupiny systému se řadí celosvětově nejrozšířenější CRM systémy, jako jsou produkty společnosti SalesForce.com, dále např. SAP CRM, produktová řada Oracle CRM či Microsoft Dynamics CRM [12, str. 398 – 401]. Druhou skupinou jsou systémy Best-of-Breed, jejichž typickým znakem je orientace na specifické obory, případně na některé procesy. Většinou nepokrývají veškeré CRM procesy, i když náklady mohou být podobné jako při zavedení All-in-One systému. Také je často nutné realizovat více projektů pro zavedení komplexní funkcionality. Na druhou stranu velkou výhodou těchto systémů je špičková a detailní funkcionalita v daném oboru. Pokud tedy chce podnik pokrýt veškeré CRM procesy pomocí špičkových produktů, je možné sáhnout po kombinaci několika Best-of-Breed systémů. Mezi tuto skupinu můžeme zařadit systémy SAS (zaměřený na marketing a CI – viz kap. 2.4.3) nebo myAVIS (zaměřený na mobilní obchod) [12, str. 398 – 401]. Poslední skupinou jsou Lite CRM systémy neboli odlehčené verze CRM systémů. Ty pokrývají pouze základní funkcionality a často jsou součástí přímo ERP systému (nejedná se o integraci ERP a CRM systému, ale speciální modul ERP systému, který se zaměřuje na základní CRM procesy). Výhodou těchto řešení je nízká pořizovací cena, která je ale na druhou stranu vykoupena nižší nabídkou funkcí. V rámci skupiny Lite CRM jsou nabízeny systémy Jazzman CRM či EasyCRM, které cílí na malé podniky a živnostníky, nebo Helios CRM, který je součástí řady ERP systémů Helios[12, str. 398 – 401].

19

2.3 Koncepce CRM systémů Dle Sodomky [12, str. 364] koncepce CRM „určuje, jak prostřednictvím IS/ICT vhodně využít obousměrnou vícekanálovou komunikaci a jak efektivně řídit všechny procesy, o něž se organizace dělí se zákazníkem“. Výsledkem vhodné koncepce CRM systému by mělo být sladění a efektivní využití obousměrné vícekanálové komunikace, efektivní řízení a optimalizace externích podnikových procesů (obchod, marketing, řízení kontaktních údajů či servis), správné porozumění požadavkům zákazníků podniku a předvídatelnost poptávky, zjednodušení a zkvalitnění řízení podniku ze strany managementu a obecně zefektivnění CRM po celou dobu jeho životního cyklu [12, str. 364].

2.3.1 Typy CRM koncepce Koncepce CRM se dá v zásadě navrhnout třemi základními způsoby. Globální koncepce CRM je typická pro velké nadnárodní korporace. Vyznačuje se jednotným typem všech CRM procesů napříč všemi divizemi podniku. S výjimkou legislativních požadavků nevyžaduje speciální přístup k produktům, službám a klientům v různých zemích. Zároveň jsou na ni kladeny minimální nároky na lokalizaci, s výjimkou využití jazyků používaných v jednotlivých zemích [12, str. 365]. Lokální koncepce je naopak využívána zejména menšími podniky, i když je použitelná i pro ty větší. Každý trh, na kterém podnik působí, má vlastní specifické CRM řešení a každá pobočka má vlastní katalogy zákazníků a produktů. Pokud existuje zastřešující oddělení pro jednotlivé pobočky, většinou určuje pouze pravidla pro globální strategii CRM, zatímco ostatní činnosti jsou prováděny na jednotlivých pobočkách [12, str. 365]. Mezičlánkem mezi předchozími dvěma typy koncepce CRM je globální, lokálně uzpůsobená koncepce CRM. Ta je používána jak velkými, tak menšími podniky na trzích, kde se musí vyrovnat se specifickými podmínkami, i když jinak používají globální koncepci. Využívají

20

ji ale také společnosti, které se rozrůstají z místních trhů na další. Typickým znakem této koncepce je globálně nasazený CRM systém, který ale vyžaduje výrazné lokální úpravy jak procesů, tak např. workflow a dalších funkcí. Často se stává, že místo jednotného CRM systému jsou použity menší, které lépe vyhovují lokálním podmínkám, a ty jsou následně propojeny do komplexního CRM portfolia [12, str. 365].

2.3.2 Strategická pravidla koncepce CRM Pokud chce podnik realizovat nějakou z koncepcí CRM systému popsaných výše, měl by se držet čtyř základních pravidel [12, str. 366]. Prvním ze základních pravidel je pravidlo sjednocení, které říká, že vůči všem zákazníkům musí podnik vystupovat jednotně a informace o zákaznících musí sloužit všem zaměstnancům. Zákazník může zvolit jakýkoliv z komunikačních kanálů, ale obdržené informace musí být konzistentní. Stejně tak musí být konzistentní informace o jednotlivých zákaznících napříč celým podnikem [12, str. 366]. Druhé pravidlo je pravidlo integrace informačních toků putujících vně i dovnitř podniku přes veškeré CRM procesy. CRM systém by měl být propojen s dalšími informačními systémy v podniku (zejména ERP systémem), aby nemuseli zaměstnanci hledat parciální data o zákaznících v jiných systémech. Ideální je, když data ze všech systémů tečou do jednoho datového skladu, nad kterým je možné provádět různé analýzy, a ty následně využít v CRM systému [12, str. 366 – 367]. Technologickým problémem může být splnění pravidla naplnění. Při implementaci CRM systému je ho totiž potřeba naplnit daty, se kterými bude následně pracovat (údaje o zákaznících, záznamy telefonátů a další komunikace se zákazníkem), a navíc jednotlivá data musí být roztříděna do kategorií. To ale může být problém zejména u podniků, které do této doby CRM systémem nedisponovaly, a které data o zákaznících nijak formálně neudržovaly. Přitom vhodná vstupní data jsou základem každého systému, protože na nich záleží, do jaké míry bude možné CRM systém využívat [12, str. 367].

21

Posledním pravidlem je pravidlo segmentace, podle kterého každý zákazník tvoří samostatný segment trhu, a proto by k němu mělo být přistupováno individuálně [12, str. 367 – 368].

2.4 Architektura CRM systému CRM systém se obecně skládá ze tří hlavních součástí – operační, kooperační a analytické. Každá z těchto částí bude rozebrána podrobněji. Propojení jednotlivých částí CRM systému a jeho celková architektura je znázorněna na obr. 2.2.

obr. 2.2 Architektura CRM, zdroj: [6, str. 60]

2.4.1 Operační část CRM Do operační části CRM spadají veškeré softwarové aplikace řešící operativní záležitosti. Řadí se sem funkce pro podporu řízení obchodních kontaktů a jednotlivých obchodních případů, tvorba marketingových kampaní a plánů, analýza a sledování konkurence, či sledování požadavků na zákaznický servis a jejich vyhodnocování [10, str. 211].

22

Základních aplikací operační části je několik. První z nich je SFA (podpora prodejních aktivit), do níž spadají nástroje pro řízení kontraktů, podpora prodejní činnosti (např. řízení obchodních případů nebo předpovědi obratu), řízení příležitostí a generování nabídek či analýza konkurence. SFA umožňuje obchodníkům mít přehled o tom, v jakém stádiu se nachází který obchodní případ, či co je potřeba udělat dále. Také by jim měla pomoci s vykazováním práce [6, str. 60 – 61]. Druhou aplikací je EMA (podpora marketingových aktivit), jenž pomáhá s vytvořením, plánováním, ohlášením, startem, monitorováním, ukončením a vyhodnocením marketingových kampaní. Mezi další funkce EMA patří generování a sledování potenciálních zákazníků nebo segmentace a integrace kampaní [6, str. 62]. Poslední aplikací v rámci operačního CRM je CSS (podpora servisních aktivit). Umožňuje zjistit dostupnost náhradních dílů a jejich rezervaci, udržuje kalendář pravidelných preventivních servisních prohlídek u jednotlivých zákazníků, a také je jejím prostřednictvím plánováno nasazení pracovníků u jednotlivých zákazníků. Všechny tyto údaje jsou zároveň sdíleny v reálném čase [6, str. 62 – 63].

2.4.2 Kooperační část CRM Kooperační část nabízí funkce pro komunikaci se zákazníkem i s okolím podniku. Patří sem veškeré možnosti pro komunikaci, ať už se jedná o telefon, poštu, fax, osobní schůzky, e-maily či interaktivní weby. Kromě komunikace se zákazníky může kooperační část CRM nabídnout také funkce pro spolupráci s obchodními partnery. Následně je možné při propojení systémů jednotlivých podniků sdílet data o zákaznících a tato data využívat pro vlastní potřeby podniku [6, str. 64]. Vše může být koordinováno pomocí kontaktních center (případně call center), která sbírají veškerou komunikaci se zákazníkem, aktualizují údaje, rozesílají marketingové materiály, a obecně integrují veškeré možnosti komunikace do jednoho místa [10, str. 211]. Mezi základní funkce kontaktních center patří alokace pracovníků, kontrola kvality

23

služeb, řízení příchozích a odchozích hovorů, přidělování oprávnění jednotlivým pracovníkům, zapisování záznamů o provedených servisních zásazích, sběr objednávek, a také tvorba předběžných nabídek nebo výkaznictví za různé zaměstnance [6, str. 66].

2.4.3 Analytická část CRM Poslední součástí CRM systému je analytická část, díky které je možné z agregovaných dat o zákaznících a procesech zjistit informace použitelné pro další řízení vztahů se zákazníky. Umožňuje analyzovat marketingové kampaně, predikovat chování jednotlivých zákazníků či vytvořit segmenty pro lepší cílení marketingové kampaně na méně významné zákazníky. Analytická část využívá dat z operační a kooperační části CRM systému a v případě potřeby také z dalších podnikových systémů, jako je ERP [10, str. 211 - 212]. Základem pro využití dat je jejich centralizace do jedné databáze, tzv. centrální znalostní báze zákazníků. Nad touto databází následně probíhají pokročilé analýzy, jejichž výsledkem je detailní poznání zákaznických preferencí a nákupních zvyků [6, str. 63]. Pro zpracování dat se většinou využívá technologií Business Intelligence (BI), které analyzují data na základě různých dimenzí (časových, geografických, dle zákazníků, produktů, služeb, obchodníků, zakázek, konkurentů, dodavatelů, či dle porovnání plánu a skutečnosti). Dimenzí může být ohromné množství a každý z uživatelů CRM systému si může zvolit ty, které jsou pro něj relevantní [6, str. 83 – 91]. Využití BI technologií v CRM systému se označuje jako Customer Intelligence (CI). CI se primárně zaměřuje na analýzy dat sebraných z integrací se zákazníky, přičemž využívá standardních procesů a zdrojů z CRM systému. Jedná se tedy o důležitou funkcionalitu CRM systému zaměřenou na poznání zákazníka, jeho preferencí, hodnoty pro podnik, rizikovosti nebo možnosti odchodu ke konkurenci. Díky využití CI je možné zvyšovat zákaznickou loajalitu, s čímž se pojí také zvyšování objemu obchodu a příjmů podniku [6, str. 92 – 95].

24

2.5 Přínosy implementace CRM systému CRM systém by neměl být v podniku implementován jen proto, aby se dalo říct „Máme v podniku CRM systém“, ale aby přinesl nějaké výhody. Celkovým efektem by mělo být zejména udržení a ideálně i zvyšování obratu podniku a následně i neustálé zvyšování zisku. Některé z přínosů se projeví téměř ihned po implementaci systému, některé z nich až po relativně dlouhé době jeho využívání. Konkrétní přínosy rozebírá ve své knize Wessling [7]. Prvním přínosem je bezproblémový průběh obchodních procesů. Data o zákaznících jsou udržována v jediné databázi, díky čemuž jsou propojeny všechny spolupracující oblasti (marketing, odbyt, služby atd.) pomocí nově definovaných procesů a za podpory informačních technologií. Následně nedochází k průtahům při zpracování procesů v jednotlivých odděleních, ani mezi odděleními navzájem. Jednotlivé obchodní procesy jsou také efektivnější, levnější, a zaměřují se na to, co je přínosem pro zákazníka [7, str. 60]. Dalším přínosem je zvýšení individuálních kontaktů se zákazníky, kdy dochází k vytvoření opravdu individuálních kontaktů s každým jednotlivým zákazníkem. Důležitý je přechod z masového marketingu (reklamy v televizi, masmédiích, na internetu atd.) k individuálnímu marketingu (telefonické oslovení, personalizované webové stránky, personalizované e-mailové kampaně atd.) při stejném nebo podobném množství zákazníků [7, str. 60 – 61]. Třetím přínosem zavedení CRM systému je získání více času na zákazníka ne přijímáním nových zaměstnanců, ale dosažením časových úspor při stávajících kapacitách. Díky efektivnějšímu průběhu jednotlivých procesů a snížení času potřebného na vyřízení administrativy je možné ušetřený čas investovat do budování kvalitnějšího vztahu se zákazníkem, např. díky častějšímu osobnímu kontaktu [7, str. 61]. Velice důležitým přínosem je odlišení se od konkurence, což souvisí s ostatními zmíněnými přínosy. Podnik, který implementoval

25

CRM systém a začal ho správně využívat, má častěji lepší vztahy se svými zákazníky, než podnik bez implementovaného CRM systému. Zde je ale nutno podotknout, že změnu nepřináší samotný CRM systém, ale změna procesů a filozofie obchodování s ním spojená. Druhou podstatnou podmínkou je plné využití všech možností, které CRM systém nabízí, včetně integrace jeho jednotlivých součástí [7, str. 61]. Ruku v ruce s odlišením se od konkurence jde také vylepšení image podniku. Díky efektivnějším procesům a lepší vztahům se zákazníky získává podnik lepší obraz mezi ostatními potenciálními zákazníky. Často k tomu dochází díky osobnímu doporučení stávajících zákazníků, kteří pochválí výborné služby podniku, a ty následně chtějí využít i další zákazníci. Druhým aspektem je vyšší důvěra zákazníků ve schopnosti podniku, která se v dlouhodobém horizontu vyplácí výrazně více, než krátkodobá snaha o maximální zisk [7, str. 61 – 62]. Mezi další přínosy patří přístup k informacím v reálném čase, ať už se jedná o informace o počtu prodejů, reakcích zákazníků na služby, získání nových zákazníků, nebo třeba počtu aktivit oddělení odbytu a servisu. Díky CRM systému jsou všechny tyto informace dostupné v reálném čase. Ve výsledku tedy může management podniku přijímat rozhodnutí výrazně rychleji než dříve a na případné problémy zareagovat rychle, nebo jim dokonce předejít. [7, str. 62] Pro plánování jsou důležité spolehlivé a rychlé předpovědi, které jsou dalším přínosem implementovaného CRM systému. Ty využijí ke své práci jak pracovníci odbytu, tak vedoucí různých pracovních skupin i top management podniku. Jakákoliv nenadálá změna je v systému evidována v reálném čase a ihned se projeví v informacích systémem poskytovaných. Navíc díky řízení oprávnění je možné omezit, jaké informace a v jakém rozsahu daný uživatel uvidí. Pokud jsou navíc pevně

stanovena

pravidla

pro

vytváření

předpovědí,

dochází

k výraznému snížení, mnohdy až k eliminaci rizika, že bude proveden chybný odhad a podnik následně přijde o zákazníka [7, str. 62].

26

Velký problém mnohdy nastává, pokud spolu musí komunikovat zaměstnanci z různých oddělení. Dalším přínosem implementovaného CRM systému je zvýšení úrovně komunikace mezi odbytem, marketingem a službami. To samozřejmě nenastane automaticky, ale až po proškolení personálu, správné transformaci procesů a vysvětlení výhod využívání CRM systému všemi stranami [7, str. 62 – 63]. Kromě lepší komunikace mezi jednotlivými odděleními dochází také k efektivnější spolupráci v rámci jednotlivých týmů. To je opět způsobeno zefektivněním jednotlivých procesů, kdy data získaná od jednoho zaměstnance jsou ihned dostupná dalším. Aktivity tak mohou probíhat výrazně rychleji a někdy i paralelně, což dříve nebylo obvyklé, mnohdy ani možné [7, str. 63]. Posledním přínosem implementace CRM systému je růst motivace pracovníků. Právě díky efektivnějším procesům a snížení administrativní zátěže mohou obchodníci pracovat na osobním vztahu se zákazníkem, marketing má rychleji vyhodnocené informace, servis může jednodušeji zajišťovat vysokou kvalitu služeb, a všichni používají nástroj, který jim práci usnadňuje a urychluje. To ale samozřejmě platí za předpokladu úspěšné implementace vhodného CRM systému a kvalitního proškolení uživatelů, kteří se následně s novým systémem ztotožnili [7, str. 63].

2.6 Kvalita CRM systému Jak píše Wessling ve své knize [7, str. 30], „kvalita CRM je dána šancí zákazníka dosáhnout stavu, kdy se nárok a úroveň poskytnutých služeb rovnají.“ Důležité je tedy zejména to, jak vnímá úroveň služeb samotný zákazník. Pokud úroveň nabízeného produktu odpovídá nárokům na něj kladeným, je kvalita CRM vysoká. Pokud ale úroveň služeb za požadovanými nároky zaostává, je kvalita CRM nízká [7, str. 30 – 32]. Kvalita CRM je graficky znázorněna na obr. 2.3.

27

obr. 2.3 Kvalita CRM, zdroj: [7, str. 30]

2.6.1 Prvky kvality CRM systému Mezi základní prvky kvality CRM patří možnosti zákazníka pro přístup k dodavateli z technologického pohledu. Do této kategorie se řadí míra využití prostředků, jako je kamenný obchod, telefon, fax, internet, email, či call centrum, a také šíře možností využití různých komunikačních kanálů [7, str. 31]. Druhou dimenzí kvality CRM je kompetentnost personálu, který se zákazníkem spolupracuje. Zákazník očekává rychlé a profesionální řešení svého problému, a proto by kontaktovaný pracovník měl mít odpovídající znalosti. Samozřejmě ne každý zaměstnanec může znát úplně vše, proto je důležité zajistit přístup k potřebným informacím (ideálně v reálném čase), případně vědět, na koho se pracovník, a potažmo i zákazník, může obrátit [7, str. 31 – 32]. Třetím prvkem zajištění kvality CRM je rychlost obchodních procesů. Při využití call centra se zákazník nedovolá přímo na požadované pracoviště, ale kontaktní osobě. Ta by následně měla zajistit zpracování požadavku, předání na příslušné místo, a dohlédnout na jeho vyřešení. To vše by mělo probíhat co nejrychleji, aby zákazník nemusel

28

dlouho čekat. Zároveň by se podnik (resp. řešitel problému nebo pracovník call centra) měl zákazníkovi zpátky ozvat sám s možným řešením problému, místo toho aby zákazník musel volat znovu [7, str. 32]. Poslední dimenzí kvality CRM jsou data o zákaznících a jejich požadavcích, která by měla být dostatečně podrobná a dostupná v reálném čase zejména pracovníkům call centra. Hodnocení kvality této dimenze ze strany zákazníka probíhá hlavně na základě rychlosti získání daných dat, a také podle jejich relevance [7, str. 32].

2.6.2 Zajištění kvality CRM systému Vhodné kvality systému CRM je dosaženo ve chvíli, kdy zákazník má možnost využít požadovaných služeb, a to v jím požadovaném rozsahu. Na šíři nabídky služeb samozřejmě záleží, ale pokud je jich příliš mnoho a každá z nich je poměrně povrchní, může být nabídka vnímána stejně negativně, jako nedostatek služeb [7, str. 33]. Hodnocení kvality služeb se také vyvíjí v čase, spolu s rozvojem komunikačních technologií a nových možností, které přináší moderní svět. Zatímco v dobách, kdy se internet teprve rozvíjel, byla možnost objednávky produktu přes internet strategickou výhodou, nyní jde již o standardní a nepostradatelnou službu. Obdobně zatímco dříve se zákazník od pracovníka call centra dozvěděl maximálně číslo, na které může zavolat a třeba se dočká vyřešení problému, v současné době je standardem nejen přímé přepojení na specialistu, ale ten má i k dispozici popis problému a může okamžitě začít s jeho řešením [7, str. 32 – 33]. Wessling ve své publikaci [7] nabízí několik kontrolních témat, na která by se měl management zodpovědný za řízení CRM v podniku zaměřit, aby zjistil úroveň kvality CRM. Mezi tato témata patří znalost nároků jednotlivých zákazníků, nabídka moderních možností přístupu k produktům, které zákazníci chtějí a mohou využívat, úroveň kvalifikace pracovníků front-office (zejména call center) jak z pohledu komunikace se zákazníkem, tak i hlediska odborného, a případně jestli vědí, kde naleznou potřebné informace. Dále je důležitým tématem znalost

29

obchodních procesů a jejich úroveň a také zajištění kvality údajů o jednotlivých zákaznících [7, str. 33].

2.7 Měření výkonnosti CRM systému Aby top management podniku zjistil, jestli CRM systém funguje tak jak má, musí měřit jeho výkonnost. Cílem měření CRM systému by tedy mělo být posouzení jeho aktuální úrovně a zjištění možností pro jeho další vylepšení [4, str. 127]. Objektivní měření výkonnosti systému CRM může přinést podniku několik zásadních výhod. Tou první je nutnost propracovanější strategie a s tím spojená i vyšší důvěra zaměstnanců v danou strategii. Měření také vede ke sjednocení komunikace ohledně strategie a klíčových faktorů CRM systému směrem k zaměstnancům. Ti jsou tak více ztotožněni s firemními cíli a jsou také loajálnější k podniku, což je velice důležité pro jejich dlouhodobé udržení. Měření výrazně zvyšuje podíl úspěšných změn a zrychlení celého procesu. Další výhodou měření výkonnosti CRM systému je vyšší možnost a schopnost předvídat problémy, protože vedoucí pracovníci dostávají včas informace o špatné funkčnosti procesů či celého systému. V neposlední řadě měření usnadňuje sledování dlouhodobého vlivu prováděných změn na jednotlivé úseky podniku, protože přináší komplexní pohled na zdánlivě nepropojené procesy v různých částech podniku [4, str. 127 – 128].

2.7.1 Oblasti měření výkonnosti Chlebovský [4, str. 129] rozlišuje čtyři základní skupiny aktivit, na které by se mělo zaměřit hodnocení výkonnosti CRM systému. Tyto oblasti jsou budování a řízení značky, budování a řízení nabídky, kontaktní aktivity a měření komplexních ukazatelů vývoje. V rámci budování a řízení značky by se podnik měl zaměřit hlavně na zjištění povědomí o značce mezi jednotlivými zákazníky (jestli značku vůbec znají, případně kolik z nich ji zná a dokáže si ji vybavit), asociací spojených se značkou, případně jestli jsou pozitivní ne-

30

bo negativní, a také na vnímání kvality značky mezi zákazníky a jejich loajalitu ke značce. Pro ohodnocení těchto faktorů je vhodné použít různé metody marketingového výzkumu, např. dotazníky. Dále by měl podnik ohodnotit finanční hodnotu značky, pokud je možné ji finančně vyčíslit. K tomu se dá využít sledování přímých i nepřímých investic a také nákladů spojených s budováním značky [4, str. 129 – 130]. Hodnocení budování a řízení nabídky by se mělo zaměřit na analýzy hodnoty nabízeného produktu pro zákazníky (porovnání ceny a kvality oproti konkurenci), k čemuž může využít kvalitativní výzkumy zaměřené na vnímání hodnoty produktu ze strany zákazníka. Sledování loajality zákazníků i zaměstnanců a akcionářů je též důležité, dá se zjistit z analýz tržeb a počtů zákazníků dle různých skupin. Jako poslední oblast se dá sledovat spokojenost zákazníků s realizovanými obchody [4, str. 130]. Oblast kontaktní zákaznické aktivity je většinou nejlépe zvládnuta a také nejjednodušeji měřitelná. Z hlediska klasického marketingu se měří dosah kampaně (kolik zákazníků bylo osloveno) a reakční procento (kolik zákazníků reagovalo) spolu s mírou konverze (kolik zákazníků skutečně nakoupilo). Poté je možné sledovat náklady na získání jednoho zákazníka (absolutní či relativní vzhledem k nákladům na kampaň), průměrnou velikost objednávky nebo také podíl zisku z jednoho zákazníka na rozpočtu. Dalším hlediskem jsou prodejní aktivity, u kterých se dá měřit pravděpodobnost úspěchu, z finančního hlediska je možnost hodnotit prodejní náklady a výsledky prodeje pro jednotlivé kategorie produktů, a dále je možné také sledovat hodnocení stávajících zákazníků, statistiky nových zákazníků pro různé kategorie produktů a statistiky kontaktů s jednotlivými zákazníky [4, str. 131 – 132]. Další oblastí v rámci kontaktních aktivit jsou servisní a podpůrné aktivity, kde můžeme sledovat počet telefonátů a jejich délku (případně počet přerušených a blokovaných telefonátů), průměrnou čekací dobu zákazníků, průměrné náklady na telefonát či průměrnou délku hovoru.

31

Ze všech těchto veličin se dá odvodit výkonnost call centra. Z pohledu servisu je možné sledovat reakční dobu odpovědi na požadavek, dobu servisního úkonu vedoucí k vyřešení problému, či úroveň spokojenosti zákazníků se servisem. Měřit se dají také internetové aktivity, kde se sleduje počet (jedinečných) návštěvníků, nejčastěji navštěvované stránky, průměrná doba strávená na stránkách podniku nebo počet registrovaných uživatelů [4, str. 132 – 133]. Poslední oblastí kontaktních aktivit jsou logistické operace, u kterých se vytváří statistiky míry plnění objednávky (co bylo objednáno a co bylo opravdu dodáno), dodržení požadovaného nebo slíbeného termínu, procenta nesplněných objednávek, celkové doby potřebné pro realizaci objednávky, nebo se vyhodnocuje spolehlivost procesu a jeho celková zásobovací perioda u objednávek produktů, které podnik nemá aktuálně na skladě a musí je objednat [4, str. 133]. Měření komplexních vývojových ukazatelů pomáhá predikovat budoucí vývoj výkonnosti firmy na základě vyhodnocení finančních ukazatelů (strategie růstu a ziskovosti z pohledu vlastníků podniku), zákaznických ukazatelů (strategie tvorby hodnoty z pohledu zákazníků) a ukazatelů rozvoje a růstu (strategie tvorby interního prostředí pro podporu nutných změn) [4, str. 134].

2.8 CRM systémy v ČR a ve světě Nabídka různých CRM systémů je celosvětově velice široká. Kromě několika systémů, které uspěly napříč všemi kontinenty, se většinou jedná o řešení lokálních dodavatelů. Jednotlivé systémy jsou nabízeny jak specializovanými společnostmi, které se zaměřují výhradně na produkci CRM systémů, tak zejména dodavateli komplexních podnikových řešení, kteří nabízejí CRM systém jako součást balíku aplikací pro řízení podniku. Právě komplexní řešení je většinou výhodou pro zákazníka, protože odpadají problémy s integrací různých systémů od různých dodavatelů, a komplexní řešení také bývá většinou levnější, než kombinace několika systémů od různých dodavatelů.

32

2.8.1 CRM systémy ve světě Dle analýzy společnosti Gartner z dubna roku 2013 [13] byla v roce 2012 lídrem na celosvětovém trhu CRM systémů společnost SalesForce.com se 14 % podílu. Následují společnost SAP, dosavadní dlouhodobý lídr trhu, a dále velcí hráči na poli podnikového software i hardware – Oracle, Microsoft a IBM. Tyto společnosti dohromady ovládají téměř polovinu celého trhu, jejich jednotlivé podíly jsou na obr. 2.4.

obr. 2.4 CRM systémy ve světě, zdroj: autor, inspirováno [13]

Společnost SalesForce.com je zdaleka nejmladší z výše uvedených společností, i přesto se poměrně rychle stala lídrem na trhu CRM systémů. Založena byla v roce 1999 jako malý start-up v Kalifornii v USA a již od počátku se zaměřovala na poskytování CRM služeb v prostředí cloud computingu. Kromě ocenění jako nejlepší CRM systém od různých společností je SalesForce.com také považována za jednu z nejinovativnějších společností na světě. Nabízené služby pokrývají kompletní životní cyklus CRM (prodej, servis, marketingové kampaně atd.) včetně platformy, na které mohou správci podnikového IT postavit vlastní aplikace navíc k nabízeným službám [14], [15]. Německá společnost SAP AG byla založena roku 1972. Proslavila se především svým komplexním ERP systémem, který byl jedním z prvních řešení podobného druhu na světě a dodnes je celosvětově nejpoužívanější s čtvrtinovým podílem na trhu ERP systémů. Společ-

33

nost obsluhuje více než 250 tis. zákazníků ve 188mi zemích světa a zaměstnává přes 66 tis. pracovníků. Systém SAP CRM je součástí balíku podnikových aplikací SAP Business Suite, do kterého dále ještě patří ERP systém, řešení pro řízení vztahů s dodavateli (SRM), řízení dodavatelského řetězce (SCM) a řízení životního cyklu výrobku (PLM). Všechny tyto aplikace jsou navzájem úzce integrované, přičemž hlavně integrace se SAP ERP systémem je velice důležitá. Mezi hlavní funkcionality SAP CRM patří řízení marketingu, prodeje a servisu, řízení partnerských kanálů, řízení komunikačního centra, řízení obchodní komunikace, možnost zřízení webového kanálu či řízení nabídek produktů v reálném čase. SAP CRM je možné nasadit jak na vlastních zdrojích zákazníka, tak provozovat pomocí technologií cloud computingu na straně dodavatele [16], [17], [18], [19]. Společnost Oracle Corporation byla založena roku 1977 v Kalifornii v USA. Na rozdíl od společností SalesForce.com a SAP AG se nezaměřuje pouze na podnikový software, ale její pole působnosti je výrazně širší – nejvíce se proslavila vlastním systémem řízení báze dat a vlastní databázovou platformou, ale nabízí i vlastní ERP řešení nebo hardware. Na světovém trhu s ERP systémy dlouhodobě zaujímá druhé místo s tržním podílem kolem 13 %. Oracle CRM je sada aplikací pro řízení vztahů se zákazníky (za zmínku stojí People Soft CRM, Siebel CRM nebo CRM on Demand), které se dají implementovat jak klasicky na straně zákazníka, tak i pomocí technologií cloud computingu. Komplexní nabídka produktů pokrývá celou oblast CRM a podobně jako v případě SAP AG je možné CRM systém jednoduše integrovat s Oracle ERP a dalšími systémy [16], [20], [21]. Microsoft je další ze severoamerických společností, která působí na trhu podnikového software. Byla založena roku 1975 a proslavila se zejména operačním systémem Windows, který je (v různých verzích) nainstalován na naprosté většině všech osobních počítačů po celém světě. Druhým nejvýznamnějším produktem je balík kancelářských aplika-

34

cí Office, který se v průběhu času stal standardem pro vytváření dokumentů na počítači. Z pohledu podnikových aplikací je podstatná řada produktů Microsoft Dynamics, do které se řadí ERP systémy AX a NAV a CRM systém (Microsoft Dynamics CRM), se kterými společnost pokrývá 5 % celosvětového trhu s ERP systémy. Obdobně jako ostatní zde zmíněné systémy, i tento obsahuje všechny funkcionality očekávané od CRM systému, navíc ještě např. aplikaci pro analýzu sociálních sítí, která prozatím není standardem (ale se vzrůstající důležitostí sociálních sítí se dá očekávat, že se brzy stane součástí většiny CRM systémů). Zároveň i tento systém jde s dobou, a tak nabízí přístup k aplikaci pomocí tenkého klienta, mobilní přístup a možnost využití technologií cloud computingu. Výhodou je zabudovaná integrace na oblíbené nástroje jako Microsoft Office, Microsoft SharePoint, Skype či Yammer (aplikace pro vytvoření vnitropodnikové sociální sítě) [16], [22], [23]. Poslední z velkých celosvětových dodavatelů CRM systémů je, opět severoamerická, společnost IBM. Na rozdíl od ostatních zmíněných společností, IBM si vybudovala reputaci zejména na poli hardwaru a s ním souvisejících služeb. Od roku 1888, kdy byla založena, mezi její největší úspěchy patří uvedení jednoho z prvních osobních počítačů na celosvětový trh a také vysoce spolehlivých mainframů, které jsou používané pro kritické podnikové aplikace. Obdobně tak pro CRM systémy IBM spíše nabízí platformu pro instalaci některého z dostupných systémů a vlastní experty a konzultanty, než aby nabízela vlastní CRM systém. Dle webových stránek má společnost uzavřeno strategické partnerství se společnostmi Oracle, SAP, Avaya nebo open source aplikací SugarCRM. Dle nejnovějších nalezených informací (září 2013) společnost IBM prodala kompletní CRM infrastrukturu společnosti Concentrix Corporation, která ji tak nahradila na pátém místě na světě mezi poskytovateli CRM systémů [24], [25], [26], [27]. Jak je z výše uvedených informací patrné, existuje jistá korelace mezi celosvětovým trhem CRM systémů a ERP systémů. S výjimkou

35

lídra trhu SalesForce.com jsou tři následující společnosti významnými poskytovateli také ERP systémů (dohromady ovládají 43% trhu [16]). Osobně zde vidím souvislost se vzrůstající důležitostí ERP systémů v podniku a také s rozšiřováním funkcí ERP systémů – již dávno se nejedná jen o plánování podnikových zdrojů, jak tomu bylo dříve, ale ERP systémy již nyní podporují významnou část podnikových aktivit. Právě nabídka CRM systému nativně jednoduše integrovatelného s ERP systémem od stejného dodavatele (ať již nově implementovaným, nebo aktuálně využívaným) je pro velkou část podniků nesmírně lákavá, zejména z finančního hlediska. Dodavatelé ERP systémů mají částečnou výhodu oproti společnostem specializovaným pouze na CRM systémy. Tito specializovaní dodavatelé tedy musí zaujmout zákazníky buď nižší cenou při zachování vysoké kvality systému, nebo nabídkou lepších služeb a většího množství kvalitních funkcí.

2.8.2 CRM systémy v ČR Na českém trhu je dle přehledu [28] dostupných 96 CRM systémů. Bohužel se nepodařilo dohledat statistiky, které CRM systémy jsou mezi podniky na českém trhu nejrozšířenější. Podobně jako na světovém trhu, i v České republice očekávám částečnou korelaci mezi využíváním ERP a CRM systémů v podnicích. Na rozdíl od celosvětového trhu s ERP systémy, ten český má úplné jiného lídra. Je jím česká společnost Asseco Solutions, která nabízí řadu produktů značky Helios. Byla založena roku 1990 a od té doby se propracovala na pozici největšího poskytovatele ERP systémů na českém trhu mezi podniky všech velikostí. Součástí portfolia podnikových produktů je také Helios CRM pro řízení všech CRM procesů (zejména marketingu, obchodních procesů, servisu a služeb). Výhodou tohoto systému je úzké provázání s některým z ERP systémů Helios, a také nadstavbová řešení pro řízení workflow, toku dokumentů, propojení na e-shop či možnost mobilního přístupu k systému [29], [30], [31].

36

Dalším významným poskytovatelem ERP systémů na českém trhu je společnost J.K.R. proslavená systémem BYZNYS ERP, který zaujímá přední místo mezi ERP systémy v podnicích všech velikostí. Společnost byla založena roku 1991 a působí na území České republiky a Slovenska. V rámci svého systému BYZNYS ERP nabízí také CRM modul pro podporu marketingových a obchodních procesů. Nenabízí tedy samostatný CRM systém, ale některé z CRM procesů jsou pokryty specializovaným modulem, který je součástí ERP systému [29], [32], [33]. Obdobně další významní dodavatelé poskytují CRM moduly ve svých ERP systémech. Mezi ně se řadí česká společnost K2 Atmitec se svým systémem K2, jenž obsahuje integrovaný CRM modul. Stejně tak obsahuje CRM modul ERP systém QI od české společnosti DC Concept, dalšího významného dodavatele ERP systému na českém trhu. Posledním z významných dodavatelů ERP systémů, kteří nabízejí vlastní CRM řešení, je společnost ABRA Software se systémem ABRA, opět obsahujícím CRM modul [29], [34], [35], [36]. Kromě lokálních poskytovatelů jsou na českém trhu dostupné také celosvětově rozšířené CRM systémy, které byly zmíněny v předchozí kapitole. Systém od společnosti SalesForce.com není v České republice tolik rozšířen jako jinde ve světě, ale i tak ho využívá několik set společností. V současné době plánuje vyšší expanzi v rámci celé Evropy a Česká republika není výjimkou [37]. Rozšířené jsou také CRM systémy SAP CRM, Microsoft Dynamics CRM nebo SugarCRM poskytovaný na platformě společnosti IBM.

37

3 Řízení projektů 3.1 Projekt Projekt je definovaný jako „dočasné úsilí provedené za účelem vytvoření jedinečného produktu, služby nebo jiného výsledku“1 [38, str. 3]. Opakem projektu jsou potom provozní činnosti sloužící k udržení chodu firmy – ty, na rozdíl od projektu, nekončí ve chvíli, kdy je dosaženo cíle [39, str. 20]. Za projekt se dá označit vše, co trvá omezenou dobu a výsledkem je nějaký unikátní produkt – napsání diplomové práce, postavení domu, návrh nového prototypu vozidla, nebo implementace ERP systému.

3.1.1 Atributy projektu Výše uvedená definice projektu je poměrně obecná, podrobnější popis jednotlivých atributů nabízí ve své knize Schwalbe [39], která rozlišuje šest základních atributů projektu. Prvním atributem je, že projekt má jedinečný účel, který je jednoznačně definován cílem projektu. Výsledkem projektu je potom unikátní produkt, služba nebo jiný výstup [39, str. 22]. Druhým atributem projektu je jeho dočasnost. Každý projekt musí mít jednoznačně zadaný začátek a konec [39, str. 22]. Projekt se také vytváří postupným rozpracováním. Na začátku je projekt většinou definován velice široce a obecně a v průběhu času se jednotlivé jeho části upřesňují a stávají se jasnějšími [39, str. 22 – 23]. Důležitým aspektem projektu je také fakt, že vyžaduje zdroje, které jsou často z různých oblastí. Mezi zdroje řadíme lidský kapitál, hardware, software, případně další prvky potřebné ke zdárné realizaci projektu. Tyto zdroje jsou většinou alokovány jednotlivým oddělením

v originále „A project is a temporary endeavor undertaken to create a unique product, service, or result.“, přeložil autor 1

38

v podniku i mimo něj, ale v rámci projektu je třeba tyto zdroje přiřadit nehledě na jejich obvyklé zařazení [39, str. 23]. Každý projekt by také měl mít zákazníka nebo sponzora. Sponzor nebo zákazník hraje v rámci projektu významnou roli, protože určuje jeho směr a obvykle poskytuje finance pro jeho plnění [39, str. 23]. Posledním atributem projektu je, že jeho součástí je nejistota. Každý projekt je unikátní a někdy je obtížné definovat jeho cíle a správně odhadnout harmonogram nebo potřebný rozpočet. Vliv mohou mít i externí faktory (např. dodavatel může zkrachovat) nebo špatný výběr projektového týmu. Právě z důvodu této nejistoty bývá velice složité dovést projekty ke zdárnému naplnění [39, str. 23].

3.1.2 Trojimperativ Pod pojmem projektový trojimperativ se rozumí tři základní dimenze každého projektu, které musí být splněny, aby byl projekt považován za úspěšný. Tyto tři dimenze jsou rozsah (co je potřeba udělat), čas (jak dlouho bude projekt trvat) a náklady (kolik bude stát realizace celého projektu). Z principu jsou všechny tyto tři dimenze protikladné, jak je vidět z obr. 3.1. Pokud tedy chce projektový manažer zvládnout všechny tři dimenze, musí mezi nimi dělat kompromisy. Pro dosažení rozsahu v daném čase může nastat potřeba navýšit rozpočet, pro splnění rozpočtu v daném čase je možné redukovat rozsah projektu, a pokud chce manažer dosáhnout daného rozsahu v daném rozpočtu, může to zabrat více času. Vždy se tedy musí určit nejdůležitější dimenze, které se následně ostatní dimenze mohou přizpůsobit [39, str. 23 – 24]. Kromě tří základních dimenzí do projektu vstupují ještě další vlivy. Jedním z nejdůležitějších faktorů úspěchu projektu je kvalita výsledného produktu a s ní související spokojenost sponzora či zákazníka projektu. Proto je možné, že i za splnění všech tří dimenzí trojimperativu neskončí projekt úspěchem. Tomuto případu se dá vyhnout kvalitním řízením projektu, které bude brát na zřetel nejenom trojimperativ, ale i další vlivy do projektu vstupující [39, str. 24 – 25].

39

obr. 3.1 Trojimperativ, zdroj: [39, str. 25]

3.1.3 Životní cyklus projektu Životní cyklus je soubor po sobě jdoucích projektových fází, který definuje, co a kdy je potřeba udělat, kdo to má udělat, jaké výstupy je potřeba dodat, a kdo a jak bude jednotlivé fáze projektu kontrolovat, hodnotit a schvalovat [39, str. 70]. Životní cyklus projektu je graficky znázorněn na obr. 3.2. Každý projekt se obecně skládá ze čtyř fází, přičemž platí, že v dřívějších fázích je nejvyšší stupeň nejistoty, ale zároveň největší možnost ovlivnit finální výstupy projektu. Čím později dojde k významným změnám v projektu, tím je jejich dopad nákladnější a ve výsledku mohou celý projekt významně prodražit. Přechod do další fáze projektu by měl nastat až ve chvíli, kdy byla úspěšně dokončena fáze předchozí. To ale není vždy možné, a tak se v praxi stává, že se v průběhu projektu přeskakuje z jedné fáze do druhé [39, str. 70 – 71]. První dvě fáze se souhrnně zabývají proveditelností projektu. Iniciální fáze celého projektu se nazývá návrh. Výstupem z této fáze by měl být popsaný obchodní případ, tedy zdůvodnění projektu a jeho výchozí myšlenky, dále by měl být proveden předběžný odhad celkových nákladů na projekt, a také jednoduchý rámcový přehled činností, které musí být v průběhu projektu provedeny [39, str. 71].

40

Druhá fáze je naplánování projektu. V průběhu této fáze jsou do detailu dovedeny jednotlivé výstupy, které byly získány ve fázi návrhu. Je tedy proveden detailní návrh rozpočtu, celý projekt je přesně rozplánován do podrobného projektového plánu, a také je provedeno vysoce detailní rozčlenění jednotlivých činností [39, str. 71 – 72]. Zbylé dvě fáze se společně zabývají akvizicí projektu. Nejprve nastává fáze implementace. Právě v této části projektu probíhá jeho samotná realizace, přičemž jednotlivé zainteresované strany jsou průběžně informovány o aktuálním stavu projektu, případných problémech a dalších záležitostech, které se projektu týkají. Zároveň s realizací projektových cílů probíhá také detailní odhad nákladů, případně je realizován definitivní rozpočet [39, str. 71 – 72]. Závěrečnou fází celého projektu je dokončení. V této fázi jsou již všechny práce hotovy a zákazník by je měl schválit (pokud projekt naplnil jeho představy). Projektový tým se zamýšlí nad projektem a dokumentuje vlastní zkušenosti v hodnotící zprávě. Následně je celý projekt vyhodnocen a je možné si z něho vzít poučení pro realizaci dalších projektů v budoucnu [39, str. 71 – 72].

obr. 3.2 Životní cyklus projektu, zdroj: autor, inspirováno [39, str. 71]

3.1.4 Úspěch projektu Za úspěšný je možné považovat takový projekt, který splní tři základní kritéria: podařilo se naplnit trojimperativ (tedy projekt byl proveden v plném rozsahu, za rozpočtovou cenu, a v rámci daného časového plánu), zákazník nebo sponzor byl s projektem spokojen (členové týmu byli vstřícní, nápomocní, ochotní, projekt nenarušil každodenní chod podniku atd.) a výsledky projektu naplnily jeho hlavní účel (vydělal

41

nebo ušetřil peníze, zajistil možnost návratu investice, učinil sponzory nebo zákazníky šťastné atd.) [39, str. 30]. Úspěchu projektů napomáhá hned několik kritérií. Dle výzkumu, který každý rok provádí americká společnost Standish Group, vede k úspěchu zejména zapojení uživatelů do projektu a podpora vedení společnosti. Mezi další kritické faktory úspěchu patří jasná definice cílů a požadavků na projekt kladených a také realistická očekávání, co projekt má přinést, vhodné naplánování projektu, kratší milníky pro splnění jednotlivých částí projektu, kompetentní projektový tým složený z pracovitých a zaujatých zaměstnanců, a v neposlední řadě také vlastnictví projektu projektovým manažerem a jednoznačně stanovená vize a cíle podniku [40]. Kromě výše uvedených kritérií je důležité také odhlédnout od projektu samotného a podívat se na problematiku komplexněji. Jak uvádí Schwalbe [39], existují čtyři základní rozdíly mezi podniky, které jsou v řízení projektů úspěšné, a těmi ostatními. Prvním rozdílem je využívání integrované sady nástrojů, metod a technik pro řízení projektů, které jasně definují, co má být uděláno, kým, kdy a jak. Tyto nástroje jsou pečlivě vybrané a propojené s vhodnými metrikami. Druhým rozdílem je podpora rozvoje projektových manažerů, protože ti jsou pro úspěch projektů klíčoví. Úspěšné podniky také rozvíjí a usměrňují proces řízení projektů na základě analýz již provedených projektů. Každý z projektů má obdobné etapy a milníky a jednotliví projektoví manažeři sdílejí své zkušenosti navzájem. Posledním rozdílem je měření projektů pomocí vhodných metrik, dle kterých jsou jednotlivé projekty kvantifikovány a vyhodnocovány [39, str. 31 – 32].

42

3.2 Projektové řízení Projektové řízení se definuje jako „aplikace znalostí, dovedností, nástrojů a technik na projektové aktivity za účelem splnění požadavků projektu“2 [38, str. 5]. Jak bylo popsáno v předchozí kapitole, projektový manažer se nesmí soustředit pouze na splnění projektového trojimperativu, ale musí při řízení projektu brát ohled i na další vlivy. Kromě kvality výsledného produktu do projektového řízení vstupují i další vlivy, jako je uspokojení potřeb a očekávání lidí, kteří na projektu pracují, i dalších lidí vstupujících do projektu nepřímo. Mezi osoby, kterých se projekt více či méně dotkne, patří projektový sponzor, celý projektový tým včetně projektového manažera, podpůrný personál (asistentky, administrativní pracovníci, zaměstnavatelé externích pracovníků atd.), zákazníci, dodavatelé, uživatelé či oponenti projektu. Zainteresovaných osob je mnoho a každá z nich má jinou motivaci a jiný zájem na projektu, takže projektový manažer musí brát ohledy na všechny z nich a ideálně s nimi navázat dobré vztahy od začátku projektu [39, str. 25 – 27].

3.2.1 Znalostní oblasti projektového řízení Existuje několik základních oblastí, které musí projektový manažer znát, aby mohl úspěšně řídit projekty. Mezi základní znalosti patří řízení základních dimenzí projektu, tedy řízení rozsahu (definice a řízení všech prací, které jsou nutné ke zdárnému dokončení projektu), řízení času (odhady doby trvání jednotlivých činností, vypracování přijatelného harmonogramu a zajištění včasného dokončení projektu), řízení nákladů (příprava rozpočtu, jeho sledování a případná aktualizace) a řízení kvality (projekt uspokojí všechny potřeby, které uspokojit má) [39, str. 27]. Kromě těchto základních znalostí musí projektový manažer také disponovat dalšími, podpůrnými znalostmi, které pomáhají dosáhnout v originále „Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.“, přeložil autor 2

43

cílů projektu. Sem se řadí řízení lidských zdrojů (efektivní využívání lidského kapitálu, který se účastní projektu), řízení komunikace (vytváření, sběr, distribuce a archivace všech informací, které se vztahují k projektu), řízení rizik (identifikace, analýza a reakce na rizika, která v průběhu projektu mohou nastat) a řízení dodávek (zajištění zboží a služeb, které jsou potřebné pro zdárné dokončení projektu, a které se získávají od externích dodavatelů) [39, str. 27 – 28]. Poslední znalostní oblastí je integrované řízení projektu. To překlenuje všechny ostatní činnosti, ovlivňuje je a zároveň je jimi samo ovlivňováno [39, str. 28]. Vztah všech znalostních oblastí projektového řízení je znázorněn na obr. 3.3.

obr. 3.3 Rámec projektového řízení, zdroj: [39, str. 26]

3.2.2 Nástroje a techniky projektového řízení Kromě znalostí z jednotlivých oblastí se musí také projektový manažer orientovat v různých nástrojích a technikách pro projektové řízení. Ty pomáhají projektovým manažerům a jejich týmům s realizací komplexních projektů. Každá z výše uvedených znalostních oblastí má několik technik a nástrojů, které pomáhají s jejich řízením [39, str. 28]. Pro oblast integrovaného řízení projektu jsou nejčastějšími technikami a nástroji podpůrný software pro řízení projektu (např. MS Project) včetně plánů řízení projektu, hodnotící zprávy pro management

44

společnosti a pro sponzora projektu, řízení změn projektu na základě aktuálního stavu, projektové smlouvy, porady a schůzky týmu ke kontrole aktuálního stavu projektu, nebo případně změnová komise, která rozhoduje o změnách v projektu [39, str. 28]. V rámci řízení rozsahu projektu je možné využít deklaraci rozsahu projektu, která může být rozdělena pomocí WBS (hierarchické struktury prací), dále SOW (definice cílů a rozsahu prací), analýzu požadavků nebo plány řízení rozsahu [39, str. 28]. Řízení času je podpořeno ganttovými diagramy, metodou síťové analýzy, metodou kritické cesty a případně monitorováním stavu projektu z hlediska času [39, str. 28]. Pro řízení nákladů jsou použity ekonomické veličiny, jako je NPV (čistá současná hodnota), ROI (návratnost investice), EVM (řízení získané hodnoty), analýza návratnosti, odhady a plánování nákladů nebo směrné plány rozpočtu [39, str. 28]. Techniky a nástroje pro řízení kvality jsou metriky kvality, kontrolní seznamy a diagramy kvality, Paretovy diagramy, diagramy rybí kosti nebo metody zralosti [39, str. 29]. Řízení lidských zdrojů využívá různých motivačních technik, empatického naslouchání, matice zodpovědnosti, různých schémat organizace projektu a histogramů zdrojů a velice oblíbené, zejména u pracovníků, jsou teambuildingové aktivity [39, str. 29]. V rámci řízení komunikace se používají komunikační plány, na začátku projektu by také měl proběhnout tzv. kick-off meeting, následně se odevzdávají pravidelné reporty o stavu postupu projektu a důležitým je také výběr vhodných komunikačních médií [39, str. 29]. Pro řízení rizik jsou využity plány řízení rizik, registry rizik, metriky pravděpodobnosti a případného dopadu, pokud se riziko stane realitou, a v neposlední řadě také hodnocení rizik [39, str. 29]. Řízení dodávek je podpořeno analýzou vlastní síly, různými smlouvami s dodavateli, souhrnem požadavků na návrhy smluv a na-

45

bídky, musí také dojít ke správnému výběru zdrojů, a v neposlední řadě by se měly využívat metriky pro hodnocení dodavatelů [39, str. 29].

3.2.3 Standardy řízení projektů Aby každý projektový manažer nemusel vymýšlet již vymyšlené, používají se best-practices, které se osvědčily v minulých úspěšných projektech. Využívání globálně uznávaných přístupů vede k vyšší efektivitě projektů, zvyšuje pravděpodobnost jejich úspěchu a snižuje riziko výskytu problémů [41]. Jednotlivé best-practices jsou sloučeny do standardů řízení projektů. Existuje celá řada různých standardů pro řízení projektů, lokálními standardy používanými v jednom podniku počínaje, a celosvětově uznávanými konče. Mezi ty celosvětově využívané patří zejména standardy ICB (IPMA Competence Baseline), PMBoK®Guide (A Guide to Project Management Body of Knowledge) a PRINCE2 (Projects in Controlled Environments 2nd version). Nejstarším a jedním z nejpoužívanějších standardů projektového řízení je IPMA Competence Baseline (ICB). Standard je udržován a aktualizován společností International Project Management Association (IPMA), která byla založena roku 1965 ve Švýcarsku a v současné době zastřešuje 55 národních asociací. Hlavním posláním společnosti je podporovat osobnostní a profesionální růst jejích členů, propagovat hodnoty projektového řízení či angažovat se při definování standardů. Pro dosažení svých cílů využívá společnost systému certifikace projektových manažerů různých úrovní, přičemž dosažení každé z úrovní je podmíněno složením písemné zkoušky a prokázáním odpovídajících zkušeností s projektovým řízením. Úrovně certifikace jsou čtyři, od nejnižší úrovně D (Projektový praktikant – je schopný pracovat v týmu a splnit úkol), přes úroveň C (Projektový manažer – je schopen řídit několik pracovníků v rámci organizace a řídit projekty s omezenou komplexitou), úroveň B (Projektový senior manažer – je schopen řídit pracovníky napříč organizacemi a komplexní projekty), k nejvyšší možné

46

úrovni A (Ředitel projektů – je schopen komplexně řídit portfolio nebo program projektů) [42], [43], [44], [45]. Druhým standardem řízení projektů je A Guide to Project Management Body of Knowledge (PMBoK®Guide), vydaný v knižní podobě společností Project Management Institute (PMI), která se zabývá jeho aktualizací a údržbou (aktuálně je vydaná 5. verze). Společnost byla založena roku 1969 a jejím cílem je, podobně jako u IPMA, napomáhat profesionálnímu růstu svých členů, zvyšovat pravděpodobnost jejich úspěchů v každodenním osobním i pracovním životě, a šířit povědomí o projektovém řízení pomocí mezinárodně uznávaných certifikátů a standardů. Podobně jako IPMA tedy nabízí certifikace projektových manažerů, kteří tak mohou prokázat získané znalosti a zkušenosti z různých částí celého oboru řízení projektů. Certifikací je k dispozici celkem šest. Úroveň Program Management Professional (PgMP) prokazuje znalosti a zkušenosti v oblasti řízení portfolií a programu projektů, Project Management Professional (PMP) je nejvyšší dosažitelná úroveň certifikace řízení projektů, úroveň Certified Associate in Project Management (CAPM) je určena speciálně pro členy projektových týmů, PMI Scheduling Professional (PMI-SP) prokazuje znalosti a zkušenosti uchazeče v oblasti plánování projektu, PMI Risk Management Professional (PMI-RMP) zase prokazuje profesionalitu uchazeče v oblasti řízením identifikace a hodnocení rizik, a poslední úroveň PMI Agile Certified Practicioner (PMI-ACP) získá uchazeč po prokázání zkušeností a znalostí z oblasti agilního projektového řízení [46], [47]. Posledním globálně uznávaným standardem řízení projektů je Projects in Controlled Environments 2nd version (PRINCE2). Původním záměrem tohoto standardu bylo nastavit jednotné procesy pro řízení IT projektů ve státní správě Velké Británie, ale postupem času a po několika revizích (poslední proběhla v roce 2012) se tento standard začal využívat jak ve státní správě dalších zemí (Nizozemí, Dánsko, Austrálie atd.), tak i v nadnárodních organizacích (NATO) či v komerč-

47

ní sféře. Kromě IT se také využívá pro řízení projektů ve finančních službách, stavebnictví, či v neziskovém sektoru. Základem standardu je soubor poměrně obecných best-practices, které se následně musí upravit pro potřeby konkrétního projektu v konkrétním oboru. Podobně jako ostatní standardy, i společnost Axelos (současný správce standardu) nabízí možnost získat certifikaci prokazující znalost řízení projektů dle této metodiky. V nabídce jsou tři úrovně certifikací – Foundation pro všechny, kteří mají co do činění s řízením projektu, Practitioner pro projektové manažery se zkušenostmi s řízením projektů, a Professional pro zkušené profesionály, kteří dosáhli předchozího stupně a mají zkušenosti s řízením projektů pomocí tohoto standardu [48].

48

4 Projekt implementace informačního systému do podniku Přístupy popsané v kapitole 3 se dají použít pro řízení téměř libovolného projektu. Jejich obecnost je ale zároveň jejich největší slabinou, protože každý obor má svá specifika, která se musí odrazit i v řízení projektů. Informační technologie nejsou výjimkou, a proto je cílem této kapitoly popsat projektové řízení pro specifickou část IT – zavádění informačního systému do podniku. Principy popsané v této kapitole se dají použít jak pro implementaci komplexního systému (typicky ERP systému), ale i pro jeho část, jakou je právě CRM systém. Stejně tak platí jak pro zavádění úplně nového systému, tak pro výměnu stávajícího.

4.1 Základní charakteristiky projektu Projekty implementace podnikového IS mají oproti ostatním projektům několik specifik. Tím prvním je podstatná nehmotná stránka nového produktu, kdy kromě nového hardwaru nebo počítačové sítě dochází zejména ke změnám podnikové kultury a zažitých procesů. Vzhledem k vrozenému strachu z jakýchkoliv změn může právě zde nastat zásadní problém přijetí nového systému. Pro úspěch projektu je tedy důležité, aby byli uživatelé i manažeři podniku dostatečně motivováni k přijetí změny. Nehmotná podstata nového produktu také přináší potřebu důkladného proškolení nových uživatelů a nutnost změny principu práce, na který byli zvyklí. Jen tehdy budou moci využívat nový systém správně a naplno [49, str. 198]. Mezi další specifika projektů implementace informačních systémů do podniku patří vysoká proměnlivost, ovlivnění předchozími zkušenostmi (mnohdy špatnými), nutné sdílení podnikových zdrojů napříč jednotlivými odděleními včetně těch, které s IT oddělením většinou nemají nic společného, a také jejich souběh s dalšími projekty, které v podniku probíhají (např. inovace procesů) [49, str. 199].

49

Mezi typické vlastnosti projektů implementace IS v podniku patří zásah do strategie celého podniku a případně i všech podniků navázaných, a také zásah do organizace podniku. Nové systémy většinou přinášejí výrazný inovační potenciál s velice krátkým cyklem inovací a zároveň formují nové výrobky a služby či nové kanály pro komunikaci se zákazníky i s dodavateli [49, str. 199].

4.2 Životní cyklus projektu Životní cyklus projektu zavádění nového informačního systému do podniku je znázorněn na obr. 4.1. Využití všech jednotlivých etap je závislé na tom, jestli dochází k implementaci úplně od začátku v podniku, který informační systém prozatím nemá, nebo jestli se jedná pouze o výměnu části komplexního podnikového informačního systému a musí se brát ohled i na ostatní komponenty [49, str. 203].

obr. 4.1 Životní cyklus projektu zavádění IS, zdroj: autor, inspirováno [49, str. 203]

4.2.1 Rozhodnutí o změně podnikového IS Prvním krokem k implementaci nového podnikového IS je rozhodnutí o změně stávajícího systému, popř. rozhodnutí o zavedení podnikového IS (pokud podnik do této doby žádný nevyužívá). Prvotním impulzem pro výměnu stávajícího či implementaci nového systému bývá vypracování IT strategie podniku ze strany ředitele informatiky (CIO), která je následně schválena top managementem podniku. Tato strategie

50

by měla být v souladu s dlouhodobou business strategií a vizí podniku, kterou stanovuje právě jeho top management [49, str. 203 – 204]. Rozhodnutí, zda vyměnit, či nevyměnit stávající informační systém, by mělo být přijato na základě důkladné analýzy stávajícího stavu podniku. Výsledkem této analýzy by mělo být jednoznačné zhodnocení, zda je projekt implementace nového podnikového IS vůbec proveditelný, zda vyřeší identifikované problémy, a zda je jeho zavedení finančně profitabilní. Mezi základní činnosti prováděné při analýze současného stavu patří zmapování využívání IT a obecně rozsahu stávajícího informačního systému, zmapování zkušeností uživatelů a určení rozsahu případného zaškolení, ujasnění si strategie podniku (jak informační, tak obecné), a také zmapování současných procesů, organizace podniku, informačních a materiálových toků, a v neposlední řadě by mělo dojít ke zvážení finančních možností podniku [49, str. 204 – 205]. Pro provedení analýzy současného stavu se nejčastěji využívá SWOT analýza silných a slabých stránek podniku, příležitostí a hrozeb. Výsledkem této analýzy může být několik zásadních zjištění, kvůli kterým by mělo dojít k urychlené výměně CRM systému. Nejvýznamnější hrozbou je ohrožení dat o zákaznících, kdy stávající systém může ukládat data ve špatném formátu, duplikovaná, či dokonce nekompletní. Druhou nejvýznamnější hrozbou je neochota uživatelů systém používat z důvodu přílišné komplikovanosti či uživatelské nepřívětivosti. Nad výměnou CRM systému by se také mělo uvažovat ve chvíli, kdy je obtížně rozšiřitelný a integrovatelný s ostatními systémy, případně ve chvíli výměny souvisejícího systému v rámci komplexního podnikového informačního systému. Mezi další důvody k výměně patří rozdělení nebo fúze společnosti, ukončení vývoje aktuálně využívaného CRM systému, vzrůstající nároky na mobilitu uživatelů i systému či přechod na cloudové technologie [50]. Pokud je rozhodnuto o výměně stávajícího systému, nastává další krok, kterým je vytvoření řešitelského týmu. Kromě vedoucího

51

týmu, kterým často bývá samotný CIO či jiný vysoce postavený manažer společnosti, by měly být členy týmu zástupci z každé oblasti podniku, které se nový informační systém dotkne. Tito (budoucí) klíčoví uživatelé jsou důležití, protože jsou profesionály ve svém oboru, a zároveň mají přehled i o ostatních činnostech a dokáží se na problémy podívat ze širšího pohledu [49, str. 206].

4.2.2 Výběr vhodného řešení Druhou etapou implementace podnikového IS je výběr vhodného řešení a jeho dodavatele. Výběr vychází z výsledků analýzy podniku provedené v předchozí etapě. Cíle, které byly analýzou stanoveny, by měly být základem pro zhodnocení jednotlivých systémů, které jsou na trhu dostupné. Zjištění jednotlivých systémů může proběhnout dvěma způsoby. Tím prvním je aktivní přístup, kdy řešitelský tým prochází jednotlivá řešení, hodnotí je, a následně přímo oslovuje potenciální dodavatele s nabídkou. Druhý přístup je pasivní, kdy tým vytvoří poptávkový dokument a ten následně vystaví na internetových stránkách nebo rozešle mezi jednotlivé potenciální dodavatele [49, str. 207 – 211]. Před samotným začátkem výběru by měl řešitelský tým přijmout tři základní rozhodnutí, která výrazně ovlivní výběr mezi jednotlivými alternativami. První otázkou je, jestli výsledný CRM systém má být samostatný, nebo součástí ERP či jiného systému. Mělo by se posoudit zejména, jestli podnik má vlastní ERP systém a jestli funkce, které daný systém z pohledu CRM nabízí, jsou dostačující pro aktualizované potřeby podniku. Druhým rozhodnutím je volba mezi vlastní a pronajímanou infrastrukturou, tedy jestli podnik chce mít kompletní infrastrukturu pod kontrolou, nebo si vystačí s některým z hostovaných přístupů (hosting, outsourcing nebo cloud computing). Poslední rozhodnutí se týká výběru lokálního nebo globálního dodavatele. Globální dodavatelé jsou většinou zralejší, působí na větším trhu, ale také jsou dražší a méně flexibilní. Naopak lokální dodavatelé bývají spíše méně zralí, působí na menších trzích, ale zase jsou levnější a flexibilnější [51].

52

Hlavními činnostmi při výběru vhodného systému je testování potenciálních systémů pomocí zkušebních dat jak u dodavatele, tak přímo v podniku, a také návštěvy potenciálních dodavatelů a návštěvy referenčních zákazníků [49, str. 207]. Vzhledem k ohromnému množství dodavatelů a systémů, které jsou na trhu dostupné, se dá výběr provádět ve dvou krocích. V prvním kroku proběhne vyhodnocení jednotlivých systémů na základě shody funkčnosti s potřebami podniku, referencí a počtu instalací daného systému daným dodavatelem, znalostí, zkušeností, velikosti a zastoupení dodavatele, nebo třeba dle preference určitých platforem (softwarových i hardwarových). Výsledkem by měl být užší výběr několika málo systémů a jejich dodavatelů nejlépe plnících požadované podmínky. Následně probíhá podrobnější analýza vybraných produktů, kdy se do detailu zkoumají jak funkční kritéria samotného systému, tak zejména jeho konkrétní dodavatel. V této fázi je také velice důležitým kritériem výsledná cena implementace – ta by ale nikdy neměla být jediným kritériem výběru vhodného systému [49, str. 207 – 211]. Když je vybrán nejvhodnější systém a jeho dodavatel, může dojít k podpisu smlouvy o dodávce informačního systému. Nejčastěji používaným konceptem je smlouva o dílo, která je ve své podstatě sice velice obecná, ale poměrně podrobně upravená v zákoně. Každopádně by ale smlouva o dodávce informačního systému měla být upravena na míru konkrétnímu vztahu mezi podnikem a dodavatelem [49, str. 211].

4.2.3 Implementace nového IS Jakmile je uzavřena smlouva o dodávce informačního systému, může začít samotná jeho implementace do podniku. Ta většinou probíhá na základě metodiky dodavatele, který má s dodávkami informačních systémů výrazně více zkušeností než podnik samotný, a zaručuje tedy efektivnější průběh celé implementace. Jednotlivé metodiky se mohou lišit, ale vesměs se skládají z podobných částí, které na sebe navzájem navazují [49, str. 212].

53

První částí je analýza specifických podmínek podniku a návrh koncepce informačního systému. Tu provádí dodavatel systému jednak na základě požadavků stanovených v průběhu analýzy podniku, a také podle vlastních zjištění při návštěvách podniku. Tato fáze často probíhá dokonce před samotným uzavřením smlouvy. Výsledná koncepce je většinou písemná a musí být odsouhlasena oběma stranami před samotným začátkem instalace systému. Jejím obsahem je přesný způsob nasazení a nastavení nového systému, ujasnění si všech procesů a pracovních postupů, definice a způsob naplnění číselníků, příprava samotných dat, která budou do nového systému migrována, a také určení datových rozhraní a integrace na ostatní systémy, které jsou již v podniku implementovány, a které tam zůstanou i po přechodu na nový systém [49, str. 212 – 213]. Následuje samotná instalace nového systému, v jejímž rámci může dojít i k nákupu nového hardwaru (pokud není zvolen přístup cloud computingu, nebo podnik nedisponuje dostatečnými zdroji) a softwarových licencí jak k samotnému systému, tak k podpůrným aplikacím (např. MS Office). Zároveň s instalací nového systému probíhá také naplnění číselníků tak, jak bylo stanoveno ve fázi analýzy. Mezi číselníky se řadí např. účetní osnova (včetně jejích úprav pro konkrétní podnik), kódy pracovišť a dalších částí podniku, číselné řady pro faktury, objednávky, nebo třeba seznam všech PSČ, obcí a krajů v České republice [49, str. 212 – 213]. Po instalaci systému a naplnění číselníků začíná testování nového systému. Testování je asi nejdůležitější součástí celého procesu, protože v jeho průběhu dochází k odhalení chyb jak technických (špatně definované číselníky, chyby ve zdrojovém kódu systému, nedostatečně dimenzovaný hardware atd.), tak procesních (špatně nastavené workflow, faktické chyby v nových procesech, neukončené větve atd.) či lidských (podceněné školení některých částí systému, nedostatečné znalosti uživatelů atd.). Přičemž čím dříve k odhalení těchto chyb dojde,

54

tím levnější je jejich odstranění. Nalezení a odstranění co největšího množství chyb (jejich maximální míra dle závažnosti je stanovena v průběhu definice testovacích případů) je také nutnou podmínkou pro převedení testovacího systému do ostrého režimu. Zároveň s celým procesem instalace a nastavování systému probíhá také školení uživatelů nového systému. Začátkem by mělo být přehledové školení top managementu společnosti, aby poznali vlastnosti nového systému a ujasnili si, co od něho mohou očekávat. Následuje školení členů projektového týmu, kteří mají na starosti implementaci systému v podniku. Důležité je také opakované školení koncových uživatelů systému. Těchto školení může být celá řada a měla by být zaměřena zcela konkrétně na oblasti, které koncoví uživatelé využijí. Nejedná se tedy o hromadné školení celého systému pro všechny uživatele, ale spíše o sérii menších školení pro úzké kruhy uživatelů dle jejich zaměření. Ještě podrobněji by měli být proškoleni správci podnikového IT, kteří budou systém po jeho předání spravovat a budou poskytovat podporu jeho uživatelům. Poslední součástí této fáze je také nastavení přístupových práv jednotlivým uživatelům [49, str. 212]. Výsledkem této fáze projektu by měl být instalovaný a nastavený systém, který je připraven pro spuštění do ostrého provozu. Spolu s novým systémem jsou také všichni uživatelé dostatečně proškoleni, aby byli schopni ho využívat [49, str. 214].

4.2.4 Provoz a údržba Ve chvíli, kdy je nový podnikový informační systém nainstalovaný a nastavený, nic nebrání přechodu na nový systém. Pro přechod na nový systém lze využít několika přístupů. Přechod může být jednorázový, kdy je starý systém najednou vyměněn za nový. Druhým přístupem je paralelní přechod, při kterém jsou po určitou dobu využívány starý i nový systém zároveň. Dalším přístupem je postupný přechod, kdy jsou jednotlivé části starého systému (funkcionality, data, případně se přechází po částech podniku) nahrazovány systémem novým, dokud

55

není plně zaveden. Posledním přístupem pro přechod na nový systém je paralelní přechod po částech, který je kombinací předchozích dvou přístupů [49, str. 216]. Jednotlivé principy jsou znázorněny na obr. 4.2.

obr. 4.2 Přístupy k přechodu na nový IS, zdroj: [49, str. 216]

Po úplném přechodu na nový systém následuje převzetí systému do provozní správy. Cílem převzetí nového systému je zajištění efektivního provozu systému, jeho správa, podpora uživatelů a dlouhodobý rozvoj. V rámci převzetí nového systému by mělo dojít k podepsání akceptačního protokolu, který oficiálně stvrzuje převod systému do produkčního prostředí. Akceptační protokol sestává z několika základních dokumentů, mezi které patří akceptace dokumentace jak uživatelské, tak technické, akceptace testů včetně seznamu řešených chyb a chyb, které jsou známé, ale nepodařilo se je v průběhu implementace odstranit. Dále sem patří akceptace pilotního projektu, pokud proběhnul,

56

a akceptace přechodové fáze, která potvrzuje správný převod systému do produkčního prostředí. Mezi další činnosti, které jsou spojené s převzetím systému, patří nastudování systému (v rámci dokumentace, nebo školením administrace a konzultacemi s dodavatelem systému), převzetí funkční instalace systému včetně postupů instalace v různých prostředích, převzetí zdrojových kódů (pokud jsou součástí předání systému), popis konfigurace testovacího a vývojového prostředí, a také postupy pro zálohování a obnovu dat [52]. Projekt implementace nového podnikového IS fakticky končí ve chvíli, kdy je nový systém předán do provozní správy. Tímto krokem ale zároveň začíná každodenní práce na správě nového systému, jeho údržbě a rozvoji. Provoz a údržba systému je tedy závěrečnou fází celého projektu. Projektový tým je již většinou rozpuštěn, ale někteří z jeho členů jsou stále v každodenním kontaktu. Systém je totiž většinou udržován ve spolupráci s dodavatelem na základě servisní smlouvy. V rámci této smlouvy je definován přesný rozsah servisních služeb ze strany dodavatele systému (většinou označovaný jako SLA) a také platební podmínky za poskytované služby (pravidelný měsíční nebo roční poplatek, poplatek za nadstandardní služby atd.). Mezi servisní služby se řadí poskytované záruky na správný chod systému po určitou dobu, pozáruční služby (např. bezplatný update či upgrade systému, garantovaná doba odstranění chyb, e-mailová a telefonická podpora atd.) a nadstandardní služby (rozvoj systému nad rámec poradenství pro rozvoj podniku, pravidelné skenování koncových zařízení proti malware, přístup do znalostní databáze dodavatele atd.). Konkrétní nastavení podmínek a nabízených služeb je ale vždy na domluvě mezi podnikem (resp. potřebami podniku a jeho zaměstnanců) a dodavatelem informačního systému (resp. možnostmi a znalostmi konkrétního dodavatele) [53].

57

4.3 Rizika projektu Podobně jako projekty z ostatních oblastí, i projekty implementace IS v podniku se setkávají se zásadními riziky, která mohou samotný projekt ohrozit. Mezi obecné problémy patří nedodržení trojimperativu (zejména překročení nákladů a nedodržení časového plánu), nutnost sladit priority s ostatními projekty v podniku, které ale mnohdy mohou mít oprávněně vyšší důležitost, a také nedostatek zdrojů ve chvíli, kdy jsou potřeba [49, str. 200]. Kromě těchto rizik, která hrozí každému projektu, existují pro projekty implementace IS i další, specifická rizika. Tím základním je nedostatečná pozornost věnovaná projektu ze strany top managementu a vlastníků podniku. Ve výsledku je přeceněna rychlost, s jakou je možné získat požadované výsledky, a zároveň podceněna doba nutná pro naplnění systému daty. Mezi další specifické problémy lze zařadit nedostatečné proškolení uživatelů, kteří následně nejsou schopni nový systém používat (pokud není opravdu hodně intuitivní), přeceňování výsledků nového systému, které jsou prezentovány uživateli, nedostatečná motivace projektového týmu, a to jak krátkodobá, tak dlouhodobá, včetně ujasnění si pozice po skončení projektu. Dále je možným rizikem výběr nevhodné aplikace (moc široký záběr, úzký záběr, nedokáže vše, co bylo požadováno atd.), nevhodný výběr dodavatele nového informačního systému či špatná komunikace mezi uživateli, vedením podniku a dodavatelem. Dalším z rizik je špatná specifikace požadavků kladených na nový systém. Některým rizikům se dá předejít již v počátečních fázích projektu, což většinou vyžaduje cit ze strany projektového manažera, případně externího konzultanta (pokud se projektu účastní) [49, str. 200 – 201], [50]. Největším rizikem, které může zhatit celý projekt implementace jakéhokoliv informačního systému, je odpor uživatelů ke změně, který následně může vést až k úplnému bojkotu nového systému a jeho obcházení. Toto riziko je při projektu implementace CRM ještě významně

58

vyšší, než u ostatních projektů. Stěžejními uživateli CRM systému jsou obchodníci, kteří jsou většinou zvyklí na volnost a svobodu. Právě nový systém jim ale může tuto svobodu omezit (např. obchodník, který nerad sdílí neoficiální informace o „svých“ zákaznících s ostatními, je najednou musí vkládat do systému, kde se k nim může dostat téměř každý uživatel), což vede k odporu k zavádění nového produktu a následně k odmítání CRM systému jako celku. Tento odpor většinou roste v průběhu implementace nového systému, spolu se vzrůstajícím pochopením toho, co bude zavedení nového systému znamenat. Možným problémům ze strany budoucích uživatelů CRM systému se dá předejít zapojením klíčových uživatelů do procesu výběru nového systému, zjištěním požadavků uživatelů, zejména klíčových funkcí používaných každý den, a také motivací zaměstnanců k účasti na projektu (např. finančním bonusem či posílením pozice v podniku). Pomoci může také plánované postupné zavádění nového systému do podniku, kdy po nějakou dobu uživatelé používají starý systém souběžně s novým a postupně dělají více úkolů v tom novém, čímž získají dostatek času pro adaptaci. V neposlední řadě je také nutné využívání systému zaměstnanci sledovat a ověřovat, že opravdu zadávají data tak, jak mají. Je ale nutné nastavit rozumnou míru sledování zaměstnance, aby se naopak necítil pod přílišným dohledem. Poslední, velice direktivní možností, je nařízení, že co není zadáno v systému, to se nestalo (a nebude to předmětem odměny uživatele). Takto vysoce direktivní přístup by ale měl být až tou úplně poslední možností [7, str. 146 – 150], [54].

4.4 Specifika projektů implementace CRM systému Oproti výše zmíněným informacím ohledně projektu implementace IS v podniku (bez rozlišení, o který systém se jedná) mají projekty implementace CRM systému několik specifik. Právě na ně a na další záležitosti, týkající se výhradně CRM systémů, upozorní tato kapitola.

59

4.4.1 Specifika při výběru vhodného CRM systému Chlebovský ve své knize [4] uvádí několik témat, na která by se měl projektový tým zaměřit při výběru vhodného CRM systému a jeho dodavatele. Následující poznatky vycházejí ze zkušeností dodavatelů CRM systémů a podniků, které CRM systémy úspěšně implementovaly [4, str. 107]. Základním bodem je uvědomit si, jaké jsou dosavadní zkušenosti s CRM v podniku, který chce nový CRM systém implementovat. Pokud nemá podnik jasně stanovenou vizi nebo nemá téměř žádné zkušenosti s CRM, vyplatí se zvážit zapojení externího konzultanta, který příslušnými zkušenostmi disponuje. Důležité je také si uvědomit, o jak velkou organizaci jde. Většinou platí pravidlo: čím větší organizace, tím delší, komplikovanější a dražší celý projekt bude. Poznatky z této fáze by se následně měly projevit při plánování rozpočtu a časového rámce projektu. S tím souvisí i další doporučení – ujasnit si rozsah rozpočtu určeného pro daný projekt. Z něho potom, spolu s velikostí potenciální cílové skupiny zákazníků, vychází plánovaný rozsah nového CRM systému a jeho velikost. Při určování rozsahu CRM systému je možné se podívat ke konkurenci a zjistit, jaký typ systému a jak úspěšně využívají podobné firmy (velikostně, působící na podobném trhu nebo oslovující podobné zákazníky) a zda existuje specializovaný CRM systém pro dané odvětví, který by samotnou implementaci výrazně urychlil. Následně je potřeba si uvědomit, jaké jsou představy o návratnosti investice, tedy za jakou dobu by se měl nový systém zaplatit. Dále které činnosti a na jaké úrovni mají být automatizovány novým systémem (což je další faktor ovlivňující rozsah systému) a s jakými dalšími systémy bude nutné CRM systém integrovat, aby mohl být využit naplno. Tím se projektový manažer vyvaruje situace, kdy bude projekt opožděn a prodražen kvůli nečekaným problémům při komunikaci CRM systému s dalšími aplikacemi [4, str. 107 – 109].

60

4.4.2 Měření efektivity implementace CRM systému Po skončení projektu implementace CRM systému by mělo dojít k jeho vyhodnocení, aby se zjistila jeho efektivita. Jednou z oblastí, na kterou by se mělo hodnocení projektu zaměřit, je efektivita implementace systému. Pro její zhodnocení se dají použít metriky, stanovené sponzorem projektu, které jsou upravené na míru danému projektu. Případně je možné využít mezinárodně uznávaných modelů. Jedním z nich je model CRMBodyCheck, který byl vyvinut poradci ze skupiny GreaterChinaCRM. Tento model je postaven na zkušenostech získaných z praxe v průběhu několika let, a stal se jakýmsi standardem pro hodnocení efektivity implementace CRM systému [55, str. 19]. Základem tohoto modelu je 17 metrik z pěti různých oblastí, přičemž každá metrika má stanovenou váhu, se kterou se k ní přihlíží. Jednotlivé oblasti, metriky a jejich váhy jsou zobrazeny na obr. 4.3.

obr. 4.3 Model CRMBodyCheck, zdroj: autor, inspirováno [55, str. 21]

61

4.4.3 Pravidla úspěchu implementace CRM systému Wessling ve své knize [7] definuje několik základních pravidel, která vedou k úspěšnému projektu implementace CRM systému v podniku. Tato pravidla se zároveň dají považovat za shrnutí celé teoretické části této diplomové práce. Prvním pravidlem je: mysli velkoryse, začínej skromně. Ačkoliv mají projekty implementace CRM strategický význam a zasahují do celého podniku, většinou se vyplatí začít s malou částí (jedním úsekem podniku), následně rozšiřovat systém do ostatních úseků a ve výsledku ho sjednotit na vyšší úrovni řízení [7, str. 158]. Pravidlo druhé hovoří o zapojení zaměstnanců od samotného začátku projektu implementace nového CRM systému. Jak jsem psal v kapitole 4.3, nejvýznamnějším rizikem pro implementaci CRM systému v podniku je odpor jeho uživatelů k jakékoliv změně, vedoucí až k bojkotu nového systému. Díky zapojení klíčových zaměstnanců do projektu od jeho samotného začátku se dá toto riziko eliminovat, a navíc je zajištěna kompatibilita implementace s obchodní strategií podniku [7, str. 158 – 159]. Pravidlo automatizace podle základních požadavků se zabývá mírou využití moderních technologií. Ty jsou sice důležité, ale měly by být využity rozumně. Pokud jsou nároky na technologické řešení příliš vysoké a rozsáhlé, může dojít k významnému zpoždění projektu kvůli implementaci funkcionalit, které ve výsledku nemají téměř žádnou přidanou hodnotu a jsou využívány pouze několika málo uživateli. Možným řešením je implementovat poměrně štíhlý systém, který se dá v dalších fázích rozvíjet [7, str. 159]. Při projektu je třeba také nezapomínat na Paretovo pravidlo 80:20. Jde o poměrně jednoduchý princip, kdy 20 % příčin způsobuje 80 % výsledků (např. 80 % bohatství je v rukou 20 % obyvatel, nebo 20 % příčin generuje 80 % problémů) [56]. Pro projekt implementace CRM systému se dá využít tak, že nalezení správných 20 % zaměstnan-

62

ců, kteří jsou projektu nakloněni, může ovlivnit myšlení zbylých 80 % zaměstnanců. Další využití souvisí s předcházejícím pravidlem, tedy že 20 % všech funkcionalit může přinést 80 % problémů, a proto je potřeba volit jen potřebné funkcionality a problémy řešit ve chvíli, kdy by mezi těmito 20 % byla některá z kritických funkcí systému [7, str. 159]. Důležitou součástí projektu je zkušený vedoucí, který by ideálně měl v podniku pracovat již dlouho a dokonale ho znát. Takový vedoucí potom má jednodušší pozici, napomáhá akceptaci projektu ze strany zaměstnanců, a zároveň je dobrým zdrojem informací pro celý projektový tým. Kromě samotného vedoucího projektu je výhodou, pokud podnik disponuje také zkušeným managementem společnosti. Při implementaci CRM systému nejde pouze o zavedení nového softwaru, ale o významnou procesní změnu, která vede k nutnosti dělat mnohdy nepříjemná rozhodnutí s dalekosáhlými důsledky. Pokud je podnik veden zkušeným managementem, může mít přijímání podobných závažných rozhodnutí menší dopad na situaci v podniku [7, str. 159 – 161]. Aby projekt získal podporu vedení, je dobré mít zástupce v top managementu podniku. Taková osoba je potom schopná prosadit důležitá strategická rozhodnutí a napomáhá komunikaci mezi jednotlivými úseky podniku. Top management společnosti by také měl jasně stanovit vizi CRM, která bude srozumitelná pro všechny zaměstnance podniku a budou se jí moci řídit při každodenní práci [7, str. 159 – 161]. CRM systém by měl být implementován pro uživatele, kteří s ním následně budou pracovat. To se ale neobejde bez investic do těchto zaměstnanců. Nejde až tak o finanční investice, jako spíš o důkladné proškolení, kdy kromě samotných školení mohou být využity i různé workshopy a koučovací programy, které mají stejný cíl – předat zaměstnancům novou filozofii CRM a připravit je na změny, které je v jejím rámci čekají. Proškolení by ale nemělo paralyzovat podnik či některá z jeho oddělení. Proto je možné využít různých e-learningových

63

kurzů nebo modulárního přístupu ke školení (kratší jednotky pro méně uživatelů, které se častěji opakují) [7, str. 160]. Velice důležitá je volba samotného CRM systému i vybavení pro práci s ním. Systém by měl být dostatečně flexibilní, aby umožňoval provádět změny a byl využitelný i při výrazném růstu podniku v budoucnosti. Měl by také zaručovat stejné uživatelské prostředí mezi jednotlivými jeho částmi a možnost integrace s ostatními využívanými informačními systémy. Systém by také měl splňovat standardy běžného software, aby mohl využívat funkce široce rozšířených operačních systémů a aplikací (např. MS Office). S tím je následně spojena úspora nákladů, které by jinak musely být vynaloženy navíc. Systém také musí být pravidelně aktualizován, aby neustále držel krok s vývojem trhu a odpovídal bezpečnostním standardům. Aktualizace musí probíhat v rozumných intervalech – příliš časté obtěžují uživatele, příliš dlouhé zase vedou k zastarávání systému a bezpečnostním hrozbám. Následně musí být také zvolen další vhodný podpůrný hardware a software, který bude s CRM systémem kompatibilní a bude v souladu s IT strategií celého podniku [7, str. 160 – 162]. Od začátku projektu by měla být vedena přehledná dokumentace, díky které budou všechny informace na jednom místě a snadno přístupné. Správně vedená dokumentace může pomoci při přijmutí nového člena projektového týmu i při následné podpoře uživatelů. Dokumentace také musí být průběžně aktualizována i po skončení projektu. Každá významnější změna systému musí být dokumentována, jinak bude velice obtížné po několika měsících či letech zpětně dohledat, co vše, kdy a jak bylo upraveno [7, str. 161]. Posledním pravidlem je, že zvyknout si na nový CRM systém vyžaduje čas. S novým CRM systémem se změní pracovní postupy velkému množství zaměstnanců a každý z nich potřebuje jiný čas, aby si na novinky zvyknul. Je tedy potřeba počítat se zvýšenou uživatelskou podporou v prvních měsících využívání nového systému [7, str. 161].

64

5 Představení společnosti XYZ Stěžejní částí této diplomové práce je zhodnocení projektu implementace CRM systému do podniku. Hodnocený projekt probíhal ve společnosti XYZ, jejíž hlavní činností je poskytování služeb odpadového hospodářství, zejména v oborech třídění a sběru odpadů, jejich materiálového nebo energetického využívání, odstraňování odpadu (skládkování, spalování, recyklace), stálé havarijní služby, poradenství v oblasti životního prostředí, čištění měst a obcí a dekontaminace území zasažených průmyslovou činností. Společnost je součástí nadnárodního holdingu, který se zaměřuje kromě odpadového hospodářství také na hospodářství vodní. Celý holding působí napříč všemi kontinenty ve více než třiceti zemích, zaměstnává více než 57 tis. zaměstnanců, a svojí činností obsluhuje více než 57 mil. obyvatel a 435 tis. společností. V České republice společnost působí od roku 2000 a v současné době se řadí mezi nejvýznamnější společnosti nakládající s odpadem [57].

5.1 Organizační struktura Společnost XYZ je organizačně rozdělena do dvou částí – na část správní a část výkonnou. Celá struktura je graficky zobrazena v příloze č. 1, přičemž barevně jsou vyznačeny úseky nebo oddělení podstatné pro projekt zavádění CRM do podniku. Jak je z barevného značení patrné, projekt implementace CRM systému více či méně zasáhl všechny úseky správní části společnosti, a také všechna obchodní oddělení jednotlivých divizí. Správní část společnosti se skládá ze čtyř úseků. Pod úsek generálního ředitele, jehož vedoucím je sám generální ředitel (GŘ), spadá interní právní oddělení, oddělení lidských zdrojů, oddělení integrovaného systému řízení a auditu, a také marketingové oddělení vedené manažerem marketingové komunikace (MMK). Druhým úsekem je obchodní úsek vedený obchodním ředitelem (OŘ), který je dále dělený na oddělení logistiky a toku odpadů, oddělení speciálních projektů,

65

a oddělení obchodního rozvoje. Technický úsek je vedený technickým ředitelem (TŘ) a nijak dále se nedělí. Posledním úsekem je finanční úsek, vedený finančním ředitelem (FŘ), pod který spadají oddělení strategických projektů, reportingu, finanční účtárna, IT oddělení pod vedením CIO a také oddělení operativy, které vede zástupce finančního ředitele pro operativu (ZFŘ-OPER). Oddělení operativy se ještě dále dělí na oddělení centrálního nákupu, oddělení pro správu pohledávek, oddělení pro ekonomickou podporu divizí, kam patří všichni ekonomové divizí (ED), a také na oddělení business softwarové podpory, vedené manažerem business software podpory (MBSWP). Výkonná část společnosti se dělí na několik divizí, které pokrývají celé území České republiky a také Slovenska. Jednotlivé divize jsou vedené ředitelem divize (ŘD) a každá z nich se dělí na provozní a obchodní část. Provozní část je vedená vedoucím provozního oddělení (VPO) a obchodní část spadá pod správu oblastního manažera obchodu (OMO). Každá z obchodních částí je ještě dále rozdělena do jedné či několika obchodních skupin, kdy každá ze skupin je vedena manažerem obchodní skupiny (MOS). V každé obchodní skupině jsou potom již samotní obchodníci. Pod pojmem obchodník se skrývá zaměstnanec na obchodní pozici, tedy asistentka, prodejce v call centru, poradce pro ekologii, manažer klíčových zákazníků, obchodní manažer i samotný obchodník. Mezi těmito jednotlivými pozicemi již nadále nebudu rozlišovat a budu používat souhrnný pojem obchodník (pokud nebude nutné jednotlivé pozice rozlišit). Pro přehlednost byly základní pozice, které jsou podstatné pro další část práce, shrnuty v tabulce, která je k nalezení v příloze č. 2.

5.2 Softwarová výbava společnosti Podnikový informační systém společnosti XYZ se skládá ze dvou stěžejních systémů, které společně podporují řízení společnosti. Prvním informačním systémem je ADG určený speciálně pro podniky, které nakládají s různými druhy odpadů. Mezi jeho zá-

66

kladní funkce patří evidence vozidel, kontejnerů a dalších nádob, likvidačních míst (překladiště, skládky, spalovny atd.), či poboček zákazníků. Dále se v něm nacházejí veškeré smlouvy, které byly uzavřeny se zákazníky, a evidence svozů odpadů na úrovni jednotlivých jízd. Jednotlivé svozy jsou následně prostřednictvím tohoto systému vyfakturovány, případně jsou z něho zaslány výzvy k fakturaci, pokud má společnost platit zákazníkovi. Mezi další funkce patří třeba hlášení za odpady, které musí pravidelně odesílat každý, kdo nakládá zejména s nebezpečnými odpady, a také je jeho součástí jednoduchý CRM modul pro evidenci schůzek a vytváření základních přehledů. Systém ADG je nainstalován pouze na terminálových serverech a přístup k němu je možný pouze přes protokol RDP (přes vzdálenou plochu). Druhým stěžejním systémem v podniku je ERP. V tomto systému je zejména vedeno účetnictví a používá se k řízení kompletního nákupního procesu (tvorba a automatizované schválení objednávek, jejich následné odeslání dodavateli, potvrzení jejich dodání a zpracování příchozích faktur). Z tohoto systému se také tvoří reporty nutné pro operativní i strategické řízení společnosti. Přístup k systému je možný dvěma způsoby. Tím prvním je přístup přes tlustého klienta nainstalovaného buď lokálně, nebo na terminálovém serveru. Přes tlustého klienta je možné získat přístup ke kompletní nabídce funkcí systému včetně testovacího prostředí a vývojového prostředí. Druhou možností je využití internetového prohlížeče pro přístup na informační portál. Ten nabízí pouze základní funkce a je vyhrazen zejména pro potřeby manažerů a zaměstnanců, kteří se účastní procesu schvalování nákupních dokladů. Přes tohoto tenkého klienta je tedy možné se rychle dostat ke schvalovacím úlohám, různým reportům a souhrnným informacím z nákupních dokladů (zejména faktur a objednávek). Koncové stanice jednotlivých uživatelů stále běží na operačním systému Microsoft Windows XP, který je ale aktuálně nahrazován novějším systémem Microsoft Windows 7. Pro tvorbu dokumentů se pou-

67

žívá balík kancelářských aplikací Microsoft Office (ve verzích 2003, 2007 a 2010), jehož součástí je také Microsoft Outlook, který je výchozím a jediným používaným e-mailovým klientem. V rámci společnosti je pro komunikaci možné také využít aplikaci Microsoft Lync, která slouží pro komunikaci v reálném čase, sdílení plochy či vzdálené připojení k počítači. Mezi další využívané aplikace patří Microsoft Exchange Server pro e-mailovou komunikaci (externí i interní), Active Directory pro správu adresářů a také dva intranetové portály. Jeden portál byl vytvořený na míru potřebám společnosti a již přestává vyhovovat, proto dochází k pozvolné migraci na druhý, kterým je Microsoft SharePoint 2010. Intranetové portály jsou využívány pro sdílení vnitrofiremních dokumentů a pro hromadnou interní komunikaci.

68

6 Projekt implementace CRM systému v XYZ Projekt implementace nového CRM systému do společnosti XYZ probíhal v období od poloviny roku 2011, kdy se management společnosti začal zabývat myšlenkou na jeho výměnu, do poloviny roku 2013, kdy došlo k jeho oficiálnímu předání. Tato kapitola pokrývá kompletní období projektu a popisuje jak pozadí jeho vzniku, tak celý životní cyklus projektu včetně návazných fází po předání systému.

6.1 Důvody pro změnu systému Jak jsem již zmínil v kapitole 5.2, systém ADG obsahuje velice jednoduchý CRM modul. V rámci tohoto modulu je možné evidovat schůzky, kterých se jednotliví obchodníci účastnili, vytvářet přehledy schůzek podle zákazníka nebo obchodníka, a také evidovat kontakty u jednotlivých zákazníků (resp. u jednotlivých smluv). Výhodou tohoto modulu je vysoká integrace se systémem ADG, který slouží pro zadávání smluv a evidenci faktur. Není tedy potřeba integrovat CRM a produkční systém externím můstkem, protože jsou již z principu integrovány interně. Nevýhodou tohoto systému je uživatelská nepřívětivost a vysoce omezená nabídka funkcí. Tyto dva faktory způsobily, že mezi uživateli CRM modulu panovala nespokojenost a používali ho zejména z povinnosti, kdy na základě metodického pokynu museli zadávat v tomto CRM modulu veškeré schůzky u zákazníků. Ve výsledku si obchodník většinou naplánoval schůzku v aplikaci Microsoft Outlook a do CRM modulu je následně jednou za čas hromadně přepsal. Všechny podstatné dokumenty k obchodnímu případu (nabídky, smlouvy, dodatky ke smlouvám atd.) měl každý obchodník v horším případě uložené pouze u sebe na lokálním počítači, v lepším případě využíval sdíleného disku nebo portálu Microsoft SharePoint. Stále ale dokumenty byly na několika místech a většinou nebylo možné se k nim jednoduše dostat.

69

Další problém nastal při schvalování jednotlivých dokumentů. Každý z dokumentů totiž musí být schválen minimálně jednou další osobu, většinou nadřízeným daného obchodníka. V případě smlouvy na vyšší částku musí dojít ke schválení ještě vyššími instancemi (OMO, OŘ, případně GŘ). Dosavadní CRM modul neměl žádný workflow nástroj pro automatizované schvalování dokumentů, takže ke schválení mohlo dojít v principu dvěma způsoby. Tím prvním bylo vytisknutí daného dokladu a zajištění fyzického podpisu potřebných osob – to nemusí být úplný problém, pokud nadřízený sídlí ve stejném místě jako obchodník a bývá alespoň několik dní v týdnu dostupný v kanceláři. U smluv na vyšší částku to již začíná být problémem, protože společnost XYZ působí na území celé České republiky i Slovenska, takže např. obchodníci z Ostravy by pravidelně museli dojíždět do Prahy pro podpis OŘ. Proto byl používanější druhý způsob – zaslání dokumentu elektronickou formou (klasicky e-mailem, někdy zaslání odkazu na sdílené úložiště) ke schválení. Doklad ovšem pořád musel být podepsán, takže v praxi většinou došlo k jeho vytisknutí, podpisu, naskenování a zaslání další schvalovací instanci, popř. zpět obchodníkovi. Kromě toho, že to všem schvalovatelům přidávalo práci navíc, nebyl mnohdy doklad po několikerém vytištění a naskenování příliš čitelný. Mezi další nevýhody řešení zabudovaného CRM modulu patřila nemožnost automatizované tvorby reportů pro hodnocení obchodního procesu a výsledků jednotlivých obchodníků. Jediný implementovaný report byl výčet schůzek a jejich výsledků. Ostatní reporty požadované managementem společnosti (jak pravidelné, tak operativní) se dělaly většinou v aplikaci Microsoft Excel spojením různých výstupů z rozdílných částí systémů ADG a ERP. Taková práce zabrala poměrně velké množství člověko-hodin, mnohdy i několik člověko-dnů. Jak z předchozích odstavců vyplývá, řešení zabudované v systému ADG zdaleka nevyhovovalo potřebám společnosti. Proto vedení společnosti rozhodlo vyměnit dosavadní systém za úplně nový, který

70

bude lépe naplňovat potřeby společnosti a ušetří práci všem uživatelům, kteří s ním budou pracovat.

6.2 Projektový záměr Před spuštěním projektu byl v říjnu 2011 prezentován projektový záměr, na jehož základě mělo být rozhodnuto, zda bude projekt podpořen vedením společnosti a bude možné ho spustit, nebo zda se žádný projekt na implementaci nového CRM systému konat nebude a vše zůstane při starém. Projektový záměr byl vytvořen a prezentován CIO. Jeho součástí byla zejména analýza rizik plynoucích z aktuálního stavu, prezentace očekávání od nového systému a jeho přínosů, zahrnuty byly také požadavky na nový systém a bylo nastíněno několik možností, kudy by se dalo ubírat a jak by nové řešení mohlo vypadat. V rámci projektového záměru bylo hlavním cílem projektu stanoveno zprovoznění nového systému pro řízení obchodních aktivit do konce roku 2012. Hlavními přínosy nového systému mělo být zachování firemního know-how, zefektivnění práce obchodníka, provázanost zákazníka a konkurence, trvale udržitelné obchodní aktivity, manažerský přehled o celém obchodním procesu pro lepší cílení obchodních aktivit, a také zvýšení motivace obchodníků a jejich transparentní odměňování.

6.2.1 Rizika aktuálního stavu První částí projektového záměru bylo krátké nastínění rizik, která plynula z aktuálního stavu CRM ve společnosti. Tato rizika jsou poměrně vážná, zvlášť v oblasti odpadového hospodářství, kde již několik let panuje tvrdý konkurenční boj a jednotlivé podniky jsou nuceny výrazně snižovat ceny, které nabízejí svým zákazníkům. Prvním rizikem je ztráta přehledu o obchodování, která by mohla vést ke ztrátě některých klíčových zákazníků. Se ztrátou přehledu je také spojeno snížení obchodní výkonnosti celé společnosti a zvýšení chybovosti při tvorbě nabídek (nabízené služby nebudou odpovídat poptávce zákazníka, nabí-

71

zená cena za služby bude úplně mimo realitu trhu atd.). Dále existovalo riziko většího množství obchodních přehmatů, kdy by energie a čas obchodníků byly vynaloženy zbytečně pro zákazníky, kteří nejsou pro společnost vhodní, nebo jsou dokonce rizikoví (potýkají se se špatnou platební schopností, nacházejí se v insolvenčním řízení atd.). Posledním rizikem bylo obtížné sledování konkurence a také náročná správa zákazníků, a to jak stálých, tak potenciálních.

6.2.2 Požadavky na nový systém Součástí projektového záměru byly také funkční a nefunkční požadavky na nový systém, rozdělené do čtyř skupin – technické, obchodní, operační a manažerské. Technické požadavky spočívaly zejména ve využití architektury klient-server a ideálně Microsoft SQL serveru pro databázi, možnosti přímého přístupu k datům pomocí jazyka SQL a také možnost rozšíření systému dle požadavků zadavatele včetně přístupu ke zdrojovým kódům customizovaných částí v případě krizového scénáře. Důležitým požadavkem byla komunikace se stávajícími systémy (ADG a ERP), autentizace a řízení oprávnění na základě Active Directory, auditovatelnost přístupů, automatizované workflow pro schvalování dokumentů a možnost zakonzervování funkčního stavu pro zpětný přístup k aplikaci v případě selhání systému. Obchodní požadavky byly založeny na možnosti zadávat podrobné informace o zákazníkovi (kontaktní osoba či osoby, provozy a pobočky, třídění dle různých databází, velikost zákazníka, organizační struktura atd.), evidovat jednotlivé kontakty s daným zákazníkem včetně jejich stavu (oslovení bez reakce, zákazník odpověděl, aktivní poptávka, nabídka, realizovaný obchod, servis atd.) včetně jejich zápisů, a navázat zákazníka na konkrétního obchodníka, který je za něj zodpovědný. Kromě údajů o zákaznících by nový systém měl být schopný evidovat také údaje o konkurenci (IČO, provoz, provázanost, další obchodní informace), evidovat partnery pro subdodávky jednotli-

72

vých obchodních případů. Dále by měl systém umožnit sledování výkonnosti vlastního portfolia, navázání nabídek na konkrétního zákazníka, vypočítat obrat a marži a připojit externí dokumenty k jednotlivým entitám. Významným prvkem by měla být automatizovaná tvorba všech potřebných obchodních dokumentů (nabídka, smlouva, dodatek ke smlouvě) z jednotného vzoru a číslování a archivace všech dokumentů. Mezi operační požadavky se řadí plánování cest k zákazníkovi na základě mapových podkladů, provázanost na další služby jako je ARES (systém pro vyhledávání nad ekonomickými subjekty, které mají IČO) nebo ISIR (insolvenční rejstřík pro vyhledávání dlužníků), přehled kompletní historie jednotlivých zákazníků, upozornění na slibný kontrakt s možností navázání spolupráce a provázanost s aplikací Microsoft Outlook, ve které by se plánovaly schůzky a ty se následně synchronizovaly do systému. Poslední skupinou jsou manažerské požadavky, mezi které patří zejména ucelené výstupy na základě různorodé množiny kritérií a jejich vzájemných kombinací (schůzky u daného zákazníka za poslední měsíc, počet změn stavu mezi oslovením a ukončením obchodního případu, výkonnost portfolia obchodníka za posledních šest měsíců atd.), export těchto výstupů do aplikace Microsoft Excel, a také zpracování výstupů ve formě grafů a tabulek. Systém by také měl umožňovat segmentaci zákazníků do kategorií a skupin, zadávání úkolů jednotlivým zaměstnancům a hlídání termínů jejich plnění, evidenci projektů a komplexních obchodních případů a také tvorbu obchodních plánů a jejich vyhodnocování.

6.2.3 Možné varianty řešení Při prezentaci projektového záměru byly navrženy tři možné přístupy k implementaci nového CRM systému. Prvním možným přístupem k implementaci nového systému je krátkodobé (na dva, možná tři roky) přechodné řešení formou malého

73

CRM systému nasazeného ve vlastním prostředí. Takové řešení by umožnilo postupný přechod na systematické obchodování dle aktualizovaného obchodního procesu, pozvolnou adaptaci jednotlivých obchodníků na nový obchodní proces a také jednoduché sdílení dat. Zároveň by bylo možné tento systém nasadit poměrně rychle (v rámci několika málo měsíců) s nízkými náklady a možností jednoduchých úprav na míru. Nevýhodou ovšem je nižší komplexnost funkcionalit a také riziko podřízení se současnému obchodnímu procesu místo jeho optimalizace. Jako druhá možnost bylo nabídnuto využití principů cloud computingu pro hostování CRM systému na infrastruktuře dodavatele. Mezi výhody tohoto řešení se řadí nulové pořizovací náklady na hardwarové vybavení a licence, jednoduše predikovatelné provozní náklady (není potřeba žádná prvotní investice) a využití tenkého klienta pro přístup k systému. Na druhou stranu by se společnost musela vzdát dat, která by byla uchována někde mimo firmu (na konci roku 2011 byl tento problém poměrně zásadní a dodnes se úplně nepodařilo strach ze vzdání se dat překonat) a bylo by velice problematické dělat úpravy na míru společnosti. Poslední variantou, která se nabízela, bylo využití systému od dodavatele již implementovaného systému ERP. Výrobce ERP systému totiž nabízí velice kvalitní CRM modul, který je přímo integrován se systémem ERP. Výhody tohoto řešení jsou zejména v jednotné datové základně ERP + CRM, téměř neomezené možnosti customizace, ale zároveň existuje možnost využít implementované best practices a na jejich základě nastavit procesy ve společnosti. Výhodou také bylo, že by se jednalo o konečné řešení, a ne o dočasné na několik let, kdy by se následně musel celý projekt opakovat. Mezi nevýhody spadala dlouhá doba implementace a vysoké pořizovací náklady, nutnost nákupu licencí, vyšší cena při vysoké míře customizace systému, a také riziko nesplnění všech podmínek na systém kladených.

74

6.2.4 Témata na zvážení managementem společnosti Poslední částí projektového záměru byl souhrn témat, ke kterým by se měli vrcholoví manažeři společnosti vyjádřit v případě, že by schválili spuštění projektu. Klíčovým tématem bylo stanovení trojimperativu včetně zvolení jeho prioritní osy, která bude rozhodující pro úspěch projektu. Rozsah projektu byl svým způsobem dán již v rámci projektového záměru, kdy byly stanoveny požadavky na nový systém – z tohoto pohledu bylo tedy důležité schválení požadavků top managementem, a případně jejich doplnění nebo vypuštění požadavků, které nejsou důležité. Druhým prvkem trojimperativu je čas, kdy měl být stanoven rámcový harmonogram projektu se stěžejním milníkem předání systému do správy IT oddělení. Poslední dimenzí trojimperativu je rozpočet, v jehož rámci měl být zvolen investor celého projektu, celkový objem investice a její rozpad na rámcové oblasti, a také měl být zvolen způsob financování projektu (mohlo jít o nižší jednorázovou investici s pravidelnými měsíčními platbami za servisní služby, vyšší jednorázovou investici zahrnující již dva roky podpory systému, nebo o pravidelné měsíční platby za pronájem hostovaného řešení). Kromě trojimperativu byla na zvážení také nominace vedoucího projektu, který bude zodpovídat za výběr vhodného systému, jeho implementaci a za splnění trojimperativu a očekávané kvality systému. Posledním tématem, které bylo navrženo ke zvážení vrcholovým managementem společnosti, byla forma odměn pro jednotlivé členy týmu a také stanovení motivačního programu pro obchodníky, aby nový systém začali používat co nejdříve.

6.3 Zadání projektu Projekt byl schválen na poradě top managementu nedlouho po prezentaci projektového záměru a zaměstnancům společnosti byla informace o spuštění projektu oficiálně oznámena interním memorandem na za-

75

čátku prosince roku 2011. Na konec roku 2011 se tedy datuje oficiální začátek celého projektu implementace nového CRM systému do společnosti XYZ. Kromě oznámení o startu projektu došlo také k jeho oficiálnímu zadání ze strany managementu společnosti, konkrétně od FŘ. Projekt byl oficiálně spuštěn na začátku roku 2012 a v rámci jeho zadání byly stanoveny strategické cíle projektu, bylo popsáno očekávané řešení, jeho rámcový harmonogram, požadavky na personální obsazení projektu a také finanční rámec projektu, který neměl být překonán. Dle zadání projektu měl být implementován systém složený ze dvou částí – samotného CRM systému, kam se vkládají data, a informačního portálu, ze kterého jsou čerpány informace. Idea podobného rozdělení systému byla převzata z principu implementace ERP systému, jak je popsáno v kap. 5.2. Obě části měly být integrovány se systémy ERP a ADG, přičemž v rámci samotného projektu mělo být následně rozhodnuto o tom, který systém bude primárním pro získávání informací o zákaznících.

6.3.1 Strategické cíle projektu Mezi strategické cíle CRM systému byl zařazen sběr obchodních informací na jednom centrálním místě, vytvoření centrální databáze partnerů včetně potenciálních zákazníků, nebo možnost řídit, evidovat a vyhodnocovat efektivitu a výkonnost jednotlivých obchodníků. Dalším cílem byla možnost kontroly plnění termínů úkolů a výběrových řízení, a s ním spojená implementace motivačního programu MP pro jednotlivé zaměstnance. Posledním strategickým cílem systému bylo měření obchodního potenciálu trhu jak stávajícího, tak plánovaného, dále plánování činnosti vzhledem k dostupné kapacitě obchodníků a k počtu zákazníků, a také měření potenciálu obratu u nových zákazníků. Informační portál měl za strategické cíle poskytování různých reportů a informací řídícím osobám – informací nejen finančních, ale také o obchodních příležitostech. Portál měl dále pomáhat s vyhodno-

76

cováním aktivit a dopadů obchodování s konkurenčními společnostmi, měl umožnit sledování a porovnávání výkonu jednotlivých obchodníků a obecně usnadnit managementu společnosti rozhodování o strategických a operativních záležitostech.

6.3.2 Trojimperativ projektu Rozsah projektu byl v projektovém zadání stanoven výčtem očekávaných funkcionalit. Mezi ně patří pro CRM systém zejména evidence obchodních případů a termínů odevzdání nabídek, revize a centrální plánování schůzek obchodníků s možností zadání úkolu obchodníkovi ze strany nadřízeného MOS nebo OMO, evidence obchodních příležitostí a také evidence kontaktů zadávaná operátory call centra. Dalším funkčním požadavkem byl sběr dat o stávajících i potenciálních zákaznících z ročních hlášení o odpadech, a z něho vyplývající hodnocení trhu a odhad jeho potenciálního růstu. Stěžejní funkcí pro nový informační portál bylo poskytování informací pro vyšší i střední management společnosti a analýza dat nad systémy ERP, ADG, CRM a také nad ročními hlášeními jednotlivých zákazníků. Rámcový harmonogram projektu byl stanoven tak, že implementace CRM systému měla proběhnout v prvním čtvrtletí roku 2012, informační portál měl být implementován do konce května 2012, školení a testování obou částí mělo probíhat od začátku dubna do konce června 2012, a po zbytek roku měl být nový systém provozován v pilotním režimu, aby bylo možné ho převzít do správy společnosti od 1. 1. 2013. Maximální výše rozpočtu projektu byla stanovena na 1,5 mil. Kč pro CRM systém a 2,2 mil. Kč pro informační portál. Celkový maximální rozpočet pro celý projekt tak byl stanoven ve výši 3,7 mil. Kč.

6.4 Prvotní fáze projektu Na základě zadání projektu mohl jeho vedoucí sestavit akční plán projektu, který je ve společnosti XYZ nejdůležitějším dokumentem pro hodnocení každého projektu. Součástí akčního plánu je konkrétní

77

stanovení cílových hodnot projektu, jeho očekávaný přínos, konkrétní stanovení trojimperativu včetně podrobného harmonogramu, určení vlastníka projektu a řešitelského týmu, popis jednotlivých činností a jejich rozpad (WBS) a také předpoklady pro úspěšné naplnění projektu (např. nábor nového zaměstnance). Součástí akčního plánu byla také krátká analýza rizik, která mohou ohrozit projekt. Akční plán projektu byl vypracován FŘ a CIO a následně v polovině února 2012 schválen GŘ.

6.4.1 Cíle a přínosy projektu, jeho předpoklady Konkrétní cílové hodnoty projektu byly stanoveny tak, aby odpovídaly zadání projektu. Jednou z hlavních hodnot byla definice nového obchodního procesu a stanovení závazných pravidel pro obchodování jak z pohledu front-office (obchodníci, poradci pro ekologii), tak i z hlediska back-office (asistentky, pracovníci call centra). Další stěžejní cílovou hodnotou projektu bylo zavedení a nastavení nového IT instrumentu pro podporu aktualizovaného obchodního procesu, přičemž zvolený systém měl mít přívětivé uživatelské prostředí a měl splňovat všechny požadavky na něj kladené v projektovém záměru a v oficiálním zadání projektu. Dalším výstupem projektu měli být proškolení uživatelé, kteří budou schopni efektivně využívat nový systém. Jako poslední cílová hodnota byla stanovena podpora motivačních programů pro jednotlivé pozice v obchodním procesu. Mezi očekávané přínosy projektu se řadil implementovaný efektivní nástroj pro řízení obchodních aktivit, kvantifikace přidané hodnoty nově stanovených prodejních týmů a jejich členů včetně projektů, které jsou jednotlivými týmy prováděny. Posledním přínosem měla být zvýšená informovanost vedoucích pracovníků o obchodním dění ve společnosti a s ní spojené jednodušší rozhodování o operativních i strategických plánech. Stanoveno bylo také několik nutných předpokladů pro úspěšné dokončení projektu. Stěžejním předpokladem bylo schválení samotné-

78

ho projektu na poradě širšího vedení společnosti, kdy zde ještě mohlo dojít k redefinici, odložení či zrušení projektu. Druhým předpokladem bylo

vymezení

finančních

prostředků

určených

pro

projekt.

S finančními prostředky také souvisí předpoklad přijetí nového zaměstnance na pozici IT specialisty pro CRM systém. Dalším předpokladem bylo úspěšné dokončení aktualizace obchodního procesu odpovídajícímu novým podmínkám. Posledním předpokladem bylo sestavení podpůrného týmu, který bude řešit operativní problémy a podporu uživatelů po oficiálním konci projektu.

6.4.2 Trojimperativ a harmonogram projektu Rozsah projektu spočíval v dodání závazných pravidel pro obchodování (tedy v aktualizaci obchodního procesu), dodání centrální databáze konkurence společnosti a také databáze informací o obchodních příležitostech. Další významnou součástí bylo dodání samotného CRM systému, který měl pomoci s plánováním, řízením a vyhodnocováním obchodních týmů jak na divizích, tak i v rámci celorepublikových zakázek. Rozpočet projektu byl stanoven ve výši 3 mil. Kč. V rámci tohoto rozpočtu měly být nakoupeny licence pro nový CRM systém a veškeré potřebné technické vybavení, dále měly být uhrazeny veškeré náklady plynoucí ze smluvního vztahu s dodavatelem systému (s výjimkou potenciálních pravidelných měsíčních poplatků za servis systému), a také se z rozpočtu použily peníze na přijetí nového IT specialisty a na odměny pro členy řešitelského týmu. Časový rámec projektu zabral téměř celý rok. Oficiální začátek řešitelské fáze projektu a tzv. kick-off meeting proběhly 16. února 2012 a datum ukončení projektu bylo stanoveno na 31. prosince stejného roku, přičemž cílovým milníkem bylo převzetí implementovaného a nastaveného CRM systému do správy IT oddělení společnosti od 1. ledna roku 2013. Podrobný harmonogram včetně jednotlivých činností je znázorněn na obr. 6.1.

79

6.4.3 Vlastník projektu a řešitelský tým Vlastníkem projektu, a zároveň jeho sponzorem a konečným příjemcem, byl stanoven GŘ společnosti XYZ. Oponentem projektu se stal další z členů top managementu společnosti, TŘ. Vedoucím celého projektu byl jmenován CIO společnosti a jeho zástupcem ZOŘ. Pro jednodušší řízení celého projektu byli všichni zaměstnanci, účastnící se projektu, rozděleni do několika týmů. Každý z týmů měl stanoven jiný cíl, vlastního vedoucího a omezenou časovou platnost. Stěžejním pro projekt byl hlavní projektový tým, který měl na starosti řízení ostatních týmů a celého projektu, komunikaci ohledně postupu projektu v rámci společnosti, sestavení požadavků na systém, výběr vlastního CRM systému a jeho dodavatele, a také sestavení struktury systému a jeho funkcionality. Mezi členy tohoto týmu patřili CIO jako vedoucí celého projektu a ZOŘ jako jeho zástupce, dále jeden z pracovníků na pozici OMO jako zástupce obchodního úseku divizí, jeden ED jako zástupce finančního úseku, a také AGŘ z úseku generálního ředitele. Druhým týmem, stanoveným v rámci projektu, byl metodický tým. Jeho hlavní činností bylo zpracování, konzultace a připomínkování nového (resp. aktualizovaného) obchodního procesu, součinnost při schvalování funkcí vybraného CRM systému, spolupráce se školícím týmem a také prezentace cílového konceptu všem zainteresovaným stranám. Do tohoto týmu patřili vybraní členové hlavního týmu (CIO, ZOŘ, OMO), jeden další pracovník na pozici OMO, jeden MOS, dva ZŘD, tři ŘD a jeden pracovník z oddělení marketingu. Jako oponenti nového obchodního procesu byli stanoveni OŘ, FŘ, TŘ a GŘ. Jako třetí byl stanoven tým interní kontroly, jehož stěžejním cílem bylo vytvořit seznam kritických míst a rizik projektu a také definice formálních periodických interních kontrol finančních i nefinančních procesů. Mezi další cíle týmu patřila kontrola souladu nově navrženého procesu s metodikami integrovaného systému řízení, kontrola dodržo-

80

vání standardů ISO a také komunikace do společnosti na příslušných úrovních. Členy tohoto týmu byli opět členové hlavního týmu (CIO, AGŘ, ED) a k nim navíc ještě MISŘ a interní auditor. Nedílnou součástí projektu byl také technický tým, který zodpovídal za instalaci nového systému, nastavení jednotlivých funkcionalit dle zadání projektu, naplnění číselníků, a také za konzultace a spolupráci s dodavateli systémů ERP a ADG. Mezi členy tohoto týmu se zařadili CIO, jeden pracovník IT oddělení, nový IT specialista pro CRM, MBSWP, a také zaměstnanci vybraného dodavatele CRM systému určení pro spolupráci na instalaci systému. Kromě týmu pro instalaci a nastavení systému byl také sestaven speciální tým pro otestování nového systému. Tento tým měl na starosti kompletní zkušební režim nového systému a jeho cílem bylo podat feedback a podněty ke zlepšení, vkládání dat a ladění procesu back-office, generování výstupů a jejich kontrola, komunikace s dodavatelem nového systému a obecně podněty ke zlepšení systému před spuštěním pilotního provozu. Jako členové týmu byli nominováni CIO, ZŘO, TŘ, jeden MOS, dva OMO, jeden ŘD, jeden pracovník marketingového oddělení, jeden obchodník z každé divize a také jedna asistentka obchodu z každé divize. Posledním týmem, který byl k provedení projektu stanoven, byl školící tým. Stěžejními úkoly tohoto týmu bylo sestavení uživatelských manuálů, příprava školících materiálů, vlastní školení všech uživatelů nového systému dle jednotlivých úrovní (manažer, obchodník, asistentka atd.) a také komunikační podpora pro zaškolení uživatelů (vytvoření portálu s potřebnými informacemi, FAQ a jejich aktualizace). Posledním úkolem tohoto týmu byla podpora uživatelů v prvotní fázi po převzetí systému do běžného provozu. Členy tohoto týmu byli CIO, ZŘO, nový IT specialista pro CRM, a také zástupci dodavatele nového systému zodpovědní za školení uživatelů.

81

6.4.4 Rozpad činností projektu Součástí akčního plánu projektu bylo také jednoduché rozdělení projektu na jednotlivé činnosti (WBS). V rámci projektu bylo stanoveno pět základních činností, které musí být provedeny, přičemž většina z těchto činností byla rozpadnuta na další, detailněji popsané aktivity. První činností na projektu bylo vytvoření nového obchodního procesu. Původní obchodní proces byl zastaralý a neodrážel aktuální realitu ve společnosti XYZ, a také byla nutná jeho aktualizace pro možnost využití nového CRM systému. V návaznosti na nový obchodní proces měla být stanovena také závazná metodika pro konkretizaci celého procesu, a podrobný manuál pro využívání konkrétního nového CRM systému. Druhou činností, kterou projektový tým musel provést, bylo sestavení podrobného cílového konceptu nového CRM systému. Za jeho vytvoření byl zodpovědný CIO a celý cílový koncept měl být sestaven ve spolupráci s vybraným dodavatelem tak, aby dle něho bylo možné implementovat systém. Další stanovenou činností byla samotná implementace nového systému. Pod implementaci systému se řadí výběr dodavatele nového systému na základě poptávky, instalace systému a jeho nastavení a otestování. Zodpovědnou osobou za tyto činnosti byl opět stanoven CIO jako vedoucí celého projektu. Čtvrtou činností celého projektu byla definice formálních kontrolních mechanizmů pro periodické hodnocení finančních i nefinančních interních procesů. Mezi základní atributy, které bylo potřeba nastavit, patřil předmět a rozsah jednotlivých kontrol, stanovení osoby kontrolora, a také forma a periodicita kontrol. Posledním atributem byl výstup kontrol a způsob jeho předání odpovědným osobám. Touto činnost byl pověřen ZOŘ ve spolupráci s interním auditorem. Poslední činností bylo proškolení jednotlivých uživatelů jak výkonných (obchodníci), tak manažerských (MOS, OMO, ZOŘ, OŘ) pozic.

82

Pod tento bod spadalo také prvotní podrobné školení podpůrného týmu, který měl na starosti uživatelskou podporu v prvotní fázi po převzetí systému, a školení budoucích administrátorů systému ze strany společnosti XYZ. Grafické znázornění WBS a jejich rozdělení do časového harmonogramu je na obr. 6.1.

obr. 6.1 Harmonogram a WBS projektu, zdroj: [58]

6.4.5 Rizika projektu Poslední částí akčního plánu projektu byla krátká analýza rizik. Kromě poměrně klasických rizik, jako je překročení rozpočtu, nedodržení očekávaného rozsahu nového systému, a zpoždění projektu, byla jako riziko také identifikována možnost výrazného navýšení celkové ceny systému oproti původně očekávanému rozpočtu nejen na projekt, ale i na údržbu systému. Pro snížení hrozby těchto rizik byl plán projektu lehce upraven, kdy byla zahrnuta také časová rezerva. Dalším rizikem je dodání menšího množství funkcí, než je očekáváno, a také nižší spolehlivost systému. V rámci analýzy rizik je také podotknuto, že nejlevnější systém nemusí být dlouhodobě nejvýhodnější. Nemělo by tedy být přihlíženo pouze k finanční stránce, ale také ke kvalitě systému. Aby byla tato rizika minimalizována, byl vytvořen závazný poptávkový list se všemi požadovanými funkcemi (některé

83

z nich byly označeny za kritické) a při hodnocení nabídek od potenciálních dodavatelů bylo k těmto požadavkům přihlíženo se zvláštním důrazem. Významným rizikem je, že bude implementován složitý systém, který nebude uživateli přijat s nadšením, a již v průběhu jeho implementace si k němu vybudují odpor a při ostrém provozu bude docházet ke snahám o jeho obejití. Toto je poměrně klasické riziko při implementaci informačních systému do podniku, a ani tento projekt nebyl výjimkou. Požadavkem na nový systém tedy byla i uživatelská přívětivost a podrobné školení pro všechny uživatele. Posledním identifikovaným rizikem bylo také riziko nejvýznamnější – hrozba toho, že společnost implementuje technické řešení, které ale nebude strategickou výhodou a nebude odrážet nutné procesní změny. Ke snížení tohoto rizika měl cílit nově vytvořený obchodní proces, jehož stanovení bylo také součástí projektu.

6.5 Aktualizace obchodního procesu Nový obchodní proces byl stanoven vnitřním předpisem „Obchodní proces ve společnosti XYZ“, který je závazný pro všechny zaměstnance společnosti. Tento vnitřní předpis byl vypracován ZOŘ a schválen GŘ s platností od poloviny dubna 2012. Vnitřní předpis popisuje pravidla, povinnosti a odpovědnosti v obchodních činnostech v komplexním procesu získání nového zákazníka, počínaje identifikací příležitostí na trhu, a konče smluvním uzavřením obchodního vztahu. Předpis dále popisuje budování vztahu se zákazníkem, péči o něj, hodnocení jeho spokojenosti, a také řešení reklamací při plnění smluvních dohod. Hlavním předmětem vnitřního předpisu je identifikace jednotlivých činností, ze kterých se obchodní proces skládá, stanovení best-practices při uzavírání obchodního kontraktu a administraci souvisejících dokumentů, a také pravidla pro uplatnění jednotlivých přístupů. V rámci předpisu je definován způsob stanovování prodejních cen, podpora obchodního oddělení

84

a popsáno know-how společnosti XYZ. Poslední součástí předpisu je stanovení systému interních kontrol obchodního procesu. Celý obchodní proces je poměrně obecný a jeho cílem je obsáhnout všechny situace, které mohou při obchodování nastat. Z hlediska projektu implementace nového CRM systému jsou důležité dokumenty, vstupující do obchodního procesu, a jejich schvalování, některá ze základních pravidel obchodování, a také role marketingového oddělení pro podporu obchodu. Pro potřeby obchodního procesu byl definován pojem informační systém jako „elektronický systém pro uchovávání a zpracovávání dat, přístupný pomocí výpočetní techniky“ [59]. V dalším textu bude tento pojem, resp. jeho zkratka IS, používán v tomto významu.

6.5.1 Základní pravidla obchodování Nový obchodní proces stanovil několik základních pravidel, která musí být dodržena v průběhu celého životního cyklu procesu. Prvním pravidlem je, že veškeré dohody (i ústní) musí být prokazatelně písemně potvrzeny. Všechny dokumenty (viz kap. 6.5.2) musí být zkontrolovány minimálně dvěma osobami (zpracovatelem a dalším odborně fundovaným nezávislým zaměstnancem). Kontrola je prokázána schválením dokumentu na základě schvalovacího procesu (viz kap. 6.5.3). Dohody musí být dle vnitřního předpisu evidovány buď v systému ADG, nebo v systému ERP. Druhé pravidlo stanovuje povinnost obchodníka předat veškeré informace o zákazníkovi svému nadřízenému. Dle pokynů nadřízeného následně musí obchodník zadat všechny informace do informačního systému, stanoveného metodickým pokynem. Veškeré schůzky, které obchodník absolvuje, musí být zadány v aplikaci Microsoft Outlook, a po jejich skončení musí být vyplněn zjišťovací formulář se zhodnocením schůzky a jejím výsledkem. Posledním závazným pravidlem pro obchodování je povinnost obchodníka ověřit údaje o zákazníkovi před samotným uzavřením ob-

85

chodu. Ověření zákazníka probíhá v databázi OCTOPUS, která shromažďuje informace o společnostech v České republice z různých zdrojů (Insolvenční rejstřík, exekuční údaje, databáze Českého statistického úřadu, Obchodní rejstřík, Živnostenský rejstřík atd.) a na jejich základě hodnotí riziko obchodování s konkrétní společností [60]. Pokud je potenciální zákazník vyhodnocen jako rizikový, musí být obchod dopředu schválen FŘ nebo ZFŘ-OPER. Pokud není možné získat informace o daném zákazníkovi, musí být obchod vždy dopředu schválen FŘ nebo OŘ. Výpis z databáze OCTOPUS se vždy musí vytisknout ve chvíli jeho vystavení a vložit do složky zákazníka.

6.5.2 Obchodní dokumenty Veškeré originální dokumenty, které se týkají jednotlivých zákazníků, jsou fyzicky uloženy ve složce zákazníka v příručních registraturách vedení jednotlivých divizí. Tyto šanony musí být pečlivě zabezpečeny proti odcizení a přístup k nim mají pouze vybraní prověření zaměstnanci, většinou asistentky oddělení. Pokud je některý z dokumentů vyžadován zaměstnancem, pověřená osoba vytvoří kopii daného dokumentu (pokud není potřeba originální dokument), kterou následně zapůjčí a zaeviduje osobu, které byla kopie zapůjčena. Všechny dokumenty mají také elektronickou verzi, která je uložena ve složce zákazníka na intranetovém portálu společnosti XYZ. Složky zákazníka jsou vytvářeny pro všechny obchodní případy, které ještě nebyly fakturovány, a u kterých je předpoklad další spolupráce se zákazníkem. Pokud zákazník přestane být aktivním a již není očekávána další spolupráce, je celá složka zákazníka předána k archivaci, resp. její elektronická verze je přesunuta do elektronického archivu na intranetovém portálu společnosti. Mezi povinné dokumenty, které musí obsahovat každá složka zákazníka, patří výpis z databáze OCTOPUS (případně z Obchodného registru pro zákazníky ze Slovenska), kalkulace ceny, schválená nabídka včetně protokolu o jejím schválení, smlouva podepsaná všemi stra-

86

nami, veškeré dodatky ke smlouvě, plné moci zástupců (pokud byla smlouva podepsána někým jiným než GŘ) a protokol o e-aukci (pokud byla realizována). K těmto dokumentům mohou být přidány ještě další – poptávka, základní popis odpadu, pokyny zákazníka k realizaci smlouvy, důležitá korespondence se zákazníkem (dopisy či e-maily), hodnocení spokojenosti ze strany zákazníka, případně reklamační listy a schválené dobropisy či slevy. Kalkulace slouží jako podklad pro stanovení prodejní ceny a vyhodnocení celého obchodního případu. Výsledná cena musí být stanovena na základě schválených ceníků a případné slevy musí být schváleny příslušným nadřízeným zaměstnancem. Prodejní cena je k zákazníkovi distribuována většinou jako součást nabídky či smlouvy. Nabídka slouží k informování potenciálního zákazníka o řešení nabízeném společností XYZ včetně výsledné ceny. Nabídka musí být před předáním zákazníkovi schválena všemi odpovědnými osobami dle matice odpovědnosti. Součástí nabídky může být i průvodní dopis a konkrétní cenová kalkulace. Pro vytvoření nabídky (všech jejích částí) byly vytvořeny závazné vzory, které jsou v otevřeném formátu dostupné na intranetu společnosti. Tyto vzory musí být použity vždy, pokud zákazník nepožaduje vlastní dokumenty. Schválená nabídka je zákazníkovi předána buď osobně ve fyzické podobě (což je většinou spojeno s její prezentací), nebo v elektronické formě v uzavřeném formátu (většinou PDF). V některých specifických případech (celorepubliková působnost zakázky, nabídky pro speciální projekty nebo při čerpání dotací z Evropské unie) musí obchodník ještě informovat osoby odpovědné za danou oblast. Informace by, dle vnitřního předpisu, měla proběhnout formou e-mailu. Smlouva je závaznou objednávkou nabídnutých služeb za dohodnutou cenu. Musí mít vždy písemnou formu a musí být potvrzena oprávněnými osobami všech smluvních stran. V oprávněných případech je možné místo klasické smlouvy využít potvrzenou objednávku

87

služeb (např. pro malé jednorázové zákazníky), pokud obsahuje všechny potřebné údaje. Pro standardizaci smluv (popř. objednávek) byly vytvořeny jejich vzory, které jsou dostupné na intranetovém portálu společnosti. Tyto vzory musí být využity vždy, případně na přání zákazníka mohou být konkretizovány a doplněny o další náležitosti. Pokud zákazník požaduje vlastní smlouvu nebo doplnění nestandardních úprav, je nutné konzultovat upravenou smlouvu s interním právníkem společnosti. Každá smlouva, objednávka či dodatek smlouvy musí být zadán do systému ADG a na základě těchto dokumentů jsou následně fakturovány služby, přičemž každý řádek faktury musí být podložen smluvním dokumentem.

6.5.3 Schvalování dokumentů Základním pravidlem obchodního procesu je, že veškerá obchodní dokumentace musí být schválena dle matice odpovědnosti minimálně jedním zaměstnancem, odlišným od tvůrce příslušného dokumentu (většinou jeho nadřízeným). Matice odpovědnosti zároveň stanovuje limity jednotlivých schvalovatelů, přičemž při překročení limitu musí být dokument schválen také osobou nadřízenou. Schvalování tedy probíhá směrem od nižších pozic (MOS, OMO) k pozicím vyšším (ŘD, ZOŘ, OŘ, případně GŘ). V rámci obchodního procesu byly stanoveny dva způsoby schvalování dokumentů. Pokud je schvalovaná částka nižší než 1 mil. Kč s platností do jednoho roku, dokument je schválen ve fyzické podobě tak, že příslušný schvalovatel dle matice odpovědnosti připojí svůj vlastnoruční nebo elektronický podpis na určené místo dokumentu. Druhým způsobem je elektronické schvalování dokumentů, které je povinné pro všechny dokumenty s částkou přesahující 1 mil. Kč nebo jakýkoliv dokument vyžadující investice ze strany společnosti XYZ. ŘD nebo OMO ale může rozhodnout, že elektronicky budou schvalovány také ostatní dokumenty, které by jinak musely být schváleny ve fyzické podobě. Veškeré dokumenty, které podléhají povinnosti

88

elektronického schválení, jsou ukládány na intranetovém portálu společnosti a uchovávány v elektronické podobě po dobu stanovenou zákonem o archivnictví a vnitřním předpisem společnosti pro nakládání s dokumenty. Za provozuschopnost, zálohování a archivaci portálu zodpovídá IT oddělení. Pro každou divizi nebo úsek jsou stanoveni minimálně dva pověření zaměstnanci, kteří jsou zodpovědní za vkládání údajů do elektronických formulářů. Každý zaměstnanec, který chce zadat dokument ke schválení, by měl vyhledat některou z těchto pověřených osob a předat jí všechna potřebná data. Za úplnost a správnost dat odpovídá zaměstnanec, který žádá o schválení dokumentu. Veškeré údaje jsou následně vyplněny do elektronického formuláře, ke kterému je přiložen samotný dokument podléhající schválení, a formulář je elektronickou cestou distribuován k jednotlivým schvalovatelům dle matice odpovědnosti. Každý ze schvalovatelů musí zaujmout jednoznačné stanovisko (schvaluji, neschvaluji, prosím o doplnění), případně je možné schvalovací pravomoc delegovat na jinou osobu (např. interního právníka pro potvrzení správnosti nestandardních ujednání). Pokud je dokument schválen, přijde pověřenému zaměstnanci, který dokument založil, upozornění e-mailem. Poté má pověřený zaměstnanec do tří pracovních dnů povinnost vytisknout schválený dokument a také protokol o schválení dokumentu a fyzicky ho distribuovat ke každému ze schvalovatelů (ale nejvýše do úrovně ŘD). Všichni schvalovatelé musí opět zkontrolovat dokument (jeho fyzickou podobu) a potvrdit jeho správnost podepsáním protokolu o schválení dokumentu. Po zkontrolování všemi odpovědnými osobami je schválený dokument i protokol o schválení naskenován, nahrán na portál a fyzické verze obou dokumentů jsou vloženy do složky zákazníka.

6.5.4 Marketingová podpora obchodu Obchodní proces je podpořen ze strany marketingového oddělení vytvořením jednotného vizuálního stylu a údržbou vzorových dokumen-

89

tů, přípravou dalších propagačních materiálů a zajišťováním sponzoringu (materiálního i finančního) a partnerských dohod s různými institucemi (vysoké školy, sportovní a kulturní organizace atd.). Kromě výše uvedených aktivit má marketingové oddělení na starosti také datově informační a analytickou podporu obchodu. Její součástí je mapování a vyhodnocování obchodních aktivit a analýza informací o zákaznících, konkurenci, službách a trhu. Každý rok je marketingovým oddělením vypracován časový plán hlavních datových analýz, a navíc ještě řeší operativní požadavky na parciální výstupy. Pro vedení společnosti jsou pravidelně měsíčně zpracovávány klíčové ukazatele obchodních aktivit. Z tohoto reportu je vidět porovnání plánovaného a skutečného obratu, pohledávky zákazníků jednotlivých obchodníků, aktivity jednotlivých obchodníků, a také přehled nově oslovených zákazníků. Jednou za pololetí je provedena analýza obchodní situace celé společnosti. Tato analýza nabízí komplexní pohled na aktivity za uplynulé období a je provedena dle různých dimenzí – podle skupin zákazníků, odvětví, geograficky, podle obchodníků a divizí, nabízených služeb či dle bilance konkurenčních společností. Podobná analýza je jednou ročně provedena také pro jednotlivé divize, kdy její dimenze mohou být ještě podrobnější, např. dle jednotlivých provozů nebo jednotlivých zákazníků (ne pouze podle jejich skupin). Pro stanovení individuálních plánů jednotlivých obchodníků slouží databáze obchodního potenciálu divizí. Ta je podkladem pro určení potenciálu společnosti na trhu regionu dané divize a je rozpracována až na úroveň jednotlivých obchodníků a jim příslušejících okresů. Databáze se aktualizuje jednou ročně a je upravena na míru jednotlivým divizím a obchodníkům. Každý rok je na základě externě (Český statistický úřad, Obchodní rejstřík atd.) a interně dostupných informací zpracována analýza situace na trhu. První částí této komplexní analýzy je rozbor produk-

90

ce odpadů na území České republiky a Slovenska, přehled způsobů nakládání s odpady, stanovení podílu jednotlivých druhů odpadů a způsobů jejich likvidace, nebo podíly jednotlivých průmyslových odvětví na produkci odpadů. Výstupem analýzy je podíl společnosti XYZ na zpracování odpadů na trhu. Druhou součástí je interaktivní mapa konkurence na úroveň jednotlivých okresů, rozdělená na průmyslové a komunální zákazníky. Poslední činností marketingového oddělení v rámci podpory obchodního procesu je údržba stávajícího CRM systému, řízení přístupových práv, školení nových obchodníků na práci s tímto systémem a také údržba výstupů, které poskytuje.

6.6 Výběr dodavatele a systému Zároveň s tvorbou nového obchodního procesu probíhalo také výběrové řízení na dodavatele nového CRM systému. Projektový záměr byl zpracován do poptávkového dokumentu, který byl zaslán potenciálním dodavatelům. Reagovali ti, kteří měli zájem, a z nich byl následně na základě zhodnocení stanovených kritérií vybrán ten nejvhodnější, včetně jím nabízeného systému. Z různých důvodů (zdravotní problémy některých členů týmu, čekání na nový obchodní proces, nutnost přesnější specifikace požadavků) došlo ke zdržení projektu a výběr dodavatele musel být asi o měsíc a půl posunut.

6.6.1 Poptávka nového CRM systému Poptávkový dokument na dodávku CRM systému vycházel z projektového záměru, ve kterém již byla zpracována většina požadavků na systém, a také z oficiálního zadání projektu. Jeho předmětem byla nejenom implementace nového systému včetně licencí, ale také proškolení koncových uživatelů a zpracování manuálů. Účelem poptávkového dokumentu byla specifikace požadavků na aplikační část poptávaného CRM systému. Specifikace měla sloužit

91

pro návrh řešení CRM systému ve společnosti XYZ. Ten měl následně být prezentován přímo ve společnosti a nabídka vybrané společnosti měla sloužit pro podrobnou analýzu požadavků a následné vytvoření cílového konceptu CRM systému. Jednotlivé požadavky byly detailně popsány v draftu cílového konceptu, který byl k poptávkovému listu přiložen. V poptávkovém listu byla krátce popsána společnost XYZ a také současný a očekávaný stav celého komplexního informačního systému společnosti včetně podmínky zachování systémů ADG a ERP a nutnosti integrovat nový CRM systém s těmito dvěma produkčními systémy. Jako další standardní údaje byly uvedeny kontaktní osoby zadavatele, různá ustanovení chránící zadavatele před hrozbou soudního sporu a případnými finančními požadavky ze strany účastníků výběrového řízení a standardizovaný vzor očekávané nabídky. Další částí poptávkového dokumentu byl rámcový harmonogram výběrového řízení na dodavatele. Účastníci měli potvrdit účast ve výběrovém řízení do jednoho týdne, během následujících dvou týdnů měli vypracovat nabídku a za další dva týdny, na začátku května 2012, měl být vybrán vhodný dodavatel. Dále již mělo jít vše dle původního plánu s termínem předání systému na začátku prosince 2012. Mezi systémové požadavky na nové řešení spadala kompatibilita se softwarovým vybavením společnosti, (viz kap. 5.2), uložení databáze na interních serverech společnosti, možnost přímého přístupu k databázi, přístup k systému přes tenkého klienta i aplikaci Microsoft Outlook a také přes mobilní telefon. Dalším požadavkem byla možnost základních úprav bez asistence dodavatele (změna názvů polí, přidání nových polí a formulářů, řízení přístupových práv a rolí uživatelů atd.), možnost definice workflow bez asistence dodavatele a bez využití programovacích jazyků a také možnost definice vlastních číselníků, šablon (pro aplikace Microsoft Office) a různých pohledů na data (grafy, tabulky, kontrolní panely).

92

Nový systém musí zvládnout obsloužit minimálně 60 aktivních (zápis dat) a 20 pasivních (pouze náhled a čtení informací) uživatelů a navíc dva administrátory systému a dva administrátory databáze. Z pohledu bezpečnosti a přístupu k systému byly kladeny požadavky na integraci s Active Directory, přístup bez nutnosti zadávat heslo (ověření na základě přihlášení do systému), externí zabezpečené připojení kontrolované interní certifikační autoritou a auditování přístupů k osobním a citlivým údajům. Kromě požadavků na systém byly v poptávkovém listu specifikovány také požadavky na dodavatele. Ten měl v rámci nabídky specifikovat implementační tým s případnými subdodavateli, specifikovat princip integrace CRM systému se systémy ADG a ERP s potenciálem dalšího rozvoje, zajistit schůzku v referenční společnosti, a také se měl zavázat k zahájení prací ještě před odsouhlasením cílového konceptu a podepsáním smlouvy. Posledním požadavkem byl kompletní přístup nového IT specialisty pro CRM ze společnosti XYZ k implementačnímu týmu dodavatele. Dva týdny po distribuci poptávky mezi potenciální dodavatele muselo ještě dojít k její úpravě a upřesnění. Byl stanoven finanční limit pro celý projekt ve výši 3 mil. Kč (v souladu s očekávaným rozpočtem), přičemž uchazeči měli dodat cenovou nabídku rozepsanou do jednotlivých kategorií (analytické práce, implementace, customizace, licence, podpora, školení). Dalším doplněním bylo stanovení podmínek pro vyhodnocení výběrového řízení a přidání kontaktů na implementátory systémů ADG a ERP. Kvůli tomuto doplnění byl také posunut časový harmonogram, kdy uzávěrka nabídek, vyhodnocení a podepsání smlouvy byly posunuty o jeden týden.

6.6.2 Výběrové řízení na dodavatele Výběrového řízení na dodavatele nového CRM systému pro společnost XYZ se zúčastnilo celkem pět společností. Protože toto číslo není nijak vysoké, byli hodnoceni všichni potenciální dodavatelé. Mezi nabíze-

93

nými systémy převládal Microsoft Dynamics CRM 2011, který nabídli celkem čtyři z pěti dodavatelů. Poslední dodavatel se účastnil výběrového řízení s vlastním CRM systémem. Hodnocení uchazečů zahrnovalo čtyři oblasti – splnění požadovaných funkcionalit (na základě draftu cílového konceptu, kdy každá požadovaná funkce byla ohodnocena známkou podobně jako ve škole), návrh celého řešení, cena za kompletní dodávku (včetně nákladů na údržbu systému po jeho převzetí) a nabízené SLA včetně případných sankcí při nedodržení nabízených záruk. Každá oblast měla stanovenou váhu, se kterou se k ní přihlíželo, a mimo to některé funkcionality byly označeny jako kritické a jejich nesplnění mohlo vést k úplnému vyřazení uchazeče z výběrového řízení. Dále si každý z uchazečů měl zvolit systém ADG nebo ERP, se kterým měl být CRM systém primárně integrovaný. Jediným uchazečem, který nenabízel řešení Microsoft Dynamics CRM, byl aktuální dodavatel systému ERP. Ten nabídl dvě varianty, se kterými má bohaté zkušenosti – buď implementace CRM systému dodávaného jako rozšíření ERP systému, nebo vlastní nezávislé řešení, které by bylo integrováno s ostatními systémy pomocí externího můstku. Integrace se systémem ERP by nebyl problém, ale s integrací na systém WinyX neměla společnost žádné zkušenosti. Primárním systémem tedy byl zvolen ERP. Z analýzy nabídky bylo zjištěno, že nesplňuje dvě základní funkcionality a jimi nabízený systém je poměrně složitý na ovládání i na administraci. Navíc celková cena za nabízené řešení byla oproti ostatním nabídkám poměrně vysoká. Jedním z uchazečů byla malá společnost, specializující se na implementaci produktů Microsoft Dynamics (CRM, NAV, AX), přičemž v této oblasti byla několikrát oceněna přímo od společnosti Microsoft. Výhodou nabídky byla nízká cena za celé řešení i nízké náklady na údržbu systému po jeho převzetí. Velkou nevýhodou ale byla chybějící zkušenost s integrací CRM systému jak na systém ERP, tak na sys-

94

tém ADG, přičemž samotný uchazeč odhadnul potenciální hlubokou integraci na jeden či druhý systém z jejich strany za téměř nemožnou, případně finančně velice náročnou. Rozpočet na projekt by v budoucnu mohl významně narůst a výsledek by i tak byl nejistý. Třetím uchazečem byla také malá společnost, která se specializuje pouze na implementaci systému Microsoft Dynamics CRM. Nabídka byla z pohledu splnění podmínek téměř totožná, náklady také (i když u této společnosti trochu vyšší) a podobně jako u předchozí nabídky, i zde chyběly uchazeči zkušenosti s integrací CRM systému na ostatní produkční systémy společnosti XYZ. Dalším uchazečem byla velká česká firma s ročním obratem podobným jako společnost XYZ a velkými zkušenostmi na poli implementace podnikových systémů. Pro implementaci CRM systému se spojila s další, menší společností, která se právě na CRM systémy specializuje. Výhodou tohoto spojení bylo zázemí velkého dodavatele, komunikace na profesionální úrovni a dlouholeté zkušenosti z velkého množství projektů. Nevýhodou se ale staly vysoké náklady jak na zavedení systému, tak na jeho údržbu, a také nutnost uzavření smlouvy mezi uchazečem a dodavatelem systému ADG, který by byl mimo kontrolu společnosti XYZ. Navíc uchazeč nedokázal nabídnout záruky za partnera, se kterým se výběrového řízení zúčastnil. Posledním uchazečem ve výběrovém řízení byl současný dodavatel systému ADG, který se přihlásil společně s další společností podobné velikosti, která má také mnoho zkušeností s implementací podnikových systémů včetně CRM. Výhodou tohoto řešení byla jednoduchá integrace se systémem ADG, znalost prostředí společnosti XYZ a jejího informačního systému a také propracovaná nabídka nejlépe splňující zadání, která byla za cenu pohybující se na úrovni průměru všech ostatních nabídek. Obě společnosti také nabídly smlouvu o vzájemné spolupráci, kdy společnost XYZ uzavře smlouvu o dodávce systému CRM pouze s jednou z nich a ta bude ručit za kompletní dodávku

95

včetně prací, které musí odvést druhý partner. Nevýhodou řešení byly chybějící reference (prozatím nikde nebylo dodavatelem systému ADG podobné řešení nasazeno), a také vyšší náklady, než které byly pro projekt naplánovány. Výběrové řízení bylo vyhodnoceno na základě zaslaných nabídek na konci května 2012 a následně byly jeho výsledky prezentovány top managementu společnosti. Mezi jednotlivými vrcholovými manažery však po prezentaci nepanovala shoda nad volbou jednoho dodavatele (zejména z finančního hlediska), a tak muselo dojít k doplnění informací o jednotlivých nabídkách a vybrané nabídky byly potenciálními dodavateli osobně prezentovány před vybranými vrcholovými manažery společnosti. Tento postup způsobil další zpoždění celého projektu, kdy oproti plánu byl vhodný dodavatel vybrán až na začátku července roku 2012, tedy téměř o tři měsíce déle, než bylo původně plánováno. Celý projekt tím nabral přibližně tříměsíční zpoždění. Z jednotlivých nabídek byla nakonec vybrána ta poslední – systém Microsoft Dynamics CRM 2011 dodaný společností, která již do XYZ dodává systém ADG, a jejím partnerem, který celou dodávku CRM systému zastřešuje svými zkušenostmi a týmem odborníků.

6.6.3 Smlouva o dodávce systému Smlouva s vybraným dodavatelem nového CRM systému byla podepsána na začátku září 2012 po téměř dvouměsíčním vyjednávání jejích podmínek. Z právního hlediska se jednalo o smlouvu, která není zákonem upravena jako typ smlouvy (nešlo tedy o smlouvu o dílo). Předmětem smlouvy byla dodávka a údržba informačního systému a služeb s tím spojených. Místem plnění smlouvy bylo stanoveno sídlo společnosti XYZ a akceptace celého systému měla být provedena podepsáním akceptačního protokolu, který mohl být ze strany společnosti XYZ odmítnut pouze za předpokladu kritických nebo závažných chyb.

96

Součástí smlouvy je metodika projektového řízení dodávek informačního systému, která odráží best-practices dodavatele. Tato metodika se podpisem smlouvy stala závaznou i pro společnost XYZ. Smlouva také stanovuje cenu, kterou musí odběratel zaplatit jak za licence, tak za služby a za případný upgrade systému. Stejně tak jsou stanoveny ceny za uživatelskou podporu ve fázi po převzetí systému. Na druhé straně jsou ve smlouvě popsány podmínky SLA a HelpDesk, které se zadavatel zavázal dodržovat. Veškeré náklady jsou naprosto přesně rozepsány na jednotlivé činnosti. Nedílnou součástí smlouvy jsou také obchodní podmínky dodavatele, které byly schváleny v předstihu, licenční politika společnosti Microsoft i dodavatele (pro případ customizovaných částí), časový harmonogram projektu (resp. implementační části projektu) splňující podmínky zadání projektu a stanovení minimální konfigurace koncových stanic pro práci se systémem. Aktualizovaný harmonogram projektu dle smlouvy je na obr. 6.2.

obr. 6.2 Aktualizovaný harmonogram projektu dle smlouvy, zdroj: autor

97

6.7 Implementace systému Po podpisu smlouvy o dodávce CRM systému mohl být daný systém implementován. Smlouva stanovila harmonogram jeho implementace, ze kterého vyplývá, že první fází byla analýza situace ve společnosti XYZ a návrh konkrétního řešení, resp. rozpracovaná verze návrhu řešení v rámci nabídky dodavatele z výběrového řízení. Výsledkem analýzy měl být cílový koncept CRM systému, na jehož základě došlo k jeho vlastní instalaci. Následoval pilotní provoz systému, a závěrem implementační fáze projektu bylo nasazení nového systému do ostrého provozu.

6.7.1 Schválení cílového konceptu První verze cílového konceptu ze strany dodavatele byla odevzdána přesně dle aktualizovaného časového harmonogramu, tedy na konci října 2012. V průběhu přezkoumání této verze dokumentu však bylo zjištěno, že došlo k vzájemnému nepochopení obou stran v některých záležitostech (zejména v oblasti obchodního a technologického názvosloví), samotná analytická část byla výrazně náročnější, než se původně očekávalo, a také bylo žádoucí jasněji definovat některé činnosti a interní procesy společnosti XYZ. Navíc schůzky analytického týmu byly shledány neefektivními, protože jejich organizace neodpovídala metodice stanovené ve smlouvě, a navíc z nich nebyly pořizovány zápisy. Vedoucí celého projektu byl po část této fáze projektu zdravotně indisponován a nemohl se projektu plně věnovat. Výsledkem bylo odmítnutí cílového konceptu a nutnost jeho přepracování ze strany dodavatele, přičemž pro dokončení analytické části získal dodavatel další tři týdny. Konečná verze cílového konceptu měla být hotova a schválena až v polovině listopadu 2012. Dalším problémem, který ve fázi analýzy aktuální situace nastal, byla nutnost zahrnout motivační program pro obchodníky. Tento požadavek byl sice v poptávce nového systému promítnut, ale systém

98

Microsoft Dynamics CRM žádný takový algoritmus neobsahuje a celý motivační program musel být vytvořen nově. Původní cílový koncept s tímto programem ani nepočítal, a po upozornění ze strany schvalovatele cílového konceptu musel být doplněn do jeho další verze. Jak se ukázalo, ani posunutý termín nebyl reálný pro provedení kvalitní analýzy a návrhu nového řešení, a tak byla druhá verze cílového konceptu dokončena až na začátku prosince roku 2012. Tato verze ještě prošla několika úpravami a opravami. Konečná podoba cílového konceptu byla schválena a podepsána na konci roku 2012 – tedy v době, kdy dle původního záměru měl již být nový CRM systém zaveden a předán do ostrého provozu. Harmonogram projektu byl tedy opět aktualizován a jeho verze z konečného cílového konceptu je na obr. 6.3.

obr. 6.3 Aktualizovaný harmonogram projektu dle cílového konceptu, zdroj: autor

Z důvodu významného posunutí časového harmonogramu bylo rozhodnuto, že s instalací a nastavením nového systému se nebude čekat až do dokončení cílového konceptu, a s pracemi se začalo již dříve, přibližně na začátku listopadu 2012. Díky tomu byl již při dokončení

99

cílového konceptu částečně funkční testovací režim a instalace systému nemusela začínat od začátku.

6.7.2 Popis cílového konceptu CRM systému dle cílového konceptu zahrnuje oblast marketingu, evidenci zájemců, obchodních vztahů, obchodních případů, nabídek a návrhů smluv, dále obsahuje integrační nástroj Scribe a vazbu na databáze systému ADG a ERP. Mimo nativní součásti obsahuje ještě customizované části pro možnost zobrazení agregovaných smluv a faktur a také aplikaci pro žádost o dobropis. Systém je logicky rozčleněn na čtyři navzájem nezávislé organizace. Dvě organizace jsou provozní, jedna pro Českou republiku a druhá pro Slovensko. Třetí organizace je testovací pro potřeby školení uživatelů a ověřování nových nastavení a funkcí. Poslední organizace je vývojová, která je nasazena u dodavatele systému, a slouží k nastavení podnikových procesů a k realizaci programových úprav. Tyto úpravy jsou následně transportovány do testovací, a případně i do provozní organizace. Cílový koncept také podrobně popisuje jednotlivá nastavení parametrů shodných pro celý systém. Do těchto parametrů patří formát jmen, počet desetinných míst u cen produktů, nastavení sdílení záznamů, automatické číslování některých entit, fiskální parametry a použité měny, dostupné jazykové mutace nebo propojení na intranetový portál společnosti. Další součástí cílového konceptu bylo stanovení rolí pro jednotlivé uživatele. Kromě předdefinovaných rolí byly také vytvořeny nové role na základě požadavku společnosti. Jednotliví uživatelé tedy spadají do jedné z rolí Administrátor, Obchodník, MOS, OMO, Management nebo Asistent. Asi nejdůležitější součástí konceptu byl podrobný popis jednotlivých entit, resp. polí, která entity obsahují, a jejich grafického vzhledu. Mezi základní entity patří Zájemce, Firma, Kontakt, Úkol, Schůzka, Žá-

100

dost o dobropis, Obchodní případ, Nabídka, Smlouva, Agregovaná smlouva a Agregovaná faktura. Kromě nich existuje ještě patnáct dalších entit. Každá z entit byla dopodrobna rozebrána a byla popsána jejich jednotlivá pole včetně typu pole a výchozích hodnot. Kromě entit byly definovány a popsány také další nativní funkce systému, např. anti-duplikační nástroj pro řešení nekonzistentnosti dat, reportingové nástroje (grafy, tabulky, seznamy a dashboardy), včetně nově vytvářeného motivačního programu MP. Poslední součástí cílového konceptu byl plán migrace dat ze stávajícího CRM systému a dalších používaných systémů do nového systému. Pro počáteční migraci se počítalo s využitím zabudovaného nástroje v kombinaci s implementovaným nástrojem Scribe. Migrace měla být provedena nejdříve do testovacího prostředí a následně do ostrého prostředí.

6.7.3 Architektura nového CRM systému Jak jsem již psal v kap. 6.6.2, pro implementaci ve společnosti XYZ byl vybrán CRM systém Microsoft Dynamics CRM 2011. Cílový koncept stanovil architekturu systému včetně integrace s ostatními produkčními systémy společnosti tak, jak je graficky znázorněna v příloze č. 3. K CRM systému se dá přistupovat dvěma způsoby. První možností je využití tenkého klienta. Tím je v zásadě jakýkoliv běžný internetový prohlížeč, přičemž standardem ve společnosti XYZ je použití prohlížeče Internet Explorer. Druhou možností je speciální doplněk pro aplikaci Microsoft Outlook 2010. Ten je standardním vybavením každého uživatele, který k CRM systému má přístup. Každý z uživatelů si z těchto dvou možností může vybrat tu, která mu vyhovuje lépe. Komunikace mezi tenkým klientem a samotným systémem probíhá prostřednictvím Internetu s využitím zabezpečeného protokolu HTTPS. Celý provoz je navíc směrován přes dva firewally, které slouží k vyššímu zabezpečení komunikace. Díky kombinaci zabezpečeného protokolu a dvou firewallů je spojení považováno za dostatečně bez-

101

pečné, aby bylo možné se připojit k CRM systému i mimo vnitřní síť společnosti XYZ bez použití příslušné VPN. Uživatelé jsou ověřováni přímo ze systému na adresář uživatelských účtů v rámci Active Directory. Pokud je uživatel připojen na svém pracovním počítači, je autentizován na základě přihlášení se do systému Windows a nemusí se znovu přihlašovat. Jinak uživatel musí zadat své uživatelské jméno a heslo – s CRM systémem je tedy možné jednoduše pracovat i na počítačích, které nejsou pod správou IT oddělení společnosti XYZ. Pokud uživatel volí pro komunikaci se systémem doplněk pro Microsoft Outlook 2011, není nativně schopný se k systému připojit mimo firemní síť bez VPN. Proto je hned za firewally implementována služba IFD (Internet Facing Deployment). Tato služba je standardně nabízena se systémem Microsoft Dynamics CRM 2011 a umožňuje koncovým klientům přistupovat k systému právě bez použití VPN i mimo firemní síť [61]. Služba IFD ke svému běhu vyžaduje použití další služby ADFS (Active Directory Federation Services) pro ověřování uživatelů v rámci firemního adresáře identit [62]. Uživatel se navíc nemusí znovu přihlásit do CRM systému, ale jeho identita je ověřena na základě přihlášení do systému Windows. Samotný CRM systém má přímý přístup pouze do vlastní databáze. Pro práci s daty z ostatních databází (zejména produktivní a replikované databáze systému ADG) je použit integrační nástroj Scribe. Ten slouží k integraci dat z různých systémů a zajišťuje jejich konzistenci napříč systémy [63], přičemž nabízí řešení přímo na míru pro systém Microsoft Dynamics CRM 2011 [64]. Přes Scribe tedy CRM systém může pracovat s daty ze systému ADG (údaje o firmách, kontakty, smlouvy a agregované faktury), ERP (úhrady a opravné položky) a také komunikuje s replikovanou databází, nad kterou se počítají data pro motivační program MP.

102

6.7.4 Rizika projektu Cílový koncept obsahoval také přehled rizik, která hrozila ve fázi implementace systému. Jako stěžejní riziko byl identifikován harmonogram projektu. Jak se již v předchozích měsících ukázalo, časový plán projektu byl opravdu poměrně krátký a neodrážel reálné potřeby komplexního projektu implementace CRM systému. Ještě před schválením cílového konceptu došlo k několikerému přehodnocení harmonogramu projektu a i konečná verze upozorňuje na to, že časový plán stále neodráží realitu. Zároveň harmonogram neobsahoval žádné rezervy a daly se očekávat problémy s lidskými zdroji (zejména klíčovými uživateli), resp. hrozily kolize mezi jejich běžnými pracovními povinnostmi a mimořádnými požadavky ze strany projektového týmu. Pro snížení rizika bylo navrženo přiřazení dostatečného množství kapacit ze stran odběratele i dodavatele, stanovení priorit jednotlivých etap, a také vytvoření scénáře pro případ dalšího zpoždění projektu. Druhým rizikem bylo využití nových funkcionalit a systémů, se kterými nemají administrátoři společnosti XYZ zkušenosti. Hlavním rizikem je úroveň zvládnutí nově zaváděných procesů a funkčností, a také rychlý a kvalitní vývoj požadovaných customizovaných částí systému. K eliminaci tohoto rizika by mělo přispět přiřazení dostatečného množství kapacit po celou dobu realizace projektu jak ze strany dodavatele, tak ze strany společnosti XYZ. Třetím rizikem byl shledán nově dodávaný motivační program MP. Technicky je proveditelný, ale v době schválení cílového konceptu ještě nebyl zcela přesně specifikován z obou stran a jeho výstupy byly zatím pouze teoretické. Navrženým řešením bylo provedení separátní studie proveditelnosti tohoto programu a s ní spojená podrobnější a přesnější specifikace požadavků a očekávání. Posledním identifikovaným rizikem bylo již několikrát zmíněné hrozící nepřijetí nového systému ze strany uživatelů. Ti se obecně ne-

103

chtějí učit používat nový systém a být pod neustálou kontrolou svých nadřízených. Dodavatelem navrhované řešení pro eliminaci tohoto rizika sestávalo z přizvání koncových uživatelů k analýze požadavků a návrhu systému, výběru několika klíčových uživatelů, kteří budou pro nový systém nadšení a přispějí k jeho popularizaci, a také z případné finanční motivace při využívání nového systému.

6.7.5 Testování systému V rámci cílového konceptu byl také stanoven základní testovací scénář pro ověření správné funkčnosti nového systému. Pro otestování systému byli využiti kromě členů testovacího týmu také další klíčoví uživatelé, kteří testovali systém v rámci školení. Testovací scénář probíhá následovně. Data o zákaznících jsou importována do databáze CRM jako zájemci. Zájemce je přiřazen obchodníkovi nebo si ho obchodník vybere sám, a následně klasifikuje zájemce jako potenciálního zákazníka. Ten je následně zkontrolován v systému OCTOPUS a jeho záznamy jsou aktualizovány. Obchodník poté provede v systému záznam několika schůzek u daného zákazníka, přičemž alespoň jedna ze schůzek by měla být typu zjišťovací a měla by obsahovat vyplněný zjišťovací formulář. Následně obchodník založí obchodní případ a k němu vytvoří několik nabídek, které projdou schvalováním (v rámci tohoto kroku je otestováno, zda funguje správně workflow). Jedna z nabídek je označena jako akceptovaná a ostatní by se měly automaticky uzavřít. Obchodník obdobně pokračuje návrhem smlouvy, který opět musí projít schvalovacím procesem. Následně je z návrhu smlouvy vytvořen fyzický dokument (kontrola správnosti tiskové sestavy) a automaticky se zašle požadavek na synchronizaci zákazníka do systému ADG. Smlouva je potom zanesena do systému ADG a měla by být přenesena přes Scribe zpět do CRM. Tato smlouva by se automaticky měla zařadit pod obchodní případ a do agregovaných smluv. Následně je

104

z objednávky vytvořena faktura, která by měla být přenesena do CRM systému jako agregovaná faktura. Celý proces je několikrát opakován v různých variantách (nabídka byla zamítnuta při schvalování, nabídka byla odmítnuta zákazníkem, smlouva byla odmítnuta při schvalování, smlouva byla odmítnuta zákazníkem, došlo ke změně údajů, bylo vytvořeno několik smluv a faktur, které musí být agregovány do CRM atd.).

6.8 Školení uživatelů Školení uživatelů nového systému je nedílnou součástí každé implementace nového informačního systému, a ani zavádění CRM systému do společnosti XYZ nebylo v tomto ohledu výjimkou. Školení uživatelů probíhalo dle harmonogramu stanoveného v cílovém konceptu po předání testovacího prototypu systému, a obsah jednotlivých školení se lišil podle toho, kteří uživatelé se ho účastnili. Administrátoři CRM systému byli proškoleni nejdříve a nejdůkladněji, přičemž znalosti systému ještě dále rozvíjeli při testování systému a jeho přezkoumání pro účely akceptace systému. Základními oblastmi jejich školení byly aplikační komponenty a procesy (samotný CRM server, integrační nástroj Scribe a různé procesy a konfigurace), údržba systému a zálohování dat, základní nastavení aplikace a také základy customizace systému, které budou prováděny bez interakce s dodavatelem (nastavení workflow nebo přejmenování polí). Klíčoví uživatelé systému byli průběžně školeni pro používání standardních funkcí systému. Jejich cílem bylo detailně pochopit nový systém z uživatelského pohledu a následně tyto znalosti předat běžným uživatelům systému. Ti tedy nebyli školeni ze strany dodavatele ani administrátorů systému, ale ze strany klíčových uživatelů. Dalším úkolem klíčových uživatelů bylo podat primární podporu uživatelům v případě některých nejasností. Teprve v případě, že by si klíčoví uživatelé nevěděli rady, požádali by o podporu některého z administrátorů systému.

105

6.9 Kontrolní mechanismy Stanovení kontrolních metrik je základním předpokladem pro možnost hodnocení výkonnosti nového procesu a pro předcházení zbytečným chybám, které by snížily jeho účinnost a zhoršily pozici společnosti XYZ na trhu. V rámci projektu implementace nového CRM systému byly interním auditorem a MISŘ stanoveny základní kontroly, které mají za cíl zhodnotit výkonnost nově definovaného obchodního procesu a zajistit správné využívání implementovaného CRM systému. Jednotlivé kontroly jsou rozděleny do čtyř skupin na obecné, kontroly fakturace a dobropisů, kontroly plateb od zákazníků a pohledávek a na kontroly technického rázu.

6.9.1 Obecné kontroly Obecné kontroly obchodního procesu provádí OMO nebo jím pověřená osoba. Jednou ročně je zkontrolováno dodržování postupu pro archivaci obchodních dokumentů (smluv, objednávek, dodatků) včetně toho, zda byly archivovány všechny ukončené kontrakty. Kvartálně je několik náhodně vybraných nabídek a smluv zkontrolováno na soulad s kalkulací nebo s prodejním ceníkem. Stejně tak čtvrtletně se namátkově kontrolují složky zákazníka. Obsahem kontroly je zejména samotná existence složky zákazníka, její kompletnost jako celku (že obsahuje všechny dokumenty, které obsahovat má) i kompletnost všech jejích dokumentů, zejména z pohledu schvalování (kontrola protokolu o schválení). Součástí této kontroly je také ověření zadání smluv do systému ADG z pohledu jejich správnosti a včasnosti. Kromě složek zákazníka podléhá pravidelné kvartální kontrole také samotný zákazník. Několik náhodně vybraných klientů je prověřeno v Obchodním rejstříku, zda vůbec existují a jestli jsou údaje o nich aktuální (např. jestli se klient nepřejmenoval). Dále jsou vybraní zákazníci prověřeni v databázi CreditCheck a je znovu zhodnocena jejich rizikovost.

106

Měsíčně jsou také náhodně hodnoceny faktury a kvalita dodávek u vybraných zákazníků. Všechny případné reklamace či stížnosti ze strany zákazníka jsou také jednou za měsíc zkontrolovány a je vyhodnoceno, zda došlo k jejich nápravě.

6.9.2 Kontroly vystavených faktur a dobropisů Faktury a dobropisy jsou kontrolovány příslušným ED minimálně jednou za čtvrtletí na vybraném provozu divize a následně alespoň jednou za rok na každém z provozů. Faktury mohou být vystaveny za svoz komunálního nebo průmyslového odpadu, prodej druhotných surovin, pronájem nádob, prodej či pronájem majetku a za ostatní pravidelné či nepravidelné služby nesouvisející s odpadem (ekologické poradenství, vedení účetnictví, čištění města, údržba veřejného osvětlení, sanační práce atd.). U několika náhodně vybraných faktur se kontroluje, jestli je zadané správné množství a cena včetně správné sazby daně, zda podklady pro fakturaci odpovídají faktuře, zda byla faktura zaplacena a případně předána k vymáhání pohledávek či zda byla správně importována do účetního systému. Kromě samotných faktur také dochází ke kontrole smluvního vztahu včetně smluvní doby splatnosti a jejího správného zadání na faktuře. V rámci fakturace se také kontroluje množství úprav faktur po jejich zaúčtování, schválení daných změn oprávněnými osobami a správnost faktur z hlediska výkaznictví a reportingu. U dobropisů se kontroluje návaznost na původní dokument, ke kterému byl dobropis vystaven, dále schválení dokumentu příslušnými zaměstnanci, správnost zaúčtování dobropisu či prokazatelnost doručení dobropisu zákazníkovi.

6.9.3 Kontroly plateb od zákazníků a pohledávek Z pohledu zákaznických plateb je ze strany zástupce hlavního účetního jednou ročně kontrolováno správné zařazení plateb na účty hlavní knihy a včasnost zaznamenání plateb ze strany společnosti XYZ, a dále je

107

měsíčně kontrolováno správné zaúčtování zápočtů pohledávek (včetně trojstranných i jednostranných pro nedobytné pohledávky), jsou zkontrolovány příslušné pokladní doklady, a také jsou vytipováni problémoví zákazníci a u nich jsou prověřeny možné zápočty promlčených pohledávek či konkurzní pohledávky. Specialista pohledávek kvartálně kontroluje dodržování splátkových kalendářů a obecně platební morálku problémových zákazníků. Společně se splátkovými kalendáři jsou kontrolovány také jejich změny a práva osob, které změny splátek schválily. Dvakrát měsíčně je také aktualizována černá listina problémových zákazníků. Na základě zprávy z oddělení centrální správy pohledávek následně každý OMO jednou za čtvrtletí zkontroluje pravidla dodržování postupu pro vymáhání pohledávek soudní cestou (pokud jsou dlouhou dobu nesplacené). OMO také zkontroluje soulad plateb od zákazníků se stanovenými platebními podmínkami a dodržování splátkových kalendářů u méně problémových zákazníků.

6.9.4 Technické kontroly Kontroly technického rázu jsou prováděny zaměstnanci IT oddělení. Na základě nastavení intervalu zálohování (denně, týdně, měsíčně dle důležitosti dat) mají probíhat pravidelné kontroly, zda záloha probíhá správně. Tyto kontroly jsou prováděny automatizovaně zálohovacím systémem a odpovědný zaměstnanec kontroluje pouze záznamy o proběhlých zálohách. S kontrolami zálohování souvisí také obnova dat. Prověření dat musí nastat při každém zjištění ztráty dat ze strany zaměstnance nebo při každém požadavku na obnovení dat, ať už ze strany zaměstnance, nebo z důvodu selhání systému. Data v systému jsou také kvartálně kontrolována i bez požadavku na jejich obnovení. Kontroly se týkají zejména duplicit v datech, jejich jedinečnosti a kontroly správného provedení změn (zavedení nových ceníků, tarifů, souvislost fakturačních řad atd.).

108

Čtvrtletně probíhá kontrola přístupových práv jednotlivých zaměstnanců. Kontrola by měla být zaměřena zejména na přidělení práv, která odpovídají pozici zaměstnance (aby práva nebyla ani příliš omezující, ani příliš volná), a také na splnění všech aktivit při ukončení pracovního poměru se zaměstnancem (zneplatnění uživatele v číselníku, odstranění z aliasů a distribučních skupin, zakázání hesla nebo jeho restartování a zneplatnění e-mailové adresy). Pokud dojde k ukončení pracovního poměru kvůli hrubému porušení pracovní kázně a existuje riziko zneužití přístupu ze strany zaměstnance (např. při ukončení pracovního poměru s administrátorem systému), je potřeba tuto kontrolu provést okamžitě se zaměřením na příslušného uživatele.

6.10 Spuštění systému a jeho převzetí Po otestování systému a proškolení uživatelů byl nový CRM systém spuštěn do pilotního provozu. Riziko zpoždění projektu, které bylo popsáno v kap. 6.7.4, se ukázalo více než reálným a došlo k dalšímu zpoždění projektu. Nový systém byl do pilotního provozu nasazen na začátku dubna 2013 (tedy asi o měsíc později, než bylo plánováno), v polovině května 2013 byl vydán a distribuován metodický postup pro práci s CRM systémem a na začátku června byl nový systém spuštěn do ostrého provozu. Po měsíčním zkušebním období byl na konci června roku 2013 oficiálně převzat do správy společnosti XYZ a tím fakticky skončila hlavní část projektu implementace CRM systému do společnosti XYZ.

6.10.1 Metodický postup pro využití CRM systému Oficiální pokyny pro jednotlivé uživatele nového systému a konkretizace obchodního procesu byly do společnosti komunikovány prostřednictvím dokumentu Metodický postup pro zavádění CRM systému do provozu. Tento dokument byl vypracován CIO, oponován ZOŘ a schválen OŘ. Dokument je závazný pro všechny zaměstnance účastnící se obchodního procesu, zejména pro obchodníky, MOS, OMO

109

a ŘD. Pokud existují rozdíly mezi tímto metodickým postupem a obchodním procesem, platí to, co je napsáno v metodickém postupu. Základní informací v metodickém postupu je, jak získat přístup k systému. Jsou zde tedy odkazy na webové adresy, přes které je přístupný jak samotný systém, tak jeho testovací verze. Uživatelé mají na základě metodického postupu povinnost zadávat do CRM systému minimálně schůzky (přes Microsoft Outlook, nejdéle v den jejich konání, následně musí být v CRM systému ukončeny), žádosti o dobropis, nabídky, návrhy smluv a dodatky ke smlouvám. Jednotlivé dokumenty musí mít vždy číslo přidělené CRM systémem, ale nemusí být přímo ze systému generovány (mohou být přiloženy ve formátu DOC či PDF). U dokumentů mají uživatelé za povinnost měnit jejich stav dle vývoje obchodního případu (připraveno, akceptováno, zamítnuto, vráceno). Poměrně podrobně je popsán také princip synchronizace údajů mezi CRM systémem a ADG. Při zadávání informací o zákaznících, pobočkách a smlouvách do systému CRM musí být vyplněno speciální pole, ve kterém je evidována osoba zodpovědná za kontakt mezi obchodníkem a systémem ADG (typicky asistentka obchodního oddělení dané divize). Obchodník, který chce synchronizovat zákazníka, pobočku, smlouvu nebo její dodatek do systému ADG, musí zmáčknout tlačítko na příslušné kartě a následně je odpovědné osobě vygenerován úkol s požadavkem na synchronizaci. Daná odpovědná osoba poté musí založit nový záznam v systému ADG (u smluv a dodatků) nebo zkontrolovat a doplnit automaticky založený záznam (u zákazníků a poboček), potvrdit jejich správnost, a následně stiskem tlačítka synchronizovat údaje zpět do CRM systému. Metodickým postupem je také konkretizováno schvalování dokumentů, které je jinak podrobně popsáno v novém obchodním procesu. Dle tohoto postupu se schvalují veškeré dokumenty, které jsou do systému zadány, bez ohledu na částku a druh dokumentu. Tímto je

110

tedy změněn obchodní proces, kdy do elektronického schvalování jdou i všechny dokumenty s částkou nižší než 1 mil. Kč. Schvalování se spouští stiskem příslušného tlačítka a probíhá dle matice odpovědnosti s tím, že je možné ještě přidat jednoho schvalovatele předcházejícímu maticovým schvalovatelům. Každý ze schvalovatelů má na schválení maximální předepsaný limit, do kterého by se daným úkolem měl zabývat. Jednou z povinností zadavatele dle obchodního procesu je zkontrolovat kredibilitu potenciálního zákazníka. Databáze OCTOPUS, která je zmíněna v obchodním procesu, byla s platností od tohoto metodického postupu zaměněna za systém CreditCheck, který funguje na podobném principu. Systém automaticky jednou denně kontroluje všechny zákazníky, a pokud zjistí zhoršení dosaženého skóre, upozorní na tuto skutečnost uživatele, který zákazníka do systému zadal. Ten je potom zodpovědný za další kroky, o kterých musí také informovat svého nadřízeného. Poslední informací v metodickém postupu je nový princip výkaznictví zaměstnance. Ten stanovuje, že veškeré ukazatele a obchodní případy musí být dostupné v novém CRM systému. Pokud ho uživatel používá správně a zadává do něj reálná a správná data, není od něj vyžadováno žádné další výkaznictví.

6.10.2 Akceptační protokol V souladu s uzavřenou smlouvou bylo převzetí systému do ostrého provozu potvrzeno akceptačním protokolem. Ten byl oběma stranami podepsán na konci června 2013 a od daného dne tedy nový CRM přešel oficiálně pod správu interního IT oddělení společnosti XYZ. Převzetí systému ovšem neproběhlo bez výhrad. Byly identifikovány celkem tři problémy, které ale nebyly kritického rázu a nebránily v řádném využívání nového CRM systému. První chybou je špatné fungování pluginu, který kopíruje dříve vytvořenou nabídku jako předlohu pro novou nabídku. Druhý problém byl při komunikaci CRM sys-

111

tému s intranetovým portálem společnosti, kdy Microsoft SharePoint špatně pojmenovával soubory a knihovny. Tyto dva problémy měly být vyřešeny do jednoho měsíce od převzetí systému. Posledním problémem byl nekompletní přenos dat prostřednictvím nástroje Scribe, kdy ne vždy byla přenesena všechna data. U tohoto problému byla identifikována jeho příčina a bylo přislíbeno řešení do konce října roku 2013.

6.11 Post-implementační fáze projektu Převzetím nového CRM systému do správy společnosti ta pravá administrátorská práce teprve začíná. Systém je sice nasazen a přebrán, ale klíčoví uživatelé a administrátoři musí řešit každodenní operativní problémy a vypořádávat se s nápady manažerů na rozšíření možností systému a nainstalování nových funkcí. Top management společnosti také vyžaduje pravidelné zprávy ohledně stavu systému a jeho využívání a uživatelé požadují operativní výstupy. Dle posledního manažerského reportu z února roku 2014 byly vyřešeny všechny problémy, popsané v kap. 6.10.2. Systém je stabilní a probíhá zejména oprava chyb (především multiplicitní údaje a občasný krátkodobý výpadek integračního nástroje Scribe), optimalizace algoritmu pro počítání motivačního programu MP a úprava jednotlivých workflow. Mezi další činnosti patří průběžné školení uživatelů, zpracovávání pravidelných reportů, optimalizace databázových struktur a hledání dalších možností, jak uživatelům usnadnit práci se systémem a zefektivnit jejich činnost. Dále probíhá rozšiřování systému o možnosti analýzy konkurenčních společností a vyhodnocení úspěšnosti marketingových kampaní.

112

7 Zhodnocení projektu Cílem této diplomové práce je porovnání teoretických principů projektového managementu se zaměřením na implementaci podnikových informačních systémů (které byly popsány v teoretické části) s konkrétním projektem zavádění CRM systému do podniku (který byl popsán v praktické části). A právě porovnání teoretického přístupu a praktického projektu je stěžejním prvkem poslední kapitoly této práce. Kromě tohoto porovnání také nabízím vlastní zhodnocení samotného projektu. Veškeré myšlenky v této kapitole vyjadřují pouze názor autora na danou problematiku a neměly by být brány dogmaticky jako názor členů projektového týmu nebo ostatních zaměstnanců společnosti XYZ.

7.1 Důvody pro změnu systému Důvody pro výměnu CRM modulu za nový CRM systém jsou podrobně popsány v kap. 6.1. Dle mého názoru jsou naprosto relevantní a s podobnými problémy se dříve či později setká každý podnik, který se rozrůstá, a který má implementovaný zastaralý CRM systém. Stejně tak již několik generací podnikatelů se snaží co nejvíce automatizovat práci a 21. století jim k tomu nabízí čím dál tím více prostředků. Není tedy třeba lpět na zastaralých postupech, jakými je třeba nutnost schválení fyzického dokumentu jeho podpisem, pokud jsme schopni správné schválení prokazatelně dokázat pomocí informačního systému. Důvody pro změnu systému plně chápu, shledávám je relevantními a dle mého názoru je dobře, že společnost XYZ sáhla k výměně zastaralého CRM modulu za nový systém.

7.2 Projektový záměr Vytvoření projektového záměru a jeho prezentaci vedení společnosti jako podklad pro jejich rozhodování vnímám také pozitivně. Celý dokument je poměrně krátký a výstižný, což je ideální pro vytížené manažery, kteří nemají příliš mnoho času na jeho analýzu. Nakonec celý do-

113

kument splnil účel a na jeho základě byl projekt podpořen top managementem společnosti, což vypovídá o jeho kvalitě – a tím nemyslím jen kvalitu z pohledu navrhovaných myšlenek a postupů, ale také kvalitu z pohledu přizpůsobení se cílové skupině. Analýza rizik je asi nejdůležitější součástí projektového záměru, protože jejím cílem by mělo být upozornit top management společnosti na nutnost výměny CRM systému a „prodat“ zamýšlený projekt, aby vrcholoví manažeři schválili jeho spuštění a podpořili ho alespoň finančně a vyčleněním potřebných lidských zdrojů. V projektovém záměru hodnoceného projektu se ale analýza rizik aktuálního stavu objevuje až na konci celého dokumentu ve formě jednoho krátkého odstavce. Na druhou stranu požadavky na nový systém jsou hned na začátku dokumentu a jsou podrobně rozepsány na necelé dvě stránky (téměř polovinu celého dokumentu). Osobně se domnívám, že jedním z důvodů je osoba zpracovatele daného dokumentu – tím byl CIO společnosti, který se na problematiku díval více technicky než manažersky. Prezentací se z mého pohledu snažil top management společnosti přesvědčit ke schválení projektu spíše formou ukázky toho, co by bylo možné implementovat a přinést do společnosti, než snahou vzbudit strach z potenciálních hrozeb. Z analýzy jednotlivých dokumentů z počátku celého projektu mám také pocit, že jednotliví manažeři intuitivně tušili, že aktuální stav není úplně ideální, byli si alespoň částečně vědomi rizik a problémů a zastávali poměrně jednotný názor, že se situace musí změnit. V takovém případě hodnotím zaměření projektového záměru kladně, protože jeho tvůrce velice dobře odhadnul atmosféru mezi cílovým publikem a nabídl jim přesně to, co vyžadovali. Pokud by tomu tak nebylo, doporučil bych zaměřit projektový záměr více na popis rizik aktuálního stavu a méně na návrh funkcionalit nového systému. Jednotlivé požadavky na nový systém jsou vyvážené jak z technického, tak z obchodního i z manažerského hlediska. Pozitivně vnímám zapojení ZOŘ do procesu stanovení požadavků již ve fázi projek-

114

tového záměru. Spolupráce technického (CIO) a obchodního (ZOŘ) zástupce evidentně pomohla celému projektovému záměru a obecně celému budoucímu projektu v tom, že se nestal pouze implementací nového systému, ale přinesl i změnu obchodního procesu a strategickou výhodu společnosti. Zároveň byly požadavky poměrně podrobné a již od začátku projektu tak bylo patrné, čeho by mělo být dosaženo. V rámci projektového záměru byly navrženy tři možné varianty řešení. Varianta přechodného systému nasazeného interně se mi nejeví jako příliš reálná pro tak velkou firmu, jakou XYZ je. Využití cloud computingu dle mého názoru také nebylo příliš reálné, protože v dané době ještě nepanovala mezi manažery důvěra v podobná řešení. Třetí varianta se nabízela sama, nikoli však v situaci, kdy byl systém ERP sám o sobě v post-implementační fázi a uživatelé si na něj ještě plně nezvykli. Mezi nabízenými variantami mi chybí ta, která byla nakonec zvolena – možnost samostatného CRM systému, který by byl s ostatními podnikovými systémy integrován pomocí můstku. Témata, která byla dána managementu společnosti ke zvážení, jsou poměrně obvyklá – stanovení trojimperativu projektu, jeho vedoucího a motivace pro týmové členy. Dle mého názoru se jedná o relevantní témata, pro jejichž rozhodnutí nemá předkladatel projektového záměru dostatek pravomocí.

7.3 Zadání projektu Zadání projektu téměř přesně vychází z projektového záměru, což jen dokazuje kvalitu předkládaného dokumentu a potřebu implementace nového CRM systému. Zadání projektu je také důkazem podpory daného projektu ze strany top managementu, což je velice důležité pro jeho úspěch. Strategické cíle projektu jsou zpracovány poměrně obecně, dávají tedy dostatek prostoru pro jejich zpřesnění v průběhu projektu. Jak bylo požadováno v projektovém záměru, top management rozhodl o trojimperativu projektu a dalších předkládaných tématech a jejich stanovení bylo součástí zadání projektu. Rozsah projektu téměř přesně

115

kopíroval nabízené funkce z projektového záměru, harmonogram projektu byl stanoven v rámci možností s kompletním dokončením v průběhu jednoho roku, a rozpočet projektu byl stanoven na poměrně nízkou částku (jak se nakonec ukázalo). Obecně si myslím, že zejména rychlost nasazení nového systému byla lehce přeceněna a objem potřebných financí byl naopak podceněn. To mohlo být způsobeno tím, že o obojím rozhodovali top manažeři podniku, kteří nemají dostatečné zkušenosti s projekty implementace podnikových informačních systémů. Jejich zájmem je naopak co nejrychlejší implementace za co nejmenší objem peněz. Výsledný harmonogram a rozpočet tak byl spíše kompromisem mezi oběma přístupy, než kvalifikovaným odhadem reálných potřeb.

7.4 Prvotní fáze projektu Akční plán projektu vycházel téměř výhradně ze jeho zadání, což se projevilo v naplánování trojimperativu – harmonogram přesně odrážel požadavky top managementu společnosti, jenom byl podrobněji rozepsán na jednotlivé činnosti. Rozpočet projektu byl v mezích stanovených top managementem a rozsah projektu vycházel ze strategických cílů a projektového záměru. Všechny tyto údaje tedy byly konzistentní napříč všemi úvodními dokumenty. Za vedoucího projektu byl zvolen CIO a jeho zástupcem ZOŘ. Tento přístup je v souladu s teoretickými principy (viz kap. 4.2.1) a dle mého názoru byl zvolen správně – CIO byl zkušenější v řízení projektů implementace podnikového systému, takže je rozumné, aby vedl celý projekt. Zároveň má ze své pozice dostatečné pravomoci, aby mohl činit některá méně významná rozhodnutí bez nutnosti schválení ze strany managementu společnosti. Na druhou stranu ZOŘ má větší přehled o obchodním procesu a je blíže budoucím uživatelům systému. Jeho znalosti a nadhled nad celou problematikou by měly zajistit, že se CRM nestane pouze novým informačním systémem, ale umožní komplexní přístup k zákazníkovi podpořený informačními technologiemi.

116

Z mého pohledu bylo velice správné rozdělení členů projektového týmu do menších skupin, které řešily problémy blízké jejich specializaci. Celkem bylo vytvořeno pět týmů, kdy každý z nich měl na starost jinou část projektu, a hlavní tým všechny ostatní koordinoval a následně integroval jejich výsledky. Toto rozdělení vedlo k jednoduššímu řízení celého projektu a k zajištění toho, že každá z částí bude provedena kvalitně a za přispění odborníků. Z pohledu rozdělení do týmů také vidím jako pozitivní to, že v hlavním týmu byli zástupci ze všech úseků správní části a také zástupci výkonné části. Projekt tím z mého pohledu získal na důležitosti v rámci celé společnosti, a zároveň se žádná z jejích částí nemohla cítit od projektu odříznuta. Výsledek tedy mohl být vnímán jako společná práce všech jednotlivých částí společnosti. Co se týká WBS, její použití je vhodné a určitě pomohla k naplánování celého projektu a ujasnění si jednotlivých činností, které bylo nutné provést. Z mého pohledu ale mohla být provedena detailněji. WBS tak, jak byla předložena, zahrnovala pouze základní činnosti, které se dále rozpadaly na více celků, a jejich podrobnější naplánování by z mého pohledu projektu jen prospělo. Pozitivně kvituji také to, že byla provedena vůbec nějaká analýza rizik. Tato část je při plánování projektů velice často opomíjena a následně projektový tým není připraven ve chvíli, kdy se riziko stane realitou. Ačkoliv provedená analýza rizik byla poměrně povrchní, hodnotím pozitivně její provedení, přípravu na možné problémy v průběhu projektu a definici kroků pro jejich eliminaci.

7.5 Nový obchodní proces Stanovení nového obchodního procesu bylo jedním ze základních předpokladů úspěchu projektu. Aktualizace principů obchodování je nutná pro to, aby daný proces odrážel realitu společnosti a využití nového systému. Z mého pohledu se tak ale nestalo a nový proces nejenom, že nerespektuje nový CRM systém, ale zároveň komplikuje některé každodenní činnosti obchodníků.

117

Původní myšlenka byla, že obchodní proces by měl být obecný, dlouhodobě platný a nezávislý na jednom či více konkrétních informačních systémech. S tímto přístupem plně souhlasím – dle mého názoru by koncepce obchodního procesu měla být dlouhodobě stabilní a neměla by se měnit s dostupným vybavením, pokud nedojde k opravdu velkým posunům v možnostech jednotlivých zařízení. Konkretizace celého procesu by následně měla být provedena metodickým postupem, což se také stalo. I zde nevidím žádný problém, metodické pokyny se mohou měnit častěji v závislosti na tom, jaké nové funkce jsou do CRM systému přidávány. Nechápu tedy, proč výsledný obchodní proces od této myšlenky odbočil. Pokud má být celý proces systémově nezávislý, proč je v něm zavedena povinnost zadávat všechny smlouvy do systému ADG? Tato povinnost je zdůrazněna dokonce několikrát, při popisu principu evidence každého z typů smluv (divizní, celorepublikové, speciální). Navíc v základních pravidlech obchodování je uvedeno, že všechny dohody musí být evidovány buď v systému ADG, nebo v systému ERP. Tento výrok je po několika stránkách vlastně negován, protože není možné dohody ukládat do systému ERP, ale pouze a jenom do systému ADG. Obdobně je v obchodním procesu exaktně uvedeno, že obchodník musí zkontrolovat kredibilitu potenciálního zákazníka v systému OCTOPUS. Toto nařízení je následně upraveno metodickým pokynem tak, že je místo této databáze využit systém CreditCheck. Kdyby v obchodním procesu byla stanovena obecná povinnost použít zvolený systém pro ukládání dokumentů, a zároveň obecná povinnost zkontrolovat kredibilitu potenciálního zákazníka v některém z dostupných systémů, splnil by původní záměr a stal se systémově nezávislým. Další z problémů, které jsem osobně v novém obchodním procesu identifikoval, se týká fyzických složek zákazníka. V současné době je ještě pochopitelné, že některé dokumenty musí být uchovávány ve fyzické podobě (je to stále vyžadováno zákonem). Některé z dokumentů

118

už ale mohou být pouze v elektronické podobě (např. fyzická a elektronická faktura jsou již plně rovnoprávné), a některé z nich jsou v elektronické podobě a pro použití ve složce zákazníka se musí transformovat do fyzické podoby (typicky e-mail a jeho vytištění). Přitom elektronická podoba dokumentů se pomalu, ale jistě dostává na zákonnou úroveň fyzické podoby, a dá se očekávat, že se čím dál více podniků bude snažit snižovat náklady na tisk dokumentů a budou je uchovávat v elektronické podobě. Toto ale dle daného obchodního procesu nebude možné, protože stanovuje povinnost vedení fyzické složky dokumentů pro všechny aktivní zákazníky. Pokud zákazník přestane být aktivním, složka musí být archivována jak fyzicky, tak i elektronicky. Přitom stačilo do nového obchodního procesu dodat odstavec o budoucím možném zrovnoprávnění elektronické a fyzické složky zákazníka, a budoucí přechod na plně elektronizovanou bezpapírovou kancelář by mohl být daleko jednodušší. Předchozí problémy jsou sice poměrně zarážející, ale také relativně jednoduše vyřešitelné vydáním případného nového metodického pokynu (i když dle mého názoru by se měly podobně velké změny odrážet přímo v samotném obchodním procesu a metodické pokyny by měly sloužit pouze k jeho upřesnění). Z mého pohledu se největší slabinou aktualizovaného obchodního procesu stal princip schvalování jednotlivých dokumentů. Už jen zavedení dvou principů schvalování (fyzického a elektronického) dle mého názoru neodráží realitu toho, jakým stylem se v současné době schvalují dokumenty. Naštěstí bylo obchodním procesem stanoveno, že elektronicky mohou být schváleny i dokumenty podléhající fyzickému schválení, a metodický pokyn dokonce fyzické schvalování prakticky úplně zrušil. Domnívám se ale (podobně jako v předchozím případě), že podobné významné změny by měly být přímou součástí obchodního procesu. Pro mě osobně je nejvíce zarážející princip, kdy po schválení dokumentu elektronickou cestou musí být vytištěn protokol o jeho schvá-

119

lení, a ten následně musí být podepsán schvalovateli znovu, fyzicky. Obchodní proces zde vlastně zavádí princip dvojího schválení, kdy schválení elektronickou cestou je považováno za podřadné a neprůkazné, i když ve skutečnosti tomu tak není (domnívám se, že elektronické schvalování je minimálně na stejné úrovni průkaznosti). Podobný princip schvalování vede k vyššímu množství práce, a ve výsledku spíše otravuje uživatele. Ti musí již jednou schválený dokument znovu prozkoumat, zjistit, jestli je stejný, a následně opět potvrdit svůj souhlas. Kromě práce navíc je tento princip naprosto zbytečný a dle mého názoru by měl být změněn na schvalování pouze elektronické bez nutnosti tisku jakýchkoliv dokumentů. Poslední zarážející věcí nového obchodního procesu je nutnost udržovat starý CRM modul. Tento modul má na starosti marketingové oddělení a dle mého pohledu jde o naprosto zbytečné ustanovení, které po zavedení nového CRM systému nemá žádné opodstatnění (všechna data byla převedena a starý modul není aktuálně vůbec využíván). Z mého pohledu se jedná o přechodné ustanovení platící do doby, než bude implementován nový CRM systém. Jako takové by nemělo být součástí dlouhodobého obchodního procesu, ale mohlo být stanoveno metodickým postupem s omezenou platností. Na základě předchozích odstavců zastávám názor, že aktualizovaný obchodní proces není úplně ideální a neplní základní myšlenku systémové neutrality a obecnosti, se kterou byl tvořen. Z mého pohledu by obchodní proces měl být nezávislý na konkrétním informačním systému, založený na dlouhodobých konceptech, a případně konkretizovaný metodickými postupy. Obchodní proces ve společnosti XYZ ale stanovuje povinnost využívat konkrétní systém ADG, nastavuje některé z konceptů nevhodně (zejména dvojí schvalování a nutnost vést fyzické složky zákazníků) a domnívám se, že brzy bude muset být upraven tak, aby odrážel rychle se vyvíjející realitu 21. století.

120

7.6 Výběr dodavatele a systému Poptávkový dokument na dodání CRM systému vznikl na základě projektového záměru a zadání projektu a spočíval zejména ve specifikaci očekávaných vlastností a funkcí nového systému. V originálním dokumentu chybělo několik podstatných informací, které také následně musely být doplněny. Domnívám se, že celý dokument byl tvořen poměrně hekticky a na poslední chvíli, a právě proto neobsahoval některé podstatné údaje. Dále také časový plán pro podání nabídek a vyhodnocení výběrového řízení byl velice podceněn a pro zájemce bylo téměř nemožné vytvořit kvalitní nabídku včas. Tato domněnka se nakonec potvrdila, kdy výběrové řízení nabralo oproti původnímu záměru časový deficit, a s tím musel být posunut i harmonogram celého projektu, a ten byl nakonec o více než půl roku zpožděn. Do výběrového řízení se přihlásilo pět zájemců s téměř identickými CRM systémy (s výjimkou jednoho dodavatele, který nabízel jiný systém). Osobně bych na tak velký projekt očekával vyšší účast, protože se jedná o poměrně zajímavý projekt s perspektivou dlouhodobé spolupráce, a v případě jeho úspěchu i o kvalitní referenci. Roli v tomto mohl sehrát poměrně nízký požadovaný finanční rámec projektu. Druhým důvodem dle mého názoru byla uzavřenost výběrového řízení – nejednalo se o otevřené řízení, kam se mohl přihlásit jakýkoliv uchazeč, ale byli cíleně vybráni potenciální dodavatelé a někteří z nich potom vytvořili nabídku. Každopádně číslo pět není nijak závratné a možná i to bylo cílem výběrového řízení – nemuset vybírat z několika desítek nabídek, ale cíleně oslovit vhodné kandidáty a udělat jakýsi předvýběr. To je ale pouze moje ničím nepodložená domněnka a osobně bych se přiklonil k přístupu otevřeného výběrového řízení s dvoukolovým výběrem nového dodavatele. Samotné výběrové řízení proběhlo transparentně. Byly přesně stanoveny metriky hodnocení jednotlivých uchazečů a jimi nabízených systémů, a hlavně cena nebyla jediným podstatným prvkem hodnocení.

121

Jednotlivé funkce byly rozděleny dle míry nutnosti implementace a následně bodově ohodnoceny. Vzhledem k tomu, že většina dodavatelů nabízela stejný systém, šlo více o výběr vhodného dodavatele, než o výběr samotného systému. Výběr současného dodavatele systému ADG byl z mého pohledu poměrně očekávaný, ale zároveň nešlo o žádnou protekci nebo nadměrné zvýhodňování – zvolená nabídka prostě byla transparentně vyhodnocena jako nejlepší. Podepsaná smlouva s novým dodavatelem je poměrně standardní, i když se nejedná o doporučovanou smlouvu o dílo. Přesně jak je popsáno v kap. 4.2.2, smlouva byla upravena na míru vztahu dodavatele a odběratele a z mého pohledu je kvalitní, podrobná, nezvýhodňující ani jednu ze stran a obsahující všechny náležitosti, které by smlouva o dodání informačního systému měla obsahovat (technickou specifikaci, výslednou cenu dle fází projektu, SLA, licenční podmínky pro jednotlivé systémy, metodiku vedení projektu i harmonogram jednotlivých prací).

7.7 Implementace systému Implementace systému probíhala v souladu s teoretickými přístupy popsanými v kap. 4.2.3. První částí implementace byla podrobná analýza situace ve společnosti XYZ. Analýza je asi nejdůležitější součástí celého procesu, protože pouze na jejím základě může být navrhnuto kvalitní řešení. V tomto ohledu souhlasím s dodavatelem nového CRM systému, který za hlavní riziko projektu již od začátku analytické části (resp. již od první verze cílového konceptu) označil časový plán projektu. Také z mého pohledu by pro analýzu stávající situace mělo být vyhrazeno více času, než původně zamýšlené tři pracovní týdny. Jak je patrné z kap. 6.7.1, k naplnění hrozby opravdu došlo a celý projekt musel být z hlediska harmonogramu přehodnocen. Nevím úplně přesně, proč nakonec byl ve smlouvě schválen harmonogram tak, jak byl. Domnívám se, že se opět jednalo o kompromis mezi „nezkušeným“ pohledem manažera (nezkušeným z po-

122

hledu řízení projektu implementace podnikového informačního systému) a požadavky dodavatele systému. Každopádně první verze cílového konceptu z mého pohledu odpovídala časovým možnostem, které byly dány na jeho vypracování. Stejně tak ale dodavatel nakonec uznal nevhodné řízení projektu, takže chybu bych hledal na obou stranách. Jako pozitivní vnímám fakt, že nakonec se obě strany dohodly na kompromisu a analýza stávajících podmínek byla provedena bez přílišného časového tlaku a byl vytvořen a schválen cílový koncept. Dle mého názoru je důležité, že fáze analýzy byla provedena důkladně a nebyla z důvodu časové tísně zkrácena nebo zrušena úplně. Stejně tak pozitivně vnímám rozhodnutí začít s instalací systému ještě před konečným schválením cílového konceptu. Rozdíly mezi předposlední a poslední verzí cílového konceptu byly marginální a jednalo se pouze o některých detailech. Principy nového systému, jeho architektura a většina podstatných věcí byly již rozhodnuty a nebyl problém začít s testovacím provozem systému. Domnívám se, že pokud by toto rozhodnutí nepadlo, a instalace by začala až po schválení cílového konceptu, celý projekt by byl ještě o několik měsíců delší. K samotnému cílovému konceptu není moc co říct, jedná se o technické shrnutí jednotlivých vlastností, parametrů a nastavení nového systému. Kladně vnímám detailnost celého konceptu, protože jednotlivé entity a jejich vlastnosti byly popsány velice podrobně. Následně bylo docela snadné porovnat plánovaný stav systému s jeho reálným stavem při převzetí. Stejně tak je možné dohledat různé informace v post-implementační fázi a při řešení různých problémů. Také s identifikovanými riziky souhlasím. Jednou z hrozeb opět bylo, že nový systém nebude přijat jeho uživateli, a ti ho budou využívat špatně nebo vůbec. Dle mého názoru několikanásobné zdůraznění tohoto rizika ze všech možných stran jen dokazuje, jak podstatná je volba uživatelsky přívětivého systému, a jak je důležité detailní školení a kvalitní podpora uživatelů systému. Riziko nedodržení stanoveného

123

harmonogramu jsem již okomentoval výše, a ostatní rizika se dala zvládnout poměrně bez problému. Pozitivní je také stanovení reakce pro případ, že se riziko stane realitou. Testování nového systému bylo z mého pohledu také standardní, kdy testovací scénář byl stanoven v cílovém konceptu a pro jeho provedení byli využiti uživatelé při školení. Tento přístup je poměrně praktický, protože uživatelé se učí používat systém na reálných procesech a zároveň je systém otestován. Tím jsou šetřeny náklady a čas.

7.8 Ostatní části projektu Školení koncových uživatelů probíhalo standardní cestou a v souladu s teoretickými principy (kap. 4.2.3), kdy bylo provedeno několik školení jak pro administrátory systému, tak pro klíčové i běžné uživatele. Pro měření výkonosti nového CRM systému bylo stanoveno několik metrik ze všech oblastí, které systém pokrývá. Nebyly využity mezinárodně uznávané sady metrik (např. CRMBodyCheck popsaná v kap. 4.4.2), ale byly stanoveny vlastní metriky, pokrývající veškeré oblasti, které mají být ve společnosti XYZ sledovány. To je dle mého názoru naprosto správné a metriky upravené na míru mohou dané společnosti říci o výkonnosti systému více, než metriky standardizované. Pilotní provoz byl oproti harmonogramu zpožděn, jak již bylo popsáno v kap. 6.10. Zpoždění bylo způsobeno průtahy v předchozích fázích projektu. Z mého pohledu je důležité, že i přes zpoždění projektu byl pilotní provoz zachován – mohlo by se stát, že by byl zrušen a systém by byl spuštěn bez zkušebního provozu hned po otestování. To se naštěstí nestalo. V průběhu pilotního provozu byl vydán také metodický postup konkretizující obchodní proces. Na závěr této fáze byl podepsán předávací protokol k novému systému, který je standardním dokumentem a je v souladu s teoretickým principem převzetí systému do správy podniku (viz kap. 4.2.4). Stejně tak následovala fáze údržby a rozvoje systému popsaná ve stejné kapitole. Tato fáze trvá dodnes,

124

což je také pozitivní – nový systém se neustále vyvíjí a tím je zaručena jeho rostoucí kvalita a přizpůsobení se novým požadavkům a trendům.

7.9 Shrnutí Projekt tak, jak byl proveden, přesně odpovídá teoretickým principům projektového řízení. Obecný životní cyklus projektu (kap. 3.1.3), tedy návrh (projektový záměr, zadání projektu), plánování (prvotní fáze projektu, akční plán), implementace (nový obchodní proces, výběr dodavatele, implementace systému) a dokončení (nasazení systému a převzetí systému, post-implementační práce), byl naplněn téměř beze zbytku. Obdobně teoretický životní cyklus projektu implementace informačního systému do podniku (kap. 4.2) téměř přesně odpovídá tomu, jak byl analyzovaný projekt řízen. Navíc oproti teoretickému životnímu cyklu přibyla fáze vytvoření nového obchodního procesu, což je odrazem toho, že byl implementován CRM systém. V teoretickém přístupu postrádám exaktní krok pro stanovení kontrolních metrik účinnosti nově implementovaného systému. Dle mého názoru by použité metriky měly být stanoveny ještě před samotnou implementací systému, a tento krok by mohl být zařazen jako součást teoretického životního cyklu projektu implementace podnikového informačního systému. Jak jsem psal v kap. 3.1.4, projekt může být považován za úspěšný v případě splnění trojimperativu, spokojenosti vlastníka projektu a naplnění projektového záměru. Z tohoto hlediska bohužel musím konstatovat, že projekt úspěšný nebyl. Nepodařilo se naplnit dvě z dimenzí trojimperativu (projekt nebyl dokončen včas a jeho náklady byly vyšší než plánovaný rozpočet) a nový systém zatím plně neřeší všechny představy, které do něj byly vloženy. Pokud porovnám projekt s kritérii úspěchu, popsanými ve stejné kapitole, konstatuji, že hodnocený projekt nebyl vhodně naplánován a nebyl vlastněn vedoucím projektu. Ostatní kritéria byla z mého pohledu splněna. Pro řízení projektu byly použity některé techniky a nástroje popsané v kap. 3.2.2. Jednalo se zejména o využití plánu projektu, WBS,

125

hodnotících zpráv pro management nebo projektových smluv. Pravidelně se konaly schůzky jednotlivých týmů, byly stanoveny metriky kvality nového systému, na začátku projektu proběhl kick-off meeting, byly odevzdávány pravidelné reporty o postupu projektu, a došlo také ke stanovení plánu řízení rizik (i když poměrně jednoduchému). Při řízení projektu nebyl využit žádný z obecně uznávaných standardů projektového řízení, které byly popsány v kap. 3.2.3. Na začátku projektu nebyla stanovena žádná závazná metodika, a po výběru nového dodavatele byla použita metodika, postavená na best-practices zvoleného dodavatele. Osobně bych doporučil proškolit několik vedoucích pracovníků společnosti XYZ pro řízení projektů některou z uznávaných metodik. Tito manažeři by následně mohli zastávat pozici vedoucího projektu a využít zvolené metodiky pro řízení dalších projektů, které ve společnosti XYZ proběhnou. Bylo by možné stanovit vnitřním předpisem závazné postupy pro řízení projektů, které by ideálně také vycházely z některého obecně uznávaného standardu. Výhodou by bylo jednotné vedení projektů v celé společnosti na základě mezinárodně uznávaných standardů a záruka kvalitních projektových manažerů mezi vlastními zaměstnanci. V kap. 4.4.3 je popsáno několik pravidel, která by měla vést k úspěchu projektu implementace CRM systému. Vzhledem k tomu, že analyzovaný projekt nebyl úplně úspěšný, nabízí se jeho srovnání právě s těmito pravidly. Z mého pohledu byli uživatelé zapojeni do projektu včas a byli dostatečně proškoleni pro jeho používání. Zvolený systém je také vhodný z pohledu jeho flexibility, použitelnosti a integrace s dalšími nástroji. Aktualizace a upgrade systému jsou podchyceny ve smlouvě, což je také pozitivní. Dokumentace k projektu je poměrně kvalitní, což dosvědčuje i možnost ho zpětně podrobně analyzovat. Vrcholový management společnosti je zkušený a byl projektu od začátku nakloněn, což mu zcela jistě pomohlo. Zkušenosti vedoucího projektu nemohu hodnotit (nevím, kolik podobných projektů reálně

126

dříve vedl), ale jeho zvolení bylo nejspíš nejlepší možnou volbou. Z mého pohledu se nepovedlo naplnění pravidla „Mysli velkoryse, začínej skromně“ a pravidla rozumné volby dostupných funkcí. Domnívám se, že projekt měl za cíl implementovat poměrně rychle velké množství funkcí, a dle mého názoru by bylo lepší začít s menší částí a postupně přidávat další. Stejně tak si myslím, že mohl být delší pilotní provoz, aby si uživatelé na nový systém lépe zvykli ještě před jeho převzetím a oficiálním spuštěním. Důvodem kratšího pilotního provozu ale bylo, dle mého názoru, výrazné zpoždění projektu a tlak ze strany managementu na co nejrychlejší uvedení nového systému do ostrého provozu.

127

Závěr Diplomová práce se věnuje srovnání konkrétního projektu implementace CRM systému do společnosti XYZ s teoretickými principy řízení projektů implementace podnikových informačních systémů. Jejím cílem je analyzovat vybraný projekt a na základě této analýzy navrhnout úpravy teoretického aparátu tak, aby byl využitelnější v praxi. První částí práce je obecné stanovení pojmu „řízení vztahů se zákazníky“, který jsem na základě různých definic shrnul jako „proces poznávání a udržení zákazníků podniku, což v dlouhodobém horizontu vede ke zvýšení zisků a snížení operativních nákladů. Tento proces je důležitou součástí podnikové kultury a v současné době je stále více podporován informačními technologiemi.“ Je důležité si uvědomit, že i když v poslední době je CRM vnímáno téměř výhradně jako softwarový nástroj, jedná se zejména o proces, který následně může být podpořen informačními technologiemi. Důležité jsou principy daného procesu, softwarová stránka je až druhořadá. Teoretická část práce dále pokračuje charakteristikou CRM systémů a jejich vlastností, obecnými principy řízení projektů, a také specifiky řízení projektů implementace podnikových informačních systémů. Celá teoretická část je zakončena několika pravidly pro úspěch projektu implementace CRM systému. Analyzovaný projekt implementace CRM systému probíhal ve společnosti XYZ, jedné z nejvýznamnějších firem pro nakládání s odpadem na území České republiky. Projekt ovlivnil všechna oddělení společnosti a nový systém se zařadil po bok dvou důležitých informačních systémů – ADG pro evidenci svozu odpadu a fakturaci a ERP pro účetnictví a nákupní proces. Hlavními důvody pro implementaci nového CRM systému byla uživatelská nepřívětivost starého CRM modulu a jeho omezená funkcionalita. Proto byl CIO společnosti pověřen zpracováním záměru projektu implementace nového CRM systému. Ten se skládal z krátkého popi-

128

su možných rizik aktuálního stavu, podrobného popisu požadavků na nový systém, možných variant nasazení nového systému, a také z požadavku na stanovení základních parametrů projektu od top managementu společnosti. Projektový záměr byl zpracován kvalitně a následně byl i schválen vedením společnosti, čímž mohl být na konci roku 2011 samotný projekt spuštěn. Stěžejním dokumentem byl akční plán projektu, který určuje jeho základních vlastnosti. Akčním plánem byl stanoven rozpočet projektu ve výši 3 mil. Kč, datum konce projektu (převzetí systému) na 1. 1. 2013, a rozsah projektu na aktualizaci obchodního procesu, dodání centrální databáze konkurence, databáze obchodních příležitostí a implementaci samotného CRM systému pro plánování, řízení a vyhodnocování obchodních týmů. Vlastníkem projektu se stal generální ředitel společnosti a celý projektový tým byl rozdělen do několika skupin dle odbornosti jednotlivých členů. Projekt byl rozdělen na několik základních činností a byla také specifikována základní rizika (nedodržení trojimperativu, odmítnutí systému uživateli, implementace softwarového řešení bez příslušných procesních změn) a možnosti jejich prevence. Jednou ze základních činností byla aktualizace obchodního procesu. Ten dle mého názoru není úplně ideální a neodráží novou situaci ve společnosti XYZ. Domnívám se, že obchodní proces by měl být obecný a dlouhodobě stabilní s možností konkretizace prostřednictvím metodických postupů. Jako hlavní problémy jsem identifikoval nutnost fyzického uchovávání jednotlivých dokumentů (proces do budoucna nepočítá s možností rovnoprávnosti některých elektronických a fyzických dokumentů), zbytečné dvojí schvalování (elektronické schválení musí následně být potvrzeno stejnými schvalovateli ještě fyzickým podpisem), evidenci dokumentů v jednom konkrétním systému (domnívám se, že obchodní proces by měl být systémově nezávislý) a nadbytečná přechodná ustanovení (údržba starého CRM modulu marketingovým oddělením).

129

Výběrového řízení na dodavatele nového CRM systému se zúčastnilo pět uchazečů, kteří většinou nabídli systém Microsoft Dynamics CRM, a také jeden vlastní CRM systém. Na základě předem stanovených metrik byl transparentně vybrán současný dodavatel systému ADG ve spolupráci se subdodavatelem, specializujícím se na dodávky CRM systému Microsoft Dynamics CRM. Smlouva o dodávce nového CRM systému byla podepsána na začátku září roku 2012. Následovala analýza současného stavu ve společnosti XYZ, vytvoření cílového konceptu a samotná instalace systému. Analytická fáze byla v harmonogramu projektu podceněna z hlediska časové dotace a výsledkem bylo zpoždění projektu. Systém byl předán do správy společnosti XYZ podepsáním akceptačního protokolu na konci června 2013, tedy o půl roku později, než bylo původně plánováno. Projekt bohužel nemohu hodnotit jako úspěšný z důvodu nenaplnění trojimperativu (projekt nebyl dokončen včas a rozpočet projektu byl významně překročen). Druhým důvodem je nesplnění všech cílů projektu, přičemž ale systém je neustále rozvíjen a dá se očekávat posun směrem k očekávaným přínosům. Pro další projekty ve společnosti XYZ doporučuji využít některou z obecně uznávaných projektových metodik, která by se měla stát závaznou pro všechny realizované projekty. Zároveň si myslím, že by bylo vhodné investovat do několika manažerů společnosti a nechat je proškolit právě pro řízení projektů zvolenou metodikou. Z hlediska úpravy teoretického aparátu řízení projektů implementace podnikových informačních systémů doporučuji exaktní zařazení fáze stanovení metrik pro hodnocení účinnosti nového informačního systému. Tato činnost by měla být provedena ještě před samotnou implementací systému a jejím přínosem by mělo být přesné stanovení kritérií úspěchu zavedení informačního systému do podniku.

130

Použité zdroje 1. CRM failure rates. ZDNet [online]. [cit. 2014-05-04]. Dostupné z: http://www.zdnet.com/blog/projectfailures/crm-failure-rates2001-2009/4967. 2. 63 % of CRM Initiatives Fail. Direct Marketing News [online]. [cit. 2014-05-04]. Dostupné z: http://www.dmnews.com/63-of-crm-initiativesfail/article/303470/. 3. ŠAŠEK, Miloslav. Řízení vztahů se zákazníky: (jak uspět na trzích B2B). 1. vyd. Praha: Vysoká škola finanční a správní, 2010, 115 s. Eupress. ISBN 978-807-4080-258. 4. CHLEBOVSKÝ, Vít. CRM: řízení vztahů se zákazníky. 1. vyd. Brno: Computer Press, 2005, 190 s. ISBN 80-251-0798-1. 5. LOŠŤÁKOVÁ, Hana a kol. Diferencované řízení vztahů se zákazníky. 1. vyd. Praha: Grada, 2009, 272 s. ISBN 978-80-247-3155-1. 6. DOHNAL, Jan. Řízení vztahů se zákazníky: procesy, pracovníci, technologie. 1. vyd. Praha: Grada, 2002, 164 s. ISBN 80-247-0401-3. 7. WESSLING, Harry. Aktivní vztah k zákazníkům pomocí CRM: strategie, praktické příklady a scénáře. 1. vyd. Praha: Grada, 2003, 196 s. ISBN 80-247-0569-9. 8. STORBACKA, Kaj a Jarmo R. LEHTINEN. Řízení vztahů se zákazníky: Customer relationship management. 1. vyd. Praha: Grada, 2002, 168 s. ISBN 80-716-9813-X. 9. KOTLER, Philip a Kevin Lane KELLER. Marketing management. 1. vyd. Praha: Grada, 2007, 792 s. ISBN 978-80-247-1359-5. 10. GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha: Grada, 2009, 496 s. ISBN 978-80-247-2615-1. 11. ŠLAPÁK, Ondřej. Různá pojetí architektury informačních systémů. [online]. [cit. 2014-05-04]. Dostupné z: http://www.slapak.cz/ondrej/archIS.htm.

131

12. SODOMKA, Petr a Hana KLČOVÁ. Informační systémy v podnikové praxi. 2., aktualiz. a rozšíř. vyd. Brno: Computer Press, 2010, 501 s. ISBN 978-80-251-2878-7. 13. Analýza Gartneru: Trh CRM systémů v roce 2012 rostl o 12,5 %. CRMForum [online]. [cit. 2014-05-08]. Dostupné z: http://www.crmforum.cz/trendy/analyza-gartneru-trh-crmsystemu-v-roce-2012-rostl-o-12-5.html. 14. About us. SalesForce.com [online]. [cit. 2014-05-08]. Dostupné z: http://www.salesforce.com/company/. 15. SalesForce products overview. SalesForce.com [online]. [cit. 201405-08]. Dostupné z: http://www.salesforce.com/products/. 16. 2013 ERP Market Share Update: SAP Solidifies Market Leadership. Forbes [online]. [cit. 2014-05-08]. Dostupné z: http://www.forbes.com/sites/louiscolumbus/2013/05/12/2013-erpmarket-share-update-sap-solidifies-market-leadership/. 17. About SAP AG. SAP [online]. [cit. 2014-05-08]. Dostupné z: http://global.sap.com/corporate-en/our-company/index.epx. 18. One for All: 365 days of SAP Business Suite. SAP News Center [online]. [cit. 2014-05-08]. Dostupné z: http://www.news-sap.com/business-suite-erp/. 19. SAP CRM. CRMPortal [online]. [cit. 2014-05-08]. Dostupné z: http://www.crmportal.cz/images/stories/crm/documents/sap_cr m.pdf?phpMyAdmin=PobcgmAHAl53p1dPL-ucm1CopD5. 20. Oracle's History: Innovation, Leadership, Results. Oracle [online]. [cit. 2014-05-08]. Dostupné z: http://www.oracle.com/us/corporate/history/index.html. 21. Oracle CRM. Oracle [online]. [cit. 2014-05-08]. Dostupné z: http://www.oracle.com/us/solutions/crm/overview/index.html. 22. Microsoft Dynamics. Microsoft [online]. [cit. 2014-05-08]. Dostupné z: http://www.microsoft.com/cs-cz/dynamics/crm-solutions.aspx.

132

23. Company information. Microsoft [online]. [cit. 2014-05-08]. Dostupné z: http://www.microsoft.com/about/companyinformation/en/us/def ault.aspx. 24. IBM Archives. IBM [online]. [cit. 2014-05-08]. Dostupné z: http://www-03.ibm.com/ibm/history/index.html. 25. Small and Medium Business Solutions: Customer relationship management. IBM [online]. [cit. 2014-05-08]. Dostupné z: http://www.ibm.com/midmarket/us/en/crm.html. 26. Customer relationship management solutions. IBM [online]. [cit. 2014-05-08]. Dostupné z: http://www.ibm.com/solutions/alliance/us/en/index/crm.html. 27. IBM To Sell CRM, BPO Business To Synnex Subsidiary For $505M. CRN [online]. [cit. 2014-05-08]. Dostupné z: http://www.crn.com/news/channel-programs/240161104/ibm-tosell-crm-bpo-business-to-synnex-subsidiary-for-505m.htm. 28. Přehled CRM systémů na českém trhu. SystemOnLine [online]. [cit. 2014-05-09]. Dostupné z: http://www.systemonline.cz/prehled-informacnichsystemu/crm-systemy/. 29. Český ERP trh zrychlil růst, v segmentu SME přibylo 2000 projektů. CVIS [online]. [cit. 2014-05-10]. Dostupné z: http://www.cvis.cz/hlavni.php?stranka=novinky/clanek.php&id= 1312. 30. O nás. Asseco Solutions [online]. [cit. 2014-05-10]. Dostupné z: http://www.assecosolutions.eu/cz/spolecnost/. 31. Helios CRM. Helios [online]. [cit. 2014-05-10]. Dostupné z: http://www.helios.eu/cz/produkty/helios-crm.html. 32. Profil společnosti J.K.R. J.K.R. [online]. [cit. 2014-05-10]. Dostupné z: http://www.jkr.cz/o-spolecnosti/profil-spolecnosti.

133

33. Zákazníci v BYZNYS ERP. J.K.R. [online]. [cit. 2014-05-10]. Dostupné z: http://www.jkr.cz/byznys-erp/popis-systemu/oblastirizeni/zakaznici. 34. CRM systém. K2 atmitec [online]. [cit. 2014-05-10]. Dostupné z: http://www.k2.cz/cz/k2-software/crm-system.html. 35. CRM. QI [online]. [cit. 2014-05-10]. Dostupné z: http://www.qi.cz/moduly/obchod-a-marketing/crm/. 36. CRM. ABRA [online]. [cit. 2014-05-10]. Dostupné z: http://www.abra.eu/informacni-systemy/moduly/crm. 37. Cloudový fenomén SalesForce.com chystá expanzi v Česku. Connect! Živě [online.] [cit. 2014-05-10]. Dostupné z: http://connect.zive.cz/clanky/cloudovy-fenomen-salesforcecomchysta-expanzi-v-cesku/sc-320-a-171592. 38. A guide to the project management body of knowledge (PMBOK® guide). 5th ed. Newtown Square: Project management institute, 2013, 589 s. ISBN 978-1-935589-67-9. 39. SCHWALBE, Kathy. Řízení projektů v IT: kompletní průvodce. 1. vyd. Brno: Computer Press, 2011, 632 s. ISBN 978-80-251-2882-4. 40. The Standish Group Report: CHAOS 2014. Project Smart [online]. [cit. 2014-05-03]. Dostupné z: http://www.projectsmart.co.uk/docs/chaos-report.pdf. 41. Standardy projektového managementu a projekt PARTSIP. Inflow [online]. [cit. 2014-05-04]. Dostupné z: http://www.inflow.cz/standardy-projektoveho-managementuprojekt-partsip. 42. IPMA History. IPMA [online]. [cit. 2014-05-04]. Dostupné z: http://ipma.ch/about/ipma-history/. 43. IPMA Answers. IPMA [online]. [cit. 2014-05-04]. Dostupné z: http://ipma.ch/about/answers/.

134

44. IPMA Vision and Mission. IPMA [online]. [cit. 2014-05-04]. Dostupné z: http://ipma.ch/about/vision/. 45. Obecně o certifikaci. Společnost pro projektové řízení [online]. [cit. 2014-05-04]. Dostupné z: http://ipma.cz/web/certifikace/obecne-o-certifikaci.php. 46. About us. PMI [online]. [cit. 2014-05-04]. Dostupné z: http://www.pmi.org/About-Us.aspx. 47. Certifikace. PMI ČR [online]. [cit. 2014-05-04]. Dostupné z: http://www.pmi.cz/index.php/cs/professionaldevelopment/certification.html. 48. Metodika projektového řízení PRINCE2 (1. díl). SystemOnLine [online]. [cit. 2014-05-04]. Dostupné z: http://www.systemonline.cz/clanky/metodika-projektovehorizeni-prince2-1.-dil.htm. 49. BASL, Josef a Roman BLAŽÍČEK. Podnikové informační systémy: podnik v informační společnosti. 3., aktualiz. a dopl. vydání. Praha: Grada, 2012, 328 str. ISBN 978-80-247-4307-3. 50. CRM aneb jak si udržet zákazníky. CIO business world [online]. [cit. 2014-05-06]. Dostupné z: http://businessworld.cz/podnikoveis/crm-aneb-jak-si-udrzet-zakazniky-5675. 51. Vyberme ten správný obchodní systém. Blue strategy [online]. [cit. 2014-05-06]. Dostupné z: http://www.bluestrategy.cz/news/61-vyberme-ten-spravny-crmsystem.htm. 52. Jak dobře zavést a převzít nový informační systém. SystemOnLine [online]. [cit. 2014-05-08]. Dostupné z: http://www.systemonline.cz/erp/jak-dobre-zavest-a-prevzitnovy-informacni-system.htm. 53. Servisní služby k ERP systémům. ERPForum [online]. [cit. 201405-08]. Dostupné z: http://www.erpforum.cz/erp-trendy/servisnisluzby-k-erp-systemum.html.

135

54. Akceptace CRM systému zaměstnanci. SystemOnLine [online]. [cit. 2014-05-08]. Dostupné z: http://www.systemonline.cz/crm/akceptace-crm-systemuzamestnanci.htm. 55. HOMMEROVÁ, Dita. CRM v podnikových procesech. 1. vyd. Praha: Grada, 2012, 136 str. ISBN 978-80-247-4388-2. 56. Paretovo pravidlo (Pravidlo 80/20). Management mania [online]. [cit. 2014-05-08]. Dostupné z: https://managementmania.com/cs/paretovo-pravidlo. 57. Webové stránky společnosti XYZ. 58. Akční plán projektu – interní dokument společnosti XYZ. 59. Vnitřní předpis „Obchodní proces ve společnosti XYZ“ – interní dokument společnosti XYZ. 60. Systém OCTOPUS – prověřování tuzemských firem. DC Group [online]. [cit. 2014-05-17]. Dostupné z: http://www.dcgroup.cz/index.php/proverovani_firem.html. 61. Configure a Microsoft Dynamics CRM Internet-facing deployment. Microsoft Developer Network [online]. [cit. 2014-05-11]. Dostupné z: http://msdn.microsoft.com/enus/library/hh699814(v=crm.5).aspx. 62. Active Directory Federation Services. Microsoft Developer Network [online]. [cit. 2014-05-11]. Dostupné z: http://msdn.microsoft.com/en-us/library/bb897402.aspx. 63. Scribe Insight. Scribe [online]. [cit. 2014-05-11]. Dostupné z: http://www.scribesoft.com/Insight. 64. Solutions – Microsoft Dynamics CRM Connector. Scribe [online]. [cit. 2014-05-11]. Dostupné z: http://www.scribesoft.com/microsoft_dynamics_crm.

136

Seznam zkratek ADFS – Active Directory Federation Services BI – Business Intelligence CI – Customer Intelligence CIO – Chief Information Officer – vedoucí IT oddělení CRM – Customer Relationship Management – řízení vztahů se zákazníky CSS – Customer Service and Support – podpora servisních aktivit EAI – Enterprise Application Integration – Integrace podnikových aplikací EMA – Enterprise Marketing Automation – podpora marketingových aktivit ERP – Enterprise Resource Planning – ekonomický informační systém EVM – Earned Value Management – řízení získané hodnoty ICB – International Competence Baseline IFD – Internet Facing Deployment IPMA – International Project Management Association IS – informační systém NPV – Net Present Value – čistá současná hodnota PLM – Product Lifecycle Management – řízení životního cyklu výrobku PMBoK®Guide – A Guide to Project Management Body of Knowledge PMI – Project Management Institute PRINCE2 – PRojects IN Controlled Environments 2nd version RDP – Remote Desktop Protocol – připojení přes vzdálenou plochu ROI – Return of Investment – návratnost investice SCM – Supply Chain Management – řízení dodavatelského řetězce SFA – Sales Force Automation – podpora prodejních aktivit SLA – Service Level Agreement – úroveň poskytovaných služeb SOW – Statement of Work – definice cílů a rozsahů prací SRM – Supplier Relationship Management – řízení vztahů s dodavateli VPN – Virtual Private Network – virtuální soukromá síť WBS – Work Breakdown Structure – hierarchická struktura prací

137

Seznam obrázků obr. 1.1 Prvky CRM a jejich provázanost, zdroj: [7, str. 17] ....................... 6 obr. 1.2 Životní cyklus CRM, zdroj: autor, inspirováno [7, str. 18] .......... 8 obr. 1.3 Změna orientace z produktu na zákazníka, zdroj: [4, str. 46] ... 10 obr. 1.4 Strategie marketingu dle míry personalizace, zdroj: [5, str. 14] 12 obr. 1.5 Obchodní cyklus, zdroj: autor, inspirováno [6, str. 34] .............. 13 obr. 1.6 Komplexní procesy CRM, zdroj: [6, str. 35] ................................. 15 obr. 2.1 Postavení CRM v podnikovém IS, zdroj: [11] .............................. 18 obr. 2.2 Architektura CRM, zdroj: [6, str. 60] ............................................. 22 obr. 2.3 Kvalita CRM, zdroj: [7, str. 30] ....................................................... 28 obr. 2.4 CRM systémy ve světě, zdroj: autor, inspirováno [13] ............... 33 obr. 3.1 Trojimperativ, zdroj: [39, str. 25] .................................................... 40 obr. 3.2 Životní cyklus projektu, zdroj: autor, inspirováno [39, str. 71] . 41 obr. 3.3 Rámec projektového řízení, zdroj: [39, str. 26]............................. 44 obr. 4.1 Životní cyklus projektu zavádění IS, zdroj: autor, inspirováno [49, str. 203] ..................................................................................................... 50 obr. 4.2 Přístupy k přechodu na nový IS, zdroj: [49, str. 216] .................. 56 obr. 4.3 Model CRMBodyCheck, zdroj: autor, inspirováno [55, str. 21] 61 obr. 6.1 Harmonogram a WBS projektu, zdroj: [58] .................................. 83 obr. 6.2 Aktualizovaný harmonogram projektu dle smlouvy, zdroj: autor ................................................................................................................. 97 obr. 6.3 Aktualizovaný harmonogram projektu dle cílového konceptu, zdroj: autor ...................................................................................................... 99

138

Přílohy 1. Organizační struktura společnosti XYZ ................................................. i 2. Tabulka významných pozic .................................................................... ii 3. Architektura CRM systému ve společnosti XYZ ................................iii

139

1. Organizační struktura společnosti XYZ

zdroj: autor

i

2. Tabulka významných pozic Zkratka pozice

Název pozice

AGŘ

asistentka generálního ředitele

CIO

vedoucí IT oddělení

ED

ekonom divize

FŘ

finanční ředitel

GŘ

generální ředitel

MBSWP

manažer business softwarové podpory

MISŘ

manažer integrovaného systému řízení

MMK

manažer marketingové komunikace

MOS

manažer obchodní skupiny

OMO

oblastní manažer obchodu

OŘ

obchodní ředitel

ŘD

ředitel divize

TŘ

technický ředitel

VPO

vedoucí provozního oddělení

ZFŘ-OPER

zástupce finančního ředitele pro operativu

ZOŘ

zástupce obchodního ředitele

ZŘD

zástupce ředitele divize

ii

3. Architektura CRM systému ve společnosti XYZ

zdroj: autor

iii