Rola integracyjnych tendencji architektury systemu w zmianach typologii Systemów Informatycznych Zarządzania

Witold Chmielarz

Warszawa 1998

Prof. dr hab. Witold Chmielarz

Wydział Zarządzania

Uniwersytetu Warszawskiego

Rola integracyjnych tendencji architektury systemu w zmianach typologii Systemów Informatycznych Zarządzania

1. Wstęp

Zasadniczym celem niniejszej pracy jest analiza wpływu procesów integracyjnych w architekturze systemów informatycznych wspomagających zarządzanie przedsięwzięciami gospodarczymi na typologię systemów.

Opracowanie dotyczy sformułowania nowej metodologii klasyfikacji systemów informatycznych wspomagających zarządzanie organizacji gospodarczych na tle zachodzących procesów integracyjnych w rozwoju architektury systemów.

W prezentowanej rozprawie przedstawiono wnioski z obserwacji - w tym uczestniczącej - tendencji rozwojowych kreacji i sprzedaży systemów informatycznych w kraju i za granicą.

Z powyższych sformułowań wynika, że na zmiany typologiczne, przedstawione zostanie spojrzenie poprzez pryzmat wymuszeń spowodowanych trzema niejako „naturalnymi” paradygmatami organizacji:

1. Dążenia do klasyfikacji rzeczy wszelakich - typologia jest pierwszym krokiem w kierunku klasyfikacji - „...wiem, że podział ten nie jest całkowicie rozłączny i kompleksowy, ale dla stworzenia takiego podziału muszę sobie rzeczywistość lub jej odwzorowanie modelowe jakoś początkowo uporządkować...”.

2. Dążenia do integracji organizacji poprzez:

• skupienie funkcji i procesów (eliminacja lub przesunięcie na zewnątrz procesów drugorzędnych - outsourcing),

• skupienie obiegu materialnego i finansowego (obieg finansowy stanowi nadbudowę nad obiegiem materialnym),

• skupienie władzy (zmniejszenie ilości poziomów decyzyjnych (reengineering) i stanowisk decyzyjnych).

W Polsce lat osiemdziesiątych i początku lat dziewięćdziesiątych dezintegracja systemów wspomagających zarządzania była wymuszona możliwościami infrastrukturalnymi (np. ograniczenia w sprowadzaniu nowych technologii informatycznych). Po usunięciu tych przeszkód, w trakcie rozwoju gospodarczego, integracja staje się konieczna ponieważ musi spełniać podstawowe standardy nowoczesnych systemów informatycznych wspomagających zarządzanie, w szczególności systemów klasy MRP II.

Według pierwszego i drugiego paradygmatu dotychczasowe typologie - oparte na kryteriach funkcjonalności systemu lub jego elementów strukturalnych - nie mają dalszego prawa bytu. W praktyce zarządzania systemy wspomagające zarządzanie całością organizacji firmy nigdy nie występowały w „czystej” klasyfikacyjnie postaci - a zawsze jako konglomerat różnych rodzajów systemów - niekiedy nawet nie połączonych w jedną całość. Przyczyną tego stanu rzeczy był trzeci z „naturalnych” paradygmatów.

3. Dążenia do różnorodności - obejmujące zarówno działanie czynników probabilistycznych jak i rozwój techniczny, wyjątkowo szybki w tej dziedzinie działalności.

1. Integracyjne tendencje rozwoju architektury systemów

Architektura systemu komputerowego definiuje sposób w jaki jego komponenty, zarówno software'owe jak i hardware'owe, są zorganizowane i połączone wzajemnie. Z pragmatycznego punktu widzenia powinno to być takie uporządkowanie, które wszystkie zasoby systemu czyni jak najbardziej dostępnymi. Będzie to zapewnione jedynie wtedy kiedy proces scalania wszystkich elementów systemów będzie nosił znamiona procesu integracyjnego.

Spotyka się też wąską definicję architektury systemu sprowadzającą się do określenia elementów systemu i relacji pomiędzy nimi jedynie na poziomie sprzętu i oprogramowania operacyjnego oraz narzędziowego. Takie podejście jest jednak coraz rzadziej wykorzystywane.

Integracja jest kompleksem przedsięwzięć sprawiających, że różne funkcjonalnie oraz typologicznie systemy, podsystemy i aplikacje, działające w niekiedy w różnych płaszczyznach lub na różnych maszynach będą ściśle współpracowały ze sobą. Żywiołowy rozwój informatyki sprawił, że integracja musiała przybrać różne formy dostosowując się do różnorodnych sytuacji występujących w trakcie informatyzacji przedsiębiorstw.

1. Rodzaje integracji

Każda integracja - polega na połączeniu elementów składowych za pomocą wzajemnych relacji tak by zapewniały określone funkcjonowanie zdefiniowanej strukturalnie całości.

Z tego punktu widzenia, w trakcie budowy i użytkowania systemów informatycznych rozróżniamy integrację:

1. Projektową - oznaczającą przyjęcie w projekcie ujednoliconych norm, kodów, haseł, klasyfikacji, nazw dokumentów w celu pełnej unifikacji założeń analitycznych i projektowych tworzonego systemu. Przyjęcie jednakowych parametrów na początku procesu generacji systemu pozwala mieć nadzieję, że w miarę jego rozbudowy normy te zostaną zachowane. Szczególna rola przypada w tym kierownikowi projektu lub głównemu projektantowi systemu. Jeżeli realizuje on złożony projekt i w związku z tym współpracuje z grupą analityków i projektantów (zwłaszcza gdy zespół projektowy jest mieszany - część osób pochodzi z informatyzowanej firmy) powinien skłonić ich do przestrzegania przyjętych założeń i kontrolować ich wykonanie. Bardzo często zdarza się, że indywidualizm poszczególnych członków zespołu przeważa nad zdaniem szefa projektu, co niekiedy doprowadza do wielkich kłopotów w ostatnim etapie realizacji lub nawet końcowego „rozsypania” systemu. W obecnym etapie rozwoju informatyki rolę „integratora” systemu przejmują częściowo narzędzia wspomagające proces projektowania (typu CASE). Prowadzi to do następnego rodzaju integracji.

2. Techniczną - polegającą na stosowaniu dla potrzeb systemu komputerowego współpracującego ze sobą sprzętu i oprogramowania (spójność zapewniona dzięki specyficznemu oprogramowaniu, zabiegom programistycznym lub platformie przetwarzania - mechanizmom wbudowanym oprogramowania). Wszyscy członkowie zespołu projektowego tworzącego dany system posługują się takim samym sprzętem i oprogramowaniem z wbudowanymi mechanizmami narzucającymi jednolite specyfikacje projektowe (struktura bazy danych, mechanizmy i formularze wejścia oraz wyjścia, mechanizmy i formy algorytmów przetwarzania) oraz programowe (chyba, że mechanizmy te wymagają uzupełniania za pomocą wbudowywania zewnętrznych fragmentów oprogramowania). Ten rodzaj integracji jest bardzo skuteczny, lecz niestety poziom rozwoju oprogramowania nie pozwala wykorzystywać go do budowy systemów bardzo dużych i złożonych. Ponadto ze względu na używane narzędzia (i wysokiej klasy specjalistów je obsługujących) jest to metoda bardzo kosztowna.

3. Organizacyjną - zasadniczo sprowadzająca się do reorganizacji jednostki organizacyjnej pod kątem optymalizacji przetwarzania informacji wewnętrznej i zewnętrznej, co oznacza koordynację funkcji (procesów) i celów poszczególnych szczebli systemu informatycznego, kanałów przesyłania oraz identyfikację źródeł informacji. Tego typu integracja może być wynikiem lub przyczyną procesów informatyzacji firmy. W wyjątkowych przypadkach stosowana jest zamiast informatyzacji. Jest to więc na ogół kompleks przedsięwzięć głównie o charakterze organizacyjnym zmieniających częściowo lub zasadniczo zarządzanie organizacją. Pierwszy przypadek występuje wtedy, gdy w wyniku analizy dokonuje się przekształceń organizacyjnych, które same w sobie powodują podniesienie sprawności i efektywności firmy, a informatyzacja nie jest koniecznym elementem tych przekształceń lub została już wcześniej w zadowalającym stopniu przeprowadzona. Drugi - gdy przekształcenie organizacji dokonywane jest „pod” informatyzację lub stanowi ona niezbędny element przekształceń organizacyjnych warunkujących jej działanie. W krańcowym przypadku proces zmian organizacyjnych przybiera postać reengineeringu.

4. Konstrukcyjno-technologiczną - będąca skojarzeniem poprzednich trzech klasyfikacji - zakładającą już we wczesnych etapach analizy organizacyjno-informacyjnej i tworzenia koncepcji systemu dokonanie zmian restrukturyzacyjnych w organizacji gospodarczej i przyjęcie jednolitych założeń dotyczących informacji (np. struktura organizacji i jej funkcje, dane dokumentacyjne i ich format, struktura bazy danych), kodyfikacji, algorytmów, interfejsów, systemu operacyjnego, konfiguracji sprzętowej, konfiguracji i protokółów sieci itp.). W późniejszej fazie polega na koordynacji bieżących przedsięwzięć projektowo-programistycznych z wymaganiami użytkownika. Likwiduje to jednocześnie ograniczenia związane z wielkością firmy jakie występowały przy integracji technologicznej, psychologiczne - występujące podczas integracji organizacyjnej, czy problemy zarządzania projektem - objawiające się w trakcie integracji projektowej.

Za integrację w systemach informatycznych będziemy więc uważali raczej taki system, który stanowi jedno narzędzie wspomagające podejmowanie decyzji niż zbiór odrębnych, niezależnych urządzeń technicznych, pracującego na nich oprogramowania i narzędzi komunikacji występujących w jednej organizacji. Organizacja traktowana tylko jako miejsce występowania nie integruje samoistnie systemu informatycznego, chociaż jak stwierdzono poprzednio istnieją wtedy podstawy do wystąpienia czynników integracyjnych w procesie informatyzacji czy reinformatyzacji.

2. Płaszczyzny integracji

Integracja w systemach informatycznych zaistnieć może w dwóch podejściach:

1. Technologicznym,

1. Funkcjonalnym (procesowym).

Integracja technologiczna polega na kompleksowym połączeniu elementów systemu w płaszczyźnie sprzętowej lub oprogramowania narzędziowego, zgodnie z określonymi wymogami integracji funkcjonalnej (procesowej). Integracja software'owa jest przy tym zdominowana wielkością zakresu integracji sprzętowej. W związku z tym wyróżnia się w nim integrację poprzez:

• dostęp - gdzie narzędzia i programy aplikacyjne mają do siebie dojście w płaszczyźnie sprzętowej (jednoprocesorowe, wieloprocesorowe, sieci),

• osadzanie - integracja na płaszczyźnie software'owej - konkretne programy są częściami większych systemów.

Integrację technologiczną przedstawiono na rys. 1.

Rys.1. Główne podejścia do integracji technologicznej

Źródło: na podstawie Fig.18.1. E. Turban: Decision Support and Expert Systems. Management Support Systems, Macmillan Publishing Company, New York, 1993, str. 722.

Zgodnie z podejściem „poprzez dostęp” narzędzia i programy aplikacyjne mają ze sobą łączność na bazie konfiguracji sprzętowej. Łączność ta może być realizowana w trzech typach konfiguracji:

• jednoprocesorowej,

• wieloprocesorowej,

• sieciowej.

Najbardziej prostym i najbardziej rozpowszechnionym podejściem jest tutaj wariant jednoprocesorowy. W podejściu tym programy i aplikacje są wywoływane tradycyjnie z pamięci komputera lub z pakietów oprogramowania opartych na tym samym procesorze. Przykładem takiej integracji mogą być PROLOG czy LISP działające na pojedynczym procesorze wraz z językami konwencjonalnymi. Podejście takie nie jest specjalnie drogie i pozwala w wysokim stopniu wykorzystać możliwości danego procesora ale jednocześnie nie daje tak dużo możliwości jak dwa następne podejścia.

Wieloprocesorowość oznacza, że różne oprogramowanie działa i współdziała, komunikując się ze sobą na różnych procesorach tej samej maszyny. Prowadzi to np. do wprowadzania danych pod systemem UNIX, a reprezentacji danych i analiz pod LISP. Podejście to daje większą elastyczność działania niż poprzednie, pozwala także na szybsze przetwarzanie złożonych zadań.

Systemy sieciowe są potrzebne w sytuacji gdy programy i aplikacje rezydują na kompletnie różnych maszynach lecz mogą ze sobą współdziałać. Bazują one na środkach i narzędziach komunikacji pomiędzy różnymi procesorami, które to umożliwiają przesyłanie danych niezbędnych do tej współpracy. Ponadto integracja sieciowa polega również na zapewnieniu łączności z odległymi systemami, uruchamianiu na nich różnych procesów i wymianie informacji (np. TCP, Ethernet, Internet Protocol, SNA itp.).

Podejście „poprzez osadzenie” oznacza, że konkretne programy są częściami większych systemów. Może to np. oznaczać połączenie w jedno narzędzie software'owe: edytora tekstów, arkusza kalkulacyjnego, systemu zarządzania bazą danych, narzędzi tworzenia grafiki, narzędzi zdalnej komunikacji, wielofunkcyjnego kalkulatora itp. Wszystkie te programy mogą w pełni korzystać z efektów działania pozostałych programów. Przykładem takich procesów integracyjnych są np. systemy automatyzacji pracy biura.

Z dwoma ostatnimi przypadkami wiąże się podział na systemy zintegrowane w sposób:

• zwarty,

• luźny.

Z integracją „zwartą” mamy do czynienia przeważnie dla systemów zintegrowanych przez osadzenie. Poszczególne elementy systemu są wówczas bardzo ściśle powiązane. Standardowe procedury osadzania (współpracy) oraz wymiana danych są realizowane za pomocą funkcji przywołania będących integralną częścią danego systemu. Użytkownik końcowy widzi system jako jedną, nierozdzielną całość (patrz Rys.2.).

Rys. 2. Architektura integracji „zwartej” systemu eksperckiego i systemu bazy danych

Integracja „luźna” występuje wtedy, gdy dwa lub więcej niezależnych systemów komunikuje się głównie poprzez połączenia komunikacyjne (przypadek integracji przez dostęp; sieciowej). Zewnętrzne wobec każdego z systemów aplikacje użytkowe są uruchamiane poprzez funkcje przywołania systemu operacyjnego. Dane wymieniane są za pośrednictwem zbiorów komunikacyjnych, o ustalonej strukturze. Użytkownik nadal postrzega odrębność połączonych systemów. System dostępu do systemów jest na ogół luźno skojarzony (patrz rys.3).

Rys.3. Architektura integracji „luźnej” systemu eksperckiego i systemu bazy danych

Niezależnie od ilości procesorów i przyjętej topologii sieci w integracji technologicznej możemy wyróżnić trzy podstawowe poziomy, na których systemy i aplikacje mogą ze sobą współpracować:

1. Fasadowy - niezależne, indywidualne systemy w tej samej organizacji wyglądają podobnie (standardowy wygląd formatek ekranowych, raportów, menu, systemu zapytań, systemu pomocy itp.) oraz funkcjonują według podobnych zasad (analogiczny sposób obsługi), wymiana i ładowanie danych dokonywana jest w sposób manualny. Wymaga to uzgodnienia wstępnego co najmniej struktur danych lub zbiorów pośredniczących.

2. Scentralizowany - istnieje centralna baza danych, z której wiele systemów pobiera dane dla swojego funkcjonowania.

3. Kompensacyjny - automatyczna wymiana danych pomiędzy aplikacjami i systemami, taka by wyrównywała braki w informacji na danym stanowisku roboczym (w danym systemie) w momencie ich pojawienia się.

Osiągnięcie wyższego poziomu integracji zapewnia wyższy stopień doskonałości technologicznej i organizacyjnej.

Integracja funkcjonalna oznacza, że różne funkcje są realizowane w taki sposób, jak byłyby wykonywane w jednym, pojedynczym systemie. W ten sposób z jednego terminala (stacji roboczej) mamy teoretycznie i praktycznie (o ile jesteśmy upoważnieni) dostęp do wszystkich funkcji istniejących w systemie poprzez jeden spójny interfejs i możliwość przełączania się pomiędzy różnymi zadaniami. W systemach obsługi biurowej oznacza to np. że pracując z pocztą elektroniczną i używając arkusza kalkulacyjnego komunikujemy się z zewnętrzną bazą danych, tworzymy jej graficzną reprezentację, zachowujemy ją i następnie modyfikujemy. W systemach klasy MRP II oznacza to dostęp do dowolnego systemu funkcyjnego oraz wszelkie możliwości współdziałania z poziomu tego systemu z innymi narzędziami zawartymi w systemie. Abstrahuje się tu jednocześnie od technologicznych aspektów integracji.

3. Zmiany gospodarcze, a tendencje integracyjne

W związku z szybkimi, a często i skokowymi, ilościowymi oraz strukturalnymi zmianami w gospodarce sprowadzającymi się głównie do:

• procesu prywatyzacji przedsiębiorstw lub upadku przedsiębiorstw nierentownych,

• rosnącej (pomimo, że chronionej barierami celnymi, kontyngentami i koncesjami) konkurencji na rynku (wewnętrznej i zewnętrznej),

• włączaniem w regionalne, międzynarodowe struktury (rynki) gospodarcze;

rodzi się konieczność sprostania nowym, a często sprzecznym wyzwaniom rynku:

• zaspokojeniu oczekiwań klientów (minimalizacja ceny, maksymalizacja użyteczności) i „właścicieli” (minimalizacja kosztów),

• tworzeniu zysku versus zaspokojeniu potrzeb konsumpcyjne,

• inwestowaniu w badania i rozwój versus rozszerzeniu bieżącej produkcji.

Aby podołać tym wyzwaniom, na poziomie firmy niezbędne są następujące rodzaje integracji gospodarczej:

• danych i procesów - na wszystkich szczeblach zarządzania: kierowniczym, operacyjnym i wykonawczym

• obszarów funkcjonalnych firmy - na wszystkich etapach jej tworzenia i rozwoju: projektowym, inwestycyjnym, eksploatacyjnym,

• węzłów decyzyjnych - w ramach firmy nie mogą być podejmowane sprzeczne decyzje wykonawcze.

Integracja gospodarcza jest naturalną konsekwencją integracji procesów zarządzania przedsiębiorstwem, poprzez:

• analizę dochodowości - tworzenie i porównywanie planów przychodów i planów sprzedaży,

• planowanie produkcji i sprzedaży,

• planowanie potrzeb materiałowych (analiza popytu, harmonogramy, plany zaopatrzenia),

• analizy zgodności procesów (wydatki-dochody, zaopatrzenie-produkcja, zbyt-popyt, itp.).

Procesy zachodzą zarówno w czasie - systemy musza uwzględniać aspekt dynamiki - i w przestrzeni - współdziałając wewnętrznie w ramach jednej firmy oraz zewnętrznie z całym otoczeniem gospodarczym.

Aby integrować procesy trzeba je wydzielić, zdefiniować i przekształcić tzn. wydzielić zespół:

• procesów głównych - obejmujących:

• rozwój produktów i usług,

• dystrybucję produktów i usług,

• planowanie dziedzin działalności, planowanie zleceń,

• kontakty z klientami itp.

• procesów pomocniczych

• personel,

• finanse,

• administracja.

4. Integracja z punktu widzenia architektury systemów

Integracji od strony architektury rozwiązań informatycznych podlegają więc:

• przepływy informacyjne,

• procesy,

• dane,

co rodzi nowe wymagania wobec powstających systemów informatycznych - przede wszystkim - co do szeroko pojętej ich:

• kompleksowości,

• otwartości,

• elastyczności.

Współczesne systemy informatyczne powinny:

• zapewniać dostarczenie funkcji wspierających obsługę zintegrowanych procesów zachodzących w przedsiębiorstwie - zarówno głównych jak i pomocniczych,

• umożliwiać symulację procesów - zarówno statyczną i dynamiczną,

• zabezpieczać łączność wzajemną pomiędzy wszystkimi elementami systemu przedsiębiorstwa oraz włączenie tych elementów w otoczenie gospodarcze.

Do tego obrazu nie pasują ukształtowane na początku lat 90-tych i funkcjonujące po dziś dzień typologie systemów informatycznych zarządzania, narzucające pewien skwantyfikowany obraz rzeczywistości, co skłania decydentów i dystrybutorów systemów informatycznych do zamawiania i wdrażania standardowych systemów cząstkowych, nie wykorzystujących potencjalnych możliwości tkwiących w reorganizowanej organizacji.

5. Czynniki wpływu integracji architektury na efektywność i wydajność wykorzystania systemu

Ocena integracji systemów informatycznych powinna dotyczyć dwóch podstawowych przypadków. Jeden z nich to przypadek jednostronnie pojętej integracji niskiego rzędu - taki w którym ocenia się system jedynie przez pryzmat przepływu informacji, zastosowanego hardware'u oraz kanałów komunikacyjnych. Drugi to przypadek integracji wysokiego rzędu w której oprócz powyżej zarysowanych założeń rozpatruje się dodatkowo tendencje integracyjne w ramach zastosowanych systemów informatycznych.

5.1. Integracja niskiego rzędu

Efektywność i wydajność architektury czy platformy systemu przetwarzania powinna być oceniana w relacji do procesu podejmowania decyzji, który jest przez niego wspomagany. Ocena przedsięwzięcia informatycznego polega na oszacowaniu alternatywnych konfiguracji komputerowych w sytuacji ustalonych wcześniej założeń i specyfikacji systemu.

Uproszczone modele oceny traktują systemy informatyczne jako zbiór posadowionych danych, kanałów komunikacyjnych i procesorów. Organizacyjne rozmieszczenie tych elementów może przebiegać zarówno w płaszczyźnie hierarchicznej jak i poziomej.

Także same procesory mogą być sprzężone w mniej lub bardziej ścisły sposób. Architektura systemu zawiera więc zarówno zbiór powiązań pomiędzy samymi elementami jak i charakterystykę możliwości każdego elementu.

Istnieje wiele różnych modeli oceny stopnia integracji systemu. Modele takie zawierają określenie modularności procesów, paralelizmu pomiędzy modułami oraz stopnia komunikacji interprocesorowej. Ogólnie rzecz ujmując służą one jednemu: takiemu doborowi konfiguracji sprzętu i oprogramowania, które zapewni optymalną obsługę ustalonych wymagań systemu informatycznego.

Wykonanie systemu informatycznego czy też sieci może być optymalizowana przez dopasowanie architektury systemu do typu procesu, który system powinien wspomagać. Tak więc im lepiej wymagania aplikacji są zdefiniowane tym dokładniej może być określona architektura systemu.

Biorąc pod uwagę trzy podstawowe, zdefiniowane wcześniej elementy architektury systemu:

• Organizacja danych - w ramach „zwartej” architektury systemów wspólnie użytkowane dane korespondują z obszarami pamięci. W architekturze „luźnej” - każdy procesor ma swoją własną pamięć (file serwery),

• Kanały komunikacyjne - z odpowiednimi pasmami i akceptowalnymi szybkościami transmisji,

• Procesory - w sensie połączonych ze sobą komputerów,

możemy stworzyć trzy uproszczone modele architektury zintegrowanej.

Pierwszy składa się z „luźno” połączonych ze sobą w sposób poziomy równoważnych komputerów, dysponujących własnymi, lokalnymi zasobami danych. W momencie gdy jeden z komputerów zdobywa kontrolę nad innymi organizacja przetwarzania może nabrać charakteru hierarchicznego. Jest to standardowa organizacja typowa dla autonomicznych mikrokomputerów działających w ramach sieci LAN.

Komputer

Rys.5. „Luźna” architektura pozioma

Drugi - dotyczy „zwartej” organizacji o wysokim stopniu komunikacji interprocesorowej. Hierarchiczne związki pomiędzy komputerami są tu niezbędne dla zapewnienia koordynacji przetwarzania, chyba że mechanizmy kontroli są już zawarte w ramach oprogramowania komunikacyjnego. Modele takie są na ogół najbardziej efektywne dla sieci inteligentnych stacji roboczych z pojedynczym file-serwerem.

Komputer

Rys.6. „Zwarta” architektura hierarchiczna

Komputer

Rys.7. „Luźna” architektura pozioma z hierarchiczną integracją

Trzeci - pokazuje „luźno” powiązaną poziomo organizację, która zawiera również pewne hierarchiczne związki we wspólnych obszarach pamięci pomocniczej. Kombinacja ta może być używana w sieciach LAN składających się z autonomicznych mikrokomputerów współpracujących z file-serwerem.

Pierwszym krokiem w kierunku ustalenia architektury systemu jest zrozumienie procesu, który system ma obsługiwać. Dla prawidłowego zrozumienia procesu należy zaś określić jego:

• modularność - rozumianą jako zakres w którym dany proces może być dzielony na poszczególne cząstki (stopień granulacji procesu),

• paralelizm - odpowiadający relacjom czasowym (równoległość zachodzenia procesów) i potencjalnej współbieżności obsługi modułów,

• stopień komunikacji pomiędzy procesami - odpowiadający ilości procesów podrzędnych wpływających na proces bieżący poprzez wejścia systemu.

5.2. Integracja wysokiego rzędu

Najbardziej całościowo ujmuje ten problem Spraque R.. Na problem integracji patrzy on z punktu widzenia rozwoju technik przetwarzania danych oraz rozwoju technik modelowania, wpływających na podstawowe elementy systemów wspomagania. Powstanie systemów zintegrowanych jest w tym kontekście naturalną niejako konsekwencją spotkania się ze sobą zapotrzebowania na określone charakterystyki tworzonych zbiorów danych oraz zmian sposobów ich przetwarzania. Trzecim łączącym te tendencje czynnikiem jest według niego powstanie dialogowego systemu interakcji. Proces łączenia procesów przetwarzania danych i rosnącej tendencji do komponowania danych w modele przedstawia on w sposób następujący:

1. Fazy ewolucji przetwarzania danych:

1.1. Pierwotne przetwarzanie danych - TPD - (Transaction Processing Systems) - charakteryzowało się wykorzystaniem komputera do rozwiązywania pojedynczych zadań, głównie w sposób transakcyjny, gdzie każdy program przetwarzał podporządkowane sobie, własne zbiory. Operowanie na danych było ograniczone do bardzo prostych operacji typu: sortowanie, klasyfikowanie, sumowanie itp. Rezultatem przetworzenia danych były sumarycznie ujęte wyniki, najczęściej w postaci tabelarycznej.

1.2. Systemy zarządzanie zbiorami - SZZ - (Management File Systems) - polegały na wykorzystaniu komputera do przetwarzania zadań zintegrowanych wykonywanymi funkcjami, niekiedy udostępniającymi te same zbiory różnym programom. W etapie tym wysiłki projektantów i twórców systemów koncentrowały się na rozwoju wspólnego oprogramowania dla tworzonych zbiorów i zapewnieniu elementarnych procedur zabezpieczenia oraz integracji danych. Wynikiem przetworzenia danych były tu raporty otrzymywane po każdorazowej sesji pracy komputera (w sposób wsadowy).

1.3. Przetwarzanie baz danych - na tej zasadzie oparto większość SBD - (Management Information Systems). Szczególną cechą tego etapu było oddzielenie danych od programów, które dane te przetwarzały. Najwyższe stadium tej fazy - Systemy Zarządzania Bazą Danych - gwarantowały redukcję oprogramowania niezbędnego dla modyfikacji danych, a także wykorzystywały swoiste „modele” danych odwzorowujących relacje pomiędzy danymi. Rezultatem działania systemu były raporty o z góry zagwarantowanej strukturze.

1.4. Systemy dialogowe oraz generacja raportów - SGR - (Structure Query Language Systems) - były następnym krokiem w rozwoju metod przetwarzania baz danych. Podczas ich konstruowania główny punkt ciężkości został położony na zagadnienie kontaktu z użytkownikiem, zwłaszcza nieprofesjonalnym, zapewniając mu bezpośredni dostęp do zbiorów danych poprzez dialog lub specjalnie konstruowany język użytkownika. Wynikiem przetworzenia danych były tu raporty tworzone na żądanie użytkownika, o kształcie i strukturze, która najbardziej mu odpowiadała.

Generalnie, można powiedzieć, że podejście do baz danych ewoluowało od tradycyjnego przetwarzania danych w kierunku charakteryzującym się:

1. Efektywnym zarządzaniem dużą liczbą danych,

2. Względną niezależnością pomiędzy danymi, a programami, które je wykorzystują,

3. Odseparowaniem fizycznej i logicznej struktury danych oraz oddzielnym działaniem na nich,

4. Wprowadzeniem elastycznego systemu łatwego dostępu do danych dla osób nie będących programistami.

2. Fazy ewolucji modelowania:

2.1. Modele symboliczne - MS - (Symbolic Models) wczesny etap modelowania charakteryzujący się rozwiązywaniem, niekiedy w dużej ilości, zbiorów równań liniowych i nieliniowych.

2.2. Modele obliczeniowe - MO - (Numeric Models) komputery w tym etapie stały się istotne dla modelowania ze względu na potencjalne możliwości redukcji wielkich ilości danych podczas estymacji współczynników równań lub rozwiązywania skomplikowanych układów równań.

2.3. Modele komputerowe - MK - (Computer Models) obejmuje okres, od którego program zamiast służyć głównie do rozwiązania problemu staje się sam modelem. Zmienne komputerowe stają się symbolami, którymi manipuluje się poprzez program (a nie poprzez równania połączone operacjami matematycznymi). To podejście prowadzi do sytuacji, w której problem nie jest w zasadzie rozwiązywany, lecz program jest uruchamiany po to, by obserwować zachowanie modelu w celu rozpoznania modelowanej sytuacji.

2.4. Systemy Baz Modeli - BM - (Model Base Systems) - dla rozwiązania szczególnych, a w pewnym sensie zalgorytmizowanych problemów zaczęto tworzyć takie systemy informatyczne, które ze swej istoty mogły być traktowane jako system modeli. Oprogramowanie zapewniało jedynie wspólny format danych wejściowych, podobne formaty generowanych raportów i zintegrowaną dokumentację, natomiast system taki mógł być wykorzystywany przez każdego użytkownika indywidualnie. Dobrymi przykładami zastosowania Systemów Modeli są ich implementacje statystyczne (SPSS) lub matematyczne (MPX).

2.5. Modele Interakcyjne - MI - (Interactive Models) - gdy komputer stał się bardziej dostępny w trybie „time-sharing” możliwe stało się modelowanie interakcyjne. Mikro- i minikomputery dedykowane bezpośredniemu użytkownikowi zazwyczaj posiadają biblioteki modeli, które mogą być zastosowane do różnego rodzaju analiz. Niestety wspólną cechą tych modeli jest uruchamianie pojedynczych programów, dla których są wymagane na ogół różne pod względem merytoryki i struktury dane wejściowe, ale rzadko kiedy możliwy jest jakikolwiek związek logiczny czy formalny pomiędzy realizowanymi programami.

Zarówno ostatni etap ewolucji przetwarzania danych jak i ostatni etap ewolucji modelowania mają jedną cechę wspólną - następuje konwergencja w punkcie zbliżenia do końcowego, nieprofesjonalnego użytkownika poprzez rozbudowany system dialogowy - SDU - (User Interface System). Jest to podstawowa płaszczyzna, na której mogą i powinny rozwijać się obecnie systemy tej klasy. Koncepcja Spraque'a przedstawiona jest na rys.8.

Rys.8. Ewolucja SIZ ze względu na zmiany sposobu przetwarzania danych i metod modelowania

Źródło: opracowanie własne na podstawie: Spraque R.H..: DSS in Contex, DSS, vol.3, nr 3,1987).

Legenda:

TPD - systemy Przetwarzania Transakcyjnego		MS - modele symboliczne
SZZ - systemy zarządzania zbiorami		MO - modele obliczeniowe
SBD - przetwarzanie baz danych		MK - modele komputerowe
SGR - systemy dialogowe oraz generacja raportów		BM - system baz modeli
SDU - System dialogu z użytkownikiem		MI - modele interakcyjne

2. Architektura systemów i ich integracja w „klasycznej” typologii SIZ

1. Kryteria klasyfikacji systemów

Stworzenie pełnej i rozłącznej klasyfikacji Systemów Informatycznych Zarządzania (Computer-Based Information Systems) nie wydaje się celowe i możliwe. Obecnie jest to pojęcie wysoce złożone obejmujące swym zasięgiem grupy upodobniającego się do siebie, lecz różnego oprogramowania, umiejscowionego w różnym środowisku sprzętowym. Istniejące próby klasyfikacji tych systemów opierają się w zasadzie bądź na strukturze problemów do których są stosowane bądź wg pewnych obszarów funkcjonalnych, które opisują.

W pierwszym przypadku jako podstawowe grupy klasyfikacyjne wyróżniane są problemy ustrukturalizowane, słabo ustrukturalizowane i nieustrukturalizowane, w drugim - takie obszary funkcjonalne jak: finanse, sterowanie produkcją, projektowanie, marketing, zarządzanie czynnikiem ludzkim itp.

Spotyka się również jako kryteria klasyfikacyjne elementy składowe oprogramowania, infrastruktury technicznej i komunikacyjnej systemów (architektura systemów). Obserwacja tych klasyfikacji skłania jednak do powtórzenia konkluzji zawartej w pierwszym zdaniu tego rozdziału - poprawna klasyfikacja SIZ nie została jeszcze stworzona. Największe monografie dotyczące tego zagadnienia przedstawiają poszczególne typy SIZ jako etapy zarysowanego wcześniej rozwoju systemów informatycznych wspomagających zarządzanie i opierają się na podejściach klasycznych - wyróżniających pewne cechy charakterystyczne SIZ w celu porównania ich ze sobą. Z drugiej strony istniejące na rynku systemy wcale nie myślą ułatwiać tego zadania teoretykom. Bardzo rzadko spotkać można system mający cechy tylko i wyłącznie jednej z wyszczególnionych grup klasyfikacyjnych, choćby ze względu na opisywane wcześniej procesy integracyjne. Wygoda użytkownika w posługiwaniu się systemami i ostra konkurencja w dziedzinie oprogramowania sprawiają, że twórcy systemów każdą pojawiającą się na rynku „nowinkę” techniczną lub technologiczną natychmiast włączają do tworzonego przez siebie systemu co powoduje, że systemy coraz mniej różnią się między sobą oraz integrują w sobie coraz więcej cech wspólnych, właściwych całkowicie różnym typom systemów. W aspekcie tym pojęcie Systemu Informatycznego Zarządzania (SIZ) zawiera w sobie pozostałe systemy ponieważ odnosi się do dowolnego systemu informatycznego wspierającego wszystkie (każdy) szczeble zarządzania, tworzonego w dowolnej technologii, w obojętnym dla prawdziwości definicji momencie historycznym. Natomiast Systemy Wspomagające Zarządzanie (SWZ) w szerokim ujęciu traktowane są jako wszelkie systemy pozwalające na cokolwiek więcej niż proste, „jednorazowe” przetworzenie danych, w wąskim - jako zintegrowane systemy wspomagania decyzji, systemy eksperckie i systemy oparte na bazach wiedzy wykorzystywane na średnim i najwyższym szczeblu zarządzania - Systemy Wspomagające Zarządzanie (bliskie pojęciu Management Support Systems).

Zgodna z tym podejściem jest definicja podawane przez E.Turbana traktująca SIZ jako „...formalny system komputerowy dokonujący wyboru, udostępniania i integracji pochodzących z różnych źródeł danych po to, by w odpowiednim czasie dostarczyć informacji niezbędnych do podejmowania decyzji ...”.

2. „Klasyczna” typologia systemów ze względu na architekturę

Przy takim podejściu wśród SIZ na początku lat 90-tych ukształtowała się następująca typologia systemów, gdzie głównym kryterium klasyfikacyjnym była - de facto - architektura systemów:

• Systemy Transakcyjne Przetwarzania Danych - TPD - (Transaction Processing Data Systems-TPS),

Rys.9. Architektura Transakcyjnego Systemu Przetwarzania Danych

• Systemy Informacyjne Zarządzania - SBD - (MIS), na swoim obecnym szczeblu rozwoju utożsamiane z Systemami Zarządzania Relacyjnymi lub Obiektowymi Bazami Danych),

Rys.10. Architektura Systemu Informacyjnego Zarządzania

• Systemy Wspomagania Decyzji - SWD - (DSS),

System Zarządzania Bazą Danych

Rys. 11. Architektura Systemu Wspomagania Decyzji

• 
  Systemy Eksperckie - SE - (ES),

System Zarządzania Bazą Danych

Rys. 12. Architektura Systemu Eksperckiego

• 
  Systemy Informowania Kierownictwa (Executive Information Systems - EIS), utożsamiane niekiedy z Systemami Wspomagania Kierownictwa (Executive Support Systems - ESS), w literaturze polskiej występujące często pod wspólnym akronimem: SIK,

Rys. 13. Architektura Systemu Informowania Kierownictwa

• Systemy Sztucznej Inteligencji - SSI- (Artificial Intelligence Systems) utożsamiane często z Systemami Sieci Neuronowych - SNN - (Artificial Neuron Networks - ANN),

System Zarządzania Bazą Danych

Rys. 14. Architektura Systemu Sztucznej Inteligencji

• Systemy Wspomagania Zarządzania - SWZ - (Management Support Systems -MSS) w literaturze polskiej określanej skrótem SWZ,

Rys. 15. Architektura Systemu Wspomagania Zarządzania

a także, umiejscawiane nieco na uboczu:

• Systemy Automatyzacji Biura -SAB - (OAS),

• Systemy Komputerowego Projektowania (CAD), Systemy Komputerowego Wspomagania Produkcji (CAM), Systemy Komputerowego Wspomagania Inżynierii (CAE).

Wzajemne "zazębianie" się systemów jest przedstawione na rys.16. Dodatkową zaletą tego rysunku jest umiejscowienie na nim osi dotyczących atrybutów wykorzystywanych danych (deterministyczne - stochastyczne) oraz charakter podstawowych wyjść z systemu usytuowanych na osi poziomej - opisowe - analityczno-diagnostyczne.

Rys. 16. Wzajemne relacje systemów informacyjnych zarządzania

Poniższa tabela zawiera zaś podstawową analizę porównawczą opisanych wcześniej systemów ze względu na szczególne, wyróżnione kryteria ich rozwoju. Trzeba też brać pod uwagę fakt, że kryteria te zmieniały się w czasie - stąd pewne pozycje w poniższej tabeli mogą być wraz z rozwojem systemów przyporządkowane innym ich rodzajom niż opisane właśnie w poniższej tabeli.

Tab.1. Podstawowe cechy charakterystyczne SIZ

Kryteria oceny	TPD	SBD	SWD	SE	SIK	SSI
Zastosowanie	Kadry i płace (listy obecności i płac), Gospodarka magazynowa, Fakturowa-nie, Ilościowe zestawienia dotyczące sprzedaży i produkcji	Systemy finansowo-księgowe, Sterowanie produkcją, Sprzedaż i jej krótko-terminowe prognozy, Systemy ostrzegawcze	Prognozowanie średnio-okresowe, Optymalizacja produkcji, Racjonalizacja przewozów, Decyzje inwestycyjne i lokalizacyjne Systemy dystrybucji	Planowa-nie strategiczne, Analizy i diagnozy, Weryfikacje i wariantowania decyzji strategicznych, Systemy wąsko-specjalizowane	Wybór strategicznych decyzji z decyzji dopuszczalnych, Systemy rachunkowości zarządczej i controlingu	Decyzje strategiczne (inwestycyjne) i lokalizacyjne, identyfikacja odchyleń i zaburzeń, Alokacja zasobów, Systemy wąsko specjalizowane
Cel	Przechowywanie i przetwarza-nie pojedynczych zbiorów danych	Organizacja baz danych	Wspomaga-nie decyzji, elastyczność, łatwość komunikacji	Wnioskowanie, transfer wiedzy	Śledzenie, kontrola, planowanie ścieżek dojścia do celu	Wnioskowanie, zdobywa-nie doświadczenia
Baza danych	Specyficzne dla każdej aplikacji, przetwarzane wsadowo, aktualizacja w następnej transakcji	Bazy danych wspólne z interaktywnym dostępem	Systemy Zarządzania Bazami Danych,	Proceduralna i naturalna wiedza, Bazy Wiedzy (procedur, algorytmów)	Dostęp do baz zewnętrznych baz danych i baz przekrojowych w trybie on-line	Wiedza wzorowa-na na naturalnej, nabywana drogą zdobywania doświadczenia drogą uczenia, Bazy Wiedzy
Podejmowa-nie decyzji	Brak lub proste modele decyzyjne	Ustruktu-ralizowane rutynowe procedury rozwiązy-wania problemów z użyciem konwencjo-nalnych narzędzi	Rozwiązywanie problemów słabo-ustrukturali-zowanych, złożonych lub modeli rzeczywistości	System użyty bywa w rozwiązywaniu kompleksowych decyzji nieustru-kturalizowanych	Brak	Używany w podejmowaniu decyzji w środowisku cząstkowej niekompletnej lub nieścisłych informacji
Typ danych	Numeryczne	Numeryczne alfanumerycz-ne	Numeryczne alfanumryczne	Numeryczne alfanumeryczne symboliczne	Numeryczne alfanumeryczne symboliczne	Numeryczne
Rodzaj informacji	Raporty cząstkowe i zbiorcze, informacja operacyjna	Raporty podaży i popytu, raporty wyjątków, struktura-lizacja i hierarchizacja raportów	Informacje wizualizowane odpowiednio do podejmowania specyficznych decyzji	Plany, diagnozy, porady, wyjaśnienia	Dostęp do informacji w dowolnym przekroju, raporty wyjątków, kluczowe wskaźniki rozwojowe	Skojarzenia, diagnozy, porady, wyjaśnienia
Wspierany poziom organizacji	Niższy poziom zarządzania -pracownicy operacyjni	Średni poziom zarządzania	Poziom kierowniczy	Poziom kierowniczy i specjaliści	Tylko najwyższy poziom kadry kierowniczej	Poziom kierowniczy i specjaliści
Przeznaczenie	Zwiększenie szybkości przetwarzania	Wzrost skuteczności i sprawności	Zwiększenie efektywności	Wzrost wydajności i wygody	Oszczędność czasu, zwiększenie sprawności	Usprawnienie procesu zdobywania informacji i wnioskowania

Źródło: na podstawie E. Turban: "Decision Support and Expert Systems", wydanie trzecie, Macmillan Publishing Company, 1993

Interesujące wydaje się tez zestawienie wykorzystania poszczególnych typów systemów do wspomagania poziomów zarządzania. W postaci graficznej ukazano je na rys. 17. W miarę rozwoju systemów informacyjnych zarządzania istnieje obecnie tendencja do "przesuwania" tej obsługi do coraz niższych szczebli hierarchii kierowniczej np. systemy oparte na bazie danych obsługują w tej chwili zdecydowaną większość stanowisk, na których odbywa się proste przetwarzania danych..

Rys.17. Wspieranie poziomów zarządzania przez Systemy Informatyczne Zarządzania

Odzwierciedlenie udziałów systemów informatycznych wspomagających zarządzanie w podejmowaniu decyzji na różnych poziomach organizacji przedstawia natomiast tab. 2.

Tab.2. Zastosowanie SWZ na poziomach organizacji

Poziom organizacji	Horyzont czasowy	Procentowy udział systemów	Możliwości decyzyjne
Wielonarodowa korporacja	20-50 lat	-	?
Holding	10-20 lat	2-5%	Strategia działania
Zrzeszenie	5-10 lat	5-7%	Artykulacja ustalania celów
Dyrektor naczelny	2-5 lat	5-10%	Wybór wśród decyzji dopuszczalnych
Dyrektor departamentu	1-2 lata	10-15%	Restrukturyzacja w ramach zastanych struktur
Kierownicy liniowi	3 mies.-1 rok	15-20%	Różnicowanie ocen na podstawie zmiennych
Poziom sklepu i biura	< 3 mies.	50-70%	Wyrokowanie w ramach określonych struktur

Fazy rozwoju poszczególnych typów systemów w przekroju czasowym przedstawia rys.18.

Rys.18. Etapy rozwoju SIZ (na podstawie: Turban E.: Decision Support ...)

Relacje między podstawowymi systemami informatycznymi zarządzania przedstawia się jako:

• postrzeganie ich przez pryzmat odrębnych technologii informatycznych,

• przeplatanie znaczeniowe i przeplatanie zakresu podejmowania decyzji,

• skłonności do ewolucji i adaptacji, w stosunku do rzeczywistości,

• interakcje i koordynację między systemami w odniesieniu do konkretnej aplikacji.

Zwraca uwagę szczególne umiejscowienie systemów wspomagających pracę biura oraz systemów wspomagających bieżące procesy projektowe i produkcyjne, a także całkowity brak w pokazanym wyodrębnieniu szalenie istotnej płaszczyzny sieciowej. Tym niemniej, już wówczas dostrzegano fakt, że podstawowym kierunkiem rozwoju większości systemów jest ich kompleksowa integracja do postaci tzw. SWZ.

3. Podstawowe elementy systemów informatycznych zarządzania

Ostatnie czterdziestolecie wykształciło istniejącą w chwili obecnej koegzystencję i kooperację różnych systemów informatycznych zarządzania. Formą, do której dąży większość z nich, uzyskiwaną dzięki integracji używanego oprogramowania z jednej strony oraz integracji infrastruktury technicznej z drugiej strony, są systemy wspomagające zarządzanie.

Ponadto, z dotychczasowych rozważań wynika bezpośrednio, że systemy te posiadają wiele cech pożądanych przez użytkowników:

• wspomaganie, a nie zastępowanie decydenta,

• zawieranie rozkazów skojarzonych z elementarnymi i złożonymi zadaniami,

• personalizacja, w kontekście podejmowanego problemu (duża elastyczność),

• zgodność ze stylem podejmowania decyzji.

Według Stair'a R. systemy informatyczne zarządzania powinny spełniać następujące warunki funkcjonalne:

• posiadać elastyczny język programowania pozwalający na kreowanie i modyfikowanie poszczególnych podsystemów dla specyficznych zastosowań,

• mieć architekturę odpowiadającą systemowemu projektowaniu umożliwiającą szybką rozbudowę całego systemu i rozwijanie alternatywnych rozwiązań,

• posiadać interfejs odgradzający użytkownika od komputera i umożliwiający mu dialog w kategoriach zarządzania i formułowania problemów decyzyjnych, komunikatywne urządzenia audiowizualne i generatory danych wyjściowych.

Zgodnie z tymi założeniami Spraque R. wyróżnił w SWZ takie elementy jak:

1. Baza danych,

1. Baza modeli,

1. Kompleksowy system oprogramowania służącego powiązaniu użytkownika z każdym z tych elementów.

Ostatni zbudowany jest z trzech głównych składowych:

• Systemu zarządzania bazą danych,

• Systemu zarządzania bazą modeli,

• Systemu zarządzającego dialogiem z użytkownikiem.

Podobne stanowisko reprezentuje Bodart F., dodając do tych podstawowych elementów funkcje, jakie wg niego, powinny one spełniać. Zgodnie z przyjętą przez niego systematyką struktura systemu informatycznego zarządzania i jego główne elementy to:

System zarządzania i integracji całego systemu:

- zawierający schemat koncepcji systemu,

- ułatwiający użytkownikowi korzystanie z systemu poprzez:

• dostarczenie semantyki danych,

• objaśnianie modeli i ich składowych,

• opis warunków zastosowania poszczególnych modeli,

• zmianę stanu bazy danych czy bazy modeli nawet wbrew pierwotnej specyfikacji (adaptacja).

System Zarządzania Bazą Danych oraz System Analiz Danych pozwalający w szczególności na:

- gromadzenie i uzupełnianie danych ustrukturalizowanych i nieustrukturalizowanych, dynamiczną restrukturyzację schematu bazy danych,

- utrzymywanie spójności procedur Bazy Danych pod kątem:

• wewnętrznej zwartości (w sensie poprawności struktury),

• logiki w stosunku do zbiorów przetwarzanych.

• dowolnego sortowanie i selekcjonowanie danych,

• zwielokrotnienia zbiorów danych w celu sprawdzenia różnych hipotez oraz generowania szeregów danych przykładowych,

- stworzenie zbioru rozkazów manipulacji danymi (głównie w sensie agregacji i dezagregacji),

- umożliwienie dowolnej wizualizacji danych zawartych w bazie danych.

System Zarządzania Bazą Modeli umożliwiający:

- budowanie, gromadzenie, katalogowanie, łączenie i zapewnienie dostępu do modeli,

- łączenie modeli z odpowiednimi, wybranymi danymi, powiązanie modeli między sobą, odwzorowane również zmianami w Bazie Danych i formułowanie tych zmian w formie czytelnej dla użytkownika.

- poszerzenie istniejących modeli oraz łatwe i szybkie tworzenie nowych.

System łączności z użytkownikiem, którego celem jest pozwolenie użytkownikowi na łatwy dialog z systemem, składający się z trzech części:

- to co użytkownik widzi (na różnych urządzeniach we/wy), w postaci:

• dialogów prowadzonych przez np. system menu, instrukcje działania czy na zasadzie - pytanie-odpowiedź,

• wolnego dialogu z użyciem języka rozkazów,

• dialogu z językiem zorientowanym celowo lub problemowo,

- to co może zrobić (język działania użytkownika),

- to co musi wiedzieć (baza wiedzy użytkownika).

Gels M. łączy system wiedzy z systemem łączności z użytkownikiem ograniczając ich działania do trzech funkcji:

• definiowania danych,

• transformacji danych,

• prezentacji danych.

W późniejszych opracowaniach pojawiają się ponadto nieco rozszerzone interpretacje bazy wiedzy oraz jej systemu zarządzania, wplatające do ogólnego schematu systemów informatycznych zarządzania elementy systemów eksperckich i sztucznej inteligencji:

System zarządzania bazą wiedzy i bazę wiedzy przeznaczone do:

- gromadzenia procedur rozwiązywania szczególnie złożonych problemów numerycznych, metod statystycznych, ekonometrycznych, optymalizacji itp. (solwer),

- rejestracji kolejnych przebiegów i wyników działania systemu,

- procedur wyboru dopasowania metody rozwiązania do potrzeb użytkownika,

- współpracy z systemem zarządzania bazy modeli w celu dostosowania struktury modelu do zmieniających się warunków zewnętrznych (przepisy, regulacje) oraz potrzeb użytkownika,

- zapamiętywania wyników uznanych przez użytkownika za optymalne (lub optymalnych) oraz ścieżki dojścia do tych wyników,

- automatycznego reagowania w sytuacjach, które miały już miejsce w przeszłości i przewidywanie prawdopodobnych rozwiązań w sytuacjach niestandardowych.

Po tym uzupełnieniu, schemat typowego informatycznego systemu zarządzania będzie wyglądał tak, jak to przedstawiono wcześniej na rys.14.

Tym niemniej jeżeli charakteryzujemy już ogólne wymagania wynikające z architektury systemów informatycznych zarządzania w stosunku do tworzonych systemów, to należy w nich wyróżnić następujące cechy:

• ewolucyjność,

• możliwość zmiany systemu wraz ze zmianą warunków ograniczających,

• pełna interaktywność w sensie:

• łączności z systemem,

• uczenia się przez system,

• udoskonalenie wiedzy o systemie,

• możliwość przetwarzania metodą prób i błędów,

• interakcyjność rozwiązania problemu.

• „życzliwość” dla użytkownika:

• łatwość nauki i nauczania innych,

• łatwość użycia.

Szczególną rolę w zapewnieniu integralności działań we współczesnych informatycznych systemach zarządzania odegrała baza modeli zawarta w systemach wspomagających podejmowanie decyzji. Dlatego poniżej umieszczoną dodatkową charakterystykę funkcjonowania systemów zarządzania bazą modeli.

Użytkownicy posługujący się komputerami i odpowiednim oprogramowaniem, typu np. arkuszy kalkulacyjnych mogą tworzyć modele odpowiadające swoim celom w sposób natychmiastowy. Cały problem polega jednak na tym, że modele tworzone w taki sposób posiadają pewne ograniczenia narzucane specyfiką rozwiązywanego zagadnienia lub organizacji. W dodatku występują kłopoty z powtarzalnością, zgodnością, integralnością i bezpieczeństwem tworzonych modeli.

Powyższe problemy skłaniają do popierania idei rozwoju scentralizowanego zarządzania modelami na wzór centralnego zarządzania danymi.

System Zarządzania Bazą Modeli - SZBM - jest to oprogramowanie umożliwiające tworzenie, gromadzenie, manipulację i zapewniające dostęp do modeli.

Funkcje gromadzenia umożliwiają prezentację istniejących modeli oraz tworzenie modeli fizycznych i logicznych. Funkcje manipulacji zawierają instalację, selekcję i syntezę modeli. Obydwie te funkcje są porównywalne z funkcjami Systemu Zarządzania Bazą Danych. Znane są różne projekty implementacji składników gromadzenia i manipulacji w SZBM. Zakłada się takie wyobrażenie modelu, w którym są wykorzystywane narzędzia logiki formalnej (założenia wstępne, zasady tworzenia, metody przeszukiwania itp.), sieci semantycznych, teorii strukturalnego i relacyjnego zarządzania danymi. Wady i zalety takiego podejścia ukazuje tab.3.

Tab.3. Wady i zalety wykorzystania komponentów manipulacji modelu

Komponenty	Zalety	Wady
Logika formalna, sformalizowane zasady tworzenia	Rozwinięte funkcje przeszukiwania i selekcji. Największe sukcesy w zastosowaniu systemów klasy sztucznej inteligencji	Niekorzystne dla utrzymywania dużych zbiorów danych i modeli. Następuje strata powiązań relacyjnych
Sieci semantyczne	Rozwinięta klasyfikacja i kategoryzacja. Utrzymywanie relacji pomiędzy problemami, modelami i danymi	Brak bezpośredniego wspomagania wielorakich poziomów logicznych. Słaba obsługa kompleksowych modeli i/lub obszarów decyzyjnych
Składniki strukturalne	Rozwinięta możliwość reprezentowania kompleksowych decyzji i/lub dziedziny. Dopuszcza się wieloraką reprezentację charakterystyk i logiki modelu.	Struktura musi być predefiniowana w kontekście środowiska problemu. Ograniczenia selekcji alternatywnie użytecznych rozwiązań nie określonych w fazie projektu.
Składniki relacyjne	Rozwinięta możliwość integracji danych i modeli. Dobrze rozwinięte funkcje zarządzania i kontroli. Potężny relacyjny język dialogu.	Mniej wygodne w procesie podejmowania decyzji. Trudności w adaptacji technik zarządzania danymi dla gromadzenia modeli, które posiadają bardziej kompleksowe i dynamiczne struktury.

Istnieją dwa zasadnicze cele projektowania SZBM:

• rozszerzenie i wzmocnienie możliwości SWZ przez wprowadzenie płynnych, dynamicznych komponentów do systemu,

• zapewnienie takiej organizacji, która centralizuje funkcje menedżera systemu zapewniające integralność, jednorodność, aktualność bazy modeli.

Wyróżnia się dwie funkcjonalne klasy SZBM:

• Przetwarzanie decyzji - opisujące funkcje organizacyjne całego SWZ. Dostarczają one narzędzi elastycznego, dynamicznego modelowania dla SWZ.

• Przetwarzanie modeli - zapewniające podstawowe funkcje zarządzania i kontroli modelami organizacji w bazie modeli. Te funkcje systemu zapewniają integralność, spójność, aktualność i bezpieczeństwo bazy modeli w sposób podobny jak w Systemach Zarządzania Bazą Danych.

Komponenty manipulacji i przechowywania modeli obu klas mogą być użytkowane bez potrzeby stosowania skomplikowanych schematów logicznych w sytuacjach, gdy decyzje i przestrzeń modelowania są wąskie i relatywnie nieskomplikowane.

Modele mogą być gromadzone w bibliotekach podprogramów algorytmicznych procedur rozwiązań. Gromadzenie procedur decyzyjnych jest często niepotrzebne ze względu na wąski zakres przestrzeni decyzyjnej. Manipulacja modelami i decyzjami może być wykonywana poprzez zastosowanie języka komend.

Na drugim biegunie tworzenia systemu zarządzania bazą modeli znajdują się generatory aplikacji. Podstawowa różnica pomiędzy możliwościami zastosowań scentralizowanej bazy zarządzania modelami a generatorami aplikacji zależy jednak od poziomu abstrakcji, na którym konstruowany jest model całego systemu. Im bardziej konkretne, na niższym szczeblu abstrakcji przeprowadzane zastosowanie systemu i dokładniejsze rozpoznanie przeprowadzone przed wprowadzeniem systemu informatycznego do przedsiębiorstwa tym większą szansę na sukces ma scentralizowany system zarządzania bazą modeli.

System generacji aplikacji stosowany jest jako rozwinięcie systemów bardziej ogólnych, ale o większej przewidywalności - standardzie - zachowań. Wymaga za to większej wiedzy merytorycznej i informatycznej od przyszłego użytkownika systemu o systemie i zasadach tworzenia aplikacji lub większego zaangażowania osoby wdrażającej system do przedsiębiorstwa, która wtedy wykonuje większość prac za przyszłego użytkownika przed wprowadzeniem systemu (sama wprowadza katalogi i tworzy pierwsze aplikacje).

III. Kierunki zmian typologii systemów spowodowane czynnikami integracyjnymi

1. Cechy charakterystyczne architektury zintegrowanej

Na początku lat 90-tych SWZ traktowane były jako najnowszy etap rozwoju informatycznych systemów zarządzania, łączący w sobie dotychczasowe podejścia do tworzenia systemów. Płaszczyzna łączenia może dotyczyć różnych typów systemów, technik modelowych i algorytmicznych, technik organizacyjnych i specjalistycznego dodatkowego wyposażenia itp. Wymagało to pełnej integracji elementów składowych systemu, korzystania ze wspólnej bazy danych i specjalistycznej bazy modeli.

Główne cechy charakterystyczne SWZ spełniały wszelkie postulaty zarysowane we wcześniejszej części tego referatu:

• współpraca ze wszystkimi procesami zachodzącymi w przedsiębiorstwie,

• sprawne i szybkie przesyłanie informacji, ich synchronizacja i monitorowanie oraz sterowanie nimi,

• integracja danych, struktur, modeli,

• dzielenie zasobów,

• łączenie organizacji z otoczeniem,

• samodoskonalenie wynikające z adaptacji do zmieniających się wymagań procesów wewnętrznych i zewnętrznych,

• stopniowe obejmowanie sferą działania wszystkich dziedzin działania organizacji gospodarczej, w której zostaje zaimplementowany.

Podstawowym metodą rozwoju systemów było łączenie różnych typów systemów w jedną całość funkcjonalną (integracja funkcjonalna). Dawało to, oprócz pewnych niedostatków spowodowanych koniecznością komunikowania się pomiędzy niekiedy krańcowo różnymi bazami danych, zaskakująco pozytywne rezultaty. Niektóre z nich przedstawione są poniżej.

2. Zalety łączenia systemów o różnej architekturze

2.1. Systemy zarządzania bazą danych i systemy eksperckie

Systemy eksperckie:

• nadzorują proces zapisu, odzyskiwania i uaktualniania informacji,

• ułatwiają operatorom poprawne zarządzania bazami, szczególnie w przypadku, rozproszonych baz danych,

• optymalizują zapytania i ścieżki poszukiwań oraz ilość przesyłanych danych,

• występują jako inteligentne interfejsy w złożeniach komercyjnych, strukturalnych baz danych.

Systemy baz danych dostarczają informacje dla systemów eksperckich oraz ułatwiają manipulację danymi.

Rys.19. Architektura połączonego Systemu Eksperckiego i Systemu Bazy Danych (Inteligentna Baza Danych);

Na podstawie: E.Turban: Decision Support and Expert Systems. Management Support SystemsMacmillan Publishing Co, NY, 1993.

Rys. 19. Przedstawia przykładową architekturę typowego połączenia systemu eksperckiego z bazą danych. Jest to połączenie bardzo ścisłe - zwraca uwagę występowanie tylko jednego interfejsu użytkowego. Program aplikacyjny może wykorzystywać dane bezpośrednio z bazy danych, jak również może korzystać z danych pobranych z bazy danych a następnie zinterpretowanych przez mechanizmy systemu eksperckiego.

2.2. Systemy eksperckie i systemy wspomagania decyzji

Połączone systemy eksperckie i systemy wspomagania decyzji dają następujące efekty:

• możliwości logicznego wyjaśnienia podejmowanych akcji i uzyskanych wyników - w wypadku dołączenia systemu eksperckiego do elementów systemu wspomagania decyzji,

• szybszego wykonywania operacji, gdy rezultaty działania systemu wspomagania są danymi wejściowymi do systemu eksperckiego,

• poprawnej identyfikacji problemu w sytuacji odwrotnej,

• zwiększenia możliwości wyboru użytkownika - korzystania z systemów dwóch typów sprzężonych bazą danych w zależności od bieżących potrzeb logicznych procesu decyzyjnego,

• generowania rozwiązań wariantowych (systemy wspomagania decyzji) i dołączanie do nich alternatywnych działań, które powinny być podjęte dla ich uzyskania.

W praktyce istnieją różne rodzaje integracji pomiędzy systemami eksperckimi i systemami wspomagania decyzji:

1. System ekspercki jako uzupełniający składnik systemu wspomagania decyzji,

2. System ekspercki jako wydzielony składnik systemu wspomagania decyzji,

3. System ekspercki rozszerzający proces podejmowania decyzji

4. Zunifikowany system ekspercki i system wspomagania.

W pierwszym przypadku system ekspercki uzupełnia działania systemu wspomagania decyzji niemal we wszystkich komponentach architektury jako:

• inteligentny moduł systemu zarządzania bazą danych systemu,

• adaptacyjny i uczący się składnik systemu zarządzania bazą modeli,

• udoskonalony system komunikacji z użytkownikiem (GUI),

• konsultant kreatora systemu,

• konsultant nieprofesjonalnych użytkowników.

Rys.20. System ekspercki jako uzupełnienie systemu wspomagania decyzji

W drugim przypadku system ekspercki jest dodawany zewnętrznie do systemu wspomagania decyzji, przeważnie do modułu zarządzania bazą danych lub zarządzania bazą modeli. Przykład takiego połączenia prezentuje rys. 19. Połączenie takie może funkcjonować w postaci dowolnego interfejsu lub jako zwykłe, sieciowe połączenie komunikacyjne. Możliwe są przynajmniej trzy konfiguracje takiej integracji:

• dane wyjściowe (modele) systemu eksperckiego są czytane przez system wspomagający decyzje,

• dane wyjściowe (modele) systemu wspomagającego decyzje są czytane przez system ekspercki,

• występuje sprzężenie zwrotne pomiędzy przekazywaniem danych i/lub (modeli).

Rys.21. System ekspercki jako oddzielny komponent systemu wspomagania decyzji

Przypadek trzeci jest mutacją poprzedniego - system ekspercki występuje jako dodatkowe wzmocnienie interfejsu użytkownika. W tym podejściu użytkownik komunikuje się z systemem wspomagania decyzji w standardowy sposób korzystając z bazy danych i bazy modeli do momentu zaistnienia potrzeby sformułowania strategii lub uzyskania dodatkowych konsultacji w dotyczących szczegółowych czy szczególnych rozwiązań systemu. Wówczas wywoływany jest system ekspercki (fizycznie zupełnie wydzielony). Pełni on tutaj rolę pomocniczą w sformułowaniu strategii, prawdziwości oceny analiz lub oceny dokładności zakładanych prognoz. Dane czy modele mogą być pobrane z mechanizmów systemu wspomagania decyzji ale już samego doboru, wnioskowania i oceny dokonuje system ekspercki.

Rys. 22. System ekspercki rozszerzający proces podejmowania decyzji w systemie wspomagania decyzji

Ostatni przypadek dotyczy w pełni zintegrowanej architektury systemu wyposażonej ponadto w atrybuty systemu sztucznej inteligencji. W tej sytuacji system ekspercki jest umiejscowiony pomiędzy niejako bazą danych a bazą modeli i przy pomocy bazy wiedzy integrujący ich współdziałanie. Strukturę takiego systemu przedstawia rys. 23.

Rys.23. Zunifikowany system ekspercki z systemem wspomagania decyzji

2.3. Systemy informowania kierownictwa i systemy wspomagania

Podstawową metodą integracji systemów informowania kierownictwa i systemów wspomagania decyzji jest wykorzystywanie przez te ostatnie informacji generowanych przez system informowania kierownictwa jako informacji wejściowych. W bardziej skomplikowanych przypadkach przewiduje się istnienie pętli sprzężenia zwrotnego poprzez specjalny inteligentny interfejs, który ze strony systemu informowania kierownictwa będzie pozwalał na tworzenie zapytań do systemu wspomagania, a w odwrotnym kierunku będzie przesyłał interpretacje i rekomendacje uzyskane od systemu wspomagania. W skrócie można ten proces zawrzeć w dwóch stwierdzeniach:

• dane po wstępnej obróbce w systemie informowania kierownictwa będą użyte jako dane wejściowe do systemów wspomagania decyzji,

• 
  system informowania kierownictwa służy do dalszych interpretacji rozwiązań uzyskanych przy pomocy systemu wspomagania decyzji.

Rys.24. Architektura połączeń pomiędzy systemem informowania kierownictwa i systemem wspomagania decyzji

2.4. Systemy eksperckie i systemy informowania kierownictwa

Wydaje się że, połączenie systemów eksperckich z systemami informowania kierownictwa w praktyce jest stosowane bardzo rzadko. Systemy informowania kierownictwa mogą się zwracać z zapytaniem do systemów eksperckich w kwestii rozwiązania szczególnych, specjalistycznych problemów, którymi te ostatnie się zajmują i w zamian uzyskiwać interpretacje dotyczące rozwiązań. Systemy informowania kierownictwa mogą też odwoływać się do bazy wiedzy lub bazy procedur systemu eksperckiego w sytuacjach gdy ich interfejs użytkowy wyposażony jest w mechanizmy komunikacyjne, które mu na takie działanie pozwalają. Struktura takiego systemu jest pokazana poniżej.

Niekiedy system ekspercki występuje w roli regularnego dostarczyciela sprawozdań (wraz z ich oceną merytoryczną) generowanych na podstawie danych przesyłanych z systemu informowania kierownictwa.

Rys.25. Architektura połączeń pomiędzy systemem informowania kierownictwa i systemem eksperckim

2.5. Systemy informowania kierownictwa i systemy baz danych

Jest to najstarszy i najbardziej niejako naturalny system połączenia dwóch systemów informacyjnych zarządzania. Wykorzystuje w pełni wszystkie mechanizmy bazy danych i jednocześnie czerpie z niej tylko te informacje, które są w danym momencie potrzebne kadrze kierowniczej. Stanowi w ten sposób dodatkowy niezależny interfejs użytkownika na szczeblu kierowniczym. Jego podstawowe cechy charakterystyczne to:

• umożliwienie bieżącego śledzenia zdarzeń zachodzących w firmie i jej otoczeniu (SIK - jako inteligentny interfejs do systemu bazy danych),

• zwrotne zapamiętywanie interpretacji SIK w bazie danych.

Rys.26. Architektura systemu informowania kierownictwa połączonego z systemem bazy danych

2.6. Powiązania pomiędzy systemami tego samego typu - dotyczą głównie systemów eksperckich (wymiana informacji pomiędzy systemami dotyczącymi różnych dziedzin) lub systemów wspomagania decyzji (wzmocnienie funkcji przetwarzania uboższych systemów przez wyspecjalizowane systemy przetwarzające).

3. Budowa systemów uniwersalnych

Obok łączenia systemów, drugą metodą budowania kompleksowych systemów zintegrowanych jest niewątpliwie budowa systemów uniwersalnych, czyli takich, które wspomagają w swoich wersjach standardowych około 90% wymagań przeciętnych użytkowników. Są to wówczas programy olbrzymie objętościowo (około 50 tys. instrukcji) i obejmują maksymalnie możliwy zakres funkcjonalny organizacji. W przypadku systemów mających inklinacje kompleksowe ich zakres funkcjonalny zawiera co najmniej:

• planowanie potrzeb materiałowych,

• planowanie produkcji i sprzedaży (plus marketing),

• harmonogramowanie spływu produkcji finalnej,

• harmonogramowanie scalania produktów i półproduktów w wyrób finalny,

• zarządzanie popytem,

• zarządzanie zleceniami,

• sterowanie transakcjami przepływów materiałowych,

• sterowanie produkcją,

• sterowanie stanowiskiem roboczym,

• planowanie zdolności produkcyjnych,

• zakupy materiałowe,

• planowanie dystrybucji ,

• planowanie i kontrola zakupów narzędziowych,

• zarządzanie finansami i księgowość (lub interfejsy do nich),

• ocena wyników,

• symulacja wariantów produkcyjnych.

Podstawowymi cechami charakterystycznymi takich systemów są więc:

• kompleksowość funkcjonalna - czyli objęcie swoim zasięgiem całości funkcji i procesów zachodzących w organizacji (co nie przeszkadza w praktyce sprzedawać często jedynie części systemu),

• złożoność architektoniczna - z jednej strony stymulowana kompleksowością funkcjonalną (wystarczyłaby sama wielkość systemu!), z drugiej łączeniem różnych rodzajów systemów w jedną całość, wreszcie wykorzystaniem również różnych rodzajów integracji technologicznej,

• względna łatwość obsługi - wszystkie nowinki techniczne są szybko włączane w istniejące systemy lub tworzy się nowe wersje poprzednich systemów różniące się np. bardziej atrakcyjnym interfejsem użytkowym. Powszechny dyktat w rozwiązaniach biurowych systemu Windows stworzył duży nacisk na twórców systemów, w kierunku budowania interfejsu „windowsopodobnego” - czyli takiego, które zapewnia łatwość obsługi przyzwyczajonych do niego użytkowników.

• powszechność użycia - wszystkie firmy, które chcą przetrwać na coraz bardziej zawężającym się i konkurencyjnym rynku szukają ratunku w zmniejszeniu kosztów. Takiego ratunku ma dostarczyć im komputerowy system wspomagający zarządzanie i produkcję. Jeżeli zostanie właściwie zastosowany uzyskane, wysokie efekty powodują wzrost zainteresowania użytą technologią, a co za tym idzie wzrost powszechności używania takich systemów.

Wyposażenie systemów zintegrowanych w moduły analityczne typu eksperckiego, bazy modeli symulacyjnych charakterystyczne dla DSS, moduły wspomagające podejmowanie decyzji typu samouczącego czy adaptującego do zmiennych warunków gospodarczych sprawiło, że obowiązująca poprzednio typologia przestaje być traktowana w sposób „ostry”.

4. Przesłanki zmian typologii SIZ

Z powyższych rozważań wynika jednoznacznie, że przedstawiona uprzednio typologia nie ma szans przerodzić się w klasyfikację (wraz z jej przyrodzonymi atrybutami kompleksowości, rozłączności i niezależności). Na drodze do tego stają przesłanki natury technicznej tzn. bardzo szybki postęp w dziedzinie informatyki oraz społecznej - powszechność użycia środków informatycznych i powstawanie zjawiska „społeczeństwa informacyjnego”. Spotęgowały to również zjawiska:

• organizacyjne (reingeneering, outsourcing, wirtualizacja procesów i organizacji),

• psychologiczno-społeczne (otwartość na świat, integracja struktur państwowych, upodobnienia behawioralne),

• techniczne (rozwój sieci globalnych, wewnętrznych, dokumenty i usługi elektroniczne, powszechna dostępność najnowszych technologii).

Dodatkowymi elementami jest postępująca homogenizacja i standaryzacja:

• struktur społecznych,

• oprogramowania,

• infrastruktury technicznej.

Wszystkie powyższe komponenty powodują postępującą nieprzystawalność dotychczas stosowanej typologii i potrzebę zastąpienia jej nowym podziałem, który uwzględni nowe zjawiska gospodarcze i społeczne. Zauważyć też należy, że w zjawiskach społeczno-gospodarczych często występuje cykliczność - pewien stan zastępowany jest innym - po czym następuje powrót do stanu poprzedniego. Upraszczając rozpatrywane zjawisko można powiedzieć że, systemy informatyczne zarządzania są w fazie przejścia od wysokiej (przedstawionej w poprzednich częściach pracy) różnorodności do - spowodowanego przyczynami integracyjnymi - relacyjnego (zewnętrznego) ujednolicenia. Następuje zastępowanie prostszej strukturalnie, dużej liczby rodzajów systemów poprzez bardzo skomplikowaną wewnętrznie mniejszą ilość. Nie jest wykluczone, że następnym etapem rozwoju typologii systemów informatycznych zarządzania będzie, z kolei, zwiększenie ich różnorodności ale prawdopodobnie na innej płaszczyźnie niż płaszczyzna architektoniczna. Trzecim istotnym powodem zmian dotychczasowej typologii będą prawdopodobnie przyczyny ekonomiczne. Swoiste „mody” na zakup najnowszego generacyjnie oprogramowania, charakteryzującego się najnowszymi parametrami użytkowymi, sprawią że, użytkownik będzie kupował tylko te systemy, które z założenia będą systemami zintegrowanymi, eksperckimi, sieciowymi albo będą spełniały wszystkie te trzy założenia na raz.

IV. Proponowany podział SIZ ze względu na przemiany architektoniczne.

W ciągu ostatnich kilku lat przemiany architektoniczne, wywołane głównie poprzez zjawiska integracyjne posunęły się tak dalece, że trudno jest mówić o istnieniu jakiegokolwiek systemu w „czystej” wyabstrahowanej z naleciałości innych systemów i wpływów otoczenia postaci. Wydaje się, że można jedynie mówić o systemach, w których nastąpiła silna dominacja jednego z typów integracji. Na tej podstawie najwyraźniej można wyszczególnić systemy o przewadze:

• integracji funkcjonalnej - zintegrowane systemy zarządzania,

• integracji technologicznej przez osadzanie, zwartej - pakiety biurowe,

• integracji technologicznej przez dostęp, wieloprocesorowej - specjalizowane systemy eksperckie,

• integracji technologicznej przez dostęp sieciowej - systemy telekomunikacyjne.

Powoduje to wyodrębnienie w miejsce poprzednio przedstawionej typologii trzech głównych grup systemów informatycznych wspomagających zarządzanie:

• zintegrowanych systemów wspomagających zarządzanie:

• przedsiębiorstwem - typu MSS, w najbardziej rozwiniętej formie reprezentowanej przez systemy MRP II (np. SAP, BAAN, IFS, ICL itp.),

• zintegrowane pakiety obsługi biura (np. Microsoft Office, Lotus Smart Suite, itp.),

• specjalistyczne systemy eksperckie oparte o metody statystyczno-ekonometryczne oraz heurystyczne coraz częściej wykorzystujące technologię sieci neuronowych i sztucznej inteligencji,

• systemy telekomunikacyjne - oparte na rozwoju technik sieciowych.

1. Zintegrowane systemy wspomagające zarządzanie

Przedstawiona uprzednio tendencja w rozwoju systemów - czyli tworzenie jednolitych, zintegrowanych systemów zarządzania - nie oznacza całkowitego zarzucenia pierwszej z omówionych dróg integracji - czyli integracji na poziomie kooperujących ze sobą aplikacji. Konieczność dostosowania systemu do potrzeb użytkownika, a także niewystarczające standardowe możliwości przystosowania systemu zintegrowanego dla wielu różnych użytkowników sprawiają, że potrzebna jest integracja na poziomie poszczególnych aplikacji.

Takie tworzenie kooperujących ze sobą aplikacji może być w pewnych warunkach:

• bardziej wydajne niż tworzenie systemu całościowego (szybsze w budowie i poprawianiu),

• eliminować do końca ręczną obróbkę informacji,

• posiadać większą funkcjonalność niż prosta suma funkcjonalności składowych aplikacji.

Możliwe są tu różne scenariusze integracji kooperujących aplikacji:

• integracja aplikacji już istniejących,

• budowa nowych integrowanych z istniejącymi,

• tworzenie tzw. „hurtowni danych - data warehouse” - korzystających z istniejących zasobów.

Podczas integracji aplikacji występują też niestety typowe problemy dotyczące integracji aplikacji:

• kooperacja wymaga wspólnego języka,

• występują różne platformy:

• sprzętowe - Digital, HP, Sun, IBM,

• systemów operacyjnych - MS-DOS, Windows, NT Windows, UNIX, VMS, AXI,

• sieci - DecNet, TCP/IP.

• organizacje posiadają różną strukturę i strategię rozwoju a więc i funkcjonowania aplikacji,

• podczas przyłączania kolejnych aplikacji tworzy się skomplikowana struktura powiązań aplikacja-aplikacja.

Możliwe są przy tym następujące poziomy integracji:

• integracja poprzez dane - omijając mechanizm aplikacji dostajemy się bezpośrednio do bazy danych aplikacji,

• integracja poprzez interfejs użytkownika - poprzez symulację interaktywnego użytkownika aplikacji,

• integracja poprzez własny interfejs aplikacji - istniejąca aplikacja udostępnia programiście możliwość uruchomienia swych funkcji wewnętrznych.

1.1. Zintegrowane systemy zarządzania przedsiębiorstwem

Dla zbudowania zintegrowanego systemu zarządzania niezbędny jest zintegrowany system informacyjny. Dla jego zbudowania trzeba jednak zrealizować następujące postulaty:

• wspólnego dla całej organizacji zasobu informacji, bez zbędnej nadmiarowości, co oznacza, że informacja o każdym obiekcie i zjawisku gromadzona jest tylko raz, najlepiej u źródła, i udostępniana wszystkim procesom, które są gotowe ją wykorzystać ,

• jednolitego standardu gromadzenia, przetwarzania i przesyłania informacji,

• jednolitej postaci mediów gromadzenia i obróbki informacji,

• wspólnych narzędzi i procedur rozwoju systemu,

• jednolitej procedury prowadzenia dialogu z użytkownikiem.

Z punktu widzenia technologii tworzenia zintegrowanych systemów informatycznych wyróżnia się dwie tendencje do budowy:

- wertykalnych systemów standardowych,

- systemów komponentowych.

Wertykalne systemy standardowe stanowią niejako powrót do lansowanej w latach siedemdziesiątych idei systemów branżowych, obejmujących swym zasięgiem jedną dziedzinę usług, czy wytwórczości. Spowoduje to „odchudzenie” systemów uniwersalnych i z drugiej strony uzupełnienie ich o specyficzne funkcje charakterystyczne dla poszczególnych branż. Powodem powrotu do takiego rozwiązania i jednocześnie jego zaleta wynika z:

- nadmiernej złożoności systemów uniwersalnych, powodującej nawet w przypadku samego wdrożenia większe koszty niż system branżowy, większą łatwość nauczenia się systemu przez użytkowników, mniej konieczności przekształcania całego systemu, a w szczególności jego mediów komunikacyjnych itp.,

- znacznie łatwiejsza adaptacja systemu branżowego do warunków panujących w poszczególnych przedsiębiorstwach danej branży niż systemu uniwersalnego,

- znaczne podobieństwo poszczególnych przedsiębiorstw (zakładów) danej branży rokuje nadzieje na zwiększenie efektu skali sprzedaży.

Systemy komponentowe powstają poprzez złożenie systemu zintegrowanego z istniejących komponentów (podsystemów, modułów, elementów, funkcji, procesów), pod warunkiem przyjęcia wspólnego standardu komunikacyjnego. Zasadniczymi zaletami takiego podejścia są:

- wykorzystanie komponentów przez wielu użytkowników, co powoduje obniżkę ich kosztów,

- zmniejszenie złożoności systemów (zakup tylko komponentów potrzebnych, zmniejszenie kosztów, szybsze i prostsze testowanie i poprawianie),

- możliwość abstrahowania od technologii realizacji,

- traktowanie (włączenie, obsługa) komponentu telekomunikacyjnego jak jednego z pozostałych elementów,

• możliwość podmiany takich samych komponentów pochodzących od różnych dostawców, pod warunkiem ustalenia standardów, komunikacyjnych.

Przykładowe charakterystyki systemów zintegrowanych zarządzania zawiera tab. 4.Tab. 4. Wybrane zintegrowane systemy zarządzania na polskim rynku

Nazwa programu	Nazwa producenta	Kraj producenta	Platforma sprzętowa	Zakres funkcjonalny
ASW	IBS AB (International Business Systems)	Szwecja	AS/400	FK, RK, SD, ZP, GM, PP, PC, PR, QM, TR, HR
Bonmaster	Bonair Ltd.	Polska	HP9000, RS/6000	FK, RK, SD, ZP, GM, TR, HR, PL
BPCS	SSA (System Software Associates Inc.)	USA	AS/400, HP9000, RS/6000, DEC	FK, RK, SD, ZP, GM, PP, PC, GR, QM, TR, HR, PR, PL
CA-CAS	Computer Associates International Inc.	USA	IBM Mainframe	FK, RK, SD, ZP, GM, PP, PC, QM, HR
IFS Applications	IFS Industrial and Financial Systems	Szwecja	RS/6000, ICL, DEC VAX, Motorola, DEC Alpha, AXP	FK, RK, SD, ZP, GM, PP, PC, PR, QM, TR, HR
JD Edwards	JD Edwards World Solution Company	USA	AS/400, HP 9000, RS/6000, DEC Alpha	FK, RK, SD, ZP, GM, PP, PC, PR, QM, TR, HR,GR
KOF (Komputerowa Obsługa Firmy)	Decsoft	Polska	VAX, DEC Alpha, HP 9000, DRS-6000, PC	FK, SD, ZP, GM, HR, PL
KOMA UX	Koma S.A.	Polska	RISC, CISC	FK, RK, SD, ZP, GM, PP, PC, PR, GR, TR, PL
MAX	MCS Ltd. (Manufacturing Control Systems)	Wielka Brytania	ICL, RS/6000, HP9000	FK, RK, SD, ZP, GM, PP, GR, QM
Oracle Applications	Oracle Corporation	USA	Większość dostępnych platform na świecie	FK, RK, SD, ZP, GM, PP, PC, PR, QM
PRO/MIS	CSBI	Polska	Intel, RS/6000, Sun, HP9000, VAX	FK, RK, SD, ZP, GM, HR, PL
R/3	S.A.P. AG	Niemcy	Dowolna	FK, RK, SD, ZP, GM, PP, PC, PR, QM, TR, HR, GR
Simple System	Simple sp. z o.o.	Polska	PC, VAX	FK, RK, SD, ZP, GM, PP, HR, PL
Teta	Teta sp. z o.o.	Polska	HP, RS/6000, DEC, PC	FK, RK, SD, ZP, GM, PP, PL
Triton (Baan IV)	Baan	Holandia, USA	RISC, HP, DEC	FK, RK, SD, ZP, GM, PP, PC, PR, TR, GR

Żródło: na podstawie: Zintegrowane Systemy Zarządzania, Vogel Publishing, Wrocław, 1997,

Legenda:

FK - finanse i księgowość	PP - produkcja dyskretna	QM - zarządzanie jakością
RK - sterowanie kosztami	PC - produkcja ciągła	GR - gospodarka remontowa
SD - zarządzanie dystrybucją	GM - gospodarka materiałowa	PR - zarządzanie przedsięwzięciami
ZP - zarządzanie zaopatrzeniem	TR - gospodarka transportowa	PL - płace
HR - kadry

W integracji polegającej na połączeniu różnych klas systemów ze sobą widać wyraźnie wysiłki zmierzające do integracji systemów sztucznej inteligencji (opartych o logikę sieci neuronowych) z konwencjonalnymi systemami. Podstawowym elementem takiego systemu staje się wówczas baza wiedzy wraz z systemem zarządzania bazą wiedzy, które może być wspomagana przez bazę danych i bazę modeli wraz z ich systemami zarządzania tak jak w typowym systemie wspomagającym zarządzanie. System rozwiązujący problem jest jednocześnie systemem klasy systemu eksperckiego i stanowi inteligentny interfejs użytkownika, pozwalający mu jednocześnie na komunikację za pomocą głosu, obrazu itp. Schemat architektury takiego systemu zawiera rys.27.

Rys. 27. Architektura komputerowego systemu zarządzania zintegrowanego z systemem sztucznej inteligencji

1.2. Charakterystyka zintegrowanych pakietów biurowych

Pojęcie zintegrowanych pakietów biurowych obejmuje ogół programów służących do ułatwiania i usprawniania wszelkich prac biurowych, w tym również w grupach roboczych. Pakiety te posiadają w pełni zintegrowane mechanizmy komunikacyjne, pozwalające na szybką wymianę danych i komunikatów pomiędzy użytkownikami. Ponadto umożliwiają zmniejszenie obiegu dokumentów papierowych oraz ewentualne opóźnienia w przepływach informacyjnych pomiędzy poszczególnymi komórkami przedsiębiorstwa (grupami roboczymi). W zakres funkcjonalny takich pakietów wchodzą programy takie jak:

• edytor tekstów - np. Microsoft Word, Word Pro, WordPerfect,

• arkusze kalkulacyjne - np. Excel, Lotus,

• bazy danych - np. Access,

• systemu grafiki prezentacyjnej - np. PowerPoint, Harward Graphics,

• DTP (DeskTop Publishing) - np. Corel Ventura, Page Maker, Quark Xpress,

• kalendarze (harmonogramy) - np. WordPerfect Office, CaLANdar,

• biblioteki dokumentów - np. ProShare,

• poczta elektroniczna - cc:Mail, Win Mail, eMail,

• automatyzujące obieg dokumentacji - np. WorkMan, WordPerfect InForms,

• specjalistyczne oprogramowanie obsługujące biurowe urządzenia zewnętrzne faksy, skanery, modemy, rysownice, pagery, multimedia, rozpoznające głos i obraz typu - WinFax, OmniPage.

Dodatkowymi cechami charakteryzującymi tą grupę oprogramowania jest:

• mniejsza skala działania niż MRP II; są one ograniczone do szeroko pojętego „biura”,

• homogenizacja oprogramowania (upodobnienie się), zarówno pod względem oferowanych funkcji jak i metod komunikacji z użytkownikiem przez różnych producentów oprogramowania,

• cykliczność rozwoju; następnym krokiem będą zapewne - zintegrowane systemy pakietów, następnym - przyłączania aplikacji (apletów),

• przejmowanie dotychczasowych funkcji ofiarowanych przez oprogramowanie zintegrowane tworzone dla małych firm (typu: Polsystem2000, Firma Softaru itp.)

Tab.5. Charakterystyka porównawcze wybranych zintegrowanych pakietów biurowych

Kryterium\Pakiet	Lotus Notes	Microsoft Office	Uniplex
Platforma sprzętowa	PC, Macintosh, Stacje robocze	PC	Stacje robocze
System operacyjny	DOS, Windows, Novell, Unix, OS/2	DOS, Novell, Windows	Unix
Biblioteki dokumentów	X	X	X
Poczta elektroniczna	X	X	X
Grafika	X	X	X
Edytor tekstów	X	X	X
Arkusz kalkulacyjny	X	X	X
Obsługa baz danych	X	X	X
Obsługa rozproszonych baz danych	X		X
Zabezpieczenie danych	X	X	X
Terminarz	X	X	X
Włączanie obiektów z innych aplikacji	X	X	X
Grupy dyskusyjne	X	X
Trasowanie dokumentów	X	X
Współpraca z wyspecjalizowanymi urządzeniami (fax, skaner, modem itp.)	X	X	X
Współpraca z sieciami	Własne sterowniki	Własne sterowniki	Mechanizmy systemu operacyjnego

Źródło: opracowanie własne na podstawie materiałów handlowych

2. Charakterystyka specyfikowanych systemów eksperckich

Z samej definicji systemy eksperckie zawierają specjalizowaną wiedzę na temat określonego obszaru ludzkiej działalności. Wiedza ta jest zorganizowana w sposób umożliwiający systemowi wejście z użytkownikiem w interakcyjny dialog związany z tematyka tego obszaru, w wyniku, którego system może oferować rady lub propozycje oraz objaśnić sposób rozumowania, leżący u ich podstaw. Ponadto współczesne systemy eksperckie zawierają dodatkowe, następujące cechy charakterystyczne:

• działanie w szczególnych niestandardowych dziedzinach typu: medycyna, meteorologia, badania kosmiczne,

• brak możliwości zastosowania oprogramowania standardowego,

• tworzenie pakietów specyficznych opartych o unikalne rozwiązania,

• wysokie wymagania wobec sprzętu i dokładności, niezawodności i bezpieczeństwa użytkowania oprogramowania,

• integracja poprzez mechanizmy sieciowe pozwalające np. na korzystanie z zasobów zgromadzonych do obsługi innych systemów.

Współczesne systemy eksperckie nieodłącznie związane są też z systemami sztucznej inteligencji. Coraz częściej zawierają bowiem mechanizmy rozumowania symbolicznego i niealgorytmicznego oraz symbolicznej reprezentacji wiedzy, co umożliwia przeprowadzanie procesu wnioskowania za pomocą komputera. Nie jest wykluczone, że wraz z rozpowszechnianiem neuronowych komputerów systemy eksperckie zostaną przetransponowane na neuronową płaszczyznę działania. Sieci neuronowe mogą być pomocne zwłaszcza w tych przypadkach, gdy reguły działania nie mogą być bezpośrednio określone, lub zbyt długo trwa ich określanie przez eksperta.

Rys. 28. Przepływy danych w architekturze specjalizowanego, neuronowego systemu eksperckiego

System przedstawiony na rys.28 integruje po trosze własności systemu eksperckiego, sieci neuronowej i relacyjno-obiektowej bazy danych (z systemem zarządzania bazą danych) w środowisku rozproszonym. Przez sprawdzenie zbioru wskaźników ekonomicznych system może generować rekomendacje dla użytkownika lub opcjonalnie, na jego polecenie wykonać za pośrednictwem sieci operację rynkową bazująca na własnych rozwiązaniach systemu. Za pomocą wskaźników obliczonych i przechowywanych w bazie danych można określić stopień wzrostu lub spadku wolumenu produkcji, ruch cen i trendy rynkowe. Baza reguł umiejscowiona w serwerze sztucznej inteligencji zawiera wszelkie procedury analityczne oraz wskaźniki analityczne i parametry związane z dopuszczalnymi sytuacjami gospodarczymi dla danej sfery zjawisk (rynkowych, produkcyjnych, bankowych itp.). Wśród nich znajdują się np. procedury obliczania średniej ruchomej, analizy regresji i analizy prawdopodobieństwa (analiza ryzyka). Sieć neuronowa jest używana z kolei do stworzenia wzorca zachowań, który pozwoliłby na stworzenie prognozy szybkości i kierunku zmian cen. Serwer systemu pozwala ponadto na szybszą komunikację z potężną bazą danych i jej systemem zarządzania.

3. Charakterystyka systemów telekomunikacyjnych

Systemy telekomunikacyjne wkroczyły do typologii systemów wspomagających zarządzanie niejako od strony technologicznego zabezpieczenia zintegrowanego środowiska zarządzania. Jest to zjawisko bardzo niejednorodne zawierające:

• elektroniczną wymianę danych,

• sieci wewnętrzne,

• sieci globalne.

W zjawisku tym jednocześnie nie dostrzegana jest bardzo istotna rola oprogramowania ponieważ uwaga użytkowników skupiona jest na aspektach technicznych sieci. Trzeba jednak pamiętać że systemy telekomunikacyjne:

• stanowią podstawę do integracji większości systemów rozproszonych przestrzennie,

• brak jest standardów, możliwości unifikacji, niejednolitość technologiczna:

• z jednej strony oprogramowanie telekomunikacyjne jest rzeczywiście tylko oprogramowaniem „technicznym” i służy tylko zapewnieniu powiązań pomiędzy istniejącymi już systemami,

• z drugiej jednak strony może oferować nową jakość w zarządzaniu np. poprzez eliminację z obsługi transakcji tradycyjnych kanałów łączności bezpośredniej np. dostosowanie cyklu przetwarzania transakcji do elektronicznego obiegu dokumentacyjnego.

Oprogramowanie systemów telekomunikacyjnych dotyczące wymiany danych pozwala na:

• elektroniczną wymianę danych (EDI) między kontrahentami handlowymi,

• elektroniczny transfer dokumentów i płatności w rozliczeniach międzybankowych, elektroniczną transmisję dokumentów i komunikatów z i do interaktywnych baz danych

• transakcje dokonywane przez osoby fizyczne typu: elektroniczne zakupy, zdalne świadczenia zdrowotne, home banking, nauka na odległość itp.

Oprogramowanie sieciowe dotyczące sieci wewnętrznych opiera się obecnie na koncepcji tzw. Intranetu - rozwiązaniu sprzętowo-programowym przeznaczonym do pracy i komunikacji w środowisku rozproszonym, zawartym przeważnie w ramach jednej organizacji.

Trzecim rodzajem rozwiązań sieciowych są sieci globalne. Spełniają one głównie rolę kompleksowego, powszechnego media komunikacyjnego. Jest to sieć służąca celom przekazu zarówno jednostronnego jak i wymianie dwustronnej komunikatów pomiędzy różnymi kontrahentami. Podstawową cechą charakterystyczna tego oprogramowania jest jego rozległość (obejmuje częstokroć cały świat), jak i jego powszechna dostępność.

Zakończenie

Przedstawiony nowy podział systemów nie jest jeszcze do końca ukształtowany, wydaje się jednak, że zaspokaja przynajmniej paradygmaty zarysowane na początku pracy.

Najwięcej kontrowersji wzbudzają systemy telekomunikacyjne, pojęcie to bowiem zawiera w sobie bardzo różne treści począwszy od systemów czysto narzędziowych po poważne aplikacje. Ich rola w rynku w ostatnich latach jednak bardzo gwałtownie wzrosła i nie sposób nie zauważać ich istnienia. Wykształcają też własne języki, procedury, protokóły, systemy zarządzania i pojęcia (Java, hipertekst itp.) a nawet własną subkulturę i związane z nią problemy społeczne. Pojawiają się rodzaje organizacji lub usług, dla których obsługi nadają się tylko systemy tej klasy - organizacje wirtualne, pasaże internetowe, telezakupy. Dlatego uznano tutaj za niezbędne specjalne wyróżnienie tej klasy systemów.

W ukazanej typologii abstrahuje się od metod rozwiązywania modeli używanych w bazach modeli czy procedur systemów (tzn. nikt z użytkowników nie dba specjalnie o charakterystyki oparte na podziale na metody symulacyjne, optymalizację liniową czy nieliniową - ważna jest realizowana funkcja systemu nie zaś droga, którą się do tego rezultatu dochodzi). Wszelkiego rodzaju metody są po prostu umieszczane w bazie procedur lub bazie wiedzy i to od użytkownika zależy czy i z której z nich będzie chciał skorzystać.

Trzeba mieć również na uwadze, że tworzenie systemów wspomagających zarządzanie nie jest stanem i każda przedstawiona typologia będzie adekwatna do rzeczywistości jedynie w określonym momencie czasowym. Prezentowane przemiany architektoniczne polegające na wielokierunkowej i wszechstronnej integracji obejmującej zarówno warunki technologiczne ujmowane punktowo i przestrzennie jak i oprogramowanie systemowe, narzędziowe oraz, a może przede wszystkim, aplikacyjne. Co ostatecznie wyniknie z tych przemian zapewne przekonamy się w nadchodzących latach, tym niemniej ukazany w pracy podział odpowiada również obecnemu poziomowi świadomości przeciętnego użytkownika systemów - są to po prostu klasy systemów, o które najczęściej (poza grami) pytają klienci czy potencjalni klienci firm tworzących i wdrażających systemy informatyczne zarządzania. Dążenie kreatorów systemów do absolutnej nowoczesności powoduje natomiast zwłaszcza w wizualizacji zewnętrznej, zatarcie różnic pomiędzy rodzajami systemów. Z drugiej strony dążenie to jest motorem napędowym tworzenia i rozpowszechniania nowych technologii (np. komputer neuronowy), które po raz kolejny prawdopodobnie zrewolucjonizują niedługo podejście do typologii systemów.

Spis treści: str.:

Wstęp .......................................................................................................... 2

I. Integracyjne tendencje rozwoju architektury systemów ...................... 3

1. Rodzaje integracji .................................................................................... 4

2. Płaszczyzny integracji .............................................................................. 7

3. Zmiany gospodarcze a tendencje integracyjne ..........................................13

4. Integracja z punktu widzenia architektury systemów.................................15

5. Czynniki wpływu integracji architektury na efektywność

i wydajność wykorzystania systemu .........................................................16

5.1. Integracja niskiego rzędu ...................................................................16

5.2. Integracja wysokiego rzędu ...............................................................20

II. Architektura systemów i ich integracja w „klasycznej”

typologii SIZ ..........................................................................................25

1. Kryteria klasyfikacji systemów ..................................................................25

2. „Klasyczna” typologia systemów ze względu na architekturę ....................27

3. Podstawowe elementy składowe systemów informatycznych

zarządzania ..............................................................................................32

III. Kierunki zmian typologii systemów spowodowane

czynnikami integracyjnymi ....................................................................46

1. Cechy charakterystyczne architektury zintegrowanej ..................................46

2. Zalety łączenia systemów o różnej architekturze .......................................47

2.1. Systemy zarządzania bazą danych i systemy eksperckie ....................47

2.2. Systemy eksperckie i systemy wspomagania decyzji ..........................48

2.3. Systemy informowania kierownictwa i systemy wspomagania ...........52

2.4. Systemy eksperckie i systemy informowania kierownictwa ...............53

2.5. Systemy informowania kierownictwa i systemy baz danych ..............54

2.6. Powiązania pomiędzy systemami tego samego typu ............................55

3. Budowa systemów uniwersalnych .............................................................56

4. Przesłanki zmian typologii SIZ ..................................................................58

IV. Proponowany podział SIZ ze względu

na przemiany architektoniczne ..............................................59

1. Zintegrowane systemy zarządzania .............................................................61

1.1. Zintegrowane systemy zarządzania przedsiębiorstwem ........................63

1.2. Charakterystyka zintegrowanych pakietów biurowych .........................68

2. Charakterystyka specyfikowanych systemów eksperckich ..........................70

3. Charakterystyka systemów telekomunikacyjnych ........................................72

Zakończenie ..................................................................................................74

Spis treści ........................................................................................................ 76

Spis rysunków ..................................................................................................78

Spis tablic .........................................................................................................79

Bibliografia .......................................................................................................80

Spis rysunków: str.:

Rys.1. Główne podejścia do integracji technologicznej ....................................8

Rys. 2. Architektura integracji „zwartej” systemu eksperckiego i systemu

bazy danych ..........................................................................................10

Rys.3. Architektura integracji „luźnej” systemu eksperckiego i systemu

bazy danych ..........................................................................................11

Rys.5. „Luźna” architektura pozioma ...............................................................18

Rys.6. „Zwarta” architektura hierarchiczna ......................................................18

Rys.7. „Luźna” architektura pozioma z hierarchiczną integracją ......................19

Rys.8. Ewolucja SIZ ze względu na zmiany sposobu przetwarzania

danych i metod modelowania ...............................................................24

Rys.9. Architektura Transakcyjnego Systemu Przetwarzania Danych ...............27

Rys.10. Architektura Systemu Informacyjnego Zarządzania .............................27

Rys. 11. Architektura Systemu Wspomagania Decyzji ....................................28

Rys. 12. Architektura Systemu Eksperckiego ..................................................28

Rys. 13. Architektura Systemu Informowania Kierownictwa ..........................29

Rys. 14. Architektura Systemu Sztucznej Inteligencji ......................................29

Rys. 15. Architektura Systemu Wspomagania Zarządzania .............................30

Rys.16. Wzajemne relacje systemów informacyjnych zarządzania ............... ...31

Rys.17. Wspieranie poziomów zarządzania przez Systemy

Informatyczne Zarządzania ................................................................... 34

Rys.18. Etapy rozwoju SIZ ..............................................................................36

Rys.19. Architektura połączonego Systemu Eksperckiego i Systemu

Bazy Danych (Inteligentna Baza Danych) ............................................47

Rys.20. System ekspercki jako uzupełnienie systemu wspomagania decyzji ....49

Rys.21. System ekspercki jako oddzielny komponent systemu wspomagania

decyzji ..................................................................................................50

Rys.22. System ekspercki rozszerzający proces podejmowania

decyzji w systemie wspomagania decyzji ..............................................51

Rys.23. Zunifikowany system ekspercki z systemem wspomagania decyzji .... 52

Rys.24. Architektura połączeń pomiędzy systemem informowania

kierownictwa i systemem wspomagania decyzji .................................... 53

Rys.25. Architektura połączeń pomiędzy systemem informowania

kierownictwa i systemem eksperckim ................................................... 54

Rys.26. Architektura systemu informowania kierownictwa połączonego

z systemem bazy danych ......................................................................55

Rys. 27. Architektura komputerowego systemu zarządzania zintegrowanego

z systemem sztucznej inteligencji ........................................................67

Rys.28. Przepływy danych w architekturze specjalizowanego,

neuronowego systemu eksperckiego ................................................... 72

Spis tablic: str.:

Tab.1. Podstawowe cechy charakterystyczne SIZ .......................................... 32

Tab.2. Zastosowanie SWZ na poziomach organizacji ..................................... 35

Tab.3. Wady i zalety wykorzystania komponentów manipulacji modelu .........43

Tab.4. Wybrane zintegrowane systemy zarządzania na polskim rynku ............65

Tab.5. Charakterystyka porównawcze wybranych zintegrowanych

pakietów biurowych ............................................................................69

Bibliografia:

1. Abramowicz W.: Hipertekst a zintegrowane systemy informacyjne w: Human-Computer Interaction'97; red. B.Kubiak, A.Korowicki, materiały konferencji, Sopot, 1997

2. Abramowicz W.: Zintegrowane systemy informacyjne w: Zintegrowane Systemy Zarządzania, Vogel Publishing, Wrocław, 1997,

3. Ackoff R. L.: Decyzje optymalne w badaniach stosowanych, PWN, Warszawa, 1969,

4. Alter S.: Information Systems: A Management Perspective; Addison-Wesley Publishing Co.,Reading, Massachussets, 1992,

5. Applegate L.M., B.R.Konsynski, J.F.Nunamaker : Model Management Systems:Design for Decision Support, DSS , nr 1, 1987,

6. Bodart F.: Intruduction to Deciosion Support System, 1-st International Summer School on Multiple Criteria Decision Making, Namur, 1983,

7. Chmielarz W.: Systemy informatyczne wspomagające zarządzania, Dom Wydawniczy „Elipsa”, Warszawa, 1996,

8. Chuchulski M., A. Stefański: Integracja środowiska informatycznego przedsiębiorstw przemysłowych z systemem R/3 w: I Ogólnopolski Kongres SAP'97, Warszawa, 1997,

9. Cypriański J., A. Nowakowski: Funkcje użytkownika końcowego w zintegrowanych systemach informacyjnych, w: Human-Computer Interaction'97 pod red.: B.F.Kubiak, A.Korowicki, Gdańsk, 1997,

10. Freyenfeld W.A. : Decision Support Systems, NCC Publications, Manchester, 1984,

11. Gels M.: Decision Support Systems: The Significance of Hybrid Communication Facilities for Operation Research Consultancy, Eurographics'83, P.J.W. Hagen, Elsevier Science Publishers, 1984,

12. Krupa K.: Współczesne narzędzia zarządzania produkcją oraz wykorzystanie pakietu Easy-Case w budowie struktur organizacyjnych firm, w: Human-Computer Interaction'97 pod red.: B.F.Kubiak, A.Korowicki, Gdańsk, 1997,

13. Landvater D., C. D. Gray: MRP II Standard System APICS, Oliver Wight Publications, Inc. , Essex Junction, 1989,

14. Lasek M. : SAP R/3 w optymalizacji procesów gospodarczych przedsiębiorstwa w: Human-Computer Interaction, red. B. Kubiak, A. Korowicki, Sopot, 1997

15. Leigh W. E.; D. L. Ali: System Architecture. Software and Hardware Concepts, South-Western Publishing Co. Cincinnati, Ohio, 1988,

16. Niedzielska E.: Zintegrowane środowisko zarządzania jako perspektywiczna platforma użytkowania gospodarczych systemów informacyjnych w: Business Information Systems'97, red. W. Abramowicz, materiały konferencyjne, Poznań, 1997,

17. Samól D., M. Gnadig, M. Scyga: Integracja procesów gospodarczych w przedsiębiorstwie, materiały I Ogólnopolskiego Kongresu SAP'97, Warszawa, 1997,

18. Spraque R.H. : A Framework for the Development of DSS, MIS Quarterly 4, nr 4, 1980,

19. Spraque R.H..: DSS in Contex, DSS, vol.3, nr 3,1987,

20. Stair R.M.: Principles of Data Processing; R.D. Irwin Inc., Illinois, 1981,

21. Turban E., H.Watson: Integrating Expert Systems and Decision Support Systems; MIS Quarterly, 1986,

22. Turban E.:Decision Support and Expert Systems. wydanie trzecie, Macmillan Publishing Company, 1993.

Ackoff R. L.: Decyzje optymalne w badaniach stosowanych, PWN, Warszawa, 1969,

Patrz: J. Cypriański, A. Nowakowski: Funkcje użytkownika końcowego w zintegrowanych systemach informacyjnych, w: Human-Computer Interaction'97 pod red.: B.F.Kubiak, A.Korowicki, Gdańsk, 1997, str. 81-87,

Patrz: K.Krupa: Współczesne narzędzia zarządzania produkcją oraz wykorzystanie pakietu Easy-Case w budowie struktur organizacyjnych firm, w: Human-Computer Interaction'97 pod red.: B.F.Kubiak, A.Korowicki, Gdańsk, 1997,str.: 171-189.

Alter S.: Information Systems: A Management Perspective; Addison-Wesley Publishing co.,Reading, Massachussets, 1992

Por.: E. Turban: Decision Support and Expert Systems. Management Support Systems, Macmillan Publishing Company, New York, 1993.

Samól D., M. Gnadig, M. Scyga: Integracja procesów gospodarczych w przedsiębiorstwie, materiały I Ogólnopolskiego Kongresu SAP'97, Warszawa, 1997, str. 23

Leigh W. E.; D. L. Ali: System Architecture. Software and Hardware Concepts, South-Western Publishing Co. Cincinnati, Ohio, 1988

Spraque R.H..: „DSS in Contex”, DSS, vol.3, nr 3,1987

Turban E.:Decision Support and Expert Systems. wydanie trzecie, Macmillan Publishing Company, 1993

por.: Turban E.: Decision Support ...

Turban E.: Decision Support ...

opis wszystkich elementów systemu i ich podstawowych funkcji znajduje się w rozdziale 3.

ze względu na popularność niektórych skrótów w większości przypadków w skrótach pozostawiono nomenklaturę angielskojęzyczną.

Patrz: Chmielarz W.: Systemy informatyczne wspomagające zarządzania, Dom Wydawniczy „Elipsa”, Warszawa, 1996.

Stair R.M.: Principles of Data Processing; R.D. Irwin Inc., Illinois, 1981

Spraque R.H. : A Framework for the Development of DSS, MIS Quarterly 4, nr 4,1980, str. 1-26

Bodart F.: Intruduction to Deciosion Support System, 1-st International Summer School on Multiple Criteria Decision Making, Namur, 1983

Gels M.: Decision Support Systems: The Significance of Hybrid Communication Facilities for Operation Research Consultancy, Eurographics'83, P.J.W. Hagen, Elsevier Science Publishers, 1984, str.:251-259

Applegate L.M., B.R.Konsynski, J.F.Nunamaker : Model Management Systems:Design for Decision Support, DSS , nr 1, 1987, str. 81-93.

E. Turban, H.Watson: Integrating Expert Systems and Decision Support Systems; MIS Quarterly, 1986

E.Turban: Decision Support and Expert Systems. Management Support SystemsMacmillan Publishing Co, NY, 1993

por.: D. Landvater, C. D. Gray: MRP II Standard System APICS, Oliver Wight Publications, Inc. , Essex Junction, 1989.

E. Niedzielska: Zintegrowane środowisko zarządzania jako perspektywiczna platforma użytkowania gospodarczych systemów informacyjnych w: Business Information Systems'97, red. W. Abramowicz, Materiały konferencyjne, Poznań, 1997.

Chuchulski M., A. Stefański: Integracja środowiska informatycznego przedsiębiorstw przemysłowych z systemem R/3 w: I Ogólnopolski Kongres SAP'97, Warszawa, 1997, str. 405

Pisze też o tym Lasek M. : SAP R/3 w optymalizacji procesów gospodarczych przedsiębiorstwa w: Human-Computer Interaction, red. B. Kubiak, A. Korowicki, Sopot, 1997, str. 112,

Abramowicz W.: Zintegrowane systemy informacyjne w: Zintegrowane Systemy Zarządzania, Vogel Publishing, Wrocław, 1997, str. 5-10

por.: Abramowicz W.: Hipertekst a zintegrowane systemy informacyjne w: Human-Computer Interaction'97 red. B.Kubiak, A.Korowicki, materiały konferencji, Sopot, 1997, str. 365

Freyenfeld W.A. : Decision Support Systems, NCC Publications, Manchester, 1984

podobny system jest opisany w: Turban E.: Decision ...

Niedzielska E.: Zintegrowane środowisko zarządzania jako....

86 Błąd! Nie można odnaleźć źródła odsyłacza.

79

Podejścia integracyjne

Poprzez dostęp

Poprzez osadzanie

Jedno-

procesorowe

Wielo-procesorowe

Sieci

Użytkownik końcowy

Interfejs użytkownika

Aplikacje użytkowa

Funkcje Systemu Eksperckiego

System Zarządzania Bazą Danych

Baza Wiedzy

Baza Danych

Baza Wiedzy

Baza Danych

Zbiory komunikacyjne

Aplikacje i funkcje systemu eksperckiego

Aplikacje i funkcje bazy danych

System przywołań

Kanały komunikacyjne

Komputer

Komputer

Komputer

Lokalna baza danych

Lokalna baza danych

Lokalna baza danych

Baza danych

Baza danych

Lokalna baza danych

Komputer

Komputer

Komputer

Kanały komunikacyjne

Lokalna baza danych

Lokalna baza danych

Komputer

Komputer

Komputer

Kanały komunikacyjne

Baza danych

Baza danych

Interfejs

użytkownika

Baza reguł systemu eksperckiego

Mechanizm wnioskowania

Groma-dzenie danych

Modele danych

Baza danych i System Zarządzania BD

Raporty

Ekrany

Transakcje Bazy Danych

Programy aplikacji Bazy Danych

System Ekspercki

Zbiory danych

Programy aplikacyj-ne

Użytkownik

Zbiór 1

Zbiór 2

Zbiór n-ty

System Zarządzania Bazą Danych

Baza Danych

Oprogra-mowanie aplikacyjne

System łączności z użytkownikiem

Baza Danych

Baza Modeli

System Zarządzania Bazą Danych

System Zarządzania Bazą Modeli

Oprogramo-wanie aplikacyjne

System łączności z Użytkowni-kiem

System Zarządzania Bazą Danych

Baza Danych

System łączności z Użytkowni-kiem

Oprogramo-wanie aplikacyjne

System Zarządzania Bazą Procedur

Baza Procedur

System Zarządzania Bazą Danych

Baza Danych

System łączności z Użytkowni-kiem

Oprogramo-wanie analityczne, symulacyjne i prognostyczne

Dane z otoczenia, innych baz danych, przetworzone z baz modeli i wiedzy

System Zarządzania Bazą Danych

Baza Danych

System łączności z Użytkowni-kiem

Oprogramo-wanie aplikacyjne

System Zarządzania Bazą Wiedzy

Baza Wiedzy

System Zarządzania Bazą Danych

Baza Danych

System łączności z Użytkowni-kiem

Oprogramo-wanie aplikacyjne

System Zarządzania Bazą Modeli

Baza Modeli

Baza Wiedzy i Procedur

(adaptacja + uczenie się)

System Zarządzania Bazą Wiedzy

Konsultant kreatora systemu

Konsultant nieprofesjonalnych użytkowników

Użytkownik

Interfejs użytkownika

Udoskonalenie komunikacji z użytkownikiem

Baza danych

Baza modeli

System zarządzania bazą danych

System zarządzania bazą modeli

Wspomaganie bazy danych i SZBD

Wspomaganie tworzenia modeli i SZBM

Użytkownik

Interfejs użytkownika

Użytkownik

Interfejs użytkownika

System ekspercki

System zarządzania bazą danych

System zarządzania bazą modeli

System zarządzania bazą modeli

System zarządzania bazą danych

Baza modeli

Baza danych

System ekspercki

Baza modeli

Baza danych

Użytkownik

Zarządzanie systemem

Interfejs użytkownika

Mechanizm wnioskowania

Inteligentny program nadzorczy

systemu eksperckiego

System zarządzania bazą danych

System zarządzania bazą modeli

Baza wiedzy

Użytkownik

Baza modeli

Baza danych

Interfejs użytkownika

System zarządzania bazą danych

System zarządzania bazą modeli

System Informowania Kierownictwa

Baza modeli

Baza danych

Otoczenie

Zapytania

Odpowiedzi

Rekomendacje

Odpowiedzi

Rekomendacje

Informacje zewnętrzne

Rekomendacje dla użytkownika

Otoczenie

Użytkownik

Rekomendacje dla użytkownika

Informacje zewnętrzne

Informacje

Interpretacje

System Informowania Kierownictwa

Interfejs użytkownika

Odpowiedzi

Rekomendacje

System zarządzania bazą danych

System zarządzania bazą wiedzy

Baza danych

Baza wiedzy

Użytkownik

Interfejs użytkownika

System zarządzania bazą danych

System informowania kierownictwa

Baza danych

System Inteligentnego Interfejsu

System Zarządzania Bazą Wiedzy

Zarządzanie system rozwiązywania problemów i wnioskowania

Język zapytań wysokiego poziomu

Dostęp przez użycie naturalnego języka, obrazów, itp.

Użytkownik

Warstwa dostępu do oprogramo-wania

Baza Wiedzy

Baza Procedur

Baza Danych + System Zarządzania Bazą Danych

Baza Modeli + System Zarządzania Bazą Modeli

System Inteli-gentne-go Inter-fejsu + System Obsługi Sieci

Mechanizm Inteligentnego dostępu

Logika języka komunikacji

Mechanizm Obiektowej Bazy Danych

Mechanizm Relacyjnego Zarządzania Komponentami

Mechanizm adaptacji i uczenia się

Architektura najwyższego poziomu integracji

Otoczenie gospodarcze

Serwer bazy danych zewnętrznych

Neuronowy serwer systemu sztucznej Inteligencji

Neuronowy serwer systemu eksperckiego

Stacja robocza użytkownika systemu

System zarządzania obiektowo-relacyjną bazą danych

Dane statystyczne, ankietowe itp.

Dane przetworzone

Rekomendacje

Dane i rekomen-dacje

Wykonane operacje

Warunki działania użytkownika

Wzorce działania pożądane

Wzorce działania optymalne

Dane do uczenia

Warstwa oprogramo-wania aplikacyjnego

Warstwa oprogramo-wania narzędziowe-go i systemowego

Warstwa sprzętowa

---