Konstrukcja aplikacji wspomagającej zarządzanie

ACTA UNIVERSITATIS LODZIENSIS FOL!A O ECONOM l 157, 2002

Robert A m b ro zia k’

KONSTRUKCJA APLIKACJI WSPOMAGAJĄCEJ

ZARZĄDZANIE

W a r ty k u le za w a rto k r ó tk i o p is m e to d y k i za r zą d za n ia k la s y M R P /E R P . o ra z p r z e d s ta w io n o p r z y k ła d o w e z a le ż n o ś c i te c h n o lo ­ g ic z n e zw ią z a n e z k o n s tr u k c ją sy s te m u w s p o m a g a ją c e g o z a r z ą ­ d z a n ie p rz e d s ię b io r s tw e m p rz e m y sło w y m . In th is p a p e r tlie M R P /E R P c la s s m a n a g e m e n t is p re s e n te d . T he e x a m p le o f s tr u c tu r e a n d te c h n ic a l a p p lic a tio n o f M R P /E R P sy ste m is a ls o p re s e n te d . W prow adzenie

W dzisiejszych bardzo konkurencyjnych czasach, w szelkie dobrze przem y­ ślane działania w sferze zarządzania inform acją, spraw na jej selekcja, oraz za­ pew nienie taniego do niej dostępu w pływ ają na rozwój firmy (przedsiębiorstw a). Żyjem y obecnie w wieku „inform acji”, która daje nam przew agę, a jej brak m o­ że być powodem naszego opóźnienia, co w konsekw encji m oże prow adzić do klęski finansow ej. Dzisiejszy „biznes” jest bardzo dynam iczny, nie pozw ala nam stawać w m iejscu, zm usza nas abyśm y w yprzedzali nasze obecne działania. Od wielu lat duże korporacje inw estują w kom puterow e system y zarządzania, które integrują całą infrastrukturę inform atyczną korporacji w jed en centralny system zarządzania. C zęsto inw estycje te sięgają lub naw et przew yższają kw oty kilku­ dziesięciu m ilionów dolarów , zatem stają się nieosiągalną barierą konkurencyj­ ności dla średnich lub małych przedsiębiorstw . W iększość średnich i małych firm w ykorzystuje pew ne system y w spom agania zarządzania, lecz dotyczy to przede wszystkim program ów księgowych, często nie udostępniających danych w sieci kom puterow ej, co uniem ożliw ia efektyw ne w ykorzystanie tych danych. Pozostałe funkcje - rozliczanie kosztów , kadry i płace, środki trw ałe, sprzedaż, gospodarka m ateriałow a, planow anie i zarządzanie produkcją, zarządzanie ja k o ­ ścią, rem onty i utrzym anie ruchu przedsiębiorstw a, zarządzanie przedsięw

ciam i i planow anie inwestycji - stosow ane są ju ż o wiele rzadziej. Należy pa­ miętać. że im w iększa organizacja, tym trudniej kierow nikom nad nią zapano­ wać, gdyż bardzo szybko rośnie stopień kom plikacji działania, tym w yraźniejsza zachodzi potrzeba kom puterow ego wsparcia. R ozpatrując oddzielnie logistykę, m arketing i finanse, popadając w nadm ierną specjalizację, traci się dystans nie­ zbędny do zarządzania. Kiedy czas i elastyczność decydują o pow odzeniu, lub klęsce przedsięw zięć, zintegrow ane system y w spom agania zarządzania są na­ rzędziem wprost wym arzonym . Przy rosnącej skali działania w pew nym m o­ m encie po prostu pojaw ia się konieczność w prow adzenia kom puterow ych sys­ tem ów zarządzania, które zw iększają zdolność szybkiej adaptacji do potrzeb klientów i rynków zbytu, co w dzisiejszych czasach jest decydującym czynni­ kiem konkurencyjności. Z często przeprow adzanych badań statystycznych w państw ach Unii Europejskiej wynika, że straty w ynikłe z niekom petentnych system ów zarządzania, tzn. nieefektyw nych metod składania zam ów ień, lub w ielokrotnego w prow adzania tych samych danych (inform acji), sięgają średnio 2% zysku[2]. N ajw iększą część czasu pracy pracow nika biurow ego pochłaniają czynności zw iązane z w ym ianą inform acji i kom unikacją. O becnie wiele firm decyduje się na wdrożenie bardzo zaaw ansow anych system ów , ale i kosztow ­ nych. Stosunkow o wysokie koszty w drożenia zw racają się zw ykle po trzech do pięciu lat, oczyw iście w przypadku większych firm, a ponoszone ryzyko według dośw iadczeń am erykańskich, do 60% wdrożeń kończy się niepow odzeniem , ale dotyczy to przede wszystkim specjalizow anych aplikacji pisanych na zam ów ie­ nie klienta i jest ceną przyszłego sukcesu.

Istota rozproszonej struktury organizacji polega przede w szystkim na zbli­ żeniu jednostek biznesow ych do rynku, oraz przynajm niej częściow ej decentra­ lizacji. System y w spom agające zarządzanie [l][2][8][7] pom agają przetw orzyć inform acje o działalności rozproszonej korporacji i budować spójne plany stra­ tegiczne, zgodnie z koncepcją "myśl globalnie, działaj lokalnie", zarządzać przede w szystkim inform acją.

Rozwój i standaryzacja system ów w spom agających zarządzanie

Przy opracow yw aniu profesjonalnych system ów najw ażniejsze je st opiera­ nie się na standardach, gw arantując w ten sposób współpracę różnych system ów , jak i m ożliw ość dość szybkiego przejścia użytkow ników z system u jednego producenta na inny. Standard M RP (M aterial R equirem ents Planning) [I][2][8] czyli m etoda Planow ania Potrzeb M ateriałow ych. M etoda M R P bierze swoje początki w późnych latach 50 tych, kiedy to opracow ano jej pierw szą w ersję - M R P I, w Polsce pierw sze systemy w spom agania zarządzania zaczęły pow sta­ wać w latach 70-tych. M etoda M RP I pozw ala obliczyć dokładną ilość m ateria­

łów i term inarz dostaw tak, aby sprostać ciągle zm ieniającem u się popytow i na poszczególne produkty, uw zględniając więcej niż je d n ą fabrykę. W jej now ­ szych im plem entacjach bierze się pod uwagę m.in. zam ów ienia spływ ające bez­ pośrednio od końcow ych odbiorców (end-user) oraz pośredników , prognozy sprzedaży i produkcji, stany m agazynów, zapisy księgow e i fakturow e. S tanda­ ryzacji dokonał J.A. Orlicky z firm y IBM w latach siedem dziesiątych.

Model M RP 1 najlepiej obrazują jego cele, a m ianowicie: > redukcja zapasów;

> dokładne określanie czasów dostaw surow ców i półproduktów ; > dokładne w yznaczanie kosztów produkcji;

> lepsze w ykorzystanie posiadanej infrastruktury, tzn. m agazynów , m ożliw o­ ści wytwórczych;

> szybsze reagow anie na zmiany zachodzące w otoczeniu; > kontrola poszczególnych etapów produkcji.

R ozszerzeniem specyfikacji M R P I było uw zględnienie C losed Loop M R P (zam knięta pętla sterow ania), czyli planow ania m ateriałow ych zdolności pro­ dukcyjnych w zam kniętej pętli procesu produkcyjnego.

M RP II (M anufacturing Resource Planning - Planow anie Z asobów Produk­ cyjnych)! 1 ][2J[8] to najpow szechniej obecnie stosow any, kom pleksow y system planow ania procesu produkcyjnego, ułatw iający koordynow anie pracy korpora­ cji, także lej o rozproszonej strukturze. W modelu M R P II większy nacisk w stosunku do poprzedniego został położony na rozbudow anie o elem enty zw ią­ zane z procesem sprzedaży i w spierające podejm ow anie decyzji na szczeblach strategicznego zarządzania produkcją. W m iarę rozw oju, specyfikacja M R P obejm ow ała kolejne obszary działalności przedsiębiorstw a, stając się stopniow o narzędziem kom pleksow ym . W modelu M RP II bierze się pod uw agę w szystkie sfery zarządzania przedsiębiorstw em zw iązane z przygotow aniem , planow aniem i kontrolą produkcji, oraz sprzedażą i dystrybucją w yprodukow anych produk­ tów.

W przypadku rozważań dotyczących im plem entacji m odelu M R P II w przem ysłow ych przedsiębiorstw ach produkcyjnych, m ożna w yłonić z opisu standardu następujące funkcje, które powinny być spełnione[ 1 ][2]:

> Sterow anie w arsztatem produkcyjnym . (Shop F loor C ontrol SFC) > Sterow anie stanow iskiem roboczym . (Input/O utput C ontrol l/O C ) > N arzędzia i pom oce warsztatowe. (Tooling Planning a n d C ontrol)

K olejnym krokiem przeistoczenia się m etodyki M R P był model ER P (E n ­ terprise Resource Planning - Planow anie Zasobów na p o trzeb y P rzedsię­

w zięć)[2], przez wielu zw ane po prostu M RP III (M oney Resource Planning - Planow anie Zasobów Finansowych).

Specyfikacja KRP w prow adzona była w życie w latach dziew ięćdziesią­ tych, a jej głównym celem jest uzyskanie m ożliwie jak najw iększej integralności podsystem ów infrastruktury inform atycznej przedsiębiorstw a na w szystkich szczeblach zarządzania.

System zarządzania klasy ERP powinien integrować następujące podsystemy: > obsługa klientów - (CRM , EDI).

> produkcja - (M R P I/11).

> finanse - księgow ość, raportow anie itp.

W związku z rozw ijającym się m arketingiem (sprzedażą) pojaw iło się nowe zapotrzebow anie na podsystem inform atyczny kategorii CRM (C ustom er R ela­ tionship M anagem ent) [7], czyli system ukierunkow any na analizę potrzeb klienta (baza inform acji o kliencie, jego preferencjach i upodobaniach z kom ­ pleksow ą analizą jeg o zachow ań aby wyjść mu naprzeciw z odpow ied nią o fer­ tą). Drugim pojęciem jest EDI (Electronic Data Interchange) - Elektroniczna W ymiana Danych, jest to standard stanowiący jed en ze składników system u logistycznego przedsiębiorstw a, wprow adzający bezpapierow ą ew idencję do­ kum entów. Technologie w spierające EDI są ciągle rozw ijane i ścisłe pow iązane ze zjaw iskiem e-com m erce, B2B itp.. W krajach Unii Europejskiej prom owany jest standard ED IFA C T[2] czyli EDI F or A dm inistration, C om m erce and Tra- sport. Do realizacji dokum entacji elektronicznej są w ykorzystyw ane formaty danych tekstowych um ożliw iające wielokrotne używ anie tych sam ych doku­ m entów w różnym kontekście i w różny sposób. Dokum enty w postaci elektro­ nicznej m ają najczęściej postać hipertekstu, czyli tekstu z dodanym trzecim w y­ miarem. Ten trzeci wym iar to m ożliwość w yróżniania fragm entów tekstu lub definiow ania go jako odnośnika (link ) do innej części dokum entu lub też innych publikacji. N astępną w ażną m ożliw ością hipertekstu jest w prow adzanie indek­ sów: tem atycznych, chronologicznych, indeksów autorów , osób itp. Indeksy m ogą być realizow ane w sposób z góry ustalony czyli „statycznie” albo „dyna­ m icznie” generow ane przez m echanizm y w yszukiw aw cze. O becnie najbardziej rozpow szechnionym formatem dokum entów elektronicznych jest H TM L (H y­ p ertext M ark-U p L anguage)[3]. W iększość form atów elektronicznego przecho­ w yw ania inform acji nie nadaje się do sporządzania dokum entacji służącej jako podstaw ę do różnych form prezentow ania czyli mających m ożliw ość autom a­ tycznego konw ertow ania ich do formatu aktualnej prezentacji czy form atu prze­ chow yw ania. Inform acja zaw arta w dokum entacji pow inna być poddana struktu- ralizacji co zapewniłoby efektyw ne i wielokrotne w ykorzystanie dokum entacji w wielu m ediach zapisu, przekazu lub prezentacji. Do opracow yw ania

doku-mciitacji posiadającej logiczną strukturę jest używ any standard SG M L (ang. Standard G eneralized M arkup Language) który został opublikow any w 1986 r. jako ISO 8879. SG M L służy do tw orzenia form alnych definicji struktury dla różnych typów dokum entów . C iągle trw ają prace nad unow ocześnianiem i tw o­ rzeniem form atów hipertekstow ych. N ajnow szą obecnie technologią struktural­ nego przechow yw ania i prezentacji informacji jest XM L (ang. e x te n sib le M ar­ kup Language), standard tej technologii nie został jeszcze odpow iednio określo­ ny i ciągle się rozwija. Praktycznie XM L jest następcą H T M L ’a, w yposażoną w strukturalną ogólną budowę. Inform acja zapisana za pom ocą X M L je st bar­ dziej ukierunkow ana na treść niż na prezentację niż w przypadku standardu HTM L. Istnieje wiele formatów elektronicznej dokum entacji, podczas projekto­ w ania aplikacji należy zastosow ać najbardziej standardow ą specyfikację form atu dokum entów tak, aby zapew nić ich wymianę z oprogram ow aniem innych nie­ zależnych producentów .

M odel aplikacji w spom agającej zarządzanie

Konstrukcję system u zarządzania trzeba rozpocząć od szczegółow ego planu projektow ego określającego m erytoryczne zastosow anie system u, zgodnie z czynnikam i organizacyjnym i, prawnym i i geograficznym i. W konstrukcjach przew idzianych do seryjnej sprzedaży (tzw. oprogram ow anie z półki), p rzezna­ czonych szczególnie dla m ałych firm. obierany jest ogólny uproszczony model infrastruktury tak aby spełnił on swe podstaw ow e wym agania. W tw orzeniu indyw idualnego projektu „na zam ów ienie” pow inny bardzo dynam icznie uczestniczyć osoby szczególnie zainteresow ane jeg o użytkow ym charakterem . Bardzo często w przypadku indyw idualnych projektów osoby zainteresow ane jak najlepszą użytecznością systemu nie m ają z góry precyzyjnie określonych wym agań. C zęsto zdarza się, że osoby z poza branży IT są błędnic przekonane że kom puter wykona za nie całą pracę, niestety rzeczyw istość jest inna i m aszy­ na m oże pom óc w pracy, ale tylko na tyle i w taki sposób w jaki nauczy j ą pro ­ gram ista. Aktywna w spółpraca ze strony przyszłych użytkow ników system u z konstruktoram i/program istam i doprow adziłaby zapew ne do w ypracow ania odpow iedniego kom prom isu, co przyczyniło by się istotnie do sukcesu w droże­ nia systemu.

Istnieje wiele trendów zw iązanych z konstruow aniem system ów w spom a­ gających zarządzanie, jednym z takich trendów jest oparcie się w yłącznie na zastosow aniach internetow ych, a ściślej zw iązanych z technologiam i w eb’owymi (W 3) [14j, takimi jak HTM L, DHTM L, Perl, Java. Takie rozw iąza­ nia posiadają wiele zalet (np. niezależność od platform y system ow ej), jedn ak posiadają także w iele wad, cała infrastruktura sieciow a jest bardziej obciążona

poprzez przesyłanie nie tylko istotnych danych, lecz także szeregu inform acji zw iązanych z w izualizacją tych danych. R ozw iązania takie w ym agają ciągłego połączenia z jednostka centralną, brak rozw iązań lokalnego buforow ania infor­ macji może mieć konsekw encje zw iązane z przestojem działalności w przypad­ ku aw arii m edium transm isji. N adm iarow ość danych nie jest w skazana ze w zględów na zw iększony koszt im plem entacji oraz utrzym ania m edium trans­ m isji, szczególnie wtedy gdy jednostka terenow a znajduje się w odległym od dużych aglom eracji miejscu np. stacje benzynowe. Nawet w przypadku lokalnej infrastruktury sieciow ej, nisko obciążone łącza mogą posłużyć do zaim plem en­ tow ania innych usług w spierających ogólno pojęte zarządzanie np. usług tele­ kom unikacyjnych, video konferencji, system ów kontroli dostępu i zabezpieczeń, video-m onitoring.

W dalszej części rozw ażane będą konstrukcje aplikacyjne zw iązane z sze­ roko pojętym zarządzaniem klasy ERP z naciskiem na w sparcie zarządzania produkcji (M RP). A p lik a c je - k lien ci in fra stru k tu ry b iu ro w e j A p lik a c je - k lien ci in frastru k tu ry p rz e m y sło w e j \T3 In fra stru k tu ra in te rn e to w a e -c o m m e rc e U słu g i lypu c u ll-c e n te r

&

K o m p u te ro w y c e n tra ln y ^— 7 s y ste m zarzą d z an iu ' E R P SE R W E R A p lik a c je - k lien ci in frastru k tu ry b iu r o b słu g i k lie n ta je d n o ste k tery to rialn y c h

Rys. 1 Uogólniony schemat systemu zarządzania.

A p lik a c je - k lie n c i in fre s ln ik lu ry m a g a z y n o w e j,

System y klasy ERP (Rys. 1) oprócz w spierania biurokracji przedsiębior­ stw a powinny w pełni integrować strategiczne podsystem y autom atyki przem y­ słowej, poprzez kom unikację z aplikacjami nadzorującym i etapy produkcji lub leż bezpośrednio z samymi urządzeniam i sterującym i tą produkcją, w ykorzy­ stując standardy przem ysłow e (np. kom unikacja szeregow a R S-485, protokół kom unikacyjny M O D B U S). Jako przykład m ożna sobie w yobrazić autom atycz­ ną linię pakow ania produktów , zintegrow aną z system em zarządzania, takie rozw iązanie da natychm iastow ą inform ację o ilości produktów gotow ych do sprzedaży.

Aby ja k najbardziej efektyw nie zintegrow ać urządzenia przem ysłow e z system em zarządzającym należy wykonać odpow iednie aplikacje pracujące w środow isku sieciow ym 1 [5]. O program ow anie w spom agające zarządzaniem przedsiębiorstw a w dzisiejszych czasach nie może ograniczyć się fizycznie tylko do jednego kom putera, zatem takie oprogram ow anie musi być aplikacją rozpro­ szoną’ [5] .

Istotą koncepcji aplikacji rozproszonej jest to, aby środow isko przetw arza­ nia danych z punktu w idzenia użytkow nika w yglądało jak przetw arzanie na lokalnej m aszynie, a topografia rozm ieszczenia kom puterów w sieci była niew i­ doczna. W praktyce operator takiego oprogram ow ania nie m a m ożliw ości stw ierdzenia gdzie i jak są przetw arzane lub przechow yw ane dane, czy to na lokalnym kom puterze czy też na kom puterze odległym (zdalnej m aszynie). Aby aplikacje rozproszone mogły ze sobą w spółpracow ać konieczne jest określenie m echanizm u kom unikacji. W w iększości dużych, średnich i m ałych firm (przed­ siębiorstw ), w ich w ew nętrznych sieciach kom puterow ych zastosow any jest protokół' T C P/IP 4 [5] spełniający m echanizm kom unikacji. T w orzone aplikacje rozproszone pow inny zatem w ykorzystyw ać usługę transpo rtow ą protokołu TCP/IP. Program iści w ykorzystujący ten protokół w sw oich aplikacjach nie m uszą znać szczegółów budowy tego protokołu, szczególnie w ażna je s t term i­

1 Sieć (network) nazywamy zestaw komputerów połączonych ze sobą mogących w zajem nie się komunikować, współdzielić korzystanie z urządzeń zewnętrznych, a także mieć dostęp do in­ nych sieci.

2 Aplikacją rozproszoną nazywamy taki zespól programów działających na różnych komputerach, współpracujących ze sobą poprzez sieć i realizujących określone zadanie przetwarzania danych. ’ Protokołem nazywamy zbiór z?sad, reguł, służących do wymiany danych (inform acji) pomiędzy

dw om a maszynami lub procesami - czyli programami dynam icznie wykonywanym i przez sys­ tem operacyjny.

4 TCP/IP (ang. Transport Control Protocol/Internet Protocol) jest to taki protokół komunikacyjny definiujący dolne warstwy sposobu komunikacji programów sieciow ych, szczególnie interneto­ wych.

nologia z nim zw iązana i nisko poziom ow y protokół adresow ania DP. Aby apli­ kacje mogły ze sobą współdziałać, program ista musi określić interakcję po m ię­ dzy program am i tworzącym i aplikację rozproszoną. Przebieg interakcji m iędzy program am i współpracującym i na warstwie transportow ej w ybranego protokołu kom unikacyjnego (np. TCP/IP) nazywam y protokołem aplikacyjnym (applica­ tion protocol). M ożna wyróżnić protokoły aplikacyjne standardow e i niestandar­ dowe. W praktyce za każdym razem , gdy program ista pisze now ą aplikacje ko­ rzystając z protokołu kom unikacyjnego, tworzy nowy protokół aplikacyjny. Protokoły aplikacyjne udokum entow ane w dokum entach RFC stają się standar­ dowym i protokołam i aplikacyjnym i [5] (standard application protocol), a w szystkie inne są niestandardow ym i protokołam i aplikacyjnym i (nonstandard application protocol). Ze standardow ych protokołów aplikacyjnych m ożna w y­ różnić np.: przesyłanie plików (file transfer), wysyłanie i odczytyw anie poczty elektronicznej (electronic mail), pracy na odległym kom puterze, czyli usługa telnet. M echanizm transportow y protokołu kom unikacyjnego T C P/IP um ożliw ia program iście jedynie naw iązanie kom unikacji i przesłanie danych pom iędzy dw om a aplikacjam i działającym i na lokalnym lub odległym kom puterze, zatem zapew nia on kom unikację pom iędzy rów no uprawnionym i partneram i zw aną partner-do-partnera (peer to peer com m unication). Program ista musi określić zasady prow adzenia interakcji, czyli zbudow ać protokół aplikacyjny. W prakty­ ce najczęściej stosuje się model organizacji aplikacji rozproszonych, korzystają­ cych z protokołu TC P/IP zwany jako model klient-serw er (client-server para­ digm ) [5]. Model ten stał się podstaw ow ym wzorem określania interakcji m ię­ dzy aplikacjam i korzystającym i z kom unikacji sieciowej partner do partnera. Podstaw ow ą potrzebą pow stania modelu klient-serw er było w yelim inow anie problem u naw iązyw ania połączenia pomiędzy aplikacjam i, zw anego problem em spotkań (problem o f randezvous). W protokole TC P/IP nie ma w budow anych m echanizm ów autom atyzacji inicjow ania połączenia, czyli aby program mógł odebrać inform ację musi na nią czekać. W m odelu klient-serw er rozróżniam y dw ie kategorie program ów, program kategorii klient, który naw iązuje połączenia (generuje zgłoszenie, żądanie w ykonania usługi), oraz program kategorii serwer, który ciągle oczekuje na naw iązanie połączenia generow anego przez program klienta dając mu odpowiedz. Program serw era jest znacznie trudniejszy do napi­ sania w stosunku do program u klienta. Serw er zazw yczaj musi obsłużyć w iększą liczbę program ów typu klient zatem musi mieć zagw arantow aną uprzyw ilejo­ w aną pracę w system ie dla zapew nienia optym alnej w ydajności. W iąże się to z zaim plem entow aniem w program ie serw era kontroli dostępu do danych i w e­ ryfikow ania uprawnień użytkow ników pracujących na program ach typu klient, poniew aż serw er pracuje w system ie operacyjnym jak o program uprzyw ilejow a­ ny to brak takich ograniczeń może doprow adzić do dziur w ochronie system o­

wego serw era na którym w ykonyw ać się będzie nasza aplikacja. Interakcja w aplikacji typu klient-serw er bazującej na protokole kom unikacyjnym TC P/IP jest połączeniow a (connection-oriented), zatem jest w pełni niezaw odna zarów ­ no w sieci lokalnej i rozległej. Program ista korzystając z technologii T C P nie musi m artw ić się o przebieg transm isji, kontrola dotarcia pakietów danych, ich kolejności, oraz szybkość przepływu danych w ykonyw ana je st autom atycznie. Kod protokołu T C P zaim plem entow any w system ie operacyjnym na, którym jest w ykonyw ana aplikacja spraw dza, czy każdy segm ent danych dotarł do odbiorcy, jeżeli nie to autom atycznie w ykonyw ana je st ponow na transm isja. Na podstaw ie sumy kontrolnej przesyłanych danych zachodzi kontrola w iarygodności danych. W celu w yelim inow ania duplikacji segm entów danych, oraz ich niew łaściw ej kolejności, każdy segm ent zostaje oznaczony num erem porządkow ym . W przy­ padku niem ożności podjęcia transm isji zarów no część aplikacji rozproszonej kategorii serw er jak i klient zostaje autom atycznie pow iadom iona. W przypadku projektow ania aplikacji w spom agających zarządzanie, lub w każdym innym przypadku aplikacji rozproszonej, gdy nie m ożna pozw olić sobie na utratę da­ nych należy odpow iednio zaprojektow ać interakcję opartą o protokół kom unika- cyjny TCP. Innym ważnym kryterium św iadczącym na korzyść protokołu T C P jest fakt m niejszego zaangażow ania pracy w tw orzoną aplikację, zm niejszeniu liczby program istów , skróceniu czasu opracow yw ania i im plem entacji protokołu aplikacyjnego, określającego interakcję w budowanej aplikacji rozproszonej. Dla zapew nienia skalow alności tworzonej aplikacji należy uw zględnić m ożliw ość zm ian num eru IP [5] oraz w ykorzystyw anego do naw iązania połączenia num eru portu, zarów no w program ie serw era jak i w program ie klienta. A plikacje um oż­ liwiające w prow adzanie strategicznych zmian w funkcjonalności technicznej noszą nazw ę program ów w pełni sparam etryzow anych (fully param eterized) [6].

Aby w iele program ów typu klient pracow ało ciągle z serw erem , czyli z punktu widzenia użytkow ników ich program y typu klient przetw arzały dane jak aplikacja lokalna w tym sam ym czasie, należy rozw ażyć i zdefiniow ać poję­ cie serw era w spółbieżnego. P odstaw ow ą jedn ostk ą zasobów i przebiegu prze­ tw arzania danych w program ach współbieżnych jest proces lub inaczej w ątek5. W system ie o przetw arzaniu w spółbieżnym wiele wątków , m oże w ykonyw ać tą samą, lub inną część kodu program u, każdy z w ątków m oże rozpocząć się, w strzym ać działanie lub zakończyć się w dowolnej chw ili i każdy z nich może przetw arzać dane z dow olną określoną przez program istę szybkością. O czyw i­ ście rów noległa praca wielu wątków, jest iluzją system u operacyjnego, który każdem u z wątków przydziela cyklicznie z bardzo du żą szybkością krótki czas

aktyw acji. Z punktu w idzenia człow ieka wątki działają jednocześnie. Istnieją także kom putery w ieloprocesorow e, które dzielą sobie sprzętow o w ykonyw anie w ątków pom iędzy procesory.

Serw er system u w spom agającego zarządzanie musi bezpiecznie przecho­ wywać dane oraz w efektywny sposób je udostępniać do edycji lub analiz. W szystkie dane są przechow yw ane w bazie d a n y c h ' którą z pow odzeniem m oż­ na nazw ać m ózgiem system u w spom agającego zarządzanie.

Technologia przechow yw ania danych rozw ija się praktycznie od sam ego początku kom puteryzacji. Przetw arzanie inform acji nie m oże odbyw ać się bez przechow yw ania danych w ejściow ych czy też rezultatów pew nych operacji. O becnie najefektow niejsze są relacyjne (R D B M S7) lub relacyjno-obiektow e bazy danych, w których dane przechow yw ane są w postaci rekordów , które wraz z odpow iednim i kluczam i, czyli indeksacją są połączone relacjam i, odzw iercie­ dlającym i odpow iednią strukturę danych reprezentującą potrzebne inform acje system u zarządzania. Poprzednie technologie oparte o proceduralne schem aty przetw arzania danych w bazie pracow ały niezaw odnie, gdy operacje na danych miały wyraźny logiczny początek i koniec. System y w spom agające zarządzanie, są środow iskam i transakcyjnym i, gdzie przetw arzanie danych odbyw a się, za pom ocą licznych zbiorów rekordów. Praca na pojedynczym rekordzie je st nie­ opłacalna, a wręcz kłopotliwa, dlatego należy stosow ać nieproceduralne sche­ maty przetw arzania danych.

System RDBM S spełnia następujące zadania :

> U trzym uje dane w określonej postaci, za pom ocą procedur niskiego pozio­ mu.

> P rzeprow adza w szelkie operacje we/wy zw iązane z plikam i, lub urządze­ niami, będącym i zasobami system u operacyjnego kom putera, na którym działa.

> Z apew nia m echanizm y dostępu do danych.

> Redukuje wszelkie anom alie w przechow yw aniu danych. > O ptym alizuje sposób przechow yw ania danych .

r Z apew nia spójność i integralność przechow yw anych inform acji.

Baza danych (database) jest to program przechowujący w określony sposób dane, umożliwiający ich udostępnianie w postaci rzeczywistej, lub przetworzonej. Programy tego typu możemy okre­ ślać terminem „serwera danych", lub „hurtownią danych”.

RDBMS (ang. Relational Database Management Systems)[51 jest relacyjny system zarządzania bazami danych, zwany potocznie serwerem baz danych lub hurtownia danych.

Projekt logiczny powinien być opracow yw any w raz z osobam i zaintereso­ wanymi pow stającym oprogram ow aniem , najlepiej nadaw aliby się eksperci z dziedziny w jakiej ma być używ ana baza danych. Ekspert pow inien określić sensow ny z uw zględnieniem dalszego rozwoju zestaw tabel i relacji, na podsta­ wie którego program ista (projektant aplikacji), mógł go w edług określonych technologii zakodow ać. Zespół ekspertów biorących udział w projektow aniu aplikacji wspom agającej zarządzanie, pow inien mieć praktyczną w iedzę z nastę­ pujących dziedzin [7]:

> Rachunkow ość i finanse przedsiębiorstw a (pełna księgow ość) > Logistyki przedsiębiorstw a.

> Z arządzania finansam i. > Z arządzania inwestycjam i. > Z arządzania zasobam i ludzkimi. > Z arządzania produkcją.

> łłan dlu i obrotu towarami w ew nętrznego i m iędzynarodow ego. > Praw a gospodarczego, podatkow e, celnego i praw pośrednich. > Z arządzania w arsztatem produkcyjnym (technolog produkcji)

W spółpraca zespołu ekonom istów z prawnikam i jest niezbędna, aby po­ wstała aplikacja była w pełni użyteczna, a przede w szystkim zgodna z po ­ w szechnie obow iązującym i przepisam i prawa. C ała ogólna konstrukcja aplikacji pow inna łączyć analitykę, a także kreatyw ność i intuicję. M odel bazy pow inien posiadać niezbędną ilość tabel nadm iarow ość jest niekorzystna, przy jed n o cze­ snym zachow aniu elastyczności, otwartości system u w przypadku późniejszych uaktualnień, czy tez ew entualnego rozwoju. Eksperci będący źródłem projektu logicznego, nie powinni być zdziw ieni rozw ojem ich dziedziny w czasie żyw ot­ ności aplikacji, pom ijając oczyw iście rew olucyjne zm iany. O gólnie w iadom o, że biurokracja jest zbudow ana poprzez szereg kom plikacji, m nogość w szelkiego typu dokum entów i form ularzy znacznie utrudnia zaprojektow anie system u w spom agającego zarządzanie. W projektow aniu odpow iedniej bazy danych kom plikacje w ynikają z [7]:

'r Słabego projektu logicznego, bez odpow iednio sform ułow anych atrybutów i priorytetów .

> Powiązań z innym i, ju ż istniejącym i niepraw idłow ym i system am i. > Rozwiązań budow anych na ograniczonych zasobach.

Zbyt uogólniony model danych spełniający próbę zadow olenia wszystkich użytkow ników , da w rezultacie model całkow icie znorm alizow any i czysty, ale tak potężny, że tylko niew ielka liczba użytkow ników jest wstanie go zrozum ieć.

Pew nym rozw iązaniem kom plikacji są zasady norm alizacji danych dostar­ czające odpow iednie testy dla modelu i określane term inem C A S E 8 [4]:

C ałkow icie znorm alizow any projekt pozw ala zapobiegać w iększości kom ­ plikacji zwanych z anom aliam i, które mogły by zagrażać przetw arzaniu i jakości przechow yw anych w bazie inform acji. Aby baza danych była znorm alizow ana, trzeba rozważyć, czy spełnia ona kilka warunków zw anych postaciam i:

Pierwsza p ostać norm alna określa brak pow tarzających się grup inform acji. Dane powinny być wartościam i elem entarnym i nierozkładalnym i. O czyw iście określenie wartości elem entarnej jest rzeczą um owną, charakterystyczną dla danego zagadnienia. Podstaw ow ym problem em baz danych jest redundancja, czyli nadm iarow ość, pow tarzalność danych. W przypadku aplikacji w spom aga­ jących zarządzanie musimy rozw ażnie podchodzić do redundancji, gdyż w wielu

przypadkach m usimy mieć pow tarzające się inform acje, co wiąże się z wym o­ gami ekonom icznym i i wym ogam i pow szechnie obow iązującego praw a. Przy­ kładem m ogą być w ystaw ione rachunki sprzedaży, kiedy to kontrahent zmieni choćby raz adres siedziby firmy w tym sam ym roku bilansow ym . W prow adzenie zmian adresu firmy w tym sam ym rekordzie spow odow ałoby, że w szystkie ra­ chunki uległy by zm ianie. Zachodzi zatem potrzeba redundancji danych dla za­ chow ania ich spójności w czasie, jest to szczególnie ważne, gdyż w szelkiego rodzaju dokum enty m uszą być przechow yw ane przez okres pięciu, a naw et dzie­ sięciu lat.

Niespójność inform acji w bazie danych określam y jak o anom alie [4]: A nom alie przy aktualizacji, anom alie przy w prow adzaniu danych (np. w m om encie gdy nie można w prow adzić danych klienta, który nic jeszcze nie kupił.), anom alie przy usuwaniu danych (np. w m om encie anulow ania trans­ akcji, m oże wystąpić usunięcie inform acji o kliencie.)

D ruga postać norm alna określa zależność wszystkich atrybutów , od jed n o ­ znacznego identyfikatora. Postać te stosuje się wyłącznie do tabel z unikalnym kluczem złożonym . Należy bardzo uw ażnie rozw ażyć znaczenie atrybutów , gdyż nie istnieją żadne metody pozw alające na autom atyczne w yznaczenie za­

C ASE*M ethod Entity Relationship Modeling, czyli zasady modelowania zw iązków encji Me­ toda ta została opracowana przez Richarda Barkera w 1989 r., procedura wymusza pewne uży­ teczne standardy modelowania danych, które zapobiegają nadmiarowi zbytecznych danych i po­ zw alają na utożsamienie modelu bazy z projektem fizycznym, co sprowadza się do całkowitego znormalizowania projektu logicznego.

leżności, lecz w ynikają one z wiedzy projektanta (eksperta) o naturze i zacho­ waniu danych w bazie.

Trzecia postać norm alna form ułuje tw ierdzenie że żadna wartość atrybutu nie będącego częścią klucza, nie zależy od innego atrybutu, nie będącego częścią klucza. Postać ta uniem ożliw ia określenie przez atrybuty sw oich wartości i jest najw ażniejszą z postaci. O dm ianą trzeciej postaci norm alnej jest postać norm al­ na B oyce’a-Codda. która jest najsilniejsza ze wszystkich znanych postaci nor­ malnych dla zależności nie wielow artościow ych.

Relację która nie spełnia zasady postaci B oyce’a-Codda, m ożna przekształ­ cić do tej postaci poprzez rozłożenie schematu relacji. O gólnie przyjęte jest, aby relacje spełniały przynajm niej trzecia postać norm alna, albo najlepiej postać norm alną B oyce’a-Codda, która nie zawiera redundancji, wszelkich anom alii oraz niezgodności.

Podczas wyboru bazy danych do im plementacji w system ie ważne je st aby w pełni w spierała technologię SQ L9, zapew niając efektyw niejsze żonglow anie danym i i przyspieszenie czas im plementacji, co wiąże się ze zm niejszeniem kosztów. Na rynku istnieje wiele technologii baz danych, w ybór wiąże się z charakterystyką przedsięw zięcia i oczyw iście z kosztam i w ykupienia licencji. W przypadku dużych przedsiębiorstw z pow odzeniem m ożna im plem entow ać kosztow ne produkty takie jak IBM DB2 [13], Oracle [I I ] , M icrosoft SQ L S er­ wer [12]. W przypadku większego nie obliczania się z kosztam i w ybór jest dość prosty, wszystkie produkty zapew niają wysokiej jakości technologię przetw a­ rzania danych, są niezależne od platform y( z w yjątkiem MS SQ L Serw er), oraz są opakow ane szerokim w achlarzem funkcji ułatw iających dość szybkie w dro­ żenie. Problem rozpoczyna się w przypadku „tanich” rozw iązań, przew idzianych dla małej lub średniej wielkości przedsiębiorstw , szczególnie w przypadku sys­ temów przew idzianych do seryjnej sprzedaży. I tu także m ożna znaleźć ciekaw e rozw iązania, stosując na przykład technologię C O D EB A SE [10] tanią i efek­ towną, lub zastosow ać system bazy danych M ySQL [9]. System ten je st bardzo ciekaw a pozycją, pom im o swej surowej prostoty w niektórych zastosow aniach może konkurow ać naw et z system em firmy Oracle. Posiada dość spore m ożli­ wości jak na cenę licencji nie przekraczającą 300$ USD, poniżej przedstaw ione są przykładow e m ożliwości:

r D ostępny na wielu platform ach (W indow s, Unix, Linux, FreeB SD , itp,). > Zapew niona praca w ielow ątkow a (m ulti-user).

J SQL (arig. Structured Query Language)[5] jest to strukturalny język zapytań zawierający stan­ dardowy zestaw poleceń służących do komunikowania się z w iększością najnow szych technolo­ gii baz danych RDBMS, dostępnych na rynku.

> Posiada wsparcie rozw ojow e dla wielu języków program ow ania (C, C++, Java, Perl, PHP.itp.).

> W pełni zgodny ze standardem ANSI SQL (S Q L 97). > W spiera kom unikację TCP/IP.

> 8-bajtow a reprezentacja liczb całkow itych.

5* Spraw dzone działanie w konfiguracji 60,000 tabel i 5,000,000,000 wierszy. System bazy danych M ySQ L [8] został pom yślnie spraw dzony w wielu aplikacjach Internetowych (portale), zatem pow inien spraw dzić się także w ap li­ kacjach w spom agających zarządzanie zw iązanych, także z e-com m erce, przew i­ dzianych dla nisko budżetow ych klientów.

Z akończyw szy pow yższe w stępne rozw ażania dotyczące aplikacji serw era przejdźm y do aplikacji typu klient. Z w cześniejszych rozw ażań wiem y że apli­ kacja klienta w celu uzyskania dostępu do danych, musi naw iązyw ać połączenie z aplikacją serwera, są to bardzo ważne aspekty technologiczne, jednak jest je sz ­ cze istotniejsza spraw a projektow ania aplikacji, dotycząca interfejsu użytkow ni­ ka. W przypadku aplikacji serw era którego użytkow anie należy pow ierzyć spe­ cjaliście z branży 1T, to w przypadku aplikacji typu klient, którą będ ą obsługi­ wali zwykli użytkow nicy (operatorzy kom putera) w ypadało by użyć graficznego interfejsu użytkow nika (G U I10) [6]. Zadow olenie końcow ych użytkow ników , nie m ający często praktycznie żadnej wiedzy inform atycznej, jest m iara przyszłego sukcesu konstruow anego system u. U żytkow nicy nie docenią projektanta aplika­ cji za skom plikow ane algorytm y przetw arzania danych oraz ciężką i m ozolną ich im plem entację. Nie widząc zachodzących procesów , będą osądzać aplikacje po jej wyglądzie zew nętrznym i sposobie użytkow ania, zatem należy pośw ięcić dość dużo czasu na opracow anie interfejsu użytkow nika, aby aplikacja została przyjęta przez w iększość użytkow ników z entuzjazm em , tylko w iększość, gdyż w szystkich nie da się zadowolić. Jeżeli chodzi o w ybór platform y operacyjnej dla projektowanej aplikacji klienta, należy zastosow ać platform ę rodziny W in­ dow s firmy M icrosoft [11]. Podczas tw orzenia aplikacji podstaw ow ym jej aspektem jest funkcjonalność i użyteczność dla przyszłego użytkow nika, dlatego trzeba poczynić wiele starań aby praca z program em była przyjem na lub choćby bezstresow a. System W indow s zdobył sobie ogrom ną popularność właśnie d zię­ ki przejrzystem u i mało skom plikow anem u interfejsow i, poprzez który uży t­ kow nik kom unikuje się z kom puterem . Jednym z głów nych aksjom atów pro­ jektow ania oprogram ow ania jest słynna zasada m inim alizacji szoku SM P

GUI ( Graphical User Interface) Metoda komunikacji pomiędzy użytkownikiem a komputerem realizowane, za pom ocą intuicyjnych graficznych symboli, nazywana graficznym interfejsem użytkownika.

(Shock M inim alization Principle). W edług zasady SM P oprogram ow anie po­ winno działać tak, aby m inim alizow ać szok w yw ierany na użytkow nika. Przed­ siębiorstw o z tak zbudow anego system też odniesie korzyści w ynikające z mniejszej potrzeby doskonalenia kadry pracow niczej, system y i produkty fir­ my M icrosoft są pow szechnie stosow ane na różnorodnych kursach i szkole­ niach, co znacznie obniża koszty wdrożenia. Istnieje wiele środow isk program i­ stycznych dla system ów operacyjnych rodziny W indow s jed n ak w skazane jest użycie M icrosoft Visual C ++ 6.0 lub M icrosoft Visual C # [12] dla nadchodzącej platform y W indow s .Net. T echnologia program ow ania obiektow ego C ++ lub C# daje dość proste m echanizm y łączenia funkcji przetw arzania danych z interfej­ sem użytkow nika, oraz transm isji danych, poprzez sieć kom puterow ą. Platform a W indow s daje duże m ożliwości wizualizacji danych poprze m ożliw ość osadza­ nia dokum entów innych aplikacji istnieje m ożliw ość integracji projektow anego system u z innymi program am i zw iązanym i z edycją dokum entów (np. MS O ffi­ ce) lub aplikacjam i wspom agającym i projektow anie (np. A utoC A D ) co znacznie uspraw ni proces obiegu dokum entacji i podniesie walory użytkow e projektow a­ nego system u, tak aby spełnić oczekiw ania klient. A utonom iczne aplikacje pra­ cujące pod kontrolą systemu W indow s mogą też łatw o w spółpracow ać z urzą­ dzeniam i zew nętrznym i takimi jak drukarki fiskalne, czytniki kodów kresko­ wych, oraz z urządzeniam i stosow anym i w autom atyce przem ysłow ej.

W nioski

Projektow anie aplikacji w spom agającej zarządzanie przedsiębiorstw em przem ysłow ym jest dość skom plikow ane, wym aga od konstruktorów ogrom nej wiedzy praktycznej. Złożoność integracji podsystem ów ekonom icznych i prze­ m ysłow ych nastręcza w iele problem ów i wym aga wielu kom prom isów .

W związku z stosow aniem różnego rodzaju technologii produkcyjnych, każde przedsiębiorstw o jest inne i nie m ożliwe je st sprecyzow anie jednolitego modelu aplikacji w spom agającej zarządzanie, a ciągły postęp technologiczny wywiera nacisk na otw artość system u, w celu późniejszych m odyfikacji, szcze­ gólnie infrastruktury przem ysłow ej.

Źródła

1. Darryl V. Landvater, Christopher D. Gray „M RP II Standard System"', O liver Wight Publica­ tions, 1989

2. M. Janiec „Komputerowe systemy wspomagania zarządzania klasy MRP/ERP"', Akademia Ekonomiczna w Krakowie, 1997.

3. MSDN Library Visual Studio 6.0+,,Microsoft Windows User Experience" dokum entacja techniczna.

4. Hans Ladanyi „SQL Księga eksperta"', W ydawnictwo HELION.2(XX)

5. Douglas E. Comer, David L. Stevens „Internetworking with T C P /IP "’, Department o f Com ­ puter Sciences Purdue University, West Lafayette, IN 47907

6. John Robbins „Debugging Applications"', Microsoft Press,2001

7. R. Ambroziak „ Tworzenie oprogramowania wspomagającego zarządzanie przedsiębiorstwem przy użyciu pakietu M S Visual C + + 6.0"\ Katedra Informatyki Stosowanej PL ,2000, dyplo­ m owa praca magisterska.

8. Adamczewski J., Zintegrowany system informatycznego zarządzania, „Logistyka”, nr 4, 1997. 9. www.mvsal.com 10. www.codebase.com 11. www.oracle.com 12. w w w. mi crosoft .com 13. www.ibm.com 14. www.w3.ort;