Informatyzacja logistyki

Z tego wynikało – zapisane na kolejnym slajdzie –

„Pytanie na wszystkie następne piątki:
co może się zdarzyć co nie ma prawa się wydarzyć.”

Możliwe konsekwencje braku odpowiedzi na to pytanie prowadziły do ostrzeżenia ze slajdu 35, że

„Największym zagrożeniem dla dzisiejszej firmy jest niezdolność do dostrzegania związku
między dzisiejszą fikcją i jutrzejszą rzeczywistością”.

Dlatego zagadnieniem o zasadniczym znaczeniu jest rozpoznanie symptomów tych zdarzeń, które „nie mają prawa się wydarzyć”, aby to co nadchodzi zbytnio nie zaskakiwało.

W dziedzinie systemów informatycznych to „niemożliwe” mogłoby np. polegać na tym, że użytkownik programuje działania realizowane za pomocą systemu informatycznego.

Od wielu już lat również logistykom komputery przychodzą z pomocą. Obecnie przyjmuje to postać lawiny programów, które epatują nazwami klas do jakich nalezą. Najwcześniej na służbę logistykom przybyły programy do planowania potrzeb materiałowych. Programy te utworzyły specjalną klasę, która przyjmowała kolejne nazwy: MRP¹⁾, MRP II²⁾, ERP³⁾. Z czasem przybyła klasa CRM⁴⁾, do obsługi relacji z klientami. Gdy można już było komputerowo sterować na odległość ruchami ludzi i wózków pojawiła się klasa WMS⁵⁾. Współcześnie rozwija się klasa PLM⁶⁾.

MRP ma już ponad 60 letnią tradycję rozwoju jej zastosowań. W zaawansowanej formie „System ERP z jego (teoretyczną) możliwością złączenia globalnych funkcji i procesów wydawał się darem bożym dla logistyków. Tymczasem […] PA Konsulting Group stwierdziła, że 92 % firm, które zainstalowały ERP nie są z tego zadowolone.” [Peter Bartram: Where ERP actually works. Logistics Europe, September 2002] Zapewne podobny los czeka pozostałe pomysły na informatyczne wspomaganie logistyki, za którymi nie ma jeszcze ani tradycji stosowania ani badań, które oceniałyby ich przydatność. Nie usunięto bowiem przyczyn, z powodu których wdrażanie systemów informatycznych w dziedzinie logistyki sprawia kłopoty i nie przynosi spodziewanych efektów.

Potocznie jako „logistyczne” określa się wszystko to, co jest związane z przemieszczaniem towarów. Nie idzie za tym żadna dodatkowa teść. Tymczasem logistyczna relacja wiążąca dostawcę i odbiorcę powoduje, że dostawca - mając do wyboru swoją wolę albo to, co chce klient – musi liczyć się z opinią klienta. Albowiem coś może być dobrem jedynie w opinii odbiorcy, który dopiero po dostarczeniu towaru zatwierdza zrealizowaną dostawę. Tym samym określenie „logistyczne” może dotyczyć tylko tego, co faktycznie służy dostarczaniu jakiegoś dobra.

Wspólną cechą systemów informatycznych jest dostarczanie logistykom szybkości obliczeń komputerowych. Jest to istotna korzyść, gdyż dzięki temu można coraz szybciej przemieszczać ładunki w ramach sieci logistycznych. Mogłoby to być traktowane jako dobro, gdyby nie forma tego dostarczania. W odniesieniu do programów komputerowych nie liczy się bowiem opinia odbiorcy, czyli użytkownika, lecz trzeba bazować na opinii dostawcy oprogramowania. To on – tworząc określony program – uznał go za dobry dla logistycznych potrzeb odbiorcy. W ramach tego udostępnił odbiorcy wachlarz określonych funkcji, z których odbiorca musi być zadowolony. Po zakupieniu programu nie ma on już żadnego wpływu ani na zbiór tych funkcji ani na sposób ich realizowania.

W efekcie logistyk, korzystający z systemu informatycznego – który wspomaga go w wielu istotnych sprawach dotyczących dostarczania – musi zdawać sobie sprawę z tego, że twórca programu mógł mieć tylko wyobrażenie o możliwych klientach, a klienta aktualnie obsługiwanego to nawet nie widział na oczy. Skutkiem tego na pewno znajdzie się kiedyś w takiej sytuacji, że choć zgadza się z wolą klienta, to nie może jej spełnić, bo „system nie pozwala”.

To zaś oznacza, że o sposobie dostarczania dóbr nie decyduje już ani odbiorca, ani dostawca, tylko twórca programu. W związku z tym nie można mówić o faktycznej trosce dostawcy o dobro klienta. Tym samym współczesne programy komputerowe stanowią tylko pozór dobra i nie mogą być określane jako logistyczne. Np. nie można używać terminu „logistyczne zarządzanie magazynem” w odniesieniu do komputerowego programu sterującego pobieraniem materiałów z magazynu.

Aby oprogramowanie komputerów spełniało potrzeby logistyki, użytkownik systemu informatycznego powinien mieć zawsze możliwość dostosowania się do wymagań klienta. Zatem logistyczny system informatyczny powinien mieć własność umożliwiającą użytkownikowi programowanie zakupionego systemu we własnym zakresie. Dziś w tym celu musiałby prosić twórcę systemu o wprowadzenie do niego odpowiednich modyfikacji.

Jednak przy dzisiejszym sposobie tworzenia oprogramowania użytkownik systemu informatycznego nie tylko nie jest przygotowany do programowania, ale dostawca systemu nie jest w stanie go do tego przygotować. Przez lata rozwoju informatyki przyzwyczajono nas, że programowanie funkcji systemu informatycznego – udostępnianych użytkownikowi w postaci np. menu – należy do kompetencji programisty. Dla użytkownika jest to zawsze poziom niedostępny. W niektórych przypadkach może on co najwyżej parametryzować funkcje programu lub mieć wpływ np. na postać raportu. Przeszkody są dwie. Po pierwsze logistycy musieliby umieć to, co umieją programiści, a to nie jest ich kompetencja. Po drugie musieliby mieć dostęp do postaci źródłowej oprogramowania, na co na razie nie chcą zgodzić się dostawcy oprogramowania.

Jednak nie to stanowi istotę problemu. Nadal pozostaje bariera w postaci stosowanego języka programowania. Wynik dotychczasowego rozwoju programowania jest taki, że pisanie programów jest zbyt skomplikowane dla użytkownika.

Rozwiązaniem problemujest zmiana zasad tworzenia języków programowania. Programiści powinni tak pisać programy by użytkownik zamiast wykorzystywać gotowe funkcje mógł swoje zadania programować we własnym zakresie. Do tego celu użytkownik systemu informatycznego powinien dysponować odpowiednim językiem programowania dostosowanym do problemów, jakie będzie rozwiązywał za pomocą systemu informatycznego.

Wbrew pozorom nie oznacza to autarkii porównywalnej do sytuacji, gdy transportowiec robi we własnym zakresie samochód. Nie byłby to też powrót do „prehistorii” komputerów, gdy każdy użytkownik programował swój komputer bez jakiegokolwiek systemu operacyjnego.

Raczej chodziłoby o doprowadzenie do sytuacji, jaka ma miejsce w przypadku innych urządzeń. Kupując bowiem dowolne urządzenie dostajemy wraz z nim instrukcję obsługi. To jest w istocie język, za pomocą którego programujemy nasze działania z tym urządzeniem. Nigdzie takich programów się nie zapisuje, bo są na tyle proste, że za każdym razem można je wymyślić od nowa.

Tylko w przypadku komputerów tak się złożyło, że wszystkie możliwe zastosowania realizuje się za pomocą tej samej instrukcji obsługi, zawartej w języku programowania. Ponadto wszystko programuje się w takim samym – co do swej istoty – języku programowania. Nie ma jednak– oprócz dotychczasowej tradycji – żadnego poważnego uzasadnienia, żeby tak było nadal.

Obecnie komputery wchodzą do różnych dziedzin życia pod różnymi postaciami. Wysyłając np. SMS-y użytkownicy nie muszą programować swoich telefonów komórkowych. Ale program użytkowy, jaki realizują jest trywialny. Nawet nie nazywa się tego programem, tylko użytkowaniem funkcji telefonu. Za tym jednak kryje się odpowiednio oprogramowany komputer.

Systemy informatyczne – tak jak dowolne urządzenia z instrukcją obsługi – powinny być tak przygotowane, aby programowaniem użytkowania zajmował się bezpośredni użytkownik, wg odpowiedniej instrukcji użytkowania i przy użyciu odpowiedniego języka programowania. Wtedy dopiero będzie można mówić o logistycznym systemie informatycznym.

W praktyce mogłoby to wyglądać następująco. Dostawca towaru negocjuje z klientem i wspólnie uzgadniają, co klient potrzebuje. Następnie dostawca sprawdza, co może zrobić za pomocą posiadanego systemu informatycznego. To, czego w systemie nie ma, programuje we własnym zakresie. Może oczywiście dokupić te zwiększone możliwości oprogramowania i dodać do tego, co już ma, bez rujnowania tego co już ma gotowego.

W tym kontekście warto zwrócić uwagę na przypadek pewnej firmy dystrybucyjnej, w której postanowiono zainstalować komputerowy system sterowania przepływem materiałów, tzw. WMS. Zadanie to powierzono firmie informatycznej, która nie miała wcześniej doświadczenia w tej dziedzinie. W zamian za to zrealizowała dokładnie to, czego sobie życzyli kierujący magazynem. W tym jednak celu w trakcie realizacji projektu pracownicy firmy dystrybucyjnej musieli wprowadzić informatyków w tajniki swego zawodu.

A ponieważ wdrożenie zakończyło się sukcesem, to już wkrótce pojawiły się ogłoszenia oferujące usługi tej firmy informatycznej w zakresie WMS. Niestety nauka na jednym przykładzie prowadzi do lasu, o czym firma przekonała się na drugim przykładzie, jakiego się podjęła. Na domiar złego magazynierzy tym razem zawierzyli kompetencjom informatyków, na czym obie strony się przejechały.
Trzeci akt tego serialu właśnie się toczy, a kanwą jest wzajemne niezrozumienie kompetencji.

Programowanie systemu informatycznego we własnym zakresie ma dla użytkowników krytyczne znaczenie. Pierwszy powód jest taki by chronić własne cele i pomysły na ich realizację przed informatykami z firmy zewnętrznej. Drugi powód to brak pokus by zawierzać sukces swojego przedsięwzięcia firmie zewnętrznej.

Jedyną metodą osiągnięcia tego celu jest udostępnienie użytkownikowi specjalizowanego języka programowania, którego alfabet będzie wykraczał poza litery i cyfry.

Język taki nie powinien też bazować na pochodnych języka FORTRAN, z którym spowinowacone są prawie wszystkie współczesne języki programowania. Nawet jego twórca, John Backus stwierdził w 1978 r., że był to niefortunny pomysł na programowanie komputerów, choć może rozwój języków programowania nie mógł być inny. Ubocznym bowiem skutkiem ułatwienia pisania programów było zablokowanie gotowości przyjęcia nowych idei programistycznych, jakie mogłyby pojawić się w przyszłości. To, że się takie nowe idee dotąd nie pojawiły nie oznacza, że nie powinny i nie mogą pojawić się w przyszłości.

Dlatego odpowiedź na copiątkowe pytanie pracowników firm informatycznych byłoby następujące.

To, co nie ma prawa się wydarzyć, to żądanie użytkownika, by we własnym zakresie mógł programować funkcjonowanie zakupionego systemu informatycznego.

Gdyby to niemożliwe się wydarzyło, to w stosunku do aktualnych systemów taki „programowalny” system informatyczny miałby taką przewagę, że użytkownik nie ujawniałby przed firmą informatyczną ani swoich celów ani sposobów ich osiągania. Dzięki temu też firmy informatyczne mogłyby skupić się na swojej kompetencji, zamiast dystrybuować pomiędzy swoimi klientami pomysły innych swoich klientów. Takie postępowanie obecnie skutecznie niweluje przewagę konkurencyjną jaką mogłoby dawać wdrożenie systemu informatycznego.

Przede wszystkim jednak taki „niemożliwy” system informatyczny nie tworzyłyby nieprzebytej bariery pomiędzy dostawcą a odbiorcą dóbr. Przy okazji dostawca mógłby dzięki temu starać się o zostanie „osobą przyjazną logistyce”.

1) MRP – Material Requirement Planning,

2) MRPII – Manufacturing Resource Planning,

3) ERP – Enterprise Resource Planning,

4) CRM – Consumer Relation Management,

5) WMS – Warehouse Management System,

6) PLM – Product Lifecycle Management.

Źródło: www.espedycja.pl
Autor: Józef Okulewicz, dr inż. - Wydział Transportu Politechniki Warszawskiej - www.okulewicz.republika.pl