Oglądaj/Otwórz - Repozytorium UW

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ń 2014
1
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
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)
04200 Biznes i technologia
Tytuł pracy w języku angielskim
Determinants of business analytics systems functioning in distributed system
3
Spis treści
1.Wstęp................................................................................................................................................................5
1.1. Wprowadzenie i uzasadnienie podjęcia badań........................................................................................5
1.2. Cele i zakres pracy................................................................................................................................14
1.3. Hipotezy badawcze rozprawy...............................................................................................................16
1.4. Procedura osiągnięcia celu badawczego i udowodnienia hipotez........................................................17
2. Charakterystyka systemów zintegrowanych..................................................................................................20
2.1. Wprowadzenie......................................................................................................................................20
2.2. Wartość biznesowa płynąca z integracji...............................................................................................22
2.3. Rodzaje, style i typy integracji..............................................................................................................36
3. Zagadnienia systemów klasy Business Intelligence......................................................................................42
3.1. Systemy klasy BI jako systemy integrujące..........................................................................................42
3.2. Architektura systemów BI.....................................................................................................................52
3.3. Warstwa integracyjna architektury BI...................................................................................................54
3.4. Warstwa składowania architektury BI..................................................................................................63
3.5. Warstwa analityczna i prezentacji architektury BI................................................................................64
3.6. Dziedziny zastosowań Business Intelligence........................................................................................67
4. Charakterystyka systemów rozproszonych...................................................................................................70
4.1. Problematyka wirtualizacji...................................................................................................................73
4.2. Typologia modeli biznesowych chmury obliczeniowej........................................................................79
4.3. Korzyści, wyzwania i zagrożenia w chmurach obliczeniowych...........................................................87
4.4. Rozwinięcie charakterystyki chmur obliczeniowych i analiza SWOT.................................................90
4.5. Ekonomiczna, techniczna i organizacyjna analiza chmur obliczeniowych (analiza ETO) ...............121
4.6. Charakterystyka czynników analizy ETO na tle charakteru organizacji............................................134
4.7. Analiza ETO – określenie związków..................................................................................................138
5.Zagadnienia systemów analityki biznesowej w systemach rozproszonych.................................................143
5.1. Rozproszenie w warstwach zasobów i systemowej............................................................................143
5.2. Współczesne wyzwania funkcjonowania systemów Business Intelligence.......................................145
5.3. Zjawisko Big Data jako symptom rozproszenia oraz nowe światło dla systemów analityki
biznesowej..................................................................................................................................................151
5.4. Rozwiązania Business Intelligence w środowiskach chmur obliczeniowych....................................163
5.5. Usługowy model systemu analityki biznesowej na przykładzie Software as a Service BI
(SaaS BI)....................................................................................................................................................171
6. Ewolucja systemów analityki biznesowej...................................................................................................183
6.1. Postulaty rozwoju i ewolucji infrastruktury IT...................................................................................183
6.2. Systemy analityki biznesowej na tle rozproszenia..............................................................................188
6.3. Modele tworzenia infrastruktury informatycznej, a systemy analityki biznesowej............................190
6.4. Typy systemów analityki biznesowej w ujęciu korporacyjnym.........................................................191
6.5. Uwarunkowania funkcjonowania systemów analityki biznesowej w małych i średnich
przedsiębiorstwach (MŚP).........................................................................................................................194
6.6. Ocena możliwości adaptacji SaaS BI w sektorze małych i średnich przedsiębiorstw........................198
6.7. Empiryczna analiza możliwości adaptacji SaaS BI............................................................................208
6.8. Wnioski i podsumowanie rozważań...................................................................................................215
7. Zakończenie.................................................................................................................................................222
Bibliografia......................................................................................................................................................230
Indeks ilustracji................................................................................................................................................242
Indeks tabel......................................................................................................................................................243
Załącznik A. Kwestionariusz badań oceny możliwości adaptacji SaaS BI.....................................................244
4
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. 349.
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
1
2
3
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. 349.
Mises von, L. (1966), Human Action, Henry Regnery, Chicago s. 290 (wyd. polskie Ludzkie działanie,
Fundacja Instytut Ludwiga von Misesa, Warszawa, 2007).
5
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,
4
5
6
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. 43-44.
6
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".
7
8
9
Power, D. (2007), A Brief History of Decision Support Systems,
http://dssresources.com/history/dsshistory.html.
Morris H. D. (2010), Business Analytics and the Path to Better Decisions, No. 224877, Technical report,
IDC, s. 6-7.
IBM (2010), Capitalizing on Complexity: Insights from the IBM 2010 Global CEO Study, IBM Institute
for Business Value, s. 18.
7
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
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. 5.
13 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. 29.
14 IBM (2010), The New Voice..., op. cit., s. 33.
15 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
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. 35-41.
17 Orzechowski, R. (2007), Dopasowanie IT-biznes, Kwartalnik Nauk o Przedsiębiorstwie 2, s. 74-79.,
Reich, B, Benbasat, I. (2000), Factors That Influence the Social Dimension of Alignment between
Business and Information Technology Objectives, MIS Quarterly 24(1), s. 81-113., 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. 212-225.
10
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. 67-73. Carr,
N. (2003), IT Doesn't Matter, Harvard Business Review, May 01.
21 IBM (2010), The New Voice ..., op. cit., s. 15.
11
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. 11-26.
23 Por. także Fletcher H. G., Surya B. Y. (2011), Business Intelligence Conceptual Model, International
Journal of Business Intelligence Research 2(2), s. 48-66.
24 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
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. 85-96.
26 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
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. 25-30; 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. 39-44; Thompson J. (2009), Business Intelligence in a SaaS Environment, Business
Intelligence Journal 14(4), s. 50-55. Chan L.-K., Sim Y.-W., Yeoh W. (2011), A SOA-Driven Business
Intelligence Architecture, Communications of the IBIMA Article ID 216423.
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. 364-374; 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. 53-63.
14
•
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
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.
1.3. 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
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.
1.4. 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
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
•
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
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. 132.
20
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. 20-43. Malmendier U., Tate G. (2005), CEO
Overconfidence and Corporate Investment, Journal of Finance 60(6), s. 2661-2700. Bracha A., Brown
D. (2012), Affective Decision-Making: A Theory of Optimism Bias, Games and Economic Behavior 75,
s. 67-80.
31 Foucault M. (2000), Filozofia, historia, polityka, PWN, Warszawa, s. 127.
32 Ibid.
21
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.
2.2. 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. 1-8.
22
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, 01.05.2003, s. 11.
23
„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
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
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
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. 1-16.
27
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. 61.
41 Gold-Bernstein B., Ruth W. (2005), Enterprise integration: the essential guide to integration solutions,
Addison-Wesley, Boston, s. 5.
28
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 4P+P42, 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. 24-25
www.quirk.biz/emarketingtextbook/download.
43 Don DeLillo (2004), Cosmopolis, Scribner, New York, s. 34.
44 Por. „dystans akcji”, a wartość w rozdz. 5.
29
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
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. 12-15.
46 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. 212-225.
47 Por. wstęp rozprawy.
31
•
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
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. 217-219.
49 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. 104.
33
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 organizacyjnej52.
50 Hohpe G., Woolf B. (2007), Enterprise Integration Patterns: designing, building, and deploying
messaging solutions, Addison-Wesley, s. 3.
51 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
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. 691-708.
35
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. 20.
36
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. 43-44.
55 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. 96-97.
37
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. 365-366.
38
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. 67.
58 Ibid., s. 117.
59 Natis Y. V. (2003), Service-Oriented Architecture Scenario, Gartner Inc.,
http://www.gartner.com/resources/114300/114358/114358.pdf, s. 2.
39
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
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
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
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
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. 7-8.
62 Stefanowicz B. (2007), Informatyczne systemy zarządzania - przewodnik, Szkoła Główna Handlowa,
Warszawa.
44
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. 123-124.
45
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
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 32.
66 Keen P., Scott Morton M. (1989), Decision Support Systems, Addison-Wesley, New York. cyt. za Olszak
op.cit. s. 35.
67 Por. Luhn H. (1958), A Business Intelligence system, IBM Systems Journal 2(4), s. 314.
47
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. 67.
48
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.12.
70 Olszak (2007), Tworzenie i wykorzystywanie systemów …, op. cit., s. 71.
71 Ibid., s. 103.
49
•
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. 33-44 i s. 63-75; 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. 27-55 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. 85-107.
73 Williams S., Williams N. (2003), The Business Value of Business Intelligence, Business Intelligence
Journal, Fall 2003, s. 3.
50
•
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: G00210036.
51
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ą.
3.2. 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
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
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. 215
76 Ibid., s. 216.
54
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 2011.
55
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. 8-11.
56
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
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
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,
http://tdwi.org/whitepapers/2011/05/state-of-the-data-integration-market.aspx.
81 White C. (2005), Data Integration..., op. cit., s. 15.
59
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. 30.
83 White C. (2005), Data Integration..., op. cit., s. 17-18.
60
•
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
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
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
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%).
3.5. 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. 146-147.
64
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 2012-201385.
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. 47.
65
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. 37-44 i Januszewski A. (2008), Funkcjonalność
informatycznych systemów …, op. cit., s. 40-64.
87 Eckerson W. (2009), Delivering Insights with Next-Generation Analytics, TDWI Research, s. 18.
88 Januszewski A. (2008), Funkcjonalność informatycznych …, op. cit., s. 67-75.
66
•
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: emaili,
środowisk mobilnych czy mediów społecznościowych.
3.6. 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
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. 176-181,
Olszak C. (2007), Tworzenie i wykorzystywanie systemów…, op. cit., s. 155-168, Surma J. (2009)
Business Intelligence …, op. cit., s. 51-53 i 89-91.
68
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
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
„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. 24.
71
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. 1.
72
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. 16.
4.1. 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
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
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. 28-30.
75
ż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 1983-84 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. 67-73.
76
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
◦ 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 213430.
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 213430.
95 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
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).
4.2. 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. 24.
79
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. 1.
80
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. 173.
81
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. 39.
82
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. 484-485.
83
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. 371.
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
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
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. 11.
102 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa …, op. cit., s. 116.
86
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.
4.3. 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, http://www.amd.com/us/Documents/Cloud-Adoption-Approaches-and-AttitudesResearch-Report.pdf.
87
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, email, 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.131-140
oraz Obłój K. (2007), Strategia organizacji, PWE, Warszawa, s. 326-342.
105 Marston S. et al. (2011), Cloud Computing - The Business Perspective, Decision Support Systems 51,
s. 176-189.
88
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. 338.
107 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
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.
4.4. 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
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. 467.
91
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
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
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
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. 5.
113 Por. rozdział 5 – analityka Big Data.
114 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa …, op. cit., s. 132-135.
95
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ń komercyjnych115.
115 Por. Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s. 58.
96
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
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,
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-riskassessment/at_download/fullReport, s. 17-20.
98
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
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. 90-92.
100
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. 5.
118 Foster I. et al. (2008), Cloud Computing and Grid Computing …, op. cit., s. 5.
101
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
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. 56.
120 Ibid., s. 55.
103
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. 38.
104
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
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
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. 35.
124 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa …, op. cit., s. 49.
107
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. 38-54.
126 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. 141-158.
108
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
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., http://www.gartner.com/it/page.jsp?id=2124215.
110
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. 252.
111
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
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. 28-29.
113
•
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, 187.
132 Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of
Integrated Solutions, IDC.
114
ś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
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
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. 216-221.
117
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. 55.
118
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
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
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. 343-360; Siwińska J. (2011), Ekonomiczna efektywność przetwarzania w chmurze,Metody
Informatyki Stosowanej 26(1), s. 121-132; 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 2010 - IT
Performance Management/ IT-Controlling.
121
„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. 53.
137 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
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
•
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
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 obliczeniowej142.
140 AMD (2011), Adoption, Approaches & Attitudes. The Future of Cloud Computing in the Public and
Private Sectors,AMD, http://www.amd.com/us/Documents/Cloud-Adoption-Approaches-and-AttitudesResearch-Report.pdf.
141 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. 19.
125
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
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. 177.
127
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
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
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
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
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
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
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
-
-
4.6. 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
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
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
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
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.
4.7. 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
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
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
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
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
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 decyzji146
145 Griffin R. (2005), Podstawy zarządzania organizacjami, PWN, Warszawa, s. 5.
146 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
(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
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.
5.2. 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 3.0148. 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. 3424-3428.
148 Źródło: Raport: Forster Research (2012), BI Maturity in The Enterprise: 2012 Update, August 7, 2012.
145
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ń konsolidacyjnych151.
149 Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, Paper No. 58854, Forrester
Research, Inc, s. 2.
150 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.,
http://blogs.forrester.com/boris_evelson/12-12-12-top_10_bi_predictions_for_2013_and_beyond.
146
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.,
http://blogs.forrester.com/michele_goetz/12-10-26master_data_management_does_not_equal_the_single_source_of_truth.
154 Evelson B. (2011), Trends 2011 And Beyond: Business Intelligence, op. cit., s. 3.
147
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
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. 5.
149
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. 500-501.
158 Opóźnienia danych i analizy są w istocie dystansem czasowym, który bezpośrednio wpływa na wartość
informacji.
150
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.
5.3. 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 emaili, 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. 122-127 oraz s. 118.
160 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
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. 28-31.
161 Gaudin S. (2012), Physicist says Moore's Law is 'collapsing', Computerworld, May 2, 2012.
162 Por. Cleveland H. (1982), Information as a resource, Futurist, Dec. 1982, s. 36-37. 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
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 13.
164 Hopkins B., Evelson B. (2011), Expand Your Digital Horizon with Big Data, Forrester Research, Inc.,
September 30, 2011, s. 4.
165 Olofson C., Vesset (2012), Big Data: Trends, Strategies, and SAP Technology, Technical report, No.
236135, IDC, s. 4.
166 Jacobs A. (2009), The pathologies of big data, Communications of the ACM 52(8), s. 44.
153
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.
6.
168 Por. rozdz. 4. - analiza ETO, a zwłaszcza ekonomiczne uwarunkowania funkcjonowania chmur
obliczeniowych.
154
•
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
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
Data170.
1. 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. 60-61.
170 Barton D., Court D. (2012), Making Advanced Analytics Work for You, Harvard Business Review
90(10), s. 80-83.
156
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
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. 62.
172 Swoyer S. (2012), Big Analytics: The Next Generation w Big Data Analytics. TDWI E-book, s. 9, TDWI
Inc., September 2012.
158
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. 12.
159
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. 20.
160
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. 61.
176 Dubmill E. (2012), What is Big Data? w Big Data Now: 2012 Edition, O'Reilly Media, Sebastopol, s.
10.
161
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
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ę.
5.4. 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. 9.
163
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
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
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 G00165291, Gartner Inc.
166
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
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
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. 4.
180 Mateos A., Rosenberg J. (2011), Chmura obliczeniowa …, op. cit., s. 235-248.
181 Croll A. (2012), Three Kinds of Big Data, op. cit., s. 60-61.
169
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
•
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.
5.5. 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. 5.
171
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, email 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. 76-77.
172
•
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. G00145507, Gartner
Research Inc. January 26, 2008.
185 Shen, G. (2011) Cloud computing. The Catalyst for self-service BI, Information Management, Sept/Oct
2011, s. 20.
173
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. 10.
187 Gartner (2012) , IT Glossary. Defining The IT Industry. Software as a Service (SaaS),
http://www.gartner.com/it-glossary/software-as-a-service-saas/.
188 Por. problem zamknięcia w chmurach obliczeniowych, poruszony w rozdziale czwartym.
174
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 2007.
Całkowity koszt utrzymania (tys. $)
Tradycyjne
oprogramowanie
Software as
a Service
Źródła oszczędności przy SaaS
Implementacja, wdrożenie
Integracja, kastomizacja
108
72
Testy podstawowej
infrastruktury, wdrożenie
54
0
Testy infrastruktury aplikacji,
wdrożenie
30
0
Szkolenie
101
34
• 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ń
750
0
• 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
480
1 500
Nieprzewidziane przestoje
308
0
• 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
2 298
1 640
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
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.,
http:/www.aberdeen.com.
176
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
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. 21.
178
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
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
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ł 3.
181
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
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.
6.1. 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
„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. 1-3. Cytowane słowa to opinia Marka
Madsena zwarta w tekście Swoyera.
184
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
• 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
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
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.
6.2. 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
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
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
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.
6.4. 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
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
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
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.
6.5. 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 20112012, PARP, Warszawa, s. 112.
194
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. 473-475.
195 Chomiak-Orsa I. (2009), Dylematy podejmowania przedsięwzięć informatycznych w małych i średnich
przedsiębiorstwach, Informatyka ekonomiczna 13, s. 70.
195
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. 475-476.
197 Pelissie du Rausas. M. et al. (2011), Internet matters. The Net's sweeping impact on growth, jobs and
prosperity, McKinsey and Company, s. 1.
198 Arendt Ł. (2007), Adaptability of the European small and medium-sized enterprises to information and
communication technologies, Instytut Pracy i Spraw Socjalnych, Warszawa, s. 110-117.
196
•
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. 283.
200 Chomiak-Orsa I. (2009), Dylematy podejmowania przedsięwzięć informatycznych..., op. cit., s. 71-72.
201 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. 478-482.
202 Por. Zygała R. (2009) Uwarunkowania rozwoju systemów ..., op. cit., s. 482-484.
197
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.
6.6. 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
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. 319-339 i Venkatesh V. et al. (2003), User Acceptance of
Information Technology: Toward a Unified View, MIS Quarterly 27(3), s. 425-478 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. 359-364.
205 Wu W.-W. (2011), Developing an explorative model for SaaS adoption, Expert Systems with
Applications 38, s. 15057-15064.
199
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. 15059.
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
(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. 44.
207 Ibid., s. 37.
208 Ibid., s. 43.
201
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. 15062-15063.
210 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. 366.
202
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.
361.
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. 165.
212 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. 171.
213 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. 303-317.
203
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 2007. Konkurencyjność
małych i średnich przedsiębiorstw, PKPP Lewiatan,
http://konfederacjalewiatan.pl/upload/File/2007_10/KONKURENCYJNOsc%20MSP%202007%20%20Raport.doc, s. 31.
215 Benlian A., Hess T., Buxmann P. (2009), Drivers of SaaS-Adoption ..., op. cit., s. 358.
204
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. 120-127.
217 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. 269-296.
219 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 4.
205
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. 53-54.
206
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
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
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. 295-336.,
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. 121-131, Cwalina W. (2000),
Zastosowanie modelowania równań strukturalnych w naukach społecznych, Statsoft Polska,
http://www.statsoft.pl/czytelnia/badanianaukowe/d4spol/nazastosowaniemod3.pdf.
209
Ankieta została przygotowana w oparciu o niezależną, internetową platformę ankietową
i dostępna była dla zainteresowanych od 23.08.2013 do 16.09.2013 (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
0-9
1
5%
1
4
14
5%
20%
70%
< 2 mln euro
4
20%
10-50 mln euro
2-10 mln euro
> 50 mln euro
b/d
4
3
7
2
20%
15%
35%
10%
Przemysł
7
35%
Handel
Administracja
Finanse i bankowość
Zdrowie
Inna
3
2
2
2
4
15%
10%
10%
10%
20%
Menedżer IT
8
40%
Administrator
BI Manager
Inne
Konsultant
Programista
6
2
2
1
1
30%
10%
10%
5%
5%
Tak
12
60%
Nie
8
40%
10-49
50-249
>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. 362.
224 Ringle, C.M., Wende, S., Will, S.: SmartPLS 2.0 (M3) Beta, Hamburg 2005, http://www.smartpls.de.
210
rzetelności łącznej (ang. composite reliability, CR) jest wartość 0.7225 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 < 0.05.
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. 39-50. Por. także Przechlewski T. (2010),
Sposoby oceny modelu pomiaru w praktyce informatyki ekonomicznej,
http://pinkaccordions.homelinux.org/staff/tp/Pubs/sem_intros/ocena_modelu_pomiaru.html.
226 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. 277-319.
211
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. 366.
212
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
„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. 110.
214
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”)231.
230 Wyniki analizy ogólnej ETO znaleźć można tabelach 3-6 (rozdz. 4).
231 Por. rozdz. 4.
215
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 17.
216
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
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
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
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
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
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
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
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
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
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. 4.
235 Gadamer H. G. (2000), Rozum, słowo, dzieje, PIW, Warszawa, s. 40.
226
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
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. 1.1.
237 Por. rozdz. 6.2
238 Por. rozdz. 4.
228
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
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. 99-108.
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. 239-246.
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. 321-328.
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. 215-234.
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. 445-456.
AMD (2011), Adoption, Approaches & Attitudes. The Future of Cloud Computing in the Public and Private
Sectors, AMD, http://www.amd.com/us/Documents/Cloud-Adoption-Approaches-and-AttitudesResearch-Report.pdf
Anderson C. (2010), Who's to Blame, Wired Magazine 18(9), s. 122-127.
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. 146-147.
Armbrust M. et al. (2010), A view of cloud computing, Communications of the ACM 53, s. 50-58.
Armstrong B. (2010), At Last, Data Warehousing for the Masses, Business Intelligence Journal 15(1), s. 4247.
Badurek J. (2012), Systemy ERP czeka kolejna fala zmian, IDG Polska,
http://www.computerworld.pl/artykuly/382164/Systemy.ERP.czeka.kolejna.fala.zmian.html
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.
79-83.
Baum D. et al. (2011), Sate of Data Integration Market, Oracle Corporation,
http://tdwi.org/whitepapers/2011/05/state-of-the-data-integration-market.aspx
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. 357-369.
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. 167189.
Bernstein P. A., Haas L. M. (2007), Information integration in the enterprise, Communications of the ACM
51(9), s. 72-79.
230
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. 691-708.
Birkinshaw J., Bouquet C., Barsoux J.-L. (2010), The 5 Myths of Innovation, MIT Sloan Management
Review 52(2), s. 43-50.
Birst (2010), Full-Featured Business Intelligence for the Cloud, Birst, Inc.,
http://www.birst.com/pdf/birst_technical_whitepaper.pdf
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. 5-11.
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.
38-54.
Bracha A., Brown D. (2012), Affective Decision-Making: A Theory of Optimism Bias, Games and Economic
Behavior 75, s. 67-80.
Briggs L. (2008), BI Case Study: SaaS Delivers Integration Flexibility with Salesforce.com, Business
Intelligence Journal 14(3), s. 40-42.
Briscoe G., Marinos A. (2009), Digital Ecosystems in the Clouds: Towards Community Cloud Computing,
CoRR abs/0903.0694.
Briscoe G., Wilde de P. (2009), Computing of Applied Digital Ecosystems, CoRR abs/0910.0674.
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. 384-426.
Campbell-Kelly M. (2009), Historical reflections: The rise, fall, and resurrection of software as a service,
Communications of the ACM 52(5), s. 28-30.
Canes M. (2009), Business intelligence for the SME, CA Magazine, s. 46-48.
Carr N. (2005), The end of corporate computing, MIT Sloan Management Review 45(3), s. 67-73.
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. 251-268.
Chadha B., Iyer M. (2010), BI in a Cloud: Defining the Architecture for Quick Wins, Infosys,
http://www.infosys.com/infosys-labs/publications/Documents/BI-in-a-cloud.pdf
Chan L.-K., Sim Y.-W., Yeoh W. (2011), A SOA-Driven Business Intelligence Architecture, Communications
of the IBIMA Article ID 216423.
Chesbrough H. (2003), The Era of Open Innovation, MIT Sloan Management Review 44(3), s. 35-41.
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. 295-336.
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. 95-142.
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. 66-75.
Chuah M.-H., Wong K.-L. (2011), A review of business intelligence and its maturity models, African Journal
of Business Management 5(9), s. 3424-3428.
231
Cleveland H. (1982), Information as a resource, Futurist, s. 34-39.
Collins L. (2006), Opening Up the Innovation Process, Engineering Management Journal 16(1), s. 14-17.
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.
60-64.
Cwalina W. (2000), Zastosowanie modelowania równań strukturalnych w naukach społecznych, Statsoft
Polska, http://www.statsoft.pl/czytelnia/badanianaukowe/d4spol/nazastosowaniemod3.pdf
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. 85-107.
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. 27-55.
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. 319-339.
Deleuze G. (1997), Różnica i powtórzenie, Wydawnictwo KR, Warszawa.
Deleuze G., Guattari F. (1998), Kłącze, Colloquia Communia 1-3, s. 221-237.
Delic K. A., Riley J. A. (2010), Enterprise Knowledge Clouds: Architecture and Technologies w Furht B.,
Escalante A., red., Handbook of Cloud Computing, Springer Science+Business Media, LLC, s. 239-254.
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,
http://tdwi.org/articles/2011/11/09/lesson-its-a-brave-new-world-for-business-intelligence.aspx
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. 265-279.
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. 6-102.
Dini P. et al. (2005), The Digital Ecosystem Research Vision: 2010 and Beyond,
http://www.digital-ecosystems.org/events/2005.05/de_position_paper_vf.pdf
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. 310.
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. 63-75.
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. 327-334.
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. 33-44.
Dumbill E. (2012), Getting Up to Speed with Big Data red., Big Data Now: 2012 Edition, O'Reilly Media,
Sebastopol, s. 3-17.
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. 57-68.
Dzierżanowski M. et al. (2007), Kierunki inwestowania w nowoczesne technologie w przedsiębiorstwach
MŚP, Polska Agencja Rozwoju Przedsiębiorczości, Warszawa.
232
Eckerson W. (2009), When to Implement BI in the Cloud, TDWI Inc, http://tdwi.org/Blogs/WayneEckerson/2009/06/Implementing-BI-in-the-Cloud.aspx
Eckerson W. (2009), Data Federation Checklist Report, TDWI Research,
http://download.101com.com/pub/tdwi/Files/TDWI_ChecklistReport_DataFederation.pdf
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, http://tdwi.org/~/media/TDWI/TDWI/Research/BPR/2007/TDWI_BPR_1Q07_PA
%20pdf.ashx
Eckerson W. (2007), Best Practices in Operational BI, TDWI Research, http://tdwi.org/research/2007/07/bpr3q-best-practices-in-operational-bi/bpr_3q07_report.aspx
ENISA (2009), An SME perspective on Cloud Computing, ENISA,
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-sme-survey
ENISA (2009), Cloud Computing Security Risk Assessment, ENISA,
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-riskassessment/at_download/fullReport
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. 58854), Forrester Research,
Inc.
Evelson B. (2012), Top 10 BI Predictions For 2013 and Beyond, Forrester Research, Inc.,
http://blogs.forrester.com/boris_evelson/12-12-12-top_10_bi_predictions_for_2013_and_beyond
Evelson B. (2011), BI in the Cloud? Yes, and on the Ground too, Forrester Research,
http://blogs.forrester.com/business_process/2010/01/bi-in-the-cloud-yes-and-on-the-ground-too.html
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. 28-31.
Feiman J., MacDonald N. (2011), Magic Quadrant for Business Intelligence Platforms, 27 January 2011 / ID
Number: G00210036.
Ferguson M. (), Cloud Based BI – Understanding Options Is the Biggest Barrier, ,
http://intelligentbusiness.biz/wordpress/?p=281
Foody P. (2009), User-Centered Business Intelligence, Business Intelligence Journal 14(4), s. 17-25.
Fornell C., Larcker D. (1981), Evaluating structural equation models with unobservable variables and
measurement error, Journal of Marketing Research 18(1), s. 39-50.
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. 118-128.
Foster I. et al. (2008), Cloud Computing and Grid Computing 360-Degree Compared w GCE '08 In 2008
Grid Computing Environments Workshop, s. 1-10.
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 Science+Business Media, LLC, s. 3-19.
Ganesan S. (1994), Determinants of Long-Term Orientation in Buyer-Seller Relationships, Journal of
Marketing 58(2), s. 1-19.
Gartner (2012), Gartner Says High Growth in IT Spending in China Will Fuel Adoption of New Technologies
in 2012 and Beyond, Gartner Inc., http://www.gartner.com/it/page.jsp?id=2124215
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. 303-317.
Gillen A., Grieser T., Perry R. (2008), Business Value of Virtualization: Realizing the Benefits of Integrated
Solutions, IDC, Raport techniczny nr 213430,
http://h20195.www2.hp.com/v2/GetPDF.aspx/c01765818.pdf
233
Goel M. (2011), Cloud ready Business Intelligence with Oracle Business Intelligence 11g, Oracle,
http://www.oracle.com/us/solutions/business-intelligence/cloud-ready-oracle-bi-177505.pdf
Goetz M. (2012), Master Data Management Does Not Equal The Single Source of Truth, Forrester Research,
Inc., http://blogs.forrester.com/michele_goetz/12-10-26master_data_management_does_not_equal_the_single_source_of_truth
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. 1--6.
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, http://www.infosys.com/offerings/industries/consumer-packaged-goods/whitepapers/Documents/establishing-business-intelligence.pdf
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. 28-43.
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. 1-5.
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. 135-140.
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. 778-787.
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. 58-61.
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. 277-319.
Herdon M. et al. (2010), Digital Business Ecosystem Tools as Interoperability Drivers, IFIP Advances in
Information and Communication Technology 326, s. 116-127.
Hesse C. (2002), The rise of intellectual property, 700 B.C. - A.D 2000: an idea in the balance, Daedalus
131(2), s. 26-45.
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. 30-32.
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, http://www.ibm.com/common/ssi/cgi-bin/ssialias?
234
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, http://www.ibm.com/common/ssi/cgi-bin/ssialias?
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,
http://tdwi.org/~/media/TDWI/TDWI/Research/BPR/2011/TDWI_BPReport_Q311_SSBI_Web.ashx
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. 159-160.
ITU-T (03.2009), Distributed Computing: Utilities, Grids & Clouds, International Telecommunication
Union, http://www.itu.int/dms_pub/itu-t/oth/23/01/T23010000090001PDFE.pdf
Jacobs A. (2009), The pathologies of big data, Communications of the ACM 52(8), s. 36-44.
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 Science+Business Media, LLC, s. 335-355.
Jutras C. (2009), ERP and BI: When 1+1=3, Aberdeen Group,
http://fm.sap.com/images/WhiteRhino/SAP0081_Industries_All/wholesale/assets/learn/gated/ERP
%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. 235-254.
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. 20-22.
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. 216-221.
KPMG (2010), From cost to value: 2010 global survey on the CIO agenda, KPMG International,
http://www.kpmg.com/Global/en/IssuesAndInsights/ArticlesPublications/Documents/CIO-From-cost-tovalue.pdf
KPMG (2008), Getting the Most from Your Investments in IT, KPMG LLP,
http://www.kpmg.com/Ca/en/IssuesAndInsights/ArticlesPublications/Oi/Documents/KPMG-%20Getting
%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. 2032-2033.
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. 774-789.
Larose D. (2006), Odkrywanie wiedzy z danych, PWN, Warszawa.
235
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. 429-436.
LogiXML (2010), An Overview of BI Models for Small- to Medium-Sized Businesses, LogiXML,
http://www.logixml.com/content/18_OverviewofBIModels.pdf?ResourceCenter
Lopez J. (2012), Best Practices fro Turning Big Data into Big Insights, Business Intelligence Journal 17(4), s.
17-21.
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.
359-364.
Loshin D. (2012), Satisfying New Requirements for Data Integration, TDWI Research,
http://tdwi.org/~/media/TDWI/TDWI/Research/CR/TDWI_Checklist%20Report_Satisfying%20New
%20Requirements%20for%20DI_web.ashx
Loshin D. (2011), Fundamentals of Business Intelligence for Small and Midsize Enterprise, TDWI Research,
http://tdwi.org/~/media/TDWI/TDWI/Research/CR/TDWI_Checklist_BI_for_SME_0611.ashx
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 2011-2012, PARP,
Warszawa, s. 110-118.
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. 20-43.
Malmendier U., Tate G. (2005), CEO Overconfidence and Corporate Investment, Journal of Finance 60(6), s.
2661-2700.
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. 120-127.
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. 103-114.
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. 176189.
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. 709-734.
Maynard D. et al. (2007), Natural language technology for information integration in business intelligence w
10th International Conference on Business Information Systems, s. 25--27.
McAfee A., Brynjolfsson E. (2012), Big Data: The Management Revolution, Harvard Business Review
90(10), s. 61-68.
McCrae R. (1996), Social Consequences of Experiential Openness, Psychological Bulletin 130(3), s. 323337.
McDonough B., Vesset D., Tenwolde E. (2008), Business analytics SaaS expand, KM World 17(1), s. 25-26.
McKinsey (2011), Big data: the next frontier for innovation, competition and productivity, McKinsey Global
Institute, http://www.mckinsey.com/mgi/publications/big_data/pdfs/MGI_big_data_full_report.pdf
McKnight D., Cummings L., Chervany N. (1998), Initial Trust Formation in New Organizational
Relationship, Academy of Management Review 23(3), s. 473-490.
236
Meents S., Tan Y.-H., Verhagen T. (2004), Distinguishing different types of trust in online B2B marketplaces,
BLED 2004 Proceedings, s. 53-65.
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. 25-30.
Microstrategy (2009), An Architecture for Software-as-a-Service (SaaS) Business Intelligence, Microstrategy,
http://tdwi.org/whitepapers/2009/08/an-architecture-for-software-as-a-service-business-intelligence.aspx?
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. 481-495.
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, 141-158.
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. 192-222.
Morris H. D. (2010), Business Analytics and the Path to Better Decisions (No. 224877), 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. 447-478.
Murphy I. (2012), BI is NOT a Cloud application, Computer Weekly,
http://www.computerweekly.com/blogs/it-fud-blog/2011/04/bi-is-not-a-cloud-application.html
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.,
http://www.gartner.com/resources/114300/114358/114358.pdf
Nayak N. et al. (2007), Core business architecture for a service-oriented enterprise, IBM Systems Journal
46, s. 723-742.
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. 437-445.
Obłój K. (2007), Strategia organizacji, PWE, Warszawa.
Olofson C., Vesset (2012), Big Data: Trends, Strategies, and SAP Technology (No. 236135), 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, http://www.swo.ae.katowice.pl/swo-2004/zarzadzanie-wiedza-i-rozwiazania-bi/systemybusiness-intelligence-w-zarzadzaniu-wiedza-w-organizacji.html
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. 74-79.
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. 364-374.
237
PARP (2010), Raport o stanie sektora małych i średnich przedsiębiorstw w Polsce w latach 2008-2009,
Polska Agencja Rozwoju Przedsiębiorczości, http://www.parp.gov.pl/files/74/81/380/9282.pdf
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. 446-452.
Patrick P. (2005), Impact of SOA on enterprise information architectures w Proceedings of SIGMOD
Conference, s. 844-848.
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. 201-202.
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 ,
http://dssresources.com/history/dsshistory.html
Przechlewski T. (2010), Sposoby oceny modelu pomiaru w praktyce informatyki ekonomicznej., ,
http://pinkaccordions.homelinux.org/staff/tp/Pubs/sem_intros/ocena_modelu_pomiaru.html
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. 212-225.
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. 258-266.
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. 1-16.
Razavi A., Moschoyiannis S., Krause P. (2009), An open digital environment to support business ecosystems,
Peer-to-Peer Networking and Applications 2(4), s. 367-397.
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. 241-246.
Reich B., Benbasat I. (2000), Factors That Influence the Social Dimension of Alignment between Business
and Information Technology Objectives, MIS Quarterly 24(1), s. 81-113.
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. 3-26.
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. 1299-1318.
Rogers S. (2011), Big Data is Scaling BI and Analytics, Information Management, s. 15-18.
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. 143-153.
Rotem-Gal-Oz A. (2007), What is SOA anyway?, http://www.rgoarchitects.com/Files/SOADefined.pdf
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/0311017.
Russom P. (2012), Introduction to Next Generation Master Data Management, What Works in Data
Management 33, s. 24-27.
Russom P. (2012), Ten Goals for Next Generation Data Quality, What Works in Data Management 33, s. 2-7.
Russom P. (2011), Big Data Analytics, TDWI Research,
http://tdwi.org/~/media/TDWI/TDWI/Research/BPR/2011/TDWI_BPReport_Q411_Big_Data_Analytics
_Web.ashx
Russom P. (2011), The State of Big Data Analytics, What Works in Data Management 33, s. 20-23.
Russom P. (2011), Next Generation Data Integration, TDWI Research, http://tdwi.org/research/2011/04/bprq2-next-generation-data-integration.aspx
238
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. 323-350.
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. 227-232.
Santaferraro J. (2012), Can Cloud-Aware Analytics Make the Difference Between Thrashing and Thriving?,
TWDI, http://tdwi.org/articles/2012/08/07/cloud-aware-analytics.aspx
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. 272-279.
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. 81-113.
Siwińska J. (2011), Ekonomiczna efektywność przetwarzania w chmurze, Metody Informatyki Stosowanej
26(1), s. 121-132.
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, www.kmis.pwsz.chelm.pl/publikacje/IV/Soja.pdf
Spence L. (1999), Does size matter? The state of the art in small business ethics, Business Ethics: A
European Review 8(3), s. 163-174.
Sroka H., Olszak C. (2001), Zintegrowane systemy informatyczne w zarządzaniu, AE Katowice, Katowice.
Standish, Group (2009), CHAOS Summary 2009, Standish Group International Inc.,
http://www.standishgroup.com
Stanley J., Briscoe G. (2010), The ABC of Digital Business Ecosystems, Communications Law 15(1), s. 1225.
Starczewska-Krzysztoszek M. (2007), Monitoring kondycji sektora MSP 2007. Konkurencyjność małych i
średnich przedsiębiorstw., PKPP Lewiatan,
http://konfederacjalewiatan.pl/upload/File/2007_10/KONKURENCYJNOsc%20MSP%202007%20%20Raport.doc
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. 2-5.
Stodder D. (2011), Five Emerging Trends in Business Intelligence and Analytics, What Works in Emerging
Technologies 32, s. 2-5.
Stokes R. (2011), eMarketing: The essential guide to digital marketing, Quirk eMarketing,
www.quirk.biz/emarketingtextbook/download
Stonebraker M. (2011), Stonebraker on data warehouses, Communications of the ACM 54, s. 10-11.
Strebel J., Stage A. (2010), An Economic Decision Model for Business Software Application Deployment on
Hybrid Cloud Environments w MKWI 2010 - 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. 121-131.
Sultan N. (2010), Reaching for the 'cloud'- How SMEs can manage, International Journal of Information
Management 31, s. 272-278.
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. 7-10.
239
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. 343360.
Tan H., Plowman D., Hancock P. (2008), The evolving research on intellectual capital, Journal of Intellectual
Capital 9(4), s. 585-608.
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 2011-2012, PARP, Warszawa.
TCS (2007), Evolving IT from 'Running the Business' to 'Changing the Business', Tata Consulting Services,
http://www.tcs.com/SiteCollectionDocuments/White%20Papers/DEWP_05.pdf
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. 1-7.
Tews R. (2007), Beyond IT. The business value of SOA, AIIM E-DOC 21, s. 14-17.
Thompson J. (2009), Business Intelligence in a SaaS Environment, Business Intelligence Journal 14(4), s. 5055.
Thoo E. (2009), Data In the Cloud: The Changing Nature of. Managing Data Accessibility (Gartner RAS
Core Research Note G00165291), Technical report, Gartner Inc.
Tsai J. (2009), Intelligence in the Cloud, Customer Relationship Management, s. 38-43.
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. 149-164.
Venkatesh V. et al. (2003), User Acceptance of Information Technology: Toward a Unified View, MIS
Quarterly 27(3), s. 425-478.
Vertica (2011), Transforming the Economics of Data Warehousing with Cloud Computing, Vertica Systems
Inc., http://www.vertica.com/wpcontent/uploads/2011/01/CloudTransformsEconomicsOfDataWarehousing-Vertica.pdf
Vesset D. (2012), Market Analysis: Worldwide Business Analytics Software 2012-2016 Forecast and 2011
Vendor Share (IDC No. 235494), Technical report, IDC.
Vesset D. (2011), Worldwide Business Intelligence Tools 2010 Vendor Shares (IDC No. 228442), Technical
report, IDC.
Vijayan J. (2011), Self-service BI, SaaS, real-time analytics will dominate 2011 agenda, Computerworld,
http://www.computerworld.com/s/article/9201318/Self_service_BI_SaaS_real_time_analytics_will_domi
nate_2011_agenda
Vouk M. (2008), Cloud computing - issues, research and implementations, Journal of Computing and
Information Technology 4, s. 235-246.
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. 536-540.
Vujasinovic M., Marjanovic Z. (2006), Data level enterprise applications integration, Lecture Notes in
Computer Science 3812(Business Process Management Workshops), s. 390-395.
Wang L. et al. (2010), Cloud Computing: a Perspective Study, New Generation Computing 28(2), s. 137-146.
Watson H. J. (2009), Tutorial: Business Intelligence – Past, Present, and Future, Communications of the
Association for Information Systems 25, s. 487-510.
Weinhardt C. et al. (2009), Cloud Computing – A Classification, Business Models, and Research Directions,
Business & Information Systems Engineering(5), s. 391-399.
White C. (2005), Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, TDWI
Research, http://download.101com.com/tdwi/research_report/DIRR_Report.pdf
White D. (2010), Fast, Affordable, Agile - The Case for SaaS BI, Aberdeen Group Inc.,
http:/www.aberdeen.com
240
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. 277-294.
Williams S., Williams N. (2003), The Business Value of Business Intelligence, Business Intelligence Journal
Fall, s. 1-11.
Williamson O. (1991), Comparative economic organization: The analysis of discrete structural alternatives.,
Administrative Science Quarterly 36(2), s. 269-296.
Wu W.-W. (2011), Developing an explorative model for SaaS adoption, Expert Systems with Applications
38, s. 15057-15064.
Xu Z., Li G. (2011), Computing for the masses, Communications of the ACM 54, s. 129-137.
Zhao H., Seibert S. (2006), The big five personality dimensions and entrepreneurial status: a meta-analytical
review., Journal of Applied Psychology 91(2), s. 259-71.
Ziemba E., Obłąk I. (2012), Systemy informatyczne w organizacjach zorientowanych procesowo, Problemy
Zarządzania 10(3), s. 8-24.
Zutshi A. (2012), Future of ERP, Infosys Lab Briefings 10(1), s. 61-66.
Zygała R. (2009), Uwarunkowania rozwoju systemów business intelligence w sektorze małych i średnich
przedsiębiorstw, Informatyka ekonomiczna 13, s. 472-485.
241
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...................................................101
Rysunek 9.Określenie zależności w między elementami analizy SWOT w metodzie "od wewnątrz do
zewnątrz".................................................................................................................................................139
Rysunek 10. Udziały czynników ETO w na tle matrycy SWOT....................................................................140
Rysunek 11. Udziały czynników ETO w na tle matrycy SWOT (podział na wymiary).................................140
Rysunek 12. Układ elementów warstw zasobów i systemowej w odniesieniu do procesu podejmowania
decyzji......................................................................................................................................................144
Rysunek 13. Dystans akcji, a wartość informacji............................................................................................149
Rysunek 14. Systemy analityki biznesowej, a rozproszenie w warstwach zasobów i systemowej................189
Rysunek 15. Systemy analityki biznesowej na tle scenariusza rozwoju modeli tworzenia
infrastruktury IT.......................................................................................................................................190
Rysunek 16. Model oceny możliwości adaptacji SaaS zaproponowany przez Wu.........................................200
Rysunek 17. Model TAM, a uwarunkowania implementacji SaaS BI............................................................202
Rysunek 18. Model oceny możliwości adaptacji SaaS zaproponowany przez Benliana
i współpracowników...............................................................................................................................203
Rysunek 19. Oszacowany model oceny możliwości adaptacji SaaS BI..........................................................213
242
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...........................................................................................................132
Tabela 4. Analiza ETO - Słabe strony..............................................................................................................133
Tabela 5. Analiza ETO - Szanse......................................................................................................................133
Tabela 6. Analiza ETO - Zagrożenia...............................................................................................................133
Tabela 7. Porównanie grup czynników analizy ETO na tle charakteru organizacji........................................135
Tabela 8. Całkowity koszt utrzymania (TCO). Tradycyjne oprogramowanie vs. Software-as-a-Service.......175
Tabela 9. Determinanty SaaS BI na tle postulatów samoobsługowej platformy BI........................................180
Tabela 10. Typy systemów analityki biznesowej na tle modeli tworzenia infrastruktury w ujęciu
korporacyjnym.........................................................................................................................................193
Tabela 11. Model oceny adaptacji SaaS BI na podstawie Benlian A. et al. (2009). Konstrukty
i indykatory..............................................................................................................................................208
Tabela 12. Badania oceny możliwości adaptacji SaaS BI. Charakterystyka próby.........................................210
Tabela 13. Ocena jakości modelu pomiaru: trafność zbieżna i rzetelność wewnętrzna..................................211
Tabela 14. Ocena jakości modelu pomiaru: trafność dyskryminacyjna (ładunki krzyżowe)..........................212
Tabela 15. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych
dla dużych przedsiębiorstw......................................................................................................................218
Tabela 16. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach prywatnych
dla dużych przedsiębiorstw......................................................................................................................219
Tabela 17. Wyniki analizy ETO dla funkcjonowania systemów analityki biznesowej w chmurach publicznych
dla małych i średnich przedsiębiorstw.....................................................................................................220
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.............................................221
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..............................................221
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............................221
Tabela 21. Udziały czynników ogólnej analizy ETO na tle matrycy SWOT (wyniki powtórzone
z rozdz. 4)................................................................................................................................................221
243
Załącznik A. Kwestionariusz badań oceny możliwości
adaptacji SaaS BI
244
245
246
247
248