Integracja ERP z systemem do zarządzania projektami — anatomia czterech przepływów
W większości firm produkcyjnych zamówienia żyją w ERP, a postęp prac — w arkuszu albo narzędziu do zarządzania projektami. Między jednym a drugim siedzi człowiek, który przepisuje dane. Codziennie, w obie strony, z błędami.
Ten artykuł pokazuje, jak wygląda porządna integracja tych dwóch światów — na przykładzie czterech przepływów, które zaprojektowaliśmy dla producenta z branży spożywczej prowadzącego dziesiątki projektów opakowaniowych równolegle (tę historię opisaliśmy szerzej w realizacji). ERP klienta działa on-premise, na bazie Oracle. Przepływy są jednak na tyle uniwersalne, że odnajdziesz w nich własny proces — niezależnie od tego, czy Twój ERP to Impuls, enova 365, Comarch czy Subiekt.
Zasada nadrzędna: każdy system jest źródłem prawdy dla swoich danych
Zanim przejdziemy do przepływów, jedna reguła, która porządkuje całość:
- ERP jest źródłem prawdy o zamówieniach — indeksy, kontrakty, terminy, stany magazynowe.
- Narzędzie do zarządzania pracą jest źródłem prawdy o postępie — kto nad czym pracuje, na jakim etapie jest projekt, co blokuje.
Integracja nie polega na kopiowaniu wszystkiego wszędzie, tylko na tym, żeby każdy system dostawał od drugiego dokładnie to, czego potrzebuje — i dokładnie wtedy, kiedy potrzebuje. Stąd dwa przepływy płyną z ERP do tablic, a dwa z tablic do ERP.
Przepływ 1: import zamówień (ERP → tablice)
Nowe zamówienie pojawia się w ERP i samo tworzy element na tablicy — z indeksem, numerem kontraktu i danymi klienta. Nikt niczego nie zakłada ręcznie, więc żaden projekt nie ginie między systemem handlowym a operacyjnym.
W praktyce najwięcej daje jeden szczegół: import od razu podświetla braki w danych. Jeśli zamówienie przyszło bez kodu EAN, zespół widzi to w pierwszej minucie, a nie w dniu wysyłki do drukarni.
Przepływ 2: dane wyrobów (ERP → tablice)
Projekt opakowania potrzebuje danych technicznych wyrobu. Tu proces ma dwa warianty i integracja musi je rozróżniać:
- Wyrób istniejący — dane zaciągamy z aktualnej wersji wyrobu w ERP od razu przy starcie projektu.
- Wyrób nowy — danych jeszcze nie ma; integracja uzupełnia je na tablicy dopiero po akceptacji specyfikacji, bez ręcznego przeklejania.
To typowy moment, w którym „prosta integracja" okazuje się mniej prosta: ten sam przepływ musi obsłużyć dwie różne ścieżki procesu. Wtyczka z marketplace'u tego rozróżnienia nie zna — projektant integracji tak.
Przepływ 3: towar na magazynie (tablice → ERP)
Pierwszy przepływ w drugą stronę. Gdy projekt na tablicy dostaje status „Na magazynie", integracja automatycznie aktualizuje status zamówienia w ERP. Dział handlowy nie dzwoni do produkcji z pytaniem „czy to już jest" — odpowiedź czeka w systemie, w którym i tak pracuje.
Przepływ 4: pierwsza paleta (tablice → ERP)
Najciekawszy z całej czwórki, bo wynika wprost z realiów produkcji: moment zejścia pierwszej palety z linii to sygnał, że produkcja realnie ruszyła. Zmiana statusu na tablicy zapisuje ten fakt w ERP — a przy okazji integracja przestaje odpytywać bazę o indeksy zakończonych etapów, więc nie generuje zbędnego ruchu na systemie, na którym pracuje cała firma.
Zauważ, że żaden z tych przepływów nie jest „synchronizacją wszystkiego co 5 minut". Każdy odpowiada na konkretne zdarzenie w procesie: nowe zamówienie, akceptacja specyfikacji, towar na magazynie, start produkcji. Dobra integracja mówi językiem procesu, nie językiem tabel.
Jak to działa pod spodem
Architektura jest krótsza niż niejeden diagram u dużego integratora:
GotaPlan → webhook → konektu → agent on-premise → baza ERP (Oracle)
- Zdarzenia z GotaPlan trafiają webhookami na naszą platformę integracyjną konektu.
- Po stronie klienta działa lekki agent zainstalowany w jego sieci — łączy się z platformą wyłącznie ruchem wychodzącym, więc integrujemy ERP za firewallem bez tuneli VPN i bez otwierania portów.
- Każde wykonanie jest logowane, nieudane operacje są automatycznie ponawiane, a błędy sygnalizowane od razu — nie wtedy, gdy ktoś zauważy, że dane się rozjechały.
Dlaczego nie Zapier albo wtyczka z marketplace'u
Trzy powody, które wracają w każdej rozmowie z firmą produkcyjną:
- ERP stoi za firewallem. Narzędzia typu Zapier zakładają, że wszystko ma publiczne API w chmurze. On-premise'owy Oracle go nie ma.
- Proces ma warianty. Stary wyrób kontra nowy, korekta kontra akceptacja — gotowe konektory znają pola, ale nie znają Twojego procesu.
- Ktoś musi za to odpowiadać. Gdy o 7:00 nie zaimportowały się zamówienia, potrzebujesz kogoś, kto to naprawi — a nie ticketu do trzech dostawców, z których każdy wskazuje pozostałych.
To ostatnie to zresztą główny powód, dla którego łączymy w jednej ofercie produkt i integrację: narzędzie, przepływy i utrzymanie pochodzą od jednego zespołu. Więcej o tym, jak realizujemy takie wdrożenia, znajdziesz na stronie integracji systemów, a jeśli porównujesz narzędzia do zarządzania pracą — zobacz GotaPlan vs Monday.com. Opisaliśmy też, jak GotaPlan układa pracę w produkcji spożywczej i w projektach opakowań.
Od czego zacząć u siebie
Nie od technologii. Zacznij od czterech pytań:
- Jakie zdarzenie w ERP powinno tworzyć pracę dla zespołu?
- Jakich danych z ERP zespół dziś szuka ręcznie (albo przepisuje)?
- O jakim postępie prac dział handlowy dowiaduje się dziś telefonicznie?
- Który moment procesu oznacza u Was „to naprawdę ruszyło"?
Odpowiedzi na te pytania to gotowa specyfikacja czterech pierwszych przepływów — u opisywanego producenta wyglądały one dokładnie tak, jak powyżej. Jeśli chcesz je omówić na przykładzie własnego procesu, napisz do nas — analiza i konkretna oferta są po naszej stronie.