Procesy zaczynają omijać system
Część pracy wraca do Excela, maili albo dodatkowych plików, ponieważ obecny proces w Odoo nie odpowiada już temu, jak faktycznie działa firma.
Przejmujemy opiekę nad działającym Odoo, usuwamy problemy techniczne i rozwijamy system wraz ze zmianami w firmie. Pracujemy nad modułami, procesami, integracjami i własnymi rozszerzeniami Odoo.
Uruchomienie systemu nie kończy pracy nad Odoo.
Producent wprowadza nowe produkty, zmienia sposób planowania produkcji, uruchamia kolejny magazyn, rozwija sprzedaż B2B, zmienia zasady zakupów albo podłącza nowe systemy. Proces, który podczas wdrożenia był prosty, po dwóch latach może wyglądać zupełnie inaczej.
Problem zaczyna się wtedy, gdy Odoo przestaje nadążać za tymi zmianami.
Sprawdźmy, co dziś ogranicza Twój systemCzęść pracy wraca do Excela, maili albo dodatkowych plików, ponieważ obecny proces w Odoo nie odpowiada już temu, jak faktycznie działa firma.
Nowy typ zamówienia, dodatkowy magazyn, nietypowa produkcja albo kolejna grupa klientów powodują następne ręczne obejścia.
ERP nie działa w izolacji. Zmiana platformy e‑commerce, WMS, systemu kurierskiego albo sposobu wymiany danych może wymagać przebudowania istniejącej integracji.
Im więcej własnych modułów i modyfikacji, tym ważniejsze jest sprawdzenie ich zgodności z kolejną wersją Odoo przed aktualizacją środowiska produkcyjnego. Oficjalny proces Odoo również zakłada osobne testowanie upgrade'u oraz dostosowanie własnych modułów do wersji docelowej.
Zakres zależy od tego, jak Odoo jest wykorzystywane w firmie i które procesy zostały już dostosowane do jej potrzeb.
Nie zaczynamy od listy przypadkowych zmian. Najpierw ustalamy, które elementy systemu wpływają na codzienną pracę zespołu oraz gdzie powstają błędy, ręczne operacje i ograniczenia.
Obszary prac
Ważne: Zakres utrzymania i rozwoju zależy od wersji, edycji, zainstalowanych aplikacji i modelu hostingu Odoo. Community i Enterprise różnią się zakresem dostępnych funkcji, a Odoo Online nie pozwala instalować niestandardowych modułów kodowych. Przed rozpoczęciem prac sprawdzamy więc nie tylko procesy i kod, ale również wariant systemu, z którego korzysta firma.
Zmiana firmy odpowiedzialnej za Odoo nie powinna zaczynać się od pierwszego zgłoszenia do naprawy. Najpierw trzeba ustalić, co właściwie działa w systemie. Tak samo zaczynamy każdą współpracę przy utrzymaniu i rozwoju Odoo.
Ustalamy wersję i edycję Odoo, model hostingu, plan subskrypcyjny (jeżeli dotyczy), używane aplikacje, dodatkowe moduły i najważniejsze zależności.
Rozdzielamy funkcje standardowe, konfigurację oraz rozwiązania napisane specjalnie dla firmy. Sprawdzamy kod własnych modułów i miejsca wymagające uporządkowania.
Ustalamy, jakie systemy wymieniają dane z Odoo, w którym kierunku przepływają informacje oraz gdzie obsługiwane są błędy synchronizacji.
Sprawdzamy, które elementy Odoo są krytyczne dla sprzedaży, magazynu, zakupów i produkcji, oraz wskazujemy procesy, których problemy bezpośrednio wpływają na pracę zespołu.
Oddzielamy problemy wymagające naprawy i dług techniczny od rozwoju wynikającego z potrzeb biznesowych. Najpierw zajmujemy się elementami krytycznymi, następnie planujemy rozwój zgodnie z procesami i celami firmy.
Dopiero wtedy można odpowiedzialnie planować kolejne zmiany.
Odoo obejmuje znacznie więcej niż sprzedaż i CRM. Platforma posiada obszary związane między innymi z magazynem, zakupami, produkcją, jakością, utrzymaniem ruchu, sprzedażą i księgowością.
Dostępność poszczególnych funkcji zależy jednak od edycji i zainstalowanych aplikacji. Nie zakładamy więc, że każda instalacja Community i Enterprise oferuje identyczny zakres. Dlatego rozwój systemu u producenta może dotyczyć kilku połączonych procesów.
Zmiany w BOM, zleceniach produkcyjnych i sposobie planowania produkcji, a w zależności od edycji i uruchomionych aplikacji również w operacjach, stanowiskach roboczych i bardziej rozbudowanej obsłudze wykonania produkcji.
Nowe magazyny i lokalizacje, zasady uzupełniania zapasów, partie, numery seryjne oraz przepływ materiałów i gotowych produktów.
Rozwój procesu zaopatrzenia, reguł zamawiania, współpracy z dostawcami i powiązania zakupów z zapotrzebowaniem magazynu lub produkcji.
W Odoo Enterprise zakres może obejmować aplikację Quality, która pozwala tworzyć punkty kontroli i kontrole jakości powiązane z produkcją oraz operacjami magazynowymi. W przypadku Odoo Community sposób obsługi jakości oceniamy osobno w zależności od procesu i dostępnych rozszerzeń.
Obsługa urządzeń, zgłoszeń serwisowych oraz działań prewencyjnych i naprawczych może zostać powiązana z procesami produkcyjnymi Odoo. Dokładny zakres zależy od wersji, zainstalowanych aplikacji i konfiguracji środowiska.
Zmiany w obsłudze klientów, ofertowaniu, cennikach, zamówieniach oraz przepływie informacji pomiędzy Odoo i kanałami sprzedaży.
Nie oznacza to, że każda firma powinna korzystać ze wszystkich modułów. Zakres powinien wynikać z procesów, które rzeczywiście warto prowadzić w jednym środowisku.
U producenta Odoo może znajdować się pomiędzy sprzedażą, magazynem, zakupami i produkcją. Dlatego przy rozwoju systemu patrzymy nie tylko na ekran, na którym użytkownik zgłosił problem.
Sprawdzamy cały przepływ
Dopiero wtedy można zdecydować, gdzie powinna powstać zmiana i które systemy rzeczywiście muszą zostać nią objęte.
Zobacz Odoo dla produkcjiDziałający system potrzebuje obu.
Dotyczy tego, co już działa i powinno nadal działać poprawnie.
Obejmuje między innymi:
Dotyczy zmian wynikających z nowych potrzeb firmy.
Może obejmować:
Dzięki takiemu podziałowi awarie i bieżące problemy nie konkurują bezpośrednio z planowanym rozwojem systemu.
Nie każdą potrzebę biznesową warto rozwiązywać nowym modułem. Czasem wystarczy konfiguracja istniejącego procesu. Czasem problem wynika z tego, że odpowiedzialność została przypisana do niewłaściwego systemu. Innym razem własne rozszerzenie rzeczywiście jest uzasadnione. Przed rozpoczęciem większej zmiany sprawdzamy trzy możliwości:
Czy proces można obsłużyć funkcjami, które system już posiada?
Czy potrzebę można rozwiązać bez rozwijania własnego kodu?
Czy specyfika firmy rzeczywiście wymaga własnego modułu lub rozszerzenia istniejącego rozwiązania?
Własny kod daje elastyczność, ale trzeba go później utrzymywać i dostosowywać przy kolejnych zmianach wersji Odoo. Dlatego customizacja powinna rozwiązywać konkretny problem, a nie zastępować analizę procesu.
Przejście na kolejną wersję Odoo nie sprowadza się do uruchomienia aktualizacji. Szczególnie wtedy, gdy system posiada własne moduły, integracje albo zmodyfikowane procesy.
Odoo wskazuje, że przy bazach zawierających własne moduły trzeba dostosować kod do wersji docelowej i przetestować go przed aktualizacją produkcji. Oficjalny proces upgrade'u dla baz customizowanych obejmuje między innymi przygotowanie modułów do nowej wersji, pracę na zaktualizowanej bazie testowej, testy oraz próbę całego procesu przed przejściem produkcyjnym.
Zakres takiego upgrade'u zależy również od hostingu. Odoo Online nie pozwala instalować niestandardowych modułów Python, więc scenariusz aktualizacji różni się od Odoo.sh i instalacji on-premise.
Przed zmianą wersji sprawdzamy
Następnie przygotowujemy środowisko testowe i scenariusze procesów, które muszą zostać sprawdzone przed uruchomieniem nowej wersji produkcyjnie.
Utrzymanie Odoo obejmuje również miejsca, w których dane przechodzą pomiędzy systemami.
Odoo udostępnia mechanizmy pozwalające integrować dane i funkcje platformy z zewnętrznymi aplikacjami. W Odoo 19 dostępne jest również External JSON-2 API.
Dostęp do zewnętrznego API zależy jednak od wariantu Odoo. W aktualnej ofercie subskrypcyjnej Odoo External API jest dostępne w planie Custom, a nie w One App Free ani Standard. Odoo Community nie jest jednym z tych planów subskrypcyjnych, dlatego przy instalacjach Community i własnym hostingu możliwości konkretnego połączenia sprawdzamy osobno.
Odoo może komunikować się między innymi z:
Przy zmianie jednego elementu sprawdzamy wpływ na cały przepływ danych
Może wpływać na to, co pokazuje sklep.
Może wymagać zmiany integracji.
Może zmienić informacje przekazywane do kanałów sprzedaży.
Dlatego rozwijamy nie tylko pojedynczą funkcję Odoo, ale również jej miejsce w całym procesie.
Zobacz integracje OdooNajczęściej wtedy, gdy:
Nie każdy taki przypadek wymaga przebudowy systemu. Pierwszym krokiem jest ustalenie, gdzie znajduje się rzeczywiste ograniczenie. Jeżeli okaże się, że potrzebne jest nowe środowisko albo zmiana ERP, właściwym zakresem jest wdrożenie Odoo. Pełną listę prac przy systemie znajdziesz w usługach Odoo.
Pokaż nam, jak dziś działa Twoje OdooPrzejęcie, własne moduły, integracje, upgrade i edycje Odoo.
Tak. Przejęcie zaczynamy od poznania obecnego środowiska, wykorzystywanych modułów, własnych modyfikacji, integracji oraz najważniejszych procesów biznesowych. Na tej podstawie ustalamy zakres prac potrzebnych przed rozpoczęciem regularnego rozwoju.
Tak, jeżeli wykorzystywane środowisko pozwala instalować własne moduły kodowe. Jeżeli standardowe możliwości i konfiguracja Odoo nie wystarczają do obsługi uzasadnionego procesu biznesowego, zakres może obejmować przygotowanie lub rozwój własnego modułu. Odoo Online nie obsługuje niestandardowych modułów kodowych, dlatego taki rozwój wymaga innego modelu hostingu.
Nie. W pierwszej kolejności sprawdzamy, czy potrzebę można obsłużyć standardowymi funkcjami Odoo albo zmianą konfiguracji. Własny kod dokładamy wtedy, gdy jest rzeczywiście potrzebny.
Tak. Zakres może obejmować analizę istniejącej integracji, mapowania danych, kierunków synchronizacji, obsługi błędów oraz zmian potrzebnych po jednej lub obu stronach integracji. Więcej o tym, jak projektujemy połączenia, piszemy na stronie integracji Odoo.
Nie. Zakres integracji nie ogranicza się do jednej konkretnej platformy e‑commerce. Techniczny sposób połączenia zależy jednak od możliwości obu systemów oraz wariantu Odoo. W planach subskrypcyjnych Odoo dostęp do External API jest przewidziany dla planu Custom, dlatego przed zaprojektowaniem integracji sprawdzamy edycję, plan, hosting i dostępne interfejsy konkretnej instalacji.
Tak. Zakres może obejmować analizę obecnej instalacji, przygotowanie własnych modułów, testowy upgrade, weryfikację integracji i kluczowych procesów oraz przygotowanie przejścia na wersję produkcyjną.
Własne moduły trzeba zweryfikować i w razie potrzeby dostosować do docelowej wersji Odoo. Oficjalna dokumentacja Odoo wskazuje, że kod customowych modułów musi być zgodny z wersją docelową przed wykonaniem upgrade'u bazy.
Może obejmować. Odoo posiada obszary związane między innymi z produkcją, magazynem, zakupami, jakością i utrzymaniem ruchu, więc zakres rozwoju może dotyczyć również procesów charakterystycznych dla producenta. Dostępność konkretnych funkcji zależy od edycji i zainstalowanych aplikacji. Przykładowo standardowa aplikacja Quality należy do zakresu Odoo Enterprise. Szerzej opisujemy to na stronie Odoo dla produkcji.
Zakres prac zawsze zaczynamy od sprawdzenia konkretnej instalacji. Community i Enterprise różnią się funkcjami i modelem licencyjnym, a dodatkowo możliwości zależą od hostingu oraz zainstalowanych modułów. Dlatego przed przejęciem lub rozwojem potwierdzamy, co jest dostępne w obecnym wariancie i czy planowane zmiany wymagają Enterprise, dodatkowego modułu albo zmiany środowiska.
Od zebrania informacji o obecnej instalacji i procesach. Potrzebujemy przede wszystkim wersji i edycji Odoo, modelu hostingu, planu subskrypcyjnego (jeżeli dotyczy), listy wykorzystywanych modułów, informacji o własnych rozszerzeniach, integracjach oraz problemach, które obecnie najbardziej utrudniają pracę.
Opisz, jak Odoo jest dziś wykorzystywane w Twojej firmie, które obszary zostały zmodyfikowane i co obecnie wymaga poprawy.
Na tej podstawie ustalimy, czy pierwszym krokiem powinno być przejęcie utrzymania, uporządkowanie istniejącego rozwiązania, poprawa integracji, upgrade czy rozwój kolejnego procesu.

Co warto przygotować?
Zapytanie wysłane
Dziękujemy, odezwiemy się w ciągu 1 dnia roboczego.
Zapytanie nie zostało wysłane
Zaznaczyliśmy pola, które trzeba uzupełnić albo poprawić.