Analizy IT w projektach e-commerce B2B: Klucz do sukcesu wdrożenia

Gdy zaczynasz projekt technologiczny, szukasz informacji o produktach. Na stronach dostawców dowiadujesz się, że przeprowadzają analizy. Jedni wykonują analizę biznesową, przedwdrożeniową, inni przeprowadzają warsztaty projektowe lub sprint analityczny. Co to jest, czym się różni i czy jest Ci potrzebne? W tym artykule znajdziesz kompleksowe informacje na temat analiz w projektach IT. Tłumaczę pojęcia, specyfikę różnych form przeprowadzania analiz oraz z czego wynikają różnice w tym, co proponują firmy IT.

Z tego artykułu dowiesz się:

• Jakie są formy analiz w projektach IT?
• W jakiej metodyce prowadzone są projekty technologiczne?
• SaaS a open source – produkty i projekty a metodyka
• Co to jest sprint analityczny?
• Co to jest analiza biznesowa IT?
• Na czym polegają warsztaty projektowe?
• Co to jest analiza przedwdrożeniowa?
• Czym różni się analiza biznesowa IT od analizy biznesowej jako takiej?
• Misz masz w nazewnictwie w branży IT

[13 minut czytania]

Zaczynamy 👊

Jakie są formy analiz w projektach IT?

Zacznijmy od różnych form analiz, jakie są przeprowadzane w projektach technologicznych. Najczęściej spotkasz się z analizą biznesową lub analizą przedwdrożeniową. Często mają one jeszcze dodatek „IT” na końcu, aby podkreślić, jakich projektów dotyczą. Rzadziej zetkniesz się ze sprintem analitycznym, warsztatami projektowymi czy analizą projektu. Nazw może być więcej, w zależności od tego, w jakiej metodyce dana firma pracuje i przeprowadza analizy. O metodykach dowiesz się więcej w kolejnej części artykułu.

Można się pogubić. Nie wiadomo, czy wszystkie te analizy to tak naprawdę to samo, tylko inaczej nazwane? Czy może inne nazwy wskazują, że kryje się pod nimi coś innego? Ale co? W dalszej treści artykułu dowiesz się szczegółowo, o co w tym wszystkim chodzi.

W jakiej metodyce prowadzone są projekty technologiczne?

Oprogramowanie w większości przypadków jest wytwarzane w metodyce zwinnej Agile. Rzadko zdarzają się projekty, w których system jest produkowany według zasad metodyki kaskadowej. W zakresie zarządzania projektami IT wykorzystuje się różne metody. W Internecie spotkasz też określenie metodologia. Bardzo często tych terminów używa się nieprawidłowo. Gubią się w tym nawet osoby z branży. A co dopiero Ty?

Na początek wyjaśnię różnice między tymi trzema określeniami: metodologia, metodyka i metoda.

Metodologia – to najszersze pojęcie, o podłożu naukowym, dotyczące aspektu teoretycznego. Jak podaje Słownik Języka Polskiego jest to „nauka o metodach badań naukowych stosowanych w danej dziedzinie wiedzy”.

Metodyka – to pojęcie z zakresu praktycznego. Oznacza „zbiór zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu”.

Metoda – to pojęcie najwęższe, które oznacza sposób wykonania czegoś. Nie można zatem postawić znaku równości między pojedynczą metodą a metodyką.

W projektach IT będziemy mieć do czynienia z metodyką i różnymi metodami stosowanymi w ramach danej metodyki.

Spotkasz się jeszcze z pojęciem framework. Oznacza ono strukturę, szkielet, model. Jest de facto metodą, wykorzystywaną w ramach metodyki.

Przejdźmy teraz do najczęściej spotykanych metodyk: Agile (zwinnej) i Waterfall (kaskadowej, tradycyjnej). Nazw podanych w nawiasach używa się zamiennie. Teraz w dużym skrócie napiszę, na czym się skupiają te metodyki.

Metodyka zwinna (ang. agile) to zbiór metod produkcji oprogramowania opartego na programowaniu iteracyjno-przyrostowym. Kluczowym aspektem wytwarzania oprogramowania jest założenie, że wymagania wobec systemu mogą się zmieniać w czasie jego wytwarzania. Dlatego praca odbywa się w cyklach, które powinny się zakończyć zaprezentowaniem działającej formy produktu.

W metodyce zwinnej funkcjonuje wiele metod pracy. Najbardziej popularną jest framework Scrum. Jako metoda pracy jest skonkretyzowany i zdyscyplinowany. Ma określone fazy, tzw. iteracje, czyli cykle produkcyjne. Pojedyncza iteracja to sprint. Trwa on zazwyczaj 2 tygodnie, ale zawsze tyle samo, ile zostało ustalone na początku projektu. Każdy sprint ma określone fazy produkcji oprogramowania – od planowania, przez wytwarzanie, testy, po przegląd sprintu i uruchomienie.

Metodyka kaskadowa (waterfall, tradycyjna) to podejście przyrostowe, ale nie iteracyjne. W procesie produkcji oprogramowania przechodzi się przez kolejne, odrębne i zamknięte etapy (fazy) wytwarzania produktu. Te etapy to takie schodki, kaskady. Kolejny etap produkcji następuje po zakończeniu poprzedniego. Zaczynamy od fazy planowania, w której musimy przewidzieć i opisać pełne wymagania wobec produktu. Gotowy i działający produkt otrzymujemy na końcu procesu produkcji.

Metodyka kaskadowa sprawdzi się w niedużych projektach IT, w których nie ma skomplikowanych wymagań i nie powstaje system innowacyjny, a coś sprawdzonego już rynkowo i powtarzalnego.

Każda z tych metodyk ma swoje zalety i wady. Jeśli chcesz się dowiedzieć więcej na ten temat, obejrzyj lekcję 9 mojego darmowego kursu „Jak współpracować z dostawcą IT, żeby się dogadać”.

Jak się do tych metodyk mają analizy, o których pisałam na początku artykułu? Dwie z funkcjonujących nazw są powiązane z metodykami i odnoszą się do początkowego (pierwszego) etapu procesu wytwarzania oprogramowania. W metodyce kaskadowej mamy analizę przedwdrożeniową, a w metodyce zwinnej możesz się spotkać ze sprintem analitycznym. W dalszych częściach artykułu omówię każdą z tych form, żeby można było je między sobą porównać.

SaaS a open source – produkty i projekty a metodyka

Zanim przejdę do różnych rodzajów analiz w projektach IT, krótki fragment poświęcę różnym sposobom wytwarzania i udostępniania oprogramowania klientom. Dowiesz się, dlaczego nie zawsze wiesz, jak to wszystko działa. To żadna wiedza tajemna. Po prostu nie zawsze jako klient bierzesz udział w procesie produkcji oprogramowania. A przynajmniej nie bezpośrednio. Ok, do rzeczy.

Zacznijmy od tego, że system, który chcesz wdrożyć może być:

• gotowym produktem, bez opcji modyfikacji na zamówienie, czyli wyprodukowania czegoś dedykowanego dla Twojej firmy (tzw. developmentu) – opcja SaaS (software as a service), w e-commerce takie produkty, jak np. Shoper, Idosell czy wiele innych; potocznie nazywa się te produkty „pudełkami”,
• gotowym produktem z opcją dedykowanych zmian lub dorobienia funkcjonalności pod klienta, tzw. opcja SaaS Enterprise – występuje często w e-commerce B2B,
• szkieletem produktu, na którym buduje się system, dostępnym w opcji open source (otwartej, darmowej) lub w opcji płatnej, jeśli posiada zaawansowane moduły, wymagające bieżącego utrzymania i aktualizacji, kluczowe dla konkretnego segmentu klientów; przykładem takiego systemu dla e-commerce jest Magento,
• koncepcją systemu, z którą przychodzisz do firmy IT, aby wyprodukowała coś zupełnie nowego, dedykowanego pod Twoje zamówienie.

Opcji udostępniania oprogramowania jest więcej, ale na potrzeby tego artykułu ograniczymy się do dwóch: SaaS i open source. W podejściu SaaS masz do czynienia z produktem. W pozostałych przypadkach opisanych powyżej wchodzisz w projekt IT, w którym będzie wytwarzane oprogramowanie. W opcji SaaS system należy do firmy IT (dostawcy), a Ty z niego tylko korzystasz. W drugiej opcji system należy do Ciebie, bo agencja IT, która produkuje go dla Ciebie, przekazuje Ci do niego majątkowe prawa autorskie.

Jakie są jeszcze różnice? Takie na przykład, że w przypadku produktu należącego do dostawcy (opcja SaaS) nie bierzesz bezpośrednio udziału w procesie wytwarzania oprogramowania. Kupujesz subskrypcję, uczysz się używać, płacisz abonament i korzystasz. Jak z Netflixem.

Nad tym, jak wygląda produkt czuwa Product Manager. Jako klient masz pośredni wpływ na sposób działania produktu. Możesz zgłaszać swoje uwagi zmian. Dostawca powinien też odpytywać klientów i śledzić na bieżąco trendy i zmiany w branży, aby dostosowywać oprogramowanie do potrzeb rynku. To dostawca decyduje, jak będzie wyglądał produkt. Dostosowuje go też do tego, jakich klientów i z jakich branż ma na platformie.

W przypadku systemów bazujących na oprogramowaniu open source lub budowanych od zera wchodzisz w projekt IT jako strona bezpośrednio zaangażowana w proces produkcji. Tym razem nie oglądasz fabryki zza płotu, tylko wchodzisz do środka i uczestniczysz w projekcie. Tutaj bezpośrednio zetkniesz się z metodyką produkcji oprogramowania.

Czy w opcji SaaS, produktowej w ogóle nie zetkniesz się z metodyką wytwarzania systemu? W przypadku produktów, w których nie ma opcji zmian lub produkcji dedykowanych funkcjonalności raczej się z tym nie spotkasz. W przypadku wersji Enterprise już tak. Jeśli podczas wdrożenia systemu wyjdzie, że produkt nie posiada czegoś i trzeba to dorobić, a dostawca wyraża na to zgodę, to element ten będzie wytwarzany zgodnie z metodyką i cyklem pracy produkcji.

Czy produkty SaaS i produkowane projektowo są wytwarzane w różnych metodykach? W obydwu przypadkach mamy do czynienia z procesem produkcji oprogramowania, w wyniku którego powstaje produkt. Firmy IT – te wytwarzające własne produkty i te pracujące projektowo dla klientów – pracują w przeważającej większości w metodyce zwinnej (Agile).

To skąd w IT wzięła się metodyka kaskadowa? Metodyka kaskadowa była historycznie pierwsza, wcześniejsza niż metodyka zwinna. Została wprowadzona i opisana w 1970 roku. Ale inżynieria oprogramowania, jak każda dyscyplina, rozwijała się i ewoluowała, dostosowując się do zmieniającego się otoczenia biznesowego, projektowego i produkcyjnego. Metodyka zwinna została ogłoszona w 2001 roku w manifeście agile.

Metodyki te powstały zagranicą. W Polsce w latach 80. pojawiły się pierwsze komputery osobiste. W 1991 roku Polska została podłączona do sieci Internet. Po przemianach gospodarczych 1989 roku w Polsce pojawiły się zagraniczne firmy handlujące sprzętem i oprogramowaniem komputerowym. W latach 90. powstały pierwsze firmy informatyczne w Polsce, a jednym z problemów był niedobór nauczycieli informatyki w szkołach. Wiele firm upadło.

Polskie przedsiębiorstwa (z różnych branż) pracowały i budowały swoje biznesy w sposób tradycyjny. Wiele z nich działa tak do dziś. Dlatego metodyka kaskadowa jest tak silnie zakorzeniona w polskich biznesach. Branża IT przeszła ogromny skok na przestrzeni ostatnich 25 lat. I tutaj, podobnie jak w bankowości, gdzie ominęły nas czeki, przyjęliśmy nową metodykę wytwarzania oprogramowania z całym dobrodziejstwem jej inwentarza.

Tym krótkim rysem historycznym kończę tę część artykułu. W kolejnej dowiesz się, co jest i na czym polega sprint analityczny – pierwsza faza projektu IT w metodyce zwinnej (Agile).

Co to jest sprint analityczny?

Dla przypomnienia, sprint to powtarzający się cykl wytwarzania oprogramowania. Najdłużej może trwać miesiąc. Zazwyczaj trwa 2 tygodnie. Na początku projektu zespół przyjmuje długość trwania sprintu, która zostaje taka sama do końca projektu. Określenie pochodzi z frameworka Scrum, który jest najbardziej popularny w branży IT.

Produkcja oprogramowania składa się z wielu sprintów. Możesz spotkać się z nazwą sprint analityczny, którą firmy określają pierwszy etap projektu, trwający od 2 do 4 tygodni, czyli tyle samo, co sprint w Scrumie. Jest to czas pracy Analityka biznesowego (Business Analyst), w którym zespół zapoznaje się z potrzebami, wymaganiami oraz oczekiwaniami klienta. W tym etapie ustalany jest sposób realizacji projektu. Powstają zarys harmonogramu, mapy procesów biznesowych oraz integracji. Podejmowane są decyzje, w jakiej kolejności będą wytwarzane poszczególne elementy systemu. Spisany zostaje plan wdrożeniowy  i harmonogram, na podstawie których powstanie Backlog, czyli lista zadań z konkretnych obszarów, które będą przypisywane w danym sprincie do konkretnego programisty.

I tu pojawia się problem, bo w Scrumie nie ma czegoś takiego jak sprint analityczny. Nie ma też takiej roli jak Analityk biznesowy. W większości przypadków Analityk biznesowy pracuje poza zespołem scrumowym. To pracownik firmy IT, ale stojący „po stronie” klienta i biznesu.

Dlaczego zatem firmy używają tego określenia? Przypuszczam, że dlatego, aby podkreślić, w jakiej metodyce pracuje dana firma IT. Słowo „sprint” jest nierozerwalnie kojarzone z metodyką zwinną.

Inną nazwą, której używają firmy IT jest analiza biznesowa, która dla klientów brzmi już bardziej zrozumiale. Jednak bez dodatku „IT” również wprowadza ich w błąd. Szczegółowo omawiam to w dalszej części artykułu.

Firmy IT pracujące projektowo i wytwarzające systemy dedykowane dla konkretnego klienta przeprowadzają analizy w początkowym etapie projektu. Nazywane są one sprintem analitycznym lub analizą biznesową IT.

Jak to jest w opcji SaaS? W przypadku rozwiązań SaaS Enterprise – tam, gdzie istnieje możliwość wyprodukowania funkcjonalności specjalnie dla Ciebie – przeprowadza się najczęściej analizę biznesową IT lub warsztaty projektowe.

Co to jest analiza biznesowa IT?

Przychodzi klient do dostawcy IT… i mówi, że chce wdrożyć e-commerce B2B. Dostawca odpowiada: zrobimy Wam prezentację produktu. Klient siedzi, ogląda i co rusz pyta, czy to można tak, a tamto jeszcze inaczej? Project Manager zmienia w locie konfigurację i pokazuje, jak bardzo zaawansowany mają system. Jeden, drugi klik i gotowe. Nagle klient rzuca bombę. Bo u niego ten proces to właściwie wygląda inaczej.

Opowiastka z cyklu „przychodzi … do lekarza”, ale pokazuje, jak to często wygląda. Brałam udział w mnóstwie takich prezentacji, wiele z nich sama przeprowadziłam. W trakcie procesu handlowego mogą się pojawić informacje, które wskazują na to, że produkt będzie wymagał dostosowania do specyfiki klienta. Jeśli dostawca rozpoznaje „grubsze” zmiany i nie ma pewności, że będzie w stanie je zrealizować, a klient przychodzi bez żadnego dokumentu z wymaganiami, to proponuje mu wykonanie analizy biznesowej.

W tym miejscu muszę zwrócić uwagę na to, że istnieją różnice między analizą biznesową IT a analizą biznesową jako taką. Firmy IT, z racji tego, że są „IT”, skracają delikatnie nazwę tej analizy, co niejednokrotnie wprowadziło klientów w błąd. Różnice opisuję w jednej z kolejnych części artykułu.

Analiza biznesowa IT to de facto analiza przedwdrożeniowa, o której więcej dowiesz się w kolejnej części artykułu. Może być przeprowadzona przed pójściem do dostawcy oprogramowania, w Twojej firmie lub u konkretnego dostawcy. Z dalszej części artykułu dowiesz się, jakie są różnice obydwu podejść, ich wady i zalety.

Na czym polegają warsztaty projektowe?

Warsztaty projektowe są wykonywane w tym samym etapie projektu IT, co sprint analityczny czy analiza biznesowa IT, czyli na początku. Najczęściej wykonują je dostawcy oprogramowania SaaS, w którym istnieje opcja modyfikacji czy dorobienia dedykowanych funkcjonalności.

Warsztaty, jak nazwa sama wskazuje, są krótsze, mniej formalne i mają ograniczony zakres. Wykonuje się je wtedy, gdy klient ma sprecyzowane wymagania, np. gdy wykonał wcześniej u siebie w firmie analizę przedwdrożeniową (o tym w kolejnej części artykułu). Celem warsztatów jest sprecyzowanie wymagań i ustalenie, czy inna realizacja opisanej w analizie funkcjonalności zaspokaja potrzeby i oczekiwania klienta.

Podczas warsztatów dostawca pokazuje klientowi funkcjonalności, które realizują wymaganie, ale w inny sposób (opcja „Mamy, ale działa/wygląda inaczej”). Jeśli występuje jakiś development („Nie mamy, ale możemy to dla Ciebie wyprodukować”), to dookreślane są wymagania i sposób realizacji. Project Manager weryfikuje te wymagania z zespołem produkcyjnym i proponuje klientowi rozwiązanie kompatybilne z produktem.

Jak widzisz, wybór, czy przeprowadzane są warsztaty projektowe czy analiza biznesowa IT, zależy przede wszystkim od przygotowania klienta i specyfiki wdrożenia. Dużo lepszą opcją z Twojej perspektywy jest przejście u dostawcy warsztatów projektowych niż analizy biznesowej IT, która jest de facto analizą przedwdrożeniową. Za chwilę dowiesz się, dlaczego tak jest.

Co to jest analiza przedwdrożeniowa?

Analiza przedwdrożeniowa to etap początkowy projektu przeprowadzany zgodnie z metodyką kaskadową. Dziś już rzadko prowadzi się projekty IT w tej metodyce. Ale nadal przeprowadza się analizy przedwdrożeniowe. Dlaczego?

Głównie z powodu podejścia i oczekiwań klientów, którzy w większości prowadzą swoje biznesy w sposób tradycyjny i projekty (inne niż IT) prowadzą zgodnie z metodyką kaskadową. Jeśli jesteś mniejszą firmą, myślisz teraz: „ja tam żadnej metodyki w swojej firmie nie stosuję”. Świadomie i z nazwy nie. Ale w praktyce tak. Słychać to od razu na początku, gdy przychodzisz do ludzi z branży IT i opowiadasz o swoich oczekiwaniach. Jakich? Np. już na początku projektu znajomości szczegółowego sposobu realizacji czy dokładnych kosztów. Wszystko od A do Z tak, jak podpisane w umowie, ani złotówki więcej niż wycenione w ofercie.

Na czym polega ta analiza? Jak wygląda w szczegółach? Dlaczego lepiej wykonać ją zanim trafisz do dostawcy oprogramowania? Przeczytaj artykuł na ten temat Jak przeprowadzić analizę przedwdrożeniową w e-commerce B2B?

Czym różni się analiza biznesowa IT od analizy biznesowej jako takiej?

Z wcześniejszej części artykułu wiesz już, że początkowy, analityczny etap projektu, firmy IT nazywają często „analizą biznesową”. Raczej nie używają określenia „sprint analityczny”, bo klient nie rozumiałby, co to jest. Rzadko używają też określenia „analiza przedwdrożeniowa”, bo pochodzi ono z innej metodyki niż ta, w której pracują (z metodyki kaskadowej, a firmy IT pracują w metodyce zwinnej).

Nieszczęśliwie dla klientów, skracają też nazwę o element „IT”, co powoduje inne nieporozumienie. Na czym ono polega? Już wyjaśniam.

Analiza biznesowa IT to tak naprawdę analiza przedwdrożeniowa. Mają one ten sam cel, występują w tym samym etapie projektu, a także mają podobny zakres informacji dotyczący wymagań wobec oprogramowania. Analizę biznesową IT przeprowadza zazwyczaj Analityk biznesowy lub Project Manager w agencji IT (projekty) lub u dostawcy oprogramowania (własne produkty). Wygląd takiego dokumentu może się różnić, ale każdy będzie zawierał kontekst biznesowy. Więcej dowiesz się z artykułu omawiającego analizę przedwdrożeniową Jak przeprowadzić analizę przedwdrożeniową w e-commerce B2B?

Analiza biznesowa to audyt firmy w zakresie strategii jej działania i wdrożenia e-commerce (lub celu wdrożenia jakiegokolwiek innego systemu), procesów i operacji oraz infrastruktury IT (systemowej) i narzędzi wykorzystywanych w firmie. Taką analizę przeprowadza się przed rozpoczęciem projektu, aby stwierdzić, co trzeba wykonać (zmienić, poprawić, wdrożyć wcześniej), żeby projekt się powiódł. Przeprowadzenie takiej analizy wymaga innej wiedzy niż w przypadku analizy biznesowej IT. Nie chodzi tu bowiem o zebranie wymagań dla systemu i zrozumienie kontekstu biznesowego, a o weryfikację gotowości przedsiębiorstwa na dany projekt i takie poukładanie biznesu, żeby nie tylko wdrożyć narzędzie, ale żeby z jego wykorzystaniem wyskalować biznes.

Zapytasz, czemu zatem tej analizy biznesowej nie nazwać audytem biznesowym? Tu znów wchodzimy w odmienne znaczenie terminów, inny cel audytu i wiele rodzajów audytów, jakie przechodzą firmy. Można się zatem narazić na kolejne nieporozumienie.

Analizę biznesową przeprowadzam w firmach, które chcą wdrożyć e-commerce B2B. Jest ona oparta na głównym pytaniu: czy firma jest gotowa na rozpoczęcie sprzedaży przez Internet i wdrożenie nowego systemu? Biorę pod uwagę wszystkie i tylko te aspekty, które są mi potrzebne do odpowiedzi na to pytanie i napisanie rekomendacji zmian, które mają doprowadzić firmę do sprawnego wdrożenia i dalszego skalowania sprzedaży. Więcej na temat analizy biznesowej przeczytasz w artykule Co to jest analiza biznesowa w e-commerce B2B?

Misz masz w nazewnictwie w branży IT

Jak widzisz, niełatwo się zorientować w terminologii branży specjalistycznej. Nawet ludzie z branży mają z tym problem. Nieustannie trwają dyskusje na temat roli i miejsca Analityka biznesowego w firmach IT. Niektóre firmy wydzieliły te kompetencje nawet tak mocno, że założyły spółki konsultingowe świadczące usługi analiz dla swoich klientów. Inne, choć próbują robić analizy, nie mają do tego kompetencji w swoich zespołach.

Spotkasz się z przeróżnymi podejściami czy nazwami analiz. Dopytaj dostawcę lub wykonawcę, czym konkretnie jest dana analiza, jaki jest jej cel i przede wszystkim zakres. A jak masz wątpliwości, to wróć do tego artykułu, a nawet daj go tej firmie do przeczytania i zapytaj, czym jest ich usługa.

Podsumowanie

Artykuł ten powstał, aby wyjaśnić zawikłane kwestie nazewnictwa oraz tego, co się pod tymi nazwami kryje. Wiem, że zawiera dużo nowej wiedzy dla Ciebie i kolejnych pojęć, z którymi będziesz się spotykać przy współpracy z firmami IT. Dlatego jeśli coś jeszcze jest dla Ciebie niejasne lub budzi wątpliwości, chcesz o coś dopytać, napisz do mnie wiadomość i po prostu zapytaj.

W formularzu na dole strony (w stopce) znajdziesz opcję „Pytanie do eksperta”. Wybierz ją i wpisz swoje pytanie. W ten sposób pomożesz innym odbiorcom tego artykułu. Dlaczego? Bo uzupełnię ten artykuł o nowe informacje. Na mnie, jako osobie z biznesu, ale też z branży IT, ciąży już „klątwa wiedzy” i możliwe, że to, co dla mnie było oczywiste, dla Ciebie takie nie jest. To żaden wstyd. Gdybyśmy się zamienili rolami i ja przyszłabym do Ciebie kupić np. pompę ciepła, byłoby tak samo.

Trzymam kciuki za Twój projekt i udaną współpracę z firmami IT.