Jak przygotować się do projektu platformy e-commerce?

Manufaktura e-commerce.

Cześć. Nazywam się Michał Zabielski i od ponad 10 lat zajmuję się działaniami e-commerce na styku biznesu i technologii. W swojej karierze miałem okazję pracować zarówno z małymi sklepami internetowymi, jak i dużymi organizacjami, dzięki czemu mogę patrzeć na problemy handlu w sieci z różnych perspektyw. Podcast ten powstał, by dzielić się swoją wiedzą i doświadczeniem, jak również pomóc biznesom online mądrze i efektywnie się rozwijać. Jeśli szukasz porad i wiedzy, jak przenieść swoje działania w internecie na wyższy poziom, to to miejsce jest zdecydowanie dla ciebie.

Odcinek drugi. Projekt platformy e-commerce. Jak się na niego przygotować?

Cześć wszystkim. Mam nadzieję, że pogoda u was jest całkiem przyjemna. U mnie niestety deszczowo, ale no ale to z drugiej strony jest całkiem dobry, dobra aura do tego, żeby nagrać coś ciekawego.

A dzisiaj chciałbym poruszyć temat związany z tym, jak przygotowywać się do projektów związanych z nową platformą e-commerce. Czyli wyobrażamy sobie taką sytuację, że docieramy do momentu, kiedy zebraliśmy sobie różne oferty, przeanalizowaliśmy je pod różnym kątem, przeprowadziliśmy rozmowy z potencjalnymi wykonawcami albo rozpoznaliśmy sobie narzędzie, z którego byśmy chcieli docelowo korzystać i podejmujemy decyzję, że chcemy wystartować z projektem naszej nowej platformy e-commerce, czy to B2B, czy to B2C. I no właśnie, pojawia się takie pytanie, jak zacząć, jak to zorganizować?

Organizacyjne aspekty projektu

Czyli dzisiaj porozmawiamy sobie o tym, jak od strony takiej organizacyjnej ogarnąć ten temat, bo jedną rzeczą jest kwestia jakby techniczna, pogadania tego, jakie funkcje mają ma mieć platforma, jak ona ma funkcjonalnie wyglądać, a drugi temat to jest taki, jak zorganizować sobie w ogóle te prace, żeby przynosiło, żeby na koniec dnia ten projekt przynosił nam rzeczywiste korzyści, no i przede wszystkim, żeby się zmieścił w tym naszym wymarzonym budżecie i w czasie.

No i faktycznie jest tak, że to wymaga zaopiekowania kilku obszarów przed startem, jeśli chcemy, żeby to faktycznie zakończyło się powodzeniem. I o takich pięciu istotnych rzeczach postaram się dzisiaj wam opowiedzieć.

1. Dedykowana osoba po stronie zamawiającego

Przede wszystkim, pierwsza podstawowa rzecz, o której musicie pamiętać, to to, że nie tylko po stronie wykonawcy potrzebna jest osoba, która będzie koordynowała prace projektowe. Tak samo jak po stronie wykonawcy potrzebna jest taka osoba, tak samo i po stronie waszej, czyli zamawiającego, jest potrzeba posiadania takiej osoby, która będzie opiekowała ten temat.

Ona jest konieczna do tego, żeby uspoić komunikację i przede wszystkim dać jasny sygnał wykonawcy, do kogo on ma się zwracać z wszelkiego rodzaju pytaniami, uwagami albo jakimiś elementami wymagającymi doprecyzowania, bo gwarantuję wam, że tych pytań, tych problemów, kwestii do omówienia będzie cała masa. I ponieważ to będzie dotykało wielu różnych obszarów, to bardzo ważne jest, żeby była to osoba, która będzie w stanie zebrać tę wiedzę z organizacji i dostarczyć ją wykonawcy.

Wydawać się to może oczywiste, że taka osoba powinna być po stronie zamawiającego, ale uwierzcie mi, bardzo często klienci wychodzą z takiego założenia, że takiej osoby dedykowanej pod to nie będzie, bo przypisujemy niejako ten temat do właściciela. Natomiast po prostu jeśli będziemy robić platformę i będziemy dotykać różnych obszarów, czy to sprzedaży, czy to marketingu, logistyki i tak dalej i tak dalej, to po prostu będziemy wybierać osobę z tego obszaru i ona będzie nam dostarczać odpowiednią wiedzę. I o ile gdzieś tam w takich w takim podstawowym założeniu to ma sens, o tyle w dłuższym horyzoncie czasowym to jest bardzo duże utrudnienie dla firmy i bardzo duża niedogodność.

Bo jak przejdziecie sobie przez taki projekt, to zobaczycie, że tych pytań związanych z tym projektem będzie bardzo dużo. Mimo że mogliście mieć wcześniej jakieś warsztaty, być może była jakaś rozmowa tak zwana Discovery Call, która powinna doprecyzowywać różne aspekty i która powinna dostarczać informacji wykonawcy, to jest bardzo wiele takich rzeczy, że do których jak zejdziemy już tak na niższym poziomie, to okaże się, że nie mamy tej wiedzy i będziemy musieli jako wykonawcy, będziemy musieli pytać, pytać i pytać. A znowuż jako zamawiający, będziemy musieli dostarczać tej wiedzy.

I spotkałem się już z wieloma projektami, w których tych pytań było tak dużo i tych osób z różnych obszarów było wywłaszczanych z pracy tak wiele, że potrafiło to zaburzać normalną pracę tych działów. Czyli przykładowo, jeśli rozmawialiśmy o sprzedaży, pojawiała się dyrektorka sprzedaży i jej zaangażowanie w odpowiedzi na te pytania, w doprecyzowywanie procesów było tak duże, że ona po prostu zwyczajnie nie była w stanie prowadzić sprzedaży. Więc dochodziło do takiej absurdalnej sytuacji, że okresowo częściowe, części różne części działów firmowych były paraliżowane przez wykonawcę, bo po prostu on bombardował firmę różnymi pytaniami. I paradoks polega na tym, że nie możemy się za bardzo na tego wykonawcę gniewać, bo on jest ekspertem w swojej dziedzinie. Natomiast no nie jest on, nie musi być, o może tak, nie musi on być specjalistą w waszym obszarze, tak samo jak nie musi znać w 100%, przynajmniej na start, wszystkich waszych, wszystkich waszych procesów, tego jak działacie. Dlatego to jest bardzo ważne, żeby przekazać mu tę wiedzę.

I dlatego właśnie ważna jest ta osoba po stronie zamawiającego, która uspuinia tę komunikację, pozyskuje tę wiedzę i co istotne, jest cały czas w procesie wytwarzania. W związku z tym ona ma kontekst wszystkich tych obszarów i tak jak wykonawca zdobywa jakąś tam wiedzę, tak samo i ta ta ta osoba zdobywa tę wiedzę w trakcie trwania projektu, dzięki czemu ta przekazywana wiedza czy podejmowane decyzje biorą pod uwagę pełen kontekst tego projektu, pełen kontekst tworzonej platformy, dzięki czemu na koniec dnia dostajemy lepsze rozwiązanie.

Oprócz tego, ważne jest to, żeby taka osoba miała dość duży, dość duży obszar decyzyjny, to znaczy, żeby ona miała sporą decyzyjność i żeby nie była uzależniona w dużej mierze od zarządu, od decyzji zarządu, żeby nie było sytuacji takich, że wykonawca zadaje jakieś pytanie i musi czekać kilka dni na to, aż zarząd, bądź ktokolwiek z firmy dogada ze sobą, jaka to powinna być ta finalna wersja tej decyzji, no i żeby po prostu nie utknąć w takich procesach decyzyjnych. To ma to szczególnie jest ważne w dużych organizacjach, gdzie te szczeble decyzyjne mogą być dość odległe od tego wykonawcy i później docieramy do, możemy dotrzeć do sytuacji, w której po prostu projekt jest sparaliżowany, bo nie jesteśmy w stanie uzyskać odpowiednich decyzji. Także ta osoba powinna być dość mocno umocowana decyzyjnie.

Oczywiście idealnie, gdyby to był właściciel, ale no wiadomo, że właściciel też ma swoje jakieś działania z różnych obszarów, no i ciężko będzie wymagać tego, żeby on w tym procesie uczestniczył cały czas. Co więcej, w większych organizacjach często jest tak, że właściciel nie ma kompletu wiedzy dotyczącej obszarów, dla których jest budowana platforma. Czyli może nie mieć pełni wiedzy na temat działań marketingowych, sprzedażowych, czy operacyjnych, które będą automatyzowane i wtedy potrzebujemy ekspertów z tych obszarów. Więc na koniec dnia taka osoba dedykowana, która będzie w stałym kontakcie z tymi osobami reprezentującymi wybrane obszary jest kluczowa.

Co więcej, osoba ta powinna być skupiona na tym projekcie i nie powinna traktować go przy okazji. Co jest konsekwencją tego, że chcielibyśmy doprowadzić do tego, żeby projekt zakończył się w odpowiednim czasie, no i żeby te decyzje docierały do nas jak najszybciej. Czyli po realizacji, po zadaniu jakiś pytań, czy po zrealizowaniu jakiś warsztatów, jeśli mamy jakieś pytania, które wymagają doprecyzowania, no to po prostu musimy jak najszybciej uzyskiwać te odpowiedzi. Dlatego ta osoba musi być skupiona na tym projekcie maksymalnie po to, żeby ten projekt zakończył się powodzeniem. To oznacza, że dla takiej osoby ten projekt musi być priorytetowy.

Jak to najlepiej osiągnąć? No, jest na to kilka sposobów. Pierwszy to jest oczywiście taki, że tworzymy wręcz stanowisko niejako dedykowane tylko do tego, żeby tworzyć tę platformę, ale są też inne opcje możliwe do osiągnięcia. Przykładowo, możemy zrobić tak, że ustalamy jakiś kwant czasowy względem wybranego stanowiska i twierdzimy, że w ramach tego czasu osoba ma być zaangażowana w 100% w ten projekt. Co jest takie już wątpliwe, bo to już zahacza o to, że są jest jakiś inny zestaw kompetencji, może nie tyle zestaw kompetencji, co jest inna, inne zaangażowanie czasowe też w inne elementy, może to rzutować na fokus. Dlatego bardzo dobrym pomysłem, który stosują niektórzy, jest ustawienie po prostu KPI-a dla tej osoby, związanego z tym projektem. Czyli osoba jest rozliczana niejako z tego, jak dowozi ten projekt, czy w ogóle ten projekt idzie w odpowiednim kierunku. Wtedy ta odpowiedzialność sprawia, że jej motywacja do rozliczania projektu jest dużo wyższa.

Także warto wziąć gdzieś pod uwagę ten fakt i być może właśnie pomyśleć o jakimś powiązaniu działania w obszarze tej platformy, powiązania tych działań osoby, która jest dedykowaną osobą po stronie zamawiającego, powiązania jej może nie wiem, może wynagrodzenia, może zaangażowania czasowego w tym projekcie. To jest o tyle ważne też, że jeśli my jasno powiemy, że ten projekt ma jakiś tam swój KPI, czy ta osoba jest rozliczana z tego projektu, to ona też automatycznie dostaje sygnał od nas, że faktycznie nam jako zarządowi, czy jako firmie, zależy na tym projekcie i na koniec dnia wszyscy będą też mieli świadomość tego i będzie to jasno powiedziane, że jeśli ta osoba jest w projekt zaangażowana, to nie zostanie jej zarzucone to, że nie angażuje się w inne obszary.

To oczywiście oznacza, że od od strony zamawiającego powinniśmy wziąć pod uwagę również ten koszt. Czyli jedną rzeczą jest koszt wynikający z wdrożenia platformy i tego co daje wykonawca, ale drugą składową kosztową jest to, że po stronie zamawiającego, czyli po naszej stronie, jest też dedykowana osoba, która opiekuje się tym projektem, no i za ten czas zapewne trzeba jej zapłacić. Więc warto uwzględnić również ten koszt w koszcie projektu, żeby potem się nie zaskoczyć niemile, że gdzieś ten budżet nam spuchł, bo się okazało nagle, że po naszej stronie pojawiają się jakieś koszty, które których wcześniej nie przewidywaliśmy, bo zakładaliśmy, że po prostu wykonawca zrealizuje ten projekt i jakby cała ta część taka zarządcza będzie robiona tylko po jego stronie.

Oczywiście możecie próbować realizować ten projekt w oparciu o tylko osoby po stronie wykonawcy, czyli jakby takiego powiedzmy Product Ownera czy Project Managera po stronie wykonawcy, ale w większości wypadków to nie jest efektywne. A nie jest efektywne dlatego, że ta osoba po stronie wykonawcy dogląda pracy programistów, dogląda pracy zespołu projektowego, oprócz tego wchodzi w komunikację z z wami, a do tego wszystkiego nie jest jeszcze umocowana decyzyjnie w tym całym procesie, więc te wszystkie działania jej z definicji od razu mają niższy priorytet. Z praktyki widzę, że ustawianie takiej osoby dedykowanej po stronie zamawiającego jednak porządkuje te prace i na koniec dnia doprowadza do tego, że ten projekt działa płynnie.

Dobra, to jest jakby pierwsza rzecz, czyli ta dedykowana osoba.

2. Analiza biznesowa (Business Analysis)

Druga rzecz, analiza biznesowa. To jest coś, co zawsze powinno być robione, najlepiej przed startem projektu, ale zdaję sobie sprawę, że nie każdy jest w stanie ponosić taki koszt wykonania pełnej analizy biznesowej przed realizacją projektu.

Czym jest ta analiza biznesowa? Analiza biznesowa jest niczym innym, jak rozłożeniem na czynniki pierwsze podstawowych procesów, jakie zachodzą w organizacji, jak również procesów różnych pobocznych, po to, żeby zidentyfikować, które z tych elementów tego procesu, bądź które procesy chcielibyśmy zawrzeć w platformie naszej e-commerce'owej, czy platformie B2B, do tego, no żeby po prostu zostały w jakimś mniejszym lub większym stopniu zautomatyzowane. Zaznaczam tutaj, że mówię o tym, że robimy analizę biznesową. Czyli to co my robimy w praktyce, to rozpisujemy sobie podstawowe kroki procesu biznesowego, na pewno tego głównego, który determinuje nasz biznes, ale i tych obszarów pośrednich, czyli tam powiedzmy sprzedaży, marketingu, logistyki, jakiejś dodatkowej analityki, działań operacyjnych. No jest tego dużo i zależy to w dużej mierze od organizacji, te procesy powinny zostać rozpisane. I co co jest istotne, nie powinniśmy przechodzić tylko przez tak zwane happy path, czyli te ścieżki, gdzie wszystko się udaje, ale warto też byłoby przeanalizować te scenariusze alternatywne, które się pojawiają, bo może się okazać i bardzo często tak jest, że te scenariusze alternatywne generują nam jakieś koszty i problemy, a bardzo łatwo można je zautomatyzować i na koniec dnia poprzez taką strategię, nazwijmy to długiego ogona, gdzie po prostu robimy masę różnych małych usprawnień, nominalnie na koniec dnia platforma dostarcza nam niesamowitych zysków, wynikających z automa z automatyzacji tych różnych pobocznych procesów, które mają miejsce.

Mając takie procesy, możemy sobie później przejść dalej do tego, żeby decydować o tym, które fragmenty tych z tego procesu chcielibyśmy zautomatyzować albo zcyfryzować w naszej platformie e-commerce. Warto korzystać z narzędzi, które wizualizują tego typu procesy, bo wtedy znacznie lepiej jest zrozumieć, jak one działają i jest to coś, co jest zdecydowanie z korzyścią zarówno dla wykonawcy, jak i dla zamawiającego. Nieraz mieliśmy taką sytuację, że na takich warsztatach, które były prowadzone przeze mnie bądź kogoś z zespołu, dochodziło do sytuacji, gdzie my zadając trafne pytania i analizując te procesy, odkrywaliśmy niejako biznes klienta wraz z nim na nowo. To znaczy, klient dowiadywał się o pewnych rzeczach, jak one są tak naprawdę realizowane, dopiero analizując krok po kroku te rzeczy, które oni robią w organizacji. Mieliśmy nawet takie spotkanie, gdzie zebrany był, zebrane były wszystkie osoby decyzyjne, praktycznie był to skład 15-osobowy z różnych działów i kiedy zeszliśmy do etapu do etapu magazynowania i zaczęliśmy analizować zachodzące tam procesy, w pewnym momencie dotarliśmy do momentu, w którym nikt nie wiedział tak naprawdę, jak wygląda następny krok. Co skończyło się tym, że osoba odpowiedzialna za obszar magazynowania musiała dzwonić do przeciętnego pracownika, który był gdzieś tam w magazynie i on opowiadał tak naprawdę, jak to jest w praktyce realizowane. Więc to jest niesamowita, niesamowity insight nie tylko dla wykonawcy, ale i dla samego zamawiającego, żeby odkryć, jak ten jego biznes poprawnie bądź niepoprawnie działa, bo różne takie wąskie gardła, czy jakieś takie niewydajności w procesach da się w ten sposób zidentyfikować. I do wizualizacji procesów najlepiej korzystać z takich rozwiązań od strony metodycznej, jak powiedzmy Business UML, czy BPMN, czy Event Storming. To są takie techniki, które pozwalają nam właśnie wizualizować procesy, jakieś jego odnogi. Ja osobiście jestem fanem Event Stormingu, dlatego że można go bardzo łatwo, on jest prosty do zrozumienia, opiera się na jakimś tam zestawie kolorowych karteczek. Jest prosty do zrozumienia, jest prosty do wytłumaczenia już na samych warsztatach, więc nie wymaga to jakiegoś wysokiego progu wejścia, a dodatkowo można go dostosowywać do potrzeb, więc jeśli potrzebujemy tylko pewnego wycinka tej metodyki, czy tego tego sposobu, no po prostu stosujemy tylko jego wycinek bez żadnego uszczerbku dla realizacji warsztatów. Natomiast od strony technicznej warto korzystać z takich rzeczy, no jak po prostu tablice, gdzie po prostu wizualizujemy ten proces, albo z narzędzi online'owych typu Miro, FigJam, Mural. Tego typu rzeczy, generalnie narzędzia typu Whiteboardy są bardzo dobre do tego, żeby wizualizować te procesy.

Mając te procesy, jesteśmy w stanie wspólnie z klientem, albo już nawet i bez jego zaangażowania, doprowadzić do tego, żeby zespół po stronie wykonawcy przeanalizował sobie procesy, znalazł te miejsca, które ich zdaniem można byłoby zautomatyzować i usprawnić i dać tym samym zestaw rekomendacji, co powinno się zawrzeć w platformie sprzedażowej, czy w platformie B2B.

3. Analiza ekosystemu IT

Mając już ten aspekt biznesowy, czyli ten nasz krok drugi, mamy kolejny element, czyli analizę ekosystemu IT. Czyli schodzimy teraz do strony technologii.

Jak być może się domyślacie, każdy system IT, który budujemy, nie funkcjonuje w próżni. To znaczy, on działa zawsze w jakimś tam ekosystemie. Nigdy nie jest tak, że budujemy system, który nie łączy się z niczym i nie produkuje nic. W związku z tym musimy przeanalizować to otoczenie, bo od niego może bardzo dużo zależeć. Może się okazać, że komunikujemy się albo platforma będzie musiała komunikować się z jakimiś zewnętrznymi narzędziami, a to oznacza konieczność integracji z nimi. Wtedy trzeba określić, jak głęboka ta integracja ma być, jakiego typu to ma być integracja, czy ona jest konieczna na start, czy nie, jakie wymagania co do wydajności i bezpieczeństwa w ramach tego ekosystemu muszą zostać zrealizowane, żeby spełnić wszelkie normy, żeby po prostu ten system też był użyteczny. I ten poprzedni krok dotyczący analizy biznesowej jest dla nas o tyle pomocny, że pozwala nam identyfikować obszary, w których ta automatyzacja, cyfryzacja jest potrzebna i z nich niejako też może nam wynikać częściowo przynajmniej, z jakimi narzędziami się będziemy musieli łączyć. Bo jeśli będziemy chcieli na przykład automatyzować działania marketingowe, to wyobrażam sobie sytuację, w której będziemy musieli na przykład zintegrować się z jakimś systemem Marketing Automation, albo z systemem CRM, w którym będziemy mogli sobie odkładać informacje o naszych klientach.

Jeśli będziemy chcieli na przykład mieć jakiś centralny system do zarządzania informacją produktową, to być może okaże się, że platforma B2B, czy platforma e-commerce będzie musiała się integrować z systemem PIM. Albo z systemem ERP, jeśli będziemy chcieli zarządzać stanami magazynowymi, które będą dzielone między platformę a inne miejsca, znowu może się okazać, że w grę wchodzi konieczność integracji z systemem WMS. Dlatego jest to bardzo ważne i super istotne, żeby ten ekosystem IT brać pod uwagę. Bo z praktyki mogę powiedzieć, że bardzo duża część godzin przepracowanych na projektach tego typu wiąże się z koniecznością integracji z różnymi systemami zewnętrznymi. I w zależności od tego, jak złożony jest ten ekosystem IT dookoła, może się okazać, że nawet większa część projektu, większą część projektu stanowi właśnie konieczność integracji z systemami. Dlatego pominięcie tego kroku sprawi, że na przykład będziemy w trakcie prac dopiero dowiadywać się o tym, z czym my się chcemy albo z czym musimy się integrować, co na pewno zrodzi nie tylko frustrację, ale sprawi, że sam projekt spuchnie, jeśli chodzi o liczbę godzin koniecznych do zrealizowania efektu końcowego.

Dlatego warto te analizę przeprowadzić i dać możliwość wykonawcy ocenienia tego, z czym się integrować, jak się integrować, uwzględniając wszelkiego rodzaju wymagania, czy dotyczące właśnie nie wiem, wydajności, bezpieczeństwa, spełnienia jakiś tam norm, czy standardów firmowych.

4. Identyfikacja ryzyk i Road Mapa

Mając te kroki, czyli mając osobę dedykowaną, robiąc analizę biznesową, ekosystem IT, możemy przejść do jeszcze jednego istotnego kroku, do identyfikacji ryzyk i zbudowania Road Mapy. To też jest szalenie ważny krok. Szczególnie jeśli chodzi o identyfikację ryzyk, bardzo ważne jest to, żeby w miarę możliwości przejść do tego, zanim zaczniemy realizować projekt. Czyli usiąść i zadać sobie takie pytania, gdzie potencjalnie może coś się nie udać, dlaczego miałoby się to nie udać, czy mamy jakieś rozwiązanie proponowane już teraz, czy rekomendacje w sytuacji, gdy to ryzyko się zmaterializuje, czy mamy budżet, czy jakiś horyzont czasowy i kosztowy, który przeznaczamy na to, że jak się to ryzyko zmaterializuje, to my będziemy w stanie na to zareagować. To jest to, co najczęściej różni oferty wykonawców między sobą.

Czyli to, że niektórzy w przy tworzeniu ofert dla klienta, dla zamawiającego, uwzględniają już na etapie budowania oferty te ryzyka, identyfikują je i od razu proponują jakieś rozwiązania, uwzględniając je powiedzmy w ofercie, czy tworząc jakieś tam bufory dodatkowe ofertowe, czy tego nie robią. No i oczywiście to jest temat wzbudzający najwięcej kontrowersji, czy powinni to teraz uwzględniać, czy faktycznie powinien budżet projektowy puchnąć, bo ktoś sobie założył, że coś się zmaterializuje, a niekoniecznie się musi to zmaterializować. To jest temat na zupełnie inny odcinek, ale co do zasady ja bym rekomendował identyfikować te ryzyka w myśl tego, że lepiej zapobiegać niż leczyć i lepiej mieć też plany zapasowe w przypadku, gdyby coś się wydarzyło, zanim to się wydarzy, niż żeby myśleć na gorąco w trakcie, kiedy to się wydarzy, co z tym faktem zrobić.

Ta identyfikacja ryzyk i Road Mapa zresztą, wynika nam trochę z tych warsztatów Discovery, czyli z tych wszystkich warsztatów, które wcześniej miały miejsce, czyli z tej analizy ekosystemu IT, z tej analizy biznesowej, z rozpisania tych procesów i z uwzględnienia osoby zamawiającej w tym całym procesie, która też dzieli się wiedzą zarówno biznesową, jak i taką dookoła tego biznesu.

I mając te zidentyfikowane ryzyka, możemy sobie wtedy przejść do Road Mapy. Road Mapa to jest znowuż nic innego, jak opisanie bardzo ogólnie, z tak zwanego lotu ptaka, tego, jak wyobrażamy sobie scenariusz tego projektu. Czyli jak wyobrażamy sobie jakiś harmonogram tego projektu, jak jaki będzie następstwo różnych realizowanych elementów, czyli dzielimy sobie trochę projekt na moduły, może na etapy, ustawiamy te etapy w różnej kolejności po to, żeby mieć zwizualizowane i znowu zaplanowane to, jak powinien wyglądać ten projekt, jeśli wszystko pójdzie zgodnie z naszymi oczekiwaniami.

Ta Road Mapa ma na celu w sumie doprowadzenie do dwóch rzeczy. Pierwsza rzecz to jest taka, że planując te rzeczy, te te te nasze działania, dzielimy sobie projekt na mniejsze składowe, dzięki czemu łatwiej nam jest go zrozumieć. I co więcej, ustawiamy sobie te składowe w jakiejś tam sekwencji zdarzeń. Może się okazać, że niektóre rzeczy jesteśmy w stanie zrównoleglić. Może się okazać, że niektóre rzeczy nie dadzą się zrównoleglić, no i musimy uwzględnić fakt, że będzie to realizowane sekwencyjnie i dzięki temu mamy już pojęcie na temat tego, z jakim horyzontem czasowym mamy do czynienia w wybranym projekcie.

Także to jest to jest bardzo cenna wartość zarówno dla wykonawcy, jak i dla zamawiającego, bo każdy mniej więcej wie, gdzie się osadza w tym projekcie, ile to będzie trwało i z jakimi to potencjalnymi kosztami się wiąże. Więc to jest jakby jedna rzecz. Uwzględnia to też, adresuje to też te ryzyka, o których mówiliśmy. Czyli pokazuje, gdzie potencjalnie coś tam może być realizowane dłużej bądź krócej, mając te ryzyka na względzie. Więc to jest jakby jedna rzecz, którą daje nam Road Mapa.

Druga rzecz jest taka, że rozbijając te rzeczy na składowe, rozbijając to na jakieś pojedyncze sekwencje zadań, możemy też o pewne rzeczy już dopytać się teraz na etapie takim analizy i projektowania. Więc jesteśmy w stanie podpytać się, czy aby na pewno wszystko zostało poprawnie zrozumiane, czy jeśli pojawia się jakieś nowe ryzyko, no to czy jesteśmy gotowi na potencjalne ścieżki alternatywne w realizacji tego projektu i znowu robimy to zanim do tego dojdzie, dzięki czemu każdy czuje się pewniej w tym projekcie. No i właśnie to jest kolejna zaleta Road Mapy, mianowicie taka, że ona daje nam poczucie tego, przynajmniej zamawiającemu daje poczucie tego, że my wiemy co robimy i mamy nad tym kontrolę.

Nie mówiąc o tym, że samo planowanie projektu w formie Road Mapy pozwala również wykonawcy mieć poczucie tego, że on to zaplanował, czyli bierze pod uwagę, jak to będzie wyglądało, jakie są następstwa, czyli daje większą szansę na to, że w kontrolowany sposób doprowadzimy do szczęśliwego zakończenia tego projektu.

Zbudowana Road Mapa i jej składowe wymagają również tego, żeby określić jakieś kryteria akceptacji tych poszczególnych składowych. W związku z tym już na etapie budowania Road Mapy możemy wspólnie z klientem określać, co rozumiemy przez zrealizowanie wybranego etapu. I o ile to na początku może się wydawać nieistotne, o tyle gwarantuję wam, że w trakcie pracy nad projektem, kiedy już mogą być różne wzloty i upadki i nie zawsze wszystko będzie szło po naszej myśli, to określenie tych kryteriów akceptacji jest kluczowe, żeby nam po pierwsze nie puchł zakres, a po drugie, żeby nie doprowadzić do sytuacji, że wykonawca realizuje coś, co w praktyce nie jest dla nas super istotne, a wydłuża czas realizacji projektu. Więc na tym etapie również ta Road Mapa jest bardzo pomocna.

5. Długoterminowa perspektywa

I to są takie rzeczy, które są istotne, jeśli chodzi o odpowiednie przygotowanie się do realizacji platformy e-commerce. Generalnie to są takie zasady, które są istotne dla każdego projektu IT. W przypadku platformy e-commerce to również jest ważne, czyli podsumowując: dedykowana osoba po stronie zamawiającego, żeby trzymała w ryzach projekt od strony tej biznesowej i od strony zamawiającego i nie paraliżowała prac wszystkich działów. Analiza biznesowa, żebyśmy dobrze jako wykonawcy zrozumieli, jak działa twój biznes, a ty, żebyś od strony zamawiającego z kolei był w stanie znaleźć jakieś swoje wąskie gardła, zobaczyć tak metodycznie, jak pracujecie i czy gdzieś tam jeszcze nie ma przestrzeni do tego, żeby to poprawić. Analiza ekosystemu IT, czyli element, który pozwala nam na identyfikowanie tego, w jakim jakie systemy mają działać na tę platformę i z którymi ona ma współpracować. Oraz identyfikacja ryzyk i Road Mapa, czyli zidentyfikowanie tego, co potencjalnie może pójść nie tak, jak to zaadresować i jak mniej więcej ten projekt będzie wyglądał na tym etapie, na którym go rozumiemy w tym momencie.

Na koniec chciałem tylko wspomnieć o tym, żebyście patrzyli na taki projekt platformy e-commerce z taką wizją przyszłości, powiedzmy. To znaczy, to co prawda będzie projekt, ale na koniec dnia po zbudowaniu tej platformy, tak naprawdę ta przygoda dopiero się zaczyna. W związku z tym znowu trzeba myśleć o tym, że wdrożenie platformy e-commerce, czy wdrożenie platformy B2B w naszej organizacji jest tak naprawdę procesem. Procesem, który na początku wymaga mocnego zaangażowania w formie zbudowania tej platformy, czyli takiego projektowego podejścia, ale później po zbudowaniu tej platformy przechodzimy na etap taki, który jest rozwojem bądź utrzymaniem tej platformy i który wymaga tego, żeby dostosować się do zmian, jakie zachodzą też w waszej organizacji. Czyli tak jak biznes ewoluuje, tak również ta platforma B2B, czy platforma e-commerce będzie ewoluowała. Dlatego pamiętajcie o tym, żeby wziąć pod uwagę takie rzeczy, jak koszt utrzymania platformy, zdecydować, czy ta osoba, która była osobą dedykowaną w trakcie projektu, czy będzie to osoba, która będzie wciąż opiekunem przy utrzymaniu, czy nadal bierzemy pod uwagę taką osobę. Jak zaalokować jej zaangażowanie na etapie rozwoju i utrzymania? Czy jeśli pojawią się jakieś nowe pomysły na platformę w trakcie prac nad projektem, to czy realizujemy je od razu, czy realizujemy je później, bo to uruchamia nam kolejny proces nowych rzeczy, które chcemy wdrażać. I jeśli spojrzymy na to w ten sposób, że platforma jest elementem, który będzie ewoluował i dostosowywał się do biznesu, to no tak, tak jest moje przypuszczenie, podparte wieloma wdrożeniami i tym, jak klienci działają obecnie z tymi platformami, że tylko takie podejście, gdzie traktujemy to jako element, który będzie podlegał ciągłemu rozwojowi i dostosowywaniu się do biznesu, tylko z takim podejściem ta platforma będzie przynosiła nam super zwroty z inwestycji i będzie ona dla was wartością samą w sobie, która pozwoli wam się skalować, która pozwoli wspomagać handlowców, która przede wszystkim będzie współgrała z waszymi procesami biznesowymi, a nie będzie takim niewygodnym elementem, który z którego ko korzystają na siłę zarówno klienci, jak i wasi pracownicy. A tego byśmy na koniec dnia oczywiście nie chcieli.

Dobra, to chyba tyle z mojej strony, jeśli chodzi o o te przygotowania do platformy. Zachęcam ciebie do podzielenia się tym odcinkiem bądź przekazania go jakiejś osobie, która z tej wiedzy mogłaby skorzystać. Zachęcam również do subskrybowania kanału po więcej ciekawych treści i pamiętajcie, że w każdej chwili możecie do mnie napisać, odezwać się, ja bardzo chętnie pomogę. Na michalzabielski.pl znajdują się wszelkiego rodzaju informacje związane z tym, co robię, z odcinkami, z tematyką tego, o czym opowiadam, a na michalzabielski/002, michalzabielski łamane na 002, znajdziecie dodatkowe materiały do tego odcinka, transkrypcję i informacje, które mogą wam pomóc przygotować się do takiego projektu platformy e-commerce. A tymczasem życzę wam udanych wdrożeń, dobrego przygotowania i mam nadzieję, że w niedługim czasie będę w stanie zobaczyć wasze działające platformy e-commerce, bądź platformy B2B w akcji. Dzięki wielkie, do usłyszenia. Cześć.