Strona główna > O firmie, publikacje naszych specjalistów > Informatyczne aspekty relacji między spedytorem i klientem

Informatyczne aspekty relacji między spedytorem i klientem

Marek Wierzbicki

Artykuł opublikowany oryginalnie w materiałach z XVI Górskiej Szkoły PTI, Szczyrk 2004

Czytając wywiady czy analizy dotyczace informatyki w najważniejszych firmach spedycyjnych, działających na terenie Polski, można odnieść wrażenie, że rzeczywistość jest bardzo różowa, a klient obsługiwany jest w sposób nie budzacy żadnych zastrzeżeń. Z punktu widzenia osoby, która korzysta z usług kurierskich jednostkowo, czyli powierzając im niewielką liczbę przesyłek, działanie tych firm może wygladać bardzo poprawnie. Jeśli jednak popatrzeć na nie oczami dużego klienta, okulary mogą się okazać niezbyt różowe. Artykuł omawia oczekiwania jak i realizację współpracy między klientem instytucjonalnym, a realizującym zlecenie spedytorem, ze szczególnym naciskiem na współpracę na gruncie informatycznym. Poruszone tematy dotyczą zarówno informatyki stosowanej przez spedytorów widzianej oczami klienta, jak i problemu elektronicznej wymiany danych między nimi. Większość uwag dotyczy wdrożeń, w których uczestniczył autor tego artykułu.

Ekonomiczne uzasadnienie korzystania z kurierów

Od kilku lat zarówno w Polsce jak i na świecie króluje recesja gospodarcza. Poza różnymi złymi stronami dekoniunktura posiada jedną dodatnią cechę. Wymusza na firmach dążenie do obniżania kosztów z jednoczesnym podnoszeniem jakości usług. Jeszcze kilka lat temu takie połączenie ognia z wodą wydawało się niemożliwe. Dla wszystkich oczywista była teza, że obniżenie kosztów mogło się odbywać wyłącznie poprzez obniżenie jakości. Jednak trwający mimo recesji rozwój techniki sprawił, że czynności o takich samych efektach można wykonywać taniej, a czasami nawet szybciej niż kiedyś. Takie wyciskanie niepotrzebnych kosztów nie jest możliwe w sposób bezinwestycyjny. Każda z dziedzin ma na to swoje sposoby i środki. Oraz wymaga czasu.

Połączenie konieczności poniesienia nakładów inwestycyjnych i czasu na wdrożenie rozwiązań obniżających koszty szerzej otworzyło umysły kadry kierowniczej na wcale nie nowy, ale zyskujący obecnie dużą popularność pomysł. Polega on na powierzaniu części swojej działalności do wykonania innym, specjalizującym się tylko w tym zakresie firmom. Pozornie sprawa nie jest oczywista. Zewnętrzna organizacja, która wykonuje dokładnie to samo, co dotychczas jeden z działów firmy macierzystej, musi przecież zarobić na działalności, która dotychczas mogła nie przynosić zysków bądź nawet generować niewielka stratę. Jak to się dzieje, że inna firma potrafi zrobic niektóre rzeczy taniej i lepiej niż my to dotychczas robiliśmy?

Kluczem do odpowiedzi na tak postawione, dość drażliwe pytanie jest specjalizacja i efekt skali. Obie przyczyny przeplataja się ze sobą dając możliwość efektywnego obniżenia kosztów, często ze wzrostem jakości działania firmy w analizowanym zakresie. Wyobrażmy sobie przedsiębiorstw, które zajmuje się jakąś działalnością, zupełnie nie związaną z informatyką. Firma posiada pewien system informatyczny i musi utrzymywać go w stanie aktywnym 24 godziny na dobę (oczywiście z pewnym małym marginesem błędu). Załóżmy, że do utrzymania takiego systemu wystarcza jeden administartor na każdą zmianę oraz jeden pracujący i jeden zapasowy serwer, który może go zastąpić w razie awarii (w praktyce zabezpieczeń sprzętowych nie wykonuje się w ten sposób, o czym pisałem w zeszłym roku w ramach XV Górskiej Szkoły PTI). Biorąc pod uwagę, konieczność istnienia rezerw zatrudnienia wynikających z urlopów i ewentualnych zwolnień chorobowych, firma musiałaby zatrudniać 4 administratorów plus ewentualnie szefa tego zespołu i posiadać 2 serwery. Wyobrażmy teraz sobie, że zadanie to zleca się firmie outsourcingowej, która robi to samo znacznie taniej. Jak to możliwe? Bardzo prosto. Jeśli firma oustourcingowa ma 3 takie same kontrakty to zamiast zatrudniać 12 administratorów i 3 szefów radzi sobie z 10 administartorami i jednym szefem. Ponadto zamiast 3 serwerów zapasowych może przy bardzo niewielkim ryzyku posiadać 2 takie serwery (a często posiada jeden i umowę z trzecią firmą, zapewniającą bardzo szybki serwis sprzętu, co dalej obniża koszty). Dzięki temu firma outsourcingowa może to zrobic taniej, niż wynosiły dotychczas koszty utrzymania tego działu, niejednokrotnie lepiej, gdyż obsługując 3 różne firmy posiada większe doświadczenie w rozwiązywaniu nietypowych problemów.

Oczywiście informatyka to nie jedyne miejsce, gdzie można i stosuje się wydzielenie działań macierzystej firmy do podmiotów zewnętrznych. Od wielu lat (ta dziedzina była chyba prekursorem prawdziwego outsourcingu w Polsce) stosuje się takie rozwiązanie w zakresie ochrony mienia i utrzymania porządku. Kolejna dziedzina, która może również pretendować do miana prekursora (głównie ze względów historycznych) to ksiegowość (osobom młodym i niezorientowanym wyjaśniam, że księgowość, a przynajmniej jej część była już w latach 70-tych prowadzona dla dużych firm usługowo przez lokalne oddziały ZETO). Również w dziedzine poszukiwanie nowych pracowników (zwłaszcza wyższego szczebla) popularne jest korzystanie z usług firm, specjalizujących się w wyławianiu z tłumu właściwych osób.

Wielkości zysku generowane dzięki korzystaniu z outsourcingu zależą w dużej mierze od skali przedsięwzięcia. W dziale, którego utrzymanie kosztuje 100 tysięcy złotych trudno zaoszczędzić więcej, niż w dziale pożerającym 10 milionów. Koszty logistyki stanowią bardzo poważną pozycję w budżetach niektórych firm. Nic więc dziwnego, że również logistyka często bywa przedmiotem outsourcingu. Logistyka jest dość pojemnym pojęciem, które swoim podstawowym zakresem oznacza dostarczanie (lub zapewnienie dostępności) określonych towarów w okreslone miejsce w określonym czasie. Dzięki takiej definicji logistyką jest zarówno zapewnienie dostawy surowców czy półproduktów do produkcji, właściwe rozmieszczenie ich w magazynie (tak żeby były optymalnie dostępne), jak i dostarczenie wyrobów gotowych do klienta.

Artykuł ten skupia się na dość obszernym i często powierzanym w outsourcing fragmencie logistyki jakim jest dostarczenie wyrobu gotowego do klienta końcowego. Jak w każdym innym przypadku powierzenie tego zadania zewnętrznej firmie wynika z chęci realizacji dwóch celów: obniżenia kosztów i podniesienia jakości. Wyznacznikiem kosztów, w zależności od charakteru dostarczanego towaru, jest najczęściej cena dostarczenia jednej paczki (jeśli wszystkie przesyłki są podobnej wielkości i wagi), bądź koszt dostarczenia jednego kilograma (jednej tony, jednej skrzynki z wyrobami, jednej sztuki wyrobu gotowego) do przeciętnego klienta (jeśli klienci kupują towar różnego rodzaju, bądź w różnych ilościach). Trudniej określić jakość. Najczęściej stosowanym, choć wcale nie jednoznacznym miernikiem, jest procentowa ilość paczek dostarczona w ciągu następnego dnia po nadaniu. Innymi stosowanymi kryteriami może być liczba paczek dostarczonych w określonym z góry momencie (tak zwany dzień i godzina zastrzeżenia) bądź bierna możliwość dokładnego określenia momentu przybycia (np. odbiorca potrzebuje określonego czasu na opróżnienie rampy przed odbiorem towaru i musi być powiadomiony godzinę wcześniej, że towar właśnie do niego dociera).

Oczywiście dostarczenie towaru do klienta końcowego jest najtrudniejszym do zrealizowania i najlepiej (przy wykorzystaniu usług firm drugich) optymalizowalnym procesem w ramach działań logistycznych. Dostawy półproduktów obejmują zazwyczaj duże ilości towaru (przy małej liczbie dostaw) na stałych trasach bądź przy porównywalnych warunkach. Operacje takie dość prosto podelgają kalkulacji, a przez to redukcji kosztów we własnym zakresie. Podobnie jest z optymalnym zatowarowaniem magazynów. Istnieje wiele standardowych programów ustalających jego optymalny poziom, rozmieszczenie w magazynie, a następnie zużywania (opróżniania) go. W obu wymienionych przypadkach firma może bez większych problemów dokonać we własnym zakresie obniżenia kosztów bez utraty (a czasami z podniesieniem jakości pracy). Natomiast dostarczanie towaru do klienta nie da się realizować taniej bez wykorzystania efektu skali. Zwiększanie liczby własnych kurierów wiąże się ze wzrostem kosztów. Zmniejszenie liczby kurierów wiąże się z wydłużeniem dostaw. Firmy kurierskie, które specjalizują się w tej dziedzinie mogą natomiast dostarczać towar taniej i szybciej, gdyż dzięki obsłudze wielu firm i klientów indywidualnych mogą zaplanować optymalną (pod kontem ceny oraz jakości) strukturę kurierów dostarczających paczki w wymaganym czasie i cenie. Po rozważeniu wszystkich wad i zalet powierzenia dostawy kurierom firm spedycyjnych można śmiało powiedzieć, że (poza jednostkowymi specyficznymi przypadkami) nie istnieje dobra alternatywa dla takiego rozwiązania.

Model współpracy

Według raportu firmy Data Group, w Polsce, w 2003 roku działało 35 operatorów logistycznych. Nie wszyscy z nich specjalizują się w dostawach detalicznych (małe paczki i palety), gdzie odbiorcą końcowym jest klient indywidualny bądź mała firma, nie powiązana ze spedytorem specjalną umową. Można uznać, że kilkanaście z nich spełnia warunki umożliwiające powierzenie im dostaw do odbiorców końcowych. Osobiście (w ramach swoich obowiązków) współpracowałem z 4 z nich. Pozostałe znam z rozmów z szefami działów IT w innych firmach, konsultacji które prowadziłem, bądź z rozmów prowadzonych z przedstawicielami tych spedytorów. Artykuł, który Państwo czytacie nie ma na celu wartościowania usług poszczególnych kurierów, tylko pokazanie od kuchni ogólnych problemów związnych ze współpracą z kurierami, z punktu widzenia ogólnie pojętej informatyki.

Niemal wszyscy kurierzy umożliwiają swoim klientom trzy modele współpracy. Wybór modelu zależy od liczby przesyłek powierzanych spedytorowi. Najprostszy i dostępny niemal dla każdego (nawet w przesyłkach typu osoba fizyczna - osoba fizyczna), to współpraca ze standardowym punktem obsługi klienta. Wystarczy zadzwonić pod znaleziony w internecie numer telefonu (często jeden dla całego obszaru Polski, czasami nawet bezpłatny, bądź płatny w ograniczony sposób) i zamówić usługę dostarczenia paczki. Po odbór przyjedzie kurier, który zabierze naszą przesyłkę, wypisując ręcznie list przewozowy i nadając jej przy okazji numer referencyjny (niemal zawsze wydrukowany na liście w postaci kodu kreskowego). Ten numer to najważniejsza sprawa przy kontakcie ze spedytorami. To dzięki niemu możemy później namierzyć naszą przesyłkę. To dzięki niemu też, w przypadku ewentualnych problemów, możemy reklamować wykonanie (a raczej niewykonanie) usługi, którą zleciliśmy. Niemal zawsze podpis na liście przewozowym jest równoznaczny z zawarciem umowy ze spedytorem. Warunki tej umowy są standardem (oczwiście innym dla każdego spedytora), więc warto przed złożeniem podpisu zapoznać się z nimi (konia z rzędem temu, kto choć raz zapoznał się z takimi warunkami czy choćby ich skrótem, wydrukowanym na tylnej stronie listu przewozowego). W uwagach na liście przewozowym warto wpisać informacje, które są dla nas ważne (np. numer faktury czy zawartość). Z deklaracji firm spedycyjnych wynika, że uwagi te powinny być przenoszone do postaci elektronicznej listu (co mogłoby nam ułatwić przyszłe lepsze jego rozpoznanie), ale często te deklaracje nie są spełniane.

Nieco bardziej zaawansowanym modelem współpracy jest ręczne wystawianie listów z użyciem specjalizowanego oprogramowania dostarczanego przez firmę spedycyjną. Oprogramowanie takie (dostępne chyba u wszystkich spedytorów) umożliwia wystawienie listu analogicznego do wystawianego ręcznie, tyle że z użyciem komputera i drukarki. Czasami oprogramowanie takie umożliwia wydruk listu na drukarce igłowej na papierze (tak zwanej składance) z nadrukowanym formularzem listu bądź drukowanie go od zera na drukarce laserowej. Występują przy tym drobne różnice między poszczególnymi rozwiązaniami. Na składance znajduje się nadrukowany numer listu przewozowego i należy go przenieść do komputera (aby w przyszłości nie zgubić powiązania między treścią listu, a jego numeru). Często dokonuje się tego poprzez wpisanie pierwszego numeru ze składanki i zaznaczeniu opcji autonumeracji. Rozwiazanie z drukarką laserową wymaga zastosowania tak zwanej zarezerwowanej puli adresów, aby inne egzemplarze takiego samego programu, działające w innych firmach nie wygenerowały listów o tych samych numerach. Korzystanie z opisanego modelu przynosi pewne uproszczenie pracy, między innymi dzięki temu, że wypisywanie listów może zostać rozłożone w czasie (w okresie mniejszego ruchu) oraz rezygnacje z wprowadzania niektórych powielających się danych (adres nadawcy, konta na które mają spływać pieniądze za pobranie itd.). Firmy spedycyjne z reguły bezproblemowo dostarczają tego typu oprogramowanie. Kuriozum może tu być OPEK, który dostarcza program zabezpieczony w tak wymyślny sposób, że nawet informatycy tej firmy mają trudności z jego uruchomieniem. Sens takiego zabezpieczenia nie jest dla mnie zrozumiały, jako że jest to program dedykowany, który może drukować listy tylko dla jednego kuriera. Na przeciwnym biegunie znajduje się firma TNT ze swoim programem ExpressManager, który jest dostępny bezpośrednio ze strony internetowej spedytora. Umożliwia on tworzenie listów przewozowych bez instalacji żadnych dodatkowych dedykowanych rozwiązań. Dodatkowo dzięki możliwości personalizacji strony i uwierzytelniania tych stron własnym hasłem możliwe jest przechowywanie (na zdalnym komputerze spedytora) danych tylko o własnych przesyłkach i zawężanie dalszych działań tylko do swoich przesyłek (co zarówno przyspiesza pracę jak i podnosi poziom prywatności wykonywanych działań).

Najbardziej zaawansowanym rozwiązaniem są programy umożliwiające spięcie firmowego WMS z programem spedytora. Idea tego spięcia bazuje na spostrzeżeniu, że dane adresowe przesyłki, która będzie wysyłana, zostały już określone w trakcie wystawiania faktury i istnieją w systemie w wersji elektronicznej. Nie ma więc sensu w ręcznym przepisywaniu ich, skoro już raz zostały wprowadzone do systemu. Dodatkowo w systemie może być zakodowana informacja na temat sposobu płatności (przelew lub gotówka, co jest w przypadku przesyłki kurierskiej równoznaczne z pobraniem), wagi, zastrzeżonej godziny dostarczenia, uwag czy liczby pudełek, w które zapakowano przesyłkę. Wszystko to można wyeksportować do programu kurierskiego, co wyeliminuje konieczność powtórnego wprowadzania danych. Niektóre z firm stosują rozwiązania wiązane, czyli program do ręcznego wystawiania listów umożliwia też prowadzenie tak zwanej akcji, czyli importu danych o listach.

Podstawowym sposobem wymiany danych w programach standardowych są metody plikowe. Firmowy system informatyczny powienin umożliwić eksport danych w formcie rozpoznawalnym przez program kurierski. Najczęściej takim formatem są pliki o stałej szerokości kolumn, bądź o kolumnach separowanych standardowym znakiem. W pliku takim powinny się znaleźć dane adresowe odbiorcy, liczba pudełek wchodzących w skład jednej przesyłki, waga, informacja o ewentualnym pobraniu i jego kwota, flaga zwrotu dokumentów i inne specjalne zalecenia (np. dostawa w sobotę) oraz data i godzina zastrzeżenia. Większość programów udostępnia możliwość automatycznego przeniesienia uwag na list (i trzeba wtedy rozszerzyć plik o takie pole). Niektóre z nich umożliwiają dodatkowo wprowadzenie własnego numeru referencyjnego, który może służyć do dokładnego powiązania listu przewozowego na przykład z numerem faktury. Większość firm stosuje podejście umożliwiające wysyłanie listów zawierających więcej niż jedą paczkę. Wyjątkiem jest chyba tylko Szybka Paczka (obecnie GLS), która stosuje rozwiązanie jedna paczka to jeden list. Wymaga to trochę bardziej zaawansowanego eksportu, który dla jednej faktury wygeneruje tyle wierszy w pliku exportu, ile paczek zawiera ta faktura. Oczywiście wymaga to rozróżnienia wierszy, najczęściej przez podanie różnego numeru referencyjnego (np. poza numerem faktury kolejnego numeru pudełka). Program kurierski importuje plik z informacjami o przesyłkach i na tej podstawie generuje (oczywiście z pewnym udziałem człowieka) serię listów przewozowych (naklejek na paczki, raportów i innych dokumentów używanych przez danego spedytora).

Standardowe metody mają wielka zaletę, a mianowicie nie wymagają zbyt długiego okresu dostosowawczego i mogą być w miarę szybko wdrożone. Niestety fakt, że są standardowe i ogólne powoduje, że ich funkcjonalność nie jest dla wszystkich wystarczająca. Tak właśnie jest w Ogólnopolskim Systemie Dystrybucji Wydawnictw AZYMUT. Duża liczba przesyłek powstających w miarę spływania zamówień, które nie zawsze muszą być wysyłane w kolejności pakowania oraz konieczność dokładnego śledzenia stanu przesyłki (o czym napiszę dalej) wymusiła na nas konieczność ściślejszego sprzęgnięcia programu wspomagającego generowanie listów przewozowych z naszym systemem. Jak każda dbająca o bezpieczeństwo biznesowe firma OSDW Azymut ma podpisane umowy z więcej niż jedną firmą spedycyjną. W naszym przypadku są to Stolica i GLS (General Logistics Systems, dawniej Szybka Paczka). Realizacja sprzęgu między oprogramowaniem firmowym a aplikacjami kurierskimi poszła w przypadku obu spedytorów różnymi drogami.

Zanim opiszę sposób integracji między aplikacjami przedstawię w skrócie fragment naszego informatycznego systemu obsługi przedsiębiorstwa, ściśle związany z procesem pakowania paczek. Używany przez nas zintegrowany pakiet do obsługi firmy ERP (o nazwie FERRODO) pracuje na platformie SQL2000. Jedną z jej cech jest możliwość używania tak zwanych wyzwalaczy (trigerów). Działanie tego mechanizmu polega na tym, że w chwili pojawienia się w bazie kolejnego rekordu uruchamiana jest procedura, która może wykonać zdefiniowana wcześniej akcję. W naszym przypadku triger ustawiony jest na tabeli z nagłówkami faktur. Pojawienie się nowego nagłówka w tabeli powoduje przepisanie niektórych informacji z faktury do nowej tabeli. Ta tabela używana jest przez program drukujący etykiety, który został napisany wewnątrz firmy przez dział informatyki, to znaczy nie jest związany z pakietem ERP. Takie podejście wynika z kilku przesłanek. Jedną z najważniejszych jest możliwość niezależnego modyfikowania zarówno właściwości jak i zawartości naszej tabeli, w oderwaniu od pakietu zintegrowanego (który jest co prawda specjalizowany pod nasze wymagania, ale jego modyfikacja trwa z reguły dłużej, niż reakcja pracowników naszej firmy). Dzięki temu możemy natychmiast reagować na konieczne zmiany w funkcjonalności programu, a przez to całego procesu występującego po zapakowaniu paczki, który nie jest już obsługiwany przez posiadany przez nas pakiet. Kolejnym powodem zastosowania takiego podejścia jest konieczność posiadania mini hurtowni danych agregowanej w ciągu dnia co 2 godziny (w odróżnieniu od normalnej hurtowni agregowanej raz dziennie w nocy), zawierającej dane o realizacji zamówień. Testy jak i zdrowy rozsądek podpowiedziały nam, że próba dokonywania agregacji na pracującym systemie wymaga znacznie silniejszych maszyn, niż posiadane przez nas ośmio i czteroprocesorowy klaster.

Zewnętrzna w stosunku do pakietu zintegrowanego tabela i wykorzystujący ją program są początkiem drogi paczki, którą można później dokładnie śledzić poprzez narzędzia udostępniane w intranecie i w internecie. Podstawą śledzenia jest nasz numer referencyjny, nadany każdemu pudełku i wydrukowany na etykiecie przylepianej na pudełko tuż po zapakowaniu. Etykieta ta zawiera czytelne dla człowieka dane takie jak numer faktury, numer pudełka, liczbę pudełek dla tej faktury, adres odbiorcy, sposób dostawy i wagę. A oprócz tego zawiera wspomniany wcześniej numer referencyjny, zapisany w postaci kodu paskowego. Dzięki temu możemy realizować zarówno mechanizmy związane z bezpieczeństwaem (ochrona, zliczanie towaru przechodzącego przez bramę) jak i logistyczną. Każda z paczek po przejściu przez sortownię trafia na wydzielony fragment rampy, gdzie czeka na właściwy sposób obsłużenia. Obsługa paczki polega na zeskanowaniu kodu jej paskowego i przydzieleniu do właściwego spedytora bądź innego sposobu odbioru (odbiór własny, odbiór przez kuriera nie współpracującego z naszą firmą czy dostawa przez przedstawiciela handlowego, który w zaplanowanej trasie będzie następnego dnia odwiedzał odbiorcę tej paczki). Dzięki ścisłemu zintegrowaniu naszego narzędzia do śledzenia paczek i programu zarządzającego trasami przedstawicieli handlowych, można zmienić domyślny sposób dostawy paczki, dokonując oszczędności. Dodatkowo zastosowanie modułów do skanowania paczek wewnątrz w firmie umożliwia przyspieszenie przekazania odpowiedzialności za paczkę na kuriera. Wszystkie paczki, które zostaną przekazane w danym dniu (choćby tylko w sposób elektroniczny) do kuriera, są uznawane w naszym systemie za paczki nadane tego dnia, co oczywiście wymusza na spedytorach wyższy standard obsługi.

Po ogólnym wprowadzeniu w działanie naszego systemu wysyłki mogę przystąpić od nieco bardziej szczegółowych wyjaśnień współpracy naszego systemu z programami generującymi listy przewozowe. Jak wcześniej napisałem firma, w której pracuję (OSDW Azymut) współpracuje z dwoma spedytorami i techniczna realizacja tych rozwiązań jest całkowicie różna. Jako pierwszą podjeliśmy współpracę ze Stolicą. W pierwszej fazie współpracy specjalizowany program przygotowywany był przez firmę CSmatrix. Program pracował na platformie bezpłatnego serwera SQL Sybase Anywhere. Przekazywanie danych odbywało się poprzez tablicę tymczasową znajdująca się na bazie Sybase. Program, za pomoca którego pracownicy skanowali paczki przeznaczone do wysłania Stolicą generuje listę paczek składowanych na palecie i stanowiących podstawową jednostkę przekazania paczek do spedytora. Po zeskanowaniu całej palety program generuje papierowy raport przekazywanych paczek oraz elektroniczną ich listę, którą eksportuje z serwera SQL 2000, wykorzystując mechanizm tak zwanych linkowanych serwerów (serwer Sybase był dla SQLa 2000 właśnie takim serwerem). Po dokonaniu eksportu program kurierski, zmodyfikowany do naszych wymagań, umożliwiał tak zwaną kompletacje paczek, czyli ponowne skanowanie przekazywanej palety (ale już przez pracowników Stolicy, ich programem). Dzięki temu następowało sprawdzenie poprawności przekazania zarówno rzeczywistych paczek jak i danych elektronicznych (braki bądź nadmiary w trakcie skanowania świadczyły o błędnym elektronicznym eksporcie danych bądź fizycznym zdjęciu paczki z palety). Po wyjaśnieniu i elektronicznym wycofaniu z eksportu brakujących paczek (lub dołożeniu zaginionej paczki) raport był podpiswany i był traktowany jako dokument przekazania zbiorczej przesyłki. Dokument ten był wykorzystywany jeszcze raz przy pakowaniu paczek oklejonych już przez Stolicę jej nalepkami i listami w celu sprawdzenia, czy wszystkie paczki zostały poprawnie nadane.

Od sierpnia 2003 roku Stolica rozpoczęła migrację na inny program, tworzony teraz przez firme BCS. Z naszego punktu widzenia istniało kilka drobnych uchybień działania starej wersji programu, których nie dało się usunąć w jego dotychczasowej postaci. Największym problemem był czas eksportu danych, który stawał się nie do zaakceptowania. Na skutek korzystania z mechanizmu linkowanych serwerów i wykonywania w czasie eksportu zadań wyzwalanych na skutek dodawania kolejnych wierszy, czasy wstawiania pojedynczych przesyłek wydłużały się nadmiernie. Powodem była prawdopodobnie architektura programu, nie przystosowana do obsługi tak wielkiej liczby historycznych paczek, której niestety nie można było usunąć. Zmiana tej architektury i wspólne doświadczenia doprowadziły do zupełnej zmiany programu po stronie Stolicy. Funkcjonalnie program zmienił się nieznacznie (podobnie jak nasze formalne procedury przekazywania paczek). Różnica nastąpiła natomiast w architekturze wewnętrznej. Nowa wersja programu wykorzystuje silnik Visual Fox Pro, która przechowuje dane pliki tymczasowe w postaci plików DBF, natomiast dane stałe na naszym serwerze SQL 2000, w wydzielonej specjalnie do tego celu bazie. Dzięki takiemu rozwiązaniu eksport poszczególnych palet i związanych z nimi danych skrócił się z kilkunastu minut do kilku sekund. Ponadto umożliwiło to przyspieszenie działania agregacji wspomnianej wcześniej naszej mini hurtowni TRACE2, przetwarzającej dane o stanie zamówienia i przesyłki.

Zupełnie inny model współpracy obowiązuje w stosunku do GLS (dawniej Szybka Paczka). Jakkolwiek, kiedy zaczynaliśmy współpracę Szybka Paczka udostępniała program do generowania serii listów przewozowych, ale program, jako produkt z końca lat osiemdziesiątych nie nadawał się do łatwej integracji z naszym systemem (poza tym Szybka Paczka nie oferowała wtedy możliwości adaptacji tego programu). Zamiast możliwości modyfikacji Szybka Paczka oferowała dokładną dokumentację plików wymiany danych. Dzięki temu firmy, które chciały silniej zintegrować swoje systemy z systemem Szybkiej Paczki mogły tworzyć własne oprogramowanie zgodne ze standardem Szybkiej Paczki. Tak zrobiła Łódzka firma TME i za jej przykładem podjęliśmy takie wyzwanie u nas. Dzięki takiemu podejściu mogliśmy dokładnie zgrać nasz system z procesem generowania listów przewozowych i nalepek na paczki. Wykonane to zostało w ten sposób, że wraz z naszą wewnętrzną nalepką drukowana jest nalepka zgodna ze standardem Szybkiej Paczki (ozywiście tylko do faktur, które są predefiniowane do wysłania za pomoca tego spedytora). Po przeniesieniu na rampę spedycyjną paczki są skanowane w podobny sposób jak przy wysyłce Stolicą, jednak końcowy raport przekazania paczek jest od razu raportem dla kuriera-kierowcy, który kontroluje poprawność poprzez ręczne porównanie listy paczek z raportem. Sprawdzenie danych elektronicznych następuje w sortowni firmy GLS, dokąd eksportujemy dane zgodne z papierowym zbiorczym zestawieniem przekazanym kierowcy.

Elektroniczna wymiana informacji

Wszystko to co dotychczas napisałem było tylko preludium, do problemu rzeczywistej wymiany informacji między klientem, a spedytorem. Podstawą jakiejkolwiek pracy jest oczywiście opisane wcześniej sprzęgnięcie systemu firmy klienta z systemem spedytora. Najprostszą i najczęciej spotykaną postacią takiego sprzęgnięcia jest dwukierunkowy eksport danych pomiędzy pakietem zintegrowanym funkcjonującym w firmie i programem obsługującym proces drukowania listów. Dotychczas pisałem o jednokierunkowej wymianie danych, od systemu obsługującego nasza firmę do progamu firmy spedycyjnej. Do czego potrzebny jest eksport w druga stronę? Otóż pozwala nam on na odbiór informacji zwrotnej i powiązanie naszego dokumentu z numerem listu przewozowego, który jest (niestety) jedynym numerem referencyjnym respektowanym przez bazy firm kurierskich. Oznacza to, że jeżeli sami nie zadbamy o powiązanie między naszym numerem dokumentu, a numerem listu przewozowego, wtedy jakakolwiek dalsza próba wymiany informacji w sposób elektroniczny nie powiedzie się. W przypadku rozwiązań stosowanych w naszej firmie kwestia musiała zostać rozwiązana wyłącznie w stosunku do Stolicy. Udało się nam wymusic rozwiązanie, w którym program drukujący listy po nadaniu numeru listu dla naszego dokumentu dokonuje zapisu w bazie SQL tego numeru w wierszu odpowiadającym danej przesyłce (który to wiersz przechowuje oprócz adresu równiez nasz numer referencyjny, którego częścia jest numer faktury). Można więc powiedzieć, że jest to eksport sukcesywny, dokonujący się w miarę powstawania nowych listów (po każdym liście eksportowany jest jeden numer). Zupełnie inaczej sprawa rozwiązana jest w przypadku Szybkiej Paczki, gdzie program "kurierski" jest tak naprawdę fragmentem naszego systemu, napisanego przez nasz dział. Tu nie ma konieczności żadnego eksportu. Program ten pracuje po prostu na naszej bazie i w miarę nadawania numerów listów wypełnia odpowiednie pole w dedykowanej tabeli.

Jednak nie we wszytkich przypadkach jest to takie proste jak opisałem w poprednim akapicie. Większość standardowych programów kurierskich, zwłaszcza tych, które do importu wymagaja danych podawanych w postaci pliku tekstowego, również w takiej postaci eksportują dane. Przy czym problemem jest to, że w wiekszości przypadków eksport w postaci plików tekstowych nie przewiduje przenoszenia dodatkowego numeru (faktury) nadanego przez firmę zlecającą wysyłkę. Tak jest na przykład w przypadku programu "Pudełko" firmy OPEK. Jedyne pole zwrotne, które zawiera dane nie wpływające na stan listu (czyli w miarę dowolnie wypełnianym), a mogące zawierać numer referencyjny, jest pole opis (które drukuje się w polu opis na liście przewozowym). Nie możemy więc tego pola wykorzystać w sposób zupełnie dowolny, choć możemy (przy zachowaniu jednolitego standardu kodowania) umieścić tam numer faktury, który umożliwi (po zwrotnym eksporcie) zidentyfikować nam zależność numer listu - numer faktury. W programach innych firm może być jeszcze gorzej. Jedyną informacją jest adres dostawy i numer listu. Może to oznaczać konieczność łączenia numeru listu z numerem faktury za pośrednictwem adresu dostawy, który nie musi byc przecież unikalny. Jeśli więc firmie nie udało się w umowie zapewnić sobie modyfikacji programu i dostosowania go do własnych potrzeb powinna zadbać we własnym zakresie o dobry standard kodowania numeru faktury, tak aby mógł on posłużyć do powiązania z listem przewozowym.

Wróćmy jednak do kwestii wymiany danych między firmą zlecająca przesyłkę, a spedytorem. Zanim dokonam przeglądu metod i zakresu wymiany czytelnikom należy się kilka słów wyjaśnienia, na temat ogólnych zalet stosowania wymiany elektronicznej. Przekazywanie dokumentów jest koniecznością każdej organizacji. Większości operacji biznesowych wymaga spełnienia formalnych warunków takich jak przesłanie umowy, faktury, czy też zamówienia. Tradycyjne systemy przesyłania dokumentów wprowadzają dużą ilość potencjalnych możliwości powstania błędu. Ponadto metody te nie mają możliwości wymuszenia odpowiedzi, czy potwierdzenia otrzymania informacji. Wad tych nie posiada elektroniczna wymiana danych (EDI - Electronic Data Interchange). Nie zajmuje ona już kilku dni, a może odbywać się w czasie mniejszym niż godzina czy nawet minuta. Nie występują żadne opóźnienia w odniesieniu do rzeczywistego stanu rzeczy, czyli informacje pokazują stan aktualny. Dzięki elektronicznej formie wymiany danych można osiągnąć takie korzyści jak zmniejszenie prawdopodobieństwa powstania błędu, redukcja kosztów, przyspieszenie pracy czy szybszy czas reakcji, a wszystko dzięki eliminacji powtórnego wpisywania danych.

Między firmą zlecającą wysyłkę, a firmą spedycyjną wymienia się do sześciu (w zależności od modelu współpracy) różnych zestawów danych. Pakiet podstawowy to opisywany wcześniej eksport danych adrsowych, używanych do automatycznego wystawiania listów przewozowych. Bardzo często ta sama informacja, wzbogacona jedynie o numer listu przewozowego wysyłana jest (już przez program spedycyjny) dalej do centrali firmy, aby można było skontrolować poprawność nadań w pierwszej sortowni spedytora. Informacja powrotna (z systemu spedytora) to, jak już wcześniej wspominałem, najważniejsza informacja w całym procesie wymiany danych między oboma systemami. Jeśli nie zostanie ona odebrana i nie połączymy za jej pomocą numeru listu z numerem referencyjnym (obowiązującym w naszej firmie), dalsza wymiana danych nie będzie możliwa. Przyjmijmy jednak, że wymieniamy informację umożliwiającą odtworzenie relacji: numer faktury - numer listu. Dzięki temu możemy możemy śledzić stan naszej przesyłki. W praktyce odbywa się to poprzez odbieranie informacji o statusach przesyłki. Określają one takie zdarzenia jak na przykład przyjęcie do wysyłki, przejście przez sortownię, dotarcie do przedstawicielstwa, wydanie kurierowi czy dostarczenie do klienta. Informacje te umożliwiają określenie stanu doręczenia paczki do odbiorcy końcowego. Kolejna porcja danych, którą odbiera się regularnie, to informacja o pobraniach, skojarzonych z przesyłkami i przekazanych na konto firmy wysyłającej. Jako ostatnie do klienta powinno trafić elektroniczne rozbicie faktury, które umożliwi zlecającemu potwierdzenie poprawności naliczenia opłaty za wykonaną przez spedytora usługę.

W praktyce sposób wymiany tych informacji między spedytorem, a jego klientem zależy od ustaleń między nimi. Sądzę, że przy bardzo dużej liczbie przesyłek (kilka tysięcy dziennie) możliwe jest ustalenie dowolnego formatu wymiany danych korzystnych dla zlecającego. Przy zleceniach rzędu kilkuset przesyłek dziennie lub mniejszych należy dopasować się do standardów proponowanych przez spedytora. Poniżej opiszę standardy stosowane w różnych firmach. Opis bazuje na własnych doświadczeniach i rozmowach z innymi użytkownikami bądź przedstawicielami spedytorów i w poszczególnych przypadkach inni klienci moga uzyskać lepsze (lub gorsze) warunki współpracy. Pominę kwestię eksportu danych z systemu firmowego do programu kurierskiego i z powrotem, gdyż dość szeroko omówiełem ten problem wcześniej. Jeżeli chodzi o współpracę programu kurierskiego zainstalowanego u klienta z serwerem w centrali, stosuje się kilka różnych standardów. Stolica wystawia na przykład na zewnątrz (w sposób widoczny z internetu) serwer SQLowy (w przypadku Stolicy jest to Sybase), do którego można odwoływać się w sposób porównywalny do transakcji z lokalnym serwerem. Zabezpieczenie składa sie z kilku elementów. Na poziomie biznesowym zabezpieczenie bazuje na tym, że każdy z dużych klientów otrzymuje uprawnienia do swojej bazy danych (nazywanych Partner), replikowanych z głównej bazy spedytora. Ta replikacja wprowadza niekiedy problemy, gdyż okazuje się, że nie zawsze przebiega ona sprawnie (dane o listach przewozowych są widoczne w internecie, a nie widać ich w bazie Partner). Moim prywatnym zdaniem sytuacja wygląda tak, jakby administratorzy wyłączali czasami co bardziej przeciążające serwer zadania sprawdzając, czy klienci zgłoszą pretensję (jest to test, czy klienci na bieżąco odbierają dane). Na poziomie informatycznym zabezpieczenie bazuje na hasłach do baz danych oraz firewallu otwieranym na czas dostępu do serwera. Inne rozwiązanie stosuje Szybka Paczka. W tej firmie dane wymieniane są w sposób plikowy. Pliki zarówno do serwera Szybkiej Paczki jak i z niego są czasowo (na moment wymiany) składowane na serwerze FTP. Zabezpieczeniem jednocześnie biznesowym i informatycznym są osobne katalogi serwera, dostępne dla poszczególnych klientów (oczywiście tylko po podaniu hasła). Poziom bezpieczeństwa podnosi też mechanizm usuwania danych z serwera przez proces pobierający, który ma obowiązek usunięcia przeczytanych plików (przy odpowiednim zgraniu pliki mogą przebywac na serwerze najwyżej kilka minut na 24 godziny). Rzowiązaniami stosowanymi przez inne firmy jest porozumiewnie się po protokole http. Zabezpieczeniami są wtedy elementy uwierzytelniające typu login i hasło oraz dynamicznie generowane strony i ich adresy.

Tym samym torem, którym przesyła się dane do serwera spedytora o listach odbiera się zazwyczaj dane o statusach doręczeń. Oczywiście dane te moga byc tez czytane ręcznie przez użytkownika ze strony WWW firmy spedycyjnej. Jednak przy kilkuset przesyłkach dziennie rozwiązanie takie staje się bardzo nieekonomiczne i nieefektywne pod względem szybkości i trafności analizy. Znacznie lepiej więc dokonać automatycznego spięcia danych o zamówieniach i fakturach z danymi o listach i umożliwić dostęp do tych danych klientowi końcowemu. Właśnie taki model udostępnia OSDW Azymut swoim klientom. Klient skaładając zamówienie otrzymuje wraz z potwierdzeniem numer tego zamówienia. Jest on przekazywany przez dyspozycję magazynową na fakturę, a tam poprzez jej numer jest kojarzony z numerem listu przewozowego. Na jego podstawie z całym procesem obsługi zamówienia kojarzone są dane o zaawansowaniu realizacji zamówienia. Wszystko razem agragowane jest przez mini hurtownię danych (nazwaną TRACE2 od angielskiej wersji słowa śledzić), która jest przeliczana co 2 godziny (tyle maksymalnie, w pesymistycznych warunkach, trwa okres między złożeniem zamówienia, a powstaniem faktury). Po agregacji dane wystawiane są na stronie intranetowej dla pracowników Działu Reklamacji oraz w internecie dla klienta. Dzięki temu może on już w kilka godzin po złożeniu zamówienia ocenić proces podążania jego paczki do miejsca przeznaczenia.

Ostanie dwa rodzaje dokumentów nie są związane z bezpośrednią obsługą paczki, tylko z kwestiami rozliczeniowymi. Pierwszy dokument to lista wpłat na konto z przesyłek pobraniowych, drugie to elektroniczne rozbicie faktury. Ze względu na to, że zjawiska takie nie zachodzą zbyt często najpopularniejszą metodą jest przesyłanie tych danych w postaci pliku Excela z użyciem poczty elektronicznej. W pliku takim znajduje się (niemal zawsze) skojarzenie wplat z numerami listów przewozowych (dla pobrań) oraz opłat za paczki równiez z listami. Rozpoczynając stałą współpracę z kurierem warto zastrzec sobie w umowie stały i określony format otrzymywania tych danych. Można dzięki temu osiągnąć automatyzację, eliminującą ponad 90 procent ręcznej pracy. W naszym przypadku zostało to osiągnięte z użyciem tej samej hurtowni danych, co śledzenie przesyłek. Dodatkowe narzędzie umożliwiające łączenie danych z Excela z danymi z serwera SQL pozwala na sparowanie numerów faktur i ich wartości z listami przewozowymi i wpłaconymi kwotami. Jeżeli obie wartości są zgodne to wpłata jest przyjmowana bezspornie na konto klienta, bez ręcznego sprawdzania (błędy zdarzają się z częstotliwością raz na 10 tysięcy wpłat i wynikają z błędnego podania przez spedytora numeru listu). Dopiero kwoty sporne są analizowane ręcznie. Podobnie jest z opłatą za usługi kurierskie. Faktura jest kojarzona danymi o dostawach listów. Do ręcznej analizy są wybierane wyłącznie opłaty za te listy, które nie maja statusów dostarczone, statusy doręczenia sugerują czas dostawy dłuższy niż jeden dzień, bądź wogóle jest brak statusu. Te pozycje faktury są analizowane ręcznie pod kontem reklamacji i obniżenia wartości faktury ze względu na niewywiązanie się spedytora z umowy. Takie rozwiązanie automatycznie pozwala wychwycić próby przemycenia w fakturze opłat za listy nie nadane w naszym systemie (które też się czasami zdarzają, najczęściej ze względu na listy wypisywane ręcznie przez kurierów odbierających paczki bądź błędy przekazania elektronicznych danych do systemu kuriera). Dodatkowo dane przekazywane na fakturze (koszty dostarczenia poszczególnych przesyłek) można importować do systemu firmowego w celu lepszej analizy kosztów. Dane takie (koszt dostarczenia poszczególnych przesyłek) można wykorzystać w systemie CRM jako kolejny współczynnik definiujący klienta (na przykład określający najlepszy stosunek obrotów do kosztów logistycznych). Warto zauważyć, że pozornie mało ważne dane też mogą nieść ciekawą i przydatną dla firmy informację.

Podsumowanie

Minęły czasy, kiedy od spedytorów oczekiwaliśmy jak najszybszego dostarczenia paczki w określone miejsce. Teraz oczekuje się zarówno szybkości w dostarczeniu (bądź spełnienia umowy w zakresie zastrzeżonego momentu doręczenia), oraz maksymalnego ułatwienia w kontaktach między zlecającym wysyłkę, a kurierem. Oczekuje się, że kurier odbierze od firmy dane w postaci elektronicznej, wygeneruje na tej podstawie listy przewozowe oraz będzie się rozliczał i przedstawiał raporty również w elektronicznej postaci, jak najlepiej dopasowanej do wymagań klienta. Tego się oczekuje i większość firm spełnia te wymagania. Natomiast informatyka idzie naprzód i jutro będzie się oczekiwać jeszcze więcej. Dziś informacje o stanie paczki pojawiają się co najwyżej 2 lub 3 razy dziennie. Rano możemy się więc dowiedzieć, że paczka przeszła przez sortownię, w ciągu dnia, że wydano ją kurierowi, a późnym wieczorem, że dotarła do klienta. Często jest to informacja wystarczająca. Ale nie zawsze. Akcje promocyjne związane na przykład z premierami książek (tak było w przypadku książki "Hary Potter i cośtam") wymuszają dokładniejszą wiedzę o stanie przesyłki. Premiera ostatniego tomu tej książki odbywała się w sobotę. Książka, jakkolwiek wydrukowana wcześniej, dotarła do dystrybutora w czwartek w ciągu dnia. Udało się nam zapakować wszystkie zamówione egzemplarze i przekazać spedytorom w czwartek wieczorem. A w piątek dział reklamacji i zwrotów siedział jak na szpilkach i nie potrafił odpowiedzieć na najczęściej zadawane pytanie: "czy książki do nas jadą i kiedy będą?". I to jest właśnie bliska przyszłość informatyki w firmach spedycyjnych. Teraz każdy przeciętny handlowiec z dużej firmy ma już HandHelda połączonego z centralą przez komórkowy GPRS. Na rynku są też już urządzenia potrafiące określić miejsce położenia za pomoca systemu GPS oraz dokładne mapy Polski. Wystarczy więc tylko zestawić ze sobą tą wiedzę, żeby móc w trybie on-line określić, że paczka dotrze do odbiorcy w konkretnym momencie. Oraz oczywiście w chwili jej odebrania wystawic status "paczka dotarła" (takie rozwiązania wdroża UPS w 2 największych miastach Polski oraz TNT). Uważam, że w niedalekiej przyszłości bieżące raportowanie stanu, włącznie z wyprzedzeniem (czyli określające przewidziany czas dostawy) będzie na porządku dziennym. Wydaje mi się też, że firmy powinny być gotowe na większą elstyczność w stosunku do klienta, to znaczy powinny dostarczać dane w łatwo modyfikowalnych formatach z użyciem kilku różnych protokołów. Optymalne byłoby pojawienie się platformy obsługi dostaw do klientów analogicznej do AX4 firmy AXIT, dotyczącej logistyki zaopatrzenia. Ale to uwaga nie do spedytorów, tylko do producentów oprogramowania.

Spedytor nie jest juz tylko dostarczycielem przesyłek. Spedytor staje sie powoli fragmentem większej układanki wpasowującym się w biznes wielu klientów. I to nie tylko swoim głównym działaniem ale również swoją informatyką. I jakkolwiem mam drobne uwagi do działania wiekszości firm spedycyjnych, z czystym sercem mogę powiedzieć, że firmy kurierskie w ciągu ostatnich lat zrobiły duży krok naprzaód i są blisko celu, którym jest zadowolenie klienta.

Uwaga po latach

Obecnie wszystkie poważne systemy WMS mają wbudowaną opcję integracji z systemami kurierskimi i jedyne o czym trzeba pamiętać, to zadbanie o właściwy wybór programu magazynowego, tak by obsługiwał w prosty sposób najważniejsze firmy kurierskie.

Literatura:

Bartczak Iwona D., IT z korzyścią dla klienta, CXO, Grudzień 2003
Bielewicz Antoni, Źródła rezerw, Computerworld, 2 marca 2004
Data Group, Raport: Operator logistyczny roku 2003.
Domaradzki Aleksander, Osobno, ale razem, Businessman Magazine, 23 marca 2004 (onet.pl)
Golachowski Krzysztof, Paczki pod kontrolą, PCkurier 20/1999
Janiak Tomasz, Nowa internetowa platforma transportowo-logistyczna, Logistyka 2/2003
Olszewski Jacek, Najszybciej i najtaniej do klienta, CXO, Listopad 2003
Świstowski Andrzej, Wymana dokumentów EDI, portal LogistykaFirm.com
Tarkowski Jacek, Stefaniak Radosław, Zarządzanie łąńcuchem dostaw w dobie gospodarki elektronicznej, Logistyka 6/2001
Wierzbicki Marek, Klaster PC. Sposób na efektywne wykorzystanie zasobów, Materiały XV Górskiej Szkoły PTI, Szczyrk 2003
Wyrzykowski Artur, Zasoby pod ręką, Teleinfo, 5 kwietnia 2004