NR 611 STUDIA INFORMATICA NR 26 2010
JERZY MARCINKIEWICZ
PODEJŚCIE PROCESOWE
W ROZWOJU SYSTEMÓW INFORMACYJNYCH FIRM
Wprowadzenie
Podejście procesowe w zarządzaniu organizacjami upowszechnia się inten-sywnie od początku lat dziewięćdziesiątych XX wieku. Początkowo było zwią-zane z techniką reengineeringu1, którego prekursorem był M. Hammer. Określił on ten sposób działania organizatorskiego jako „fundamentalne przemyślenie i radykalne przeprojektowanie procesów w fi rmie, prowadzące do przełomowej poprawy wyników osiąganych przez fi rmę – przy zastosowaniu współczesnych miar osiąganych wyników (koszty, jakość, szybkość, serwis)”2. Głównym po-jęciem tej techniki modernizowania funkcjonowania fi rm jest proces. Reen-gineering koncentrował się na radykalnym przeprojektowywaniu procesów. W pewnym stopniu jest w nim dokonywana zmiana sposobu zarządzania organi-zacjami – przez koncentrację działań na przebiegających w nich procesach biz-nesowych.
Żeby uzyskać rzeczywistą poprawę efektywności funkcjonowania, organi-zacje, w których przeprowadzono reengineering po raz pierwszy, powinny stoso-wać tę logikę modernizacji fi rmy w dalszym ciągu. Systematyczna reorganizacja procesów staje się wówczas integralną częścią jej funkcjonowania i jest określa-na terminem „zarządzanie procesami biznesowymi” (BPM – Business Process
1 M. Hammer, J. Champy, Reengineering w przedsiębiorstwie, Neuman Management Institut,
Warszawa 1996.
Management)3. Obecnie jest to typowy sposób działania wielu dobrze zorganizo-wanych przedsiębiorstw i organizacji.
Poza orientacją na procesy zachodzące w organizacji, jedną z charaktery-stycznych cech BPM jest koncentracja na trzech składnikach każdego procesu: – zasobach ludzkich i ich optymalnym wykorzystaniu w realizacji procesu, – danych i informacjach niezbędnych do realizacji procesów,
– optymalnie wykorzystanych technologiach, w tym technologiach teleinfor-matycznych.
Twórcy techniki reengineeringu i późniejszego podejścia BPM przyjmowali założenie, że technologia teleinformatyczna jest coraz tańsza i łatwiej dostępna, a więc jej zastosowanie w procesach biznesowych jest coraz prostsze. Jednym z celów zarządzania procesami biznesowymi jest zapewnienie optymalnego wy-korzystania technologii teleinformatycznych w procesach organizacji.
1. Przesłanki upowszechniania podejścia procesowego w tworzeniu aplikacji informatycznych
Przedstawiony sposób realizacji podejścia procesowego oznacza, że mo-dernizacja procesów stanowi podstawę do zdefi niowania wymagań organizacji wobec nowych rozwiązań informatycznych, które mają wspomagać doskonalo-ne procesy bizdoskonalo-nesowe. W warunkach stosowania podejścia BPM zmianie ulega sposób realizacji wstępnych etapów cyklu rozwoju aplikacji informatycznych. Można założyć z góry konieczność wykorzystania podejścia kaskadowego do realizacji projektu informatycznego. Miejsce modernizacji procesów w cyklu rozwoju aplikacji informatycznych zaprezentowano na rysunku 1.
Analizując zależność zarządzania procesowego i realizacji projektów infor-matyzacji w organizacjach, można zauważyć, że
– specyfi kacja większości wymagań użytkowników jest zawarta w modelach i projektach modernizacji procesów biznesowych,
– projekty modernizacji procesów zawierają w sobie założenia i rozwiązania dotyczące architektury modernizowanego rozwiązania informatycznego.
Można więc sformułować wniosek, że proces budowy systemu informa-tycznego – skutecznie obsługującego procesy biznesowe fi rmy – powinien się koncentrować na konstruowaniu takiej architektury rozwiązania, która będzie
skutecznie „obsługiwać” procesy biznesowe zachodzące w organizacji. Jest to podstawowa przesłanka stosowania podejścia procesowego, również w pro-cesie rozwoju zastosowań informatycznych.
Rys. 1. Miejsce podejścia BPM w procesie rozwoju systemów informatycznych fi rmy Źródło: opracowanie własne na podstawie Inżynieria systemów informatycznych
w e-gospodarce, red. E. Kolbusz, W. Olejniczak, Z. Szyjewski, PWE,
Warsza-wa 2005, s. 156.
Istotne zmiany dotyczące podejścia procesowego w organizacjach można też zaobserwować w technologiach przetwarzania, stosowanych w systemach informatycznych fi rm. Upowszechnienie technologii obiektowej i związanej z nią „architektury brokera obiektów programowych” (na przykład standardu CORBA)4 spowodowało zainicjowanie rozwoju architektury serwowania usług SOA (Service Oriented Architecture).
SOA nie jest konkretnym produktem. Jest to styl architektury stosowany w technologii informatycznej fi rm. Jego realizacja wymaga jednak zastosowania nowych technologii informatycznych. SOA jest też określana jako standardowa 4 G. Lausen, G. Vossen, Obiektowe bazy danych – modele danych i języki, WNT, Warszawa
metodologia organizacji i projektowania, wiążąca ściśle technologię informa-tyczną fi rmy z jej procesami biznesowymi5. Rozproszony zestaw usług jest wy-korzystywany do wspomagania poszczególnych procesów biznesowych. Usługa nie jest jednak tożsama z procesem biznesowym. Proces fi rmy będzie związany z wieloma usługami. Można więc sformułować wniosek, że zaprojektowanie optymalnej obsługi informatycznej procesów biznesowych przez architek-turę SOA wymaga orientacji procesu projektowania na procesy biznesowe fi rmy.
W ostatnich latach pojawiło się kolejne zjawisko w obszarze obsługi pro-cesów biznesowych przez technologie informatyczne. Pojawiają się rozwiąza-nia zwane systemami zarządzarozwiąza-nia procesami biznesowymi. Stanowią one kompleks metod, technik i narzędzi umożliwiający kontrolę nad całym proce-sem zarządzania procesami biznesowymi. Pozwalają one na oddzielenie logiki biznesowej od podstawowej infrastruktury informatycznej6. W efekcie uzysku-je się warunki do szybkiego tworzenia aplikacji obsługujących systematycznie modernizowane procesy organizacji. Ten rodzaj rozwiązań programowo-orga-nizacyjnych jest dopiero we wstępnej fazie rozwoju, mając jednak na uwadze zakres upowszechniania się podejścia procesowego w zarządzaniu organizacja-mi, można stwierdzić, że ten sposób tworzenia i zarządzania rozwiązaniami in-formatycznymi w fi rmach będzie się intensywnie poszerzać. W związku z tym konieczne staje się rozwijanie metod budowy rozwiązań informatycznych zorientowanych na procesy.
Trzy przedstawione zjawiska: upowszechnienie się podejścia procesowego w zarządzaniu organizacjami, opracowanie architektury SOA i rozwój systemów zarządzania procesami biznesowymi – stanowią przesłanki do rekonstrukcji ar-chitektury systemów informatycznych z jednej strony oraz do zmian w metodach rozwoju rozwiązań informatycznych zorientowanych na obsługę procesów za-chodzących w fi rmach z drugiej.
5 J. Muszyński, SOA – Usługi na pierwszym miejscu, www.networld.pl/artykuly/druk/50939/
SOA.uslugi.na.pierwszym.miejscu.html.
6 J. Muszyński, B. Silver, BPM usprawnia procesy w biznesie, www.networld.pl/artykuly/
2. Założenia architektury systemów informatycznych zorientowanych na procesy
Rozwój podejścia obiektowego w budowie systemów informatycznych, po-czynając od początku lat dziewięćdziesiątych XX wieku, zapoczątkował okres istotnych zmian w architekturze systemów informatycznych. Na rysunku 2 za-prezentowano próbę uogólnienia tych zachodzących zmian.
Rys. 2. Ewolucja architektury systemów informatycznych Źródło: opracowanie własne.
Pierwszą formą architektury, która była wynikiem upowszechnienia po-dejścia obiektowego tak w sferze konstrukcji oprogramowania, jak i sposobu tworzenia aplikacji informatycznych, jest rozwiązanie oparte na logice broke-ra obiektów. Broker obiektów udostępnia aplikacjom obiekty zlokalizowane na przestrzennie rozproszonych serwerach obiektów. Każdy udostępniany obiekt ma swoją uogólnioną defi nicję w repozytorium brokera obiektów. Najbardziej rozpowszechnionym standardem jest CORBA (Common Object Request
Bro-ker Architecture)7. Należy stwierdzić, że pomimo zaproponowania kolejnych form technologicznych, architektura brokera obiektów jest stosowana w dosyć ograniczonym zakresie. Wynika to z konieczności tworzenia oprogramowania w językach obiektowych, wykorzystania oprogramowania brokera obiektów i uogólnionej defi nicji serwowanych obiektów programowych i ich interfejsów.
Architektura zorientowana na usługi (SOA) stanowi rozwinięcie rozwiązań zaproponowanych w architekturze brokera obiektów. Tak jak już wspomniano, jest ona traktowana jako zbiór zasad i praktyk tworzenia aplikacji, aby można było z niej korzystać jako z zestawu usług. Defi nicje oferowanych w niej usług są bardziej abstrakcyjne niż obiektów w architekturze brokera obiektów. Usługa może być dowolnym fragmentem oprogramowania (nie tylko obiektem), napisa-nym nie tylko w obiektowym języku programowania. Warunkiem jest wyposaże-nie w interfejs umożliwiający wywoławyposaże-nie i określewyposaże-nie sposobu jej wykonywania. Usługa powinna być zdefi niowana tak, by każdy użytkownik korzystał z niej na wymaganym poziomie szczegółowości8.
Architektura SOA rozwija trzy koncepcje zapoczątkowane w architekturze brokera obiektów9:
– Wirtualizację usług – usługa jest traktowana jako fragment kodu, który może być wywołany przez użytkownika za pośrednictwem publikowanego interfejsu metadanych.
– Usługi wielokrotnego użytku, które powinny być defi niowane na wysokim poziomie abstrakcji, bez wikłania w usługę kodu aplikacyjnego. Każda usłu-ga powinna mieć rozpoznawalną funkcję biznesową, na przykład weryfi kacja tożsamości. Programiści, przygotowując nową aplikację, powinni tworzyć jak najmniej nowego kodu, maksymalnie wykorzystując wcześniej zdefi nio-wane usługi.
– Brokera usług – oprogramowania umożliwiającego uniwersalną defi nicję usługi oraz zarządzającego udostępnianiem usług.
Realizacja architektury SOA wymaga zastosowania odpowiednich narzędzi programowych. Najczęściej wymienia się następujące warstwy oprogramowa-nia:
7 G. Lausen, G. Vossen, Obiektowe bazy danych..., s. 179–189.
8 P. Schmidt, Modelowanie procesów w ramach systemów SOA, 4PM Project Management,
www.4pm.pl/artykul/modelowanie_procesow_w_ramach_systemow_soa.html.
– brokerzy usług,
– motory aranżacji aplikacji,
– środowiska warstw pośredniczących opartych na wymianie wiadomości – oraz narzędzia zarządzania usługami.
Na rysunku 3 zaprezentowano ogólną wielopoziomową architekturę SOA, zaproponowaną przez M.P. Papazoglou i D. Georgakopulos.
Rys. 3. Ogólna architektura SOA
Źródło: M.P. Papazoglou, D. Georgakopoulos, Service-Oriented Computing, “Commu-nication of the ACM” 2003, vol. 46.
Przedstawiona architektura świadczy o kolejnej ewolucji, jaka ma miejsce w ramach modelu SOA. Jako usługę oferuje się użytkownikowi gotowe opro-gramowanie, które użytkownik może nabyć i uruchomić, korzystając z infra-struktury usługodawcy. Rozwiązanie to jest określane jako SaaS (Software as a Service). Określenie to pierwszy raz pojawiło się w 2005 roku i stanowi nowy nurt w udostępnianiu oprogramowania użytkownikom10. Zaczyna ono być sto-sowane również przez dużych producentów klasycznego oprogramowania do zarządzania fi rmami, na przykład przez fi rmę SAP11. Usługi zarządzania zapre-zentowane na rysunku 3 mogą być udostępniane na zasadzie SaaS.
10 M. Małyszko, SAAS jako metoda świadczenia e-usług, Państwowa Agencja Rozwoju
Przed-siębiorczości, Warszawa, www.web.gov.pl/g2/big/2009_03/c6dfab4e6f795ca260afdc0c04f5f5c7. PDF.
11 J. Żeliński, Analizy: oferta SaaS nieco wyprzedza świadomość użytkowników, www.zelinski.
Kolejny istotny etap ewolucji architektury jest wymuszony przez upo-wszechnianie się podejścia procesowego. Architektura zorientowana na zarzą-dzanie procesami stanowi rozwinięcie architektury SOA na obsługę kompletnych procesów biznesowych w fi rmie (rysunek 2). Użytkownik uzyskuje narzędzia, za pomocą których może defi niować swoje modele procesów, korzystając z istnie-jących usług (komponentów programowych), a także uzyskiwać ich wersję wy-konawczą i zarządzać tak zinformatyzowanymi procesami. Wdrożenie takiego rozwiązania wymaga wykorzystania specjalnego narzędzia zwanego systemem zarządzania procesami biznesowymi (SZPB). Jest to kompleks narzędzi progra-mowych, metod i technik umożliwiających kontrolę nad całym cyklem zarzą-dzania procesami biznesowymi. Logikę zarzązarzą-dzania procesami biznesowymi za pomocą takiego narzędzia zaprezentowano na rysunku 4.
Rys. 4. Cztery fazy zarządzania procesami biznesowymi
Źródło: opracowanie własne na podstawie J. Muszyński, B. Silver, BPM usprawnia
procesy...
Zakłada się tutaj wyodrębnienie w cyklu życia procesu czterech faz:
1. Modelowanie nowej wersji procesu na podstawie analizy funkcjonowania dotychczasowej wersji.
2. Generowanie projektu procesu z wykorzystaniem narzędzi programowych systemu.
3. Wdrażanie rozwiązania przez włączenie aplikacji procesu w strukturę opro-gramowania.
4. Zarządzanie użytkowaniem aplikacji procesu z rejestrowaniem efektywności przebiegu, analizą przypadków specjalnych i ich rozwiązywaniem.
Zgromadzone dane o przebiegu procesów są podstawą do obliczania wskaź-ników efektywności i do uruchomienia kolejnego cyklu modernizacji procesu biznesowego. Tak rozpatrywana architektura pozwala na oddzielenie logiki biz-nesowej od infrastruktury informatycznej na podobnej zasadzie, jak to nastąpiło w odniesieniu do danych – w okresie upowszechniania się technologii baz da-nych w latach siedemdziesiątych.
Zakres rozwiązań stosujących tego typu architekturę jest stosunkowo nie-wielki, wyraźnie się jednak poszerza. Najczęściej rozwiązania kompleksowego zarządzania procesami biznesowymi rozwijają się równolegle z eksploatacją ty-powych systemów informatycznych zarządzania fi rmami.
3. Podejście procesowe w metodach rozwoju systemów informatycznych Jest rzeczą oczywistą, że szersze stosowanie architektury zorientowanej na procesy wymaga stosowania odpowiednich metod do tworzenia aplikacji zorien-towanych na procesy i do zapewnienia efektywnego zarządzania cyklem życia procesów. Dokonany przez autora przegląd metod rozwoju aplikacji wyraźnie wskazuje, że orientacja na procesy nie znalazła jeszcze właściwego miejsca w metodach inżynierii oprogramowania i inżynierii wymagań. Przyczyną może być stosunkowo niedawna (lata dziewięćdziesiąte), głęboka zmiana w tym ob-szarze, spowodowana szerokim zastosowaniem podejścia obiektowego. Jedna z najbardziej znaczących metod rozwoju aplikacji RUP (Rational Unifi ed Process) w swojej aktualnej wersji koncentruje się na12
– zastosowaniu podejścia obiektowego w budowie aplikacji informatycznych, wykorzystując mechanizmy języka UML,
– wykorzystaniu iteracyjnego sposobu rozwoju aplikacji,
– zapewnieniu optymalnej struktury procesu tworzenia rozwiązania informa-tycznego.
Z punktu widzenia metody, tworzona aplikacja informatyczna obsługuje przypadki użycia. Metoda nie uwzględnia procesu biznesowego jako obszaru
obsługi organizacji przez system informatyczny. Podobna sytuacja ma miejsce w innych metodach rozwoju, stosujących podejście obiektowe. Procesy bizneso-we nie są w nich punktem odniesienia w procesie specyfi kacji wymagań organi-zacji (użytkowników) wobec zastosowań informatycznych13.
Również środowisko badawcze zajmujące się problematyką inżynie-rii wymagań stosunkowo mało uwagi poświęca procesom biznesowym jako źródłom defi niowania wymagań organizacji14. Jeżeli metoda inżynierii wymagań jest prezentowana jako „zorientowana procesowo” – oznacza to położenie naci-sku na organizację procesu specyfi kacji wymagań, a nie na identyfi kację wyma-gań związanych z poszczególnymi procesami biznesowymi organizacji.
W sferze zarządzania proces biznesowy jest rozpatrywany jako sieć działań, których realizacja ma pozwolić na osiągnięcie wyznaczonego celu, dostarcza ona wartość dodaną odbiorcy (klientowi lub pracownikowi). W inżynierii wymagań najczęściej potrzeby użytkowników są analizowane na poziomie elementarnych działań składających się na proces. Będą to konkretne czynności, na konkretnym stanowisku. Inaczej więc jest postrzegana rola zarządzania procesami przez spe-cjalistów ze sfery zarządzania, inaczej przez analityków-projektantów aplikacji informatycznych.
W odróżnieniu od metod rozwoju, podejście procesowe jest bardziej kom-pleksowo uwzględniane w narzędziach zarządzania procesami biznesowymi niż w metodach specyfi kacji wymagań i konstruowania aplikacji informatycznych stosowanych przez producentów oprogramowania użytkowego dla fi rm. Kilku producentów oprogramowania BPM doprowadziło do rozwinięcia standardo-wej notacji modeli procesów (technika BPMN)15 oraz do opracowania języków obsługujących tę notację: BPEL i XDPL16. Postulat konieczności opracowania standardowego języka modelowania procesów pojawiał się już na początku XX1 wieku17. Języki tego typu powinny być pomostem między defi nicją procesu z punktu widzenia organizacji a formalną defi nicją procesu w obsługujących je aplikacjach informatycznych.
13 I. Sommerville, Inżynieria oprogramowania, WNT, Warszawa 2003, s. 146–167.
14 Por. 16th IEEE International Requirements Engineering Conference, RE 2008, 8–12
septem-ber, Barcelona, IEEE Computer Society 2008, Bibtex.
15 S.A. White, Introduction to BPMN, “BP Trends”, July 2004,
www.bptrends.com/publication-fi les/07-04%20WP%20Intro%20to%20BPMN%20-%20White.pdf.
16 J. Muszyński, B. Silver, BPM usprawnia procesy...
17 H. Smith, P. Fingar, Business Process Management: The Third Wave, Technical Excerpt
Interesującym obszarem rozwijania technik modelowania procesów bizne-sowych i specyfi kacji wymagań wobec obsługujących je procesów biznebizne-sowych są narzędzia informatyczne wspomagające modernizację procesów biznesowych w fi rmach. Przykładami mogą tu być ARIS i ADONIS18.
W jednym z nielicznych opracowań zajmujących się „orientacją proceso-wą” na etapie specyfi kacji wymagań autorzy próbują znaleźć metodę wiążącą wymagania szczegółowe poszczególnych procesów biznesowych z funkcjami przyszłego rozwiązania informatycznego. Stosuje się do tego specjalną macierz, w której na skrzyżowaniu defi nicji wymagania szczegółowego procesu i funkcji systemu określa się specyfi kację rozwiązania szczegółowego w ramach funkcji systemu informatycznego19. Proponowane rozwiązanie opiera się jednak w swo-ich założeniach na klasycznej strukturalnej architekturze rozwiązania informa-tycznego.
Podsumowując dotychczasową analizę, można zdefi niować następujące wnioski:
– dotychczas brakuje kompleksowych metod wspomagających tworzenie zastosowań informatycznych, nastawionych na obsługę procesów bizne-sowych fi rmy;
– coraz częściej sygnalizuje się potrzebę dysponowania takimi metodami, które poza zwiększeniem efektywności obsługi informatycznej procesów, dodatkowo ułatwiałyby wdrażanie i użytkowanie w fi rmie systemu zarzą-dzania procesami biznesowymi (SZPB);
– zadaniem, od którego należałoby rozpocząć rozwijanie takiej metody, powin-no być opracowanie metody specyfi kacji wymagań procesów biznesowych wobec systemów informatycznych lub szerzej – wobec obsługujących pro-cesy rozwiązań technologicznych.
Proponowana metoda (podejście) specyfi kacji wymagań procesów bizneso-wych powinna mieć następujące cechy:
1. Metoda stanowiłaby połączenie procedury modernizacji procesów bizneso-wych i specyfi kacji wymagań tych procesów wobec obsługujących je rozwią-zań informatycznych.
18 J. Rutkowska, Podejście procesowe a technologia informatyczna według metodologii ARIS i ADONIS, Uniwersytet Warszawski, www.wszin-sochaczew.edu.pl.
19 T. Arao, E. Goto, T. Nagata, „Business Process” Oriented Requirements Engineering Pro-cess, Proceedings of the 13th International Conference on requirements Engineering, IEEE
2. Powinna się opierać na określonym modelu procesów, wykorzystującym no-tację grafi czną. Model i zastosowana notacja powinny zapewniać modelo-wanie różnych klas procesów – poczynając od procesów technicznych fi rmy, kończąc na procesach podejmowania decyzji. Powinny one też zapewniać opis procesu tak z punktu widzenia użytkowników, jak i zespołu realizujące-go projekt. Wynika z terealizujące-go wniosek, że model powinien zapewniać również możliwość opisu wymaganych rozwiązań teleinformatycznych oraz infra-struktury technicznej, w której jest lub będzie realizowany proces. Rozwią-zaniem, które powinno być wzięte pod uwagę przy wyborze modelu, jest – coraz szerzej stosowana w modelowaniu procesów biznesowych – technika modelowania BPMN20.
3. Z zastosowaną techniką modelowania powinien być związany sformalizowa-ny język opisu procesów, który powinien stanowić mechanizm opisu procesu w ramach oprogramowania zarządzania procesami biznesowymi, zgodnie z logiką przedstawioną w poprzednim punkcie. Jednym z możliwych rozwią-zań byłoby zastosowania języka BPEL, opracowanego na potrzeby notacji BPMN.
4. Metoda powinna określać sposób postępowania zapewniający skuteczną identyfi kację procesów, ich szczegółowy opis, proponowaną modernizację oraz sposób wykorzystania rozwiązania informatycznego w poszczególnych działaniach składających się na proces.
5. Powinna ona określać również formy udziału przyszłych użytkowników. Jako że metoda specyfi kacji powinna być jednocześnie metodą modernizacji procesów biznesowych – udział przyszłych użytkowników powinien być de-cydujący.
6. Metoda powinna również proponować zestaw standardowych miar jakości i efektywności przebiegu procesu oraz sposobu ich ustalania. Zespół wyko-nawczy mógłby dobierać miary w zależności od analizowanego procesu i na tej zasadzie, opierając się na symulacji, dokonywać wstępnej oceny propono-wanych rozwiązań informatycznych w ramach jednego lub kilku procesów.
Upowszechnianie logiki zarządzania procesami biznesowymi w funkcjono-waniu organizacji zmusza do kompleksowej realizacji podstawowego postulatu tak reengineeringu, jak i techniki zarządzania procesami biznesowymi – opty-malnego wykorzystania technologii teleinformatycznych. Metody rozwoju
temów informatycznych zorientowane w swojej strukturze na procesy ułatwią realizację tego postulatu.
Literatura
16th IEEE International Requirements Engineering Conference, RE 2008, 8–12
Septem-ber, Barcelona, IEEE Computer Society 2008, Bibtex.
Arao T., Goto E., Nagata T., „Business Process” Oriented Requirements Engineering
Process, Proceedings of the 13th International Conference on requirements
Engi-neering, IEEE Computer Society 2005.
Hammer M., Champy J., Reengineering w przedsiębiorstwie, Neuman Management Institut, Warszawa 1996.
Inżynieria systemów informatycznych w e-gospodarce, red. E. Kolbusz, W. Olejniczak,
Z. Szyjewski, PWE, Warszawa 2005.
Kruchten P., Rational Unifi ed Process, WNT, Warszawa 2007.
Lausen G., Vossen G., Obiektowe bazy danych – modele danych i języki, WNT, Warszawa 2000.
Małyszko M., SAAS jako metoda świadczenia e-usług, Państwowa Agencja Rozwoju Przedsiębiorczości, Warszawa, www.web.gov.pl/g2/big/2009_03/c6dfab4e6f795 ca260afdc0c04f5f5c7.PDF.
Muszyński J., Silver B., BPM usprawnia procesy w biznesie, www.networld.pl/artykuly/ druk/53162/SOA.BPM.usprawnia.procesy.w.biznesie.html.
Muszyński J., SOA – Usługi na pierwszym miejscu, www.networld.pl/artykuly/druk/50939/ SOA.uslugi.na.pierwszym.miejscu.html.
Papazoglou M.P., Georgakopoulos D., Service-Oriented Computing, “Communication of the ACM” 2003, vol. 46.
Peppard J., Rowland P., Re-engineering, Gebethner & Ska, Warszawa 1997.
Rutkowska J., Podejście procesowe a technologia informatyczna według metodologii
ARIS i ADONIS, Uniwersytet Warszawski, www.wszin-sochaczew.edu.pl.
Schmidt P., Modelowanie procesów w ramach systemów SOA, 4PM Project Management, www.4pm.pl/artykul/modelowanie_procesow_w_ramach_systemow_soa.html. Smith H., Fingar P., Business Process Management: The Third Wave, Technical Excerpt
BPML, Meghan-Kiffer Press 2003.
Smith H., Fingar P., Business Process Management: The Third Wave, Technical Excerpt BPML, Meghan-Kiffer Press 2003.
Sommerville I., Inżynieria oprogramowania, WNT, Warszawa 2003.
White S.A., Introduction to BPMN, “BP Trends”, July 2004, www.bptrends.com/publica-tionfi les/07-04%20WP%20Intro%20to%20BPMN%20-%20White.pdf.
Żeliński J., Analizy: oferta SaaS nieco wyprzedza świadomość użytkowników, www. zelinski.biz.pl/php/html/modules.php?name=News&fi le=article&sid=262.
PROCESS ORIENTED APPROACH IN MODERNIZATION OF ORGANIZATION INFORMATION SYSTEMS
Summary
In recent years, we observe a radical change in the approach to architecture and development of information systems for companies. As a result of the dissemination of the management of business processes, it has an increasing impact on the architecture of information systems.
The purposes of the article are:
– characteristics of the basic architecture of process oriented information systems, – an analysis of the application process approach in the methods and techniques
of information systems development,
– presentation the assumptions of the process-oriented method of requirements engi-neering on IT systems.
