AI zmieniło Twoje Odoo. Teraz zespół nie może pracować.

Prosisz AI o poprawienie formularza w Odoo, dodanie obliczenia albo przygotowanie raportu. Dostajesz kod i wdrażasz zmianę.

A potem pracownik nie może zapisać dokumentu. Otwarcie raportu sprawia, że serwer przestaje odpowiadać. Prosisz AI o kolejną poprawkę, ale proces biznesowy nadal nie działa.

Zmiana mogła być niewielka. Jej wpływ na firmę bywa znacznie większy.

Jeżeli Odoo obsługuje klientów, operacje i księgowość, błąd w dobudowanej funkcji staje się problemem wszystkich osób pracujących w tym procesie. W ERPixel widzieliśmy to w praktyce.

Francuska firma ubezpieczeniowa nie mogła przyjmować wniosków

Jeden z naszych klientów to firma ubezpieczeniowa we Francji. Jej oddziały korzystają z Odoo do obsługi klientów, obliczeń ubezpieczeniowych i prowadzenia ewidencji, w tym księgowości.

Klient użył AI do zmiany sposobu obliczeń w dokumencie wniosku. Chodziło o dokładniejsze wyliczenie konkretnego elementu ubezpieczenia i dostosowanie go do wymagań prawnych.

Po zmianie pola i mechanizm ponownego przeliczania we francuskojęzycznym formularzu uniemożliwiały zapisanie dokumentu oraz przekazanie go do dalszej obsługi.

Z perspektywy pracownika sytuacja była prosta: klient chciał złożyć wniosek, a formularz nie działał. W sześciu biurach błąd w kodzie przerwał obsługę klientów.

Co spowodowało awarię?

Podczas przeglądu znaleźliśmy błędy składniowe oraz przestarzały sposób korzystania z modeli Odoo, niezgodny z Odoo 17.

Wygenerowany kod odwoływał się do modeli działających inaczej w wersji używanej przez klienta. Formularz nie pozwalał już wykonać operacji potrzebnej pracownikom.

Odtworzenie problemu było proste. Zrozumienie przyczyny wymagało wspólnego sprawdzenia formularza, obliczeń i odpowiednich modeli Odoo.

Jak to naprawiliśmy?

Wprowadziliśmy punktową poprawkę w kodzie i dodaliśmy komentarze wyjaśniające zmiany osobom, które będą dalej rozwijać rozwiązanie.

Zauważyliśmy również bałagan w zarządzaniu wersjami. Nie było prostej drogi wycofania wdrożenia: odwrócenie zmian wymagałoby ręcznej pracy i zapisania jej w nowym commicie.

Po usunięciu awarii przejrzeliśmy repozytorium, uporządkowaliśmy gałęzie i przygotowaliśmy instrukcje dla AI dotyczące pracy z nimi. Poprawiliśmy też skrypty wdrożeniowe, aby kod bez testów i przeglądu nie trafiał do środowiska produkcyjnego.

Bezpośrednim problemem był niedziałający formularz. Szerszy problem dotyczył sposobu, w jaki zmiany trafiały do używanego systemu.

Raport rotacji zapasów sprawiał, że Odoo stawało się niedostępne

U innego klienta AI przygotowało raport rotacji zapasów.

Po otwarciu raport próbował od razu przeliczyć dużą liczbę ruchów towarowych i powiązanych zapisów. Jedno żądanie wyświetlenia wyniku uruchamiało rozległe przetwarzanie danych.

Obciążenie procesora i serwera powodowało niedostępność Odoo. Raport miał pomóc pracownikom zrozumieć, jak obraca się zapas. Tymczasem jego otwarcie uniemożliwiało korzystanie z systemu.

Skąd brało się przeciążenie?

Przyjęty sposób obliczeń wymagał zbyt dużo pracy dokładnie w chwili, gdy użytkownik otwierał raport.

Zamiast odczytać przygotowane wyniki, system za każdym razem przetwarzał dużą historię zapisów źródłowych. Nie był to już tylko wolny raport: obciążenie dotykało serwera, na którym działało Odoo.

Jak to naprawiliśmy?

Dodaliśmy tabele pośrednie i wcześniejsze obliczanie potrzebnych wyników. Raport mógł odczytać przygotowane dane zamiast ponownie przeliczać całą historię przy każdym otwarciu.

Pytanie biznesowe pozostało takie samo. Zmieniliśmy sposób, w jaki system przygotowywał odpowiedź.

Kod może wykonywać zamówione obliczenie, a mimo to nie nadawać się do ilości danych i środowiska, w którym ma pracować.

O tym, jak definiujemy wskaźniki, przygotowujemy obliczenia i dobieramy warstwę raportową, piszę szerzej w artykule o dashboardach i raportowaniu w Odoo 19. To osobny projekt i inny przykład niż opisana tutaj awaria raportu.

Dlaczego takie błędy są problemem dla biznesu?

Obie awarie miały inne przyczyny techniczne, ale podobny skutek: pracownicy nie mogli dokończyć swojej pracy.

W firmie ubezpieczeniowej nie dało się zapisać i wysłać wniosku. W drugim przypadku próba uzyskania informacji powodowała niedostępność całego systemu.

Koszt takiej przerwy to znacznie więcej niż czas programisty:

• Pracownicy czekają albo szukają obejścia.
• Obsługa klientów i zadania operacyjne się opóźniają.
• Zespół techniczny odrywa się od zaplanowanych prac.
• Po przywróceniu systemu pozostają jeszcze zaległości do nadrobienia.

Mała usterka może więc wywołać poważny problem operacyjny.

Sytuacja staje się trudniejsza, gdy nie ma zespołu gotowego do diagnozy. Ktoś musi zrozumieć wymaganie biznesowe, przejrzeć kod, znaleźć przyczynę i zdecydować, jak bezpiecznie zmienić rozwiązanie.

Kolejny prompt może dać więcej kodu. Sam w sobie nie wyjaśnia jednak, która zmiana wywołała awarię ani czy proponowana poprawka pasuje do reszty Odoo.

Co te przypadki mówią o rozwijaniu Odoo z AI?

Najważniejsze pytanie brzmi: czy przygotowana zmiana działa w rzeczywistym systemie klienta?

Czy pracownik może dokończyć dokument? Czy implementacja pasuje do używanej wersji Odoo? Czy raport poradzi sobie z ilością danych bez przeciążenia serwera? Czy zespół potrafi ustalić, jaki kod wdrożono, i go wycofać?

Te pytania łączą programowanie z procesem biznesowym.

Działające wydanie wymaga jasnego opisu zadania, przeglądu kodu, odpowiednich testów i kontrolowanego wdrożenia. Zmiany generowane przez AI również potrzebują takiego procesu.

Jeśli dopiero planujesz rozszerzenie, zobacz, jak podchodzimy do dostosowywania Odoo do procesów firmy. Możliwości Studio i funkcji AI omawiamy też w artykule o Odoo 20. Konfiguracja w Studio i kod przygotowany przez asystenta AI wymagają oceny w kontekście konkretnego rozwiązania.

Jak ERPixel może pomóc?

W ramach audytu i naprawy zmian Odoo przygotowanych z AI pomagamy firmom, których dobudowane funkcje przestały działać albo wymagają sprawdzenia przed wdrożeniem.

Możesz wybrać jeden z dwóch sposobów współpracy.

Jednorazowa pomoc przy pilnym problemie

Zajmujemy się konkretnym incydentem: błędem po wdrożeniu, zablokowanym obiegiem pracy, przeciążonym serwerem albo zmianami, których Twój zespół nie potrafi bezpiecznie wycofać.

Badamy problem, wyjaśniamy ustalenia i proponujemy poprawkę. Na początku ustalamy priorytet zgłoszenia oraz dostęp potrzebny do diagnozy. Zakres prac zależy od tego, co znajdziemy w systemie.

Stałe wsparcie Odoo

Stałe wsparcie Odoo pozwala objąć rozwój z AI regularnym przeglądem i utrzymaniem.

Sprawdzamy repozytorium Git, proponowane zmiany oraz ich zgodność z istniejącym kodem. Wykonujemy techniczny code review, badamy uzgodnione obszary pod kątem podatności i pomagamy doprecyzować wymagania biznesowe oraz prompty.

Pracujesz z wyznaczonym zespołem ludzi i korzystasz z dedykowanego kanału komunikacji. Zakres dostępności ustalamy indywidualnie.

Francuska firma ubezpieczeniowa korzysta dziś właśnie z takiego podejścia. Przeglądamy proponowane wydania, wskazujemy problemy i rekomendujemy poprawki przed wdrożeniem.

Od czego zacząć i co otrzymasz?

Skontaktuj się z ERPixel i opisz:

• Co pracownik próbuje zrobić?
• Co dzieje się zamiast oczekiwanego rezultatu?
• Kiedy problem się pojawił?
• Co zmieniono tuż przed jego wystąpieniem?

„Nie możemy zapisać i wysłać wniosku” wystarczy, aby rozpocząć rozmowę. Nie musisz samodzielnie wskazywać błędnej metody w kodzie.

Ustalamy zasady współpracy i uzgadniamy dostęp do serwera oraz repozytorium kodu źródłowego.

Głównym rezultatem audytu jest zwięzły raport z audytu — Audit Report, który zawiera:

1. Twój problem: sytuację z perspektywy pracowników.
2. Nasze ustalenia: wykryte błędy i ich wpływ na proces.
3. Proponowane rozwiązania: zmiany, które rekomendujemy do zatwierdzenia.

Przeglądasz raport i akceptujesz kierunek działania. Następnie przygotowujemy zakres oraz wycenę naprawy do osobnego zatwierdzenia przed realizacją. Ocenę determinują między innymi moduły, integracje, dane i potrzebne testy.

Praca może polegać na usunięciu błędu, zmianie sposobu obliczeń, refaktoryzacji kodu porządkującej jego strukturę albo zastąpieniu zbędnej logiki własnej. Gdy problem dotyczy wymiany danych, sprawdzamy również powiązania opisane w zakresie integracji Odoo.

Zmiany wprowadzamy w osobnych gałęziach Git. Twój zespół techniczny może sprawdzić i zaakceptować kod przed wdrożeniem. Uporządkowana kontrola wersji pozwala prześledzić poprawki i w razie potrzeby wycofać nasz kod. Wycofanie kodu i przywrócenie danych w bazie to odrębne zadania.

Po rozwiązaniu bieżącego problemu możemy dalej przeglądać i wspierać kolejne wydania.

Jeśli zmiana przygotowana z AI zatrzymała pracę firmy albo chcesz sprawdzić kod przed następnym wdrożeniem, porozmawiaj z ERPixel.