Autor: Jakub (Kuba) Skałbania

Dynamics 365 Business Edition, czyli z Maderą się nie udało; czas na Teneryfę…

Jakub (Kuba) Skałbania aktualizacja, Dynamics 365, nowy, Tenerife, xRM

W światku Dynamics’owym zawrzało… Od wczoraj Twitter i blogi, a także część polskiego internetu poświęconego Microsoft Dynamics się gotuje. Polacy piszą: Dynamics 365 „Business Edition już nie ma”, „Dynamics 365 Business Edition zaprzestana”, a Amerykanie „Business Edition is no more” (cytat wyrwany z kontekstu z wypowiedzi przedstawiciela Microsoft). W takich sytuacjach warto zatrzymać się na chwilę i zamiast cytować plotki – doczytać i dopiero dzielić się informacjami.

Co stało się wczoraj na Directions 2017?

Marko Perisic, podczas otwierającej sesji na konferencji Directions w Orlando powiedział, że Microsoft Dynamics 365 Business Edition to od teraz Project Tenerife. Dla przypomnienia roboczą nazwą dla Business Edition była Project Madeira.

Panika rozlała się po wszystkich. Panika wynikająca z niezrozumienia co się stało. Rozwój Microsoft Dynamics 365 Business Edition nie został zawieszony! To, co się wydarzyło, to „niespodziewana” zmiana planów i roadmapy „mniejszego” Dynamics’a 365. Zmiana, która w kręgu dobrych partnerów NAV’owych i grup zainteresowanych konsultantów Dynamics 365, była spodziewana. Nawet dla rynku ogólnego powinna być spodziewana, bo jak można się nie spodziewać zmiany planów, jeśli Microsoft w sierpniu (na miesiąc przed premierą) mówił, że moduł marketingowy i funkcjonalność przeniesiona z NAV nie jest jeszcze gotowa. A dodatkowo w zasadzie nie było planu co dalej z Microsoft NAV. Ktokolwiek wierzył, że w jeden miesiąc ogromne funkcjonalności nagle się pojawią? Chyba nie.

Co w takim razie dzieje się z Microsoft Dynamics 365 Business Edition i czym jest Project ‚Tenerife’?

Dynamics 365 Business Edition rzeczywiście znika, ale tylko z licencjonowania Microsoft. Znika, bo tak, jak pisałem wcześniej, a mówiłem wszystkim Klientom na spotkaniach, totalnie bez sensu była wersja Business Edition, która miała być tańsza i być przeznaczona dla x liczby użytkowników. I zawsze pojawiało się to samo pytanie:

„Załóżmy, że Klient kupi Business Edition i urośnie o kilku użytkowników. Co ma się stać? Ma się zmigrować z Business Edition opartego o Dynamics NAV i przenieść do Enterprise Edition opartego o Dynamics AX?”

No przecież – proste, że nie! Mimo oszalałej wizji pań i panów z marketingu w Redmond, już w listopadzie 2016 roku na spotkaniach dla insider’ów były poruszane tematy potencjalnej konieczności migracji i zawsze kończyło się tak samo. Przy tej okazji pozdrawiam Klientów, którym jeszcze w zeszłym tygodniu mówiliśmy, żeby uważali na Business Edition 😉 – mam nadzieję, że znów pomogliśmy w strategii.

W Project Tenerife i w nowym licencjonowaniu licencje kupuje się dla użytkowników „na moduł” (per app), a nie w zależności od liczby użytkowników. I to ucina spekulacje, że Business Edition się skończył. Licencjonowanie tak, produkt nie. Ba, produkt żyje i będzie większy niż Microsoft mówił.

Project Tenerife to w zasadzie połączenie Microsoft Dynamics 365 Business Edition i Microsoft Dynamics NAV, ale ze znaczącym naciskiem na platformę stojącą pod spodem i opartą o Common Data Service. Sam NAV ma być rzeczywiście zaprzestany, a wiodącym systemem ma być jego następca, Tenerife, który będzie oferował pełną funkcjonalność Dynamics NAV i w chmurze i on-premise.

Razem z nową platformą Microsoft ogłosił też, że możliwe będzie budowanie własnych aplikacji dla konkretnych branż i sprzedawanie ich jako „white label”, tj. np. „Mały ERPik z super CRMem powered by Microsoft Dynamics”. Mamy więc odpowiednik Force.com w Microsofcie (ciekawe dlaczego? Ktoś zgadnie? 🙂 Może dlatego, że szef AppExchange’a Salesforce’owego rządzi teraz w Microsofcie?)

Najważniejsze fakty o Dynamics 365 Project Tenerife

Najważniejsze fakty o następcy Business Edition można podsumować tak:

  • pełny Dynamics NAV połączony z Dynamics 365 Business Edition
  • brak ograniczeń wynikających z liczby licencji
  • licencjonowanie oparte o moduły i aplikacje
  • platforma do budowy własnych aplikacji oparta o Common Data Service
  • pełna integracja z Outlook, Office365 i Power BI
  • szereg gotowych modułów, np. Accountant Hub dla księgowych
  • możliwość instalacji w chmurze i on-premise

 

Reklamy

Rozwiązania (Solutions) i Poprawki (Patches) – wszystko, co musisz wiedzieć o wersjonowaniu w Dynamics 365

Jakub (Kuba) Skałbania aktualizacja, dostosowanie, Dynamics 365, xRM

Przy okazji rozdzielenia platformy od aplikacji (opisanej w poprzednim poście) wypada się pochylić bardziej nad tym, jak przygotowywać nowe Rozwiązania (Solutions) w trakcie wdrożenia Dynamics 365 (i po nim). Skoro od teraz każdy moduł funkcjonalny będzie w osobnym Rozwiązaniu, to i my, partnerzy wdrażający, powinniśmy trochę bardziej serio zacząć traktować solucje i poprawki. Wiadomo, że w realnym życiu nikt poza ISV nie używa Rozwiązań Zarządzanych ;), ale wypada zacząć używać Rozwiązań i Poprawek w celu lepszego panowania nad cyklem życia naszych dostosowań w CRM’ie (Dynamics 365 for Customer Engagement, taaaa).

* standardowo, będę używał słów „rozwiązania” i „solucje” zamiennie, mimo że „solucja” to wg Słownika Języka Polskiego i CD Action coś zupełnie innego 🙂

 

Wersjonowanie Rozwiązań vs wersjonowanie Poprawek

Jak wiadomo, każde rozwiązanie przygotowywane przez nas podczas wdrażania Dynamics 365 ma numer wersji. Pierwszy numer podczas tworzenia Rozwiązania nadajemy my sami, więc wydaje się, że możemy wybrać dowolną nazwę. A jednak nie! Odkąd Microsoft wprowadził do CRM 2016 i Dynamics 365 „Aktywa” (Assets), czyli poszczególne, bardzo małe komponenty konkretnych encji, to numerowanie Rozwiązań jest wymuszane przez platformę do określonego formatu X.Y.Z.W, gdzie:

  • X – numer głównej wersji Rozwiązania (major)
  • Y – numer aktualizacji Rozwiązania (minor)
  • Z – numer Poprawki (build)
  • W – numer rewizji Poprawki (revision)

Dlatego też próba wpisania takiego numerku wersji:

dynamics365-solution-number

…spowoduje z automatu poprawienie przez system numeru wersji na taki:

dynamics365-solution-number02

 

Każda Poprawka (Patch) do naszego Rozwiązania będzie miała później automatycznie nadawany numer będący inkrementacją trzeciego numerka (Z w numerze X.Y.Z.W).

 

Poprawki (Patches) w Dynamics 365 – co to takiego?

Poprawki (albo „patche”), jak sama nazwa wskazuje, służą do wgrywania poprawek do istniejących rozwiązań. Poprawki to nic innego jak zestaw konkretnych Aktywów dodanych do istniejącego Rozwiązania. Na przykład:

chcemy szybko zmienić konkretny widok, albo dodać nowy wykres, albo zmienić pola na formatce w docelowym środowisku – wtedy nie tworzymy nowego rozwiązania zawierającego tylko widok, wykres i formularz, ale tworzymy patch do istniejącego rozwiązania, który zawiera tylko te elementy, które chcemy zmienić.

Patche mogą być aplikowane zarówno do Rozwiązań Zarządzanych, jak i Niezarządzanych (ufff!), a więc szybko powinny się stać obowiązkowym i ulubionym elementem każdego dobrego wdrożenia Dynamics 365. Patch zawsze powstaje poprzez utworzenie go (sklonowanie) z istniejącego rozwiązania – nie można stworzyć patch’a ot tak bez istniejącego Rozwiązania. Każdy patch jest stworzony dla konkretnego Rozwiązania i nie może być używany poza kontekstem tego Rozwiązania. Oczywiście, co za tym idzie, nie można wgrać Poprawki na środowisko, w którym nie ma oryginalnego Rozwiązania, którego ta Poprawka dotyczy!

Dodatkowo, podczas próby importu Poprawki, CRM (tfu, Dynamics 365) zawsze sprawdzi, czy numer głównej wersji Rozwiązania (X) i numer aktualizacji Rozwiązania (Y) w Poprawce są takie same, jak numery Rozwiązania istniejącego już na środowisku docelowym. Nie da się więc patch’em zaktualizować numeru wersji, czy aktualizacji. Patch to patch. Zawsze trzeci numerek w numerze wersji.

 

Poprawka, a aktualizacje Rozwiązania (minor version)

Jak łatwo się domyślić, w prawdziwych wdrożeniach będziemy mieli wiele patch’y do istniejących rozwiązań. Dlatego Microsoft przemyślał sprawę i pozwala na tworzenie Aktualizacji Rozwiązania (numerek Y w X.Y.Z.W), które automatycznie uwzględniają wszystkie dotychczasowe Poprawki! Nie ma więc potrzeby pamiętania o wszystkich Poprawkach dodawanych do rozwiązania, bo każda nowa wersja Rozwiązania będzie zawierać wszystkie zmiany, które dodaliśmy wcześniej patch’ami.

 

Jak to zadziała w realnym życiu, przy wielu zainstalowanych rozwiązaniach?

Załóżmy trochę trudniejszy scenariusz niż kolejne patch’e na jednym rozwiązaniu (co oczywiście jest proste i skutkuje konkretnymi, spodziewanymi zmianami wprowadzanymi w patch’ach). Mianowicie, wprowadzamy Poprawkę do dostosowania (np. encji), które jest też komponentem innego Rozwiązania. Mamy więc taką sytuację na środowisku docelowym:

  • PodstawoweRozwiazanie, 2017.0.0.0., zawiera encję „Encja” i pole „Pole Testowe” o długości 50 znaków
  • InneRozwiazanie, 1983.0.0.0., zainstalowane później, też zawiera encję „Encja„, ale długość pola „Pole Testowe” jest zmieniona na 100 znaków

solutions-managed

Przygotowujemy poprawkę PodstawoweRozwiazanie, 2017.0.1.0. (pierwszy patch) z długością pola „Pole Testowe” zmienioną na 70 znaków. Co stanie się, kiedy zainstalujemy naszą Poprawkę? 

Otóż odpowiedź różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych i Niezarządzanych:

W przypadku Rozwiązań Zarządzanych… nic się nie stanie dopóki w systemie mamy zainstalowane InneRozwiazanie. Długość pola „Pole Testowe” nadal będzie mieć 100 znaków! A to dlatego, że nasza Poprawka chce zmienić i może zmienić tylko nasze PodstawoweRozwiazanie, ale nie może zmienić drugiego rozwiązania (bo nie została dla niego stworzona)! Dlatego, w powyższym scenariuszu nasz patch zostanie „uwzględniony” dopiero, kiedy odinstalujemy InneRozwiazanie (1983.0.0.0.). Wtedy z automatu PodstawoweRozwiazanie będzie mieć numerek 2017.0.1.0. (pierwszy patch), a więc będzie zawierać wszystkie zmiany wprowadzone przez nasz patch.

W przypadku Rozwiązań Niezarządzanych oczywiście nasz patch nadpisze „Pole Testowe” tak, jak się tego spodziewamy. UWAGA! Wbrew temu, co pisze Microsoft na MSDN’ie tutaj w akapicie „Another patching example”: https://msdn.microsoft.com/en-us/library/mt593040.aspx

 

Tworzenie poprawek i aktualizacji krok po kroku

Poniżej opisuję kilka kroków, które przeprowadzą Was dokładnie przez proces utworzenia pierwszego patch’a (Z) i pierwszej aktualizacji (Y) w Dynamics 365:

  1. Tworzymy Rozwiązanie i dodajemy do niego wszystkie aktywa, które ma zawierać:

solution01

2. Tworzymy pierwszą Poprawkę do Rozwiązania poprzez „Klonuj do poprawki”. Dynamics 365 automatycznie zmieni numer wersji, inkrementując trzecią cyfrę:

solution02

3. Dodajemy zmiany w Poprawce. Po dodaniu wszystkich aktywów, w systemie mamy jedno Rozwiązanie (2017.0.0.0) i jedną Poprawkę (2017.0.1.0):

solution03

4. Kiedy mamy już dużo poprawek, możemy zdecydować się na utworzenie aktualizacji Rozwiązania. Taka aktualizacja automatycznie będzie zawierać wszystkie wcześniej utworzone Poprawki, a same Poprawki znikną z systemu!

solution04

solution05

 

Aktualizacja zmieni też numer build’u, inkrementując drugą cyfrę (Y, minor) w numerze wersji Rozwiązania.

5. Podczas importu aktualizacji Rozwiązania system wykryje, że ma do czynienia z aktualizacją i pokaże nam dodatkową opcję zastosowania aktualizacji do istniejącego Rozwiązania.

 

Usuwanie poprawek

Podobnie jak w powyżej opisanym przypadku pracy z kilkoma Rozwiązaniami, usuwanie patch’y różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych, czy nie.

I tak, w przypadku Rozwiązania Zarządzanego wystarczy ze środowiska docelowego odinstalować to Rozwiązanie, a wszystkie poprawki (patch’e) zostaną usunięte automatycznie.

Natomiast, w przypadku Rozwiązania Niezarządzanego usuwanie Poprawek odbywa się „pojedynczo”, a samo Rozwiązanie nie da się usunąć, jeśli najpierw nie usuniemy jego Poprawek. System poinformuje nas o tym, jeśli zapomnimy o tej kolejności miłym błędem:

solution-unmanaged-deletion

 

Podsumowanie

Mechanizm Poprawek i Aktualizacji stanowczo wspiera pracę podczas wdrażania Microsoft Dynamics 365 for Customer Engagement poprzez dobry i przemyślany, a przede wszystkim działający, mechanizm wersjonowania. Dzięki mechanizmom klonowania Poprawek i aktualizacji system sam dba o zależności między naszymi poprawkami a istniejącymi Rozwiązaniami, a dzięki temu, że wszystkie Poprawki automatycznie stają się częścią nowych aktualizacji, nie musimy się już martwić, że zapomnimy podczas importu nowej wersji Rozwiązań o jakimś komponencie.

To jedna z tych funkcji, które powinniście zacząć używać jak najszybciej!

 

Rozdzielenie platformy od aplikacji w Dynamics 365 (9.x.x.x) – o co chodzi Microsoftowi?

Jakub (Kuba) Skałbania co nowego?, Dynamics 365, nowy, xRM

Prawdziwy Dynamics 365 nadchodzi!

Pamiętam kilka naprawdę gorących rozmów z Klientami (i przy okazji Microsoft’em) o tym, dlaczego nie warto migrować się do Microsoft Dynamics 365, który pojawił się na rynku w 2016 roku. Ci klienci, którzy nam uwierzyli w lutym i marcu tego roku i posłuchali, że „tamten” Dynamics 365 z grudnia to jedynie update, a nie nowa wersja (8.2.x.x, a nie 9.x.x.x) dobrze na tym wyszli. Ci, którzy uwierzyli mimo naszych warsztatów Microsoftowi przeżyli koszmar z migracją do nowych licencji i do platformy, która była przejściowa. Teraz muszą zmierzyć się z migracją do tego prawdziwego Dynamics 365 :). Dlatego warto wierzyć ekspertom, a nie sprzedawcom, ale to tak przy okazji.

Tak, czy inaczej, prawdziwy Dynamics 365 (a więc wersja z nowym numerem) nadchodzi wielkimi krokami. Należy więc zacząć przygotowywać się do niej z odpowiednią uwagą.

Rozdzielenie platformy i aplikacji, czyli co?

Jedną ze zmian, o których rzadko mówią sprzedawcy Microsoftu (z mojego doświadczenia nawet o niej nie wiedzą, bo to nie jest coś, co się „łatwo sprzedaje”) jest tzw. application-platform separation, czyli rozdzielenie platformy Microsoft Dynamics CRM (tak, CRM, nie żaden Dynamics 365) od logiki i modułów funkcjonalnych. Z wysokiego poziomu można to rozdzielenie opisać w taki sposób:

Do tej pory mieliśmy moduł Sprzedaży, Marketingu i Obsługi Klienta wbudowany w platformę. Te moduły, niejako, były częścią Microsoft Dynamics CRM. Były tam zawsze; no dobra, Obsługi Klienta nie było w 1.2 😉 ). Generalnie chodzi o to, że kupując Microsoft Dynamics CRM kupowaliśmy te trzy moduły i platformę do budowania aplikacji xRM:

dynamics-crm-5-8-platform

Od wersji 9.0 wszystkie te moduły, które znamy od lat i które dla wielu osób są tożsame z „CRM’em”, zostaną „wyrzucone” z „platformy”, która staje się z powrotem platformą, czyli czymś, na czym można budować dowolne inne aplikacji.

Witajcie w historii MBS CRM i w 2003 roku!!! 🙂 Już wtedy Philip Richardson (teraz w Salesforce) był adwokatem osobnej platformy xRM i budowania na niej „appek” w oparciu o SDK. Nomen omen, teraz ta platforma ma roboczą nazwę… xRM Server.

xRM Server jest więc platformą do budowania aplikacji i obejmuje (nazwy Rozwiązań celowo po angielsku, bo takie będą nazwy Solucji w v9!):

dynamics-365-v9-platform.png

 

Oczywiście istniejące moduły zostają „w CRM’ie”, ale technicznie będą realizowane już przez osobne Rozwiązania i nie będą „częścią systemu”. To, w wersji 9.0, dotyczy również modułu Sprzedaży, Marketingu i Obsługi Klienta – od nowej wersji nie są one już częścią platformy, a stają się Rozwiązaniami (Solutions)!!!

 

Czemu tak?

Od niedawna widać, że Microsoft zaczął dodawać kupowane przez siebie produkty (portale ADX, FieldOne) jako solucje (rozwiązania) do Dynamics CRM. Oczywiście to wynika z faktu, że partnerzy robiący wcześniej te rozwiązania oferowali je swoim Klientom jako solucje, więc naturalnym krokiem było pozostawienie ich w tej formie, zamiast podejmowania próby „wbudowywania” ich w platformę. Dodatkowo takie podejście ma mnóstwo innych zalet…

 

Zalety rozdzielenia platformy od logiki aplikacji

Trzymanie konkretnych funkcjonalności / modułów jako osobne rozwiązania, w separacji od platformy ma szereg zalet w kontekście Microsoft Dynamics 365, m.in.:

  • Możliwość aktualizacji konkretnego modułu (np. Sprzedaży) bez konieczności podnoszenia wersji całej platformy
  • Brak zależności od konkretnego partnera / zespołu wewnątrz Microsoft podczas aktualizacji ważnych dla nas funkcjonalności
  • Rozdzielenie kodu platformy od kodu realizującego konkretne funkcjonalności, przez co developerzy mają znacznie mniej zależności przy rozwoju konkretnego modułu
  • Możliwość szybszego nadążania za rynkiem w kontekście konkretnego modułu bez oglądania się na całą platformę
  • Ogromna zmiana w podejściu do implementacji rozwiązań przez partnerów, bo nie będziemy zależni od „wszystkich” komponentów encji systemowych, ale w zamian będziemy zależni tylko od poszczególnych modułów

 

Na czym technicznie polega to rozdzielenie?

Platforma Microsoft Dynamics 365 składa się z wielu komponentów/warstw (od bazy danych, przez serwery web’owe aż po aplikacje natywne i kod po stronie klienta). Dlatego rozdzielenie, o którym mowa w tym poście, musiało dotyczyć wszystkich tych warstw.

W warstwie serwerowej oznacza to, że:

  • cały kod charakterystyczny dla poszczególnych modułów został przeniesiony do plug-in’ów
  • metadane encji (a także jej elementów, takich jak widoki i formularze) zostały przeniesione do konkretnych rozwiązań

W warstwie klienckiej rozdzielenie platformy od aplikacji polegało na:

  • przepisaniu wszystkich stron ASPX na własne kontrolki w oparciu o CCF (Custom Control Framework)
  • kod JScript został skonwertowany na TypeScript

Jak możecie się domyślać, rozdzielenie oznacza, że przybędzie nam Rozwiązań (Solutions). I tak, w wersji 9.0, mamy następujące Rozwiązania:

  • LeadManagement
  • ProductManagement
  • ClientUtilities
  • Sales
  • Scheduling
  • ServiceManagement
  • Marketing

 

Ktoś może zapytać „No dobra, a co stanie się, jak nie zainstaluję tych rozwiązań?” A, to odpowiedź jest prosta – sama platforma (xRM Server) bez doinstalowanych rozwiązań z funkcjonalnością np. Sprzedaży sprowadzi się po stronie UI jedynie do modułu Ustawień J. A to dlatego, że cała funkcjonalność będzie teraz realizowana przez dedykowane solucje.

 

Cele w CRM, a własność encji w Dynamics 365

Jakub (Kuba) Skałbania dostosowanie, Dynamics 365, problem

Ten post jest trochę nietypowy, bo jest wskazówką i pewną odpowiedzią na notoryczny problem z tym, na jakich encjach można tworzyć cele w Microsoft Dynamics 365.

Trochę o celach w Microsoft Dynamics 365

Zarządzanie celami to jedna z funkcjonalności Dynamics 365 obecna w Dynamics CRM od wersji 2011. Niektórzy ją kochają ze względu na elastyczność i łatwość tworzenia celów dla użytkowników CRM, a także za łatwość prezentacji danych o postępie i celach. Inni nienawidzą za to, że każdy cel musi mieć właściciela i jest tylko na dany okres fiskalny, a w kolejnych trzeba tworzyć cele od nowa i za każdym razem osobno dla każdego użytkownika / zespołu.

Jeśli ktoś chce używać celów, to ma do dyspozycji całkiem dobry mechanizm (o ile akceptuje trudność w ergonomii dla tworzenia celów od nowa co okres fiskalny) składający się z następujących komponentów:

  • Metryka Celu (Goal Metric):
    Obiekt pozwalający na wybór typu celu oraz danych, które chcemy śledzić (np. czy to będzie cel liczbowy, czy kwotowy i jaki typ danych będzie liczony do postępu i realizacji celów)
  • Cel (Goal):
    Cel to jak sama nazwa wskazuje właściwy cel, który obowiązkowo składa się z Nazwy, Metryki Celu, Właściciela Celu (i jego managera) oraz przede wszystkim z Okresu Obrachunkowego, dla którego ma być liczony. Cel zawiera dane o oczekiwanej (docelowej) liczbie lub kwocie, a także może zawierać Cele Podrzędne, jeśli chcemy liczyć cele dla zespołów.
  • Zapytanie Zestawienia (Rollup Query):
    Zapytanie Zestawienia umożliwia szczegółowy wybór rekordów, które mają być zaliczane do Celu. Przykładem może być sytuacja, w której Celem jest uzyskanie 100 000 PLN przychodu w wystawionych fakturach (Metryka Celu), ale dodatkowo chcemy, żeby były to faktury na konkretny rodzaj usługi (Zapytanie Zestawienia).

Mojej encji nie mam na liście Celów, czyli haczyk z własnością encji…

Wiadomo, że cele w Dynamics 365 mogą obejmować nie tylko dane sprzedażowe, ale dowolne inne dane z różnych encji, które dają się sumować lub liczyć (pod warunkiem, że Metryka Celu jest jednym z dwóch typów – Liczba, albo Kwota). Łącznie z tym, że możemy tworzyć Cele (Goals), Metryki Celów (Goal Metrics) i Zapytania Zestawienia (Rollup Queries) dla encji stworzonych przez nas (encji dostosowanych / Custom Entities).

Jednak jest jeden bardzo ważny punkt – teoretycznie wszystkie (w tym custom) encje mogą być przedmiotem dla Celu. Czy naprawdę? Wystarczy chwilę się zastanowić (i nie zapomnieć podczas wdrożenia), że Cele mają Właścicieli i obejmują rekordy, które mają właścicieli. Dlatego też Cele mogą być w praktyce tworzone tylko dla encji, które mają Własność ustawioną na „Użytkownik lub zespół”, a nie na „Organizacja”!!!

Screen Shot 2017-05-08 at 17.10.36

Implikacje w prawdziwym życiu

Czemu to jest takie ważne? Ano dlatego, że ta przypadłość celów wymaga odpowiedniego planowania nowych obiektów w kontekście ich właśności w systemie. Nie da się przecież zmienić typu Własności już po utworzeniu encji. A co dopiero, kiedy encja jest w pełni dostosowana, a my zaimportujemy już dane z zewnętrznego systemu… Wtedy możemy się nieźle zdziwić, kiedy obiecamy Klientowi np. zarządzanie celami na wystawione faktury, albo na liczbę zamówień i stworzymy encję, której Własność ustawiona będzie na „Organizacja”. A przecież w przypadku takich obiektów jak Faktura takie ustawienie właśnie ma największy sens. Chcemy przecież zapewnić w systemie w prosty sposób – albo ktoś widzi faktury z ERP, albo nie. Nie zastanawiamy się i na pewno nie chcemy dodatkowo ustawiać właścicieli dla każdej zaimportowanej faktury i konfigurować ról zabezpieczeń w taki sposób, żeby użytkownicy mogli widzieć tylko konkretne faktury.

Podobnie ma się sytuacja z wieloma innymi encjami utworzonymi na wdrożeniach – chcemy albo widzieć stan magazynowy (kiedy tworzymy sobie encję na te potrzeby), albo nie. Chcemy albo pozwolić użytkownikom widzieć wejścia na stronę (kiedy tworzymy encję na te potrzeby), albo nie. Nie ma przecież sensu, żeby takie obiekty miały właścicieli – po prostu użytkownicy albo je widzą, albo nie.

Podsumowując – cele w Microsoft Dynamics 365 można ustawiać na wielu encjach, w tym encjach własnych. Jednak nie da się używać mechanizmu Celów na encjach, które właściwość Własność mają ustawioną jako „Organizacja”. Dodajcie sobie powyższy punkt do listy podczas planowania nowych encji :).

Dynamics 365 – mapowanie licencji i użytkowników Dynamics CRM do nowych planów [2/2]

Jakub (Kuba) Skałbania Dynamics 365, licencjonowanie, PowerApps

Zgodnie z obietnicą ten post jest drugim z kolei traktującym o mapowaniu funkcjonalności i licencji z ostatniej wersji Microsoft Dynamics CRM 2016 do Microsoft Dynamics 365. Poprzedni post jest tutaj – Dynamics 365 – mapowanie funkcjonalności Dynamics CRM do nowych planów [1/2]. Tym razem zajmę się szczegółami licencjonowania Dynamics 365. Opiszę dokładnie plany, rodzaje licencji i funkcjonalności (bez szczegółów funkcjonalności aplikacji / modułu Operations z Planu 2 z prostej przyczyny – nie jest gotowy w tej chwili).

 

Aplikacje i plany – o co chodzi?

Microsoft wprowadził w Dynamics 365 dwa rodzaje licencjonowania użytkowników:

  • Licencja na aplikację (konkretny moduł Dynamics 365)
  • Licencja na plan dający dostęp do wielu modułów

Licencja na aplikację (konkretny moduł)

To nic innego jak długo oczekiwane licencjonowanie pozwalające na wykupienie dostępu tylko do konkretnego modułu Dynamics 365, np. Dynamics 365 for Sales. Użytkownik posiadający licencję na dany moduł może korzystać z każdej funkcjonalności w danym module Dynamics 365, ale również z funkcjonalności pozwalających na dostosowanie systemu w ramach danego modułu. Dodatkowo licencja na jedną z aplikacji Dynamics 365 daje dostęp do:

  • PowerApps, w tym Flow (w ramach danej aplikacji)
  • Microsoft Social Engagement (w Sales, Customer Service, Field Service i Project Service)
  • Unified Service Desk (w Sales i Customer Service)
  • Voice of Customer (w Sales, Customer Service, Field Service i Project Service)
  • Aplikacja mobilna z dostępem offline (w Sales, Customer Service, Field Service i Project Service)
  • Funkcjonalnośc grywalizacji – Microsoft Gamification (w Sales, Customer Service, Field Service i Project Service)

Bardzo ważne jest, że użytkownik posiadający licencje na daną aplikację może dostosowywać raporty, formatki, pulpity nawigacyjne, przepływy pracy i robić importy danych tylko na encjach z danej aplikacji!

Dynamics 365 - aplikacje

Licencja na plan 

Plan daje dostęp do wszystkich aplikacji objętych danym planem, wszystkich funkcjonalności Dynamics 365 i pełne możliwości dostosowywania systemu. Dodatkowo użytkownik posiadający licencje na dany plan w cenie dostaje:

  • PowerApps, w tym Flow
  • Microsoft Social Engagement
  • Unified Service Desk
  • Voice of Customer 
  • Aplikacja mobilna z dostępem offline
  • Funkcjonalnośc grywalizacji – Microsoft Gamification
  • Portal kliencki dla użytkowników zewnętrznych

Dla przypomniania, Microsoft Dynamics 365 oferuje następujące plany:

  • Dynamics 365 Business Edition
  • Dynamics 365 Enterprise Edition (Plan 1) – nic innego niż nowy Dynamics CRM
  • Dynamics 365 Enterprise Edition (Plan 2) – nowy Dynamics CRM i AX 7

Dynamics 365 - plany

 

Rodzaje licencji, czyli gdzie jest „Basic”?

Wiele organizacji korzystających z Dynamics CRM do tej pory zdążyło się już przyzwyczaić, że licencje CRM dzielimy na: Professional, Basic, Essential i Employee Self-Service. Zdążyli się przyzwyczaić i partnerzy Microsoft, którzy jeszcze 2 tygodnie temu w jednym z naszych potencjalnych projektów wprowadzali w błąd Klienta, wyceniając w ofercie licencje Basic…

Chcąc korzystać z Microsoft Dynamics 365 trzeba się odzwyczaić od aktualnego podziału licencji. Naturalne są więc pytania w rodzaju „Co z moimi licencjami Basic?”, „Jak kupić CRM taniej, skoro nie potrzebuje całej funkcjonalności?” i „Jak zmapować istniejące licencje do tych nowych?” Postaram się na nie odpowiedzieć poniżej.

W Dynamics 365 mamy do czynienia z dwoma typami licencji:

  • Licencje pełne (albo na aplikację, albo na plan)
  • Licencje „lekkie„

Licencje pełne to oczywiście w pewnym sensie odpowiedniki starych „Professionali”, jednak dające znacznie więcej funkcjonalności w cenie.

Licencje lekkie to… no właśnie… to tzw. „Team Members”. I tu zaczyna się cała zabawa, bo między licencjami pełnymi i Team Members nie starczyło już miejsca na licencje Basic i Essential znane z Dynamics CRM. Jednak przy odpowiednim zaplanowaniu licencji nie będziecie tęsknić za „Basic’ami”. A to dlatego, że licencja Team Member daje pełny dostęp do odczytu wszystkich danych z Dynamics 365, pełny dostęp do niektórych encji i daje wiele funkcjonalności charakterystycznych dla danego modułu. Najkrócej podsumować to tak – Team Member to:

  • prawo odczytu danych z całego Dynamics 365
  • pełny dostęp do obiektów Kont (Klientów), Kontaktów, Działań i Notatek
  • pełny dostęp do encji dostosowanych (custom entities)
  • pełny dostęp do Relacji i Połączeń między obiektami
  • możliwość uruchamiania przepływów pracy (workflows)
  • wyszukiwanie zaawansowane w całym Dynamics 365
  • możliwość raportowania, tworzenia widoków
  • możliwość eksportu danych do Excel’a
  • możliwość tworzenia i edycji Szans Sprzedaży poprzez portal

Jak widać powyżej – licencja „lekka” Team Member z łatwością zastępuje istniejący do tej pory Basic. Jednak, żeby nie było tak różowo – Basic w Dynamics CRM pozwalał również na pełne korzystanie z modułu Obsługi Klienta (pod warunkiem, że użytkownicy „nie dotykali”sprzedaży), a Team Member na to nie pozwala!!!

 

Mapowanie licencji Dynamics CRM 2016 do Dynamics 365

Dla ułatwienia i przejrzystości stworzyłem tabelkę dla wszystkich potencjalnych i istniejących Klientów i użytkowników zastanawiających się jak migracja do Dynamics 365 wpłynie na ich licencje:

Dynamics CRM 2016 Dynamics 365
Professional Licencja pełna na aplikację (np. Sales, Customer Service)
albo
Licencja pełna na plan (Enterprise Plan 1)
Basic • Jeśli użytkownik „dotyka” obiektu Potencjalny Klient, to Licencja pełna na aplikację Dynamics 365 for Sales

• Jeśli użytkownik „dotyka” obiektu Spraw, to Licencja pełna na aplikację Dynamics 365 for Customer Service

• Jeśli użytkownik nie „dotyka” ani Potencjalnych Klientów, ani Spraw i w zasadzie potrzebuje odczytu danych i dostępu do Klientów / Działań, to Licencja „lekka” Team Member

Oczywiście zawsze można zamienić Basic na Enterprise Plan 1.
Essential Licencja „lekka” Team Member
Employee Self-Service Licencja „lekka” Team Member

 

Jak łatwo się domyślić, zamiana licencji Basic na Licencję Pełną (na Aplikację, albo na Plan) niesie ze sobą spore koszty, bo Basic kosztował przecież około 30% ceny Professional’a w Dynamics CRM 2016. Jednocześnie w wielu przypadkach możliwa będzie wymiana Basic na Licencję „lekką” Team Member i wtedy koszty będą znacznie niższe, bo Team Member w najdroższej wersji to wydatek około 8,40 EUR miesięcznie, czyli znacznie mniej niż za Basic kiedyś.

 

Jak kupić licencje Microsoft Dynamics 365?

Standardowo licencje Microsoft kupuje się od partnerów Microsoft (takich jak Netwise), a nie od samego Microsoft’u – tutaj nic się nie zmienia. Zmienia się jednak dostępność Dynamics 365 w różnych programach licencyjnych. I tak, licencje Dynamics 365 możemy kupić poprzez nastepujące umowy:

  • Enterprise Agreement (EA) – TAK
  • Microsoft Products and Services Agreement (MPSA) – TAK
  • Open (najbardziej popularny model) – NIE
  • Cloud Solution Provider (CSP) – TAK

W każdej umowie licencje Dynamics 365 są subskrypcją, mimo tego, że można je płacić w ratach miesięcznych, rocznych, albo jednorazowo (Enterprise Agreement). Każda licencja Dynamics 365 daje tzw. podwójne prawa (dual rights) do instalacji Dynamics 365 w infrastrukturze Klienta (On-Premise).

Warto zwrócić uwagę, że Dynamics 365 nie można już kupić w programie Open, a więc poprzez jednorazową płatność pozwalającą kupić licencje na własność!

 

Mam nadzieję, że powyższe podsumowanie rozjaśni Wam licencjonowanie Dynamics 365. Jeśli chcecie wiedzieć więcej, to polecam oficjalną stronę Microsoft dotyczącą licencjonowania (https://www.microsoft.com/pl-pl/dynamics365/pricing), albo kontakt z konsultantami Netwise (http://www.netwise.pl).

 

 

 

Dynamics Marketing, czyli nigdy nieistniejący produkt i przyszłość marketingu w Dynamics 365

Jakub (Kuba) Skałbania co nowego?, Dynamics 365

Microsoftu przygoda z marketingiem cyfrowym

Rok temu gdzieś „wypsnęło” mi się na którymś wystąpieniu z przedstawicielami Microsoft Polska, że linia produktów Dynamics nie ma narzędzia marketingowego poza funkcjonalnością Microsoft Dynamics CRM. Oczywiście mamy wspaniałe rozszerzenie ClickDimensions i wszystkie funkcje modułu Marketing z Dynamics CRM, ale nie ma Microsoft prawdziwej konkurencji dla Salesforce’owego Pardot’a, Marketo, czy Adobe Marketing Cloud. I co? I oberwało mi się, że jak to nie ma. A Dynamics Marketing?!

No tak, ale moja odpowiedź brzmiała, że Dynamics Marketing, a więc wcześniejszy MarketingPilot to produkt z tzw. statusem „dead-on-arrival”, czyli zabity zanim w ogóle zaczął istnieć. Kupiony przez Microsoft po coś innego (patrz mechanizm budowy przepływów pracy, czyli Workflow Builder w nowym Dynamics 365 😉 ), a  nie dla funkcjonalności marketingu. Najlepiej można było się przekonać, sprawdzając, czy jest dostępny w cennikach.

Trzeba było czekać rok, żeby Microsoft ogłosił to już publicznie – linia produktów Dynamics nie miała pełnego modułu marketingowego. Przez pełny mam na myśli planowanie, egzekucję, rozliczanie kampanii. Zarówno w marketingu cyfrowym, jak i marketingu ATL / BTL, planowania działań wielokanałowych, śledzenia zachowania, liczenia ROI, planowania wydatków marketingowych i zderzaniu ich z lead generation itd. Jednym słowem – nie mieliśmy w linii Dynamics z prawdziwego zdarzenia systemu do Campaign Management.

Co w związku z tym? Niespodzianka!

Microsoft tydzień temu publicznie ogłosił partnerstwo z Adobe, które ma na celu zaoferowanie Adobe Microsoft Cloud jako OFICJALNY moduł marketingowy w nadchodzącej wielkimi krokami platformie Microsoft Dynamics 365.

Adobe Marketing Cloud to w pełni dojrzałe narzędzie do zarządzania kampaniami marketingowymi. AMC składa się z kilku modułów, w tym z trzech głównych – Adobe Campaign, Adobe Experience Manager i Adobe Analytics. Wszystkie moduły będą częścią planu Enterprise w Microsoft Dynamics 365.

Adobe Campaign:

Adobe Campaign to platforma do obsługi marketingu wielokanałowego pozwalająca na planowanie i uruchamianie kampanii marketingowych, włączając w to email marketing i marketing smsowy. Dodatkowo Adobe Campaign pozwala na integrację ze stronami i systemami e-commerce oraz na interakcje na żywo poprzez monitoring zachowań użytkowników i analitykę na żywo.

Adobe Campaign pozwala na trzymanie wielu informacji o użytkownikach w jednym miejscu. Te dane wzbogacą dane trzymane w Dynamics CRM (a raczej w module, który nazywał się będzie Microsoft Dynamics 365 for Sales).

Więcej tu: https://www.adobe.com/pl/marketing-cloud/campaign-management.html

 

Adobe Experience Manager:

Adobe Experience Manager to w zasadzie bardzo zaawansowany CMS pozwalający na budowanie formatek, landing page’y i stron, które mogą być wykorzystywane w kampaniach marketingowych i serwowane odpowiednio w zależności od segmentacji, kanału, czy rozgałęzienia kampanii wynikającego z poprzednich działań z danym klientem.

Więcej tu: https://www.adobe.com/pl/marketing-cloud/enterprise-content-management.html

 

Adobe Analytics:

Adobe Analytics to bardzo zaawansowana platforma chmurowa do monitoringu i analiz sentymentów w internecie oraz do śledzenia zachowań użytkowników. Adobe Analytics pozwala na bardzo zaawansowaną segmentację, w tym segmentację na żywo, a także na marketing predykcyjny (predictive marketing) bazujący na badaniu korelacji i skłonności klientów (customer propensity). Dodatkowo Adobe Analytics wspiera analizę big data i wnioskowanie z nieustrukturyzowanych danych gromadzonych przez wiele firm w internecie (takich jak geolokalizacja, sentymenty itd).

Więcej tu: http://www.adobe.com/pl/marketing-cloud/web-analytics.html

Czy to dobre? Co dalej?

Adobe Marketing Cloud to jedno z najlepszych rozwiązań tego typu na świecie, na pewno. Połączone z Dynamics 365 for Sales (czyli na tę chwilę jeszcze Dynamics CRM 😉 ) jest w pełni zintegrowaną platformą do zarządzania kampaniamii. Wreszcie platformą, której nie trzeba sie wstydzić tak, jak Dynamics Marketing…

 

[EDIT, 2016-10-10]

Więcej na temat partnerstwa Adobe i Microsoft w bardziej oficjalnej formie można przeczytać na Blogu Netwise tutaj: http://blog.netwise.pl/microsoft-adobe-partnerstwo/