Jira + ERP + MES:
Integracja Krok po Kroku

Wyobraź sobie, że maszyna na hali produkcyjnej właśnie zatrzymała zlecenie wartości 200 tys. zł. MES wie o tym od 3 minut. ERP nadal widzi zlecenie jako „w realizacji". Helpdesk IT jeszcze nie otrzymał żadnego ticketu. Kiedy technik wreszcie otwiera Jirę, traci kolejne 20 minut na zbieranie kontekstu z trzech różnych systemów. Według danych McKinsey, 63% krytycznych zdarzeń operacyjnych w firmach produkcyjnych ginie lub jest znacząco opóźnione przez silosy między IT, ERP i systemami produkcyjnymi. Ten artykuł opisuje, jak zbudować integrację która tego zapobiega: od architektury, przez REST API, po monitoring produkcyjny.

Dlaczego integracja trzech systemów jest trudna

Integracje Jira↔ERP brzmią jak projekt weekendowy dopóki nie zaczniesz. Rzeczywistość okazuje się znacznie bardziej złożona, i to z konkretnych powodów architektonicznych, nie przypadkowych trudności.

Trzy różne modele danych

Jira myśli w kategoriach issue, project, workflow, SLA. ERP (Comarch, SAP, Sage) widzi świat przez zamówienia, faktury, kontrahentów, środki trwałe. MES operuje na zleceniach roboczych, operacjach, maszynach, partiach, jakości. Te trzy ontologie nie mapują się 1:1, każda transformacja wymaga decyzji biznesowych, nie tylko technicznych.

Trzy różne częstotliwości zmian

ERP zmienia dane rzędem minut do godzin (nowe zamówienie, zmiana statusu faktury). Jira operuje na minutach do dni (otwarcie ticketu, zmiana statusu, komentarz). MES generuje zdarzenia co sekundy: alarmy maszyn, zmiany parametrów produkcyjnych, odczyty czujników. Integracja synchroniczna która sprawdza się dla ERP, może kompletnie zawalić się pod obciążeniem MES.

Trzy różne kontrakty API

Jira oferuje nowoczesne REST API z paginacją, WebHookami i dobrą dokumentacją. Comarch ERP XL używa natywnego API opartego na bibliotece DLL (CDN_API.DLL); integracja z Jirą wymaga middleware lub serwisu pośredniczącego. Starsze instalacje korzystają również z interfejsu SOAP lub COM+. Systemy MES często w ogóle nie mają REST API, komunikują się przez OPC-UA, MQTT, pliki CSV lub własne protokoły binarne. To wymaga osobnych adapterów dla każdej warstwy.

Architektura integracji: model referencyjny

Najtrwalszy wzorzec dla integracji Jira+ERP+MES to event-driven hub-and-spoke z centralną warstwą middleware. Unikaj integracji point-to-point: przy N systemach generuje N×(N-1)/2 połączeń, czyli dla 3 systemów 3 połączenia, dla 5 systemów już 10.

Podział odpowiedzialności (MDM)

Kluczowe jest ustalenie Master Data Management: który system jest właścicielem których danych:

• ERP: master dla danych kontrahentów, produktów, cenników, umów serwisowych, środków trwałych (numery seryjne, lokalizacje).
• MES: master dla zleceń produkcyjnych, operacji na maszynach, parametrów procesu, partiowości, danych jakości.
• Jira: master dla incydentów IT, requestów serwisowych, SLA, historii komunikacji z klientem, eskalacji.

Każdy system może czytać dane innych systemów (przez middleware). Zapis powinien odbywać się wyłącznie przez system będący master: middleware nigdy nie nadpisuje danych z pominięciem właściciela. Jeśli chcesz zrozumieć ogólne wzorce integracji systemów przez API (REST, webhooks i middleware), przeczytaj nasz kompleksowy przewodnik po integracji systemów.

Jira ↔ ERP krok po kroku (Comarch ERP XL + REST API)

Poniżej omawiamy konkretny, najczęstszy scenariusz: ticket serwisowy w Jira SM ma być automatycznie wzbogacony danymi kontrahenta i środka trwałego z Comarch ERP XL, bez ręcznego kopiowania.

// POST /api/token
{
  "grant_type": "client_credentials",
  "client_id":     "your_client_id",
  "client_secret": "your_client_secret",
  "scope":         "api"
}

// GET /api/Kontrahenci?nip={nip}
Authorization: Bearer {token}

// Odpowiedź ERP:
{
  "Id":         "KNT-001234",
  "Nazwa":      "Acme Manufacturing Sp. z o.o.",
  "OpisTrwaly": "Kontrakt serwisowy Premium do 2027-06-30",
  "OpiekunId":  "USR-042"
}

// PUT /rest/api/3/issue/{issueKey}
{
  "fields": {
    "customfield_10201": "KNT-001234",          // ID kontrahenta ERP
    "customfield_10202": "Acme Manufacturing",   // Nazwa firmy
    "customfield_10203": "Premium do 2027-06-30", // Status kontraktu
    "priority": { "name": "High" }               // z warunków SLA w ERP
  }
}

Jira ↔ MES: specyfika środowiska produkcyjnego

Integracja z MES rządzi się innymi prawami niż integracja z ERP. Trzy kluczowe różnice które musisz zaadresować już na etapie projektu:

1. Zdarzenia w czasie rzeczywistym, nie polling

MES generuje alerty maszynowe z częstotliwością rzędu sekund. Nie używaj pollingu HTTP do odczytu zdarzeń MES. Zamiast tego skonfiguruj push przez MQTT lub WebSocket. Middleware subskrybuje topik MES (mes/linia1/alarm/krytyczny) i na każde zdarzenie decyduje czy otworzyć nowy ticket Jira, zaktualizować istniejący, czy zignorować (duplikat).

2. Filtrowanie i deduplication na poziomie middleware

Maszyna może wygenerować 200 alarmów tego samego typu w ciągu minuty (flapping). Middleware musi implementować window deduplication: jeśli alarm tego samego typu z tej samej maszyny pojawił się w ostatnich 5 minutach, nie twórz nowego ticketu. Dodaj notatkę do istniejącego.

3. Kontekst produkcyjny w tickecie

Ticket Jira stworzony z alarmu MES powinien zawierać pełny kontekst: numer zlecenia roboczego, oznaczenie maszyny/linii, wartość parametru który przekroczył próg, ostatnie 10 operacji na tej maszynie. Bez tego technik IT nie może ocenić powagi incydentu bez dzwonienia na halę, co niweluje korzyści z integracji.

Narzędzia middleware: porównanie

Wybór platformy middleware ma największy wpływ na koszt utrzymania integracji w perspektywie 3-5 lat. Poniżej porównanie pięciu najpopularniejszych opcji dla firmy produkcyjnej klasy MŚP:

Dla większości firm produkcyjnych MŚP n8n self-hosted oferuje najlepszy stosunek elastyczności do kosztu. Obsługuje REST, MQTT (przez custom node), WebHooki, kolejkowanie, retry logic i ma wbudowany panel monitorowania przepływów. Wdrożenie na VPS od 200 zł/mies. zamknie 90% scenariuszy integracyjnych.

5 typowych pułapek i jak je przewidzieć

Utrzymanie i monitoring integracji

Integracja wdrożona bez monitoringu to integracja która popsuje się po cichu. Dowiesz się o tym od kierownika produkcji, nie z dashboardu. Trzy warstwy monitorowania które uważam za obowiązkowe:

Warstwa 1: Health-check połączeń

Cykliczny ping (HEAD lub GET /health) do każdego systemu co 60 sekund. Jeśli którykolwiek nie odpowie w ciągu 5 sekund przez 3 kolejne próby, wyślij alert na Teams/Jira/email. Koszt implementacji: 30 minut w n8n lub prosta funkcja Lambda.

Warstwa 2: Metryki przepływu

Monitoruj ile wiadomości przechodzi przez każdy flow na godzinę. Nagły spadek do zera zazwyczaj oznacza że coś się popsuło. Skonfiguruj alert gdy throughput spada poniżej 20% średniej z ostatnich 7 dni przez ponad 30 minut.

Warstwa 3: Dead Letter Queue

Każda wiadomość która nie mogła być przetworzona po N próbach trafia do DLQ. Alert powinien uruchomić się natychmiast gdy DLQ nie jest pusta i wymagać ręcznej analizy, nie automatycznego retry. DLQ to twój "canary in the coal mine" dla błędów transformacji danych.

FAQ: Najczęstsze pytania