25 rzeczy, o których nigdy nie wspomni dostawca oprogramowania

Według raportu Panorama Consulting z 2016 roku dotyczącego oprogramowania dla przedsiębiorstw tylko 57% respondentów uważa swoje nowe oprogramowanie za „sukces”.

Kierując się tymi 25 krokami, łatwiej zbudujesz zaufanie i zapewnisz pomyślne rezultaty wdrożenia projektu Microsoft Dynamics 365.

1. W świecie Dynamics 365 istnieją poważne niedobory zasobów. Dostawcy grają w grę „przynęta i zmiana”, na początek delegując swoich najlepszych pracowników na prezentacje sprzedażowe lub rozpoczęcia projektów, a następnie stopniowo zastępując ich mniej kompetentnymi osobami. Z trudem zdobyta w komunikacji z klientem wiedza przekazywana między zespołami podczas cyklu sprzedaży zostaje w większości stracona. Nalegaj na model sprzedawca=opiekun klienta, w którym dostawca wyznacza jeden, niezmienny zespół, który zajmuje się klientem od początku do końca, a w przypadku zmian w zespole gwarantowane jest bezpłatne wdrożenie nowej osoby.
2. W procesie wdrażania produktu nie ma miejsca na tajemnice. Należy z góry wyraźnie zadeklarować swój budżet i nalegać, aby dostawca powiedział, czy cele projektu mogą być osiągnięte przy podanych założeniach. Zbyt piękne, żeby było prawdziwe? Nie bój się zadawać trudne pytania zarówno przy niskich, jak i wysokich wycenach. Nieuniknione jest, że coś zostanie pominięte.
3. Partnerzy systemu Dynamics 365 zrealizowali wiele projektów i mają wiedzę o tym, jaki będzie odpowiedni budżet i harmonogram przy danych celach projektu. Ustal budżet, harmonogram lub ambitne cele, ale nie dyktuj tych wszystkich trzech czynników bez zasięgnięcia porady doświadczonego praktyka.
4. Upewnij się, że dostawca poczyni znaczne inwestycje w celu dostarczenia Twojego systemu zgodnie z założeniami i w ustalonych ramach czasowych. Nalegaj na rozsądnej wysokości raty płatności realizowane po wykonaniu i dostarczeniu ważnych etapów projektu, ale zachowaj uczciwe podejście co do zakresu ryzyka i poziomu wynagrodzenia.
5. Unikaj pokusy rozpoczynania projektu od długotrwałego procesu sprzedaży, próbując zrozumieć wszystkie wymagania w celu zapewnienia maksymalnie dokładnych wycen i zobowiązań od dostawców. Chociaż pozornie wydaje się to dobrym pomysłem, tak szczegółowe podejście do zapytania ofertowego bardziej prawdopodobnie zakończy się klęską projektu. Może się tak stać, ponieważ zapytanie ofertowe i projekt systemu będą bazować na procesach i funkcjach w stanie, w jakim się znajdują („as-is”), które mogą zupełnie stracić znaczenie, kiedy zostaną zniwelowane przez właściwości nowego systemu.
6. Wykonanie dobrej pracy wymaga adekwatnej ilości czasu. Wcześniej niekoniecznie oznacza lepiej. Znacznie bardziej korzystne jest ustalenie zakresu projektu i zbudowanie mapy funkcyjnej projektu o odpowiednim stopniu szczegółowości, aby ułatwić opracowanie przyszłego projektu w okresie przedsprzedażowym.
7. Nie martw się przesadnie znalezieniem dostawcy, który ma doświadczenie z najnowszą wersją Twojego systemu. Rodzina Dynamics 365 ewoluuje nieustanie od 16 pełnych i częściowych wersji przez ostatnie 27 lat. Większość praktyków, którzy pracowali z co najmniej dwiema lub trzema wersjami, powinna wiedzieć, jak przeprowadzić adaptację wersji najnowszej. W praktyce oznacza to, że każda ważna wersja to 2-letni cykl, a ponieważ ukończenie większości dużych projektów zajmuje ok. 2 lata, nigdy nie znajdziesz specjalisty doświadczonego w projektach w zakresie najnowszej wersji. Po prostu upewnij się, że dostawca jest w stanie przeprowadzić adaptację nowej wersji.
8. Wielu dostawców zrobi wszystko, żeby uniknąć odpowiedzialności wobec Twojej firmy. Nigdy nie zgadzaj się na podpisanie umowy, w której zapis o macierzy odpowiedzialności (ang. RACI) nie obejmuje partnera.
9. Odsprzedawcy Microsoft Dynamics 365 są ekspertami w wydobywaniu prawdy od opornych właścicieli procesów. Dzień spędzony na analizie funkcjonalnej bez wkładu Twojego dostawcy jest dniem straconym. Jego zespół będzie musiał przejść przez tę analizę ponownie i zadawać niezręczne pytania, których Twoi pracownicy mogli nie mieć odwagi zadać. Co gorsza, Twoi eksperci zniechęcą się, będąc zmuszeni do zajmowania się ponownie tymi samymi zagadnieniami.
10. Strzeż się konsultantów, którzy spieszą się do fazy projektowej rozwiązania bez pełnego zrozumienia całości działalności biznesowej (włącznie z niepowodzeniami). Pominięte wymagania mogą spowodować konieczność kompletnego przeprojektowania — a tego rodzaju zmiany na ostatnią chwilę kosztują dziesięć razy więcej niż na etapie ustalania wymagań, ponieważ wszystko musi zostać przekodowane i ponownie przetestowane.
11. Rozmawiaj z każdym liderem zespołu projektowego i zadawaj im podchwytliwe pytania dotyczące Twoich procesów. Wybierz jakieś mało znane funkcje Dynamics 365 (w bazie TechNet) i zapytaj ich o zaprojektowanie procesu wykorzystującego tę funkcję. Jeśli powiedzą, że wymagane jest przeprogramowanie, masz do czynienia z amatorami.
12. Poproś zespół odsprzedawcy o wyjaśnienie różnicy między funkcją a procesem (funkcja pomaga osiągnąć cel biznesowy; proces to sposób, w jaki ten cel jest osiągany). Jeśli nie potrafią wyraźnie tego odróżnić, Twój projekt nigdy nie spełni założonych oczekiwań.
13. Przygotuj warsztaty dotyczące wymagań z opisami scenariuszy biznesowych i przykładami wykorzystania. Każdy potrafi utworzyć dokumentację procesu sprzedaży/płatności/odbioru czy wysyłki. Musisz skoncentrować się na tych niekomfortowych przypadkach procesów, które powodują duże straty pieniędzy i czasu, jeśli są źle przeprowadzone. To z nich bierze się przede wszystkim Twój zwrot z inwestycji.
14. Nigdy nie zgadzaj się na umowę wdrożenia dostawcy bez wyraźnie wymienionych elementów dostawy i ceny każdego elementu — po jednym do każdego celu biznesowego. Nie akceptuj mglistych obietnic związanych z „pomocą” przy dostawie, „wspieraniem” Twojego zespołu lub „zarządzaniem” celami. Płacisz dostawcy za zaprojektowanie, zbudowanie, skonfigurowanie, wypełnienie danymi, skorygowanie, dostarczenie, wdrożenie oraz zagwarantowanie działania Twojego systemu. Nie akceptuj oferty niezawierającej wszystkich tych elementów.
15. Odsprzedawcy zarabiają znaczną marżę na sprzedaży licencji i mogą być zachęcani do realizacji kwartalnych celów sprzedaży Microsoft. Nie ma żadnego rozsądnego sposobu na przewidzenie wymagań licencyjnych klienta przed przeprowadzeniem analizy i pełnym zdefiniowaniem zmian projektowych i organizacyjnych. Całkowicie wykonalne i realne jest rozpoczęcie wersji aplikacji od systemu na 10 użytkowników i dodawanie nowych dopiero wtedy, kiedy będzie to konieczne. Będziesz płacić opłaty za wsparcie Microsoft do każdej licencji od pierwszego dnia ich zakupu, co daje zero zwrotu z inwestycji. Nie pozwól, żeby odsprzedawca wywierał na Tobie presję kupowania zawyżonej liczby licencji „na wyrost”.
16. Prawidłowo funkcjonujący lider projektu musi zaplanować i uzgodnić wszystkie funkcje biznesowe przed zaprojektowaniem rozwiązania.
17. Projekt musi być napisany zrozumiałym językiem (żadnych niewyjaśnionych skrótów) i zawierać: 1) schemat zakresu i wycenę procesów według obecnego stanu; 2) Przyszłe scenariusze biznesowe i przypadki testowe; 3) Harmonogram wymagań funkcjonalnych; 4) Harmonogram wdrożenia wyraźnie określający, jak zostaną spełnione wymagania (wersja standardowa/konfiguracja/wymagania szkoleniowe/sposoby rozwiązywania problemów/programowanie); 5) Klarowną i zwięzłą specyfikację każdego elementu projektu.
18. Nie pozwól odsprzedawcy na rozpoczęcie prac, dopóki właściciele procesów po Twojej stronie nie zatwierdzą i podpiszą specyfikacji — bez żadnych wyjątków.
19. Pamiętaj, że na projekt musisz przeznaczyć odpowiednie zasoby. Poproś w swoim biurze, żeby zgłosiły się osoby, które mogą przeznaczyć 50% swojego czasu... Nie łudź się, że duży projekt oprogramowania może być zrealizowany wyłącznie przez właścicieli procesów i administratorów, którzy już i tak mają zajęty cały dzień. Tak: musisz zaangażować w prace projektowe swoich najlepszych ludzi.
20. Przeprowadź porządkowanie i czyszczenie danych TERAZ. Główną przyczyną przekładania uruchomienia projektu jest źle zaplanowana i źle przeprowadzona migracja danych. Jeśli nie jesteś w stanie zapanować nad danymi, kiedy nic Cię nie pogania, nie masz szans nad nimi zapanować, kiedy pojawi się pośpiech i presja.
21. Dobrzy pracownicy są drodzy i dostawcy będą chcieli podzielić pracę swoich najlepszych ludzi między kilka różnych projektów. Nie będą w stanie dostarczyć Ci optymalnych rezultatów prac, zajmując się nimi tylko w te wybrane dni, kiedy dla Ciebie pracują. Nalegaj, aby zespół był kompletny i pozostawał kompletny na czas ważnych sprintów pracy.
22. Przygotuj się odpowiednio na duży nakład pracy przy testowaniu po dostarczeniu pierwszej wersji Twojego oprogramowania. Jeśli nie możesz przetestować oprogramowania, konfiguracji, migracji danych i ustawień bezpieczeństwa niezwłocznie po dostarczeniu systemu, Twoja gwarancja może wygasnąć długo zanim zostaną wykryte defekty.
23. Upewnij się, że system dostawcy rejestruje konkretne dane o poszczególnych celach biznesowych/obszarach interwencji, i nalegaj na raporty z postępów w każdy poniedziałek rano. Takie raporty muszą obejmować procentowe wartości stanu realizacji zadań lub czas pozostały do zakończenia prac. Reaguj na opóźnienia, jak tylko się pojawią. Zarezerwuj sobie prawo do wymiany członków zespołu, którzy nie radzą sobie z pracą.
24. Zmiany zakresu to wróg realizacji ograniczonego czasowo i budżetowo projektu. To proste równanie. Zakres musi być dokładnie opisany bez wyjątków... albo upewnij się, że masz bardzo dużo pieniędzy lub wyrozumiały zarząd, aby udźwignąć konsekwencje zmian.
25. Nie ignoruj zarządzania projektami — zarówno Ty, jak i odsprzedawca będziecie potrzebować dobrego kierownika projektów. I przygotuj się na finansowanie obu. Twój kierownik projektów musi być asertywny, zmotywowany i mieć odpowiednie uprawnienia, aby podejmować decyzje prowadzące projekt do mety. We wdrażaniu systemu Dynamics 365 nie ma miejsca na święte krowy.

‍