Determinanty funkcjonowania systemów analityki biznesowej w rozproszonym środowisku obliczeniowym

Transkrypt

1 Uniwersytet Warszawski Wydział Zarządzania Mgr Tomasz Kozyra Determinanty funkcjonowania systemów analityki biznesowej w rozproszonym środowisku obliczeniowym Praca doktorska na kierunku Zarządzanie Praca wykonana pod kierunkiem prof. dr hab. Witolda Chmielarza Wydział Zarządzania, Uniwersytet Warszawski Katedra Systemów Informacyjnych Zarządzania Warszawa, grudzień

2 Oświadczenie kierującego pracą Oświadczam, że niniejsza praca została przygotowana pod moim kierunkiem i stwierdzam, że spełnia ona warunki do przedstawienia jej w postępowaniu o nadanie stopnia doktora. Data Podpis kierującego pracą Oświadczenie autora pracy Świadom odpowiedzialności prawnej oświadczam, że niniejsza praca dyplomowa została napisana przez mnie samodzielnie i nie zawiera treści uzyskanych w sposób niezgodny z obowiązującymi przepisami. Oświadczam również, że przedstawiona praca nie była wcześniej przedmiotem procedur związanych z uzyskaniem tytułu zawodowego w wyższej uczelni. Oświadczam ponadto, że niniejsza wersja pracy jest identyczna z załączoną wersją elektroniczną. Data Podpis autora pracy Zgoda autora pracy Wyrażam zgodę ma udostępnianie mojej rozprawy doktorskiej dla celów naukowobadawczych Data Podpis autora pracy 2

3 Streszczenie Przedmiotem rozprawy jest problematyka funkcjonowania systemów analityki biznesowej widzianej z perspektywy rozproszonego środowiska obliczeniowego. Za przykład takiego środowiska w toku rozprawy służy model chmury obliczeniowej. W pracy omawiane są korzyści oraz bariery stosowania systemów analityki biznesowej w chmurze obliczeniowej z uwzględnieniem czynników natury ekonomicznej, technicznej i organizacyjnej. Rozprawa ukazuje także możliwości rozwoju wspomnianych systemów, jak też możliwe scenariusze ich zastosowania przez duże oraz małe i średnie przedsiębiorstwa. Słowa kluczowe systemy analityki biznesowej, systemy rozproszone, chmury obliczeniowe, zarządzanie IT Dziedzina pracy (kody wg programu Socrates-Erasmus) Biznes i technologia Tytuł pracy w języku angielskim Determinants of business analytics systems functioning in distributed system 3

4 Spis treści 1.Wstęp Wprowadzenie i uzasadnienie podjęcia badań Cele i zakres pracy Hipotezy badawcze rozprawy Procedura osiągnięcia celu badawczego i udowodnienia hipotez Charakterystyka systemów zintegrowanych Wprowadzenie Wartość biznesowa płynąca z integracji Rodzaje, style i typy integracji Zagadnienia systemów klasy Business Intelligence Systemy klasy BI jako systemy integrujące Architektura systemów BI Warstwa integracyjna architektury BI Warstwa składowania architektury BI Warstwa analityczna i prezentacji architektury BI Dziedziny zastosowań Business Intelligence Charakterystyka systemów rozproszonych Problematyka wirtualizacji Typologia modeli biznesowych chmury obliczeniowej Korzyści, wyzwania i zagrożenia w chmurach obliczeniowych Rozwinięcie charakterystyki chmur obliczeniowych i analiza SWOT Ekonomiczna, techniczna i organizacyjna analiza chmur obliczeniowych (analiza ETO) Charakterystyka czynników analizy ETO na tle charakteru organizacji Analiza ETO określenie związków Zagadnienia systemów analityki biznesowej w systemach rozproszonych Rozproszenie w warstwach zasobów i systemowej Współczesne wyzwania funkcjonowania systemów Business Intelligence Zjawisko Big Data jako symptom rozproszenia oraz nowe światło dla systemów analityki biznesowej Rozwiązania Business Intelligence w środowiskach chmur obliczeniowych Usługowy model systemu analityki biznesowej na przykładzie Software as a Service BI (SaaS BI) Ewolucja systemów analityki biznesowej Postulaty rozwoju i ewolucji infrastruktury IT Systemy analityki biznesowej na tle rozproszenia Modele tworzenia infrastruktury informatycznej, a systemy analityki biznesowej Typy systemów analityki biznesowej w ujęciu korporacyjnym Uwarunkowania funkcjonowania systemów analityki biznesowej w małych i średnich przedsiębiorstwach (MŚP) Ocena możliwości adaptacji SaaS BI w sektorze małych i średnich przedsiębiorstw Empiryczna analiza możliwości adaptacji SaaS BI Wnioski i podsumowanie rozważań Zakończenie Bibliografia Indeks ilustracji Indeks tabel Załącznik A. Kwestionariusz badań oceny możliwości adaptacji SaaS BI

5 1. Wstęp 1.1. Wprowadzenie i uzasadnienie podjęcia badań Podstawowym elementem Systemów Informacyjnych Zarządzania (SIZ) jest informacja. Według E. Turbana System Informacyjny Zarządzania jest formalnym, komputerowym systemem, tworzonym w celu dostarczenia, selekcjonowania i integracji dostarczonej z różnych źródeł informacji w celu zapewnienia aktualnych informacji niezbędnych dla podejmowania decyzji w zarządzaniu 1. W innej pracy Turban2 proponuje opis relacji zachodzących między danymi, informacją i wiedzą, w którym informacje zależą od danych, a wiedza kształtowana jest zarówno przez dane, jak i informacje (rys. 1). Rysunek 1. Triada - dane, informacja, wiedza. Źródło: Turban E., Aronson J.E., 2001, DSS and Intelligent Systems, Prentice Hall, New Jersey 2001, s Ludvig von Mises pisał, że cechą przedsiębiorcy musi być umiejętność przewidywania 3. Ta jednak częstokroć wiąże się z umiejętnością wykorzystania wiedzy. Wydaje się jednak, że owa umiejętność nie może być kształtowana bez zdolności przekształcania zarejestrowanych opisów rzeczywistości (danych) w informację, gdyż to dopiero Turban, E. (1990), Decision Support and Expert Systems, MacMillan Publishing Company, New York. [cyt. za Kisielnicki J., Sroka H. (2005), Systemy Informacyjne Biznesu, Placet, Warszawa, s. 20]. Turban, E, Aronson, J. (2001), DSS and Intelligent Systems, Prentice Hall, Ney Jersey, s Mises von, L. (1966), Human Action, Henry Regnery, Chicago s. 290 (wyd. polskie Ludzkie działanie, Fundacja Instytut Ludwiga von Misesa, Warszawa, 2007). 5

6 informacja umożliwia podejmowanie decyzji.4 Należy więc wprowadzić istotne zastrzeżenie do schematu zaproponowanego przez Turbana. O ile dane kształtują - choć niejednokrotnie w sposób pasywny - repozytorium wiedzy, o tyle w procesie podejmowania decyzji wykorzystywane są właśnie informacje. W skrócie można powiedzieć, że wykorzystywanie informacji polega na przypisaniu wartości danym. Przy czym, wartość należy postrzegać w tym kontekście w szerokim aksjologicznym sensie. Trudno bowiem stwierdzić, że działanie podlega jedynie prawom ekonomicznym. Stąd dane wartościowane są podług kryteriów poznawczych, moralnych, ekonomicznych czy w końcu estetycznych. O znaczeniu tych ostatnich w zarządzaniu może choćby świadczyć rosnące zainteresowanie estetyką w praktykach menedżerskich i organizacyjnych5. Trzeba zatem podkreślić, że te same dane mogą być źródłem decyzji o różnym charakterze. Trudno wyrokować o proporcjach w procesach przypisywania wartości, a służących podejmowaniu działań. Jednak dla działalności gospodarczej kluczowe znaczenie ma sytuowanie danych w kontekstach ekonomicznych, tj. przypisywanie im wartości o takim charakterze. Przypisywanie wartości danym można uznać za pewną formę ich interpretacji niezbędną do podejmowania decyzji. W zaproponowanej przez Turbana definicji pojawia się jedno z kluczowych pojęć dla procesu formowania się źródeł decyzji: integracja. Mechanizmy i procesy integracji zakładają jednak pewien z góry nieopisany stan, który uznać należy za stan rozproszenia. Współczesne strategie informacyjne opierają się między innymi na Systemach Wspomagania Decyzji (SWD). Ich ewolucja rozpoczyna się wraz z powstawaniem systemów transakcyjnych, poprzez systemy informowania kierownictwa, systemy ekspertowe, by rozwinąć się w systemy klasy Business Intelligence, które są stałym elementem praktyki w zarządzaniu oraz stanowią o sukcesie gospodarczym wielu organizacji. Wśród systemów wspomagających decyzje należy wyróżnić zorientowane na modele, dane, wiedzę, komunikację oraz dokumentację6. Systemy klasy Business Intelligence, Odróżniając firmy pod względem osiąganych zysków, badania wykazują, że organizacje sprawniejsze finansowo proaktywnie dokonują przemiany danych w informację pozwalającą podejmować działania, IBM (2010), The new voice of the CIO: Insights from the Global Chief Information, IBM Institute for Business Value, s. 22. Minahan, S, Cox, J. (2007), Aesthetic Turn in Management, Ashgate, Aldershot. Bhargava, H, Power, D. J. (2001), Decision Support Systems and Web Technologies: A Status Report Prepared for AMCIS 2001, Boston, AMCIS 2001, Americas Conference on Information Systems oraz Olszak C. (2007), Tworzenie i wykorzystywanie systemów Business Intelligence na potrzeby współczesnej organizacji, Wydawnictwo Akademii Ekonomicznej w Katowicach, Katowice, s

7 będące trzonem współczesnych systemów analityki biznesowej, należy przypisać do SWD zorientowanych na dane7. Przy czym przez systemy analityki biznesowej rozumieć będziemy szerokie spektrum oprogramowania analitycznego, które charakteryzują trzy główne aspekty, przedstawione przez H. Morrisa8: wsparcie procesów biznesowych oprogramowanie systematyzujące i automatyzujące zadania, które odnoszą się do przeglądu i optymalizacji działań biznesowych lub odkrywania szans i rozwoju tych działań, separacja od funkcji transakcyjnych oprogramowanie to powinno funkcjonować niezależnie od systemów transakcyjnych, jednak jego działanie powinno podlegać tym systemom i ewentualnie zasilać je danymi i wynikami, czasowe ukierunkowanie zintegrowanych danych oprogramowanie ma za zadanie integrować, pobierać i ewentualnie transformować dane z różnych źródeł podlegając wymiarom czasu, w celu analizy przeszłych i przyszłych zachowań. Odnosząc się do definicji Turbana oraz do zawartego nim postulatu integracji, w prosty schemat decyzyjny należy wpisać dwa elementy: rozproszenie i integrację. Złożone procesy decyzyjne uzależnione są od relacji pomiędzy rozproszeniem, a integracją oraz możliwością znoszenia tego pierwszego przez drugie. W tym swoistym napięciu, w próbach przełamywania rozproszenia systemy wspomagające procesy podejmowania decyzji uczestniczą zatem także systemy analityki biznesowej (rys. 2). W badaniu, które przeprowadziła firma IBM9 6-ciu z 10-ciu menedżerów stwierdziło, że środowisko ekonomiczne staje się coraz bardzie złożone. Zgodnie z badaniami przewiduje się, że taką opinię za pięć lat wyrazi 80% respondentów. Istotne jest przy tym to, że tylko połowa badanych, wyrażających takie przekonanie, jest przygotowana do zmierzenia się z problemem złożoności. Oznacza to istotną lukę między doświadczaniem złożoności, a możliwościami jej przezwyciężenia. W badaniach tych, 39% opiniowanych uważa, że głównym czynnikiem wpływającym na reprezentowane przez nich organizacje jest technologia. IBM proponuje następujące strategie zarządzania i mierzenia się ze złożonością: wcielanie postawy kreatywnych liderów, przedefiniowywanie stosunków z klientami oraz stosowanie sprawności operacyjnej" Power, D. (2007), A Brief History of Decision Support Systems, Morris H. D. (2010), Business Analytics and the Path to Better Decisions, No , Technical report, IDC, s IBM (2010), Capitalizing on Complexity: Insights from the IBM 2010 Global CEO Study, IBM Institute for Business Value, s

8 W innym badaniu, przeprowadzonym przez firmę KPMG10, tylko jeden na ośmiu Rysunek 2. Dane, informacja i wiedza na tle rozproszenia i integracji. Źródło: opracowanie własne. decydentów IT uważa, że osiąga maksymalną wartość z inwestycji w technologie. Odwracając tę statystykę można powiedzieć, że 88% respondentów nie jest przekonana, że IT przynosi maksymalną wartość biznesową. Co więcej, aż 49% projektów IT nie jest realizowana zgodnie z założeniami czasowymi i finansowymi. Te statystyki korespondują z danymi raportu firmy Standish Group11, według którego tylko 32% projektów IT kończy się sukcesem, mierzonym według czynników czasowych, finansowych i funkcjonalnych. Co więcej, na przestrzeni ostatnich lat statystyki te wykazują tendencje spadkowe. Inna charakterystyka dotyczy związku między budżetem projektu, a jego realizacją. Nie trudno o potwierdzenie przypuszczenia, że koszt projektu jest odwrotnie proporcjonalny do kosztu realizacji. Złożoność zatem ujawnia się nie tylko w przeczuciach menedżerów, ale i realnych działaniach podejmowanych w celu wdrażania technologii informatycznych. Zintegrowane systemy funkcjonują niejednokrotnie niczym twierdza zamykająca w swym obrębie wszelkie struktury i zasoby organizacji. Wraz z rozwojem technologii jej ramy zaczynają pękać. Sprzyjają temu procesy wymiany informacji i jej udostępnianie. Nie oznacza to jednak, iż przez powstające szczeliny informacje przedostają się w sposób niekontrolowany. Przeciwnie, kluczowe dla organizacji dane oraz informacje podlegają ścisłym prawo ochrony, na co wskazują statystyki firmy IBM. Jednym z głównych celów kadry IT jest ochrona i bezpieczeństwo systemów oraz danych. Owe szczeliny i pęknięcia 10 KPMG (2008), Getting the Most from Your Investments in IT, KPMG LLP. 11 Standish Group (2009), CHAOS Summary 2009, Standish Group International Inc. 8

9 w sposób istotny intensyfikują kwestię złożoności, lecz na jej realny obraz w głównej mierze wpływają kategorie rozproszenia i heterogeniczności. W klasycznej pracy Griffin wyróżnia cztery typy zasobów: ludzkie, pieniężne, rzeczowe i informacyjne12. Czwarty typ zasobów podlega najsilniejszym przemianom oraz tendencjom rozproszenia. Dane przetwarzane są na każdym poziomie i szczeblu organizacji. Wzrasta liczba zależności między procesami, z których coraz większa ilość podlega systematyzacji. Haas13 podaje wyniki firmy Forester Research według, których 79% firm ma więcej niż dwa repozytoria dokumentów, zaś 25% ponad 15-cie. Wraz z rozwojem technologii informacyjnych wzmaga się ilość danych. Być może żyjemy nico intensywniej niż 50 lat temu, jednak diametralnej przemianie ulega proces rejestracji zdarzeń, tj. proces generowania danych. Dotyczy to nie tylko technologii dostępnych na rynku konsumenckim, ale także wszelkich obszarów funkcjonowania dzisiejszych organizacji. Organizacje zasypywane są danymi i coraz częstszym problemem jest nie ich brak czy dostępność, ale nadmiar, wymagane kompetencje i wiedza pozwalająca na ich właściwe interpretowanie i wyszukiwanie14. Ciekawym fenomenem świadczącym o nadmiarze danych jest zjawisko Big Data, będące świadectwem konieczności przyswajania przez przedsiębiorstwa dużych wolumenów danych lokalizowanych częstokroć poza organizacją. Na procesy rozproszenia danych wpływa także stopień specjalizacji, wiedzy i różnorodność postaw pracowników. W innej propozycji systematyzacji zasobów Haanes i Lowendhal15 dzielą zasoby na wymierne i niewymierne (intelektualne). Wśród zasobów intelektualnych wymieniają kompetencje oraz relacje. Relacje indywidualne, jak i organizacyjne w sposób istotny determinują stan rozproszenia. Działania firm coraz częściej opierają się na świadomych decyzjach związanych z otwartością. Można wręcz rzec, że stosują one strategie otwartości. Pociąga to za sobą dostosowywanie do nich istniejącej infrastruktury IT. Zamknięte, monolityczne systemy ulegają rozczłonkowaniu nie tylko z uwagi na swobodniejszy i szybszy przepływ informacji, ale także z powodu relegacji zadań związanych z zarządzaniem systemami i ich 12 Griffin, R. (2005), Podstawy zarządzania organizacjami, PWN, Warszawa, s Haas, L. (2007), Beauty and the Beast: The Theory and Practice of Information Integration, Suciu D. Schentick T. red., w ICDT 2007, Springer-Verlag, Berlin Heidelberg, s IBM (2010), The New Voice..., op. cit., s Haanes, K, Lowendahl, B. (1997), The Unit of Activity: Towards an Alternative to the Theories of the Firm w Thomas, H., red., Strategy, Structure and Style, Wiley, New York. 9

10 utrzymywaniem. Strategie otwartości realizowane się w następujących obszarach: outsourcing, otwarta innowacja, uczestnictwo w życiu społecznościowym16. Zasoby informacyjne, ludzkie czy relacyjne wspierane są przez systemy informacyjne, w których w warstwie technicznej dochodzi do innego rodzaju rozproszenia: procesów, aplikacji, systemów przetwarzania i analizowania i dystrybucji danych. Mamy zatem do czynienia z dwoma rodzajami rozproszenia: z jednej strony rozproszenie zasobów, z drugiej rozproszenie systemów je przeważających. Rozproszenie danych i informacji wiąże się nie tylko z mnogością ich źródeł, ale także z ich niepełnością i jakością, brakiem strukturalnego podobieństwa, czy redundancją. Heterogeniczność potęguje także mnogość systemów oraz modeli. W warstwie organizacyjnej dochodzi niejednokrotnie do konfliktów związanych z rozumieniem procesów oraz celów funkcjonowania systemów, czego przykładem może być choćby problem dopasowania IT i biznesu 17. Zatem heterogeniczność uwidacznia się nie tylko w domenie zasobów informacyjnych, ale także organizacyjnych. Podejmowanie skutecznych i właściwych decyzji, prowadzących do wzrostu efektywności organizacji polega nie tylko na doborze informacji oraz kształtowaniu jej na podstawie danych, ale także na tworzeniu odpowiednich relacji oraz współzależności pomiędzy nimi. Rozproszenie, zarówno w warstwie zasobów, jak i w warstwie systemowej blokuje procesy decyzyjne, a formą jego przełamywania jest stosowanie różnych strategii integracyjnych. Zagadnienie integracji rozpatrywane może być z różnych perspektyw: organizacyjnotechnicznej, systemowej, transakcyjnej, relacyjnej (ze względu na rodzaje połączeń oraz zakresu - integracja wewnętrzna i zewnętrzna)18. Dzięki wdrożeniom rozwiązań integracyjnych organizacja może zredukować personel, zredukować powielane czynności, usprawnić operacje finansowe, zredukować koszty (np.: utrzymania systemów IT). Są to niewątpliwie wymierne korzyści płynące z integracji, ale dzięki integracji organizacje poprawiają sposoby dostępu do informacji, wprowadzają 16 Chesbrough, H. (2003), The Era of Open Innovation, MIT Sloan Management Review 44(3), s Orzechowski, R. (2007), Dopasowanie IT-biznes, Kwartalnik Nauk o Przedsiębiorstwie 2, s , Reich, B, Benbasat, I. (2000), Factors That Influence the Social Dimension of Alignment between Business and Information Technology Objectives, MIS Quarterly 24(1), s , Luftmann, J, Papp, R.and Brier, T. (1999), Enablers and Inhibitors of Business-IT Alignment, Communications of the Association for Information Systems 1(11). 18 Put, D. (2010), Wieloaspektowość zagadnienia integracji zasobów informacyjnych w dynamicznych strukturach sieciowych w Chmielarz, W., Kisielnicki, J., Parys, J., red., Informatyka Q Przyszłości, Wydanictwa Naukowe WZ UW, Warszawa, s

11 mechanizmy standaryzacji (głównie dotyczące informacji), a na płaszczyźnie organizacyjnej zacieśniają współpracę między działami. Kluczowym dla działań i procesów integracyjnych są dane i informacje. Put19 z punktu wiedzenia metody przechowywania zasobów informacyjnych szereguje rodzaje integracji następująco: integracja opiera się na jednolitej bazie danych oraz migracji danych do jednego systemu (systemy zintegrowane) lub integracja opiera się na pewnych formach interfejsów ponad heterogenicznymi i rozproszonymi zasobami informacyjnymi. W klasycznym ujęciu systemy business intelligence bazują na rozwiązaniu pośrednim, mianowicie na hurtowni danych oddzielonej od innych repozytoriów, a będącej centralnym zbiorem danych. Rozwiązanie to dominuje we współczesnych wdrożeniach tej klasy systemów. Wraz ze złożonością środowiska systemów informacyjnych oraz zasobów organizacji realizacja tego typu rozwiązań stanowi barierę finansową, organizacyjną i techniczną. Organizacje zmuszone są zatem do koncentrowania wysiłków zmierzających do przełamania złożoności rozumianej jako pojęcia uwzględniającego rozproszenie i heterogeniczność. Muszą one przy tym osiągać wymierne korzyści z zastosowania systemów informatycznych. Wszelkie te problemy dotyczą jednak w głównej mierze dużych organizacji zorientowanych na własne środowisko informacyjne. Jednak rozwiązania IT realizowane są coraz częściej w publicznych środowiskach rozproszonych. Dotyczy to nie tylko infrastruktury IT, ale także aplikacji. Jak przekonuje Carr, przybywa rozwiązań masowych, które powstają na bazie złożonych, niejednokrotnie dedykowanych rozwiązań IT. Główny ciężar związany z adaptacją technologii ponoszą zatem duże organizacje i służy on jedynie początkowo zwiększaniu konkurencyjności. Modele sprawdzonych korporacyjnych rozwiązań IT zostają dostosowywane do potrzeb masowych. Dzięki temu ze standaryzacji i obniżania kosztów wykorzystywania technologii IT korzystają mniejsze przedsiębiorstwa20. U boku prezesów zarządów stoją niemalże nieodłącznie menedżerowie IT. W innym raporcie tej firmy IBM na pytanie, jakie rozwiązania technologii informacyjnych wpływają na zwiększanie przewagi konkurencyjnej, decydenci IT wymieniają na pierwszym miejscu rozwiązania business intelligence (83%) i kolejno: wirtualizację (76%) oraz zarządzanie ryzykiem (71%)21. Jeśli zatem systemy analityki biznesowej stanowią już niemalże 19 Ibid. 20 Carr, N. (2005), The end of corporate computing, MIT Sloan Management Review 45(3), s Carr, N. (2003), IT Doesn't Matter, Harvard Business Review, May IBM (2010), The New Voice..., op. cit., s

12 integralny element infrastruktury IT, jak też element strategii IT - na co wskazują przytoczone powyżej statystyki - a organizacje muszą dostosowywać się do rzeczywistości, w której dominuje i potęguje się stan rozproszenia, powstają pytania kluczowe dla przedstawianej rozprawy: Jakie bariery muszą pokonać organizacje, aby przystosować się do wymogów ekonomicznych i technicznych systemów analityki biznesowej w perspektywie rozproszenia? W końcu, kto może być jej najskuteczniejszym beneficjentem w takiej perspektywie? Uzasadnienie badań. W dotychczasowych badaniach poświęconych problematyce systemów BI do dziś nie udało się wypracować np.: całościowego, konceptualnego modelu systemu BI 22. C. Olszak argumentuje, że badania w zakresie budowy systemów BI zorientowane były głównie na artefakty, a nie na procesy. Podejście procesowe umożliwiłoby powiązanie systemów BI z procesami biznesowymi. Takie podejście w ścisły sposób odwołuje się do zadań, jakie powinien stawiać przed sobą system BI w konkretnej organizacji. W skrótowym ujęciu podejście procesowe do rozwoju systemów business intelligence zakłada kolejno rozpoznania potrzeb biznesu, wymagań użytkowników, które determinują funkcje i zadania BI, warunkujące zastosowanie konkretnych technologii BI23. Pomimo słuszności tak zarysowanej propozycji możliwej strategii badawczej odniesionej do systemów BI, w świetle współczesnych przemian technologicznych sprawa zastosowania konkretnych technologii wciąż ma istotne znaczenie. Klasyczna literatura przedmiotu ukazuje systemy klasy Business Intelligence jako rozwiązania przypisane w głównej mierze do wewnętrznej infrastruktury IT 24. Ponadto w tradycyjnie stosowanej architekturze systemy BI podlegają silnym prawom konsolidacji i integracji danych. Jednak przedstawiony we wprowadzeniu obecny kontekst systemów informatycznych wnosi nowe światło dla problematyki funkcjonowania tych systemów. Do istotnych problemów zaliczyć należy przywołane kwestie heterogeniczności, a także 22 Olszak C. (2012), Analiza i ocena dorobku naukowego z zakresu Business Intelligence - wybrane zagadnienia w Olszak C., Ziemba E., red., Systemy inteligencji biznesowej jako przedmiot badań ekonomicznych, Wydawnictwo Uniwersytetu Ekonomicznego w Katowicach, s Por. także Fletcher H. G., Surya B. Y. (2011), Business Intelligence Conceptual Model, International Journal of Business Intelligence Research 2(2), s Por. m. in. Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Systemy Business Intelligence, Vol. T. 2, PWN, Warszawa; Olszak C. (2007), Tworzenie i wykorzystywanie systemów Business Intelligence na potrzeby współczesnej organizacji, Wydawnictwo Akademii Ekonomicznej w Katowicach, Katowice; Surma J. (2009), Business Intelligence. Systemy wspomagania decyzji biznesowych, PWN, Warszawa. 12

13 postępujących procesów rozproszenia zasobów oraz systemów je przetwarzających. Przemiany te prowadzą do wyłonienia się takich form systemów rozproszonych jak chmura obliczeniowa (ang. cloud computing). Przetwarzanie w chmurze obliczeniowej wiąże się z szeregiem barier, ale także i korzyści, które stanowić mogą właściwy grunt dla zastosowania konkretnych systemów analityki biznesowej. Istotny jest tu fakt, że to właśnie ten przykład przetwarzania rozproszonego (chmury obliczeniowe) poszerza możliwości i spektrum oprogramowania analityki biznesowej, która nie ogranicza się już zasadniczo tylko do systemów klasy BI. Ponadto uwarunkowania funkcjonowania chmur obliczeniowych, jako modelowego przykładu przetwarzania rozproszonego, wpływają na zmianę podejścia do strategii tworzenia infrastruktury IT, która za sprawą obecnego kontekstu funkcjonowania danych i informacji może wykroczyć poza ramy organizacji. Stanowi to także istotny punkt zwrotny dla ewolucji systemów analityki biznesowej. C. Olszak, przedstawiając obecne trendy rozwoju systemów Business Intelligence, wymienia takie rozwiązania jak Business Intelligence 2.0, SOA (Service Oriented Architecture) czy SaaS (Software as a Service) BI25. Pierwszy z przykładów ukazuje powstawanie nowej generacji systemów omawianej klasy, która zakłada nowe podejścia w sposobach wyszukiwania informacji przy uwzględnieniu zewnętrznych ich źródeł oraz zmieniającego się kontekstu. Ten etap w rozwoju systemów BI zakłada także między innymi: wykorzystanie podejścia semantycznego, rozwiniętych metod predykcyjnych, wzbogacanie interfejsów, czy szersze zastosowanie analizy w czasie rzeczywistym. SOA z kolei wytycza nowe podejście do tworzenia oprogramowania i usprawnić może procesy tworzenia zaawansowanych systemów analityki biznesowej. Jednym z kolejnych przejawów rozwoju technologii informatycznych i sposobów jej udostępniania jest koncepcja Software-as-a Service (SaaS). Jest ona sygnałem istotnych przemian zachodzących w podejściu do tworzenia, wdrażania i utrzymywania aplikacji. W szerszym jednak ujęciu problematyka związana z rozwiązaniami BI opartymi na modelu SaaS podlega problematyce przetwarzania w chmurach obliczeniowych. We współczesnych publikacjach poświęconych problematyce systemów analityki biznesowej istnieje wiele nawiązań do wymienionych trendów26, jednak niniejsza rozprawa 25 Olszak C. (2011), Wybrane technologie informatyczne w doskonaleniu rozwoju systemów Business Intelligence, Problemy Zarządzania, zeszyt specjalny, s Por. m. in. TDWI (2013), Analytics in the Cloud. Challenges and Benefits, Technical report, The Data Warehousing Institute, October 2013; Menon L., Rehani B., Gund S. (2012), Business Intelligence on 13

14 ma na celu systematyczne ukazanie i ustalenie uwarunkowań funkcjonowania różnych systemów analityki biznesowej w ścisłym odniesieniu do systemów rozproszonych, a będących właściwym kontekstem dla tych trendów. Uwarunkowania te jednak nie mają jedynie charakteru czysto technicznego. Stosowanie systemów analityki biznesowej w środowisku rozproszonym wiąże się także z konsekwencjami natury ekonomicznej i organizacyjnej. Dzięki określeniu szerokiego spektrum czynników funkcjonowania tych systemów możliwe jest wytyczenie wielu ścieżek badawczych, umożliwiających ocenę możliwości przyszłej ewolucji rozwiązań analitycznych, czy też możliwości zastosowania ich w dużych oraz małych i średnich przedsiębiorstwach 1.2. Cele i zakres pracy Powyższy kontekst badawczy oraz towarzyszące mu motywacje wytyczają następujący cel przeprowadzenia badań: Opracowanie technicznych, ekonomicznych oraz organizacyjnych uwarunkowań funkcjonowania systemów analityki biznesowej w systemie rozproszonym (chmura obliczeniowa) Ten ogólny cel osiągnięty być może dzięki następującym celom szczegółowym przypisanym do poniższych kategorii: Cele poznawcze: rozwój systemów informatycznych przyczynia się do coraz większej wagi systemów rozproszonych; poza usystematyzowaniem dobrze rozpoznanych aspektów technicznych funkcjonowania tych systemów, istotne dla przedsiębiorstw są kwestie ekonomiki ich funkcjonowania oraz problemy natury organizacyjnej, takie jak choćby zarządzanie tymi systemami; the Cloud Overview, Use Cases and RoI, IJCA Proceedings on National Conference on Communication Technologies & its impact on Next Generation Computing 2012 CTNGC(2), s ; Mircea M., Ghilic-Micu B., Stoica M. (2011), Combining Business Intelligence with Cloud Computing to delivery agility in actual economy, Economic Computation & Economic Cybernetics Studies & Research 45(1), s. 1-16; Chadha B., Iyer M. (2010), BI in a Cloud: Defining the Architecture for Quick Wins, SETLabs Briefings 8(1), s ; Thompson J. (2009), Business Intelligence in a SaaS Environment, Business Intelligence Journal 14(4), s Chan L.-K., Sim Y.-W., Yeoh W. (2011), A SOA-Driven Business Intelligence Architecture, Communications of the IBIMA Article ID Owoc M., Hauke K. (2010), Modele upowszechniania cloud computingu w organizacjach w Korczak J., Chomiak-Orsa I., Sroka H., red., Systemy informatyczne w zarządzaniu, Uniwersytet Ekonomiczny we Wrocławiu, Wrocław, s ; Nycz M. (2012), Przetwarzanie w chmurze: rewolucja czy ewolucja w przetwarzaniu danych w Olszak C., Ziemba E., red., Systemy inteligencji biznesowej jako przedmiot badań ekonomicznych, Wydawnictwo Uniwersytetu Ekonomicznego w Katowicach, s

15 systemy analityki biznesowej cechuje relatywnie długa historia, a ich trzon stanowią przywołane powyżej systemy klasy Business Intelligence, jednak systemy analityki biznesowej wkraczają w nowy etap, dlatego konieczne jest ukazanie jej nowych odmian; kluczowym dla ustalenia uwarunkowań funkcjonowania systemów analityki biznesowej w założonym celu głównym jest określenie, w jakich warunkach systemów rozproszonych mogą one funkcjonować, a także jakie formy systemów analityki biznesowej pasują do konkretnych rozwiązań technicznych systemów rozproszonych; poza ustaleniem stanu faktycznego współczesnych systemów analityki biznesowej intrygującym zadaniem jest ustalenie możliwości ich ewolucji widzianej z perspektywy rozwoju systemów rozproszonych. Cele metodyczne: systematyczne ujęcie uwarunkowań biznesowej w środowiskach funkcjonowania rozproszonych systemów analityki wymaga przyjęcia właściwej perspektywy ukazującej funkcjonowanie systemów rozproszonych, która oparta będzie na przygotowaniu zasadnego modelu jakościowego; główne zadanie wypracowanego modelu jakościowego polega na przedstawieniu czynników wpływających na podatność danego systemu rozproszonego na adaptację w organizacji; ustalenie zakresu technologii odpowiadających modelowi jakościowemu; w celu określenia empirycznych podstaw oceny zastosowania wybranego systemu analityki biznesowej konieczna będzie ewaluacja oraz adaptacja modeli ilościowych mierzących stopień i możliwości zastosowania usług oferowanych w chmurach obliczeniowych. Cele utylitarne: przedstawienie uwarunkowań funkcjonowania systemów analityki biznesowej rozpatrywanej w kontekście systemów rozproszonych na tle dużych przedsiębiorstw oraz małych i średnich podmiotów gospodarczych; ustalenie wytycznych dla decyzji menedżerskich dotyczących strategii zarządczych w obszarze systemów informatycznych, a w szczególności dla decyzji powiązanych 15

16 z zastosowaniem oprogramowania bazującego na założeniach chmur obliczeniowych; stworzenie właściwego kontekstu dla upowszechniania przez uczestników rynku oprogramowania (np.: producenci, media, firmy doradcze) korzyści gospodarczych płynących z zastosowania systemów analityki biznesowej Hipotezy badawcze rozprawy Wyznaczenie różnorodnych uwarunkowań funkcjonowania systemów analityki biznesowej widzianej z perspektywy systemów rozproszonych, jako główny cel pracy, stanowi podstawę do wysunięcia następującej głównej hipotezy badawczej (HG): Współczesne systemy rozproszone (chmury obliczeniowe) przyczyniają się do rozwoju systemów analityki biznesowej w organizacjach. Hipoteza ta wspierana jest dodatkowymi hipotezami pomocniczymi. Hipoteza 1 (H1). Rozwój systemów analityki biznesowej zależy w głównej mierze od podejścia do sposobu tworzenia infrastruktury IT Współczesne systemy rozproszone od strony technicznej umożliwiają rozwój modelu chmury obliczeniowej. Ich zastosowanie zmienia oblicze infrastruktury IT i pociąga za sobą szereg konsekwencji dla zarządzania oraz funkcjonowania organizacji zarówno w aspektach technicznym, jak też ekonomicznym i organizacyjnym. Odniesienie się organizacji do różnych sposobów upowszechniania chmur obliczeniowych (publiczne, prywatne lub hybrydowe) oraz różnych modeli usługowych (IaaS, PaaS, SaaS) stosowanych przez dostawców warunkuje zastosowanie konkretnych systemów analityki biznesowej. Hipoteza 2 (H2). Model prywatnych chmur obliczeniowych stanowi istotny etap na drodze rozwoju systemów analityki biznesowej w dużych przedsiębiorstwach Z dwóch głównych modeli upowszechniania chmur obliczeniowych (chmury publiczne i prywatne) model chmur prywatnych zapewnia szereg korzyści usprawniających zarządzanie infrastrukturą IT oraz usprawnia funkcjonowanie systemów analityki 16

17 biznesowej. W modelu tym minimalizowane jest ryzyko towarzyszące korzystaniu z informatycznych zasobów publicznych, w których zasoby informacyjne organizacji podlegają szeregowi krytycznych ograniczeń. Hipoteza 3 (H3). Rozwiązania Software-as-a-service BI (oprogramowanie Business Intelligence udostępniane na żądanie) sprzyjają rozwojowi systemów analityki biznesowej w sektorze małych i średnich przedsiębiorstw. Software-as-a-Service (SaaS) stanowi przykład usługi realizowanej w systemie informatycznym o charakterze rozproszonym. SaaS można uznać za sposób dostarczania aplikacji na żądanie za pośrednictwem Internetu, przy czym obowiązują w nim różnorodne metody subskrypcyjne odmienne od tradycyjnych aplikacji. W świetle tej hipotezy model SaaS BI, jako forma systemu klasy Business Intelligence, przynależąca do szerszego spektrum systemów analityki biznesowej, jest w sposób istotny podatny na implementację w sektorze MŚP i przyczynia się do rozwoju postaw kalkulacyjnych w procesach podejmowania decyzji gospodarczych w tym sektorze Procedura osiągnięcia celu badawczego i udowodnienia hipotez Procedura osiągnięcia celu badawczego i udowodnienia hipotez zakłada dwa główne etapy przeprowadzane w obszarach teoretyczno-analitycznym i empirycznym. Dodatkowo osiągnięcie celu badawczego w warstwie metodycznej zakłada stworzenie autorskiego modelu jakościowego oceny funkcjonowania i przydatności chmur obliczeniowych dla organizacji oraz przeprowadzenie analizy porównawczej ilościowych modeli oceny adaptacji rozwiązań SaaS oraz dostosowania zasadnego modelu na potrzeby SaaS BI. W teoretyczno-analitycznym obszarze w pierwszym etapie wykorzystywana jest metoda literaturowa przy wykorzystaniu dotychczasowego dorobku z dziedziny systemów analityki biznesowej. O ile jednak literatura przedmiotu zarówno w publikacjach naukowych, jak i technicznych obszernie przedstawia tę problematykę, o tyle jej rozwinięcie i przeniesienie na płaszczyznę systemów rozproszonych stanowi nowy obszar poszukiwań. Poszukiwania prowadzone są przy użyciu literatury przedstawiającej zagadnienia funkcjonowania systemów analityki biznesowej i systemów rozproszonych zarówno w aspekcie teoretycznym jak i praktycznym, i ujmują tym samym różnorodność 17

18 perspektyw. Brane zatem będą pod uwagę opracowania naukowe z zakresu zarządzania i systemów informacyjnych oraz dokumentacja techniczna dotycząca przedstawianych technologii i stosowanych praktyk (tworzenia architektury, projektowych i wdrożeniowych). Obszar teoretyczno-analityczny zakłada kolejno następujące działania: ustalenie charakterystyki systemów zintegrowanych i rozproszonych ze szczególnym uwzględnieniem charakterystyki rozwiązań i modeli biznesowych realizowanych w chmurach obliczeniowych; przeprowadzenie analizy SWOT rozwiązań funkcjonujących w chmurach obliczeniowych; opracowanie trzech wymiarów ekonomicznego, technicznego funkcjonowania chmur obliczeniowych i organizacyjnego (ETO) - w kontekście przeprowadzonej analizy szans i zagrożeń; odniesienie dokonanych analiz do środowisk dużych organizacji oraz małych i dużych przedsiębiorstw; usystematyzowanie rozwiązań analityki biznesowej na tle opracowanych analiz: szans i zagrożeń związanych z systemami rozproszonymi, ich trzech wymiarów funkcjonowania (ETO) oraz podziału na rozwiązania korporacyjne i niekorporacyjne; ocena możliwości rozwoju systemów analityki biznesowej w różnych modelach tworzenia infrastruktury IT; W warstwie metodycznej opracowanie trzech wymiarów funkcjonowania chmur obliczeniowych wraz z ewaluacją czynników do nich przynależących stanowi podstawę do stworzenia trójczynnikowego modelu jakościowego (model ETO), będącego podstawą do udowodnienia wymienionych powyżej hipotez pomocniczych rozprawy. Postępowanie badawcze w obszarze empirycznym zakłada użycie ogólnodostępnych wyników badań oraz badań ankietowych w zakresie wybranych modeli usługowych chmur obliczeniowych. Przeprowadzane badania empiryczne dotyczące zastosowania wybranego systemu analityki biznesowej (SaaS BI) stanowią unikalny wkład naukowy w obszar oceny możliwości zastosowań technologii informatycznych i stanowią rozwinięcie uznanych już wyników prezentowanych w światowej literaturze przedmiotu. Procedura badań empirycznych zakłada następujące kroki: określenie uwarunkowań funkcjonowania aplikacji SaaS BI (ang. Software-as-aService BI); 18

19 przestawienie charakterystyki funkcjonowania małych i średnich przedsiębiorstw (MŚP); ustalenie uwarunkowania zastosowania technologii informatycznych w sektorze MŚP; wybór i dopasowanie modelu oceny empirycznej możliwości adaptacji rozwiązań SaaS; ustalenie warunków adaptacji SaaS BI oraz możliwości rozwoju tych rozwiązań w sektorze MŚP; Etap ten zakłada ocenę i analizę modeli oceny możliwości adaptacji rozwiązań SaaS. Postępowanie to ma charakter metodyczny i uwzględnia analizę użyteczności rozszerzonego modelu TAM opracowanego na potrzeby rozwiązań Software-as-a-Service. Analiza porównawcza tych modeli stanowi podstawę do wypracowania właściwej metody oceny możliwości zastosowania systemów analityki biznesowej w systemach rozproszonych na przykładzie SaaS BI. Realizacja badań empirycznych podlega następującym działaniom: W oparciu o dotychczasowe wyniki badań empirycznych przedstawionych w literaturze światowej praca w zakresie empirycznym obejmuje ewaluację możliwości adaptacji systemów analityki biznesowej w systemach rozproszonych. Wywiady indywidualne umożliwiają ustalenie faktycznego stanu stopnia wykorzystania oraz technik i metod analityki biznesowej i są przy tym formą wstępnego rozpoznania pozwalającą na przygotowanie badań ankietowych. Finalizacja badań w tym etapie realizowana jest bezpośrednio przy użyciu technik ankietowych, a ich struktura wyodrębnia główne cele warstwy empirycznej tj.: oceny stopnia wykorzystania systemów analityki biznesowej i ich przydatności, podatność na adaptację nowych technologii oraz ocenę wpływu stron trzecich na możliwości ich zastosowania. 19

20 2. Charakterystyka systemów zintegrowanych 2.1. Wprowadzenie Ekonomika domaga się systemu, ale i systemowego działania27. Przypadkowe, eklektyczne zestawienia i łączenie różnych porządków niemalże wykluczają decyzje ukierunkowane ekonomicznie. Np.: jakie konsekwencje dla działania podług imperatywu powiększania kapitału w pewnej firmie mogą mieć ze sobą tak zestawione fakty: obraz Rothko w gabinecie prezesa, skłonności do hazardu jego asystentki i kromka chleba upuszczona przez głównego analityka w dniu, gdy widzi ją po raz pierwszy? Anarchicznie wpisane w system nie mieszczą się w jego prymarnej, ekonomicznej funkcji, nawet jeśli w pewnej sytuacji fakty te mogłyby mieć znaczenie dla jakiejś decyzji. Co więcej, ekonomicznie uwarunkowane działania znosić muszą ukoronowaną anarchię. Dlatego ekonomia sytuuje się w pośrednim obszarze zdrowego rozsądku. W końcu zdrowy rozsądek jest także prorokiem ostatecznej uniformizacji. W tym procesie, ale i w pojęciu, wyróżnić należy trzy elementy: jedność, formę i dynamikę. Uniformizowana wiedza podlega scalaniu w jedną formę. Oczywiście nie oznacza to, że przy zaistnieniu konkretnego opisu lub informacji28, w dwóch różnych sytuacjach podjęta zostanie ta sama decyzja29. Składnikami warunkującymi podejmowanie decyzji przez ludzi 27 Celowo stosujemy tu termin ekonomika, by podkreślić charakter podejmowanych w ekonomii działań. Ekonomia ma charakter ściśle sprawczy. 28 Ontologie formalne umożliwiają odtwarzanie sensów przy takich samych warunkach wyjściowych. 29 W systemach wspomagania decyzji ten warunek musi być spełniony: Obecnie koncentracja badań następuje w obszarze nie tylko wspierania, ale i bezpośredniego podejmowania decyzji przez systemy BI. Polega to na powiązaniu wyników analiz systemów BI z podejmowaniem bezpośrednio operacyjnych decyzji zarządczych (tzw. zagadnienie golden loop) oraz inteligentnej aktywacji działań na podstawie monitorowania zdarzeń. Surma J. (2009), Business Intelligence. Systemy wspomagania decyzji biznesowych, PWN, Warszawa, s

21 mogą być chociażby emocje lub preferencje estetyczne30, które w systemach sformalizowanych nie występują lub nie są z reguły symulowane. Wydaje się, że należałoby się zgodzić ze stwierdzeniem, że znany nam świat nie ma tej, ogólnie biorąc, prostej postaci, w której wszystkie zdarzenia są zacierane, aby wyjawić stopniowo ich zasadnicze cechy, ostateczny sens, pierwszą i ostatnią wartość 31. Jest on bowiem, jak zauważa Foucault, niezliczoną liczbą splątanych zdarzeń 32. Jednak systemy wspierające w sposób ścisły wspomaganie decyzji w sposób jednoznaczny ustalają fakty. Co więcej, zmiana raz ustalonego sensu zdarzenia może mieć katastrofalne skutki. Zdarzenia są splątane, ale i poplątane. Wysiłek ludzkiego działania polega na wykluczaniu ich ze splotu, porządkowaniu i zestawianiu. Dochodzimy do sytuacji, w której anarchiczne kłącza musimy przekształcać w struktury, a zdarzeniom i opisom nadawać znaczenia wraz z przypisanymi do nich funkcjami. Te ostanie stanowią istotową własność aplikacji i narzędzi. Systemy informacyjne cechuje coraz większa ilość aplikacji oraz funkcji. W coraz większej ilości organizacji stosowane systemy i aplikacje podlegają złożonym związkom i powiązaniom, opartych na różnorodnych platformach. Częstą formą koncentracji i integracji jest wykorzystanie systemów zintegrowanych, które pełnią centralną rolę w realizacji zadań i strategii biznesowych. Użytkownicy, firmy współpracujące oraz klienci zainteresowani są odpowiedziami na konkretne pytania, które niejednokrotnie wymagają zniesienia granic pomiędzy systemami. Co więcej, z ich punktu widzenia takie granice w ogóle nie powinny być zauważalne. Ponadto, poszukiwanie informacji wiązać się powinno z minimalnym zaangażowaniem w jej odnalezienie przy jednoczesnym znoszeniu redundancji, bowiem powielanie informacji oraz funkcji w systemach informacyjnych prowadzi bezsprzecznie do intensyfikacji zadań i wysiłków mających na celu redukcję nadmiarowości. Przedstawione we wstępie kwestie heterogeniczności i złożoności są realnymi problemami zauważanymi przez decydentów. Według raportu firmy Forester najważniejszym priorytetem dla menedżerów w dużych organizacjach jest konsolidacja infrastruktury IT. Wśród innych badanych celów i zadań wymienić należy: zapewnienie ciągłości działania, usprawnianie środowiska bezpieczeństwa, wykorzystywanie 30 Por. Malmendier U., Tate G. (2008), Who makes acquisitions? CEO overconfidence and the marketʼs reaction, Journal of Financial Economics 89(1), s Malmendier U., Tate G. (2005), CEO Overconfidence and Corporate Investment, Journal of Finance 60(6), s Bracha A., Brown D. (2012), Affective Decision-Making: A Theory of Optimism Bias, Games and Economic Behavior 75, s Foucault M. (2000), Filozofia, historia, polityka, PWN, Warszawa, s Ibid. 21

22 technologii mobilnych, przebudowa architektury oraz wzbogacanie kanałów komunikacji między członkami firm33. Realizacja wielu z tych zadań wymaga nie tylko sprawnego koordynowania działań poszczególnych jednostek biznesowych, ale także uwzględnienia skutecznych strategii integracji. Początek automatyzacji procesów biznesowych, do których należą operacje księgowe i obsługa płatności datuje się na lata 60-te i 70-te XX wieku. Procesy te realizowały głównie rozwiązania bazujące na komputerach klasy mainframe. Wraz z nastaniem ery komputerów osobistych (lata 80-te) użytkownicy końcowi zaczęli stosować wiele nowych funkcji niedostępnych w minionych dekadach. Zaczęli korzystać z edytorów tekstu, arkuszy kalkulacyjnych i narzędzi graficznych. Izolację użytkowników powodowaną przez możliwości komputerów osobistych przełamały technologie sieciowe pojawiające się w latach 90-tych. Otworzyło to drogę nie tylko do wzmożonej komunikacji między członkami organizacji, ale przede wszystkim umożliwiło to realizację komunikacji poza środowiskiem firmy. Te oczywiste fakty ujawniają jednak istotną cechę rozwoju systemów informacyjnych: tendencję do znoszenia rozproszenia. Ważną rolę w tej ewolucji miało także tworzenie nowych obszarów funkcjonalnych. Zapewne głównym katalizatorem złożoności było nastanie ery cyfrowej komunikacji. Można zaryzykować tezę, że to właśnie w chwili, gdy informacja zaczyna przepływać swobodniej, zachodzi możliwość powstawania nowych obszarów funkcjonalnych Wartość biznesowa płynąca z integracji Mnogość procesów i obszarów funkcjonalnych wyklucza w wielu przypadkach zastosowanie wyłącznie systemu o charakterze zintegrowanym. Istnieje pewien próg złożoności procesów, który uniemożliwia stosowanie wyłącznie systemu monolitycznego. Złożoność ta wynika między innymi z charakteru prowadzonych działań oraz rozmiaru organizacji. Potwierdzają to między innymi tezy Carra o rosnącym znaczeniu standaryzacji rozwiązań IT przy jednoczesnym słabnięciu roli IT w osiąganiu przewagi konkurencyjnej: W dłuższym horyzoncie czasowym, największe możliwe ryzyko IT, którego może doświadczyć wiele firm jest bardziej prozaiczne, aniżeli katastroficzne. To po prostu 33 Balaouras S. (2010), Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And 2011, Technical report, Forester Research, Inc., s

23 przekroczenie budżetu. IT może stać się towarem, a jego koszty mogą spaść na tyle szybko, że nowe możliwości rozwiązania są szeroko wykorzystywane, a sam fakt wplecenia w IT wielu funkcji biznesowych oznacza, że pochłaniać będzie dużą część wydatków korporacji 34. Jako paradoksalną strategię dla zarządzania systemami informacyjnymi Carr zaleca: zmniejszanie wydatków ponoszenie znacznych wydatków na IT rzadko przekłada się na znaczące wyniki finansowe; łatwiej podążać drogą standaryzacji i korzystania z rozwiązań masowych, aniżeli narażać się na ponoszenie znaczących kosztów; zasadę naśladowania, a nie przodowania, która opiera się na zasadzie Moore'a, wskazującej nie tylko na wzrost mocy obliczeniowej procesorów, ale przede wszystkim na jej konsekwencjach ekonomicznych: zwlekanie z inwestycją IT obniża ryzyko ponoszenia znaczących kosztów oraz wyboru funkcji szybko skazanych na bezużyteczność. Oczywiście warto przy tym zauważyć, że wychodzenie z nowymi koncepcjami funkcjonalnymi i systemowymi może mieć znaczenie dla organizacji, jednak ta tendencja słabnie; koncentrowanie się na słabych punktach rozwiązań IT, a nie na szansach, gdyż organizacje zdane są coraz częściej na zewnętrznych dostawców; Mimo wszystko nawet w sytuacji stosowania się do tych zaleceń, w chwili gdy organizacja przekracza wspomniany próg złożoności, zapewne zaistnieje realna potrzeba integracji. W tym świetle możemy wyróżnić dwa powiązane ze sobą istotne elementy systemu informacyjnego: zintegrowany system i procesy integracji. Historycznie rzecz przedstawiając, zanim nastała era wzmożonej komunikacji elektronicznej, informacja skupiała się w miejscu, które w przybliżeniu można by nazwać centrum jej przepływu. Wynikało to, jak zarysowaliśmy to powyżej, z braku technologicznych podstaw, umożliwiających jej względnie swobodny ruch podlegający bezpośrednim, nieskupionym wokół jednego punktu relacjom. Sam jednak przepływ informacji należy powiązać z traktowanym tu w sposób pobieżny i intuicyjny pojęciem obszaru funkcjonalnego. Mając na uwadze te dwa elementy, spróbujmy prześledzić genezę i ewolucję systemów, w których informacja oraz funkcja zbiegają w sposób niewykraczający poza ramy tych systemów. System zintegrowany najszerzej go opisując, można zdefiniować w sposób następujący: 34 Carr N. (2003), IT Doesn't Matter, Harvard Business Review, , s

24 Mówiąc o zintegrowanym systemie informatycznym (ZSI) przedsiębiorstwa należy mieć na myśli modułowo zorganizowany system informatyczny, obsługujący wszystkie sfery jego działalności, począwszy od marketingu i planowania i zaopatrzenia, poprzez techniczne przygotowanie produkcji i jej sterowanie, dystrybucję, sprzedaż i gospodarkę materiałową do prac finansowo-księgowych i gospodarki zasobami ludzkimi 35. Ten ogólny opis zawiera pewien postulat, a mianowicie obsługę wszystkich stref działalności organizacji. Jest to niewątpliwie sytuacja modelowa, rzec by można idealna. Jak wskazaliśmy powyżej, możliwości realizacji tak określonego postulatu uzależnione byłyby od stopnia złożoności procesów oraz odpowiadających im funkcji. Definicja ta powinna zostać rozszerzona o charakterystykę struktury tego typu systemów. W modelowym ujęciu zintegrowany system informatyczny można uznać za strukturę funkcjonującą w układzie podstruktur opisanych według poniższych kryteriów36: funkcje, cele i zadania systemu należące do struktury funkcjonalnej; dane i algorytmy przetwarzania formujące strukturę informacyjną; techniczne elementy przetwarzania danych określające strukturę techniczną; rozmieszczenie przestrzenne elementów jako strukturę organizacyjno-przestrzenną. Struktura funkcjonalna ma charakter hierarchiczny oraz nadrzędny w stosunku do systemu organizacji. Jest to zbiór zadań, które system informatyczny wykonuje na rzecz systemu organizacji. Cele i funkcje wraz z wzajemnymi relacjami i zależnościami formują strukturę o postaci drzewa i własności hierarchicznej. W obrębie tej struktury należy wyróżnić: podsystemy, moduły, zbiory funkcjonalne i funktory, do których przyporządkowuje się zadania. Struktura informacyjna zawiera dane oraz algorytmy przetwarzania. Dane muszą być uporządkowane i odniesione do procesów decyzyjnych i technologicznych. Forma tego uporządkowania ma za zadanie określenie relacji między danymi. W końcu algorytmy przetwarzania danych wskazują na procesy przetwarzania danych. 35 Adamczewski P. (2004), Zintegrowane systemy informatyczne w praktyce, MIKOM, Warszawa, s. 16. W literaturze krajowej problematykę systemów zintegrowanych przedstawiają także następujące prace: Banaszak Z., Kłos S., Mleczko J. (2011), Zintegrowane systemy informatyczne, PWE, Warszawa; Kisielnicki J., Pańkowska M., Sroka H. (2011), Zintegrowane Systemy Informatyczne, PWN, Warszawa; Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Zintegrowane systemy transakcyjne, PWN, Warszawa; Lech P. (2003), Zintegrowane systemy zarządzania ERP/ERPII, Difin, Warszawa; Sroka H., Olszak C. (2001), Zintegrowane systemy informatyczne w zarządzaniu, AE Katowice, Katowice; Kasprzak T. r. (2000), Integracja i architektury systemów informatycznych przedsiębiorstw, Katedra Informatyki Gospodarczej i Analiz Ekonomicznych WNE UW, Warszawa. 36 Ibid. 24

25 Struktura techniczna tworzona jest przez środki techniczne w postaci urządzeń oraz oprogramowania mającego na celu gromadzenie danych, tworzenie ich zbiorów, przetwarzanie i udostępnianie. Struktura organizacyjno-przestrzenna określa przestrzenne zależności między elementami trzech powyższych struktur. Zależności między tą, a pozostałymi strukturami przestawiają się następująco: w odniesieniu do struktury funkcjonalnej miejsce realizacji funkcji systemu informatycznego powinno być zbliżone do miejsca realizacji funkcji w organizacji; w odniesieniu do struktury informacyjnej lokalizacja zbioru danych wejściowych powinna być bliska źródłom ich powstawania, a lokalizacja zbiorów danych wyjściowych w pobliżu ich wykorzystania; w odniesieniu do struktury technicznej istnieje istotna zależność między rozmieszczeniem elementów struktury informacyjnej oraz właściwościami środków komunikacyjnych. Zasadniczo opisy tych struktur można uznać za wciąż obowiązujące, jednak głębokie przemiany systemów informacyjnych, zwłaszcza w aspekcie struktur technologicznych i informacyjnych, wpływają na zależności pomiędzy nimi. W szczególności najmniej obowiązująca wydaje się zasada zbliżenia danych wejściowych i wyjściowych do miejsca ich powstawania i wykorzystania. Przemiany technologiczne w większości przypadków znoszą tę zasadę. Mają tu znaczenie nie tylko charakter współczesnych środków komunikacji, ale wraz z nimi także procesy wirtualizacji37. Ostatnia zależność stanowi jedną z najistotniejszych cech systemów zintegrowanych, a rozpatrywaną w kontekście kluczowych zagadnień tej rozprawy: charakter struktury informacyjnej między innymi odzwierciedlają możliwości środków komunikacyjnych38. Właściwe zagadnienie integracji wynika między innymi ze specyfiki rozwoju systemów zintegrowanych, w tym także obecnej dynamiki procesów rozproszenia, dlatego też zrozumienie podstaw i problemów pojęcia integracji oraz wartości biznesowej, którą niesie należy poprzedzić krótkim rysem historycznym, prowadzącym ku obecnym problemom i ograniczeniom systemów zintegrowanych. 37 Por. rozdział 4. zagadnienia wirtualizacji. 38 Przedstawiony w następnych akapitach rozwój systemów zintegrowanych ukazuję ścisłą zależność między tymi elementami. Np.: naturalne rozwinięcie systemów klasy ERP o systemy analityki biznesowej, sytuuje ją w ścisłym powiązaniu ze strukturą informacyjną systemów tej klasy oraz możliwymi środkami komunikacyjnymi. 25

26 Pierwociny systemów zintegrowanych należy datować na koniec lat 50-tych XX wieku, kiedy to zaczęły powstawać proste systemy ewidencjonowania oraz sterowania zapasami systemy IC (ang. Inventory Control). W roku 1957 w USA powstało Amerykańskie Stowarzyszenie Sterowania Produkcją i Zapasami (ang. APICS). Jego celem było wypracowanie komputerowych metod zarządzania organizacjami produkcyjnymi. Pod koniec lat 50-tych APICS opracowywał podstawy standardu MRP (ang. Material Requirements Planning). Jest to system wspierający planowanie i harmonogramowanie produkcji. Systemy te mają za zadanie określanie właściwej ilości materiałów wraz terminarzami ich dostaw w celu zaspokojenia popytu. W stosunku do systemów sterujących zapasami MRP umożliwiło prognozowanie, określanie stanów magazynowych oraz rozliczanie ilościowe produkcji. Główne cele klasy systemów MRP to: zmniejszanie zapasów; precyzyjne określanie czasów dostaw surowców i komponentów; wyznaczanie kosztów produkcji; kontrola poszczególnych etapów produkcji; lepsze wykorzystanie infrastruktury wytwórczej. W roku 1989 powstał standard MRP II (ang. Manufacturing Resource Planning), będący rozwinięciem standardu MRP. Został rozbudowany o elementy związane z procesem sprzedaży wraz z powiązaniem go z planowaniem produkcji. Kolejnym etapem rozwoju systemów zintegrowanych było opisanie standardu EPR (ang. Enterprise Resource Planning). ERP stanowi rozwinięcie założeń MRP II. W systemach ERP w stosunku do systemów MRP rozszerzono zakres integracji o procesy finansowe i ludzkie. W połowie lat 90-tych ubiegłego wieku nastała era systemów klasy ERP II wzbogacone o takie podsystemy jak zarządzanie relacjami z dostawcami i klientami (SRM i CRM), zarządzanie łańcuchem dostaw (SCM) czy zarządzanie cyklem życia produktów (PLM). W końcu naturalnym rozwinięciem komponentów systemów klasy ERP II są rozwiązania business intelligence, stające się nieodłącznym elementem tak pojmowanego systemu zintegrowanego. Z pobieżnego opisu tego rozwoju wynika istotna cecha systemów zintegrowanych: tendencja do obejmowania coraz szerszego spektrum funkcji, informacji i procesów. Czy jednak istnieją granice dla takiej formy ewolucji systemu zintegrowanego, dodajmy, ewolucji o charakterze ściśle genetycznym? Zanim dojdziemy do tej kwestii, spróbujmy 26

27 prześledzić korzyści płynące ze stosowania systemów zintegrowanych oraz bariery związane z ich funkcjonowaniem i przetwarzaniem. Do jednych z najważniejszych korzyści płynących ze stosowania systemów zintegrowanych należy zaliczyć39: niezawodny dostęp do informacji związany ze stosowaniem wspólnego systemu zarządzania bazą danych, zwięzłością i dokładnymi danymi; unikanie redundancji danych i działań moduły korzystają z tych samych danych zgromadzonych w centralnej bazie danych co pozwala na ograniczenie wielokrotnego wprowadzania danych oraz powtarzania operacji; redukcja czasu dostaw i cyklu produkcji; redukcja kosztów wynikająca z efektywności czasowej i zwiększonej kontroli wynikające na poziomie korporacyjnym z analizy decyzji podejmowanych w organizacji; łatwa adaptacja zmiany w procesach biznesowych są łatwe w adaptacji i restrukturyzacji; ulepszona skalowalność osiągana dzięki strukturalnej i modularnej budowie; ulepszone zarządzanie systemem użytkowanie zintegrowanego systemu wiąże się niejednokrotnie z kontraktami wsparcia producentów tych systemów. Z drugiej strony do istotnych ujemnych stron systemów zintegrowanych należą: czasochłonność związana z wewnętrzną polityką oraz problemami osiągania konsensusu; znaczące koszty wdrożenia i użytkowania; uzgadnianie funkcjonowania poszczególnych modułów z istniejącymi procesami biznesowymi; uzależnienie od producenta; nadmiarowość zawartych w systemie funkcji i złożoność konieczność rozpoznania właściwych i pożądanych funkcji; skalowalność i dostępność uzależniona od postępów prac producenta nad oprogramowaniem. Pomimo jawnych korzyści systemy zintegrowane zdają się osiągać swój kres. Wskazują choćby na to przemiany w ekonomii, w której zaznaczają się zjawiska przemiany dążenia 39 Rashid M. A., Hossain L., Patrick J. D. (2002), The Evolution of ERP Systems : A Historical Perspective w Hossain L., Patrick J. D., Rashid M. A., red., Enterprise Resource Planning: Global Opportunities and Challenges, Idea Group Inc (IGI), s

28 do posiadania produktu w chęć korzystania z usługi. Świadczy o tym choćby coraz większe zainteresowanie usługami realizowanymi w chmurach obliczeniowych. Jak wspomnieliśmy powyżej, rozwiązania klasy ERP tworzone były z myślą o zarządzaniu produktami, a nie z oferowaniem usług. Łatwo w ich obrębie uzyskać odpowiedzi na pytania o zamówienia, konta klientów czy produkty, ale czy tworzone były z myślą o dosprzedaży (ang. upselling), monitorowaniu powracających klientów? Rzecz jasna nie były one tworzone z myślą o odpowiedzi na te pytania. Co więcej, firmy nakierowane na udostępnianie usług muszą stosować w ramach tych systemów model cenowy pasujący do produktów (koszt produkcji plus zysk - ang. cost-plus pricing). Na rozwój i zastosowanie systemów klasy ERP wpływa także wspomniany czas potrzebny na osiąganie korzyści z ich wdrożenia, opór przed zmianą oraz sam ewentualny sukces wdrożenia40. Organizacje coraz częściej liczą na stosowanie systemów analityki biznesowej. Moduły analityczne będące integralną częścią systemów klasy ERP muszą uwzględniać szerokie spektrum informacji, istniejącej częstokroć poza organizacją. Niemałym wyzwaniem dla dostawców systemów omawianej klasy jest łączenie informacji ustrukturyzowanych i nieustrukturyzowanych, a wzrost wolumenów danych doprowadza do granicznej sytuacji ich możliwości przetwarzania. Pamiętajmy, że żelazne zasady informatyki mają wciąż zastosowanie i dlatego wraz ze wzrostem danych maleje ich szybkość przetwarzania. Rozwój sieci mobilnych oraz ich możliwości technologiczne sprawiają, że producenci systemów ERP są zmuszeni także rozważyć tworzenie aplikacji przystosowanych do środowisk mobilnych. Wymienione tu przemiany ekonomiczno-technologiczne należy powiązać ze zjawiskami wynikającymi z samych potrzeb organizacyjnych i około-organizacyjnych 41, a ukazującymi szerszy obszar, wykraczający już poza problematykę systemów zintegrowanych, a mianowicie obszar problemu integracji: Interakcja z klientami. W przeszłości klienci dokonywali transakcji w sklepach, lub kontaktując się ze sprzedawcami telefonicznie lub podczas spotkań. Era cyfrowa odmieniła na zawsze sposób zawierania transakcji oraz obsługę klientów, dlatego dostęp do spójnie reprezentowanej informacji ma znaczenie nie tylko z punktu widzenia procesu obsługi i cyklu zakupowego, ale, co być może ważniejsze, także z ekonomicznych uwarunkowań związanych z pozyskaniem klienta, które są znacząco wyższe, aniżeli koszty utrzymania klientów dotychczasowych. Właśnie dlatego spójny, scentralizowany obraz, począwszy od 40 Zutshi A. (2012), Future of ERP, Infosys Lab Briefings 10(1), s Gold-Bernstein B., Ruth W. (2005), Enterprise integration: the essential guide to integration solutions, Addison-Wesley, Boston, s

29 historii zakupów, preferencji oraz wsparcia po cechy klienta możliwe do określenia poza wewnętrznymi systemami informatycznymi, ma kluczowe znaczenie dla uzyskiwania najwyższej wartości z relacji z klientami. Produkcja. Nowe modele marketingowe takie jak 4PP42, w których poszczególne elementy w świetle przemian społecznych i technologicznych otrzymują nowe znaczenie, wskazują między innymi na istotne zjawisko personalizacji. Jak wiadomo, jednym z elementów modelu 4P jest produkt. Internet znacząco wpłynął na postrzeganie produktu przez organizacje i klientów. Nie tylko coraz powszechniejsza staje się możliwość dostosowywania produktu do indywidualnych potrzeb, ale także możliwość wpływania na przyszły jego kształt. Wiąże się to w istotny sposób z planowaniem produkcji oraz logistyki, a na poziomie systemów informacyjnych z potrzebą ich pełniejszej integracji. Biznes czasu rzeczywistego. W pewnych branżach szybkość podejmowania decyzji może prowadzić do znaczących zysków. W jednej z powieści Don DeLillo czytamy słowa: Czas jest korporacyjnym zasobem. Należy do wolnego rynku. Teraźniejszość jest trudna do odnalezienia. Jest wysysana ze świata, aby utorować drogę dla przyszłych niekontrolowanych rynków i ogromnego potencjału inwestycyjnego 43. Te apokaliptyczne słowa mają już pewne odzwierciedlenie w ekonomii. Minimalizowany czas podjęcia decyzji rzeczywiście prowadzi do unicestwiania teraźniejszości. Na przykład z punktu widzenia zarządzania danymi oraz ich dostępności systemy zintegrowane powinny spełniać dwie zasady: zerowego opóźnienia w przedsiębiorstwie (ang. zero latency enterprise) jest to idealna sytuacja, w której rejestrowane dane są dostępne w systemach bez opóźnienia lub inaczej zasada ta odnosi się do braku przerwy między rejestrowaniem zdarzenia, a podejmowaniem decyzji na podstawie danych odnoszących się do zarejestrowanego zdarzenia; pozwala to między innymi na zachowanie spójności równolegle podejmowanych decyzji (zarówno w perspektywie systemowej jak i ludzkiej)44; przetwarzania bezpośredniego (ang. straight through processing) polegająca na jednokrotnym wprowadzeniu danych, prowadzącym do eliminacji nieefektywnych działań takich jak ręczne wprowadzanie danych oraz w przypadkach zleceń 42 Stokes R. (2011), emarketing: The essential guide to digital marketing, Quirk emarketing, s Don DeLillo (2004), Cosmopolis, Scribner, New York, s Por. dystans akcji, a wartość w rozdz

30 płatniczych i obsługi transakcji pełnej automatyzacji procesu bez manualnej ingerencji w jego etapy; zasada ta w przypadku systemów zintegrowanych ma na celu uniknięcie sytuacji, w której powtarzane dane mogą popadać w konflikt. Zasady te przyczyniają się między innymi akceleracji procesów biznesowych. Termin czas rzeczywisty nie zawsze może zostać w pełni zastosowany i realizowany, jednak wpisanie go w kontekst teorii systemów informacyjnych z konieczności wymaga intensyfikacji działań integracyjnych. Działania operacyjne. Rozwój systemów informacyjnych odzwierciadlał niejednokrotnie struktury firm. Zadania przydzielane systemom związane były z funkcjonowaniem departamentów, które na swój sposób definiowały przedmioty swoich działań. Stworzyło to sytuacje, w których systemy mnożyły procesy oraz odpowiadające im elementy. Łatwo zatem w takich sytuacjach o ich powielanie. Potrzeba integracji wynika z potrzeby całościowego spojrzenia na działania w firmach, które uwzględniałyby wszelkie potrzeby zainteresowanych stron, ale także scalałyby je w procesy o charakterze uniwersalnym. Już sama redukcja błędów, wynikająca z integracji prowadzi do znaczących zwrotów z nakładów inwestycyjnych. Globalizacja. Otwarcie na otoczenie, uzyskiwane dzięki wzmożonej komunikacji przyczyniło się do decentralizacji organizacji. Oznacza to, że do zasobów informacyjnych mogą mieć dostęp nie tylko pracownicy, ale dostawcy, partnerzy i czasami klienci. W pewnym momencie zaistniała potrzeba tworzenia portali korporacyjnych, odpowiadających między innymi trendom wytyczonym przez zarządzanie wiedzą. Np.: portale udostępniają informacje z systemów back-office w postaci zintegrowanej. Zarządzanie. Stosowanie strategii biznesu czasu rzeczywistego przyczynia się do osiągania przewagi konkurencyjnej, ale wymaga także sprawnego monitorowania krytycznych działań. Realizacja takiej strategii możliwa jest dzięki rozwiązaniom analitycznym uwzględniającym kluczowe czynniki efektywności informujące o zmianach w czasie rzeczywistym. Zatem z jednej strony integracja może wcielać zasady biznesu czasu rzeczywistego, prowadząc do przyśpieszania procesów, ale z drugiej strony wpływa na funkcjonowanie systemów analitycznych, które wspierają podejmowanie decyzji na poziomie zarządczym. Jedną z istotnych zalet stosowania strategii integracyjnych jest ich wpływ na zwrot z nakładów inwestycyjnych. Integracja może wpłynąć na redukcję personelu, redukcję 30

31 kosztów, wzrost zyskowności i satysfakcji klientów oraz ulepszanie i optymalizację procesów biznesowych45. Put, analizując złożoność problemu integracji, pisze: W wyniku przeprowadzonego procesu integracji wieloaspektowo różnorodnych zasobów informacyjnych tworzone są jednolite standardy charakteryzujących je atrybutów, formatów, definicji i struktur, dane i informacje są jednakowo rozumiane, poprawia się także ich jakość i w efekcie uzyskuje się lepszą organizację zasobów informacyjnych 46. Istotne jest w tych słowach położenie akcentu na samą informację. Ma ona, jak analizowano wcześniej47, kluczowe znaczenie dla podejmowania decyzji. Dopiero w świetle tych słów Put dzieli korzyści płynące ze stosowania integracji na wymierne i niewymierne: wymierne: ograniczenie ilości pracowników, poprawa wydajności, zmniejszenie powielanych czynności, usprawnienie zarządzania transakcjami oraz operacji finansowych, obniżenie kosztów (od IT poprzez koszty zaopatrzenia, logistyczne i utrzymania systemów), wzrost dochodów, skrócenie czasu dostaw oraz wprowadzenie strategii biznesu czasu rzeczywistego; niewymierne: lepszy dostęp do informacji, usprawnienie procesów biznesowych, standaryzacja (komunikacji, informacji oraz sposobów jest uzyskiwania), elastyczność dostępu do informacji, lepsza koordynacja pracy między działami, usprawnienie obsługi klientów. Rysunek 3. przedstawia korzyści płynące z integracji w kontekście zasobów informacyjnych. Warto w tym miejscu zaznaczyć elementy i efekty integracji istotne z punktu widzenia systemów analityki biznesowej. Z punktu widzenia przygotowania i projektowania architektury systemów analityki biznesowej ważą rolę odgrywają: standaryzacja atrybutów, formatów, struktur i definicji; identyfikacja systemów, baz danych i repozytoriów; poprawa jakości zasobów informacyjnych. Natomiast następujące efekty integracji mają bezpośrednie przełożenie na funkcjonowanie wspomnianych systemów: 45 Gold-Bernstein B., Ruth W. (2005), Enterprise integration, op. cit., s Put D. (2010), Wieloaspektowość zagadnienia integracji zasobów informacyjnych w dynamicznych strukturach sieciowych w Chmielarz W., Kisielnicki J., Parys J., red., Informatyka Q Przyszłości, Wydawnictwa Naukowe WZ UW, Warszawa, s Por. wstęp rozprawy. 31

32 wzrost możliwości obliczeniowych i analitycznych; możliwość agregacji, selekcji, projekcji i wyliczeń; dostęp do zasobów informacyjnych w czasie rzeczywistym. Zagadnienie integracji ukazaliśmy w pozytywnym świetle, jednak osiągnięcie celu, jakim jest doprowadzenie do pełnej sprawności strategii i procesów integracyjnych wiąże się z ogromną złożonością samych założeń i czynników. W chwili pojawienia się Rysunek 3. Zasoby informacyjne oraz składniki i efekty integracji. Źródło: Put D. Wieloaspektowość zagadnienia integracji zasobów informacyjnych w dynamicznych strukturach sieciowych w Chmielarz W., Kisielnicki J., Parys J., red., Informatyka Q Przyszłości, Wydawnictwa Naukowe WZ UW, Warszawa, s. 220 wraz z modyfikacjami. 32

33 technologii sieciowych wydawało się, że integracja będzie przebiegać we względnie przyswajalny sposób. Samo pojęcie sieci jako medium uwolniło wizje o powszechnej komunikacji. Jednak początki funkcjonowania sieci w organizacjach wiązały się z własnościową technologią, a protokoły sieciowe rozwijane przez różnych producentów nie podlegały łatwej negocjacji. Gdy większość sieci korporacyjnych funkcjonowała na poziomie departamentów, a coraz powszechniejszą metodą komunikacji stała się poczta elektroniczna, stało się jasne, że organizacje nie będą mogły obyć się bez działań zmierzających ku integrowaniu systemów. To dopiero standaryzacja protokołów sieciowych umożliwiła integrację na najbardziej rudymentarnej płaszczyźnie, płaszczyźnie sieciowej. Istotnie, bez standaryzacji protokołów, technologii czy języków zapytań, procesy integracyjne byłyby trudniejsze do przeprowadzenia. Podobnie odwoływanie się do współczesnych standardów integracyjnych może wzorem poprzednich dekad ułatwić integrację. Same jednak standardy niekoniecznie muszą przyczynić się do sukcesu integracji. Organizacje powinny odwoływać się do przygotowanej strategii integracyjnej, zawierającej oprócz opisów standardów także sposoby podejścia integracyjnego (np.: typy integracji). Przystąpienie do tworzenia strategii powinno jednak wiązać się ze świadomością ograniczeń i problemów. Za Putem, problemy i wyzwania możemy podzielić na cztery grupy: społecznoorganizacyjne, związane z zasobami informacyjnymi, związane z procesem integracji oraz pozostałe48. Na poziomie organizacyjnym samo pojęcie integracji oznacza istotną zmianę: Jednym z podstawowych zadań dla integracji systemów informatycznych jest zapewnienie łatwego i szybkiego dostępu do danych dla pracowników organizacji i osób współpracujących w zależności od ich roli i przypisanych praw dostępu 49. Rozpoczęcie planowania procesów integracyjnych wiąże się między innymi z koniecznością zaangażowania kierownictwa już na etapie planowania wraz z pokonaniem dystansu członków projektu do podejmowanych wysiłków integracyjnych. Dystans ten dotyczy nie tylko decydentów, ale także wszelkich osób lub jednostek biznesowych mających udostępniać własne zasoby. Nawet przy wysokiej kulturze organizacyjnej oraz 48 Ibid., s Markowski M. (2005), Złożoność integracji systemów informatycznych w Kisielnicki J., Grabara J. K., Nowak J. S., red., Informatyka i współczesne zarządzanie, Polskie Towarzystwo Informatyczne, Katowice, s

34 przy stosowaniu strategii zarządzania wiedzą wciąż dominuje przekonanie o przynależności danych do departamentów oraz osób odpowiedzialnych za ich tworzenie. Co więcej, z racji uwarunkowań genetycznego rozwoju infrastruktury informatycznej (dotyczy to w głównej mierze organizacji o dłuższej historii) istnieje silne przekonanie nie tylko o prawach do własności informacji i danych, ale także o prawach do samych systemów odpowiedzialnych za ich przetwarzanie. Prowadzi to niejednokrotnie do konfliktu interesów i do braku zaufania między partnerami biznesowymi. Inną przyczyną problemów natury społeczno-organizacyjnych jest niezrozumienie oczekiwań partnerów i niejednakowe rozumienie informacji, która w różnych systemach lub jednostkach organizacyjnych pełnić może odmienne funkcje. Wiąże się to także z brakiem wiedzy o danych gromadzonych przez inne działy czy partnerów. Złożoność zasobów, na którą kładliśmy tu już wielokrotnie nacisk, wynika między innymi z różnorodności procesów, które należy uzgadniać ze sobą, a które są silnie powiązane z jednostkami je realizującymi. Oczywiście może to być także przyczyną konfliktów. Problemy te wskazują na relację informacji oraz procesów do samej kwestii integracji. Hohpe i Woolf wskazują na istotny problem związany z procesem integracji, a będący rozszerzeniem prawa Conwaya. Według Conwaya organizacje projektujące systemy są ograniczone do tworzenia projektów, które są kopiami struktur komunikacyjnych tych organizacji 50. Oznacza to nie tylko, że zespoły projektowe funkcjonują podług konkretnych obszarów funkcjonalnych, ale przede wszystkim konieczność koordynacji działań między jednostkami biznesowymi a działami IT51 - w tym wypadku komunikacja jest z reguły bardzo utrudniona, co przekłada się na tworzone rozwiązanie integracyjne. Integracja obejmować musi nie tylko porozumienie i współdziałanie różnych grup, ale przede wszystkim prowadzić do świadomości, że w zintegrowanej aplikacji korporacyjnej grupy nie kontrolują określonej aplikacji, ponieważ aplikacja jest odtąd częścią całościowego przepływu różnych aplikacji i usług. Przykładem takiej strategii może być związek stosowania integracji opierającej się na usługach przy zastosowaniu architektury zorientowanej na usługi (SOA) ze zmianami w strukturze organizacyjnej Hohpe G., Woolf B. (2007), Enterprise Integration Patterns: designing, building, and deploying messaging solutions, Addison-Wesley, s Por. także o znaczeniu rozwiązań self-service BI w minimalizowaniu konfliktów między działami IT a jednostkami biznesowymi (rozdz. 5). 52 Po skalkulowaniu wartości biznesowej SOA na potrzeby ROI i wydajności IT (np.: ponowne wykorzystywanie i zredukowanie kosztów rozwoju aplikacji), zachowania ekonomiczne organizacji muszą być zaadoptowane tak, aby wspierać wizję SOA. Nowe inicjatywy muszą zostać zinstytucjonalizowane, aby ukierunkowywać organiczną ewolucję organizacji w stronę tej wizji. 34

35 Z założenia integracja pociąga za sobą pokonanie przeszkód związanych z zasobami informacyjnymi. Wysunęliśmy hipotezę o wpływie intensyfikacji komunikacji na powiększanie się obszarów funkcjonalnych. Nie trudno o jej rozszerzenie. Każda nowa funkcja wzbogaca możliwości podejmowania decyzji. Różnorodność podejmowanych decyzji dodatkowo kwantyfikuje ilość informacji. Oczywiście w tym miejscu nie będziemy rozstrzygać o prymacie informacji nad funkcją. Bez względu na to, czy to potrzeba korzystania z nowych funkcji, czy też chęć posiadania bogatszych źródeł informacji przyczyniły się do jej proliferacji, bezsprzecznie mamy do czynienia z jej lawinowym wzrostem. Prowadzi to do różnorodności formatów danych oraz rodzajowego zróżnicowania informacji. Towarzyszy temu brak jednolitych standardów opisu, co jednokrotnie powodowane jest brakiem semantyki lub jej różnorodnością. W systemach przetwarzania danych informacja może być powielana. W różnych systemach bazodanowych funkcjonować mogą różne modele danych, które z biegiem czasu mogą ulegać transformacjom. Napotyka się także konflikty w metadanych. Dane charakteryzować może zła jakość, a za nią niepewność, sprzeczność lub brak ich wiarygodności. Ponadto niejednokrotnie wysiłki integracyjne wymagają łączenia danych zewnętrznych przy barku bezpośrednich połączeń. Poważną barierą może być także sam proces integracji. Strategia integracyjna powinna zawierać metody i miary oceny skuteczności projektu integracyjnego. Skuteczny proces integracji wymaga metodologii prowadzenia, wdrażania i funkcjonowania rozwiązania integracyjnego. Sytuację utrudnia także różnorodność typów i technologii integracji. Sam projekt może mieć charakter długofalowy i wymaga współdziałania w długim horyzoncie czasowym z partnerami biznesowymi. W końcu rozwiązanie integracyjne musi uwzględniać metody dostępu do systemu, a także rozwiązanie problemów prezentacji informacji użytkownikom, a sam projekt zwierać powinien politykę bezpieczeństwa i poufności, zważywszy na całkowitą lub częściową formę unifikacji zasobów informacyjnych. Bieberstein N. et al. (2005), Impact of service-oriented architecture on enterprise systems, organizational structures and individuals, IBM Systems Journal 44(4), s

36 2.3. Rodzaje, style i typy integracji Inicjatywy integracyjne mogą przybierać różne formy: od taktycznych po strategiczne, a różne wymagania biznesowe domagają się różnych typów technologii integracyjnych 53. Do wymagań biznesowych przyczyniających się do inicjatyw integracyjnych i wpływających na formy samej integracji, należy zaliczyć: wzrost wydajności i konkurencyjności, poprawa zadowolenia klientów, fuzje i przejęcia oraz problemy regulacyjne. Działania integracyjne mające na celu doprowadzenie do wzrostu efektywności i wydajności można podzielić na dwa typy. W inicjatywach o charakterze strategicznym głównym celem jest automatyzacja i zarządzanie procesami biznesowymi wraz z ich symulacją. Taktyczne inicjatywy koncentrują się na ujednolicaniu, niespójności danych oraz na rozbieżnościach w działaniach i funkcjonowaniu aplikacji raportujących. Organizacje czerpiące bezpośrednie zyski z bliskiego kontaktu z klientami i pragnące poprawić stopień zadowolenia z relacji z klientami muszą często łączyć ze sobą takie elementy infrastruktury IT jak CRM i SFA (ang. sales force automation), portale, środowiska mobilne. Integracja o charakterze strategicznym powinna w przypadku takich motywacji powinna koncentrować się na analityce oraz symulacji zarządzania procesami. Taktyczne działania integracyjne z reguły uwzględniają niektóre z tych elementów. Na poziomie strategicznym stosowanie złożonej analityki musi zazwyczaj łączyć wiele systemów i zadanie to ma charakter jeśli nie całościowy, to uwzględniający większą ilość systemów oraz powiązań, szczególnie w zakresie miar oceny zadowolenia: wskaźniki utrzymania klienta, czas reakcji na zapytania klientów, liczby skarg, wskaźniki rozwiązań problemów czy wartość klienta. Na poziomie taktycznym integracja może uwzględniać na przykład poprawę funkcjonowania portali lub ich mobilną implementację bądź wytyczona być może przez cel taktyczny taki jak na przykład usprawnienie procesu zakupowego. Organizacje niejednokrotnie łączą się z innymi lub są nabywane przez inne. Taka sytuacja stawia jasny cel przed decydentami IT: integrację wynikającą z nadmiarowości systemowej oraz niekompatybilności. Podejmują oni zwykle decyzje o wyborze jednych systemów na rzecz innych i konwersji danych z systemów eliminowanych, co ogranicza wysiłki integracyjne. Inne działania mają na celu integrację systemów bez ich eliminowania, ale często sam proces integracji może być na tyle złożony, że utworzenie 53 Gold-Bernstein B., Ruth W. (2005), Enterprise integration, op. cit., s

37 nowego systemu może przynieść lepsze rezultaty. Oczywiście wraz ze złożonością i heterogenicznością różne z tych podejść stosowane są z reguły jednocześnie. W końcu czynnikiem wpływającym na inicjatywy integracyjne mogą być kwestie standardów raportowania (np.: finansowego przy użyciu standardu XBLR) czy regulacje prawne i branżowe. Realizacja strategii integracyjnej może przynieść znaczący zwrot z nakładów inwestycyjnych. Gold-Bernstein wymienia następujące praktyki, wskazane przy projektach integracyjnych54: Utworzenie planu działania zawierającego zarys strategii, a ściślej wiedzę, procesy i architekturę. Z reguły plan działania powinien obejmować okres od 2 do 3 lat; Określenie wskaźników oceny efektywności strategii; Minimalizacja redundancji. W tym przypadku redundancja odnosi się nie tylko do zasobów systemowych i informacyjnych, ale także do zasobów projektowych, zwłaszcza zasobów ludzkich; Minimalizacja zestawu pożądanych kompetencji. Umożliwia to między innymi staranne określenie standardów na poziomie korporacyjnym; Inwestycja w ponowne wykorzystanie. Statystyki pokazują, że podniesienie kosztów integracyjnych rozwiązań taktycznych o 10% do 20% prowadzi często do możliwości ponownego wykorzystania części lub całości rozwiązania; Rewizja inicjatyw integracyjnych pod wpływem strategicznych zmian w organizacji. Zmiany w ogólnych wytycznych działań integracyjnych wymagają aktywnego uczestnictwa managementu najwyższego poziomu. O złożoności problemu integracji świadczy wielość jej aspektów. Zacznijmy od najbardziej rudymentarnego podziału, który odnajdujemy w pracy Chmielarza55. Wymienia on następujące typy integracji: projektową, techniczną, organizacyjną i konstrukcyjnotechnologiczną. Integracja projektowa ma na celu określenie norm, haseł, klasyfikacji i nazw dokumentów. Jest to punkt wyjściowy inicjatywy integracyjnej. Ten charakter integracji można powiązań z wyżej wskazaną praktyką utworzenia planu działania rozwiązania integracyjnego. 54 Ibid., s Chmielarz W. (2000), Rola tendencji integracyjnych w kształtowaniu systemów informatycznych zarządzania w Kasprzak T., red., Integracja i architektura systemów informacyjnych przedsiębiorstw, Wydawnictwo WNE UW, Warszawa, s

38 Integracja techniczna polega na zapewnieniu spójności między oprogramowaniem, zabiegami programistycznymi i platformą przetwarzania. Z warstwą tą należy powiązać takie elementy jak aplikacje, informacje, procesy oraz systemy. Integracja organizacyjna ma na celu dostosowanie struktury organizacyjnej lub reorganizację jednostek biznesowych do potrzeb przepływu informacji. Związana jest zatem ze swoistym wyznaczeniem celów systemów informacyjnych zgodnych z potrzebami organizacji lub odwrotnie Przy czym ten drugi przypadek ma raczej znaczenie drugorzędne. Integracja konstrukcyjno-technologiczna ma charakter scalający trzy typy wymienione powyżej. Polega przyjęciu jednolitych założeń dotyczących informacji, technicznych metod realizacji integracji oraz ewentualnych konsekwencji dla struktury organizacji. Z punktu widzenia rodzaju połączenia integrację można podzielić na dwa rodzaje: każdy z każdym (ang. point-to-point) oraz przy użyciu warstwy pośredniej (ang. middleware). W pierwszym modelu aplikacje łączone są ze sobą bezpośrednio, niejednokrotnie za pomocą niezależnych technologii integracyjnych. Największym problemem tego modelu jest skalowalność, gdyż przy dodawaniu nowych aplikacji wzrasta liczba połączeń, co skutkuje wzmożeniem działań mających na celu integrowanie systemów i aplikacji. Natomiast model, w którym występuje warstwa pośrednia definiuje interfejsy komunikacyjne ogólnego przeznaczenia 56. O ile w przypadku rozwiązań typu point-to-point liczba połączeń integracyjnych rośnie wykładniczo w zależności od ilości aplikacji, o tyle w przypadku połączeń integracyjnych opierających się na warstwie pośredniej liczba połączeń rośnie liniowo. Oznacza to, że drugi model ma większe znaczenie w organizacjach o rozbudowanej strukturze systemów informacyjnych. Jednak w przypadku mniejszych środowisk wiąże się to z czasochłonnością budowy systemu opartego na warstwie pośredniej oraz ze znacznymi kosztami w porównaniu do rozwiązań integracyjnych point-to-point. Z drugiej strony integrację opartą o middleware cechuje mniejsza wydajność. W pracy Gold-Bernstein i Ruth czytamy: Integracja korporacyjna nie jest rozwiązaniem gotowym. Jest to termin który obejmuje szerokie spektrum rozwiązań technologicznych, włączając: pośredniczące oprogramowanie komunikacyjne, oprogramowanie wymiany informacji, serwery integracyjne z mapowaniem danych, transformacją i narzędziami routingu, serwery 56 Szpielak D. (2007), Techniki integracji systemów informatycznych w Kozielski S. et al., red., Bazy Danych: Nowe Technologie, WKŁ, Gliwice, s

39 aplikacji z funkcjami integracji, integrację procesów biznesowych i ich zarządzanie (BPM), integrację business-to-business (B2Bi), integrację mobilną czy rozwijające się technologie takie jak usługi webowe i XML 57. W celu organizacji inicjatyw integracyjnych wymienieni autorzy proponują zastosowanie architektury integracyjnej o wielowymiarowym charakterze. W architekturze tej wyróżnić trzeba trzy podejścia: usługową architekturę integracyjną, architekturę integrującą procesy biznesowe, informacyjną architekturę integracyjną. Pierwsza z nich definiuje luźno powiązane i możliwe do wielokrotnego stosowania usługi biznesowe. Ma ona charakter integracji aplikacyjnej, podatnej na zmiany biznesowe. Wraz z nastaniem standardów usług webowych jej znaczenie wyraźnie wzrosło. Architektura integrująca informacje ma za zadanie utworzenie uniwersalnego obrazu danych zawartych w rożnych systemach. Bez integralności rozproszonych danych wartość rozwiązań integracyjnych na pewno maleje. Wartość informacji, znaczenie i integralność może być osiągana dzięki tworzeniu metadanych, czyli informacji o danych. W końcu architektura integrująca procesy biznesowe modeluje ich zachowanie oraz umożliwia ich unifikację. Prowadzi do wzrostu wydajności i ulepszania procesów. Integracja usług. W architekturze zorientowanej na usługi ustanawia się bariery między większymi częściami logicznymi (obszarami biznesowymi np.: takimi jak klient, zamówienie, promocje). Oznacza to, że w architekturze tej procesy i funkcje biznesowe tworzone są jako niezależne komponenty ze standardowymi interfejsami, które mogą być wykorzystywane przez inne aplikacje, usługi czy procesy bez względu na platformę lub język programowania 58. W przeszłości architektura była już obecna, ale organizacje i zespoły programistyczne musiały opierać się na między innymi na takich rozwiązaniach jak COBRA, J2EE czy.net. Jednak dopiero powstanie standardu SOAP, na którym oparto usługi webowe stało się podstawą dla szerokiego stosowania SOA. W dokumencie firmy Gatner59 dowiadujemy się, że do rozwoju SOA przyczyniły się między innymi rozwiązania personalizujące rożnego rodzaju interfejsy użytkownika: webowe i portali. Użytkownicy o różnych rolach w przedsiębiorstwie w różnych 57 Gold-Bernstein B., Ruth W. (2005), Enterprise integration, op. cit., s Ibid., s Natis Y. V. (2003), Service-Oriented Architecture Scenario, Gartner Inc., s

40 sytuacjach używają tych samych funkcji biznesowych zlokalizowanych po stronie zaplecza infrastruktury IT. Do korzyści ze stosowania SOA możemy zaliczyć: przyrostowy rozwój i wdrażanie oprogramowania biznesowego; możliwości ponownego wykorzystania komponentów w różnych sytuacjach; niski koszt zestawiania nowych procesów biznesowych; przejrzystość topologii aplikacji; wysoki zwrot z nakładów inwestycyjnych; doprowadzanie do sprawności biznesowej; redukcję kosztów szkoleń; obniżanie kosztów testowania i usuwania błędów; przyśpieszanie rozwoju aplikacji dzięki działaniom równoległym. Integracja nakierowana na procesy zamiast przesłanek technicznych uwzględnia poziom procesowy. Główne zadanie tego rodzaju integracji polega na tworzeniu modeli procesów oraz definicji, które dają ogólny obraz głównych zadań biznesowych. Integracja procesów umożliwia tworzenie procesów od końca do końca, czyli procesów kompleksowych obejmujących swoim zasięgiem istniejące systemy i różnorodne platformy. Integracja ta umożliwia między innymi monitorowanie wskaźników wydajności w czasie rzeczywistym i symulację procesów wykorzystywaną do ich optymalizacji. Już w latach 50-tych William Edwards Deming dowodził, że optymalizacja procesów biznesowych prowadzi do wzrostu sprawności biznesowej i efektywności ekonomicznej. Jego tezy przyczyniły się do między innymi do analizy procesów produkcyjnych. Do współczesnych technologii integracji procesowej należą: Business Process Management (BPM), Business Process Integration (BPI), Business Process Automation (BPA), Workflow Automation (WA), Business Activity Monitoring (BAM) i Web Service Orchestration (WSO). BPM obsługuje wszelkie aspekty zarządzania procesami: od projektowania, modelowania, wdrażania po monitorowanie. Wspiera procesy manualne i automatyczne. BPI odnosi się do metod integracji procesów z podległymi aplikacjami oraz monitorowania procesów w kompleksowy sposób. Jednak jego podstawowe zadanie to integracja bez zarządzania procesami. Jest to rozwiązanie mniej kompleksowe od BPM. Jego znaczenie rośnie w chwili, gdy zarządzający nie są zainteresowani zarządzaniem procesami, ale raczej zmianami w samych procesach lub odniesieniem się do konkretnych jednostek biznesowych. 40

41 BPA wspierają automatykę procesów i z reguły są nakierowane na procesy transakcyjne i z reguły nie wspierają procesów manualnych. WA mają za zadanie skracanie czasu w przerwach zaistniałych w procesach manualnych. Dzięki automatyzacji WA zapewnia przydzielanie zadań do pracowników na podstawie zdefiniowanych reguł. Odpowiedzialni za konkretne zadania mogą aktywnie śledzić zlecenia, raportować oraz uruchamiać kolejne etapy procesów. BAM to istotne narzędzie wiążące wskaźniki czasu rzeczywistego z rozwiązaniami business intelligence takimi jak eksploracja danych lub analiza trendów. Niektóre rozwiązania BAM wspierają kokpity wraz z alertami i powiadomieniami wraz z wytycznymi i regułami działań. W końcu same systemy są w stanie podejmować decyzje na podstawie żądanych wartości wskaźników. WSO łączy zarządzanie procesami z usługami webowymi. Sprawdza się między innymi w tworzeniu aplikacji kompozytowych, jednak przy złożonych procesach i środowiskach lepszym wyborem byłoby narzędzie BPM. Integracja informacji. Niemalże każdy projekt integracyjny powinien opierać się na spójnym obrazie informacji. Właściwe zadania architektury integracji informacji polegają na określaniu danych dotyczących obiektów biznesowych takich jak klienci, pracownicy, produkty itp. Opis danych, nazywany metadanymi umożliwia zapytywanie o informacje, raportowanie, konsolidację, synchronizację i w końcu integrację. Istnieje kilka standardów tworzenia i użytkowania metadanych. Zaliczyć do nich można standardy tworzone przez takie organizacje jak W3C (World Wide Web Consortium), OASIS (Organization for the Advancement of Structured Information Standards), OMG (Object Management Group), OAG (Open Aplication Group) Integrację informacji można podzielić na dwa rodzaje: agregację i publikację. Agregacja ma za zadanie skupianie informacji z różnych systemów w postaci jednego modelu metadanych. Natomiast publikacja informacji polega na jej rozsyłaniu do systemów przetwarzających. W architekturach integracji informacji jej konsolidacja realizowana jest między innymi za pomocą technologii EII (ang. Enterprise Information Integration), w której do tworzonego wirtualnego schematu odwołują się użytkownicy i aplikacje. Więcej miejsca technologii EII poświęcimy w następnym rozdziale. 41

42 3. Zagadnienia systemów klasy Business Intelligence 3.1. Systemy klasy BI jako systemy integrujące Powód dla którego próbować będziemy określić systemy klasy Business Intelligence jako systemy integrujące, polega na aktywnych procesach i zadaniach integracyjnych. Oznacza to, że podejście do statycznego funkcjonowania rozwiązań BI należy umieścić w kontekście praktyk integracyjnych, a nie samej charakterystyki systemów zintegrowanych. Przywołać tu zatem należy zarysowane w poprzednim rozdziale rozróżnienie między systemem zintegrowanym, a procesami i inicjatywami integracyjnymi. Na potrzeby tej rozprawy systemy BI przyjmiemy za właściwy punkt wyjścia dla spojrzenia na rozwój systemów analityki biznesowej. Najpierw powróćmy do zarysowanej we wstępie relacji zachodzącej między danymi, informacją, a wiedzą. Przedmiot pracy koncentruje się między innymi na pośredniej relacji uwzględniającej potrzebę znoszenia napięcia między rozproszeniem, a integracją. Proces ten, przebiega na dwóch płaszczyznach: systemowej i zasobów. Rozproszenie zasobów organizacji (informacyjnych, ludzkich oraz rzeczowych) potęgowane jest przez odpowiadające mu rozproszenie w warstwie systemowej (sformalizowane procesy i odpowiadające im aplikacje oraz systemy przetwarzania, analizowania i dystrybucji danych odniesionych do procesów). Właściwe zadanie systemów informacyjnych polega na reprezentacji i zarządzaniu zasobami organizacyjnymi. Oznacza to, że wszelkie procesy przebiegające na płaszczyźnie zasobów organizacyjnych powinny w sytuacji modelowej znaleźć swoje miejsce w warstwie systemowej. Oczywiście sytuacja ta oznaczałaby, że każda decyzja o charakterze systematycznym i metodycznym powinna być podejmowana w oparciu zasoby organizacyjne przetworzone w systemie informatycznym. 42

43 Zanim jednak decyzja zostanie podjęta dane muszą zostać przekształcone w informację, która zostaje wcielona w obszar wiedzy sformalizowanej lub niesformalizowanej. Pozostawiamy jednak w tym miejscu problem roli formalizowania wiedzy i jego stopnia w skuteczności działań ekonomicznych60. Formalizacja wiedzy wymaga precyzyjnych metod gromadzenia danych. Te ostatnie są zapisami zaistniałych faktów i stanów rzeczy. Po ich rejestracji nie można sobie wyobrazić zmiany ich znaczenia, choć błędny zapis oczywiście może zostać poprawiony. Jednak prosty fakt rejestrowany z systemach informacyjnych powinien charakteryzować się względną stabilnością opisu. Ma to zasadnicze znaczenie w procesach podejmowania decyzji. Zazwyczaj dane kojarzy się z precyzyjnym, ścisłym i niepodlegającym przemianom opisem. O ile jednak we wczesnym etapie funkcjonowania systemów informacyjnych przetwarzanie danych wiązało się z ich precyzyjną strukturą, warunkującą ich podobieństwo, o tyle współcześnie dane, tak często zapisywane w postaci cyfrowej, niejednokrotnie nie posiadają usystematyzowanej struktury. Właśnie dlatego ważną rolę w problematyce wykorzystywania, przetwarzania i udostępniania danych ma podział na dane ustrukturowane i nieustrukturowane. Dane ustrukturowane najczęściej rezydują w bazach danych. Spotyka się także zapisane w postaci plików jednorodnych lub formatach zapisu danych różnych aplikacji. Systemy informacyjne przetwarzają jednak także inne typy danych takie jak złożone dane systemów zastanych (ang. legacy systems). Coraz częściej systemy funkcjonują w oparciu o dane o charakterze semi-strukturalnym (XML lub standardy podobne). Systemy rejestrują także zdarzenia systemowe, tworząc oddzielną grupę danych. Ponadto systemy przetwarzają także dane standardów przemysłowych. Rejestrują położenie geograficzne obiektów oraz pracowników i dane bez wyraźnej struktury: wypowiedzi w języku naturalnym, audio i wideo. Te ostatnie typy danych odnajdujemy nie tylko w obrębie organizacji, ale także w sieciach społecznościowych i innych serwisach webowych. Zanim dane trafią do systemów wspomagających podejmowanie decyzji rejestrowane są i przetwarzane w systemach transakcyjnych, niejednokrotnie o charakterze systemów 60 Problem ten dotyczy choćby komponentów afektywnych w podejmowaniu decyzji przez członków organizacji. Ponadto wiedza podlegająca systematyzacji zdaje się posiadać swoje granice wyznaczające obszar, który możemy nazwać epistemologicznym niezdeterminowaniem, bowiem nie każdy obszar wiedzy może być w sposób precyzyjny opisany i formalizowany. 43

44 zintegrowanych. Januszewski wymienia następujące cechy danych istniejących w tych systemach61: duża ilość zbiorów danych wpływa negatywnie na orientację pracowników w ich przeznaczeniu oraz zawartości; ich formalny opis jest często mało przejrzysty, a nazewnictwo tabel i struktura baz są z reguły czytelne dla twórców systemów lub dla osób zarządzających infrastrukturą; ich głównym celem jest spełnienie warunku ewidencjonowania, a nie analizowania; Na problematyczność kwestii podejmowania decyzji wpływa nie tylko niepełna kodyfikacja informacji w organizacjach, ale także możliwości kwantyfikowania danych. Ponadto wielorakie systemy działając w oparciu o różne struktury i modele danych, umieszczają je nie tylko w niezależnych repozytoriach, ale także w niezależnych lokalizacjach. Systemy transakcyjne i operacyjne cechuje warunek szybkości i niezawodności. Ich zadanie polega na precyzyjnym rejestrowaniu zdarzeń. Na przykład dotarcie do danych historycznych w systemach transakcyjnych i przetwarzanie ich bezpośrednio w tych systemach wiązałoby się ze spadkiem wydajności związanym z analizą danych, a w konsekwencji mogłoby negatywnie wpłynąć na podstawowe procesy biznesowe (np.: obsługę transakcji lub ewidencji klientów). Właśnie dlatego klasyczny model rozwiązań business intelligence stanowi element wydzielonej, choć zależnej od innych systemów platformy. Oczywiście postępujące zmiany technologiczne dopuszczają coraz częściej możliwość bezpośredniego przetwarzania analitycznego w systemach transakcyjnych, na przykład za pośrednictwem warstwy pośredniej, ale tego typu rozwiązania mają dość istotne ograniczenia w stosunku do tradycyjnych modeli systemów BI. Wspomnimy o nich w części poświęconej architekturze integracji danych. Opis formalny informacji przedstawiony przez Stefanowicza odpowiada ogólnemu rozumieniu informacji jako interpretowanych danych62. Za informację możemy uznać każdy komunikat będący treścią pewnej interpretacji. Komunikat uwzględnia opisywany obiekt, cechy lub atrybuty obiektu, wartości cechy obiektu oraz czas, w którym cecha obiektu posiada wartość. Systemy wspomagania decyzji, a zwłaszcza systemy business intelligence dostarczają ogromne ilości informacji, których właściwy dobór wpływa na 61 Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Systemy Business Intelligence, T. 2, PWN, Warszawa, s Stefanowicz B. (2007), Informatyczne systemy zarządzania - przewodnik, Szkoła Główna Handlowa, Warszawa. 44

45 skuteczne działania rynkowe. Zauważmy przy tym, że dostarczane przez te systemy informacje mają ściśle faktograficzny charakter63. Pojawia się tu zatem problem określenia wartości informacji. Surma tak przedstawia wyniki badań wykazujące poniższe zagadnienia pomiaru informacji64: mierzenie informacji informacja powinna być mierzona w odniesieniu do wartości użytkowej; dostęp wartość informacji maleje wraz ilością osób ją posiadających; wiarygodność źródła wartość informacji zależy od wiarygodności źródła, z którego pochodzi; zdolność do wykorzystania wartość rośnie, w chwili, gdy potrafimy wykorzystać informację; jakość im większa jakość informacji (kompletność, prawdziwość), tym większa jej wartość; kontekst wartość informacji wiąże się tzw. efektem posiadania, w świetle którego dobro sprzedawane oceniane jest wyżej, aniżeli dobro kupowane czas im starsza informacja, tym niższa jej wartość; mnogość zastosowań im większe możliwości zastosowania, tym trudniej ocenić wartość informacji; asymetria informacyjna wartość może być niejednokrotnie odkryta dopiero po zapoznaniu się z jej treścią. Ta ogólna charakterystyka ukazuje informację zwłaszcza jako dobro podlegające ekonomicznej wymianie z istotną cechą ekonomiczną, którą jest ograniczoność występowania. Pojawiają się tu jednak pytania istotne z punktu widzenia podejmowania decyzji w przedsiębiorstwie: Czy w samej organizacji ograniczanie dostępu do informacji może zmniejszyć jej wartość? Czy informacje rzeczywiście tracą wartość wraz z ich czasem występowania? Czy można zastosować efekt posiadania do systemów analityki biznesowej? Na ile asymetria informacyjna może być przedmiotem nieekonomicznej wymiany informacji? 63 Stefanowicz przedstawiając interpretację infologiczną danych, wymienia także inne rodzaje informacji: semantyczne - określające znaczenie obiektu, proceduralne opisujące sposoby działania, normatywne nakładające normy na opisywane obiekt, klasyfikacyjne ustanawiające miejsce obiektu w wytypowanych zbiorach, strukturalne przedstawiające strukturę obiektu, przestrzenne określające położenie obiektu, komparatywne porównujące stany. 64 Por. Łach T. (2007), Wartość informacji w podejmowaniu decyzji gospodarczych, Szkoła Główna Handlowa, Warszawa oraz Surma J. (2009), Business Intelligence. Systemy wspomagania decyzji biznesowych, PWN, Warszawa, s

46 Wydaje się, że informacja w obrębie organizacji raczej nie podlega modelowi ekonomicznej wymiany, choć jak zauważyliśmy wcześniej, niektóre jednostki biznesowe mogą aspirować do prawa do własności pewnych informacji. Nawet jeśli aspirują do jej posiadania, z reguły nie wynikają z tego faktu żadne roszczenia. Swoiste ukrywanie informacji może być elementem gry, wymiany i osiągania przewagi, co potwierdza możliwość zaistnienia asymetrii informacyjnej. Chodzi tu zatem o zachowania o charakterze ochrony informacji, co wskazywałoby na przypisywanie jej pewnej wartości, zapewne odnoszącej się określenia stosunków zależności i władzy. Można zatem wysnuć przypuszczenie, że na gruncie określania wartości informacji uwarunkowania wymiany ekonomicznej w obrębie organizacji przekształcają się stosunki władzy. Na tę sytuację ma także psychologiczny efekt posiadania. Odniesienie informacji do wartości materialnej może stwarzać problemy w sytuacji mnogości jej zastosowań, ale z punktu widzenia skuteczności rynkowej przedsiębiorstwa powszechna dostępność informacji oraz mnogość jej zastosowań, jak też dowolny czas, w którym powstała zdają się być koniecznym warunkiem dla owej skuteczności. Te przypuszczenia wiodą nas w stronę trzeciego elementu omawianej triady, a mianowicie wiedzy. Pytanie o wiedzę stanowi przedmiot rozważań humanistyki od kilku tysięcy lat. W trójelementowej relacji uwzględniającej dane i informację wiedza staje się zasobem o charakterze ekonomicznym i jest silnie zespolona z racjonalnymi wyborami. Jednak wiedza nie jest jedynie zbiorem zebranych informacji. W procesie podejmowania decyzji uczestniczą one bowiem w zastanych schematach pojęciowych i układzie poglądów jednostki. Nawet, gdy decyzje podejmowane są kolektywnie, zbierane informacje uczestniczą w szerokim obszarze powiązań i relacji z niewyrażonymi explicite normami, przekonaniami czy uprzedzeniami. Bez względu na rozstrzygnięcia dotyczące problemu wiedzy, którą posiada organizacja lub jednostka istotna z punktu widzenia skuteczności rynkowej jest nie sama wiedza, ale orientacja w jej obszarze, a wraz z nią podejmowanie decyzji. Opisane uprzednio podstawowe typy integracji oprócz pokonywania rozproszenia i heterogeniczności w istotny sposób porządkują zasoby informacyjne. Rozwiązanie problemów decyzyjnych w przedsiębiorstwie umożliwiają nie tylko integracja informacji, ale jej przełożenie i odniesienie do procesów. Jednak sztywne określenie ram takiego przełożenia w zasadniczy sposób ograniczałoby przystosowalność do zmiany. Sytuację tę komplikuje dodatkowo natura problemów słabo ustrukturalizowanych. O ile bowiem 46

47 decyzje finansowe czy dotyczące produkcji mogą ściśle zależeć od kwantyfikowalnych danych, o tyle natura decyzji kadrowych, rozwojowych czy marketingowych uwzględnia dużą liczbę elementów jakościowych. Wśród metod wspomagania decyzji Olszak wymienia trzy następujące: monadyczne, strukturalne i kontekstowe65. Metody monadyczne stosuje się do przedstawiania informacji na temat organizacji oraz jej otoczenia. Wykorzystywane są między innymi do analizy problemów decyzyjnych. Są podstawą do analizy danych i modeli, które realizują metody strukturalne. Stosuje się w nich formalne modele (finansowe, ekonometryczne lub optymalizacyjne). W końcu metody kontekstowe odnoszą się do szerszego kontekstu, aniżeli organizacyjny. Na gruncie systemów informacyjnych metody te mogą być realizowane przez systemy wspomagania decyzji (SWD): SWD łączą intelektualne zasoby pojedynczych jednostek z możliwościami komputerów w celu poprawy jakości decyzji, a ich zadaniem jest integrowanie danych i modeli celem poszukiwania rozwiązania dla częściowo lub niestrukturalizowanych problemów decyzyjnych 66. Definicja ta ukazuje nie tylko aspekt integracji koniecznej dla SWD, ale także jej istotne przeznaczenie, a mianowicie wspieranie problemów częściowo lub niestrukturalizowanych, Problemy o naturze ustrukturalizowanej mogą być rozwiązywane przy pomocy systemów inteligentnych bez ludzkiej ingerencji. Elementy strukturalne problemu nie wymagają bowiem subiektywnej oceny decydenta. Historia systemów wspomagania decyzji sięga lat 60-tych XX w. przebiega od systemów transakcyjnych poprzez systemy informowania kierownictwa, systemy ekspertowe, EIS aż po systemy klasy business intelligence. Ze względu na komponent systemowy SWD dzielimy na zorientowane na: modele, dane, wiedzę, komunikację i dokumentację. Właściwy przedmiot pracy odnosi się do SWD zorientowanych na dane. Systemy te podlegają procesom modelowania i analizowania konkretnych zestawów danych oraz ich integracji. Termin business intelligence upowszechnił Howard Dresner, który odniósł się do systemów analitycznych. Jednak po raz pierwszy pojęcie to zostało użyte w 1958 roku przez H.P Luhna w pracy A Business Intelligence system 67. Olszak zauważa, że systemy 65 Olszak C. (2007), Tworzenie i wykorzystywanie systemów Business Intelligence na potrzeby współczesnej organizacji, Wydawnictwo Akademii Ekonomicznej w Katowicach, Katowice, s Keen P., Scott Morton M. (1989), Decision Support Systems, Addison-Wesley, New York. cyt. za Olszak op.cit. s Por. Luhn H. (1958), A Business Intelligence system, IBM Systems Journal 2(4), s

48 business intelligence pełnią rolę holistycznej infrastruktury wspomagającej podejmowanie decyzji. Posiadają one zatem naturę scalającą informację, nawet jeśli architektura konkretnego rozwiązania nie ma ściśle zintegrowanego charakteru. Oznacza to, że nawet w przypadku zastosowania architektury rozproszonej, systemy klasy business intelligence integrują informację, tak aby ulepszać decyzje biznesowe w oparciu o jak najszerszy zestaw zasobów informacyjnych przedsiębiorstwa. Spróbujmy zestawić ze sobą główne cechy systemów BI. Po pierwsze, rozwiązania te mają wspierać decydentów w zakresie wyboru informacji, kojarzenia faktów i wnioskowania oraz dzielenia się informacją 68. Po drugie, wykorzystują informacje pochodzące z różnych źródeł i zapobiegają utracie wiedzy. Stanowiąc uzupełnienie systemów transakcyjnych, ułatwiają podejmowanie decyzji w oparciu o dane, które nie są w tych systemach dostępne. Innymi słowy, gromadzenie danych z różnych systemów ułatwia zastosowanie szerokiej perspektywy czasowej rejestrowanych zdarzeń. Po trzecie, podjęcie decyzji zawsze wybiega w przyszłość, dlatego historyczna perspektywa informacji rozszerza horyzont możliwych decyzji. (Im szerszy i dłuższy jest horyzont archiwizowanych i zbieranych informacji, tym większe możliwości przewidywania zdarzeń). Po czwarte, holistyczna natura systemów klasy BI umożliwia podejmowanie decyzji przez różnych członków organizacji, począwszy od kadry kierowniczej poprzez analityków aż po pracowników działów operacyjnych. Zatem w największym skrócie można powiedzieć za Olszak, że systemy BI służą przede wszystkim transkrypcji określonych danych w informację i wiedzę oraz tworzeniu środowiska do efektywnego podejmowania decyzji, strategicznego myślenia i działania w organizacji. Definicja ta zatem w sposób bezpośredni odwołuje się do przedstawionej powyżej triady dane-informacja-wiedza oraz potwierdza stwierdzenie, że systemy BI są zorientowane na dane. Założenia przedstawiają perspektywę biznesową, z technicznego zaś punktu widzenia jest to: Rozwiązanie informatyczne w szerokim znaczeniu, obejmujące obok rozwiązań programowych służących raportowaniu, analizie danych i eksploracji danych i tekstu również rozwiązania technologiczno-programowe, obejmujące hurtownie danych i wielowymiarowe serwery OLAP wraz z odpowiednimi narzędziami programowymi 68 Olszak C. (2007), Tworzenie i wykorzystywanie systemów, op. cit., s

49 służącymi do zbierania danych oraz zarządzania i administrowania poszczególnymi elementami systemów BI 69. Definicja ta przedstawia takie elementy architektury systemów BI jak: hurtownię danych, mechanizmy zbierania i integracji danych i narzędzia do ich analizy oraz prezentacji. Architekturę systemów tej klasy przedstawimy w kolejnej części rozdziału. Rozwiązania BI mogą być wykorzystywane na różnych szczeblach zarządzania: od planowania strategicznego, po taktyczne i operacyjne. Na szczeblu strategicznym umożliwiają wyznaczanie celów oraz ocenę ich realizacji. W działaniach taktycznych dostarczają informacji marketingowych, finansowych i kapitałowych. W końcu na poziomie operacyjnym wspierają pracowników w konkretnych działaniach związanych z poszczególnymi procesami biznesowymi np.: sprzedażą, współpracą z dostawcami i klientami lub operacjami finansowymi. Business Intelligence stosowane być może w wielu obszarach, które wymagają dostępności danych historycznych i operacyjnych. Sprawdzają się zwłaszcza w następujących obszarach70: modelowaniu scenariuszy rozwoju firmy, tworzeniu strategii oraz dostarczaniu informacji o otoczeniu organizacji i trendach rynkowych; zarządzaniu i poprawie relacji z klientami, pomiarze ich satysfakcji oraz zachowań; analizowaniu zyskowności i usług oraz ocenie wydajności pracowników; analizie procesów wewnętrznych i sprawności operacyjnej organizacji; kontrolingu i rachunkowości zarządczej. Szerzej o korzyściach płynących z zastosowania systemów tej klasy mówić będziemy w części poświęconej metodom analitycznym, gdzie odniesiemy się do korzyści w poszczególnych metodach. Decydenci IT oraz kadra zarządzająca wybierają rozwiązania BI z różnych powodów. Jedne z najważniejszych motywów wymienia C. Olszak71: zmiana podejścia do podejmowania decyzji: od decyzji instynktownych i intuicyjnych do decyzji popartymi analizami wskaźników i faktów; potrzeba prognozowania wyników finansowych, zachowań klientów lub dostawców; powiązanie działań operacyjnych z założeniami strategicznymi; 69 Januszewski A. (2008), Funkcjonalność informatycznych systemów, op. cit., s Olszak (2007), Tworzenie i wykorzystywanie systemów, op. cit., s Ibid., s

50 wdrażanie standardów ustanawiających powtarzalne i regularne procesy; ujednolicenie przepływu informacji. wykrywanie informacji odbiegającej od założonych norm (wykrywanie oszustw, nieterminowości, odchyleń produkcyjnych); skracanie czasu analiz i zmniejszenie liczby elementów pośrednich wymaganych do podjęcia decyzji; automatyzacja raportów i analiz. Jeśli systemy BI można stosować w wielu obszarach funkcjonowania przedsiębiorstwa, to powstaje pytanie: jak ocenić skuteczność tego typu zastosowań? Po pierwsze, wdrożenie systemu BI należy traktować jako projekt inwestycyjny72. Przestawienie korzyści biznesowych decydentom musi się jednak w ścisły sposób wiązać z realnymi korzyściami finansowymi np.: inwestycja rzędu 2 mln $ we wdrożenie systemu BI musi skutkować odpowiednim wzrostem przepływu gotówki. Oprócz określenia warunków finansowych firma musi określić, czy za pomocą tego rozwiązania usprawni procesy zarządzania takie jak planowanie, kontrola, monitorowanie oraz czy poprawi takie procesy operacyjne jak realizacja kampanii sprzedażowych, wykrywanie oszustw, procesy obsługi zamówień i płatności73. Williamsowie podkreślają, że przy wdrażaniu rozwiązań BI należy wykroczyć poza techniczną implementację środowiska. Według autorów przytoczonej publikacji organizacje pragnące w pełni wykorzystać możliwości systemów tej klasy muszą zaangażować się efektywnie w strategiczne dopasowanie, inżynierię procesową i zarządzanie zmianami. We wdrożeniach business intelligence względnie dobrze rozumiane są zarządzanie projektem wdrożeniowym oraz jego techniczne aspekty. Jednak trzy poniższe działania są z reguły pomijane. Strategiczne dopasowanie polega na zbliżeniu wykorzystania business intelligence ze strategią organizacji. Osiągane być powinno dzięki: 72 Zagadnienie efektywności ekonomicznej przedsięwzięć informatycznych zostało przedstawione między innymi w pracach Dudycz H., Dyczkowski M. (2006), Procedura pomiaru i oceny efektywności przedsięwzięć informatycznych. Podstawowe problemy metodyczne oraz Dudycz H. (2006), Ocena efektywności przedsięwzięć informatycznych. Tradycyjnie czy nowocześnie w Dudycz H., Dyczkowski M., Nowak, red., Informatyka - ocena efektywności, Polskie Towarzystwo Informatyczne - Odział Górnośląski, Katowice, s i s ; Czarnacka-Chrobot B. (2011), Porównanie metod pomiaru i szacowania projektów informatycznych jednostki programowe a jednostki umowne w Grabara J. K., Nowak J. S., red., Efektywność zastosowań systemów informatycznych, Wydawnictwa NaukowoTechniczne, Warszawa, s oraz Czarnacka-Chrobot B. (2011), Narzędzia wspomagające pomiar i szacowanie projektów informatycznych w Grabara J. K., Nowak J. S., red., Efektywność zastosowań systemów informatycznych, Wydawnictwa Naukowo-Techniczne, Warszawa, s Williams S., Williams N. (2003), The Business Value of Business Intelligence, Business Intelligence Journal, Fall 2003, s

51 rozumieniu głównych czynników wpływających na konkurencyjność; określeniu kluczowych problemów i pytań biznesowych wymaganych do planowania, budżetowania, kontroli i monitorowania wydajności przedsiębiorstwa; identyfikacji narzędzi, metod i ram środowisk analitycznych w celu poprawy funkcjonowania procesów i wydajności; podążanie za technicznymi procedurami udostępniania, zarządzania i gromadzenia danych, tak aby spełnić oczekiwania menedżerów co do zasobów informacyjnych. Inżynieria procesowa ma kluczowe znaczenie dla sukcesu funkcjonowania rozwiązania BI. Większość inicjatyw wdrożeń tych systemów ma charakter indywidualny lub ad hoc. Skuteczne wykorzystanie możliwości BI nie może opierać się tylko na zapewnieniach producentów o przystosowaniu rozwiązania do cech branżowych lub typu organizacji. Właśnie dlatego aplikacje BI powinny być ściśle powiązane z konkretnymi procesami, choć niekoniecznie tworzone na potrzeby jednego konkretnego. Załóżmy na przykład, że firma pragnie stworzyć aplikację BI, która mierzyć będzie produktywność. Ponadto stwierdzono, że to właśnie produktywność istotnie wpływa na redukcję kosztów. Można zatem stwierdzić, że podstawowy warunek strategicznego dopasowania został spełniony (redukcja kosztów zależy od poprawy produktywności, stąd potrzeba jej monitorowania i analizowania i stworzenia specjalnej aplikacji). Właściwe podejście do wykorzystania tej aplikacji powinno w dalszym etapie uwzględnić odpowiedzi na takie pytania jak: Kto otrzymuje wyniki analiz? Jakie decyzje powinny zostać podjęte? Co powinno być analizowane, przez kogo i kiedy? Jaki jest horyzont czasowy dla decyzji? Jakie działania zostaną podjęte po podjęciu decyzji? Kto będzie odpowiedzialny za monitorowanie decyzji? Zarządzanie zmianą. O ile inżynieria procesowa określa, jak wykorzystywać systemy BI w celu osiągania żądanych wyników oraz realizowania konkretnych procesów, o tyle zarządzanie zmianą w tym kontekście określa konieczne zmiany organizacyjne i procesowe dla pełnego wykorzystania tych systemów. W raporcie firmy Gartner74 czytamy, że podjęcie decyzji o wdrożeniu systemu motywowane jest ulepszaniem procesu decyzyjnego. Systemy te powinny ewoluować od rozwiązań dostarczających informację w stronę platform decyzyjnych. Platformy te powinno cechować aktywne włącznie systemów analityki biznesowej w procesy. Niestety według autorów raportu większość rozwiązań BI funkcjonuje bez takiej integracji. 74 Feiman J., MacDonald N. (2011), Magic Quadrant for Business Intelligence Platforms, 27 January 2011 / ID Number: G

52 Platformy BI powinny także zapewniać coraz szersze możliwości symulacji oraz analizy predykcyjnej. Dla zapewnienia szerszej perspektywy planistycznej i analitycznej przyszłość rozwiązań business intelligence musi bazować na integracji modeli danych, tworzonych w departamentach z korporacyjnymi modelami danych, co potwierdza zasadę konieczności stosowania podejścia holistycznego. W końcu rozwój systemów analityki biznesowej powinien ułatwiać kolektywne podejmowanie decyzji. Wymaga to między innymi silnej integracji narzędzi analitycznych z aplikacjami wspierającymi pracę zespołową Architektura systemów BI Skuteczna realizacja celów biznesowych stawianych przed systemami klasy business intelligence uzależniona jest od zaplanowania architektury środowiska analitycznego. Najogólniejszy rys architektury systemów omawianej klasy zakłada następujące warstwy: źródeł, integracji, składowania, analityczną, prezentacji oraz administracji. (Rys. 4). Rysunek 4. Architektura systemów BI. Źródło: opracowanie własne na podstawie Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Systemy Business Intelligence, T. 2, PWN, Warszawa, s. 20 (nieznacznie zmodyfikowany). Warstwa transakcyjna. Systemy business intelligence jako rozwiązanie integrujące bazują na szerokim spektrum źródeł informacji. Decyzje podejmowane w oparciu o systemy analityki biznesowej dotyczyć mogą wszelkich aspektów funkcjonowania organizacji. Dane mogą być zatem pobierane z systemów zastanych, ERP/CRM i innych systemów transakcyjnych. Dodatkowo dane mogą być gromadzone z przestrzeni internetu 52

53 i rozwiązań e-biznesu (np. z systemy obsługujących środowiska B2B). Źródłami danych mogą być takie repozytoria danych jak dane branżowe, statystyczne, dane sieci społecznościowych. Do analiz mogą być także wykorzystywane dane zawarte w plikach danych (pliki płaskie, arkusze itp.). Wszelkie te dane są cennym źródłem podejmowanych decyzji, a zdolność do ich integrowania może znacząco przyczynić się do skutecznych działań rynkowych. Warstwa integracji. W chwili gdy repozytoria i źródła danych zostaną zidentyfikowane oraz określone jako istotne dla podejmowanych w organizacji decyzji, zawarte w nich dane muszą podlegać procesom integracji. W poprzednim rozdziale wymieniliśmy trzy rodzaje integracji: zorientowaną na usługi, procesy oraz informacje. Według tej typologii w omawianej warstwie integruje się dane i ma ona charakter integracji informacji. Istnieją trzy techniki integracji danych istotne z punktu widzenia rozwiązań business intelligence: konsolidacja,federacja oraz propagacja. Z czego dwie pierwsze wpływają bezpośrednio na charakter podejmowanych decyzji oraz możliwości (analityczne) wdrażanego rozwiązania. Warstwa składowania. Integrowane dane muszą rezydować w dedykowanym repozytorium (konsolidacja) lub być wirtualizowane (federacja). Zagadnienie składowania danych stanowi centralny punkt rozwiązań analityki biznesowej. Od warstwy tej zależy funkcjonowanie warstwy analitycznej, która jest źródłem podejmowanych decyzji. Warstwa analityczna. Na podstawie zebranych danych stosuje się różne metody analityczne, które przystosowane są do różnych obszarów działalności. Wśród nich wymienić należy standardowe raporty, przetwarzanie analityczne OLAP, techniki drążenia danych, analizy predykcyjne i statystyczne. Warstwa prezentacji. Analizowane dane mogą być dostarczane za pośrednictwem rozwiązań webowych w różnej postaci prezentacyjnej. W warstwie tej stosuje się interaktywne narzędzia do wizualizacji danych, interaktywne raportowanie i kokpity. Rezultaty analiz mogą być automatycznie dostarczane w różnych kanałach i technologiach komunikacyjnych. Spróbujmy przyjrzeć się bliżej poszczególnym warstwom, zaczynając od warstwy integracji. 53

54 3.3. Warstwa integracyjna architektury BI Istnieją dwie najbardziej ogólne metody organizowania zasobów informacyjnych: zastosowanie jednej centralnej bazy danych zawierającej wszelkie dane systemów transakcyjnych lub użycie pewnej formy interfejsu integrującego rozproszone i heterogeniczne zasoby informacyjne75. Pierwsza metoda odzwierciedla praktykę stosowania systemu zintegrowanego (najczęściej klasy ERP) lub systemu dedykowanego o charakterze zintegrowanym. Z reguły architektura ta dostosowywana jest do charakteru konkretnej organizacji. Wdrożenie systemu ERP wiąże się niejednokrotnie z dopasowaniem go do specyfiki i charakteru działań przedsiębiorstwa. W przypadku tworzenia rozwiązania dedykowanego, system może mieć jeszcze bardziej unikalny charakter. W przypadku takich architektur integracja z innymi podmiotami może być utrudniona. Tak funkcjonujące systemy utrudniają także stosowanie analityki, która z reguły jest dostępna specjalistom generującym odwołania do baz danych skojarzonych z systemami ERP lub dedykowanymi. Rozwój środowiska informatycznego przedsiębiorstwa i tworzenie dodatkowych systemów, wykraczających poza funkcjonalność systemów zintegrowanych lub systemów dedykowanych opartych o centralną bazę danych wpływają na rozproszenie zasobów integracyjnych. W takim przypadku systemy istnieją niezależnie i posiadają cechy systemów heterogenicznych względem siebie. Tendencję tę obserwujemy wraz ze wzrostem złożoności systemu organizacji. Systemy niezależne projektowane są i wdrażane dla różnych jednostek organizacyjnych, powielając niejednokrotnie obszary funkcjonalne. Dla integracji rozproszonych repozytoriów Put rezerwuje termin federacja 76. Istotnie, rozwiązania o charakterze federacyjnym łączą i integrują zasoby informacyjne przy pomocy połączeń każdy-z-każdym lub przy użyciu warstwy pośredniej. W integracji heterogenicznych rozproszonych zasobów stosować można schematy współdzielone (ontologie) lub łączyć ze sobą aplikacje lub definiować usługi. Aplikacje i użytkownicy w celu odnalezienia danych i informacji mogą korzystać z takich interfejsów jak katalogi, rejestry, serwisy wyszukujące lub dynamicznie modyfikowane perspektywy. Z punktu widzenia systemów analityki biznesowej Put przedstawia rozwiązanie pośrednie, które bazuje na hurtowni danych. Mówimy w tym wypadku o rozwiązaniu pośrednim, gdyż integrować może ono nie tylko bazę danych systemów zintegrowanych, 75 Put D. (2011), Wieloaspektowość zagadnienia integracji, op. cit., s Ibid., s

55 ale także jednocześnie repozytoria o charakterze rozproszonym. Uznać można zatem hurtownie danych za centralny element integracji danych. Pamiętać jednak należy, że hurtownia danych ma głównie na celu integrację danych transakcyjnych i przeznacza się ją na potrzeby analityczne. Hurtownie danych gromadzą także dane spoza systemów transakcyjnych (np.: dane repozytoriów zewnętrznych lub dane z systemów należących do partnerów organizacji). Zanim jednak dane zostaną zgromadzone w hurtowni danych lub bezpośrednio wykorzystane w warstwie analitycznej muszą przejść przez proces integracji. Z punktu widzenia procesów integracyjnych środowisko IT większości organizacji może być podzielone na trzy zasadnicze elementy: środowisko transakcyjne, środowisko współpracy i środowisko analityczne. W środowisku transakcyjnym dokonuje się rutynowych działań operacyjnych. Zawiera ono szczegółowe dane transakcyjne i obsługiwane jest niejednokrotnie przez wiele różnych repozytoriów danych. Środowisko analityczne służy raportowaniu i analizowaniu danych dotyczących operacji biznesowych. Aplikacje analityczne mogą odwoływać się bezpośrednio do systemów transakcyjnych, jednak dostarczają informacji pochodzących z głównie tematycznych lub centralnych hurtowni danych. Dane zawarte w hurtowniach danych mają charakter zbiorczy. Cechuje je ponadto określony horyzont czasowy. Pomiędzy środowiskami transakcyjnymi, a analitycznymi dane przepływają w dwóch kierunkach. Tradycyjnie systemy analityczne pobierają i gromadzą dane pochodzące z środowiska transakcyjnego, ale coraz częściej spotyka się też rozwiązania, w których dane przesyłane są w kierunku odwrotnym. Wtedy to wyniki analiz, prognoz oraz wskaźników trafiają bezpośrednio do systemów transakcyjnych i wspierają bezpośrednio procesy operacyjne. Obydwa te środowiska zasilają środowisko współpracy, w którym członkowie organizacji przy użyciu różnych kanałów komunikacyjnych interpretują informacje transakcyjne i analityczne. W dalszej części skoncentrujemy się na relacji zachodzącej między dwoma pierwszymi środowiskami. Przy czym relację tę rozpatrywać będziemy z punktu widzenia integracji przepływających danych. Wspomnieliśmy, że dane można podzielić według ich właściwości strukturalnych. Ich struktura ma istotne znaczenie dla procesu integracji. Według raportu TDWI77 w niemalże wszystkich projektach integracji danych stosuje się dane o wyraźnej strukturze. Są nimi dane pochodzące z relacyjnych baz danych oraz pliki płaskie zawierające określoną 77 Russom P. (2011), Next Generation Data Integration, TDWI Research, April 1st

56 strukturę. Jednak w integracji danych stosuje się coraz częściej złożone, hierarchiczne dane oraz pochodzące z systemów zastanych. Ponadto wykorzystuje się dane semistrukturalne i dane zdarzeń systemowych. Większość respondentów raportu pragnie także integrować takie dane jak dane geolokacyjne, języka naturalnego, audio, wideo. Zagadnienie integracji polega zatem na przyjęciu możliwie szerokiej perspektywy, która umożliwi na scalenie tak różnorodnych źródeł informacji. Dzięki integracji danych organizacje zapewniają sobie spójny obraz rozproszonych informacji. Integrację danych realizować można za pomocą trzech podstawowych technik: konsolidacji, federacji oraz propagacji78. Konsolidacja danych scala dane rozproszone w różnych źródłach w jedno repozytorium. Służy ona zasadniczo przeprowadzaniu analiz w oparciu o hurtownie danych lub udostępnianiu danych aplikacjom w oparciu o operacyjne repozytoria danych. Wspominaliśmy o dwóch zasadach wyznaczających realizację biznesu czasu rzeczywistego. Jedna z nich (zasada zerowego opóźnienia w przedsiębiorstwie) pośrednio odnosi się do konsolidacji danych. Otóż w przypadku tej techniki integracji konsolidowane dane dostępne są z pewnym opóźnieniem. Proces ładowania danych do repozytorium może być czasochłonny i dlatego udostępniane mogą być z pewnym opóźnieniem. Zazwyczaj wiąże się to ze złożonością modeli danych oraz wielością źródeł konsolidowanych danych. Częstotliwość procesu konsolidacji zależy od wymagań biznesowych. W tym kontekście należy wyróżnić trzy typy konsolidowanych danych: dane opóźnione, dane bliskie czasu rzeczywistego oraz dane czasu rzeczywistego. Typowo dane opóźnione charakteryzuje opóźnienie rzędu godzin lub dni. Dane bliskie czasu rzeczywistego opóźnione są w docelowych repozytoriach o sekundy, minuty lub godziny. Natomiast dane czasu rzeczywistego dostępne są w repozytoriach docelowych bez opóźnienia. Należy podkreślić, że ostatni typ opóźnienia (zerowego) jest trudny do osiągnięcia w przypadku konsolidacji z uwagi na czas potrzebny na ładowanie danych. Dane o dużym opóźnieniu ładowane są okresowo przy użyciu techniki wsadowej. W takim przypadku docelowe repozytorium danych może nie odzwierciedlać stanu faktycznego. W czasie między dwoma ładowaniami dane mogły zostać zmienione. W przypadku danych o niskim opóźnieniu dane ładowane są ciągle, w chwili ich zmiany (np.: przy użyciu techniki CDC, ang. changed data capture). 78 White C. (2005), Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, TDWI Research, November 2005, s

57 Po załadowaniu danych docelowe repozytoria nie zmieniają ich postaci. Miałoby to wpływ na integralność zawartych danych. Zdarza się jednak, że w przypadku konfliktu danych mogą być one modyfikowane w docelowym repozytorium79. Dane podlegające analizom i raportowaniu docierają do aplikacji analitycznych. Jednak coraz częściej zmiany w repozytoriach docelowych mogą przyczyniać się do zmiany w systemach źródłowych. Integrowane dane mogą być wykorzystywane do zmian w zintegrowanym planowaniu, budżetowaniu. Przykładem może być zmiana modelu cenowego na podstawie danych skonsolidowanych w poprzednim okresie lub zmiana harmonogramu produkcji na podstawie analiz zachowań nabywców. Główna korzyść konsolidacji danych płynie z możliwości gromadzenia dużych wolumenów danych po ich uprzedniej restrukturyzacji, uzgodnieniu, oczyszczeniu i agregowaniu. Jednak wielkość repozytoriów danych wpływa na możliwości ich tworzenia i przetwarzania. Federacja danych. O ile konsolidacja prowadzi do fizycznego składowania danych w docelowych repozytoriach, o tyle federacja ustanawia wirtualny obraz jednego lub więcej źródeł. Ściślej, w chwili gdy aplikacja wymaga pobrania danych, wysyła zapytanie do serwera przetwarzającego, który pobiera dane z potrzebnych źródeł i po ich przetworzeniu przesyła rezultat zapytania do aplikacji. Technika ta opiera się na akcydentalnym przetwarzaniu. Dane są zatem pobierane i przetwarzane na żądanie. Federacja danych opiera się między innymi na metadanych, które wykorzystuje system przetwarzający. Główną zaletą tej techniki jest dostęp do aktualnych danych bez konieczności ich uprzedniej konsolidacji. Ma ona jednak swoje ograniczenia, głównie związane z wielkością wolumenu danych oraz ich jakością. Wiąże się to choćby z wydajnością samego procesu pobierania i ujednolicania oraz przetwarzania samych zapytań. Propagacja danych. Propagacja danych polega na przenoszeniu danych z jednego systemu do drugiego. W zależności od zdarzenia dane mogą być propagowane synchronicznie lub asynchronicznie. Pierwsza metoda aktualizuje dane w dwóch systemach przetwarzających np.: w przypadku jednej transakcji dane są uaktualniane w obydwu systemach mogą przepływać w dwóch kierunkach. Technika ta zapewnia gwarancję dostarczenia danych. Przykładowymi technologiami są tu integracja aplikacji korporacyjnych (EAI, ang. enterprise application integration) oraz replikacja danych korporacyjnych (EDR, ang. enterprise data replication). Ten typ integracji odpowiada 79 Por. także - charakterystyka hurtowni danych. 57

58 zasadzie zerowego opóźnienia. W odróżnieniu od konsolidacji, propagacja jest zorientowana na transakcje i wiadomości. Spróbujmy prześledzić technologie, dzięki którym realizować może powyższe metody integracji danych. W warstwie integracji najistotniejszą rolę odgrywają proces ETL (ang. extract, transform, load) i EII (ang. enterprise information integration). Jednak do środowiska analitycznego odnoszą się także takie rozwiązania jak zarządzanie danymi referencyjnymi (ang. master data management) oraz zarządzanie treścią w przedsiębiorstwie (ang. enterprise content management). W warstwie integracji dochodzi do działań mających na celu przygotowanie i pobieranie danych w celu ich dostarczenia do repozytoriów danych przypisanych do warstwy składowania. Ładowanie danych do hurtowni danych lub operacyjnych składnic danych (ang. ODS operational data store) odbywa się w trzech fazach: ekstrakcja czyli określenie i pozyskiwanie danych; transformacja czyli przekształcanie danych tak, aby przystosować je do struktur hurtowni danych; ładowanie czyli fizyczne załadowanie danych do hurtowni. Ten trójstopniowy proces nosi miano ETL. Zaprojektowanie i przygotowanie tego procesu w projektach realizujących platformę business intelligence pochłania znaczną część czasu poświęconego na wdrożenie. Po pierwsze, faza ekstrakcji polega na określeniu i identyfikacji źródeł danych, ich wyborze oraz odniesieniu tych informacji do poziomu biznesowego. Faza ekstrakcji może być problematyczna w takich przypadkach jak brak koniecznych danych (w tym przypadku należy przygotować potrzebne źródło) lub zmiana wymiaru dowolnego obiektu. Po drugie, po określeniu źródeł i identyfikacji danych, dane powinny zostać przekształcone do postaci, która umożliwi ich zapis w hurtowni danych. W fazie transformacji dane są często kierowane do platformy pośredniej (ang. staging area). Zanim bowiem trafią do hurtowni danych są w tym obszarze składowane i podlegają czyszczeniu oraz przetwarzaniu. Zatem w tym miejscu zachodzi właściwy proces transformacji, do której można zaliczyć dwa rodzaje integracji: formatów i semantyczną. Pierwszy rodzaj integracji ujednolica formaty danych reprezentowanych w systemach źródłowych. Drugi typ integracji polega na uzgadnianiu definicji danych. W fazie transformacji dokonuje się także czyszczenia danych oraz wstępnego agregowania. Czyszczenie danych jest procesem weryfikacji jakości danych. Określa, czy 58

59 dany rekord jest poprawny. Natomiast agregacja danych grupuje dane według zadanych kryteriów. Np.: ładowanie do hurtowni sumy transakcji z danego dnia z danej kasy, zamiast ładowania wszystkich pojedynczo. W końcu trzeci etap prowadzi do fizycznego zapisu danych do hurtowni. Proces ten ma charakter powtarzalny i jak wspomnieliśmy powyżej, częstotliwość zależy od wymagań biznesowych. W rozwiązaniach ETL coraz częściej stosuje się także przetwarzanie równoległe, równoważenie obciążenia oraz buforowanie. Ponadto w materiałach firmy Oracle 80 znajdujemy informacje o istotnych przemianach w technologii ETL. Otóż obecne rozwiązania ETL ewoluują w stronę rozwiązań ELT. Drugi typ eliminuje obszar pośredni, w którym uruchamia się procesy transformacji. Zamiast niego procesy te realizowane są najczęściej bezpośrednio w docelowych repozytoriach. Wpływa to na redukcję infrastruktury oraz kosztów administracji, ponieważ architekci ELT sami mogą wybrać, gdzie transformacje będą dokonane (druga możliwość to dokonanie transformacji w samych systemach źródłowych). Poza ETL drugą technologią wykorzystywaną w warstwie integracji jest integracja informacji korporacyjnej (EII). EII wspiera rozwiązania federacyjne. Scenariusz tej metody integracji polega na stworzeniu wirtualnego schematu (schematu mediującego), do którego odwołują się użytkownicy i aplikacje. Aplikacje i użytkownicy postrzegają zatem dane, tak jakby rezydowały w jednym repozytorium. Z technicznego punktu widzenia: W najprostszej formie, dostęp EII do rozproszonych danych zakłada rozłożenie zapytania kierowanego do wirtualnego obrazu danych na komponenty w celu przetwarzania ich w miejscu, gdzie rezydują żądane dane. Następnie produkt EII scala pobrane dane i wysyła końcowy rezultat do aplikacji, która zainicjowała zapytanie 81. O ile zatem w przypadku ETL dane ładowane są do scalającego repozytorium danych, o tyle w technologiach EII dane udostępniane są bezpośrednio z pominięciem warstwy składowania. W przedstawionym schemacie architektury środowiska analitycznego warstwa ta powinna być pominięta, gdyż aplikacje analityczne odwołują się bezpośrednio do wirtualnego obrazu danych. Kluczowymi dla funkcjonowania rozwiązań tego typu są optymalizacja i wydajność. W rozwiązaniach EII dochodzi bowiem do przetwarzania rozproszonych relacyjnych baz 80 Baum D. et al. (2011), Sate of Data Integration Market, Oracle Corporation, 81 White C. (2005), Data Integration..., op. cit., s

60 danych (DDBMS). Optymalizacja dotyczy zatem przetwarzania rozproszonych i heterogenicznych źródeł. Większość systemów oferuje jedynie dostęp tylko do odczytu, gdyż funkcje zapisu w źródłowych danych stwarzają dodatkowe problemy. Haas wymienia następujące dezyderaty zadania procesu integracji informacji82: zrozumienie danych informacje o danych, właściwości i statystyczne (dystrybucja danych, częste wartości, niespójności), określenie metadanych; standaryzacja sposób reprezentacji danych; specyfikacja i wybór narzędzi; realizacja materializacja, federacja, wyszukiwanie. Rozwiązania federacyjne należą zatem do całościowego procesu integracji i mogą funkcjonować równolegle z innymi formami integracji. Powstaje pytanie, w jakich przypadkach stosować można technologię EII? EII może służyć za tymczasowe rozwiązanie integracyjne, zanim zrealizowany zostanie proces materializacji. W szczególności dotyczy to przejęć i fuzji z innymi organizacjami. Inna możliwość to wykorzystanie EII w aplikacjach, które wymagają częstego dostępu do aktualnych danych. Stosuje się je także do realizacji kokpitów, które pobierają dane z wielu źródeł. Wspomnieliśmy, że rozwiązania federacyjne cechują istotne ograniczenia. Spróbujmy opisać te ograniczenia, porównując ze sobą procesy ETL i EII. Według White'a83 EII nie może zastąpić tradycyjnych rozwiązań ETL. Główną przyczyną jest wpływ złożonych zapytań na wydajność systemów, zwłaszcza, że zapytania w środowisku EII kierowane są w stronę systemów transakcyjnych i operacyjnych. Inny problem dotyczy metod transformacji danych z wielu źródeł. Wpływa na to między innymi złożoność związków między danymi pochodzącymi z różnych systemów, a także jakość samych danych. White wymienia następujące korzyści i scenariusze, w których EII może być alternatywą dla ETL: dostęp na żądanie do szybko zmieniających się danych konsolidacja nie jest w stanie zapewnić krótkich interwałów odświeżania danych. Jednak bezpośredni dostęp do systemów transakcyjnych wiąże się z problemami wydajności i możliwości przetwarzania zapytań w ich obrębie; 82 Haas L. (2007), Beauty and the Beast: The Theory and Practice of Information Integration w Suciu D. Schentick T., red., w ICDT 2007, Springer-Verlag, Berlin Heidelberg, s White C. (2005), Data Integration..., op. cit., s

61 bezpośredni zapis w repozytoriach źródłowych konsolidacja nie spełnia swego zadania w przypadku aktualizacji danych w systemach źródłowych, a niektóre produkty EII to umożliwiają; trudności z konsolidacją źródłowych repozytoriów w niektórych przypadkach utworzenie jednego repozytorium jest trudne do realizacji; koszty funkcjonowania rozwiązań EII są niższe niż rozwiązań konsolidacyjnych okazuje się, że zachodzi związek między ilością konsolidowanych danych, a stopniem ich wykorzystania; rozwiązania federacyjne mogą znacząco poprawić tę zależność; kwestie dotyczące kopiowania danych federacja danych może być skutecznym rozwiązaniem w przypadku ograniczeń związanych z kopiowaniem danych źródłowych (np.: bezpieczeństwo, prywatność lub licencje); potrzeby użytkowników mogą być nierozpoznane dzięki rozwiązaniom EII użytkownicy mogą projektować dostęp do źródeł we własnym zakresie. Integracja danych powinna zakładać architekturę. Jej realizacja może być odpowiedzią na takie problemy jak brak zwięzłości oraz możliwości wykorzystania efektów poprzednich projektów integracyjnych. Rysunek 5. podsumowuje opisane powyżej techniki i technologie korporacyjnej architektury integracji danych. 61

62 Rysunek 5. Techniki i technologie integracji danych. Źródło: White C. (2005), Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, TDWI Research, November 2005, s. 8-11, s. 34 (zmodyfikowany). Z punktu widzenia połączeń systemów architekturę integracji danych można także podzielić na dwa typy: architektura o strukturze gwiaździstej i architektura punkt-dopunktu. Pierwszy typ architektury jest najczęściej stosowany w rozwiązaniach integracji danych. Dotyczy nie tylko takich technologii jak ETL, ale także EII oraz EAI (z udziałem serwera integracyjnego). Jej topologa ogranicza ilość połączeń i interfejsów. Te ostatnie w tej architekturze mogą być wykorzystywane wielokrotnie bez konieczności ich redefiniowania. Drugi typ architektury z reguły uzupełnia pierwszy. Okazuje się, że pewne powiązania punkt-do-punktu w środowiskach informatycznych są niezbędne. Dzieje się tak choćby w przypadku propagacji danych. Ponadto zdarza się, że wydajność serwera integracyjnego może być wąskim gardłem. Pominięcie centralnego serwera integrującego możliwe jest także w zastosowaniach ELT, a obszary przejściowe wykorzystywane w integracji danych ustanawiają warstwę pośrednią w architekturze o strukturze gwiaździstej. 62

63 3.4. Warstwa składowania architektury BI W warstwie składowania przechowuje się zbierane i integrowane dane. Najczęściej stosowanym elementem tej warstwy architektury BI jest hurtownia danych. W najbardziej ogólnym ujęciu system hurtowni danych składuje informacje ładowane z różnych systemów w celu wspierania podejmowania decyzji biznesowych. Oznacza to, że funkcjonowanie hurtowni danych jest ściśle powiązane z systemami analitycznymi. Najpowszechniejsza definicja hurtowni danych obejmuje następującą charakterystykę: hurtownia danych powinna być uporządkowana tematycznie, zintegrowana, uwarunkowana historycznie, nieulotna oraz powinna wspomagać decyzje: tematyczne uporządkowanie ogranicza dane do określonych obszarów biznesowych, a nie procesów czy działań; charakter zintegrowany wymaga, aby zgromadzone dane powinny być dostępne w całej firmie oraz aby dane zostały sprowadzone do ujednoliconego formatu; uwarunkowanie historyczne podlega procesowi nadawania znaczników czasowych gromadzonym danym, co umożliwia analizę danych w żądanych horyzontach czasowych; nieulotność dane zostają zapisane w repozytorium i nie podlegają zmianie oraz usunięciu. Typowo hurtownia danych zawiera informacje faktyczne, referencyjne, zbiorcze oraz metadane. Głównym celem funkcjonowania hurtowni danych jest gromadzenie zapisów zdarzeń przebiegających w działalności firmy lub jej otoczeniu. Zapisywane fakty opisywane są za pomocą miar, będącymi wartościami liczbowymi np.: wielkość sprzedaży, liczba aktywacji, zgłoszeń itp. Informacje referencyjne określają wymiary, według których fakty będą analizowane. np. wielkość sprzedaży (fakt) można analizować z punktu widzenia sprzedawców, klienta, czasu (wymiary). Oprócz faktów i wymiarów hurtownia może także zawierać dane agregowane. Są to dane zbiorcze grupujące fakty według żądanych wymiarów. W końcu metadane opisują znaczenie danych gromadzonych w hurtowni, ich lokalizację, przeznaczenie oraz sposoby pozyskania. Januszewski wskazuje na istotne różnice między hurtowniami danych, a bazami operacyjnymi. Natura działań wykonywanych w systemach transakcyjnych wymaga, aby 63

64 dane aktualizowane były w czasie rzeczywistym. W bazach operacyjnych ewidencjonuje się zdarzenia i dokonuje jedynie nieskomplikowanych operacji arytmetycznych. Z drugiej strony dane gromadzone w hurtowniach danych mają charakter statyczny, z uwagi na charakter działań analitycznych odwołania do systemu zarządzającego hurtownią danych cechuje dużo większa złożoność, ale i mniejsza częstotliwość. Ogólne założenia funkcjonowania hurtowni danych mogą być realizowane w różnych wariantach. Z punktu widzenia architektury hurtowni danych można wyróżnić84: wiele tematycznych hurtowni danych projektowanych na potrzeby konkretnej dziedziny lub jednostki biznesowej; architekturę opartą o magistralę integrującą niezależne hurtownie tematyczne; centralną hurtownię danych mającą na celu między innymi zasilanie hurtowni tematycznych; pojedynczą hurtownię danych projektowaną pod kątem całej organizacji oraz osób podejmujących decyzje w oparciu o dane niej gromadzone; architekturę federacyjną. Badania Ariyachandry i Watsona dowiodły, że żadna z tych architektur nie ma kluczowego udziału w wynikach ankiety przeprowadzonej wśród architektów systemów oraz decydentów, jednak rozwiązanie oparte o centralną hurtownię danych jest najczęściej stosowane (39%) Warstwa analityczna i prezentacji architektury BI Właściwym źródłem podejmowania decyzji są interpretowane dane. Warstwa składowania danych pozostawia je, można by rzec, w postaci surowej. Platforma business intelligence spełnia zasadę nadawania znaczenia danym. Powróćmy na chwilę do formalnego opisu informacji przedstawionego przez Stefanowicza. Za informację możemy uznać zinterpretowany komunikat, który przedstawiamy jako następującą relację: 84 Ariyachandra T., Watson H. J. (2008), Which Data Warehouse Architecture is Best?, Communications of the ACM 51(10), s

65 Komunikat K = <O, X, x, t>, gdzie O opisywany obiekt X cecha (atrybut) obiektu x wartość cechy X t czas, w którym cecha X obiekty ma wartość x Warstwa składowania odnosi się na poziomie technicznym do danych, ale to właśnie w warstwie analitycznej dochodzi do tworzenia informacji, np.: użytkownik korzystający z narzędzi OLAP może analizować dane sprzedaży książek. Na podstawie analizy może uzyskać informację o wielkości sprzedaży konkretnego produktu w żądanym okresie. Wtedy to informacja według powyższego wzoru może być zapisana jako następująca relacja: <O Książka Business Intelligence, X wielkość sprzedaży, x 3651, t 2012 i 2013), co jest równoznaczne z otrzymaniem informacji o sprzedaży 3651-ciu książek pod tytułem Business intelligence w latach Warstwa analityczna spełnia zatem zasadniczą rolę w procesie podejmowania decyzji. W trakcie długiej, bo już ponad 20-letniej historii business intelligence, wypracowano wiele narzędzi wspomagających analizę danych. Najbardziej rudymentarny podział uwzględnia dwie grupy narzędzi analiz dostarczanych przez rozwiązania business intelligence. Do pierwszej zaliczyć należy standardowe raportowanie, raporty i zapytania ad-hoc oraz interaktywne przetwarzanie analityczne (OLAP). Do drugiej przynależą zaawansowane takie narzędzia analityczne jak narzędzia do eksploracji danych, analityki statystycznej i predyktywnej. Większość systemów transakcyjnych umożliwia tworzenie predefiniowanych raportów, które definiowane są według potrzeb użytkowników. Raporty tego typu dostarczają także platformy BI. Z reguły ich możliwości nie wykraczają poza metody filtrowania danych przy zachowaniu struktury raportu. Wiele platform analitycznych zapewnia różne style raportowania, począwszy od finansowych po operacyjne i monitorujące wydajność. Ich przygotowanie wiąże się przede wszystkim z uzależnieniem formatu raportu, jego struktury i dziedziny od działania projektanta. Zapytania ad-hoc dostarczają danych na żądanie użytkownika. Wiąże się to każdorazowo z wykorzystaniem języka zapytań lub aplikacją, która udostępnia funkcje kreatora. Metoda ta wymaga jednak znajomości struktury repozytoriów danych lub 85 Nieznacznie zmieniony przykład i opis formalny informacji zaczerpnięty z Surma J. Business Intelligence, op. cit., s

66 warstwy semantycznej ułatwiającej orientację w zasobach repozytoriów. Mimo wszystko ten rodzaj kreacji informacji ograniczony jest do użytkowników posiadających dostateczną wiedzę techniczną oraz biznesową. Kolejną metodą dostarczającą informacje dla decydentów jest przetwarzanie analityczne online (OLAP). Do powstania systemów OLAP przyczyniła się w głównej mierze technika modelowania wielowymiarowego. Przetwarzanie tego typu umożliwia przekrojowe analizy, trudne do uzyskania w modelach relacyjnych baz danych, a główną przesłanką stosowania tego typu przetwarzania jest dostęp do analiz danych prowadzonych dla wielu wymiarów86. Eckerson za głównych beneficjentów tej metody analizowania danych uważa analityków biznesowych, zainteresowanych także narzędziami do odkrywania danych przy użyciu wizualizacji87. Warto w tym miejscu zauważyć, że część użytkowników o mniej zaawansowanej wiedzy wciąż pragnie korzystać z raportowania ad-hoc i OLAP. W celu pokonania bariery braku dostatecznego rozeznania w stosowaniu i użytkowaniu tego typu narzędzi producenci stosują wyszukiwalne rozwiązania business intelligence (ang. search-based BI), dzięki którym użytkownicy mogą przeszukiwać strukturę wymiarów i tworzyć raporty na podstawie wpisywanego tekstu, bez konieczności znajomości struktury i modeli danych. Serwery przetwarzające indeksują warstwę semantyczną i generują raporty na podstawie wyszukiwań użytkowników. O ile w przypadku standardowych metod analitycznych analizy podlegają zdefiniowanym wskaźnikom i kryteriom, o tyle zaawansowana technika analityczna jaką jest eksploracja danych ma na celu odnalezienie wykrycie nieznanych związków zachodzących w zbiorach danych. Eksploracja danych prowadzi do uzyskania wiedzy, która nie była wcześniej uświadomiona, tj. odnalezienie nowych zależności, nie wynikających z informacji wcześniej ugruntowanych. Januszewski przywołuje pięć typów zadań, które obejmuje eksploracja danych88: modelowanie opisowe do metod tych należą takie metody statystyczne jak analiza skupień i segmentacja, które prowadzą do określenia grup obiektów o podobnych właściwościach; 86 Techniczne aspekty stosowania projektowania i użytkowania narzędzi OLAP opisane są między innymi w: Surma J. Business Intelligence, op. cit., s i Januszewski A. (2008), Funkcjonalność informatycznych systemów, op. cit., s Eckerson W. (2009), Delivering Insights with Next-Generation Analytics, TDWI Research, s Januszewski A. (2008), Funkcjonalność informatycznych, op. cit., s

67 modelowanie predykcyjne wykorzystuje się w nich takie techniki i algorytmy jak drzewa decyzyjne, sieci neuronowe i algorytmy genetyczne; okrywanie wzorców i reguł dostarcza zbiory obiektów, występujących w określonym kontekście; eksploracyjna analiza danych stosuje się tu metody wizualne w celu znalezienia struktur w danych. Warstwa analityczna jest ściśle powiązana z warstwą prezentacyjną. Informacje dostarczane przez narzędzia warstwy analitycznej dostarczane są najczęściej w postaci portali BI. Zawierają one zestawy raportów, wskaźników oraz aplikacje analityczne. Powszechnie stosowaną metodą dostarczania informacji są kokpity. Kokpity mogą dostarczać informację o kluczowych wskaźnikach efektywności (KPI) w ramach kart wyników, które z reguły zakładają stosowanie takich metodologii monitorowania wydajności jak Six Sigma czy zrównoważona karta wyników. Powiązane mogą być z monitorowaniem aktywności biznesowej (BAM) oraz rozwiązaniami business intelligence czasu rzeczywistego. Jednak najpowszechniej stosowane są w szerokim przekroju, zawierając interaktywne raporty lub elementy narzędzi OLAP. Portale implementują zatem część funkcji narzędzi analitycznych realizowanych przez niezależne aplikacje. Oprócz portali warstwa prezentacyjna dostarcza także wyniki analiz dla innych kanałów: i, środowisk mobilnych czy mediów społecznościowych Dziedziny zastosowań Business Intelligence Systemy Business Intelligence wspierają podejmowanie decyzji na wszelkich poziomach zarządzania wiedzą, począwszy od zarządzania strategicznego po taktyczne i operacyjne. Rozwój systemów BI doprowadził do sytuacji, w której uzyskiwana informacja jest wykorzystywana nie tylko przez kierownictwo wysokiego i średniego szczebla lub analityków biznesowych przeprowadzających analizy typu ad-hoc, OLAP oraz analizy zaawansowane, ale także przez pracowników najniższego szczebla. Oznacza to, że ewolucja tych systemów zapewnia możliwość kontrolowania i przewidywania procesów w obrębie całej organizacji, a odpowiednia ilość i zakres informacji dostępne są dla zainteresowanych decydentów. Przy czym za decydentów nie uznaje się już tylko kadry kierowniczej, ale każdego członka organizacji. Ułatwia to zadanie zarządzającym, którzy nie są zobligowani do znajdowania bezpośrednich przyczyn konkretnego zdarzenia, gdyż 67

68 analiza może być przeprowadzana na dowolnym szczeblu. Co więcej, uwzględnienie wszelkich szczebli w systemach wspomagających zarządzanie usprawnia procesy decyzyjne, gdyż zdecydowaną większość decyzji podejmuje się horyzontalnie. Horyzontalność podejmowania decyzji wymaga dostępu do spójnych informacji na danym szczeblu i odzwierciedla naturę stosunków w strukturze organizacyjnej. Oprócz całościowego wsparcia na płaszczyźnie organizacyjnej systemy BI wspierają różne obszary działalności organizacji. Systemy te wykorzystywane są w następujących obszarach89: finanse stosuje się tu analizy sprawozdań finansowych, majątku obrotowego i struktury kapitałowej, analizy kosztów, przychodów i rentowności w różnych przekrojach, płynności finansowej, analizy rynków finansowych, wykrywanie nadużyć i modelowanie ryzyka; sprzedaż analizy dynamiki i struktury przychodów z punktu widzenia sprzedaży widzianej z różnych perspektyw (klienta, produktu, kanału sprzedaży itp.), analizy wykonania planów sprzedaży oraz skuteczności sprzedawców, analizy sprzedaży krzyżowej (ang. cross-selling) i uzupełniającej (ang. up-selling); marketing i zarządzanie relacjami z klientami segmentacja klientów, wartość klienta w czasie, rentowność klienta, analizy lojalności i satysfakcji oraz odejść klientów, modelowanie przyszłych zachowań klientów, projektowanie kampanii marketingowych; zarządzanie produkcją analizy jakości i efektywności produkcji, badanie jej dynamiki, monitorowanie procesów produkcyjnych oraz ich wydajności; logistyka analiza stanów magazynowych, analizy dostaw do klientów, analizy wykorzystania środków transportu, optymalizacja dostaw i zamówień (np.: optymalizacji tras przewozowych); zarządzanie personelem planowanie szkoleń, analizy fluktuacji zatrudnienia, badania wpływu wynagrodzeń na wyniki pracy, analizy wskaźników wydajności pracy. Wyżej wymienione obszary są już silnie zakorzenione w praktykach stosowania systemów analityki biznesowej. Nakierowane są głównie na wnętrze organizacji. Jednak zasoby informacyjne wykraczają poza jej ramy. Zadanie analizy danych i dostarczania 89 Szerzej por. Januszewski A. (2008), Funkcjonalność informatycznych systemów, op. cit., s , Olszak C. (2007), Tworzenie i wykorzystywanie systemów, op. cit., s , Surma J. (2009) Business Intelligence, op. cit., s i

69 właściwych informacji nie może się już opierać wyłącznie na zasobach informacyjnych samej organizacji. Przykładem może być choćby stosowanie rozszerzonej analityki klienta, gdzie źródłami analiz mogą być przetworzenia rozmów klientów z reprezentantami, śledzenie ścieżek kliknięć w serwisach internetowych organizacji, profile w sieciach społecznościowych będące choćby podstawą segmentacji, zewnętrzne wyniki badań rynku i satysfakcji. Wszystkie te źródła mogą uzupełniać klasyczny obszar analitycznego CRM, wspierając na przykład takie działania jak marketing bezpośredni lub prognozowanie sprzedaży. 69

70 4. Charakterystyka systemów rozproszonych W poprzednim rozdziale zarysowaliśmy charakterystykę rozwiązań klasy business intelligence. Próba ta miała na celu ukazanie środowiska analityki biznesowej jako środowiska integrującego. Implementacja środowiska business intelligence jest procesem wskazującym na jego zintegrowany charakter. O charakterze tym świadczy choćby centralny punkt architektury BI - hurtownia danych. Przeważająca ilość propozycji systemów BI opiera się właśnie na tym elemencie architektury. Okazuje się jednak, że istnieje wiele możliwości faktycznej realizacji tej warstwy architektury, która funkcjonować może w różnych środowiskach: od środowisk ściśle powiązanych z wewnętrzną infrastrukturą IT organizacji do środowisk o charakterze rozproszonym i wykraczającym poza jej ramy. Prowadzi to do istotnych konsekwencji ekonomicznych, technicznych i organizacyjnych. Ponadto stosownie do ustaleń z poprzedniego rozdziału warstwa składowania opiera się na warstwie integracji. Integracja danych w swych trzech odmianach (konsolidacja, federacja, propagacja) określa dynamikę struktury systemu BI. O ile bowiem można przyjąć, że w przypadku konsolidacji struktura ma charakter względnie stabilny, o tyle w przypadku federacji struktura ta ma charakter dużo bardziej elastyczny. Zagadnienie integracji ogniskuje się tu wokół warstwy składowania. Jest to niewątpliwie przykład najbardziej instruktywny, ale należy podkreślić, że inne warstwy sytuować będziemy także w perspektywie systemów rozproszonych. Powstają pytania: czy realizacja systemów analityki w systemach rozproszonych może przynieść korzyści w jednym z trzech wymienionych obszarów (ekonomicznym, technicznym, organizacyjnym) i kto może być ich beneficjentem? Zanim jednak podejmiemy próbę rozpatrzenia tych kwestii przyjrzyjmy się charakterystyce systemów rozproszonych oraz ich typów. W klasycznej pracy dotyczącej systemów rozproszonych czytamy: 70

71 System rozproszony (ang. distributed system) jest zbiorem samodzielnych komputerów połączonych za pomocą sieci i wyposażonych w rozproszone oprogramowanie systemowe. Oprogramowanie systemu rozproszonego umożliwia komputerom koordynowanie ich działań oraz dzielenie zasobów systemu: sprzętu, oprogramowania i danych (podkreślenie TK). Użytkownicy dobrze zaprojektowanego systemu rozproszonego powinni go odbierać jako jedno, zintegrowane środowisko obliczeniowe, pomimo że może ono być realizowane za pomocą wielu komputerów znajdujących się w różnych miejscach 90. Mamy tu zatem wielość zasobów, które podlegają integracji z punktu widzenia odbiorców systemu. Mówimy tu o odbiorcach systemu, gdyż mogą nimi być nie tylko użytkownicy, ale i aplikacje. Definicja wskazuje także na inny aspekt integracji, a mianowicie jednolitość i spójność działań odbiorców w środowisku rozproszonym. Klasyczne ujęcie systemu rozproszonego zakłada następujące cele: dzielnie zasobów każdy funkcjonalny element systemów powinien być z łatwością dzielony przez odbiorców;elementy są dzielone z punktu widzenia sprzętu (komputery, drukarki i inne urządzenia) oraz oprogramowania (dane, pliki, aplikacje lub ich elementy); ta cecha systemu rozproszonego umożliwia pracę zespołową, ograniczanie kosztów użytkowania zasobów; otwartość systemy powinny umożliwiać rozszerzanie oprogramowania poprzez dodawanie nowych funkcji do systemów operacyjnych, protokołów oraz usług dzielenia zasobów; ogólnie można przyjąć, że jest to podatność na rozszerzenia, zarówno sprzętowe, jak i programistyczne; współbieżność systemy powinny przetwarzać wiele zadań równocześnie; skalowalność zapewnia możliwość rozszerzania systemu bez strat jego wydajności, zwiększanie skali systemu nie powinno pociągać za sobą dokonania zmian; tolerowanie uszkodzeń dzięki tej cesze system może zachować ciągłość działania przy pojawiających się błędach oprogramowania lub awariach sprzętowych; przezroczystość system składający się z wielu integrowanych elementów postrzegany jest jako całość; do odmian przezroczystości należy zaliczyć przezroczystość: dostępu (identyczne działania umożliwiają dostęp do systemów lokalnych i odległych), położenia (dostęp do obiektów bez znajomości położenia), 90 Coulouris G., Dollimore J., Kindberg T. (1998), Systemy rozproszone. Podstawy i projektowanie, WNT, Warszawa, s

72 współbieżności (użycie wspólnych obiektów nie zakłóca współbieżności), zwielokrotniania (ukrycie faktu, że istnieje wiele kopii zasobu), awarii (system ukrywa zaistnienie awarii), wędrówki (obiekty systemu mogą się przemieszczać bez wpływu na funkcjonowanie programów lub działania użytkowników). W rozproszonych środowiskach informatycznych wyróżnić możemy dwa następujące sposoby przetwarzania komputerowego: wysokowydajne przetwarzanie komputerowe (ang. high-performance computing - HPC) i przetwarzanie o wysokiej przepustowości (ang. high-troughput computing). Celem pierwszego sposobu jest prędkość przetwarzania wraz ze zdolnością przetwarzania zmiennoprzecinkowego. Stosowany jest głównie na potrzeby nauki, inżynierii lub produkcji. Jednak potrzeby systemów zorientowanych rynkowo doprowadziły do istotnej zmiany paradygmatu. Zastosowanie drugiego sposobu wiąże się z rozwojem Internetu, a w szczególności z wyszukiwaniem informacji oraz realizacją usług internetowych dostępnych dla milionów użytkowników. Wydajność w systemach przetwarzania o wysokiej wydajności wiąże się z ilością zadań wykonywanych w danym czasie. Powyższe metody realizowane są przez systemy masowe. Hwang, Dongara i Fox dzielą powyższe klasy systemów na cztery grupy: klastry, sieci P2P, gridy oraz chmury obliczeniowe91: klastry tworzone są jako zbiór połączonych ze sobą niezależnych komputerów, które współpracując ze sobą, tworzą zintegrowany zasób przetwarzający; sieci P2P to grupa luźno powiązanych komputerów, które w odróżnieniu od modelu klient-serwer funkcjonują równocześnie jako klient lub serwer udostępniając lub pobierając zasoby; mogą one także w dowolnym momencie łączyć się z innymi komputerami w tej sieci bez naruszenia jej funkcjonowania; gridy w odróżnieniu od klastrów tworzone są z elementów heterogenicznych, którymi mogą być powiązane komputery, oprogramowanie, specjalne urządzenia lub sensory; konstruowane są przy użyciu sieci lokalnych rozległych lub przy użyciu Internetu; chmury obliczeniowe dostarczają pulę dynamicznie alokowanych, skalowalnych i wirtualizowanych zasobów dla zarejestrowanych użytkowników. 91 Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing. From Parallel Processing to the Internet of Things, Morgan Kaufmann, rozdz

73 Funkcjonalność, aplikacje Klastry Sieci P2P Platformy chmur obliczeniowych Gridy Architektura, komunikacja sieciowa i skala Sieć hierarchicznie łączonych węzłów przy użyciu SAN, LAN lub WAN Elastyczna sieć maszyn klienckich połączonych siecią nakładkową Heterogeniczny klaster klastrów połączonych szybkimi sieciami przy użyciu wybranych źródeł zasobów Wirtualizowany klaster serwerów rozciągający się poprzez wiele centrów danych z właściwymi umowami utrzymania Zarządzanie zasobami i kontrola Homogeniczne węzły wraz rozproszoną kontrolą przy użyciu systemów UNIX lub Linux Autonomiczni klienci, z dowolnym wejściem lub wyjściem z sieci wraz z rozproszoną samoorganizacją Scentralizowan a kontrola zorientowana na serwery z uwierzytelniony m bezpieczeństwe m i statycznym zarządzaniem zasobami Dynamiczne przydzielanie zasobów serwerów, pamięci masowych i sieci przy użyciu dużych zbiorów danych Wysokowydajne przetwarzanie, silniki Aplikacje i usługi wyszukiwania, zorientowane usługi webowe, sieciowo itp. Najatrakcyjniejsz a w dzieleniu się plikami, dostarczaniu treści oraz aplikacjach społecznościowy ch Rozproszone superprzetwarzanie, globalne rozwiązywanie problemów, usługi centrów danych Wyszukiwanie sieciowe, utility computing, outsourcing usług przetwarzania Tabela 1. Klasyfikacja rozproszonych i równoległych systemów przetwarzania. Źródło: Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing. From Parallel Processing to the Internet of Things, Morgan Kaufmann, s Problematyka wirtualizacji Stan wykorzystania współczesnych technologii wymaga wprowadzenia istotnego zastrzeżenia do przedstawionej powyżej definicji systemu rozproszonego. Otóż definicja ta uzależnia funkcjonowanie systemu rozproszonego od warstwy sprzętowej (samodzielne komputery). Korekta dotyczy właśnie tego elementu proponowanej definicji. Konwencjonalne komputery obsługiwane są przez jeden konkretny system operacyjny. Wpływa to na powiązanie aplikacji z konkretnym rozwiązaniem sprzętowym. Aplikacje mogą poprawnie funkcjonować w jednym środowisku sprzętowym, lecz nie spełniać swojego zadania w innym. Pokonanie tej choćby bariery możliwe jest dzięki wykorzystaniu wirtualizacji. Z pojęciem wirtualizacji spotkaliśmy się już, omawiając zagadnienie integracji informacji. Wtedy to rozwiązanie federacyjne było w istocie tworzeniem wirtualnego 73

74 obrazu zbioru danych, dostępnego dla aplikacji lub użytkowników. Wirtualizacja w obecnym kontekście dotyczy przede wszystkim warstwy systemowej, choć jak przekonamy się, pojęcie to może być rozciągnięte na wszystkie elementy platformy przetwarzania informacji w środowiskach informatycznych. Wirtualizacja w ujęciu systemowym umożliwia ukrycie warstwy sprzętowej i udostępnienie pewnej abstrakcji infrastruktury aplikacjom i użytkownikom. Z reguły wirtualizowane środowisko udostępnia system lub systemy, uruchamiane pod kontrolą hypervisora lub inaczej monitora maszyny wirtualnej. Monitor maszyny wirtualnej jest warstwą pośrednią, która udostępnia wirtualizowanym systemom zasoby sprzętowe takie jak procesor, pamięć operacyjną lub pamięci masowe i urządzenia wejścia/wyjścia. Sprawność ekonomiczna zależy bez wątpienia od umiejętności zarządzania zasobami bez względu na ich charakter. W środowiskach informatycznych dochodzi do istotnego sprzężenia zasobów rzeczowych z zasobami informacyjnymi. Polega ono na właściwym przyporządkowaniu i wykorzystaniu infrastruktury technicznej na rzecz infrastruktury informacyjnej. Jak dalece zakorzenione jest rozumienie takiego związku we współczesnym zarządzaniu zasobami informacyjnymi? Historia systemów informatycznych jawnie pokazuje, że stosowane technologie wykorzystywały metody wirtualizacji, choć cechowało je nieco odmienne zastosowanie np.: rozwiązania typu mainframe lub UNIX od dawna wcielały zasadę wirtualnego środowiska pracy użytkownika, ale nie było to rozwiązanie w ścisły sposób realizowane przy użyciu powyżej opisanej metody. Pierwsze symptomy rozproszonych środowisk datuje się na moment wykorzystywania właśnie komputerów klasy mainframe i terminali. W międzyczasie nastąpił znaczący rozwój dostępności minikomputerów, a w dalszej kolejności komputerów PC wraz z rozwiązaniami klient-serwer. Po okresie względnej autonomii przetwarzania danych i wykorzystywania aplikacji w obrębie komputerów PC nastąpił powrót do architektury klient-serwer bądź do architektury wielogałęziowej. Przy czym obecnie kluczowa zmiana polega na wykorzystywaniu infrastruktury poza obrębem organizacji. Innym ważnym czynnikiem rozwoju przetwarzania rozproszonego był postęp w dziedzinie sieci komputerowych ewoluujących w stronę protokołu TCP/IP wraz z rozpowszechnieniem sieci szerokopasmowych, będących podstawą dzisiejszej infrastruktury globalnej. Równolegle z tymi procesami dochodziło do różnego spojrzenia na funkcjonowanie i wykorzystywanie zasobów. Jednym z przykładów uświadomienia sobie, że infrastruktura techniczna jest realnym zasobem o istotnej wartości ekonomicznej jest koncepcja utility computing. Utility 74

75 computing umożliwia korzystanie z zasobów zlokalizowanych poza organizacją. Zamiast utrzymywać infrastrukturę wewnątrz organizacji utility computing pozwala na przeniesienie istotnych zadań i procesów do usługodawców. Paradygmat ten stosuje się głównie do przetwarzania informacji i wykorzystania zasobów obliczeniowych lub przestrzeni składowania danych. Przykład utility computing pokazuje, że zasoby obliczeniowe mogą stać się zasobem o wymiarze ekonomicznym. Koncepcja ta została przedstawiona już w latach 60-tych XX wieku przez Johna McCarthy'ego z MIT. Uprzedzając nieco wypadki, możemy w tej chwili w ujęciu historycznym przybliżyć znaczenie podejścia usługowego do zasobów technicznych środowisk informatycznych, które przedstawia Cambell-Kelly92. Organizacje od dawna stoją przed wyborem, czy korzystać z własnych zasobów, czy też zasobów zewnętrznych. Uwarunkowania techniczne wpływają istotnie na koniunkturę modelu usługowego w dziedzinie informatyki. Początki dziedziny automatycznego przetwarzania informacji, które mogło stać się towarem datuje się na lata 30-te XX wieku. Początki te nie dotyczyły jeszcze komputerów, a jedynie elektrycznych maszyn księgowych (ang. electric accounting machines) dostarczanych przez firmę IBM. Po raz pierwszy powstała wtedy alternatywa, czy dokonać inwestycji we własne maszyny, czy też zlecać zadania przetwarzania w biurach IBM. Już wtedy decyzja zależała od prostej kalkulacji wyznaczającej koszt transakcji. Jedną z pierwszych firm wykorzystujących model usługowy w przetwarzaniu informacji była niewielka firma pod nazwą Automatic Payrolls Inc. założona w 1949 roku. Świadczyła usługi przetwarzania list płac. Nie tylko dokonywała koniecznego przetwarzania, ale także redukowała ilość procesów księgowych u zleceniodawców. W późniejszym okresie (lata 60-te) już jako Automatic Data Processing Inc. nabyła komputer IBM 1401 i wykorzystywała pierwsze technologie sieciowe. Właśnie w tym okresie doszło do znaczącego rozwoju branży usług przetwarzania danych, a już roku 1961 powstała organizacja skupiająca usługodawców (ADAPSO Association of Data Processing Services Organizations). Co ciekawe ADP Inc. po dzień dzisiejszy zapewnia przygotowywanie wypłat w postaci czeków w Stanach Zjednoczonych. Niejako naprzeciw, niebezpośrednio na koncepcji ufundowanej przez McCarthiego w latach 60-tych w świadomości przedsiębiorców zaczęła krystalizować koncepcja przetwarzania jako zasobu. Carr ilustruje analogię do ery udostępniania energii elektrycznej, dowodząc, 92 Campbell-Kelly M. (2009), Historical reflections: The rise, fall, and resurrection of software as a service, Communications of the ACM 52(5), s

76 że obecny rozwój rozwiązań opartych na systemach rozproszonych i funkcjonujących podług modelu utility computing przypomina gospodarcze uwarunkowania dostawców i odbiorców energii elektrycznej i cofa się w tym celu aż do końca XIX wieku tj. do czasu, kiedy energia elektryczna stała się towarem93. Autor stawia prowokacyjną tezę o końcu ery przetwarzania w korporacjach. Powstaje choćby pytanie, czy złożone związki między zasobami służącymi do przetwarzania informacji można zestawić z niezłożonym zasobem jakim jest energia elektryczna? W dalszym ciągu pracy będziemy mieć na uwadze tezę o końcu przetwarzania korporacyjnego, gdyż wiąże się ona z głównymi założeniami i hipotezami niniejszej rozprawy. Wróćmy do historycznego ujęcia Campbell-Kelly'ego. Autor przekonuje, że model usługowy w przetwarzaniu informacji podlegał istotnym załamaniom. Wspominaliśmy już o nastaniu ery komputerów osobistych. Zanim do niej doszło w latach 60-tych powszechnie stosowano model czasowego dzielenia komputerów. Wykorzystywano wtedy dalekopisy łączone z mainframe'ami. Jednak na początku lat 70-tych doszło do recesji, która w Stanach Zjednoczonych wpłynęła silnie na branżę usług przetwarzania informacji. Niedługo później powstały ekranopisy lub tak zwane szklane dalekopisy (ang. glass teletypes), o wiele cichsze,dając wrażenie dzisiejszych komputerów. Stosowano wtedy między innymi model biznesowy uwzględniający podział zysków z dostawcą usługi. I wreszcie, mniej więcej w latach era czasowego dzielenia zasobów dobiegła przejściowego kresu, a stało się to za sprawą dostępności komputerów osobistych. Ich koszt przyczynił się do nieopłacalności usług udostępniania zasobów. Komputery osobiste mogły zostać spłacone w ciągu roku. Uniknięto dzierżawy linii telefonicznych koniecznych dla utrzymania infrastruktury bazującej na mainframe'ach i w końcu komputery osobiste nie wymagały znaczących nakładów w utrzymaniu. Nowe możliwości dla modelu utility computing otworzyła głównie technologia sieciowa oraz wzrost kosztów utrzymania infrastruktury i jej złożoność. Trudno jednak wyrokować, jak długo model ten będzie ugruntowany ekonomiczne. Nie ulega jednak wątpliwości, że ma on coraz większe znaczenie w różnych dziedzinach działalności gospodarczej i naukowej. Podstawowa zasada wirtualizacji odnosi się do powyższych przemian. Jednoznaczne przypisanie systemu operacyjnego lub aplikacji do konkretnego serwera prowadzi wielokrotnie do niepełnego wykorzystania jego możliwości obliczeniowych. Wyobraźmy sobie sytuację, w której firma logistyczna zapełnia przestrzeń wysyłanych kontenerów 93 Carr N. (2005), The end of corporate computing, op. cit., s

77 jedynie w jednej trzeciej. Niewykorzystaną przestrzeń przyrównać można do niewykorzystanej przestrzeni obliczeniowej. Intensywny rozwój technologii wirtualizacji datuje się na początek obecnego wieku. Początkowo technologia ta zwróciła uwagę głównie zarządzających centrami danych, ale już wkrótce okazało się, że wszelkim wysiłkom konsolidacji przetwarzania informacji w przedsiębiorstwach sprzyjają rozwiązania wirtualizacji. Okazuje się, że koncepcja jednoznacznego przypisania warstwy sprzętowej do warstwy oprogramowania coraz rzadziej ma zastosowanie. Co więcej, jak przekonamy się w dalszej części sama warstwa oprogramowania może być podzielona na warstwy systemów operacyjnych i aplikacji, tworząc kolejne stopnie wirtualizacji w środowiskach informatycznych. W każdym jednak przypadku ostatecznym rezultatem stosowanej technologi jest zapewnienie możliwie najpełniejszego i spójnego obrazu przetwarzania informacji. Początkowo wirtualizowano środowiska projektowania aplikacji oraz środowiska testowe. Jednak około roku 2005 wirtualizacja dosięgła środowisk produkcyjnych infrastruktury IT. Przyglądając się pobieżnie korzyściom płynącym z wirtualizacji, można wymienić następujące z nich: konsolidacja środowisk produkcyjnych stosowanie rozwiązań wirtualizacji prowadzi do silniejszej koncentracji zadań oraz zwiększa ich efektywność; ujednolicenie i standaryzacja platform z konsolidacją wiąże się nieodłącznie standaryzacja, która na poziomie sprzętowym ogranicza problemy związane z różnorodnością konfiguracji, a na poziomie oprogramowania wyklucza konflikty związane z tą różnorodnością; ułatwienie migracji środowisk wirtualizowane środowisko umożliwia szybszą migrację, przyczynia się bowiem do tego zmniejszenie heterogeniczności systemowej osiąganej dzięki standaryzacji; skalowalność udana implementacja środowiska z racji możliwości jego replikacji przyśpiesza procesy jego rozszerzania; zwiększenie dostępności platform w chwili braku dostępności lub awarii systemu, może on być z powodzeniem odtworzony na równoległej platformie; uproszczenie zarządzania infrastrukturą: wiele typowych zadań w wirtualizowanych środowiskach może być automatyzowanych np.: monitorowanie infrastruktury lub automatyzacja reakcji na zdefiniowane problemy; 77

78 oprogramowanie do zarządzania redukuje ilość potrzebnych pracowników IT; większa dostępność aplikacji, baz danych oraz redukcja kosztów związanych z brakiem produktywności użytkowników lub dostępem klientów i partnerów do aplikacji; uproszczone zadanie wsparcia użytkowników z racji mniejszej heterogeniczności środowisk IT; zwiększenie wskaźników ilości użytkownika na serwer i administratora na serwer. Oczywiście ostatecznie wszystkie te korzyści wpływają na koszty w ujęciu ogólnym (TCO total cost of ownership), co potwierdzają raporty branżowe94. Przykładowe zestawienie kosztów na serwer oraz analizy zwrotu z nakładów inwestycyjnych (ROI) w ciągu trzech lat zawiera tabela 295: Wirtualizacja podstawowa Wirtualizacja zaawansowana Korzyści ogółem 144,9 $ 212,4 $ Całkowita inwestycja 24,1 $ 23,3 $ Korzyści zdyskontowane 113,3 $ 166,6 $ Inwestycja zdyskontowana 19,8 $ 19,1 $ NPV (net present value) 93,5 $ 147,0 $ 472,00% 769,00% 6,8 4,3 12,00% 12,00% ROI (return on investment) Zwrot nakładów (miesiące po wdrożeniu) Stopa dyskontowa Tabela 2. Porównanie zwrotu z nakładów inwestycyjnych dla wirtualizacji pojedynczego serwera. Źródło: Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of Integrated Solutions,IDC, Raport techniczny nr Wirtualizacja w warstwie systemowej rozszerzona może być na warstwę aplikacji. Oznacza to, że wirtualizowane środowisko aplikacji spełniać powinno podstawowy warunek zawarty w definicji systemu rozproszonego, a mianowicie przezroczystość. Istotnie, rozpowszechnione na masową skalę aplikacje dostarczane komercyjnie i 94 Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of Integrated Solutions,IDC, Raport techniczny nr Wirtualizacji podstawowa konsolidacja serwerów bez zaawansowanej technologii migracji oraz z ograniczoną automatyzacją, systemy są wykorzystywane w 20%-40%, ograniczone zastosowanie w środowisku produkcyjnym; wirtualizacja zaawansowana szeroko wirtualizowana infrastruktura (>25%), wirtualizacja serwerów i pamięci masowych, wykorzystywanie zaawansowanych narzędzi automatyzacji zadań oraz równoważenia obciążenia, wykorzystanie od 40%-60% mocy; korzyści ogółem obniżenie kosztów na użytkownika w okresie trzech lat; całkowita inwestycja inwestycja w sprzęt, oprogramowania, usługi, czas personelu IT wymagana do wdrożenia; korzyści zdyskontowane korzyści netto realizowane przez użytkowników; inwestycja zdyskontowana faktyczne koszty inwestycji; NPV korzyści zdyskontowane - inwestycja zdyskontowana; ROI stosunek NPV do inwestycji zdyskontowanej; zwrot nakładów czas po którym zostaje spłacona inwestycja; stop dyskontowa koszt kapitału i ryzyka przedłużonego czasu wdrożenia. 78

79 niekomercyjnie w Internecie spełniają ten warunek. Szeroko stosowana wirtualizacja wraz z rozwojem globalnej sieci i technicznymi jej możliwościami przyczyniły się do narodzin zjawiska i technologii noszących miano chmury obliczeniowej (ang. cloud computing) Typologia modeli biznesowych chmury obliczeniowej Oprócz sprzyjających i szeroko stosowanych technologii wirtualizacji wraz z rozwojem sieci Internet różnorodne firmy zaczęły na szeroką skalę stosować platformy udostępniające aplikacje do komunikowania się, osiągnęły także znaczącą sprawność w zarządzaniu centrami danych oraz składowaniem danych. Na masową skalę firmy internetowe dostarczają takie rozwiązania jak platformy wyszukiwania, pakiety biurowe, aplikacje do zarządzania procesami czy wspierające pracę grupową. Wszelkie te aplikacje mogą być utrzymywane na komercyjnych platformach jako usługi przynoszące zyski firmom je dostarczającym. Oprogramowanie nie musi rezydować na komputerze osobistym. Przykładem mogą tu być choćby dostawcy poczty elektronicznej. Należy jednak zauważyć, że takie rozwiązania były dostępne już w 90-tych ubiegłego wieku, gdy firmy takie jak Hotmail i Yahoo udostępniały na swoich platformach podobne usługi. Można zatem powiedzieć, że sieciowy model usługowy rozwinął się za sprawą Internetu. W przyszłości, praca z dużymi zbiorami danych będzie zazwyczaj oznaczać wysyłanie żądań obliczeń w stronę lokalizacji danych, raczej niż kopiowanie danych do stacji roboczych. Odzwierciedla to trend w IT, który polega na przenoszeniu przetwarzania od stacji roboczych do dużych centrów danych, gdzie dostarcza się na żądanie oprogramowanie, sprzęt oraz dane jako usługi. Eksplozja danych prowadzi do idei chmury obliczeniowej 96. Ten proces obserwujemy już od czasu rozwoju architektury klient-serwer, a za nią architektury wielogałęziowej, jednak kluczowe zjawisko prowadzące do przemian w metodach i systemach przetwarzania informacji podlega, jak zauważa Hwang, dynamicznej eksplozji danych. Coraz bardziej złożony staje się problem ich składowania oraz tworzenia repozytoriów. Duże zestawy danych ograniczają możliwości stosowania dotychczasowych modeli baz danych, a struktura informacji, zwłaszcza informacji będącej 96 Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing, op. cit., s

80 podstawą podejmowania decyzji zawiera elementy o różnej funkcji i znaczeniu (np.: informacja może zawierać już nie tylko elementy czysto ilościowe, ale także jakościowe). Jedną z najpełniejszych definicji chmury obliczeniowej przestawia Ian Foster. Za chmurę obliczeniową możemy uznać: paradygmat rozproszonego i wielkoskalowego przetwarzania motywowanego przez ekonomię skali, w którym pula abstrakcyjnych, wirtualizowanych, dynamicznie skalowanych i zarządzanych zasobów takich jak moc obliczeniowa, przestrzeń danych, platformy i usługi dostarczana jest do zewnętrznych klientów na żądanie za pośrednictwem Internetu 97 W definicji tej możemy wyróżnić następujące elementy: zasoby zasoby udostępniane są jako abstrakcyjne jednostki dostarczające różne poziomy usług podmiotom spoza chmury; skalowalność chmury obliczeniowe są środowiskami o znaczących możliwościach skalowania. Zawierają w sobie pulę zasobów udostępnionych zarejestrowanym użytkownikom lub podmiotom. Umożliwia to między innymi rezygnację w utrzymywania własnego centrum danych; technologia wirtualizacji dzięki niej wirtualizowane zasoby mogą być dynamicznie przydzielane. Na poziomie sprzętowym tworzyć one mogą wspomniane pule, które udostępniane są na żądanie; ekonomia skali do chmury obliczeniowej w istotny sposób odnosi się ekonomia skali. Dynamicznie skalowane i wirtualizowane zasoby koncentrowane mogą być w ogromnych centrach danych, gdzie zasoby obliczeniowe i informacyjne jako towar w istocie podlegają prawom ekonomii skali. Okazuje się, że istotne przemiany gospodarcze dotyczące produktów materialnych dosięgły nie tylko skalowanej infrastruktury, ale także produktów niematerialnych (warstwa oprogramowania). Właśnie w modelu chmury obliczeniowej między innymi dzięki możliwościom replikacji środowiska w wirtualizowanych platformach, ekonomia skali dosięga warstwy oprogramowania. Dotychczasowy model, nie bazujący na technologiach wirtualizacji znacząco obniża możliwości dynamicznego przydzielania zasobów, a tym samym obniża potencjał ekonomii skali. Dzięki ekonomii skali ważnym elementem funkcjonowania chmur obliczeniowych, 97 Foster I. et al. (2008), Cloud Computing and Grid Computing 360-Degree Compared w GCE '08 In 2008 Grid Computing Environments Workshop, s

81 zarówno z punktu widzenia dostawcy, jak i odbiorcy, są koszty utrzymania i dzierżawienia usługi. Do szerokiego zastosowania chmur obliczeniowych oprócz wirtualizacji i znaczącego rozwoju technologii obliczeniowych, przyczyniło się także szerokie zastosowanie architektury zorientowanej na usługi (SOA) a wraz z nią modularyzacja oprogramowania. Architektura zorientowana na usługi dzięki luźnemu sprzężeniu spełnia zasadę braku podatności na awarię w systemach rozproszonych. W architekturze tej komponenty składające się na tworzoną aplikację mogą działać niezależnie na różnych maszynach. W przeciwieństwie do silnego sprzężenia zmiany w jednym module aplikacji nie muszą wpływać na zmiany w innych. Atrakcyjność architektury zorientowanej na usługi wynika między innymi z możliwości ponownego wykorzystania tworzonych modułów i to właśnie z jej podstaw korzysta wiele aplikacji internetowych. Usługi definiowane w architekturze mogą odpowiadać funkcjom biznesowym, które z kolei podlegają integrowaniu, zapewniając obsługę żądanych procesów: SOA. Elastyczny zestaw zasad projektowania systemu w poszczególnych fazach wytwarzania i integracji. Wdrożona architektura oparta o SOA to luźno sprzężony zbiór usług, które mogą być wykorzystywane w różnych dziedzinach biznesowych. SOA dzieli funkcje na rozłączne jednostki, nazywane usługami, udostępniane w sieci (najczęściej w internecie), tak aby użytkownicy mogli korzystać z nich i łączyć je w aplikacjach produkcyjnych. Usługi komunikują się z konsumentami, przekazując dane w dobrze zdefiniowanym, wspólnym formacie (najczęściej XML) lub koordynując czynności wykonywane przez dwie usługi lub więcej usług 98. Tak definiowany paradygmat tworzenia aplikacji zapewnia dużą dowolność w ich tworzeniu, w skład których część usług może pochodzić z zewnątrz, zaś część może być tworzona we własnym zakresie. Przyśpiesza to proces tworzenia aplikacji lub tworzenie ich wręcz ad hoc. Dodatkową zaletą tej architektury jest możliwość wykorzystania standardowych protokołów internetowych umożliwiających komunikację. Dzięki założeniom architektury SOA usługi mogą być publikowane w Internecie przez ich dostawców i odnajdowane dzięki rejestrom przez konsumentów usługi. W tradycyjnym modelu przetwarzania organizacje są zmuszone utrzymywać własną infrastrukturę, zapewniając między innymi ciągłość jej działania. Jak widzieliśmy powyżej, wiąże się to choćby z niepełnym jej wykorzystaniem, ale także z koniecznym 98 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa. Rozwiązania dla biznesu, Helion, Gliwice, s

82 utrzymaniem i administracją, aktualizacjami oprogramowania. Odpowiedzią na te problemy, choć nie w każdym przypadku, mogą być modele usługowe stosowane w chmurach obliczeniowych. Mateos i Rosenberg dla wyróżnienia usług przetwarzania w chmurach obliczeniowych proponują schemat X jako usługa 99. Za X możemy podstawić różnego rodzaju zasoby: sprzęt, infrastrukturę, platformę, framework lub aplikacje. W obecnej taksonomii wyróżnia się jednak trzy podstawowe modele: infrastruktura jako usługa (ang. Infrastructure as a Service IaaS), platforma jako usługa (ang. Platform as a Service PaaS) i oprogramowanie jako usługa (ang. Software as a Service SaaS) IaaS. W modelu tym dostawcy udostępniają sprzęt i oprogramowanie z reguły przy użyciu technologii wirtualizacji. Użytkownicy działają zatem na najniższym poziomie. Dzięki wirtualizacji użytkownicy mogą na żądanie wdrażać dowolną liczbę systemów operacyjnych i konfigurować je z aplikacjami. Jednak nie zarządzają infrastrukturą chmury, a określają jedynie wymaganą ilość zasobów. W modelu tym dostępne mogą być także pamięć masowa oraz łącza transmisji danych. PaaS. Model ten udostępnia rozszerzone środowisko służące tworzeniu, testowaniu oraz wdrażaniu aplikacji w chmurze. Środowisko takie zawiera narzędzia programistyczne dostarczane przez dostawcę platformy. Skonstruowane jest zatem ze sprzętu i oprogramowania zintegrowanego z określonymi interfejsami programistycznymi. Należy podkreślić, że platforma taka wiąże się z reguły z ograniczeniami powodowanymi konkretnym typem oprogramowania. SaaS. Z modelem tym kojarzy się popularny zwłaszcza na początku obecnego wieku model ASP (ang. application service providers). Dostawcy dostarczali aplikacje według nowego modelu licencyjnego uzależnionego od faktycznie używanych instancji programu. Aplikacje w większości przypadków dostarczane były w pewnych odmianach wirtualizacji. W obecnym kształcie SaaS oferuje aplikacje uruchamiane przy użyciu przeglądarki jako aplikacje webowe i to właśnie ten sposób ich uruchamiania przyczynił się do lawinowego przyrostu zastosowań tego modelu. Model SaaS przypisać można do warstwy aplikacji w typowym środowisku użytkownika, gdzie za wszelkie działania wdrożenia i zarządzania odpowiada dostawca usługi. Dzięki temu wszelkie problemy dotyczące utrzymania aplikacji są minimalizowane. Dostawcy odpowiedzialni są zatem nie tylko za konfigurację środowiska aplikacji, ale także za aktualizacje oprogramowania oraz obsługę błędów. Z zarządzaniem aplikacją przez dostawcę wiąże się także możliwość 99 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

83 bezpośredniego wsparcia użytkowników oraz tworzenie baz wiedzy dotyczących użytkowania aplikacji. Podobnie jak w innych modelach aplikacje dostarczane są w trybie na żądanie w różnych modelach opłat. Dostawcy rozwiązań w modelu SaaS oferują instancje tej samej aplikacji wielu usługobiorcom. Celem dostawców jest minimalizowanie zmian konfiguracyjnych koniecznych do utrzymania aplikacji, co prowadzić ma do uzyskania ekonomii skali100. Minimalizacja różnorodności środowisk dostarczanej aplikacji SaaS nie zawsze jest możliwa. Im bogatsza bowiem funkcjonalność aplikacji tym większa szansa różnorodności zapotrzebowań usługobiorców. Wymagania mogą dotyczyć nie tylko obszaru funkcjonalnego, ale także kwestii integracji ze środowiskiem usługobiorcy, wydajności oraz zapewnienia bezpieczeństwa. Z punktu widzenia dostawcy zachodzi istotna zależność pomiędzy zapewnieniem wymaganiom możliwie użytkowników, a szerokiej stworzeniem funkcjonalności trzonu odpowiadającej funkcjonalnego aplikacji, wykorzystywanego w każdej instancji i zapewniającego korzyści płynące z ekonomii skali. Od sprawnego planowania tej relacji (zmienność funkcjonalna vs. trzon funkcjonalny aplikacji) zależy ekonomiczny sukces przedsięwzięć w modelu SaaS. Skala zastosowań modelu SaaS jest bardzo szeroka. Oprogramowanie dostarczane w tym modelu zapewnia obsługę wielu procesów biznesowych w organizacjach. Oprogramowanie SaaS dostarczane dla firm to aplikacje CRM, HR, ERP, aplikacje biurowe, systemy finansowe oraz aplikacje do pracy grupowej. Oddzielną grupę, którą będziemy szerzej się zajmować, stanowią aplikacje analityki biznesowej. Równolegle do modelu SaaS dostawcy usług oferują czasem usługę pod nazwą FaaS (ang. Framework as a Service). Usługa ta przylega do usługi SaaS i umożliwia tworzenie dodatkowych komponentów dla dzierżawionej w modelu SaaS aplikacji np.: aplikacja CRM może być w tym modelu rozszerzona o dodatkowe funkcje. 100 Por. Moc K. (2011), SaaS jako innowacyjny model dostarczania oprogramowania dla przedsiębiorstw w Chmielarz W., Kisielnicki J., O. S., red., Informatyka 4 Przyszłości, Wydawnictwo Wydziału Zarządzania UW, Warszawa, s

84 Warto w tym miejscu podkreślić dwa niezależne nurty. Z jednej z strony wszelkie zasoby (w warstwie sprzętowej lub programistycznej) w chmurach obliczeniowych mogą być udostępniane w modelu usługowym. Z drugiej zaś, tworzenie aplikacji wykorzystywać może architekturę zorientowaną na usługi. Komponenty aplikacji odnoszące się do Rysunek 6. Modele upowszechniania i modele usługowe chmur obliczeniowych. Źródło: opracowanie własne na podstawie: Owoc M., Hauke K. (2010), Modele upowszechniania cloud computingu w organizacjach w Korczak J., Chomiak-Orsa I., Sroka H., red., Systemy informatyczne w zarządzaniu, Uniwersytet Ekonomiczny we Wrocławiu, Wrocław, s konkretnych funkcji funkcjonują jako usługi, ale i same aplikacje udostępniane na żądanie w chmurach podlegają zasadom biznesowego modelu usługowego. Nie ma tu bezpośredniej zależności (usługi są w każdym z tych przypadków definiowane w odmienny sposób), ale świadczy to o pewnym zjawisku, które ściśle odnosi się do 84

85 korzystania z zasobów, a mianowicie możliwości korzystania z nich w elastyczny i dynamiczny sposób. Zarówno bowiem komponenty aplikacji w architekturze SOA jak i usługi w chmurze (IaaS, PaaS, SaaS) mogą być dowolnie komponowane bez potrzeby stałego ich wykorzystania. W tych przypadkach to realna, niejednokrotnie chwilowa potrzeba stanowi o kreowaniu infrastruktury informatycznej. Wiąże się to z odmiennym podejściem do zarządzania nią i bezsprzecznie ułatwia jej planowanie oraz implementację.możemy w tym momencie powrócić do pytania o analogię między dostawcami zasobów energetycznych, a dostawcami usług w chmurach obliczeniowych. Z perspektywy trzech wymienionych modeli biznesowych usług zasoby nie są już prostym źródłem utrzymującym działanie infrastruktury. O ile zachodzi bezpośredni związek między mocą obliczeniową, a na przykład energią elektryczną, o tyle sama infrastruktura i oparta o nią warstwa oprogramowania funkcjonuje już na innym poziomie. Poziom ten możemy nazwać poziomem infrastrukturalnym lub zgodnie z charakterystyką zarysowaną w części poświęconej integracji, warstwą systemową. Zasadniczo przestrzeń tej płaszczyzny zawiera szeroko pojęte narzędzia, które uznać możemy za systemy i aplikacje umożliwiające przetwarzanie informacji. Właśnie w tej przestrzeni zachodzą skomplikowane relacje inkluzji oraz zależności, których nie obserwujemy w przypadku prostych zasobów umożliwiających działanie owych narzędzi (moc obliczeniowa w swoisty sposób zasila realizowanie funkcji tak pojętych narzędzi). Ponadto z punktu widzenia zarządzania jednym i drugim typem zasobów (zasobów zasilających i przetwarzających) określenie sposobu ich przydzielania, realizowania, wdrażania i finansowania ma zgoła odmienny charakter. Szczególnie dotyczy to metod oceny wartości tych zasobów oraz istotnego ich przełożenia na spełnianie wszelkich zadań, jakie stawia sobie organizacja w celu spełnienia swojej misji. Ponadto ekonomiczny wymiar stosowania i wykorzystywania zasobów w ramach chmur obliczeniowych wiąże się niepodzielenie z modelem usługowym oraz relacją między zasobami z chmury obliczeniowej, a zasobami wewnętrznymi. Chmury obliczeniowe mogą być upowszechniane w czterech modelach: chmury publicznej, prywatnej, wspólnej i hybrydowej. Typowy model upowszechniania chmury obliczeniowej (chmura publiczna) odnosi się do wspomnianych usług oferowanych przez niezależnych i zewnętrznych dostawców za pośrednictwem Internetu. Organizacje decydują się jednak coraz częściej na tworzenie własnych chmur obliczeniowych. 85

86 Według statystyk typowy serwer w centrach danych różnych organizacji wykorzystywany jest w około 5%, a w chwili maksymalnego obciążenia w około 20%101. Głównym czynnikiem wpływającym na możliwość stosowania modelu chmury prywatnej jest zainteresowanie decydentów IT technologiami wirtualizacji już na wczesnym etapie rozwoju infrastruktury. To właśnie one stały się czynnikiem stymulującym rozwój wszelkich rozwiązań chmury obliczeniowej. Mateos wymienia cztery podstawowe przesłanki stworzenia prywatnej chmury obliczeniowej102: bezpieczeństwo krytyczne cechy danych, takie jak prawne obwarowania ich ochrony mogą uniemożliwić wdrożenie aplikacji w chmurach publicznych. W takim przypadku dane nie mogą zostać przeniesione i przetwarzane poza obrębem organizacji. dostępność chmury publiczne w większości przypadków nie gwarantują 100% pewności dostępności zasobów z puli przydzielanej na żądanie, a co może zapewnić chmura prywatna. społeczność użytkowników przy dużym rozproszeniu geograficznym i rozproszeniu struktury organizacyjnej zasadne może być tworzenie jednej wirtualizowanej infrastruktury. efekty skali istniejąca infrastruktura IT może sprzyjać tworzeniu chmury prywatnej, a jej konstrukcja może być łatwo poszerzana. Skala centrum danych wiąże się także z możliwością negocjacji korzystniejszych warunków zakupu sprzętu do tworzenia infrastruktury (serwery, pamięci masowe, urządzenia sieciowe itp.). Do chmury obliczeniowej stosuje się pięć głównych zasad: pula zasobów, wirtualizacja, elastyczność, automatyzacja i naliczanie opłat. W przypadku chmury prywatnej zastosowanie mają tylko zasady wirtualizacji, elastyczności i automatyzacji, gdyż pula zasobów określa poziom dostępu w określonej usłudze dla klientów dostawcy. Do chmury prywatnej nie stosuje się także formuł naliczania opłat, tak jak ma to miejsce w przypadku komercyjnych dostawców usług w chmurach publicznych, bowiem zasoby pierwszego typu chmury dostępne są tylko dla danej organizacji. Oczywiście teoretycznie zasoby wewnętrznej chmury obliczeniowej mogą być przydzielane na żądanie, ale wiąże się to ze specyfiką działalności przedsiębiorstwa. Możemy sobie wyobrazić rygorystycznie przestrzegane zasady wykorzystywania mocy obliczeniowej w organizacjach nastawionych 101 Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing, op. cit., s Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

87 na badania i rozwój technologii, gdzie ściśle określa się priorytety zadań związanych z przetwarzaniem danych. Niejako pośrednim rozwiązaniem może być wirtualna chmura prywatna, która jest wydzieloną infrastrukturą, która tworzy system hybrydowy. Łączy się w nim wewnętrzne centrum danych z wydzieloną chmurą w usłudze publicznej. Zasoby łączone są za pomocą tuneli VPN, które zapewniają ochronę chmury wirtualnej. W takim przypadku narzędzia do ochrony (zapory ogniowe lub IDS (systemy wykrywania włamań) obejmują także wirtualną chmurę. Do tak użytkowanej chmury wirtualnej przenosić można część aplikacji z zastanej infrastruktury organizacji. Do pozostałych modeli upowszechniania należy zaliczyć: chmury wspólne, w których organizacje współdzielą infrastrukturę, kierując się podobnymi celami w konkretnym środowisku (np.: misja, wymogi bezpieczeństwa itp.) oraz chmury hybrydowe stanowiące zespolenie wielu chmur powiązanych ze sobą wybraną technologią. Chmurą hybrydową może być na przykład chmura powstała z połączenia chmur prywatnej i publicznej Korzyści, wyzwania i zagrożenia w chmurach obliczeniowych. Technologia i modele chmur obliczeniowych przeżywają obecnie intensywny rozwój. Nie jest to już jedynie termin celnie wykorzystywany na potrzeby promocji producentów i dostawców oprogramowania i sprzętu. Rozwój tego modelu przetwarzania przyczynił się do wytworzenia odrębnej branży, jednak pomimo jawnych korzyści, stosowanie różnych metod upowszechniania chmur obliczeniowych wiąże się z zagrożeniami. Według raportu firmy Red Shift Research opracowanego na zlecenie AMD, producenta procesorów, technologie stosowane w chmurach obliczeniowych osiągają stadium dojrzałości, a 37% organizacji badanych globalnie wdraża te rozwiązania103. Większa część organizacji decyduje się na wdrożenia własnych chmur obliczeniowych i wykorzystuje je na potrzeby zdalnych aplikacji(26% organizacji) lub gromadzenia danych (26% organizacji). Przy czym tylko 15% organizacji wdraża ten model w celu realizacji obydwu tych potrzeb. Warto przy tym zaznaczyć, że także sektor publiczny, mimo oczywistych wątpliwości, wykazuje coraz większe zainteresowanie. W ujęciu globalnym 23% 103 AMD (2011), Adoption, Approaches & Attitudes. The Future of Cloud Computing in the Public and Private Sectors, AMD, 87

88 organizacji publicznych stosuje już pewną odmianę technologii chmur obliczeniowych, a 36% rozważa taką możliwość. W końcu, z punktu widzenia zastosowań, wśród stosowanych w chmurach aplikacji przeważa oprogramowanie finansowe, , aplikacje obsługujące HR i e-commerce, marketing, sprzedaż, produkcję, usługi webowe i ERP. Chmury obliczeniowe jako nowy model przetwarzania informacji są obecnie w centrum zainteresowania nie tylko decydentów IT w wielu organizacjach, ale także bezpośrednich beneficjentów stosowanych technologii i oprogramowania, tj. użytkowników i osób realizujących zadania i procesy niezbędne do działania organizacji oraz spełniania jej celów. W organizacjach problemy techniczne wiążące się z realizacją postulatów chmur obliczeniowych lub kwestie ekonomiczne nie mogą stanowić jedynego źródła podejmowanych w tym celów kroków. Według wspomnianego raportu wśród organizacji, które zdecydowały się na wdrożenie modeli chmury obliczeniowej tylko połowa traktuje ten paradygmat jako istotny dla strategicznej zmiany w korporacyjnych wytycznych dotyczących IT. W pozostałych przypadkach decyzje mają charakter ekonomiczny lub wiążą się z realizacją konkretnego celu. Zastosowanie chmury obliczeniowej wzorem wielu organizacji powinno uwzględniać wpływ jej stosowania na całościowy obraz polityki systemów informacyjnych. Właśnie dlatego omawiane szeroko korzyści i zagrożenia będziemy szeregować według następującej procedury: gromadzone aspekty podstaw działania chmur obliczeniowych i konsekwencji ich użytkowania grupować będziemy według analizy SWOT; analiza SWOT stanowić będzie podstawę dla wyodrębnienia z niej czynników ekonomicznych, technicznych i organizacyjnych. W skrócie ten etap nazwiemy analizą ETO; wyodrębnione w analizie ETO czynniki odniesiemy następnie do charakteru organizacji; na postawie przeprowadzonej analizy ETO określimy możliwe związki między grupami czynników. Metoda SWOT stosowana jest najczęściej w celu ustalenia możliwych działań strategicznych organizacji104. Zastosowanie jej do technologii lub sposobów przetwarzania informacji może budzić poważne wątpliwości metodologiczne. Jednak usytuowanie chmur obliczeniowych na tle analizy SWOT prezentuje choćby Marston105, a w naszym 104 Por. Pierścionek Z. (2011), Zarządzanie strategiczne w przedsiębiorstwie, PWN, Warszawa, s oraz Obłój K. (2007), Strategia organizacji, PWE, Warszawa, s Marston S. et al. (2011), Cloud Computing - The Business Perspective, Decision Support Systems 51, s

89 przypadku zastosowanie tej metody ma charakter porządkujący lub przygotowawczy i jest punktem wyjściowym pod właściwą analizę ETO. Analiza ETO, odniesiona do pierwszej metody, ma za zadanie ukazać pogłębione relacje zachodzące w macierzy SWOT w trzech istotnych z punktu widzenia organizacji wymiarach: ekonomicznym, technicznym i organizacyjnym. W ujęciu mikroekonomicznym w celu przeprowadzenia analizy SWOT należy przeprowadzić następujące czynności106: 1. Określenie i zdefiniowanie mocnych i słabych stron, szans i zagrożeń. 2. Przypisanie wag do zdefiniowanych elementów w celu oceny znaczenia możliwości rozwoju przedsiębiorstwa lub organizacji. 3. Wertykalne zbadanie relacji zachodzących między czynnikami. Jako metoda heurystyczna, koncepcja SWOT może być stosowana nie tylko do analizy organizacji, ale także analizy projektów lub tworzonych rozwiązań. Za takie rozwiązanie uznamy model chmury obliczeniowej. W przeprowadzonym badaniu wykorzystamy podział na czynniki zewnętrzne i wewnętrzne, którym odpowiadają mocne/słabe strony oraz szanse/zagrożenia107. Analiza SWOT może być przeprowadzana w dwóch kierunkach, w których bada się relacje zachodzące między czynnikami wewnętrznymi, a zewnętrznymi lub odwrotnie: od wewnątrz do zewnątrz (SWOT); od zewnątrz do wewnątrz (TOWS). W naszym badaniu analizować będziemy związki w pierwszym ujęciu, tj. na ile wewnętrzne czynniki modelu chmury obliczeniowej determinują czynniki zewnętrzne. Przeprowadzana tu analiza będzie miała rudymentarny charakter. Wiąże się to z dwojakiego rodzaju problemami. Po pierwsze, ścisłe przypisanie niektórych czynników do kategorii czynników wewnętrznych lub zewnętrznych jest problematyczne np.: bezpieczeństwo może być związane z zastosowaniem konkretnej technologii czynnik wewnętrzny lub regulacjami prawnymi czynnik zewnętrzny. Po drugie, decyzja 106 Obłój K. (2007) Strategia organizacji, op. cit., s Stosując zasadę przeniesienia analogicznego, możemy określić strukturalne podobieństwa ujęcia mikroekonomicznego do analizowanego przez nas zjawiska: model chmury obliczeniowej posiada cechy opisujące, które uznać możemy za czynniki wewnętrzne determinujące jego funkcjonowanie oraz może podlegać przemianom pod wpływem czynników zewnętrznych. Te dwa typy czynników określają warunki jego rozwoju oraz podatność na zastosowania. W typowym ujęciu mikroekonomicznym analiza SWOT ma na na celu ustalenie strategii działania organizacji. W naszym ujęciu punktem odniesienia dla analizy SWOT będzie możliwość zastosowania, a ściślej podatność modelu chmury obliczeniowej na zastosowania w organizacji oraz możliwości rozwoju tego modelu. 89

90 dotycząca przydzielenia wag do określonych czynników nie może być poparta badaniami ilościowymi108. Głównym celem analizy SWOT przeprowadzanej na potrzeby tego studium jest wyróżnienie istotnych związków między czynnikami warunkującymi funkcjonowanie i zastosowanie modelu chmury obliczeniowej a w konsekwencji określenie podstaw dla Rysunek 7. Przekrój czynników w analizie SWOT chmury obliczeniowej. Źródło: opracowanie własne. kierunku badań o związkach zachodzących między kształtowaniem i rozwojem technologii wspierających model chmury obliczeniowej (przykładem wykorzystania paradygmatu systemów rozproszonych), a rozwiązaniami analityki biznesowej Rozwinięcie charakterystyki chmur obliczeniowych i analiza SWOT Analiza SWOT zgodnie z poczynionymi powyżej założeniami przebiegać będzie w czterech obszarach: mocnych stron, słabych stron, szans i zagrożeń. W każdym z tych obszarów wyodrębnimy kluczowe czynniki. W kolejnym etapie określimy zachodzące 108 O ile przypisanie wag poszczególnych czynników w analizie SWOT w konkretnej organizacji może wiązać się ze ścisłym określeniem wag na podstawie założeń strategicznych firmy oraz na podstawie wyników finansowych, analiz kosztów, efektywności produkcji, ilościowych badań rynku itp., o tyle analiza modelu chmury obliczeniowej przeprowadzana na potrzeby niniejszej rozprawy wymagałaby przeprowadzania przekrojowych i szerokich ilościowych badań czynników wraz z określeniem ich wpływu na skuteczność działań badanych organizacji, co odbiega od właściwego tematu rozprawy. 90

91 relacje oraz kierunki związków czyli wyznaczenie czynników determinujących zarówno negatywnie, jak i pozytywnie obecność innych czynników. Mocne strony. W definicji zaproponowanej przez Fostera wyróżniliśmy takie elementy jak:wirtualizację, skalowalność, udostępnianie abstrakcyjnych jednostek na różnych poziomach usług. Definicja ta zawiera także element nie rozwijany wcześniej, a mianowicie zarządzanie infrastrukturą. Do mocnych stron należy dodać też czynnik bezpieczeństwa, który zazwyczaj uznawany jest za inhibitor zastosowań modelu chmury obliczeniowej. Elementy te traktować będziemy jako czynniki przynależące do obszaru mocnych stron analizy SWOT modelu chmury obliczeniowej. Zarządzanie infrastrukturą. W klasycznym modelu przetwarzania systemów informacyjnych w organizacjach większość zadań związanych z zarządzaniem nimi realizowana jest wewnątrz organizacji. Oczywiście organizacje coraz częściej relegują zadania trzecim stronom, stosując w tym celu outsourcing czyli wydzielanie podstawowych procesów produkcyjnych (usługowych) lub/i zarządczych poza granice danego przedsiębiorstwa oraz realizowanie ich w ścisłej współpracy z różnymi, coraz to nowymi, niezależnymi przedsiębiorstwami 109. Outsourcing nie posiada jedynie wymiaru ekonomicznego (ograniczanie kosztów zatrudnienia, inwestycyjnych, realizacji usługi itp). Jest także cennym źródłem innowacji, wpływa na koncentrację działań organizacji ściśle związanych z jej celami,zwiększa dostęp do wiedzy. Model chmury obliczeniowej jest ściśle związany z tą tendencją. Realizacja procesów biznesowych w chmurach potencjalnie redukuje zaangażowanie w zarządzanie infrastrukturą IT. Największy wpływ na atrakcyjność modelu chmury obliczeniowej z punktu widzenia zarządzania infrastrukturą IT ma niewątpliwie wirtualizacja. W części poświęconej zagadnieniu wirtualizacji wymieniliśmy następujące korzyści.: konsolidacja środowisk produkcyjnych; ujednolicenie i standaryzacja platform; ułatwienie i przyśpieszenie migracji, replikacji i automatyzacji środowisk; redukcja personelu IT; uproszczenie procesów wsparcia użytkowników oraz ułatwienie zadań szkoleniowych. 109 Pierścionek Z. (2011), Zarządzanie strategiczne w przedsiębiorstwie, op. cit., s

92 Oczywiście na korzyści te znacząco wpływa model usługowy. Im bowiem niższa będzie warstwa modelu usługowego, tym korzyści te będą większe. Oznacza to, że stopień wirtualizacji, zarówno od strony kondensacji i konsolidacji środowiska, jak też od strony modelu usługowego (IaaS, PaaS, SaaS) wpływa znacząco na zarządzanie infrastrukturą IT. Należy także nadmienić, że na omawiany tu czynnik wpływa także model upowszechniania chmury obliczeniowej. Procesy wirtualizacji można realizować w celu niwelowania rozproszenia systemowego. Jednak rozproszenie funkcjonalne związane z różnorodnością procesów i ich powiązaniami warunkuje wybór modelu upowszechniania chmur. Niejednokrotnie zdarza się bowiem, że przyjęcie jednego tylko modelu upowszechniania jest niemożliwe. Stosowanie zatem jednego typu chmur (np.: chmury prywatnej) znacząco podnosi korzyści związane z zarządzaniem infrastrukturą IT. Bezpośrednią konsekwencją wirtualizacji jest zjawisko określane mianem multitenancy. Termin ten określa możliwość stosowania jednej instancji aplikacji dla wielu użytkowników. Poza wspomnianymi korzyściami takimi jak migracja, replikacja i standaryzacja, obsługa wielu użytkowników za pomocą jednej instancji ma także wpływ na zarządzanie strukturą przepływu informacji w organizacji. Standaryzacja uwarunkowana technicznie (dzięki wirtualizacji) nie tylko wpływa na usprawnienie implementacji środowisk informatycznych i zarządzanie nimi, ale także na sam proces przetwarzania informacji. Okazuje się, że ujednolicenie platform redukuje ilość możliwych kanałów przepływu informacji i zwiększa jej efektywność. Przyśpiesza to także procesy podejmowania decyzji w oparciu o ujednolicane kanały przepływu oraz homogeniczność funkcjonalną np.: dwie równolegle działające aplikacje BI implementowane niezależnie w dwóch różnych działach mogą dostarczać niespójne informacje. Stosowanie zatem ujednoliconych form redukuje redundancję i niespójność źródeł informacji. Multitenancy odpowiada zatem nie tylko usprawnianiu zarządzania infrastrukturą IT, ale także zarządzaniu na poziomie całej organizacji, a ściślej zarządzaniu przepływem informacji i procesów podejmowania decyzji. Aplikacje. W trzech podstawowych modelach upowszechniania zasoby określane są jako abstrakcyjne jednostki. Na poziomie usług SaaS funkcje te pełnią aplikacje. Aplikacje model kliencki. Przenoszenie danych do przetwarzania w stronę zaplecza infrastruktury IT wiąże się, jak widzieliśmy, z tendencją krystalizowania się technologii systemów rozproszonych. Technologie chmur obliczeniowych uwidaczniają nie tylko tę tendencję, ale znaczący fakt przedstawiający stopień wykorzystania zasobów 92

93 obliczeniowych. Fakt ten dotyczy nie tylko znikomego wykorzystania mocy serwerów, ale co może mniej podkreślane, samych zasobów po stronie użytkowników. Na podstawie przywoływanych statystyk można wysnuć przypuszczenie, że stacje robocze użytkowników nie wykorzystują w pełni swoich zasobów obliczeniowych, zwłaszcza, że zaznacza się obecnie koncentracja przetwarzania po stronie zaplecza IT (centra danych, chmury, gridy itp.). Pewnym przejawem tego zjawiska był rozwój platform ASP pod koniec lat 90-tych ubiegłego wieku. W rozwiązaniach oferowanych przez te platformy zasoby strony klienckiej mogą być redukowane do absolutnego minimum, a część rozwiązań klienckich określana jest mianem cienkiego klienta (ang. thin-client). Coraz częściej wymagania sprzętowe są określane przez systemy operacyjne. Paradoksalnie w wielu przypadkach to te wymagania doprowadzają do ewolucji i przemian infrastruktury. Ma to także oczywiste konsekwencje ekonomiczne. Wiąże się to choćby z zapewnieniem względnej kompatybilności sprzętu z oprogramowaniem systemowym czyli cyklicznymi inwestycjami związanymi z infrastrukturą kliencką. Aplikacje przeglądarka jako platforma. Chmury obliczeniowe w warstwie aplikacyjnej (SaaS) przeobrażają środowisko pracy użytkowników końcowych. Dzieje się tak za sprawą sposobu dostarczania aplikacji, która można już rzec, uruchamiana jest w swoistej platformie. Prowadzi to do nowego spojrzenia na platformę systemową oraz na możliwości wykorzystania infrastruktury IT, a ściślej jej żywotności. Oprogramowanie rezydujące po stronie zaplecza infrastruktury IT, redukując ilość zadań przetwarzanych po stronie klienckiej zapewnia możliwość dłuższego jej wykorzystania, co wiąże się bezsprzecznie z nakładami ponoszonymi na utrzymanie infrastruktury. Aplikacje - funkcjonalna zwięzłość. Z uwagi na proces rozwoju oprogramowania model SaaS w obecnych zastosowaniach oferuje coś, co by można nazwać funkcjonalną zwięzłością. Określić ją możemy jako względnie efektywną realizację związku obsługiwanego procesu z funkcją lub funkcjami aplikacji110. Rozwiązania dostarczane w chmurach obliczeniowych są szansą na spełnianie założeń tego postulatu. Technologie zapewniające działanie różnych modeli usług umożliwiają bardziej elastyczne podejście do tworzenia aplikacji, które być może w przyszłości w prostszy sposób będą mogły podlegać procesom ich komponowania. 110 Jest to szerokie zagadnienie i wykracza ono poza ramy niniejszej rozprawy. Ogólne jednak założenia tego postulatu wychodzą naprzeciw praktykom projektowania aplikacji oraz systemów informatycznych. Problem ten dotyczy także możliwości realizacji tego postulatu w rozwiązaniach gotowych, gdzie elastyczność w doborze pożądanych funkcji jest z reguły ograniczona. W wymiarze ilościowym postulat zwięzłości funkcjonalnej wymaga choćby założenia o przyporządkowaniu jak najmniejszej ilości funkcji do jak największej ilości procesów. 93

94 Na rynku konsumenckim wiąże się to także ze zjawiskiem realizacji wielu zadań przy użyciu niewielkich aplikacji, które w efektywny sposób zapewniają jedynie pożądane funkcje. Jeżeli proces ten zaobserwowalibyśmy w środowiskach produkcyjnych infrastruktury IT w organizacjach, możliwą konsekwencją byłyby procesy rozszczepiania złożonych aplikacji lub ich szybsze tworzenie. Tradycyjny model dostarczania aplikacji oparty na gotowym zestawie funkcji utrudnia zastosowanie zasady zwięzłości funkcjonalnej. Co więcej, oprogramowanie dostarczane jako gotowe rozwiązanie wyklucza niejednokrotnie zastosowanie zasady ekologii funkcjonalności. Za ekologię funkcjonalności uznamy świadome realizowanie postulatu zwięzłości funkcjonalnej. Oznacza to, że organizacje w sposób ścisły odnoszą się do związku między procesami, a funkcjami i redukują funkcje redundantne w systemach informacyjnych, co niewątpliwie utrudniają rozwiązania gotowe. Organizacje coraz częściej wyznaczają precyzyjne miary oceny wykorzystania zasobów informatycznych. Zauważyliśmy, że dzieje się tak w modelach utility computing. Podaliśmy także szczególny i teoretyczny przypadek konieczności oceny wartości zasobów obliczeniowych w chmurze prywatnej. Powstaje jednak pytanie: czy istnieje przełożenie stosowania ekologii funkcjonalności na sprawność podejmowanych decyzji? To pytanie w tym miejscu ma charakter otwarty. Jednak odpowiedź na nie uwzględnia już miar ekonomicznych, ale także organizacyjne. Wiążą się z tym inne pytania: czy złożoność narzędzia przyspiesza podejmowanie decyzji? Na ile ograniczenie funkcji narzędzi jedynie do związanych z nimi procesów usprawnia podejmowane decyzje? W końcu, jak bardzo funkcjonalność może wykraczać poza wymagane w narzędziach funkcje? Są to niewątpliwie pytania powiązane z postulatem ekologii funkcjonalności. Bez względu na ich rozstrzygnięcie, modele chmur obliczeniowych oraz stosowane technologie tworzenia i udostępniania aplikacji otwierają perspektywę dla ugruntowania założeń ekologii funkcjonalności. Zwięzłość funkcjonalna jest bezsprzecznie powiązana jest ze złożonością procesu. Co więcej, im większa złożoność funkcjonalna, tym trudniejszy proces adaptacji. Napotykamy tu na problem możliwości ułatwienia adaptacji111. Z punktu widzenia zarządzania procesami, a ścisłej zarządzania zmianą procesów, model SaaS nie wymaga stałego monitorowania zamian. Okazuje się bowiem, że to dostawcy monitorują sposoby użytkowania aplikacji i sami wprowadzają nowe funkcje. Nie oznacza to jednak, że postulat zwięzłości funkcjonalnej jest zawsze w tym przypadku 111 Por. poniżej część Zagrożenia - Rozeznanie i adaptacja. 94

95 stosowany, ponieważ nowe funkcje oferowane przez dostawców niekoniecznie muszą odpowiadać faktycznym potrzebom usługobiorcy. Z drugiej strony to sami usługobiorcy mają wpływ na kształt używanych aplikacji, a sukces wielu dostawców zależy od tworzenia nowych funkcji, na które jest faktyczne zapotrzebowanie112. Pamiętajmy jednak, zasada zachowania trzonu funkcjonalnego przez dostawców musi być zachowana, bez niej bowiem trudno byłoby wykorzystywać efekty skali w chmurach obliczeniowych. Aplikacje Typy aplikacji. Model chmury obliczeniowej przyczynił się do powstawania nowych rodzajów aplikacji takich jak interaktywne aplikacje mobilne, które działają w oparciu o kontekst lokalizacyjny. Kolejnym przykładem może być równoległe przetwarzanie wsadowe (ang. parallel batch processing), które odbywać się może na tysiącach serwerów. Otwarty charakter aplikacji i środowisk na pewno uatrakcyjnia aplikacje analityki biznesowej, które integrowane mogą być ogromnymi zestawami danych113. Ogólne wytyczne dla możliwych zastosowań aplikacji udostępnianych w chmurach obliczeniowych oraz ich wzorce znajdujemy w opracowaniu Mateosa114: istnieją pewne typy funkcjonujących w organizacji aplikacji, których przeniesienie do chmury obliczeniowej nie wiąże się ze znaczącą ingerencją w ich podstawy programistyczne. Przy przenoszeniu aplikacji należy uwzględnić ewentualne podobieństwo infrastruktury, jeśli działanie aplikacji opiera się na specyfice lokalnego centrum danych. Jeśli bowiem aplikacja będzie podlegać istotnym modyfikacjom, a infrastruktura dostawcy nie będzie mogła być przystosowana do wymagań aplikacji, jej wdrożenie w chmurze z oczywistych powodów nie powiedzie się; z punktu widzenia aplikacji za skalę internetową możemy uznać ilość potencjalnych użytkowników. Jeśli potencjalny rozwój przedsięwzięcia może przybrać na dynamice, warto rozważyć utworzenie aplikacji w modelu chmury obliczeniowej. Skala internetowa powiązana jest zatem z kwestią skalowalności środowiska. Jednak decyzja dotycząca rozwoju aplikacji przystosowanej do działania w chmurach obliczeniowych wiąże się bezpośrednio z ścisłymi celami organizacji. Okazuje się, że sama potencjalność rozwoju przedsięwzięć nie 112 Dubbey A., Wangle D. (2007), Delivering software as a service, McKinsey Quarterly, s Por. rozdział 5 analityka Big Data. 114 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

96 koniecznie zakładać musi skalę internetową. Nie oznacza to jednak, że aplikacje funkcjonujące w ramach chmur obliczeniowych muszą podlegać efektom skali internetowej. Niemniej jednak owe założenia dotyczące rozwoju do takiej skali w istotny sposób motywują tworzenie oprogramowania i usług w modelach chmur obliczeniowych. istnieje pewna klasa oprogramowania oraz zastosowań, które wykazują sporadyczne ale znaczące zapotrzebowanie na moc obliczeniową. Owa sporadyczność, wyklucza decyzje o inwestycji we własną infrastrukturę. Ten typ aplikacji jawnie ukazuje ekonomiczny wymiar funkcjonowania aplikacji w chmurach obliczeniowych; jeśli aplikacje wykorzystują dane, które przyrastają wykładniczo, ich wdrożenie w chmurze może znacząco obniżyć koszty zarządzania repozytoriami danych. O ile bowiem przestrzeń pamięci masowych jest stosunkowo tania, o tyle właśnie zarządzanie infrastrukturą stanowi znaczący koszt utrzymania dużych repozytoriów danych. Warto przy tym zaznaczyć, że dane powinny być w takim przypadku przetwarzane po stronie chmury, gdyż ich przenoszenie na potrzeby obliczeń do lokalnego centrum danych może być nieefektywne; zasadniczo najczęstszym wzorcem zastosowania aplikacji w chmurze jest ich niestrategiczny charakter. Do takich aplikacji można choćby zaliczyć rozwiązania umożliwiające tworzenie kopii zapasowych. Z reguły dostawcy specjalizujący się w archiwizacji danych posiadają dużo większe kompetencje oraz wysoką specjalizację. Dotyczy to jednak nie tylko archiwizacji, ale także innych relegowanych zadań podmiotom zewnętrznym. Aplikacje FLOSS (ang. Free/Libre Open Source Software) i licencjonowanie. Firmy oferujące tradycyjne oprogramowanie osiągają przychody w oparciu o instancje aplikacji uruchamianych na stacjach roboczych. Ten model biznesowy ulega przeobrażeniom w chmurach obliczeniowych. Dostawcy usług w chmurach obliczeniowych stosują różne modele cenowe, które przybliżymy w części poświęconej uwarunkowaniom ekonomicznym chmur obliczeniowych. Jednak to dynamiczny rozwój modeli biznesowych opartych na otwartym źródle przyczynia się do zmiany formy licencjonowania rozwiązań tradycyjnych. Innymi słowy, swoista ekonomiczna konkurencyjność rozwiązań opensource i wolnego oprogramowania zmienia struktury licencjonowania rozwiązań komercyjnych Por. Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s

97 Skalowalność. Zgodnie z założeniami chmur obliczeniowych ich fundamentalną cechą jest stosowanie efektów skali. Efekty skali związane z modelem chmur obliczeniowych należy kojarzyć zarówno z dostawcami, jak i usługobiorcami. Z punktu widzenia dostawcy efekty skali dotyczą tworzenia i utrzymywania infrastruktury, która podlega względnej uniformizacji (między innymi dzięki technologiom wirtualizacji). Efekty skali stosowane przez dostawców umożliwiają także negocjację warunków nabywania sprzętu i oprogramowania. Dla usługobiorców jedną z najistotniejszych przemian w sposobie przetwarzania danych w środowiskach chmur obliczeniowych wyraża się w czterech następujących aspektach zaistnienia efektów skali: zróżnicowane zapotrzebowanie zasobów istnieją klasy zastosowań oraz usług, których wymagania dotyczące zasobów przetwarzających zmieniają się w czasie. Opisaliśmy to jako jeden z wyznaczników dla możliwych aplikacji stosowanych w chmurach obliczeniowych. Specyficzne procesy biznesowe lub charakter działalności organizacji mogą wymagać szczytowego zapotrzebowania na zasoby przetwarzające jedynie kilka dni w miesiącu, co prowadzi do niewykorzystania zasobów własnego centrum danych w pozostałym czasie. W takich przypadkach większe uzasadnienie ekonomiczne ma korzystanie z usług oferowanych w chmurach obliczeniowych, nawet jeśli jednostkowe koszty dzierżawienia maszyn i usług dostawcy, kalkulowane na podstawie czasu ich wykorzystania (np.: koszt wykorzystania serwera przez godzinę) są wyższe, aniżeli w przypadku własnej infrastruktury. Elastyczność w alokowaniu zasobów jeszcze bardziej sprzyja sytuacjom, w których działalność organizacji dodatkowo podlega wahaniom sezonowym; nierozpoznane potrzeby rozwój wielu przedsięwzięć może być nieprzewidywalny. Ma to miejsce w przypadku nowo powstających firm i organizacji. Nieprzewidywalność i nagłe zapotrzebowanie zasobów w tradycyjnym modelu wiązałyby się z natychmiastową potrzebą powiększania własnej infrastruktury; elastyczność alokowania zasobów oprócz nierozpoznanych potrzeb w chmurach obliczeniowych można stosować zasadę wymienności kosztów, gdy potrzeby są rozpoznawalne. Dotyczy to między innymi czasowych obliczeń wsadowych, w których zachodzi proste przełożenie: dzięki zlecaniu obliczeń o dużej skali mogą 97

98 one być wykonane o wiele szybciej (używanie 1000 maszyn w chmurze równa się wykorzystaniu jednej maszyny przez tysiąc godzin); rozwój i adaptacja systemów elastyczność alokowania zasobów nie wiąże się jedynie z zasobami przetwarzania informacji, bowiem efekty skali mają zastosowanie nie tylko na poziomie zasobów obliczeniowych, ale także na płaszczyźnie systemowej. Świadectwem tego może być choćby stosowanie aplikacji typu mashup. Z racji unifikacji środowiska dodawanie kolejnych komponentów systemowych i aplikacyjnych bezpośrednio odnosi się do możliwych efektów skali. Bezpieczeństwo. W analizach chmur obliczeniowych wiele uwagi poświęca się zagrożeniom płynącym z zastosowania tego modelu. Nie inaczej będzie w przypadku niniejszej analizy (por. poniżej analiza zagrożeń). Jednak korzystanie z chmur obliczeniowych przynosi korzyści związane z bezpieczeństwem. W raporcie organizacji ENISA (European Network and Information Security Agency) znajdujemy następujące korzyści płynące z zastosowania chmur obliczeniowych116: korzyści skali korzyści skali wpływają bezpośrednio na koszty wszelkich ocen i strategii bezpieczeństwa; korzyści te odnoszą się do takich elementów i działań jak: filtrowanie, ochrona i zabezpieczanie maszyn wirtualnych, redundancja sprzętu i oprogramowania, silne uwierzytelnianie, efektywna kontrola roli użytkowników, ulepszone zarządzanie bezpieczeństwem relacji między partnerami; ze skali usług płyną także tak kluczowe korzyści jak skrócony czas reakcji na nadużycia. Dostawcy są w stanie rozwijać bardziej efektywne i wydajne usługi reakcji na takie zdarzenia; dostawcy są w stanie zatrudniać wysokiej klasy specjalistów od bezpieczeństwa, co nie zawsze jest możliwe przy utrzymywaniu własnej infrastruktury; standaryzacja zarządzania bezpieczeństwem dostawcy usług w chmurach obliczeniowych mogą oferować standaryzowane interfejsy do zarządzania 116 ENISA (2009), Cloud Computing Security Risk Assessment, ENISA, s

99 bezpieczeństwem, co otwiera możliwości do zmiany dostawców przez usługobiorców; szybkie i inteligentne skalowanie zasobów dostawcy są w stanie szybko relokować zasoby takie jak filtrowanie, kształtowanie ruchu czy szyfrowanie w celu przeciwdziałania zagrożeniom (np.: odpowiadając na ataki typu DDoS); audyt i informatyka śledcza Technologie wirtualizacji umożliwiają tworzenie kopii maszyn wirtualnych. Dzięki temu w trakcie działania systemu, jego kopia może być równolegle audytowana i sprawdzana przy pomocy narzędzi informatyki śledczej. Co więcej, analizy takie mogą być przyśpieszone poprzez tworzenie wielu takich kopii; efektywne aktualizacje stosowanie technologii wirtualizacji ułatwia proces przygotowywania platformy systemowej pod kątem bezpieczeństwa. Obrazy systemów operacyjnych zawierać mogą najświeższe aktualizacje przygotowywane w relatywnie krótkim czasie. Na płaszczyźnie modeli PaaS i SaaS oznacza to większe bezpieczeństwo dla aplikacji funkcjonujących poza obszarem serwisowych określają korporacyjnym; lepsze zarządzanie ryzykiem warunki umów niejednokrotnie kary związane z naruszaniem bezpieczeństwa i brakiem koniecznych zabezpieczeń. Wymusza to stosowanie przemyślanej i atrakcyjnej dla usługobiorców polityki bezpieczeństwa; koncentracja pomimo kluczowej charakterystyki chmur obliczeniowych jaką jest rozproszenie, w modelu tym dochodzi do zjawiska koncentracji. Oznacza to, że pomimo cech systemu rozproszonego model ten zapewnia względnie unifikowaną postać zasobów, wszelkie zatem procesy zarządzania są ułatwione. Potwierdza to, jak widzieliśmy powyżej, stosowanie technologii wirtualizacji. Koncentracja zasobów niesie za sobą także pewne ryzyko (np.: dostęp do większej ilości danych), jednak zaistnienie koncentracji umożliwia prostsze wprowadzanie spójnej polityki bezpieczeństwa oraz polityki, określającej kontrolę dostępu do danych, procedur aktualizacji oprogramowania czy zarządzania incydentami. Słabe strony. Analiza słabych stron opiera się na uwzględnieniu czynników determinujących funkcjonowanie modelu chmury obliczeniowej, które ograniczają rozwój tego modelu lub blokują decyzję o jego zastosowaniu. Zaznaczmy od razu, że czynniki te 99

100 są ściśle powiązane z samą charakterystyką chmur, nie zaś z uwarunkowaniami ich otoczenia, za które uznać możemy regulacje, standardy, nastawienia organizacyjne itp. Do czynników słabych stron zaliczymy: aplikacje, problemy funkcjonowania danych, bezpieczeństwo oraz dostępność. Aplikacje. O ile w przypadku mocnych stron wyróżniliśmy wzorce aplikacji, które sprzyjają zastosowaniom chmur obliczeniowych, o tyle pewne rodzaje aplikacji nie mogą być z powodzeniem wdrażane w środowiskach chmur. Mateos wyróżnia trzy rodzaje tak rozumianych aplikacji117: aplikacje historyczne typowe środowiska chmur obliczeniowych cechuje względne podobieństwo platform sprzętowych i programistycznych. Z reguły środowiska te działają w oparciu o takie systemy operacyjne jak Linux i Windows. Organizacje, szczególnie te o długiej historii wciąż mogą korzystać z aplikacji tworzonych pod kątem innych systemów operacyjnych (np.: HP-UX lub VMS). Z reguły aplikacje takie nazywa się aplikacjami zastanymi o długiej historii. Z naturalnych powodów przenoszenie takich aplikacji do chmur wiązałoby się ich dostosowaniem do platform programistycznych dostawców usług w chmurach. Oczywiście pociąga to za sobą znaczące nakłady na rozwój aplikacji oraz znaczny czas ich przeprojektowania. Jeżeli czas życia aplikacji historycznych (np.: z powodu zmian w infrastrukturze) dobiega końca, warto przeprojektować je do postaci odpowiadającej wymaganiom technicznym chmur obliczeniowych; aplikacje z krytycznymi scenariuszami czasu rzeczywistego jedną z wskazanych powyżej zalet chmur obliczeniowych jest udostępnianie zasobów na żądanie, w szczególności aplikacjom o dużych wymaganiach mocy obliczeniowej. Istnieje pewne niebezpieczeństwo, że zasoby dostawcy okażą się niedostępne (por. poniżej problemy dostępności). Takie zdarzenia, choć stosunkowo rzadkie, mogą mieć jednak miejsce. Pewna grupa aplikacji wymaga absolutnej, tj. 100% dostępności zasobów przetwarzania. Do takich aplikacji zaliczyć można choćby aplikacje do analizy medycznej czasu rzeczywistego, gdzie niedostępność usługi bądź kanałów komunikacji może mieć krytyczne znaczenie dla podtrzymania życia. Zdecydowana większość zastosowań dla przedsięwzięć biznesowych nie posiada tak krytycznych uwarunkowań. Dotyczy to zwłaszcza rozwiązań SaaS 117 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

101 wspierających niestrategiczne obszary działalności. Co więcej, wiele umów dostarczania usług przewiduje wysoki stopień dostępności; aplikacje z dostępem do poufnych danych aplikacje obsługujące dane o klauzulach poufności nie zawsze mogą być uruchamiane w modelach chmur obliczeniowych, a zwłaszcza w chmurach publicznych. Firmy administrujące pewnymi typami danych mogą być zobligowane do przestrzegania norm i reguł ich ochrony. Ma to miejsce choćby w przypadku danych służby zdrowia, poufnych danych obywateli czy innych danych zawierających inne poufne informacje. Problemy funkcjonowania danych. Zarządzanie danymi, ich ochrona oraz położenie mają kluczowe znaczenie dla realizowania celów organizacji. W tradycyjnym modelu przetwarzania danych to organizacja odpowiada za zarządzanie nimi. Jednak model chmury obliczeniowej pociąga za sobą niebezpieczeństwa płynące z samych uwarunkowań technicznych rozwiązań oferowanych w tym modelu. W charakterystyce tego czynnika odnosić się będziemy zatem do istotowych cech chmur obliczeniowych, takich jak skalowalność, przenoszalność i lokowanie danych czy też problemy modelowania. W przetwarzaniu informacji ma miejsce istotne sprzężenie informacji z możliwościami jej przetwarzania. Choć dominuje przekonanie, że zdecydowana większość operacji przetwarzania danych będzie miała miejsce po stronie centrów danych, przywołany wcześniej przykład przemian w modelu utility computing pokazuje, że taka tendencja nie koniecznie musi mieć miejsce w przyszłości. Foster wysuwa hipotezę, że przyszłość przetwarzania internetowego, u którego progu obecnie stoimy, będzie koncentrować się nie tylko na scentralizowanej formie przetwarzania po stronie chmur obliczeniowych. W przetwarzaniu internetowym zachodzić będzie bowiem istotny związek między przetwarzaniem klienckim, przetwarzaniem w chmurach oraz danymi (rys. 8)118. Rysunek 8. Relacja przetwarzania w chmurze i przetwarzania klienckiego. Źródło: Foster I. et al. (2008), Cloud Computing and Grid Computing 360-Degree Compared w GCE '08 In 2008 Grid Computing Environments Workshop, s Foster I. et al. (2008), Cloud Computing and Grid Computing, op. cit., s

102 W triadzie tej dochodzi do komunikacji między klientami, a chmurami. Jednak zarządzanie danymi tj. ich mapowanie, partycjonowanie, zapytywanie o nie, przenoszenie, przechowywanie i buforowanie, replikacja itp. odniesione musi być do dwóch pozostałych elementów triady. Dzieje się tak z prostej przyczyny. Otóż, o ile znamy już zalety przetwarzania danych w chmurach, o tyle z reguły nie docenia się przetwarzania klienckiego: niektóre zastosowania wykluczają przenoszenie danych, które muszą być przetwarzane lokalnie; w przypadku braku komunikacji lub braku dostępności zasobów chmury, z reguły zadania wciąż muszą być wykonywane; rozwój technologii stosowanych w procesorach może w przyszłości przekształcić dowolną jednostkę kliencką w osobisty superkomputer z procesorami o setkach lub tysiącach rdzeni; istnieje wiele rodzajów obliczeń, które wykonywane są na poziomie sprzętowym, a które wykonywane są po stronie klienckiej; zaliczyć do nich można choćby wizualizacje lub przetwarzanie multimediów. Nie przesądzając o kierunku ewolucji oraz proporcji przetwarzania danych w układzie klient-chmura, a co za tym idzie o określeniu jaki rodzaj informacji będzie przetwarzany po której stronie, pewna część danych będzie mogła być przetwarzana po stronie chmur. Jak okazuje się, nie bez ograniczeń: modelowanie i integracja danych społeczności skupione wokół systemów gridowych, już na wczesnym etapie funkcjonowania tego typu systemów rozproszonych, zdały sobie sprawę ze znaczenia właściwego zarządzania danymi i opracowywały pojęcie i technologie wirtualnych danych. W technologiach tych określa się relacje między danymi, programami i obliczeniami. Zapewnia to dostęp do aktualnie wymaganych danych, możliwości przetwarzania ich w zdefiniowanych lokalizacjach oraz tworzenie abstrakcyjnych reprezentacji danych. O ile takie podejście jest kluczowe dla funkcjonowania gridów, które cechuje silna heterogeniczność i rozproszenie, o tyle usługi oferowane w chmurach obliczeniowych z reguły opierają się o jednorodną i unikalną strukturę platformy. Poza oczywistymi zagrożeniami wiążącymi się z tak postrzeganą unikalnością, organizacje napotykają na problem adaptacji własnego modelu danych do modelu 102

103 danych określonego prze dostawcę, co niejednokrotnie uniemożliwia zastosowanie atrakcyjnych usług przetwarzania danych np.: usług analitycznych wykorzystujących dane usługodawców; nieokreślona lokalizacja danych wiele organizacji wykazuje obawę o utratę kontroli nad fizyczną lokalizacją danych. Wiąże się to ściśle z naturą przetwarzania danych w chmurach obliczeniowych. Niektórzy dostawcy oferują jednak usługi, które powiązane są z geograficzną lokalizacją lub wydzielają wirtualne chmury prywatne. Ścisłe przypisanie oferowanych zasobów do lokalizacji geograficznej może być między innymi podyktowane spełnieniem koniecznych regulacji prawnych; ograniczenia transferu danych wraz z globalną ekspansją danych aplikacjom stawia się coraz większe wymagania ich przetwarzania. Istotnym problemem staje się przenoszenie danych. Nie tylko ze względów technicznych, ale także ekonomicznych119. Oczywiście szacować można, że koszty transferu danych będą spadać, ale powstaje pytanie, czy będą spadać proporcjonalnie do wzrostu wolumenów danych. Bezpieczeństwo. Kwestia bezpieczeństwa rozpościera się niemalże na całą analizę SWOT przeprowadzaną w tym miejscu rozprawy. Omówiliśmy korzyści związane z bezpieczeństwem z perspektywy wewnętrznej charakterystyki chmur obliczeniowych. Jednak kluczowe cechy determinujące chmury obliczeniowe rodzą wiele obaw co do bezpieczeństwa. Zdecydowana większość wątpliwości rodzi się w świetle problemów natury technicznej, a ściśle uwarunkowań technicznych chmur obliczeniowych. Jak zauważyliśmy wcześniej, z technicznego punktu widzenia usługi dostarczane w chmurach obliczeniowych opierają się w głównej mierze na technologiach wirtualizacji. Oczywiście im niższy poziom abstrakcji oferowanej usługi, tym bardziej bezpieczeństwo odgrywa kluczową rolę. Co więcej, z poziomem abstrakcji wiąże się także relegacja odpowiedzialności na użytkowników. Innymi słowy, przy niższym poziome abstrakcji oferowanych usług i zasobów, większa odpowiedzialność spoczywa na usługobiorcach. Armburst zauważa, że wirtualizacja jest głównym gwarantem bezpieczeństwa w chmurach120. Ogranicza ona próby wzajemnego ataku użytkowników lub ataki skierowane przeciwko infrastrukturze chmur. Jednak technologie wirtualizacji narażone są na błędy, 119 Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s Ibid., s

104 które mogą naruszyć bezpieczeństwo. Dotyczy to w głównej mierze systemów operacyjnych. Niepoprawnie konfigurowana wirtualizacja sieci może przyczynić się do niepożądanego dostępu do zasobów lokalizowanych w chmurach. Te uwarunkowania mają także zastosowanie w przypadkach prywatnych centrów danych. Pamiętajmy jednak, że z naturalnych powodów pełna kontrola usługobiorców nad bezpieczeństwem zasobów w chmurach publicznych jest niemożliwa121. Wirtualizacja wiąże się z opisywanym zjawiskiem równoległego dostępu (multitenancy). Wielu użytkowników ma dostęp do tej samej pamięci masowej lub sieci, które są przez nich dzielone. Główne zagrożenie wiąże się tu z błędami w mechanizmach separacji zasobów. Naturalnie ilość użytkowników mających dostęp do tych samych współdzielonych zasobów potęguje to zagrożenie. Do głównych problemów bezpieczeństwa rozpatrywanego z punktu widzenia słabych stron należy zaliczyć: naruszenie interfejsu zarządzania obsługa i zarządzanie usługami oraz ich elementami n się z koniecznością dostępu do paneli administracyjnych. Niewątpliwie zwiększa to ryzyko naruszenia bezpieczeństwa. Możliwymi przyczynami mogą tu być niepoprawna konfiguracja, błędy systemów operacyjnych lub błędy aplikacji; problemy transferu danych jako systemy rozproszone chmury obliczeniowe wymagają intensywniejszego przemieszczania się danych. Odnosi się to nie tylko do danych będących źródłem podejmowania decyzji, ale także, co rzadziej podkreślane, także danych formujących infrastrukturę. W wielu bowiem przypadkach właściwe funkcjonowanie chmur obliczeniowych wymaga synchronizacji obrazów maszyn lub ich migrację i dystrybucję. Właśnie dlatego naruszenie bezpieczeństwa transmisji danych stanowi poważne zagrożenie zarówno dla dostawców, jak i usługobiorców. Zdecydowana większość rozwiązań w prywatnych centrach danych uwzględnia tworzenie bezpiecznych kanałów transferu (np. tunele VPN), jednak taka praktyka nie zawsze stosowana jest w chmurach obliczeniowych122; niedefinitywne usunięcie danych niepewność lokalizacji danych ma swój dodatkowy wymiar. Problem ten ukazaliśmy z punktu widzenia geograficznej lokalizacji danych. Jednak ich status oraz lokalizacja mogą stać się o wiele 121 Por. poniżej część Zagrożenia -Zmiany w zarządzaniu. 122 ENISA (2009), Cloud Computing Security Risk Assessment, op. cit., s

105 bardziej problematyczne w takich przypadkach jak zmiana organizacyjna dostawcy, obniżenie ilości udostępnianych zasobów, relokacja infrastruktury sprzętowej itp. Problem ten dotyczy nie tyle bezpieczeństwa samych danych, ile realizacji ich kompletnego usunięcia. Żądanie usunięcia danych nie zawsze wiąże się z ich fizycznym usunięciem. Określone wymogi polityki bezpieczeństwa mogą z góry narzucić określoną praktykę usuwania danych, która wymagać może specjalnych procedur w chmurach obliczeniowych. Problem ten ma mniejszy wydźwięk w chwili, gdy przechowywane dane są szyfrowane. Wciąż jednak polityka bezpieczeństwa może narzucić ich kompletne usunięcie. Dostępność. Dzierżawienie usług w chmurach obwarowane jest umowami o poziomie świadczonych usług (ang. Service Level Agreement SLA). SLA jest koniecznym warunkiem przeniesienia usługi do chmury obliczeniowej. Określa między innymi poziom kontroli nad zadaniami realizowanymi w obrębie dotychczasowej infrastruktury organizacji. Umowy te określają poziom usług, do których zobowiązani są dostawcy. Z reguły zawierają metryki, które są podstawą do ewentualnych roszczeń z tytułu niespełnienia zapisanego w umowie poziomu usługi. SLA zwierają różne wyznaczniki poziomu usług, jednak w zdecydowanej większości, zawierają klauzule o dostępności usługi. Z reguły naruszenie poziomu dostępności usługi wynagradzane jest w postaci przyszłych, jasno określonych zniżek za oferowane usługi. Dostępność mierzona jest w jednostkach czasu korzystania z usługi, a dostawcy oferują niejednokrotnie specjalistyczne narzędzia do monitorowania dostępności dzierżawionych systemów i usług. Należy przy tym zauważyć, że wszelkie roszczenia wynikające z naruszenia SLA muszą być poparte odpowiednimi wnioskami składanymi przez usługobiorcę wraz z opisami zaistniałych incydentów. Rzecz jasna naruszenie ciągłości działania usługi może mieć krytyczne konsekwencje dla działania organizacji. Rzadkością jednak jest zapewnienie w SLA nieprzerwanej dostępności. Większość umów zakłada pewien margines niedostępności, co jak widzieliśmy powyżej wyklucza zastosowanie niektórych aplikacji w chmurach obliczeniowych. Niedostępność zasobów i usług może wynikać z poniższych czynników: niepoprawne wyliczenia koniecznych zasobów dostawcy oferując usługi na żądanie, wymogi dotyczące posiadania koniecznej infrastruktury opierają na 105

106 podstawie prognoz statystycznych wykorzystywania zasobów. Błędne zastosowanie algorytmów alokacji przyszłych zasobów oraz modelowania ich wykorzystania prowadzi do możliwych sytuacji niedostępności usług; nieprzewidywalność wydajności według badań przeprowadzonych przez Armbursta i jego współpracowników wirtualne maszyny stosunkowo dobrze dzielą zasoby obliczeniowe i pamięć. Jednak bardzo często problemy niedostępności wiążą się ze współdzieleniem sieci i pamięci masowych. Zaleca on ulepszanie architektur i systemów operacyjnych, tak aby lepiej wykorzystywały obsługę kanałów przerwań i operacji wejścia/wyjścia. Pamiętajmy, że problemy te zostały pokonane między innymi w latach 80-tych ubiegłego wieku w przypadku mainframe'ów firmy IBM. Inną metodą na minimalizowanie ryzyka wystąpienia tych problemów może być choćby stosowanie pamięci flash, które oferują szybszy dostęp, niż tradycyjne dyski, wykorzystując przy tym mniej energii; błędy wielkoskalowych systemów rozproszonych problemy występujące w systemach o dużej skali niejednokrotnie jest trudniej rozwiązywać, aniżeli w systemach o mniejszej skali. Wynika to często z niemożności odtworzenia problemu występującego w systemach o dużej skali w środowisku systemu o mniejszej skali. Szanse. O ile w przypadku analizy mocnych i słabych stron uwzględnialiśmy czynniki bezpośrednio związane z charakterystyką modelu chmury obliczeniowej, uznając je za czynniki istotowe, o tyle w analizie szans pod uwagę będziemy brali kontekst i otoczenie badanego modelu. W przypadku analizy szans wybrane elementy kontekstu będą miały pozytywny wpływ na rozwój, możliwości oraz skalę zastosowań chmur obliczeniowych. Do elementów kontekstu, stymulujących rozwój modelu chmur obliczeniowych możemy zaliczyć: zjawisko Green IT, bezpieczeństwo, uwarunkowania rynkowe oraz innowacje. Green IT jest praktyką mającą w ścisłym znaczeniu redukować zużycie zasobów naturalnych. Jest to zatem praktyka ekologii. Pomimo sloganowego wyrazu, zjawisko Green IT ma poważny wpływ nie tylko na możliwości zastosowania chmur obliczeniowych, ale także na środowisko naturalne. Niektórzy analitycy szacują, że znacząca część serwerów (15%) w typowych firmach pozostaje w stanie bezczynności. Oznacza to, że około jedna-szósta wszystkich zasilanych maszyn nie wykonuje żadnych 106

107 zadań. W ujęciu globalnym z 44 milionów działających serwerów około 5 milionów serwerów nie wykonuje użytecznych zadań. Według 1E Company i Alliance to Save Energy (ASE) wyłączenie tych serwerów pociągałoby za sobą oszczędności rzędu 3.8 mld $, podczas gdy sam koszt tych serwerów szacuje się na 27,7 mld $. Oprócz znaczących kosztów tak potężny zbiór urządzeń pobierających energię prowadzi do uwolnienia 11.8 milionów ton dwutlenku węgla co odpowiada wydzielaniu tej substancji przez 2.1 milionów samochodów123. Są to niezaprzeczalnie fakty o naturze środowiskowej. Jedno z podstawowych zadań decydentów IT w tym kontekście polegałoby na identyfikacji niewykorzystywanych lub nie w pełni wykorzystywanych serwerów. Na ekologiczne uwarunkowania chmur obliczeniowych wpływa wielkość centrum danych. Wbrew intuicjom, największe centra danych posiadają najniższe współczynniki wydajności energetycznej PUE (ang. Power Usage Effectiveness). Współczynnik ten określa wydajność centrum danych i jest stosunkiem energii dostarczanej do centrum danych do energii niezbędnej do działania infrastruktury obliczeniowej działającej wewnątrz centrum. Uptime Institute szacuje, że dla typowego centrum danych wskaźnik ten wynosi około 2,5124. Stosunek ten pokazuje, że z każdych 2,5 watów dostarczanych do centrum danych, tylko jeden wat wykorzystywany jest do faktycznych obliczeń. Instytut ten szacuje także, że większość centrów danych stosując najnowsze technologie sprzętowe i właściwe praktyki, mogłaby osiągnąć wyniki rzędu 1,6 PUE. Obecnie najkorzystniejszą wartość czynnika szacowaną na około 1,125 PUE osiągają jedynie największe centra danych na świecie. Jest to zatem kolejny przykład zastosowania efektów i ekonomii skali. Jeżeli przyjmiemy, że zarówno stacje robocze, jak i infrastruktura zaplecza IT opierają się głównej mierze na tradycyjnym przetwarzaniu, to wiąże się to bezsprzecznie z efektywnością wykorzystania energii zasilającej te systemy. I tak, przyjmując szacunkowo 5%-15% wykorzystanie mocy obliczeniowej danego systemu, w chwili gdy inny system przetwarzać będzie informacje systemów o niepełnym wykorzystaniu zasobów, możemy osiągnąć znaczące korzyści związane z wykorzystaniem energii (kilka systemów wykorzystujących w niewielkim stopniu swoje zasoby, wciąż musi być zasilana energią, a relegacja zadań w stronę jednego systemu podniesie efektywność wykorzystania energii elektrycznej). W celu ograniczania zużycia energii inżynierowie tworzący rozwiązania sprzętowe dla centrów danych wprowadzają mechanizmy optymalizujące dopływ prądu, wentylatory z 123 Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing, op. cit., s Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

108 zastosowaniem zmiennej prędkości czy też zmieniają architekturę płyt głównych ograniczając ilość niezbędnych komponentów (np.: stosuje się płyty główne pozbawione kart graficznych). Oprócz tworzenia efektywnych aplikacji, które uwzględniają relacje między wydajnością, a zarządzaniem energią i technologii obniżania zużycia energii przez zasoby sprzętowe takiej jak procesory, pamięci masowe i urządzenia sieciowe istotny wpływ na zjawisko Green IT mają technologie wirtualizacji125. Oczywiście wirtualizacja jest głównym czynnikiem determinującym funkcjonowanie środowisk chmur obliczeniowych, ale zależność tę można odwrócić, zadając pytanie: jakie czynniki zewnętrzne wpływają na stosowanie wirtualizacji w tym kontekście? W badaniu przeprowadzonym w USA, Australii i Nowej Zelandii menedżerowie IT wykazywali ogólnie pozytywne nastawienie ku zjawisku Green IT. Zdecydowana większość za czynniki stymulujące podejmowanie działań w kierunku realizacji założeń Green IT uznała: redukcję kosztów IT, strategię korporacyjną, założenia środowiskowe, akceptację społeczną, dojrzałość rynku rozwiązań Green IT, regulacje prawne i inicjatywy rządowe oraz naciski ze strony klientów126. Oczywiście nie wszystkie inicjatywy Green IT wykorzystują technologie właściwe dla modelu chmury obliczeniowej. Niemniej jednak wszystkie te czynniki można uznać za zewnętrzne w stosunku to modelu chmury obliczeniowej, warunkując jej zastosowanie. Zjawisko Green IT jest w pewnym sensie powiązane z ekologią funkcjonalności. Jej założenia odnoszą się do kreowania systemów pozbawionych zbędnych funkcji. Minimalizacja funkcji sprzyja wypracowywaniu wydajnych algorytmów przetwarzania informacji. Można bowiem założyć, że im większa złożoność informacji (pociąga to za sobą także złożoność funkcjonalną), a nie koniecznie jej ilość, tym trudniejsze są do wykonania procesy optymalizacji. Jeżeli zatem postulaty ekologii funkcjonalności będą w miarę możliwości realizowane, istnieje szansa tworzenia systemów bardziej wydajnych, a ich powszechne stosowanie może przyczynić się do bardziej efektywnego korzystania z zasobów obliczeniowych, a co za tym idzie zasobów energetycznych. Bezpieczeństwo. W poprzednich częściach analizy (mocne i słabe strony) przyglądaliśmy się kwestii wpływu czynników determinujących model chmury 125 Bose R., Luo X. (2011), Integrative framework for assessing firms' potential to undertake Green IT initiatives via virtualization - A theoretical perspective,journal of Strategic Information Systems 20, s Molla A., Copper V., Pittayachawan S. (2009), IT and Eco-sustainability: Developing and Validating a Green IT Readiness Model, International Conference on Information Systems, Association for Information Systems, Phoenix, s

109 obliczeniowej na bezpieczeństwo działań w nich podejmowanych. Z punktu widzenia szans istnieją pewne czynniki zewnętrzne wpływające na zwiększanie bezpieczeństwa w chmurach np.: regulacje prawne mogą wymuszać okresowe audyty zewnętrzne i wewnętrzne, co przyczynia się do wzrostu zaufania ze strony usługobiorców. Oprócz samych regulacji prawnych i standardów, które w ścisły sposób określają działania dostawców usług, bezpieczeństwo może być kryterium określającym przewagę konkurencyjną tych ostatnich. Jako że bezpieczeństwo jest jednym z głównych kryteriów wyboru usługi, dostawcy mogą traktować bezpieczeństwo jako element wyróżniający ich na tle konkurencji. Decyzje o wyborze dostawcy nie koniecznie zależą od kryteriów ekonomicznych lub funkcjonalnych. Zresztą kryterium ekonomiczne, choć istotne w odniesieniu do tradycyjnego modelu przetwarzania informacji w organizacjach, z racji samych uwarunkowań efektów skali nie stanowi z reguły elementu przewagi konkurencyjnej osiąganej przez dostawców. Usługobiorcy niejednokrotnie zainteresowani są dobrą reputacją dostawców, którą ci ostatni osiągają odnosząc się do zasad poufności, integralności i umiejętności reakcji na zagrożenia, stosując przy tym różnorodne dodatkowe usługi podnoszące poziom bezpieczeństwa, nieobecne w tradycyjnych środowiskach. Rynek. Internet bez wątpienia przyczynił się do intensyfikacji relacji zachodzących na rynkach oraz w gospodarce. Rynki cechują wzmożone relacje B2B (business to business), B2C (business to consumer), G2C (government to consumer) lub C2C (consumer to consumer). Model chmury obliczeniowej znosi silne uwarunkowania rozproszenia możliwych relacji, prowadząc do ich względnej koncentracji (np.: w obrębie chmur obliczeniowych zorientowanych na usługi świadczone w konkretnej branży). Sprzyjają temu nie tylko protokoły używane w internecie, ale przede wszystkim inicjatywy mające na celu tworzenie standaryzacji technicznych uwarunkowań chmur obliczeniowych. Jednak w obecnym etapie rozwoju rozważanego modelu przeważają głosy o braku pożądanych regulacji. Na przestrzeni ostatnich 10-ciu lat doszło do istotnych przemian w sposobach tworzenia nowych przedsięwzięć gospodarczych. Od czasów początków Internetu powstał nowych ich rodzaj nazywany start-up. Jest to rodzaj firmy, która może bardzo elastycznie zmieniać się w zależności od zapotrzebowania rynku. Przy czym istotna jest dynamika i prędkość alokowania zasobów w zależności od wymagań klientów lub partnerów. W tradycyjnym 109

110 modelu biznesowym dochodzi do innych założeń ekonomicznych oraz działań inwestycyjnych. O ile bowiem w przypadku tradycyjnych firm kluczową rolę odgrywa finansowanie własnej infrastruktury i dopasowywanie jej do potrzeb, o tyle w przypadku startupów ten model nie musi mieć zastosowania. Oznacza to, że projektując usługę lub produkt, firmy typu startup nie muszą polegać na aktywnych inwestycjach w infrastrukturę, gdyż ta może być w zależności od potrzeb dynamicznie alokowana przez dostawców chmur. Właśnie dlatego szybkość reakcji na zmieniające się zapotrzebowania związane z zasobami niezbędnymi do sprzedaży produktów lub świadczenia usług jest nieporównywalnie większa, aniżeli w przypadku firm tradycyjnych. Tę zasadniczą różnicę w podejściu do ponoszenia kosztów (rozróżnienie OPEX/CAPEX) omawiać będziemy szerzej w części poświęconej uwarunkowaniom ekonomicznym chmur obliczeniowych. Co więcej, z uwagi na znaczącą relegację zadań związanych z zarządzaniem infrastrukturą startupy mogą skoncentrować swoją uwagę na projektowaniu produktów i usług oraz ich rozwoju. Istotnie, większość startupów to niewielkie firmy tworzące niejednokrotnie produkty technologiczne, które w znacząco krótkim okresie mogą odnieść niespodziewany sukces. Zatem zdolność do błyskawicznej odpowiedzi na żądania klientów jest dla tych firm kluczowa. Możliwość swobodnego rozwoju wielu firm, który jeszcze kilkanaście lat temu nie byłby możliwy bez wsparcia inwestorów, wpływa na rozwój konkurencyjności. Nowe przedsięwzięcia wykorzystujące potencjał chmur obliczeniowych nie muszą polegać na zewnętrznych inwestycjach. Chmury obliczeniowe mogą być zatem odpowiedzią na potrzeby gospodarcze oraz biznesowe i w istotny sposób mogą przyczynić się do stymulacji przedsiębiorczości. Ta ostatnia ma choćby znaczenie w krajach rozwijających się, gdzie bariera techniczna i inwestycyjna jest w wielu przypadkach nie do pokonania. Jednym z głównych beneficjentów rozwiązań oferowanych w chmurach obliczeniowych mogą być Chiny, gdzie stale rośnie zainteresowanie technologiami wirtualizacji i usługami SaaS127. Innowacje otwartość. Nowy model biznesowy współczesnych przedsięwzięć mogący w aktywny sposób wykorzystywać ekonomiczne zalety modelu chmur obliczeniowych wpływa na rozwój przedsiębiorczości. Jak widzieliśmy powyżej, chmury obliczeniowe jako podstawa infrastruktury firmy znoszą możliwe bariery wejścia na rynek, w 127 Gartner (2012), Gartner Says High Growth in IT Spending in China Will Fuel Adoption of New Technologies in 2012 and Beyond, Gartner Inc., 110

111 szczególności dla niewielkich firm technologicznych. Niewątpliwie sprzyja to rozwojowi innowacyjności. Jednym z aspektów technicznych funkcjonowania chmur obliczeniowych jest zastosowanie rozwiązań typu FLOSS (Free Libre/Open Source Software). Realizacja postulatów FLOSS przyczynia się do rozwoju chmur obliczeniowych. Bariera wejścia nie dotyczy jedynie usługobiorców, ale także usługodawców. Otóż w zależności od modelu upowszechniania (PaaS, SaaS) rozwiązania FLOSS mogą stanowić ważny element dostarczanych usług, a modele licencjonowania tych rozwiązań znoszą niejednokrotnie opłaty za korzystanie z oprogramowania. Sami producenci i projektanci rozwiązań oprogramowania tego typu, które są podstawą dla infrastruktury i usług dostarczanych przez usługodawców, osiągają korzyści ekonomiczne w odmiennych, aniżeli tradycyjne modelach biznesowych i czerpią zyski głównie ze wsparcia technicznego lub dodatkowych płatnych funkcji128. Zasadniczo jednak, dostawcy usług w chmurach obliczeniowych nie korzystając z dodatkowych usług oferowanych przez producentów i projektantów oprogramowania FLOSS, są w stanie zapewnić sobie niemalże darmową warstwę oprogramowania. Inna konsekwencja stosowania rozwiązań typu FLOSS ma charakter czysto techniczny. Otwartość kodu oraz możliwość względnie elastycznego jego stosowania zdecydowanie rozszerza potencjał innowacyjności. Innymi słowy, projektanci usług i platform mają dużo większą swobodę w chwili, gdy korzystają z rozwiązań opartych na otwartym lub udostępnionym źródle. Innowacje aplikacje mash-up. Najbliższy okres przyniesie intensywny rozwój aplikacji typu mashup. W najprostszym ujęciu aplikacja typu mashup to strona lub aplikacja, która wykorzystuje dane bądź funkcjonalność dwóch lub więcej zewnętrznych źródeł w celu stworzenia nowej usługi 129. Oferowane za pomocą API komponenty mogą być łączone. W ten sposób mogą powstawać aplikacje, których zastosowanie nie było przewidziane przez właścicieli danych. Mateos przewiduje, że nie tylko mashupy przyczynią się do dynamicznego rozwoju chmur obliczeniowych, ale i same chmury rozwiną możliwości mashupów. Chmura obliczeniowa zdaje się być idealnym środowiskiem, gdzie aplikacje tego typu mogą być najefektywniej tworzone. Potencjalnie każdy typ danych może mieć swoje własne API. Właśnie dlatego firmy posiadające repozytoria z cennymi danymi mogą je udostępniać innym usługodawcom. 128 Por. Riehle D. (2010), The Single-Vendor Commercial Open Source Business Model,Information Systems and e-business Management. 129 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s

112 Właściciele danych mogą dzięki takim rozwiązaniom czerpać korzyści ekonomiczne. Możemy sobie wyobrazić aplikacje, które wykorzystują dane finansowe wraz z koniecznością weryfikacji klientów lub aplikacje, które wykorzystują mapy i bazy danych produktów. Najczęściej podawanym przykładem aplikacji typu mashup jest usługa wiążąca ze sobą dane lokalizacyjne np.: dane z jednej usługi (adres) mogą być powiązane z informacją o położeniu geograficznym (mapa). Oczywiście jest to dziś powszechnie stosowany typ powiązania. Niemniej jednak spełnia podstawowe założenia tworzenia mashupów. Oczywiście katalizatorem dla rozwoju chmur obliczeniowych jest nie tylko sama charakterystyka aplikacji typu mashup, ale także zrozumienie potencjału wartości posiadanych danych. W chwili, gdy dane posiadać będą realną wartość rynkową, potencjalny usługodawca musi stworzyć odpowiedni interfejs. Obecnie aplikacje mashup tworzone są przez programistów, jednak decydującym krokiem będzie udostępnienie rozwiązań, które umożliwią komponowanie usług przez użytkowników końcowych. Programiści będą tworzyć specjalne platformy, które przyśpieszą proces tworzenia aplikacji. Co więcej, zapewnią one elastyczność funkcjonalną, która będzie mogła być dostosowywana do zmieniających się lub powstających potrzeb i nowych procesów. Dotyczy to nie tylko dostawców komercyjnych, ale także konkretnych organizacji, które tworzyć mogą w ten sposób aplikacje na swoje potrzeby, wychodząc naprzeciw zasadzie ekologii funkcjonalności, de facto tworząc rozwiązania dedykowane w dowolnych modelach upowszechniania chmury obliczeniowej. Innowacje długi ogon. Wraz z rozwojem Internetu obserwujemy zjawisko długiego ogona (ang. long tail). Termin ten wprowadził C. Anderson. Anderson uważa, że współczesny rynek i kultura są coraz mniej zainteresowane usługami i produktami, które przynależą do mainstreamu. Usługi i produkty z głównego nurtu lokalizowane są na szczycie krzywej popytu. Główna strategia i modele biznesowe opierały się dotychczas na niezróżnicowanym podejściu do klientów. Ci ostatni są coraz częściej zainteresowani nabywaniem produktów i usług silnie dopasowanych do ich potrzeb lub inaczej silnie spersonalizowanych. Teoria długiego ogona głosi, że z ekonomicznego punktu widzenia elektroniczne kanały dostarczania usług i produktów zrównują rozwiązania mainstreamowe z niszowymi. Dostawcy usług mogą koncentrować się na znajdowaniu wąskich grup odbiorców i dopasowywać swoje rozwiązania i produkty do ich unikalnych potrzeb. Jest to istotna tendencja rynkowa i kulturowa. Dostępność rozwiązań opartych na komponentach i otwartych źródłach sprzyja rozwojowi tej tendencji. Nie chodzi zatem 112

113 jedynie o możliwości przełamania bariery wejścia na rynek, tak jak to ma miejsce w przypadku startupów, ale także o konieczność znajdowania nisz rynkowych, co wymaga korzystania niejednokrotnie z różnorodnego zestawu usług oferujących aplikacje, dostęp do danych i platform. Większa potrzeba tworzenia unikalnych rozwiązań przyczyni się niewątpliwie do wzrostu różnorodności usług świadczonych w modelach chmur obliczeniowych. Zagrożenia. Zagrożenia dla różnych osób czy organizacji najczęściej powiązane są z czynnikami zewnętrznymi. Nie inaczej jest w przypadku chmur obliczeniowych. Do czynników tych zaliczymy: efekty zmian w zarządzaniu, dostępność, uwarunkowania rynku pracy, rozeznanie, kwestie prawne, problem zamknięcia oraz zagrożenia związane z bezpieczeństwem. Zmiany w zarządzaniu. Omawiając charakterystykę bezpieczeństwa w obszarze słabych stron, natknęliśmy się na problem kontroli mechanizmów bezpieczeństwa stosowanych przez usługodawców za strony usługobiorców. Jest to szczególny przypadek ogólniejszego problemu, a mianowicie kwestii zmian w zarządzaniu, koniecznych przy zastosowaniu modelu chmury obliczeniowej. Zmiany te dotyczą utraty kontroli oraz ogólnej polityki IT organizacji. Użytkowanie chmur obliczeniowych bezsprzecznie wiąże się z relegacją wielu zadań realizowanych dotychczasowo w obrębie własnej infrastruktury IT. Zmienia się wiele zastanych zadań i procedur, które mogą wpłynąć na strategię i efektywność działań organizacji. Na zmiany te mogą wpłynąć między innymi130: niejasne role i obowiązki zarówno usługobiorców jak i usługodawców; słabe możliwości wymuszenia określonych ról; nieefektywna synchronizacja odpowiedzialności lub zobowiązań stron zewnętrznych w stosunku do usługodawcy; sprzeczne zapisy w SLA dotyczące różnych stron kontraktów; niedostępność pewnych form audytu lub certyfikacji (por. nieobecność standardów); aplikacje tworzone przy użyciu zasobów wielu chmur (np.: mashup) ukrywają niekiedy zależności, a co za tym idzie granice odpowiedzialności; 130 ENISA (2009), Cloud Computing Security Risk Assessment, op. cit., s

114 brak kontroli nad procesami oceny zagrożeń; niejasny opis przynależności zasobów; Utrata kontroli może mieć istotny wpływ na niespełnienie wymogów bezpieczeństwa realizowanych dotychczas w ramach własnej infrastruktury oraz pociągać za sobą brak poufności, integralności i dostępności danych lub ograniczenie wydajności. Jak zauważyliśmy poprzednio, inicjatywy mające na celu zastosowanie chmur obliczeniowych w organizacji nie mogą być jedyne motywowane względami ekonomicznymi lub technicznymi. Raczej, należy uwzględnić przy takich inicjatywach całościową politykę zarządzania systemami informacyjnymi (SI). Wiąże się to z pokonaniem istotnych barier takich jak: stworzenie spójnej polityki systemów informacyjnych obejmującej wszelkich możliwych dostawców, czy też określenie procedur mających na celu realizowanie inicjatyw pochodzących ze strony konkretnych jednostek biznesowych. Chodzi tu między innymi o procesy niezależnego realizowania i wnioskowania subskrypcji usług przez departamenty lub inne jednostki biznesowe. Ponadto polityka SI powinna uwzględnić optymalny poziom ryzyka związany z korzystaniem z usług w obrębie chmur obliczeniowych, wyznaczenie procedur audytu i zbierania dowodów (działań kierowanych przeciwko danym i systemom, jak też niespełniania zasad zapisanych w kontraktach SLA) czy też wyróżnienie określonych regulacji, które muszą być spełniane, a co tym idzie stworzenie wzorców SLA. Powyższa lista ma jedynie charakter obrazujący potencjalne zadania konieczne do swoistej przemiany polityki IS i nie jest wyczerpująca. Stanowi to obecnie, jak pokazuje Marston jeden z postulowanych obszarów badawczych131. Niemniej jednak nie uwzględnianie powyższych postulatów może przyczyniać się do pogwałcenia kluczowych zasad polityki IT i do ograniczenia możliwości zastosowania chmur obliczeniowych w wielu organizacjach. Rynek pracy. Wiele statystyk potwierdza intuicyjny wgląd na temat wyższego stosunku liczby serwerów przypadających na administratora w środowisku wirtualizowanym, aniżeli w środowisku niewirtualizowanym132. Wielkości wskaźników ukazujących te proporcje zależą od stopnia zróżnicowania aplikacji, możliwości automatyzacji zadań itp. Bez wątpienia jednak liczba administratorów zarządzających serwerami i aplikacjami w 131 Marston S. et al. (2011), Cloud Computing - The Business Perspective, op. cit., s. 186, Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of Integrated Solutions, IDC. 114

115 środowiskach wirtualizowanych może być mniejsza niż w typowych środowiskach. Ten jawny obraz wpływa jednak na nastroje pracowników oraz ogólne uwarunkowania sytuacji rynku pracy. Planowane redukcje personelu mogą spotkać się z negatywną reakcją związków zawodowych lub organizacji rządowych, o ile w tym ostatnim przypadku pozwalają na to regulacje prawne. Okazuje się zatem, że korzyści ekonomiczne płynące ze stosowania wirtualizacji mogą mieć niekorzystny wpływ na kwestie zasobów ludzkich oraz strukturę organizacyjną, pociągając za sobą ograniczenia inicjatyw mających na celu wdrożenie rozwiązań oferowanych w modelach chmur obliczeniowych. Dostępność. Jednym z czynników przypisanych do słabych stron był problem dostępności. Wtedy to dostępność rozważaliśmy głównie z punktu widzenia uwarunkowań technicznych np.: nieprzewidywalność wydajności lub błędy wielkoskalowych systemów rozproszonych. Jednak na dostępność usług i zasobów wpływ mogą też mieć czynniki niebezpośrednio związane z charakterem chmury obliczeniowej. Dostępność - zaprzestanie świadczenia usług. Dostawców usług w modelu chmury obliczeniowej należy bez wątpienia uznać za podmioty rynkowe podlegające podobnym uwarunkowaniom, jak inne przedsiębiorstwa. Silna konkurencja, brak możliwości finansowania lub błędna stratega lub model biznesowy mogą przyczynić się do zaprzestania działalności lub zmiany jej profilu. Pociąga to za sobą możliwość zaprzestania świadczenia usług. Niedostępność usługi może wpływać na osłabienie pozycji rynkowej usługodawcy, utratę zaufania klientów czy też utratę zaufania pracowników. O możliwości braku dostępności klienci powinni być zatem informowani zawczasu, a właściwe kontrakty usługobiorców z klientami powinny zawierać klauzule o braku dostępności. Dostępność - problemy łańcucha dostaw. Wielu dostawców usług może przenosić część swoich obowiązków na strony trzecie. Niejednokrotnie ma to miejsce w przypadkach zadań o wysokiej specjalizacji. W przypadkach tworzenia łańcucha dostaw, wszelkie uwarunkowania techniczno-organizacyjne powinny być stosowane także przez strony trzecie. Instruktywnym przykładem niech będzie tu choćby kwestia bezpieczeństwa. Ponadto wszelkie formy braku dostępności ze strony stron trzecich skutkować mogą brakiem dostępności właściwego dostawcy. Dostawcy usług i strony trzecie powinny skutecznie synchronizować działania, aby przeciwdziałać niedostępności. Jeżeli na przykład elementy składowe usługi udostępniane przez stronę trzecią zmieniane będą bez uzgodnień z właściwym dostawcą lub przynajmniej nie będą sygnalizowane, to w 115

116 oczywisty sposób może zaburzyć to integralność usługi dostarczanej przez właściwego dostawcę. Kwestie prawne. Ograniczenia związane z regulacjami prawnymi są w wielu przypadkach istotnym elementem hamującym rozwój i zastosowanie chmur obliczeniowych w organizacjach. Nieuczciwe praktyki ze strony innych usługobiorców mogą prowadzić do utraty reputacji. Nie zawsze takie praktyki mają ścisłe konsekwencje prawne. Przykładem może tu być blokowanie publicznych adresów IT dostawcy, w chwili wykrycia pewnych nadużyć (np.: wysyłanie spamu). Sankcje w takich przypadkach mogą dotyczyć wielu usługobiorców. Nieuczciwa praktyka jednego usługobiorcy w takich przypadkach skutkuje poważnymi konsekwencjami jakie ciążą tym samym na innych usługobiorcach. Ponadto zdarza się, że dochodzenia prawne z ramienia instytucji rządowych i prawnych lub podmiotów cywilnych pociągają za sobą nakazy wydania urządzeń przechowujących dane, co prowadzi do narażenia na ryzyko ujawnienia danych podmiotów niepodlegających dochodzeniu. Wynika to z uwarunkowań technicznych takich jak wirtualizacja lub składowanie danych w współdzielonych przestrzeniach. Brak informacji o jurysdykcji może naruszyć podstawowe regulacje związane z przechowywaniem danych wrażliwych takich jak dane osobowe. Dane mogą być składowane w krajach o wysokim stopniu ryzyka ich ujawnienia. Właściwe regulacje dotyczące składowania danych wrażliwych znajdujemy choćby w dyrektywie 95/46/WE Parlamentu Europejskiego, gdzie zapisane zostały ścisłe odstępstwa od wymogu przechowywania danych osobowych poza granicami Unii Europejskiej. Umowy SLA mogą nie zawierać klauzul o odpowiedzialności z tytułu utraty danych lub niezapewnienia ciągłości działania. Jak widzieliśmy powyżej, z reguły takie zapisy regulują zmiany w sposobie naliczania opłat, jednak rzadko umowy SLA zawierają zapisy o odszkodowaniach za faktycznie poniesione szkody czy też za utracone korzyści. Ponadto umowy SLA powinny zawierać informacje o formach i procesach wsparcia, reakcjach na błędy w systemach i na awarie oraz klauzule dotyczące praktyk związanych z zabezpieczaniem danych oraz ich odzyskiwaniem i udostępnianiem po zakończeniu umowy. Niespełnienie któregokolwiek z powyższych warunków wpływa na podjęcie decyzji o korzystaniu z usług oferowanych w danej chmurze obliczeniowej. 116

117 Rozeznanie i adaptacja. Podobnie do innych zaawansowanych rozwiązań informatycznych usługi dostępne w modelach chmury obliczeniowej wymagają swoistej wiedzy i przygotowania, nie tylko technicznego, ale także organizacyjnego. W cytowanym już raporcie firmy Red Shift czytamy, że w ujęciu globalnym firmy wykazują potrzebę zapewniania sobie we własnym zakresie koniecznych kompetencji mających na celu integrację usług lokalizowanych w chmurach. Większości firm zależy na długoterminowych i strategicznych inwestycjach, co pociąga za sobą przekształcanie zastanej infrastruktury, a nie jej części. Raport pokazuje, że wśród ankietowanych firm, które używają obecnie technologii wykorzystywanych w chmurach 75% posiadała konieczną wiedzę do ich wykorzystywania, 16% nie posiadała takiej wiedzy, ale uważa za konieczne jej zdobycie, w końcu tylko 9% firm nie planuje zdobywać wiedzy dotyczącej chmur, pomimo iż używają usług z tego modelu. Co ciekawe, pomimo tych danych, 21% ankietowanych w Europie i 14% w USA nie było w stanie określić różnicy między chmurami obliczeniowymi, a SaaS. Kourik w swojej analizie możliwości zastosowania chmur obliczeniowych w średnich i małych przedsiębiorstwach potwierdza przypuszczenie, że firmy te bądź nie posiadają świadomości dostępnych usług bądź nie posiadają koniecznej wiedzy, co warunkowane jest między innymi ograniczonymi zasobami technicznymi133. Chmury obliczeniowe mogą wymagać nowego zestawu kompetencji, dlatego też wybór dostawcy powinien być podyktowany rozpoznaniem koniecznych umiejętności. Firmy powinny zatem określić, na ile możliwe jest wykorzystanie zastanych kompetencji bez konieczności posiłkowania się wsparciem technicznym, forami i grupami eksperckimi lub outsourcingiem. Dla wielu organizacji chmury obliczeniowe mogą być istotnym przełomem organizacyjnym, co sprzyjać może rozwojowi kadry IT oraz stosowanych praktyk. Jednak wybór rozwiązań opartych na modelu chmury obliczeniowej może spotkać się z oporem wielu departamentów IT. W przekonaniu wielu decydentów chmury mogą zagrozić korporacyjnej kulturze IT (np.: bezpieczeństwo danych, polityki audytu systemów itp.). Taki przypadek potwierdza konieczność tworzenia spójnej przemiany polityki systemów informacyjnych z punktu widzenia zastosowania chmur obliczeniowych. 133 Por. Kourik J. (2011), For small and medium size enterprises (SME) deliberating cloud computing: a proposed approach w Proceedings of the 5th European conference on European computing conference, World Scientific and Engineering Academy and Society (WSEAS), Stevens Point, Wisconsin, USA, s

118 Z punktu widzenia użytkowników usług chmury obliczeniowe stanowią także wyzwanie adaptacyjne. Dotyczy to nie tylko użytkowania samych aplikacji, ale także zdobycia koniecznej wiedzy umożliwiającej rekonfigurację i dostosowywanie usług do konkretnych potrzeb. Bez zapewnienia koniecznych szkoleń i wskazówek dotyczących funkcji aplikacji adaptacja do nowego środowiska może być jednym z głównych czynników blokujących decyzje o jego zastosowaniu. Bezpieczeństwo. Kwestia bezpieczeństwa rozciąga się na wszystkie obszary analizy SWOT, którą przeprowadzamy. W niniejszej części przyjrzymy się wpływowi niektórych czynników niezależnych od zasad modelu na bezpieczeństwo. Armburst twierdzi, że większość zagrożeń bezpieczeństwa w chmurach obliczeniowych można przyrównać do zagrożeń, które mogą wystąpić w typowych centrach danych 134. Jednak w przypadku chmur obliczeniowych odpowiedzialność jest dzielona między wiele stron. Zaliczyć do nich trzeba usługobiorców, dostawców i strony trzecie. Zależność ta miała częściowo miejsce przypadku problemu z ciągłością i synchronizacją łańcucha dostaw. Ochrona chmury przed zewnętrznymi zagrożeniami może być skuteczniejsza, aniżeli w przypadku typowych środowisk. Jednak chmury narażone są na nadużycia z tytułu nieprecyzyjnie określonych ról i ich egzekwowania. Powracamy tu zatem do kwestii zmian w sposobie zarządzania infrastrukturą. Przeniesienie kluczowych działań związanych z bezpieczeństwem na dostawców może wiązać się niekontrolowanymi nadużyciami ze strony ich pracowników. Problem ten określa się jako problem nadużycia przywilejów (ang. abuse of high privilege roles). Kolejny problem dotyczy zmian organizacyjnych i kapitałowych dostawców (np.: przejęcia i fuzje). Wiązać się to może nie tylko ze wzrostem ryzyka niedostępności, ale także poważnym naruszeniem zasad bezpieczeństwa. W niektórych przypadkach dochodzi do nieuzgodnionych zmian w polityce bezpieczeństwa oraz naruszenia dotychczasowych, akceptowanych przez usługodawców praktyk. Usługodawcy powinni uwzględniać takie scenariusze i mając to na uwadze, powinni stosować precyzyjne zapisy i klauzule w umowach SLA na okoliczność takich zdarzeń. O ile w przypadku zagrożeń technicznych wspomina się niejednokrotnie o takich atakach jak DDoS (ang. Distributed Denial of Service), które wynikają z samej architektury chmur obliczeniowych, o tyle praktycznie nie wspomina się o zagrożeniu, które ENISA określa jako EDoS (ang. Economic Denial of Service). Ta niepożądana 134 Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s

119 praktyka polega na świadomym i złośliwym wykorzystywaniu zasobów dostarczanych przez usługobiorcę. Ten typ zagrożenia ma charakter ściśle ekonomiczny. Istnieją trzy główne scenariusze, w których EdoS ma miejsce: kradzież tożsamości nieuprawniona osoba lub organizacja wykorzystuje zasoby usługobiorcy na swoje potrzeby lub w celu ograniczenia lub kompletnego wyczerpania możliwości ekonomicznych atakowanej organizacji, na przykład stosując fikcyjne obliczenia i obciążając finansowo faktycznego usługobiorcę; usługodawca nie posiada polityki efektywnego limitowania wykorzystania zasobów nawet przy wykorzystywaniu zasobów przez użytkowników usługobiorcy zgodnie z ich przeznaczeniem, przekroczenie pewnego pułapu ich wykorzystania może stanowić zagrożenie ekonomiczne dla usługobiorcy; atakujący może wykorzystać kanały publiczne (np.: poprzez zapytania HTTP) w celu przekroczenia puli usługobiorcy; Ataki te mają na celu obniżenie sprawności ekonomicznej usługobiorcy, a w skrajnych przypadkach mogą one prowadzić nawet do bankructwa. Problem zamknięcia. Jedna z ważnych obaw to nie tylko obawa o utratę kontroli, ale także troska o niemożliwość wycofania się ze świadczonych usług, a ściślej niemożliwość wycofania danych oraz ewentualnie wdrożonego w chmurze środowiska. Problem ten możemy nazwać jako kwestia zamknięcia (ang. lock-in). W obecnym stadium rozwoju modelu chmur obliczeniowych możliwości, narzędzia i procedury przenoszenia danych oraz usług pomiędzy dostawcami są niezwykle ograniczone. Mobilność zbiorów danych lub usług w wielu przypadkach nie jest w szeroko pojętym interesie dostawców. Zamknięcie klientów może być atrakcyjne choćby z ekonomicznego punktu widzenia. Dostawcy wykorzystując sytuację zamknięcia usługobiorcy, mogą podnosić ceny usług, oczywiście jeżeli umowy SLA nie są zbytnio restrykcyjne w tym względzie. Zamknięcie może być rozpatrywane w kontekście różnych modeli usług oferowanych w chmurach obliczeniowych. W zależności od oferowanego modelu sytuacja zamknięcia przedstawia się w innym świetle: zamknięcie SaaS Usługobiorcy niejednokrotnie muszą tworzyć specjalne wywołania, które pozwolą na eksport danych zlokalizowanych u macierzystego dostawcy, a które następnie mogą być importowane do środowiska innego 119

120 dostawcy. Inny problem dotyczy zamknięcia aplikacji. Problem ten nie jest specyficzny jedynie dla aplikacji dostępnych w chmurach obliczeniowych. Charakter aplikacji dostarczanych w modelu SaaS jest z reguły unikalny i dopasowany do docelowego rynku dostawcy. W przypadku dużej ilości użytkowników usługobiorcy zmiana dostawcy aplikacji pociąga za sobą wysokie koszty, gdyż zmiana ta w szczególny sposób dotyka interakcji użytkowników z aplikacją, co wiązać się może choćby z potrzebą powtórnych szkoleń. Ponadto, jeśli usługobiorca wykorzystuje interfejsy API dostawcy w celu bezpośredniej integracji aplikacji z chmury z aplikacjami z własnej infrastruktury IT, w chwili zmiany integracja może wymagać ponownego stworzenia powiązań między integrowanymi aplikacjami. zamknięcie PaaS wiele platform PaaS oferuje właściwe dla siebie interfejsy API oraz środowiska programistyczne, które mogą być niedostępne u innego dostawcy. Dostawcy w takich modelach dostarczają z reguły konkretne rozwiązania bazodanowe, które ściśle wiążą tworzoną aplikację i jej procedury z oferowanym typem bazy danych. Tak tworzony kod nie koniecznie musi być kompatybilny z usługami innych dostawców PaaS. zamknięcie IaaS typowo oprogramowanie hypervisorów oraz metadane maszyn wirtualnych są właściwe dla konkretnego dostawcy. Migracja między dostawcami bez użycia standardów(np.: takich jak OVF Open Virtualization Format) może być utrudniona. Główną strategią umożliwiającą łatwą migrację danych może być standaryzacja interfejsów API (np.: Data Liberation Front). Takie inicjatywy nie tylko zapewniłyby elastyczność i mobilność danych lub usług, ale także znacznie ułatwiłyby i uatrakcyjniły możliwości integracji z prywatnymi centrami danych. Początkowo można by sądzić, że nie sprzyja to interesom dostawców, ale możemy wyobrazić sobie sytuację, w której nieutrudniona integracja pomiędzy zasobami usługodawcy a platformą dostawcy może przynieść dodatkowe korzyści w postaci uruchamiania dodatkowych zadań w obrębie chmur obliczeniowych, w chwili, gdy prywatne centrum danych nie może ich realizować (np.: z przyczyn niewystarczalności posiadanych zasobów). Strategia ta ma między innymi zastosowanie w implementacjach open source własnościowych API. (Eucalyptus, Hypertable i inne). 120

121 4.5. Ekonomiczna, techniczna i organizacyjna analiza chmur obliczeniowych (analiza ETO) W niniejszej części spróbujemy podzielić czynniki wyróżnione w analizie SWOT na trzy podstawowe wymiary (obszary): ekonomiczny, techniczny i organizacyjny. Pamiętajmy przy tym, że niektóre czynniki będą mogły być zaklasyfikowane do więcej niż jednego z tych wymiarów. Po dokonaniu tego podziału naszym celem będzie wyznaczenie relacji między tymi wymiarami w odniesieniu do dokonanej analizy SWOT. Innymi słowy, analiza ETO ma charakter systematyzujący i pozwala na dostrzeżenie ważnych związków między opisywanymi powyżej czynnikami. Ponadto systematyzacja ta będzie punktem odniesienia dla oceny wpływu czynników na możliwość zastosowania chmur obliczeniowych przez organizacje o charakterze korporacyjnym lub niekorporacyjnym. Wymiar ekonomiczny. Ścisłe określenie wpływu danego czynnika na kondycję i zachowania ekonomiczne organizacji może być zadaniem trudnym do zrealizowania. W poniższej analizie wśród czynników o charakterze ekonomicznym wyróżnimy te, które mają bezpośredni wpływ na kondycję ekonomiczną organizacji, tj. wpływają na przykład na zwrot z nakładów inwestycyjnych, koszty lub przychody. Zaznaczmy przy tym, że ścisła granica pomiędzy wymiarami ma charakter umowny. Dla przykładu trudno jednoznacznie wyrokować, czy utrata reputacji przekłada się silniej niż zmiana organizacyjna na kondycję ekonomiczną. W tym konkretnym przypadku wydaje się jednak, że utratę reputacji można bezpośrednio powiązać na przykład ze spadkiem sprzedaży, a tym samym określić bezpośredni związek. Natomiast w przypadku zmian organizacyjnych koniecznych w celu zastosowania modelu chmury obliczeniowej znacznie trudniej o znalezienie bezpośredniej zależności o charakterze ekonomicznym. Wymiarowi ekonomicznemu chmur obliczeniowych poświęca się zazwyczaj w literaturze przedmiotu dużo miejsca135. Istotnie, przemiana modelu przetwarzania danych w chmurach obliczeniowych w stosunku do tradycyjnych środowisk IT ma charakter zasadniczy. Jednym z głównych argumentów wysuwanych w celu obrony modelu chmur obliczeniowych jest przykład zmian zachodzących w zarządzaniu kosztami: 135 Por. Talukder A. K., Zimmerman L., Prahalad H. A. (2010), Cloud Economics: Principles, Costs, and Benefits w Antonopoulos N., Gillam L., red., Cloud Computing: Principles, Systems, Applications, Springer, s ; Siwińska J. (2011), Ekonomiczna efektywność przetwarzania w chmurze,metody Informatyki Stosowanej 26(1), s ; Skilton M. (2010), Building Return on Investment from Cloud Computing,The Open Group; Strebel J., Stage A. (2010), An Economic Decision Model for Business Software Application Deployment on Hybrid Cloud Environments w MKWI IT Performance Management/ IT-Controlling. 121

122 Chociaż ekonomiczne zalety chmur obliczeniowych są często określane jako «zamiana wydatków kapitałowych na wydatki operacyjne» (CapEx na OpEx), uważamy, że wyrażenie «płacisz za to, z czego korzystasz» [ang. pay-as-you-go T.K.] lepiej oddaje istotę korzyści ekonomicznych dla kupującego 136. Sygnalizowaliśmy już ową przemianę w kontekście przemian w modelu klienckim, gdzie koncentracja zadań i przenoszenie ich w stronę zaplecza IT ogranicza inwestycje ponoszone na rzecz infrastruktury klienckiej. Wyrazem tego miał być, jak wspomnieliśmy, rozwój branży ASP, której modele cenowe (tj. modele cenowe dostawcy rozwiązania) odpowiadają modelom stosowanym obecnie przez dostawców SaaS, zaś sam sektor dostawców SaaS jest naturalnym rozwinięciem praktyk z początku wieku wśród dostawców ASP. Zasadnicza jednak korzyść ekonomiczna dotyczy nie tyle infrastruktury klienckiej, ale przede wszystkim infrastruktury zaplecza IT, gdyż inwestycje z nią związane znacznie przekraczają inwestycje w infrastrukturę kliencką. Model chmur obliczeniowych z założenia ma prowadzić do zmniejszenia kapitału wymaganego do realizacji i funkcjonowania środowisk IT. Dzięki przejściu na model OpEx, organizacje mogą minimalizować ryzyko inwestycyjne powiązane z zapewnieniem odpowiedniej infrastruktury, zwłaszcza w początkowym stadium rozwoju przedsięwzięć gospodarczych. Rozwiązania oferowane w chmurach obliczeniowych są zatem szansą dla nowych przedsięwzięć, które w przewidywalnym czasie mogą wymagać znaczących inwestycji w infrastrukturę. Tę zaletę wykorzystać mogą nowe firmy o perspektywie znacznego rozwoju Za przykład służyć tu mogą wspomniane przedsięwzięcia typu start-up. Kosztowe uwarunkowania chmur obliczeniowych sprzyjają także stymulacji zachowań rynkowych w krajach rozwijających. Zaś rozwiązania opensource coraz częściej stosowane w chmurach obliczeniowych są dodatkowym elementem stymulującym powstawanie nowych przedsięwzięć, które bez wspominanych rozwiązań borykałyby się z trudnościami natury ekonomicznej lub wręcz nie mogłyby zaistnieć. Mateos argumentuje, że model chmury obliczeniowej wbrew pierwszej intuicji nie koniecznie jest najatrakcyjniejszy ekonomicznie. Autor ten porównuje cztery modele tworzenia infrastruktury informatycznej: tradycyjną infrastrukturę wewnętrzną, kolokację, usługę zarządzaną oraz model chmury137. Okazuje się, że według szacunkowego 136 Armbrust M. et al. (2010), A view of cloud computing, op. cit., s Tradycyjna infrastruktura wewnętrzna model bez outsourcingu przy całkowitym zastosowaniu zasobów wewnętrznych; kolokacja w tym przypadku firma nadal dokonuje inwestycji we własny sprzęt, ale umieszcza się go w zewnętrznych centrach danych; usługa zarządzana dostawca 122

123 porównania kosztów tych modeli dla niewielkiej firmy internetowej najtańszymi rozwiązaniami są modele kolokacji i chmury obliczeniowej. Koszty im towarzyszące są znacznie niższe od pozostałych modeli. Niedostatek przeprowadzanych szacunków wynika jednak z pominięcia kosztów zarządzania systemami i aplikacjami tj. np.: redukcji kadry informatycznej czy też kosztów wsparcia i szkoleń użytkowników. Bez wątpienia ten aspekt zastosowania chmur obliczeniowych jest nie bez znaczenia ekonomicznego. O ekonomicznym powodzeniu wdrożenia decydować będzie także charakter aplikacji w konkretnym środowisku IT. Z punktu widzenia stosowanych aplikacji za korzystne ich typy uznaliśmy aplikacje o skali internetowej, stosowane sporadycznie, niestrategiczne oraz aplikacje o znacznym przyroście danych. Zastosowanie tego typu aplikacji jest ściśle powiązane z dynamiką zapotrzebowań na zasoby IT i właśnie dlatego w odniesieniu do aplikacji wdrażanych w tradycyjnych środowiskach jest atrakcyjniejsze z ekonomicznego punktu widzenia. Ponadto szczegółowe analizy porównawcze całkowitego kosztu utrzymania (TCO) aplikacji wypadają na korzyść aplikacji użytkowanych w modelach chmur obliczeniowych138. Natomiast za wątpliwe aplikacje uznaliśmy aplikacje historyczne, czasu rzeczywistego oraz aplikacje z dostępem do poufnych danych. Przy czym spośród tej ostatniej grupy najściślejszy (negatywny) związek z wymiarem ekonomicznym wykazują aplikacje historyczne. Powróćmy do modeli cenowych stosowanych w chmurach obliczeniowych. Z ekonomicznego punktu widzenia modele chmur obliczeniowych wprowadzają nową zasadę ponoszenia wydatków za wykorzystane zasoby. Przedstawić ją można za pomocą dwóch modeli: pay-as-you-go w przypadku modeli IaaS wnosi się opłaty za zarezerwowane instancje i z reguły ponoszone są one wstępnie. W przypadku niektórych dostawców rozwiązań PaaS i SaaS stosuje się modele subskrypcji i według Open Group zasadniczo odpowiada to np.: leasingowaniu tradycyjnego oprogramowania. Oznacza to, że z punktu widzenia przepływu gotówki faktyczne koszty związane z użytkowaniem oprogramowania w chmurze przyrównać można do modelu finansowania własnych aplikacji. wynajmuje sprzęt, zarządza nim oraz może zapewnić także podstawowe oprogramowanie (np.: bazy danych); model chmury obliczeniowej różni się od usługi zarządzanej tym, że nie dedykuje się w nim zasobów sprzętowych, a udostępnia wirtualne i przydziela się je w zależności od aktualnych potrzeb. 138 Por. rozdział 4 (Porównanie modelu SaaS z tradycyjnymi aplikacjami). 123

124 pay-as-you-drink zasada ta ściślej odnosi się do zasady korzystania z zasobów na żądanie. W usługach IaaS klienci płacą za moc obliczeniową lub instancje wykorzystywane np.: przez godzinę bez długoterminowych zobowiązań. Ten typ ponoszenia opłat powiązany może być z wykorzystywaniem transmisji danych w sieci, ilością wykonanych transakcji dostępu do przestrzeni pamięci masowej. Oczywiście ścisły podział pomiędzy tymi modelami nie zawsze jest możliwy. I tak, model subskrypcyjny uzależniony może być od z góry ustalonej ilości użytkowników wykorzystujących aplikację lub użytkowników faktycznie z niej korzystających. Opłaty mogą być naliczane w zależności od stosowanych funkcji. Ponadto stosuje się także różnorodne zobowiązania czasowe. Dla przykładu można zatem powiedzieć, że im krótszy czas zobowiązania, tym bardziej przybliżamy się do modelu pay-as-you-drink. Możliwość ponoszenia kosztów za wykorzystane zasoby uwalnia organizacje od ryzyka związanego z niedoszacowaniem lub przeszacowaniem zasobów koniecznych do realizowania zadań organizacji. Jedną z mocnych stron modeli chmur obliczeniowych jest elastyczność alokowania zasobów oraz powiązane z nią efekty skali. Odnosi się to nie tylko do aplikacji i systemów je przetwarzających, które mogą wymagać zróżnicowanych zasobów w czasie, ale także do samych użytkowników. Otóż modele cenowe chmur obliczeniowych umożliwiają względnie elastyczną zmianę warunków umowy dzierżawienia aplikacji. Dzięki temu skalowalność odnosi się nie tylko do warstwy systemowej. Możemy sobie wyobrazić sytuację, w której ilość narzędzi koniecznych do realizowania zadań zmieniać się będzie w czasie, np.: w chwili zmian organizacyjnych, zmian w procesach biznesowych lub w sytuacjach fluktuacji kadrowych (np.: konieczność tymczasowego zatrudnienia pracowników kontraktowych). W takich sytuacjach długoterminowe przywiązanie do konkretnych rozwiązań warstwy systemowej może okazać się nieefektywne ekonomicznie139. Skalowalność odnieśliśmy także do infrastruktury samej chmury, bowiem wraz z konsekwencjami efektów skali wiążą się konkretne korzyści powiązane w wydajnością centrów danych oraz zjawiskiem Green IT. Z ekonomicznego punktu widzenia skalowalność odnosi się także do rozwoju i adaptacji systemów. W środowiskach chmur obliczeniowych dochodzi do względnego znoszenia zjawisk rozproszenia. Osiągane jest to między innymi za sprawą unifikacji w warstwie systemowej, co ułatwia między innymi skalowanie systemu od strony funkcjonalnej. Unifikacja i standaryzacja znoszą istotne ograniczenia ekonomiczne. Można 139 W tradycyjnych środowiskach informatycznych reguły koszty licencji z reguły ponoszone są przy zakupie oprogramowania, nawet jeśli sposób finansowania eliminuje potrzebę realizowania inwestycji z góry. 124

125 wysnuć przypuszczenie, że skala rozproszenia i heterogeniczność potęgują od strony systemów informacyjnych problemy ekonomiczne. Pozytywny wydźwięk ekonomiczny mogą mieć niektóre składowe czynnika jakim jest bezpieczeństwo. Dotyczy to w głównej mierze możliwości korzyści skali płynących z zastosowania chmury obliczeniowej. Wpływają one bowiem na redukcję kosztów wszelkich ocen i strategii bezpieczeństwa, a także na podniesienie jakości zarządzania bezpieczeństwem, które będąc celem wielu organizacji wiązałaby się ze wzrostem kosztów. Według przywoływanego już raportu opracowanego przez firmę Red Shift Research 60% badanych globalnie firm dostrzega korzyść finansową płynącą ze stosowania rozwiązań oferowanych w modelu chmury obliczeniowej. Jednak z punktu widzenia zwrotu z nakładów inwestycyjnych (ROI) 40% firm osiąga wskaźnik ROI na poziomie 2150%, a 37% organizacji jest skłonna zastosować chmury obliczeniowe przy 100% zwrocie z nakładów inwestycyjnych140. Wyniki te pokazują, że na obecnym etapie decyzja dotycząca przejścia na model chmury obliczeniowej obarczona jest ryzykiem finansowym, pomimo wskazanych w tej części korzyści ekonomicznych. Jedną z możliwych przyczyn niskiego poziomu ROI może być brak stosowania metodologii jego wyliczania. Na fakt ten zwraca uwagę organizacja Open Group. Otóż prawie połowa badanych firm i organizacji uznała, że posiada trudności z określeniem ROI chmury obliczeniowej oraz uzasadnieniem jej funkcjonowania. O niskim poziomie zwrotu nakładów z inwestycji świadczyć mogą także obecne (wciąż wczesne) stadium rozwoju modelu chmury obliczeniowej oraz niewłaściwe dopasowanie wdrażanego rozwiązania do potrzeb biznesowych i powiązanych z nimi procesów. Ocena efektywności przeprowadzona może być nie tylko w ujęciu całościowym przedsięwzięcia, co sugeruje choćby raport Open Group141. Rimal sugeruje, że analizy stosowane powinny być także na poziomie użytkownika końcowego, co pozwoliłoby na dogłębną ocenę wykorzystania zasobów w chmurze obliczeniowej AMD (2011), Adoption, Approaches & Attitudes. The Future of Cloud Computing in the Public and Private Sectors,AMD, Open Group proponuje model ROI który uwzględnia dwa aspekty oceny: współczynniki KPI (ang. KPI ratios)- wskaźniki porównujące KPI docelowego rozwiązania w chmurze z konkretnymi metrykami tradycyjnego środowiska IT oraz modele usprawnienia ROI. Obydwa te aspekty są badane w przekrojach kosztu, czasu, jakości oraz zyskowności. Więcej w Skilton M. (2010), Building Return on Investment from Cloud Computing, The Open Group. 142 Rimal B. P. et al. (2011), Architectural Requirements for Cloud Computing Systems: An Enterprise Approach, Journal of Grid Computing No. 9, s

126 Oprócz wspomnianych problemów z oceną ROI oraz statystykami jego wielkości, niektóre czynniki przeprowadzanej analizy SWOT posiadają ujemną charakterystykę w wymiarze ekonomicznym. Niewątpliwie duże znaczenie ekonomiczne mają problemy związane z dostępnością usługi, którą opisywaliśmy zarówno z punktu widzenia technologii jak i w świetle ekonomiczno-organizacyjnym. Brak ciągłości działania, wynikający z między innymi z zaprzestania świadczenia usług dostawcy czy też ataków typu EDoS, może być istotnym kryterium ograniczającym decyzję o zastosowaniu usługi w chmurze obliczeniowej. Należy jednak przy tym zaznaczyć, że centra danych lokalizowane w chmurach zapewniają względnie wysoki poziom ciągłości działania, ograniczając tym samym ryzyko ekonomiczne związane z przestojami lub brakiem produktywności. Decyzje o zastosowaniu modelu chmury obliczeniowej uzależnione mogą być także od możliwości przystosowania istniejącego środowiska IT do środowiska chmur obliczeniowych. Dotyczy to takich przypadków jak aplikacje historyczne lub złożoność i czasochłonność procesu integracji lub migracji, a w jej kontekście także cyklicznych transferów danych do nowego środowiska (np.: konieczność przepływu danych pomiędzy infrastrukturą wewnętrzną a infrastrukturą publicznej chmury wiąże się z kosztami transmisji danych). Podkreślmy jednak, że kwestie te przedstawiać się mogą w odmiennym świetle w zależności od charakteru organizacji. W końcu negatywnie na kondycję ekonomiczną organizacji mogą wpływać czynniki powiązane z problemem zamknięcia (np.: zamknięcie przez dostawców lub zamknięcie aplikacji). Wymiar techniczny. Chmury obliczeniowe bez wątpienia stanowią zaawansowane rozwiązanie technologiczne. Z punktu widzenia rodzaju przetwarzania informacji przypisaliśmy je ściśle do systemów rozproszonych. Zarówno charakter rozproszenia, jak i złożoność techniczna mogą prowadzić do rozwoju zastosowań omawianego modelu, ale też charakter stosowanych technologii niejednokrotnie przyczynia się do odrzucenia możliwości zastosowania lub adaptacji. W niniejszej części spróbujemy wyróżnić te czynniki wymienione w analizie SWOT, które są uwarunkowane technicznie. W pracy S. Marstona czytamy: Chmura obliczeniowa reprezentuje zbieżność dwóch głównych trendów w technologiach informacyjnych (a) wydajność IT, gdzie moc współczesnych komputerów wykorzystywana jest dzięki wysoko-skalowalnym zasobom sprzętowym i oprogramowaniu oraz (b) sprawność biznesową, gdzie IT może być wykorzystywane jako narzędzie konkurencyjności dzięki szybkim wdrożeniom, przetwarzaniu 126

127 równoległemu, stosowaniu wydajnej analityki biznesowej czy interaktywnych aplikacji mobilnych, które odpowiadają wymaganiom użytkowników w czasie rzeczywistym 143. Obydwa te cele wymagają właściwego stosowania technologii, która nie może być celem samym w sobie. Innymi słowy, samo wykorzystanie zaawansowanej technologii, choć może być narzędziem zdobywania przewagi konkurencyjnej, niekoniecznie musi do niej prowadzić. Konieczne jest zatem zrozumienie, na ile technologia wykorzystywana w chmurach obliczeniowych może sprzyjać zarówno wydajności IT, jak i osiąganiu sprawności biznesowej. W tym kontekście jednym z najistotniejszych czynników jest zarządzanie infrastrukturą. Choć przynależy ono ściśle do obszaru organizacyjnego, to właśnie technologie chmury obliczeniowej wpływają na sprawność w zarządzaniu IT, a tym samym na samą sprawność biznesową. Jak widzieliśmy, jedną z głównych technologii stosowanych w chmurach obliczeniowych jest technologia wirtualizacji. Bezpośrednimi zaś jej konsekwencjami są ujednolicenie i standaryzacja, ułatwienie migracji platform i ich replikacja. Jeżeli sprawność biznesowa uzależniona będzie od czasu reakcji na zmiany w systemach IT, to bez wątpienia te czynniki mają znaczenie niebagatelne. Technologia wirtualizacji ma też istotny wpływ na tendencje w zakresie Green IT. Sprawność technologii wirtualizacji przyczynia się, jak zauważyliśmy do wzrostu wydajności PUE. Przykładem może tu być choćby stosowanie rozszerzeń systemowych wspierających funkcjonowanie procesorów dedykowanych do technologii wirtualizacji. W tym konkretnym przypadku dochodzi do sprzężenia zwrotnego: z jednej strony producenci procesorów projektują dedykowane jednostki obliczeniowe, z drugiej zaś twórcy oprogramowania do wirtualizacji dopasowują swoje rozwiązania do oferowanych procesorów. Od strony stosowanych aplikacji istotną zaletą jest utworzenie swoistej platformy klienckiej, którą realizuje się za pośrednictwem protokołów webowych. Prowadzi to do równoległej do zaplecza IT formy jednolitości. Tym samym upraszcza się zespolenie unifikowanego środowiska zaplecza IT ze środowiskiem klienckim opartym o platformę webową. Taka sytuacja w tradycyjnych środowiskach jest trudniejsza do uzyskania, choć ta zasada może być tam także odzwierciedlona. Zarówno zaplecze IT oraz środowiska klienckie korzystać mogą w modelu chmur obliczeniowych z różnych zalet rozwiązań typu FLOSS, do których zaliczyć należy ułatwienia wsparcia oprogramowania, szybszą obsługę błędów oraz mechanizmów 143 Marston S. et al. (2011), Cloud Computing - The Business Perspective, op. cit., s

128 bezpieczeństwa. Etos otwartości ugruntowany w tego typu rozwiązaniach w istotny sposób stymuluje także nowe inicjatywy gospodarcze zarówno ze strony dostawców, jak i usługobiorców, bowiem bez swobodnego dostępu do kodu źródłowego oprogramowania, takie inicjatywy w wielu przypadkach nie mogłyby się zrodzić. Do stymulacji zachowań rynkowych oraz rozwoju branży chmur obliczeniowych przyczyniają się także technologie typu mash-up, które zdecydowanie ułatwiają komponowanie nowych usług oraz sprzyjają innowacyjności. Zarysowana koncepcja ekologii funkcjonalności rozpatrywana w kontekście Green IT może przyczynić się do zwiększania wydajności systemów i jeszcze bardziej uatrakcyjniać model chmur obliczeniowych. Z punktu widzenia bezpieczeństwa relacja integracji i unifikacji oraz rozproszenia i heterogeniczności ma charakter ambiwalentny. Z jednej bowiem strony, unifikacja i koncentracja zasobów ułatwiają procesy ochrony systemów. Z drugiej zaś, uniformowane systemy narażają na poważniejsze straty w przypadku naruszenia bezpieczeństwa. Niektóre cechy technologii stosowanych w chmurach obliczeniowych sprzyjają podniesieniu poziomu bezpieczeństwa w organizacjach. Możliwe jest to między innymi dzięki technologiom wirtualizacji. Sprzyja ona bowiem procedurom relokowania zasobów systemowych w przypadku zagrożeń oraz na potrzeby informatyki śledczej, przyśpiesza i usprawnia aktualizacje bezpieczeństwa i ujednolica interfejsy do zarządzania bezpieczeństwem. Częściej jednak zwraca się uwagę na niebezpieczeństwa powiązane z wirtualizacją. Jak każda inna technologia, narażona jest ona na błędy umożliwiające nieautoryzowany dostęp do systemów i co warte podkreślenia, niekoniecznie powiązanych z jednym usługobiorcą. Inny problem dotyczy także naruszenia interfejsów zarządzania. Wiele obaw co do chmur obliczeniowych wynika z technicznych uwarunkowań funkcjonowania danych. Po pierwsze, problematyczne mogą być procesy modelowania i przystosowywania zbiorów danych do środowisk chmur obliczeniowych. Ponadto, w wielu przypadkach transmisja dużych wolumenów danych nie zawsze jest możliwa. Chodzi tu o związek między ilością danych koniecznych do wykorzystywania żądanych funkcji, a ich dostępnością w czasie. Oznacza to na przykład, że infrastruktura sieciowa może wykluczać wdrożenie niektórych aplikacji, np.: bardzo wątpliwe może okazać się przystosowanie rozwiązań operacyjnego BI (przykład aplikacji czasu rzeczywistego) w modelu chmury hybrydowej. W niektórych przypadkach nie do zaakceptowania może być sytuacja niedefinitywnego usunięcia danych w środowiskach chmur. Opisywany problem zamknięcia niejednokrotnie prowadzi do problemów eksportu lub importu danych. 128

129 Ponadto systemy mogą wykazywać obniżone wskaźniki dostępności warunkowane choćby wykorzystywaniem konkretnych technologii służących dostępowi i przechowywaniu danych, co ukazuje problem nieprzewidywalności wydajności. Niewłaściwa konfiguracja systemów oraz niewystarczające zabezpieczenia mogą być wykorzystywane w celu przeprowadzenia ataków EDoS. Ich bezpośredni efekt ma oczywiście charakter ekonomiczny, jednak ataki te wynikają głównie z błędów natury technicznej (np.: brak stosowania pułapów wykorzystania zasobów lub błędy obsługi protokołów sieciowych). Ponadto problem to problem zamknięcia uniemożliwia niejednokrotnie migrację lub zmianę aplikacji, platform programistycznych lub maszyn wirtualnych. W końcu ogromne centra danych narażone są na błędy systemów wielkoskalowych, których rozwiązanie może być prostsze w mniejszych, tradycyjnych środowiskach. Wymiar organizacyjny. Za wymiar organizacyjny należy uznać wszelkie cechy modelu chmury obliczeniowej wypływające na działania i cele funkcjonowania organizacji lub na działania i zachowania rynkowe. Jedną z głównych konsekwencji zastosowania chmur obliczeniowych są przemiany w zarządzaniu infrastrukturą IT. Zmiany te wynikają głównie z konsolidacji zachodzącej w warstwie systemowej. Konsolidacja i uniformizacja wpływają na usprawnienie przepływu informacji, znoszenie redundancji (funkcji i danych) oraz redukują zaangażowanie w obsługę systemów i ich utrzymanie oraz wsparcie. Stosowanie różnorodnych typów aplikacji lokalizowanych w chmurach obliczeniowych oprócz bezpośrednich konsekwencji ekonomicznych wpływa także na możliwości rozwoju organizacji. Powstawanie wielu przedsięwzięć nie byłoby możliwe bez zapewnienia warunków dla funkcjonowania aplikacji, które nazwaliśmy aplikacjami o skali internetowej lub aplikacji o znaczącym przyroście danych. Do powodzenia zastosowania chmur obliczeniowych przyczynić się może zjawisko funkcjonalnej zwięzłości aplikacji. Postulat i zjawisko funkcjonalnej zwięzłości posiada między innymi silne przełożenie na sprawność podejmowania decyzji oraz efektywność przetwarzania informacji. W tym kontekście ciekawym zjawiskiem jest obserwowane przenoszenie procesu zarządzania zmianą procesów na dostawców usług. Zjawisko to ma zapewne swoje ograniczenia, które potęgują się wraz ze wzrostem złożoności funkcjonalnej usług oferowanych przez dostawców, jednak należy uznać je w wielu przypadkach zastosowań za czynnik pozytywny omawianego wymiaru. 129

130 Duże znaczenie dla możliwości zastosowania chmur obliczeniowych mają czynniki powiązane z bezpieczeństwem. Dzięki przeniesieniu systemów i aplikacji do chmur obliczeniowych organizacje mogą skorzystać z efektów skali, które w wymiarze organizacyjnym wiążą się choćby ze znaczącym podniesieniem kompetencji w zakresie bezpieczeństwa, co przejawia się w stosowaniu standardów bezpieczeństwa wdrażanych przez dostawców, możliwościami stosowania informatyki śledczej czy też lepszym zarządzaniem bezpieczeństwem, które podnosi zapewne forma koncentracji zasobów (np.: ułatwienie tworzenia spójnej polityki bezpieczeństwa). Ponadto bezpieczeństwo może być także, jak wykazywaliśmy, elementem stymulującym konkurencyjność między usługodawcami, zaś szerokie zastosowanie regulacji dotyczących ochrony danych podnosi ich wiarygodność w oczach usługobiorców oraz ich klientów. Dzięki skalowalności usług w chmurach obliczeniowych organizacje mogą wykorzystywać sytuacje oraz planować działania, których ilość zasobów koniecznych do przetwarzania informacji nie będzie z góry przewidziana (np.: kampania marketingowa, która wykorzystuje efekty wirusowe). Inną konsekwencją skalowalności jest ułatwienie powstawania nowych przedsięwzięć gospodarczych, które mogą rozwijać się w bardzo szybkim tempie. Do wymiaru ekonomicznego zaliczyliśmy korzyści płynące z charakteru rozwoju i adaptacji systemów. Naturalnie ten czynnik przypisać można także do wymiaru organizacyjnego, bowiem rozwój systemów i aplikacji w środowiskach chmur obliczeniowych znacząco wpływa na czas realizacji wdrożeń oraz ich efektywność (np.: czas wdrożenia systemu analityki biznesowej w modelu SaaS ulega znacznemu skróceniu w stosunku do czasu jego realizacji w środowisku tradycyjnym). Chmury obliczeniowe stwarzają szanse dla intensyfikacji relacji biznesowych oraz stymulują zachowania rynkowe w krajach rozwijających się, gdzie oprócz znaczącej bariery inwestycyjnej wejścia na rynek istotną barierą jest także bariera wiedzy, eliminowana w pewnym stopniu w modelach chmur obliczeniowych. Omawiany model znacząco wpływa także na innowacje i sprzyja tendencji rynkowej określanej mianem długiego ogona. Zjawisko Green IT opisywane jest głównie w kontekście ekonomiczno-technicznym, jednak warto zauważyć, że posiada ono także wpływ na możliwość identyfikacji zasobów wewnątrz organizacji. Oznacza to, że odwoływanie się do wytycznych powiązanych z Green IT w pewnym sensie wymusza rewizję wykorzystywanych systemów oraz ocenę ich wydajności. 130

131 Organizacje pomimo powyższych korzyści niejednokrotnie zmuszone są rezygnować z wdrożeń w środowiskach chmur obliczeniowych. Dzieje się tak choćby w przypadku aplikacji z dostępem do poufnych danych, kiedy to ich ochrona jest nadrzędnym celem ich przetwarzania. Problem ten ma jeszcze wyraźniejszy wydźwięk w sytuacjach konieczności spełnienia wyraźnych norm i regulacji, a zwłaszcza w sytuacjach realizacji usług bez określenia lokalizacji danych lub niedostatecznej ochrony transferu danych czy braku procedur definitywnego ich usuwania. Do trudnych sytuacji mogą prowadzić niedogodności związane brakiem zapewnienia dostępności usługi powodowanej między innymi zaprzestaniem świadczenia usług, problemami łańcucha dostaw usług lub nieprawidłowymi wyliczeniami posiadania koniecznych zasobów dokonywanymi przez dostawcę. Zmiany organizacyjne dostawców (np.: przejęcia lub fuzje) mogą wywierać negatywny wpływ na zastane procedury bezpieczeństwa, w chwili gdy nowy twór nie będzie stosować się do uprzednich ustaleń zapisanych w umowach świadczenia usług. Ponadto pracownicy dostawców mogą nadużywać przyznanych im przywilejów, co wiąże się choćby z problemem utraty kontroli nad zasobami. Problemy te zależą w głównej mierze od kondycji i działań dostawcy i w jawny sposób dalekie są od wymiarów ekonomicznego i technicznego, które w ścisły sposób determinują możliwości zastosowania chmur obliczeniowych przez organizacje. Jak widzieliśmy powyżej, decyzje o przeniesieniu części lub całości infrastruktury do chmur obliczeniowych wiążą się z poważnymi zmianami w zarządzaniu. Prowadzą one między innymi do częściowej utraty kontroli nad zasobami, konieczności przeprowadzenia zmian w zastanych procesach i procedurach. W konsekwencji zmiany te muszą prowadzić do stworzenia spójnej polityki, co rzecz jasna może mieć swoje ujemne i dodatnie strony. Konieczne zmiany organizacyjne skutkować także mogą redukcją stanowisk pracy, która rozpatrywana była jako jedna z korzyści natury ekonomicznej. Jednak może mieć to negatywny wpływ na rynek pracy (zmniejszenie zapotrzebowania na kadrę IT może wpłynąć choćby na stawki wynagrodzeń specjalistów). Decyzje o wdrożeniu w modelu chmury obliczeniowej wymagają także rozpoznania koniecznych umiejętności, zarówno w zakresie zarządzania usługami oraz ich wsparciem, jak też w zakresie ich użytkowania oraz koniecznej adaptacji użytkowników końcowych. Może to mieć jednak pozytywny efekt, gdyż w przypadku wielu organizacji ścisłe rozeznanie i rozpoznanie koniecznych kompetencji w zakresie systemów IT nie jest przeprowadzane. Korzystanie z usług oferowanych w chmurach publicznych i prywatnych 131

132 może także wiązać z wewnętrznym oporem organizacyjnym, zwłaszcza w przypadku departamentów IT. W końcu stosowanie chmur obliczeniowych może w poważny sposób narazić na utratę reputacji w chwili nieuczciwych praktyk innych usługobiorców. Pamiętajmy bowiem, że współdzielona infrastruktura dostawcy stanowi swoisty organizm, który przez wiele instytucji i firm traktowany jest jako pojedynczy twór, bez względu na ilość usługobiorców. Właśnie dlatego nieuczciwe praktyki jednego usługobiorcy w oczach instytucji regulujących działania gospodarcze lub technologiczne wpływają na pozycję innych usługobiorców. Inny problem natury regulacyjno-prawnej wynikać może z braku informacji o jurysdykcji. W poniższych tabelach znajdziemy podsumowanie podziału czynników dokonanego w analizie ETO: Tabela 3. Analiza ETO Mocne strony. Źródło: opracowanie własne. Mocne strony Grupa czynników Czynniki Zarządzanie infrastrukturą Konsolidacja środowisk produkcyjnych Ujednolicenie i standaryzacja platform Migracja, replikacja, automatyzacja środowisk Aplikacje E T O Redukcja personelu IT Ułatwione wsparcie i szkolenie użytkowników Aplikacje o skali internetowej Aplikacje o sporadycznym zapotrzebowaniu Aplikacje niestrategiczne Aplikacje przyrostu danych Skalowalność Bezpieczeństwo Model kliencki Przeglądarka jako platforma Funkcjonalna zwięzłość Zarządzanie zmianą procesów FLOSS Licencjonowanie Różne potrzeby w czasie Nierozpoznane potrzeby w czasie Elastyczność alokowania zasobów Rozwój i adaptacja systemów Korzyści skali Standaryzacja Audyty i informatyka śledcza Aktualizacje Lepsze zarządzanie ryzykiem 132

133 Tabela 4. Analiza ETO - Słabe strony. Źródło: opracowanie własne. Słabe strony Grupa czynników Czynniki E T O Aplikacje Aplikacje historyczne - Aplikacje czasu rzeczywistego - Aplikacje z dostępem do poufnych danych Funkcjonowanie danych Modelowanie i migracja danych - - Nieokreślona lokalizacja Transfer danych Bezpieczeństwo Dostępność / - - Błędy technologii wirtualizacji - Błędy separacji zasobów - Naruszenie interfejsów zarządzania - Niedefinitywne usunięcie danych - Błędne wyliczenie koniecznych zasobów (dostawcy) - - Nieprzewidywalność wydajności - Błędy systemów wielkoskalowych - Tabela 5. Analiza ETO - Szanse. Źródło: opracowanie własne. Szanse Grupa czynników Czynniki Green IT Identyfikacja niewykorzystanych zasobów Wydajność PUE Bezpieczeństwo Rynek Innowacje E T O Pozytywny wpływ na technologie wirtualizacji Ekologia funkcjonalności Regulacje dotyczące audytów i standardów Element przewagi konkurencyjnej dostawców Intensyfikacja relacji biznesowych Przedsięwzięcia typu startup Niezależność inwestycyjna Kraje rozwijające się Otwartość Aplikacje mashup Długi ogon Tabela 6. Analiza ETO - Zagrożenia. Źródło: opracowanie własne. Zagrożenia Grupa czynników Czynniki E T O Zmiany w zarządzaniu Utrata kontroli - Zmiana procesów i procedur - 133

134 Zagrożenia Grupa czynników Czynniki E T O Konieczność spójnej polityki IT -/ Rynek pracy Redukcje stanowisk pracy - Dostępność Zaprzestanie świadczenia usług (dostawcy) Problemy prawne Bezpieczeństwo Problem zamknięcia - Problemy łańcucha dostaw - Nieuczciwe praktyki innych usługobiorców - Brak informacji o jurysdykcji - Brak odszkodowań za faktyczne straty Rozeznanie i adaptacja - - Rozpoznanie koniecznych umiejętności -/ Wewnętrzny opór organizacyjny - Adaptacja użytkowników - Nadużycie przywilejów dostawcy - Zmiany organizacyjne dostawcy - EDoS - Celowe zamknięcie przez dostawców - Problemy eksportu/importu danych Zamknięcie aplikacji - Migracja platform programistycznych i maszyn wirtualnych Charakterystyka czynników analizy ETO na tle charakteru organizacji Głównym celem rozprawy jest określenie możliwości zastosowania systemów analityki biznesowej w systemach rozproszonych. Model chmury obliczeniowej spełnia podstawowe zasady tych systemów i otwiera nowe możliwości dla systemów analityki biznesowej. Charakterystyka chmur obliczeniowych przedstawiona w analizie ETO może być odniesiona do typu organizacji, a tym samym w ściślejszy sposób ukaże uwarunkowania chmur obliczeniowych. W niniejszej części dokonamy najbardziej rudymentarnego podziału. Tłem dla wyróżnionych grup czynników będą przedsiębiorstwa, które podzielimy na duże firmy oraz małe i średnie przedsiębiorstwa (MŚP). W poniższym zestawieniu zastosowano następujące symbole znaczenia wyróżnionych czynników: 134

135 Czynnik Pozytywny Negatywny Pozytywny ze stronami negatywnymi Negatywny ze stronami pozytywnymi n Neutralny (o znikomym znaczeniu lub bez znaczenia) Tabela 7. Porównanie grup czynników analizy ETO na tle charakteru organizacji. Źródło: opracowanie własne. Grupa czynników Zmiany w zarządzaniu Aplikacje Małe i średnie przedsiębiorstwa (MŚP) Duże przedsiębiorstwa Największe korzyści z tej grupy czynników przynoszą możliwości redukcji personelu oraz ułatwione wsparcie i szkolenie użytkowników. Ostania korzyść zyskuje na znaczeniu zwłaszcza w modelu SaaS, w którym dostawcy koncentrują się z reguły na konkretnym rozwiązaniu, wspierając przy tym wielu usługobiorców. Chmury obliczeniowe uatrakcyjniają duża koncentracja środowisk produkcyjnych, standaryzacja platform i środowisk oraz ich migracja i replikacja. Ma to znaczenie w dużych, rozbudowanych i heterogenicznych środowiskach, w których dzięki chmurom obliczeniowych dochodzi do owej koncentracji zasobów. Podobnie do MŚP duże przedsiębiorstwa korzystać mogą także z redukcji personelu oraz usprawniać zadania szkoleniowe i wsparcia użytkowników. W MŚP adaptacja środowiska chmur obliczeniowych jedynie w niewielkim stopniu będzie uzależniona od negatywnych konsekwencji zmian w zarządzaniu infrastrukturą. Zależy to jednak od stopnia rozbudowania środowiska IT oraz zasobów koniecznych do jego utrzymania. n Im większy rozmiar przedsiębiorstwa tym bardziej utrudnione jest zadanie relegacji zadań oraz ról. Przystosowanie aplikacji do modelu chmury obliczeniowej wymaga niejednokrotnie zmiany procesów oraz procedur lub też utworzenia wspólnej polityki IT dla systemów wewnętrznych i zewnętrznych. MŚP mogą w praktyczny sposób korzystać ze wszelkich typów aplikacji, które sprawdzają się w chmurach obliczeniowych (np.: a. o sporadycznym zapotrzebowaniu, a. znacznego przyrostu danych). Szczególne znaczenie dla MŚP zyskują aplikacje niestrategiczne. Przy czym obejmują one coraz większe spektrum dziedzin oraz funkcji biznesowych (np.: ERP w modelu SaaS), co w tym sektorze przedsiębiorstw niejako znosi granicę między aplikacjami strategicznymi, a niestrategicznymi. Duże przedsiębiorstwa podobnie do MŚP korzystać mogą z wielu typów aplikacji oferowanych w chmurach obliczeniowych, wyłączając jednak aplikacje strategiczne. Aplikacje oferowane w chmurach cechuje niejednokrotnie funkcjonalna zwięzłość, która sprzyja procesom podejmowania decyzji w środowiskach o dużej złożoności i heterogeniczności procesów. Infrastruktura IT MŚP w niewielu przypadkach opiera się o aplikacje historyczne (legacy applications). n Konstrukcja aplikacji historycznych może skutecznie ograniczyć ich wdrożenie w chmurach obliczeniowych. W takich przypadkach konieczne jest przystosowanie ich do środowiska dostawcy. Wdrożenie aplikacji czasu rzeczywistego oraz aplikacji z dostępem do poufnych danych może być nie do przyjęcia z uwagi na dostępność systemów, jak też uwarunkowania prawne. Podobnie jak w MŚP. 135

136 Grupa czynników Małe i średnie przedsiębiorstwa (MŚP) Duże przedsiębiorstwa Realizacja wielu usług w oparciu o platformę Zarówno przeglądarka jako platforma, jak i przeglądarki redukuje konieczność model kliencki sprawdzić się mogą w przywiązania się do konkretnego dużych środowiskach, pozytywnie urządzenia klienckiego, zwiększając wpływając na usprawnianie procesów mobilność pracowników (dostęp do zarządzania infrastrukturą IT. aplikacji z dowolnego urządzenia, np.: urządzenia mobilnego) lub zapewniając możliwość tworzenia wirtualnego przedsiębiorstwa. Przeglądarka jako platforma wspiera także opisywany model kliencki, znacznie redukując nakłady inwestycyjne oraz obsługę systemów. Skalowalność Bezpieczeństwo FLOSS rozszerza możliwości wyboru aplikacji bez znacznych obciążeń finansowych z uwagi na elastyczne formy licencjonowania. FLOSS oraz formy licencjonowania stosowane w chmurach odgrywają coraz większą rolę w funkcjonowaniu systemów IT dużych przedsiębiorstw. Korzystanie z rozwiązań FLOSS wiąże się jednak z koniecznością wsparcia oprogramowania, co nie zawsze jest oferowane przez twórców lub dostawców usług bazujących na wolnym i otwartym oprogramowaniu. Zarządzanie zmianą procesów dokonywaną przez dostawców sprzyja ich porządkowaniu oraz wychodzeniu naprzeciw zmianom rynkowym i technologicznym, które nie zawsze są śledzone przez MŚP. Zarządzenie zmianą procesów w dużych przedsiębiorstwach podlega odgórnym wytycznym działów IT, a zarządzanie ich zmianą ze strony dostawcy usługi w chmurze obliczeniowej może przyczynić się do konfliktów między obsługiwanymi aplikacjami i systemami. Nierozpoznane potrzeby w czasie, jak też elastyczność alokowania mają szczególne zastosowanie do małych i średnich przedsiębiorstw. Ich rozwój nie musi być uzależniony od znaczących nakładów inwestycyjnych. Skalowalność w chmurach obliczeniowych przyczynia się zatem do zwiększenia elastyczności działania oraz ewentualnej zmiany charakteru przedsięwzięcia. Duże przedsiębiorstwa mogą niejednokrotnie wdrażać swoje własne środowiska chmur obliczeniowych, ale wciąż istnieją domeny, w których tymczasowe zapotrzebowanie na zasoby obliczeniowe może przekroczyć możliwości prywatnej infrastruktury IT (np.: zaawansowane obliczenia firm badawczych, wahnięcia zachowań konsumentów, przedsięwzięcia uzależnione od sezonowości). Systemy i aplikacje dostępne w chmurach obliczeniowych ułatwiają rozwój własnych rozwiązań, który bez zasobów dostawców wymagałby stworzenia własnego środowiska. Dostawcy, zwłaszcza rozwiązań o określonym profilu, w wielu przypadkach dostarczają usługi, których konstrukcja ułatwia rozbudowę w oparciu o nowo przygotowywane funkcje (np.: dostawcy oferujący usługi analityki biznesowej w modelu SaaS). Względna jednolitość systemów ułatwia ich rozwój i modyfikację przy założeniu braku ograniczeń integracji z systemami przedsiębiorstwa. Wiele spośród niewielkich podmiotów nie posiada precyzyjnych mechanizmów reagowania na zagrożenia z bezpieczeństwem oraz dostępnością systemów. MŚP w istotny sposób zyskują na standardach zabezpieczania i zarządzania bezpieczeństwem, przyśpieszonych aktualizacjach oraz specjalistycznej wiedzy. Wymienione korzyści, które mają znaczenie dla MŚP mają także zastosowanie w dużych podmiotach. Duże przedsiębiorstwa mogą także znacząco podnieść bezpieczeństwo systemów dzięki stosowanym przez dostawców procedurom audytów i ułatwieniom informatyki śledczej. 136

137 Grupa czynników Małe i średnie przedsiębiorstwa (MŚP) Duże przedsiębiorstwa Zewnętrzne czynniki takie jak regulacje dotyczące audytów lub stosowanie standardów bezpieczeństwa zdecydowanie podnoszą wartość chmur obliczeniowych w tym sektorze. Wiele dużych podmiotów prawdopodobnie nie podejmie decyzji o wdrożeniu bez zapewnienia ze strony dostawcy o spełnianiu kryteriów określonych w stosownych regulacjach dotyczących bezpieczeństwa. Wymusza to na dostawcach działania podnoszące jakość ochrony systemów. Techniczne uwarunkowania powiązane z wirtualizacją mogą poważnie naruszyć bezpieczeństwo informacji. Nieodpowiednie zabezpieczenia transferu danych i brak procedury definitywnego usuwania danych mogą mieć znaczenie krytyczne dla wielu przedsiębiorstw. Problemy bezpieczeństwa wynikające z technologii wirtualizacji mają większe znaczenie dla dużych organizacji z uwagi na możliwość przechowywania dużo większej ilości danych, podlegającej częstokroć dużej intensywności przemieszczania się. MŚP w szczególny sposób narażone są na ataki typu EDoS, a z uwagi na możliwość korzystanie jedynie z usług lokalizowanych w chmurach obliczeniowych ich zależność od wiarygodności i rzetelności usługobiorców w zakresie dostępu do systemów ma znaczenie kluczowe. Naruszenie zasad dostępu do systemów usługobiorcy ze strony pracowników dostawcy może w istotny sposób narazić duże przedsiębiorstwa na niekontrolowany wyciek dużych wolumenów danych. Pośrednio mogą się przyczynić także zmiany organizacyjne dostawców. Dostępność Umowy SLA gwarantują relatywnie wysoki poziom dostępności usługi z punktu widzenia działań podejmowanych w MŚP. Np.: w wielu niewielkich podmiotach błędy w typowym środowisku informatycznym lub niedostępność systemów IT wymagają ingerencji specjalistów, którzy nie są pracownikami przedsiębiorstwa. Niepożądane zachowania dostawców (bankructwo dostawcy lub problemy z poddostawcami usługodawcy) mogą jednak doprowadzić do braku dostępności aplikacji i systemów przez dłuższy czas. n Duże podmioty charakteryzuje w wielu przypadkach systematyczne podejście do zapewniania ciągłości działania, które w środowiskach chmur obliczeniowych może być narażone na większe ryzyko, płynące choćby z zaprzestania świadczenia usług przez dostawcę lub z problemów łańcucha dostaw. Jednak w wielu niekrytycznych zastosowaniach poziomy dostępności usług świadczone przez dostawców chmur obliczeniowych mogą być do zaakceptowania, o ile nie naruszają one pozostałych działań, nieskoncentrowanych wokół chmur obliczeniowych. Funkcjonowanie danych Nieskomplikowane modele danych mogą w Działania niezbędne do wdrożenia wielu stosunkowo szybkim czasie zostać aplikacji w chmurze muszą opierać się na przystosowane do aplikacji w chmurach integracji danych oraz ich przystosowaniu obliczeniowych. Wielu dostawców usług do modeli lub typów baz danych udostępnia interfejsy integracji danych lub dostawców. Większa złożoność struktur świadczy dodatkowe usługi danych oraz ilość możliwym wywołań lub przystosowywania danych usługobiorcy zapytań utrudnia procesy mające na celu do udostępnianej aplikacji (ma to choćby integrację systemów wewnętrznych z miejsce w aplikacjach BI udostępnianych systemami lokalizowanymi w chmurach w chmurach). obliczeniowych. Nieokreślona lokalizacja danych może wykluczać realizację wdrożenia w chmurze z tytułu obwarowań regulacyjnoprawnych. Wiele działań na danych (zwłaszcza poufnych) wymaga określenia lokalizacji. Jeśli dostawca nie zapewni informacji o lokalizacji, może to wykluczyć wykorzystanie jego usługi. Zjawisko Green IT opiera się w głównej mierze na wykorzystaniu ekonomii skali, w szczególności w chwili tworzenia prywatnych centrów danych. n Decyzje o utworzeniu prywatnego centrum danych w oparciu o założenia chmur obliczeniowych stwarzają możliwości dla identyfikacji niewykorzystywanych zasobów obliczeniowych oraz prowadzić mogą do polepszenia wskaźników PUE. Green IT 137

138 Grupa czynników Małe i średnie przedsiębiorstwa (MŚP) Duże przedsiębiorstwa Rynek Chmury obliczeniowe intensyfikują relacje biznesowe co stwarza nowe możliwości w sektorze MŚP. Otwierają także możliwości dla przedsięwzięć typu startup lub ułatwiają reorganizację lub zmianę profilu przy względnej niezależności od inwestorów. Duże przedsiębiorstwa posiadają z reguły silną sieć relacji biznesowych oraz większą elastyczność inwestycyjną umożliwiającą podejmowanie nowych przedsięwzięć niezależnie od technicznych barier (np.: bariera zapewnienia koniecznej infrastruktury). n Innowacje Rozwój aplikacji typu mashup umożliwia tworzenie nowych produktów oraz usług i zapewnia większą elastyczność doboru komponentów. Wiele MŚP podlega ekonomicznej zasadzie długiego ogona, stymulowanej przez model chmur obliczeniowych. Innowacje w dużych organizacjach koncentrują się niejednokrotnie wokół zasobów wewnętrznych. Pomimo ogólnej dostępności komponentów usług, organizacje te wciąż mogą opierać się na rozwiązaniach tworzonych we własnym zakresie. n Nieuczciwe praktyki innych usługobiorców mogą na przykład poważnie naruszyć reputację firmy. Im większy jej rozmiar oraz spektrum usług i produktów tym straty z tytułu nieuczciwych praktyk mogą być poważniejsze. Brak informacji o jurysdykcji lub odszkodowań za faktycznie ponoszone straty mogą być istotnymi inhibitorami zastosowań usługi pośród MŚP. Umowy SLA uwzględniają poziomy dostępności, jednak nie zawierają z reguły klauzul o odszkodowaniach z tytułu niedostępności usługi lub naruszenia prywatności danych. Poważnym problemem przy tym może być brak informacji o jurysdykcji. Rozeznanie i adaptacja Zastosowanie nowych usług opierać się może na intuicyjnych wyborach, gdzie decyzje zależą choćby od łatwości przyswajania funkcji aplikacji (np.: usługi SaaS). Jednakowoż im niższy jest poziom usług (PaaS, IaaS) tym adaptacja może stanowić barierę nie do pokonania. n Duże organizacje narażone są na większy opór organizacyjny przy zmianie modelu przetwarzania informacji lub wprowadzaniu nowych aplikacji. Wiąże się to także z zapewnieniem użytkownikom względnej łatwości adaptacji (szkolenia i wsparcie). Adaptacja do nowych usług może jednak przyczynić się do rozpoznania koniecznych umiejętności i swoistej rewizji zasobów ludzkich w zakresie IT. Problem zamknięcia Bark elastyczności w doborze aplikacji lub usług może doprowadzić do sytuacji blokowania możliwego rozwoju przedsiębiorstwa z uwagi na przywiązanie do dotychczasowego dostawcy. Znaczące zaangażowanie zasobów organizacji w realizację projektów informatycznych lokalizowanych w chmurach bezpośrednio przekłada się na ich względne przywiązanie do usługodawców. Praktyki dostawców prowadzące do zamknięcia usługobiorców intensyfikują ten problem. Problemy prawne Reputacja w sektorze MŚP z reguły opiera się na bliskich relacja między podmiotami, dlatego też nieuczciwe praktyki innych usługobiorców w mniejszym stopniu narażają na straty Analiza ETO określenie związków Wyróżnienie trzech wymiarów oraz przypisanie do nich czynników wyodrębnionych w analizie SWOT ma na celu określenie możliwie bliskich związków między czynnikami. Uzyskujemy w ten sposób wyraźniejszy opis samego zjawiska chmury obliczeniowej wraz z uwarunkowaniami zastosowania tego modelu. 138

139 Powróćmy do samych założeń analizy SWOT. Po pierwsze analizę tę przeprowadzamy w kierunku od wewnątrz do zewnątrz, ukazując wpływ czynników wewnętrznych na czynniki zewnętrzne. Przy czym zarówno czynniki wewnętrzne, jaki czynniki zewnętrzne określamy jako potencjalnie stymulujące lub hamujące możliwości zastosowania i rozwoju modelu chmury obliczeniowej. Rysunek 9.Określenie zależności w między elementami analizy SWOT w metodzie "od wewnątrz do zewnątrz". Źródło: opracowanie własne. Związki w ujęciu od wewnątrz do zewnątrz mogą być ukazane dzięki odpowiedziom na następujące pytania (rys. 9): czy mocne strony umożliwiają wykorzystanie szans? czy mocne strony mogą zniwelować zagrożenia? czy słabe strony uniemożliwią wykorzystać szanse? czy słabe strony spotęgują występujące zagrożenia? Odpowiedzi na te pytania powinny być jednak udzielone w świetle systematyki ETO. Oznacza to na przykład, że chcielibyśmy dowiedzieć się, czy pozytywne czynniki organizacyjne wyróżnione wśród mocnych stron będą mogły niwelować czynniki negatywne przypisane do zagrożeń? Wspominaliśmy, iż w analizie SWOT nie będziemy przypisywać konkretnych wag do poszczególnych czynników (uznamy je zatem za jednakowo istotne). Porównanie czynników na tle charakteru organizacji jest w tym świetle instruktywnym przykładem. Otóż niektóre z czynników mają większe znaczenie dla MŚP niż dla dużych przedsiębiorstw i odwrotnie, niektóre zaś mają charakter neutralny. Sytuację tę różnicować 139

140 będą jeszcze bardziej charakter branży, czynniki geograficzne, rynkowe (charakter kanału dystrybucji, ilość klientów itp) i inne. Przedstawione zatem w tabeli 7. porównanie czynników oraz umiejscowienie ich na planie mocnych i słabych stron oraz szans i zagrożeń wraz z wymiarami ETO może stanowić punkt wyjścia dla oceny przydatności usług z modelu chmury obliczeniowej w konkretnej organizacji. W najbardziej zatem ogólnym przypadku nasza analiza może być podsumowana dzięki udziałom czynników w jednym z elementów matrycy SWOT w świetle wymiarów ekonomicznego, technicznego lub organizacyjnego. Każda z poniżej przedstawionych wartości określa udział czynników danego wymiaru w ilości wszystkich czynników danego elementu matrycy SWOT. Np.: liczba czynników wyróżnionych wśród szans ( Szanse jako element matrycy MS SS E T O E T O 0,64 0,32 0,56-0,23-0,69-0,38 SZ ZA E T O E T O 0,31 0,31 0,62-0,26-0,21-0,68 Rysunek 10. Udziały czynników ETO w na tle matrycy SWOT. Źródło: opracowanie własne. SWOT) wynosi 13, a liczba czynników wymiaru technicznego wśród szans wynosi 4 (tabela 5). Żądany udział wymiaru technicznego wśród szans wynosi 0,31. Właściwe określenie związków spróbujemy uwidocznić w każdym z trzech omawianych w analizie ETO wymiarów. Rysunek 11. przestawia znaczące relacje między elementami matrycy SWOT na tle ekonomicznym, technicznym oraz organizacyjnym144: MS E SS E MS T SS T MS O SS O 0,64-0,23 0,32-0,69 0, 56-0,38 SZ E ZA E SZ T ZA T SZ O ZA O 0,31-0,26 0,31-0,21 0, 62-0,68 Rysunek 11. Udziały czynników ETO w na tle matrycy SWOT (podział na wymiary). Źródło: opracowanie własne. Na podstawie tak zobrazowanych związków można wysnuć następujące tezy: 144 Za wskaźnik znaczenia relacji między udziałami w poszczególnych wymiarach przyjęto różnicę w potencjałach na poziomie 0,8. 140

141 1. W wymiarze ekonomicznym wyróżnione czynniki mogą pozytywnie wpłynąć na zachowania rynkowe. Znaczące korzyści płynące z ekonomicznych uwarunkowań chmur ekonomicznych mogą przeważyć nad takimi potencjalnymi zagrożeniami jak EDoS lub zagrożeniami ekonomicznymi wynikającymi z problemu zamknięcia. 2. Wymiar techniczny jest najsilniej umiejscowiony w obszarze słabych stron. Wydaje się, że ujemne strony techniczne nie powinny zasadniczo wpłynąć na możliwości innowacji oraz tendencje zachodzące w obszarze Green IT. Ponadto zagrożenia natury technicznej powiązane są z problemem zamknięcia, który w głównej mierze zależy od strategii dostawców, wyłączając kwestię migracji platform programistycznych i maszyn wirtualnych, która powiązana jest z kwestią technologicznych standardów oraz ich otwartością. 3. Największą ilość związków obserwujemy w wymiarze organizacyjnym. Można uznać, że czynniki tego wymiaru wyróżnione wśród słabych stron nie uniemożliwią postępów innowacyjnych, jak też nie wpłyną zasadniczo na zachowania rynkowe. Ponadto można uznać, że takie korzyści jak podniesienie poziomu bezpieczeństwa, różnorodność aplikacji, kwestie skalowalności zintensyfikują szanse rodzące się w tym wymiarze. Jednak związek między mocnymi stronami, a zagrożeniami w tym wymiarze należy uznać za najbardziej problematyczny. Wydaje się bowiem, że korzyści w zakresie zmian w zarządzaniu nie zniwelują negatywnych aspektów takich jak utrata kontroli, konieczność zmian procesów i procedur. Trudno także o znalezienie elementów w obszarze mocnych, które mogłyby przeważyć nad takimi problemami jak kwestie prawne czy brak dostępności z winy zmian organizacyjnych dostawcy. Natomiast pozytywny wpływ na wyróżnione zagrożenia związane z bezpieczeństwem mogą mieć lepsze możliwości w zakresie audytów i informatyki śledczej. Chmury obliczeniowe stanowią nowy etap w rozwoju systemów informatycznych o charakterze rozproszonym. Ich zastosowanie może być niezwykle cenne z ekonomicznego punktu widzenia, który wraz z pozytywnymi czynnikami o charakterze organizacyjnym dominuje wśród mocnych stron. Jednak należy pamiętać, że uwarunkowania natury organizacyjnej stanowią przeciwwagę dla ekonomiki z uwagi na względny brak wpływu korzyści organizacyjnych na zagrożenia w tym obszarze. Wymiar techniczny stanowi niejako odrębny obszar, który traktowany może być niezależnie. Należy się spodziewać, że ujemne strony tego wymiaru będą niwelowane wraz z dojrzewaniem technologii w 141

142 zakresie bezpieczeństwa i funkcjonowania danych oraz tworzeniem otwartych i szeroko obowiązujących standardów niwelujących problemy zamknięcia. Stopień i skala zastosowań polegać będą w głównej mierze na pokonywaniu problemów natury organizacyjnej,w szczególności problemów natury prawnej oraz uwarunkowań relacji usługobiorca-dostawca w zakresie warunków świadczenia usług. Spodziewać się zatem należy precyzyjnie tworzonych umów SLA, które uwzględniać powinny sytuacje zaprzestania świadczenia usług przez dostawcę oraz problemy z poddostawcami, kwestie określenia ról dla zarządzających zasobami, a także sytuacje naruszenia zasad bezpieczeństwa ze strony usługodawców. 142

143 5. Zagadnienia systemów analityki biznesowej w systemach rozproszonych 5.1. Rozproszenie w warstwach zasobów i systemowej Na początku rozdziału trzeciego zasygnalizowaliśmy istnienie dwóch płaszczyzn, w których dochodzi do znoszenia napięcia między rozproszeniem, a integracją. Są nimi warstwy zasobów oraz systemowa. Griffin w jednej ze swych głównych prac dzieli zasoby na ludzkie, pieniężne, rzeczowe i informacyjne145. Z punktu widzenia systemów wspomagania decyzji należy ograniczyć te cztery grupy do trzech, a mianowicie do zasobów ludzkich, rzeczowych oraz informacyjnych. Systemy informacyjne przypiszemy do warstwy systemowej, którą kształtują aplikacje, systemy, modele oraz procesy, przy czym aplikacje należy rozumieć, jako bezpośrednie narzędzia odniesione do procesów np.: system ERP może zawierać wiele aplikacji, które wspierają różne procesy biznesowe lub system BI może zawierać wiele niekoniecznie komplementarnych aplikacji. Pamiętajmy jednak, że samo pojęcie systemu oprócz funkcji biznesowej (np.: ERP, BI, CRM itp.) odnosi się także do charakteru architektury (np.: opartej o przetwarzanie rozproszone). Ponadto, zauważmy, że ścisłe przypisanie aplikacji do jednego z systemów nie musi mieć miejsca. Dzieje się tak choćby w przypadku architektury SOA, gdzie aplikacje komponowane mogą być z elementów (usług) przynależących źródłowo do różnych systemów. Trzy elementy warstwy zasobów (ludzkie, rzeczowe i informacyjne) w istocie ugruntowują procesy podejmowania decyzji oraz ich realizacje. Każdorazowo decyzję podejmuje jakiś podmiot (zasoby ludzkie) w oparciu o gromadzoną wiedzę (informacyjne). Następnie podmiot wykorzystuje posiadane środki (rzeczowe) w celu realizacji decyzji Griffin R. (2005), Podstawy zarządzania organizacjami, PWN, Warszawa, s W tym kontekście charakter podmiotu należy odnieść do szerszego spektrum. Otóż już we wczesnych stadiach rozwoju teorii podejmowania decyzji za podmiot uznawano dowolną instancję zdolną 143

144 (rys. 12). Zasoby rzeczowe są jednak podstawą nie tylko dla realizacji działań, ale także stanowią podstawę dla funkcjonowania warstwy systemowej (zarówno aplikacje, jak też infrastruktura je wspierająca, należy przypisać do warstwy zasobów). Charakter zasobów informacyjnych przedstawić należy w świetle opisywanej wcześniej triady, a mianowicie związku między danymi, informacją i wiedzą. (por. rozdział 2). Dlatego do obszaru zasobów informacyjnych należy zaliczyć dane i informacje, które w zależności do strategii informacyjnych organizacji we właściwy sobie sobie sposób kształtują wiedzę. Przyjęte założenia przetwarzania danych (np.: wybór źródeł danych lub określenie związków między danymi) wpływają bezpośrednio na model danych. Umieściliśmy go w warstwie systemowej, gdyż jest on reprezentacją i opisem faktycznych zasobów oraz procesów. Rysunek 12. Układ elementów warstw zasobów i systemowej w odniesieniu do procesu podejmowania decyzji. Źródło: opracowanie własne. podejmować decyzje. Stąd zasoby ludzkie nie wyczerpują kategorii podmiotu w proponowanym schemacie. Choć stoi to w opozycji do klasyfikacji Griffina oraz przeczy to naturalnym skądinąd intuicjom, zasadniczo w tym miejscu zasoby ludzkie powinny być rozszerzone o dowolny obiekt podejmujący decyzje. W dalszych rozważaniach odnosić się będziemy jednak do węższej kategorii podmiotu, a mianowicie ludzi. 144

145 Warstwa systemowa zasadniczo umożliwia podejmowanie działań oraz wspiera funkcjonowanie warstwy zasobów. Rodzą się tu istotne rodzaje rozproszenia, odpowiadające wymienionym elementom warstw oraz kwestie zależności między tymi elementami. Coraz częściej organizacje odnoszą się do fenomenów rozproszenia lub wręcz zmuszone są do podejmowania działań mających na celu eliminację tych zjawisk. Korzystają z zewnętrznych zasobów ludzkich, rzeczowych i informacyjnych. Naturalnie narzuca się tu choćby kwestia relegacji zadań w ramach outsourcingu, której nie sposób nie przeceniać. Jednak zasoby informacyjne należą do zgoła odmiennego porządku, wzmagając przy tym dodatkowo zależności i charakter rozproszenia zachodzący w relacji tych trzech zasobów. Podobne problemy obserwujemy w warstwie systemowej. Wszelkie jej elementy można choćby przypisać do charakteru ich zlokalizowania (wewnątrz lub na zewnątrz organizacji), ale na stopień rozproszenia wpływają także takie cechy jak heterogeniczność oraz złożoność powiązań pomiędzy poszczególnymi systemami i aplikacjami. Ostateczną instancją rozproszenia jest układ zależności zachodzących między poszczególnymi elementami dwóch opisywanych tu warstw. Przedstawione w poprzednim rozdziale przykłady systemów rozproszonych wpisują się w matrycę tych zależności. W niniejszym rozdziale spróbujemy odnieść do nich systemy analityki biznesowej Współczesne wyzwania funkcjonowania systemów Business Intelligence Systemy klasy business intelligence mają swoją wieloletnią historię. Istnieje wiele propozycji sposobu określania poziomu dojrzałości systemów tej klasy147. W jednym z raportów badających stan dojrzałości zastosowanych rozwiązań BI, firma Forrester Research wykazuje, że w 5-cio stopniowej skali oceny dojrzałości, organizacje osiągają średnią ocenę poniżej Jest to wciąż niesatysfakcjonujący poziom, zważywszy na duże zaangażowanie inwestycyjne wiążące się z wdrażaniem i utrzymaniem systemów BI. 147 Wśród modeli dojrzałości systemów BI (ang. BI maturity models) wymienić należy między innymi: TDWI BI MM, Gartner BI MM, Forrester BI maturity self-assessement model. Por. Olszak C. (2011), Przegląd i ocena wybranych modeli dojrzałości Business Intelligence w Korczak J., Dudycz H., red., Informatyka Ekonomiczna nr 22, Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu oraz Chuah M.-H., Wong K.-L. (2011), A review of business intelligence and its maturity models, African Journal of Business Management 5(9), s Źródło: Raport: Forster Research (2012), BI Maturity in The Enterprise: 2012 Update, August 7,

146 Evelson wymienia trzy czynniki wpływające na niski poziom skuteczności w osiąganiu zamierzonych celów inicjatyw BI149: implementacja systemów BI uzależniona jest z reguły od przeszłych doświadczeń związanych z funkcjonowaniem systemu długofalowa strategia realizacji i utrzymywania systemów BI zależy od wysiłków wiążących takie elementy jak źródła danych, modelowanie, metryki, portale itp. Ponadto organizacje mają trudności z określaniem przyszłych wymagań dla systemów BI z uwagi na zmiany rynkowe i uwarunkowania biznesowe. W końcu istotnym problemem jest określenie priorytetów oraz właściwe zdefiniowanie metryk używanych w analityce. Uzależnione jest to bowiem od konsensusu osiąganego przez różne grupy interesariuszy lub jednostki biznesowe; technologie BI nie nadążają za wymaganiami sprawności aplikacje BI cechuje typowo duży stopień złożoności, co prowadzi do problemu elastyczności oraz szybkości w stosowaniu zmian; centralizacja nie skutkuje sprawnymi, uproszczonymi implementacjami konsolidacja prowadzi do redukcji kosztów czy redukcji zadań związanych z implementacją. Jednak prowadzi ona do istotnego zwiększenia biurokracji. Kolejne zmiany scentralizowanego systemu wymagają uzgadniania stanowisk wielu stron oraz mnożenia procesów akceptacji podejmowanych działań150. Te negatywne zjawiska wpływają na ograniczenie sprawności działania systemów oraz szybkość wdrażania zmian. Pomimo coraz szerszego spektrum funkcji oferowanych przez platformy BI bardzo często oprogramowanie to nie realizuje w pełni wymagań stawianych przez założenia inicjatyw BI. Oznacza to, że na obecnym etapie rozwoju aplikacji BI organizacje w wielu przypadkach zmuszone są stosować wiele narzędzi tej klasy, co prowadzi co zwiększenia wysiłków integracyjnych bądź działań konsolidacyjnych Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, Paper No , Forrester Research, Inc, s Jest to przykład procesu warunkowanego heterogenicznością (tu: zróżnicowaniem zdań). Zauważmy przy tym, że heterogeniczność skutkuje rozproszeniem na stosownej płaszczyźnie. Np.: heterogeniczność danych może być między innymi związana z heterogenicznością źródeł bądź heterogenicznością procesów ich zapisu. W tym kontekście można sądzić, że skala heterogeniczności w systemach informacyjnych wpływa na stopień rozproszenia. W najbardziej abstrakcyjnym ujęciu można powiedzieć, że dowolna różnica wprowadza swoistą przestrzeń między zróżnicowanymi elementami, zaś przestrzeń tę uznać można za płaszczyznę, na której dochodzi do rozproszenia. 151 Evelson B. (2012), Top 10 BI Predictions For 2013 and Beyond, Forrester Research, Inc., 146

147 Zachodzące zmiany w podejściu do kształtowania infrastruktury systemów BI, a mianowicie zmiany ugruntowujące model rozproszony tych systemów, tj. decentralizowany prowadzą do zjawiska redundancji. Mamy z nim do czynienia każdorazowo, w chwili gdy istnieje wiele wzajemnie nakładających się reprezentacji wiedzy (np.: osobne tematyczne hurtownie danych będące podstawą dla względnie osobnych środowisk BI w obrębie organizacji). Redundancja ta istotnie wpływa na możliwość destabilizacji spójności podejmowanych decyzji w obrębie organizacji. Pewnym przejawem potrzeby niezależnego kształtowania podstaw i funkcji narzędzi BI są postulaty samoobsługowych platform BI152. Powstają jednak w tym miejscu istotne pytania: czy spójność podejmowanych decyzji powinna być osiągana za wszelką cenę? Jak przekłada się taki postulat na efektywność dziań ekonomicznych oraz jaki powinien być zasięg tak rozumianej spójności (np.: na poziomie całej organizacji, departamentu, jednostki biznesowej itp.)? W świetle systemów klasy business intelligence odpowiedzi na te pytania wcale nie są jednoznaczne. Jest to bowiem zjawisko wielowymiarowe, którego bezpośrednim efektem jest choćby stosunek decydentów i menedżerów do problemu jednej wersji prawdy [ang. single version of truth]. Osiągnięcie stanu, w którym dane rozumiane są w jednolity sposób (vide single version of truth) możliwe jest między innymi przy zastosowaniu narzędzi do zarządzania danymi referencyjnymi (MDM - ang. Master Data Management). Okazuje się jednak, że określenie definicji i instrukcji w systemach MDM wymaga podjęcia decyzji o właściwym kontekście np.: osoba może być określana jako rodzic, przyjaciel, kolega i każdy z tych opisów osoby ma swoje motywacje oraz wymagania zastosowania. Oznacza to, że dowolny opisywany obiekt może mieć różne zastosowania. Dlatego modelowanie danych w MDM powinno dopuszczać elastyczność zastosowania w różnych sytuacjach153. Kolejnym problemem będącym przeszkodą w tworzeniu i utrzymywaniu platform BI jest sama natura procesów biznesowych. Większość procesów biznesowych, które cechuje względna niezmienność jest z reguły modelowana, tworzona i implementowana w przedziale od 6-ciu do 12-tu miesięcy154. Są to z reguły dobrze zdefiniowane procesy wspierające podstawowe operacje planowania, budżetowania czy obsługi płatności. Jednak wiele procesów wykazuje zmienność, na którą wpływają brak automatyzacji uzależnionej 152 Por. dalsza część rozdziału. 153 Goetz M. (2012), Master Data Management Does Not Equal The Single Source of Truth, Forrester Inc., Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, op. cit., s

148 choćby od interwencji ludzi. Innymi słowy, czynnik ludzki w funkcjonowaniu procesów wpływa na ich całkowicie lub częściowo manualny charakter. Dotyczy to nie tylko pracowników organizacji. Wiele procesów biznesowych zależy od działań stron zewnętrznych (klientów, potencjalnych klientów, partnerów biznesowych, instytucji regulacyjnych), które podlegają w wielu przypadkach silnemu niezdeterminowaniu. W celu osiągnięcia większej sprawności w funkcjonowaniu systemów klasy BI oraz odpowiedzi na dynamikę procesów biznesowych na poziomie organizacyjnym zaleca się następujące działania: przydzielanie liderom biznesowym własności i zadań zarządzania inicjatywami BI im bardziej platformy BI uzależnione są od jednostek biznesowych (bezpośrednich beneficjentów systemu), tym bardziej przekłada się to na skuteczność działania środowisk BI; podkreślanie konieczności zmian organizacyjnych i kulturowych użytkownicy z reguły nie są skłonni poddawać się zmianom (np.: mają swoje przyzwyczajenia i preferencje związane z użytkowanymi aplikacjami, nie koniecznie z obszaru wdrażanej platformy BI); zaleca się monitorowanie oczekiwań i komunikację ich dotyczącą, stosowanie analityki użycia systemów BI (BI on BI) oraz wykorzystywanie metryk używania aplikacji BI w celu oceny pracowników, a nawet ewentualnego powiązania tych metryk z wynagradzaniem; oddzielanie procesów przygotowywania danych od procesów ich użytkowania te dwa typy działań powinny być przydzielone oddzielnym strukturom w organizacji, przy czym IT powinno być bardziej odpowiedzialne za procesy przygotowywania; wymagania frontendu BI i backendu BI powinny być określane oddzielenie te elementy środowiska BI różnią się co do tolerancji na ryzyko, planowania czy dokładności danych wymaga to tworzenia odrębnych zasad i wytycznych tworzenia procesów powiązanych z frontendem i backendem; ustanawianie modelu hub-and-spoke - zarówno skrajnie scentralizowana jak i rozproszona architektura (np.: bazująca na data marts) mają swoje negatywne skutki; opieranie się na modelu hub-and-spoke podlegać powinno dyrektywom i wytycznym, które obiekty modeli danych przynależeć powinny do obszaru scentralizowanego (hub), a które mogą należeć do jednostek-satelitów (spoke); 148

149 dyrektywy te powinny określać, na ile krytyczne dla działania organizacji są wymieniane obiekty i które z jednostek mogą mieć do nich dostęp. W przedstawionych w rozdziale trzecim założeniach dotyczących pomiaru wartości informacji jednym z istotnym czynników wpływających na wartość informacji był czas. Otóż wedle jednego z założeń im starsza jest informacja, tym mniejsza jest jej wartość. Teza ta znajduje odzwierciedlenie w systemach BI czasu rzeczywistego155: Koncepcja integracji danych czasu rzeczywistego wydaje się naturalnym rozwiązaniem dla wszelkich aspektów wszechobecnego business intelligence przestawia się w niezwykłym świetle. Można nawet spekulować, że wszystko powinno być dostępne dla BI i hurtowni danych w czasie rzeczywistym. Jednak logistyka synchronizacji danych czasu rzeczywistego może wpływać na kryteria wydajności, szczególnie w środowiskach z wieloma aplikacjami przetwarzającymi równolegle transakcje produkcyjne i operacyjne, gdzie aplikacje przetwarzające informowane są przez różne aplikacje BI 156. Słowa te dotyczą sytuacji sprzężenia zwrotnego między systemami BI, a systemami transakcyjnymi. Naturalnie problem zerowego opóźnienia obecny jest także w przypadku operacyjnego BI, gdzie aplikacje tych systemów bazują na źródłowych danych z reguły bez procesu konsolidacji danych. Rysunek 13. Dystans akcji, a wartość informacji. Źródło: Hackathorn R. (2004), The BI Watch: Real-Time to Real Value, DM Review 14(1). Nieznacznie zmodyfikowany. 155 Por. także rozdz. 2 - założenia biznesu czasu rzeczywistego. 156 Loshin D. (2012), Satisfying New Requirements for Data Integration, TDWI Research, s

150 Decydenci muszą niejednokrotnie odpowiadać sobie na pytanie, jak szybko dane mogą lub muszą być pobierane, przechowywane, analizowane i współdzielone. Odpowiedzi na te pytania zależą od określenia na ile istotny dla danej decyzji jest dystans akcji. Termin ten wprowadza Hackathorn, który przedstawia model oceny wartości operacyjnego BI157. Wartość tracona jest w przypadku wzrostu dystansu akcji (rys. 13), czyli czasu od zaistnienia zdarzenia do czasu podjęcia decyzji, przy czym na dystans ten składają się opóźnienie danych, czyli opóźnienie związane ze składowaniem danych (może być eliminowane), opóźnieniem analizy czyli dostarczeniem informacji oraz opóźnieniem decyzji po otrzymaniu tej ostatniej158. Model dystansu akcji zakłada czynnik czasu, jako istotny dla samej wartości. Należy jednak zauważyć, że nie wszystkie procesy wymagają krótkiego dystansu akcji. Jednak w wielu kluczowych procesach skracanie tego dystansu wpływa na bezpośredni efekt ekonomiczny. Dla przykładu pracownicy pierwszego kontaktu (np.: call-center) w wielu przypadkach będą potrzebowali możliwe najświeższych informacji oraz analiz w celu przedstawiania stosownych ofert klientom. Powiążmy wyróżnione tu czynnik czasowy oraz dystans akcji z problemem rozproszenia. Otóż kluczowe znaczenie ma tu między innymi logistyka danych. Bez wątpienia na dystans akcji wpływa położenie danych. Oznacza to, że fizyczna lokalizacja danych znajduje swe bezpośrednie odzwierciedlenie w problemie dystansu akcji. Nasuwa się tu dość oczywiste pytanie: na ile krótki może być dystans akcji w systemach rozproszonych? Nie chodzi tu rzecz jasna o określenie precyzyjnej miary, ale o wskazanie scenariuszy rozproszenia, w których pewne rozwiązania BI nie mogą być implementowane. Tradycyjne monolityczne systemy BI nie zawsze mogą być dopasowane do charakteru i dynamiki rozproszenia. Część danych efektywniej może być analizowana poza organizacją (zlecane analizy branżowe, wykorzystywanie zewnętrznych platform analitycznych czy analizy w chmurach przy użyciu sandboxów analitycznych). Zatem obecny kształt rozwiązań analityki biznesowej wprowadza stan dodatkowego rozproszenia. Z jednej strony systemy BI funkcjonują w ramach zastanej infrastruktury IT. Z drugiej zaś nie wszystkie zadania systemów analityki biznesowej mogą być realizowane w ramach 157 Hackathorn R. (2004), The BI Watch: Real-Time to Real Value, DM Review 14(1), s. 43 oraz Watson H. J. (2009), Tutorial: Business Intelligence Past, Present, and Future, Communications of the Association for Information Systems 25, s Opóźnienia danych i analizy są w istocie dystansem czasowym, który bezpośrednio wpływa na wartość informacji. 150

151 wewnętrznej infrastruktury IT. Sytuację dodatkowo komplikuje różnorodność pochodzenia danych i ich lokalizacja. Te tendencje ujawniają takie zjawiska jak fenomen Big Data, czy rozwiązania BI realizowane w modelach chmur obliczeniowych, którym przyjrzymy się w dalszej części rozdziału Zjawisko Big Data jako symptom rozproszenia oraz nowe światło dla systemów analityki biznesowej Fenomenem o niewątpliwych cechach rozproszenia jest zjawisko noszące miano Big Data. Mówimy tu o zjawisku, aniżeli o technologii, ponieważ wokół zjawiska tego koncentrują się nie tylko konkretne technologie, ale także kwestie zróżnicowania pochodzenia i typów danych, problemy zarządzania nimi, strategie organizacyjne oraz interesujące nas tu najbardziej konsekwencje dla funkcjonowania systemów analityki biznesowej. Era komunikacji elektronicznej przyczyniła się do lawinowego przyrostu danych. Często przywołuje się ogromny przyrost ilości blogów, tweetów czy i, wykazując przy tym tempo wzrostu wolumenów danych w sieci globalnej. Anderson pokazuje jednak, że te media i kanały informacyjne nie stanowią o ogromie danych w Internecie. Według jego głośnych słów sieć (www) należy uznać za skończoną, a przyszłość przynależy do Internetu159. Istotnie, Internet zazwyczaj kojarzony jest siecią WWW jednak w jego obrębie duża część ruchu przypada na transmisje wideo, VoIP czy P2P. Naturalnie pojawia się pytanie, na ile ta przeważająca część globalnego wolumenu danych może zostać wykorzystana przez organizacje, zwłaszcza, że dwa ostatnie z wymienionych kanałów mają charakter na poły prywatny lub ściśle prywatny. W obecnej sytuacji świadomość ogromu danych jest coraz powszechniejsza. Inną jednak sprawą jest fakt generowania i gromadzenia danych, a inną możliwości ich interpretowania i analizowania. Od czasów powstania ery cyfrowej ilość danych zawsze wykraczała poza możliwości ich analizowania. Świadczyć o tym może choćby fakt, że przyrost danych przekracza równoległy przyrost mocy obliczeniowej procesorów opisywany przez prawo Moore'a160. O ile jednak prawo Moore'a wiąże się z 159 Słowa te brzmiały: The web is dead. Long live the Internet. Por. Anderson C. (2010), Who's to Blame, Wired Magazine 18(9), s oraz s Fayyad i Uthurusamy określają to prawo mianem Prawa Składowania (ang. Storage Law), choć nie określają ścisłych wytycznych dla jego weryfikacji, co ma miejsce w przypadku prawa Moore'a. 151

152 ograniczeniami natury fizycznej (już na obecnym etapie pojawiają się głosy o załamaniu się tego prawa161), o tyle niepisane prawo przyrostu informacji ograniczone będzie głównie przez ograniczoność zasobów składowania, tj. przez przestrzeń konieczną do ich składowania, a nie ograniczenia wynikające z praw fizyki odniesionych do obecnie używanych materiałów stosowanych w jednostkach obliczeniowych. Powstaje zatem pytanie, jakie strategie informacyjne i organizacyjne należy przyjąć, aby dostępne dane w ich różnorodności i potężnej skali mogły służyć podejmowaniu decyzji? Można przypuścić, że wartość informacji maleje wraz z jej powszechnością. Stoi to w opozycji to jednej z tez Clevelanda, w świetle której wartość informacji zależy od jej rozszerzania, która możliwa jest dzięki powszechności. Cleveland poszukuje wartości, jaka płynie dla społeczeństwa i jego rozważania nie koncentrują w tym przypadku na wartości informacji, dzięki której można osiągnąć przewagę konkurencyjną. Można jego tezę odnieść do wnętrza organizacji, ponieważ wątpliwe wydaje się, aby radykalne ograniczanie dostępu do gromadzonych informacji wewnątrz organizacji miało pozytywny wydźwięk ekonomiczny. Na gruncie rynkowym przyswojenie przez organizację unikalnej i jej tylko dostępnej informacji może przyczynić się do wzrostu przewagi konkurencyjnej. Jednak w przestrzeni publicznej większość informacji jest powszechnie dostępna, co oznacza, że potencjalnie każda organizacja może ją wykorzystać w celu osiągania przewagi konkurencyjnej. Zatem w chwili gdy dwie organizacje będą w posiadaniu tej samej ogólnodostępnej informacji, osiągnięcie przewagi może być wątpliwe. Powstaje zatem pytanie, czy możliwe jest przekroczenie bariery powszechności, zmniejszającej wartość informacji i wykorzystanie powszechności w celu zdobycia przewagi na rynku?162 W tym miejscu należy przywołać kwestię omawianej triady decyzyjnej. W triadzie tej wyróżniliśmy trzy elementy: dane, informacje oraz wiedzę. Informację tworzymy dzięki zinterpretowaniu danych. Sama interpretacja zależy od kontekstu, w którym lokujemy wykorzystywane dane. Otóż to właśnie dzięki kontekstowi powszechnie zaistniałe informacje możemy ponownie przetworzyć i potraktować jako dane, które w kolejnym etapie podlegają nowym procesom interpretacji. Dzięki przetworzeniu ogólnodostępnej Wskazują jednak na istotny trend, który potwierdza się w obecnym okresie. Por. Fayyad U., Uthurusamy R. (2002), Evolving data into mining solutions for insights, Communications of the ACM 45(8), s Gaudin S. (2012), Physicist says Moore's Law is 'collapsing', Computerworld, May 2, Por. Cleveland H. (1982), Information as a resource, Futurist, Dec. 1982, s W świetle współczesnych tendencji wiążących się z otwartością (np.: modele biznesowe uwzględniające oferowanie oprogramowania open source), kwestia powszechności vs. prywatności informacji zyskuje nowe światło i nie jest tak spolaryzowana, jak to ukazano. 152

153 informacji w dane oraz ich nowej interpretacji powszechność informacji nie stanowi ograniczenia dla niesienia przez nią wartości oraz osiągania przewagi konkurencyjnej. W świetle badań przeprowadzonych przez MIT Center for Digital Business organizacje, które określają siebie jako ukierunkowane przez dane osiągają lepsze wyniki finansowe i operacyjne163. Organizacje nakierowane na podejmowanie decyzji popartych danymi są potencjalnie lepiej przygotowane do trudnego zadania tworzenia informacji z ogólnodostępnych rozproszonych danych. Mają zatem szanse na szybsze i efektywniejsze wykorzystanie potencjału zjawiska Big Data. Jak jednak powinniśmy ujmować ten fenomen? Spróbujmy przywołać niektóre z definicji. Przez Big Data rozumie się: techniki i technologie, które czynią operacje na danych o ogromnej skali dostępnymi ekonomicznie 164; nową generację technologii i architektur zaprojektowanych do uzyskania ekonomicznej korzyści z dużych wolumenów zróżnicowanych danych dzięki szybkiemu rejestrowaniu, odkrywaniu i/lub analizie 165; dane, których rozmiar zmusza nas do spojrzenia poza wypróbowane metody [operowania danymi T.K.], jakie dostępne są w teraźniejszym czasie 166. Ostatnia z definicji ukazuje historyczny rys powiązany ze zjawiskiem Big Data. Już w latach 80-tych zbiory danych były na tyle duże, że wymagały zmiany tysięcy taśm w zrobotyzowany sposób. W latach 90-tych oznaczało to wykorzystanie raczej aplikacji Unixowych, aniżeli aplikacji PC. W końcu współcześnie oznacza to być może porzucenie relacyjnego modelu baz danych oraz wykorzystanie systemów rozproszonych i przetwarzania równoległego. Zauważmy, że są to kolejne przykłady na ograniczenia związane z operowaniem danymi oraz ewentualnym wykorzystaniem ich na potrzeby przeprowadzanej analizy. Z przywołanych definicji wyróżnić powinniśmy następujące elementy: ekonomię, dane oraz technologie (składowania, analiz itp.) z nimi powiązane. Ekonomicznie uwarunkowana dostępność. Zarówno wdrożenie repozytoriów Big Data, jak i przenoszenie do nich danych można uznać za atrakcyjne z ekonomicznego punktu 163 Brynjolfsson E., Hitt L., Kim H. H. (2011), Strength in Numbers: How does data-driven decisionmaking affect firm performance? w ICIS 2011 Proceedings, December 6, 2011, Paper Hopkins B., Evelson B. (2011), Expand Your Digital Horizon with Big Data, Forrester Research, Inc., September 30, 2011, s Olofson C., Vesset (2012), Big Data: Trends, Strategies, and SAP Technology, Technical report, No , IDC, s Jacobs A. (2009), The pathologies of big data, Communications of the ACM 52(8), s

154 widzenia. Analizy dokonywane przez ekspertów od danych nie muszą opierać się na czasochłonnym procesie integrowania, oczyszczania i agregowania danych. Co więcej, dla specjalistów tych dostępne są środowiska przetwarzania równoległego, w których wykorzystywać mogą na przykład techniki drążenia danych na znacznych wolumenach danych przy użyciu transformacji wymagających niewielkich skryptów167. Duże znaczenie dla kontekstu ekonomicznego ma także możliwość implementacji środowisk analitycznych Big Data w chmurach obliczeniowych. Przy czym wszelkie pozytywne cechy ekonomiki chmur obliczeniowych mają tu zastosowanie168. W odróżnieniu od tradycyjnych środowisk analitycznych bazujących na systemach klasy BI, systemy analityki Big Data, nie muszą podlegać procesom integracji, a jedynie pożądanej dla analizy transformacji danych. Ten aspekt ma kolosalne znaczenie z punktu widzenia czasu koniecznego dla przeprowadzenia unikalnych analiz, gdyż etap integracji zostaje pominięty. Pominięcie etapu integracji bez wątpienia może przyczynić się do ograniczenia kosztów związanych z analityką. Taka strategia wiąże się z możliwością braku absolutnej precyzji, która jednak dla wielu problemów decyzyjnych nie ma krytycznego znaczenia. Dane. Charakterystyka fenomenu Big Data bez wątpienia uzależniona winna być od właściwego spojrzenia na specyfikę samych danych. Typowo przypisuje się im trzy kluczowe cechy (3V): skala (volume), szybkość (velocity) i różnorodność (variety): skala przywołany lawinowy wzrost danych jest głównym czynnikiem charakteru zjawiska Big Data. Skala jednak Big Data nie zależy jedynie od danych globalnej sieci. Coraz częściej to same organizacje generują dane, których wolumeny wykraczają poza możliwości składowania i analizy w tradycyjnych architekturach bazodanowych i aplikacjach analitycznych; szybkość dane przemieszczają się z coraz większą prędkością. Ten fakt ma ogromne znaczenie choćby w przypadku usług i rynków finansowych. Szybkość przemieszczania się danych oraz szybkość i częstotliwość rejestrowania zdarzeń (np.: o charakterze lokalizacyjnym) mogą być skutecznie wykorzystywane nie tylko przez brokerów finansowych, ale także przez sieci handlowe, firmy telekomunikacyjne, gdzie właściwa i szybka reakcja na zmiany ma coraz większe znaczenie; 167 Hopkins B., Evelson B. (2011), Expand Your Digital Horizon with Big Data, Forrester Research, Inc., s Por. rozdz analiza ETO, a zwłaszcza ekonomiczne uwarunkowania funkcjonowania chmur obliczeniowych. 154

155 różnorodność różnorodność wskazuje tu nie tylko na zmienność pochodzenia danych i ich znaczenie czy kategorie. Oznacza także różnorodność ich formatów od plików tekstowych po dane generowanych przez sensory. Technologie. Systemy analityki biznesowej zyskują nowe światło, które jeszcze dekadę temu nie było w jej zasięgu. Można wysnuć przypuszczenie, że wpłynęła na to nie tylko sama ilość i różnorodność danych, ale także nowe możliwości ich składowania i przetwarzania. Na horyzoncie oferowanych rozwiązań składowania danych, oprócz produktów opartych na klasycznych relacyjnych bazach danych, pojawiło się wiele rozwiązań określanych mianem NoSQL. Rozwiązania NoSQL cechują między innymi możliwości obsługi dużych wolumenów danych i szybkości rejestrowania transakcji, architektura rozproszona oraz obsługa nieustrukturyzowanych danych. Do modeli NoSQL zaliczyć można bazy klucz-wartość, bazy dokumentowe, grafowe czy kolumnowe. Nie każdy rodzaj danych lub ich ilość czy zróżnicowane pasują do jednego modelu infrastruktury bazodanowej. Np.: dokumenty kodowane przy użyciu XML mogą być przechowywane w bazach XML, a relacje w sieciach społecznościowych z natury są grafami i bardziej pasują do bazy grafowej. Jeżeli organizacja stosować będzie wiele rożnych modeli składowania danych co skutkuje dodatkowym rozproszeniem systemów, to staje między innymi przed problemem integracji heterogenicznych modeli (np.: problem dostępu do platform NoSQL przez standardowe aplikacje BI). W chwili gdy konwencjonalne infrastruktury baz relacyjnych nie mogą obsłużyć znaczących wolumenów danych, wśród głównych możliwości technologicznych należy wymienić architekturę MPP (ang. massively parallel processing architecutre) oraz rozwiązania oparte o platformę Hadoop. Decyzja o wyborze jednej z tych opcji zależy gównie od stopnia różnorodności danych oraz konieczności zmienności schematów danych: hurtownie danych bazujące na architekturze MPP oparte są na definiowanych schematach, podczas Hadoop nie stawia ograniczeń co do struktury danych. W świetle powyższej charakterystyki może powstać pytanie, czy systemy analityki Big Data nie są po prostu rozwiązaniami, które przyrównane mogą być do tradycyjnych rozwiązań analityki biznesowej takich jak business intelligence? Bez wątpienia posiadanie dużych ilości danych, obecne już w początkach rozwoju sieci www czy elektronicznego handlu, musi podlegać właściwym metodom analizy powiązanych z terminem określanym mianem analityki odkrywającej. Realizowana może być ona przy użyciu narzędzi bazujących na SQL, drążeniu danych, analizie 155

156 statystycznej, wizualizacji danych, przetwarzaniu języka naturalnego i tekstu itp. Analitycy Big Data próbują odkrywać nowe nieznane dotychczas fakty, zaś typowe rozwiązania BI związane są w większości przypadków z raportowaniem tego, co wiemy o niewiadomych: Hurtownie danych i narzędzia BI świetnie odpowiadają na na powtarzane w koło pytania takie jak: «jaka była sprzedaż Marii w tym kwartale?». Jednak gorzej sprawdzają się w badawczych, nieprzewidywalnych pytaniach co-jeżeli, które mają znaczenie dla planowania i podejmowania decyzji, ponieważ szybka eksploracja niestrukturyzowanych danych jest typowo trudna do przeprowadzenia, a tym samym kosztowna 169. Funkcjonowanie systemów przetwarzających dane źródłowe opiera się na swoistej zasadzie ograniczania wolumenu danych, ponieważ część danych w procesie oczyszczania jest tracona. Dane z obszaru Big Data podlegać powinny zasadzie opierającej na składowaniu danych, a ściślej dyktacie utrzymywania wszelkich danych, o ile to możliwe. Przeciwdziałanie utracie danych może przyczynić się do trafniejszych decyzji. Z punktu widzenia przeprowadzanych analiz skala Big Data zapewnia gigantyczne próbki statystyczne, co niewątpliwie usprawnia takie metody analiz jak drążenie danych czy analizy statystyczne. Ponadto techniki zaawansowanej analizy Big Data są relatywnie sprawne w uzyskiwaniu pożądanych rezultatów z nieprzetworzonych danych źródłowych, z danych o niskiej jakości, danych niestandardowych. W tym kontekście dobrym przykładem jest wykrywanie oszustw przy użyciu systemów analityki Big Data. Mają tu bowiem znaczenie wszelkie dane będące sygnałem odstępstwa, które może być przeoczone w chwili stosowania tradycyjnych metod oczyszczania danych i procesów ETL, jeśli wykorzystywane są w we wspomnianych systemach. Powszechność informacji oraz zaawansowane możliwości analizy i interpretacji wymuszają podejmowanie określonych działań, mających na celu efektywne wykorzystanie zjawiska Big Data przez organizacje. Barton i Court wymieniają trzy główne typy strategii, które firmy powinny opanować, aby wykorzystać potencjał Big Data Wybór właściwych danych. Różnorodność danych jako cecha Big Data wymusza sprawny dobór źródeł danych. Właściwe zadanie decydentów i analityków odpowiedzialnych za formowanie infrastruktury i jej wykorzystanie polega na 169 Croll A. (2012), Three Kinds of Big Data w Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s Barton D., Court D. (2012), Making Advanced Analytics Work for You, Harvard Business Review 90(10), s

157 dopasowaniu źródeł danych do konkretnych problemów biznesowych lub do pojawiających się szans rozwoju przedsięwzięć. Koniecznym warunkiem osiągania wartości z określonych typów danych jest uzyskanie wsparcia działów IT, gdyż infrastruktura IT często nie jest przystosowana do integracji wielu typów danych, a zwłaszcza danych niestrukturyzowanych. Zainteresowane strony mogą wykorzystać taktykę krótkoterminową, dzięki której identyfikowane i łączone są najważniejsze dane. 2. Tworzenie modeli przewidujących i optymalizujących wyniki. Najprawdopodobniej najefektywniejsza strategia dotycząca Big Data nie zaczyna się od danych, ale raczej od określenia, jak model analityczny (statystyczny) będzie wpływać na poprawienie wyników. Konieczne jest przy tym zachowanie względnej prostoty modelu, gdyż jego złożoność wpływa na wydajność systemów. 3. Przemiany organizacyjne. Po pierwsze, analizy powinny być zorientowane na codzienne działania i procesy do nich dopasowane. Oznaczać to może choćby ustanowienie zespołu zadaniowego do spraw analityki, który na przykład podczas spotkań z menedżerami odpowiedzialnymi za politykę cenową i promocje może precyzyjnie określać typy podejmowanych decyzji, koniecznych do ustalania konkretnych polityk. Pozwolić to może na skuteczny dobór narzędzi, które wspierać mogłyby procesy decyzyjne. Po drugie, zaawansowane modele powinny być implementowane na potrzeby pracowników pierwszej linii. Po trzecie, organizacja powinna wzbogacać możliwości wykorzystywania modeli przez decydentów, co osiągane być może dzięki zapewnianiu szkoleń lub mierzeniu wpływu i wykorzystywania modeli wraz z ewentualnym promowaniem i wynagradzaniem praktyk mających na celu stosowanie systemów analityki Big Data. Zjawisko Big Data jest obecnie przedmiotem szerokiego zainteresowania, jednak w celu wdrożenia jakiejkolwiek strategii powiązanej z tym zjawiskiem organizacje muszą odpowiedzieć na pytanie, czy potencjał analityczny tego zjawiska przyniesie pożądane korzyści. Zasadniczo można je osiągnąć w trzech głównych obszarach. Analityka klienta. Era internetu zmieniła sposób rozumienia zachowań klientów i właśnie dlatego duże sieci internetowe wypchnęły w wielu przypadkach firmy tradycyjne. Pośrednim tego przejawem jest przemiana tradycyjnego modelu marketingowego (4P) w 157

158 modele uwzględniające dodatkowy komponent, a mianowicie ludzi, których działania i decyzje w erze cyfrowej mogą być w precyzyjny sposób analizowane: W chwili gdy klienci zaczęli dokonywać zakupów w sieci, zrozumienie ich zachowań znacząco wzrosło. Detaliści sieciowi mogą śledzić nie tylko to, co kupili klienci, ale także to, co obserwowali; jak poruszali się po sklepie; jak bardzo podatni byli na promocje, recenzje i układ stron; jakie wykazywali podobieństwa do innych kupujących lub ich grup. Natychmiast zaczęli tworzyć algorytmy przewidujące, jakie książki klienci chcieliby przeczytać algorytmy, które poprawiają swe działanie za każdym razem, gdy klient odpowiada na rekomendację lub ją ignoruje. Tradycyjni detaliści po prostu nie mają dostępu do tego typu informacji, nie mówiąc o dostępie do nich we właściwym czasie. Nie dziwi zatem, że Amazon zmusił wiele tradycyjnych firm (ang. brick-and-mortar) do wycofania się z rynku 171. Z punktu widzenia danych transakcyjnych pojedynczy wpis w serwisie społecznościowym nie niesie tyle informacji co konkretny zapis transakcji. Jednak wartość informacyjna tych dwóch różnych źródeł (danych transakcyjnych i nietransakcyjnych) wzrasta po ich powiązaniu. Np.: specjalnie filtrowane ogromne ilości komentarzy mogą być powiązane z historią zakupów danego produktu lub kampanii sprzedażowej. Do specyficznych zastosowań systemów analityki Big Data w obszarze powiązanym z działaniami i zachowaniami klientów należy zaliczyć: wpływ zachowań w społecznościach na działania marketingowe, segmentację baz klientów, rozpoznawanie cech sprzedaży oraz szans rynkowych. Należy tu podkreślić, że analityka Big Data odniesiona do klientów wnosi istotną wiedzę, gdyż zarejestrowane fakty dotyczące transakcji lub preferencji nie dają odpowiedzi między innymi na pytanie dlaczego?. W ogólnym ujęciu informacje uzyskiwane dzięki Big Data wykraczają poznawczo poza informacje o faktach dostarczają wiedzy o tym, co mogło się wydarzyć, co powinno się wydarzyć lub co się wydarzy 172. Rozszerzenie potencjału BI. Dzięki analizom predykcyjnym, drążeniu danych, analizie wieloczynnikowej czy wizualizacji danych systemy analityki Big Data znacznie poszerzają możliwości tradycyjnych środowisk BI. Systemy analityki Big Data wydają się naturalnym rozwinięciem tradycyjnych systemów BI i należy je rozumieć jako dziedzinę szeroko rozumianych systemów analityki biznesowej. Nie oznacza to jednak, że należy je 171 McAfee A., Brynjolfsson E. (2012), Big Data: The Management Revolution, Harvard Business Review, 90(10), s Swoyer S. (2012), Big Analytics: The Next Generation w Big Data Analytics. TDWI E-book, s. 9, TDWI Inc., September

159 traktować jako tylko niezależne. Przeciwnie, w wielu wypadkach konieczne jest całościowe spojrzenie na analizowane problemy, które uwzględnia nie tylko optykę Big Data, ale także zastane platformy analityczne. Różnorodność danych sprawia, że niektórym przypisuje się odrębne znaczenie. Tymczasem stanowią one część informacyjnego kontinuum. Właśnie dlatego należy się spodziewać, że informacje pochodzące ze źródeł Big Data zasilać będą tradycyjne raporty czy kokpity menedżerskie, a wiele organizacji już stosuje takie rozwiązania. Ponadto część zastosowań analityki Big Data realizowana jest w przestrzeni korporacyjnych hurtowni danych (EDW), wpisując się ściśle w klasyczną architekturę systemów klasy BI. Zastosowania tematyczne. Choć możliwość wykorzystania Big Data na polu analizy zachowań klientów jest najczęściej podkreślana, Big Data to nie tylko analityka klienta. Istnieje szereg zastosowań, które nie są bezpośrednio powiązane z tym obszarem. Zaliczyć do nich można między innymi: optymalizację logistyki i operacji w łańcuch dostaw, kwantyfikację ryzyk czy aplikacje mające na celu wykrywanie oszustw. Za istotną korzyść uznać można także możliwość automatyzacji procesów biznesowych w czasie rzeczywistym, np.: podejmowanie decyzji o przyznaniu kredytu. Pomimo znaczącego potencjału systemów analityki Big Data, ich stosowanie wiąże się z istotnymi barierami, które podzielić można na organizacyjne i techniczne. Już przy pierwszym spojrzeniu na zagadnienie Big Data, może pojawić się wątpliwość, czy dana organizacja będzie w stanie podjąć się wyzwań powiązanych z Big Data. Jedną z najczęściej wymienianych barier jest bariera wiedzy oraz koniecznych zasobów ludzkich173. Istotnie, analizy przeprowadzane w oparciu o repozytoria Big Data wymagają swoistych kompetencji, które znacząco wykraczają poza typową wiedzę przyswajaną przez analityków z obszaru business intelligence. Kompetencje te wiążą się choćby z umiejętnościami projektowania i tworzenia architektury Big Data oraz zapewnieniem jej użyteczności dla użytkowników końcowych. Rozwój zjawiska Big Data wpłynął na nowy obszar nazywany nauką o danych (ang. data science). Obejmuje on swoim zakresem takie dziedziny jak matematykę, programowanie oraz wiąże się ze swoistym zmysłem naukowym. Dziedzina ta, która ma szczególne znaczenie dla analityki Big Data, doprowadziła do wyłonienia się nowych kompetencji osób odpowiedzialnych za przygotowywanie analiz i ich udostępnianie ekspertów od danych (ang. data scientist). Do cech charakteryzujących tę nową rolę w organizacjach należy zaliczyć: ekspercką wiedzę w konkretnej dziedzinie naukowej, 173 Russom P. (2011), Big Data Analytics, TDWI Research, s

160 zdolność do rozkładania problemów na zestaw możliwych do testowania hipotez, umiejętność efektywnego komunikowania rezultatów (skomplikowane analizy muszą zostać w odpowiedni sposób przyswojone przez osoby korzystające z rezultatów) oraz zdolność do spojrzenia na problemy z wielu kreatywnych stron. Jedną z powszechnych barier funkcjonowania systemów analityki Big Data jest przywiązanie ich do zespołów odpowiedzialnych za tradycyjne środowisko hurtowni danych i business intelligence. Tymczasem, jak przekonuje Russom, większość zastosowań Big Data ma charakter ściśle powiązany z działaniem konkretnych departamentów. Pokrywa się to zresztą z wymienionymi obszarami zastosowań omawianego zjawiska. Ponadto wiele inicjatyw powiązanych z Big Data wychodzi od konkretnych działów, które w wielu przypadkach są w stanie zapewnić konieczne fundusze do ich realizacji. Właśnie dlatego szansą dla wielu projektów Big Data jest wsparcie ekspertów od danych, niekoniecznie związanych z korporacyjnym zespołem analitycznym. Większość współczesnych środowisk analitycznych stanowi istotną barierę techniczną dla realizacji inicjatyw powiązanych z Big Data. Jedną z głównych przeszkód natury technicznej jest skalowalność zastanych środowisk. Przy czym skalowalność oznacza tu niedopasowanie większości środowisk BI do skali wolumenów danych. Napotyka się także problemy szybkiego przetwarzania niejednokrotnie równoległych zapytań oraz ładowania danych. Ponadto wiele problemów może pojawić się jeśli hurtownie danych modelowane są jedynie pod kątem raportów i OLAP. Te problemy mogą przyczynić się do decyzji o zmianie architektury platformy analitycznej. Według badań przeprowadzonych przez TDWI Research174 połowa firm nie planuje zmiany obecnych platform analitycznych. Wiąże się to częstokroć z brakiem koniecznych funduszy, a także zaspokojeniem obecnych potrzeb w zakresie analityki biznesowej. Jedna trzecia badanych organizacji zamierza wymienić obecne platformy w ciągu trzech lat. Całkowita wymiana platformy analitycznej nie zawsze jest możliwa czy pożądana. Jak widzieliśmy, naturalną drogą dla zastosowania systemów analityki Big Data są choćby inicjatywy mające na celu realizację środowisk wykorzystujących potencjał omawianego fenomenu na poziomie departamentów. W praktyce oznacza to stosowanie dwóch równoległych systemów analitycznych, co prowadzi co istotnych zależności między danymi z równoległych platform. Z jednej strony aplikacje Big Data mogą wykorzystywać na swoje potrzeby dodatkowe dane z hurtowni danych. Z drugiej zaś w wielu przypadkach rezultaty analiz dokonanych przy użyciu aplikacji funkcjonujących w niezależnych 174 Ibid., s

161 systemach analityki Big Data mogą zasilać hurtownie danych, a w konsekwencji platformę BI. Jeżeli zatem analityka Big Data ma stać się rozszerzeniem tradycyjnych platform BI, technologie Big Data muszą być uzupełniane o narzędzia integracji danych łączące te dwa środowiska, o ile funkcjonować będą jako oddzielne platformy. Decyzja o wdrożeniu odrębnych platform analitycznych (Big Data i BI) zależy między innymi od odpowiedzi na następujące pytanie: czy korporacyjna hurtownia danych będzie w stanie sprostać wymaganiom skali Big Data bez wpływu na jej dotychczasowe zadania, związane choćby z raportowaniem lub OLAP? Pytanie to ostatecznie sprowadza się do kwestii obsługi dostatecznej ilości zadań oraz związanego z nimi obciążenia. W końcu, czy będzie ona w stanie efektywnie przetwarzać dane o specyfice Big Data? Wiele implementacji korporacyjnych hurtowni danych spełnia takie oczekiwania, między innymi dzięki analityce in-database. Zdarza się jednak, że obciążenia związane z zarządzaniem Big Data i zaawansowanymi analizami są na tyle znaczne, że ich stosowanie w obrębie korporacyjnej hurtowni danych jest nie do przyjęcia. Dodatkowym problemem natury technicznej jest stosowanie ETL w odniesieniu do Big Data (np.: dane dzienników systemowych lub pochodzące z sensorów ładowane do baz analitycznych)175. Co więcej, ewolucja hurtowni danych nakreśliła ich typowy charakter: Istniejące korporacyjne hurtownie danych i bazy relacyjne celują w przetwarzaniu danych ustrukturyzowanych i mogą przetrzymywać ogromne zbiory danych, jednak za pewną cenę: wymóg ustrukturyzowania ogranicza możliwość przetwarzania pewnych typów danych i wprowadza inercję, która sprawia, że hurtownie danych są niedopasowane do sprawnej eksploracji heterogenicznych danych o dużej skali. Rozmiar wysiłku wkładanego w składowanie danych (w hurtowniach) sprawia, że wiele cennych źródeł danych nigdy nie jest analizowane. Właśnie w tym aspekcie Hadoop może doskonale się sprawdzić 176. Platforma Hadoop jest obecnie jednym z najczęściej stosowanych rozwiązań zapewniających obsługę ogromnych wolumenów danych. Jej głównymi zaletami jest skalowalność oraz możliwość przetwarzania równoległego. Te dwie zalety osiągane są głownie dzięki architekturze sprzętowej opartej na tanich masowo tworzonych serwerach. Dzięki rozproszonemu systemowi plików (HDFS, ang. Hadoop Distributed File System) Hadoop zapewnia obsługę danych zawartych w plikach, co zdecydowanie usprawnia 175 Croll A. (2012), Three Kinds of Big Data, op. cit., s Dubmill E. (2012), What is Big Data? w Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s

162 proces ich przechowywania. Przy zastosowaniu tradycyjnej bazy relacyjnej dane wymagałyby modelowania, integracji i ładowania. Dodatkowym komponentem platformy Hadoop jest framework MapReduce, który uzupełnia HDFS o możliwą analitykę. Hadoop na obecnym etapie wiąże się z między innymi z takimi problemami jak manualne kodowanie zadań MapReduce, wymagające niezbędnej wiedzy i umiejętności. Ponadto główna warstwa platformy, HDFS nie spełnia zasad ACID, co eliminuje ją z krytycznych zastosowań w korporacji. Właściwa realizacja platformy analitycznej Big Data zasadniczo może być realizowana na trzy sposoby: platforma software'owa, platforma sprzętowo-software'owa (np.: dzięki rozwiązaniom data warehouse appliance) lub przy użyciu chmur obliczeniowych. Wybór jednej z tych możliwości podlega uwarunkowaniom ekonomicznym, regulacyjnym i technicznym. Wolumeny danych w systemach analityki Big Data niejednokrotnie przekraczają możliwości ich przenoszenia (np.: z systemów i baz zewnętrznych). Jest to typowy problem funkcjonowania danych w środowiskach rozproszonych, a zwłaszcza w środowiskach chmur obliczeniowych o charakterze hybrydowym. W chwili gdy wolumeny przenoszonych danych, koniecznych do analizy przekroczą kryteria techniczne i ekonomiczne, organizacje mogą rozważyć przeniesienie platformy analitycznej do środowiska chmury obliczeniowej. Inna sytuacja dotyczy postulatu zerowego opóźnienia w przedsiębiorstwie i wiąże się także z transmisją danych. Tym razem jednak to nie wolumeny danych, ale opóźnienie w dostępie do nich ma znaczenie krytyczne. Dotyczy to głównie transakcyjnych systemów finansowych. W takich przypadkach, realizacja aplikacji w środowisku bliskim źródła powstawania danych może mieć istotne uzasadnienie biznesowe (opóźnienie niektórych operacji o milisekundy może mieć negatywny wpływ na przewagę konkurencyjną). Wspominaliśmy o ekonomicznych zaletach płynących z możliwości wdrożenia systemów analityki Big Data w środowisku chmur obliczeniowych. Naturalnie dotyczy to skali inwestycji oraz ewentualnego jej przełożenia na korzystne wyniki. Nie wszystkie bowiem organizacje są w stanie ponieść znaczące nakłady konieczne do wdrożenia platformy analitycznej w obrębie własnej infrastruktury IT (np.: przy użyciu takich rozwiązań jak jak rozwiązania typu software appliance). Co więcej, niektóre projekty mogą wiązać się jedynie z tymczasową potrzebą. Nawet jeśli platforma analityczna Big Data zdaje się być w zasięgu dane organizacji, z jej funkcjonowaniem wiążą się między innymi procesy wstępnego oczyszczania danych o 162

163 silnie nieuporządkowanym charakterze. Zanim zatem dojdzie do zastosowania konkretnych zbiorów danych i dokonania analiz, dane muszą przejść przez żmudny, wstępny proces przyswajania ich na potrzeby tych analiz177. W takich przypadkach organizacje mogą zrezygnować z tych procesów i korzystać z usług określanych mianem DaaS (ang. Data as a Service). Usługi tego typu wprowadzają nowy sposób z korzystania z potencjału zjawiska Big Data. Oferowane są na rynkach danych (ang. data marketplaces), gdzie usługodawcy udostępniają zbiory danych, z których korzystać mogą organizacje. Naturalnie usługodawcy w modelu DaaS zmierzać powinni do udostępniania danych oczyszczonych i względnie przetworzonych, a jakość dostępnych wolumenów wpływać będzie na konkurencyjność w obrębie tych rynków. Firmy sieciowe z reguły bazują na gromadzonych danych takich jak dane dzienników systemowych, historyczne dane interakcji internautów z serwisami www lub dane o reakcjach na kampanie reklamowe, ale obecność Big Data jest szansą także dla firm tradycyjnych. Decyzja odnośnie zastosowania systemu analityki Big Data zależy od zdolności organizacji do wdrożenia platformy. Dzięki środowiskom chmur obliczeniowych możemy sobie wyobrazić sytuację, w której nawet stosunkowo niewielkie przedsiębiorstwa będą mogły korzystać z zasobów, których nie mogłyby przetwarzać w tradycyjnych środowiskach. Zatem przede wszystkim w systemach rozproszonych, bariery płynące z rozproszenia danych, ich heterogeniczności i szybkości przemieszczania się oraz przeszkody natury organizacyjnej mogą być łatwiej pokonywane i skutecznie wykorzystywane przez niemalże dowolną organizację Rozwiązania Business Intelligence w środowiskach chmur obliczeniowych W niniejszej części przyjrzymy się bliżej możliwościom i ograniczeniom stosowania systemów klasy Business Intelligence w środowiskach chmur obliczeniowych. W tym celu wykorzystamy rezultaty analizy ETO przeprowadzonej w poprzednim rozdziale. Poza aspektami ekonomicznymi, technicznymi i organizacyjnymi funkcjonowania chmur obliczeniowych warto zasygnalizować fakt, że w ostatnim czasie doszło do pewnego rodzaju polaryzacji źródeł wiedzy wykorzystywanej na potrzeby podejmowania 177 Szacuje się, że około 80% zadań związanych z danymi w rozwiązaniach Big Data, polega na wstępnym oczyszczaniu lub jak ujmuje to Pete Warden zamianie nieładu danych w coś użytecznego. Por. Dubmill E. (2012), What is Big Data?, op. cit., s

164 decyzji. W początkowych stadiach rozwoju systemów wspomagania decyzji, a w szczególności w systemach klasy Business Intelligence decyzje oparte były o dane pochodzące w głównej mierze z systemów przynależących do danej organizacji. W pewnym momencie zaczęto jednak brać pod uwagę dane niepochodzące z systemów informacyjnych organizacji. Diametralnie zmienił się kontekst tworzonych informacji. Bez wątpienia te procesy świadczą o dynamice rozpraszania się zasobów informacyjnych wraz rozszerzaniem kontekstów podstawy decyzyjnej. Ukazaliśmy już pośrednio te zamiany na przykładzie systemów analityki Big Data, gdzie dzięki skali oraz różnorodności danych kontekst dla decyzji ulega rozszerzeniu. Polaryzacja źródeł wiedzy wiąże się jednak z istotnym wyzwaniem, jakim jest ich dobór, weryfikacja oraz przyswajanie. Usługi webowe oraz usługi DaaS stają się towarem ułatwiającym wspomniane zadania. Świadczą one o wyłanianiu się dostarczycieli danych oraz ich konsumentów. Organizacje mogą zatem podjąć decyzję o przyjęciu postawy wobec tego rozróżnienia. Oczywiście nie oznacza to, że konkretna organizacja ma całkowicie stać się konsumentem danych. Zgodnie z wcześniejszymi ustaleniami zależy to od możliwości przyswajania danych na potrzeby własnych środowisk analitycznych (kompetencje i inwestycje). Ponadto, nawet przy posiadaniu potencjału do przyswojenia danych pochodzących z zewnętrznych źródeł istotną rolę może ogrywać czas konieczny do adaptacji tych źródeł. W tym świetle dana organizacja może zadać sobie kluczowe pytanie: czy środowisko analityczne musi być ściśle i zawsze realizowane z ramach wewnętrznej infrastruktury IT? Swoistą alternatywą może tu być wdrożenie systemów analitycznych w środowiskach chmur obliczeniowych. Alternatywa zarysowana w poprzedniej części odnosi się w głównej mierze do systemów analityki Big Data. Jednak modele chmur obliczeniowych mogą w efektywny sposób zaspokoić szersze spektrum systemów analityki biznesowej. Wyróżnione warstwy tradycyjnej architektury BI, takie jak warstwa integracji, składowania, analityczna i prezentacji mogą być wdrażane w środowiskach chmur obliczeniowych. Jednak skuteczność realizacji platformy BI w tych środowiskach na obecnym etapie uzależniona jest od wielu czynników. Jak wspominaliśmy w poprzednim rozdziale, w chmurach obliczeniowych usługi są dostarczane w trzech głównych modelach: IaaS, PaaS, SaaS. Ich charakterystyka może być odniesiona do platform business intelligence wdrażanych w chmurach obliczeniowych: IaaS. Platforma BI może być tworzona od podstaw w środowisku chmur obliczeniowych. Oznacza to, że cała istniejąca platforma, realizowana przy użyciu 164

165 infrastruktury IT danej organizacji może zostać przeniesiona do chmury. Dotyczy to zatem nie tylko warstwy samej architektury platformy, ale także jej sprzętowej infrastruktury opartej na mocy obliczeniowej, pamięciach masowych, czy też infrastrukturze sieci. PaaS. W ścisłym sensie PaaS zapewnia predefiniowaną platformę umożliwiającą tworzenie aplikacji. W kontekście BI w platformach tych tworzone aplikacje biznesowe mogą być wzbogacane o dodatkowe funkcje lub komponenty analityczne. Ponadto w usługach tych deweloperzy mogą także tworzyć dopasowaną do swoich potrzeb platformę BI. Do modelu tego zaliczymy także rozwiązania umożliwiające implementację wszelkich warstw architektury BI (warstwę integracji, składowania, aplikacji i prezentacji). Zasadniczą cechą tego modelu usługowego jest możliwość tworzenia i dopasowywania platformy BI na potrzeby organizacji w przestrzeni chmury obliczeniowej. SaaS. Model ten realizowany jest na najwyższym poziomie abstrakcji w modelach chmur obliczeniowych, czyli na poziomie aplikacji. W modelu SaaS BI środowisko analityczne oferowane jest jedynie w warstwach aplikacji i prezentacji architektury BI. Z reguły oferowane aplikacje BI mają charakter rozwiązań dedykowanych i ukierunkowanych na specyficzną formę analiz dopasowaną niejednokrotnie do konkretnych systemów źródłowych lub zastosowań branżowych. Dwa z przedstawionych powyżej modeli (IaaS i PaaS) stwarzają możliwość pełnej realizacji platformy BI w środowisku chmury obliczeniowej. Potencjał tych modeli na obecnym etapie rozwoju technologii oraz w świetle uwarunkowań poza-technicznych jest trudny do maksymalnego wykorzystania. Innymi słowy, wykorzystanie tych dwóch typów usług oferowanych w chmurach obliczeniowych wiąże się z istotnymi ograniczeniami. Uporządkować je można w trzy główne grupy, stosownie do kategoryzacji dokonanej w analizie ETO chmur obliczeniowych: uwarunkowania funkcjonowania danych, kwestie bezpieczeństwa oraz dostępności zasobów oraz platformy. Funkcjonowanie danych. Systemy klasy BI bez wątpienia są silnie uzależnione od uwarunkowań funkcjonowania danych, których charakterystyka w dokonanej analizie ETO chmur obliczeniowych ma wyraźnie ujemne cechy. Wyróżniliśmy choćby takie problemy jak: modelowanie i migracja danych, nieokreślona lokalizacja danych oraz ich transfer. Głównym problemem obecnych zastosowań chmur obliczeniowych na polu systemów analityki biznesowej jest uzależnienie platform BI realizowanych w chmurach od wewnętrznej infrastruktury informatycznej organizacji. Oznacza to, że platformy BI wdrażane poza organizacjami mają stosunkowo marginalny charakter i częstokroć warunkują zaistnienie środowisk hybrydowych. W przypadkach takich dochodzi do 165

166 istotnego ruchu danych między infrastrukturą organizacji, a rozwiązaniami analitycznymi wdrażanymi w chmurach. Ruch ten zachodzić może w dwóch kierunkach. Z jednej strony rezultaty analiz przeprowadzanych w chmurze mogą być wykorzystywane w systemach wewnętrznych. Z drugiej wewnętrzne systemy organizacji mogą być źródłami dla analiz w chmurze. Warto przy tym zaznaczyć, że dane źródłowe pochodzić mogą także z repozytoriów i systemów zlokalizowanych w przestrzeni publicznej. Fakt ten znacząco wpływa na charakter rozproszenia zasobów informacyjnych. Fakt przemieszczania się danych oraz możliwość wykorzystywania współbieżnie wielu rozproszonych aplikacji analitycznych wymaga precyzyjnie zaplanowanych procesów integracji, harmonizowania danych, unifikacji ich znaczenia i struktur. Ponadto same technologie zapewniające transmisję danych mogą znacząco ograniczyć możliwości realizacji platformy BI w środowiskach chmur obliczeniowych. Architekci systemów BI muszą także podejmować decyzje, gdzie i jak powinna być wdrożona warstwa integracji (np.: gdzie powinny realizowane być procesy ETL lub czy w grę wchodzą rozwiązania federacyjne?). Bezpieczeństwo. Wdrożenie platformy analitycznej w chmurze obliczeniowej wiąże się z naturalnymi obiekcjami co do bezpieczeństwa danych. Jednak oprócz bezpieczeństwa samych danych w grę wchodzą także kwestie autoryzacji i ról przydzielanych w ramach wdrażanej platformy. Bezpieczeństwo zatem jest w tym kontekście ściśle powiązane z zaistnieniem potrzeby tworzenia spójnej polityki IT oraz określeniem procesów kontroli danych i aplikacji umiejscowionych w przestrzeni chmur obliczeniowych. Mimo narzucających się obaw dotyczących utraty kontroli nad systemami i danymi, badania Gartnera wskazują na coraz częstsze stosowanie aplikacji oferowanych w chmurach obliczeniowych, pomimo jawnych barier tego typu modeli przetwarzania178. Obecny etap rozwoju chmur obliczeniowych przypomina pod tym względem początki rozwoju handlu elektronicznego, kiedy to wiele organizacji wykazywało podobne obawy. Dostępność zasobów i wydajność. Bez wątpienia systemy analityki biznesowej powiązane są wysokimi wymaganiami szybkości przetwarzania. Architektura sprzętowa oferowana w chmurach w wielu przypadkach może nie w pełni zaspokoić potrzeb typowego środowiska BI. Jej potencjał tkwi jednak w możliwościach przetwarzania równoległego, do którego dostosowana powinna być choćby architektura warstwy składowania. Ta ostatnia w typowych zastosowaniach BI z reguły opiera się na bazach rezydujących na jednym systemie (węźle) powiększanym w miarę zapotrzebowania 178 Thoo E. (2009), Data In the Cloud: The Changing Nature of. Managing Data Accessibility, Gartner RAS Core Research Note G , Gartner Inc. 166

167 większych wolumenów danych. Tymczasem rozproszona architektura systemów oferowanych w chmurach obliczeniowych oparta jest w głównej mierze na technologiach wirtualizacji, która niesie za sobą istotne konsekwencje dla wydajności (brak szybkich połączeń między węzłami, brak szybkich operacji I/O czy bezpośrednio podłączonych pamięci masowych). Umiejscowienie platformy analitycznej w środowisku chmury obliczeniowej wiąże się zatem z istotnymi ograniczeniami, które wykluczają w wielu przypadkach wykorzystanie potencjału systemów rozproszonych. Oznacza to, że na obecnym etapie nie wszystkie projekty wdrożenia platform BI mogą być realizowane w chmurach obliczeniowych. Naturalnie wskazane powyżej ograniczenia nie mają charakteru konkluzywnego, gdyż uzależnione są w głównej mierze od postępów natury technologicznej (dwie grupy z przedstawionych powyżej barier mają w przeważającej mierze charakter techniczny funkcjonowanie danych oraz dostępność i wydajność). Pomimo ukazanych barier istnieją jednak scenariusze ukazujące możliwości stosowania systemów analityki biznesowej w chmurach obliczeniowych: Aplikacje małych ilości danych. Z uwagi na ograniczenia powiązane z funkcjonowaniem danych ich ilość ma krytyczne znaczenie dla analityki w chmurze. Wiąże się to choćby z technicznymi możliwościami transferu danych lub jego kosztami. O ile ma to uzasadnienie ekonomiczne, organizacje mogą decydować się na wdrażanie tematycznych hurtowni danych w obrębie chmur publicznych. Środowiska testowe. Dostawcy usług w chmurach obliczeniowych zapewniają nie tylko konieczne zasoby, które mogą być wykorzystywane w krótkim czasie, ale także konieczne narzędzia analityczne. Ma to istotne znaczenie dla projektów testowych, które niejednokrotnie mają charakter przygotowawczy. W przypadkach takich organizacje nie muszą ponosić ryzyka związanego z inwestycją w platformę testową oraz konieczną infrastrukturę. Co więcej, różnorodność dostarczanych środowisk umożliwia przeprowadzenie testów w różnych warunkach, których odtwarzanie w ramach własnej infrastruktury może być problematyczne. Chodzi tu zatem nie tylko o specyfikę samej architektury wykorzystywanej w chmurach obliczeniowych, ale także o różnorodność dostarczanych samych narzędzi. Ponadto środowiska testowe z reguły nie wymagają regularnego ładowania danych, które z reguły konieczne jest w produkcyjnych środowiskach analitycznych. Krótkoterminowe analizy ad-hoc. Platformy BI w chmurach obliczeniowych mogą w efektywny sposób spełniać swe zadanie w przypadkach analiz ad-hoc przeprowadzanych 167

168 przez wymagających analityków. Z reguły analizy te wiążą się z jednorazowym importem danych, który uwzględniać może wiele ich źródeł. Analizy takie mogą być realizowane w postaci sandboxów analitycznych, jako wydzielonych środowisk analitycznych przystosowanych do unikalnych analiz. Charakter zaawansowanych analiz wykluczyć może ich przeprowadzanie w wewnętrznym środowisku BI danej organizacji. Z reguły środowiska te przystosowane są do typowych użytkowników, nie wpływających znacząco na wydajność środowiska analitycznego. Wykorzystywanie sandboxów w chmurach może znacząco poprawić efektywność całej platformy BI, gdyż oddzielają one zadania realizowane przez zaawansowanych analityków od zadań zwykłych użytkowników aplikacji BI. Elastyczność alokowania zasobów w chmurach oraz ich dostępność na żądanie może być wykorzystywana przez dowolny czas bez angażowania wewnętrznej infrastruktury IT, np.: organizacja może nagle przeprowadzić dodatkowe analizy czynników wpływających na załamanie się zamówień produkcyjnych lub zmian preferencji konsumentów na podstawie niewykorzystywanych w swoim środowisku BI źródeł danych. Aplikacje rezydujące w chmurach. Coraz więcej firm postanawia tworzyć infrastrukturę IT w oparciu o aplikacje dostarczane w chmurach. Niejednokrotnie firmy decydują się wręcz w pełni na wykorzystanie modelu chmury obliczeniowej w celu zapewnienia funkcjonowania IT. Dotyczy to wszelkich aplikacji wspierających podstawowe procesy biznesowe, np.: CRM, HR lub ERP. W takich przypadkach wdrożenie środowiska analitycznego w chmurze jest naturalnym rozszerzeniem wykorzystywanych w niej aplikacji produkcyjnych, a w szczególności systemów transakcyjnych. Aplikacje analityczne szerokiego dostępu. Im bardziej działanie organizacji opiera się na interakcji z różnorodnymi partnerami, tym większa zachodzi potrzeba zapewnienia właściwych kanałów informacyjnych. Chmury obliczeniowe z definicji realizują zasadę wielodostępowości. Są one idealnym środowiskiem dla współdzielenia platformy analitycznej oraz tworzonych w niej aplikacji i raportów. Sprzyja to potrzebom zapewnienia dostępu do rezultatów analiz dla stron trzecich (np.: partnerów biznesowych lub klientów). Rozwiązania PaaS BI pokazują, że wszelkie elementy architektury BI mogą zostać umiejscowione w modelu chmury publicznej. Istotne problemy powstają jednak w przypadku modelu chmury hybrydowej. W niej bowiem dochodzi istotnego rozproszenia zasobów. Ukazane powyżej problemy w jawny sposób odnoszą się do procesów 168

169 rozproszenia i eksponują konieczność łączenia platform analitycznych lub ich konsolidowania. W tym miejscu możemy powrócić do przedstawionej tezy Carra o końcu przetwarzania korporacyjnego179. Teza ta opiera się na przeświadczeniu, że zasoby systemów informatycznych będą w przyszłości oferowane na wzór energii elektrycznej. Teza Carra może zatem zostać sprowadzona do pytania o pełne wykorzystanie potencjału chmury publicznej i tworzenie infrastruktury jedynie w oparciu o chmury obliczeniowe. Nie udzielając jednak bezpośredniej odpowiedzi na te pytania, Mateos przewiduje następujący scenariusz rozwoju chmur obliczeniowych180: faza I etap zastosowania środowiska chmur obliczeniowych przy użyciu modeli SaaS i IaaS; faza II migracja środowisk w stronę chmur prywatnych; faza III dominacja chmur prywatnych; faza IV powszechne stosowanie modelu przetwarzania na żądanie. Wiele problemów przedstawionych z analizie ETO wyklucza szybkie przystosowanie się większych organizacji do modelu chmury obliczeniowej. Ryzyko zastosowania rozwijających się wciąż technologii mogą jednak podjąć nowo tworzone firmy lub firmy o niewielkich potrzebach związanych infrastrukturą IT. Jednak już obecnie wiele organizacji dostrzega istotny potencjał chmur obliczeniowych i w polu ich zainteresowania znajduje się model chmur prywatnych: Model chmury obliczeniowej uległ przemianie od obietnicy w stronę kompromisu. Po pierwsze, ogromne publiczne chmury pozyskały innowacyjne startupy. Potem, kilka lat później, ważni producenci IT wprowadzili oferty bazujące na chmurach prywatnych. Te prywatne chmury oferują tylko część z korzyści ich publicznych kuzynów. Niemniej jednak cechują je wystarczająco wyraźnie posmak, podobieństwa oraz funkcjonalność, aby opóźnić o kilka lat nieuniknione przejście w domenę publiczną, uspokajając przy tym zatroskanych decydentów 181. Oznacza to, że duże przedsiębiorstwa i organizacje rządowe dostrzegają wiele korzyści płynących z modelu chmury obliczeniowej, jednak wiele z ich uwarunkowań stoi na przeszkodzie faktycznych zastosowań. Ten przejściowy etap (zastosowania chmur prywatnych) jak przekonuje także Mateos, ma doprowadzić nas w stronę pełnego 179 Por. rozdz Mateos A., Rosenberg J. (2011), Chmura obliczeniowa, op. cit., s Croll A. (2012), Three Kinds of Big Data, op. cit., s

170 przetwarzania w na żądanie. Szerokie zastosowanie chmur prywatnych ułatwi proces migracji w stronę chmur publicznych, przy założeniu, że ich funkcjonowanie oparte będzie o globalnie akceptowane standardy, tworzone przez organizacje standaryzujące. Tendencję tę obserwujemy także o obszarze zastosowań i funkcjonowania systemów analityki biznesowej. Ograniczenia zastosowania platform business intelligence w modelu chmury publicznej otwierają zgodnie w cytowanymi powyżej słowami szerokie możliwości dla dostawców przystosowujących te platformy do chmur prywatnych. Do najistotniejszych cech, odróżniających wdrożenie systemów klasy BI w chmurze prywatnej od wdrożeń w chmurze publicznej należy zaliczyć: większa kontrola dostępności i wydajności chmury prywatne stwarzają szansę na większą kontrolę wykorzystania zasobów wykorzystywanych do celów analitycznych, dzięki ich monitorowaniu. Pozwalają także na efektywniejsze wykorzystanie zasobów koniecznych dla funkcjonowania równoległych tematycznych hurtowni danych, które w modelach tradycyjnych wymagałyby oddzielnej infrastruktury; efektywniejsze bezpieczeństwo danych z oczywistych powodów chmury prywatne zapewniają zadowalające rezultaty zapewniania bezpieczeństwa danych i kontroli dostępu; skuteczniejsza integracja platforma analityczna realizowana w prywatnej chmurze obliczeniowej usprawnia procesy powiązane z warstwą integracji. Względnie eliminuje redundancję narzędzi oraz ich zróżnicowanie. Przyśpieszyć może znacząco procesy integrowania danych, a zwłaszcza procesy ETL. Z uwagi na ujednolicanie platformy zadania wdrażania nowych aplikacji analitycznych, zlecane choćby przez zainteresowane departamenty, mogą być realizowane szybciej; większa kontrola budżetu IT ekonomika chmur publicznych ma zastosowanie także do chmur prywatnych. Oznacza to, że jednostki biznesowe zainteresowane wykorzystywaniem platformy analitycznej, w prostszy sposób będą rozliczane z wykorzystania zasobów, przy czym dział IT może być przyrównany do dostawcy usługi w modelach chmur publicznych. Uzasadniony ekonomicznie rozwój chmury prywatnej może być przeprowadzony efektywniej, aniżeli w tradycyjnych środowiskach dzięki wszelkim cechom skalowalności architektury; 170

171 zarządzanie infrastrukturą platformy analityczne realizowane w prywatnych chmurach obliczeniowych narażone są mniej na problemy związane z priorytetyzowaniem projektów, ponieważ wszelkie prace wdrożeniowe przeprowadzane są w oparciu o ujednolicone procedury rozwoju platformy oraz przydzielania niezbędnych zasobów do realizacji projektu Usługowy model systemu analityki biznesowej na przykładzie Software as a Service BI (SaaS BI) W obliczu przedstawianych scenariuszy rozwoju i zastosowania chmur obliczeniowych systemy informatyczne przechodzić będą istotne przemiany. Paradygmat utrzymywania własnej infrastruktury IT zaczyna być bowiem wypierany przez model usługowy oparty na udostępnianiu zasobów informatycznych na żądanie. Systemy klasy BI wpisują się ściśle w ten kontekst. Pierwsza faza dokonujących się przemian została w skrócie przedstawiona jako transformacja środowisk IT w platformy oparte na modelach SaaS i IaaS. W niniejszej części przyjrzymy się bliżej rozwiązaniom SaaS oraz możliwościom ich adaptacji na potrzeby systemów analityki biznesowej. We wprowadzeniu do niniejszego rozdziału wyróżniliśmy główne czynniki wpływające na brak skuteczności w realizowaniu założeń i celów powiązanych z platformami BI. Do swoistego bezwładu tych platform przyczyniają się silne uzależnienie ich funkcjonowania od przeszłych decyzji dotyczących kształtu i profilu systemu (są to w wielu przypadkach środowiska o relatywnie długiej historii procesu implementacji i użytkowania, w których kolejne aplikacje i elementy architektury są wdrażane sukcesywnie). Na skuteczność funkcjonowania systemów i ich sprawność wpływa także czas wdrażania zmian oraz elastyczność procesów modyfikacji architektury, a także tendencja do holistycznego, scentralizowanego podejścia do tworzenia systemu. Evelson postuluje, iż systemy klasy BI powinno cechować: większa automatyzacja, unifikacja (nie przecząca jednak decentralizacji), wszechobecność dostępu do platformy oraz nieograniczoność (adaptowalności modeli danych, przeszukiwań danych i powiązanych z nimi analiz)182. W kontekście głównych tez pracy na szczególną uwagę zasługuje drugi z postulatów, a mianowicie wszechobecność dostępu do systemów BI (ang. pervasive BI). 182 Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, op. cit., s

172 Pervasive BI opiera się na założeniu, że aplikacje, raporty i analizy powinny być dostępne na wszelkich poziomach funkcjonowania systemów informacyjnych. Oznacza to między innymi uwzględnienie BI w rzeczywistych procesach. Informacje uzyskiwane dzięki BI powinny być de facto wkomponowane w aplikacje wspomagające dany proces. Ponadto, architektura systemu analitycznego powinna być zintegrowana z korporacyjną przestrzenią informacyjną (portale, wyszukiwarki, arkusze, edytory tekstu, lub aplikacje mediów społecznościowych). Ogólnodostępność BI w organizacji powinna być poparta samoobsługowym charakterem tego systemu, co oznacza, że zdecydowana większość żądań dotyczących systemu BI powinna być realizowana przez samych użytkowników z niego korzystających. Systemy analityki biznesowej powinny być także dostępne w środowiskach publicznych i mobilnych, włączając w to sytuacje braku połączenia. W dotychczasowych rozważaniach koncentrowaliśmy się w głównej mierze na rozproszeniu zasobów informacyjnych (warstwa zasobów) oraz systemów, aplikacji, modeli (warstwa systemowa). Postulaty pervasive BI ukazują także inny charakter rozproszenia, który zachodzi w w obszarze zasobów ludzkich oraz rzeczowych. W organizacjach niejednokrotnie wielu ich członków niejako podskórnie wyczuwa izolacje i antagonizmy zachodzące między dwoma strukturami: IT i jednostkami biznesowymi. W warstwie zasobów ludzkich dochodzi przy tym do swoistego pęknięcia znamionującego proces rozproszenia. Na pierwszy rzut oka działy IT oraz działy realizujące procesy biznesowe, przyczyniające się bezpośrednio do realizacji celów organizacji, podejmują decyzje w niezależnych obszarach funkcjonalnych. Nie sposób jednak pominąć istotnych zależności, które wpływają na efektywność i skuteczność działań całej organizacji. Zależności te ukazywane są w problemie określanym mianem dopasowania IT i biznesu. Problem ten ukazuje jednak szerszy wymiar, aniżeli współdziałanie samych działów. Odnosi się bowiem do ogólnych zależności między IT, a celami i zadaniami organizacji. W jednym z modeli (Strategic Alignment Maturity Model) do określenia i oceny dopasowania IT i biznesu wykorzystuje się następujące obszary183: nadzór (integrowanie strategii IT i biznesu, dbanie o właściwą strukturę organizacyjną, kontrola kosztów IT i efektywności inwestycji IT); pomiar wartości (wyznaczanie gwarancji świadczonych przez IT usług, ocena efektywności inwestycji IT); partnerstwo (określa wzajemne relacje IT i jednostek biznesowych); 183 Por. Orzechowski R. (2007), Dopasowanie IT-biznes, Kwartalnik Nauk o Przedsiębiorstwie 2, s

173 komunikacja (określa na ile efektywna jest wymiana poglądów oraz wymagań, które spełnić ma IT w konkretnych projektach); umiejętności (zapewnienie środowiska przygotowanego do funkcjonowania w zmieniającym się otoczeniu); zakres i architektura (rola i dojrzałość infrastruktury IT, integracja i standardy). Im większą dojrzałość obserwujemy w przedstawionych powyżej obszarach, tym większe prawdopodobieństwo, że organizacja będzie w efektywny sposób wykorzystywać potencjał systemów informacyjnych, zmniejszając przy tym dystans i lukę między IT i biznesem. Wiele organizacji zmniejsza tę lukę, stosując precyzyjne metody oceny efektywności i wartości dostarczanych przez IT. Zauważmy przy tym, że trzy spośród wymienionych obszarów są w istotny sposób powiązane z kapitałem ludzkim (partnerstwo, komunikacja i umiejętności). O ile dwa pierwsze obszary mają istotne znaczenie zwłaszcza w początkowych stadiach funkcjonowania systemów IT w organizacji, o tyle ostatni z wymienionych obszarów rozciąga się na cały cykl ich życia i ma bez wątpienia niebagatelne znaczenie w przypadku systemów klasy BI. Są to bowiem systemy o dużej złożoności powiązanej nie tylko z procesami planowania i utrzymywania, ale także z samym ich użytkowaniem. Niektóre z badań dowodzą, że tylko 20% użytkowników biznesowych korzysta regularnie z potencjału systemu BI wdrożonego w danej organizacji184. Decydenci i analitycy mają częstokroć problemy ze znalezieniem właściwych źródeł informacji, rezydujących w rozbudowanych i złożonych platformach, a jeśli są już w stanie precyzyjnie określić rodzaj pożądanych informacji, czekać muszą wiele dni lub tygodni na przygotowanie przez IT odpowiednich danych i raportów185. Co więcej, proces ten komplikuje się w chwili, gdy wymagania ulegną nieznacznym zmianom. Zdarza się bowiem, że nowe żądania związane z dostarczonymi raportami wymagają kolejnych zmian, które wydłużają czas ich dostępności. Można powiedzieć, że zachodzi realna potrzeba uelastycznienia BI, które jest niejako w rękach IT. Odpowiedzią na te problemy jest postulat dostarczania platform BI o charakterze samoobsługowym (ang. self-service BI). Evelson zakłada, że platformy te wspierane będą przez funkcje i technologie, które pozwolą na realizowanie 80% żądań przez samych 184 Schlegel, K. (2008) Emerging technologies Will Drive Self-service BI, ID No. G , Gartner Research Inc. January 26, Shen, G. (2011) Cloud computing. The Catalyst for self-service BI, Information Management, Sept/Oct 2011, s

174 użytkowników końcowych186. Innymi słowy, samoobsługowe platformy BI mają przyczynić się nie tylko do usprawnienia procesów podejmowania decyzji, ale także większego dopasowania IT i biznesu. Samoobsługowe platformy BI cechują: łatwiejsze odkrywanie, rozumienie i współdzielenie informacji; przejrzystsze narzędzia do generowania informacji; rozwiązania o szybkim wdrożeniu platformy; dostęp do wszelkich danych, lokalizowanych nie tylko w hurtowniach danych. Wymienione cechy samoobsługowych platform BI odniesione mogą być do założeń SaaS BI. Zanim przystąpimy do szerszego ujęcia tych rozwiązań spróbujmy prześledzić główne cechy samego modelu SaaS: Software as a Service (SaaS) jest oprogramowaniem posiadanym, dostarczanym i zarządzanym zdalnie przez jednego lub wielu dostawców. Dostawca dostarcza oprogramowanie oparte na zbiorze definicji danych oraz definicjach programistycznych, które jest użytkowane w modelu jedno-do-wielu przez zakontraktowanych klientów w dowolnej chwili na bazie opłat za faktyczne użycie lub w modelach subskrypcyjnych na podstawie metryk wykorzystania 187. SaaS w skrócie można zatem uznać za sposób dostarczania aplikacji za pośrednictwem Internetu w modelach cenowych pay-per-use lub subskrypcyjnym. Dostawcy zapewniają z reguły jedną instancję aplikacji we wspólnym (lecz nieogólnodostępnym) środowisku, które współdzielone może być przez setki firm lub osób prywatnych. Zasada ta ma istotne znaczenie z punktu rentowności dostawców. Dodatkowym elementem stymulującym jest spadek kosztów transmisji danych, niezbędnej z uwagi na umiejscowienie aplikacji w przestrzeni sieci publicznej. Oprogramowanie dostarczane w tym modelu nie podlega cyklom życia tradycyjnego oprogramowania, powiązanych z licencjonowaniem, kontraktami wsparcia oraz koniecznymi aktualizacjami. Model ten zapewnia dzięki temu względną elastyczność doboru dostawcy, przy założeniu niskiego poziomu czynnika zamknięcia188. Można jednak założyć, że przywiązanie do wybranego oprogramowania w modelu tradycyjnym jest dużo silniejsze, aniżeli w modelu SaaS. 186 Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, op. cit., s Gartner (2012), IT Glossary. Defining The IT Industry. Software as a Service (SaaS), Por. problem zamknięcia w chmurach obliczeniowych, poruszony w rozdziale czwartym. 174

175 Model SaaS bazuje na wymiernych i poważnych konsekwencjach ekonomicznych. Podobnie do innych modeli usługowych chmur obliczeniowych mają do niego zastosowanie wszelkie wyróżnione w poprzednim rozdziale czynniki natury ekonomicznej Tabela 8. Całkowity koszt utrzymania (TCO). Tradycyjne oprogramowanie vs. Software-as-a-Service. Źródło: Dubbey A., Wangle D. (2007), Delivering software as a service, McKinsey Quarterly, May Całkowity koszt utrzymania (tys. $) Tradycyjne oprogramowanie Software as a Service Źródła oszczędności przy SaaS Implementacja, wdrożenie Integracja, kastomizacja Testy podstawowej infrastruktury, wdrożenie 54 0 Testy infrastruktury aplikacji, wdrożenie 30 0 Szkolenie Obniża wymagania dotyczące szkoleń - prostsze interfejsy użytkownika - możliwości auto-szkolenia Zarządzanie i dopasowywanie zmiany procesów biznesowych 94 0 Nie wymaga bieżącego zarządzania zmianą procesów biznesowych - dostawcy monitorują aktywność użytkowników w celu wzbogacenia usługi - klienci dostarczają opinii dotyczących wzbogacenia funkcjonalności Wynajęcie zaplecza centrum danych, operacje, bezpieczeństwo, wykrywanie oszustw, monitorowanie zdarzeń Skrócony czas wdrożenia, ograniczona kastomizacja, samoobsługowy charakter dzięki skryptom instalacyjnym Nie wymaga testowania infrastruktury i aplikacji Operacje bieżące Zawiera koszty dostawcy uwzględnione w cenie subskrypcji (bieżące operacje, hardware i software) Oprogramowanie Licencje użytkowników, subskrypcje, utrzymanie Nieprzewidziane przestoje Zapewnia dostępność serwerów na poziomie 99,9% vs. 99% Niewykorzystane licencje 92 0 Redukuje liczbę niewykorzystanych licencji o 20%, użytkownicy dodawani w miarę zapotrzebowania Inne Całkowite koszty (z innymi kosztami) wyróżnione w analizie ETO. Tabela 8. ukazuje niektóre z tych czynników i zawiera porównanie kosztów poszczególnych elementów TCO dla przykładowego 175

176 oprogramowania CRM w modelach tradycyjnym (tj. utrzymania aplikacji w wewnętrznej infrastrukturze) i w modelu SaaS dla 200-u użytkowników. Ekonomiczne uwarunkowania modelu SaaS mają zastosowanie także w rozwiązaniach SaaS BI. Badania przeprowadzone przez Aberdeen Group wykazują jednak, że decyzje o zastosowaniu tych rozwiązań podlegają nie tylko motywacjom ekonomicznym189. Do innych powodów należy zaliczyć: złożoność tradycyjnych narzędzi BI; zbyt długi czas wdrożenia typowych platform BI; zbyt duże wymagania co do zasobów koniecznych do wdrożenia; konieczność dostarczania narzędzi BI małym grupom roboczym o zróżnicowanych wymaganiach; złożoność utrzymania platformy uniemożliwia jej szerokie zastosowanie. Wyróżnienie głównych cech SaaS BI może być odniesione do powyższych barier, które organizacje mogą pokonać dzięki następującym czynnikom determinującym SaaS BI: marginalizacja kompetencji, funkcjonalność i interfejs, uwarunkowania funkcjonowania danych oraz uwarunkowania implementacji. Marginalizacja kompetencji. Wraz ze wzrostem poziomu abstrakcji w trzech głównych modelach usługowych chmur obliczeniowych (IaaS, PaaS, SaaS) spada poziom kompetencji koniecznych do wdrożenia i użytkowania usługi. Z naturalnych powodów zarówno IaaS jak i PaaS stanowią istotną barierę wiedzy, wiążącą się z wykorzystywaniem specjalistów IT. Ponadto, modele te wymagają starannie dobranych elementów wdrażanych platform, opracowania ewentualnych strategii integracji oraz polityki IT w zakresie przydzielania dostępu, kwestii bezpieczeństwa itp. Innymi słowy, ciężar przystosowania infrastruktury oferowanej w tych modelach spoczywa w głównej mierze na własnych zespołach IT lub zewnętrznych zespołach powołanych w ramach dodatkowych umów. W nieco odmienny sposób uwarunkowane są propozycje w ramach modelu SaaS. Z założenia w ich zakresie oferowane aplikacje powinny funkcjonować w oparciu o minimalną ingerencję w procesy przygotowania aplikacji do jej wykorzystania jak też jej utrzymania. W przedstawionym powyżej porównaniu tradycyjnych aplikacji i rozwiązań SaaS widoczne jest to choćby w redukcji kosztów związanych z testowaniem platformy, za które odpowiada dostawca oraz uwzględnieniem kosztów dostawcy związanych z 189 White D. (2010), Fast, Affordable, Agile - The Case for SaaS BI, Aberdeen Group Inc., 176

177 utrzymaniem w kosztach subskrypcji. Wszelkie zatem działania mające na celu zapewnienie właściwego funkcjonowania aplikacji (instalacja, bieżące utrzymanie i aktualizacje) realizowane są przez dostawcę. W przypadku platform SaaS BI istotnym etapem jest przystosowanie środowiska analitycznego na potrzeby usługobiorcy. Z reguły dostawcy oferują predefiniowane interfejsy importu danych bądź zasilania środowiska analitycznego. Dzieję się tak choćby w przypadku usług wzbogacających aplikacje rezydujące w chmurach obliczeniowych o funkcje analityczne. Usługobiorcy mogą także zlecić przystosowanie procesów zasilania danych niezbędnych do analizy w ramach oddzielnych umów. Założenia biznesowe dostawców rozwiązań SaaS BI opierają się na potencjale chmur obliczeniowych. W szczególności chodzi tu o nieograniczone możliwości skalowania architektury. Dzięki temu czynnikowi dostawcy mogą oferować swoją platformę znacznej liczbie usługobiorców. Wiąże się jednak z tym istotne ograniczenie, o którym wspominaliśmy w rozdziale czwartym. W celu wykorzystania potencjału skalowalności usługodawcy muszą zachować względnie stabilny trzon funkcjonalny. Prowadzi to do znacznego ograniczenia możliwości dostosowywania platformy do indywidualnych potrzeb. Z punktu widzenia marginalizacji wymaganych kompetencji ma to znaczenie niebagatelne. Usługobiorcy otrzymują gotowe rozwiązanie, nie wymagające istotnego wkładu w przygotowanie aplikacji do działania. Można zatem stwierdzić, że potencjał chmur obliczeniowych w modelu SaaS wymaga swoistego umasowienia rozwiązania. Naturalnie ma to swoje negatywne skutki w chwili unikalnych potrzeb klientów. Właściwe zadanie dostawców polega zatem nie tylko na dostarczeniu atrakcyjnego środowiska analitycznego, ale także ustanowieniu swoistej elastyczności w zakresie oferowanych funkcji aplikacji. Wspomniane powyżej ograniczanie możliwości kastomizacji wiąże się pośrednio z koniecznością zapewnienia właściwych funkcji środowiska analitycznego. Ma to miejsce w dedykowanych rozwiązaniach branżowych. W odróżnieniu od SaaS BI ogólnego przeznaczenia, rozwiązania dedykowane dodatkowo redukują barierę wiedzy. Dostawcy SaaS BI mogą w ramach swej oferty dostarczać środowisko o specjalnym przeznaczeniu (np.: analityka branżowa), znacząco podnosząc przydatność rozwiązania. Ograniczają przy tym także konieczność rozeznania usługobiorcy w praktyce i zasadach wdrażania i utrzymania systemów analityki biznesowej. Zasady te uwzględniać mogą choćby konieczne metryki, źródła danych, typy analiz etc. 177

178 Funkcjonalność i interfejsy. Na obecnym etapie wiele rozwiązań SaaS BI oferuje względnie ograniczoną funkcjonalność. Są to w większości przypadków aplikacje tworzone od podstaw dla środowiska webowego. Cechuje je prostota oraz intuicyjność, wymuszone niejako przez samą architekturę interfejsu. Paradoksalnie to ograniczone dotychczas możliwości przeglądarek webowych wpłynęły na efektywne tworzenie interfejsu aplikacji oraz możliwości projektowania ich pod kątem wielodostępowości (multitenancy). Widoczne jest to szczególnie w przypadkach producentów tradycyjnych rozwiązań BI, którzy oferują je w modelach SaaS lub PaaS. Z punktu widzenia tradycyjnych rozwiązań, aplikacje BI udostępniane przez nich w modelach SaaS i PaaS cechuje zredukowana funkcjonalność. Jednym z powodów jest konieczność przeprojekotwania aplikacji obsługiwanych dotychczas w trybie jednej instancji dla jednego klienta na tryb wielodostępowości. Jednym z przykładowych problemów może być tu choćby kwestia ról administracyjnych oraz bezpieczeństwa, która wymaga odmiennego podejścia w modelach SaaS i PaaS. Z drugiej strony dostawcy SaaS, tworzący swe produkty od podstaw muszą mieć na uwadze aktualnie wykorzystywane metody analiz, sposoby ich prezentacji oraz interakcji z nimi. Z punktu widzenia funkcjonalności oraz interfejsu obydwie te tendencje wskazują na zbliżanie się do siebie tradycyjnych rozwiązań do rozwiązań oferowanych w chmurach, zwłaszcza w modelu SaaS. Osiąganie przewagi konkurencyjnej przez dostawców wiąże się nie tylko z zapewnieniem właściwej funkcjonalności środowiska analitycznego, ale także z jego wzbogacaniem. Jedną z istotnych cech aplikacji oferowanych w chmurach obliczeniowych jest przejęcie roli dopasowywania funkcjonalności platformy przez dostawcę. Odbywa się to dwutorowo. Z jednej strony sami dostawcy zapewniają zarządzanie platformą oraz aktywny jej rozwój w oparciu nowe metody, praktyki i obszary analiz. Z drugiej zaś mają oni za zadanie monitorować wymagania samych usługobiorców. Proces projektowania i wzbogacania aplikacji powinien zatem uwzględniać faktyczne potrzeby klientów usługi190. Funkcjonowanie danych. SaaS BI jako system wspomagania decyzji zorientowany na dane podlega istotnym ograniczeniom systemów rozproszonych. W świetle analizy ETO chmur obliczeniowych aspekty funkcjonowania danych zostały ukazane w negatywnym świetle. W kontekście funkcjonowania danych główne ograniczenia to problemy modelowania i migracji danych, ich nieokreślona lokalizacja oraz transfer. 190 Rimal B. P. et al. (2011), Architectural Requirements for Cloud Computing Systems: An Enterprise Approach, Journal of Grid Computing 9, s

179 Negatywne skutki pierwszego czynnika w modelu SaaS minimalizowane mogą być między innymi dzięki opisanym powyżej cechom marginalizacji kompetencji. Należy jednak pamiętać, że dostawcy SaaS BI częstokroć oferują jedynie proste interfejsy integracji danych, które mogą nie spełnić oczekiwań w przypadkach złożonego środowiska źródeł danych. Można przypuszczać, że postępujące procesy wirtualizowania, które obserwujemy od początków rozwoju Internetu, przyczynią się do przełamywania uprzedzeń i obaw związanych z samym położeniem danych. Problem lokalizacji danych w głównej mierze dotyczy zobowiązań regulacyjnych i prawnych samych usługobiorców, którzy muszą mieć na względzie ten aspekt funkcjonowania danych. Ważną rolę w minimalizacji tego czynnika będzie miało promowanie pozytywnych cech lokalizowania zbiorów danych w chmurach obliczeniowych. Widoczne jest to choćby w przedstawionym powyżej porównaniu tradycyjnych aplikacji i SaaS. W drugim z tych modeli dostępność aplikacji, a co za tym idzie danych oferowana jest na wyższym poziomie. Wiąże się to nie tylko z zapewnieniem ciągłości działania, ale także efektywnością samych aplikacji. Na obecnym etapie ograniczone jest samo przemieszczanie się danych. Efektywność przemieszczania się danych zależy nie tylko od możliwości sieci rozległych, w tym sieci dostawcy, ale co być może istotniejsze, od warunków umów serwisowych, które zakładać mogą opłaty za transfer danych. W uzasadnionych przypadkach w środowiskach chmur hybrydowych pokonanie bariery przemieszczania się danych może być realizowane przy użyciu rozwiązań federacji danych. Jednak najbardziej uzasadnione wdrożenia SaaS BI opierają się na stosunkowo niewielkich wolumenach danych i przy relatywnie nieskomplikowanych modelach. Uwarunkowanie implementacji. Dwa z powyższych determinant, marginalizacja kompetencji oraz uwarunkowania funkcjonowania danych bezpośrednio przyczyniają się do usprawnienia wdrożenia SaaS BI. Takie elementy jak ograniczenie kastomizacji, zapewnienie uniwersalnych interfejsów danych czy obsługa relatywnie nieskomplikowanych modeli przyczyniają się do minimalizacji wysiłków związanych z przygotowaniem i wdrożeniem platformy BI oferowanej w modelu SaaS. Stosowanie platformy BI uznawane jest za element sprzyjający dojrzałości architektury IT. Samo jednak jej zastosowanie niekoniecznie musi przyczyniać się do osiągania przewagi konkurencyjnej, nie mówiąc o faktycznych korzyściach mierzonych ścisłymi metodami finansowymi. 179

180 Ekonomiczne uwarunkowania modelu SaaS BI znoszą finansowe ryzyko niepowodzenia zastosowania platformy BI w organizacji. Główną zaletą wdrożenia SaaS BI jest niewątpliwie brak ciężaru związanego z finansowaniem tego typu usług. Zgodnie bowiem z wcześniejszymi ustaleniami usługi, oferowane w chmurach przenoszą ciężar inwestycyjny w obszar kosztów operacyjnych (CAPEX vs. OPEX). Charakter usług na żądanie nie przywiązuje organizacji w długim horyzoncie czasowym do konkretnego dostawcy oraz jego propozycji środowiska BI przy założeniu, że minimalizowane jest ryzyko czynnika zamknięcia. Osiągane być to może między innymi dzięki odpowiednim klauzulom w umowach serwisowych. Efektywność wdrożenia podniesiona może być także przez właściwy dobór dostawcy. Ma to miejsce choćby w przypadkach chmur hybrydowych. Jeżeli SaaS BI jest rozszerzeniem typowego rozwiązania BI oferowanego przez producenta tradycyjnego rozwiązania BI, wykorzystywanego w ramach własnej infrastruktury, to proces implementacji platformy analitycznej w chmurze będzie narażony na mniejszą ilość przeszkód. SaaS BI należy uznać za istotny krok na drodze wprowadzania zasady analityki samoobsługowej. Dotyczy to nie tylko typowych zastosowań i metod analitycznych BI, ale także rozwiązań analityki Big Data oferowanych w modelach SaaS, gdzie stopień zaawansowania technologicznego niemalże wymaga intuicyjnych narzędzi do przeprowadzania analiz. Tabela 9 zawiera zestawienie przedstawionych cech SaaS BI w odniesieniu do postulatów samoobsługowych platform BI. Tabela 9. Determinanty SaaS BI na tle postulatów samoobsługowej platformy BI. Źródło: opracowanie własne. Postulaty samoobsługowej platformy Determinanty SaaS BI BI Sprawniejsze odkrywanie, rozumienie i współdzielenie informacji Marginalizacja kompetencji - minimalizacja kompetencji względem modeli IaaS i PaaS - uniwersalne, predefiniowane interfejsy dla importu i zasilania danych - outsourcing przystosowania platformy na potrzeby usługobiorcy - ograniczenia kastomizacji Funkcjonalność i interfejsy - zarządzanie zmianą procesów analitycznych przez usługodawcę - dopasowywanie funkcjonalności aplikacji w oparciu o wzorce wykorzystania przez usługobiorców - funkcje lub zakres tematyczny SaaS BI jako element przewagi konkurencyjnej dostawcy Przejrzystsze narzędzia do generowania Funkcjonalność i interfejsy - SaaS BI zapewnia intuicyjne interfejsy informacji - Zaawansowane narzędzia i metody analityczne w interfejsach 180

181 Postulaty samoobsługowej platformy Determinanty SaaS BI BI webowych Rozwiązania o szybkim wdrożeniu platformy Uwarunkowania implementacji - pozytywny wpływ marginalizacji kompetencji - pozytywny wpływ cech funkcjonowania danych uniwersalne interfejsy danych - OPEX zamiast CAPEX - możliwości uzupełnienia tradycyjnej platformy BI przez SaaS BI tego samego producenta Dostęp do wszelkich danych Funkcjonowanie danych - aplikacje analityczne bliskie źródłom danych (np.: analiza danych pochodzących z innych aplikacji SaaS) - analiza relatywnie niewielkich wolumenów danych - ewentualna federacja danych w chmurach hybrydowych Samoobsługowy charakter SaaS BI ma istotne przełożenie na potrzeby systemów analityki biznesowej w dużych organizacjach. Zgodnie z wcześniejszymi ustaleniami przynależność infrastruktury informatycznej do działów IT jest przejawem kształtowania się w organizacji swoistych stosunków władzy191. Stosunki te powinny być nie tyle odwrócone, ile raczej złagodzone. Faktycznie oznacza to ułatwienie możliwości wykorzystania infrastruktury IT przez użytkowników biznesowych. W części poświęconej postulatom osiągania sprawności w funkcjonowaniu platform BI wyróżniliśmy następujące elementy: oddzielenie preparacji danych od użytkowania; podział architektury na elementy podlegające centralizacji i satelity; przydzielenie większej kontroli biznesowi (np.: poprzez wydzielenie źródeł danych, które biznes może wykorzystywać bez ingerencji IT). W świetle powyższych postulatów oraz wyróżnionych determinant modelu SaaS BI, jego zastosowanie może przyczynić się do większego dopasowania IT i biznesu. W dużych organizacjach wydziałowe inicjatywy IT mogą napotykać na przeszkody, które w modelu SaaS w skuteczny sposób mogą być minimalizowane. Po pierwsze, dostawcy mogą przejąć istotną rolą preparacji danych. Natomiast dzięki utworzeniu właściwej polityki dotyczącej wykorzystywania danych źródłowych lub hurtowni danych, poszczególne wydziały mogą podejmować własne inicjatywy wdrożenia platform BI w modelu SaaS przy użyciu koniecznych źródeł. W końcu atrakcyjny model finansowania platform SaaS BI sprzyja ich wdrożeniu przez pojedyncze jednostki biznesowe, które nie są zmuszone do trudnych 191 Por. rozdział

182 niejednokrotnie pertraktacji z działami IT w zakresie wykorzystania infrastruktury informatycznej zlokalizowanej w obrębie organizacji. SaaS BI jest modelowym przykładem systemu rozproszonego i ściśle wpisuje się w założenia niniejszej rozprawy. Ukazuje ponadto możliwą przemianę paradygmatu przetwarzania w systemach informacyjnych, a mianowicie paradygmatu przetwarzania na żądanie realizowanego w środowiskach chmur obliczeniowych. Powstają pytania, jakie są możliwości zastosowania tego modelu usługowego oraz kto może najefektywniej wykorzystać potencjał systemów analityki biznesowej postrzeganej z perspektywy tak rozumianego systemu rozproszonego? Kolejna część niniejszej rozprawy poświęcona będzie w głównej mierze wypracowaniu odpowiedzi na powyższe pytania. 182

183 6. Ewolucja systemów analityki biznesowej Niniejszy rozdział stanowić będzie syntezę dotychczasowych rozważań. Schemat naszego wywodu opierać się będzie na przesłance, że ewolucja systemów analityki biznesowej w ścisłej mierze zależeć będzie od ewolucji paradygmatu tworzenia infrastruktury w organizacjach. Przy czym paradygmat ten rozpatrywać będziemy w interesującej nas perspektywie rozproszenia. Wypracowaną tezę o ewolucji tegoż paradygmatu odniesiemy następnie do rezultatów analizy ETO, przechodząc kolejno przez analizę na tle typów organizacji po analizę modelów upowszechniania chmur obliczeniowych. Rozważania te odniesiemy następnie do przykładów systemów analityki biznesowej, rozpatrywanych w rozdziałach trzecim i piątym. W końcu jeden z tych przykładów zostanie przedstawiony w sposób szczegółowy z uwzględnieniem analizy teoretycznej i empirycznej Postulaty rozwoju i ewolucji infrastruktury IT W dużych organizacjach o rozbudowanej infrastrukturze IT zastosowanie obecnych usług dostępnych w chmurach podlega taktycznym inicjatywom, które wychodzą niejednokrotnie od jednostek biznesowych. Wynika to między innymi z silnego przywiązania pojęcia infrastruktury, ale i funkcji w niej zawartych, do faktycznie posiadanych zasobów IT. Co więcej, strategiczne i krytyczne procesy w naturalny sposób powiązane są z własnymi zasobami IT. Ta naturalnie rozwinięta dychotomia ma swoje przełożenie na zawężenie pojęcia infrastruktury IT i jej silnej identyfikacji z zarządzanymi przez IT zasobami: 183

184 Większość organizacji postrzega chmury jako sposób obniżenia kosztów centrów danych i kosztów IT. Naturalnie jest to realna korzyść, ale bez wątpienia większa korzyść płynie z szybkości i elastyczności, nie mówiąc o łatwości dostarczania. [...] IT zwykle obawia się utraty kontroli i ta obawa jest często podkreślana jako powód rezygnacji z chmury. Zwykle jednak to ekonomika chmur rozwiewa te wątpliwości. Zalety chmur, takie jak obniżanie kosztów i szybsze wdrożenia, jawnie rysująca się elastyczność, w końcu popularność chmur wśród jednostek biznesowych to wszystko przezwycięża obiekcje IT 192. Z naturalnych powodów, takich jak utrata kontroli przez działy IT nad systemami czy problemy bezpieczeństwa, rozumienie infrastruktury jako ogółu systemów wykraczającego poza fizyczne ich ramy, może spotkać się ze sprzeciwem IT. Z punktu rynkowego, wszelkie korzyści oferowane przez usługodawców decydentom zainteresowanych jednostek biznesowych, mogą być oferowane decydentom po stronie IT. Zaliczyć można do nich między innymi czas implementacji usług, a przede wszystkim kwestie ekonomiki poruszone w analizie ETO. Naturalnie kwestie te mają istotne znaczenie dla zastosowań o charakterze taktycznym na poziomie jednostek biznesowych, bezpośrednio finansujących usługę. Jednak uwarunkowania te mają niebagatelne znaczenie także dla budżetu oraz strategii zarządzania systemami IT w zasięgu całej organizacji, co może wpłynąć na zmianę obecnego rozumienia paradygmatu infrastruktury przez IT, a tym samym przyczynić się do silnego rozwoju modelu chmur obliczeniowych oraz wcielania ich w obszar tej infrastruktury. W tym punkcie rozprawy zbiegają się wątki poruszane dotychczas w naszych rozważaniach, które stanowią trzon dla postulatów związanych z rozwojem systemów analitycznych widzianych przez pryzmat ewolucji modelu chmury obliczeniowej. 1. W toku rozprawy zwracaliśmy uwagę na dwie tezy Carra dotyczące współczesnych systemów IT: a) w pierwszej tezie napotykamy twierdzenie o nieistotności zasobów IT dla przewagi konkurencyjnej. Przypomnijmy, że za tezą tą stoją dwie główne przesłanki: konsekwencje ryzyka inwestycji IT wiele uwagi poświęca się problematyce ryzyka związanego z wdrażaniem technologii; ryzyko to ma głównie charakter ekonomiczny, co silnie przekłada się na kondycję ekonomiczną i 192 Swoyer S., (2013) As BI Moves to the Cloud, It's Time to Rethink What "Infrastructure" Means w Analytics in the Cloud. Challenges and Benefits, TDWI, s Cytowane słowa to opinia Marka Madsena zwarta w tekście Swoyera. 184

185 konkurencyjną organizacji; tym samym decyzje związane z zastosowaniem konkretnej technologii muszą być ekonomicznie ugruntowane; procesy standaryzacji technologii i rozwiązań informatycznych stosowanych przez organizacje doprowadzają do minimalizacji przewagi osiąganej przez organizacje stosujące istotne innowacje w zakresie IT; procesy te bowiem doprowadzają do upowszechnienia się pionierskich rozwiązań, które w początkowym etapie mogły stanowić źródło przewagi konkurencyjnej nad organizacjami bez danej innowacji w obszarze IT; b) druga teza formułowana przez Carra dotyczy postulatu sposobu przetwarzania informacji w organizacji : Carr przewiduje, że ewolucja przetwarzania informacji zmierza w stronę przetwarzania poza korporacją, posługuje się w tym celu analogią zasięgniętą z historycznych uwarunkowań rynku energii elektrycznej. 2. Swoistym podparciem tych tez są zachodzące procesy wirtualizacji (opisywane miedzy innymi w rozdziale czwartym): a) procesy wirtualizacji ukazane zostały z perspektywy infrastruktury, ale także w kontekście integracji danych w odniesieniu do architektury systemów BI: wirtualizacja w znaczący sposób zmieniła podejście do zarządzania infrastrukturą; dotyczy także przetwarzania i reprezentacji danych (np.: wirtualizacja omawiana przy okazji metod integracji danych w warstwie integracji architektury systemów BI federacja danych). b) procesy wirtualizacji obejmują także kształtowanie nowych form organizacyjnych (np.: wirtualne organizacje). Kształtowanie się tych form zależy miedzy innymi od specyficznych uwarunkowań technicznych. Zaliczyć do nich można upowszechnianie się technologii sieciowych oraz dostępność aplikacji w sieci globalnej. 3. Przemiany towarzyszące wykorzystywaniu nowych technologii oraz zarządzaniu informacją i towarzyszącymi jej procesami podejmowania decyzji: a) upowszechnianie się technologii mobilnych ma silne przełożenie na zarządzanie informacją i infrastrukturą: doprowadza do konieczności koncentracji zadań przetwarzania po stronie zaplecza IT; 185

186 wymaga sprawnych mechanizmów dostarczania informacji w heterogenicznych środowiskach (np.: różnorodność urządzeń i aplikacji na nich stosowanych). b) potrzeba silnego uniezależnienia podmiotów podejmujących decyzje od IT podlega: konieczności sprawnego dostosowywania narzędzi do potrzeb podmiotów podejmujących decyzje, zarówno na poziomie konkretnych osób, jak też jednostek biznesowych (np.: rozwiązania samoobsługowe); minimalizowania wysiłku w tworzenie rozwiązań sprzyjających interakcji, przy czym przez interakcję należy rozumieć tu wszelkie procesy lezące na styku kontaktów między osobami lub systemami i aplikacjami. Ukazanie możliwego scenariusza rozwoju modelu chmur obliczeniowych zależy między innymi od konsekwencji powyższych tez i zjawisk. Wydaje się, że pierwsza z tez Carra w sposób istotny ukazuje obecne tendencje w zarządzaniu. Co istotne, wyznacza ona swoistą aurę towarzyszącą podejmowaniu decyzji odnośnie infrastruktury IT na gruncie strategicznym. Decydenci coraz częściej przywiązują niebagatelną wagę do znaczącego przełożenia się inwestycji na wyniki. Niektóre z przedstawionych sytuacji związanych z funkcjonowaniem systemów analityki biznesowej ukazują przeniesienie ciężaru zarządzania IT w stronę jednostek biznesowych, które narzędzia informatyczne postrzegają w sposób ściśle utylitarny. Takie podejście eliminuje w wielu przypadkach żmudne procesy definiowania wymagań biznesowych, które na gruncie całej organizacji są niejednokrotnie zadaniem niewspółmiernym do inicjatyw konkretnych jednostek biznesowych. Wiąże się z tym także istotny czynnik wpływający na przewagę konkurencyjną, a mianowicie czas. Można z dużą dozą pewności stwierdzić, że skala przedsięwzięcia oprócz kwestii ekonomicznych, w istotny sposób przekłada się także na horyzont czasowy, który w wielu przypadkach ma dla przewagi konkurencyjnej znaczenie niebagatelne. Dużo wątpliwości rodzi jednak druga z tez Carra. Zasadniczo jest ona dużo bardziej dyskusyjna od tezy pierwszej. Przypomnijmy pokrótce rodzące się w tym kontekście zastrzeżenia. Po pierwsze, prognoza co do przeniesienia ciężaru przetwarzania w stronę potencjalnych usługodawców, wydaje się zbyt optymistyczna. Historyczne spojrzenie na ten problem przedstawia tę tezę w zgoła odmiennym świetle. Fluktuacje w obszarze przetwarzania informacji poza obszarem organizacji ukazuje Campbell-Kelly. Otóż pomimo wielu oczywistych korzyści, głownie natury ekonomicznej, historia informatyki 186

187 dowodzi, że model usługowy w przetwarzaniu informacji nie zawsze był szeroko stosowany. Wpływały na to czynniki rynkowe (np.: kryzys gospodarczy), ale także technologiczne (np.: pojawienie się komputerów osobistych w latach 80-tych). Ten aspekt tezy Carra pośrednio wiąże się z wątpliwościami co do zasadności analogii, którą zastosował autor tej tezy. Zastosowanie tej analogii budzi poważne wątpliwości co do jej przeniesienia na grunt systemów informatycznych. Energię elektryczną należy umiejscowić na planie płaszczyzny przetwarzania, która z kolei znajduje swoje miejsce w warstwie zasobów. Ściślej rzecz biorąc, o ile można odnaleźć związki między zasobem, jakim jest energia elektryczna, a zasobami rzeczowymi (np.: moc obliczeniowa), o tyle przeniesienie takiej relacji na grunt warstwy systemowej wydaje się nie do pogodzenia. Zachodzą w niej bowiem złożone związki i relacje, których nie odnajdujemy w zasobie, jakim jest energia elektryczna. W stosunku do usług udostępnianych na żądanie, dostarczenie energii elektrycznej zdaje się być usługą o relatywnie niskiej złożoności i płaskiej strukturze.w ostatecznym rozrachunku punktem odniesienia dla tak zarysowanej przez Carra tezy jest analiza ETO, ukazująca wielowymiarowość problemu dostarczania usług na żądanie. Wirtualizacja bez wątpienia umożliwia koncentrowanie działań oraz zasobów. Przyczynia się także w głównej mierze do wzmocnienia efektu wpływu wielu czynników analizy ETO na potencjał adaptacji chmur obliczeniowych np.: zarządzanie infrastrukturą, skalowalność lub aplikacje (ETO - mocne strony). Jeśli uznamy cytowaną powyżej diagnozę uwarunkowań zmiany paradygmatu infrastruktury za zasadną, to wymienione powyżej grupy czynników stanowią grunt dla jej uprawomocnienia się. Czynniki te mają bowiem głownie ekonomiczny wymiar i mogą być przeciwwagą dla aspektów negatywnych, takich jak bezpieczeństwo (ETO słabe strony), czy negatywne skutki zmian w zarządzaniu (ETO zagrożenia). Zagadnienie wirtualizacji rozpatrywane było w głównej mierze od strony technologii, jednak pewne aspekty wirtualizacji dotyczą także wyłaniania się nowych form organizacji, dla których klasycznie rozumiana infrastruktura IT może być przeszkodą. Opisywane w rozdziale czwartym aspekty rynkowe (ETO Szanse) funkcjonowania chmur obliczeniowych ukazują skalę i możliwości interakcji, która ma w tym wypadku charakter inter-organizacyjny, ale odpowiadają one także przemianom form i struktur konkretnych organizacji. Np.: niezależność inwestycyjna rozpatrywana na gruncie rynkowym, może być także rozumiana jako niezależność inwestycyjna konkretnych jednostek biznesowych w konkretnej organizacji. 187

188 Wirtualizacja może także przyczynić się do wzmocnienia tendencji z zakresie technologii mobilnych. Ich rozwój zależy jednak w głównej mierze od sprawnych mechanizmów dostarczania aplikacji poza obrębem organizacji. Istotną rolę odgrywa tu zatem wykraczanie infrastruktury poza sztywne ramy środowiska IT danej organizacji. Podsumowując, odniesieniem do powyższych tez i zmian jest pojęcie infrastruktury, której obraz w ich obliczu ulega radykalnej przemianie. Należy przy tym zaznaczyć, że ewolucja systemów informatycznych podlegająca zmianie przedstawionego paradygmatu jest procesem płynnym, który znajdzie swe odzwierciedlenie w ewolucji przetwarzania w chmurach. Można też wysnuć mocniejszą i odwrotną tezę: przetwarzanie w chmurach przyczyni się do zmiany paradygmatu infrastruktury Systemy analityki biznesowej na tle rozproszenia W rozdziale piątym przedstawiliśmy dwie płaszczyzny, na których tle dochodzi do zjawisk rozproszenia. Zaliczyliśmy do nich warstwę zasobów i warstwę systemową. W tym miejscu spróbujemy odnieść wyróżnione elementy z tych warstw do głównych tez rozprawy. Rozważmy prosty przykład. Nie dalej jak dekadę temu większość użytkowników domowych korzystała z komputera osobistego, który zawierał wszelkie dane konkretnej osoby. W ciągu niespełna kilku lat liczba urządzeń przetwarzających informacje wzrosła. Wymieńmy choćby takie jak telefon komórkowy, urządzenia przenośne itp. Niemalże natychmiast pojawił się problem dostępu do danych i ich spójności, bowiem nie wszystkie dane mogą rezydować w jednym miejscu. Ten prosty i dość oczywisty problem ulega znacznej intensyfikacji w przypadku organizacji. Pewnym przejawem tej tendencji jest zasygnalizowana w tym rozdziale tendencja w obszarze zastosowań mobilnych. Pojawia się tu trudność natury terminologicznej. Przewijająca się w nurcie naszych rozważań kwestia rozproszenia wymaga w tym miejscu doprecyzowania. Z jednej strony mówimy o systemach rozproszonych. Z drugiej zaś o rozproszeniu w warstwach zasobów i systemowej. Pierwsza kwestia dotyczy w ścisłym sensie charakteru architektury samego systemu informatycznego. Druga zaś procesów towarzyszących jego funkcjonowaniu. Dla przykładu system BI może być realizowany w tradycyjnej architekturze (rozdz. 3.), ale 188

189 może być także zrealizowany w systemie o cechach systemu rozproszonego w środowisku chmury obliczeniowej np.: w oparciu o model hybrydowy. Systemy rozproszone są zatem jedynie symptomem możliwych rozproszeń i nie wyczerpują wszelkich scenariuszy i relacji wynikających z układu elementów warstwy Rysunek 14. Systemy analityki biznesowej, a rozproszenie w warstwach zasobów i systemowej. Źródło: opracowanie własne. zasobów i systemowej (rys. 14) np.: rozproszenie zasobów ludzkich może wymusić zastosowanie systemu rozproszonego, a względnie nierozproszona informacja system nierozproszony, choćby w postaci centralnego repozytorium wiedzy w organizacji. Zauważmy przy tym, że sytuację tę dodatkowo komplikuje wewnętrzny lub zewnętrzny w stosunku do organizacji charakter rozproszenia (np.: organizację może charakteryzować duże rozproszenie zewnętrznych i niewielkie wewnętrznych zasobów informacyjnych), a taka perspektywa ma także istotny wpływ na podejmowanie inicjatyw informatycznych w organizacjach. Rysuje się tu zatem istotne zastrzeżenie. Rozwinięcie tez o ewolucji systemów analityki biznesowej sytuować w tym miejscu na tle rozproszenia w warstwie systemowej z jego modelowym przykładem, a mianowicie przetwarzaniem w chmurach obliczeniowych. Ewolucja paradygmatu infrastruktury, a wraz z nią ewolucja systemów analityki biznesowej odniesiona powinna być zatem do modeli chmur obliczeniowych. 189

190 6.3. Modele tworzenia infrastruktury informatycznej, a systemy analityki biznesowej W rozdziale czwartym przedstawiliśmy za Meteosem prawdopodobny scenariusz rozwoju modeli przetwarzania w chmurach. Można przypuszczać, że zarówno teza Carra, jak też uwarunkowania wirtualizacji i obecnych symptomatycznych przemian technologicznych podpierają tak ukazany scenariusz. W naszych rozważaniach jest to swoisty punkt odniesienia dla ewolucji systemów analityki biznesowej, ponieważ na tle podtrzymywanego przez nas scenariusza Mateosa sytuować będziemy konkretne rozwiązania analityki biznesowej. Ponadto interesować nas będzie nastawienie Rysunek 15. Systemy analityki biznesowej na tle scenariusza rozwoju modeli tworzenia infrastruktury IT. Źródło: opracowanie własne. korporacyjne i niekorporacyjne do tych rozwiązań. Zarys dalszych rozważań przedstawiono na rysunku 15. Po pierwsze, rysunek ten pokazuje zgodnie z przewidywaniami Mateosa możliwy scenariusz ewolucji przetwarzania w chmurach. Ze scenariusza tego należy jednak wyodrębnić dwa nurty. Z jednej strony dochodzi do upowszechniania się rozwiązań SaaS i IaaS w modelu publicznym, co uznać należy za 190

191 zjawisko względnie niezależne, jednakże wpływające na rozwój i dojrzałość oferowanych usług i technologii stosowanych w chmurach obliczeniowych, a zwłaszcza ugruntowania zasadności wdrożeń w modelu chmur publicznych. Z drugiej strony, scenariusz ten zakłada stopniowe przechodzenie od tradycyjnej infrastruktury w stronę chmur publicznych. Przy czym postulowanym etapem pośrednim jest upowszechnianie się chmur prywatnych. Naturalnie tak postrzegana ewolucja podlegać będzie swoistym przemianom w rozumieniu pojęcia infrastruktury i przełamywaniu barier z tym związanych. Co więcej, przechodzenie przez kolejne etapy zależy także od charakteru działalności organizacji oraz koniecznych rozwiązań informatycznych, które mają zapewnić realizację określonych celów. Należy podkreślić, że ukazana tendencja nie ma charakteru ściśle konkluzywnego. Oznacza to, że scenariusz ten ukazuje kierunek nadchodzących zmian, a nie ostateczny stan rzeczy, tj. docelowe przejście wszystkich organizacji na model przetwarzania w chmurach publicznych. Drugi aspekt ukazany na powyższym diagramie dotyczy uwarunkowań zastosowania poszczególnych modeli tworzenia infrastruktury informatycznej wewnętrzna oraz zewnętrzną ukazanych od strony typu organizacji. Przy czym, wewnętrzna infrastruktura może być realizowana w sposób tradycyjny lub przy pomocy chmur prywatnych, natomiast infrastruktura zewnętrzna przy użyciu chmur publicznych. W rozdziale czwartym dokonaliśmy wstępnej analizy ETO odniesionej do sektora dużych przedsiębiorstw oraz małych i średnich przedsiębiorstw. W tej części pracy spróbujemy odnieść wyróżnione typy systemów analityki biznesowej do wypracowanych wcześniej wniosków. Zaliczymy do nich tradycyjne rozwiązania BI, systemy analityki Big Data oraz usługi SaaS BI Typy systemów analityki biznesowej w ujęciu korporacyjnym Dokonana w rozdziale czwartym analiza ETO nie zawierała istotnego rozróżnienia na omawiane wcześniej modele oparte na przetwarzaniu rozproszonym: chmury prywatne oraz chmury publiczne. Zasadniczo wszelkie ustalenia dotyczące analizy ETO w ujęciu korporacyjnym, odniesione do tych dwóch modeli mogą być podtrzymane. Jednak w przypadku kilku czynników zachodzą istotne różnice (por. tabela 10). 191

192 Zarządzanie infrastrukturą. Poszczególne czynniki tej grupy wyrastają z charakterystyki technicznej, w głównej mierze podlegającej założeniom wirtualizacji. Z naturalnych powodów korzyści wynikające z wirtualizacji mogą być większe w przypadku chmur prywatnych. O ile bowiem takie aspekty funkcjonowania chmur prywatnych jak konsolidacja środowisk produkcyjnych, ujednolicenie i standaryzacja platform czy migracja i replikacja środowisk mają istotny i pozytywny wpływ na decyzje o adaptacji tego modelu, o tyle w przypadku chmur publicznych kwestie nie są już tak oczywiste. Przy zastosowaniu modelu hybrydowego, powstaje wiele problemów, które wynikają między innymi z braku standaryzacji wspierającej interoperacyjność miedzy chmurami lub też zgodność z technologiami i rozwiązaniami wykorzystywanymi w ramach korporacyjnej infrastruktury IT. Funkcjonowanie danych. Systemy BI jako przykład systemów analityki biznesowej definiowaliśmy jako zorientowane na dane systemy wspomagania decyzji. Ten aspekt funkcjonowania tak rozumianych systemów w środowiskach chmur obliczeniowych ma zatem znaczenie fundamentalne. W przypadku chmur prywatnych problemy związane z modelowaniem i integracją danych, ich nieokreśloną lokalizacją czy też transferami są dużo łatwiejsze do pokonania, aniżeli ma to miejsce w modelu hybrydowym. Rozszerzenie systemów analityki biznesowej o usługi oferowane w chmurach publicznych nieodłącznie wiąże się z wymienionymi tu problemami. Dostępność. Chmury prywatne oferują dużo większe możliwości w zakresie kontroli dostępności systemów, aniżeli w przypadku chmur publicznych. Fakt ten jest nie bez znaczenia dla systemów BI. Bezpieczeństwo. Nieodłączne obawy związane z bezpieczeństwem wdrożeń w środowiskach chmur publicznych mogą być ograniczane dzięki implementacji w chmurach prywatnych, gdzie łatwiej o spójność w zakresie korporacyjnej polityki bezpieczeństwa, przeprowadzanie audytów, czy większą kontrolę nad zasobami i dostępem do nich. 192

193 Na obecnym etapie chmury prywatne mogą mieć dla funkcjonowania systemów analityki biznesowej w dużych przedsiębiorstwach znaczenie niepomniejsze, zwłaszcza przy marginalizacji jej zastosowań w chmurach publicznych. Jak zauważyliśmy powyżej, Tabela 10. Typy systemów analityki biznesowej na tle modeli tworzenia infrastruktury w ujęciu korporacyjnym. Źródło: opracowanie własne. Infrastruktura wewnętrzna Tradycyjna infrastruktura Chmury prywatne Infrastruktura zewnętrzna Chmury publiczne Tradycyjne systemy BI Systemy BI wciąż Otwierają możliwości najczęściej stosowane są konsolidacji środowiska w modelu wewnętrznej analitycznego, zwiększają infrastruktury możliwości w w zakresie W ujęciu korporacyjnym bezpieczeństwa i ułatwiają cechuje je słaba podatność kontrolę dostępności, na zmiany oraz minimalizują problemy długofalowość wdrożeń i związane funkcjonowaniem silny stopień centralizacji. danych. W modelu tym występują jednak problemy ze skalowalnością, kwestie zwrotu nakładów inwestycyjnych w stosunku do nie opartej o wirtualizację infrastruktury IT oraz pełne zespolenie wszystkich elementów architektury BI w wirtualizowanym środowisku. Systemy analityki Big Data Systemy analityki Big Dzięki wirtualizacji Z racji bliskości wielu Data wymagają środowiska analityki Big źródłowych dla systemów znacznego zaangażowania Data osiągnięte mogą być analityki Big Data zasobów lub wręcz podobne korzyści do repozytoriów źródłowych niezależnej od BI wirtualizacji tradycyjnych chmury publiczne są dla niej platformy, sytuowanej w platform BI. dogodnym środowiskiem. obrębie korporacyjnego Dzięki architekturze W chwili zaistnienia centrum danych. systemów analityki Big Data konieczności integracji jest ona bardziej podatna na wyników danego systemu funkcjonowanie w analityki Big Data lub systemach rozproszonych. rozszerzenia jego źródeł o zasoby korporacyjne dochodzi do problemów podobnej natury, jak ma to miejsce w przypadku stosowania tradycyjnych systemów analitycznych w chmurach publicznych. SaaS BI W ujęciu korporacyjnym silne uzależnienie od wewnętrznej infrastruktury IT, co warunkuje stosowanie modelu hybrydowego; problemy z funkcjonowaniem danych, bezpieczeństwem, dostępnością oraz wpływem na zarządzanie infrastrukturą w usługach publicznych. Marginalne zastosowania aplikacje małych ilości danych, środowiska testowe, krótkoterminowe analizy adhoc, aplikacje analityczne szerokiego dostępu. Wdrażanie aplikacji analitycznych w modelu SaaS BI dla korporacji ma znaczenie marginalne. Wykorzystywanie usług SaaS BI podlega z reguły inicjatywom wydziałowym o charakterze taktycznym, bezpośrednio finansowanym przez zainteresowane departamenty. 193

194 mogą one także minimalizować problemy, które pojawiają się na gruncie chmur publicznych. Należy jednak pamiętać, że obecne decyzje co do stosowania systemów BI w środowiskach chmur prywatnych zależą od takich problemów jak skalowalność hurtowni danych w systemach rozproszonych, istotny wzrost TCO w stosunku do prywatnych centrów danych, w których systemy BI nie podlegają wirtualizacji, czy decyzje co do umiejscowienia wszystkich czy też tylko poszczególnych elementów architektury BI w chmurze prywatnej Uwarunkowania funkcjonowania systemów analityki biznesowej w małych i średnich przedsiębiorstwach (MŚP) Mając na uwadze powyższe podsumowanie, dziedzina rozważań dotyczących systemów analityki biznesowej w małych i średnich przedsiębiorstwach ulega w stosunku do ujęcia korporacyjnego znacznemu zawężeniu. Z pobieżnego oglądu diagramu ukazanego na rys. 14. wynika, że obszar ten będzie w głównej mierze wytyczony przez zastosowania tych systemów modelu chmur publicznych. Zasadniczo w celu wdrożenia systemów klasy BI, ale też i szerzej rozumianych systemów analityki biznesowej obejmującej choćby systemy analityki Big Data, firmy sektora MŚP rzadko stosują wewnętrzna infrastrukturę. Z oczywistych powodów odnosi się to w głównej mierze do chmur prywatnych, ale jak się przekonamy dotyczy to także tradycyjnej niewirtualizowanej infrastruktury IT podmiotów tego sektora. W raporcie Polskiej Agencji Rozwoju Przedsiębiorczości (PARP), dotyczącym stanu sektora małych i średnich przedsiębiorstw193, czytamy, że polskie przedsiębiorstwa w stosunkowo dużym stopniu zaadoptowały ICT (ang. Information and Communication Technology) na potrzeby komunikacji z podmiotami zewnętrznymi, w tym z kontrahentami lub administracją publiczną, stosując przy tym w zdecydowanej większości ogólnodostępne internetowe usługi bankowe i finansowe lub dwukrotnie częściej niż w UE zaawansowane podpisy cyfrowe w relacjach z klientami i dostawcami. Ponadto na ogólnoeuropejskim poziomie wykorzystują strony internetowe na potrzeby przyjmowania zamówień lub rezerwacji. Jednak ta rudymentarna charakterystyka obrazuje jedynie aspekt komunikacyjny ICT. Autorzy raportu zwracają uwagę, że w bardziej zaawansowanych 193 Łapiński J. (2013) Wpływ Internetu i ICT na gospodarkę i przedsiębiorstwa w Tarnawa A., ZaduraLichota P., red., Raport o stanie sektora małych i średnich przedsiębiorstw w Polsce w latach , PARP, Warszawa, s

195 obszarach funkcjonowania przedsiębiorstw obecne statystyki sytuują polskie przedsiębiorstwa w dużo mniej optymistycznym świetle. Dużo rzadziej, aniżeli w przypadku firm europejskich wykorzystują e-faktury czy też realizują zamówienia za pośrednictwem sieci komputerowych. Rzadziej też kupują lub sprzedają online. Zdecydowanie mniej firm osiąga obroty z handlu elektronicznego. Sytuacja ta obrazuje zatem relatywnie niski stopień zaangażowania w wykorzystywanie oraz adaptację bardziej zaawansowanych technologii informatycznych. Z punktu widzenia problemów związanych z podejmowaniem decyzji Zygała wymienia dwa główne poziomy: strategiczno-taktyczny i poziom operacyjny194. Do pierwszego z tych poziomów należy zaliczyć decyzje prowadzące do zmian technologicznych i innowacji oraz decyzje prowadzące do zmian w strukturze organizacyjnej lub systemie zarządzania. Dużo szerszy zasięg ma poziom operacyjny. W sektorze MŚP na tym poziomie zasadniczo podejmuje się następujące decyzje: pozyskiwanie nowych klientów i kreowanie odpowiedniej polityki wobec nich przy czym kwestie tej ostatniej (np.: rabaty, przyśpieszanie zamówień, terminy płatności i ich zmiana) często są rozpatrywane przez prezesów bądź właścicieli; negocjowanie warunków z dostawcami; bieżące problemy natury logistycznej i zaopatrzeniowej; windykacja należności; zamiany w strukturze wynagrodzeń pracowników; zapewnienie płynności finansowej (planowanie i kontrola czynników finansowych wynagrodzenia, płatności kontrahentom lub urzędom). Chomiak-Orsa zaznacza przy tym, że w sektorze MŚP wdrażanie technologii informatycznych odbywa się zazwyczaj w dwóch perspektywach. Pierwsza z nich to wdrażanie rozwiązań opartych na technologiach internetowych pozwalających na rozwijanie e-handlu do takiej formy ograniczają się najczęściej mikroprzedsiębiorstwa, ze względu na stosunkowo niskie koszty wdrożenia. Druga perspektywa to wdrażanie kompleksowych rozwiązań klasy ERP/MRPII, wspomagających większość obszarów funkcjonowania przedsiębiorstw wykorzystujących m.in. technologie internetowe 195. Ten podział trafnie odzwierciedla zarówno przywołane powyżej statystyki opracowane przez 194 Zygała R. (2009), Uwarunkowania rozwoju systemów business intelligence w sektorze małych i średnich przedsiębiorstw, Informatyka ekonomiczna 13, s Chomiak-Orsa I. (2009), Dylematy podejmowania przedsięwzięć informatycznych w małych i średnich przedsiębiorstwach, Informatyka ekonomiczna 13, s

196 PARP, jak też ogólną charakterystykę decyzji podejmowanych w sektorze MŚP na poziomie operacyjnym. Rozwiązania informatyczne stosowane w MŚP w znacznej mierze różnią się od ukazywanych w toku tej rozprawy196. Mniejsza w stosunku do dużych organizacji złożoność podejmowanych decyzji oraz ich różnorodność wpływają na mniejszą złożoność funkcjonalną. Z uwagi na ewidencyjno-sprawozdawczy charakter rozwiązania informatyczne w MŚP z reguły nie wspierają funkcji analitycznych. Oprogramowanie stosowane przez firmy tego sektora nie stawia dużych wymagań sprzętowych oraz niejednokrotnie nie wymaga ciągłej ingerencji wykwalifikowanej kadry informatycznej. W końcu z reguły są to rozwiązania o relatywnie niskiej cenie zakupu i eksploatacji. Przy czy warto zaznaczyć, że o ile początkowe nakłady wiążące się z zakupem oprogramowania mogą być w wielu przypadkach do zaakceptowania, o tyle konieczność ponoszenia stałych wydatków eksploatacyjnych, wiążących się choćby z dalszymi pracami wdrożeniowymi lub utrzymaniem aplikacji mogą skutecznie wykluczyć decyzję o adaptacji danej technologii. W raporcie firmy McKinsey odnajdujemy ważne fakty dotyczące wpływu ICT na kondycję danych podmiotów197. McKinsey odnotowuje, że wyraźna obecność firm w Internecie przyczynia się bez względu na branżę do dwukrotnego wzrostu obrotów, aniżeli ma to miejsce w przypadku firm nieobecnych w sieci. Firmy obecne w sieci dużo więcej eksportują i tworzą więcej miejsc pracy. Powstaje jednak pytanie: co jednak powstrzymuje ich przed stosowaniem ICT? Szczegółową analizę tego problemu odnajdujemy w pracy Arendta198. Do głównych barier stosowania technologii informatycznych przedsiębiorcy sektora MŚP zaliczają w porządku ważności: brak funduszy; brak wiedzy i umiejętności; brak właściwej orientacji biznesowej (tj. co jest naprawdę istotne w działalności?); brak wykwalifikowanej kadry; brak standardowych procedur operacyjnych; brak długoterminowej strategii biznesowej; 196 Por. Zygała R. (2009) Uwarunkowania rozwoju systemów..., op. cit., s Pelissie du Rausas. M. et al. (2011), Internet matters. The Net's sweeping impact on growth, jobs and prosperity, McKinsey and Company, s Arendt Ł. (2007), Adaptability of the European small and medium-sized enterprises to information and communication technologies, Instytut Pracy i Spraw Socjalnych, Warszawa, s

197 brak odpowiedniego oprogramowania; brak wyznaczonego planu ISP (ang. Information System Plan). Wielicki i Cavalcanti badając bariery zastosowania ICT w tym sektorze w USA, wyraźnie wskazują na istotny wpływ wiedzy i umiejętności zarządczych na stopień adaptacji IT oraz na poprawianie procesów biznesowych199. Twierdzenie to w jawny sposób stoi w opozycji do obiegowego przekonania, że główną przeszkodą na drodze do usprawniania procesów biznesowych za sprawą IT w sektorze MŚP jest ograniczony dostęp do oprogramowania i sprzętu. Kolejny aspekt wykorzystywania ICT w sektorze MŚP wiąże się z problemem wyboru konkretnych zastosowań. Przystosowanie wybranych technologii na potrzeby danego przedsiębiorstwa wymaga uwzględnienia wielu kryteriów, do których zaliczyć należy: kryteria produktowe (technologie wykorzystywane w systemie, funkcjonalność w systemie, cena systemu), kryteria doboru dostawcy (listy referencyjne, sytuacja rynkowa, polityka zatrudnienia dostawcy), warunków umowy czy też ocenę wewnętrznych uwarunkowań. Pomimo oczywistych konsekwencji wynikających z nieuwzględnienia tych czynników małe i średnie przedsiębiorstwa ograniczają się najczęściej do intuicyjnej oceny technologii i systemów informatycznych, dokonywanej przez kadrę zarządzającą, powiązanej niejednokrotnie z upodobaniami estetycznymi200. Systemy klasy Business Intelligence, nawet w swej najbardziej rudymentarnej postaci, są w stanie przyczynić się do zwiększenia efektywności w wymienionych powyżej obszarach decyzyjnych MŚP201. Jednak pomimo jasno rysujących się korzyści z ich zastosowania, wdrożenie systemów tej klasy w sektorze MŚP wiąże się istotnymi barierami. Zygała zalicza do nich między innymi202: niski poziom innowacyjności; przekonanie o braku wpływu nowoczesnych technologii na przewagę konkurencyjną; brak wiedzy; 199 Wielicki T., Cavalcanti G. (2006), Study of Digital Divide: Measuring ICT Utilization and Implementation Barriers Among SMEs of Central California w Abramowicz W., Mayr H. Business Information Systems, 9th International Conference on Business Information Systems, BIS 2006, s Chomiak-Orsa I. (2009), Dylematy podejmowania przedsięwzięć informatycznych..., op. cit., s Por. Ziemba E., Obłąk I. (2012), Systemy informatyczne w organizacjach zorientowanych procesowo, Problemy Zarządzania 10(3), s. 17 oraz Zygała R. (2009) Uwarunkowania rozwoju systemów..., op. cit., s Por. Zygała R. (2009) Uwarunkowania rozwoju systemów..., op. cit., s

198 brak wykorzystania podstawowych narzędzi do analizy danych, np.: arkuszy kalkulacyjnych, co mogłoby przyczynić się do zwiększania świadomości analityki. Przedstawione w tym miejscu charakterystyka decyzji podejmowanych w MŚP, cechy rozwiązań informatycznych oraz uwarunkowania ich adaptacji i wyboru w rozważanym w tym miejscu sektorze, w końcu ograniczenia możliwości zastosowania systemów BI widziane z perspektywy przedsiębiorców zawężają możliwości zastosowania systemów analityki biznesowej w MŚP. W ostatecznym rozrachunku szansą dla ich rozwoju w tym sektorze jest model przetwarzania w chmurach publicznych Ocena możliwości adaptacji SaaS BI w sektorze małych i średnich przedsiębiorstw Punktem wyjścia dla oceny możliwości adaptacji rozwiązań SaaS BI będzie zestawienie dwóch obszarów teoretycznych: 1. W poprzednim podrozdziale przedstawiliśmy uwarunkowania stosowania ICT w MŚP wraz z barierami towarzyszącymi zastosowaniu systemów BI widzianymi z perspektywy przedsiębiorców. Wyróżniliśmy między innymi: typy decyzji podejmowanych; cechy stosowanego oprogramowania; ograniczenia adaptacji ICT; problemy doboru ICT; ograniczenia zastosowań BI; 2. W rozdziale piątym przedstawiliśmy determinanty funkcjonowania systemów SaaS BI. Zaliczyliśmy do nich: marginalizację kompetencji [MK]; funkcjonalność i interfejsy [FI]; uwarunkowania funkcjonowania danych [FD]; uwarunkowania implementacji [UI]; Przedstawione tu dwa obszary teoretyczne stanowią dla siebie przeciwwagę. Z jednej bowiem strony mamy szereg czynników warunkujących stosowanie technologii 198

199 informatycznych, w tym technologii zapewniających funkcjonowanie systemów analityki biznesowej. Z drugiej zaś możliwości rozwoju tej ostatniej za sprawą systemów SaaS BI. Powstaje jednak zasadnicze pytanie, w jaki sposób, mając na uwadze tak założoną dychotomię (uwzględniającą uwarunkowania stosowania ICT w MŚP i determinanty funkcjonowania systemów SaaS BI), możemy ukazać na gruncie empirycznym możliwości adaptacji tych systemów? Stan wykorzystania oraz ogólne uwarunkowania funkcjonowania rozwiązań SaaS BI przybliżają rezultaty badań raportu branżowego firmy Aberdeen Group oraz badania przeprowadzone przez Adelakuna i Kempera203. W pierwszym z wymienionych opracowań zapoznajemy się z ogólną charakterystyką rozwiązań SaaS BI wraz z badanymi przyczynami i ograniczeniami wyboru tych rozwiązań. W drugim opracowaniu odnajdujemy silny nacisk na określenie kryteriów decyzyjności związanych z adaptacją SaaS BI. Przy czym rezultaty drugiego badania odniesione są do dwóch konkretnych komercyjnych usług SaaS BI (YouCalc, QlikTech). Zasadniczo można przyjąć, że ogólna charakterystyka tych usług jak też korzyści z nimi związane w przywołanych opracowaniach pokrywają się z wyżej wymienionymi determinantami funkcjonowania SaaS BI. W celu określenia ram empirycznych dla oceny możliwości adaptacji SaaS BI za punkt wyjścia przyjęto model akceptacji technologii (ang. Technology Acceptance Model TAM). W literaturze poświęconej adaptacji technologii odnajdujemy szereg badań, które uwzględniają klasyczne podejście zaproponowane przez Davisa, modyfikowane w badaniach na wiele sposobów204. W stosunku do rozwiązań SaaS zastosowanie tego kierunku badawczego odnajdujemy w pracy Wu205. Wu wykorzystuje na potrzeby oceny adaptacji usług SaaS model TAM-DTM zaproponowany przez Lopez-Nicolasa, który zintegrował model TAM z teorią dyfuzji informacji (ang. Innovation Diffusion Theory DTM). Główną motywacją badawczą dla Wu byłą przesłanka o relatywnie niskim stopniu rozumienia czynników określających decyzje menedżerskie w klasycznie modyfikowanych modelach TAM (np.: TAM2, TAM3 czy UTAUT). Istotnie, do badań 203 Por. White C. (2010), Fast, Affordable, Agile - The Case for SaaS BI, op. cit. Adelakun O., Kemper T. (2010), Software-as-a-Service Business Intelligence: Adoption Criteria and Business Value, Master's thesis, Jonkoping International Business School. 204 Por. Davis J. (1989), Perceived Usefulness, Perceived Ease of Use, And User Acceptance of Information Technology, MIS Quarterly 13(3), s i Venkatesh V. et al. (2003), User Acceptance of Information Technology: Toward a Unified View, MIS Quarterly 27(3), s i Lopez-Nicolas C., Molina-Castillo F. J., Bouwman H. (2008), An assessment of advanced mobile services acceptance: Contributions from TAM and diffusion theory models, Information Management 45(6), s Wu W.-W. (2011), Developing an explorative model for SaaS adoption, Expert Systems with Applications 38, s

200 oceny adaptacji SaaS, przeprowadzonych przez Wu zaproszeni zostali członkowie kadry menedżerskiej skupionej wokół grupy Taiwan Style Competency Study Group (TSCSG), pochodzących w głównej mierze z Hsin-Chu Science-Based Industry Park (HSIP), a stanowiących grupę wysoko wykwalifikowanych prezesów i menedżerów zainteresowanych innowacjami oraz nowymi technologiami. Rysunek 16. Model oceny możliwości adaptacji SaaS zaproponowany przez Wu. Źródło: Wu W.-W. (2011), Developing an explorative model for SaaS adoption, Expert Systems with Applications 38, s Spróbujmy odnieść model Wu do zarysowanej na wstępie niniejszego podrozdziału dychotomii oraz wyników badań Adelakuna i Aberdeen. Model Wu jako rozwinięcie klasycznego modelu TAM bazuje na dwóch istotnych czynnikach: postrzeganej łatwości użytkowania danej technologii (PEOU Perceived Ease of Use) oraz postrzeganej użyteczności technologii (PU Perceived Usefulnes). Przy czym pierwszy czynnik wpływa na drugi, a ten z kolei przyczynia się do nastawienia do wykorzystania lub adaptacji technologii. Pełne ujęcie modelu Wu wraz z uwzględnionymi w nim czynnikami wpływającymi na adaptację SaaS odnajdujemy na rysunku 16. Spróbujmy usytuować dwa wyróżnione powyżej czynniki (PU, PEOU) na tle dotychczasowych rozważań w odniesieniu do sektora MŚP. Bez względu bowiem na wariację modelu bazującego na TAM są jego nieodłącznym elementem. Badania przeprowadzone przez Adelakuna w wyraźny sposób pokazują, że z punktu widzenia modelu TAM usługi SaaS BI cechuje wysoki stopień postrzeganej łatwości użytkowania 200

201 (PEOU)206. Wśród respondentów dominowały głosy o szybkiej implementacji oraz łatwości użytkowania. Pokrywa się to z teoretycznymi ustaleniami dotyczącymi determinant funkcjonowania SaaS BI [czynniki FI oraz MK]. Ponadto w raporcie Aberdeen decydenci IT za główny powód decyzji o wdrożeniu SaaS BI uznawali zbyt dużą złożoność tradycyjnych rozwiązań BI. Dużo bardziej problematyczne jest ujęcie postrzeganej użyteczności (PU). Otóż zarówno w badaniach Adelakuna, jak też firmy Aberdeen odnajdujemy pozytywny wydźwięk czynników o charakterze ekonomicznym, co w dość naturalny sposób odpowiada opisywanym uwarunkowaniom implementacji SaaS BI [UI]. Z drugiej strony postrzeganiu użyteczności rozwiązań BI w sektorze MŚP towarzyszą takie obiekcje przedsiębiorców jak przeświadczenie o braku wpływu IT na konkurencyjność oraz towarzyszący mu niski poziom innowacyjności. Problem ten znajduje odzwierciedlenie także od strony dostawców: Największym problemem, jaki napotykają obydwaj producenci BI [QlikTech i YouCalc - T.K.] z punktu widzenia klientów jest akceptacja technologii. Wielu klientów nie rozumie możliwości jakie daje im oprogramowanie, a tym samym opiera się przez jego stosowaniem 207. Jednym słowem, możemy przypuścić, że na gruncie modelu TAM postrzegana łatwość użytkowania (PEOU) SaaS BI będzie miała pozytywny wpływ na akceptację technologii, jednak z wymienionych wyżej powodów nie wpłynie na nią postrzegana (jako niska) użyteczność (PU), rozumiana także jako kwestia potrzeby stosowania systemów analityki biznesowej. W tym miejscu rodzi się fundamentalne pytanie: co może wpłynąć na zmianę postrzegania użyteczności? Odpowiedź na to pytanie znajdujemy w dwóch cytowanych już publikacjach oraz w trzeciej, której rezultaty stanowią właściwy fundament dla naszych badań możliwości adaptacji SaaS BI w MŚP. Po pierwsze, Adelakun w odwołaniu do modelu TAM stwierdza, że skuteczny proces adaptacji SaaS BI zależy w głównej mierze od wzmacniania przez dostawców przekazu o łatwości użytkowania oferowanych aplikacji208. Z kolei wyniki Wu wykazują istotny wpływ takich czynników jak wpływ społeczny (SI social influence) oraz wkład marketingowy (ME marketing efforts) na postrzeganą użyteczność (PU) 206 Adellakun O., Kemper T. (2010), Software-as-a-Service Business Intelligence..., op. cit., s Ibid., s Ibid., s

202 rozwiązań SaaS209. Po trzecie, podobne rezultaty odnajdujemy w pracy Benliana oraz współpracowników, pomimo odmiennego podłoża teoretycznego dla tworzonego przez nich modelu oceny adaptacji rozwiązań SaaS210. Rysunek 17. Model TAM, a uwarunkowania implementacji SaaS BI. Źródło: opracowanie własne. Wszystkie te rezultaty oraz związane z nimi sugestie możemy określić mianem strategii upowszechniania potencjału BI (rys. 17). Otóż zalecenia, które odnajdujemy w trzech cytowanych powyżej źródłach w sposób ścisły odpowiadają potencjałowi zastosowania business intelligence w sektorze MŚP. Generalnie na potencjał ten wpływają brak podejścia kalkulacyjnego oraz postawy przedsiębiorców MŚP wobec konkurencyjności. 209 Wu W.-W. (2011), Developing an explorative model for SaaS adoption, op. cit., s Por. Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption An Empirical Study of Different Application Types, Business & Information Systems Engineering 1(5), s

203 Firmy sektora małych i średnich przedsiębiorstw cechuje relatywnie krótki horyzont decyzyjny, który w głównej mierze wpływa na brak podejścia kalkulacyjnego. Wiąże się to w głównej mierze z decyzjami o charakterze operacyjnym, których przykłady wymieniliśmy w poprzednim podrozdziale. Decyzje o takim charakterze wynikają między innymi z trudności w przepływach gotówki oraz reagowania na bieżące problemy211. Z reguły działania przedsiębiorców nakierowane są na poszukiwanie krótkoterminowych Rysunek 18. Model oceny możliwości adaptacji SaaS zaproponowany przez Benliana i współpracowników. Źródło: Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption An Empirical Study of Different Application Types, Business & Information Systems Engineering 1(5), s szans i w zdecydowanej większości przypadków nie są poparte analizami (np.: analizami ryzyka i kosztów)212. Podłożem dla braku podejścia kalkulacyjnego jest także charakter relacji między podmiotami w tym sektorze. Dominują w nim bowiem relacje nieformalne, które podlegają w głównej mierze zaangażowaniu afektywnemu213. Jak widzieliśmy, wpływa to także na procesy dobru (intuicyjnego) ICT. 211 Por. Spence L. (1999), Does size matter? The state of the art in small business ethics, Business Ethics: A European Review 8(3), s Berkowska A., Marczewska-Kuźma R. (2011), Management od Customer Service as a Source of Development of Small and Medium Enterprises w Adamik A., Lachiewicz S., red., Methods and Concepts of Small and Medium-Sized Enterprises Management, Wydawnictwo Politechniki Łódzkiej, Łódź, s Por. Geyskens I. et al. (1996), The effects of trust and interdependence on relationship commitment: A trans-atlantic study, International Journal of Research in Marketing 13, s

204 Drugim biegunem potencjału BI są uwarunkowania konkurencyjności MŚP. Według badań ekspertów Polskiej Konfederacji Pracodawców Prywatnych Lewiatan z 2007 r. polscy przedsiębiorcy za główny środek osiągania przewagi konkurencyjnej uznają kształtowanie cen produktów oraz usług214. Przy czym niewielkie znaczenie dla pozycji konkurencyjnej mają według nich jakość obsługi klientów czy budowanie z nimi trwałych relacji, a za marginalne uznają wąską specjalizację, zdolność do dostosowywania produkcji i usług do wymagań klientów, czy nowatorski i innowacyjny charakter oferowanych produktów. Cena jako kluczowy dla funkcjonowania mniejszych podmiotów gospodarczych czynnik może stanowić istotne podłoże dla kształtowania świadomości wpływania na pozycję konkurencyjną za pomocą systemów analityki biznesowej. Model Wu zarysowuje założenia dotyczące oceny możliwości adaptacji SaaS BI, kierując nas w stronę potencjalnie negatywnego postrzegania użyteczności wspomnianych systemów, które minimalizowane może być w głównej mierze dzięki strategiom upowszechniania potencjału BI w sektorze MŚP. Wykorzystanie tego modelu w badaniach empirycznych wiąże się jednak z istotnym ograniczeniem. Po pierwsze, model TAM uwzględnia faktyczne wykorzystywanie oprogramowania. Określenie zarówno PEOU i PU, a w konsekwencji powiązanych czynników zależy od stosowania konkretnego oprogramowania. Po drugie, przychylamy się do motywacji Benliana, który konstruując alternatywny model oceny adaptacji rozwiązań SaaS, odrzuca teorię dyfuzji i modele akceptacji technologii z dwóch powodów: Po pierwsze, nasze badania [Benliana i współpracowników, T.K.] wyraźnie poszukują wieloaspektowego teoretycznego podejścia do wyjaśnienia adaptacji SaaS, opartego na teoriach, które zostały sprawdzone wielokrotnie w literaturze poświęconej outsourcingowi IT. Po drugie, uwzględnienie decyzji powiązanej z kontekstem outsourcingu, aniżeli z akceptacją technologii jest bliższe codziennym decyzjom menedżerów IT, a tym samym jest istotniejsze z praktycznego punktu widzenia 215. W oparciu o zaproponowany model Benlian i jego współpracownicy przeprowadzili badania oceny adaptacji trzech typów aplikacji oferowanych w modelu SaaS: aplikacji biurowych, CRM oraz ERP. Stosownie do uzyskanych w badaniach Benliana wyników, model ten wykazuje dość skuteczną metodę oceny adaptacji zróżnicowanych aplikacji. 214 Starczewska-Krzysztoszek M. (2007), Monitoring kondycji sektora MSP Konkurencyjność małych i średnich przedsiębiorstw, PKPP Lewiatan, s Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption..., op. cit., s

205 Na dzień obecny w literaturze przedmiotu nie odnaleziono istotnych propozycji teoretycznych, które odnosiłyby się do zarysowanej kwestii potencjału BI oraz jego upowszechniania. Pewną próbą bezpośredniej oceny możliwości adaptacji rozwiązań SaaS BI jest propozycja de Marco i jego współpracowników. Uwzględnia ona co prawda model Benliana, wzbogacając go o aspekty kultury organizacyjnej, ale proponowaną tam metodą badawczą jest zastosowanie jakościowego podejścia bazującego na studiach przypadków216. Mając na uwadze zarówno cytowane powyżej motywacje badawcze, jak też lukę w badaniach empirycznych w obszarze SaaS BI, skłaniamy się do wykorzystania modelu Benliana. Próba przeprowadzenia badań empirycznych oceny adaptacji SaaS BI w oparciu o powyższy model stanowi rozwinięcie perspektywy przyjętej w pracy źródłowej o założenia funkcjonowania systemów analityki biznesowej. Model ten zgodnie ze źródłową metodą zostanie wykorzystany na potrzeby badań ilościowych. Spróbujmy zatem przybliżyć założenia funkcjonowania modelu Benliana i jego współpracowników. Głównym podłożem teoretycznym dla empirycznej oceny możliwości adaptacji oprogramowania oferowanego w modelu SaaS są trzy perspektywy teoretyczne odnoszące się do zagadnień outsourcingu217: teoria kosztów transakcyjnych (ang. transaction cost theory - TCT), podejście zasobowe (ang. resource-based view - RBV) oraz teorię planowego zachowania (ang. theory of planned behvior TPB) (rys. 18). W rozwinięciu teorii kosztów transakcyjnych wprowadzonej przez Coase'a oraz odniesieniu jej do koncepcji outsourcingu Williamson zauważył, że różnice kosztów transakcyjnych widziane z perspektywy outsourcingu zależą głownie od dwóch czynników: unikalności zasobu oraz niepewności co do outsourcingu danego zasobu218. Dalsze badania dowiodły, że w przypadku usług SaaS specyficzność (unikalność) aplikacji, określona przez stopień kastomizacji, integracji oraz modularyzacji jest istotnym czynnikiem wpływającym na adaptację usługi219. Natomiast niepewność co do biznesowych (np.: cena, procesy, poziomy usługowe) i technicznych (np.: zmiana uwarunkowań technicznych w czasie) aspektów outsourcingu danego zasobu wpływają 216 Por. Marco de M. et al. (2010), BI as a service - an attempt to understand the leading adoption factors w International Conference on E-Business Intelligence (ICEBI 2010), Atlantis Press, s W tym ujęciu usługi SaaS są traktowane jako forma outsourcingu. 218 Por. Williamson O. (1991), Comparative economic organization: The analysis of discrete structural alternatives., Administrative Science Quarterly 36(2), s Por. Benlian A. (2009), A transaction cost theoretical analysis of software-as-a-service (SAAS)-based sourcing in SMBs and enterprises w ECIS 2009 Proceedings, paper

206 negatywnie na decyzję o podjęciu outsourcingu tego zasobu220. Wyniki te pociągają za sobą dwie następujące hipotezy: H1: specyficzność aplikacji jest negatywnie powiązana z adaptacją SaaS. oraz H2: niepewność biznesowa i techniczna towarzysząca usłudze jest negatywnie powiązana z adaptacją SaaS. Stosownie do podejścia zasobowego organizacja może korzystnie pozycjonować siebie na tle innych organizacji w zależności od zasobów (unikalnych, rzadkich lub nieimitowanych), które wpływają na wartość strategiczną. Benlian i jego współpracownicy argumentują, że przypisywanie przez organizację strategicznej roli aplikacji wykorzystywanej w modelu SaaS ma wpływ na jej adaptację. Podobnie imitowalność aplikacji, rozumiana tu jako możliwość jej zastąpienia przez inną lub wręcz przez zadania manualne, będzie wpływać na adaptację usług na żądanie. Na tej podstawie zakładamy dwie kolejne hipotezy: H3: strategiczna wartość aplikacji jest negatywnie powiązana z adaptacją SaaS. oraz H4: nieimitowalność aplikacji jest negatywnie powiązana z adaptacją SaaS. Trzeci z obszarów teoretycznych stanowiących podstawę konstrukcji modelu Benliana to teoria planowego działania. Za wyborem tej teorii stoi argument, że decyzje (tu decyzje odnośnie usługi SaaS) podejmowane są przez konkretne jednostki, aniżeli przez organizacje jako takie. W świetle teorii planowego zachowania wybór pewnej opcji zależy od indywidualnego nastawienia do działania (intencji), uzależnionego od stosunku do tego działania oraz normy subiektywnej. Pierwszy z tych dwóch komponentów (stosunek do działania) na gruncie technologii informatycznych może być uzależniony od indywidualnych przekonań opartych na ocenie rozpowszechnienia technologii na rynku, ocenie korzyści kosztowych oraz ewaluacji wpływu technologii na procesy i wydajność. Przekonania powiązane z tymi aspektami wpływają na podjęcie decyzji. W kontekście rozpatrywanego modelu za podstawę stosunku do działania (tu: stosunek do adaptacji SaaS) przyjęto przekonania powiązane z teorią kosztów transakcyjnych oraz podejściem zasobowym. Sam stosunek do działania należy uznać za mediator między charakterystyką aplikacji, a faktycznym zastosowaniem SaaS. Zatem w odniesieniu do stosunku do działania wysnuto cztery następujące hipotezy: 220 Dibbern J., Goles T., Hirschheim R. and Jayatilaka B. (2004), Information systems outsourcing: a survey and analysis of the literature, ACM SIGMIS Database 34(4), s

207 H5: specyficzność aplikacji jest negatywnie powiązana ze stosunkiem do adaptacji SaaS. oraz H6: niepewność biznesowa i techniczna towarzysząca usłudze jest negatywnie powiązana ze stosunkiem do adaptacji SaaS. oraz H7: strategiczna wartość aplikacji jest negatywnie powiązana ze stosunkiem do adaptacji SaaS. oraz H8: nieimitowalność aplikacji jest negatywnie powiązana ze stosunkiem do adaptacji SaaS. oraz H9: stosunek do adaptacji SaaS jest pozytywnie powiązany z adaptacją SaaS. Drugi komponent wpływający na nastawienie do działania to normy subiektywne. W świetle przeprowadzanych badań decyzje dotyczące zastosowań technologii nie zawsze wynikają z oceny i porównań alternatywnych opcji. Uzależnione są niejednokrotnie od postawy odzwierciedlającej decyzje innych organizacji221. W odniesieniu do SaaS, jako modelu obecnie o relatywnie niskiej dojrzałości, decyzje mogą zależeć także od wpływu innych podmiotów, takich jak firmy badające rynek, konsultantów IT, dostawców SaaS, stowarzyszenia branżowe. Norma subiektywna poza wpływem na decyzję może także wpływać na formowanie się przekonań. Na tej podstawie można wysnuć dwie następujące hipotezy: H10: norma subiektywna (tu: pozytywna opinia stron trzecich) jest pozytywnie powiązana z adaptacją SaaS. oraz H11: norma subiektywna jest pozytywnie powiązana ze stosunkiem do adaptacji SaaS. 221 Por. Lacity M., Hirschheim R. (1995), Beyond the information systems outsourcing bandwagon: the insourcing response., Wiley, Chichester. 207

208 6.7. Empiryczna analiza możliwości adaptacji SaaS BI. Analiza empiryczna oceny możliwości adaptacji SaaS BI została dokonana w oparciu o przedstawione w poprzednim podrozdziale hipotezy. Przy czym rozwiązania SaaS BI zostały tu potraktowane jako szczególny rodzaj aplikacji oferowanej w modelu outsourcingowym. Stosownie do badań źródłowych Benliana i jego współpracowników w Stopień adaptacji SaaS BI (DSA) Stosunek do Norma subiektywna (SN) adaptacji SaaS BI (ATSA) Ogólnie, s tosow anie aplikac ji BI w modelu SaaS jest... A TSA 2 Ogólnie, s tosow anie aplikac ji BI w modelu SaaS jest... A TSA 3 Ogólnie, s tosow anie aplikac ji BI w modelu SaaS jest... SN1 Osoby, grupy lub insty tucje, któryc h opinia jest w aż na dla naszej organiz ac ji uw ażają, ż e stos ow anie aplikacji BI w modelu SaaS jest... SN2 Osoby, grupy lub insty tucje, któryc h opinia jest w aż na dla naszej organiz ac ji uw ażają, ż e stos ow anie aplikacji BI w modelu SaaS jest... SN3 Osoby, grupy lub insty tucje, któryc h opinia jest w aż na dla naszej organiz ac ji uw ażają, ż e stos ow anie aplikacji BI w modelu SaaS jest... A S1 A rchitektura s tosow anej aplikac ji BI jes t modularna w s topniu... A S2 Stosow ana aplikacja BI jest dopasow yw ana do indy w idualnyc h potrzeb w stopniu... A S3 Stosow ana aplikacja BI jest zintegrow ana z ogólną inf rastrukturą s ys temów i aplikacji w stopniu... PU1 Stosow anie aplikac ji BI w modelu SaaS podlega problemom tec hnic znym (przepustow oś ć, dostępność) w stopniu... PU2 Stosow anie aplikac ji BI w modelu SaaS podlega zależnośc iom ekonomicz ny m (np.: zmiany w modelach cenow yc h subs krypcji) w s topniu... PU3 Stosow anie aplikacji BI w modelu SaaS uzależnia f unkcjonow anie kluc zow ych procesów f irmy (np.: w przypadku pogors zenia jakości lub braku dos tępnoś ci us ługi) w stopniu... SV 1 A plikac ja BI ma s trategicz ne znacz enie dla naszej f irmy SV 2 A plikac ja BI przyc zy nia się z nacząco do realiz acji c elów f irmy SV 3 Brak aplikacji BI doprow adziłby do pogors zenia konkurencyjnośc i A I1 A plikac ja BI jes t zasobem f irmy, który nie może być zamieniony na komplementarny A I2 A plikac ja BI ma s pecy f icz ne dla f irmy konf igurac je, które nie mogą by ć dostarc zone przez s trony trzecie A I3 Konf igurac ja aplikacji BI jes t z nacząco odmienna od konf iguracji dos tarcz anych prz ez konkurency jnyc h dostaw ców Nieimitow alność aplikacji (AI) Specyficzność aplikacji (AS) A TSA 1 Postrzegana niepew ność (PU) Indykator DSA 1A Strategiczna w artość aplikacji (SV) Kons trukt Prosz ę podać prz ybliżony /esty mow any udz iał procentow y budż etu IT aplikac ji BI przy dz ielony dla modelu SaaS w 2012 i 2014 r. DSA 1B DSA 2A Prosz ę podać przybliżony /estymow any poz iom w ykorzy stania aplikac ji SaaS BI w stos unku do trady cyjnyc h aplikac ji BI w 2012 i 2014 r. (100% - jeśli aplikac ja BI jest w y korz ys ty w ana ty lko w modelu SaaS). DSA 2B Tabela 11. Model oceny adaptacji SaaS BI na podstawie Benlian A. et al. (2009). Konstrukty i indykatory. Źródło: opracowanie własne. celu weryfikacji hipotez zastosowano podejście modelowania równań strukturalnych (ang. structural equatation modeling) z wykorzystaniem metody najmniejszych częściowych kwadratów (ang. partial least squares). Jako jedną z technik modelowania z nurtu SEM zastosowano analizę ścieżek (ang. path analysis), która umożliwia poszukiwanie 208

209 zależności przyczynowych między zmiennymi, które nie są bezpośrednio obserwowalne (zmienne ukryte lub także konstrukty)222. Miary i zmienne. Na podstawie modelu zaproponowanego przez Benliana i współpracowników miary zmiennych ukrytych dla oceny adaptacji SaaS BI zostały określone na podstawie miar z badań źródłowych. Przy czym pojęcie aplikacji SaaS BI zastało zastąpione ogólnym pojęciem aplikacji w modelu źródłowym. Do oceny możliwości adaptacji SaaS BI wykorzystano 22 pytania, z których na 18 respondenci udzielali odpowiedzi w 7-stopniowej skali. Dla konstruktów specyficzność aplikacji (AS), postrzegana niepewność (PU), strategiczna wartość aplikacji (SV), nieimitowalność aplikacji (AI) użyto 7-stopniowej skali Likerta. Natomiast dla stosunku do adaptacji SaaS BI (ATSA) i normy subiektywnej (SN) wykorzystano 7-punktową skalę bipolarną. Stopień adaptacji SaaS BI (DSA) określono przy pomocy procentowego udziału budżetu SaaS BI w całkowitym budżecie BI w latach 2012 i 2014 (DSA1) oraz procentowego stopnia wykorzystania SaaS BI w stosunku do wykorzystania BI w latach 2012 i 2014 (DSA2). Konstrukty oraz indykatory wykorzystywane w modelu przedstawia tabela 11. Pomiar i charakterystyka próby. Test hipotez oraz modelu został przeprowadzony w oparciu o badania ankietowe. Badania zrealizowano we współpracy z firmą IDG Poland, która odpowiedzialna była za dystrybucję zaproszeń do ankiety oraz ich weryfikację techniczną. Badania te zostały przeprowadzone w dwóch turach na przełomie lipca i sierpnia 2013 r. W oparciu o zgromadzoną przez IDG Poland bazę teleadresową w pierwszej turze za pośrednictwem poczty elektronicznej do udziału w badaniach zaproszeni zostali członkowie kadry IT, wykazujący zainteresowanie systemami klasy BI. W tej turze wysłano 2335 zaproszeń. W drugiej turze zaproszenia zostały rozesłane także do grupy menedżerów IT bez wskazania na zainteresowanie systemami BI. W ostatniej turze w sumie wysłano 4342 zaproszenia. 222 Chin W. (1998), The partial least squares approach for structural equation modeling w Marcoulides G A., red., Modern methods for business research, Lawrence Erlbaum Associates, Hillsdale, s , Strzała K. (2006), Modelowanie równań strukturalnych: koncepcja i podstawowe pojęcia, Prace i Materiały Wydziału Zarządzania Uniwersytetu Gdańskiego, Nr. 2, s , Cwalina W. (2000), Zastosowanie modelowania równań strukturalnych w naukach społecznych, Statsoft Polska, 209

210 Ankieta została przygotowana w oparciu o niezależną, internetową platformę ankietową i dostępna była dla zainteresowanych od do (Załącznik A). Ogółem ankietę otworzyło 119 osób, wypełniły ją zaś 24 osoby. Do analizy statystycznej Liczba zatrudnionych pracowników w firmie % % 20% 70% < 2 mln euro 4 20% mln euro 2-10 mln euro > 50 mln euro b/d % 15% 35% 10% Przemysł 7 35% Handel Administracja Finanse i bankowość Zdrowie Inna % 10% 10% 10% 20% Menedżer IT 8 40% Administrator BI Manager Inne Konsultant Programista % 10% 10% 5% 5% Tak 12 60% Nie 8 40% >250 Przychody firmy Branża firmy Stanowisko respondenta Czy firma korzysta z rozwiązań Business Intelligence? Tabela 12. Badania oceny możliwości adaptacji SaaS BI. Charakterystyka próby. Źródło: opracowanie własne. zakwalifikowano ostatecznie 20 ankiet, a charakterystykę próby przedstawia tabela 12. Należy podkreślić, że tak niski stopień oddźwięku wśród osób zaproszonych do udziału w badaniach odzwierciedla powszechny problem w badaniach ankietowych w obszarze IT223. Analiza danych i wyniki. Trafność i rzetelność. Na potrzeby analizy danych wykorzystano oprogramowanie SmartPLS224. Zgodnie z zaleceniami Fornela i Larckera akceptowalną wartością trafności zbieżnej mierzoną przeciętną wariancją wyodrębnioną (ang. average variance extracted, AVE) jest wartość wyższa niż 0.5. Natomiast minimalną wartością współczynnika 223 Por. Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption..., op. cit., s Ringle, C.M., Wende, S., Will, S.: SmartPLS 2.0 (M3) Beta, Hamburg 2005, 210

211 rzetelności łącznej (ang. composite reliability, CR) jest wartość pokazuje, że dla wykorzystanych w modelu konstruktów zarówno AVE, jak i CR spełniają minimalne kryteria (tabela 13). W związku z tym, stosowanie do zaleceń Fornella i Larckera, badania spełniają kryteria trafności zbieżnej i rzetelności wewnętrznej. Model pomiaru wykazuje także trafność dyskryminacyjną, określoną na podstawie ładunków krzyżowych (ang. cross-loadings)226 (tabela 14). Ponadto w oszacowanym modelu ładunki czynnikowe są istotne na przyjętym poziomie p < konstrukt przeciętna wariancja wyodrębniona (average variance extracted, AVE) współczynnik rzetelności łącznej (composite reliability,cr) AI 1,000 1,000 AS 1,000 1,000 ATSA 0,773 0,910 DSA 0,754 0,924 PU 0,729 0,841 SN 0,881 0,957 SV 0,898 0,950 Tabela 13. Ocena jakości modelu pomiaru: trafność zbieżna i rzetelność wewnętrzna. Źródło: opracowanie własne. Analiza związków przyczynowych. Do oceny jakości modelu zastosowano współczynnik determinacji (R2). W wyniku dokonanej analizy statystycznej adaptacja SaaS BI jest wyjaśniana przez model w 49% (R2). Można zatem uznać, że model cechuje akceptowalne dopasowanie. Ponadto stosunek do adaptacji SaaS BI został wyjaśniony przez model w 62% (R2). Weryfikacja hipotez podlega ocenie istotności statystycznej współczynników ścieżkowych mierzących wpływ czynników. Trzy z tych współczynników okazały się statystycznie istotne. W oszacowanym modelu pominięto zmienne obserwowalne o nieistotnym wpływie na konstrukty (rys. 19). 225 Fornell C., Larcker D. (1981), Evaluating structural equation models with unobservable variables and measurement error, Journal of Marketing Research 18(1), s Por. także Przechlewski T. (2010), Sposoby oceny modelu pomiaru w praktyce informatyki ekonomicznej, Henseler J., Ringle C., Sinkovics R. (2009), The use of partial least squares path modeling in international marketing w New Challenges to International Marketing Advances in International Marketing, Emerald Group Publishing Limited, s

212 AI AS ATSA AI1 1,000 0,196-0,109 AS1 0,196 1,000 ATSA1-0,189 ATSA2 DSA PU SN SV 0,356-0,084-0,231 0,463 0,258 0,085 0,270-0,011 0,600 0,243 0,961 0,262-0,515 0,629-0,022-0,389 0,000 0,802 0,000-0,453 0,362-0,284 ATSA3 0,208 0,372 0,867 0,285-0,407 0,586 0,254 DSA1A 0,270 0,046 0,192 0,833-0,022 0,346 0,311 DSA1B 0,295 0,077 0,271 0,949-0,285 0,493 0,308 DSA2A 0,378 0,075 0,186 0,895-0,300 0,319 0,480 DSA2B 0,285 0,096 0,148 0,787-0,329 0,349 0,271 PU1-0,046 0,264-0,564-0,301 0,967-0,470 0,169 PU2-0,157 0,188-0,207-0,115 0,724-0,119 0,196 SN1-0,308 0,000 0,464 0,312-0,271 0,927-0,020 SN2-0,252-0,031 0,537 0,360-0,406 0,961-0,009 SN3-0,129 0,000 0,686 0,508-0,457 0,928-0,054 SV1 0,417 0,625 0,141 0,398 0,134 0,081 0,955 SV3 0,464 0,506-0,133 0,358 0,243-0,159 0,941 Tabela 14. Ocena jakości modelu pomiaru: trafność dyskryminacyjna (ładunki krzyżowe). Źródło: opracowanie własne. Do ścieżek istotnych statystycznie należy zaliczyć: postrzegana niepewność (PU) stosunek do adaptacji SaaS BI (ATSA) (H6) specyficzność aplikacji (AS) stosunek do adaptacji SaaS BI (ATSA) (H5) norma subiektywna (SN) stopień adaptacji SaaS BI (DSA) (H11) Interpretacja wyników W wyniku oszacowania modelu dwie z zaproponowanych hipotez zostały (H6, H11) poparte zebranymi danymi, natomiast jedna z hipotez została zaprzeczona (H5). W źródłowych badaniach Benliana i współpracowników w ogólnej ocenie możliwości adaptacji rozwiązań SaaS największą rolę odgrywała teoria planowego działania227. Wyniki tych badań dowodzą, że norma subiektywna ma istotny wpływ na stosunek do adaptacji SaaS, jak też na sam stopień adaptacji tych rozwiązań. Z punktu widzenia zaawansowanych technologii opartych na modelach outsourcingu decyzje nie zawsze opierają się na rzeczowych porównaniach i ocenie. Dotyczy to w głównej mierze sektora MŚP. Jednak nawet w przypadku większych organizacji podlegają one niejednokrotnie pewnej formie imitacji zachowań lub decyzji innych podmiotów. W tym kontekście przeprowadzona analiza ukazuje trzy związki między wybranymi czynnikami. 227 Por. Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption..., op. cit., s

213 Pierwszy dotyczy niepewności towarzyszącej implementacji usług proponowanych przez dostawców w modelu SaaS (PU ATSA, por. rys. 19). Ten wynik wspiera zarówno Rysunek 19. Oszacowany model oceny możliwości adaptacji SaaS BI (*p < 0.05; n nieistotny statystycznie). Źródło: opracowanie własne. podłoże teoretyczne oparte na teorii kosztów transakcyjnych, jak też uprzednio cytowane badania firmy Aberdeen. Drugi ze związków (AS ATSA, por. rys. 19) także wiąże się z tym obszarem. Jego interpretacja na tle założonych hipotez jest jednak problematyczna. Zgodnie z jedną z hipotez specyficzność aplikacji negatywnie wpływa na stosunek do adaptacji SaaS BI. Wyniki przeprowadzonych badań ankietowych ukazują jednak wpływ o przeciwnym charakterze. Prawdopodobna przyczyna leży tu w ocenie trafności czynnika AS, gdyż dwie pozostałe zmienne objaśniające reprezentujące pojęcie specyficzności aplikacji nie mogły być uwzględnione w oszacowanym modelu z uwagi na założone kryteria trafności oraz na istotność statystyczną. Nieco odmienne światło zyskuje trzeci ze związków (SN DSA, por. rys. 19), który w sposób bezpośredni odnosi się do adaptacji SaaS BI. Po pierwsze, kwestia oceny trafności teoretycznej samej zmiennej pozostaje jednoznaczna. Ponadto pomimo braku możliwości oceny wpływu na stosunek do adaptacji SaaS BI, czynnik ten wykazuje bezpośredni związek z faktycznym zastosowaniem systemów. Oznacza to, że sama norma subiektywna jest istotnym czynnikiem wpływającym na adaptację SaaS BI. W podsumowaniu ogólnej oceny możliwości adaptacji SaaS Benlian tak odnosi się do kwestii normy subiektywnej: 213

214 Nawet jeśli firmy o nastawieniu technologicznym często nie ulegają bezrefleksyjnie ocenie stron trzecich, posiłkując się uważną oceną alternatywnych usług popartą np.: analizą kosztów i zasobów, to ich stosunek do SaaS w istotny sposób zależy od opinii ekspertów oraz od presji ze strony innych podmiotów. W związku z tym dostawcy SaaS powinni aktywnie angażować się w kształtowanie opinii ekspertów i innych stron, takich jak stowarzyszenia lub lobby, które mają dużo do powiedzenia w sprawach stosowania nowych technologii 228. Dostawcy powinni zatem wpływać na ukazywanie korzyści płynących z zastosowania SaaS BI, przy jednoczesnym znoszeniu negatywnego wpływu elementów z postulowanych obszarów, uwzględnionych w modelu. Dotyczy to między innymi postrzeganej niepewności powiązanej z postrzeganiem ryzyka technicznego i ekonomicznego. Taka strategia dotyczy jednak w głównej mierze większych organizacji. Jednakże ustalone fakty odnoszą się także bezpośrednio do postulowanej w poprzednim podrozdziale strategii upowszechniania BI w MŚP. Dobrowolna inicjatywa dotycząca bardziej zaawansowanych technologii wśród małych i średnich przedsiębiorstw jest stosunkowo rzadka. W większości przypadków decyzje o zastosowaniu konkretnej technologii w tym sektorze wspierane są przez podmioty zewnętrzne, bez wsparcia których inicjatywy te nie byłyby podejmowane229. Uzyskane rezultaty dopełniają wyniki empiryczne uzyskane przez Adelakuna i firmę Aberdeen, jak też rozszerzają perspektywę adaptacji SaaS zaproponowaną przez Benliana. Z punktu widzenia adaptacji SaaS BI w MŚP zestawienie tych źródeł odnosi się w ścisłej mierze do trzech wymienionych determinant funkcjonowania SaaS BI: marginalizacji kompetencji [MK], funkcjonalności i interfejsów [FI], uwarunkowań implementacji [UI] (por. rys. 17). Należy jednak podkreślić, że postulowane podłoża teoretyczne w wykorzystywanych źródłach, jak też w adoptowanym modelu nie odnoszą się do czwartej determinanty, jaką są uwarunkowania funkcjonowania danych [FD]. Przy czym, zgodnie z ustaleniami z rozdziału piątego negatywne skutki tego czynnika mogą być łatwiej minimalizowane w małych i średnich przedsiębiorstwach o relatywnie niewielkich i niezłożonych źródłach danych wykorzystywanych w konkretnej usłudze SaaS BI. 228 Ibid. 229 Arendt Ł. (2007), Adaptability of the European small and medium-sized enterprises..., op. cit., s

215 6.8. Wnioski i podsumowanie rozważań W celu podsumowania rozważań rozprawy, wyniki badań oraz analiz tego rozdziału spróbujemy odnieść do wcześniejszych ustaleń. W tym celu w sposób systematyczny umiejscowimy tezy dotyczące zastosowania oraz systemów analityki biznesowej na tle ogólnej analizy ETO chmur obliczeniowych. W rozdziale czwartym dokonaliśmy wstępnej oceny uwarunkowań funkcjonowania i zastosowania chmur obliczeniowych z podziałem na duże organizacje oraz małe i średnie przedsiębiorstwa. Uzyskane rezultaty rozważań dotyczących funkcjonowania systemów analityki biznesowej możemy odnieść właśnie do tego podziału oraz uwzględnionych w nim charakterystyk. Podsumowanie podzielimy zatem na dwie części. 1. Dla dużych organizacji omawiane przykłady systemów analityki biznesowej sytuowaliśmy w dwóch modelach upowszechniania chmur obliczeniowych: chmurach publicznych i prywatnych. Wdrożenie i wykorzystywanie tych systemów w środowiskach chmur obliczeniowych podlega różnorodnym kryteriom, które ogólną analizę uwarunkowań funkcjonowania chmur obliczeniowych rysują w odmiennym świetle. Tabele 15 i 16 oraz tabele 18 i 19 przedstawiają porównanie dwóch wspomnianych modeli wykorzystywanych na potrzeby systemów analityki biznesowej. W tabelach tych zaznaczono zmiany znaczenia czynników w stosunku do analizy ogólnej230 oraz różnice (symbol D ) między znaczeniami czynników w dwóch porównywanych modelach. Np.: zastosowanie przez duże organizacje systemów analityki biznesowej w chmurach publicznych wiąże się z problemami w zarządzaniu systemami IT (konsolidacja, ujednolicenie platform oraz migracja środowisk). Czynniki te mają zatem negatywny wpływ, nie zaś wpływ pozytywny, na co wskazuje analiza ogólna. Naturalnie wiele z czynników może cechować nie tylko znaczenie przeciwne, ale także marginalne (symbol n ). W niniejszej ocenie przyjęto zasadę, że czynnik o charakterze neutralnym dla zastosowania systemu analityki biznesowej w danym modelu upowszechniania chmur obliczeniowych nie będzie brany pod uwagę w określeniu udziału danego wymiaru (ekonomicznego, technicznego lub organizacyjnego) w danym z elementów matrycy (np.: mocne strony ) Wyniki analizy ogólnej ETO znaleźć można tabelach 3-6 (rozdz. 4). 231 Por. rozdz

216 Przeniesienie rezultatów rozważań dotyczących możliwości zastosowania systemów analityki biznesowej w środowisku chmur obliczeniowych na grunt analizy ETO potwierdza dotychczasowe tezy. W przypadku wdrożeń tych systemów w środowisku chmur publicznych ukazane w rozdziale czwartym relacje nie ulegają zasadniczym zmianom (tabele 15 i 18). W związku z tym konkluzje, dotyczące w głównej mierze przeciwwagi wymiarów ekonomicznego i organizacyjnego, mogą być utrzymane. Oznacza to, że decyzje dotyczące zastosowań podlegać muszą trudnej ewaluacji korzyści i barier. Uznanie za dopuszczalne zastosowań o charakterze taktycznym i akcydentalnym w takim modelu może zminimalizować ryzyko płynące się z takiej polaryzacji. W dużo korzystniejszym świetle rysują się możliwości zastosowania omawianych systemów w modelu chmury prywatnej (tabele 16 i 19). Analiza ETO dla takich scenariuszy przedstawia zminimalizowane ryzyko płynące z zagrożeń przy jednoczesnym utrzymaniu korzyści natury ekonomicznej. Ponadto szereg czynników wymiaru technicznego uzyskuje przeciwne znaczenie, co sprawia, że negatywne aspekty tego wymiaru przedstawione w analizie ogólnej są minimalizowane. Tym samym problematyczna przeciwwaga (wymiar ekonomiczny versus organizacyjny) występująca w poprzednim ze scenariuszy zostaje względnie zniesiona. 2. Przeniesienie wyników analizy oceny możliwości rozwiązań SaaS BI na grunt analizy ETO wymaga przypisania omawianych w poprzedniej części determinant funkcjonowania rozwiązań SaaS BI do wyróżnionych czynników analizy ETO. Do poniższych determinant zaliczymy następujące czynniki analizy ETO: marginalizacja kompetencji - redukcja personelu IT, ułatwione wsparcie i szkolenie użytkowników oraz zarządzanie zmianą procesów; funkcjonalność i interfejsy - przeglądarka jako platforma oraz funkcjonalna zwięzłość; uwarunkowania implementacji - różne potrzeby w czasie, nierozpoznane potrzeby w czasie, elastyczność alokowania zasobów oraz rozwój i adaptacja systemów; funkcjonowanie danych - modelowanie i integracja danych, nieokreślona lokalizacja oraz transfer danych232 Wyniki przeprowadzonej w tym kontekście analizy ETO ukazują zniwelowanie wielu związków między udziałami czynników w odniesieniu do analizy ogólnej. Dwie ze 232 Poszczególne czynniki wymienionych determinant zostały wyróżnione w kolumnie SaaS BI tabeli

217 znaczących relacji występują w obszarach ekonomicznym i organizacyjnym. W przypadku sektora MŚP za kluczową barierę dla zastosowań ICT uznaliśmy kwestie ekonomiczne. Należy zatem uznać, że występująca, także i w tym scenariuszu przeciwwaga wymiarów ekonomicznego i organizacyjnego będzie w skuteczny sposób niwelowana z racji charakteru samych decyzji związanych z wykorzystywaniem technologii informatycznych wśród małych i średnich przedsiębiorstw, co przemawia za możliwością szerokiego zastosowania rozwiązań SaaS BI w tego typu przedsiębiorstwach. Wyniki badań empirycznych przeprowadzonych przez cytowane, niezależne zespoły badawcze w wielostronny sposób ugruntowują zasadność determinant funkcjonowania SaaS BI, jak też ich wpływu na zastosowania tych rozwiązań. Problematyczne jednak dla zastosowania, a tym samym i rozwoju wspomnianych systemów jest podjęcie inicjatywy lub decyzji przez konkretny podmiot, zmierzającej do zastosowania danej usługi. Badania empiryczne zrealizowane na potrzeby tej rozprawy dowodzą, że wpływ stron trzecich na decyzję o zastosowaniu SaaS BI ma znaczenie kluczowe. Wniosek ten można także przenieść na grunt dokonanej w obszarze SaaS BI analizy ETO (tabele 17 i 20). Stosownie do wniosków zawartych w poprzednim podrozdziale, dostawcy oraz inne podmioty kształtujące normę subiektywną mogą (oprócz wzmacniania korzyści) w skuteczny sposób niwelować negatywny wydźwięk czynników, do których zliczyć można kwestie bezpieczeństwa, problemy prawne i zamknięcia. 217

218 Tabela 15. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych dla dużych przedsiębiorstw. Źródło: opracowanie własne. Mocne strony PU E Zrządzanie infrastrukturą Aplikacje Skalowalność Bezpieczeństwo konsolidacja środowisk produkcyjnych ujednolicenie i standaryzacja platform migracja, replikacja, automatyzacja środowisk redukcja personelu IT ułatwione wsparcie i szkolenie użytkow. a. o skali internetowej a. o sporadycznym zapotrzebowaniu a. niestrategiczne a. przyrostu danych model kliencki przeglądarka jako platforma funkcjonalna zwięzłość zarządzanie zmianą procesów FLOSS licencjonowanie różne potrzeby w czasie nierozpoznane potrzeby w czasie elastyczność alokowania zasobów rozwój i adaptacja systemów korzyści skali standaryzacja audyty i informatyka śledcza aktualizacje lepsze zarządzanie ryzykiem koncentracja środowisk i platform T - O - Szanse Green IT Bezpieczeństwo Rynek Innowacje E identyfikacja niewykorzystanych zasobów wydajność PUE pozytywny wpływ na technologie wirtualizacji ekologia funkcjonalności regulacje dot. audytów i standardów element przewagi konkurencyjnej dostawców intensyfikacja relacji biznesowych przedsięwzięcia typu start-up niezależność inwestycyjna kraje rozwijające się otwartość aplikacje mashup długi ogon T O PR Słabe strony D D D D n D PU PR D..... n D n D n D D n D n D n D n D Aplikacje Funkcjonowanie danych Bezpieczeństwo Dostępność a. historyczne a. czasu rzeczywistego a. z dostępem do poufnych danych modelowanie i integracja danych nieokreślona lokalizacja transfer danych błędy technologii wirtualizacji błędy separacji zasobów naruszenie interfejsów zarządzania niedefinitywne usunięcie danych błędne wyliczenie koniecznych zasobów nieprzewidywalność wydajności błędy systemów wielkoskalowych E - T PU PR D.. D D D D.. D D... PU PR D D D D. n D n D n D n D n D -/ O Zagrożenia E Zmiany w zarządzaniu Rynek pracy Dostępność Problemy prawne Rozeznanie i adaptacja Bezpieczeństwo Problem zamknięcia utrata kontroli zmiana procesów i procedur konieczność spójnej polityki IT redukcje stanowisk pracy zaprzestanie świadczenia usług (dostawcy) problemy łańcucha dostaw nieuczciwe praktyki innych usługobiorców brak informacji o jurysdykcji brak odszkodowań za faktyczne straty rozpoznanie koniecznych umiejętności wewnętrzny opór organizacyjny adaptacja użytkowników nadużycie przywilejów dostawcy zmiany organizacyjne dostawców EDoS celowe zamknięcie przez dostawców problemy eksportu/importu danych zamknięcie aplikacji migracja platform prog. i maszyn wirtualnych T O -/ -.. n D n D n D n D n D n D n D Legenda - zmiana znaczenia czynnika w stosunku do analizy ogólnej* - czynnik o znaczeniu pozytywnym - czynnik o znaczeniu negatywnym n - czynnik neutralny** D - różnica między znaczeniami czynnika PU - model chmury publicznej PR - model chmury prywatnej * przeciwna zmiana czynnika (np.: zamiast ) - zmiana na - ** czynnik neutralny (n) (usunięcie wartości czynnika) 218

219 Tabela 16. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach prywatnych dla dużych przedsiębiorstw. Źródło: opracowanie własne. Mocne strony PU E Zrządzanie infrastrukturą Aplikacje Skalowalność Bezpieczeństwo konsolidacja środowisk produkcyjnych ujednolicenie i standaryzacja platform migracja, replikacja, automatyzacja środowisk redukcja personelu IT ułatwione wsparcie i szkolenie użytkow. a. o skali internetowej a. o sporadycznym zapotrzebowaniu a. niestrategiczne a. przyrostu danych model kliencki przeglądarka jako platforma funkcjonalna zwięzłość zarządzanie zmianą procesów FLOSS licencjonowanie różne potrzeby w czasie nierozpoznane potrzeby w czasie elastyczność alokowania zasobów rozwój i adaptacja systemów korzyści skali standaryzacja audyty i informatyka śledcza aktualizacje lepsze zarządzanie ryzykiem koncentracja środowisk i platform T O Szanse E Green IT Bezpieczeństwo Rynek Innowacje identyfikacja niewykorzystanych zasobów wydajność PUE pozytywny wpływ na technologie wirtualizacji ekologia funkcjonalności regulacje dot. audytów i standardów element przewagi konkurencyjnej dostawców intensyfikacja relacji biznesowych przedsięwzięcia typu start-up niezależność inwestycyjna kraje rozwijające się otwartość aplikacje mashup długi ogon T O PR Słabe strony D D D D n D PU PR D Aplikacje Funkcjonowanie danych Bezpieczeństwo Dostępność a. historyczne a. czasu rzeczywistego a. z dostępem do poufnych danych modelowanie i integracja danych nieokreślona lokalizacja transfer danych błędy technologii wirtualizacji błędy separacji zasobów naruszenie interfejsów zarządzania niedefinitywne usunięcie danych błędne wyliczenie koniecznych zasobów nieprzewidywalność wydajności błędy systemów wielkoskalowych E n D n D n D D n D n D n D n D - - Zagrożenia Zmiany w zarządzaniu Rynek pracy Dostępność Problemy prawne Rozeznanie i adaptacja Bezpieczeństwo Problem zamknięcia utrata kontroli zmiana procesów i procedur konieczność spójnej polityki IT redukcje stanowisk pracy zaprzestanie świadczenia usług (dostawcy) problemy łańcucha dostaw nieuczciwe praktyki innych usługobiorców brak informacji o jurysdykcji brak odszkodowań za faktyczne straty rozpoznanie koniecznych umiejętności wewnętrzny opór organizacyjny adaptacja użytkowników nadużycie przywilejów dostawcy zmiany organizacyjne dostawców EDoS celowe zamknięcie przez dostawców problemy eksportu/importu danych zamknięcie aplikacji migracja platform prog. i maszyn wirtualnych T PU PR D.. D D D D.. D D... PU PR D D D D. n D n D n D n D O - E T O - n D -/ n D n D n D n D n D n D n D Legenda - zmiana znaczenia czynnika w stosunku do analizy ogólnej* - czynnik o znaczeniu pozytywnym - czynnik o znaczeniu negatywnym n - czynnik neutralny** D - różnica między znaczeniami czynnika PU - model chmury publicznej PR - model chmury prywatnej * przeciwna zmiana czynnika (np.: zamiast ) - zmiana na - ** czynnik neutralny (n) (usunięcie wartości czynnika) 219

220 Tabela 17. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych dla małych i średnich przedsiębiorstw. Źródło: opracowanie własne. Mocne strony S E Zrządzanie infrastrukturą Aplikacje Skalowalność Bezpieczeństwo konsolidacja środowisk produkcyjnych ujednolicenie i standaryzacja platform migracja, replikacja, automatyzacja środowisk redukcja personelu IT ułatwione wsparcie i szkolenie użytkow. a. o skali internetowej a. o sporadycznym zapotrzebowaniu a. niestrategiczne a. przyrostu danych model kliencki przeglądarka jako platforma funkcjonalna zwięzłość zarządzanie zmianą procesów FLOSS licencjonowanie różne potrzeby w czasie nierozpoznane potrzeby w czasie elastyczność alokowania zasobów rozwój i adaptacja systemów korzyści skali standaryzacja audyty i informatyka śledcza aktualizacje lepsze zarządzanie ryzykiem koncentracja środowisk i platform T Bezpieczeństwo Rynek Innowacje Aplikacje n n MK MK FI FI MK SaaS BI O n - - FD n FD n FD n n n UI UI UI UI E identyfikacja niewykorzystanych zasobów wydajność PUE pozytywny wpływ na technologie wirtualizacji ekologia funkcjonalności regulacje dot. audytów i standardów element przewagi konkurencyjnej dostawców intensyfikacja relacji biznesowych przedsięwzięcia typu start-up niezależność inwestycyjna kraje rozwijające się otwartość aplikacje mashup długi ogon Dostępność a. historyczne a. czasu rzeczywistego a. z dostępem do poufnych danych modelowanie i integracja danych nieokreślona lokalizacja transfer danych błędy technologii wirtualizacji błędy separacji zasobów naruszenie interfejsów zarządzania niedefinitywne usunięcie danych błędne wyliczenie koniecznych zasobów nieprzewidywalność wydajności błędy systemów wielkoskalowych T Funkcjonowanie danych Bezpieczeństwo S E n Szanse Green IT Słabe strony SaaS BI O S T Zagrożenia SaaS BI O S E Zmiany w zarządzaniu n Rynek pracy Dostępność Problemy prawne n n Rozeznanie i adaptacja n n n Bezpieczeństwo Problem zamknięcia utrata kontroli zmiana procesów i procedur konieczność spójnej polityki IT redukcje stanowisk pracy zaprzestanie świadczenia usług (dostawcy) problemy łańcucha dostaw nieuczciwe praktyki innych usługobiorców brak informacji o jurysdykcji brak odszkodowań za faktyczne straty rozpoznanie koniecznych umiejętności wewnętrzny opór organizacyjny adaptacja użytkowników nadużycie przywilejów dostawcy zmiany organizacyjne dostawców EDoS celowe zamknięcie przez dostawców problemy eksportu/importu danych zamknięcie aplikacji migracja platform prog. i maszyn wirtualnych T SaaS BI O n n n n n n n n Legenda - zmiana znaczenia czynnika w stosunku do analizy ogólnej* - czynnik o znaczeniu pozytywnym - czynnik o znaczeniu negatywnym n - czynnik neutralny** * przeciwna zmiana czynnika (np.: zamiast ) - zmiana na - ** czynnik neutralny (n) (usunięcie wartości czynnika) Czynniki determinujące zastosowanie SaaS BI w SME MK - marginalizacja kompetencji FK - funkcjonalność i interfejsy UI - uwarunkowania implementacji FD - funkcjonowanie danych 220

221 Tabela 18. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach publicznych dla dużych przedsiębiorstw na tle analizy ogólnej. Źródło: opracowanie własne. MS SS E T O E T O 0,64 0,08 0,52-0,23-0,69-0,38 SZ ZA E T O E T O 0,31 0,31 0,62-0,26-0,21-0,68 MS E SS E MS T SS T MS O SS O 0,64-0,23 0,08-0,69 0,52-0,38 SZ E ZA E SZ T ZA T SZ O ZA O 0,31-0,26 0,31-0,21 0,62-0,68 Tabela 19. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach prywatnych dla dużych przedsiębiorstw na tle analizy ogólnej. Źródło: opracowanie własne. MS SS E T O E T O 0,64 0,32 0,52 0,08-0,08 0,23 SZ ZA E T O E T O 0,08 0,15 0,15 0,00 0,00-0,05 MS E SS E MS T SS T MS O SS O 0,64 0,08 0,32-0,08 0,52 0,23 SZ E ZA E SZ T ZA T SZ O ZA O 0,08 0,00 0,15 0,00 0,15-0,05 Tabela 20. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach publicznych dla małych i średnich przedsiębiorstw na tle analizy ogólnej. Źródło: opracowanie własne. MS SS E T O E T O 0,64 0,2 0,52-0,08-0,46-0,15 SZ ZA E T O E T O 0,15 0,15 0,23-0,21-0,21-0,37 MS E SS E MS T SS T MS O SS O 0,64-0,08 0,2-0,46 0,52-0,15 SZ E ZA E SZ T ZA T SZ O ZA O 0,15-0,21 0,15-0,21 0,23-0,37 Tabela 21. Udziały czynników ogólnej analizy ETO na tle matrycy SWOT (wyniki powtórzone z rozdz. 4). Źródło: opracowanie własne. MS SS E T O E T O 0,64 0,32 0,56-0,23-0,69-0,38 SZ ZA E T O E T O 0,31 0,31 0,62-0,26-0,21-0,68 MS E SS E MS T SS T MS O SS O 0,64-0,23 0,32-0,69 0,56-0,38 SZ E ZA E SZ T ZA T SZ O ZA O 0,31-0,26 0,31-0,21 0,62-0,68 Legenda - zmiana w wymiarze w stosunku do analizy ogólnej MS - mocne strony SS - słabe strony SZ - szanse ZA - zagrożenia - znaczące relacje między udziałami czynników w danym wymiarze (E, T, O) 221

222 7. Zakończenie Niniejsza rozprawa stanowi próbę określenia uwarunkowań funkcjonowania systemów analityki biznesowej w środowisku chmury obliczeniowej. Systemy analityki biznesowej cechuje relatywnie wysoki stopień zaawansowania technologicznego. Można wręcz rzec, że stają się one niezbywalnym elementem kontinuum IT współczesnych organizacji i wytyczają drogę dla coraz bardziej racjonalnych decyzji, dla których możliwe jest wyznaczanie granic coraz większego ryzyka. Organizacje coraz częściej korzystają z dodatkowych alternatywnych rozwiązań analityki, takich jak analityka Big Data, analityka branżowa, której przykładem może być analityka zachowań konsumentów (np.: analityka kampanii reklamowych) czy zlecana zaawansowana analityka danych (np.: danych naukowych). Alternatywy te znamionują istotne zmiany w problematyce funkcjonowania systemów analityki biznesowej U podstaw naszych rozważań stało przekonanie, że w funkcjonowaniu współczesnych systemów informatycznych znaczącą rolę odgrywają procesy prowadzące do różnych form rozproszenia. Na potrzeby tej rozprawy omówiliśmy zagadnienia integracji, założenia tworzenia i utrzymywania systemów BI jako typowego przykładu systemów analityki biznesowej, charakterystykę systemów rozproszonych oraz umiejscowiliśmy systemy analityki biznesowej w kontekście systemów rozproszonych. Główną osią rozważań było określenie determinant funkcjonowania chmur obliczeniowych, co w rezultacie umożliwiło umiejscowienie problematyki systemów analityki biznesowej w kontekście zagadnień systemu rozproszonego. W toku rozprawy dowodziliśmy, że wyróżnione modele upowszechniania chmur obliczeniowych sprzyjają zastosowaniom konkretnych typów systemów analityki 222

223 biznesowej. Ponadto uznaliśmy, że ich rozwój zależy od sposobów tworzenia infrastruktury IT. Stopień udowodnienia hipotez. W stosunku do wysuniętych hipotez rozprawy zastosowano podejście teoretyczne, podlegające w głównej mierze analizie jakościowej. Jedna z hipotez została poparta istniejącymi wynikami badań empirycznych oraz przeprowadzonymi przez autora dodatkowymi badaniami ankietowymi. Hipotezy można uznać za dowiedzione na gruncie teoretycznym, a częściowo także na gruncie empirycznym. Pomocnicza hipoteza pierwsza (H1). Pierwsza z hipotez pomocniczych rozprawy w ścisły sposób wiąże się z dwiema pozostałymi. W jej świetle samo podejście do sposobów tworzenia infrastruktury warunkuje funkcjonowanie konkretnych typów systemów analityki biznesowej. Z drugiej strony konieczność lub chęć wykorzystania konkretnych systemów analityki biznesowej pociąga za sobą konieczność ewaluacji formy infrastruktury IT, która by im odpowiadała, na co wskazują pozostałe dwie hipotezy. W przypadku dużych organizacji podejście do sposobu tworzenia infrastruktury IT jest wypadkową wielu decyzji, które w rozpoznanych scenariuszach rozwoju systemów analityki biznesowej mogą przybierać wręcz charakter decyzji o charakterze strategicznym, uzależnionych jednak od szerszego kontinuum systemów informatycznych funkcjonujących w danej organizacji. Scenariusze te nie wykluczają akcydentalnego (taktycznego) stosowania systemów analityki biznesowej w środowiskach chmur obliczeniowych. Taki rodzaj zastosowań uwzględniać jednak musi szereg kryteriów, które w najlepszym przypadku będą wypadkową korporacyjnych strategii otwarcia infrastruktury IT 233. Formalizowanie owych strategii (np.: na poziomie warstwy zasobów) może usprawnić decyzje związane w wdrożeniem żądanego systemu lub usługi oraz ułatwić dostęp do koniecznych zasobów dla zainteresowanych stron. Należy jednak podkreślić, że rozprawa jedynie częściowo wskazuje na taką strategię, postrzeganą jedynie z punktu widzenia determinant wyróżnionych w modelu ETO, widzianych przez pryzmat funkcjonowania systemów analityki biznesowej. W przypadku małych i średnich przedsiębiorstw, kształtowanie infrastruktury IT w oparciu o model publicznej chmur obliczeniowej uwarunkowane jest w sposób o wiele mniej problematyczny. W sektorze tym bowiem, stosunek korzyści do ryzyka z 233 Pojęcie to ukazane jest tu jedynie jako swoisty symptom, wyznaczający konieczność zastosowania kompleksowego podejścia, uwzględniającego całość infrastruktury IT danej organizacji, gdzie ocena zakłada możliwości i granice dla rozwijania infrastruktury poza obrębem organizacji. 223

224 zastosowania systemów analityki biznesowej w modelu chmury publicznej można uznać za pozytywny. Pomocnicza hipoteza druga (H2). Wyniki analizy ETO prowadzą do uwypuklenia determinant ekonomicznych, które w przypadku dużych organizacji stanowią przeciwwagę dla determinant organizacyjnych czy też technicznych. W tym świetle zaznacza się potencjał zastosowania systemów analityki biznesowej w chmurach prywatnych. Jeśli zgodnie z uzyskanymi rezultatami analiz kryteria natury ekonomicznej mają redukować część negatywnych skutków tego typu zastosowań, niezbędne jest wyraźne odniesienie się do tych kryteriów w procesach stanowiących podstawę decyzji o wdrożeniu lub migracji. Podejście to zakłada swoistą radykalizację stosunków w ramach organizacji. Radykalizacja ta oznacza silną ekspozycję celów oraz środków, wymaganych dla skutecznego wdrożenia i wykorzystywania systemów analityki biznesowej. Takie podejście w jawny, choć nie zawsze oczywisty sposób, uwypukla tendencje znoszące prymat technologii jako takiej nad jej zastosowaniem. Pomocnicza hipoteza trzecia (H3). W przypadku małych i średnich przedsiębiorstw determinanty o charakterze ekonomicznym zyskują jeszcze bardziej na znaczeniu, sytuując funkcjonowanie rozwiązań SaaS BI w tym sektorze w korzystnym świetle. Badania empiryczne przeprowadzone na potrzeby udowodnienia tej hipotezy ugruntowują tezę, w świetle której sukces rozwoju SaaS BI zależy od postrzegania ich użyteczności, nie zaś jak miało to miejsce w przypadku dużych organizacji od kalkulacji, która oparta może być choćby o proponowany model ETO. Należy jednak podkreślić, że zakres przeprowadzonych badań empirycznych jest ograniczony, a uzyskane wyniki można uznać za wstępne, gdyż dowodzą tylko jednego z aspektów rozważanego problemu, a mianowicie normy subiektywnej jako kluczowego czynnika dla zastosowania SaaS BI. Procedura dowodzenia tej hipotezy w przypadku próby o mniejszym zróżnicowaniu mogłaby potwierdzić większą ilość związków w przystosowywanym przez autora na potrzeby tej rozprawy modelu oceny możliwości adaptacji SaaS BI. Ponadto, konstrukcja argumentu na rzecz zasadności tej hipotezy opiera się na innych badaniach empirycznych, które dopełniają przeprowadzone rozumowanie. Hipoteza główna (HG). Powyższe trzy hipotezy odniesione winny być do hipotezy głównej rozprawy. Charakter jej dowiedzenia można uznać za spekulatywny, uwzględnia on jednak rzeczowe, poparte skrupulatną analizą zachodzących zjawisk związanych z zarządzaniem systemami IT oraz kontekstem rynkowym. Kluczowa kwestia dotyczy 224

225 zagadnienia związku między funkcjonowaniem chmur obliczeniowych, a rozwojem systemów analityki biznesowej. Poszczególne etapy rozważań doprowadziły do określenia szeregu determinant jako kluczowych dla zastosowania konkretnych typów systemów analityki biznesowej w wyróżnionych modelach upowszechniania chmur obliczeniowych (por. rozdz. 6.8). W związku z tym można uznać, że rozprawa ukazuje szereg zależności w tym obszarze. Zarysowująca się teza dotycząca rozwoju systemów analityki biznesowej uwzględnia kategorię rozwoju, która rozumiana jest w sposób intuicyjny. Zagadnienie rozwoju systemów analityki biznesowej postrzegać można między innymi z punktu widzenia powszechności zastosowań. Tak postrzegany rozwój uwzględnia zwiększające się zróżnicowanie oferowanych rozwiązań, zarówno w charakterze funkcjonalnym, jak też tematycznym. Najsilniej eksponuje tę problematykę hipoteza trzecia (H3). Postulaty zawarte w rozważaniach ugruntowujących zasadność tej hipotezy koncentrują się na zachowaniach stron trzecich, prowadzących do upowszechniania postaw kalkulacyjnych w sektorze MŚP, a tym samym do ich utrwalania w działaniach gospodarczych. Przywoływane w toku rozprawy statystyki zastosowania systemów BI, wyraźnie pokazują, że postawy te są nieodzownym elementem decyzji gospodarczych w sektorze dużych przedsiębiorstw. Przedstawione argumenty, przemawiające za możliwością zastosowania systemów analityki biznesowej w sektorze MŚP, pozwalają zatem na podtrzymanie hipotezy głównej. Pozostałe dwie hipotezy akcentują inne aspekty rozwoju, a mianowicie techniczne. Wiele z rozwiązań oferowanych w środowiskach prywatnych chmur obliczeniowych musi zostać poddanych swoistym innowacjom. Te procesy, w ślad za wykraczaniem infrastruktur IT poza obręb organizacji, są szansą na uproszczenie podstawowych zadań związanych z funkcjonowaniem tych rozwiązań (takich jak modelowanie danych czy ich integracja) w środowiskach hybrydowych, w chwili, gdy dojrzewające technologie, wrażane w środowiskach chmur prywatnych będą oferowane w środowiskach chmur publicznych. Proces ten może także zachodzić w odwrotnym kierunku. Wiele z obecnych systemów analityki biznesowej wciąż znajduje się albo w obszarze zainteresowań organizacji lub fazie przygotowań do zastosowania (np.: systemy analityki Big Data). Sytuowanie wielu z propozycji rynkowych innowacyjnych systemów analityki biznesowej w środowiskach chmur publicznych stanowi istotny krok ku ich rozwojowi (widzianemu tu głównie z perspektywy technicznej). Jednak uzależnione jest to od podejścia organizacji do sposobu tworzenia infrastruktury IT (H1). 225

226 Ponadto, w kontekście hipotezy pierwszej (H1) kwestię rozwoju systemów analityki biznesowej odnieść można do zagadnień takich jak szerokość spektrum wiedzy czy dostępność systemów wielkoskalowych (np.: przetwarzanie języka naturalnego przez systemy sztucznej inteligencji). Bez względu na ocenę, na ile organizacja powinna rozszerzać infrastrukturę na zewnątrz, zdolność do zwiększania przez nią zasobów informacyjnych oraz możliwości ich przetwarzania mają swe ograniczenia. Oznacza to, że zewnętrzny potencjał analityczny, widziany tu choćby z perspektywy analityki Big Data234, będzie zawsze większy poza organizacją. Wykorzystanie tego potencjału już na obecnym etapie znajduje swe miejsce w praktyce gospodarczej. Można wręcz powiedzieć, że potencjał ten będzie coraz szerzej wykorzystywany, co przy odpowiedniej strategii otwarcia infrastruktury IT przyczyniać się będzie do rozwoju systemów analityki biznesowej, zarówno a aspektach rynkowym, jak i technicznym. Podsumowanie osiągnięć autorskich. Według słów Gadamera, teoretyka współczesnej hermeneutyki filozoficznej, w nowożytnej nauce dominującym elementem stała się idea metody: Ideał poznawczy określony przez pojęcie metody, polega na tym, że dążymy drogą poznania tak świadomie, że zawsze możemy ponownie na nią wejść. Methodos znaczy postępowanie «drogą, którą idzie się za kimś». Metodyczność zakłada stałą możliwość pójścia drogą, którą raz już się szło, i taką możliwość znamionuje postępowanie naukowe 235. W opinii autora praca stanowi unikalne ujęcie problematyki funkcjonowania systemów analityki biznesowej nie tyle z powodu natury przyjętego w pracy problemu (omawianego przecież w sposób mniej lub bardziej szczątkowy w licznych publikacjach), ale z powodu przyjętej metody, porządkującej wiele zakresów tematycznych oraz wątków badawczych. W toku rozprawy dominującym elementem była analiza ETO, którą uznać możemy za swoisty model, ale i metodę. Model ten w toku samej rozprawy stanowił źródło powrotu i wytyczał drogę prowadzącą do wniosków rozprawy. W ślad intencji Gadamera uznać można, że umożliwił podążanie tą samą drogą w toku samego rozumowania. W samej zatem konstrukcji rozprawy rozpoznać można dzięki niemu prawidła postępowania naukowego. 234 Patrz charakterystyka 4V rozdz Gadamer H. G. (2000), Rozum, słowo, dzieje, PIW, Warszawa, s

227 Celem tej pracy było ukazanie uwarunkowań funkcjonowania systemów analityki biznesowej w chmurze obliczeniowej. W tym właśnie miejscu znajdujemy możliwość dla wytyczenia nowej drogi, umożliwiającej rozumienie podatności zastosowania różnorodnych rozwiązań informatycznych w środowisku chmury obliczeniowej. Po pierwsze, wszelkie wyniki uzyskane przy użyciu analizy ETO dla wyróżnionych w toku rozprawy scenariuszy zastosowania systemów analityki biznesowej mogą być doprecyzowane przez konkretną organizację za pomocą przypisania wag do poszczególnych czynników w trzech wymiarach. Wtedy to, ogólne wyniki analiz jakościowych przedstawione w pracy, mogą zostać doprecyzowane, a zaobserwowane związki mogą zostać uznane za bardziej lub mniej zasadne. Po drugie, z oczywistych powodów niniejsza praca zawęża horyzont zastosowania chmur obliczeniowych. Analiza ETO jako postulowana metoda umożliwia sytuowanie różnych rozwiązań informatycznych w modelu chmury obliczeniowej, w szczególności zaś metoda ta: zawiera trzy aspekty determinujące decyzje zarządcze w obszarze systemów informatycznych; uwzględnia nie tylko aspekt techniczny, ale także ekonomiczny i organizacyjny; może być wykorzystywana przez dowolną organizację stojącą przed decyzją o zastosowaniu usług oferowanych w chmurach obliczeniowych; stosować ją mogą zatem zarówno duże organizacje, jak też nawet najmniejsze podmioty; znajduje swe zastosowanie w różnych sposobach upowszechniania chmur obliczeniowych (chmury prywatne, publiczne i hybrydowe), jak też może być odniesiona do różnych modeli usługowych oferowanych w chmurach obliczeniowych (IaaS, PaaS, SaaS). Po trzecie, jednym z efektów podjętych rozważań jest zarysowanie możliwych przemian paradygmatu infrastruktury IT, ukazanych dzięki specyfice determinant uwzględnionych w analizie ETO. Oprócz aspektu metodycznego rozprawy, na jej kartach odnajdujemy szereg tez dotyczących rozwoju systemów analityki biznesowej oraz możliwej ich ewolucji, jak też szerzej rozumianej ewolucji w funkcjonowaniu i zastosowaniu chmur obliczeniowych przez organizacje. Ponadto, w wyniku podjętych badań, rozpoznano szereg dodatkowych uwarunkowań funkcjonowania systemów analityki biznesowej w sektorze małych i średnich 227

228 przedsiębiorstw. W tym celu w sposób unikalny zaadaptowano sprawdzony model ilościowy adaptacji usług SaaS na potrzeby rozwiązań SaaS BI. Prace w tym zakresie są między innymi podstawą dla rozpoznania konkretnych działań uczestników rynku rozwiązań SaaS BI, mających na celu jego rozwój. Zamierzenia badawcze. We wstępie rozprawy zarysowaliśmy alternatywny sposób oceny możliwości adaptacji i wykorzystywania systemów BI236. Sposób ten zakłada podejście procesowe i abstrahuje od dominującej w interesującym nas obszarze badawczym strategii, opierającej się na analizie funkcjonowania systemów. Istotnie, w niniejszej rozprawie przyjęto tę właśnie optykę, która zgodnie z przyjętą w pracy terminologią, oscyluje wokół elementów warstwy systemowej. Tymczasem propozycja przedstawiona między innymi przez C. Olszak stwarza możliwości dla ukazania problematyki podjętej w pracy z innej perspektywy, sygnalizowanej w toku rozprawy237. Taki kierunek badawczy zakładałby rozpatrzenie na ile rozproszenie procesów (warstwa systemowa) z ich heterogenicznością i złożonością wpływa na zastosowanie systemów analityki biznesowej oraz uwzględniać może problematykę rozproszenia zasobów informacyjnych i ludzkich (warstwa zasobów). Powyższa badawcza umożliwiłaby także eksplorację jednego z pobocznych wątków, które odnajdujemy na kartach tej rozprawy. Chodzi mianowicie o zarysowane założenia ekologii funkcjonalności 238. Zagadnienie to umożliwiłoby zrozumienie, na ile funkcjonalność danego rozwiązania informatycznego, wpływa na efektywność podejmowanych decyzji. Kolejną możliwość otwierają tezy o wpływie podejścia do sposobu tworzenia infrastruktury IT. Przyjęcie założenia o konieczności wdrażania przez organizacje strategii otwarcia infrastruktury IT pociąga za sobą szereg ciekawych problemów badawczych, takich jak problem oceny ryzyka powiązanego z udostępnianiem zasobów lub metod wiązania wybranych procesów ze strategiami otwarcia. Problematyka ta w sensie szczegółowym może być odniesiona do systemów analityki biznesowej, jednak w szerszym ujęciu, obejmować może kształtowanie takich strategii dla dowolnych systemów informatycznych. 236 Por. rozdz Por. rozdz Por. rozdz

229 Podziękowania. Chciałbym bardzo podziękować Panu prof. dr hab. Witoldowi Chmielarzowi za poświęcony czas oraz pomoc w przygotowaniu rozprawy. Swoje podziękowania kieruję też na ręce prof. Alexandra Benliana, który okazał swą pomoc przy dostosowywaniu modelu adaptacji rozwiązań SaaS na potrzeby SaaS BI. Dziękuję także Panu Redaktorowi Tomaszowi Bitnerowi oraz jego współpracownikom z firmy IDG Poland za pomoc w realizacji badań ankietowych. Na koniec składam też serdeczne podziękowania swojej rodzinie. 229

230 Bibliografia Adamczewski P. (2010), Wybrane uwarunkowania e-biznesu w MŚP w Chmielarz W., Kisielnicki J., Parys J., red., Informatyka Q Przyszłości, Wydawnictwa Naukowe WZ UW, Warszawa, s Adamczewski P. (2005), Systemy ERP/ERP II jako kategoria ekosystemu informatycznego przedsiębiorstwa w Kozielski S. et al., red., Bazy danych. Modele, technologie, narzędzia, Wydawnictwa Komunikacji i Łączności, Warszawa, s Adamczewski P. (2007), Gdy systemy ERP/ERP II przestają już wystarczać w Szewczyk A., red., Problemy społeczeństwa informacyjnego, Uniwersytet Szczeciński, Szczecin, s Adamczewski P. (2004), Zintegrowane systemy informatyczne w praktyce, MIKOM, Warszawa. Adamczyk A., Chmielarz W. (2005), Zintegrowane systemy informatycznego wspomagania, Wydawnictwo WSE-I, Warszawa. Adellakun O., Kemper T. (2010), Software-as-a-Service Business Intelligence: Adoption Criteria and Business Value, Master's thesis, Jonkoping International Business School. Adler P. (2001), Market, hierarchy and trust: the knowledge economy and future of capitalism, Organization Science 12(2), s Akkermans H., Bogerd P., Doremalen van J. (2004), Travail, transparency and trust: a case study of computer supported collaborative supply chain planning in high-tech electronics, European Journal of Operational Research 153(2), s AMD (2011), Adoption, Approaches & Attitudes. The Future of Cloud Computing in the Public and Private Sectors, AMD, Anderson C. (2010), Who's to Blame, Wired Magazine 18(9), s Anderson C. (2008), The Lon Tail, Hyperion, New York. Arendt Ł. (2007), Adaptability of the European small and medium-sized enterprises to information and communication technologies, Instytut Pracy i Spraw Socjalnych, Warszawa. Ariyachandra T., Watson H. J. (2008), Which Data Warehouse Architecture is Best?, Communications of the ACM 51(10), s Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s Armstrong B. (2010), At Last, Data Warehousing for the Masses, Business Intelligence Journal 15(1), s Badurek J. (2012), Systemy ERP czeka kolejna fala zmian, IDG Polska, Balaouras S. (2010), Business Continuity and Disaster Recovery Are Top IT Priorities For 2010 And 2011, Forester Research Inc. Banaszak Z., Kłos S., Mleczko J. (2011), Zintegrowane systemy informatyczne, PWE, Warszawa. Barczak A., Florek J., Sydoruk T. (2006), Projektowanie zintegrowanych systemów informatycznych zarządzania, Wydawnictwo Akademii Podlaskiej, Siedlce. Barton D., Court D. (2012), Making Advanced Analytics Work for You, Harvard Business Review 90(10), s Baum D. et al. (2011), Sate of Data Integration Market, Oracle Corporation, Benlian A. (2009), A transaction cost theoretical analysis of software-as-a-service (SAAS)-based sourcing in SMBs and enterprises w ECIS 2009 Proceedings, s. Paper 4. Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption An Empirical Study of Different Application Types, Business & Information Systems Engineering 1(5), s Berkowska A., Marczewska-Kuźma R. (2011), Management of Customer Service as a Source of Development of Small and Medium Enterprises w Adamik A., Lachiewicz S., red., Methods and Concepts of Small and Medium-Sized Enterprises Management, Wydawnictwo Politechniki Łódzkiej, Łódź, s Bernstein P. A., Haas L. M. (2007), Information integration in the enterprise, Communications of the ACM 51(9), s

231 Bhargava H., Power D. J. (2001), Decision Support Systems and Web Technologies: A Status Report Prepared for AMCIS 2001, Boston, Massachusetts, AMCIS 2001, Americas Conference on Information Systems. Bieberstein N. et al. (2005), Impact of service-oriented architecture on enterprise systems, organizational structures and individuals, IBM Systems Journal 44(4), s Birkinshaw J., Bouquet C., Barsoux J.-L. (2010), The 5 Myths of Innovation, MIT Sloan Management Review 52(2), s Birst (2010), Full-Featured Business Intelligence for the Cloud, Birst, Inc., Blevins T. et al. (2009), Business Scenario Workshop Report, The Open Group. Bonifati A. et al. (2008), Distributed databases and peer-to-peer databases: past and present, SIGMOD Rec. 37, s Bose R., Luo X. (2011), Integrative framework for assessing firms' potential to undertake Green IT initiatives via virtualization - A theoretical perspective, Journal of Strategic Information Systems 20, s Bracha A., Brown D. (2012), Affective Decision-Making: A Theory of Optimism Bias, Games and Economic Behavior 75, s Briggs L. (2008), BI Case Study: SaaS Delivers Integration Flexibility with Salesforce.com, Business Intelligence Journal 14(3), s Briscoe G., Marinos A. (2009), Digital Ecosystems in the Clouds: Towards Community Cloud Computing, CoRR abs/ Briscoe G., Wilde de P. (2009), Computing of Applied Digital Ecosystems, CoRR abs/ Brodkin J. (2008), Gartner - Seven Cloud-Computing Security Risks, Network World. Brynjolfsson E., Hitt L., Kim H. (2011), Strength in Numbers: How does data-driven decision-making affect firm performance? w ICIS 2011 Proceedings., s. Paper 13. Builders I. (2012), Anatomy of the New Decision. How Five Hot Trends Are Shaping the Future of Business Analytics, Information Builders Buonanno G. et al. (2005), Factors affecting ERP system adoption: A comparative analysis between SMEs and large companies, Journal of Enterprise Information Management 18(4), s Campbell-Kelly M. (2009), Historical reflections: The rise, fall, and resurrection of software as a service, Communications of the ACM 52(5), s Canes M. (2009), Business intelligence for the SME, CA Magazine, s Carr N. (2005), The end of corporate computing, MIT Sloan Management Review 45(3), s Carr N. (2003), IT Doesn't Matter, Harvard Business Review(May 01). Carraher S., Parnell J., Spillan J. (2009), Customer service-orientation of small retail business owners in Austria, The Czech Republic, Hungary, Latvia, Slovakia, and Slovenia, Baltic Journal of Management 4(3), s Chadha B., Iyer M. (2010), BI in a Cloud: Defining the Architecture for Quick Wins, Infosys, Chan L.-K., Sim Y.-W., Yeoh W. (2011), A SOA-Driven Business Intelligence Architecture, Communications of the IBIMA Article ID Chesbrough H. (2003), The Era of Open Innovation, MIT Sloan Management Review 44(3), s Chin W. (1998), The partial least squares approach for structural equation modeling w Marcoulides G. A., red., Modern methods for business research, Lawrence Erlbaum Associates, Hillsdale, s Chmielarz W. (2000), Rola tendencji integracyjnych w kształtowaniu systemów informatycznych zarządzania w Kasprzak T., red., Integracja i architektura systemów informacyjnych przedsiębiorstw, Wydawnictwo WNE UW, Warszawa, s Chou D., Chou A. (2008), Software as a Service (SaaS) as an outsourcing model: An economic analysis w 2008 SWDSI. Chomiak-Orsa I. (2009), Dylematy podejmowania przedsięwzięć informatycznych w małych i średnich przedsiębiorstwach, Informatyka ekonomiczna 13, s Chuah M.-H., Wong K.-L. (2011), A review of business intelligence and its maturity models, African Journal of Business Management 5(9), s

232 Cleveland H. (1982), Information as a resource, Futurist, s Collins L. (2006), Opening Up the Innovation Process, Engineering Management Journal 16(1), s Coulouris G., Dollimore J., Kindberg T. (1998), Systemy rozproszone. Podstawy i projektowanie, WNT, Warszawa. Coyne R. D. (1995), Designing Information Technology in the postmodern age: from method to metaphor, MIT Press, Cambridge, London. Croll A. (2012), Three Kinds of Big Data red., Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s Cwalina W. (2000), Zastosowanie modelowania równań strukturalnych w naukach społecznych, Statsoft Polska, Czarnacka-Chrobot B. (2011), Narzędzia wspomagające pomiar i szacowanie projektów informatycznych w Grabara J. K., Nowak J. S., red., Efektywność zastosowań systemów informatycznych, Wydawnictwa Naukowo-Techniczne, Warszawa, s Czarnacka-Chrobot B. (2011), Porównanie metod pomiaru i szacowania projektów informatycznych jednostki programowe a jednostki umowne w Grabara J. K., Nowak J. S., red., Efektywność zastosowań systemów informatycznych, Wydawnictwa Naukowo-Techniczne, Warszawa, s Czerwonka P., Lech T., Podgórski G. (2011), Chmura obliczeniowa w Acta Universitatis Lodziensis. Folia Oeconomica 261, Uniwersytet Łódzki. Davis J. (1989), Perceived Usefulness, Perceived Ease of Use, And User Acceptance of Information Technology, MIS Quarterly 13(3), s Deleuze G. (1997), Różnica i powtórzenie, Wydawnictwo KR, Warszawa. Deleuze G., Guattari F. (1998), Kłącze, Colloquia Communia 1-3, s Delic K. A., Riley J. A. (2010), Enterprise Knowledge Clouds: Architecture and Technologies w Furht B., Escalante A., red., Handbook of Cloud Computing, Springer ScienceBusiness Media, LLC, s DeLoach D. (2011), It s a Brave New World for Business Intelligence: How the Cloud, Social Computing, and Next-Generation Analytic Technologies Are Redefining the Data Management Landscape, TDWI, Demirkan H., Delen D. (2012), Leveraging the capabilities of service-oriented decision support systems: Putting analytics and big data in cloud, Decision Support Systems. Deutsch M. (1958), Trust and Suspicion, Journal of Conflict Resolution 2(4), s Dibbern J., Goles T., Hirschheim R. and Jayatilaka B. (2004), Information systems outsourcing: a survey and analysis of the literature., ACM SIGMIS Database 34(4), s Dini P. et al. (2005), The Digital Ecosystem Research Vision: 2010 and Beyond, Dubbey A., Wangle D. (2007), Delivering software as a service, McKinsey Quarterly. Dubmill E. (2012), What is Big Data? red., Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s Dudycz H. (2006), Ocena efektywności przedsięwzięć informatycznych. Tradycyjnie czy nowocześnie w Dudycz H., Dyczkowski M., Nowak, red., Informatyka - ocena efektywności, Polskie Towarzystwo Informatyczne - Odział Górnośląski, Katowice, s Dudycz H. (2008), Informatyczne uwarunkowania realizacji strategii inteligentnego wspomagania biznesu 2008 w Gołuchowski A., Frączkiewicz-Wronka J., red., Technologie wiedzy w zarządzaniu publicznym '07, Prace Naukowe Akademii Ekonomicznej, Katowice, s Dudycz H., Dyczkowski M. (2006), Procedura pomiaru i oceny efektywności przedsięwzięć informatycznych. Podstawowe problemy metodyczne w Dudycz H., Dyczkowski M., Nowak, red., Informatyka - ocena efektywności, Polskie Towarzystwo Informatyczne - Odział Górnośląski, Katowice, s Dumbill E. (2012), Getting Up to Speed with Big Data red., Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s Dyer J., Chu W. (2003), Role of Trustworthiness in Reducing Transaction Costs and Improving Performance: Empirical Evidence from the United. States, Japan, and Korea, Organization Science 14(1), s Dzierżanowski M. et al. (2007), Kierunki inwestowania w nowoczesne technologie w przedsiębiorstwach MŚP, Polska Agencja Rozwoju Przedsiębiorczości, Warszawa. 232

233 Eckerson W. (2009), When to Implement BI in the Cloud, TDWI Inc, Eckerson W. (2009), Data Federation Checklist Report, TDWI Research, Eckerson W. (2009), Delivering Insights with Next-Generation Analytics, TDWI Research. Eckerson W. (2007), Predictive Analytics: Extending the Value of your Data Warehousing Investment, TDWI Research, %20pdf.ashx Eckerson W. (2007), Best Practices in Operational BI, TDWI Research, ENISA (2009), An SME perspective on Cloud Computing, ENISA, ENISA (2009), Cloud Computing Security Risk Assessment, ENISA, Essaidi M. (2010), ODBIS: towards a platform for on-demand business intelligence services w Proceedings of the 2010 EDBT/ICDT Workshops, ACM, New York, NY, USA, s. 12:1--12:6. Evelson B. (2012), Trends 2011 And Beyond; Business Intelligence (Paper No ), Forrester Research, Inc. Evelson B. (2012), Top 10 BI Predictions For 2013 and Beyond, Forrester Research, Inc., Evelson B. (2011), BI in the Cloud? Yes, and on the Ground too, Forrester Research, Farooq F., Sarwar S. M. (2010), Real-time data warehousing for business intelligence w Proceedings of the 8th International Conference on Frontiers of Information Technology, ACM, New York, s. 38:1-38:7. Fayyad U., Uthurusamy R. (2002), Evolving data into mining solutions for insights, Communications of the ACM 45(8), s Feiman J., MacDonald N. (2011), Magic Quadrant for Business Intelligence Platforms, 27 January 2011 / ID Number: G Ferguson M. (), Cloud Based BI Understanding Options Is the Biggest Barrier,, Foody P. (2009), User-Centered Business Intelligence, Business Intelligence Journal 14(4), s Fornell C., Larcker D. (1981), Evaluating structural equation models with unobservable variables and measurement error, Journal of Marketing Research 18(1), s Foster I., Iamnitchi A. (2003), On death, taxes, and the convergence of peer-to-peer and grid computing w In 2nd International Workshop on Peer-to-Peer Systems (IPTPS 03, s Foster I. et al. (2008), Cloud Computing and Grid Computing 360-Degree Compared w GCE '08 In 2008 Grid Computing Environments Workshop, s Foucault M. (2000), Filozofia, historia, polityka, PWN, Warszawa. Foucault M. (1977), Archeologia wiedzy, PIW, Warszawa. Furht B. (2010), Cloud Computing Fundamentals w Furht B., Escalante A., red., Handbook of Cloud Computing, Springer ScienceBusiness Media, LLC, s Ganesan S. (1994), Determinants of Long-Term Orientation in Buyer-Seller Relationships, Journal of Marketing 58(2), s Gartner (2012), Gartner Says High Growth in IT Spending in China Will Fuel Adoption of New Technologies in 2012 and Beyond, Gartner Inc., Garzawyńska M. (2010), Open Innovation and Business Success, Diplomatica Verlag. Gaudin S. (2012), Physicist says Moore's Law is 'collapsing', Computerworld. Geyskens I. et al. (1996), The effects of trust and interdependence on relationship commitment: A transatlantic study, International Journal of Research in Marketing 13, s Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of Integrated Solutions, IDC, Raport techniczny nr , 233

234 Goel M. (2011), Cloud ready Business Intelligence with Oracle Business Intelligence 11g, Oracle, Goetz M. (2012), Master Data Management Does Not Equal The Single Source of Truth, Forrester Research, Inc., Gold-Bernstein B., Ruth W. (2005), Enterprise integration: the essential guide to integration solutions, Addison-Wesley, Boston. Golfarelli M., Rizzi S., Cella I. (2004), Beyond data warehousing: what's next in business intelligence? w Proceedings of the 7th ACM international workshop on Data warehousing and OLAP, ACM, New York, NY, USA, s Goliński M., Grabara J. K., Nowak J. S. (2005), Informatyka i efektywność systemów, Polskie Towarzystwo Informatyczne, Katowice. Griffin R. (2005), Podstawy zarządzania organizacjami, PWN, Warszawa. Grochowski L. (2003), Rozproszone systemy informatyczne, Dom Wydawniczy Elipsa, Warszawa. Grudzewski W. et al. (2007), Zarządzanie zaufaniem w organizacjach wirtualnych, Difin, Warszawa. Grudzewski W. et al. (2009), Zarządzanie zaufaniem w przedsiębiorstwie, Oficyna Wolters Kluwer, Kraków. Guillet de Monthoux P., Gustafsson C., Sven-Erik Sjöstrand S.-E. (2007), Aesthetic leadership : managing fields of flow in art and business, Palgrave Macmillan, New York. Gutierrez N. (2011), Establishing a Business-Intelligence Self Service Platform, Infosys Technologies Limited, Haanes K., Lowendahl B. (1997), The Unit of Activity: Towards an Alternative to the Theories of the Firm w Thomas H., red., Strategy, Structure and Style, Wiley, New York. Haas L. (2007), Beauty and the Beast: The Theory and Practice of Information Integration, Suciu D. Schentick T., red., w ICDT 2007, Springer-Verlag, Berlin Heidelberg, s Hackathorn R. (2004), The BI Watch: Real-Time to Real Value, DM Review 14(1), s. 43. Haes de S., Grembergen van W. (2008), Practices in IT Governance and Business - IT Alignment, Information Systems Control Journal 2, s Hagel J., Brown J. (2001), Your Next IT Strategy, Harvard Business Review(October 01). Haines M. R. M. (2010), How a Service-Oriented Architecture May Change the Software Development Process, Communications of the ACM 53(8), s Halevy A. et al. (2005), Enterprise information integration: successes, challenges and controversies w Proceedings of the 2005 ACM SIGMOD international conference on Management of data, ACM, New York, s Hand D., Mannila H., Smyth P. (2005), Eksploracja danych, WNT, Warszawa. Hejduk I. et al. (2011), Znaczenie zaufania i zarządzania zaufaniem w opinii przedsiębiorstw, E-mentor 32(5), s Henseler J., Ringle C., Sinkovics R. (2009), The use of partial least squares path modeling in international marketing red., New Challenges to International Marketing Advances in International Marketing, Emerald Group Publishing Limited, s Herdon M. et al. (2010), Digital Business Ecosystem Tools as Interoperability Drivers, IFIP Advances in Information and Communication Technology 326, s Hesse C. (2002), The rise of intellectual property, 700 B.C. - A.D 2000: an idea in the balance, Daedalus 131(2), s Hohpe G., Woolf B. (2007), Enterprise Integration Patterns: designing, building, and deploying messaging solutions, Addison-Wesley. Hopkins B., Evelson B. (2011), Expand Your Digital Horizon with Big Data, Forrester Research, Inc. Horwitt E. (2011), Self Service BI Catches on, Computerworld, s Hwang K., Dongarra J., Fox G. (2011), Distributed and Cloud Computing. From Parallel Processing to the Internet of Things, Morgan Kaufmann. Hyde L. (2001), O pewnym pokarmie, którego nie możemy zjeść, Krasnogróda(13). IBM (2010), Capitalizing on Complexity: Insights from the IBM 2010 Global CEO Study, IBM Instutute for Business Value, 234

235 infotype=pm&subtype=xb&appname=gbse_gb_sc_usen&htmlfid=gbe03297usen&attachment =GBE03297USEN.PDF IBM (2010), The new voice of the CIO: Insights from the Global Chief Information, IBM Instutute for Business Value, infotype=pm&subtype=xb&appname=gbse_ci_cw_usen&htmlfid=cie03046usen&attachment= CIE03046USEN.PDF Imhoff C., White C. (2011), Self-service Business Intelligence. Empowering Users to Generate Insights, TDWI Research, Ion M. et al. (2007), An Open Distributed Identity and Trust Management Approach for Digital Community Ecosystems w International Workshop on ICT for Business Clusters in Emerging Markets. Ippolito J. (2001), Whatever Happened to the Gift Economy, Leonardo 34(4), s ITU-T ( ), Distributed Computing: Utilities, Grids & Clouds, International Telecommunication Union, Jacobs A. (2009), The pathologies of big data, Communications of the ACM 52(8), s Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Systemy Business Intelligence, PWN, Warszawa. Januszewski A. (2008), Funkcjonalność informatycznych systemów zarządzania. Zintegrowane systemy transakcyjne, PWN, Warszawa. Jin H. et al. (2010), Cloud Types and Services w Furht B., Escalante A., red., Handbook of Cloud Computing, Springer ScienceBusiness Media, LLC, s Jutras C. (2009), ERP and BI: When 11=3, Aberdeen Group, %20and%20BI%20When%201%20%201%20=%203.pdf Kasper-Fuehrer E., Ashkanasy N. (2001), Communicating trustworthiness and building trust in interorganizational virtual organizations, Journal of Management 27, s Kasprzak T. r. (2000), Integracja i architektury systemów informatycznych przedsiębiorstw, Katedra Informatyki Gospodarczej i Analiz Ekonomicznych WNE UW, Warszawa. Kaur R., Sengupta J. (2011), Software Process Models and Analysis on Failure of Software Development Projects, IJSER 2(2). Keen P., Scott Morton M. (1989), Decision Support Systems, Addison-Wesley, New York. Keidar I. (2009), Distributed Computing in the Clouds, SIGACT News 40(2). Kisielnicki J., Pańkowska M., Sroka H. (2011), Zintegrowane Systemy Informatyczne, PWN, Warszawa. Kisielnicki J., Sroka H. (2005), Systemy Informacyjne Biznesu, Placet, Warszawa. Klimek A. (2004), Wykradzione sekrety, Sprawy nauki 2. Konarski R. (2009), Modele równań strukturalnych. Teoria i praktyka., PWN, Warszawa. Kosambia S. (2008), Business Intelligence. The Self-Service Way, DM Review 18(7), s Kourik J. (2011), For small and medium size enterprises (SME) deliberating cloud computing: a proposed approach w Proceedings of the 5th European conference on European computing conference, World Scientific and Engineering Academy and Society (WSEAS), Stevens Point, Wisconsin, USA, s KPMG (2010), From cost to value: 2010 global survey on the CIO agenda, KPMG International, KPMG (2008), Getting the Most from Your Investments in IT, KPMG LLP, %20the%20Most%20from%20Yr%20Investments%20in%20IT_2008.pdf Labrinidis A., Jagadish H. V. (2012), Challenges and opportunities with big data, Proc. VLDB Endow. 5(12), s Lacity M., Hirschheim R. (1995), Beyond the information systems outsourcing bandwagon: the insourcing response., Wiley, Chichester. Lancastre A., Lages L. (2006), The relationship between buyer and a B2B e-marketplace: Cooperation determinants in an electronic market context, Industrial Marketing Management 35(6), s Larose D. (2006), Odkrywanie wiedzy z danych, PWN, Warszawa. 235

236 Lech P. (2003), Zintegrowane systemy zarządzania ERP/ERPII, Difin, Warszawa. Lenart A. (2007), Systemy ERP a procesy biznesowe w Szewczyk A., red., Problemy społeczeństwa informacyjnego, Uniwersytet Szczeciński, Szczecin, s LogiXML (2010), An Overview of BI Models for Small- to Medium-Sized Businesses, LogiXML, Lopez J. (2012), Best Practices fro Turning Big Data into Big Insights, Business Intelligence Journal 17(4), s Lopez-Nicolas C., Molina-Castillo F. J., Bouwman H. (2008), An assessment of advanced mobile services acceptance: Contributions from TAM and diffusion theory models, Information Management 45(6), s Loshin D. (2012), Satisfying New Requirements for Data Integration, TDWI Research, %20Requirements%20for%20DI_web.ashx Loshin D. (2011), Fundamentals of Business Intelligence for Small and Midsize Enterprise, TDWI Research, Luftmann J., Papp R.and Brier T. (1999), Enablers and Inhibitors of Business-IT Alignment, Communications of the Association for Information Systems 1(11). Luhn H. (1958), A Business Intelligence system, IBM Systems Journal 2(4). Łach T. (2007), Wartość informacji w podejmowaniu decyzji gospodarczych, Praca magisterska, Szkoła Główna Handlowa. Łapiński J. (2013), Wpływ Internetu i ICT na gospodarkę i przedsiębiorstwa w Tarnawa A., Zadura-Lichota P., red., Raport o stanie sektora małych i średnich przedsiębiorstw w Polsce w latach , PARP, Warszawa, s Madsen M. (2012), Cloud Computing Models for Data Warehousing, Technical report, Third Nautre Inc. Malmendier U., Tate G. (2008), Who makes acquisitions? CEO overconfidence and the market s reaction, Journal of Financial Economics 89(1), s Malmendier U., Tate G. (2005), CEO Overconfidence and Corporate Investment, Journal of Finance 60(6), s Marco de M. et al. (2010), BI as a service - an attempt to understand the leading adoption factors w International Conference on E-Business Intelligence (ICEBI 2010), Atlantis Press, s Markowski M. (2005), Złożoność integracji systemów informatycznych w Kisielnicki J., Grabara J. K., Nowak J. S., red., Informatyka i współczesne zarządzanie, Polskie Towarzystwo Informatyczne, Katowice, s Marks E. A., Bell M. (2006), Service-Oriented Architecture - A Planning and Implementation Guide for Business and Technology, Wiley & Sons. Marston S. et al. (2011), Cloud Computing - The Business Perspective, Decision Support Systems 51, s Mateos A., Rosenberg J. (2011), Chmura obliczeniowa. Rozwiązania dla biznesu, Helion, Gliwice. Materska K. (2005), Rozwój koncepcji informacji i wiedzy jako zasobu organizacji w Sosińska-Kalata B., Przastek-Smokowa M., Skrzypczak A., red., Od informacji naukowej do technologii społeczeństwa informacyjnego, Wydawnictwo SBP, Warszawa. Mayer R., Davis J., Schoorman F. (1995), An integrative model of organizational trust, Academy of Management Review 20(3), s Maynard D. et al. (2007), Natural language technology for information integration in business intelligence w 10th International Conference on Business Information Systems, s McAfee A., Brynjolfsson E. (2012), Big Data: The Management Revolution, Harvard Business Review 90(10), s McCrae R. (1996), Social Consequences of Experiential Openness, Psychological Bulletin 130(3), s McDonough B., Vesset D., Tenwolde E. (2008), Business analytics SaaS expand, KM World 17(1), s McKinsey (2011), Big data: the next frontier for innovation, competition and productivity, McKinsey Global Institute, McKnight D., Cummings L., Chervany N. (1998), Initial Trust Formation in New Organizational Relationship, Academy of Management Review 23(3), s

237 Meents S., Tan Y.-H., Verhagen T. (2004), Distinguishing different types of trust in online B2B marketplaces, BLED 2004 Proceedings, s Menon L., Rehani B., Gund S. (2012), Article: Business Intelligence on the Cloud Overview, Use Cases and RoI, IJCA Proceedings on National Conference on Communication Technologies & its impact on Next Generation Computing 2012 CTNGC(2), s Microstrategy (2009), An Architecture for Software-as-a-Service (SaaS) Business Intelligence, Microstrategy, sc_lang=en Minahan S., Cox J. (2007), Aesthetic Turn in Management, Ashgate, Aldershot. Mircea M., Ghilic-Micu B., Stoica M. (2011), Combining Business Intelligence with Cloud Computing to delivery agility in actual economy, Journal of Economic Computation and Economic Cybernetics Studies in press. Mises von L. (1966), Human Action, Henry Regnery, Chicago. Moc K. (2011), SaaS jako innowacyjny model dostarczania oprogramowania dla przedsiębiorstw w Chmielarz W., Kisielnicki J., O. S., red., Informatyka 4 Przyszłości, Wydawnictwo Wydziału Zarządzania UW, Warszawa, s Molla A., Copper V., Pittayachawan S. (2009), IT and Eco-sustainability: Developing and Validating a Green IT Readiness Model, International Conference on Information Systems, Association for Information Systems, Phoenix, Monthoux de, P. G.; Gustafsson, C. & Sjostrand, S.-E., ed. (2007), Aesthetic Leadership: Managing Fields of Flow in Art and Business, Palgrave Macmillan, New York. Moore G., Benbasat I. (1991), Development of an Instrument to Measure the Perceptions of Adopting an Information Technology Innovation, Information Systems Research 2(3), s Morris H. D. (2010), Business Analytics and the Path to Better Decisions (No ), Technical report, IDC. Mount K. et al. (2005), Higher-order dimensions of the big five personality traits and the big six vocational interest types, Personnel Psychology 58(2), s Murphy I. (2012), BI is NOT a Cloud application, Computer Weekly, Nachira F.Nachira, Francesco anbd Nicolai, A.; Dini, P.; Le Louarn, M. & Leon, L. R., ed. (2007), Digital Business Ecosystems, Office for Official Publications of the European Communities, Luxemburg,. Natis Y. V. (2003), Service-Oriented Architecture Scenario, Gartner Inc., Nayak N. et al. (2007), Core business architecture for a service-oriented enterprise, IBM Systems Journal 46, s Nermend K., Nermend M. (2007), Rozwój zintegrowanych systemów MRP/ERP II wspomagających zarządzanie przedsiębiorstwem w Szewczyk A., red., Problemy społeczeństwa informacyjnego, Uniwersytet Szczeciński, Szczecin, s Obłój K. (2007), Strategia organizacji, PWE, Warszawa. Olofson C., Vesset (2012), Big Data: Trends, Strategies, and SAP Technology (No ), Technical report, IDC. Olszak C. (2011), Przegląd i ocena wybranych modeli dojrzałości Business Intelligence w Korczak J., Dudycz H., red., Informatyka Ekonomiczna, Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu. Olszak C. (2007), Tworzenie i wykorzystywanie systemów Business Intelligence na potrzeby współczesnej organizacji, Wydawnictwo Akademii Ekonomicznej w Katowicach, Katowice. Olszak C. (2004), Systemy business intelligence w zarządzaniu wiedzą w organizacji, Akademia Ekonomiczna, Olszak C., Ziemba E. (2007), Strategie i modele gospodarki elektronicznej, PWN, Warszawa. Orzechowski R. (2007), Dopasowanie IT-biznes, Kwartalnik Nauk o Przedsiębiorstwie 2, s Owoc M., Hauke K. (2010), Modele upowszechniania cloud computingu w organizacjach w Korczak J., Chomiak-Orsa I., Sroka H., red., Systemy informatyczne w zarządzaniu, Uniwersytet Ekonomiczny we Wrocławiu, Wrocław, s

238 PARP (2010), Raport o stanie sektora małych i średnich przedsiębiorstw w Polsce w latach , Polska Agencja Rozwoju PrzedsiÄ biorczoå ci, Parys T. (2007), System ERP - funkcjonalność, ewolucja oraz charakterystyka rynku w Polsce w Szewczyk A., red., Problemy społeczeństwa informacyjnego, Uniwersytet Szczeciński, Szczecin, s Patrick P. (2005), Impact of SOA on enterprise information architectures w Proceedings of SIGMOD Conference, s Pelissie du Rausas. M. (2011), Internet matters. The Net's sweeping impact on growth, jobs and prosperity, Technical report, McKinsey and Company. Peskin L. (2005) Trade Secrets: Intellectual Piracy and the Origins of American Industrial Power, The Journal of American History 92(1), s Pierścionek Z. (2011), Zarządzanie strategiczne w przedsiębiorstwie, PWN, Warszawa. Poe V., Klauer P., Brobst S. (2000), Tworzenie hurtowni danych, WNT, Warszawa. Power D. (2007), A Brief History of Decision Support Systems, Przechlewski T. (2010), Sposoby oceny modelu pomiaru w praktyce informatyki ekonomicznej.,, Put D. (2010), Wieloaspektowość zagadnienia integracji zasobów informacyjnych w dynamicznych strukturach sieciowych w Chmielarz W., Kisielnicki J., Parys J., red., Informatyka Q Przyszłości, Wydanictwa Naukowe WZ UW, Warszawa, s Put D. (2008), Model integracji informacji zorientowany na użytkownika w Kisiel, red., Informatyka dla przyszłości, Wydawnictwo Naukowe Wydziału Zarządzania UW, Warszawa, s Rashid M. A., Hossain L., Patrick J. D. (2002), The Evolution of ERP Systems : A Historical Perspective w Hossain L., Patrick J. D., Rashid M. A., red., Enterprise Resource Planning: Global Opportunities and Challenges, Idea Group (IGI), s Razavi A., Moschoyiannis S., Krause P. (2009), An open digital environment to support business ecosystems, Peer-to-Peer Networking and Applications 2(4), s Razavi A., Moschoyiannis S. K., Krause P. (2008), A Scale-free Business Network for Digital Ecosystems w 2nd IEEE International Conference on Digital Ecosystems and Technologies, s Reich B., Benbasat I. (2000), Factors That Influence the Social Dimension of Alignment between Business and Information Technology Objectives, MIS Quarterly 24(1), s Riehle D. (2010), The Single-Vendor Commercial Open Source Business Model, Information Systems and ebusiness Management. Rimal B. P. et al. (2011), Architectural Requirements for Cloud Computing Systems: An Enterprise Approach, Journal of Grid Computing 9, s Ringle C., Starsted M. (2010), Treating unobserved heterogeneity in PLS path modeling: a comparison of FIMIX-PLS with different data analysis strategies, Journal of Applied Statistics 37(8), s Rogers S. (2011), Big Data is Scaling BI and Analytics, Information Management, s Rot A. (2008), Oprogramowanie dostarczane w formie usługi - model SaaS. Stan obecny, perspektywy rozwoju oraz przykłady rozwiązań, Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu nr 23. Informatyka Ekonomiczna 12, s Rotem-Gal-Oz A. (2007), What is SOA anyway?, Rotem-Gal-Oz A., Bruno E., Dahan U. (2007), SOA Patterns, Manning Publications. Roussopoulos M. et al. (2003), 2 P2P or Not 2 P2P?, CoRR cs.ni/ Russom P. (2012), Introduction to Next Generation Master Data Management, What Works in Data Management 33, s Russom P. (2012), Ten Goals for Next Generation Data Quality, What Works in Data Management 33, s Russom P. (2011), Big Data Analytics, TDWI Research, _Web.ashx Russom P. (2011), The State of Big Data Analytics, What Works in Data Management 33, s Russom P. (2011), Next Generation Data Integration, TDWI Research, 238

239 Sacha J. et al. (2007), A Service-Oriented Peer-to-Peer Architecture for a Digital Ecosystem w IEEE International Conference on Digital Ecosystems and Technologies (DEST'07), IEEE,. Sacha J. et al. (2010), Decentralizing a service-oriented architecture, Peer-to-Peer Networking and Applications 3, s Sahama T. R., Croll P. R. (2007), A data warehouse architecture for clinical data warehousing w Proceedings of the fifth Australasian symposium on ACSW frontiers - Volume 68, Australian Computer Society, Inc., Darlinghurst, Australia, Australia, s Santaferraro J. (2012), Can Cloud-Aware Analytics Make the Difference Between Thrashing and Thriving?, TWDI, Saunders C. et al. (2004), Interorganizational trust in B2B relationships w Proceedings of the 6th international conference on Electronic commerce, ACM, New York, NY, USA, s Scholz P. et al. (2010), Benefits and Challenges of Business Intelligence Adoption in Small and MediumSized Enterprises, Challenges, 18th European Conference on Information Systems. Scott J. (2000), Facilitating interorganizational learning with information technology, Journal of Management Information Systems 17(2), s Siwińska J. (2011), Ekonomiczna efektywność przetwarzania w chmurze, Metody Informatyki Stosowanej 26(1), s Skilton M. (2010), Building Return on Investment from Cloud Computing, The Open Group Skrobacki R. (2011), Ryzyko i zaufanie jako czynniki rozwoju firm sektora małych i średnich przedsiębiorstw prywatnych, PhD thesis, Uniwersytet im. Adama Mickiewicza. Smok B.Smok, B., ed. (2010), Business Intelligence w zarządzaniu, Wydawnictwo Uniwersytetu Ekonomicznego we Wrocławiu. Soja P. (2005), Rozwój zintegrowanych systemów zarządzania klasy ERP, Katedra Informatyki Akademii Ekonomicznej w Krakowie, Spence L. (1999), Does size matter? The state of the art in small business ethics, Business Ethics: A European Review 8(3), s Sroka H., Olszak C. (2001), Zintegrowane systemy informatyczne w zarządzaniu, AE Katowice, Katowice. Standish, Group (2009), CHAOS Summary 2009, Standish Group International Inc., Stanley J., Briscoe G. (2010), The ABC of Digital Business Ecosystems, Communications Law 15(1), s Starczewska-Krzysztoszek M. (2007), Monitoring kondycji sektora MSP Konkurencyjność małych i średnich przedsiębiorstw., PKPP Lewiatan, Stefanowicz B. (2007), Informatyczne systemy zarządzania - przewodnik, Szkoła Główna Handlowa, Warszawa. Stodder D. (2012), Five Emerging Trends at the Leading Edge of Business Intelligence and Analytics, What Works in Emerging Technologies 34, s Stodder D. (2011), Five Emerging Trends in Business Intelligence and Analytics, What Works in Emerging Technologies 32, s Stokes R. (2011), emarketing: The essential guide to digital marketing, Quirk emarketing, Stonebraker M. (2011), Stonebraker on data warehouses, Communications of the ACM 54, s Strebel J., Stage A. (2010), An Economic Decision Model for Business Software Application Deployment on Hybrid Cloud Environments w MKWI IT Performance Management/ IT-Controlling. Strommen-Bakhtiar A., Razavi A. (2008), Emerging Problems in the Digital Business Ecosystem,. Strzała K. (2006), Modelowanie równań strukturalnych: koncepcja i podstawowe pojęcia red., Prace i Materiały Wydziału Zarządzania Uniwersytetu Gdańskiego, s Sultan N. (2010), Reaching for the 'cloud'- How SMEs can manage, International Journal of Information Management 31, s Surma J. (2009), Business Intelligence. Systemy wspomagania decyzji biznesowych, PWN, Warszawa. Swoyer S. (2012), Big Analytics: The Next Generation red., Big Data Analytics. TDWI E-book, s

240 Szepielak D. (2007), Techniki integracji systemów informatycznych w Kozielski S. et al., red., Bazy Danych: Nowe Technologie, WKŁ, Gliwice. Talukder A. K., Zimmerman L., Prahalad H. A. (2010), Cloud Economics: Principles, Costs, and Benefits w Antonopoulos N., Gillam L., red., Cloud Computing: Principles, Systems, Applications, Springer, s Tan H., Plowman D., Hancock P. (2008), The evolving research on intellectual capital, Journal of Intellectual Capital 9(4), s Tanenbaum A., Steen van M. (2006), Systemy rozproszone. Zasady i paradygmaty, WNT, Warszawa. Tarnawa, A., Zadura-Lichota, P. (2013), Raport o stanie sektora małych i średnich przedsiębiorstw w Polsce w latach , PARP, Warszawa. TCS (2007), Evolving IT from 'Running the Business' to 'Changing the Business', Tata Consulting Services, Telesca L., Koshutanski H. (2007), A Trusted Negotiation Environment for Digital Ecosystems, Building the foundations of Digital Ecosystems FP6 Results and Perspectives Publisher European Commission, s Tews R. (2007), Beyond IT. The business value of SOA, AIIM E-DOC 21, s Thompson J. (2009), Business Intelligence in a SaaS Environment, Business Intelligence Journal 14(4), s Thoo E. (2009), Data In the Cloud: The Changing Nature of. Managing Data Accessibility (Gartner RAS Core Research Note G ), Technical report, Gartner Inc. Tsai J. (2009), Intelligence in the Cloud, Customer Relationship Management, s Turban E. (1990), Decision Support and Expert Systems, MacMillan Publishing Company, New York. Turban E., Aronson J. (2001), DSS and Intelligent Systems, Prentice Hall, Ney Jersey. Tuten T., Urban D. (2001), An Expanded Model of Business-to-Business Partnership Formation and Success, Industrial Marketing Management 30, s Venkatesh V. et al. (2003), User Acceptance of Information Technology: Toward a Unified View, MIS Quarterly 27(3), s Vertica (2011), Transforming the Economics of Data Warehousing with Cloud Computing, Vertica Systems Inc., Vesset D. (2012), Market Analysis: Worldwide Business Analytics Software Forecast and 2011 Vendor Share (IDC No ), Technical report, IDC. Vesset D. (2011), Worldwide Business Intelligence Tools 2010 Vendor Shares (IDC No ), Technical report, IDC. Vijayan J. (2011), Self-service BI, SaaS, real-time analytics will dominate 2011 agenda, Computerworld, nate_2011_agenda Vouk M. (2008), Cloud computing - issues, research and implementations, Journal of Computing and Information Technology 4, s Vries de R., Vries de A., Feij de J. (2009), Sensation seeking, risk-taking, and the HEXACO model of personality, Personality and Individual Differences 6(47), s Vujasinovic M., Marjanovic Z. (2006), Data level enterprise applications integration, Lecture Notes in Computer Science 3812(Business Process Management Workshops), s Wang L. et al. (2010), Cloud Computing: a Perspective Study, New Generation Computing 28(2), s Watson H. J. (2009), Tutorial: Business Intelligence Past, Present, and Future, Communications of the Association for Information Systems 25, s Weinhardt C. et al. (2009), Cloud Computing A Classification, Business Models, and Research Directions, Business & Information Systems Engineering(5), s White C. (2005), Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, TDWI Research, White D. (2010), Fast, Affordable, Agile - The Case for SaaS BI, Aberdeen Group Inc., 240

241 Wielicki T., Cavalcanti G. (2006), Study of Digital Divide: Measuring ICT Utilization and Implementation Barriers Among SMEs of Central California W. Abramowicz, H. Mayr, red., w Business Information Systems, 9th International Conference on Business Information Systems, BIS 2006, s Williams S., Williams N. (2003), The Business Value of Business Intelligence, Business Intelligence Journal Fall, s Williamson O. (1991), Comparative economic organization: The analysis of discrete structural alternatives., Administrative Science Quarterly 36(2), s Wu W.-W. (2011), Developing an explorative model for SaaS adoption, Expert Systems with Applications 38, s Xu Z., Li G. (2011), Computing for the masses, Communications of the ACM 54, s Zhao H., Seibert S. (2006), The big five personality dimensions and entrepreneurial status: a meta-analytical review., Journal of Applied Psychology 91(2), s Ziemba E., Obłąk I. (2012), Systemy informatyczne w organizacjach zorientowanych procesowo, Problemy Zarządzania 10(3), s Zutshi A. (2012), Future of ERP, Infosys Lab Briefings 10(1), s Zygała R. (2009), Uwarunkowania rozwoju systemów business intelligence w sektorze małych i średnich przedsiębiorstw, Informatyka ekonomiczna 13, s

242 Indeks ilustracji Rysunek 1. Triada - dane, informacja, wiedza...5 Rysunek 2. Dane, informacja i wiedza na tle rozproszenia i integracji...8 Rysunek 3. Zasoby informacyjne oraz składniki i efekty integracji...32 Rysunek 4. Architektura systemów BI...52 Rysunek 5. Techniki i technologie integracji danych...62 Rysunek 6. Modele upowszechniania i modele usługowe chmur obliczeniowych...84 Rysunek 7. Przekrój czynników w analizie SWOT chmury obliczeniowej...90 Rysunek 8. Relacja przetwarzania w chmurze i przetwarzania klienckiego Rysunek 9.Określenie zależności w między elementami analizy SWOT w metodzie "od wewnątrz do zewnątrz" Rysunek 10. Udziały czynników ETO w na tle matrycy SWOT Rysunek 11. Udziały czynników ETO w na tle matrycy SWOT (podział na wymiary) Rysunek 12. Układ elementów warstw zasobów i systemowej w odniesieniu do procesu podejmowania decyzji Rysunek 13. Dystans akcji, a wartość informacji Rysunek 14. Systemy analityki biznesowej, a rozproszenie w warstwach zasobów i systemowej Rysunek 15. Systemy analityki biznesowej na tle scenariusza rozwoju modeli tworzenia infrastruktury IT Rysunek 16. Model oceny możliwości adaptacji SaaS zaproponowany przez Wu Rysunek 17. Model TAM, a uwarunkowania implementacji SaaS BI Rysunek 18. Model oceny możliwości adaptacji SaaS zaproponowany przez Benliana i współpracowników Rysunek 19. Oszacowany model oceny możliwości adaptacji SaaS BI

243 Indeks tabel Tabela 1. Klasyfikacja rozproszonych i równoległych systemów przetwarzania...73 Tabela 2. Porównanie zwrotu z nakładów inwestycyjnych dla wirtualizacji pojedynczego serwera...78 Tabela 3. Analiza ETO Mocne strony Tabela 4. Analiza ETO - Słabe strony Tabela 5. Analiza ETO - Szanse Tabela 6. Analiza ETO - Zagrożenia Tabela 7. Porównanie grup czynników analizy ETO na tle charakteru organizacji Tabela 8. Całkowity koszt utrzymania (TCO). Tradycyjne oprogramowanie vs. Software-as-a-Service Tabela 9. Determinanty SaaS BI na tle postulatów samoobsługowej platformy BI Tabela 10. Typy systemów analityki biznesowej na tle modeli tworzenia infrastruktury w ujęciu korporacyjnym Tabela 11. Model oceny adaptacji SaaS BI na podstawie Benlian A. et al. (2009). Konstrukty i indykatory Tabela 12. Badania oceny możliwości adaptacji SaaS BI. Charakterystyka próby Tabela 13. Ocena jakości modelu pomiaru: trafność zbieżna i rzetelność wewnętrzna Tabela 14. Ocena jakości modelu pomiaru: trafność dyskryminacyjna (ładunki krzyżowe) Tabela 15. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych dla dużych przedsiębiorstw Tabela 16. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach prywatnych dla dużych przedsiębiorstw Tabela 17. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych dla małych i średnich przedsiębiorstw Tabela 18. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach publicznych dla dużych przedsiębiorstw na tle analizy ogólnej Tabela 19. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach prywatnych dla dużych przedsiębiorstw na tle analizy ogólnej Tabela 20. Udziały czynników analizy ETO dla funkcjonowania systemów analityki biznesowej (SAB) w chmurach publicznych dla małych i średnich przedsiębiorstw na tle analizy ogólnej Tabela 21. Udziały czynników ogólnej analizy ETO na tle matrycy SWOT (wyniki powtórzone z rozdz. 4)

244 Załącznik A. Kwestionariusz badań oceny możliwości adaptacji SaaS BI 244

245 245

246 246

247 247

248 248