Jak wybrać system ERP? Moje doświadczenia z dużych firm i przetargów

Chcę opowiedzieć, jak duży biznes podejmuje decyzję o wyborze ERP. Uczestniczyłem w takich projektach po stronie klienta, a także brałem udział w kilku dużych przetargach na wdrożenie systemów dla przedsiębiorstw.

Od razu wyjaśnię, o jakim doświadczeniu mówię. Chodzi o duże, dojrzałe organizacje ze specyficznymi procesami i złożoną strukturą. Biznes może na przykład składać się z sześciu spółek, które są ze sobą powiązane i uczestniczą we wspólnej działalności. Jedna kupuje towar, druga zajmuje się logistyką, trzecia sprzedaje, a zarząd chce widzieć sytuację każdej spółki oraz całej grupy.

W takich organizacjach wybór systemu ERP jest ściśle związany ze sposobem podejmowania decyzji inwestycyjnych. Dlatego zacznę od tego, jak firma działa od środka. Bez tego trudno zrozumieć, dlaczego wybór trwa tak długo, kto na niego wpływa i co zamawiający faktycznie ocenia.

Myślę, że te doświadczenia przydadzą się zarówno menedżerom zastanawiającym się, jaki system ERP wybrać, jak i konsultantom, którzy chcą pracować przy dużych projektach.

Po wyborze platformy przychodzi kolejna decyzja: jak dojść do uruchomienia. W osobnym artykule porównuję trzy podejścia i etapy wdrożenia ERP: klasyczne, iteracyjne oraz start od standardu.

1. Najpierw pojawia się projekt i uzasadnienie inwestycji

W dużej firmie zwykle działa kilka gremiów decyzyjnych: zarząd, rada nadzorcza, komitet zarządzania projektami. Nazwy i kompetencje mogą się różnić, ale cel jest praktyczny: istotne inwestycje powinny być uzgadniane z uwzględnieniem interesów różnych uczestników biznesu.

Wdrożenie ERP przechodzi przez ten sam system podejmowania decyzji.

Kiedy firma dochodzi do wniosku, że potrzebuje nowej ERP, powstaje wewnętrzny projekt. Musi mieć uzasadnienie, dokumentację i osoby odpowiedzialne za jego prowadzenie.

Zwykle są to kierownik projektu, właściciel biznesowy lub sponsor oraz formalny inicjator — osoba albo dział, od których wyszła inicjatywa. Ktoś odpowiada za oczekiwany rezultat biznesowy, ktoś organizuje pracę, a ktoś ma uprawnienia do zatwierdzenia finansowania.

W mojej praktyce jednym z podstawowych dokumentów była karta projektu, czyli project charter. To znane narzędzie formalnego zarządzania projektami, między innymi podejść związanych z PMBOK — zbiorem wiedzy o zarządzaniu projektami.

W karcie zapisuje się mniej więcej taką myśl:

„Jako firma rozważamy wdrożenie nowej ERP do obsługi określonych procesów biznesowych. Oczekujemy takich rezultatów, przyjmujemy określone ramy czasowe i budżetowe oraz stawiamy systemowi następujące zasadnicze wymagania”.

Ważne, żeby właściwie rozumieć rolę tego dokumentu. To nie formalność przygotowana po to, by odłożyć ją do segregatora. Karta określa, czego firma chce dokonać, kto podejmuje decyzje i jaką skalę inwestycji jest gotowa rozpatrywać. Kiedy interesy działów zaczynają się rozchodzić, można wrócić do tych ustaleń.

2. Kryteria wyboru systemu ERP: wymagania biznesowe trafiają do macierzy

Następny etap to przygotowanie postępowania ofertowego.

Kierownik projektu przeprowadza rozmowy z kluczowymi grupami uczestników: finansami, sprzedażą, zakupami, magazynem, logistyką, produkcją, IT i innymi działami, które będą pracować w systemie.

Rezultatem jest macierz wyboru ERP. Firma opisuje w niej, co system musi potrafić, żeby w ogóle można było brać go pod uwagę.

W biznesie o złożonej strukturze kryteria mogą obejmować:

• obsługę wielu podmiotów prawnych;
• możliwość przygotowania skonsolidowanych raportów dla grupy;
• standardowe procesy budżetowania;
• zatwierdzanie wniosków o płatność;
• aplikację mobilną dla przedstawicieli handlowych;
• API do integracji z innymi systemami;
• zarządzanie sprzedażą i fakturowanie klientów;
• zakupy;
• ewidencję magazynową;
• kontrolę zapasów i analizę ich rotacji;
• księgowość i ewidencję finansową.

Wyjaśnię kilka rzeczy osobom, które wcześniej nie uczestniczyły w takim wyborze.

Konsolidacja finansowa pozwala zarządowi patrzeć na grupę spółek jak na jeden biznes, przy zachowaniu możliwości analizowania poszczególnych podmiotów.

API to interfejs programistyczny, przez który systemy mogą wymieniać dane. Samo istnienie API nie oznacza jeszcze, że potrzebna integracja jest gotowa. Dla firmy może to jednak być warunek podstawowy: ERP musi mieć możliwość współpracy z pozostałymi rozwiązaniami. Zakres takiej wymiany opisujemy na stronie integracji systemów informatycznych.

Rotacja zapasów pomaga zrozumieć, jak szybko sprzedaje się towar i ile środków pozostaje związanych w stanach magazynowych.

Lista wymagań bywa długa. Nie widzę w tym problemu. Im dokładniej firma sformułuje kryteria na tym etapie, tym bardziej zrozumiałe będzie późniejsze porównanie. Najważniejsze, żeby za każdym kryterium stała rzeczywista potrzeba biznesowa.

Na przykład zdanie „system obsługuje wiele firm” pozostawia mnóstwo pytań. Czy można prowadzić oddzielną ewidencję każdego podmiotu? Widzieć grupę jako całość? Rejestrować operacje między powiązanymi spółkami? Pracować w różnych walutach?

Z akceptacjami jest podobnie. Przycisk „Zatwierdź” sam w sobie niewiele mówi. Trzeba wiedzieć, kto zatwierdza dokument, w której spółce, pod jakimi warunkami i co się dzieje, gdy główna osoba zatwierdzająca jest nieobecna.

Jak może wyglądać fragment macierzy

Poniżej przedstawiam przykład umowny. To nie dokument z konkretnego przetargu klienta, lecz ilustracja sposobu zapisywania wymagań i wyników ich weryfikacji.

Taka tabela pomaga oddzielić odpowiedź dostawcy od potwierdzonej możliwości systemu.

Za słowami „tak, obsługujemy to” mogą kryć się zupełnie różne sytuacje: funkcja działa standardowo, trzeba ją skonfigurować, potrzebny jest dodatkowy moduł albo dostawca uważa, że zdoła ją dopiero opracować.

Dla projektu oznacza to różne koszty, czas i ryzyko. Chcę, żeby macierz uwidaczniała te różnice.

Mamy więc kartę projektu i kryteria wyboru. Można przejść do szukania potencjalnych wykonawców.

3. W mojej praktyce poszukiwania zaczynały się od producentów ERP

W dużych projektach, o których opowiadam, zamawiający zwykle zaczynał od samych producentów — firm rozwijających i dostarczających produkty ERP.

Firma mogła zwrócić się na przykład do dziesięciu producentów wyraźnie obecnych na jej rynku. Każdy otrzymywał konkretne zapytanie:

„Rozważamy wdrożenie ERP. Oto nasze kryteria wyboru, warunki postępowania i przewidywany harmonogram. Prosimy polecić partnerów zdolnych zrealizować taki projekt”.

To ważna informacja dla konsultantów. W mojej praktyce taki wybór zaczynał się od bezpośredniego kontaktu z producentami. Zamawiający nie ograniczał się do wyszukania firm w internecie i porównania stron integratorów.

To podejście ma praktyczne przyczyny.

Producent jest zainteresowany dużym projektem. Może skierować zapytanie do odpowiednich partnerów i polecić firmy, które według jego oceny poradzą sobie z zadaniem.

Udział producenta pomaga też w rozmowach handlowych. Jeżeli oferta partnera przestaje być konkurencyjna ze względu na cenę, producent może wpłynąć na negocjacje albo zaproponować inny sposób realizacji.

W tym układzie producent jest zainteresowaną stroną: zna swoją sieć partnerską i chce, żeby wybrano jego produkt.

Oczywiście sama rekomendacja nie potwierdza jeszcze, że wykonawca będzie odpowiedni. Nadal trzeba ocenić zespół, sprawdzić doświadczenie i szczegółowo przeanalizować ofertę. Duży zamawiający zyskuje jednak bezpośredni kontakt do ludzi, którzy mogą pomóc wyłonić kandydatów.

Praktyczny wniosek: warto wykorzystać zaangażowanie producenta, żeby dotrzeć do odpowiednich wykonawców, a następnie przeprowadzić własną ocenę. Ja nadal chciałbym poznać proponowany zespół i zrozumieć, jak zamierza zrealizować właśnie nasz projekt.

4. Zebranie ofert to osobne, duże zadanie

Wyznacza się termin składania ofert. W miarę ich napływania zespół projektowy zaczyna analizę, a następnie organizuje prezentacje i spotkania z kandydatami.

To etap pracochłonny i, szczerze mówiąc, dość monotonny. Ofert może być kilkadziesiąt, a każda wymaga uwagi.

Nie wszyscy dojdą do rozmowy na żywo. Ktoś nie ma wystarczającej obecności w danym regionie, komuś brakuje odpowiedniego doświadczenia, ktoś nie spełnia zasadniczego kryterium z macierzy.

Pozostali kandydaci przechodzą do rozmów o rozwiązaniu i sposobie jego wdrożenia.

W tym miejscu macierz zaczyna działać jako narzędzie selekcji. Pomaga ustalić, komu warto poświęcić czas, na które pytania już odpowiedziano i gdzie istotne wymagania nadal pozostają bez odpowiedzi.

Bez wspólnej podstawy porównania łatwo odbyć wiele spotkań, podczas których każdy dostawca pokazuje wygodną dla siebie część produktu. Prezentacji przybywa, a jasności przy wyborze niekoniecznie.

Na tym etapie jednocześnie oceniamy dwa elementy przyszłego projektu: samą ERP i ludzi, którzy proponują jej wdrożenie.

5. Funkcje trzeba pokazać na konkretnych zadaniach

Pierwsze pytanie jest proste: czy system odpowiada zestawowi kryteriów sformułowanemu przez firmę?

Proszę pokazać, jak działa sprzedaż. Jak wyglądają zakupy? Jak prowadzony jest magazyn? Jak działają pozostałe moduły, bez których nasz biznes nie jest gotowy rozważać rozwiązania?

Szczególnie uważnie podchodzę do demonstracji raportowania. To dla mnie jeden z najbardziej wymownych i wrażliwych obszarów oceny.

Sposób prezentowania informacji w dużej mierze decyduje o tym, na ile program pomoże biznesowi podejmować decyzje. Prawidłowe zarejestrowanie operacji jest konieczne, ale zarząd musi jeszcze zrozumieć jej konsekwencje: co się wydarzyło, dlaczego i co robić dalej.

Jeżeli system ma standardowe raporty, proszę je pokazać. Następnie proszę pokazać szczegóły.

Czy można przejść od sumy do dokumentów, które się na nią składają? Zobaczyć przychody i koszty według działów? Porównać wyniki spółek grupy? Zmienić okres i przekrój analityczny?

Jeżeli biznes potrzebuje analizy kohortowej, proszę ją zademonstrować. Firma może na przykład chcieć porównać, jak zmieniają się kolejne zakupy klientów, którzy po raz pierwszy kupili w różnych miesiącach. Potrzebna jest do tego określona logika grupowania i obliczeń, której zwykły raport sprzedaży niekoniecznie dostarcza.

Zależy mi na tym, żeby podczas demonstracji można było otworzyć konkretną liczbę, spojrzeć na dane inaczej i zrozumieć, skąd wziął się wynik.

Im więcej przydatnych możliwości analizy ERP rzeczywiście pokazuje, tym ciekawsza staje się dla biznesu. Gdy potrzebne są dodatkowe przekroje obejmujące kilka źródeł, warto też ocenić zakres analityki i raportowania Tableau BI.

Osobno omawia się rozwój systemu. Czy można instalować dodatkowe moduły? Jak wpływają na koszt rozwiązania? Od czego zależy czas opracowania specyficznej funkcji potrzebnej firmie?

Na przykład trzeba połączyć wewnętrzny system księgowy — choćby 1C, jeśli organizacja z niego korzysta. Co będzie potrzebne? Jakie dane mają być przesyłane? Która część integracji już istnieje, a którą trzeba dopiero opracować?

Im konkretniejsze odpowiedzi, tym dokładniej możemy określić, czy proponowane rozwiązanie do nas pasuje.

Na pewno zapisywałbym, co już zademonstrowano, a co nadal jest obietnicą. Jedno i drugie może występować w ofercie, ale komitet projektowy powinien widzieć różnicę.

6. Wybieramy ERP razem z zespołem wdrożeniowym

Zespół jest jednym z kluczowych czynników decyzji.

W wielu dojrzałych produktach ERP podstawowe obszary funkcjonalne rzeczywiście są podobne. Większość systemów można rozbudowywać i dostosowywać, choć koszt oraz trudność zmian bywają różne.

W praktyce realizacja projektu bardzo mocno zależy jednak od ludzi.

Dlatego chcę wiedzieć: jaki macie zespół? Kto konkretnie będzie z nami pracował? Jaką wiedzę i doświadczenie mają ci specjaliści?

Czy możemy porozmawiać z nimi bezpośrednio? Oczywiście w obecności przedstawicieli waszej firmy, ale chcemy usłyszeć osoby, które będą prowadziły wdrożenie.

Musimy zrozumieć, czy znają dystrybucję towarów, ewidencję magazynową, logistykę, finanse i pozostałe obszary ważne dla naszego biznesu.

Dobra prezentacja handlowa jest przydatna. Projekt będą jednak wykonywać konkretni specjaliści: analizować procesy, podejmować decyzje architektoniczne, konfigurować system i rozwiązywać problemy.

Rozmawiamy na przykład o wycenie zapasów albo operacjach między spółkami grupy. Czy konsultanci rozumieją logikę biznesową? Jakie pytania zadają? Potrafią wyjaśnić konsekwencje proponowanego podejścia?

Takie rozmowy wiele pokazują jeszcze przed rozpoczęciem prac.

Wybieramy połączenie: odpowiedni program z wystarczającym potencjałem i zespół, który potrafi wykorzystać ten potencjał w naszym biznesie.

Rekomendacje i historia firmy są ważne. Radzę jednak osobno ocenić ludzi proponowanych do waszego projektu. To oni mają zamienić obietnice z oferty w działające procesy.

7. Cenę rozpatruje się razem z jakością i ryzykiem

W dużych projektach, w których uczestniczyłem, cena rzadko była jedynym czynnikiem rozstrzygającym.

Biznes rozumiał, że koszt należy oceniać razem z jakością rozwiązania, profesjonalizmem zespołu i ryzykiem wdrożenia.

Droższa oferta nie staje się automatycznie lepsza. Niższa kwota w ofercie sama w sobie również nie czyni inwestycji korzystniejszą.

Oszczędność na etapie wyboru może być niewystarczającym argumentem, jeśli w zamian firma przyjmuje poważne ryzyko utraty rezultatu całego projektu.

Duży biznes potrafi ocenić tę różnicę. Patrzy na konsekwencje nieudanego wdrożenia i na to, co otrzymuje za swoje pieniądze.

Dlatego porównywałbym cenę razem ze zobowiązaniami dostawcy. Jakie wymagania uwzględniono? Co jest założeniem? Jakie prace będą wyceniane później? Jaki zakres dodatkowych zadań już teraz widać?

Łatwiej zestawić oferty, kiedy koszt i zawartość projektu rozpatruje się łącznie.

W przeciwnym razie za tańszy może uchodzić wariant, w którego kalkulacji po prostu nie ma jeszcze części koniecznej pracy.

8. Kierownik projektu uzasadnia krótką listę rozwiązań

Stopniowo powstaje krótka lista — zwykle do pięciu potencjalnych wariantów.

Każdy obejmuje już ocenioną ERP, sprawdzony zespół i określone podejście do realizacji. Porównanie uwzględnia cenę, harmonogram, możliwość rozpoczęcia prac, rekomendacje i doświadczenie dostawcy.

Z taką macierzą kierownik projektu wraca do wewnętrznego gremium podejmującego decyzję inwestycyjną i przedstawia wyniki selekcji.

Na tym etapie uczestnicy zazwyczaj rozumieją, że ostateczny budżet może przekroczyć wstępne szacunki. Harmonogramy proponowane przez kandydatów również wymagają potwierdzenia po dokładniejszej analizie.

Skala poszczególnych wariantów staje się jednak czytelna.

Jedne rozwiązania pozwalają stosunkowo szybko uruchomić podstawowe procesy i następnie rozwijać system. Inne wymagają rozbudowanych prac programistycznych, zanim biznes będzie mógł w pełni rozpocząć pracę.

Firma wybiera więc również sposób realizacji:

W złożonych organizacjach, o których mówię, ostatni wariant występuje rzadziej. Zazwyczaj pewne ustawienia, integracje lub modyfikacje są jednak konieczne.

Zależy mi na tym, żeby porównanie wyjaśniało konsekwencje wyboru. Z czego firma będzie mogła skorzystać najpierw? Co pozostanie poza zakresem pierwszego uruchomienia? Ile pracy trzeba wykonać, zanim pracownicy przejdą do nowego systemu?

Wtedy zarząd podejmuje decyzję ze świadomością, jaki projekt będzie musiał wspierać.

9. Po wstępnej selekcji zaczynają się wewnętrzne negocjacje

Krótka lista nie oznacza jeszcze zakończenia wyboru.

Firma ma już kandydatów, rozumie skalę projektów i zna orientacyjne potrzeby budżetowe. Właśnie wtedy często rozpoczyna się kolejna runda wewnętrznych negocjacji.

Wybór ERP potrafi wywoływać konflikty. Działy mają różne interesy, a nowy system może zmienić dotychczasowy sposób pracy.

Finanse mogą być zadowolone z modelu ewidencji, podczas gdy dział operacyjny nadal ma pytania o codzienne czynności pracowników. Jeden dział jest gotów zmienić proces, drugi zakłada zachowanie dotychczasowego porządku.

Te rozbieżności trzeba rozwiązać. Są częścią wyboru, bo to firma będzie żyła z rezultatem wdrożenia.

Pojawiają się więc dodatkowe konsultacje z potencjalnymi dostawcami. Najczęściej przyjmują formę bardziej szczegółowych demonstracji.

Prośba brzmi teraz konkretniej:

„Pokażcie, jak widzicie nasz proces w waszym systemie. Jak dokładnie będzie działał?”.

Potrzebny jest już scenariusz przekrojowy — sekwencja działań obejmująca kilka działów i obszarów funkcjonalnych.

10. Demonstracja end-to-end pokazuje ERP w strukturze biznesu

Załóżmy, że jedna spółka grupy kupuje towar od innej powiązanej spółki. Towar trzeba dostarczyć, odprawić celnie, rozliczyć koszty dodatkowe i przekazać do sprzedaży.

Jeżeli proces obejmuje produkcję, trzeba również pokazać operacje produkcyjne i kalkulację kosztu wytworzenia gotowego produktu.

Chcemy zobaczyć cały łańcuch, a następnie zrozumieć, jak znajduje odzwierciedlenie w ewidencji i raportowaniu. Na tym polega demonstracja end-to-end.

Podczas takiej demonstracji nieuchronnie pojawiają się pytania. Czego brakuje? Co wymaga konfiguracji? Gdzie potrzebne jest programowanie? Na których etapach obowiązują akceptacje?

Następnie ten sam proces trzeba obejrzeć z drugiej strony.

Załóżmy, że pracuję w podmiocie A powiązanym z podmiotem B. Co widzę ja? Co widzą pracownicy drugiej spółki? Jak operacje zapisują się u każdej strony? Jak później powstaje obraz całej grupy?

To pozwala zrozumieć, jak ERP zachowa się w rzeczywistej strukturze organizacyjnej. Sama deklaracja obsługi transakcji między spółkami nie zastępuje takiego sprawdzenia. Praktykę rozliczania transportu i importu opisuję osobno w artykule o kosztach dodatkowych Landed Costs w Odoo.

Właśnie po takich demonstracjach warto wrócić do macierzy wyboru. Część odpowiedzi się potwierdza, inne wymagają doprecyzowania. Czasem ujawnia się ograniczenie albo dodatkowy zakres prac, którego wcześniej nie było w ofercie.

Porównanie musi odzwierciedlać aktualną wiedzę o kandydatach. W przeciwnym razie firma ryzykuje decyzję na podstawie tabeli, która nie odpowiada już wynikom rozmów.

11. Dlaczego decyzja potrafi dojrzewać tak długo

Szczegółowe demonstracje wymagają czasu.

Dostawca musi przygotować scenariusz. Zamawiający — zebrać pracowników, którzy rozumieją dane procesy i potrafią ocenić rezultat. Wszyscy mają bieżące zadania, kalendarze i ograniczoną dostępność.

Uzgadnianie spotkań, przygotowanie danych, przeprowadzenie demonstracji i późniejsze omówienie wyraźnie wydłużają cały proces.

Samo postępowanie ofertowe, analiza propozycji i konsultacje bywają rozciągnięte w czasie. Następnie dochodzi do nich cykl budżetowania.

Nawet jeśli preferowany wariant wyłoniono w bieżącym okresie, finansowanie projektu może zostać przewidziane dopiero w następnym cyklu budżetowym.

Między rozpoczęciem wyboru a decyzją, za którą faktycznie stoją przyznane środki, może więc minąć znacznie więcej czasu, niż wynikałoby z samej liczby spotkań.

Szczególnie zwracam na to uwagę konsultantom IT. Żeby uczestniczyć w dużych projektach, warto rozumieć, jak zamawiający podejmuje decyzje inwestycyjne.

Wasze spotkania z zespołem projektowym są częścią szerszego procesu. Wewnątrz firmy omawia się budżet, uzgadnia interesy działów i przechodzi wymagane procedury zarządcze.

Dlatego przy rozmowie o harmonogramie pytałbym o pożądany moment uruchomienia ERP oraz o najbliższą wewnętrzną decyzję: co ma się wydarzyć dalej, kto o tym decyduje i kiedy firma zatwierdza finansowanie. To pomaga trafniej rozumieć, na jakim etapie naprawdę znajduje się projekt.

12. Jak w taki wybór wpisuje się Odoo

Wszystko, o czym opowiedziałem, określa również moje podejście do oceny Odoo.

Mamy już kartę projektu, macierz wymagań, potencjalne zespoły i scenariusze demonstracji. Według tych samych kryteriów możemy określić, czy Odoo zasługuje na miejsce na krótkiej liście.

Uważam, że zasługuje.

Odoo jest pełnoprawnym systemem ERP, z własną specyfiką, mocnymi stronami i ograniczeniami. Trzeba rozpatrywać je w odniesieniu do konkretnego biznesu, tak jak pozostałe systemy.

W zależności od zakresu projektu i sposobu realizacji może zaoferować bardziej dostępny koszt niż niektóre warianty SAP czy Oracle. To moja ocena możliwości rozwiązania; porównanie konkretnego projektu wymaga zestawienia tego samego zakresu i odpowiedzialności.

Przed wyborem trzeba jednak ustalić, gdzie Odoo dobrze odpowiada naszym procesom, a które wymagania będą wymagały dodatkowej pracy.

Do tego właśnie przydaje się przygotowana macierz. Szerszy kontekst rozwiązania i jego zastosowań przedstawiamy na stronie systemów ERP dla firm.

13. Gdzie widzę mocne strony Odoo

Dla firm z tradycyjnymi procesami operacyjnymi — kupujemy, sprzedajemy, magazynujemy, wysyłamy i prowadzimy ewidencję — Odoo dostarcza już znaczną część potrzebnych funkcji.

Jeżeli standardowa logika odpowiada pracy firmy, zakres modyfikacji może być stosunkowo niewielki.

Dużą wartość widzę w powiązanej ewidencji, automatycznym tworzeniu zapisów księgowych, operacjach wielowalutowych, wielojęzyczności i obsłudze wielu firm w jednym systemie.

Dla grupy podmiotów istotne są też raportowanie finansowe i konsolidacja. Te możliwości dokładnie sprawdzałbym w odniesieniu do struktury zamawiającego.

Proszę pokazać nasze spółki, operacje między nimi, używane waluty i raporty oczekiwane przez zarząd. Proszę wyjaśnić, jak zostanie to zorganizowane w proponowanej konfiguracji.

W ten sposób ogólna rozmowa o obsłudze grupy spółek staje się oceną konkretnego rozwiązania.

Jeżeli kluczowe wymagania operacyjne i ewidencyjne zostaną odpowiednio pokryte, projekt zyskuje dobrą podstawę. Można wtedy rzeczowo omówić obszary, w których standardowy system nie wystarcza.

14. Co w Odoo trzeba ocenić szczególnie uważnie

Najwięcej pytań mam o złożone sterowanie kolejnością procesów biznesowych, ścieżki akceptacji oraz wspólną pracę nad dokumentami.

W Odoo istnieją mechanizmy zatwierdzania, konfigurowalne reguły, zarządzanie dokumentami i podpis elektroniczny. Obecność poszczególnych funkcji nie oznacza jednak, że w pełni obsługują korporacyjny proces.

Weźmy umowę.

Prawnik wprowadza zmiany. Pozostali uczestnicy muszą je zobaczyć i sprawdzić. Następnie dokument przechodzi kilka etapów akceptacji — na przykład przez finanse, dział operacyjny i zarząd. Potem trzeba go podpisać, zapisać i dalej kontrolować jego status.

W dużej firmie cały ten przebieg może być szczegółowo uregulowany.

W takiej sytuacji chciałbym zobaczyć właśnie nasz scenariusz, zanim uznam wymaganie za spełnione. Jak uczestnicy pracują z kolejnymi wersjami? Jak przechodzi się między etapami? Kto widzi dokument? Co się dzieje przy zwrocie do poprawy?

Podobnie jest z obiegiem dokumentów między działami i podmiotami prawnymi. Jednej firmie wystarczy prosta akceptacja, inna potrzebuje znacznie bardziej złożonej logiki.

Moim zdaniem Odoo może tu wymagać dodatkowych modułów, prac programistycznych albo integracji z innym rozwiązaniem.

To powinno znaleźć się w ocenie: co działa w proponowanej standardowej konfiguracji, co zapewnia osobna aplikacja, co powstaje na zamówienie i kto później utrzymuje rezultat. Taki zakres rozpatrujemy w ramach dostosowywania Odoo do procesów firmy.

Wtedy firma rozumie rzeczywistą zawartość projektu i może świadomie zdecydować, czy taki wariant jej odpowiada.

15. Praktyczne podejście: uruchomić podstawowe procesy i rozwijać system

Dla firm, które szukają bardziej dostępnej alternatywy dla kosztownych rozwiązań ERP, Odoo jest moim zdaniem propozycją wartą poważnego rozważenia.

Jedno z możliwych podejść polega na uruchomieniu najpierw podstawowych procesów operacyjnych, a następnie stopniowym dodawaniu wyspecjalizowanych funkcji.

Złożone akceptacje, wspólną pracę nad dokumentami i inne cechy organizacji można wydzielić jako jasno opisane zadania rozwojowe.

Kolejność musi przy tym odpowiadać potrzebom biznesu. Jeżeli określona akceptacja jest niezbędna do rozpoczęcia pracy, należy uwzględnić ją w początkowym zakresie projektu. Odłożyć można funkcje, bez których firma rzeczywiście jest w stanie zacząć korzystać z systemu.

Jako partner wdrożeniowy możemy pomóc w takim przygotowaniu.

ERPixel ma duże doświadczenie w ewidencji magazynowej i finansowej, operacjach między spółkami grupy, zarządzaniu płynnością oraz budżetowaniu.

Dla czytelnika mniej zaznajomionego z finansami wyjaśnię: zarządzanie płynnością, czyli treasury, dotyczy zarządzania środkami pieniężnymi — wiedzy o dostępnych pieniądzach, planowania płatności i wpływów oraz kontroli zdolności do regulowania zobowiązań. W grupie spółek dochodzą do tego różne podmioty, rachunki bankowe i waluty.

W tych obszarach rozumienie biznesu jest równie ważne jak znajomość programu.

Możemy omówić sposób działania firmy, ustalić, gdzie Odoo daje odpowiednią podstawę, i opisać dodatkowe funkcje, które będą potrzebne wokół niej. Takie przygotowanie jest częścią naszego podejścia do wdrożenia Odoo.

Połączenie standardowych możliwości ERP i przemyślanych rozszerzeń pozwala stworzyć mocny system kontroli operacji i rozumienia tego, co dzieje się w biznesie.

Koszt takiego rozwiązania może być atrakcyjny. Konkretna ocena zależy od procesów, integracji i koniecznych modyfikacji, dlatego wolę najpierw poznać wymagania, a dopiero potem rozmawiać o zobowiązaniach finansowych.

Firmie, która chce pełnoprawnej ERP i uważnie podchodzi do kosztu projektu, zdecydowanie radzę rozważyć Odoo.

Porozmawiajmy o wyborze ERP dla Twojej firmy

Jeśli przygotowujesz się do wyboru ERP, zapraszam do rozmowy.

Możemy omówić strukturę Twojego biznesu, procesy, które system ma wspierać, kryteria selekcji i to, czy warto umieścić Odoo na krótkiej liście.

Chętnie pomogę Ci uporządkować warianty i dobrać odpowiednie połączenie ERP oraz zespołu wdrożeniowego.

Opisz swoją sytuację w formularzu poniżej albo przejdź do strony kontaktowej ERPixel.