Problemy przy wdrożeniach IT rzadko wynikają wyłącznie z jednego błędu technicznego. Najczęściej są konsekwencją kilku nakładających się zaniedbań: niejasnego celu, niedostatecznej analizy, nieprecyzyjnego zakresu, opóźnionych decyzji, niekontrolowanych zmian albo niewystarczających testów.
Dotyczy to zarówno wdrażania stron internetowych i sklepów e-commerce, jak również systemów B2B, paneli klienta, aplikacji webowych oraz integracji z ERP, CRM i innymi zewnętrznymi usługami.
Niewłaściwe przygotowanie projektu może prowadzić do:
Nie każdego problemu da się przewidzieć. Można jednak znacząco ograniczyć ryzyko, jeżeli przed rozpoczęciem prac zostaną ustalone cele, zakres, odpowiedzialność, sposób podejmowania decyzji, plan testów oraz zasady dalszego utrzymania systemu.
Nieudane wdrożenie rzadko zaczyna się w momencie publikacji systemu. Pierwsze błędne decyzje zapadają zazwyczaj znacznie wcześniej: podczas definiowania celu, przygotowywania zapytania, wyboru wykonawcy albo ustalania zakresu.
Problem polega na tym, że skutki tych decyzji nie zawsze są widoczne od razu. Nieprecyzyjne wymaganie może ujawnić się dopiero podczas programowania. Brak planu migracji danych staje się poważnym problemem tuż przed uruchomieniem. Źle dobrana architektura może przez wiele miesięcy działać poprawnie, a następnie utrudnić wdrożenie kolejnych funkcji.
Udane wdrożenie nie oznacza wyłącznie tego, że strona, sklep lub system został opublikowany. Rozwiązanie powinno:
Dlatego ocenianie powodzenia projektu wyłącznie na podstawie terminu publikacji może prowadzić do błędnych wniosków. System uruchomiony szybko, ale wymagający natychmiastowej przebudowy, nie jest udanym wdrożeniem.
„Chcemy nową stronę internetową”, „potrzebujemy sklepu” albo „chcemy wdrożyć platformę B2B” nie są jeszcze celami biznesowymi. Opisują rodzaj rozwiązania, ale nie wyjaśniają, jaki problem ma ono rozwiązać.
Inaczej należy zaplanować stronę, której głównym zadaniem jest zwiększenie liczby zapytań ofertowych, a inaczej serwis mający uporządkować ofertę międzynarodowej firmy, obsłużyć wiele wersji językowych i wspierać rekrutację.
Podobnie system B2B może służyć do:
Dobry cel powinien określać oczekiwaną zmianę w biznesie. Może nią być zwiększenie sprzedaży, skrócenie czasu obsługi, automatyzacja powtarzalnego procesu, ograniczenie liczby błędów albo zapewnienie użytkownikom dostępu do danych bez udziału pracownika firmy.
Cel nie musi od razu zawierać precyzyjnej wartości procentowej. Powinien jednak pozwalać odpowiedzieć na pytanie: po czym poznamy, że wdrożenie przyniosło oczekiwany efekt?
Rozpoczęcie developmentu bez wcześniejszego uporządkowania wymagań może pozornie skrócić początek projektu. W praktyce często oznacza, że analiza jest wykonywana fragmentami już podczas programowania, a każda nowa informacja wymusza zmianę wcześniej przygotowanych elementów.
Analiza przedwdrożeniowa powinna objąć przede wszystkim:
Jeżeli projekt ma zastąpić obecnie wykorzystywane rozwiązanie, analiza powinna również objąć jego ograniczenia, dane wymagające przeniesienia oraz procesy, które nie mogą zostać przerwane podczas uruchomienia nowego systemu.
Celem analizy nie jest stworzenie jak najdłuższego dokumentu. Powinna ona uporządkować decyzje, które mają wpływ na architekturę, zakres, budżet i harmonogram.
Szerzej opisujemy ten etap w poradniku wyjaśniającym, na czym polega analiza przedwdrożeniowa i jakie ustalenia powinny powstać przed rozpoczęciem developmentu.
Lista funkcji nie zawsze jest wystarczającą specyfikacją projektu. Sformułowania takie jak „integracja z ERP”, „panel klienta”, „wyszukiwarka produktów” albo „import danych” mogą być rozumiane na wiele różnych sposobów.
Przykładowo informacja, że system ma umożliwiać import produktów, nie wyjaśnia:
Im bardziej ogólny zapis, tym większe ryzyko, że klient i wykonawca inaczej zrozumieją oczekiwany rezultat.
Dlatego dla najważniejszych funkcji warto określić kryteria odbioru. Powinny one opisywać, w jakich warunkach funkcja zostanie uznana za prawidłowo wykonaną. Pozwala to ograniczyć spory interpretacyjne i przygotować konkretne scenariusze testowe.
Nie oznacza to, że przed rozpoczęciem projektu trzeba przewidzieć każdy szczegół. Ważne jest jednak rozróżnienie pomiędzy:
Niska cena sama w sobie nie oznacza, że oferta jest niewłaściwa. Może jednak wynikać z mniejszego zakresu, innych założeń albo pominięcia etapów, które w pozostałych ofertach zostały uwzględnione.
Porównując oferty, należy sprawdzić nie tylko końcową kwotę, ale również:
Dwie oferty mogą dotyczyć pozornie tego samego systemu, ale jedna będzie obejmowała jedynie development, a druga także analizę, UX/UI, testy, migrację, wdrożenie i opiekę po publikacji.
Różnice pomiędzy zakresem, modelem współpracy i rzeczywistym budżetem szerzej omawiamy w artykule o tym, ile kosztuje software house.
Nie każdy projekt powinien być realizowany według tych samych zasad. Problemem nie jest sam wybór modelu Fixed Price lub Time & Material, ale zastosowanie go bez uwzględnienia poziomu niepewności i dojrzałości zakresu.
Fixed Price może dobrze sprawdzić się wtedy, gdy:
Przy projekcie, którego wymagania będą doprecyzowywane podczas realizacji, sztywna cena może prowadzić do sporów o to, czy dana zmiana znajduje się jeszcze w zakresie. Wykonawca może również uwzględnić w cenie dodatkowy bufor związany z ryzykiem.
Time & Material zapewnia większą elastyczność, ale wymaga:
Przy rozbudowanych wdrożeniach dobrym rozwiązaniem może być także etapowanie projektu. Pierwszy etap obejmuje funkcje niezbędne do uruchomienia i zweryfikowania rozwiązania, natomiast kolejne są realizowane na podstawie rzeczywistych danych i informacji od użytkowników.
Przeanalizujemy cel, zakres, integracje, dane, ryzyka i możliwe etapy realizacji. Dzięki temu łatwiej ocenisz realny budżet i ograniczysz kosztowne zmiany podczas developmentu.
Projekt IT wymaga po stronie klienta osoby, która rozumie jego cel i ma możliwość podejmowania lub koordynowania decyzji. Nie musi znać technologii ani samodzielnie tworzyć specyfikacji technicznej.
Właściciel biznesowy powinien:
Problem pojawia się wtedy, gdy decyzje wymagają każdorazowo konsultacji z wieloma osobami, ale żadna z nich nie odpowiada za ostateczne stanowisko. W efekcie wykonawca otrzymuje niespójne uwagi, zaakceptowane wcześniej elementy wracają do ponownej analizy, a projekt zatrzymuje się w oczekiwaniu na decyzję.
Duża liczba osób uczestniczących w projekcie nie zastępuje jasno określonej odpowiedzialności. Informacje z kilku działów powinny zostać zebrane i uporządkowane przed przekazaniem ich zespołowi projektowemu.
Zmiany podczas realizacji nie muszą oznaczać, że projekt został źle zaplanowany. Część nowych potrzeb pojawia się dopiero po zobaczeniu makiet, pierwszych działających funkcji albo wyników testów.
Błędem jest natomiast wdrażanie każdej nowej propozycji bez oceny jej wpływu na pozostałą część projektu.
Każda istotna zmiana powinna zostać przeanalizowana pod kątem:
Dobrym rozwiązaniem jest prowadzenie backlogu oraz rozdzielanie funkcji na elementy niezbędne, ważne i możliwe do realizacji w przyszłości. Pozwala to uniknąć sytuacji, w której pierwsza wersja systemu stale się rozrasta i nigdy nie osiąga gotowości do uruchomienia.
Jeżeli nowa funkcja ma wejść do bieżącego etapu, warto świadomie zdecydować, czy zwiększa budżet i termin, czy zastępuje inne zadanie o niższym priorytecie.
System może być zgodny ze specyfikacją i jednocześnie niewygodny dla osób, które będą z niego korzystać. Dzieje się tak szczególnie wtedy, gdy wymagania są przygotowywane wyłącznie na poziomie zarządczym, bez rozmowy z pracownikami wykonującymi dany proces na co dzień.
Projektując rozwiązanie, warto sprawdzić:
UX nie oznacza wyłącznie estetycznego interfejsu. Obejmuje architekturę informacji, kolejność działań, komunikaty, formularze, obsługę błędów oraz dopasowanie systemu do rzeczywistego sposobu pracy.
Jeżeli użytkownik musi wykonywać więcej kroków niż wcześniej albo nie rozumie nowych komunikatów, może zacząć omijać system i wracać do arkuszy, e-maili lub ręcznych notatek.
Integracja z ERP, CRM, PIM, systemem magazynowym, płatnościami lub zewnętrznym API nie jest pojedynczym przełącznikiem. To proces wymiany danych pomiędzy rozwiązaniami, które mogą mieć odmienną strukturę, ograniczenia i sposób działania.
Przed rozpoczęciem integracji należy ustalić:
Przykładowo cena produktu może pochodzić z ERP, opis z systemu PIM, a stan magazynowy z dodatkowego źródła. Bez jednoznacznego określenia odpowiedzialności łatwo doprowadzić do nadpisywania danych lub prezentowania niespójnych informacji.
Integracja powinna być testowana nie tylko dla standardowego, prawidłowego przypadku. Należy również sprawdzić brakujące dane, błędne formaty, powtórzone komunikaty, opóźnienia i czasową niedostępność zewnętrznego systemu.
Migracja bywa traktowana jako czynność techniczna wykonywana tuż przed uruchomieniem nowego rozwiązania. W rzeczywistości jej przygotowanie powinno rozpocząć się znacznie wcześniej.
Najpierw trzeba ustalić:
W przypadku sklepu internetowego migracja może obejmować produkty, warianty, zdjęcia, kategorie, klientów, zamówienia, kupony, dokumenty i historię zmian. Samo skuteczne zaimportowanie rekordów nie oznacza jeszcze, że dane są kompletne i prawidłowo powiązane.
Przed uruchomieniem należy wykonać przynajmniej jedną migrację testową. Pozwala ona ocenić czas operacji, wykryć problemy z mapowaniem oraz przygotować procedurę walidacji.
Trzeba również zaplanować okres pomiędzy migracją testową a produkcyjną. Jeżeli w starym systemie nadal pojawiają się nowe zamówienia lub zmiany, konieczne jest ustalenie sposobu przeniesienia danych przyrostowych albo czasowego zatrzymania wybranych operacji.
Testy nie powinny być pojedynczym etapem wykonywanym dopiero po zakończeniu całego developmentu. Im później wykryty zostanie problem, tym większy może być koszt jego poprawienia.
Kontrola jakości powinna obejmować między innymi:
W projektach e-commerce należy sprawdzać pełne scenariusze zakupowe: od wyszukania produktu, przez koszyk i płatność, po przesłanie zamówienia do zewnętrznego systemu.
W przypadku systemu B2B osobnych testów mogą wymagać indywidualne ceny, limity kupieckie, role użytkowników, dostęp do dokumentów, synchronizacja stanów oraz składanie zamówień w nietypowych sytuacjach.
Klient powinien otrzymać czas i środowisko do przeprowadzenia testów akceptacyjnych. Ich celem nie jest powtarzanie pracy zespołu developerskiego, lecz potwierdzenie, że rozwiązanie odpowiada rzeczywistym procesom organizacji.
Publikacja systemu nie powinna polegać na przypadkowym przeniesieniu plików na serwer produkcyjny. Im bardziej projekt wpływa na sprzedaż lub codzienne procesy firmy, tym dokładniej trzeba zaplanować uruchomienie.
Plan go-live powinien określać:
Rollback, czyli możliwość powrotu do wcześniejszej wersji, powinien być zaplanowany przed rozpoczęciem publikacji. Nie wystarczy wiedzieć, że istnieje kopia zapasowa. Trzeba również ustalić, ile czasu zajmie jej przywrócenie i co stanie się z danymi wprowadzonymi już po uruchomieniu nowej wersji.
W przypadku systemów przetwarzających zamówienia lub dane użytkowników trzeba dodatkowo uwzględnić ryzyko utraty albo podwójnego zapisania operacji.
Technicznie poprawnie działający system może nie osiągnąć celu, jeżeli użytkownicy nie wiedzą, dlaczego został wdrożony i jak mają z niego korzystać.
Przygotowanie organizacji może obejmować:
Szkolenie nie powinno sprowadzać się do jednorazowego pokazania wszystkich funkcji. Użytkownicy potrzebują przede wszystkim wiedzy dotyczącej zadań, które będą rzeczywiście wykonywać.
Warto również przygotować się na to, że pierwsze dni po wdrożeniu mogą ujawnić nietypowe scenariusze niewystępujące podczas testów. Powinien istnieć sposób ich szybkiego zgłaszania, oceny i priorytetyzacji.
Uruchomienie strony, sklepu lub systemu nie kończy jego cyklu życia. Z czasem zmieniają się procesy biznesowe, oferta, wymagania użytkowników, przepisy, usługi zewnętrzne i technologie.
Jeżeli rozwiązanie od początku jest traktowane jako zamknięty projekt, łatwo pominąć:
Nie oznacza to, że od razu trzeba zbudować system przygotowany na każdy hipotetyczny scenariusz. Nadmierne projektowanie przyszłości również zwiększa koszt i komplikuje rozwiązanie.
Ważniejsze jest rozdzielenie funkcji potrzebnych obecnie od możliwych kierunków rozwoju oraz unikanie decyzji, które całkowicie zablokują ich późniejszą realizację.
Dobrym podejściem jest przygotowanie roadmapy obejmującej pierwszą wersję, rozwój po uruchomieniu i obszary wymagające ponownej oceny na podstawie danych.
System może działać prawidłowo w dniu uruchomienia, a następnie stopniowo tracić stabilność. Przyczyną mogą być zmiany w API, wygasające certyfikaty, rosnąca liczba danych, nowe wersje komponentów, błędy integracji albo problemy z infrastrukturą.
Po wdrożeniu należy określić:
Monitoring techniczny powinien być uzupełniony kontrolą kluczowych procesów. Sama dostępność strony nie oznacza, że prawidłowo działają płatności, formularze, wysyłka wiadomości, synchronizacja produktów lub przekazywanie zamówień do ERP.
Uruchomienie systemu rozpoczyna etap jego dalszej eksploatacji. Sprawdź, na czym polega maintenance stron, sklepów i systemów IT i dlaczego warto uwzględnić go już w początkowym budżecie projektu.
Nie istnieje pojedyncza procedura gwarantująca, że w projekcie nie pojawią się żadne problemy. Można jednak przygotować proces, dzięki któremu ryzyka zostaną wcześniej zauważone, a ich wpływ będzie łatwiejszy do kontrolowania.
Przed rozpoczęciem prac warto:
Ważnym elementem jest także bieżące zarządzanie ryzykiem. Lista zagrożeń nie powinna być dokumentem przygotowanym tylko na początku projektu. Należy ją aktualizować, gdy pojawiają się nowe informacje, zmienia się zakres albo występują problemy z zależnościami zewnętrznymi.
W Webtom.pl traktujemy wdrożenie jako proces obejmujący nie tylko programowanie, ale również przygotowanie założeń, projektowanie doświadczeń użytkownika, integracje, testowanie, publikację oraz późniejszy rozwój rozwiązania.
Zakres procesu dopasowujemy do skali projektu. Prosta strona internetowa nie wymaga takiej samej dokumentacji jak system B2B z indywidualnymi cenami, wieloma rolami użytkowników i integracją z ERP. W obu przypadkach konieczne jest jednak określenie celu, odpowiedzialności i kryteriów odbioru.
Przed rozpoczęciem developmentu porządkujemy wymagania i identyfikujemy elementy, które mogą wpłynąć na architekturę, budżet lub termin. Dotyczy to szczególnie:
Rozbudowane projekty dzielimy na etapy, dzięki czemu najważniejsze funkcje mogą zostać uruchomione wcześniej, a kolejne decyzje są podejmowane na podstawie wyników i informacji od użytkowników.
W trakcie realizacji wykorzystujemy środowiska testowe, kontrolujemy wersje kodu oraz weryfikujemy działanie przygotowywanych funkcji. Przed publikacją ustalamy zakres testów akceptacyjnych, sposób migracji oraz działania wykonywane podczas uruchomienia.
Po wdrożeniu możemy odpowiadać za monitoring, utrzymanie, optymalizację i rozwój rozwiązania. Dzięki temu wiedza zgromadzona podczas projektu nie jest tracona w dniu jego publikacji.
Poszczególne etapy, role i zasady komunikacji szerzej przedstawiamy w poradniku pokazującym, jak wygląda współpraca z software house krok po kroku.
Przykłady stron, sklepów oraz bardziej rozbudowanych wdrożeń można zobaczyć wśród wybranych realizacji Webtom.pl.
Największe problemy przy wdrożeniach IT rzadko wynikają wyłącznie z samej technologii. Najczęściej ich źródłem są niejasne cele, niedostateczna analiza, nieprecyzyjny zakres, opóźnione decyzje, niekontrolowane zmiany oraz testowanie rozpoczęte zbyt późno.
Ryzyko rośnie również wtedy, gdy integracje i migracja danych są traktowane jako proste zadania techniczne, a uruchomienie systemu odbywa się bez przygotowanego planu, monitoringu i możliwości bezpiecznego wycofania zmian.
Aby ograniczyć problemy podczas wdrożenia, należy przede wszystkim:
Dobre wdrożenie nie polega na przewidzeniu każdej możliwej sytuacji. Polega na stworzeniu procesu, który pozwala odpowiednio wcześnie wykrywać ryzyka, podejmować świadome decyzje i ograniczać skutki pojawiających się zmian.
W Webtom.pl pomagamy uporządkować projekt przed rozpoczęciem prac, zaplanować jego etapy, przygotować UX/UI, wdrożyć funkcje oraz integracje, przeprowadzić testy i zapewnić dalsze utrzymanie rozwiązania.
Przekroczenie budżetu najczęściej wynika z niepełnych założeń, zmian zakresu, nieuwzględnionych integracji, problemów z danymi albo opóźnionych decyzji. Koszt może wzrosnąć również wtedy, gdy podczas realizacji ujawniają się procesy i wyjątki, które nie zostały opisane na początku.
Ryzyko można ograniczyć przez analizę, etapowanie projektu, prowadzenie backlogu oraz każdorazową ocenę wpływu nowych funkcji na budżet i harmonogram.
Zakres analizy powinien być proporcjonalny do skali i ryzyka projektu. Prosta strona oparta na jasno określonym zakresie nie wymaga tak rozbudowanego procesu jak system B2B, integracja z ERP lub sklep obsługujący tysiące produktów.
Nawet przy mniejszym projekcie warto jednak ustalić cel, strukturę, wymagane funkcje, odpowiedzialność za treści, kryteria odbioru i sposób późniejszego utrzymania.
Po stronie klienta powinna zostać wyznaczona osoba odpowiedzialna za cel biznesowy, priorytety oraz zebranie informacji od pozostałych interesariuszy. Nie musi samodzielnie podejmować wszystkich decyzji, ale powinna koordynować ich uzyskiwanie.
Brak jednej osoby odpowiedzialnej prowadzi często do sprzecznych uwag, wielokrotnego wracania do zaakceptowanych elementów i opóźnień.
Nie trzeba całkowicie blokować zmian. Należy natomiast prowadzić backlog i oceniać każdą nową propozycję pod względem wartości, kosztu, terminu oraz zależności.
Zmiana może zostać dodana do bieżącego etapu, zastąpić inną funkcję albo trafić do kolejnej wersji. Najważniejsze jest podejmowanie tej decyzji świadomie, a nie automatyczne rozszerzanie projektu.
Fixed Price daje przewidywalność wtedy, gdy zakres jest dobrze zdefiniowany i nie będzie znacząco zmieniany. Przy dużej liczbie niewiadomych sztywna cena może zawierać dodatkowy bufor albo prowadzić do sporów dotyczących zakresu.
W projektach rozwijanych iteracyjnie większą kontrolę może zapewnić Time & Material połączony z limitem budżetu, regularnym raportowaniem oraz priorytetyzacją zadań.
Testowanie powinno rozpocząć się wraz z pierwszymi gotowymi funkcjami, a nie dopiero po zakończeniu całego developmentu. Wczesna weryfikacja pozwala szybciej wykryć błędne założenia i ograniczyć koszt poprawek.
Przed uruchomieniem należy dodatkowo przeprowadzić testy całych procesów, integracji, migracji, wydajności oraz testy akceptacyjne po stronie klienta.
Plan powinien określać kolejność działań, osoby odpowiedzialne, sposób wykonania kopii bezpieczeństwa, migrację danych, konfigurację usług, testy po publikacji oraz monitoring.
Powinien również zawierać procedurę wycofania zmian, jeżeli podczas uruchomienia pojawi się problem uniemożliwiający bezpieczne korzystanie z systemu.
Przy większej ilości danych lub istotnych informacjach biznesowych migracja testowa jest zdecydowanie rekomendowana. Pozwala wykryć problemy z formatem, mapowaniem, duplikatami i powiązaniami pomiędzy rekordami.
Dzięki próbie można również oszacować czas migracji produkcyjnej i przygotować sposób weryfikowania danych po jej zakończeniu.
Tak, szczególnie jeżeli rozwiązanie wspiera sprzedaż, obsługę klientów lub wewnętrzne procesy firmy. Trzeba ustalić zasady aktualizacji, monitoringu, wykonywania kopii bezpieczeństwa i obsługi błędów.
Warto również rozdzielić utrzymanie stabilności od rozwoju nowych funkcji. Są to dwa różne rodzaje prac, które mogą wymagać odmiennego planowania i budżetu.
Etapowanie pozwala wcześniej uruchomić najważniejsze funkcje i zweryfikować przyjęte założenia. Ogranicza także ryzyko inwestowania dużego budżetu w elementy, które nie zostały jeszcze sprawdzone w praktyce.
Nie każdy system musi jednak rozpoczynać się od bardzo ograniczonego MVP. Pierwsza wersja powinna zawierać kompletny zestaw funkcji niezbędnych do bezpiecznego przeprowadzenia wybranego procesu.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Sprawdź, jak przygotować się do współpracy z software house. Poznaj checklistę, uniknij błędów i lepiej zaplanuj projekt IT.
Poznaj w jaki sposób realizujemy projekty i dowiedz się czym jest metoda MoSCoW.
Na czym polega maintenance WordPress? Sprawdź, dlaczego aktualizacje, bezpieczeństwo i stałe utrzymanie strony internetowej są kluczowe dla stabilności systemu.
Dobra strona internetowa to nie tylko wygląd. Sprawdź cechy skutecznej strony firmowej: UX, szybkość, responsywność, treści, SEO, WordPress, technologia i rozwój.
Share:
