Problem unifikacji pakietu Diana

EDWARD MICHALEWSKI Instytut Bada Systemowych PAN

PROBLEM UNIFIKACJI PAKIETU DIANA

Streszczenie

Problem, czy powinien byü jeden zunifikowany (uniwersalny) pakiet DIANA (Wspomaganej komputerowo DIAgnostycznej ANAlizy i projektowania systemów za-rządzania) dla dowolnego badanego obiektu (przedsiĊbiorstwo, urząd, bank), czy teĪ dla kaĪdego z nich powinno siĊ stworzyü odpowiednią mutacjĊ pakietu, powstał juĪ w pierwszych latach istnienia metodyki DIANA. Początkowo uwaĪano, Īe pakiet po-winien obsługiwaü wszystkie rodzaje badanych obiektów, jednak z czasem stały siĊ konieczne modyfikacje pakietu, uwzglĊdniające specyfikĊ danego obiektu. Obecnie rozwijane są prace umoĪliwiające adaptacjĊ pakietu do specyfiki obiektu juĪ na wstĊpnym etapie badaĔ. W niniejszej publikacji omówiono bardziej szczegółowo te okresy ewolucji pakietu DIANA.

Słowa kluczowe: komputerowe systemy wspomagania decyzji, narzdzia wspomagajce projek-towanie struktury organizacyjnej, zarzdzanie wiedz

1. Wprowadzenie

Celem podjtych w Instytucie Automatyki PAN (obecnie Instytut Bada Systemowych PAN) ponad 40 lat temu prac było opracowanie narzdzia do usprawniania funkcjonowania duych organizacji. W efekcie uzyskano metod wspomaganej komputerowo DIAgnostycznej ANAlizy i projektowania systemów zarzdzania (DIANA) i jej implementacje w postaci kolejnych wersji komputerowych pakietów, z których pakiety DIANA-9, 10 i 11 s obecnie z powodzeniem wykorzystywane zarówno w małych i rednich przedsibiorstwach i organizacjach, jak te w duych obiektach rzeczywistych (np. KG Policji RP, Centrala PKO BP, czy Słuba Celna RP).

Problem czy powinien by jeden zunifikowany (uniwersalny) pakiet DIANA dla dowolnego badanego obiektu (przedsibiorstwo, urzd, bank), czy te dla kadego z nich powinno si stwo-rzy odpowiedni mutacj pakietu, powstał ju w pierwszych latach istnienia metodyki DIANA [1]. Pocztkowo uwaano, e pakiet powinien obsługiwa wszystkie rodzaje badanych obiektów [2], jednak z czasem stały si konieczne modyfikacje pakietu, uwzgldniajce specyfik danego obiektu [3]. Obecnie rozwijane s prace umoliwiajce adaptacj pakietu do specyfiki obiektu ju na wstpnym etapie bada [4]. Poniej omówiono bardziej szczegółowo te okresy ewolucji pakietu DIANA.

2. Wersja uniwersalna pakietu DIANA

Proponowana w metodzie DIANA architektura (budowa) modelu systemu informacyjnego zarzdzania badanego obiektu [5] stanowi wielopoziomow polihierarchiczn przestrzenn sie powiza informacyjnych (Rys. 1).

Rys. 1. Model systemu informacyjnego zarządzania

ródło: Opracowanie własne.

Na najniszym poziomie wzłami sieci s czynno
ci, wykonywane przez poszczególnych pracowników badanego systemu informacyjnego zarzdzania, za łukami wej ciowe i wyj ciowe informacje. Poziom ten posiada pewn hierarchi: zadania - podzadania - operacje (czynno ci elementarne). Zarówno wzły jak i łuki opisywane s szeregiem parametrów, wykorzystywanych nie tylko w diagnozie ale te przy projektowaniu struktury organizacyjnej.

Nastpny poziom zawiera zbiór pracowników (wzły sieci) - ich wzajemne powizania (łuki sieci) wynikaj z powiza pomidzy wykonywanymi przez nich czynno ciami. Mamy wic nie tylko łuki poziome (dostawca – odbiorca informacji), ale równie łuki pionowe, które wskazuj jakie czynno ci realizuje dany pracownik. Poziom ten posiada własn hierarchi: np. prezes - jego zastpcy - kierownicy komórek - szeregowi pracownicy. Zarówno wzły jak i łuki opisywane s parametrami, wykorzystywanymi nie tylko w diagnozie, ale te przy projektowaniu struktury organizacyjnej.

Jeszcze wyszym poziomem jest sie, w której wzłami s komórki organizacyjne, za po-wizania midzy nimi (łuki) wynikaj z powiza zatrudnionych w tych komórkach pracowników. Patrzc w dół – wynikaj z powiza realizowanych przez nich czynno ci. Tu równie mamy łuki pionowe, wskazujce w jakiej komórce jest zatrudniony dany pracownik. Ten poziom posiada własn hierarchi: np. obiekt - piony - departamenty - wydziały - stanowiska. Zarówno wzły jak i łuki opisywane s parametrami, wykorzystywanymi nie tylko w diagnozie, ale te przy projekto-waniu struktury organizacyjnej.

Wreszcie na najwyszym poziomie znajduje si sie celów i zasobów badanego systemu in-formacyjnego zarzdzania. Poziom ten posiada własn hierarchi: np. cele obiektu (statutowe) - cele pionów - cele departamentów - cele stanowisk. Zarówno wzły jak i łuki opisywane s parametrami (z których najwaniejszymi s zasoby, czyli rodki przeznaczone na realizacj celów).

POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 22, 2009

127

Te parametry s wykorzystywane zarówno w diagnozie jak te przy projektowaniu struktury organizacyjnej. Powyszy model uzupełniaj powizania z otoczeniem.

W trakcie wieloletnich bada w ramach unifikacji danych zbieranych dla rónych obiektów (przedsibiorstwa, urzdy, banki itp.) udało si wprowadzi standardy dla wszystkich poziomów modelu i prawie wszystkich jego parametrów (z jednym wyjtkiem). Przykładem moe by rodzaj funkcji elementarnej (niezwykle istotny parametr czynno ci, zarówno w diagnozie, jak i projekto-waniu), dla którego niezalenie od rodzaju badanego obiektu wprowadzono 10 kategorii:

• realizacja standardowa - s to czynno ci zrutynizowane, dla których istniej okre lone przepisy ich wykonywania (obliczenia, formularze);

• realizacja niestandardowa - s to czynno ci, dla których nie ma okre lonych przepisów wykonywania i wymagaj one za kadym razem innego sposobu po-stpowania;

• archiwowanie - s to czynno ci zwizane z gromadzeniem, zabezpieczeniem i przechowywaniem informacji, w tym równie wyników własnych czynno ci w celu wykorzystania ich w póniejszym terminie;

• kontrola - s to czynno ci dotyczce sprawdzania i oceny przebiegu lub rezulta-tów innych czynno ci wykonywanych na własnym lub obcym stanowisku; • nadzór - s to czynno ci zwizane z regulowaniem przebiegu realizacji innych

czynno ci wykonywanych na własnym lub obcym stanowisku;

• koordynacja - s to czynno ci dotyczce synchronizacji procesów realizacji in-nych czynno ci;

• konsultacja - wymiana pogldów; czyli czynno ci o charakterze konsultacji spe-cjalistycznych, konsultacji udzielanych podczas narad, dyskusji, szkolenia itp. • koncepcja - s to czynno ci o charakterze twórczym, zwizane z retrospekcj

własnej praktyki zawodowej, zaznajamianiem si z literatur fachow oraz anali-z istniejcych rozwiza; wynikiem takich operacji mog by np. wytyczne; • decyzja - s to czynno ci majce charakter procesów decyzyjnych, wybór

najko-rzystniejszej alternatywy i zwizane z okre laniem celów, rodków i metod, w tym take decyzje w sprawach przedłoonych;

• konsultacja kierownicza - wymiana pogldów specjalistycznych i porady udzie-lane przez przełoonego (decyzje nieformalne).

Wspomnianym wyej wyjtkiem jest jeden z parametrów opisujcych czynno ci, a mianowicie sfera działalno ci, która w standardowej wersji posiadała nastpujce kategorie:

• zaopatrzenie, • zbyt,

• sterowanie procesami, • planowanie długookresowe,

• techniczne przygotowanie procesów, • gospodarka materiałowa,

• gospodarka rodkami trwałymi, • gospodarka narzdziowa, • gospodarka remontowa, • finanse,

• kadry i płace, • koszty,

• sterowanie jako ci procesów, • inne sfery działalno ci.

Mona zauway, e te kategorie idealnie pasuj w przypadku przedsibiorstw produkcyjnych. Dla bardziej łatwego dopasowania w przypadku innych obiektów (np. urzdów) rozszerzono niektóre podstawowe kategorie, np.: - sterowanie/zarzdzanie procesami, - technicz-ne/organizacyjne przygotowanie procesów, - gospodarka narzdziowa/gospodarka zasobami. Oczywi cie, pewne kategorie (np. gospodarka remontowa) mogły mie wówczas marginalny udział, za w sytuacji całkowitego braku dopasowania zawsze pozostawała kategoria „inne sfery działalno ci”. Warto jednak zwróci uwag, e ten sposób postpowania miał istotne ograniczenia, wynikajce z konstrukcji algorytmu obliczania siły powiza – bardzo wanego syntetycznego wskanika, wykorzystywanego w kilkunastu algorytmach diagnostycznych oraz w algorytmach komputerowo wspomaganego projektowania struktur organizacyjnych. Dla przykładu, wiksza siła powiza midzy dwoma stanowiskami powoduje, e znajd si one w jednej komórce organiza-cyjnej.

Siła powiza pomidzy zadaniami jest obliczana według nastpujcego wzoru:

( ) ( )

(

[ ]

[ ]

)

( )

( )

( )

( )

( )

( )

( )

_ 
     ₊ • •    
     ₊ + =

+

ij ij ij ij ij ij ij m ij n ij ij ij ij t l o w r h k b a p c

T

L

O

W

R

H

K

E

F

P

C

S

τ

µ

η

γ

φ

δ

β

α

₍₁₎ gdzie:

i - identyfikator zadania dostawcy j - identyfikator zadania odbiorcy

τ

µ

η

γ

φ

δ

β

α

- współczynniki korekcyjne

( )

cij

C

- zaleno  siły powiza od czstotliwo ci kontaktów ci, cj

( )

   ≥ < = j i j j i i ij c c ezeli j c c c eli e j c c

C

,_, z (2)

( )

pij

P

- zaleno  siły powiza od pracochłonno ci zada pi, pj :

( )

   ≥ < = j i j j i i ij p p ezeli j p p p ezeli j p p

P

,_, (3)

[ ]

n ij a

F

- zaleno  siły powiza od rodzaju funkcji elementarnej dostawcy i odbiorcy

POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 22, 2009

129 O d b i o r c a Dos-tawca 1 2 3 4 5 6 7 8 9 10 1 { 82 50 65 37 10 26 17 2 5 1 } 2 { 50 82 65 65 26 50 37 10 17 5 } 3 { 65 65 82 50 17 37 26 5 10 2 } 4 { 37 65 50 82 37 65 50 17 26 10 } 5 { 10 26 17 37 82 50 65 50 65 37 } 6 { 26 50 37 65 50 82 65 26 37 17 } 7 { 17 37 26 50 65 65 82 37 50 26 } 8 { 2 10 5 17 50 26 37 82 65 65 } 9 { 5 17 10 26 65 37 50 65 82 50 } 10 { 1 5 2 10 37 17 26 65 50 82 }

(Rodzaje funkcji elementarnych: n = 1, ... , 10)

[ ]

m

ij b

E

- zaleno  siły powiza od sfery działalno ci dostawcy i odbiorcy informacji, gdzie macierz

[ ]

b

_m ma posta:

O d b i o r c a Dos-tawca 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 { 82 74 33 33 25 33 25 33 25 16 8 25 25 1 } 2 { 74 82 16 16 8 16 8 8 8 25 8 25 25 1 } 3 { 33 16 82 40 65 65 40 65 74 16 16 25 74 1 } 4 { 33 16 40 82 33 25 33 40 50 40 33 40 16 1 } 5 { 25 8 65 33 82 74 50 65 57 16 25 25 74 1 } 6 { 33 16 65 25 74 82 57 65 65 16 8 16 57 1 } 7 { 25 8 40 33 50 57 82 40 65 33 8 40 33 1 } 8 { 33 8 65 40 65 65 40 82 57 16 8 16 57 1 } 9 { 25 8 74 50 57 65 65 57 82 16 16 25 33 1 } 10 { 16 25 16 40 16 16 33 16 16 82 57 65 16 1 }

O d b i o r c a Dos-tawca 1 2 3 4 5 6 7 8 9 10 11 12 13 14 11 { 8 8 16 33 25 8 8 8 16 57 82 57 16 1 } 12 { 25 25 25 40 25 40 40 16 25 65 57 82 33 1 } 13 { 25 25 74 16 74 33 33 57 33 16 16 33 82 1 } 14 { 1 1 1 1 1 1 1 1 1 1 1 1 1 1 } (Rodzaje sfer: m = 1, ... , 14)

( )

kij

K

- zaleno  siły powiza od klasy zadania

( )

   = ≠ = j i j i ij k k ezeli j k k ezeli j k

K

1_{2 ,}, (4)

( )

hij

H

- zaleno  siły powiza od charakteru zada

( )

   = ≠ = j i j i ij h h ezeli j h h ezeli j h

H

1_{2 ,}, (5)

( )

r

ij

W

( )

w

ij

O

( )

o

ij

L

( )

l

ij

T

( )

t

ij

R

,

,

,

oraz - zaleno ci siły powiza

od charakterystyk dostawcy wzgldem wykonawcy, odpowiednio: hierarchii dostawcy, jego wano ci, opónie, błdów oraz sposobu kontaktu

(przyjmuj warto  charakterystyki).

Konkretne liczby w powyszych macierzach zale od specyfiki danego obiektu i to powoduje, e wykorzystanie tych samych warto ci dla rónych obiektów jest do  ograniczone. Szczególnie jest to widoczne w przypadku sfer działalno ci. Dla przykładu, sfera działalno ci: techniczne przygotowanie procesów i organizacyjne przygotowanie procesów, maj te same warto ci (kolum-na 5 w macierzy), co w wielu realnych przypadkach jest do  trudne do przyjcia.

Mimo wszystko, ten sposób postpowania udawało si utrzyma do momentu, gdy obiektem bada stał si bank, Centralny Bank (NBP). Było jasne, e musi by stworzona nowa mutacja pakietu DIANA, uwzgldniajca specyfik tego nowego obiektu bada.

3. Mutacje pakietu DIANA

Najbardziej charakterystyczn (ale nie jedyn) stała si mutacja bankowa pakietu DIANA. Stworzono j na pocztku lat 90-tych ubiegłego wieku, gdy obiektem bada został Narodowy Bank Polski [6]. Dla parametru sfera działalno ci ustalono wówczas nastpujce kategorie:

• organizacja i zarzdzanie, • zagadnienia prawne, • informatyka, • współpraca z zagranic, • rewizje i kontrole, • kadry, • rodki rzeczowe,

POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 22, 2009

131

• własna gospodarka finansowa, • polityka pienina,

• system bankowy,

• rachunkowo  i operacje finansowe, • znaki pienine, depozyty Skarbu Pastwa, • prace naukowo-badawcze,

• inne sfery działalno ci.

Oczywi cie w macierzy, na podstawie opinii ekspertów, przyjto inne warto ci liczbowe. Ko-lejnym przykładem konieczno ci modyfikacji kategorii parametru sfera działalno ci jest przypadek badania Urzdu Wojewódzkiego [7], dla którego te kategorie przyjły nastpujc posta:

• polityka regionalna, • ochrona rodowiska,

• organizacja i funkcjonowanie administracji, • współdziałanie z samorzdami,

• planowanie przestrzenne, budownictwo, infrastruktura, • rolnictwo, gospodarka ywno ciowa,

• usługi społeczne, • usługi obywatelskie,

• współdziałanie z administracj specjaln, • finanse,

• kadry i płace, • koszty, • promocja,

• inne sfery działalno ci.

Równie w tym przypadku ustalenie odpowiednich warto ci w macierzy wymagało gruntow-nych bada i aktywnego udziału ekspertów, a wic i dodatkowych nakładów. Jednak analiza porównawcza m.in. wyników projektowania struktury za pomoc uniwersalnego pakietu i jego mutacji wykazała, e ten wysiłek opłacał si – wszystkie warianty wygenerowane w pierwszym przypadku zostały odrzucone przez Zespół Oceniajcy. Natomiast wyniki projektowania, uzyskane za pomoc mutacji pakietu DIANA, uwzgldniajcej specyfik Urzdu Wojewódzkiego, zostały w cało ci zaakceptowane.

Kolejna konieczno  stworzenia nastpnej mutacji pakietu DIANA powstała przy badaniu Słuby Celnej RP [8]. Tu równie niezbdny był udział ekspertów przy wyznaczaniu odpowied-nich warto ci w macierzy uwzgldniajcej sfer działalno ci przy obliczaniu siły powiza.

W ten sposób namnoyła si spora ilo  mutacji pakietu DIANA, za panowanie nad nimi sta-wało si coraz trudniejsze, jeeli uwzgldni si fakt, e modyfikacja macierzy powoduje zmiany w kilkuset miejscach rónych algorytmów (diagnostycznych i projektowania struktury). Z tego powodu przystpiono do opracowania innego podej cia do rozwizania tego problemu.

4. Adaptacja pakietu DIANA do specyfiki badanego obiektu na wstpnym etapie bada Pomysł adaptacji narzdzia do specyfiki badanego obiektu ju na wstpnym etapie bada nie jest nowy – jest stosowany od dawna przez wiele czołowych firm, które tworz narzdzia klasy CASE-TOOLS (do których naley pakiet DIANA). Problem jednak ley w tym jak to zrobi.

Przewanie korzysta si z tzw. Repozytorium, które zawiera dane z wielu uprzednio przebadanych obiektów. Zadanie polega na dopasowaniu specyfiki danego obiektu do specyfiki którego z tych uprzednio przebadanych. Niestety, informacji na temat konkretnych rozwiza tego zadania brak – s objte tajemnic firmow (czemu, zreszt, nie ma co si dziwi). Natomiast po rednio mona oceni ich skuteczno , na podstawie raportów wdroeniowych – jest bardzo niska! Według wyników bada podanych przez Gartner Group – firm zajmujc si analiz rynku technologii informacyjnej [9], ponad 40% prób dopasowania t drog narzdzia do specyfiki badanego obiektu nie s trafne. Dlaczego, mona tylko domy la si - najbardziej prawdopodobne jest zbyt prymi-tywne korzystanie z zasobów Repozytorium. Dlatego obecnie prowadzone prace nad adaptacj pakietu DIANA do specyfiki aktualnie badanego obiektu skupiały si w pierwszej kolejno ci na opracowaniu skutecznych algorytmów nie tylko do przeszukiwania zasobów Baz Danych uprzed-nio przebadanych obiektów rzeczywistych (ponad 100) – tworzc w ten sposób Baz Wiedzy, ale równie do „inteligentnego” korygowania na bieco działania poszczególnych programów diagnozy i projektowania. Wydaje si, e wła nie tu drzemi najwiksze potencjalne moliwo ci zwikszenia skuteczno ci adaptacji pakietu DIANA do specyfiki aktualnie badanego obiektu. Wyniki testowania tych prób w najnowszej wersji narzdzia – pakiecie DIANA-11, wyranie na to wskazuj.

5. Wnioski

Próby stworzenia jednego, uniwersalnego pakietu DIANA dla dowolnego badanego obiektu nie powiodły si. Konieczno  uwzgldnienia specyfiki kadego z tych obiektów spowodowała stworzenie wielu mutacji pakietu DIANA. Zwizany z tym proces wprowadzania kilkuset modyfi-kacji w algorytmach, a nastpnie w programach pakietu DIANA wykazał z czasem nieracjonalno  takiego postpowania. Dlatego obecnie wybrano drog adaptacji pakietu DIANA do specyfiki danego obiektu ju na wstpnym etapie bada.

Bibliografia

1. Michalewski E.: Formalizacja wybranych funkcji systemu zarzdzania jednostk gospodarcz, Metody cybernetyczne w zarzdzaniu, Warszawa, 1974, str. 88-92, Wyd. Ossolineum, Wrocław 1978, str.81-93.

2. Michalewski E.: Some aspects of computer diagnostic analysis of the management systems, Control and Cybernetics vol.4, nr.3-4, 1975, str.31-38.

3. Michalewski E.: Computer-aided design of large-scale information systems, International Conference on systems Engineering, Coventry 1980, Sup. Part. 6.

4. Michalewski E.: Wspomagane komputerowo diagnoza i projektowanie systemów informacyjnych zarzdzania. Wydawnictwo: Wysza Szkoła Informatyki Stosowanej i Zarzdzania, Seria Monografie, (wyd. 2-gie uzupełnione), Warszawa, 2008.

5. Michalewski E.: Podstawy metody analizy diagnostycznej i projektowania systemów zarzdzania (metoda DIANA). Wyd. IBS PAN, Seria Badania Systemowe, tom 34, Warszawa 2004.

6. Michalewski E.: Methodology of analysis and design of information structure based on the use of microcomputer, Polish- Scandinavian Seminar „Current trends in information systems development methodologies”, Gdask, 1988.

7. Michalewski E.: Zastosowanie pakietu DIANA-9 jako CASE; Konf. Badania Operacyjne i systemowe BOS`91, Warszawa 1991.

POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 22, 2009

133

8. Michalewski E.: Pakiet DIANA-10 jako platforma integrujca specjalistów rónych dziedzin, Konf. Naukowa "Badania Operacyjne i Systemowe" BOS'95, Szczecin 1995, str. 250-259.

9. Integracja i systemy do zarzdzania; Raport „Teleinfo” nr 11, 1997.

10. Michalewski E.: Podrcznik uytkownika pakietu DIANA-11, Raport Badawczy RB/16/2008, IBS PAN, Warszawa 2008.

PROBLEM UNIFICATION DIANA PACKAGE

Summary

The problem, whether it should be one unified (universal) package DIANA for the any investigated object (enterprise, office, bank), or for each of them it is also necessary to create the suitable mutation of the package, was already in the first years of the existence of methodology DIANA (Computer-aided DIAgnostic ANAlysis and design of management systems). At first thought that the package should support all types of investigated object, however with time made necessary modifications of the package, taking into account the specific characteristics of the given object. Cur-rently works are developed to adapt the package to the specificity of the object at a preliminary stage of research. The paper discusses these periods the evolution of the package DIANA in more detail.

Keywords: computer decisions making systems, computer-aided tools for design of organization structure, information management systems

Edward Michalewski

Instytut Bada Systemowych PAN, Warszawa, Newelska 6