Migrace informačního systému MS Dynamics CRM na vyšší verzi

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Migrace informačního systému MS Dynamics CRM na vyšší verzi DIPLOMOVÁ PRÁCE Bc. Martin Veselý Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato diplomová 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. Bc. Martin Veselý Vedoucí práce: RNDr. Pavel Hajn i

3 Poděkování Na tomto místě bych rád poděkoval všem, kteří mě podporovali při tvorbě této práce. Především děkuji vedoucímu práce RNDr. Pavlu Hajnovi za jeho cenné rady a připomínky, dále pak děkuji rodině a přátelům za jejich podporu a trpělivost. ii

4 Shrnutí Práce popisuje základy informačního systému MS Dynamics CRM a popisuje základy jeho konkrétní implementace. Dále se práce zabývá novými funkcemi představenými s verzí MS Dynamics CRM 2013 a jejich využitím při migraci stávajícího systému a přidružených aplikací na novou verzi. V rámci migrace systému na novou verzi se věnujeme také plánování celého procesu a identifikaci rizik. Na závěr práce je předvedena aktualizace několika aplikací tak, aby byly funkční v nové verzi MS Dynamics CRM. iii

5 Klíčová slova CRM, Customer Relationship Management, MS Dynamics CRM, migrace iv

6 Obsah 1 Úvod Co je CRM? Cíle práce MS Dynamics CRM Představení Základní pojmy Organizace Entita Řešení Pracovní postup Plugin Historie MS CRM MS Dynamics CRM MS Dynamics CRM MS Dynamics CRM MS Dynamics CRM Stávající řešení Popis Proces založení klienta Další uživatelské úpravy systému Práce s dokumenty Komunikace s externími systémy Import produktů Import stavu portfolií Komunikace s věrnostním systémem Technické řešení Entity Webové prostředky Pluginy Webové aplikace Konzolové aplikace Úpravy na úrovni databáze Rozhraní pro externí aplikace Nové vlastnosti MS Dynamics CRM v

7 4.1 Nové uživatelské rozhraní Obchodní pravidla Pracovní postup běžící v reálném čase Tok obchodního procesu Migrace na novou verzi CRM Migrace uživatelských úprav systému Formuláře Webové prostředky Úpravy na úrovni databáze Konzolové aplikace, webové aplikace a webové služby Migrace dat Migrace s využitím nové instance databázového a aplikačního serveru Migrace s využitím stávající instance databázového serveru Migrace v rámci původního prostředí Výběr vhodné metody migrace Migrace CRM ve společnosti ABC Plán migrace Identifikovaná rizika projektu Praktická část Detekce duplicit Sankční seznam Aktualizace aktiv a stavu klientů Závěr Literatura Přílohy A Elektronické přílohy vi

8 1 Úvod 1.1 Co je CRM? Se zkratkou CRM (Customer Relationship Management) jsme se poprvé mohli setkat zhruba v polovině 90. let 20. století [14]. Ve volném překladu se jedná o Řízení vztahů se zákazníky. Velmi zjednodušeně můžeme CRM definovat jako proces získávání, zpracování a využití informací o zákaznících společnosti. Tento proces umožňuje poznat, pochopit a následně pak i předvídat potřeby, přání a zvyklosti našich zákazníků. Jako CRM bývá přeneseně označován také informační systém, který je pověřen vykonáváním tohoto procesu. V kontextu CRM je tedy důležité rozlišit dva pohledy na CRM. Jeden pohled ukazuje CRM jako podnikatelskou filozofii, zatímco druhý pohled vidí CRM jako soubor technologií a softwaru, které slouží jako podpora pro implementaci a následnou realizaci této filozofie. [6] V této práci budeme označení CRM používat pro zmíněnou technologickou část. Pořízení CRM systému bylo dříve doménou velkých společností, které měly dostatek finančních prostředků pro nákladnou implementaci těchto systémů. S rozvojem konkurenčního prostředí a informačních technologií se však CRM systémy stávají stále dostupnější. V současné době si CRM systém stále častěji pořizují i střední a malé podniky. CRM v současné podobě již není informační systém postavený na zelené louce, ale modulární aplikace, kterou je možné jednoduše upravovat a rozšiřovat dle požadavků zákazníka. Podnik, který se rozhodne pro implementaci CRM systému, musí být dle Pepperse [11] schopen: 1. Identifikovat své zákazníky. 2. Jednoznačně rozlišit jednotlivé zákazníky. 3. Být schopen interakce s nimi. 4. Přizpůsobit své chování potřebám zákazníka. CRM rozdělujeme dle architektury (obrázek 1.1) na část operativní a analytickou. 1

9 1. ÚVOD Obrázek 1.1: Architektura CRM [13] Operativní část architektury CRM je zaměřena na automatizaci a řízení základních podnikových procesů, která se týkají marketingu, obchodu a servisních činností. Jejím primárním účelem je zajištění maximální možné efektivnosti již existujících procesů. [4] V analytické části se využívají data týkající se zákazníků a data získaná sledováním procesů v operativní části CRM. Používají se zde aplikace Business Intelligence (dále jen BI) 1 pro 1. BI aplikace poskytují různé pohledy na získaná data, která jsou nejčastěji uložená v datovém skladu (Data Warehouse). 2

10 1. ÚVOD práci se získanými daty za účelem lepšího porozumění zákazníkům. [4] 1.2 Cíle práce Cílem této práce je zmapovat rozsah funkcionality a uživatelských úprav v reálné instanci systému MS Dynamics CRM 2011, popsat změny a novinky představené s verzí MS Dynamics CRM 2013 a navrhnout postup migrace na novou verzi. V části věnující se migraci na novou verzi systému se věnujeme převodu uživatelských změn ze současného systému i výběru nejvhodnějšího z podporovaných postupů pro migraci stávajících dat. V závěru práce se zabýváme také analýzou rizik spojených s migrací systému a možnostmi jejich eliminace. Podkladem pro zpracování této práce byl reálný systém společnosti působící v oblasti financí. Vzhledem k této citlivé oblasti nebudeme zveřejňovat jméno společnosti, ale budeme ji dále nazývat ABC. Praktická část této práce se věnuje převodu tří reálných aplikací, které jsou v současné době ve společnosti ABC používány v řešení založeném na systému MS Dynamics CRM Konkrétně se jedná o doplnění funkce pro detekci vkládání duplicitních záznamů. Ve stávající verzi (MS Dynamics CRM 2011) se jedná o standardní součást systému, která byla v nové verzi odstraněna. Dále se jedná o aplikace pro import seznamu sankcionovaných osob, následnou kontrolu záznamů v CRM proti tomuto seznamu a aplikaci pro pravidelný přepočet stavu aktiv u klientů v CRM. 3

11 2 MS Dynamics CRM 2.1 Představení MS Dynamics CRM je implementace CRM systému vyvíjená společností Microsoft. Samotná aplikace se zaměřuje primárně na oblasti prodeje, marketingu a podpory zákazníků (helpdesk). Zhruba od roku 2009 se však samotný Microsoft snaží produkt MS Dynamics CRM propagovat jako XRM platformu (význam této zkratky je vysvětlen dále v této kapitole), kterou je možné s pomocí partnerů rozšiřovat tak, aby splňovala požadavky zákazníků z různých odvětví činnosti. Definic pro zkratku XRM existuje několik, ale nejpoužívanější jsou tyto dvě: [8] Podle první definice je písmeno X zkratkou pro extended. Celý význam zkratky je potom extended relationship management, volně přeloženo jako rozšířené řízení vztahů. Druhá definice definuje X jako proměnnou. Zkratka tedy znamená anything relationship management, což můžeme volně přeložit jako řízení libovolných vztahů. Oba tyto významy však odkazují na možnost vystavět nad platformou MS Dynamics CRM de-facto libovolnou aplikaci. Vytvoření takové XRM aplikace může probíhat formou úprav funkcionalit, které jsou standardní součástí systému, nebo navržením zcela nové aplikace, která nevyužívá integrované nástroje pro obchod, podporu nebo marketing. Tato nová aplikace má však stále možnost využívat všech možností platformy MS Dynamics CRM. Celá tato platforma je založena výhradně na vlastních technologiích a produktech společnosti Microsoft jako např. MS Windows Server, MS SQL Server, MS Exchange Server,.NET Framework 1 atd. MS Dynamics CRM je aplikace s architekturou klient-server. Ser- 1..NET je zastřešující název pro soubor technologií v softwarových produktech, které tvoří celou platformu. Základem této platformy je Microsoft.NET Framework. 4

12 2. MS DYNAMICS CRM verová část běží primárně na IIS 2. Souběžně s klientským rozhraním zde běží také webové služby, které slouží pro komunikaci s dalšími systémy. Klienti přistupují k CRM systému pomocí běžného webového prohlížeče nebo s využitím tzv. tlustého klienta - rozšiřujícího modulu pro Microsoft Outlook. Od uvedení MS Dynamics CRM 2011 Update Rollup 12 jsou mezi podporovanými prohlížeči kromě Internet Exploreru také Mozilla Firefox, Google Chrome a Apple Safari. 2.2 Základní pojmy V této sekci si představíme několik pojmů z terminologie MS Dynamics CRM. Tyto pojmy budeme dále využívat v dalších kapitolách a proto je důležité správně pochopit jejich význam v této doméně, aby nedocházelo k jejich nesprávné interpretaci Organizace Organizaci lze definovat jako instanci CRM, která je nezávislá na okolním prostředí a využívá služeb MS CRM serveru, v rámci kterého běží. Na jednom fyzickém CRM serveru lze provozovat několik organizací zároveň. Přesný počet organizací provozovaných v rámci jednoho MS CRM serveru je závislý na typu použité licence Entita Entitou v kontextu MS CRM rozumíme množinu dat, která se vztahují ke konkrétnímu objektu reálného světa. Příkladem entit je např. Kontakt, Klient nebo Obchodní příležitost. Každá entita sestává z atributů pro ukládání informací o konkrétním objektu. Dále se pro entitu definují pohledy na data - formuláře a tzv. zobrazení. Formulář slouží pro prohlížení a editaci jednoho konkrétního záznamu, zobrazení je použito při prohlížení více záznamů. 2. Internet Information Services nebo také Internet Information Server je softwarový webový server s kolekcí rozšiřujících modulů, vytvořený společností Microsoft pro operační systém Windows. 5

13 2. MS DYNAMICS CRM Řešení Koncept tzv. řešení byl do MS CRM přidán z důvodu snadnějšího přizpůsobení systému a možnosti následného šíření těchto úprav. Řešení obsahuje všechny úpravy systému, tj. nově vytvořené entity, přidané atributy, webové prostředky, role zabezpečení atd. Vytvořené řešení lze vyexportovat a následně importovat do dalších systémů. Tohoto lze využít pro vývoj řešení, kdy není nutný stálý přístup ke klientskému prostředí. Případně pro průběžný vývoj již existujícího systému, kdy se úpravy provádí nejdříve na testovacím prostředí a následně po otestování a odsouhlasení se jednoduše přenáší do produkčního prostředí Pracovní postup Jako pracovní postup je v terminologii MS Dynamics CRM označován jeden z typů procesů. Pracovní postup je obecně sekvence vzájemně navazujících funkcí či metod označovaných jako kroky. Pořadí provádění jednotlivých kroků můžeme pozměnit s využitím podmínek, resp. podmínkových větví. V prostředí MS Dynamics CRM je nutné přihlédnout k faktu, že standardní pracovní postupy jsou spouštěny asynchronně. Jako prostředí pro běh pracovních postupů slouží Windows služba 3 s názvem Microsoft Dynamics CRM Asynchronous Processing Service. [16] Plugin Plugin je označení pro.net assembly 4, která se využívá pro zachycení událostí generovaných MS Dynamics CRM. Na základě těchto událostí se plugin vyvolá a provede akci, kterou implementuje. Pluginy může vytvářet každý vývojář ovládající prostředí.net, potažmo MS Dynamics CRM. 3. Windows služby, dříve známé jako NT služby, jsou zvláštním druhem aplikací, které umožňují dlouhodobý běh aplikací ve svém vlastním kontextu bez závislosti na uživateli a interakce s ním. 4. Assembly je logickou kolekcí, stávající se z jednoho nebo více.exe,.dll nebo.module souboru a zdrojů doplněných o tzv. manifest - blok metadat s informacemi o této kolekci. 6

14 2.3 Historie 2. MS DYNAMICS CRM MS CRM 1.0 První verze CRM řešení od společnosti Microsoft, oficiálně pojmenovaná Microsoft Business Solutions Customer Relationship Management 1.0 (dále MS CRM 1.0), byla představena v lednu Verze MS CRM 1.0 byla z velké části založena na původním řešení icommunicate.net od společnosti icommunicate, kterou v roce 2001 Microsoft odkoupil. Uživatelské rozhraní (UI) MS CRM 1.0 (obrázek 2.3.1) bylo pouze drobnou logickou evolucí původního UI systému icommunicate.net. V této verzi nebyly podporovány žádné pokročilé uživatelské úpravy, např. přidávání vlastních entit. Obrázek 2.1: Uživatelské rozhraní Microsoft Business Solutions Customer Relationship Management 1.0 [10] MS Dynamics CRM 3.0 Systém Microsoft CRM 2.0 (někdy také označován jako Microsoft CRM 2005) nebyl, po několika odkladech, vůbec představen. Jako druhá v pořadí proto byla na konci roku 2005 představena verze Microsoft Dynamics CRM 3.0 (dále jen MS CRM 3.0). Od verze MS CRM 3.0 se v názvu produktů objevuje značka Dynamics, kterou 7

15 2. MS DYNAMICS CRM společnost Microsoft zavedla jako prvek sjednocující ERP 5 a CRM produkty [2]. S touto verzí bylo představeno prostředí, které imituje Microsoft Outlook a sjednocuje většinu prvků do levého navigačního menu (obrázek 2.3.2). Další výraznou změnou je podpora uživatelských úprav systému, zejména vytváření nových entit a definice relací mezi existujícími entitami. Obrázek 2.2: Uživatelské rozhraní MS Dynamics CRM 3.0 [12] MS Dynamics CRM 4.0 V prosinci 2007 představená verze Microsoft Dynamics CRM 4.0 (dále jen MS CRM 4.0) přinesla podstatná vylepšení, která ale nebyla viditelná na první pohled. Jedná se o první verzi MS CRM, která podporuje více než jednu organizaci na běžící současně na jedné fyzické instanci systému. V praxi tedy např. může jedna fyzická instance MS CRM 4.0 sloužit pobočkám společnosti po celém světě (obrázek 2.3). Důležitou novinkou je také podpora více jazyků a více měn. Od uve- 5. Enterprise Resource Planning 8

16 2. MS DYNAMICS CRM dení této verze si každý uživatel systému může zvolit vlastní jazykovou mutaci CRM. V předchozích verzích museli všichni uživatelé systém používat ve stejném jazyce. Obrázek 2.3: Více instancí v rámci MS Dynamics CRM 4.0 [1] MS Dynamics CRM 2011 Verze MS Dynamics CRM 2011 opět přinesla viditelnou změnu uživatelského rozhraní. U všech entit byl přidán tzv. ribbon 6, který byl společností Microsoft poprvé použit v Office Základní koncepce UI je však stejná jako u MS CRM 3.0. V této verzi byla také přidána podpora grafů a tzv. dashboardů 7. Díky těmto nástrojům je možné sledovat vizualizace dat bez nutnosti generování reportů nebo tvorby těchto grafů v Excelu. (Obrázek 1.4). 6. Ribbon, nazývaný též pás karet, je ovládací prvek uživatelského rozhraní vyvinutý a patentovaný společností Microsoft. 7. Dashboard jednoduché rozhraní, které obsahuje grafickou prezentaci aktuálního stavu a historických trendů vývoje klíčových ukazatelů výkonnosti společnosti. 9

17 2. MS DYNAMICS CRM Obrázek 2.4: Uživatelské rozhraní MS Dynamics CRM MS Dynamics CRM 2013 MS Dynamics CRM v aktuální verzi 2013 doznal podstatných změn uživatelského rozhraní. Vzhledem k rostoucímu rozšíření chytrých telefonů, tabletů a obecně zařízení, která lze ovládat dotykem, se společnost Microsoft rozhodla opustit koncept používaný od roku 2006 a vytvořit moderní rozhraní, které bude fungovat stejně na různých platformách. Výsledkem je nové uživatelské rozhraní, které je možné ovládat klasicky pomocí klávesnice a myši, zároveň je ale použitelné také na mobilních zařízeních. 10

18 3 Stávající řešení 3.1 Popis Informační systém MS Dynamics CRM 2011 se ve společnosti ABC využívá jako centrální systém, který shromažd uje informace z ostatních bankovních systémů a díky tomu poskytuje souhrnný přehled o klientech. Každý uživatel CRM má v závislosti na své uživatelské roli přístup k informacím o klientech. V CRM systému jsou evidovány komplexní informace - ke každému klientovi jsou přístupné jeho kontaktní informace, dále také jeho produkty, uzavřené smlouvy včetně napojení na systém pro správu dokumentů (Document Management System, dále jen DMS). Samozřejmou součástí CRM je evidence komunikace a aktivit s klientem jako jsou y, telefonní hovory, schůzky a požadavky. V této kapitole si zběžně představíme životní cyklus klienta od jeho založení v CRM až po jeho přechod do neaktivního stavu. Následně se budeme věnovat propojení CRM s externími systémy a také si přiblížíme technické řešení jednotlivých součástí CRM, které byly do systému přidány nad rámec standardních funkcí Proces založení klienta CRM systém má rovněž nezastupitelnou roli v procesu zadávání nových klientů. Údaje o novém klientovi jsou pracovníky manuálně zadány pouze jednou do CRM. Po tomto manuální zadání klienta následuje proces schvalování klienta. Tento proces sestává z kontroly proti seznamu sankcionovaných osob (sankčnímu seznamu) 1, ověření nového klienta oddělením AML (Anti-money laundering). Toto oddělení vyhodnocuje, zda nedochází k legalizaci finančních prostředků pocházejících z trestné činnosti, takzvanému praní špinavých peněz. Pokud nový klient úspěšně projde těmito kontrolami, je odeslán ke schválení. Podle parametrů klienta proběhne toto schvalování automaticky 1. Seznam sankcionovaných osob je jedním z nástrojů pro aplikaci opatření proti financování terorismu. Jedná se o seznam subjektů, kterým mj. nesmí být poskytovány finanční služby. 11

19 3. STÁVAJÍCÍ ŘEŠENÍ Obrázek 3.1: Znázornění procesu založení nového klienta v CRM. nebo se odešle upozornění na příslušné schvalovatele, kteří klienta schválí nebo si vyžádají další potřebné informace. Po úspěšném schválení je s klientem možné uzavřít smlouvu a přenést jeho data do příslušných bankovních informačních systémů. Během schvalování je klientovi také vygenerován jednoznačný identifikátor, který slouží pro identifikaci v externích systémech Další uživatelské úpravy systému Životní cyklus klienta začíná založením a schválením klienta v CRM systému, které je blíže popsáno v předchozí kapitole. Jakmile je klient schválen, je zapotřebí jej přenést do tzv. bankovního informačního systému (dále jen BIS), který zpracovává informace o klientech a jejich produktech. Pokud klient není evidován v BIS, tak mu není možné založit žádný produkt. Pro tyto účely byla vytvořena aplikace, která slouží jako průvodce pro uživatele CRM a zároveň zajišt uje integritu přenášených dat - nekompletně vyplněného klienta nepovolí exportovat. Po úspěšném přenosu do BIS se zpět do CRM předává identifikátor klienta v BIS. Klient v tomto stavu se nazývá aktivní. Uživatelé CRM mají u 12

20 3. STÁVAJÍCÍ ŘEŠENÍ těchto klientů v rámci systému přehled o jejich produktech, investicích a případně benefitních bodech (viz níže v této kapitole). Pokud dojde k nějaké výrazné změně v údajích u klienta, je tento záznam o klientovi odeslán na tzv. přeschvalování. V rámci přeschvalování jde převážně o kontrolu, zda nové údaje souhlasí a klient i nadále splňuje všechny požadavky. Proces nabízení nových služeb U každého (aktivního) klienta je v CRM podporován také proces nabízení nových služeb (dále jen SELL proces). Nabídku a následný prodej nových služeb lze rozdělit na tři kategorie: Up-sell, v překladu navyšovací prodej. Jedná se o aktivitu, která má za cíl zvýšit celkový objem služeb formou prodeje pokročilejších verzí produktů či služeb. Down-sell, což je přesný opak předcházejícího. Účelem downsellu je naopak snaha o snížení objemu poskytovaných služeb. V praxi se ale příliš nevyužívá. Cross-sell, volně přeloženo doplňkový prodej. Jako cross-selling se označují aktivity, které mají za účel navýšit celkovou objednávku doporučením souvisejícího zboží. CRM systém poskytuje jeho uživatelům nástroje pro realizaci a následnou evidenci celého procesu od vytvoření marketingové kampaně, přes plánování aktivit až po evidenci úspěšnosti tohoto procesu na konkrétním klientovi. Evidence požadavků Společnost ABC využívá CRM také pro evidenci požadavků a dotazů od klientů. Tyto požadavky mohou být do CRM vloženy různými způsoby, např. manuálně pracovníkem klientského centra, elektronicky prostřednictvím klientské aplikace atd. Po zadání nového požadavku a po jeho uložení je o této skutečnosti informován zodpovědný pracovník, který konkrétní požadavek řeší. Dle typu požadavku je klient notifikován em či SMS zprávou, případně je vytvořena aktivita některému z pracovníků klientského centra. 13

21 3. STÁVAJÍCÍ ŘEŠENÍ Schvalování výjimek Každý klient může zažádat o výjimku z pravidel u produktů, které využívá. Tyto výjimky musí projít schvalovacím procesem podle typu výjimky a dalších parametrů. Pro zjednodušení procesu a lepší přehled o schválených výjimkách byl tento proces také implementován v CRM systému. Po zadání výjimky a doplnění potřebných údajů je vytvořena žádost o schválení pro příslušné uživatele CRM, kteří se musí ke konkrétní výjimce vyjádřit (schválit nebo zamítnout). Jedná se o podobný proces jako je schvalování klientů zmíněné v sekci Investiční dotazník Pokud má klient zájem o investování do cenných papírů, musí vyplnit tzv. investiční dotazník. Po jeho vyhodnocení jsou klientovi doporučeny vhodné produkty, do kterých může investovat. Po vyplnění investičního dotazníku v klientské aplikaci jsou tato data přenesena do CRM, kde proběhne jejich vyhodnocení a uložení. Pokud je zadaný investiční dotazník v pořádku, klient em obdrží jeho vyhodnocení, kde vidí pro něj dostupné produkty. Investičních dotazníků může být v průběhu času v CRM evidováno více, ale platný je pouze jeden - ten, který byl vyplněn nejpozději Práce s dokumenty Z prostředí CRM mají uživatelé systému rovněž přístup k dokumentům, které mají návaznost na konkrétního klienta. Tyto dokumenty jsou uloženy v DMS na platformě MS Share Point. Z CRM je možné dokumenty také vytvářet, což se využívá převážně pro generování smluvní dokumentace a personalizované korespondence jako jsou např. průvodní dopisy. Díky propojení CRM s DMS uživatelé rovněž nemusí procházet dokumenty v papírové podobě, veškerá práce s dokumenty je možná v digitální podobě. Originály dokumentů jsou uloženy v archivu odkud jsou dodány na vyžádání ve zvláštních případech. Pro účely evidence dokumentů a jejich následnou digitalizaci byly 14

22 3. STÁVAJÍCÍ ŘEŠENÍ do CRM přidány funkce, které se starají o generování a tisk čárových kódů. V případě smluvní dokumentace generované z CRM, resp. DMS, je čárový kód nedílnou součástí každého dokumentu. V případě, že se jedná o dokumenty nepocházející z CRM systému, je možné vytisknout si štítek s čárovým kódem, kterým se konkrétní dokument označí. Následně při skenování dokumentu je čárový kód rozpoznán, v CRM se dohledá záznam, ke kterému tento dokument náleží, a nakonec se uloží na patřičné místo v DMS Komunikace s externími systémy Import produktů Import produktů z BIS do CRM se provádí pravidelně každou noc. Data o produktech, která vidí uživatelé v CRM tedy nejsou aktuální, ale reflektují stav z předchozího dne. Jedná se o omezení dané protistranou (BIS), která informace o produktech poskytuje. Data jsou poskytována ve formě XML souboru, který obsahuje informace o aktuálním stavu všech produktů. Toto XML je zpracováno importní aplikací. Jedná se o konzolovou aplikaci, která je periodicky spouštěna pomocí plánovače úloh systému Microsoft Windows. Z důvodu rychlosti aplikace zpracovává XML soubor paralelně ve více vláknech a pro komunikaci s CRM využívá webových služeb a z výkonnostních důvodů i přímé čtení databáze. Jelikož importní soubor obsahuje informace o všech produktech, je tudíž nutné pro každou položku v XML ověřit, zda konkrétní produkt již v CRM existuje a případně, jestli nedošlo k jeho změně. Na základě této kontroly se stávající záznam aktualizuje, resp. vytvoří se nový Import stavu portfolií Podobně jako import produktů z BIS se periodicky provádí také import portfolií resp. cenných papírů. I v tomto případě jsou v CRM vidět pouze data z předchozího dne, což je ale pro obecný přehled dostačující. Zdroje dat pro import jsou celkem dva - SQL databáze a webová 15

23 3. STÁVAJÍCÍ ŘEŠENÍ služba. Importní aplikace je spouštěna pravidelně plánovačem úloh systému Microsoft Windows. I v tomto importu se využívá paralelního zpracování dat. V případě importu cenných papírů obdrží CRM pouze aktuální stav. Z tohoto důvodu je nutné vždy před importem data smazat a importovat data nová, protože není možné jednoduše zjistit k jakým změnám v průběhu dne došlo Komunikace s věrnostním systémem MS Dynamics CRM slouží ve společnosti ABC také jako systém pro počítání benefitních bodů, které jsou klientům přidělovány na základě otevřených produktů nebo také manuálně, např. v případě mimořádného připsání bodů. Benefitní body jsou tedy uloženy v CRM, kde je pravidelně kontroluje další naplánovaná úloha, která v případě definovaných podmínek tyto konkrétní body odešle do věrnostního systému. Obdobně se také zpět do CRM stahují informace o ostatních pohybech na každém z benefitních účtů. Uživatelé CRM systému mají tedy u klienta de-facto na jednom místě kompletní přehled o jeho produktech, investicích a benefitních bodech. Benefitní systém je provozován mimo společnost ABC a komunikace probíhá pomocí webových služeb. 3.2 Technické řešení Stávající řešení založené na CRM 2011 obsahuje řadu uživatelských úprav a rozšíření nad rámec standardně dodávaného systému. Tyto úpravy můžeme rozdělit do následujících kategorií. Úpravy entit Pluginy Webové aplikace Konzolové aplikace Úpravy na úrovni databáze (triggery, uložené procedury) 16

24 3. STÁVAJÍCÍ ŘEŠENÍ Entity Úpravy entit, at již systémových nebo uživatelsky přidaných, jsou standardní součástí organizace, která se při migraci automaticky převede do nové verze systému. Každá entita obsahuje, mimo jiné, definici atributů a rozložení formulářů. Z hlediska nových vlastností verze MS Dynamics CRM 2013 je v podmnožině úprav systému podstatná hlavně definice vzhledu uživatelských formulářů a jejich rozložení Webové prostředky Webové prostředky obsahují obrázky a skripty, které souvisí s uživatelskými úpravami v řešení. Jedná se hlavně o JavaScript, který slouží pro implementaci dynamických pravidel na uživatelských formulářích. JavaScript se používá na uživatelském formuláři pro doplnění funkcí, které není možné realizovat s pomocí standardních systémových nástrojů Pluginy Pluginem rozumíme kód implementující určitou obchodní logiku (business logic), který je možno integrovat s MS Dynamics CRM a tímto modifikovat nebo rozšířit standardní chování této platformy. Jedná se vlastně o obslužnou rutinu (handler), která reaguje na akce vyvolané CRM. Pluginů se využívá pro různé akce, které se mají provádět až po vytvoření nebo modifikaci záznamu a z tohoto důvodu není možné použít JavaScript přímo na formuláři. S pomocí pluginů jsou dále často řešeny procesy, které nemohou být realizovány pomocí pracovních procesů. Je to hlavně z toho důvodu, že proces musí být proveden synchronně s uživatelskou akcí v systému nebo je nutná nějaká interakce s uživatelem. Interakcí s uživatelem rozumíme spíše informování o výsledku procesu/pluginu. V případě úspěšného běhu je to většinou doplnění pluginem vypočtených hodnot. Při chybě procesu je to zobrazení chybového hlášení a případně zabránění uložení těchto dat, které by mělo za následek porušení integrity dat v CRM. 17

25 3. STÁVAJÍCÍ ŘEŠENÍ Webové aplikace Další kategorií jsou webové aplikace, což jsou samostatné aplikace, které se vyvolají uživatelskou akcí přímo z prostředí CRM (nejčastěji kliknutím na tlačítko v navigační liště). Jako webové aplikace jsou řešeny činnosti, které lze vykonávat nad již existujícími záznamy a zároveň není možné využít pluginů. Nejčastěji se jedná o schvalování klientů, přenos záznamů do externích systémů a podobně. Obecně se jedná o akce, které není žádoucí spouštět při každé modifikaci záznamu nebo je v procesu nutná interakce uživatele. Tyto webové aplikace komunikují s CRM standardní cestou pomocí webových služeb, které MS Dynamics CRM poskytuje. Formu webových aplikací mají například tyto rozšířené funkce MS Dynamics CRM implementované ve společnosti ABC: Tisk čárových kódů a adresních štítků. Schvalování klientů. Přenos klienta do BIS. Změna IČ/RČ u klienta Konzolové aplikace Formou konzolových aplikací jsou realizovány především aplikace, které se spouští periodicky bez zásahu uživatelů. Komunikace s CRM probíhá opět prostřednictvím webových služeb CRM, ale v některých případech se přistupuje přímo do databáze. Přímý přístup (pro čtení) do databáze je používán z výkonnostních důvodů. Příkladem konzolových aplikací jsou například importy produktů a portfolií popsané v předchozí části této kapitoly. Jako konzolové aplikace jsou vytvořeny také různé notifikace, které se spouští v určitý čas. Tyto aplikace po spuštění vyberou z CRM množinu záznamů podle definovaných pravidel a následně pro každý záznam z této množiny vygenerují a odešlou nebo nad tímto záznamem spustí pracovní postup. 18

26 3. STÁVAJÍCÍ ŘEŠENÍ Úpravy na úrovni databáze Úpravy na úrovni databáze, tj. uložené procedury, triggery 2, omezení (constranints) a podobně, řeší problémy, které nelze vyřešit standardními funkcemi MS Dynamics CRM (pluginy nebo pracovní postupy). Takových situací je ale velmi málo a obecně by se se tyto nepodporované úpravy neměly pro práci s daty využívat, protože není zaručena jejich funkčnost. Mimo jiné mohou nastat například problémy s bezpečnostními aktualizacemi. V rámci implementace CRM systému ve společnosti ABC se takováto úprava na databázové úrovni přesto objevila při generování čárových kódů. Při generování čárových kódů musí být zajištěna jedinečnost každého z vygenerovaných kódů. Použití pluginů se v tomto případě ukázalo jako nespolehlivé, a proto se vytvořil trigger, který slouží pro generování číselné řady. Tento trigger využívá vlastnosti IDENTITY, což je standardní funkce MS SQL Serveru od verze Tímto je jednoduše vyřešen problém s rychlým generováním jednoznačných čárových kódů, které jsou dále využívány v CRM i DMS Rozhraní pro externí aplikace Pro komunikaci s vybranými externími systémy, které přistupují k datům v CRM, jsou k tomuto účelu vytvořeny webové služby. Jedná se většinou o relativně jednoduché aplikace, které pouze provádí transformaci dat a s vlastním CRM dále komunikují prostřednictvím webových služeb standardně poskytovaných CRM. Důvod implementace tohoto, na první pohled možná zbytečného, mezistupně je bezpečnostní hledisko. Pokud by externí systémy přistupovaly přímo ke službám poskytovaným CRM, tak by potenciálně měly přístup ke všem datům v CRM. 2. V kontextu databází trigger definuje činnosti, které se nad konkrétní tabulkou provedou v případě definované události. Definovanou událostí může být vložení, aktualizace nebo smazání záznamu. 19

27 4 Nové vlastnosti MS Dynamics CRM 2013 Jak již bylo řečeno v druhé kapitole, nejviditelnější změny se v MS Dynamics CRM 2013 udály v oblasti uživatelského rozhraní. Jednotlivé novinky si blíže představíme v této kapitole. 4.1 Nové uživatelské rozhraní Nejvýraznější a na první pohled viditelnou změnou je nové uživatelské rozhraní někdy označované jako Flow UI nebo Process Based Flow UI. Většina změn v uživatelském rozhraní byla provedena z důvodu zlepšení uživatelské zkušenosti (User Experience, dále jen UX) se systémem a pro snížení počtu kliknutí myší uživatele při interakci se systémem. Zapracováno bylo také na eliminaci nově otevíraných oken a celkově plošší UX. Toto ploché uživatelské rozhraní je také základem pro posun od webové aplikace, která je ale úzce zaměřená na platformu Windows resp. Internet Explorer, k multiplatformnímu systému. Díky tomu již uživatelé nejsou při práci se systémem úzce omezeni je na PC/Windows platformu, ale mohou systém využívat napříč širokým spektrem zařízení od chytrých telefonů a tabletů po přenosné a stolní počítače. Součástí změn vzhledu uživatelského rozhraní bylo odstranění levého navigačního menu, které bylo hlavním navigačním prvkem de-facto již od první verze systému. Toto menu je v aktuální verzi nahrazeno dlaždicovým navigačním panelem v horní části obrazovky. Tento panel se automaticky skrývá, aby nezabíral místo na obrazovce v době, kdy s ním uživatel nepracuje. Když uživatel vybere položku z navigačního menu, tak se vybraný záznam zobrazí ve stejném okně. Nedochází k otevírání nových oken čí záložek, jak bylo zvykem v předchozích verzích. V navigačním panelu se postupně zobrazuje tzv. drobečková navigace 1. Příklad tohoto navigačního panelu s drobečkovou navigací je na obrázku (4.1), kde jsme v sekci PRODEJ, máme vybránu entitu 1. Drobečková navigace je textovou reprezentací informace, kde na webové stránce se daná informace nachází a umožňuje uživateli postupný přechod do nadřazených kategorií[7]. 20

28 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 Kontakty a zobrazen záznam Veselý, Martin. Obrázek 4.1: Detail navigačního panelu v MS Dynamics CRM Na obrázku 4.1 můžeme rovněž vidět nový příkazový panel, který nahrazuje pás karet (ribbon) použitý v CRM V novém panelu se zobrazují pouze nejčastěji používané operace. Ostatní jsou dostupné pod tlačítkem Další příkazy s ikonou v podobě výpustky. Z příkazového panelu byly u existujících záznamů odstraněny také ikony pro uložení. Tato funkcionalita byla nahrazena automatickým ukládáním změn. Změněné údaje se u existujících záznamů ukládají každých 30 sekund. Novinkou je také, že formuláře využívají tzv. responzivního designu. Responzivní design spočívá v tom, že jednotlivé prvky formuláře mění svoji velikost a pozici v závislosti na změně velikosti okna prohlížeče. Díky této technice je optimalizace pro mobilní zařízení mnohem jednodušší než v případě fixního designu aplikace, který byl používán v předchozích verzích MS Dynamics CRM. 4.2 Obchodní pravidla Obchodní pravidla (Business Rules) jsou vlastností představenou společně s MS Dynamics CRM Pomocí obchodních pravidel je možné vytvářet vlastní logiku na uživatelských formulářích. Dosud bylo možné vytvářet vlastní logiku formulářů pouze pomocí JavaScriptu. Obchodní pravidla ale přinášejí jednoduché rozhraní pomocí kterého lze vytvářet a spravovat vlastní pravidla, které lze aplikovat na klasické formuláře i formuláře pro rychlé založení záznamu a to jak v klasické webové aplikaci, tak i v rozhraní pro tablety. Jediným typem formuláře, kde se obchodní pravidla neaplikují, je tzv. mobilní formulář. Jedná se o typ formuláře s omezenými možnostmi zobrazení, vytváření a úpravu záznamů. Tento typ formuláře se využívá ve webové verzi CRM systému určené pro mobilní telefony 21

29 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 (nazývané Mobile Express) a také v nativních aplikacích pro mobilní telefony s operačním systémem Windows Phone, ios a Android. Obchodní pravidla nabízejí pouze omezenou podmnožinu operací, které na formuláře aplikovat. V aktuální verzi můžeme definovat vlastní podmínky a využívat těchto operací: Nastavit hodnotu atributu Nastavit úroveň požadování atributu (bez omezení, doporučený, povinný) Zobrazit nebo schovat atribut Aktivovat či deaktivovat atribut Provést validaci vložených dat a zobrazit chybové zprávy V prostředí MS Dynamics CRM 2013 jsou obchodní pravidla vytvořena s účelem zjednodušení tvorby nejčastěji se vyskytujících (jednoduchých) pravidel. Nemají tedy za cíl nahradit skripty na formuláři, ale spíše jsou jejich doplňkem. Z tohoto důvodu mají poměrně značná omezení v porovnání s možnostmi, které vývojářům nabízí skripty na formulářích využívající JavaScript. Asi největším omezením je fakt, že všechny podmínky jsou vyhodnoceny s použitím logického operátoru AND. Není tedy možné, aby jedno obchodní pravidlo využívalo nějaké komplexnější podmínky. Pokud bychom chtěli v našich obchodních pravidlech využít operátor OR, znamenalo by to tuto podmínku rozdělit do několika pravidel. Další omezení obchodních pravidel jsou následující: Obchodní pravidla jsou spuštěna pouze při načtení formuláře nebo při změně hodnoty atributu. Nespouštějí se při uložení záznamu. Obchodní pravidla fungují pouze s atributy. Naproti tomu Java Script na formuláři může pracovat i s ostatními viditelnými prvky formulářů jako jsou karty a sekce. V případě, že je pomocí obchodního pravidla nastavena hodnota některého atributu, nebude spuštěna žádná obslužná rutina navázaná na událost OnChange. Toto chování je z dů- 22

30 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 vodu omezení možného vzniku nekonečné smyčky, která by mohla vzniknout rekurzivním voláním dané funkce. Pokud obchodní pravidlo obsahuje referenci na atribut, který není přítomen na formuláři, tak nebude toto pravidlo spuštěno bez jakéhokoli upozornění uživatele. Nejsou podporovány atributy datového typu Celé číslo s formátem Doba trvání, Časové pásmo a Jazyk. S těmito atributy tudíž není možné v obchodních pravidlech pracovat. 4.3 Pracovní postup běžící v reálném čase Jak bylo naznačeno v kapitole 2.2.4, v předchozích verzích MS Dynamics CRM byly pracovní procesy předurčeny k tomu, aby byly spuštěny na pozadí bez interakce s uživatelem a zpracovávaly data bez předem daného času, kdy bude pracovní proces spuštěn a dokončen. Vykonání jednotlivých spuštěných pracovních postupů je řízeno pomocí CRM Async Service. Tento koncept byl zaveden za účelem lepší správy systémových prostředků aplikačních serverů a tím pádem i zrychlení odezvy CRM systému. Konkrétnímu pracovnímu postupu jsou systémové prostředky potřebné pro jeho běh přiděleny tak, aby nedošlo k omezení uživatelů pracujících se systémem. Princip fungování lépe ilustruje následující příklad. Mějme několik uživatelů systému, kteří ve stejný čas provedou operaci, která má za následek vyvolání pracovního postupu. Pro každý z těchto pracovních postupů dojde k vytvoření instance pracovního postupu. Tato instance je, zjednodušeně řečeno, předána CRM Async Service, která má na starosti její vykonání. Z hlediska uživatele byla jím vyvolaná operace úspěšně dokončena. Ve skutečnosti je ale pracovní proces zařazen do fronty, kde čeká až budou vykonány všechny předchozí procesy a budou mu přiděleny potřebné systémové prostředky. Pracovní postupy v této podobě se tedy zjevně nehodí pro implementaci obchodní logiky, která vyžaduje nějakou formu interakce s uživatelem (např. zobrazení upozornění či chybových hlášení) nebo zrušení prováděné operace (např. kontrola vstupních údajů při uložení nebo smazání - nelze smazat záznam, který má vyplněno, že je 23

31 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 evidován v externím systému). Jedinou možností, jak tuto logiku v systému implementovat, bylo použití pluginů (kapitola 2.2.5). Nevýhodou tohoto řešení je přílišná komplikovanost pro uživatele, kteří by tuto logiku měli implementovat - business analytiky/architekty. Ve výsledku tedy bylo nutné, aby i ty nejmenší změny prováděl někdo z programátorů. S verzí MS Dynamics CRM 2013 došlo k rozšíření možností pracovních procesů o tzv. pracovní postupy běžící v reálném čase. Nově představené pracovní postupy běžící v reálném čase (Real-Time Workflows) umožňují implementovat obchodní logiku pomocí stejného uživatelského rozhraní (obrázek 4.2), které se používá pro definici standardních pracovních postupů. Vytvoření a následnou úpravu takovýchto pracovních postupů již zvládne i analytik, který se stará o tvorbu podnikových procesů. Obrázek 4.2: Prostředí editoru pracovních procesů. Možnost použití pluginů v systému zůstává nadále zachována a 24

32 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 Obrázek 4.3: Srovnání jednotlivých nástrojů pro automatizaci procesů dostupných v MS Dynamics CRM 2013.[9] pro složitější logiku je i nadále nejlepší volbou. Pro jednoduché, případně často se měnící, procesy je ale možné využít této nové funkce a převést sem část logiky z pluginů. To může přinést úspory času byznys analytiků i programátorů a hlavně to znamená zrychlení zavádění nové obchodní logiky a úpravy již existující. Na obrázku 4.3 je porovnání jednotlivých nástrojů, které jsou v aktuální verzi dostupné pro tvorbu obchodní logiky/obchodních procesů bez nutnosti psaní kódu. Z následujícího výčtu funkcí dostupných v předchozích verzích systému můžeme vidět, že v této oblasti došlo s uvedením nové verze k výraznému posunu: MS Dynamics CRM 4.0: pracovní postupy MS Dynamics CRM 2011: pracovní postupy, dialogy 2 MS Dynamics CRM 2013: pracovní postupy, pracovní postupy běžící v reálném čase, dialogy, toky obchodních procesů, obchodní pravidla, akce 3 2. Dialog je prostředek určený pro získání dat od uživatele, např. operátora call centra, v požadované podobě.[15] 3. Akce je de-facto pracovní postup běžící v reálném čase, který může být spuštěn pouze pomocí webových služeb MS Dynamics CRM. Hlavním rozdílem však je, že akce podporují vstupní a výstupní parametry.[2] 25

33 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 Obrázek 4.4: Tok obchodního procesu v prostředí aplikace MS Dynamics CRM Tok obchodního procesu Tok obchodního procesu (Business Process Flow) je dalším prvkem, který byl představen s uvedením CRM Toky obchodních procesů jsou postaveny na stejné podpůrné vrstvě jako ostatní typy procesů, ale jejich schopnosti a využití se zásadně liší. Toky obchodních procesů si můžeme představit jako jakési průvodce. Tito průvodci vedou uživatele CRM k cíli postupem, který je definován společností pomocí procesů. Dostupné toky obchodních procesů je možné kontrolovat a omezit na základě rolí zabezpečení, které mají konkrétní uživatelé přiřazeny. Každý uživatel tím pádem vidí pouze ty procesy, které se své práci potřebuje. Tuto novou vlastnost systému použijeme k definici sady kroků, které má uživatel provést pro dosažení požadovaného výstupu. Tyto kroky uživatelům zároveň poskytují vizuální indikátor, kde se v rámci konkrétního procesu nacházejí. Přínosem této nové vlastnosti systému je také snazší zaškolení nových uživatelů, protože ti se nemusí tolik soustředit s jakou entitou pracují. Pokud je tok obchodního procesu dobře definovaný, tak se uživatel může nechat procesem vést. To je benefitem i pro zkušené uživatele CRM, protože dojde ke zrychlení prováděných úkonů. V neposlední řadě toky obchodních procesů přispívají ke snížení chybovosti. V rámci každého toku definujeme posloupnost fází (stages) a kroků (steps), které se následně zobrazují v horní části formuláře (viz obrázek4.4). Každá fáze se skládá z jednotlivých kroků. Jeden krok pak reprezentuje pole, které slouží pro vstup dat od uživatele. Po vyplnění 26

34 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 Obrázek 4.5: Příklad obchodního pravidla, které skrývá nepotřebné atributy. všech povinných polí, resp. kroků, pokračuje uživatel na další fázi procesu pomocí tlačítka Další fáze. Jak již bylo zmíněno, ke každému z kroků lze nastavit příznak, že se jedná o povinnou položku. Povinné kroky jsou pro uživatele označeny červenou hvězdičkou vedle názvu a bez jejich doplnění nelze pokračovat v procesu k dalším fázím. Bohužel (v této verzi) není podporována žádná logika, která by umožnila v rámci toku vyhodnocovat zadané informace a nějakým způsobem na ně reagovat. V porovnání s ostatními typy procesů, které MS Dynamics CRM 2013 nabízí, tedy toky obchodních procesů působí jako nástroj relativně jednoduchý, skoro až primitivní. Při tvorbě toků však můžeme alespoň využit toho, že toky jsou plně integrovány s ostatními úpravami na formuláři. Všechny změny provedené v jednotlivých krocích se ihned aplikují na příslušné atributy na formuláři. V praxi to tedy znamená, že se na pozadí vykonávají všechny obchodní pravidla a skripty na straně klienta, které jsou ve formuláři navázány na změnu konkrétního atributu. Na obrázku 4.4 je příklad takového skriptu na formuláři, který hlídá správnost vyplněných dat - současně může být vybrána pouze jedna hodnota vztahu, proto dojde při výběru jedné z možných hodnot ke skrytí ostatních hodnot, které nemohou být současně vybrány. Všechny typy pracovních postupů (tj. běžící v reálném čase nebo na pozadí), které jsou iniciovány změnou některého z atributů zahr- 27

35 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 nutých do toku obchodního procesu, budou spuštěny v momentu, kdy dojde k manuálnímu či automatickému uložení změn formuláře. Výsledek pracovního postupu běžícího v reálném čase bude viditelný jakmile dojde k aktualizaci stavu formuláře po uložení. Při tvorbě toků ale nejsme omezeni pouze na jednu entitu. Můžeme rovněž vytvořit tok obchodního procesu, který zahrnuje více entit. Můžeme tedy vytvořit například životní cyklus příležitosti, který začíná vlastním vytvořením příležitosti a dále pokračuje cenovou nabídkou, objednávkou, fakturou a nakonec se vrací zpět k příležitosti, kterou už zbývá pouze uzavřít. Celkem můžeme do tohoto životního cyklu zapojit až pět různých entit. Zároveň můžeme také pro každou entitu definovat více než jeden tok. Jelikož ne všichni uživatelé CRM systému musí pracovat podle stejných procesů a pravidel, z tohoto důvodu můžeme definovat až deset různých procesů pro každou z podporovaných entit. Pokud máme pro entitu aktivováno více toků, můžeme také řídit kterým uživatelům se konkrétní tok zobrazí a který bude nastaven jako výchozí. Jak již bylo zmíněno na začátku této sekce, jednotlivé toky obchodních procesů můžeme propojovat s rolemi zabezpečení. Následně když některý z uživatelů vytváří nový záznam v entitě, která má definováno více toků, bude mít dostupné pouze ty toky, které jsou povoleny pro některou z rolí zabezpečení konkrétního uživatele. Výchozím tokem obchodního procesu je vždy první ze seznamu těch, které jsou uživateli dostupné. Po každém přepnutí na nový tok, bude tento nový tok vždy začínat znovu od první fáze. Drobným omezením při práci více uživatelů s jedním záznamem je fakt, že pro každý záznam může běžet v daném čase pouze jeden tok obchodního procesu. Pokud tedy některý z uživatelů systému aplikuje nový tok, ostatní uživatelé jej uvidí včetně průběhu také. Pokud některý z uživatelů nebude mít k aktivovanému toku oprávnění, tento tok se mu zobrazí, ale nebude aktivní. 28

36 4. NOVÉ VLASTNOSTI MS DYNAMICS CRM 2013 Klient/firma Fax Produkt Schůzka Požadavek Položka ceníku Kampaň Faktura Nabídka Aktivita kampaně Zájemce Opakovaná schůzka Odpověd na kampaň Dopis Prodejní dokumentace Konkurent Marketingový seznam Objednávka Kontakt Příležitost Uživatel Telefonní hovor Tým Úkol Tabulka 4.1: Přehled systémových entit s podporou toku obchodního procesu Při definici nových toků obchodních procesů je zároveň nutné brát zřetel na omezení týkající se podporovaných entit, počtů aktivovaných toků v jednotlivých entitách, fází a návazných entit. Vlastní toky obchodních procesů můžeme definovat pro systémové entity uvedené v tabulce 4.1 a dále také pro námi vytvořené vlastní entity. U každé vlastní entity je nutné tyto funkce nejprve povolit. Pokud ale u vlastních entit toky jednou povolíme, není již možné tuto akci vrátit zpět. Pro zachování akceptovatelné rychlosti systému a použitelnosti uživatelského rozhraní platí následující omezení pro návrh toků: Pro každou z entit může být zároveň aktivních maximálně 10 toků obchodních procesů. Každý tok může obsahovat maximálně 30 fází. Toky definované napříč více entitami mohou obsahovat maximálně 5 různých entit. 29

37 5 Migrace na novou verzi CRM Tato kapitola se věnuje samotné migraci systému MS Dynamics CRM z verze 2011 na aktuální verzi V první části si představíme doporučení, jak postupovat při převodu dodatečných úprav systému a návazných aplikací. Zaměříme se také na využití nově přidaných funkcí systému, které jsou popsány v předchozí kapitole. Druhá část se věnuje migraci dat. Jsou zde představeny oficiálně podporované scénáře pro migraci dat včetně jejich výhod a nevýhod. Na závěr je pak vybrána nejvýhodnější varianta migrace dat pro společnost ABC. 5.1 Migrace uživatelských úprav systému Formuláře Jak již bylo zmíněno v předchozí kapitole, nejviditelnější a zároveň velmi rozporuplnou změnou je nové uživatelské rozhraní. Většina uživatelů CRM, kteří mají zkušenosti s některou z předchozích verzí (MS Dynamics CRM 4.0 nebo 2011) není s novým rozhraním spokojena a jejich produktivita práce je mnohem nižší než v původním systému. Uživatelé musí novému systému přivyknout a naučit se pracovat novým způsobem, což je ale spíše záležitostí školení uživatelů a uživatelské podpory. Samotné řešení, konkrétně tedy vzhled formulářů, je po automatickém převodu do nové verze sice použitelné, ale také dosti neergonomické a složitě použitelné. Po migraci stávajícího řešení do MS Dynamics CRM 2013 je tedy vhodné věnovat pozornost našemu řešení s úpravami a modifikovat formuláře tak, aby využívaly nových funkcí a byly pro uživatele pohodlnější. S novým UI došlo k odstranění levého navigačního menu včetně rychlé navigace mezi záložkami formuláře. U komplexních formulářů (například pro entitu Klient), které obsahují kolem 200 atributů je nyní velmi zdlouhavé vyplnit požadované údaje. Obzvláště v případě, že požadované údaje jsou rozmístěny po celém formuláři. Pro tyto účely je vhodné využít toků obchodních procesů popisovaných v kapitole 4.4. Pomocí těchto toků je možné uživatelům CRM sys- 30

38 5. MIGRACE NA NOVOU VERZI CRM tému připravit průvodce, který je provede založením nového záznamu a zobrazí pohromadě všechny povinné atributy. V odstraněném levém navigačním menu byly rychle dostupné také návazné entity. Návaznými entitami rozumíme relaci s kardinalitou 1:N, tj. k jedné primární entitě může být navázáno více záznamů sekundární entity. Příkladem takového vztahu je relace Klient:Smlouva, jeden klient může mít uzavřeno více smluv. V novém uživatelském rozhraní je přechod na tyto návazné entity zdlouhavější. Je nutné kliknout pro rozbalení horního menu, zde najít požadovaný typ návazné entity a tu teprve vybrat. Pro zrychlení práce s návaznými entitami je vhodné vložit do formuláře nové prvky, které uživatelům usnadní práci. Prvním z těchto prvků je tzv. formulář pro rychlé zobrazení, který slouží pro zobrazení návazných entit. Na formuláři primární entity se následně zobrazí tabulka/mřížka, která obsahuje seznam návazných záznamů konkrétního typu, které přísluší ke konkrétní primární entitě. Tímto postupem můžeme uživatelům připravit přívětivější formulář, který jim usnadní a urychlí práci se systémem. Druhý prvek se nazývá rychlé zobrazení a je obdobou výše zmíněného formuláře, ale je určen pro relace s kardinalitou 1:1, resp N:1 1. Na formuláři primární entity se pak zobrazí malý formulář, který zobrazí definované atributy ze související entity. Pokud budeme jednotlivé formuláře takto přizpůsobovat, tak brzy narazíme na problém, že návazných záznamů je u hlavních entit (např. klient nebo kontakt) příliš mnoho a pokud je všechny přidáme na formulář, tak je výsledek značně nepřehledný. I tento problém však můžeme vyřešit. Vzhledem k tomu, že neexistuje de-facto žádný uživatel CRM systému, tak vytvoříme několik různých formulářů. Na základě přístupových oprávnění pak uživatelům zpřístupníme jako výchozí ten z formulářů, který nejlépe odpovídá povaze jejich práce. Na obrázcích 5.1 a 5.2 můžeme vidět porovnání stejného formuláře zobrazujícího detail kontaktu v prostředí MS Dynamics CRM 2011 resp. MS Dynamics CRM Na obrázku 5.1 je číslovkou 1 označen již zmiňovaný pás karet (ribbon), známý například z kan- 1. MS Dynamics CRM nepodporuje relace s kardinalitou 1:1. Jako relaci 1:1 tedy v tomto případě označujeme relaci N:1, kdy je naše entita v roli entity sekundární. 31

39 5. MIGRACE NA NOVOU VERZI CRM Obrázek 5.1: Zobrazení detailu kontaktu v MS Dynamics CRM celářského balíku MS Office. Číslem 2 je označeno výše zmiňované levé navigační menu, které bylo do verze MS Dynamics CRM 2011 nedílnou součástí formulářů. Ve formuláři MS Dynamics CRM 2013 (obrázek 5.2) je číslem 1 označeno nové navigační menu, které spojuje pás karet i levé navigační menu do jednoho menu. V tomto obrázku je také vidět prvek formulář pro rychlé zobrazení (číslo 2) a také několik rychlých zobrazení návazných entit (číslo 3), zde jsou to konkrétně vztahy tohoto kontaktu a jeho aktivity Webové prostředky Migrace webových prostředků znamená starat se hlavně o úpravu JavaScriptu, který používáme pro skriptování formulářů. Ostatní webové prostředky nemusíme měnit vůbec (obrázky, ikony) nebo pouze minimálně (CSS a HTML soubory). JavaScriptu se týká hlavně odstranění podpory pro přístup k objektovému modelu formuláře a jeho globálním funkcím a také odstranění koncového bodu webových služeb (dále jen endpoint) ve verzi Jak zmiňuje MSDN [3], tyto dále nepodporované funkce byly nahrazeny následujícím způsobem. 32

40 5. MIGRACE NA NOVOU VERZI CRM Obrázek 5.2: Zobrazení detailu kontaktu v MS Dynamics CRM Odstranění endpointu verze 2007 Stávající skripty využívající této odstraněné funkcionality by měly být aktualizovány pro použití nových endpointů pro rozhraní REST 2 nebo SOAP 3 Odstranění objektového modelu pro formulář a globální funkce Skripty, které využívají tohoto objektového modelu je nutné upravit a zastaralé metody nahradit novým objektovým modelem Xrm.Page Úpravy na úrovni databáze Protože úpravy provedené přímo v databázi nejsou podporovaným postupem, není nikde dostupný přehled změn, které se v nové verzi systému udály. Pokud jde ale pouze o základní operace jako je čtení a případně zápis do tabulek, tak je potřeba v úpravách CRM reflektovat pouze sloučení původních dvou databázových tabulek do jedné. 2. Representational State Transfer 3. Simple Object Access Protocol 33

41 5. MIGRACE NA NOVOU VERZI CRM V předchozích verzích MS Dynamics CRM existovaly v databázi pro každou entitu dvě tabulky lišící se sufixem - Base a ExtensionBase. Base tabulka obsahovala všechny systémové atributy. Systémovými atributy rozumíme takové, které jsou součástí CRM po instalaci nebo atributy, které se automaticky vygenerují při vytvoření vlastní entity. ExtensionBase tabulka pak obsahuje všechny uživatelsky přidané atributy. Toto rozdělení zůstávalo v MS Dynamics CRM jako pozůstatek z důvodu kompatibility s MS SQL Serverem 2000, který podporoval pouze omezený počet sloupců v každé tabulce. Poslední verzí MS Dynamics CRM, která podporovala MS SQL Server 2000 jako databázový server, byla verze 3.0 z roku 2005, takže tato zpětná kompatibilita již nebyla několik let nutná a podařilo se ji odstranit. Celkově se jedná o užitečnou změnu, která přináší: Méně spojování tabulek (SQL příkaz JOIN). Menší počet zámků tabulek. Nižší režii při zpracování databázových dotazů. Odstranění duplicitních klíčů, které byly v Base i ExtensionBase tabulkách. Migrace databázových úprav na MS Dynamics CRM 2013 znamená revizi používaných databázových dotazů, uložených procedur a pohledů, zdali se v nich nevyskytují reference na ExtensionBase tabulky. Pokud se tyto tabulky v našich skriptech vyskytují, je nutné je přepsat (ve většině případů rovněž dojde k jejich zjednodušení) do podoby, která využívá pouze tabulky dostupné v novém databázovém schématu Konzolové aplikace, webové aplikace a webové služby Pro aplikace komunikující s MS Dynamics CRM 2013, at už se jedná o konzolové aplikace nebo webové aplikace, které zahrnují i webové služby, jsou postupy pro migraci velmi podobné předchozím případům. 34

42 5. MIGRACE NA NOVOU VERZI CRM Pokud aplikace komunikují pomocí webových služeb, je potřeba prověřit, zda aplikace nepoužívá zastaralý endpoint ve verzi Pokud ano, je potřeba všechna volání upravit pro použití podporované verze Používáme-li v naší aplikaci nějakou formu přímého přístupu k CRM databázi, je potřeba provést revizi SQL skriptů, aby odpovídaly novému schématu databáze MS Dynamics CRM Nejen při migraci stávajících aplikací, ale i při vývoji aplikací nových se osvědčilo také využití následujících doporučení: Použít pro aplikaci.net Framework ve verzi 4.0 nebo vyšší. Systém MS Dynamics CRM 2013 běží na verzi 4.0 a tato verze také přináší například podporu pro paralelní zpracování dat. Díky tomu můžeme s vynaložením minimálního úsilí výrazně zrychlit běh stávajících aplikací. Toto platí hlavně pro aplikace, které hromadně zpracovávají data z CRM. Při tvorbě aplikací používat tzv. dynamického typování (late binding) objektů z CRM. 5.2 Migrace dat Převod stávajících dat vytvořených v předchozí verzi (MS Dynamics CRM 2011) je v nové verzi systému standardně podporován při upgradu systému. Pro migraci dat tedy není zapotřebí vytvářet žádné zvláštní scénáře. Při tomto postupu dojde také k převodu všech vlastních úprav systému, protože při úpravách systémových entit nebo vytváření entit vlastních dochází ke změně datového modelu. Po migraci dat tedy budeme mít v novém systému přeneseny i všechny entity, atributy, vazby a webové prostředky, které obsahovalo původní řešení. Na tyto součásti se zaměříme v dalších kapitolách této práce. Migraci našeho existujícího MS CRM 2011 můžeme provést třemi způsoby, které jsou blíže popsány níže. 35

43 5. MIGRACE NA NOVOU VERZI CRM Migrace s využitím nové instance databázového a aplikačního serveru V první variantě si ke stávajícímu prostředí MS CRM 2011 nainstalujeme nové prostředí pro MS CRM Celkem tedy potřebujeme dva aplikační CRM servery a dva databázové servery (Obrázek 3.1), resp. dvě instance MS SQL Serveru. Tyto dvě instance mohou být fyzicky umístěny na stejném serveru. Vzhledem k tomu, že jsou na sobě nezávislé, tak je pro názornost označujeme jako dva oddělené databázové servery. Obrázek 5.3: Migrace s využitím nové instance databázového a aplikačního serveru. Při vlastní migraci pak provedeme zálohu databáze s organizací MS CRM Následně obnovíme zálohovaná data na databázový server pro MS CRM 2013 a spustíme import této organizace na novém aplikačním serveru. Tato varianta zajišt uje nejkratší dobu odstávky stávajícího systému, který může zůstat v provozu po dobu instalace nového prostředí. V případě problémů s novým prostředím se můžeme rovněž prakticky okamžitě vrátit k funkčnímu systému. Nevýhodou je potřeba dvou nových serverů pro nový systém. 36

44 5. MIGRACE NA NOVOU VERZI CRM Migrace s využitím stávající instance databázového serveru Druhá varianta počítá s instalací nového aplikačního serveru pro CRM Databáze bude ale umístěna na stávajícím databázovém serveru, resp. na stávající instanci SQL Serveru. Při migraci dle tohoto scénáře dojde k aktualizaci konfigurační databáze a databáze výchozí organizace na novou verzi CRM Vzhledem k tomu, že CRM 2011 stále zůstává nainstalována, tak v případě problémů při migraci stačí obnovit předchozí verzi konfigurační a organizační databáze. Návrat k předchozí funkční verzi je možný provést v čase, který nám zabere obnova potřebných databází ze záloh. Nevýhodou proti první variantě je, že po dobu instalace nového aplikačního serveru uživatelé nemohou pracovat ani s původním systémem. Obrázek 5.4: Migrace s využitím stávající instance databázového serveru Migrace v rámci původního prostředí Poslední varianta počítá s provedením migrace přímo na původním systému ( in-place ). Jedná se postup, který nevyžaduje žádné dodatečné hardwarové prostředky, ale zároveň přináší nejdelší dobu výpadku při instalaci i případném obnovení původního systému. Na stávajícím aplikačním serveru se spustí instalace CRM 2013, která provede upgrade aplikačního serveru na novou verzi. Současně se provede migrace konfigurační databáze a databáze primární organizace obdobně jako ve výše popisované druhé variantě. 37

45 5. MIGRACE NA NOVOU VERZI CRM V případě problémů s novým systémem, kdy se potřebujeme vrátit k původnímu systému, je potřeba provést novou instalaci a nastavení CRM 2011 a následně ze záloh obnovit všechny používané organizace. Obrázek 5.5: Migrace v rámci původního prostředí Výběr vhodné metody migrace Výběr vhodné metody pro migraci stávajícího systému založeného na CRM 2011 na novou verzi závisí na našich požadavcích na maximální dobu výpadku systému během migrace (samotný upgrade plus případné obnovení původního systému) a také na hardwaru, který jsme schopni a ochotni na tuto operaci alokovat. Srovnání jednotlivých metod dle různých požadavků je uvedeno v tabulce