WSTĘP
Systemy logistyczne są w ogólności systemami materialnymi obejmującymi środki zapewniające przepływ materiałów, ludzi, finansów i informacji [1]. Istotną rolę w systemach logistycznych odgrywają procesy przetwarzania danych i podejmowania decyzji. Informacja jest przy tym głównym czynnikiem umożliwiającym powiązanie procesów transportowych z procesami w sferze działalności produkcyjnej i magazynowej. Często pełni też inicjującą rolę w procesach transportowych wpływając w znaczącym stopniu na ich efektywność.
Ze względu na obniżanie się kosztów systemów informatycznych coraz więcej i to coraz mniejszych firm próbuje wdrażać u siebie systemy informatyczne. Nie ma z tym żadnych problemów w odniesieniu do działalności standardowej lub stabilnej. Gdy jednak system ma objąć dziedzinę często zmieniającą się, to albo bardzo trudno wdrożyć taki system albo po sukcesie wdrożeniowym elastyczność firmy wbrew oczekiwaniom staje się mocno ograniczona. Potocznie system utożsamia się z pewną rzeczywistością. Jednak pojęcie systemu określa sposób poznawania przez człowieka otaczającej go rzeczywistości. Systemem nazywamy zbiór elementów i wiążących je relacji [4] przydatnych do opisu wybranego fragmentu rzeczywistości. Kryterium dla wyodrębnienia elementów i relacji systemu stanowi cel, dla którego dana rzeczywistość jest badana lub poznawana. Ze względu na przyjęty cel definiuje się elementy systemu, którym najczęściej odpowiadają pewne obiekty rzeczywiste. Często jednak jest tak, że obiekty rzeczywiste, aby móc istnieć, posiadają szereg innych własności, które umożliwiają osiągnięcie także innych celów niż te, które sformułowano przy opisie systemu. W wyniku tego okazuje się, że system rzeczywisty może być użytkowany nie tylko do celów, dla których był utworzony ale także dla innych, o których twórcy systemu często nie myśleli lub nie przewidywali. Zwykle dopiero zmiana warunków funkcjonowania systemu rzeczywistego może spowodować ujawnienie jego ukrytych możliwości.
To co nie udaje się w przypadku systemów tworzonych z obiektów materialnych możliwe jest w przypadku systemów informatycznych. Komputery umożliwiają tworzenie systemów, których funkcjonowanie odpowiada ściśle założeniom, a jedynie błąd w doborze oprogramowania lub sprzętu może powodować działania inne niż zamierzone.
Z jednej strony mamy więc do czynienia z systemem logistycznym, który oprócz znanych własności ma znaczne potencjalne możliwości realizacji innych nieznanych zadań. Z drugiej strony jest system informatyczny utworzony na potrzeby znanych własności funkcjonalnych systemu logistycznego. System logistyczny może sprostać zmianom warunków funkcjonowania, a ponadto może ulegać znaczącym modyfikacjom, jeśli warunki zewnętrzne będą tego wymagały. System informatyczny zaś ma niewielkie możliwości realizacji innych funkcji niż te, dla których został utworzony. Owocne współdziałanie dwóch systemów o tak różnych cechach często kończy się w krótkim czasie po jej inauguracji.
Początkowa zgodność pomiędzy systemem informatycznym i logistycznym może być utracona czy to ze względu na zmianę celów systemu logistycznego czy też zmianę zakresu uświadomienia sobie tych celów przez kadrę zarządzającą. Często samo rozpoczęcie myślenia o informatyzacji systemu logistycznego zmienia sposób myślenia pracowników o jego celach i sposobie funkcjonowania. Projektanci systemu informatycznego często nie są w stanie uchwycić tych zmian ani nadążać za nimi.
System informatyczny aby móc współdziałać z systemem logistycznym powinien się charakteryzować takimi samymi jak on cechami, tzn. umożliwiać realizację funkcji niewiele odbiegających od założeń oraz umożliwiać łatwe modyfikowanie realizowanych funkcji odpowiednio do zmian zachodzących w systemie logistycznym.
W znanych systemach informatycznych tworzonych na potrzeby systemów logistycznych [2] wymaganie to jest realizowane poprzez modułowość tych systemów. Moduł jest autonomicznym elementem, który może być zainstalowany w systemie informatycznym w celu zwiększenia jego własności funkcjonalnych. Umożliwia to wymianę modułu na nowszy bez konieczności dokonywania istotnych zmian w całym systemie.
W ostatnich latach występuje tendencja by system informatyczny umożliwiał działanie zbioru względnie odosobnionych tzw. "obiektów" [8], wg procedur zawartych w definicjach poszczególnych obiektów. Wydaje się, że technologia programowania obiektowego w odpowiednim środowisku daje możliwość dalszego rozdrobnienia modułów systemu informatycznego i dynamicznego modyfikowania systemu poprzez wymianę obiektów bez konieczności generowania całego systemu.
OBIEKTOWE PROJEKTOWANIE SYSTEMU INFORMATYCZNEGO
Zwykle przyjmuje się, że system informatyczny ma służyć do realizacji tych funkcji, które są realizowane w istniejącym nieinformatycznym systemie informacyjnym. Wynik analizy systemu informacyjnego, choć daje wystarczająco dokładny opis badanego systemu, nie może być bezpośrednio przełożony na oprogramowanie. Przyczyną tego jest to, że metody stosowane przez projektantów systemów i twórców oprogramowania różnią się i nie są wzajemnie dopasowane w dostatecznym stopniu [5].
Nadzieje związane z szybko rozwijającą się analizą obiektową (analiza zorientowana obiektowo) bazują na tym, że zarówno analiza, jak i projektowanie i programowanie będą realizowane wg tych samych zasad. Analiza obiektowa poprzedza etapy projektowania i programowania systemu, które są także realizowane metodami zorientowanymi obiektowo. “Obiektowość” jako wspólna płaszczyzna analizy i projektu systemu może spowodować, że wyniki poszczególnych faz tworzenia systemu informatycznego będą w większym stopniu wykorzystywane na następnych fazach tworzenia systemu. Aktualnie mocno zaawansowane są prace nad projektem zakładającym montowanie programu do zarządzania firmą z gotowych obiektów dostarczanych przez różnych wytwórców [3].
W metodologii zorientowanej obiektowo postuluje się aby obiekt definiować jako "pojęcie lub przedmiot materialny, które może być wyodrębnione z otoczenia" [6]. W systemie informatycznym obiekt występuje jako zbiór zmiennych i metod. Funkcjonowanie obiektu polega na odbieraniu komunikatów i reagowaniu na nie. Konkretny obiekt jest generowany na podstawie definicji klasy obiektów. Obiekt jest hermetyczny i nie zmienia swej postaci.
Jednak słabą stroną analizy zorientowanej obiektowej jest określanie klas metodą zgadywania. Pewną wygodę może stanowić możliwość powtórnego wykorzystywania raz opracowanych klas w kolejnych programach. Powinno to skłaniać programistów i projektantów do tworzenia klas możliwie uniwersalnych aby ułatwić ich ponowne użycie. Ponadto umożliwi to powstanie rynku, na którym będą oferowane klasy powstałe na potrzeby istniejących programów oraz takie, które były tworzone z myślą o przyszłych programach. Spowoduje to, że analiza systemu informacyjnego będzie sprowadzała się do przeglądaniu zbiorów istniejących klas obiektów, z których będą wybierane klasy odpowiednie dla modelowanego systemu. Uprości to i przyśpieszy tworzenie systemów informatycznych.
RELACYJNE PROJEKTOWANIE SYSTEMU INFORMATYCZNEGO
Podstawą pomysłu aby odwzorowywać w programie lub w systemie informatycznym obiekty występujące w świecie rzeczywistym jest założenie, że człowiek postrzegając rzeczywistość wyodrębnia w niej obiekty a następnie je klasyfikuje [6]. Przyjmuje się, że tak wyodrębniony obiekt istnieje niezmiennie i wystarczy go odwzorować w systemie informatycznym aby utworzyć model będący obrazem rzeczywistości.
Jednak wyodrębnienie czegokolwiek w otaczającej człowieka rzeczywistości polega w istocie na wyodrębnieniu tego czegoś w wewnętrznym obrazie rzeczywistości jaki człowiek tworzy na swoje potrzeby. Mimo pozorów odrębności i hermetyczności obiekt jest subiektywnym tworem człowieka, jako odpowiedź na doraźne potrzeby. Nie można więc w systemie informatycznym, który jest modelem rzeczywistości, nadawać obiektowi cech trwałości. Nie ma także potrzeby aby na czymś tak nieuchwytnym i nieprecyzyjnym jak obiekt budować koncepcję systemu informatycznego. Wydaje się, że procedurą bardziej podstawową od klasyfikowania i wyodrębniania obiektów, jest wchodzenie w relacje z rzeczywistością. Sposób postrzegania rzeczywistości jest zależny od relacji w jakiej jest z nią postrzegający podmiot. Na potrzeby danej relacji podmiot tworzy pewne atrybuty i nadaje im wartości odpowiednio do sytuacji, w której się znajduje. Ten konkretny zbiór atrybutów na tę konkretną potrzebę może przybrać postać obiektu. Oczywiście obiektem może być coś konkretnego co ma swój odpowiednik w rzeczywistości, ale też może to być jakiś obiekt abstrakcyjny, pojęcie, problem albo zadanie, z czym jako reprezentacją rzeczywistości podmiot jest w relacji.
Nawet pobieżna analiza procesu podejmowania decyzji wskazuje, że występuje w nim kilka kolejnych faz przetwarzania informacji. Przede wszystkim aby mogło mieć miejsce przetworzenie informacji przez decydenta, musi wcześniej nastąpić zarejestrowanie danych, a następnie poinformowanie go np. o potrzebie i warunkach podjęcia decyzji. Odbiorca informacji może wykorzystać dane do podjęcia decyzji, która następnie wymaga realizacji. W tym celu niezbędne jest przygotowanie odpowiednich poleceń, instrukcji i przekazanie ich wykonawcy, który je zrealizuje. Polecenia są przekazywane w postaci danych, które z kolei muszą być przez wykonawcę zarejestrowane, zrozumiane itd. Jeśli decyzje są podejmowane w jednym systemie i dotyczą drugiego systemu, to pierwszy z tych systemów pełni funkcję "podmiotu", a drugi - funkcję "przedmiotu".
Dla potrzeb analizy procesu decydowania relacje pomiędzy takimi dwoma systemami wygodnie jest rozpatrywać tylko z punktu widzenia jednego z nich, tzn. "podmiotu". Na odpowiednim poziomie ogólności można tu wyróżnić trzy rodzaje relacji. Pierwszy rodzaj relacji jest związany z tym, że podmiot postrzega przedmiot, drugi - z tym, że podmiot oddziałuje na przedmiot, a trzeci - z brakiem postrzegania i oddziaływania pomiędzy nimi. Dodatkowo ze strony podmiotu zarówno postrzeganie jak i oddziaływanie może być realizowane albo w sposób pasywny, albo aktywny.
Po połączeniu scharakteryzowanych powyżej rodzajów relacji ze sposobami ich zachodzenia, otrzymuje się zupełny zbiór pięciu relacji, występujących kolejno pomiędzy dwoma systemami w procesie postrzegania i oddziaływania jednego na drugi (podmiotu na przedmiot). Na tej podstawie można zdefiniować "cykl informacyjny" składający się etapów odpowiadających wyróżnionym powyżej relacjom [7]. Etapy te w odniesieniu do podejmowania decyzji można określić następująco:
1) rejestrowanie - rozumiane jako postrzeganie pasywne,
2) informowanie - rozumiane jako postrzeganie aktywne,
3) decydowanie - rozumiane jako brak postrzegania i oddziaływania,
4) zlecanie - rozumiane jako oddziaływanie pasywne,
5) wykonywanie - rozumiane jako oddziaływanie aktywne.
Powyższe relacje dotyczą zbiorów komunikatów, gdyż w przypadku przetwarzania informacji występującego w procesie podejmowania decyzji, argumentami relacji są komunikaty (wiadomości).
Podmiot podejmuje swe działania w odniesieniu do pewnych przedmiotów w obszarze działania systemu. Przedmiotem może być jakiś fizyczny obiekt albo zadanie. Zbiór atrybutów, tworzony na potrzeby podmiotu, składa się na statyczny model przedmiotu wykorzystywany przez ten podmiot. Stan modelu, będący zbiorem wartości atrybutów, zmienia się w kolejnych etapach cyklu informacyjnego.
STRUKTURA SYSTEMU INFORMACYJNEGO
Wykorzystując pojęcie cyklu informacyjnego można określić system informacyjny jako zbiór powiązanych wzajemnie cykli informacyjnych i występujących w nich modeli. W cyklach tych są realizowane procesy podejmowania decyzji.
Cykle informacyjne systemu mogą dotyczyć rozmaitych przedmiotów, tzn. że system może zawierać modele kilku różnych przedmiotów. Dany przedmiot może mieć przy tym różne modele w różnych cyklach.
Na poszczególnych etapach cyklu informacyjnego każdy z modeli może być poddawany rozmaitym operacjom na jego atrybutach i relacjach. Aby można było posługiwać się modelem na poszczególnych etapach jest on utożsamiany z pewnym obiektem. W efekcie obiekt ten staje się nośnikiem pewnego modelu. Do tak rozumianego obiektu można przypisać jeden lub kilka modeli zmieniających się na poszczególnych etapach. Dodatkową cechą proponowanej metodologii jest to, że metody i zmienne nie są utożsamiane z obiektem na stałe i postać modelu przypisana do obiektu może się zmieniać.
Można więc powiedzieć, że cykle informacyjne są strukturą nadrzędną w stosunku do obiektów. Cykle stanowią kanwę, na której analizuje się system informacyjny. Obiekty są wynikiem tej analizy jako nośniki modeli, zaś analiza rozpoczyna się od określenia cykli realizowanych przez poszczególne podmioty korzystające z danego systemu.
W praktyce system informacyjny jest realizowany za pomocą określonych środków technicznych. Dla systemu informacyjnego realizowanego za pomocą komputerów przyjęto określenie "system informatyczny". Wobec tego system informatyczny można określić jako techniczną realizację wybranego fragmentu systemu informacyjnego, którego zadaniem może być np. wspomaganie procesu decyzyjnego poprzez odpowiednie przetwarzanie danych.
Struktura cyklu informacyjnego jest niezależna od rodzaju podejmowanych decyzji. Własność ta może być wykorzystana przy automatyzacji projektowania systemów informatycznych. Konkretny system informatyczny powstawałby na podstawie specyfikacji opisujących przyjęte w wyniku analizy cykle informacyjne, etapy przetwarzania w tych cyklach oraz modele i ich atrybuty. Podstawową korzyścią z takiego podejścia byłaby możliwość realizowania działania systemu informatycznego na podstawie tej specyfikacji za pomocą uniwersalnego programu do interpretacji cykli informacyjnych. Program taki odtwarzałby funkcjonowanie systemu informatycznego na podstawie opisu cykli. W efekcie praca nad systemem informatycznym sprowadzałaby się do wykonania analizy systemu informacyjnego.
Tworzenie opisu systemu informacyjnego z wykorzystaniem koncepcji cyklu informacyjnego polega na realizacji następujących kroków:
1) określenie użytkowników systemu,
2) określenie zdarzeń, na które reaguje system,
3) określenie cykli informacyjnych w systemie,
4) określenie modeli występujących na poszczególnych etapach cykli,
5) określenie funkcji przetwarzania modeli na poszczególnych etapach cykli.
Po sprawdzeniu poprawności opisu, system informatyczny byłby gotowy do pracy. Opis podmiotów, cykli i etapów można będzie zmieniać w trakcie użytkowania systemu. System od początku powstania byłby systemem rozwijającym się. Rozbudowa systemu polegałaby na zdefiniowaniu nowego podmiotu, cykli związanych z tym podmiotem oraz klas obiektów obsługiwanych na etapach zdefiniowanych cykli.
ZAKOŃCZENIE
W stosowanych metodach analizy systemu informacyjnego, np. przedsiębiorstwa bierze się zwykle pod uwagę istniejące już dokumenty oraz przepływy danych, które w jakiś sposób wstępnie klasyfikują dane i ułatwiają ich analizę. Tak utworzony system informatyczny zwykle już od chwili swego powstania wymaga modernizacji.
Przedstawiona metoda wraz z odpowiednim oprogramowaniem komputerowym może być wykorzystana do analizy projektowanych jak też istniejących systemów informacyjnych dla potrzeb systemów logistycznych. Wynik analizy stanowi zbiór danych wejściowych uniwersalnego interpretera, który na tej podstawie odtwarza funkcjonowanie systemu informatycznego.
LITERATURA
[1]. Abt S., Woźniak H.: Podstawy logistyki. Gdańsk 1993.
[2]. Adamczewski P.: Zintegrowane pakiety informatyczne wspomagające zarządzanie przedsiębiorstem. Logistyka nr 1/96, s. 20-22.
[3]. Andrews D., DeGiglio M.: IBM's San Francisco Project: Java Building Blocks for Business Application Developers, D.H. Andrews Group, Inc., Internet: www.dhagroup.com, 1997.
[4]. Bertalanfy L.: Ogólna teoria systemów, PWN Warszawa 1984.
[5]. Coad P., Yourdon E.: Analiza obiektowa. READ ME Warszawa 1994.
[6]. Kliszewski M.: Inżynieria oprogramowania obiektowego - Analiza obiektowa. RESPEKT Warszawa 1994.
[7]. Okulewicz J.: Cykl informacyjny w systemie informatycznym zarządzania. w: Sztuczna inteligencja w zarządzaniu. Instytut Badań Systemowych PAN, Warszawa 1990, mat.konf. ss.161-167.
[8]. Taylor D.A.: Technika obiektowa. HELION Warszawa 1994.
9