Przed przystąpieniem do realizacji zadań, kluczowe jest odpowiednie przygotowanie. Podobnie rzecz ma się w przypadku projektów e-commerce, które niejednokrotnie są bardzo rozbudowane i kosztowne. Etapem przygotowawczym takich projektów jest analiza przedwdrożeniowa. Sprawne wdrożenie projektu, bez wcześniej przeprowadzonej analizy, jest praktycznie niemożliwe!
Spis treści:
1. Co to jest analiza przedwdrożeniowa?
Najprościej mówiąc, analiza przedwdrożeniowa jest obszernym dokumentem zawierającym specyfikację wdrożenia. Obejmuje ona m.in.: opis rynku, na którym działa firma, wymagania funkcjonalne projektu, harmonogram działań, które będą realizowane, a także kosztorys. Każdy realizowany przez nas projekt budowy platformy e-commerce B2B lub B2C rozpoczynamy od wykonania takiego dokumentu.
W zależności od stopnia złożoności projektu, przygotowanie analizy zajmuje od 30 do 60 dni roboczych.
1.1. Kto potrzebuje analizy?
Istnieją sytuacje, w których da się zrealizować projekt IT bez uprzedniego wykonania analizy przedwdrożeniowej przez zewnętrznego dostawcę usługi e-commerce. Ma to zazwyczaj miejsce w przypadku firm, które chcą wdrożyć u siebie szablonowe rozwiązania, o dużej powtarzalności. Takie, w których ustawienia w znacznej mierze da się “wyklikać” spośród gotowych opcji. Z wykonania analizy przedwdrożeniowej często rezygnują także firmy, które pilnie potrzebują wdrożyć u siebie oprogramowanie. Jest to jednak związane obarczone dużym ryzykiem powstania błędów.
By uniknąć błędów, zaleca się wykonanie analizy przedwdrożeniowej przed przystąpieniem do prac. Analiza jest niezbędna w każdej firmie, gdyż służy poznaniu procesów, określeniu jaki ma być przyszły e-commerce firmy oraz jak mają działać poszczególne elementy systemu. Na podstawie tych informacji firma wdrażająca będzie mogła zrealizować projekt IT. Analiza w tym przypadku to przełożenie wyobrażeń o e-commerce, które mają klienci, na język programowania, grafiki i usability.
1.2. Jak bardzo jest szczegółowa?
Nasze prace nad przygotowaniem analizy przedwdrożeniowej rozpoczynają się od opracowania obszarów ogólnych. Obejmują one przykładowo: cele projektu, charakterystykę branży, w której działa firma, ale także charakterystykę organizacji i użytkowników. Odpowiednie opracowanie tych informacji jest kluczowe, gdyż przekłada się na prawidłową realizację dalszych (już bardziej szczegółowych) części. Ma także wpływ na ostateczną realizację poszczególnych wymagań.
Po opracowaniu obszarów ogólnych, przygotowywane są te bardziej szczegółowe, tj. dotyczące wymagań funkcjonalnych i jakościowych. Są one opisywane dużo bardziej szczegółowo. Zwłaszcza wtedy, gdy pojawiają się wymagania, których nigdy wcześniej nie realizowaliśmy u innych klientów. W takich przypadkach niezbędna jest bardzo zaawansowana analiza, uwzględniająca elementy realizacji projektu, czyli: prototypy działania danej funkcjonalności, opis analityczny, fragmenty kodu, odpowiednio dobrane narzędzia, itd.
Najogólniej rzecz ujmując, analiza jest zbiorem danych dotyczących nie tylko tego CO ma być wdrożone, ale także JAK to będzie wdrożone.
W sytuacji, gdy wymagania danej firmy są szablonowe i nieskomplikowane programistycznie istnieje możliwość, by analiza została przygotowana na podstawie realizacji wykonywanych wcześniej.
1.3. Jak powstaje analiza przedwdrożeniowa?
1. Spotkanie inicjujące/ startowe –> mające na celu zdefiniowanie podstaw projektu
Jest to początkowe spotkanie, na którym wspólnie z klientem określamy cel projektu, a także to, jakie są procesy biznesowe, które ma obsługiwać docelowy e-commerce. Ze strony klienta w spotkaniach tym powinna brać udział osoba decyzyjna i finansująca projekt, która będzie zatwierdzała ustalenia. W przypadku dużych firm taką osobą zazwyczaj jest jej właściciel lub prezes zarządu. W mniejszych natomiast może być nią także osoba, która później będzie kierowała projektem.
Na spotkaniu startowym ustalana jest komunikacja oraz to, kto będzie uczestniczył w projekcie – kierownik projektu, ale także osoby, które będą uczestniczyły w poszczególnych jego etapach.
2. Zbieranie informacji do analizy
Niejednokrotnie bywa tak, że sposób, w jaki kierownik projektu opisuje procesy w firmie różni się od tego, jak ich realizacja wygląda faktycznie. Dlatego też tak ważne jest by na tym etapie – w zależności od wielkości firmy – porozmawiać z kilkoma osobami (w przypadku niewielkich firm) lub z wieloma (w przypadku tych większych). Konieczna jest także obserwacja tego, jak poszczególne procesy biznesowe wyglądają “na żywo”, czyli na przykład to, w jaki sposób przekazywane są informacje o realizacji zamówień, jak wyglądają poszczególne dokumenty, itd. Ilość etapów przygotowania analizy jest proporcjonalna do wielkości organizacji – im jest ona większa, tym tych etapów jest więcej.
3. Przygotowanie dokumentacji
Na kolejnym etapie przygotowywana jest dokumentacja. Zawiera ona wymagania, które konsultowane są kolejno z analitykami oraz grafikami, testerami i programistami. Dział techniczny przygotowuje częściowe rozwiązania dla poszczególnych wymagań. Przygotowywane są między innymi makiety, prototypy i fragmenty kodu. Ustalany jest również harmonogram działań oraz budżet (widełki cenowe “od – do”), tak by klient miał możliwość podjęcia decyzji o rozłożeniu projektu w czasie. Całość przygotowywana jest w formie dokumentu do prezentacji dla klienta.
4. Zatwierdzenie przez Klienta
Na ostatnim etapie analiza jest weryfikowana przez klienta. Jeżeli ma on jakieś uwagi, w dokumencie wprowadzane są zmiany. Jeżeli nie, następuje jej zatwierdzenie.
1.4. Analiza przedwdrożeniowa – koszt i wartość.
Jakie są koszty przygotowania analizy i od czego zależą?
Ostateczny koszt przygotowania analizy uzależniony jest od dwóch czynników: od tego jak duża jest organizacja oraz od powtarzalności projektu. Czas przygotowania dokumentu oraz koszt ustalane są przez nas indywidualnie dla każdego klienta.
Jaka jest wartość analizy?
- Zmniejszenie ryzyka – przy projektach o dużej skali, wartych na przykład kilkaset tysięcy złotych, wykonanie analizy za kilkanaście tysięcy (jest etapem, na którym można łatwo się wycofać) w znaczący sposób zmniejsza ryzyko niepowodzenia projektu.
- Przepływ know-how – połączenie i przepływ wiedzy – klienta, który zna swoją branżę oraz naszej dotyczącej e-commerce – jest kluczem do wdrożenia sklepu internetowego z sukcesem. Fakt jest taki, że my jako agencja e-commerce jesteśmy ekspertami właśnie w tej dziedzinie i bez wiedzy na temat branży, w której działa klient, specyfiki sprzedaży jego produktów oraz innych związanych z tym informacji, nie jesteśmy w stanie zaproponować odpowiednich narzędzi sprzedaży online. Podobnie jest w przypadku klienta – dopiero po przekazaniu mu przez nas wiedzy na temat e-commerce, może on ocenić, które z sugerowanych rozwiązań będą odpowiednie dla jego firmy.
- Zmniejszenie kosztów – w momencie, gdy znane są wszystkie wymagania i potrzeby, a także wiemy, ile będą kosztowały dane funkcjonalności, można w łatwy sposób zdecydować, gdzie ograniczyć koszty. Przeprowadzając prace analityczne można znaleźć takie rozwiązania, które będą optymalne zarówno dla klienta, jak i dla firmy wdrażającej.
- Punkt odniesienie do wyboru dostawcy – oferty od różnych dostawców mogą być porównywane, tylko gdy dokumentacja jest przygotowana w języku zrozumiałym dla całej branży IT. Gdy klient nie ma takiej “bazy”, od różnych dostawców może otrzymać oferty różniące się bardzo pod względem jakościowym i cenowym. A będzie to wynikało z faktu, że te same wymagania będą wyceniane różnie przez różnych dostawców.
2. Analiza przedwdrożeniowa – z czego się składa?
2.1. Komunikacja
W analizie konieczne jest określenie kto i na którym etapie będzie miał dostęp do poszczególnych danych. Gdy w projekcie będzie uczestniczyło zbyt wiele osób, może to doprowadzić do pojawienia się problemów i błędów w codziennej komunikacji. Ze względu na rozbieżność interesów poszczególnych osób mogą pojawić się także spory.
Uczestnikami projektu są oczywiście pracownicy firmy, która wdraża e-commerce oraz pracownicy przedsiębiorstwa klienta. Jednak oprócz nich, w projekcie mogą brać udział również firmy, z którymi dokonywane są integracje (np. systemy ERP) lub podwykonawcy. Konieczne jest określenie zakresu dostępu do przebiegu projektu w stosunku do nich, ale także tego, w jakim zakresie i w jaki sposób będzie przebiegała komunikacja z otoczeniem. Przykładowo z firmą, która była poprzednim dostawcą platformy, a także z innymi klientami.
Kluczowe jest także określenie project managerów oraz osób decyzyjnych we wszystkich firmach, które będą uczestniczyły w projekcie. By komunikacja przebiegała sprawnie należy wskazać dane kontaktowe do tych osób oraz narzędzia, które będą wykorzystywane do komunikacji. W przypadku projektów prowadzonych przez naszą firmę komunikacja prowadzona jest w aplikacji Redmine. Dzięki niej praca nad projektem jest całkowicie przejrzysta i transparentna.
2.2. Cel analizy przedwdrożeniowej
Zaczynając prace wdrożeniowe należy postawić pytanie – po co chcemy mieć e-commerce, a także co dzięki niemu chcemy osiągnąć, czyli tak naprawdę zdefiniować cel projektu. Bardzo często firma, która chce wdrożyć u siebie e-commerce ma wyobrażenie, jak on będzie działał. Nie uzmysławia sobie jednak, jakie problemy ma rozwiązywać lub też w którym kierunku rozwijać ich firmę.
Można powiedzieć, że powodzenie projektu zależne jest od ustalenia, jaki jest jego CEL. Dlaczego? Sprawa jest prosta – jeżeli firma, która będzie przeprowadzała wdrożenie systemu będzie widziała, jak coś ma działać, to oczywiście wykona to w dokładnie taki sposób, w jaki ma to działać. Jeżeli jednak będzie wiedziała po co, dlaczego i jaki jest cel, zupełnie zmieni to sytuację. W odniesieniu do celu dobierane będą odpowiednie funkcjonalności oraz określana będzie specyfikacja całego systemu. Określenie celu pozwoli także na sprawdzenie za jakiś czas, w jakim stopniu został on osiągnięty.
Znajomość celu pozwoli wszystkim ludziom biorącym udział w projekcie – poczynając od analityków, przez project managerów, kończąc na back-end developerach – samodzielnie dobierać odpowiednie środki i narzędzia, ale także podejmować różnego rodzaju decyzje. Tak więc, jak widzisz, zdefiniowanie celu projektu jest niezmiernie istotne.
2.3. Charakterystyka użytkowników
Najprostszym sposobem na określenie charakterystyki użytkownika jest stworzenie profilu, który będzie zawierał dane na temat tego, kim on jest.
Rodzajów użytkowników jest kilka:
- konsument docelowy (B2C);
- klient biznesowy (B2B);
- administratorzy platformy – dział handlowy, dział marketingu, magazyn, dział obsługi klienta.
W jakim celu profil tworzony jest dla każdej z grup? Po to, by:
- każdy użytkownik projektu wiedział i pamiętał, kto będzie korzystał z systemu w przyszłości;
- z uwzględnieniem ich potrzeb i charakterystyki tworzone były wymagania funkcjonalne systemu. Przykładowo, jednym z takich wymagań może być możliwość pobrania z systemu informacji dotyczących tras, którymi transportowane są zamówienia do klientów. Dla działów takich jak dział marketingu, dział obsługi klienta, czy też dla pracowników magazynu wymaganie to może być szczególnie ważne. Na przykład, by możliwe było wyeksportowania danych nt. dat i godzin składania zamówień, danych o lokalizacjach.
2.4. Procesy biznesowe
Pierwszym najistotniejszym etapem przygotowywania analizy jest zebranie wszystkich procesów biznesowych, które zachodzą w firmie (czyli na przykład: ofertowanie, realizacja zamówień czy też dostaw) i dokładne ich opisanie.
Niejednokrotnie bywa tak, że firmy, które działają na rynku już od wielu lat, mają wypracowane swoje metody działania. Każdy z pracowników wie, co należy do jego zadań i obowiązków, przepływ informacji również odbywa się bez problemów. Jednak nie jest to nigdzie w żaden sposób spisane. Aby procesy te mogły być odwzorowane przez firmę wdrożeniową w systemie do sprzedaży online, niezbędnym jest ich usystematyzowanie i dokładne opisanie w jednym dokumencie. W tym celu konieczne jest przeprowadzenie wielu spotkań i rozmów z osobami, które uczestniczą w danym procesie oraz “wyciągnięcie” od nich szczegółów na temat ich codziennej pracy oraz sposobu wykonywania danych czynności. Dla tych osób, ze względu na to, że mają z tym do czynienia na co dzień, są to informacje oczywiste. Dla projektantów e-commerce są natomiast kluczowe!
Konieczne jest zebranie informacji na temat tego:
- kto bierze udział w poszczególnych procesach,
- jak długo te procesy trwają,
- jaka jest droga przepływu danej informacji,
- na których etapach w procesie uczestniczy klient docelowy,
- co dostaje ten klient, itd.
Firma wdrożeniowa dopiero, gdy posiada te informacje jest w stanie odwzorować procesy w firmie lub zgodnie z celem zaprojektować je na nowo, czyli ogólnie rzecz biorąc – prawidłowo zaprojektować działanie e-commerce w danym przedsiębiorstwie.
2.5. Wymagania funkcjonalne
Dotyczą one tego, czy dana funkcja ma istnieć czy nie. W wymaganiach funkcjonalnych zebrane zostają funkcje, które w systemie mają się pojawić oraz te, których zdecydowanie ma nie być (te drugie uwzględnione są również w części “Ograniczenia”). Określenie tego, co musi się znaleźć w systemie jest ważne. Jednak równie istotne jest określenie tego, czego w systemie ma nie być.
Gdy znane są już wszystkie wymagania funkcjonalne można określić, ile będą one kosztowały. Możliwe jest także podjęcie decyzji czy będą finalnie realizowane, a jeżeli tak – to na którym etapie.
2.6. Wymagania jakościowe
W wymaganiach jakościowych określana jest jakość wykonania danej funkcji oraz to, w jaki sposób zostanie zrealizowana. Wymaganiem takim może być na przykład waga strony lub szybkość jej ładowania. Wymagania funkcjonalne, o których pisaliśmy wyżej, są zdecydowanie bardziej techniczne i “twarde”. Natomiast te są bardziej elastyczne i “miękkie”.
Oba rodzaje wymagań – jakościowe i funkcjonalne – są wzajemnie od siebie zależne, muszą ze sobą współgrać. Dla przykładu – grafika nawiązująca do wybranego motywu jest wymaganiem jakościowym. W przypadku, gdy zostanie stworzona bardzo zaawansowana grafika, dodane zostaną odpowiednie widgety, wymaganie to zostanie zrealizowane. Jednak gdy Google nie będzie widział części tych treści, nie będzie spełnione wymaganie funkcjonalne SEO. Może też być tak, że strona będzie ładowała się 20 sekund, zatem wymaganie te będzie sprzeczne z innym wymaganiem jakościowym.
W przypadku braku wymagań jakościowych w stosunku do danych wymagań funkcjonalnych, warto tę informację umieścić w analizie przedwdrożeniowej po to, by było to wiadome dla obu stron projektu.
2.7. Interfejsy użytkownika
Określają one, w jaki sposób system łączy się ze swoimi użytkownikami. Z racji tego, że każda grupa użytkowników ma swoje potrzeby i wymagania, system ma wiele interfejsów, a każdy z nich jest dopasowany do potrzeb danej grupy.
Przygotowując analizę, w tej części określamy: jakie funkcjonalności i uprawnienia będą posiadały konkretne interfejsy. Przygotowujemy również ich wizualizacje i prototypy (np. strona kategorii, producenta czy towaru).Z uwagi na fakt, że interfejsy użytkowników przygotowywane są na etapie analizy, jesteśmy w stanie zachować spójność z wymaganiami jakościowymi i funkcjonalnymi. Gdy wszystkie wymagania są już zebrane i ustalone, do komunikacji w projekcie włącza się grafik. Sprawia to, że wiemy, jak dokładnie ma wyglądać dany interfejs. Zarówno back-end (tj. panel administracyjny), jak i front-end.
2.8. Interfejsy programowe
Są nimi wszystkie integracje, czyli sposób w jaki platforma przeprowadza z zewnętrznymi aplikacjami komunikację jedno lub dwustronną. Na przykład z oprogramowaniami magazynowymi, produkcyjnymi, księgowymi. Mowa tutaj również o oprogramowaniach, które wspierają e-commerce (np. live chaty, porównywarki cenowe i powszechnie znane Google Analytics).
Interfejsy programowe są opisywane, ale także wizualizowane w formie czytelnych diagramów (np. schemat generowania etykiet na produkcji).
2.9. Interfejsy sprzętowe
W interfejsach sprzętowych ustalamy, w jaki sposób platforma komunikuje się bezpośrednio z jakimś sprzętem. Przykładowo z drukarką etykiet (czyli urządzeniem wyjścia) lub ze skanerem (czyli urządzeniem wejścia).
2.10. Ograniczenia
Wspominaliśmy już o nich przy okazji wymagań jakościowych i funkcjonalnych (opisanych wyżej). W ograniczeniach umieszczane są te elementy, których ma nie być w projektowanej platformie. Brak niektórych funkcjonalności w systemie może być dla klientów tak samo oczywiste, jak to, że pewne funkcjonalności w nim istnieją. Dlatego też konieczne jest wypunktowanie tych, które nie będą wdrażane. Jakie to mogą być funkcjonalności? Przykładowo: brak rejestracji dla klientów przed dokonaniem zakupów, brak wersji językowych lub brak dostępności aplikacji na smartwatchach.
Pojawiające się w projekcie ograniczenia mogą być jednocześnie ułatwieniami w jego realizacji. Bardzo często bywa tak, że brak danych funkcjonalności może wpływać na większą elastyczność systemu, sama realizacja jest mniej skomplikowana, a przez to także tańsza. Przykładowo:
- wyłączenie monitorowania zmian w cennikach, które wykonywane są z dużą częstotliwością sprawia, że system nie jest obciążony, a dzięki temu działa też szybciej.
- ograniczenia dostępności serwisu do 95%, co również daje możliwość wprowadzenia znaczących oszczędności.
Klient najlepiej zna swoją firmę, jej otoczenie i związane ze swoją działalnością potrzeby. Dlatego też szukanie oszczędności zawsze powinno odbywać się wspólnie z nim.
2.11. Testy
Opisanie planowanych testów jest bardzo ważne z punktu widzenia klienta. Daje mu to pewność, że podczas projektowania systemu zachowana jest duża dbałość o szczegóły oraz że utrzymywana jest wysoka jakość. Testy przeprowadzane są na poziomie całego projektu, jak i na poziomie poszczególnych zadań.
Testy wydajnościowe
Przeważnie przeprowadzane są one na końcu projektu. Wtedy gdy system jest już gotowy, działa ze wszystkimi funkcjonalnościami, dzięki czemu możemy spojrzeć na niego i występujące pomiędzy poszczególnymi jego składowymi zależności, w sposób całościowy. Gdyby takie testy wykonane zostały wcześniej, musielibyśmy opierać się wyłącznie na przyjętych założeniach i prototypach.
Testy jednostkowe
Ten rodzaj testów wykonywany jest przez programistów przez praktycznie cały czas trwania projektu. Mają one na celu sprawdzenie, czy podstawowe elementy konkretnego modułu funkcjonują poprawnie. Testy jednostkowe dopisywane są do poszczególnych funkcji systemu. Przykładowo, w module koszyka zakupowego konieczne jest przetestowanie pewnych stałych elementów, jak choćby nierealizowanie zamówień przy wartości koszyka 0,00. Każda kolejna wprowadzona zmiana, wiąże się z wykonaniem testów jednostkowych. Testy są zautomatyzowane i dzięki nim zachowana jest spójność między konkretnymi modułami.
Testy akceptacyjne
Mają one na celu sprawdzenie, czy to co zostało przez klienta zamówione, faktycznie zostało zrealizowane. Testy akceptacyjne mogą być przeprowadzone zarówno po stronie klienta, jak i po naszej. Przeprowadzając ten rodzaj testów należy ponownie dokładnie przejrzeć wszystkie wymagania i sprawdzić, czy zostały one zrealizowane. To, czy poszczególne wymagania funkcjonalne zostały wykonane, określane jest w sposób zero-jedynkowy.
Testy mogą być przeprowadzone również przez klienta. W takim przypadku należy ustalić z nim ich przebieg. Wszystko po to, by testy aplikacji u nas odbywały się w ten sam sposób, co u klienta.
Istnieje także możliwość, by klient został włączony w testy, które są przeprowadzane przez naszą firmę. W takiej sytuacji, w każdym momencie klient ma możliwość wglądu w pracę testera.
Checklisty
W ramach testów tworzymy także checklisty, działające podobnie do testów jednostkowych. Różnica pomiędzy nimi polega na tym, że testy przeprowadzane są przez programistę, a checklisty realizuje tester.
W ramach checklisty ustalana jest lista funkcji. Jest ona testowana za każdym razem, nawet przy najprostszej zmianie, którą wprowadzamy do systemu. Dzięki temu wszystkie błędy eliminowane są od razu, a klient wie, że kluczowe funkcjonalności w jego e-commerce działają poprawnie. W miarę rozwoju projektu do stworzonej na początku podstawowej checklisty, dodawane są kolejne kluczowe punkty. Na przykład gdy pojawiają się błędy, których nie można było przewidzieć. Testy przeprowadzane zgodnie z przygotowaną checklistą zajmują dużo czasu, jednak warto. Dają pewność i bezpieczeństwo prac nad projektem.
2.12. Podsumowanie projektu
Jest to element, który powinien znaleźć się z każdej analizie. Podsumowanie jest opisem zawierającym:
- cel projektu;
- informacje na temat tego, które narzędzia zostaną użyte;
- opis kluczowych funkcjonalności znajdujących się w systemie;
- harmonogram działań.
Dlaczego podsumowanie projektu jest tak ważne? Dzięki niemu wszyscy użytkownicy aplikacji, zarówno ci obecni, jak i przyszli, będą mogli zapoznać się z podstawowymi informacjami dotyczącymi przeprowadzonego wdrożenia. Gdy zajdzie taka potrzeba będą mogli przejść do wybranego fragmentu i zapoznać się tylko z nim, lub jeżeli zechcą – z całym dokumentem.
Analiza jest niezbędna!
Podstawą sprawnie wdrożonego projektu IT jest uprzednio wykonana analiza przedwdrożeniowa. Oczywiście możesz spróbować zrealizować go bez przeprowadzania analizy, jednak wiąże się to z dużym ryzykiem. Projekty e-commerce są z reguły bardzo rozbudowane i kosztowne. By uniknąć błędów oraz zbędnych kosztów, przed przystąpieniem do prac odpowiednio się do nich przygotuj, wykonując analizę.
Masz pytania dotyczące analizy przedwdrożeniowej? Chciałbyś dowiedzieć się czegoś więcej na jej temat? Skontaktuj się z nami. Chętnie Ci doradzimy i pomożemy przygotować analizę.
Zamów analizę przedwdrożeniową >>