Audyt przedwdrożeniowy Dynamics 365: co sprawdzić, zanim podpiszesz umowę.

Audyt przedwdrożeniowy Dynamics 365 to uporządkowane prześwietlenie firmy, jej procesów, danych i integracji, zanim rusza projekt wdrożenia. Jego zadaniem nie jest pokazać, że system „da radę", tylko odpowiedzieć na trudniejsze pytanie: ile Twoja konkretna organizacja zapłaci za dojście do stanu docelowego i gdzie po drodze czają się niespodzianki. To różnica między prezentacją handlową a diagnozą. Warto zacząć od liczby, która dobrze ustawia perspektywę. W badaniu Panorama Consulting ponad jedna czwarta firm przekroczyła budżet projektu ERP, a najczęstszym powodem były dodatkowe potrzeby technologiczne, które wyszły na jaw dopiero w trakcie wdrożenia. Innymi słowy, największe przekroczenia nie biorą się z tego, że ktoś źle napisał kod. Biorą się z tego, że coś nie zostało sprawdzone, zanim podpisano zakres i cenę. Audyt przedwdrożeniowy przesuwa moment odkrycia tych rzeczy o kilka miesięcy do przodu, kiedy zmiana planu kosztuje rozmowę, a nie renegocjację kontraktu.

Z perspektywy zarządu istota tej diagnozy jest finansowa: audyt wycenia niepewność, zanim zostanie ona zaszyta w cenie kontraktu jako bufor, którego już nie odzyskasz. Dostawca, który nie zna Twoich danych, musi ten bufor doliczyć, a Ty płacisz go niezależnie od tego, czy ryzyko się zmaterializuje. Każda niewiadoma zdjęta przed podpisem to zatem nie tylko mniejsze ryzyko, ale też twardsza podstawa do zawężenia tego narzutu, bo w dużej organizacji nawet kilkuprocentowa różnica w wycenie ryzyka przekracza koszt samego audytu o rząd wielkości. Dlatego audyt najlepiej czytać nie jako wydatek na starcie, lecz jako pierwszą decyzję inwestycyjną projektu, która porządkuje wszystkie następne.

‍

Po co komu audyt, skoro było już demo

To najczęstsze zastrzeżenie i zarazem najlepszy punkt wyjścia. Demo pokazuje, że oprogramowanie potrafi wykonać daną operację na czystych, przygotowanych danych. Audyt sprawdza coś zupełnie innego: czy Twoje dane, Twoje procesy i Twoje otoczenie systemowe pozwolą osiągnąć ten sam efekt, w jakim czasie i jakim kosztem. Demo odpowiada na pytanie „czy system to umie". Audyt odpowiada na pytanie „czy my to udźwigniemy i za ile". Ta różnica przekłada się na pieniądze w bardzo konkretny sposób. Podczas prezentacji nie widać, że połowa Twoich indeksów magazynowych ma niespójne jednostki miary, że dział sprzedaży od lat prowadzi rabaty w osobnym arkuszu, a integracja z bankiem opiera się na pliku, którego format nikt już nie utrzymuje. Każda z tych rzeczy staje się osobnym zadaniem projektowym. Audyt wyłapuje je wcześnie i wycenia, zamiast pozwolić im wypłynąć w połowie wdrożenia jako „drobna zmiana zakresu".

Za tą asymetrią stoi prosty mechanizm: na demie lepiej poinformowany jest dostawca, bo to on wie, czego prezentacja celowo nie pokazuje. W trakcie wdrożenia ta przewaga zamienia się w przewagę negocjacyjną: gdy zespół jest już zaangażowany, a termin startu ogłoszony w organizacji, koszt wyjścia z projektu rośnie na tyle, że każda „drobna zmiana zakresu" bywa akceptowana niemal automatycznie. To klasyczna pułapka kosztu utopionego, w której zamawiający płaci nie za wartość zmiany, lecz za brak alternatywy. Audyt rozbraja ją, przenosząc odkrycie tych pozycji na moment, w którym zamawiający wciąż ma wybór i pełną siłę przetargu. Drugi, rzadziej dostrzegany efekt dotyczy adopcji: procesy prowadzone dziś w arkuszach nie znikną same, lecz przeniosą się do nowego środowiska jako obejścia, jeśli nie rozstrzygnie się ich przed konfiguracją.

‍

Audyt jako dźwignia negocjacyjna na zakres i cenę

Największa wartość audytu przedwdrożeniowego ujawnia się nie w samym raporcie, lecz w asymetrii informacji, którą ten raport likwiduje. Zanim powstanie diagnoza, to dostawca dysponuje pełniejszym obrazem tego, co w projekcie jest trudne, kosztowne i ryzykowne, a zamawiający kontraktuje w ciemno, opierając się na optymistycznych założeniach oferty. Audyt odwraca ten układ sił jeszcze przed podpisem. Kiedy siadasz do rozmowy o cenie z własną, niezależną listą interfejsów, z policzonym długiem danych i z rejestrem fit-gap, przestajesz negocjować procentowy rabat od kwoty, której podstaw nie rozumiesz, a zaczynasz kwestionować pojedyncze pozycje wyceny. Dyskusja przesuwa się z poziomu „proszę o pięć procent w dół" na poziom „ta funkcja jest w standardzie modułu, więc nie przyjmuję jej jako osobnej pozycji roboczogodzinowej".

Druga dźwignia to sposób rozliczenia. Dostawca, który nie zna Twoich danych, wycenia projekt z buforem na niepewność, a ten bufor płacisz niezależnie od tego, czy ryzyko się zmaterializuje. Im więcej niewiadomych zdejmie audyt, tym węższy staje się uzasadniony bufor i tym łatwiej przesunąć część zakresu z modelu time and material na cenę stałą, bo obie strony wiedzą, co dokładnie jest do zrobienia. Trzecia dźwignia dotyczy struktury umowy: ustalenia audytu można wprost przekuć na bramki milowe i kryteria odbioru, w których płatność zależy od zmierzalnego rezultatu, a nie od upływu czasu. Bez audytu negocjujesz cenę; z audytem negocjujesz ryzyko, a to ono decyduje o końcowym rachunku, bo pozycje ukryte w buforze rzadko wracają do zamawiającego, gdy okazują się zbędne. Ta obserwacja ma wymiar systemowy: bufor niepewności jest asymetryczny, bo dostawca inkasuje go przy podpisie, a odzyskuje się z niego najwyżej ułamek.

‍

Co prześwietla audyt przedwdrożeniowy Dynamics 365

Dobry audyt schodzi głębiej niż lista życzeń biznesu. Prześwietla sześć obszarów, w których zwykle kryją się ukryte koszty i ryzyka:

• Procesy. Firmy zwykle opisują procesy tak, jak powinny wyglądać. Audyt szuka procesów faktycznych, tych prowadzonych obok systemu: obejść w arkuszach, ręcznych akceptacji na mailu, wyjątków, które „zawsze się jakoś załatwiało". To one decydują o tym, ile konfiguracji i zmian w organizacji pochłonie projekt. Mapa procesów as-is kontra to-be nie jest formalnością — to pierwsza wersja zakresu.
• Dane. Jakość danych podstawowych to najczęściej niedoceniany czynnik ryzyka: zdublowani kontrahenci, indeksy bez spójnej struktury, niekompletne kartoteki, brakujące kody podatkowe czy numery NIP, rozjeżdżające się struktury BOM w produkcji. Tego nie widać na demo, a potrafi wywrócić harmonogram migracji. Audyt kwantyfikuje ten dług danych, zanim stanie się on problemem w środowisku produkcyjnym, i pozwala zdecydować, co czyścimy przed migracją, a co świadomie zostawiamy.
• Integracje. Dynamics 365 rzadko stoi sam. Łączy się z systemem produkcyjnym MES, z magazynem WMS, z wymianą dokumentów EDI, z bankowością, z platformą e-commerce, z KSeF. Audyt inwentaryzuje wszystkie te styki i zamienia mgliste „to się później zintegruje" na policzalną listę interfejsów, z których każdy ma swój koszt, ryzyko i właściciela. Skala takiej mapy potrafi zaskoczyć: u producentów pracujących na wielu modułach, jak w projekcie S&P Reinforcement, gdzie ANEGIS wdrożył Microsoft Dynamics 365 obejmujący finanse, produkcję i logistykę, liczba połączeń między obszarami przesądza o złożoności projektu.
• Analiza fit-gap. To serce audytu. Każde wymaganie trafia do jednej z trzech szuflad: standard, konfiguracja albo kod. Ten podział wyznacza budżet mocniej niż liczba użytkowników. Właśnie tu siedzą niedopasowania, które wychodzą na jaw za późno i rozsadzają koszty; rzetelna analiza fit-gap wyciąga je na stół na etapie, gdy decyzja „robimy inaczej niż zawsze, żeby zostać przy standardzie" jest jeszcze tania.
• Licencje i koszt utrzymania. Model licencyjny Dynamics 365 nie jest płaski: inaczej rozlicza się użytkownika pełnego, inaczej team membera, inaczej licencje dołączane do podstawowej. Dobór tej mieszanki przed podpisaniem umowy potrafi wyraźnie zmienić rachunek za subskrypcję. Audyt układa profile użytkowników i przypisuje im właściwy typ licencji, zanim liczba miejsc zostanie zamrożona. Punktem odniesienia jest cennik Microsoft, gdzie Dynamics 365 Finance zaczyna się od 182 euro za użytkownika miesięcznie, ale prawdziwą stawkę wyznacza dopiero struktura zespołu, nie cena katalogowa.
• Zgodność i lokalizacja. System z globalnego demo nie zawsze pokrywa polskie obowiązki od ręki. Audyt sprawdza, czy standardowa lokalizacja obsłuży KSeF, kolejne wersje JPK i mechanizm podzielonej płatności bez dobudowywania osobnych rozszerzeń. Luka odkryta po starcie oznacza nie tylko koszt, ale i ryzyko niezgodności z prawem w konkretnym terminie ustawowym.

Te obszary są przy tym sprzężone kosztowo: wymaganie zepchnięte do kodu podnosi nie tylko pracochłonność wdrożenia, ale i koszt utrzymania oraz retestów przy każdej aktualizacji, także tej wymuszonej przez polskie regulacje.

‍

Taksonomia ryzyka przedwdrożeniowego

Ryzyko wdrożeniowe warto rozłożyć na pięć rozłącznych kategorii, bo każda z nich reaguje na inne działanie i każda inaczej obciąża budżet:

• Dopasowanie procesów — dystans między tym, jak firma pracuje, a tym, co zakłada standard systemu.
• Jakość danych — stan kartotek, indeksów i struktur, które trzeba przenieść.
• Złożoność integracji — mierzona nie liczbą systemów, lecz liczbą i zmiennością interfejsów między nimi.
• Gotowość organizacyjna — zdolność zespołu do przyjęcia zmiany, obecność właściciela biznesowego z mandatem decyzyjnym oraz dostępność ekspertów dziedzinowych obok ich bieżących obowiązków.
• Prawidłowy dobór licencji — ryzyko przepłacenia lub niedoszacowania uprawnień.

Wartość tej taksonomii polega na tym, że pozwala priorytetyzować: nie każde ryzyko trzeba domknąć przed startem, ale każde trzeba świadomie zaadresować lub świadomie odłożyć z zapisanym uzasadnieniem. Ta sama siatka pomaga czytać sygnały ostrzegawcze, które statystycznie poprzedzają nieudane projekty. Brak jednego właściciela biznesowego i rozmycie decyzji między działami to najczęstszy predyktor kłopotów. Kolejne to lista wymagań pisana jako „ma działać jak dotychczas", masa życzeń oznaczonych jako krytyczne bez hierarchii, sponsor, który nie potrafi wskazać trzech mierzalnych celów projektu, oraz dane, do których żaden dział nie chce się przyznać jako właściciel. Osobną flagą jest terminarz podyktowany datą wygaśnięcia poprzedniego systemu, a nie gotowością organizacji, bo taka presja spycha etap analizy na koniec kolejki.

Audyt nie usuwa tych ryzyk, ale nazywa je na etapie, gdy reakcja jest tania, i zamienia rozproszone przeczucia w rejestr, z którego zarząd podejmuje decyzje. Wartość takiego rejestru polega na tym, że każdemu ryzyku przypisuje się właściciela, prawdopodobieństwo i wpływ na budżet, więc zarząd rozmawia o wielkościach, nie o wrażeniach.

‍

Asymetria kosztów: audyt kontra przeskalowanie projektu

Ekonomika audytu opiera się na jednej nierówności: koszt sprawdzenia jest o rząd wielkości niższy niż koszt naprawy tego, czego nie sprawdzono. Audyt przedwdrożeniowy to zwykle wydatek liczony w kilku procentach wartości wdrożenia, często mieszczący się w kilkudziesięciu tysiącach złotych, podczas gdy przeskalowanie zakresu w biegnącym projekcie to koszt liczony w setkach tysięcy, a w większych organizacjach w milionach. Mechanizm tej asymetrii opisuje zasada znana z inżynierii jakości: koszt usunięcia wady rośnie mniej więcej dziesięciokrotnie na każdym kolejnym etapie, na którym wada pozostaje niewykryta. Błąd w założeniach, który na etapie analizy kosztuje godzinę rozmowy, na etapie konfiguracji kosztuje przeprogramowanie, a po starcie produkcyjnym kosztuje przestój, korektę danych i utracone zaufanie użytkowników do nowego systemu.

Do tego dochodzi koszt, którego nie widać w fakturach: opóźnienie. Każdy miesiąc poślizgu to nie tylko dodatkowe roboczogodziny zespołu wdrożeniowego, ale też odroczone korzyści z systemu i przedłużone utrzymanie starego środowiska, które miało zostać wyłączone, wraz z jego licencjami i personelem. Kiedy zestawi się te wielkości, pytanie „czy stać nas na audyt" odwraca się: przy złożonym projekcie właściwe pytanie brzmi, czy stać nas na wejście w wielomiesięczne wdrożenie bez zdjęcia najdroższych niewiadomych. Cytowane badanie Panorama Consulting pokazuje, że to właśnie późno odkryte potrzeby technologiczne, a nie błędy programistyczne, najczęściej rozsadzają budżety. W tym ujęciu audyt jest niedrogim ubezpieczeniem od najkosztowniejszej klasy błędów, tych odkrywanych już po zabetonowaniu zakresu i ceny. Do tej kalkulacji zarząd powinien doliczyć składnik spoza faktur: koszt utraconej wiarygodności projektu. Wdrożenie ślizgające się po terminie wypala kapitał zaufania sponsora, a odbudowa tej gotowości bywa droższa niż korekta techniczna.

‍

Punktowa ocena jakości danych i jej wpływ na harmonogram

Jakość danych przewiduje termin wdrożenia lepiej niż liczba modułów, a mimo to bywa kwitowana jednym zdaniem, że „dane są w porządku". Warto zamienić to wrażenie na wynik liczbowy. Sprawdzoną metodą jest ocena każdej domeny danych, czyli kontrahentów, indeksów, kartotek materiałowych, struktur BOM czy cenników, według kilku wymiarów: kompletności, unikalności, zgodności z regułami formatu, spójności między systemami i aktualności. Każdy wymiar dostaje ocenę, na przykład w skali od jednego do pięciu, a średnia ważona daje profil ryzyka migracji dla całej organizacji. Ten prosty zabieg ma dwie konsekwencje. Po pierwsze, ujawnia, że problem rzadko rozkłada się równomiernie: zwykle jedna lub dwie domeny ciągną cały wynik w dół i to na nich trzeba skupić czyszczenie, zamiast rozkładać wysiłek płasko na wszystko.

Po drugie, przekłada się wprost na harmonogram, bo migracja danych o niskim wyniku wymaga iteracji: pierwszego ładowania próbnego, listy błędów, poprawek po stronie źródła i ponownego ładowania, a każda taka pętla to tygodnie kalendarza, nie godziny. Dlatego projekt z pięcioma modułami i uporządkowanymi danymi startuje szybciej niż projekt z dwoma modułami i kartotekami, których nikt nie porządkował od dekady. Ocena punktowa pozwala też podjąć świadomą decyzję ekonomiczną: co czyścimy przed migracją, co przenosimy w stanie zastanym i akceptujemy, a co archiwizujemy i w ogóle nie migrujemy. Bez takiej oceny ta decyzja zapada przypadkiem, zwykle w najgorszym momencie, czyli podczas pierwszego ładowania na środowisko produkcyjne, kiedy każda zmiana planu uderza już w termin startu. Dobrą praktyką jest powtórzenie tej oceny tuż przed migracją, bo różnica wobec pomiaru z audytu pokazuje, czy czyszczenie danych posuwa się do przodu, czy tylko figuruje w harmonogramie.

‍

Kto i kiedy powinien go zamówić

Audyt przedwdrożeniowy zwraca się najbardziej tam, gdzie stawka projektu jest wysoka, a organizacja złożona: wiele spółek, produkcja, rozproszone magazyny, sprzedaż w kilku kanałach, obecność w kilku krajach. Im więcej styków i wyjątków, tym większa szansa, że coś istotnego umknie w standardowej ofercie. Kryterium decydujące nie jest sama wielkość firmy, lecz liczba niezależnych decyzji do uzgodnienia między spółkami i działami, zanim powstanie jeden zakres. Dwie spółki o zbliżonych obrotach potrafią różnić się złożonością o rząd wielkości, jeśli jedna pracuje na jednym procesie sprzedaży, a druga na kilkunastu wyjątkach obsługiwanych ręcznie. Najlepszy moment to okno między decyzją „idziemy w Dynamics 365" a podpisaniem umowy na wdrożenie. Wtedy wyniki audytu wprost wpływają na zakres, harmonogram i cenę, bo jeszcze nic nie zostało zabetonowane.

Audyt zamówiony po podpisie też ma wartość, ale zmienia rolę: z narzędzia negocjacji zakresu staje się planem ograniczania ryzyka już w biegnącym projekcie. Jeśli rozważasz szersze przygotowanie do wdrożenia Dynamics 365 albo migracji ze starszej wersji systemu, audyt jest naturalnym pierwszym krokiem obu tych ścieżek. Osobną kwestią jest napięcie między terminem podyktowanym końcem wsparcia poprzedniego systemu a gotowością organizacji. Gdy datę startu wyznacza wygaśnięcie licencji starego ERP, a nie stan przygotowania danych i procesów, analiza zwykle ląduje na końcu kolejki i to ona jest ścinana pod presją czasu. Audyt wykonany wcześnie ujawnia tę rozbieżność, gdy można jeszcze albo przyspieszyć czyszczenie danych, albo świadomie przesunąć termin, zamiast odkrywać brak gotowości w tygodniu przejścia na produkcję.

‍

Kto powinien być właścicielem audytu: biznes czy IT

Odpowiedź na pytanie o właściciela audytu przesądza o jego wyniku bardziej niż dobór metody. Kiedy audyt prowadzi wyłącznie dział IT, diagnoza ciąży w stronę architektury, integracji i infrastruktury, a najdroższe ryzyko, czyli dystans między standardem systemu a sposobem pracy biznesu, bywa niedoszacowane, bo nikt z mandatem procesowym nie siedzi przy stole. Kiedy audyt prowadzi wyłącznie biznes, powstaje odwrotna luka: lista życzeń bez oceny wykonalności i kosztu technicznego, w której wszystko wydaje się łatwe. Najlepsze wyniki daje układ, w którym właścicielem jest biznes, konkretny sponsor z uprawnieniem do rozstrzygania sporów między działami, a IT pełni rolę współgospodarza odpowiadającego za wykonalność i za spójność z resztą krajobrazu systemowego. Ten sam podział warunkuje późniejsze wdrożenie, bo projekt bez właściciela biznesowego z mandatem to jeden z najsilniejszych predyktorów porażki.

Przy okazji warto rozróżnić dwa instrumenty, które bywają mylone. Audyt odpowiada na pytanie o zakres, koszt i ryzyko całego przedsięwzięcia i jest właściwym narzędziem, gdy niepewność dotyczy dopasowania procesów i danych. Proof of concept odpowiada na węższe pytanie, czy konkretny, ryzykowny mechanizm w ogóle zadziała w danym środowisku, i ma sens tam, gdzie ryzyko jest technologiczne i punktowe. Mylenie ich kosztuje: firmy budują kosztowny prototyp, gdy potrzebowały diagnozy procesów, albo zamawiają ogólny audyt, gdy jedno nietypowe wymaganie wołało o test na żywym systemie. Do domeny audytu należy również przegląd licencji przed odnowieniem subskrypcji, który pozwala odzyskać nadmiarowo przydzielone miejsca i uporządkować strukturę uprawnień, zanim umowa zostanie przedłużona na kolejny okres i zamrozi nadpłatę na następne lata. Dobrym testem podziału ról jest pytanie, kto podpisze się pod decyzją o zniknięciu danego wyjątku procesowego.

‍

Co dostajesz na wyjściu

Wartość audytu mierzy się tym, czy da się na jego podstawie podejmować decyzje. Rzetelny raport zamyka się kilkoma konkretami, a nie ogólną oceną „system pasuje". Test praktyczny jest prosty: jeśli po lekturze raportu zarząd wciąż nie umie wskazać, które pozycje wyceny może zakwestionować, a których nie, dokument jest opisem, nie narzędziem decyzyjnym. Dobry raport ma strukturę, która daje się przełożyć wprost na warunki umowy, bo każdy zidentyfikowany element zakresu powinien mieć przypisany koszt, właściciela i moment, w którym trafia do harmonogramu, tak aby dało się z niego zbudować bramki milowe i kryteria odbioru. Rejestr fit-gap staje się wtedy podstawą wyceny pozycja po pozycji, ocena jakości danych wyznacza liczbę iteracji migracji, a mapa integracji zamienia się w listę odrębnych zleceń, z których każde można kontraktować osobno.

Co istotne, ten sam dokument służy później jako punkt odniesienia przy odbiorach: jeśli w trakcie wdrożenia pojawia się „nowe" wymaganie, raport pozwala rozstrzygnąć, czy było ono znane i wycenione, czy faktycznie wykracza poza uzgodniony zakres, co przesądza, która strona ponosi jego koszt. Dla zarządu praktyczną konsekwencją jest to, że raport pozwala rozłożyć wydatek w czasie: część zakresu można uruchomić od razu, a część świadomie odłożyć do kolejnej fazy, bez ryzyka, że odłożone elementy okażą się później blokujące. Dopiero taki zestaw pozwala rozmawiać o cenie i harmonogramie w oparciu o wiedzę, a nie o założenia. To także dobra baza pod późniejszą optymalizację systemu, bo obszary długu technologicznego i danych są już nazwane. Poniższe zestawienie porządkuje elementy, które powinny znaleźć się w rzetelnym raporcie z audytu:

‍

Jak wybrać firmę do audytu Dynamics 365

Kluczowe kryterium jest jedno: audyt ma sens wtedy, gdy prowadzi go zespół, który wdrażał Dynamics 365 w praktyce, a nie tylko czytał o nim w dokumentacji. Tylko ktoś, kto sam przeszedł kilka projektów, rozpozna wzorce ryzyka, zanim się zmaterializują, i odróżni wymaganie, które warto obsłużyć standardem, od takiego, które faktycznie potrzebuje kodu. Warto też pytać wprost o doświadczenie z polską lokalizacją i o to, czy audytujący będzie później odpowiadał za wdrożenie, bo to zmienia jakość i szczerość diagnozy. Wybierając firmę do audytu Dynamics 365, warto świadomie rozważyć kwestię, która na pierwszy rzut oka wygląda na konflikt interesów: czy ten sam podmiot powinien audytować i wdrażać. Argument przeciw jest oczywisty, bo audytor liczący na kontrakt wdrożeniowy ma pokusę, by diagnozę nagiąć pod własną ofertę.

Argument za bywa jednak silniejszy w złożonych projektach: zespół, który weźmie odpowiedzialność za wdrożenie, ma bodziec, by nie przeoczyć ryzyka, które później sam musiałby naprawić na własny koszt. Rozstrzygnięcie tej pokusy nie leży w wyborze między jednym a drugim modelem, lecz w konstrukcji umowy, bo jeśli audyt kończy się mierzalnymi produktami, czyli rejestrem fit-gap, oceną jakości danych i mapą integracji, to jego jakość da się ocenić niezależnie od tego, kto poprowadzi wdrożenie, a zamawiający zachowuje prawo do zmiany wykonawcy bez utraty dorobku analizy. Drugim filtrem są referencje z projektów o podobnej złożoności i branży, najlepiej takich, w których dało się sprawdzić, czy pierwotne szacunki zakresu i budżetu utrzymały się do startu produkcyjnego. Trzecim jest skład zespołu: czy diagnozę prowadzą konsultanci z doświadczeniem procesowym i znajomością polskiej lokalizacji, czy wyłącznie architekci techniczni.

ANEGIS jako Microsoft Solutions Partner w obszarze Business Applications ma za sobą jedno z największych wdrożeń Dynamics na świecie i prowadzi zarówno audyty, jak i pełne projekty wdrożeniowe, co skraca drogę od diagnozy do decyzji. Jeśli zastanawiasz się, czy Twój projekt jest gotowy do startu i gdzie leżą jego najdroższe ryzyka, porozmawiajmy o audycie przed wdrożeniem Dynamics 365. Kilka godzin rozmowy o procesach, danych i integracjach zwykle pokazuje więcej niż niejedna prezentacja.

‍

‍

‍

‍