Vztahy v CRM

Napřed si vysvětleme, co takový vztah N:N znamená, na jednoduchém příkladu. Předpokládejme, že v CRM evidujeme osoby v entitě Kontakt. V CRM také evidujeme profesní sdružení, říkejme jim Sdružení. Každý Kontakt může být členem více Sdružení a každé Sdružení může mít více členů, tedy eviduje více Kontaktů.

Nativní vztahy

Tento typ vztahu se v CRM definuje přímo ve vývojovém prostředí. Prosím, povšimněte si políčka Display Option, a to na nastavení obou entit, které definuje, jestli bude na formuláři Kontaktu i Sdružení tato vazba viditelná. (Poznámka: osvědčilo se nám vyvíjet v anglickém jazykovém prostředí CRM, proto téměř všechny příklady uvádíme v angličtině.)

Musím přiznat, že to není příliš obvyklé nastavení, ale pro ilustraci možností dostatečně vypovídající. Daleko obvyklejší nastavení je Use Plural Name:

Toto nastavení vede k tomu, že uživatelé takto vytvořený vztah uvidí přímo na formuláři. Tedy ve výše uvedeném příkladu bude na formuláři Kontaktu zobrazeno, do kterých Sdružení daný kontakt patří, a na kartě Sdružení zase bude vidět členy sdružení.

Další možností je Display Label – prostě se zadá libovolný text. Používá se zejména v případě, kdy máme více vztahů stejné entity, abychom odlišili jejich význam. Tedy jeden by se jmenoval Členové sdružení a druhý například Představenstvo sdružení – oba by přitom odkazovaly na stejnou entitu Kontakt.

Samozřejmě je možné podle vztahů vyhledávat relevantní informace. Například toto Rozšířené hledání nám umožní najít všechna aktivní Sdružení s přiřazenými Kontakty:

Nemuseli jsme do hledání Kontaktu přidávat podmínku typu „Kontakt obsahuje data“. Nastavená vazba typu N:N to za nás dělá automaticky.

A opačně, chceme-li vyhledat všechny Kontakty, které jsou členy nějakého Sdružení:

Hledáme v entitě Kontakt a vyhledáváme Sdružení bez dalších vyhledávacích podmínek.

Když se budeme symetricky definovanou vazbou typu N:N probírat podrobněji, zjistíme, že při Rozšířeném hledání narazíme na určitá omezení.

Například se to týká filtrování vybraných záznamů. Pokud hledáme všechny Kontakty, které jsou členy nějakého Sdružení, můžeme si do výsledku hledání přidat další atributy Kontaktu, jako třeba telefonní číslo, poštovní směrovací číslo, město a tak dále. Výsledky takového vyhledávání můžeme dále filtrovat, například použijeme filtr, který omezí zobrazené Kontakty jen na ty, jejichž město začíná na řetězec „Praha“. Do výsledku hledání sice mohu přidat i políčka z vazební entity Sdružení, ale nemohu nad těmito políčky filtrovat.

A opačně, pokud vyhledáváme nad entitou Sdružení, můžeme do výsledku hledání přidat obsah políček entity Sdružení a tato políčka použít pro filtrování, ale nemůžeme filtrovat nad políčky z entity Kontakt.

Výhody a nevýhody nativních vztahů typu N:N

Zásadní výhodou je, že tyto vztahy se velmi snadno vytvářejí a jsou na první pohled ihned srozumitelné. Nicméně za výhody je třeba i něco oželet. Najde se tedy i několik nevýhod, které je vhodné mít na zřeteli:

• Nemůžeme evidovat žádnou doplňující informaci ke vztahu (prostě je členem Sdružení ... tečka … pro zavedení další informace, jako např. Od kdy?, musíme zvolit jiný typ vztahu).
• Nemůžeme Rozšířeným hledáním vytvářet pohledy, které obsahují sloupce z obou stran vztahu (díváme-li se na Kontakty, pak můžeme filtrovat podle polí Kontaktu i podle polí Sdružení, ale zobrazíme si jen informace z Kontaktu).
• Nemůžeme použít vestavěného Průvodce importem, tedy nemůžeme naimportovat dlouhý seznam členů asociací a při importu vytvořit „členství“ ve Sdruženích.
• Nemůžeme využívat Pracovní Postupy = WorkFlow (WF). Například nemůžeme poslat automatickou notifikaci, když je do Sdružení přidán nový člen. Nebo bychom chtěli vytvořit nový záznam člena, když bude splněna nějaká podmínka :-(

Naštěstí CRM nabízí možnost ručního vytvoření vazeb typu N:N, které řeší všechny uvedené problémy. Je to pracnější a méně přehledné, ale myslíme si, že jsou v životě situace, kdy se vyplatí dát si se vztahy tu práci :-)

Ručně vytvořené vztahy N:N

Základem ručně vybudovaných vztahů N:N je vytvoření vazební Entity a nepřímé Vztahy. Vazební Entita je další zákaznicky vytvořená Entita, která je využívána jako skladiště vztahů. Pro náš původní příklad by se tato Entita jmenovala například Členství ve Sdružení nebo pouze Členství.

Místo tvorby přímých vztahů N:N mezi dvěma Entitami budeme vytvářet nepřímé vztahy typu 1:N k vložené vazební Entitě (dva – oba konce).

Schematicky vyjádřeno:

Oproti Nativním vztahům N:N

Výsledek je stejný, Kontakt může být členem několika Sdružení a Sdružení mají množinu členů.  Ale v prostředí CRM je podstatný rozdíl v tom, že nevýhody Nativního vztahu N:N jsou eliminovány:

• Ve vazební Entitě můžeme evidovat další informace (od kdy je členem, kolik platí příspěvků atp.).
• Můžeme vytvářet pohledy pomocí Rozšířeného hledání nad vazební entitou a používat libovolná políčka jak z vazební entity, tak i z entit Kontakt a Sdružení.
• Pokud máme Excel s Kontakty, Členstvím a Sdruženími, můžeme použít importní utilitu CRM. Jako bonus můžeme přímo využít Průvodce importem, který nám umožní založit zákaznickou vazební entitu Členství a zákaznickou entitu Sdružení, stejně jako přiřadit záznamy přímo při importu, tedy jedním importem vyřešíme vše potřebné!
• Workflow můžeme používat i nad vazební Entitou, takže máme k dispozici všechny možnosti automatizace procesů.

Propojení a Propojovací role

Oba předchozí vztahy vyžadovaly změnu nastavení datového modelu ve vývojovém prostředí CRM. To je práce pro IT odborníky. A co mají k dispozici zručnější uživatelé? Microsoft jim připravil i jednu vazbu N:N, která se jen definuje v sekci nastavení, a tak je její užití výrazně jednodušší.

Jedná se o specifickou obdobu flexibilního manuálního vztahu N:N s jedním textovým polem. Tedy přesně případ uprostřed obou výše popsaných variant. Tím jedním textovým polem je Název propojovací role. V samotné propojovací roli se pak jen zaškrtne, nad kterými entitami je daná propojovací role povolena. Na rozdíl od předchozích vztahů, kde se entity definovaly striktně, zde je možnost pracovat s více entitami. Tedy stavebním dozorem může být na stavbě osoba (v CRM Kontakt) nebo firma (v CRM Obchodní vztah) nebo zaměstnanec (v CRM Uživatel).

A praktické využití? Aniž by se zákazník musel detailně zabývat technickými aspekty vazeb, snadno si nakonfiguruje například následující:

• Zájmy – kdo hraje golf (Jaký má handicap? Na to už se musí použít manuální N:N – jasné, ne?)
• Kdo je lékařem koho – a naopak, kdo je pacientem koho
• Kdo je na stavbě stavebním dozorem, generálním dodavatelem atp.
• Kdo nabízí servis k přístroji a kdo na něj dodává spotřební materiál
• Kdo má rozhodovací pravomoc (decision maker) a kdo rozhodnutí ovlivňuje a podporuje nás
• …

Podrobnější rozbor propojení a dalších aspektů vazeb v CRM je už nad rámec tohoto článku, nicméně pokud máte specifickou potřebu se dozvědět více, kontaktujte autora článku.

Závěr

Jak zakončit vaše navazování vztahů s platformou CRM jinak, než optimisticky?

Máme hodně možností, jak v Dynamics CRM 2011 řešit vztahy – a to nejen typu N:N! Ale jak poznáme, kterou z nich využít? Zkusme si to závěrem jednoduše shrnout.

Nativní N:N

Nejjednodušší a nejrychlejší způsob, jak vazbu vyřešit, ale používejme jen tehdy, pokud potřebujeme evidovat pouze existenci vztahu dvou záznamů v různých entitách a žádné další informace o tomto vztahu.

Manuální N:N

Poněkud pracnější způsob, budeme muset trošku namáhat mozek, ale vyplatí se nám to tehdy, když kromě samotné informace o existenci vztahu potřebujeme znát i další informace, jako kdy vztah vznikl, jaký má stav a podobně.

Příklady:  Školení, registrace na školení a Kontakty, Sdružení a jejich Členové.

Propojení a Propojovací role

Specifické systémové Propojení, které můžete snadno upravovat a obsahuje právě jeden evidenční údaj – „Název propojovací role“. Podstatnou výhodou propojení je, že umožňuje vytvářet stejný vztah mezi více Entitami, Kontakt s Kontaktem, Kontakt s Firmou, Kontakt s Příležitostí atd.

Příklady: nejčastěji se používá na podchycení většího množství různorodých vztahů, které se zobrazují na jednom místě a mají spíše podpůrný význam. Evidence u kontaktu, že má psa, hraje golf a je vášnivý motorkář (u firmy prodávající obráběcí stroje), je rozdílná od přesnější evidence počátku platby městského poplatku za psa (městský úřad) a preference určitého veterináře (veterinární klinika).

Doufám, že i tento poměrně hodně technický článek vás neodradil od úvah nad tím, k čemu všemu by se dalo CRM použít u vás ve firmě. Příště bychom se rádi podívali na některý konkrétní dotaz někoho ze čtenářů Quasu. Neváhejte a pište na adresu quas@daquas.cz nebo autorovi.

Jiří Stříbrný | Dynamica, a.s., j.stribrny@dynamica.cz