Case study wdrożenia Odoo w firmie usługowo-handlowej — jak skrócić obieg zamówień o 37% i odzyskać kontrolę nad marżą

W wielu polskich firmach usługowo-handlowych problem nie polega już na braku klientów, ale na tym, że operacje nie nadążają za sprzedażą. Zamówienia wpadają z kilku kanałów, handlowcy pracują na różnych plikach, magazyn aktualizuje się z opóźnieniem, a zarząd widzi wynik zbyt późno, żeby odpowiednio zareagować. W tym case study pokazujemy modelowy scenariusz wdrożenia Odoo, w którym celem nie było „postawienie ERP”, ale skrócenie czasu obsługi zamówienia, poprawa kontroli marży i ograniczenie ręcznej pracy między działami. To przykład szczególnie ważny dla firm, które rosną szybciej niż ich procesy. Jeśli chcesz zobaczyć, jak podejść do wdrożenia etapami i gdzie zwykle pojawia się realny zwrot, ten materiał da Ci konkretną mapę działań.

Sytuacja wyjściowa firmy

Analizowana firma działała w modelu usługowo-handlowym B2B. Sprzedawała urządzenia i komponenty do klientów biznesowych, a jednocześnie realizowała usługi wdrożeniowe, serwisowe i opiekę powdrożeniową. Zespół liczył około 35 osób, z czego 8 pracowało bezpośrednio w sprzedaży i obsłudze klienta, 6 w operacjach zakupowo-magazynowych, a reszta w realizacji, serwisie i administracji. Przychody rosły dynamicznie, ale wraz ze wzrostem rosła też liczba wyjątków procesowych, ręcznych obejść i pomyłek. Firma miała już doświadczenie z różnymi narzędziami punktowymi, jednak żadne z nich nie spinało całego łańcucha od leada przez ofertę i zamówienie aż po zakup, dostawę, fakturę i raport marżowy.

W praktyce oznaczało to, że handlowcy pracowali jednocześnie w CRM, arkuszach i skrzynkach mailowych, dział zakupów miał osobne zestawienia dostaw, a zarząd dostawał raporty z opóźnieniem liczonym w dniach, nie godzinach. Każdy zespół potrafił „dowieźć swoją część”, ale brak wspólnego źródła prawdy powodował napięcia, błędy i utratę czasu. Problem był więc systemowy, a nie jednostkowy.

Najważniejsze problemy przed wdrożeniem

Przed uruchomieniem projektu zmapowano proces od zapytania ofertowego do rozliczenia zamówienia. Okazało się, że największe straty czasu i jakości pojawiają się w pięciu miejscach. Po pierwsze, oferty były przygotowywane w różnych wersjach i na różnych cennikach, przez co firma traciła kontrolę nad narzutem i wyjątkami handlowymi. Po drugie, po akceptacji oferty zamówienie trzeba było przepisać do kolejnych narzędzi, co generowało ryzyko błędu i opóźnienia. Po trzecie, dział zakupów nie widział w jednym miejscu priorytetów wynikających z terminów klienta oraz stanu dostępności. Po czwarte, status realizacji był rozproszony i wymagał dodatkowych telefonów lub wiadomości. Po piąte, raportowanie rentowności odbywało się po fakcie, więc korekty marży następowały zbyt późno.

Warto podkreślić, że żaden z tych problemów nie był „spektakularny” sam w sobie. Prawdziwym kosztem była ich suma: kilkanaście minut straty na jednym zamówieniu, kilka niepotrzebnych wiadomości w tygodniu na osobę, pojedyncze pomyłki cenowe i brak szybkiej informacji o odchyleniach. W firmie obsługującej dziesiątki lub setki zamówień miesięcznie taki model po prostu przestaje się skalować.

Najczęściej występujące objawy operacyjne

• Dublowanie pracy: te same dane były przepisywane do CRM, arkusza, zamówienia i dokumentów księgowych.
• Brak jednej wersji prawdy: różne działy widziały inne statusy tej samej sprawy.
• Spadek marży: rabaty i koszty dodatkowe nie zawsze były prawidłowo uwzględniane.
• Trudne planowanie zakupów: priorytety zmieniały się szybciej niż aktualizowane raporty.
• Napięcia między zespołami: problem procesowy był odbierany jako problem komunikacyjny.

Cele biznesowe i KPI projektu

Projekt został zdefiniowany przez cele biznesowe, a nie listę modułów. To ważne, bo wiele wdrożeń ERP zaczyna się od rozmowy o funkcjach, a kończy na nadmiernym zakresie. Tutaj przyjęto cztery KPI. Pierwszy: skrócenie czasu od akceptacji oferty do uruchomienia realizacji o minimum 25%. Drugi: wzrost udziału zamówień obsługiwanych bez ręcznego przepisywania danych do poziomu co najmniej 80%. Trzeci: możliwość podglądu marży na poziomie zamówienia w trakcie realizacji, a nie dopiero po zamknięciu miesiąca. Czwarty: ograniczenie liczby eskalacji statusowych i wewnętrznych „pingów” o minimum 30%.

Dodatkowo ustalono miękkie cele organizacyjne: zwiększenie przewidywalności pracy, łatwiejsze wdrażanie nowych osób oraz wzmocnienie odpowiedzialności procesowej. Zespół projektowy przyjął więc, że Odoo ma stać się centralnym systemem pracy, a nie wyłącznie repozytorium dokumentów.

Zakres wdrożenia Odoo

Zakres wdrożenia został świadomie zawężony do procesów, które wpływały na cash flow, marżę i doświadczenie klienta. W pierwszej fazie wdrożono moduły CRM, Sales, Purchase, Inventory, Accounting oraz wybrane elementy projektowe i serwisowe zależnie od rodzaju zleceń. Zrezygnowano z pokusy „wdrożenia wszystkiego od razu”. Taki ruch był istotny, bo umożliwił szybkie uruchomienie spójnego procesu end-to-end zamiast wielomiesięcznego projektu z niejasnym momentem wejścia na produkcję.

Dodatkowo przygotowano standardy danych: struktury produktów, wariantów, polityki cenowej, odpowiedzialności za rabaty oraz reguły nazewnictwa dokumentów. To pozornie mniej efektowna część projektu, ale w praktyce właśnie ona decyduje o jakości raportów i automatyzacji. Bez uporządkowanych danych nawet najlepszy system będzie tylko szybciej przenosił chaos.

Jeśli planujesz podobny projekt, warto wcześniej przeczytać także jak uporządkować sprzedaż, magazyn i finanse w jednym systemie oraz materiał o obszarach, w których automatyzacja daje szybki zwrot. Wspólny mianownik jest zawsze ten sam: najpierw proces, potem konfiguracja.

Etapy projektu krok po kroku

Projekt podzielono na pięć etapów. Etap pierwszy to warsztaty i mapowanie procesu. W praktyce oznaczało to nie tylko opisanie „jak jest”, ale też wskazanie, które wyjątki są uzasadnione biznesowo, a które wynikają wyłącznie z historycznych przyzwyczajeń. Etap drugi objął porządkowanie danych podstawowych: kartotek klientów, produktów, cenników i warunków handlowych. Etap trzeci to konfiguracja docelowego przepływu ofert, zamówień, zakupów i dostaw. Etap czwarty obejmował testy scenariuszowe na realnych przypadkach, w tym zamówienia mieszane, częściowe dostawy i korekty. Etap piąty to start produkcyjny oraz krótka faza stabilizacji.

Istotnym elementem było prowadzenie testów nie na „idealnym” scenariuszu, ale na sytuacjach z codziennej pracy: klient chce przyspieszyć wysyłkę, dostawca zmienia termin, część asortymentu jest dostępna od ręki, a część wymaga zakupu, pojawia się dodatkowa usługa wdrożeniowa albo niestandardowa pozycja na ofercie. Dzięki temu system został dopasowany do realiów operacyjnych, a nie tylko do prezentacji wdrożeniowej.

Automatyzacje, które dały najszybszy efekt

Największą wartość w pierwszych tygodniach przyniosły nie najbardziej zaawansowane funkcje, ale kilka dobrze dobranych automatyzacji. Po pierwsze, automatyczne przekazywanie danych z zaakceptowanej oferty do zamówienia i dalszego procesu. Po drugie, widoczność braków i zapotrzebowania zakupowego bez konieczności ręcznego budowania list. Po trzecie, standardowe powiadomienia i statusy dla zespołów, dzięki którym znacząco spadła liczba pytań „na jakim etapie to jest?”. Po czwarte, uporządkowany model odpowiedzialności za wyjątki cenowe i marżowe.

W firmie bardzo dobrze zadziałało też wprowadzenie jednego pulpitu dla menedżerów operacyjnych. Zamiast zbierać informacje z wielu miejsc, mogli w kilka minut zobaczyć zamówienia zagrożone, opóźnione zakupy, potencjalne ryzyka w marży oraz obciążenie zespołu. To nie tylko oszczędzało czas, ale też zmieniało jakość decyzji. Menedżer przestawał gasić pożary po sygnale z maila, a zaczynał reagować wcześniej.

Automatyzacje o najwyższym wpływie

• Oferta → zamówienie → zakup: jedno źródło danych dla kilku etapów procesu.
• Kontrola marży: czytelne zasady wyjątków i szybka identyfikacja odchyleń.
• Statusy operacyjne: mniej ręcznych aktualizacji, więcej pracy na zdarzeniach systemowych.
• Widok priorytetów: szybciej widać, które zlecenia wymagają reakcji dziś, a nie jutro.

Jeśli interesuje Cię część produkcyjna i operacyjna, dobrym uzupełnieniem będzie też artykuł o monitorowaniu realizacji w czasie rzeczywistym. W firmach, które łączą handel, usługi i elementy produkcyjne, właśnie przepływ danych między obszarami najszybciej pokazuje wartość ERP.

Wyniki po 90 dniach

Po około 90 dniach od startu produkcyjnego firma odnotowała kilka wyraźnych efektów. Średni czas od akceptacji oferty do uruchomienia realizacji skrócił się o 37%. Udział zamówień obsługiwanych bez ręcznego przepisywania danych przekroczył 85%. Liczba wewnętrznych eskalacji statusowych spadła o około 41%, a menedżerowie zaczęli pracować na raportach aktualnych operacyjnie, nie historycznie. Szczególnie istotna była poprawa kontroli marży. Firma szybciej identyfikowała zlecenia wymagające korekty ceny, dopłaty za dodatkowe usługi albo reakcji zakupowej.

Co ważne, nie wszystkie efekty były czysto liczbowe. Zespół sprzedaży zaczął szybciej wdrażać nowe osoby, bo proces był bardziej przewidywalny. Operacje miały mniej „niespodzianek” na końcu dnia. Zarząd zyskał też lepszą podstawę do planowania kolejnych inwestycji: automatyzacji w obszarze dokumentów, self-service dla klientów i dalszego rozwoju raportowania.

Najważniejsze lekcje z wdrożenia

Najważniejszy wniosek z tego typu projektu jest prosty: skuteczne wdrożenie Odoo nie zaczyna się od konfiguracji, tylko od decyzji, które procesy mają być standardem. Firmy najczęściej tracą czas i budżet wtedy, gdy próbują odwzorować w systemie każdy historyczny wyjątek. Znacznie lepsze wyniki daje zdefiniowanie modelu docelowego, który obsługuje 80–90% przypadków bez tarcia, a wyjątki traktuje świadomie i procesowo.

Druga lekcja dotyczy danych. Bez spójnych cenników, reguł rabatowych, nazw produktów i właścicieli procesów nawet najlepszy system nie pokaże pełnej wartości. Trzecia lekcja jest organizacyjna: wdrożenie trzeba prowadzić językiem biznesu. Pracownicy dużo szybciej akceptują zmianę, kiedy rozumieją, że chodzi o mniej chaosu, a nie „kolejny system do klikania”.

Właśnie dlatego firmy przygotowujące się do cyfryzacji finansów i dokumentów powinny równolegle czytać także o przygotowaniu procesu fakturowania pod KSeF. Integracja operacji z finansami nie jest dodatkiem do projektu ERP — to jego krytyczna część.

FAQ