O usłudze
Termin uruchomienia systemu został przesunięty po raz kolejny. Lista zgłoszonych błędów rośnie zamiast maleć, dane zostały zmigrowane po raz trzeci i nadal nie uzgadniają się ze źródłem, a w zespole partnera zmieniają się kolejni konsultanci. Raporty statusu wciąż informują, że projekt przebiega zgodnie z planem. Twoi pracownicy wykonują zadania, za które odpowiada partner, a zarząd przestaje wierzyć w kolejną datę startu. W tej sytuacji najwyższy koszt generują nie środki już wydane, lecz każdy kolejny tydzień bez decyzji.
ANEGIS przejmuje zagrożone, opóźnione i wstrzymane wdrożenia Dynamics 365 Finance and Operations oraz migracje z Dynamics AX. Pracę rozpoczynamy od dwutygodniowego audytu, który jednoznacznie wskazuje, które elementy rozwiązania należy zachować, które naprawić, a z których zrezygnować, oraz ile realnie kosztuje dokończenie projektu. Następnie stabilizujemy projekt, usuwamy przyczyny blokujące uruchomienie i prowadzimy go do startu produkcyjnego oraz opieki po starcie. Możemy przejąć projekt w całości albo pracować równolegle z Twoim obecnym partnerem jako niezależna instancja oceniająca. Jeśli Twój projekt postępuje, lecz potrzebuje punktowego wzmocnienia kompetencji lub zasobów, właściwą usługą jest wsparcie projektowe. Project recovery dotyczy projektów, które utraciły zdolność do samodzielnego dotarcia do celu.
5
98
20+
Projekt rzadko kończy się nagłym załamaniem. Znacznie częściej stopniowo traci wiarygodność
Poniższe sygnały powtarzają się w niemal każdym projekcie, który trafia do nas w celu przejęcia. Jeśli rozpoznajesz któryś z nich, warto spojrzeć na projekt z zewnątrz, zanim zostanie wyznaczona kolejna data.

Termin uruchomienia przesunięty po raz drugi lub trzeci
Budżet rośnie, a zakres się zmniejsza
Testy nie zbliżają się do zakończenia
Dane zmigrowane ponownie i nadal niezgodne
Integracje działają podczas prezentacji, nie pod obciążeniem
Twój zespół wykonuje pracę partnera
Po stronie partnera zmieniają się ludzie
Raporty informują o prawidłowym przebiegu, a komitet sterujący utracił zaufanie
Co odzyskujesz, gdy projekt wraca pod kontrolę
Inwestycja, która nie zostaje utracona
Większość wykonanej pracy zwykle da się zachować: konfigurację, część rozszerzeń, przygotowane dane, przeszkolonych pracowników. Naprawa chroni to, za co już zapłaciłeś. Ponowne rozpoczęcie projektu spisuje tę wartość na straty.
Koniec finansowania dwóch systemów jednocześnie
Dotychczasowy system Dynamics AX generuje koszty utrzymania, licencji i ręcznych obejść, a nowy system jeszcze nie pracuje. Zakończenie projektu zamyka podwójny rachunek.
Jeden spójny obraz finansów grupy
Zamknięcie okresu bez arkuszy pomocniczych, konsolidacja w terminie i liczby, którym zarząd może zaufać.
Zgodność z przepisami w wymaganym terminie
Obowiązkowy Krajowy System e-Faktur, kontrole podatkowe, raportowanie ustawowe. Uruchomiony system zamyka obszar, którego system bez wsparcia producenta nie jest już w stanie bezpiecznie obsłużyć.
Plan, który można obronić przed zarządem
Realny harmonogram oparty na zweryfikowanych faktach, nie na deklaracjach. Sponsor projektu odzyskuje wiarygodność, ponieważ prezentuje kontrolę nad sytuacją, a nie kolejną datę.
Zespół, który wraca do swoich obowiązków
Koniec usuwania awarii po godzinach pracy. Pracownicy otrzymują system, na którym można wykonywać obowiązki, a nie projekt, który pochłania ich etaty.
Pomożemy Ci w transformacji
Z jakimi sytuacjami zgłaszają się do nas klienci
Każdy zagrożony projekt ma inną historię, lecz większość przypadków mieści się w jednym z sześciu scenariuszy.
Wdrożenie Finance and Operations zatrzymało się przed uruchomieniem
Kolejny termin przesunięty, zakres rozmyty, zespół wyczerpany. Potrzebujesz rzetelnej odpowiedzi, czy i w jaki sposób projekt można dokończyć.
Migracja z Dynamics AX zatrzymała się w połowie drogi
Dotychczasowy system nie ma już wsparcia producenta, nowy jeszcze nie działa, a przedsiębiorstwo pracuje na obu jednocześnie.
System został uruchomiony, lecz nie działa stabilnie
Każde zamknięcie miesiąca jest sytuacją kryzysową, użytkownicy powrócili do arkuszy kalkulacyjnych, a partner po uruchomieniu ograniczył zaangażowanie.
Utraciłeś zaufanie do partnera, ale nie chcesz rozpoczynać od początku
Chcesz wiedzieć, jaką część dotychczasowej pracy można wykorzystać, zanim podejmiesz decyzję o zmianie wykonawcy.
Potrzebujesz niezależnej drugiej opinii
Projekt jest kontynuowany z obecnym partnerem, lecz zarząd oczekuje zewnętrznej oceny planu, architektury i ryzyka przed uruchomieniem kolejnej transzy budżetu.
Wdrożenie w grupie międzynarodowej utraciło spójność między krajami
Każda spółka pracuje na innej wersji rozwiązania, wspólny rdzeń przestał być wspólny, a kolejne kraje oczekują na swoją kolej.
Pierwszy krok i punkt decyzji
Dwutygodniowy audyt projektu, który jednoznacznie określa, co przestało działać, co można zachować i ile kosztuje dokończenie. Stała cena, ustalony termin oraz rezultat, który należy do Ciebie i z którego możesz skorzystać z dowolnym partnerem.
Parametry
- Czas trwania: 2 tygodnie
- Forma: praca z zespołem projektowym, przegląd środowisk i dokumentacji, warsztaty z przedstawicielami biznesu
- Rozliczenie: stała cena, znana od początku
- Zobowiązania: brak; po audycie decydujesz, czy współpraca jest kontynuowana

Zakres
W ramach audytu badamy osiem obszarów: zakres i procesy biznesowe w odniesieniu do pierwotnych celów projektu; projekt rozwiązania i architekturę; kod i rozszerzenia, w szczególności ich odporność na aktualizacje i ingerencję w standard systemu; stan danych i podejście do migracji; integracje oraz sposób ich testowania; status testów i rejestr błędów; organizację projektu, procesy decyzyjne i ścieżki eskalacji; umowę, zespół i środowiska. Badanie prowadzimy według ram Success by Design, czyli metodyki Microsoft dla wdrożeń Dynamics 365, dzięki czemu porównujemy projekt z wzorcem, który producent uznaje za właściwy.


Jak przebiega audyt
- Spotkanie otwierające. Ustalamy, które problemy są najbardziej dotkliwe, kto podejmuje decyzje i jakie terminy są nieprzekraczalne.
- Przegląd dokumentacji i środowisk. Harmonogram, specyfikacje, kod, dane, rejestr błędów, konfiguracja.
- Warsztaty z kluczowymi użytkownikami. Weryfikujemy, jak system ma funkcjonować w rzeczywistej pracy, a nie wyłącznie w specyfikacji.
- Analiza techniczna. Kod, rozszerzenia, integracje, jakość danych, wydajność.
- Raport i rekomendacja. Co zachować, co naprawić, z czego zrezygnować. Z oszacowaniem kosztu i czasu.
- Prezentacja dla zarządu. Ustalenia przedstawione w języku decyzji biznesowych, nie technologii.

Co otrzymujesz na zakończenie
Raport z kluczowymi ustaleniami przedstawionymi bez łagodzenia wniosków, mapę ryzyk, rekomendację ścieżki postępowania obejmującą stabilizację, ponowne zaplanowanie, zmianę zakresu lub w wyjątkowych przypadkach ponowne wdrożenie, realny plan dokończenia projektu oraz szacunek kosztu do zakończenia. Jeśli wniosek z audytu brzmi, że projekt warto dokończyć z obecnym partnerem, również o tym usłyszysz.

Porozmawiajmy o audycie


Najpierw zatrzymaj eskalację problemów
Zanim przystąpimy do naprawy, projekt musi przestać generować nowe szkody. Porządkujemy to, co blokuje codzienną pracę, i przywracamy zasady podejmowania decyzji.

Bez zrywania relacji i bez rozpoczynania od początku
Przejęcie projektu wymaga ostrożności: dotyczy wiedzy, kodu, umów i relacji. Stosujemy procedurę, która chroni Twoją inwestycję i nie naraża Cię na przerwę w realizacji projektu.
- Co pozostaje, co naprawiamy, z czego rezygnujemy. Każdy element rozwiązania otrzymuje jedną z trzech kwalifikacji. W większości przypadków znacząca część rozwiązania pozostaje.
- Przekazanie wiedzy przed odejściem partnera. Przegląd kodu, dokumentacji i konfiguracji oraz rozmowy z dotychczasowym zespołem, jeśli okoliczności na to pozwalają.
- Dwa tryby współpracy. Pełne przejęcie projektu albo praca równolegle z obecnym partnerem w roli niezależnej kontroli jakości. Decyzję podejmujesz po audycie, nie przed nim.
- Umowy i licencje. Pomagamy uporządkować formalną stronę przejęcia: zobowiązania wynikające z obecnej umowy, kwestie licencyjne oraz ciągłość dostępu do środowisk.
- Bez ustalania winnych. Nie sporządzamy oceny poprzedniego wykonawcy. Sporządzamy plan dokończenia projektu.
Najczęstsze źródło problemów w projektach Finance and Operations
W większości przejmowanych projektów problem sprowadza się do dwóch lub trzech decyzji architektonicznych, które pociągają za sobą wszystkie pozostałe. Identyfikujemy je i usuwamy u źródła.
Rozszerzenia zamiast modyfikacji standardu
Kod napisany w sposób właściwy dla Dynamics AX, ingerujący w standardowe obiekty systemu, ulega uszkodzeniu przy każdej aktualizacji. Przebudowujemy go na rozszerzenia, które pozostają odporne na kolejne wydania.
Standard w pierwszej kolejności
Część modyfikacji odtwarza dawne obejścia, które nowy system miał wyeliminować. Tam, gdzie to możliwe, przywracamy funkcjonalność standardową i pozostawiamy wyłącznie te rozszerzenia, które dają rzeczywistą przewagę.
Plan kont, wymiary finansowe, rozliczenia wewnątrzgrupowe
Trzy obszary, w których błędna decyzja na początku projektu znajduje odzwierciedlenie w każdym raporcie. Korygujemy je, zanim przejdziemy dalej.
Integracje zaprojektowane na rzeczywiste wolumeny
Interfejsy testujemy pod obciążeniem i na wyjątkach procesowych, nie wyłącznie na ścieżce podstawowej.
Najczęstsza przyczyna przesunięcia uruchomienia
Dane są obszarem, w którym zatrzymuje się najwięcej projektów. Zwykle nie dlatego, że są trudne, lecz dlatego, że prace nad nimi rozpoczęto zbyt późno i prowadzono zbyt pospiesznie.
- Oczyszczanie u źródła, nie po załadowaniu. Kartoteki, kontrahenci, indeksy materiałowe, bilans otwarcia. Porządkujemy dane w dotychczasowym systemie, zanim trafią do nowego.
- Próbne migracje z uzgodnieniem. Każde załadowanie danych kończy się uzgodnieniem z systemem źródłowym. Bez zgodnych sald uruchomienie nie następuje.
- Migracja nie jest przeniesieniem wszystkiego. Nie przenosimy danych w relacji jeden do jednego. Wspólnie ustalamy, jaki zakres historii jest rzeczywiście potrzebny.
- Właściciele danych po stronie biznesu. Jakość danych jest odpowiedzialnością działów biznesowych, nie działu IT. Ustalamy role w sposób, który funkcjonuje również po uruchomieniu systemu.
Termin oparty na faktach, nie na oczekiwaniach
Nowy harmonogram budujemy od końca: od tego, co musi działać w dniu uruchomienia, przez testy, które to potwierdzą, po próbne przejścia produkcyjne, które wykażą gotowość.
- Zakres na uruchomienie i zakres po uruchomieniu. Rozdzielamy elementy niezbędne do rozpoczęcia pracy od tych, które mogą zostać dostarczone później. Ustalenia zapadają wspólnie z biznesem i są dokumentowane.
- Testy odzwierciedlające rzeczywistą pracę. Scenariusze z codziennej działalności, rzeczywiste dane, odbiory podpisywane dlatego, że rozwiązanie działa, a nie dlatego, że zbliża się termin.
- Próbne przejścia produkcyjne. Przed właściwym uruchomieniem wykonujemy pełne, mierzone próby startu. Każda kończy się listą poprawek i zmierzonym czasem wykonania.
- Decyzja o uruchomieniu na podstawie kryteriów. Uruchomienie następuje wtedy, gdy kryteria gotowości są spełnione. Nie wcześniej, nawet pod presją kosztów poniesionych w dotychczasowym projekcie.
Każdy tydzień zwłoki może kosztować więcej niż audyt
Rozpocznij od rozmowy, która pokaże rzeczywisty stan Twojego projektu.


Uruchomienie nie kończy procesu naprawy
Najwięcej problemów w przejętych projektach ujawnia się kilka tygodni po uruchomieniu, gdy zespół kryzysowy kończy pracę, a przedsiębiorstwo działa z pełną intensywnością. Dlatego pozostajemy na miejscu.
Wzmożona opieka po uruchomieniu
W pierwszym okresie po starcie zespół projektowy pozostaje do Twojej dyspozycji.
Pierwsze zamknięcie miesiąca wspólnie
Przechodzimy z Twoim zespołem przez pierwsze zamknięcie okresu i pierwszą konsolidację. To sprawdzian o największym znaczeniu.
Przekazanie do utrzymania
Po stabilizacji projekt przechodzi pod opiekę serwisową ANEGIS albo do Twojego zespołu. Z dokumentacją, która odpowiada stanowi faktycznemu.
Gotowość na aktualizacje
Rozwiązanie przekazujemy w stanie, w którym kolejne wydania Dynamics 365 nie stanowią zagrożenia dla ciągłości działania.

System, z którego użytkownicy chcą korzystać
W zagrożonych projektach użytkownicy zwykle zdążyli utracić zaufanie do systemu. Odbudowa adopcji jest odrębnym zadaniem, a nie uzupełnieniem szkoleń.
- Szkolenia z procesów, nie z ekranów. Uczymy pracy w konkretnej roli i w konkretnym procesie od pierwszego dnia, nie przeglądu funkcji systemu.
- Kluczowi użytkownicy jako sojusznicy. Włączamy ich w testy i decyzje, aby stali się ambasadorami rozwiązania, a nie jego krytykami.
- Koniec arkuszy równoległych do systemu. Identyfikujemy obejścia, które powstały w okresie kryzysu, i zastępujemy je rozwiązaniem w systemie.
- Zarządzanie zmianą jako element planu. Komunikacja, terminy, odpowiedzialności. Wpisane w harmonogram, nie dodane na jego końcu.

Gdy nie zamierzasz zmieniać partnera, lecz potrzebujesz pewności
Nie każdy zagrożony projekt wymaga przejęcia. Niekiedy wystarczy niezależna ocena, która powie zarządowi, czy plan jest realny, zanim zostanie uruchomiona kolejna transza budżetu.
Przegląd planu, architektury i ryzyk
Ocena wolna od konfliktu interesów, ponieważ nie ubiegamy się o ten projekt.
Stała rola kontroli jakości
Uczestniczymy w kluczowych punktach kontrolnych projektu i raportujemy bezpośrednio do sponsora.
Przegląd gotowości do uruchomienia
Niezależna ocena spełnienia kryteriów startu, zanim podejmiesz decyzję.
Przejście do pełnego przejęcia, jeśli zajdzie potrzeba
Jeśli druga opinia wykaże, że partner nie dostarczy rozwiązania, dysponujemy już wiedzą o projekcie i nie rozpoczynamy od początku.
Dlaczego naprawę projektu warto powierzyć nam

Zobacz jak zmieniamy firmy technologiczne
Modele współpracy
- Audyt ratunkowy w stałej cenie: dwa tygodnie, raport, plan i decyzja, bez zobowiązań.
- Pełne przejęcie projektu: prowadzimy naprawę od stabilizacji po uruchomienie i opiekę, etapami, z punktami decyzyjnymi.
- Niezależna druga opinia: stała rola kontroli jakości równolegle z obecnym partnerem, raportowanie do sponsora projektu.
- Wzmocnienie zespołu: tymczasowy kierownik projektu, architekt lub specjaliści w Twoim zespole, gdy problemem są zasoby, a nie partner.
- Opieka po uruchomieniu: pakiet stabilizacyjny, a następnie opieka serwisowa.












Każdy tydzień zwłoki może kosztować więcej niż audyt
Rozpocznij od rozmowy, która pokaże rzeczywisty stan Twojego projektu.


Zobacz inne usługi
Najczęstsze pytania o project recovery
Czy musimy rozpoczynać projekt od początku?
Nie. Większość wykonanej pracy zwykle można zachować. Audyt wskazuje dokładnie, które elementy pozostają, które naprawiamy, a z których rezygnujemy. Ponowne wdrożenie rekomendujemy wyłącznie wtedy, gdy naprawa kosztowałaby więcej niż rozpoczęcie od nowa.
Czy możecie pracować równolegle z naszym obecnym partnerem?
Tak, w roli niezależnej drugiej opinii lub kontroli jakości. O pełnym przejęciu projektu decydujesz po audycie, na podstawie jego ustaleń.
Ile trwa audyt i co otrzymuję?
Audyt trwa dwa tygodnie i jest rozliczany w stałej cenie. Otrzymujesz raport ustaleń, mapę ryzyk, rekomendację ścieżki postępowania, plan dokończenia oraz szacunek kosztu do zakończenia. Rezultat należy do Ciebie niezależnie od dalszej decyzji.
Ile trwa naprawa projektu?
Zależy to od ustaleń audytu. Typowe ścieżki obejmują od kilku tygodni stabilizacji po kilka miesięcy naprawy i ponownego planowania. Harmonogram przedstawiamy w raporcie z audytu, wraz z punktami decyzyjnymi.
Co z umową i licencjami u obecnego partnera?
Pomagamy uporządkować tę kwestię w ramach przejęcia. Przed audytem nie musisz niczego wypowiadać ani zmieniać konfiguracji środowisk.
Czy zajmujecie się również systemem, który został uruchomiony, lecz nie działa prawidłowo?
Tak. Jest to odrębny scenariusz: w pierwszej kolejności stabilizujemy działanie operacyjne, a następnie przystępujemy do naprawy architektury.
Czy przejmujecie projekty na Dynamics AX?
Tak, w tym wstrzymane migracje z Dynamics AX na Dynamics 365. Z systemem AX pracujemy od jego pierwszych wersji.
Jak zapewniana jest poufność?
Audyt jest niezależny i objęty poufnością. Nie kontaktujemy się z Twoim obecnym partnerem bez Twojej zgody.
Porozmawiajmy o Twoim projekcie
Napisz, z czym przychodzisz: wdrożenie, migracja, rozwój systemu albo pytanie, na które szukasz odpowiedzi. Wracamy z konkretną propozycją następnego kroku, nie z prezentacją handlową.































