Case study wdrożenia Odoo w firmie HVAC — jak skrócić czas ofertowania o 55%, odzyskać kontrolę nad serwisem i spiąć finanse z operacjami

W firmach HVAC chaos rzadko zaczyna się na montażu. Zwykle zaczyna się znacznie wcześniej: w ofertowaniu opartym o arkusze, w handlowcach pracujących na własnych wzorach, w zamówieniach materiałów składanych „na szybko” i w serwisie, który wie najwięcej, ale nie ma wspólnego systemu z resztą organizacji. Ten case study pokazuje, jak wyglądało wdrożenie Odoo w średniej firmie instalacyjno-serwisowej, która rosła szybciej niż jej procesy. Celem nie było kupienie modnego ERP, ale skrócenie czasu reakcji na zapytania, odzyskanie kontroli nad marżą projektów, uporządkowanie prac ekip terenowych i spięcie finansów z rzeczywistym przebiegiem realizacji. Poniżej opisujemy punkt wyjścia, architekturę procesu, zakres wdrożenia, konkretne decyzje projektowe oraz wyniki, które zarząd zobaczył już w pierwszym kwartale po starcie.

Sytuacja wyjściowa: szybki wzrost, ale bez wspólnego systemu operacyjnego

Firma działała w modelu mieszanym. Z jednej strony realizowała projekty instalacyjne dla klientów biznesowych, z drugiej utrzymywała stałe umowy serwisowe, a dodatkowo prowadziła sprzedaż części i drobnych modernizacji. Teoretycznie każdy obszar działał poprawnie. W praktyce dane były rozproszone między CRM-em, arkuszami Excel, skrzynkami mailowymi, komunikatorami i programem księgowym. Handlowiec przygotowywał ofertę w jednym pliku, kierownik projektu poprawiał harmonogram w drugim, magazyn miał trzecią listę materiałów, a finanse dostawały informację o realnym zakresie prac dopiero po zakończeniu etapu.

Przez długi czas firma radziła sobie dzięki zaangażowaniu ludzi. Problem pojawił się wtedy, gdy liczba równoległych projektów wzrosła, a zespół serwisowy zaczął obsługiwać coraz więcej zgłoszeń cyklicznych i awaryjnych. Każde nowe zlecenie zwiększało koszt koordynacji. Coraz trudniej było odpowiedzieć na proste pytania: ile naprawdę zarabiamy na danym projekcie, czy materiał jest już zabezpieczony, które zlecenia serwisowe są opóźnione, kto zaakceptował rabat oraz które faktury można wystawić bez ryzyka korekt. Zarząd widział przychód, ale nie widział wystarczająco szybko przyczyn odchyleń w marży.

Dodatkowym utrudnieniem była specyfika branży HVAC. Oferty często składały się z wielu pozycji, wersji wariantowych i zależności technicznych. Po wygraniu tematu firma musiała błyskawicznie przejść do zamówień, rezerwacji komponentów, harmonogramu ekip i ustalenia kamieni milowych do rozliczeń. Gdy każdy dział używał własnych narzędzi, rosło ryzyko, że zakres handlowy i zakres realizacyjny zaczną żyć osobno. To z kolei prowadziło do nadgodzin, pilnych zakupów i niepotrzebnych napięć między sprzedażą a operacjami.

Cele biznesowe i mierniki sukcesu

Na etapie discovery nie zaczynaliśmy od listy funkcji. Zaczęliśmy od pytań biznesowych, na które zarząd chciał odpowiadać co tydzień, a nie raz na miesiąc. Pierwszy cel dotyczył ofertowania: skrócić czas przygotowania kompletnej oferty i jednocześnie ograniczyć liczbę błędów wynikających z ręcznego kopiowania pozycji. Drugi cel dotyczył realizacji: połączyć projekt, zakupy, magazyn i harmonogram ekip tak, aby kierownicy projektów widzieli stan materiałowy oraz blokery bez dopytywania trzech osób. Trzeci cel dotyczył serwisu: uporządkować zgłoszenia, SLA, wizyty i rozliczenia, aby dział utrzymaniowy przestał działać reaktywnie. Czwarty cel dotyczył finansów: uzyskać szybszy i bardziej wiarygodny widok na marżę, zaliczki, fakturowanie etapowe i rentowność kontraktów.

Wspólnie ustaliliśmy zestaw mierników, które miały pokazać, czy wdrożenie daje realny efekt. Do KPI weszły: średni czas od wpłynięcia zapytania do wysłania oferty, udział ofert przygotowanych z użyciem standaryzowanych szablonów, liczba pilnych zakupów realizowanych poza planem, odsetek zleceń serwisowych zamkniętych w terminie SLA, czas potrzebny na przygotowanie danych do faktury oraz różnica między marżą planowaną i rzeczywistą na projekcie. Kluczowe było też to, aby każdy wskaźnik miał właściciela procesowego. Sam ERP nie podnosi jakości pracy, jeśli organizacja nie wie, kto odpowiada za definicję „danych poprawnych”.

To podejście ustawiło projekt we właściwej kolejności. Najpierw zdefiniowaliśmy przepływ danych i decyzji, dopiero potem role, widoki i automatyzacje. Dzięki temu uniknęliśmy częstego błędu: wdrażania modułów bez uzgodnienia, co dokładnie ma oznaczać „gotowa oferta”, „zabezpieczony materiał”, „rozpoczęte prace” albo „możliwość fakturowania”.

Jak ułożyliśmy proces w Odoo: od szansy sprzedażowej do serwisu posprzedażowego

Docelowy proces został zaprojektowany jako jeden ciąg operacyjny. Wszystko zaczynało się w CRM, gdzie handlowiec kwalifikował zapytanie i przypisywał je do typu: nowa instalacja, modernizacja, kontrakt serwisowy albo sprzedaż komponentów. Na tym etapie wprowadziliśmy obowiązkowe pola, które wcześniej funkcjonowały wyłącznie w mailach: lokalizacja obiektu, wymagany termin, typ klienta, zakres techniczny, poziom pilności i przewidywany model rozliczenia. Dzięki temu już w lejku można było odróżnić lead wymagający wizji lokalnej od zapytania, które da się wycenić szybciej.

Następny etap to ofertowanie. Zamiast budować każdy dokument od zera, firma dostała bibliotekę komponentów, usług i wariantów handlowych. Odoo połączyło część sprzedażową z logiką materiałową i kosztową. Handlowiec widział nie tylko cenę sprzedaży, ale także referencyjny koszt i wpływ rabatu na marżę. Tam, gdzie potrzebna była akceptacja, wdrożyliśmy progi decyzyjne. Jeśli rabat lub marża schodziły poniżej uzgodnionego poziomu, system wymagał zatwierdzenia. To ograniczyło sytuacje, w których sprzedaż wygrywała temat kosztem późniejszych problemów na projekcie.

Po akceptacji oferty proces przechodził do realizacji projektu. Zatwierdzone pozycje zamieniały się na zadania, zapotrzebowanie materiałowe oraz kamienie milowe. Kierownik projektu nie musiał już przepisywać zakresu z pliku ofertowego. Widział wszystko w jednym miejscu: status zakupów, plan ekip, terminy prac, zaległości i dokumenty klienta. Dla serwisu wdrożyliśmy oddzielny strumień obsługi zgłoszeń, ale oparty na tych samych danych klienta, urządzeń i historii realizacji. To było kluczowe, bo serwis nie zaczynał już od zgadywania, co zostało zamontowane i na jakich warunkach.

• CRM i pipeline: kwalifikacja szans według typu projektu i pilności.
• Sprzedaż: standaryzowane oferty, kontrola rabatów i marży.
• Projekt i operacje: zadania, kamienie milowe, harmonogram prac.
• Zakupy i magazyn: rezerwacje, braki materiałowe, zamówienia do dostawców.
• Serwis: zgłoszenia, SLA, wizyty terenowe, rozliczenia.
• Finanse: fakturowanie etapowe, zaliczki, analiza rentowności.

Tak zaprojektowana architektura miała jeszcze jedną przewagę: pozwalała budować raportowanie wokół przepływu pracy, a nie wokół działów. Zamiast raportu „co widzi sprzedaż” i osobnego raportu „co widzą finanse”, zarząd dostał wspólny obraz ścieżki klienta od pierwszego kontaktu do rozliczenia i obsługi posprzedażowej. To podejście dobrze uzupełnia praktyki opisane też w artykule Odoo ERP dla dystrybutora B2B, gdzie podobnie istotne było połączenie sprzedaży z zakupami i stanami.

Zakres modułów i integracji

Rdzeń wdrożenia objął CRM, Sales, Purchase, Inventory, Project, Accounting oraz procesy serwisowe i harmonogram prac w terenie. W praktyce najwięcej wartości dało nie samo „włączenie modułów”, ale ich właściwe spięcie. Na przykład status wygranej sprzedaży uruchamiał konkretne działania: tworzenie projektu, listy zadań, zapotrzebowania materiałowego i planu fakturowania. Dzięki temu firma przechodziła z etapu handlowego do operacyjnego bez ręcznego otwierania pięciu różnych narzędzi.

W obszarze magazynu wdrożyliśmy reguły rozróżniające materiały standardowe od pozycji kupowanych pod projekt. To pozornie drobna decyzja, ale w firmach HVAC ma ogromne znaczenie dla płynności. Jeśli wszystkie zakupy traktuje się tak samo, zespół albo mrozi kapitał w zapasach, albo wpada w tryb ciągłych pilnych zamówień. Odoo pozwoliło zbudować prostszy model: część indeksów trafiała do stałego obrotu magazynowego, a część była automatycznie wiązana z konkretnym zleceniem. W rezultacie kierownik projektu widział, czy brak materiału wynika z niedostępności u dostawcy, błędnej specyfikacji czy opóźnienia po stronie wewnętrznej.

W finansach skupiliśmy się na trzech rzeczach: zaliczkach, etapach i rentowności. Firma wcześniej potrafiła wystawić fakturę, ale miała problem z szybkim powiązaniem przychodu z realnym postępem i kosztami. Po wdrożeniu Odoo fakturowanie etapowe zostało powiązane z kamieniami milowymi projektu, a raportowanie marży mogło być przeglądane zarówno z perspektywy kontraktu, jak i całego portfela zleceń. To podejście jest szczególnie ważne także przy przygotowaniu firm do nowych wymogów obiegu dokumentów, o czym pisaliśmy szerzej w materiale KSeF 2026 w praktyce.

Przebieg wdrożenia krok po kroku

Pierwszy etap obejmował warsztaty procesowe z udziałem sprzedaży, kierowników projektów, zakupów, serwisu i finansów. To było krytyczne, bo największe ryzyko leżało nie w technice, lecz w różnicach interpretacyjnych. Dla handlowca „gotowa oferta” oznaczała dokument wysłany do klienta. Dla zakupów dopiero oferta zatwierdzona z kompletną specyfikacją. Dla finansów ważne było jeszcze to, czy uzgodniono model fakturowania. Wspólny warsztat pozwolił zamienić te skróty myślowe na konkretne statusy i reguły.

Drugi etap to uporządkowanie danych podstawowych. Lista klientów, lokalizacji, urządzeń, produktów i usług wymagała standaryzacji. Bez tego nie da się zbudować wiarygodnego raportowania. W wielu projektach ten krok jest traktowany jako nudna konieczność, a potem organizacja dziwi się, że ERP „nie pokazuje prawdy”. Tu zrobiliśmy odwrotnie: uznaliśmy jakość danych za element wdrożenia, a nie osobny temat poboczny.

Trzeci etap objął konfigurację procesu handlowego i projektowego, a dopiero potem serwis oraz finanse. Taka kolejność wynikała z faktu, że to właśnie przejście od oferty do realizacji generowało najwięcej strat. Nie wdrażaliśmy wszystkiego jednocześnie. Zaczęliśmy od najważniejszych punktów kontrolnych: czy lead jest poprawnie sklasyfikowany, czy oferta jest zbudowana na aktualnym katalogu, czy zwycięstwo handlowe tworzy projekt bez ręcznego przepisywania oraz czy kierownik projektu widzi braki materiałowe na czas.

Czwarty etap to testy scenariuszowe. Zamiast klikać pojedyncze funkcje, testowaliśmy pełne historie: nowy klient z projektem inwestycyjnym, modernizacja istniejącej instalacji, nagłe zgłoszenie serwisowe, przedłużenie umowy SLA, zakup materiałów pod konkretny etap oraz korekta faktury po zmianie zakresu. Taki sposób testowania szybciej ujawnia luki na styku działów. Dzięki temu przed startem produkcyjnym dopracowaliśmy zarówno uprawnienia, jak i komunikaty, które prowadziły użytkownika przez proces.

Piąty etap to uruchomienie produkcyjne z krótkim okresem wzmożonego wsparcia. Nie chodziło o to, aby użytkownicy „jakoś sobie poradzili”, tylko aby pierwsze tygodnie były momentem świadomej stabilizacji. Monitorowaliśmy, gdzie proces jest obchodzony, które pola są pomijane i gdzie organizacja próbuje wracać do starych plików. Właśnie w tym okresie najwięcej zyskuje firma, która traktuje wdrożenie jako zmianę sposobu pracy, a nie jako migrację systemową.

Wyniki po uruchomieniu: co zmieniło się w liczbach i codziennej pracy

Po pierwszym kwartale od startu firma odnotowała skrócenie średniego czasu przygotowania oferty o 55%. Nie wynikało to wyłącznie z automatyzacji dokumentów, ale przede wszystkim z uporządkowania danych wejściowych i wariantów ofertowych. Handlowcy przestali budować ofertę od zera, a kierownicy nie musieli później „tłumaczyć” specyfikacji na język realizacji.

Drugi efekt dotyczył serwisu. Dzięki wspólnemu widokowi zgłoszeń, historii urządzeń i zadań terenowych odsetek interwencji domykanych w założonym SLA wzrósł z 68% do 89%. Zespół mniej czasu poświęcał na szukanie informacji, a więcej na realną obsługę klienta. Dodatkowo możliwe stało się uporządkowane rozliczanie prac wykraczających poza standard kontraktu serwisowego.

Trzeci efekt pojawił się w finansach i controllingu. Firma nie musiała już czekać do końca miesiąca, żeby zobaczyć, gdzie uciekła marża. Kierownicy projektów i zarząd dostali szybszy widok odchyleń kosztowych. Różnica między marżą planowaną a rzeczywistą spadła, bo problemy były identyfikowane wcześniej: na etapie zakupu, zmian zakresu albo błędnych założeń czasowych. To szczególnie ważne w projektach, gdzie marża nie znika spektakularnie w jednym miejscu, tylko „wycieka” po trochu na wielu małych decyzjach.

Warto jednak podkreślić, że najbardziej odczuwalna zmiana nie dotyczyła samego wskaźnika, lecz jakości decyzji. Zarząd, sprzedaż i operacje zaczęli pracować na tych samych danych. Spadła liczba konfliktów wynikających z tego, że każdy dział miał „swoją prawdę”. Tego efektu nie da się osiągnąć samą tabelą w Excelu. Potrzebny jest wspólny model procesu, odpowiedzialności i statusów.

Najważniejsze lekcje dla firm, które planują podobne wdrożenie

Pierwsza lekcja: nie zaczynaj od modułów, zacznij od przepływu pracy. Jeśli nie wiesz, jak ma wyglądać przejście od leadu do realizacji i rozliczenia, nawet najlepsza konfiguracja ERP nie rozwiąże problemu. Druga lekcja: potraktuj dane podstawowe jak inwestycję. To one decydują, czy raport będzie wiarygodny, a automatyzacja bezpieczna. Trzecia lekcja: pilnuj punktów przekazania odpowiedzialności między działami. Najwięcej strat powstaje na styku sprzedaży, operacji, zakupów i finansów.

Czwarta lekcja dotyczy adopcji. Użytkownicy nie potrzebują wyłącznie szkolenia z kliknięć. Potrzebują zrozumieć, dlaczego nowy proces ogranicza ryzyko i oszczędza czas całej firmie. Piąta lekcja: wdrożenie ERP powinno prowadzić do lepszych decyzji menedżerskich, a nie tylko do „uporządkowania systemu”. Jeśli po starcie zarząd nadal nie widzi na czas, gdzie powstają odchylenia, projekt nie jest domknięty.

Jeżeli analizujesz podobny scenariusz w swojej firmie, warto zestawić potrzeby HVAC z szerszym podejściem do planowania i terminowości w MŚP oraz z architekturą procesów obsługi klienta i realizacji. W praktyce większość problemów jest wspólna: rozproszone dane, brak jednego workflow i za mało wiarygodnych sygnałów zarządczych.

Dla zespołu WorkToGrow ten projekt był też potwierdzeniem, że firmy usługowo-instalacyjne nie potrzebują „ciężkiego ERP dla korporacji”, tylko dobrze zaprojektowanego systemu, który szanuje codzienną pracę operacyjną. Odoo sprawdziło się dlatego, że pozwoliło połączyć porządek procesowy z elastycznością wdrożenia. Organizacja nie musiała zmieniać wszystkiego na siłę. Musiała natomiast jasno ustalić, które dane są obowiązkowe, które decyzje muszą być zatwierdzane i kiedy proces może przejść do kolejnego etapu. To właśnie te reguły, a nie sama technologia, odpowiadają za trwały efekt biznesowy.

W praktyce podobny schemat można zastosować również poza HVAC: w firmach serwisowych, dystrybucyjnych, instalacyjnych i produkcyjnych, które łączą sprzedaż projektową z utrzymaniem posprzedażowym. Jeśli firma dziś korzysta z kilku narzędzi i dużej liczby wyjątków, wdrożenie powinno zacząć się od zidentyfikowania powtarzalnych punktów krytycznych. Gdzie gubią się dane? Gdzie trzeba ręcznie dopisywać informacje? Gdzie opóźnienie jednej osoby blokuje cały następny etap? Odpowiedzi na te pytania są ważniejsze niż wybór pojedynczej funkcji.

Dlatego przed rozpoczęciem projektu zawsze warto zbudować krótką mapę decyzji zarządczych. Jakie informacje mają być widoczne codziennie, tygodniowo i miesięcznie? Kto odpowiada za jakość danych sprzedażowych, materiałowych, projektowych i finansowych? Jak wygląda eskalacja, kiedy projekt traci marżę albo serwis nie wyrabia SLA? Jeżeli te pytania są jasno zaadresowane, ERP staje się realnym narzędziem sterowania firmą, a nie kolejną bazą danych. To właśnie różnica między wdrożeniem, które „działa”, a wdrożeniem, które realnie poprawia wynik operacyjny.

FAQ