Aktualizacja Dynamics 365 trafia do Twojego środowiska dwa razy w roku, automatycznie i niezależnie od tego, czy Twój zespół jest na to gotowy. Microsoft dostarcza dziesiątki nowych funkcji w każdym release wave: nowe widoki sprzedażowe, rozszerzenia Copilota, zmiany w interfejsie Customer Service, poprawki modeli danych. Problem w tym, że sama aktualizacja platformy to dopiero połowa pracy. Konfiguracja środowiska, weryfikacja integracji, wdrożenie nowych funkcji dla użytkowników i testowanie regresji pozostają po stronie firmy lub jej partnera. Nasi konsultanci podczas realizacji projektów obserwują ten sam wzorzec: organizacje, które wdrożyły Dynamics 365 Sales lub Customer Service kilka lat temu, płacą za licencje obejmujące funkcje, z których nigdy nie skorzystały, bo nikt nie zadbał o to, żeby kolejne aktualizacje przekładały się na realne zmiany w pracy zespołu. W tym artykule pokazujemy, dlaczego aktualizacja systemu CRM to proces ciągły, a nie jednorazowe zdarzenie, i jak wygląda aktywna opieka nad środowiskiem Dynamics 365, która zamienia każdy release wave w przewagę operacyjną zamiast w ryzyko.
Microsoft aktualizuje Dynamics 365 w dwóch cyklach rocznych: Wave 1 w pierwszym kwartale i Wave 2 w trzecim. Każdy z nich przynosi setki zmian: nowe funkcje, poprawki interfejsu, rozszerzenia modelu danych, aktualizacje Copilota. Z perspektywy platformy system jest więc zawsze aktualny. Z perspektywy organizacji, która z niego korzysta, obraz wygląda zupełnie inaczej. Często identyfikujemy tę rozbieżność jako główną przyczynę frustracji zespołów sprzedaży i obsługi klienta: system teoretycznie działa, ale w praktyce nie nadąża za tym, jak firma chce pracować.
Release wave to półroczny pakiet zmian, który Microsoft zapowiada z wyprzedzeniem w dokumentacji publicznej, a następnie wdraża stopniowo do środowisk produkcyjnych. Część funkcji trafia do systemu automatycznie, część wymaga ręcznego włączenia przez administratora. Nasi konsultanci podczas realizacji projektów regularnie natrafiają na środowiska, w których funkcje dostępne od dwóch lub trzech wave'ów nadal nie są aktywne, bo nikt w organizacji nie przeanalizował listy zmian i nie podjął decyzji o ich wdrożeniu. W efekcie firma płaci za możliwości, których nie używa, a jej konkurenci, korzystający z tych samych licencji i aktywnego partnera, mają już wdrożone narzędzia zwiększające produktywność handlowców.
Problem nie leży w braku informacji: Microsoft publikuje szczegółowe release notes dla każdej aktualizacji Dynamics 365 Sales i Customer Service. Problem leży w tym, że ich przeczytanie, zrozumienie i przełożenie na konkretne decyzje konfiguracyjne wymaga czasu i kompetencji technicznych, których większość organizacji nie ma wewnętrznie. Bez osoby lub partnera, który aktywnie śledzi zmiany platformy, kolejne wave'y mijają niezauważone.
Każdy release wave dzieli funkcje na dwie kategorie. Pierwsza to zmiany włączane domyślnie: trafiają do środowiska produkcyjnego bez żadnej akcji ze strony administratora i mogą zmienić wygląd interfejsu lub zachowanie elementów, z których korzystają użytkownicy każdego dnia. Druga kategoria to funkcje opcjonalne: dostępne w systemie, ale wymagające świadomej decyzji o aktywacji.
Bez przeglądu release notes przed wdrożeniem wave'u organizacja nie wie, co zmieni się samo, a co trzeba włączyć. To właśnie w tej luce powstają incydenty zgłaszane jako „CRM nagle działa inaczej" — i to właśnie tu aktywna opieka partnera ma największą wartość dla optymalizacji Dynamics 365.
Aktualizacja Dynamics 365 obejmuje platformę: jej rdzeń, standardowe encje, interfejs i wbudowane funkcje. Nie obejmuje jednak trzech warstw, które w każdej wdrożonej organizacji są równie istotne. Pierwsza warstwa to konfiguracja: widoki, formularze, reguły biznesowe, przepływy pracy i ustawienia zespołów, które zostały dostosowane do procesów Twojej firmy podczas wdrożenia. Druga warstwa to integracje: połączenia z systemami zewnętrznymi, synchronizacja danych, konektory Power Automate. Trzecia warstwa to użytkownicy: ich nawyki, poziom znajomości systemu i sposób, w jaki faktycznie z niego korzystają każdego dnia.
Widzimy częsty problem w organizacjach, które po wdrożeniu nie mają aktywnego partnera: każda automatyczna zmiana platformy wchodzi w interakcję z tymi trzema warstwami bez żadnej weryfikacji. Reguła biznesowa oparta na polu, które Microsoft zmienił w nowym wave'ie, przestaje działać poprawnie. Integracja z systemem ERP zaczyna zwracać błędy po cichu. Użytkownicy zgłaszają, że „coś się zmieniło", ale nikt nie wie co i dlaczego.
Platforma Microsoftu jest aktualizowana centralnie i nie ma możliwości jej zatrzymania. Oznacza to, że każda organizacja korzystająca z Dynamics 365 w modelu chmurowym podlega tym zmianom niezależnie od swojej gotowości. Różnica między firmami, które to rozumieją, a tymi, które nie, jest prosta: jedne zarządzają tymi zmianami aktywnie, inne reagują na incydenty.
Aktywne zarządzanie oznacza przegląd nadchodzącego wave'u na środowisku testowym, weryfikację konfiguracji i integracji przed wdrożeniem produkcyjnym oraz zaplanowane komunikaty do użytkowników o zmianach w interfejsie. To praca, która nie wymaga dużego nakładu, ale wymaga systematyczności i kompetencji — dlatego najefektywniej realizuje ją zewnętrzny partner utrzymaniowy.
Podczas konsultacji często wskazujemy na konkretne zachowania organizacyjne, które sygnalizują, że aktualizacja Dynamics 365 działa tylko na poziomie platformy, a nie na poziomie realnej wartości dla firmy. Pierwszym sygnałem jest to, że użytkownicy zgłaszają zmiany w interfejsie jako błędy: nie wiedzą, że to efekt wave'u, bo nikt ich o tym nie poinformował. Kolejnym jest sytuacja, w której handlowcy prowadzą część pracy poza systemem, w arkuszach kalkulacyjnych lub e-mailach, mimo że Dynamics 365 Sales posiada funkcje, które mogłyby to zastąpić.
Trzecim sygnałem jest brak kogoś w organizacji, kto mógłby odpowiedzieć na pytanie: „jakie nowe funkcje pojawiły się w ostatnim wave'ie i które z nich włączyliśmy?" Czwarty to integracje działające bez monitorowania: nikt nie wie, czy dane synchronizują się poprawnie, dopóki ktoś nie zauważy rozbieżności. Piątym sygnałem jest to, że ostatni przegląd konfiguracji systemu miał miejsce przy wdrożeniu, kilka lat temu. Jeśli rozpoznajesz więcej niż dwa z tych scenariuszy w swojej organizacji, środowisko Dynamics 365 wymaga aktywnej opieki, a nie tylko utrzymania reaktywnego. Szczegółową ocenę stanu środowiska przeprowadzamy w ramach bezpłatnej konsultacji.
Środowisko Dynamics 365, które nie jest aktywnie zarządzane, nie psuje się nagle. Degraduje się stopniowo: konfiguracja rozjeżdża się z procesami firmy, integracje działają z rosnącą liczbą cichych błędów, a użytkownicy wypracowują obejścia, które stają się nowym standardem pracy. Ten proces jest trudny do zauważenia od środka, bo każda zmiana jest mała i lokalna.
Z zewnątrz widać go wyraźnie: nasi konsultanci podczas audytów przejęciowych regularnie dokumentują środowiska, w których dystans między tym, co system potrafi, a tym, z czego firma faktycznie korzysta, narósł przez lata biernego utrzymania. Odrobienie tego dystansu jest możliwe, ale kosztuje znacznie więcej niż systematyczna opieka od początku. Więcej o tym, jak wygląda taki audyt, piszemy w artykule o audycie i naprawie wdrożenia CRM.
Każdy release wave to w praktyce lista funkcji, które czekają na decyzję: włączyć, skonfigurować, zakomunikować użytkownikom lub świadomie pominąć. Organizacje, które mają aktywnego partnera zarządzającego środowiskiem, podejmują te decyzje systematycznie i z wyprzedzeniem. Pozostałe odkrywają nowe funkcje przypadkowo lub nie odkrywają ich wcale. Różnica w produktywności zespołów sprzedaży i obsługi klienta, która narasta między tymi dwoma grupami przez kolejne lata, jest jednym z najbardziej niedocenianych kosztów biernego podejścia do utrzymania systemu CRM.
Nasi konsultanci podczas realizacji projektów utrzymaniowych regularnie konfigurują funkcje dostępne w systemie od miesięcy, a nawet lat, które klient widzi po raz pierwszy. W obszarze Dynamics 365 Sales szczególnie duży wpływ na codzienną pracę handlowców mają narzędzia organizacji pracy i priorytyzacji. Sales Accelerator z wbudowaną listą zadań handlowca porządkuje kolejkę działań według priorytetu i kontekstu szansy sprzedażowej. Sekwencje działań automatyzują prowadzenie leada przez kolejne kroki procesu bez konieczności ręcznego planowania każdej aktywności. Forecasting dostarcza menedżerom sprzedaży prognoz opartych na rzeczywistych danych pipeline'u, a nie na subiektywnych deklaracjach handlowców.
W obszarze Dynamics 365 Customer Service równie duży potencjał drzemie w funkcjach, które większość organizacji ma dostępne, ale niewłączone. Integracja z Microsoft Teams bezpośrednio w rekordzie sprawy pozwala agentom konsultować trudne przypadki bez wychodzenia z systemu. Model danych klienta budujący prawdziwy widok 360 stopni, wzbogacony o dane pobierane automatycznie ze źródeł zewnętrznych, dostarcza agentom kontekstu, który skraca czas obsługi i podnosi jej jakość. To funkcje, które są już w systemie, w ramach posiadanych licencji, i wymagają wyłącznie konfiguracji przez partnera znającego optymalizację Dynamics 365.
Opportunity i Lead Health Score to kolejny przykład funkcji, która wymaga aktywacji i kalibracji pod procesy konkretnej firmy. System ocenia kondycję szansy sprzedażowej lub leada na podstawie aktywności, czasu bez kontaktu i postępu w lejku. Handlowiec widzi, które rekordy wymagają uwagi, zanim sam zauważy problem. Bez konfiguracji tej funkcji przez partnera ocena zdrowia rekordów albo nie istnieje, albo opiera się na domyślnych parametrach Microsoftu, które rzadko pasują do specyfiki procesu sprzedażowego klienta.
Podobnie działa ulepszony tracking wiadomości e-mail: system rejestruje otwarcia, kliknięcia i odpowiedzi, dostarczając handlowcowi sygnałów o zaangażowaniu kontaktu bez konieczności manualnego śledzenia korespondencji. To informacja, która zmienia moment i sposób follow-upu, a jej wartość jest dostępna od razu po prawidłowej konfiguracji środowiska.
Microsoft Copilot w Dynamics 365 Sales i Customer Service to obszar, w którym dystans między tym, co jest dostępne, a tym, z czego organizacje faktycznie korzystają, jest największy. Copilot summary generuje automatyczne podsumowanie rekordu szansy sprzedażowej lub sprawy obsługowej przed spotkaniem lub rozmową, oszczędzając handlowcowi lub agentowi kilka minut przygotowania przy każdym kontakcie. W skali tygodnia i całego zespołu to godziny odzyskanego czasu pracy. AI email drafting tworzy wstępne wersje wiadomości na podstawie kontekstu rekordu i historii komunikacji, skracając czas przygotowania korespondencji bez obniżania jej jakości.
Nasi architekci systemowi podkreślają, że Copilot działa tym lepiej, im lepiej skonfigurowane jest środowisko danych wokół niego. Widok 360 stopni klienta, poprawna archiwizacja aktywności i właściwa integracja z SharePoint decydują o tym, czy Copilot ma dostęp do pełnego kontekstu, czy tylko do wycinka danych. To kolejny powód, dla którego aktualizacja Dynamics 365 i wdrożenie nowych funkcji AI to nie dwa oddzielne projekty, ale jedno zadanie wymagające spójnego podejścia do całego środowiska. Szczegółowy zakres prac w tym obszarze omawiamy w ramach usługi optymalizacji Dynamics 365.
Bariera wdrożenia Copilota w Dynamics 365 nie jest techniczna. Funkcje są dostępne, dokumentacja Microsoftu jest obszerna, a sama aktywacja zajmuje administratorowi godziny, nie tygodnie. Barierą jest brak kogoś, kto przetłumaczy możliwości platformy na konkretne scenariusze użycia w procesach sprzedażowych lub obsługowych Twojej firmy i przeprowadzi użytkowników przez zmianę sposobu pracy.
Automatyzacje Power Automate zintegrowane z Dynamics 365 działają analogicznie: generator dokumentów ofertowych, automatyczne alerty o zmianie statusu szansy, powiadomienia Teams przy eskalacji sprawy obsługowej. Każda z tych automatyzacji jest możliwa do skonfigurowania w ramach posiadanej licencji i przynosi mierzalny efekt od pierwszego dnia działania.
Aktywne zarządzanie aktualizacją Dynamics 365 to nie tylko wdrażanie nowych funkcji. To również ochrona tego, co już działa. Każdy release wave niesie ryzyko regresji: zmiany na poziomie platformy mogą wpłynąć na customizacje, reguły biznesowe i integracje zbudowane podczas wdrożenia. Bez testów regresji przeprowadzonych na środowisku sandbox przed wdrożeniem produkcyjnym organizacja dowiaduje się o problemach od użytkowników, a nie od partnera.
Podczas konsultacji często wskazujemy na archiwizację aktywności jako obszar szczególnie wrażliwy w środowiskach, które przez lata działały bez opieki. Dataverse storage zapełnia się wolniej, gdy aktywności są archiwizowane zgodnie z polityką, a nie przechowywane bezterminowo w środowisku produkcyjnym. Podobnie integracja z SharePoint, gdy jest prawidłowo skonfigurowana ze strukturą folderów i uprawnieniami dostosowanymi do procesów firmy, odciąża storage CRM i zapewnia porządek dokumentacyjny, który przetrwa kolejne wave'y bez interwencji. Więcej o tym, jak przygotowujemy środowiska do przejęcia, opisujemy w artykule o reimplementacji Dynamics 365.
Testy regresji przed każdym wave'em to element aktywnej opieki, który ma największy wpływ na stabilność środowiska produkcyjnego. Partner przejmujący opiekę nad Dynamics 365 powinien mieć dostęp do środowiska sandbox, protokół testowy obejmujący kluczowe scenariusze biznesowe i procedurę eskalacji w przypadku wykrycia konfliktu z istniejącą konfiguracją.
Organizacje, które przeszły przez ten model choć przez jeden cykl wave'owy, opisują zmianę w ten sam sposób: aktualizacja Dynamics 365 przestała być źródłem niepokoju, a stała się regularnym, przewidywalnym wydarzeniem z jasnym harmonogramem i zerową liczbą nieplanowanych incydentów.
Decyzja o braku aktywnej opieki nad środowiskiem Dynamics 365 rzadko jest podejmowana świadomie. Częściej wynika z przekonania, że system, który działa, nie wymaga uwagi. To przekonanie jest kosztowne, choć przez długi czas niewidoczne w żadnym raporcie budżetowym. Koszty zaniedbania środowiska CRM kumulują się w trzech miejscach jednocześnie: w czasie pracy zespołów, w rosnącym długu konfiguracyjnym i w ryzyku, które materializuje się najczęściej w najgorszym możliwym momencie.
Nasi konsultanci podczas audytów przejęciowych dokumentują środowiska, w których dług konfiguracyjny narósł przez kilka lat biernego utrzymania. Obraz jest powtarzalny: część reguł biznesowych przestała działać po którymś z wave'ów i nikt tego nie naprawił, bo użytkownicy wypracowali obejście. Obejście stało się standardem pracy. Kolejna aktualizacja Dynamics 365 wchodzi w interakcję z tym obejściem i tworzy nowy problem. Cykl się powtarza, a każda iteracja oddala środowisko od stanu, w którym można je rozwijać w kontrolowany sposób.
Regresje po aktualizacjach mają konkretny koszt: czas zgłoszenia problemu, czas diagnozy, czas naprawy i czas komunikacji z użytkownikami. Każdy nieplanowany incydent w środowisku produkcyjnym pochłania zasoby, które w modelu aktywnej opieki byłyby przeznaczone na rozwój systemu. Widzimy częsty problem w organizacjach, które nie testują wave'ów na środowisku sandbox: pierwszym miejscem, gdzie problem wychodzi na jaw, jest środowisko produkcyjne, a pierwszą osobą, która o nim informuje, jest użytkownik w trakcie pracy z klientem.
Dług konfiguracyjny jest szczególnie trudny do wyceny, bo nie pojawia się w żadnej fakturze. Objawia się za to w spowalnianiu każdego nowego projektu rozwojowego: zanim można dodać nową funkcję, trzeba zrozumieć, w jakim stanie jest obecna konfiguracja, które elementy są niestandardowe i dlaczego. W środowisku bez dokumentacji i bez historii zmian to zadanie, które może zająć tyle samo czasu co sam rozwój.
Archiwizacja aktywności i porządek w Dataverse storage to przykłady obszarów, które przy aktywnej opiece kosztują kilka godzin konfiguracji raz na kwartał. Bez tej opieki Dataverse zapełnia się niestrukturyzowanymi danymi historycznymi, co przekłada się na rosnące koszty storage i wolniejsze działanie systemu przy każdym kolejnym wave'ie.
Porównanie kosztów obu modeli utrzymania jest prostsze, niż się wydaje, gdy uwzględni się wszystkie składowe. Model reaktywny, czyli zgłaszanie problemów po ich wystąpieniu i zlecanie napraw ad hoc, generuje koszty trudne do przewidzenia i jeszcze trudniejsze do zakontraktowania. Każde zgłoszenie to nowa wycena, nowy czas oczekiwania i nowy kontekst do przekazania partnerowi, który nie zna środowiska na co dzień. W modelu aktywnej opieki abonamentowej partner zna system, zna historię zmian i może reagować w czasie, który jest z góry zdefiniowany w umowie.
Podczas konsultacji często wskazujemy na jeszcze jeden wymiar tej różnicy: w modelu abonamentowym partner ma interes w tym, żeby środowisko działało stabilnie, bo niestabilne środowisko generuje więcej pracy bez dodatkowego wynagrodzenia. W modelu godzinowym ten interes jest odwrócony. To strukturalna różnica, która przekłada się na podejście do prewencji, dokumentacji i zarządzania zmianą przy każdej kolejnej aktualizacji Dynamics 365. Szczegółową wycenę opieki abonamentowej przygotowujemy indywidualnie podczas bezpłatnej konsultacji.
Stała opieka techniczna nad Dynamics 365 ma jeszcze jeden wymiar, który rzadko pojawia się w kalkulacjach ROI: wartość skumulowanej wiedzy o środowisku. Partner, który opiekuje się systemem przez rok lub dwa, zna każdą customizację, każdą integrację i historię każdej zmiany. Ta wiedza ma realną wartość finansową: skraca czas diagnozy problemów, eliminuje konieczność ponownego kontekstualizowania każdego zlecenia i pozwala na proaktywne rekomendacje zamiast reaktywnych napraw.
Utrata tego partnera i onboarding nowego to koszt, który organizacje często bagatelizują przy porównywaniu ofert. Audyt przejęciowy, czas na poznanie środowiska i nieunikniony okres obniżonej efektywności to realne wydatki, które w stabilnej relacji z jednym partnerem ponosi się tylko raz.
Reimplementacja Dynamics 365 jest w większości przypadków konsekwencją kilku lat zaniedbań, a nie jednego poważnego incydentu. Nasi architekci systemowi podkreślają, że granica, po przekroczeniu której naprawa środowiska jest droższa niż jego odbudowa, jest trudna do wskazania z wyprzedzeniem, ale łatwa do rozpoznania po fakcie. Środowisko, które osiągnęło ten punkt, charakteryzuje się zwykle kilkoma wspólnymi cechami: brak dokumentacji konfiguracji, customizacje warstwy na warstwie bez wiedzy o tym, co jest aktywne, integracje działające w trybie awaryjnym od miesięcy i użytkownicy, którzy przestali ufać systemowi i prowadzą równoległą ewidencję poza CRM.
Koszt reimplementacji to wielokrotność kosztu pierwotnego wdrożenia, powiększona o czas migracji danych, przeprojektowania procesów i ponownego onboardingu użytkowników. Aktywna opieka nad środowiskiem, nawet jeśli nie zapobiega wszystkim problemom, systematycznie oddala ten scenariusz, utrzymując system w stanie, który pozwala na kontrolowany rozwój zamiast kryzysowej odbudowy. Więcej o tym, kiedy reimplementacja staje się konieczna i jak ją przeprowadzić, piszemy w artykule o migracji systemu CRM do chmury.
Wczesne rozpoznanie degradacji środowiska jest możliwe i znacznie tańsze niż reagowanie na jej skutki. Audyt przejęciowy przeprowadzany przy zmianie partnera lub po kilku latach bez zewnętrznej opieki dostarcza obiektywnej oceny stanu konfiguracji, integracji i adopcji systemu przez użytkowników. Na jego podstawie można podjąć świadomą decyzję: naprawiać przyrostowo, przeprowadzić reimplementację lub zmienić zakres systemu.
Każda z tych ścieżek jest lepsza od kontynuowania status quo w środowisku, które przestało służyć organizacji. Różnica między nimi sprowadza się do czasu, budżetu i gotowości zespołu na zmianę — i to właśnie te trzy wymiary analizujemy podczas pierwszego spotkania z klientem rozważającym przejście pod opiekę ARP Ideas.
Żeby aktywnie zarządzać aktualizacją Dynamics 365, trzeba rozumieć, jak Microsoft ten proces organizuje. Cykl release wave nie jest przypadkowym zdarzeniem: ma określony harmonogram zapowiedzi, okno testowe i datę wdrożenia produkcyjnego. Organizacje, które ten harmonogram znają i wpisują go w swój kalendarz operacyjny, mają czas na przygotowanie. Pozostałe dowiadują się o zmianach, gdy te już obowiązują w ich środowisku produkcyjnym.
Microsoft publikuje plany każdego release wave z kilkumiesięcznym wyprzedzeniem w dokumentacji Microsoft Learn. Wave 1 obejmuje zmiany wdrażane między lutym a czerwcem, a jego zapowiedź pojawia się już w październiku poprzedniego roku. Wave 2 obejmuje sierpień do listopada, a jego dokumentacja jest dostępna od kwietnia. To okno wyprzedzenia jest realną możliwością przygotowania: partner zarządzający środowiskiem ma czas przeczytać release notes, ocenić wpływ zmian na istniejącą konfigurację, zaplanować testy i podjąć decyzję, które z nowych funkcji wdrożyć w pierwszej kolejności.
Każdy wave obejmuje zmiany dla całego ekosystemu Dynamics 365, w tym osobne sekcje dla Sales i Customer Service. Nasi konsultanci podczas realizacji projektów utrzymaniowych pracują na liście zmian podzielonej na trzy kategorie: funkcje włączane automatycznie dla wszystkich użytkowników, funkcje dostępne opcjonalnie dla administratorów oraz funkcje w trybie early access, które można aktywować na środowisku testowym jeszcze przed oficjalnym wdrożeniem. Ta ostatnia kategoria jest szczególnie wartościowa: pozwala ocenić nowe możliwości bez jakiegokolwiek ryzyka dla środowiska produkcyjnego.
Dokumentacja release wave dla Dynamics 365 Sales i Customer Service liczy przy każdym cyklu od kilkudziesięciu do ponad stu pozycji. Nie wszystkie są istotne dla każdego środowiska: część zmian dotyczy funkcji, których klient nie używa, część to poprawki błędów bez wpływu na konfigurację, a część to nowe możliwości wymagające aktywnej decyzji o wdrożeniu. Zadaniem partnera utrzymaniowego jest przejście przez tę listę i wyfiltrowanie tego, co ma realne znaczenie dla konkretnego środowiska.
To zadanie, które przy znajomości środowiska zajmuje kilka godzin i dostarcza jasnej listy działań do podjęcia przed wdrożeniem produkcyjnym. Bez tej znajomości staje się projektem samym w sobie, co tłumaczy, dlaczego organizacje bez stałego partnera najczęściej nie podejmują go wcale.
Środowisko sandbox w Dynamics 365 to oddzielna instancja systemu, na której Microsoft wdraża zmiany wave'owe wcześniej niż na produkcji. To właśnie tutaj partner utrzymaniowy przeprowadza testy regresji: uruchamia kluczowe scenariusze biznesowe, sprawdza, czy customizacje i reguły działają zgodnie z oczekiwaniem, i weryfikuje stabilność integracji po zmianach platformy. Wynik tych testów to lista: co działa bez zmian, co wymaga korekty konfiguracji i co należy zakomunikować użytkownikom jako zmianę w interfejsie lub zachowaniu systemu.
Zarządzanie zmianą po stronie użytkowników to element, który organizacje najczęściej pomijają w planowaniu wave'u, a który ma największy wpływ na adopcję nowych funkcji. Nasi architekci systemowi podkreślają, że nawet najlepiej skonfigurowana funkcja nie przynosi wartości, jeśli użytkownicy jej nie znają lub nie wiedzą, kiedy jej używać. Krótka komunikacja przed wdrożeniem wave'u opisująca, co się zmieni i dlaczego, różni się od braku komunikacji tym samym, czym kontrolowana zmiana różni się od incydentu: reakcją zespołu i czasem potrzebnym na adaptację.
Protokół testowy dla środowiska Dynamics 365 nie musi być rozbudowany, żeby był skuteczny. Wystarczy lista scenariuszy pokrywających krytyczne procesy biznesowe obsługiwane przez system: rejestracja leada, prowadzenie szansy przez lejek, zamknięcie sprawy obsługowej, synchronizacja z systemem ERP. Jeśli te scenariusze działają poprawnie na sandbox po wdrożeniu wave'u, ryzyko incydentu produkcyjnego jest minimalne.
Budowa i utrzymanie tego protokołu to część pracy partnera utrzymaniowego, która przynosi wartość przy każdym kolejnym wave'ie. Zakres i szczegółowość testów dostosowujemy do złożoności środowiska w ramach usługi optymalizacji i opieki nad Dynamics 365.
Aktualizacja Dynamics 365 wpływa nie tylko na rdzeń CRM, ale na cały ekosystem zbudowany wokół niego. Power Automate, Power Apps i Power BI połączone z Dynamics 365 korzystają z tych samych konektorów i modelu danych, który zmienia się wraz z każdym wave'em. Zmiana schematu encji lub nazwy pola w standardowej tabeli Dataverse może cicho zepsuć przepływ Power Automate działający od miesięcy bez żadnego incydentu. Integracje z systemami zewnętrznymi, takimi jak ERP czy systemy księgowe, są jeszcze bardziej wrażliwe: synchronizacja danych oparta na konkretnych polach i wartościach słownikowych nie toleruje nieoczekiwanych zmian po stronie platformy.
Nasi konsultanci podczas realizacji projektów utrzymaniowych prowadzą rejestr integracji i automatyzacji dla każdego obsługiwanego środowiska. Przed każdym wave'em ten rejestr jest punktem wyjścia do testów: które przepływy mogą być dotknięte zmianami w modelu danych, które konektory wymagają weryfikacji, które raporty Power BI odwołują się do pól zmienianych w nowym release'ie. To właśnie ten rejestr — dokument, którego większość firm nie posiada — jest fundamentem przewidywalnego zarządzania aktualizacjami Dynamics 365 w złożonych środowiskach.
Integracja z SharePoint w kontekście aktualizacji Dynamics 365 wymaga osobnej uwagi ze względu na strukturę uprawnień i mapowanie dokumentów do rekordów CRM. Po wave'ach zmieniających model danych lub uprawnienia dostępu biblioteki SharePoint powiązane z rekordami mogą wymagać reweryfikacji mapowania. Przy prawidłowej konfiguracji i aktywnym monitoringu to zadanie zajmuje minuty. Bez monitoringu jego efekty mogą być niezauważone przez tygodnie.
Power BI Integration z Dynamics 365 jest szczególnie wrażliwa na zmiany nazw pól i tabel w Dataverse. Raporty zbudowane na widokach CRM mogą przestać odświeżać dane po wave'ie, który zmienił strukturę widoku bazowego. Weryfikacja raportów BI po każdym wave'ie to standardowy element protokołu testowego w środowiskach, gdzie zarząd korzysta z dashboardów sprzedażowych opartych na danych Dynamics 365.
Decyzja o przekazaniu opieki nad środowiskiem Dynamics 365 zewnętrznemu partnerowi jest łatwiejsza, gdy wiadomo, jak ten proces wygląda w praktyce. W ARP Ideas nie zaczynamy od podpisania umowy wsparcia: zaczynamy od zrozumienia stanu środowiska, które mamy przejąć. To podejście chroni obie strony przed zobowiązaniami opartymi na niepełnej wiedzy i pozwala zbudować warunki współpracy, które są uczciwe i realistyczne od pierwszego dnia.
Podczas konsultacji często wskazujemy na konkretne sygnały, które odróżniają środowisko wymagające aktywnej opieki od takiego, które radzi sobie z bieżącym utrzymaniem. Pierwszym sygnałem jest brak osoby w organizacji, która potrafi odpowiedzieć na pytanie o stan systemu: co zostało zmienione w ostatnim roku, które funkcje są aktywne, jak wyglądają integracje. Jeśli wiedza o systemie jest rozproszona lub nieudokumentowana, ryzyko każdego kolejnego wave'u rośnie.
Drugi sygnał to korzystanie z Dynamics 365 wyłącznie w zakresie wdrożonym kilka lat temu, bez żadnych zmian od tamtego momentu. System, który nie ewoluuje wraz z procesami firmy, zaczyna być postrzegany przez użytkowników jako przeszkoda, a nie narzędzie. Trzecim sygnałem jest brak środowiska sandbox lub nieużywanie go do testów przed wave'em. Czwartym jest historia incydentów, w których zmiany w systemie były odkrywane przez użytkowników, nie przez administratora lub partnera. Piątym sygnałem jest aktualny model wsparcia oparty wyłącznie na zgłoszeniach reaktywnych, bez żadnego elementu proaktywnego przeglądu środowiska.
Rozpoznanie tych sygnałów nie oznacza, że środowisko jest w złym stanie. Oznacza, że jego stan jest nieznany — a nieznany stan środowiska produkcyjnego to ryzyko, które materializuje się przy pierwszym poważniejszym wave'ie lub pierwszej zmianie procesowej w firmie wymagającej rekonfiguracji systemu.
Nasi konsultanci podczas audytów przejęciowych regularnie napotykają środowiska, w których stan konfiguracji okazuje się lepszy, niż klient się obawiał, albo wymagający więcej pracy, niż zakładał. W obu przypadkach wynik audytu dostarcza czegoś, czego wcześniej brakowało: pewności co do tego, z czym ma się do czynienia. Więcej o tym, jak przebiega taka ocena, opisujemy w artykule o audycie i naprawie wdrożenia CRM.
Przejęcie opieki nad środowiskiem Dynamics 365 w ARP Ideas przebiega w trzech etapach, z których pierwszy jest bezpłatny. Warsztaty rozpoznawcze to dwie sesje online, podczas których wspólnie mapujemy procesy obsługiwane przez system, identyfikujemy kluczowe integracje i oceniamy, czego o systemie nie wiadomo. Wynikiem tych warsztatów jest doprecyzowana oferta audytu przejęciowego, oparta na rzeczywistym kontekście, a nie na widełkach szacunkowych.
Audyt przejęciowy to pełna inwentaryzacja środowiska: konfiguracja, customizacje, integracje, stan Dataverse, środowisko sandbox, dostępy i dokumentacja. Jego wynikiem jest dokument zdawczy, który staje się własnością klienta niezależnie od dalszej współpracy, oraz mapa ryzyk wskazująca obszary wymagające uwagi w pierwszej kolejności. Na tej podstawie przygotowujemy warunki umowy wsparcia abonamentowego, które są uczciwe dla obu stron, bo opierają się na tym, co naprawdę wiemy o systemie, a nie na tym, co zakładamy. Szczegółowy zakres usługi utrzymania i optymalizacji Dynamics 365 opisujemy na stronie usługowej.
Model abonamentowej opieki nad Dynamics 365 obejmuje zarządzanie aktualizacjami przy każdym wave'ie, bieżące wsparcie konfiguracyjne, konsultacje dla administratora i użytkowników kluczowych, monitorowanie integracji i pule godzin na prace rozwojowe. Zakres jest ustalany po audycie i dopasowywany do rzeczywistych potrzeb środowiska: inaczej wygląda opieka nad środowiskiem z jedną integracją i standardową konfiguracją, a inaczej nad środowiskiem z rozbudowanymi customizacjami i kilkoma połączeniami z systemami zewnętrznymi.
Dla organizacji korzystających z Dynamics CRM w wersji on-premise opieka abonamentowa jest często pierwszym krokiem w kierunku migracji do chmury: partner poznaje środowisko, dokumentuje customizacje i buduje plan przeniesienia, który minimalizuje ryzyko. Więcej o tej ścieżce piszemy w artykule o migracji systemu CRM do chmury.
Aktywna opieka nad środowiskiem Dynamics 365 nie jest kosztem dodatkowym wobec licencji: jest warunkiem koniecznym, żeby te licencje przynosiły wartość. Organizacje, które traktują aktualizację Dynamics 365 jako systematyczny proces zarządzany przez partnera, korzystają z funkcji dostępnych od miesięcy, których ich konkurenci jeszcze nie odkryli, unikają incydentów produkcyjnych, które kosztują wielokrotność miesięcznego abonamentu, i budują środowisko, które jest gotowe na kolejne zmiany zamiast reaktywnie doganiać każdy wave. Rozmowę o stanie Twojego środowiska i możliwościach współpracy zaczynamy od bezpłatnych warsztatów rozpoznawczych.
Pytania, które najczęściej pojawiają się w rozmowach z organizacjami zarządzającymi środowiskami Dynamics 365 Sales i Customer Service.
Podczas bezpłatnych warsztatów rozpoznawczych oceniamy stan Twojego środowiska Dynamics 365 Sales lub Customer Service: które funkcje są aktywne, jak wyglądają integracje po ostatnich wave'ach i gdzie jest największy potencjał do odzyskania wartości z posiadanych licencji.
Warsztaty rozpoznawcze — bezpłatnie, online, bez zobowiązania
