Pięć spółek, siedmiu operatorów 3PL i Odoo. Historia wdrożenia bez upiększeń

Zastanawialiście się kiedyś, jak trudno zarządzać firmą, która urosła już do międzynarodowej skali?

Zwłaszcza jeśli rosła szybko. Tak szybko, że technologia, procesy i wewnętrzne narzędzia po prostu nie nadążały za biznesem.

Firma otwiera nową spółkę. Potem dochodzi kolejny magazyn. Nowy operator 3PL. Następne konto Amazon. Shopify. Księgowość żyje w osobnym systemie. Część danych przepływa automatycznie, część ręcznie, a część istnieje wyłącznie w głowach konkretnych pracowników.

Sam biznes może przy tym świetnie się rozwijać.

Do pewnego momentu.

Chcę Wam opowiedzieć o jednym z naszych projektów. Klient rozwijał się tak szybko, a jego narzędzia były tak rozproszone, że wdrożenie całkiem standardowych mechanizmów Odoo pozwoliło w końcu zmienić ten układ w znacznie bardziej uporządkowany i łatwiejszy do zarządzania system.

Jeśli wolicie najpierw zobaczyć skalę, architekturę i rezultaty, mamy też krótszy opis tego projektu w Portfolio. Tutaj opowiem, jak to wyglądało od środka.

Wszystko zaczęło się od zwykłego zapytania przez stronę

Poznaliśmy klienta zupełnie przypadkiem.

Trafił do nas przez stronę i powiedział mniej więcej: mamy biznes i chcemy go zautomatyzować za pomocą Odoo.

Na pierwszy rzut oka zwykłe zapytanie.

Ale już po pierwszych rozmowach było jasne, że ten projekt prosty nie będzie.

Klient działa na rynku międzynarodowym i sprzedaje fizyczne produkty na całym świecie. Główne kanały sprzedaży to Amazon i Shopify.

Szczegółów dotyczących produktu nie mogę zdradzić – podpisaliśmy NDA. Powiem tylko, że sam produkt naprawdę mi się podoba. Takie projekty dają zresztą rzadką okazję, żeby zobaczyć od środka, jak przedsiębiorczy ludzie budują szybko rosnący międzynarodowy biznes.

I to jest bardzo ciekawe.

W tamtym momencie działalność klienta obejmowała około pięciu podmiotów prawnych w różnych częściach świata.

Spółki kupowały towary od dostawców, sprzedawały je, przekazywały między sobą, uzupełniały zapasy w magazynach, a na końcu dostarczały produkty klientom przez kanały e-commerce.

Nie mieliśmy więc przed sobą po prostu sklepu internetowego.

To była pełnoprawna międzynarodowa organizacja handlowa.

Pięć spółek to dopiero początek

Kiedy zaczęliśmy zaglądać głębiej, okazało się, że główna trudność nie tkwi nawet w liczbie spółek.

Klient korzystał z usług zewnętrznych operatorów logistycznych – około siedmiu różnych dostawców 3PL, którzy przechowywali i wysyłali towary w różnych częściach świata.

I tutaj zaczynała się prawdziwa matematyka.

Ten sam operator 3PL mógł przechowywać towar kilku spółek. Ten sam produkt mógł znajdować się w kilku miejscach. Towar mógł należeć do jednej spółki, fizycznie leżeć w magazynie w innym kraju, później zostać odsprzedany wewnątrz grupy, a dopiero potem trafić do klienta z zamówienia w Shopify albo na Amazonie.

Powstawała dość złożona macierz:

spółka × magazyn × produkt × właściciel towaru × kanał sprzedaży × uzupełnianie zapasu × przemieszczenia.

A ta macierz bez przerwy się zmieniała.

Towar przyjeżdżał. Przemieszczał się. Był przepakowywany. Zapasy trzeba było uzupełniać. Z marketplace’ów napływały zamówienia.

Część towarów sprzedawano przez Amazon FBA, część w innych modelach realizacji zamówień, a część przez Shopify.

W sezonie wszystko działo się bardzo szybko.

W takim układzie automatyzacja nie może działać na zasadzie „no, w większości przypadków chyba jest dobrze”. Przy dużej sprzedaży drobny błąd routingu albo synchronizacji szybko zamienia się w setki nieprawidłowych operacji.

To właśnie ta skala sprawiała, że zarządzanie zapasami i magazynami musieliśmy rozpatrywać razem ze sprzedażą, własnością towaru i rozliczeniami.

Najpierw musieliśmy zrozumieć, jak ta firma właściwie działa

Jedna z najważniejszych części projektu zaczęła się jeszcze przed poważnymi pracami programistycznymi.

Musieliśmy zrozumieć, jak biznes działa w rzeczywistości.

Nie jak powinien działać według procedur. Nie jak opisuje go jeden z menedżerów. Tylko co naprawdę dzieje się z towarem, zamówieniem i pieniędzmi od początku do końca.

To okazało się osobnym zadaniem.

Różni pracownicy znali różne fragmenty procesu. Ktoś świetnie rozumiał zakupy. Ktoś Amazon. Ktoś pracę konkretnego magazynu. Finanse widziały swoją warstwę zdarzeń.

Pełny obraz nie zawsze mieścił się w głowie jednej osoby.

W szybko rosnących firmach to zresztą zupełnie normalne. Proces powstaje, bo dzisiaj trzeba rozwiązać konkretny problem. Potem dochodzi kolejny. Nowy pracownik wprowadza własny sposób pracy. Firma wchodzi na następny rynek.

Po kilku latach biznes działa, ale nikt nie potrafi już szybko wyjaśnić całego łańcucha.

Dlatego pierwszy etap był w dużej mierze analityczny. Dosłownie rozkładaliśmy firmę na części i składaliśmy ją ponownie – tym razem w postaci procesów.

Co dzieje się po zakupie? Która spółka staje się właścicielem towaru? Dokąd towar jedzie? Jak trafia do magazynu? Skąd wiemy, że trzeba uzupełnić zapas? Co się dzieje, gdy sprzedaje go inny podmiot? Jak powinna wyglądać transakcja wewnątrz grupy? Jakie skutki finansowe wywołuje fizyczny ruch towaru?

Czasami odpowiedź na jedno pytanie tworzyła pięć nowych.

Czasami dwóch pracowników inaczej opisywało ten sam proces.

Czasami czynność, która wyglądała na zupełnie prostą, nagle dotyczyła trzech spółek i dwóch magazynów.

W pewnym momencie stało się oczywiste, że to już nie jest po prostu konfiguracja Odoo.

To projekt porządkowania procesów biznesowych. Właśnie dlatego nasze podejście do wdrożenia Odoo zaczyna się od zrozumienia firmy, a nie od instalowania aplikacji.

Multi-company i intercompany

Potem zaczęliśmy budować model w Odoo.

Pierwszym dużym obszarem było multi-company, czyli obsługa wielu spółek.

Nie mogliśmy po prostu dodać pięciu podmiotów i uznać, że temat jest załatwiony. Te spółki cały czas ze sobą współpracowały.

Jedna mogła kupić towar od dostawcy, potem przekazać go albo odsprzedać innej spółce w grupie. Ta druga sprzedawała go klientowi końcowemu.

Wszystko musiało przy tym prawidłowo odzwierciedlać się w zapasach, kosztach i księgowości.

Skonfigurowaliśmy zakupy i procesy intercompany tak, żeby operacje wewnątrz grupy były dla użytkowników możliwie przejrzyste.

Dla biznesu to kluczowe. Właśnie tutaj zaczyna się kształtować rzeczywisty koszt towaru.

Jeśli transakcja między spółkami zostanie ujęta nieprawidłowo, zniekształcona będzie wycena zapasu. Jeżeli wycena zapasu jest błędna, błędny będzie COGS – koszt własny sprzedaży. A wtedy raporty rentowności stają się po prostu ładnymi liczbami, którym nie można ufać.

I nagle ERP przestaje być „programem do magazynu”, a staje się narzędziem do zarządzania biznesem.

Potem przyszły magazyny. Cała siódemka operatorów

Kolejnym dużym kawałkiem projektu były integracje z 3PL.

Tutaj spędziliśmy naprawdę dużo czasu.

Trzeba było podłączyć około siedmiu różnych operatorów logistycznych. Na początku wydaje się: co w tym trudnego, siedem API, połączymy.

W praktyce robi się znacznie ciekawiej.

Jeden dostawca ma świetną dokumentację. U drugiego dokumentacja jest, ale API zachowuje się trochę inaczej. U trzeciego brakuje połowy informacji. U czwartego potrzebnego opisu nie da się znaleźć na stronie.

W pewnym momencie nie czytasz już dokumentacji API. Dzwonisz do ludzi w biurze i próbujesz ustalić, którego endpointu właściwie trzeba użyć, żeby dostać status przesyłki.

Mało romantyczny fragment projektu ERP.

W prezentacjach zwykle go nie pokazują.

Ale właśnie na takich rzeczach rozstrzyga się, czy prawdziwy projekt zacznie działać.

Ostatecznie zbudowaliśmy konektory do wszystkich potrzebnych operatorów 3PL. To dobry przykład tego, co w praktyce obejmuje integracja Odoo z zewnętrznymi systemami: sam dostęp do API jest dopiero początkiem.

Jak naprawdę działa taki konektor

W dużym uproszczeniu wyglądało to tak.

Kupujący składa zamówienie w Shopify. Zamówienie trafia do Odoo. Odoo ustala, z którego magazynu należy je wysłać. Nasz system sprawdza, który konektor odpowiada za ten magazyn.

Następnie operator 3PL otrzymuje informacje:

• kto jest kupującym;
• dokąd trzeba dostarczyć przesyłkę;
• jakie produkty i ilości obejmuje zamówienie;
• którego zamówienia dotyczy wysyłka;
• jakie parametry realizacji trzeba uwzględnić.

Magazyn wykonuje swoją pracę, a my czekamy na status zwrotny. Odbieramy go elektronicznie. Sprawdzamy, czy zamówienie rzeczywiście istnieje i czy nie zostało już przetworzone. Rejestrujemy operację magazynową w Odoo, a potem przekazujemy status z powrotem do e-commerce.

Opisane w kilku zdaniach brzmi to niemal nudno.

Teraz pomnóżcie to przez pięć spółek, kilka kanałów sprzedaży, siedem różnych systemów logistycznych i duży strumień zamówień.

Wtedy robi się ciekawiej.

Żeby nie budować siedmiu osobnych światów, zrobiliśmy wspólny router

Dość szybko doszliśmy do wniosku, że siedem całkowicie niezależnych integracji to kiepski pomysł.

Zbudowaliśmy więc wspólną warstwę routingu.

Logika jest prosta. Odoo ma rozumieć fakt biznesowy:

To zamówienie trzeba wysłać z tego konkretnego magazynu.

Dopiero router ustala, którego konektora 3PL użyć, w jakim formacie wysłać dane i jak zinterpretować odpowiedź.

W gruncie rzeczy próbowaliśmy sprawić, żeby siedem zupełnie różnych systemów logistycznych rozmawiało z Odoo tak, jakby uczestniczyły w jednym procesie.

To była chyba jedna z najbardziej użytecznych decyzji architektonicznych w całym projekcie. Podobne podejście stosujemy także przy integracji systemów informatycznych, gdy różne aplikacje trzeba połączyć w spójny przepływ danych.

Amazon i Shopify wyglądały na prostsze. Tylko wyglądały

Następną warstwą były kanały sprzedaży. Głównie Amazon i Shopify.

Podłączenie jednego sklepu Shopify do Odoo samo w sobie nie jest jakąś nadzwyczaj trudną sprawą. W przypadku Amazona również wiadomo, z czym mamy do czynienia.

Problem zaczyna się wtedy, gdy sklep, spółka i magazyn nie są po jednym.

Mieliśmy różne podmioty prawne, konta, magazyny i modele realizacji zamówień. Wszystko trzeba było bardzo starannie ze sobą powiązać.

Błąd w przypisaniu spółki oznacza nieprawidłową operację księgową. Błąd w przypisaniu magazynu – zamówienie zostanie skierowane nie tam, gdzie powinno. Błąd w przypisaniu produktu – i już nie można ufać stanom magazynowym.

Spora część pracy wyglądała więc mniej więcej tak:

skonfigurowaliśmy;

przetestowaliśmy;

znaleźliśmy problem;

zmieniliśmy konfigurację;

przetestowaliśmy ponownie;

przygotowaliśmy uruchomienie produkcyjne;

znaleźliśmy jeszcze jeden nietypowy przypadek;

wróciliśmy do ustawień.

I tak kilka razy.

Sam taki cykl nie oznacza, że ktoś źle wykonał pracę. Złożonego projektu ERP nie da się w pełni sprawdzić tylko na jednym ładnym scenariuszu testowym.

Prawdziwe problemy zaczynają się wtedy, gdy do systemu wchodzi prawdziwe życie.

W pewnym momencie model operacyjny wreszcie się poskładał

To był bardzo przyjemny etap.

Cały układ stopniowo zaczynał mieć sens. Odoo wiedziało już:

• jakie spółki i magazyny uczestniczą w procesach;
• gdzie znajduje się towar i do kogo należy;
• skąd przyszło zamówienie i który magazyn ma je wysłać;
• jak działa uzupełnianie zapasów;
• jak spółki handlują między sobą;
• jaki jest koszt towaru.

Od strony operacyjnej mieliśmy już całkiem spójny system.

Magazyny. Zapasy. Zakupy. Koszty. Routing. Amazon. Shopify. 3PL. Intercompany.

Można było odetchnąć.

Ale na krótko.

Bo potem zaczęła się księgowość.

Finanse okazały się osobnym projektem wewnątrz projektu

Bardzo szybko dociera do człowieka, że wiedza o fizycznym położeniu towaru nie wystarcza.

Dyrektora finansowego nie interesuje wyłącznie to, że sto sztuk przeniesiono z magazynu A do magazynu B. Potrzebuje też wiedzieć:

• kto jest właścicielem tego towaru;
• jaka jest jego wartość;
• czy nastąpiła sprzedaż wewnątrz grupy;
• gdzie powstał przychód;
• który kanał sprzedaży wygenerował koszt;
• jaka jest ostateczna rentowność.

Musieliśmy przygotować model finansowy obejmujący całą grupę.

Wszystkie spółki potrzebowały logicznej struktury kont. Trzeba było ustawić przychody i ich analitykę, COGS i jego analitykę, kanały sprzedaży oraz transakcje intercompany.

Tak naprawdę należało powiązać każdy fizyczny ruch towaru z jego znaczeniem finansowym.

Na tym etapie potrzebowaliśmy już wielu wspólnych ustaleń z zespołem finansowym klienta.

A potem pojawiło się Xero

Księgowość klienta od dawna działała w Xero.

Powstawał więc kolejny ciekawy układ: Odoo stopniowo stawało się głównym źródłem informacji operacyjnej, ale rzeczywistość księgowa nadal żyła w innym systemie.

Bez faktur od dostawców, operacji bankowych i zapisów księgowych obraz finansów w Odoo pozostawał niepełny.

Osobny przykład pracy z operacjami bankowymi znajdziesz w artykule o przelewach wewnętrznych w Odoo, wymianie walut i koncie Liquidity Transfer.

Trzeba było połączyć je z Xero.

Najpierw zdecydowaliśmy się na gotowy konektor z Odoo Apps. Rozumowanie było oczywiste: po co pisać coś, co już zostało napisane?

Niestety, właśnie tutaj czekała na nas jedna z najmniej przyjemnych części projektu.

Szybko odkryliśmy, że kupiony konektor nie obsługuje znacznej części rzeczywistych scenariuszy klienta. W prostym środowisku z jedną spółką być może sprawdziłby się całkiem dobrze.

U nas było pięć podmiotów prawnych, operacje bankowe, faktury dostawców, rozbudowana struktura kont i całkiem duży przepływ danych.

Gotowy konektor trzeba było poważnie przebudować.

Potem przebudować jeszcze trochę.

Potem poprawić jego zachowanie pod obciążeniem.

W pewnym momencie „gotowa integracja” stała się po prostu osobnym projektem programistycznym – takim, który wymagał rzeczywistego dostosowania Odoo.

Przydatna lekcja z tego projektu:

Ładne zrzuty ekranu konektora wcale nie gwarantują, że jest gotowy na Twoje środowisko produkcyjne.

Tego projektu na pewno nie można nazwać bezproblemowym

Nie chcę zamieniać tej historii w klasyczny marketingowy opis, w którym wszystko było idealnie.

Nie było.

Mieliśmy mnóstwo trudności. Część zadań niedoszacowaliśmy. Niektóre rzeczy robiliśmy dłużej, niż obiecaliśmy. Część integracji trzeba było przebudować.

Rozwiązania, które podczas analizy wydawały się właściwe, po sprawdzeniu w praktyce okazywały się niewygodne.

Czasem popełnialiśmy błędy.

Czasem po prostu nam nie szło.

Czasem odkrywaliśmy problem, którego wcześniej nie dało się przewidzieć.

W niektórych momentach projekt był zwyczajnie ciężki.

Ale chyba właśnie dlatego okazał się dla nas tak wartościowy.

Złożone projekty ERP są ciekawe nie dlatego, że wszystko działa za pierwszym razem. Są ciekawe dlatego, że stopniowo zamieniasz bardzo skomplikowany układ w coś, co da się zrozumieć.

A któregoś dnia odkrywasz, że na pytanie, które wcześniej wymagało zbierania informacji z pięciu miejsc, można już odpowiedzieć w jednym systemie.

Dlaczego uważam ten projekt za ważny

Nie dlatego, że wykorzystaliśmy ogromną liczbę modułów.

I nie dlatego, że stworzyliśmy jakąś magiczną technologię.

Wręcz przeciwnie.

Większość podstawowych elementów jest w Odoo całkiem standardowa: spółki, magazyny, trasy logistyczne, zakupy, sprzedaż, zapasy, księgowość, analityka i transakcje między spółkami.

Trudność pojawiła się przez skalę rzeczywistego biznesu.

Pięć spółek. Około siedmiu operatorów 3PL. Sprzedaż na całym świecie. Kilka kanałów e-commerce. Wiele magazynów. Handel wewnątrz grupy. Zewnętrzny system księgowy.

Wszystko musiało działać jak jeden system.

Właśnie takiego doświadczenia nie zdobędzie się na bazie demonstracyjnej. To jeden z powodów, dla których w naszym Portfolio pokazujemy rzeczywiste środowiska pracy, decyzje i rezultaty projektów.

Co z tego wyszło

Dzisiaj Odoo stopniowo staje się centralnym systemem informacyjnym tego biznesu.

Moim zdaniem to najważniejszy rezultat całego projektu.

Celem nie jest już dokładanie kolejnych osobnych programów. Przeciwnie – chcemy stopniowo zmniejszać liczbę miejsc, w których istnieje „własna wersja prawdy”.

Odoo ma być głównym źródłem informacji operacyjnej. Pozostałe systemy powinny albo otrzymywać z niego dane, albo przekazywać do niego informacje ze swoich wyspecjalizowanych obszarów.

E-commerce. Magazyny. Analityka. Księgowość. Logistyka.

Wszystkie powinny działać wokół jednego podstawowego modelu biznesu.

Co dalej

Następnym logicznym etapem jest księgowość.

Na razie część procesów finansowych pozostaje w Xero. Myślimy już jednak o stopniowym przeniesieniu większej liczby operacji księgowych bezpośrednio do Odoo. Chcielibyśmy, żeby stało się ono głównym systemem także dla finansów.

Wtedy architektura byłaby znacznie prostsza:

operacje odbywają się w Odoo;

księgowość działa w Odoo;

analityka otrzymuje dane z Odoo;

usługi zewnętrzne integrują się z Odoo.

Jedno główne źródło informacji zamiast kilku częściowo zsynchronizowanych systemów.

To jeszcze plan, nie zakończony etap wdrożenia. Najprawdopodobniej będzie to już osobny, kolejny projekt z tym klientem.

I trochę osobiście

Ten projekt nie był łatwy.

Były tygodnie, kiedy walczyliśmy z integracjami. Były decyzje, które trzeba było przemyśleć jeszcze raz. Były zadania, które zajęły znacznie więcej czasu, niż zakładaliśmy.

Ale dzisiaj bardzo się cieszę, że ten projekt do nas trafił.

Nieczęsto można zajrzeć do środka tak złożonego międzynarodowego biznesu i dostać możliwość rzeczywistej przebudowy jego architektury technologicznej.

Dla nas to bardzo cenne doświadczenie.

Jestem szczerze wdzięczny klientowi za zaufanie i za to, że mogliśmy je zdobyć.

A gdyby ktoś zapytał, czy chciałbym jeszcze raz podjąć się takiego projektu?

Tak.

Mimo wszystkich trudności – zdecydowanie tak.