Czy można zastąpić Dynamics 365 Sales czy inny moduł aplikacją Power Apps? Ukryte ryzyka licencyjne, które warto znać.
W tym tygodniu rozmawialiśmy z potencjalnym klientem, który szuka sposobów na optymalizację kosztów licencji Microsoft. W trakcie rozmowy okazało się, że…
W tym tygodniu rozmawialiśmy z potencjalnym klientem, który szuka sposobów na optymalizację kosztów licencji Microsoft. W trakcie rozmowy okazało się, że otrzymał już rekomendację od swojego obecnego dostawcy – firmy z wieloletnim doświadczeniem na rynku. Rekomendacja brzmiała: stopniowo zastępować standardowe funkcjonalności Dynamics 365 CRM własnymi aplikacjami Power Apps opartymi na Dataverse i standardowych encjach. Zacząć od procesów serwisowych, docelowo objąć również sprzedaż.
Słuchałam tego z szeroko otwartymi oczyma. Ktoś tu albo nie zna zasad licencjonowania Microsoft, albo po prostu nie powiedział klientowi całej prawdy.
Bo pomysł na poziomie technicznym jest wykonalny. Power Apps daje dużą swobodę, Dataverse to solidna platforma, a Canvas App można zbudować tak, żeby wyglądała i działała „niemal” jak natywny CRM. Problem zaczyna się dokładnie w tym miejscu, gdy aplikacja zaczyna wyglądać i działać jak Dynamics 365, bo Microsoft ma na to bardzo konkretną odpowiedź licencyjną.
I właśnie o tym chcę napisać. Nie po to, żeby zniechęcać do Power Apps – to świetne narzędzie, używamy go regularnie. Ale żeby pokazać, gdzie kończy się optymalizacja kosztów, a zaczyna ryzyko, które może być bardzo kosztowne.
„Skoro możemy zbudować własną aplikację (CRM) w Power Apps i użyć Dataverse jako bazy danych – po co nam licencja Dynamics 365?”
Pytanie brzmi rozsądnie i rozumiem skąd się bierze. Licencje Dynamics 365 potrafią stanowić znaczącą część projektu a w kolejnych latach widoczną w raportach część budżetu IT. Z drugiej strony Power Platform kusi elastycznością i niższymi kosztami bo umożliwia szybkie tworzenie aplikacji biznesowych gdzie Dataverse zapewnia zaawansowaną warstwę danych a licencje są znacznie tansze. Tyma samym na pierwszy rzut oka pomysł wydaje się bardzo atrakcyjny, zbudujemy własne rozwiązanie, które dopasujemy dokładnie do potrzeb organizacji, ale będzie wykorzystywało standardowe encje znane z Dynamics. Problem polega na tym, że w połowie przypadków ta kalkulacja jest błędna. Nie dlatego, że Power Apps jest złym narzędziem. Dlatego, że licencjonowanie Microsoft nie działa tak, jak większość ludzi intuicyjnie zakłada.
Skąd bierze się ten pomysł?
Schemat jest zawsze podobny. Organizacja planuje wdrożenie lub dostosowanie jakiegoś procesu/ów. Rozpoczyna od analizy kosztów i w pewnym momencie ktoś patrzy na cennik Dynamics 365 i mówi: „to jest duża pozycja w budżecie.” I już chwilę później pojawia pomysł: „mamy Power Apps, Power Automate, Dataverse i Power BI. Możemy to zbudować sami.” I tu zaczyna się problem. Bo technicznie, pełna zgoda – mają rację. To nie fantazja. Przy użyciu wyżej wskazanych narzędzi można zbudować bardzo dobre aplikacje. Power Platform jest na tyle elastyczna, że da się w niej odtworzyć znaczną część funkcjonalności Dynamics 365. Po prostu ktoś patrzy na problem wyłącznie przez pryzmat technologii, pomijając pytanie, które powinno paść jako pierwsze: czy takie podejście jest zgodne z zasadami licencjonowania Microsoft? A o pytanie rzadko pojawia się na etapie, gdy pomysł jest jeszcze świeży i wszyscy są podekscytowani perspektywą oszczędności. Pojawia się znacznie później – czasem dopiero przy audycie.
Technologia a licencjonowanie to dwa różne światy
Większość ludzi zakłada, że licencja zależy od aplikacji, w której pracuje użytkownik. Jeśli nie loguję się do Dynamics 365, nie potrzebuję licencji Dynamics 365. Brzmi logicznie, ale Microsoft nie patrzy na to w ten sposób. Dla Microsoft nie ma znaczenia, jakie okno widzi użytkownik. Liczy się to, jaką funkcjonalność faktycznie wykorzystuje i na jakich danych operuje. Czy obsługuje zgłoszenia serwisowe, a może tworzy ofertę? Zarządza kolejkami? Monitoruje SLA? Jeśli tak – jest w obszarze Dynamics 365, niezależnie od tego, czy robi to przez natywny interfejs, czy przez własnoręcznie napisaną aplikację Canvas. To nie jest interpretacja. To wprost zapisane w warunkach licencyjnych Microsoft.
Czym jest „multiplexing” w licencjonowaniu Microsoft?
Microsoft opisaną wyżej sytuację nazywa multiplexingiem i ma na ten temat bardzo jasne stanowisko: nie można zmniejszać wymagań licencyjnych przez dodanie dodatkowej warstwy między użytkownikiem a produktem. Nieważne czy tą warstwą jest portal internetowy, aplikacja mobilna czy własnoręcznie napisana aplikacja Canvas w Power Apps. Jeśli użytkownik pośrednio korzysta z funkcjonalności Dynamics 365 – jest traktowany tak samo jak użytkownik, który loguje się bezpośrednio.
To zasada, która działa niezależnie od intencji. Można nie wiedzieć, że się ją narusza. Można być przekonanym, że znalazło się sprytne obejście. Audyt weryfikuje fakty, nie zamiary.
O co dokładnie chodzi z tym multiplexing? Restricted tables.
W Dataverse część tabel jest oznaczona jako zastrzeżone dla określonych licencji Dynamics 365. W obszarze serwisowym mowa o tabelach, które są sercem każdego procesu obsługi klienta: Case, Entitlement, SLA, Work Order. W obszarze sprzedażowym lista jest równie konkretna: Opportunity, Quote, Order, Invoice, Lead, czyli dokładnie te tabele, na których opiera się każdy proces sprzedażowy. Użytkownik z licencją Power Apps może co prawda odczytać dane z tych tabel, ale już ich tworzenie, aktualizacja czy usuwanie rekordów wymaga odpowiedniej licencji Dynamics 365. Nie Power Apps Premium tylko Dynamics 365.
I tu pojawia się moment, w którym wiele projektów zaczyna się sypać w fazie analizy licencyjnej. Aplikacja Canvas jest gotowa, wygląda świetnie, działa dokładnie tak jak powinna – a potem ktoś sprawdza, na jakich tabelach operuje, i okazuje się, że cały pomysł na oszczędności licencyjne przestaje trzymać się kupy.
Wróćmy do klienta, z którym rozmawialiśmy w tym tygodniu. Plan zakładał stopniowe zastępowanie Dynamics 365 – zaczynając od procesów serwisowych, kończąc na sprzedażowych. W praktyce oznacza to operowanie na restricted tables z obu obszarów. Czyli de facto na każdej kluczowej tabeli, która w Dynamics 365 ma znaczenie biznesowe.
Mechanizm jest prosty: Microsoft nie patrzy na interfejs. Patrzy na dane. Jeśli twoja aplikacja czyta i zapisuje do tabel, które są częścią licencjonowanego rozwiązania Dynamics 365 – jesteś w obszarze Dynamics 365, niezależnie od tego, jak bardzo twoja aplikacja różni się wyglądem od natywnego CRM.
Dlatego przed podjęciem jakiejkolwiek decyzji architektonicznej warto zadać jedno bardzo konkretne pytanie: na jakich tabelach będzie operować ta aplikacja? Jeśli odpowiedź zawiera Case, Entitlement, SLA, Opportunity, Quote lub Order – rozmowa o licencjach musi się odbyć zanim powstanie pierwsza linia kodu.
Kiedy Power Apps jest bezpiecznym wyborem?
Żeby nie było nieporozumień – nie twierdzę, że Power Apps to zła droga. Wręcz przeciwnie, używamy go regularnie i widzimy, ile wartości można nim dostarczyć.
Tysiące organizacji buduje w Power Apps rozwiązania, które nie mają nic wspólnego z Dynamics 365 – systemy zarządzania flotą, aplikacje HR, rejestry sprzętu, procesy audytowe, narzędzia compliance. I robią to całkowicie legalnie, opierając się na własnych tabelach Dataverse, własnej logice biznesowej i własnych procesach. W takich przypadkach licencja Power Apps Premium w zupełności wystarcza i nikt nie ma do tego żadnych zastrzeżeń.
Granica jest prosta, choć nie zawsze oczywista na pierwszy rzut oka: jeśli aplikacja nie dotyka funkcjonalności ani danych Dynamics 365 – jesteś bezpieczny. Problem zaczyna się w momencie, gdy zaczynasz budować coś, co funkcjonalnie przypomina CRM, korzysta z jego tabel i odtwarza jego procesy – tylko w innym opakowaniu.
Koszt licencji to tylko część równania
Nawet jeśli ktoś znajdzie sposób na rozwiązanie kwestii licencyjnych i zrobi to w pełni zgodnie z zasadami Microsoft, zostaje jeszcze druga strona równania, o której rozmawia się znacznie rzadziej.
Dynamics 365 to nie tylko licencja. To produkt, który Microsoft rozwija od lat i w który inwestuje regularnie – nowe funkcjonalności, aktualizacje bezpieczeństwa, integracje, mechanizmy AI. Kupując licencję, organizacja kupuje też ten rozwój. Gdy decyduje się zbudować własne rozwiązanie, przejmuje za niego pełną odpowiedzialność.
W praktyce oznacza to, że każda nowa potrzeba biznesowa to projekt deweloperski. Każda zmiana procesu to zaangażowanie zespołu. Każda kwestia bezpieczeństwa, kontroli dostępu czy zgodności regulacyjnej leży po stronie organizacji, nie producenta. A funkcjonalności, które w Dynamics 365 pojawiają się w kolejnych aktualizacjach – Copilot, automatyzacja, nowe mechanizmy routingu – we własnej aplikacji trzeba zaprojektować, zbudować i utrzymać samodzielnie.
To nie jest argument przeciwko budowaniu własnych rozwiązań. To argument za liczeniem pełnych kosztów. Widziałam projekty, w których oszczędność na licencjach wynosiła kilkadziesiąt tysięcy złotych rocznie, a koszt utrzymania własnej aplikacji po dwóch latach przekroczył tę kwotę kilkukrotnie. Decyzja, która na papierze wyglądała jak optymalizacja, w praktyce okazała się droższa niż to, od czego próbowano uciec.
Jak podejść do tematu odpowiedzialnie?
Gdy przychodzi do nas klient z takim pomysłem, zadajemy mu kilka pytań. Nie po to, żeby go zniechęcić tylko po to, żeby wspólnie zrozumieć, z czym naprawdę mamy do czynienia.
Pierwsze pytanie jest zawsze o procesy: co dokładnie chcemy obsługiwać i czy te procesy są rzeczywiście unikalne dla tej organizacji, czy po prostu przypominają standardowy Customer Service lub Sales? To pytanie często otwiera oczy, bo wiele organizacji jest przekonanych, że ich procesy są wyjątkowe, a w praktyce Dynamics 365 obsługuje je w standardzie, bez jednej linii customizacji.
Drugie pytanie dotyczy danych: na jakich tabelach będzie operować aplikacja? Własne encje czy standardowe tabele Dynamics 365? To pytanie, jak już pisałam, często kończy dyskusję o oszczędnościach licencyjnych zanim na dobre się zaczęła.
Trzecie pytanie jest najtrudniejsze, bo wymaga odrobiny szczerości: czy rozwiązujemy realny problem biznesowy, czy przede wszystkim próbujemy obniżyć koszty licencji? Jedno i drugie może być słusznym celem, ale gdy optymalizacja kosztów staje się ważniejsza niż architektura i potrzeby biznesowe to często projekty kończą się źle.
I wreszcie pytanie o pieniądze, ale policzone uczciwie. Nie „ile zaoszczędzimy na licencjach”, tylko „ile wyniesie całkowity koszt rozwiązania za pięć lat, wliczając rozwój, utrzymanie, wsparcie i wszystko, co dziś dostajemy w standardzie od Microsoft”. Ta kalkulacja bardzo często zmienia optykę.
Ostatnia rzecz, którą zawsze rekomendujemy przed startem projektu: formalna interpretacja licencyjna. Nie opinia kolegi z branży, nie wpis na LinkedIn, nie założenie że „pewnie jest OK”. Weryfikacja z Microsoft lub wyspecjalizowanym partnerem licencyjnym. To krok, który kosztuje najmniej ze wszystkich i który najczęściej jest pomijany.
Podsumowanie
Wróćmy do klienta, od którego zaczął się ten artykuł.
Nie odradziliśmy mu Power Apps. Nie powiedzieliśmy, że pomysł jest zły. Powiedzieliśmy, że zanim podejmie decyzję, musi odpowiedzieć na kilka konkretnych pytań – o procesy, o tabele, o pełne koszty i o interpretację licencyjną. Bo jeśli te odpowiedzi są dobre, Power Apps może być świetnym wyborem. Jeśli nie są, zmiana interfejsu przy zachowaniu tych samych danych i procesów nie jest optymalizacją. Jest ryzykiem, które ujawni się najpóźniej przy audycie.
Doradzanie klientom, żeby zastępowali Dynamics 365 własną aplikacją Canvas, brzmi atrakcyjnie na slajdzie. W praktyce wymaga czegoś więcej niż technicznej wykonalności. Wymaga uczciwej analizy licencyjnej, pełnego rachunku kosztów i świadomości, że Microsoft nie patrzy na to, jak wygląda aplikacja, tylko na to, czym ona jest i na jakich danych działa.
Dobre rozwiązanie nie musi być najtańsze na starcie. Musi być uczciwie policzone, zgodne z zasadami producenta i gotowe na to, żeby działać za pięć lat, bez niespodzianek.