Jak wybrać firmę do wdrożenia Dynamics 365: kryteria, koszt i etapy (2026)

Wybór firmy wdrożeniowej waży więcej niż wybór samego systemu. Dynamics 365 u dwóch różnych partnerów da dwa różne rezultaty, ponieważ o powodzeniu projektu decyduje nie licencja, lecz to, kto mapuje Twoje procesy, migruje dane i utrzymuje system po starcie.

Decyzja o partnerze jest w praktyce nieodwracalna w horyzoncie kilku lat: raz przyjęty model danych, architektura integracji i sposób odwzorowania procesów tworzą zależność, której późniejsza zmiana kosztuje wielokrotność pierwotnej oszczędności. Dlatego ocenę partnera warto prowadzić jak ocenę wieloletniego kontraktu strategicznego, a nie jak zakup usługi jednorazowej.

Poniżej odpowiadamy na pytania, które najczęściej zadają osoby odpowiedzialne za ten wybór: jak rozpoznać dobrego partnera, ile realnie kosztuje wdrożenie, jak wygląda proces i jak zaplanować rollout w firmie z wieloma oddziałami.

‍

Najważniejsze fakty w skrócie:

• Kogo wybrać. Certyfikowanego partnera Microsoft (Solutions Partner for Business Applications) z doświadczeniem w Twojej branży i własnym zespołem konsultantów, który odpowiada za projekt również po go-live, a nie z rozproszonym łańcuchem podwykonawców.

• Ile to kosztuje. Całkowity koszt to suma trzech składników: licencji Microsoft (Dynamics 365 Finance od 182 € za użytkownika miesięcznie), prac wdrożeniowych wycenianych indywidualnie oraz utrzymania po starcie. Rzetelną kwotę daje analiza przedwdrożeniowa, a nie cennik.

• Ile trwa i jak przebiega. Wdrożenie prowadzi się w sześciu fazach (analiza, projekt rozwiązania, konfiguracja i rozwój, migracja danych, testy i szkolenia, go-live z opieką), a cały cykl zajmuje zwykle od kilku do kilkunastu miesięcy.

• Co decyduje o cenie. Liczba i złożoność integracji, stopień customizacji względem standardu, liczba lokalizacji oraz zakres migracji danych ze starszych systemów, zwłaszcza z Dynamics AX.

• Na co patrzeć poza ceną. Pełny koszt posiadania (TCO), a nie samą stawkę licencji: zarządzanie zmianą, migrację danych, utrzymanie integracji oraz rozwój systemu w drugiej fali optymalizacji po go-live.

• Rollout w wielu oddziałach. Najpierw wspólny model bazowy, potem pilot i kolejne fale

‍

Partner wdrożeniowy Dynamics 365: jak wybrać właściwego?

Najlepszą firmę do wdrożenia Dynamics 365 rozpoznasz po trzech rzeczach: aktualnym statusie Microsoft Solutions Partner (Business Applications), udokumentowanym doświadczeniu w Twojej branży oraz własnym zespole konsultantów, który odpowiada za projekt również po go-live. Certyfikacja potwierdza kompetencje, doświadczenie branżowe skraca analizę i ogranicza ryzyko, a własny zespół (zamiast podwykonawców) zapewnia ciągłość i odpowiedzialność za rezultat. „Najlepszy" partner to nie ten z najgłośniejszą marką, lecz ten najlepiej dopasowany do Twojego projektu według poniższych kryteriów.

Warto jednak spojrzeć na te kryteria głębiej, niż sugeruje ich lista. Certyfikacja jest warunkiem koniecznym, lecz niewystarczającym: potwierdza spełnienie progu formalnego, ale nie mówi nic o tym, czy konkretni ludzie przypisani do Twojego projektu przepracowali podobny scenariusz. Doświadczenie branżowe ma sens tylko wtedy, gdy dotyczy zbliżonego modelu operacyjnego, a nie samej nazwy sektora; producent kontraktowy i producent na magazyn działają w tej samej branży, lecz mają odmienne procesy planowania, kosztowania i rozliczeń.

Własny zespół konsultantów przekłada się na przewidywalność, ponieważ eliminuje ryzyko utraty wiedzy w momencie, gdy podwykonawca kończy kontrakt i wychodzi z projektu wraz z nieudokumentowaną znajomością rozwiązania. Dla kadry zarządzającej istotne jest także to, kto ponosi odpowiedzialność kontraktową za rezultat: rozproszony łańcuch podwykonawców rozmywa tę odpowiedzialność i utrudnia egzekwowanie zobowiązań.

Ocena partnera powinna więc obejmować nie tylko obecność wymaganych statusów, lecz również strukturę zespołu, rotację kadr, sposób dokumentowania decyzji projektowych oraz gotowość do przyjęcia jednoznacznej odpowiedzialności za dowiezienie zakresu. Dodatkowym, często pomijanym wymiarem jest dopasowanie kulturowe i sposób komunikacji: partner, który potrafi rozmawiać jednocześnie językiem procesu biznesowego i językiem technologii, znacząco skraca czas uzgodnień i ogranicza ryzyko nieporozumień, które w projektach ERP przekładają się wprost na koszt i harmonogram.

Warto ocenić także dojrzałość partnera w zarządzaniu projektem, czyli sposób raportowania postępu, transparentność w komunikowaniu ryzyk oraz gotowość do prowadzenia trudnych rozmów, zanim problem urośnie.

‍

‍

Praktyczna wskazówka: poproś o referencje projektów o skali zbliżonej do Twojej i zapytaj wprost, kto realizował prace, konsultanci partnera czy podwykonawcy.

To jedno pytanie odsiewa większość ryzykownych ofert, lecz weryfikację referencji warto pogłębić, ponieważ przejrzenie listy logotypów znanych marek daje złudne poczucie bezpieczeństwa i niewiele mówi o zdolności partnera do dowiezienia Twojego projektu. Logotyp potwierdza jedynie, że doszło do współpracy, nie ujawnia natomiast ani jej zakresu, ani przebiegu, ani tego, kto po stronie dostawcy realnie wykonał prace.

Wartościowa weryfikacja polega na rozmowie z klientem referencyjnym o zbliżonym profilu, prowadzonej wokół pytań, które odsłaniają zachowanie partnera w sytuacjach trudnych: co poszło niezgodnie z planem i jak partner zareagował, czy dotrzymano budżetu i harmonogramu oraz jak wyglądała współpraca w fazie utrzymania, gdy pierwotny entuzjazm opada. Z tym wiąże się pułapka najtańszej oferty.

Najniższa cena wdrożenia niemal zawsze kryje koszt, który ujawnia się później: w postaci pominiętej lub skróconej analizy, oszczędności na testach, mniej doświadczonego zespołu, przenoszenia prac na podwykonawców albo rozwiązania zbudowanego szybko i tanio, lecz kosztownego w utrzymaniu i podatnego na problemy przy aktualizacjach. Ukryty koszt najtańszej oferty rzadko znika, zwykle jedynie przesuwa się w czasie i przenosi z fazy inwestycyjnej do operacyjnej, gdzie jest trudniejszy do kontroli i mniej widoczny dla osób, które podejmowały pierwotną decyzję.

Dojrzała ocena ofert polega więc na porównywaniu nie ceny uruchomienia, lecz oczekiwanego kosztu i ryzyka w całym cyklu życia rozwiązania. Warto też potraktować proces wyboru jako element zarządzania ryzykiem korporacyjnym: ustalić z góry, które kompetencje muszą pozostać po stronie organizacji, oraz porównać co najmniej dwóch partnerów nie po cenie, lecz po jakości pytań i gotowości do wskazania ryzyk, o których sam klient jeszcze nie pomyślał.

‍

Jak rozpoznać certyfikowanego partnera Microsoft

Certyfikowanego partnera Microsoft potwierdzisz przez oznaczenie „Microsoft Solutions Partner". Od października 2022 zastąpiło ono dawne statusy Gold i Silver, oparte na kompetencjach (competencies). Aktualny status i specjalizacje partnera sprawdzisz w oficjalnym katalogu Microsoft, a kompetencje zespołu, prosząc o certyfikaty konkretnych konsultantów przypisanych do Twojego projektu.

Dla decydenta ważne jest zrozumienie logiki nowego modelu: obecny status jest wskaźnikiem dynamicznym, ponieważ Microsoft ocenia partnerów w oparciu o wyniki, umiejętności zespołu i skalę realizowanych wdrożeń, a nie o jednorazowo zdobyty tytuł. Oznacza to, że partner utrzymujący status Solutions Partner for Business Applications wykazuje bieżącą aktywność w ekosystemie, a nie jedynie historyczne osiągnięcia. Rozróżnienie to ma znaczenie praktyczne, ponieważ kompetencje w obszarze Dynamics 365 dezaktualizują się szybciej niż w wielu innych technologiach; platforma jest rozwijana w modelu ciągłych aktualizacji, a wiedza sprzed kilku lat może nie odpowiadać obecnym możliwościom systemu.

Weryfikując partnera, warto więc odróżnić dwie warstwy: formalny status organizacji oraz realne, aktualne kompetencje osób, które zasiądą przy Twoim projekcie. Ta druga warstwa jest trudniejsza do sprawdzenia, ale ważniejsza, ponieważ to konsultanci, a nie logotypy, projektują rozwiązanie i podejmują setki decyzji wpływających na jego jakość.

Rozsądnym postępowaniem jest poproszenie o imienny skład zespołu, jego doświadczenie w podobnych wdrożeniach oraz o informację, jaka część prac zostanie wykonana przez ten właśnie zespół, a jaka mogłaby zostać przekazana na zewnątrz w razie spiętrzenia projektów u dostawcy. Warto również zapytać o dostępność kluczowych konsultantów w czasie, ponieważ najlepsi specjaliści bywają rozdzieleni między kilka projektów, a ich realne zaangażowanie w Twój projekt może odbiegać od deklaracji ofertowej.

Dla decydenta praktyczny sygnał jakości stanowi to, czy partner potrafi wskazać konkretne osoby i ich role, czy operuje wyłącznie ogólnymi zapewnieniami o kompetencjach organizacji jako całości.

Na co zwrócić uwagę przy weryfikacji:

• Rodzaj oznaczenia: dla wdrożeń ERP i CRM istotny jest Solutions Partner for Business Applications, a nie ogólne partnerstwo Microsoft.
• Specjalizacje: dodatkowe „specializations" potwierdzają wąską ekspertyzę (np. w obszarze Finance czy Supply Chain).
• Certyfikaty konsultantów: liczba i aktualność certyfikatów osób, które realnie będą pracować przy projekcie.
• Historia i referencje: nagrody i miejsca w rankingach partnerskich Microsoft to zewnętrzne potwierdzenie skali.

Dla porównania: ANEGIS ma status Microsoft Solutions Partner (Business Applications), historycznie także Microsoft Gold Partner, zespół ponad 200 certyfikowanych ekspertów Microsoft, a w rankingu partnerów Microsoft w Polsce zajął 3. miejsce w kategorii Dynamics 365 Finance & Operations i Customer Engagement, z wyróżnieniem za wdrożenia ERP w sektorze produkcyjnym.

Status i pozycja w rankingu są sygnałami zewnętrznymi, ale ich wartość dla decydenta polega na tym, że są weryfikowalne u niezależnego podmiotu, jakim jest Microsoft, a nie oparte wyłącznie na deklaracjach dostawcy. W praktyce warto zestawiać takie sygnały z bezpośrednim wywiadem u klientów referencyjnych, ponieważ dopiero ich połączenie daje wiarygodny obraz.

Certyfikacja mówi o kompetencji technicznej, ranking o skali i uznaniu w ekosystemie, natomiast referencja o tym, jak partner zachowuje się w sytuacjach trudnych: przy zmianie zakresu, opóźnieniu, konflikcie priorytetów czy problemie jakościowym. Dojrzała organizacja kupująca ocenia wszystkie trzy wymiary łącznie i nie zadowala się żadnym z nich w izolacji, ponieważ każdy z osobna można w krótkim horyzoncie zbudować lub przedstawić w korzystnym świetle.

Weryfikacja certyfikacji nie powinna też być czynnością jednorazową, wykonaną wyłącznie na etapie wyboru: w modelu, w którym Microsoft ocenia partnerów w sposób ciągły, warto upewnić się, że dostawca utrzymuje wymagane kompetencje przez cały okres współpracy, a nie tylko w momencie podpisywania umowy. Dla organizacji planującej wieloletnią współpracę oznacza to, że aktualny status jest wskaźnikiem bieżącej kondycji partnera, a nie zaświadczeniem raz na zawsze, i że jego okresowe potwierdzanie jest uzasadnionym elementem nadzoru nad relacją z dostawcą.

Warto przy tym pamiętać, że certyfikat organizacji nie przekłada się automatycznie na kompetencje każdej osoby w zespole, dlatego rozmowa o konkretnych ludziach przypisanych do projektu pozostaje ważniejsza niż sam tytuł widniejący w katalogu.

‍

Ile realnie kosztuje wdrożenie Dynamics 365

Całkowity koszt wdrożenia Dynamics 365 składa się z trzech elementów: licencji Microsoft, prac wdrożeniowych partnera i utrzymania po go-live. Wycena jest indywidualna, ponieważ zależy od liczby użytkowników, zakresu modułów i stopnia customizacji. Sama licencja Dynamics 365 Finance zaczyna się od 182 € za użytkownika miesięcznie (cennik Microsoft, rozliczenie roczne; wariant Finance Premium: 259,90 €). Koszt prac wdrożeniowych partner wycenia na podstawie zakresu projektu.

Dla dyrektora finansowego kluczowa jest jednak nie sama wysokość poszczególnych składników, lecz ich wzajemna proporcja i rozkład w czasie. Licencja jest kosztem widocznym, przewidywalnym i łatwym do zbudżetowania, przez co bywa nadmiernie eksponowana w rozmowach o kosztach, podczas gdy stanowi ona zwykle mniejszą część całkowitego rachunku w horyzoncie kilku lat. Prace wdrożeniowe oraz utrzymanie są trudniejsze do oszacowania z góry, a jednocześnie to one decydują o rzeczywistym obciążeniu budżetu. Dlatego porównywanie ofert wyłącznie przez pryzmat stawki licencyjnej albo pierwotnej wyceny wdrożenia prowadzi do błędnych wniosków.

Rozsądne podejście polega na modelowaniu kosztu w perspektywie od trzech do pięciu lat, z uwzględnieniem nie tylko uruchomienia, lecz również rozwoju systemu, kolejnych aktualizacji, rosnącej liczby użytkowników oraz zmian w procesach, które nieuchronnie pojawią się po starcie. Taki model pozwala zobaczyć, że oferta pozornie tańsza w części wdrożeniowej może okazać się droższa w utrzymaniu, jeśli prowadzi do rozwiązania trudnego w rozwoju.

Poniższa tabela porządkuje trzy podstawowe składniki, lecz należy ją czytać jako punkt wyjścia do pełnego rachunku kosztu posiadania, a nie jako komplet pozycji budżetowych.

Warto również pamiętać, że koszt i harmonogram są ze sobą sprzężone: presja na skrócenie czasu wdrożenia zwykle podnosi koszt, ponieważ wymaga równoległej pracy większych zespołów i zwiększa ryzyko błędów, a nadmierne oszczędzanie w fazie inwestycyjnej wydłuża i podraża późniejsze utrzymanie. Rzetelne planowanie polega więc na świadomym wyważeniu trzech zmiennych, zakresu, czasu i budżetu, zamiast optymalizowania każdej z nich w oderwaniu od pozostałych.

‍

‍

Co najbardziej podnosi koszt wdrożenia: liczba i złożoność integracji z istniejącymi systemami, stopień customizacji względem standardu, liczba lokalizacji (rollout wielooddziałowy) oraz zakres migracji danych, zwłaszcza ze starszych systemów takich jak Dynamics AX. Dlatego rzetelną wycenę uzyskasz dopiero po analizie przedwdrożeniowej, a nie z cennika.

Wersje Finance & Operations (enterprise) Microsoft wycenia na zapytanie; publiczny cennik obejmuje aplikacje takie jak Finance, ale pełną wycenę środowiska F&O przygotowuje partner.

Z punktu widzenia zarządzania kosztem warto rozumieć, że każdy z wymienionych czynników działa jak mnożnik, a nie jak niezależna pozycja: złożona integracja zwiększa nie tylko pracochłonność budowy, lecz również koszt testów, ryzyko błędów oraz obciążenie utrzymaniem, ponieważ każdy punkt styku między systemami trzeba utrzymywać przez cały cykl życia rozwiązania. Podobnie migracja danych z systemów starszej generacji nie jest jednorazowym transferem, lecz procesem obejmującym oczyszczanie, uzgadnianie i walidację danych, których jakość w źródłowym systemie zwykle okazuje się gorsza, niż zakładano.

Dlatego najuczciwszą odpowiedzią na pytanie o koszt jest wskazanie zmiennych, które go kształtują, oraz zaproszenie do analizy przedwdrożeniowej, w której te zmienne zostaną oszacowane na podstawie faktycznego stanu procesów i danych, a nie założeń przyjętych na potrzeby szybkiej wyceny.

Dla kadry finansowej istotne jest również rozróżnienie kosztów jednorazowych od powtarzalnych oraz świadomość, że część wydatków ma charakter warunkowy i zmaterializuje się tylko wtedy, gdy ziści się określone ryzyko, na przykład gorsza od zakładanej jakość danych źródłowych albo zmiana zakresu w trakcie projektu. Ujęcie tych pozycji jako jawnych rezerw, a nie ukrytych niespodzianek, pozwala zarządzać budżetem w sposób kontrolowany i unikać sytuacji, w której przekroczenie ujawnia się dopiero po fakcie, gdy pole manewru jest już niewielkie.

‍

Pełny TCO wdrożenia poza licencją

Rzetelny rachunek kosztu posiadania (TCO) wykracza daleko poza licencję i pierwotną wycenę prac wdrożeniowych, a jego niedoszacowanie jest najczęstszą przyczyną przekroczeń budżetu w projektach ERP. Na całkowity koszt składają się co najmniej cztery obszary, które w ofertach bywają pomijane albo traktowane skrótowo:

• Zarządzanie zmianą organizacyjną. Komunikacja, szkolenia, budowa sieci lokalnych ekspertów oraz czas pracowników poświęcony na naukę nowego systemu zamiast na bieżące obowiązki. Ten koszt jest realny, choć rzadko ujmowany w budżecie projektu, ponieważ obciąża działy operacyjne, a nie linię IT.

• Migracja danych. Pochłania znacznie więcej wysiłku, niż sugeruje intuicja, ponieważ dane historyczne niemal zawsze wymagają oczyszczenia, ujednolicenia i uzgodnienia, a decyzje o zakresie migracji (co przenosimy, co archiwizujemy, od jakiego momentu) mają bezpośrednie przełożenie na koszt i ryzyko.

• Integracje. Każdy interfejs do systemu magazynowego, produkcyjnego, bankowego czy e-commerce trzeba zaprojektować, zbudować, przetestować, a następnie utrzymywać przez cały cykl życia rozwiązania, co czyni z integracji stały, a nie jednorazowy koszt.

• Utrzymanie i rozwój po go-live. Obsługa zgłoszeń, adaptacja do zmian prawnych, rozbudowa o nowe funkcje oraz obowiązkowe aktualizacje platformy, które w modelu ciągłych aktualizacji stają się elementem kalendarza operacyjnego.

‍

Dla kadry finansowej praktyczny wniosek jest następujący: budżet wdrożenia należy planować jako sumę kosztu uruchomienia i wieloletniego kosztu operacyjnego, a nie jako pojedynczy wydatek inwestycyjny.

Tylko takie ujęcie pozwala uczciwie porównać oferty i uniknąć sytuacji, w której tanie uruchomienie generuje kosztowne, wieloletnie utrzymanie, obciążające kolejne budżety operacyjne długo po zakończeniu projektu.

Niezależne analizy rynku ERP potwierdzają tę prawidłowość: to właśnie koszty ukryte, od zarządzania zmianą po migrację danych, najczęściej odpowiadają za przekroczenia budżetu i harmonogramu. W jednym udokumentowanym przypadku niekontrolowany zakres i słaby nadzór projektu podniosły koszt o 25% i wydłużyły wdrożenie o pół roku (Panorama Consulting).

Warto również pamiętać, że część składników kosztu posiadania nie ma postaci faktury od dostawcy, lecz przybiera formę czasu i uwagi własnych pracowników, dlatego umyka standardowej analizie budżetowej opartej na wydatkach zewnętrznych. Uwzględnienie tego kosztu wewnętrznego, zwłaszcza zaangażowania ekspertów procesowych i kadry zarządzającej, urealnia porównanie ofert i chroni przed złudzeniem, że wdrożenie prowadzone najmniejszym nakładem po stronie organizacji jest wdrożeniem najtańszym.

‍

Dlaczego wyceny „fixed price" bywają iluzją i jak dzielić ryzyko

Model wyceny ryczałtowej („fixed price") jest atrakcyjny dla kadry finansowej, ponieważ obiecuje przewidywalność i przeniesienie ryzyka na dostawcę, jednak w projektach ERP o dużej złożoności ta obietnica bywa iluzoryczna i wymaga krytycznej analizy.

Cena ryczałtowa ma sens tylko wtedy, gdy zakres jest precyzyjnie zdefiniowany, a w momencie podpisywania umowy zakres wdrożenia rzadko jest znany z wystarczającą dokładnością, ponieważ pełne zrozumienie procesów, jakości danych i wymagań integracyjnych powstaje dopiero w fazie analizy. W konsekwencji dostawca oferujący sztywną cenę musi wkalkulować w nią bufor na ryzyko, przez co klient płaci za niepewność niezależnie od tego, czy się ona zmaterializuje, albo dostawca przyjmuje cenę zbyt niską i odrabia ją później przez restrykcyjne zarządzanie zakresem, w którym każda zmiana staje się przedmiotem osobnej, kosztownej negocjacji.

Oba scenariusze są dla klienta niekorzystne: w pierwszym płaci za bufor, w drugim za każdą korektę. Dojrzalszym podejściem jest podział projektu na etapy i dopasowanie modelu rozliczeń do stopnia niepewności każdego z nich.

Fazę analizy warto rozliczyć osobno, w modelu czasu i materiału lub jako oddzielny, zamknięty produkt, ponieważ jej celem jest właśnie zredukowanie niepewności i zbudowanie wiarygodnej podstawy do wyceny dalszych prac. Dopiero po analizie, gdy zakres jest znany, można rozważyć elementy ryczałtowe dla części dobrze zdefiniowanych, pozostawiając mechanizmy zmiany zakresu dla obszarów o wyższej zmienności.

Aby kontrakt wytrzymał próbę realnego projektu, powinien zawierać kilka elementów, które chronią obie strony:

• Jasny proces zarządzania zmianą. Ustalona ścieżka zgłaszania, wyceny i akceptacji zmian zakresu, zamiast doraźnych negocjacji przy każdej korekcie.

• Przejrzysty katalog założeń. Spisane wprost założenia przyjęte do wyceny, tak aby było wiadomo, co obejmuje cena, a co jest zmianą zakresu.

• Mechanizm współdzielenia oszczędności i przekroczeń. Podział skutków odchyleń od planu, dzięki któremu interesy stron są zbieżne, a nie przeciwstawne.

• Rozliczenie fazy analizy osobno. Wydzielenie etapu, którego celem jest redukcja niepewności, tak aby wycena dalszych prac powstawała na wiarygodnej podstawie.

Podział ryzyka, a nie jego pozorne przeniesienie, jest cechą kontraktu, który wytrzymuje próbę realnego projektu.

‍

Jak przebiega wdrożenie Dynamics 365 krok po kroku

Wdrożenie systemu ERP Dynamics 365 przebiega w sześciu fazach: analiza przedwdrożeniowa, projekt rozwiązania, konfiguracja i rozwój, migracja danych, testy i szkolenia oraz go-live z opieką powdrożeniową. U większości firm cały cykl trwa od kilku do kilkunastu miesięcy, zależnie od zakresu i liczby integracji.

Dla kadry zarządzającej istotne jest zrozumienie, że wartość i ryzyko nie rozkładają się równomiernie na wszystkie fazy. Nieproporcjonalnie duży wpływ na powodzenie całości ma faza analizy przedwdrożeniowej, ponieważ to w niej zapadają decyzje o zakresie, architekturze i sposobie odwzorowania procesów, a błędy popełnione na tym etapie są najdroższe do naprawienia później.

Koszt korekty decyzji rośnie z każdą kolejną fazą: to, co w analizie jest zmianą na papierze, w fazie rozwoju staje się przebudową kodu, a po go-live przebudową działającego systemu, obciążoną ryzykiem dla ciągłości operacyjnej. Dlatego skłonność do skracania analizy w imię szybszego startu jest jedną z najkosztowniejszych oszczędności w całym projekcie.

Równie ważny jak sama sekwencja faz jest sposób, w jaki partner nimi zarządza: czy każda faza kończy się formalnym odbiorem, czy istnieją mierzalne kryteria przejścia do kolejnego etapu oraz czy zakres jest kontrolowany w sposób jawny, czy rozmywa się w trakcie prac. Testy i szkolenia, często traktowane jako etap końcowy i redukowane pod presją harmonogramu, w rzeczywistości decydują o tym, czy organizacja będzie zdolna do pracy w nowym systemie od pierwszego dnia. Niedoszacowanie tej fazy skutkuje spadkiem produktywności po starcie, który bywa dotkliwszy niż samo opóźnienie wdrożenia.

Dla decydenta praktyczny wniosek jest taki, że harmonogram należy oceniać nie przez pryzmat najwcześniejszej możliwej daty startu, lecz przez pryzmat gotowości organizacji do stabilnej pracy w nowym systemie, ponieważ przedwczesne uruchomienie potrafi kosztować więcej niż kilkutygodniowe opóźnienie.

Równie ważne jest, aby data go-live nie kolidowała z okresami szczególnego obciążenia biznesu, takimi jak zamknięcie roku czy szczyt sezonu sprzedażowego, gdyż nałożenie ryzyka wdrożeniowego na ryzyko operacyjne wielokrotnie zwiększa potencjalne skutki ewentualnych problemów.

1. Analiza przedwdrożeniowa: mapowanie procesów biznesowych, ustalenie zakresu, harmonogramu i celów projektu.
2. Projekt rozwiązania: architektura systemu, dobór modułów, zaprojektowanie integracji i rozszerzeń.
3. Konfiguracja i rozwój: ustawienia standardowe Dynamics 365 oraz niezbędne rozszerzenia (customizacje).
4. Migracja danych: przeniesienie i oczyszczenie danych z dotychczasowych systemów (np. z Dynamics AX).
5. Testy i szkolenia: testy akceptacyjne użytkowników (UAT) oraz szkolenia zespołów, które będą pracować w systemie.
6. Go-live i opieka powdrożeniowa: uruchomienie produkcyjne oraz stałe wsparcie i rozwój systemu.

Dobry partner prowadzi projekt według uznanej metodyki (np. zgodnej z Microsoft Success by Design), z jasno zdefiniowanymi kamieniami milowymi i odbiorami na końcu każdej fazy. To pozwala kontrolować zakres, budżet i ryzyko na każdym etapie.

Wartość metodyki nie polega jednak na samym istnieniu dokumentów i list kontrolnych, lecz na dyscyplinie, jaką narzuca ona zespołowi: wymusza podejmowanie i dokumentowanie decyzji we właściwym momencie, weryfikację architektury pod kątem skalowalności i zgodności z platformą oraz wczesne ujawnianie ryzyk, zanim staną się problemami. Success by Design kładzie nacisk na przeglądy kluczowych decyzji projektowych w punktach, w których ich korekta jest jeszcze tania, co bezpośrednio przekłada się na ograniczenie kosztownych zmian w późniejszych fazach.

Dla decydenta metodyka jest przede wszystkim narzędziem przewidywalności i kontroli: pozwala zadawać właściwe pytania na koniec każdej fazy, powiązać płatności z odbiorami oraz uzyskać wczesne ostrzeżenie, gdy projekt zaczyna odchodzić od założeń. Partner, który stosuje metodykę wybiórczo albo traktuje ją jako formalność, pozbawia klienta tej kontroli, nawet jeśli formalnie deklaruje jej użycie.

Metodyka nie zastępuje jednak zdrowego rozsądku ani zaangażowania stron i nie powinna przeradzać się w biurokrację, w której wytwarzanie dokumentacji staje się celem samym w sobie, a nie środkiem do kontroli ryzyka. Właściwie stosowana, pełni rolę wspólnego języka między biznesem a zespołem wdrożeniowym: porządkuje decyzje, ustala odpowiedzialności i wyznacza momenty, w których zarząd otrzymuje rzetelną informację o stanie projektu.

Dla organizacji istotne jest, aby na końcu każdej fazy dysponować nie tylko formalnym odbiorem, lecz również jasną odpowiedzią na pytanie, czy projekt nadal zmierza do zakładanych celów biznesowych, czy jedynie realizuje kolejne zadania zgodnie z planem. To rozróżnienie, między postępem prac a postępem w kierunku wartości, jest jednym z najważniejszych, jakie kadra zarządzająca powinna egzekwować na każdym kamieniu milowym, ponieważ projekt może być formalnie na czas i w budżecie, a mimo to oddalać się od pierwotnego uzasadnienia biznesowego.

‍

Standard, customizacja i model ciągłych aktualizacji

Jedną z najważniejszych, a zarazem najczęściej niedocenianych decyzji strategicznych we wdrożeniu jest wybór proporcji między wykorzystaniem standardu Dynamics 365 a budową rozszerzeń dopasowanych do specyfiki organizacji. Naturalną skłonnością zespołów biznesowych jest odwzorowanie w nowym systemie dotychczasowego sposobu pracy, co prowadzi do mnożenia customizacji odtwarzających istniejące procesy zamiast korzystania z gotowych, sprawdzonych mechanizmów platformy.

Każde rozszerzenie wykraczające poza standard tworzy jednak zobowiązanie, które będzie obciążać organizację przez cały cykl życia rozwiązania, ponieważ trzeba je utrzymywać, testować przy każdej aktualizacji platformy oraz dokumentować, aby nie stało się zależne od wiedzy pojedynczych osób. Nadmierna customizacja jest formą długu technologicznego: przynosi krótkoterminową korzyść w postaci wiernego odwzorowania oczekiwań użytkownika, lecz generuje długoterminowy koszt w postaci rosnącej złożoności, trudniejszych aktualizacji i większej kruchości systemu.

W modelu ciągłych aktualizacji Dynamics 365 ten koszt jest szczególnie odczuwalny, ponieważ każde rozszerzenie musi być regularnie weryfikowane pod kątem zgodności z nowymi wersjami platformy, a im więcej rozszerzeń, tym większe ryzyko i wysiłek związany z każdą aktualizacją. Rozsądne podejście polega na świadomym rozróżnieniu procesów, które stanowią realną przewagę konkurencyjną firmy i uzasadniają rozszerzenie, od procesów pomocniczych, w których warto przyjąć standard nawet kosztem zmiany dotychczasowych przyzwyczajeń.

To rozróżnienie jest decyzją biznesową, a nie techniczną, i powinno zapadać z udziałem kadry zarządzającej, ponieważ ma bezpośredni wpływ na koszt utrzymania, tempo rozwoju oraz zdolność organizacji do korzystania z kolejnych funkcji dostarczanych przez Microsoft. Partner, który konsekwentnie kwestionuje zasadność customizacji i broni standardu tam, gdzie to możliwe, chroni klienta przed długiem, którego skutki ujawniają się dopiero po latach.

Znaczenie tej decyzji potęguje model One Version: wybierając Dynamics 365 w wariancie chmurowym, organizacja przyjmuje zobowiązanie do przyjmowania aktualizacji platformy w regularnym rytmie i nie może pozostać na starszej wersji w nieskończoność. Model ten daje realne korzyści, ponieważ system otrzymuje nowe funkcje i poprawki bez kosztownych, wieloletnich projektów modernizacyjnych i nie starzeje się w sposób wymuszający po dekadzie wymianę całości. Ma jednak swoją cenę w postaci trwałego zobowiązania operacyjnego: każda aktualizacja wymaga przetestowania rozszerzeń i integracji pod kątem zgodności, więc im więcej customizacji, tym większy stały obowiązek testów regresyjnych i tym wyższe ryzyko przy kolejnych wersjach.

Dla kadry zarządzającej wniosek jest jednoznaczny: wdrożenie nie kończy się w dniu go-live, lecz przechodzi w tryb stałego utrzymania, w którym cykl aktualizacji staje się elementem kalendarza operacyjnego i powinien być uwzględniony w budżecie oraz w modelu współpracy z partnerem.

‍

Gotowość organizacyjna i rola sponsora biznesowego

O powodzeniu wdrożenia w co najmniej takim samym stopniu jak jakość partnera decyduje gotowość samej organizacji, a ten czynnik pozostaje w rękach klienta i nie da się go zlecić na zewnątrz. Gotowość organizacyjna oznacza między innymi:

• Jasność celów. Uzgodnione, mierzalne cele projektu, do których można odnosić kolejne decyzje o zakresie i priorytetach.

• Dostępność ekspertów. Realny czas kluczowych osób biznesowych na pracę w projekcie, a nie jedynie ich formalne przypisanie do zespołu obok pełnego zakresu bieżących obowiązków.

• Tempo decyzji. Zdolność do podejmowania rozstrzygnięć w wymaganym rytmie, ponieważ przeciągające się tygodniami uzgodnienia są jedną z głównych przyczyn utraty tempa i wiarygodności projektu.

• Właściwe podejście do zmiany. Akceptacja faktu, że wdrożenie systemu jest przede wszystkim zmianą sposobu pracy, a dopiero wtórnie przedsięwzięciem informatycznym.

Najczęstszą przyczyną niepowodzeń nie są ograniczenia technologii, lecz niedostateczne zaangażowanie strony biznesowej: eksperci procesowi są zbyt obciążeni bieżącą pracą, decyzje przeciągają się tygodniami, a projekt traci tempo i wiarygodność.

Dlatego rola sponsora biznesowego jest krytyczna. Sponsor to osoba z poziomu zarządu, która posiada mandat do rozstrzygania konfliktów priorytetów, zapewnienia zasobów oraz egzekwowania decyzji w poprzek działów, ponieważ wdrożenie ERP niemal zawsze wymusza ujednolicenie procesów, które dotąd funkcjonowały odmiennie w różnych częściach organizacji.

Bez takiego mandatu projekt grzęźnie w niekończących się uzgodnieniach, a partner, choćby najlepszy, nie jest w stanie zastąpić decyzji, które należą do właściciela procesu. Sponsor odpowiada również za utrzymanie kierunku, gdy pojawia się naturalna pokusa rozszerzania zakresu albo powrotu do dawnych przyzwyczajeń pod presją użytkowników.

Dla kadry zarządzającej praktyczny wniosek jest taki, że decyzja o wdrożeniu powinna obejmować równoległą decyzję o wyznaczeniu sponsora, uwolnieniu czasu kluczowych ekspertów oraz jawnym uznaniu, że przez okres projektu część zasobów organizacji będzie zaangażowana w zmianę, a nie wyłącznie w bieżącą działalność. Zignorowanie tego wymiaru jest jednym z najczęstszych i najkosztowniejszych błędów, ponieważ jego skutki obciążają projekt niezależnie od jakości wybranego dostawcy.

‍

Kto kompleksowo wdroży Dynamics 365 Finance & Operations

Wdrożenie Dynamics 365 Finance & Operations (dawniej Dynamics AX) wymaga partnera wyspecjalizowanego w rozwiązaniach klasy enterprise, z kompetencjami w modułach Finance i Supply Chain Management oraz doświadczeniem w migracjach z AX do D365. To projekty o innej skali i złożoności niż wdrożenia dla mniejszych firm, dlatego liczy się udokumentowane doświadczenie w dużych środowiskach.

Różnica między wdrożeniem enterprise a projektem dla mniejszej organizacji nie jest wyłącznie ilościowa i nie sprowadza się do liczby użytkowników. Środowiska klasy Finance & Operations wymagają odwzorowania procesów, których nie spotyka się w mniejszych wdrożeniach:

• Złożone struktury organizacyjne. Wiele jednostek prawnych, walut i jurysdykcji podatkowych obsługiwanych w jednym środowisku.

• Zaawansowane planowanie i kosztowanie. Planowanie produkcji, kalkulacja kosztów i zarządzanie łańcuchem dostaw o wysokiej złożoności.

• Architektura integracji. Liczne punkty styku z systemami MES, WMS, bankowymi i e-commerce, których skala zwielokrotnia ryzyko.

• Migracja z Dynamics AX. Nie tylko przeniesienie danych, lecz decyzja, co zachować, a co zastąpić standardem, aby nie przenieść długu technologicznego.

Poprawne odwzorowanie tych obszarów wymaga doświadczenia trudnego do zdobycia poza dużymi projektami. W takich wdrożeniach szczególnego znaczenia nabiera architektura integracji oraz strategia migracji danych, ponieważ skala i różnorodność źródeł zwielokrotniają ryzyko.

Migracja z Dynamics AX jest tu odrębnym wyzwaniem, gdyż wymaga nie tylko przeniesienia danych, lecz również przemyślenia, które rozwiązania z poprzedniego systemu warto zachować, a które zastąpić standardem nowej platformy, aby nie przenieść do nowego środowiska długu technologicznego zgromadzonego przez lata.

Dlatego przy wyborze partnera do wdrożenia F&O waga referencji o zbliżonej skali i złożoności rośnie, a ogólne doświadczenie w mniejszych projektach nie stanowi wystarczającej rękojmi. Warto również zweryfikować, czy partner dysponuje zespołem zdolnym do utrzymania tak złożonego środowiska po go-live, ponieważ w tej klasie rozwiązań faza utrzymania jest równie wymagająca jak samo wdrożenie i wymaga stałego dostępu do kompetencji, które trudno zbudować doraźnie.

Dla organizacji o skali enterprise istotna jest także zdolność partnera do pracy w reżimie podwyższonych wymagań dotyczących bezpieczeństwa, zgodności regulacyjnej i ciągłości działania, ponieważ awaria systemu klasy Finance & Operations przekłada się bezpośrednio na zdolność firmy do realizacji sprzedaży, produkcji i rozliczeń. Ocena partnera powinna więc obejmować nie tylko kompetencje wdrożeniowe, lecz również dojrzałość procesów operacyjnych po jego stronie, w tym sposób obsługi zgłoszeń krytycznych i gwarantowane czasy reakcji.

Kompleksowe wdrożenie F&O obejmuje zwykle moduły Finance, Supply Chain Management, a często również Project Operations i Commerce, wraz z integracjami, migracją danych i utrzymaniem. ANEGIS realizuje takie projekty w skali od 20 do 30 000 użytkowników. Przykładem jest wdrożenie dla sieci New Yorker: Dynamics 365 Finance obsługujący ponad 1000 sklepów w 40 krajach i ponad 10 000 pracowników, wraz z modułami magazynu, sprzedaży i zarządzania cenami.

Do standardu dochodzą autorskie moduły ANEGIS Power Center (m.in. zarządzanie personelem AWM czy obieg dokumentów ADF), rozszerzające Dynamics 365 o gotowe funkcje. Gotowe rozszerzenia tego typu zasługują na uwagę decydenta z powodu odmiennym niż indywidualna customizacja: są utrzymywane i rozwijane przez dostawcę jako produkt, a nie budowane od zera dla pojedynczego klienta, dzięki czemu przenoszą ciężar utrzymania i aktualizacji z organizacji na dostawcę modułu.

To istotna różnica w rachunku kosztu posiadania, ponieważ pozwala uzyskać funkcję wykraczającą poza standard bez zaciągania pełnego długu technologicznego charakterystycznego dla rozwiązań pisanych na zamówienie. Ocena takich modułów powinna obejmować pytanie o sposób ich rozwoju, zgodność z kolejnymi wersjami platformy oraz zakres, w jakim zastępują one prace, które w innym scenariuszu trzeba by wykonać jako indywidualne rozszerzenia.

Warto również sprawdzić, na jakich zasadach organizacja korzysta z takiego modułu w dłuższym horyzoncie: czy jego utrzymanie jest objęte współpracą z dostawcą, jak wygląda ścieżka rozwoju funkcji oraz jakie są konsekwencje ewentualnego zakończenia współpracy. Odpowiedzi na te pytania decydują o tym, czy gotowy moduł pozostaje aktywem obniżającym całkowity koszt posiadania, czy z czasem sam staje się źródłem zależności.

Dla decydenta rozstrzygające jest, aby korzyść z gotowej funkcji nie zamieniła się w nową formę uzależnienia, trudniejszą do rozpoznania niż klasyczna customizacja, ponieważ ukrytą w produkcie dostarczanym przez partnera.

‍

Rollout Dynamics 365 w wielu oddziałach i filiach

Rollout Dynamics 365 w wielu oddziałach realizuje się etapowo: najpierw powstaje wspólny model bazowy (core model / template), a następnie wdraża się go w kolejnych lokalizacjach, uwzględniając lokalne wymogi prawne, podatkowe i językowe. Ten model jest tańszy i mniej ryzykowny niż osobne, niezależne wdrożenia w każdej filii, bo powtarzalna część pracy wykonywana jest raz.

Ekonomika takiego podejścia opiera się na efekcie skali: koszt zaprojektowania procesów, architektury i konfiguracji ponosi się jednorazowo w modelu bazowym, a w kolejnych lokalizacjach dochodzi jedynie koszt lokalizacji i uruchomienia, znacząco niższy niż budowa od podstaw.

Za tą oszczędnością kryje się jednak napięcie strategiczne, które kadra zarządzająca powinna świadomie rozstrzygnąć: im silniejsza standaryzacja modelu bazowego, tym większe korzyści skali, lecz tym większy opór lokalnych organizacji, przywiązanych do własnej specyfiki. Odwrotnie, im więcej odstępstw dopuszczonych w poszczególnych lokalizacjach, tym łatwiejsza akceptacja lokalna, ale tym słabszy efekt skali i tym droższe utrzymanie wielu wariantów rozwiązania.

Znalezienie właściwej równowagi między tym, co globalnie wspólne, a tym, co lokalnie dopuszczalne, jest jedną z kluczowych decyzji w projekcie wielooddziałowym i powinno zapadać na poziomie zarządu, ponieważ przesądza o kosztach i sterowności organizacji na lata. Rollout etapowy ma również zaletę zarządzania ryzykiem: pilot w jednej lokalizacji referencyjnej pozwala zweryfikować model, wyłapać błędy i skorygować podejście, zanim rozwiązanie trafi do kolejnych oddziałów, co ogranicza skalę ewentualnego niepowodzenia.

Kolejność fal wdrożeniowych warto planować nie tylko według geografii, lecz również według gotowości poszczególnych lokalizacji i ich znaczenia dla ciągłości biznesu, tak aby najbardziej krytyczne jednostki startowały wtedy, gdy model jest już dojrzały i sprawdzony. Istotnym elementem zarządzania takim programem jest również jasny podział ról między centralnym zespołem odpowiedzialnym za model bazowy a lokalnymi organizacjami, ponieważ bez tego rozgraniczenia lokalne oczekiwania stopniowo erodują standard, a każda kolejna lokalizacja negocjuje własne wyjątki, co z czasem odbudowuje złożoność, której rollout etapowy miał uniknąć.

‍

Typowy przebieg rolloutu wielooddziałowego:

• Model bazowy: standard procesów i konfiguracji wspólny dla całej organizacji.
• Lokalizacja: dostosowanie do przepisów i specyfiki danego kraju lub oddziału.
• Pilot: wdrożenie w jednej lokalizacji referencyjnej i weryfikacja modelu.
• Fale wdrożeń (waves): sukcesywne uruchamianie w kolejnych oddziałach według harmonogramu.

‍

Przy projektach międzynarodowych kluczowa jest zdolność partnera do pracy w wielu krajach jednocześnie. ANEGIS prowadzi takie projekty z biur w Polsce (Wrocław, Warszawa, Sieradz) i w Wielkiej Brytanii (Londyn). Dla New Yorker wdrożenie objęło 40 krajów, a dla producenta OSTP (wyroby ze stali nierdzewnej) środowisko Dynamics obejmowało zakłady w Polsce i Szwecji, z integracjami do systemów produkcyjnych i łańcucha dostaw.

Zdolność do prowadzenia rolloutu w wielu krajach jednocześnie nie sprowadza się do obecności geograficznej, lecz obejmuje znajomość lokalnych wymogów prawnych i podatkowych, umiejętność koordynacji zespołów pracujących w różnych strefach czasowych oraz zdolność utrzymania spójności modelu bazowego mimo presji na lokalne odstępstwa. Dla organizacji planującej ekspansję istotne jest również, aby partner potrafił przenieść wiedzę zdobytą w pierwszych lokalizacjach na kolejne, tak aby każda następna fala wdrożenia była szybsza i tańsza od poprzedniej.

Ten efekt uczenia się jest jednym z głównych źródeł wartości rolloutu etapowego i powinien być przedmiotem rozmowy z potencjalnym dostawcą. Przy projektach obejmujących wiele krajów rośnie także znaczenie zarządzania danymi podstawowymi, ponieważ spójny plan kont, jednolite kartoteki kontrahentów i produktów oraz uzgodnione reguły raportowe są warunkiem tego, aby wspólny model bazowy rzeczywiście umożliwiał porównywalność wyników między lokalizacjami. Bez tej dyscypliny organizacja może wdrożyć jeden system, a mimo to nadal otrzymywać dane nieporównywalne między oddziałami, co niweczy część korzyści z ujednolicenia.

Dla kadry zarządzającej praktyczny wniosek jest taki, że rollout międzynarodowy jest w równym stopniu projektem technologicznym, co projektem ładu informacyjnego, a wybór partnera powinien uwzględniać jego doświadczenie w godzeniu globalnej standaryzacji z lokalnymi wymogami prawnymi i podatkowymi. Warto też z góry ustalić, kto w organizacji sprawuje pieczę nad danymi podstawowymi po zakończeniu wdrożenia, ponieważ bez wyznaczonego właściciela spójność modelu erodować będzie z każdą kolejną zmianą wprowadzaną lokalnie.

‍

Druga fala optymalizacji po go-live i krzywa wartości

Jednym z najczęściej pomijanych aspektów w planowaniu wdrożenia jest kształt krzywej wartości w czasie, czyli moment, w którym system faktycznie zaczyna zwracać poniesioną inwestycję. Powszechnym błędem jest założenie, że wartość pojawia się w dniu go-live; w rzeczywistości uruchomienie produkcyjne to zwykle moment przejściowego spadku produktywności, ponieważ organizacja uczy się nowego sposobu pracy, a procesy dopiero się stabilizują. Realny zwrot z inwestycji materializuje się później, w tak zwanej drugiej fali optymalizacji, gdy system działa stabilnie, użytkownicy opanowali podstawy, a organizacja jest gotowa świadomie wykorzystywać funkcje, na które nie było przestrzeni w napiętym harmonogramie pierwszego uruchomienia. To właśnie w tej fazie sięga się po możliwości platformy, które w pierwszym podejściu świadomie odłożono, aby nie przeciążać projektu:

• Zaawansowana automatyzacja. Automatyzacja procesów, które w pierwszym uruchomieniu pozostały ręczne, aby nie zwiększać ryzyka startu.

• Rozbudowa raportowania i analityki. Przejście od podstawowych raportów do analityki wspierającej decyzje zarządcze, w tym wskaźników wcześniej niedostępnych.

• Dopracowanie procesów. Korekta i uproszczenie procesów w oparciu o realne dane z pierwszych miesięcy pracy w nowym systemie.

• Wykorzystanie odłożonych funkcji. Wdrożenie modułów i możliwości platformy, które świadomie wyłączono z zakresu pierwszej fali.

Dla kadry zarządzającej ma to dwie konsekwencje. Po pierwsze, oczekiwania co do zwrotu należy kalibrować realistycznie i nie interpretować przejściowego spadku produktywności po starcie jako oznaki niepowodzenia, lecz jako naturalny element krzywej.

Po drugie, budżet i plan współpracy z partnerem powinny z góry przewidywać drugą falę, ponieważ organizacje, które po go-live rozwiązują projekt i pozostawiają system samemu sobie, zatrzymują się na poziomie odtworzenia dawnych procesów w nowej technologii i nigdy nie sięgają po pełnię wartości, za którą zapłaciły.

Świadome zaplanowanie fazy optymalizacji jest tym, co odróżnia wdrożenie traktowane jako koszt zgodności od wdrożenia traktowanego jako inwestycja w przewagę operacyjną. Partner zdolny towarzyszyć klientowi w tej fazie, a nie jedynie doprowadzić do startu, jest w tym ujęciu cenniejszy niż dostawca oferujący najniższą cenę samego uruchomienia.

Praktycznym rozwiązaniem jest zaplanowanie drugiej fali już na etapie definiowania projektu i zarezerwowanie na nią budżetu oraz zasobów, tak aby optymalizacja stała się świadomym, zaplanowanym etapem, a nie przypadkowym następstwem zgłaszanych po starcie problemów.

Dlaczego ANEGIS

ANEGIS to wyspecjalizowana firma konsultingowa Microsoft Dynamics 365, która prowadzi wdrożenia od analizy po wieloletnie utrzymanie. Najważniejsze fakty:

• Status: Microsoft Solutions Partner (Business Applications); historycznie Microsoft Gold Partner.
• Zespół: ponad 200 certyfikowanych ekspertów Microsoft; biura we Wrocławiu, Warszawie, Sieradzu i Londynie.
• Skala: projekty od 20 do 30 000 użytkowników; 3. miejsce w rankingu partnerów Microsoft w Polsce (Dynamics 365 F&O i Customer Engagement).
• Zakres: wdrożenia D365 (ERP i CRM), migracje z Dynamics AX do D365, opieka serwisowa, body leasing oraz rollout międzynarodowy.
• Branże: produkcja, handel i dystrybucja, usługi profesjonalne, budownictwo i inżynieria.

Przykładowe wdrożenia:

• New Yorker (moda, handel detaliczny): Dynamics 365 Finance dla ponad 1000 sklepów w 40 krajach i ponad 10 000 pracowników.
• TERG / Media Expert (handel elektroniką, Polska): Dynamics 365 Finance dla ponad 550 sklepów i ponad 10 000 pracowników, z 154 interfejsami integracyjnymi i rozliczeniami omnichannel.
• OSTP (produkcja, stal nierdzewna): środowisko Microsoft Dynamics w Polsce i Szwecji, z integracjami do systemów MES i planowania łańcucha dostaw.

Zestawienie tych cech ma znaczenie o tyle, o ile odpowiada na kryteria opisane wcześniej w tym materiale. Aktualny status Microsoft Solutions Partner adresuje wymóg weryfikowalnej kompetencji, zespół własny liczący ponad 200 ekspertów odpowiada na potrzebę ciągłości wiedzy i jednoznacznej odpowiedzialności bez rozpraszania jej na podwykonawców, a rozpiętość skali od 20 do 30 000 użytkowników pozwala dobrać podejście do realnej wielkości projektu.

Obecność w Polsce i w Wielkiej Brytanii oraz doświadczenie w projektach obejmujących wiele krajów odnoszą się wprost do wymogów rolloutu wielooddziałowego, w którym liczy się zdolność do pracy w różnych jurysdykcjach i utrzymania spójnego modelu bazowego. Prowadzenie projektu od analizy po wieloletnie utrzymanie jest tu istotne w świetle wcześniejszych rozważań o koszcie posiadania i o drugiej fali optymalizacji: partner obecny przez cały cykl życia rozwiązania może towarzyszyć organizacji nie tylko do startu, lecz również w fazie, w której system zaczyna zwracać inwestycję.

Referencje o zróżnicowanym profilu, od handlu detalicznego po produkcję, dostarczają materiału do pogłębionej weryfikacji, o której mowa była wyżej, ponieważ pozwalają rozmawiać z klientami o zbliżonej skali i charakterze wyzwań, a nie jedynie oglądać zestaw logotypów. Ostateczna ocena partnera powinna jednak zawsze wracać do specyfiki Twojego projektu: żadna referencja, żaden status ani żaden ranking nie zastąpią własnej analizy tego, czy dany dostawca rozumie Twój model biznesowy, Twoje procesy i Twoje cele finansowe.

Dlatego najbardziej wartościowym krokiem nie jest porównanie deklaracji marketingowych, lecz wspólna praca nad wstępnym zarysem rozwiązania, w której partner pokazuje sposób myślenia o Twoim konkretnym przypadku. Taka rozmowa ujawnia więcej niż jakiekolwiek zestawienie osiągnięć, ponieważ pozwala ocenić nie to, co partner zrobił dla innych, lecz to, jak podchodzi do wyzwania, przed którym stoi Twoja organizacja.

‍

Porozmawiajmy o Twoim wdrożeniu

‍