Schemat blokowy

AMODIT vs TMS – gdzie kończy się workflow, a zaczyna operacyjna logistyka? 

W branży TSL bardzo łatwo wrzucić wszystko do jednego worka i nazwać „systemem do zarządzania transportem”. W praktyce jednak za tym pojęciem kryją się zupełnie różne klasy problemów - od chaotycznego obiegu dokumentów, przez obsługę zgłoszeń, aż po zaawansowaną optymalizację tras i decyzje operacyjne.

To właśnie w tym miejscu najczęściej pojawia się pytanie: czy wystarczy jeden system, czy potrzebujemy kilku współpracujących ze sobą narzędzi?

W szczególności dotyczy to dwóch światów, które często są ze sobą mylone - BPM (zarządzanie procesami biznesowymi) oraz TMS (systemy zarządzania transportem). Choć na pierwszy rzut oka mogą wydawać się podobne, w rzeczywistości rozwiązują zupełnie inne problemy i działają na różnych poziomach organizacji.

Porównanie AMODIT i TMS

W rozmowach z firmami logistycznymi bardzo często pojawia się pytanie: Czy system BPM/workflow może zastąpić system TMS? 

Krótka odpowiedź brzmi: nie – ale może rozwiązać problemy, których TMS nie rozwiązuje dobrze.  W praktyce pytanie nie brzmi więc który system jest lepszy, tylko: czy dany problem to zarządzanie procesem i dokumentami, czy operacyjna logistyka w czasie rzeczywistym. 

To są dwa zupełnie różne światy. 

Dokumenty od partnerów, którzy nie działają elektronicznie

To jeden z najczęstszych problemów w logistyce. 

Dokumenty przychodzą różnymi kanałami: 

  • zdjęcia z telefonu 
  • e-mail 
  • skany 
  • papierowa poczta 

Każdy z nich wymaga później: 

  • klasyfikacji 
  • powiązania z kontrahentem lub zleceniem 
  • weryfikacji poprawności 
  • akceptacji 
  • archiwizacji 

To klasyczny problem workflow dokumentowego. 

Systemy BPM, takie jak AMODIT, są projektowane właśnie do takich scenariuszy.
Pozwalają stworzyć proces, w którym dokument przechodzi kolejne etapy: 

  • przyjęcie 
  • digitalizacja (OCR) 
  • walidacja danych 
  • przypisanie do kontrahenta lub sprawy 
  • akceptacja 
  • przekazanie danych dalej 

W takiej architekturze AMODIT działa jako brama przyjęcia dokumentów i warstwa kontroli jakości danych, a dane trafiają dalej do systemu logistycznego. 

Wniosek: to naturalny obszar dla systemu BPM.

 

Zgłoszenia zapotrzebowania na transport lub odbiór

Tu pojawiają się tak naprawdę dwa różne problemy, które często są wrzucane do jednego worka. 

Przyjęcie zgłoszenia 

To proces biznesowy: 

  • partner składa zgłoszenie 
  • zgłoszenie trafia do kolejki 
  • następuje walidacja 
  • przypisywany jest priorytet 
  • sprawdzane są SLA 
  • zapada decyzja biznesowa 

To jest workflow. 

System BPM sprawdza się tu bardzo dobrze, bo umożliwia: 

  • portal partnera 
  • obsługę wyjątków 
  • eskalacje 
  • kontrolę terminów 
  • historię decyzji 

Planowanie transportu 

To już zupełnie inna klasa problemów. Pojawiają się takie elementy jak: 

  • routing 
  • optymalizacja tras 
  • GPS 
  • telematyka 
  • dynamiczne planowanie 
  • ograniczenia logistyczne 

To jest domena systemów TMS (Transport Management System). Takie systemy wykorzystują algorytmy optymalizacyjne i są projektowane do pracy w czasie rzeczywistym. 

Wniosek:
najlepszym podejściem jest model hybrydowy: 

  • BPM → przyjęcie i obsługa zgłoszeń 
  • TMS → operacyjne planowanie transportu

    Asystent spedytora – typowy obszar TMS

Jeśli wchodzimy w takie funkcje jak: 

  • decyzja: własna flota vs przewoźnik zewnętrzny 
  • kalkulacja stawek 
  • optymalizacja kosztów 
  • planowanie czasu pracy kierowców 
  • dobór trasy 
  • giełdy transportowe 
  • dopasowanie ładunku powrotnego 
  • analiza rentowności zlecenia 

to jesteśmy już w świecie pełnoprawnych systemów TMS. 

Budowanie takich funkcji w systemie BPM zwykle kończy się problemami: 

  • bardzo ciężką konfiguracją 
  • brakiem algorytmów optymalizacyjnych 
  • słabą wydajnością 
  • dużym długiem technologicznym 

Dlatego próba stworzenia TMS w BPM rzadko kończy się sukcesem. 

Ale to nie znaczy, że BPM nie ma tu miejsca 

W praktyce część procesów spedytorskich nadal świetnie pasuje do warstwy workflow. 

Na przykład: 

  • obieg zlecenia transportowego jako sprawy 
  • powiązanie zlecenia z umową 
  • kontrola marży 
  • obsługa dokumentów 
  • teczka kontrahenta 
  • compliance i audyt 
  • obsługa wyjątków 
  • reklamacje 
  • monitoring SLA 

To obszary, w których BPM działa jak warstwa orkiestracji procesów biznesowych. 

 

Jak wygląda to w nowoczesnej architekturze logistycznej 

Najbardziej realistyczny model wygląda dziś tak: 

TMS – silnik operacyjny  BPM – warstwa procesowa 
  • routing 
  • dispatch 
  • GPS 
  • optymalizacja floty 
  • kalkulacja transportu 
  • integracje z giełdami transportowymi 

 

  • przyjęcie dokumentów 
  • workflow zgłoszeń 
  • kontrola decyzji biznesowych 
  • zarządzanie wyjątkami 
  • compliance 
  • zarządzanie dokumentacją
  • monitoring SLA 

 

Można to ująć prosto: 

BPM jest mózgiem procesu.
TMS jest silnikiem operacyjnym. 

A czy istnieją TMS, które robią wszystko? 

Na rynku istnieją bardzo zaawansowane systemy TMS, np.: 

  • SAP Transportation Management 
  • Oracle Transportation Management 
  • Descartes 
  • MercuryGate 
  • Transporeon 
  • Alpega 

Potrafią one obsługiwać: 

  • planowanie transportu 
  • optymalizację tras 
  • dispatch 
  • tracking 
  • kalkulacje kosztów 
  • zarządzanie przewoźnikami 

Problem polega jednak na tym, że nawet te systemy nie są projektowane jako pełne platformy workflow. 

Zwykle mają: 

  • prosty obieg dokumentów 
  • ograniczoną obsługę wyjątków 
  • mało elastyczne BPM 

Dlatego w praktyce duże organizacje logistyczne często kończą z architekturą: 

TMS + platforma procesowa (BPM). 

Najczęstszy błąd przy projektowaniu systemów logistycznych 

Z doświadczeń wdrożeń wynika jeden powtarzający się scenariusz. 

Firmy próbują: 

  • zbudować TMS w BPM
    albo 
  • rozbudować TMS tak, żeby zastąpił workflow 

Efekt jest zwykle ten sam: system, który nie jest ani dobrym BPM, ani dobrym TMS. 

Znacznie lepiej sprawdza się architektura współpracujących systemów. 

Gdzie BPM daje największą wartość w logistyce 

System workflow może znacząco poprawić obszary, których w TMS często nie widać: 

  • digitalizacja dokumentów od partnerów 
  • obsługa zgłoszeń transportowych 
  • zarządzanie sprawą jako całością 
  • teczka kontrahenta 
  • kontrola marży i dokumentów 
  • compliance 
  • SLA 
  • obsługa reklamacji i wyjątków 

To właśnie tam często kryje się duża ilość pracy ręcznej, której TMS nie eliminuje. 

Podsumowanie 

Systemy TMS są świetne w tym, do czego zostały stworzone: zarządzaniu transportem i optymalizacji operacji logistycznych. 

Systemy BPM są z kolei bardzo dobre w: 

  • zarządzaniu procesami 
  • dokumentami 
  • decyzjami biznesowymi 
  • obsłudze wyjątków 

Dlatego w praktyce najlepsze efekty daje połączenie obu światów, a nie próba zastąpienia jednego drugim. 

Autorem wpisu jest:

Ewa Skrzypczak

Business Development Representative

Na co dzień współpracuje z dużymi organizacjami przy porządkowaniu obiegu dokumentów i projektowaniu spójnych procesów workflow. Analizuje procesy biznesowe, identyfikuje wąskie gardła i wspiera zespoły w doborze oraz wdrażaniu rozwiązań, które przyspieszają decyzje, ograniczają błędy i zwiększają przejrzystość pracy. Pracuje z platformą AMODIT wspieraną AI, projektując wraz z klientami obiegi m.in. umów, faktur, zamówień i dokumentacji operacyjnej. Doświadczenie w pracy na styku biznesu, operacji i technologii pozwala jej łączyć perspektywy różnych zespołów i skutecznie prowadzić inicjatywy wymagające koordynacji wielu interesariuszy. W pracy stawia na trafne pytania, dane i pełne zrozumienie kontekstu decyzyjnego po stronie klienta. Po godzinach zgłębia praktyczne zastosowania AI, planuje kolejne podróże do Hiszpanii i testuje śródziemnomorską kuchnię.

FAQ

1 Czym różni się system BPM od TMS w logistyce?

2 Czy system BPM może zastąpić TMS?

3 W jakich obszarach logistyki najlepiej sprawdza się BPM?