Mariusz Jażdżyk

Chief Data Officer

Jak przeprowadzić transformację opartą o dane?

© Mariusz Jażdżyk, 2025

Książka pokazuje, jak prowadzić organizację ku skutecznemu wykorzystaniu danych w biznesie. Omawia cztery kluczowe obszary: cele biznesowe i strategię, technologię i architekturę, różne rodzaje danych oraz ludzi i zespoły. Jest przeznaczona dla decydentów i specjalistów pracujących z danymi, pomagając dostrzec elementy niezbędne do osiągania sukcesu na poziomie projektów i całej organizacji.

ISBN 978-83-8189-219-3

Książka powstała w inteligentnym systemie wydawniczym Ridero

Przedmowa

W ostatnich latach coraz więcej mówi się i pisze o „danych”, słowo „dane” odmienia się przez wszystkie przypadki. Patrząc z dzisiejszego punktu widzenia, szczęśliwie dla mnie, od początku mojej kariery zawodowej zajmowałem się „danymi”. Po ukończeniu na Wydziale Elektroniki Politechniki Warszawskiej specjalności — systemy informatyczne wsparcia decyzji, rozpocząłem poszukiwanie miejsca, gdzie można takie systemy implementować. Dosyć szybko doszedłem do wniosku, że bez danych jako podstawowego budulca, nie można myśleć o żadnym istotnym wspieraniu czy optymalizowaniu decyzji biznesowych. Ta myśl towarzyszyła mi i była wzmacniana podczas pracy w wielu firmach. Budowałem hurtownie danych wraz z ludźmi, którzy nie traktowali swojej pracy jak zło konieczne i byli do niej bardzo dobrze przygotowani. Branża telekomunikacyjna dysponowała największą ilością danych, a także realnych potrzeb ich operacyjnego i analitycznego wykorzystania. Już na przełomie roku dwutysięcznego brałem udział w tworzeniu środowiska analitycznego w Polkomtelu — operatorze sieci Plus GSM. Tam właśnie, bardzo dobrze dobrany zespół techniczny, pracujący na efektywnej technologii i skupiający się — co nawet dzisiaj jest ewenementem — na problemach biznesowych, doprowadził do sytuacji, w której ze zdziwieniem obserwowaliśmy rynek i publikacje z informacjami o projektach hurtowni danych, kończących się przeważnie porażką. Taki obraz rynku był dla nas obcy, przedstawiane czarne scenariusze nie sprawdzały się w naszej pracy. Nie było łatwo, jednak efektem działań stały się wartości konsekwentnie dostarczane naszym odbiorcom. Kluczem do sukcesu, jak się później okazało, był niezwykle kompetentny i stabilny zespół, rozumiejący biznes i skupiony na realizacji celów biznesowych. Ponadto istotny okazał się minimalny narzut korporacyjny, dobra znajomość technologii i zdrowe partnerstwa z dostawcami.

Kolejnym wyzwaniem po pracy w Polkomtelu były dla mnie firmy telekomunikacyjne: Telekomunikacja Polska i PTK Centertel, połączone w największego operatora w naszej części Europy — Orange Polska. Dzięki pracy w Orange poznałem na żywym organizmie aspekty, które nie były mi wcześniej znane — ekstremalnie złożone ekosystemy organizacyjno-technologiczne jednej z największych korporacji, bo liczącej sobie kilkadziesiąt tysięcy pracowników. Takie wyzwania nie byłyby możliwe do opanowania, gdyby nie strategiczne i operacyjne podejście do budowy architektury systemów i rozwoju obszaru danych. Wiele projektów realizowanych na rynku (ze względu na niewielką złożoność albo z powodu skupienia się jedynie na kilku wąskich aspektach) nawet nie dotyka tego zagadnienia. Zmierzenie się ze skalą problemu jest niezbędne, gdy chcemy osiągnąć efekty biznesowe w dużej strukturze, w organizacji ze sporą historią lub zaawansowanej, za którą stoi technologia o dużej złożoności. Brak właściwego podejścia, zakładającego szerokie spojrzenie na całość prac, powoduje, że lokalne sukcesy nie mają biznesowego znaczenia, znoszą się z innymi pracami, albo ujawniają ukryte koszty widoczne w innych miejscach, czy też nie uwzględniają ważnych aspektów, które powinny być wzięte pod uwagę. Dopracowanie efektywnej metody pracy na dwóch poziomach, strategicznym i projektowym, nie było łatwe. Spory udział w tej ewolucji miała metodologia TOGAF[1], którą stosowałem niezwykle ostrożnie i pragmatycznie. Widziałem mocne i słabe punkty skupienia się na problematyce strategii. Dostrzegałem także trudność integracji wielu spojrzeń strategicznych i rozpoznawałem, gdzie realnie podejmowane są decyzje w tak dużej firmie. Wiedza ta była kluczowa do ułożenia całości wizji, którą prezentuję w mojej książce.

Znalezienie właściwej drogi do budowy strategii analityki było ważnym etapem moich poszukiwań, ale i to nie zagwarantowałoby powodzenia. Strategia, jak się okazuje, jest tyle warta, ile taktyka, która za nią stoi, dlatego kolejnym etapem mojej pracy było ułożenie strategii analityki, wraz z poszukiwaniem najlepszego operacyjnego sposobu skutecznego jej wdrażania. Doświadczenia efektywnego wprowadzania rozwiązań, które wyniosłem z pracy dla Polkomtela, przydało się. Nadeszły czasy rozkwitu metod AGILE[2], okazały się one ważnym kluczem spinającym cele strategiczne i produktowe, dawały też szansę na postępy we wdrożeniach. Ten etap pozwolił na połączenie rozwoju architektury środowiska analitycznego, w założonym, dobrze określonym kierunku, z efektywną pracą, bazującą na lokalnie podejmowanych decyzjach, a także na poznawanie danych i nowych technologii opensource przez całkiem sporą organizację. Wszystko zostało zrealizowane zgodnie z kierunkiem wynikającym z potrzeby biznesowej. Holistyczne podejście w zakresie rozwoju analityki danych dało polskiemu oddziałowi Orange pozycję lidera analityki w grupie Orange, wyprzedziliśmy inne dojrzałe rynki. Konsekwentnie stosowane połączenie aspektów, które staram się wyjaśnić w tej książce, po pewnym czasie procentuje widocznymi efektami biznesowymi, chętnie naśladowanymi przez innych. Metoda nie jest łatwa do skopiowania, wymaga zastosowania jednocześnie wielu reguł i połączenia aspektów, które zwykle rozpatrywane są oddzielnie.

Kolejną firmą, która miała istotny wpływ na mój sposób myślenia o budowie analityki, jest grupa mediowo-komunikacyjna Publicis, obsługująca jedną trzecią polskiego rynku reklamowego tradycyjnego i cyfrowego. Różnica w wykorzystaniu danych w tej branży jest widoczna gołym okiem. Wymagana tutaj dynamika powoduje, że całkiem oczywiste staje się stosowanie wspomnianych już metod AGILE, ale też elastyczne podejście do pozyskania infrastruktury technicznej i idące za tym odpowiednie przygotowanie zespołu do zadania. Są jednak elementy niezmienne w działaniu wymienianych firm: cel biznesowy zawsze musi być pierwszym powodem, dla którego podejmujemy prace w analityce danych, powinna to być także znajomość danych, strategiczne podejście do technologii i do budowy całości architektury, a także dobrze ułożona współpraca w zespole realizującym projekt, jak i między różnymi zespołami oraz resztą organizacji — współpraca adaptacyjna i przyrostowe rozwijanie odpowiednich funkcji systemu. Niezwykle ważne miejsce zajmuje to, co w telekomach i bankach jest o wiele łatwiejsze — specjalne podejście do aspektu pozyskania danych z ekosystemu współpracujących firm.

Usystematyzujmy cztery elementy, wokół których będę prowadził czytelnika przez temat danych, są nimi:

— sam cel biznesowy, który zawsze musi być pierwszym powodem, dla którego podejmujemy prace w analityce danych,

— znajomość danych,

— strategiczne podejście do technologii i do budowy całości architektury,

— dobrze ułożona współpraca, zarówno w zespole realizującym projekt, jak i między różnymi zespołami oraz z resztą organizacji — współpraca adaptacyjna i przyrostowe rozwijanie odpowiednich funkcji systemu.

Wnioski, zebrane podczas dwudziestu lat mojej pracy w kilku firmach i połączone z szerokim spojrzeniem na wiele różnych branż, które miałem okazję poznać podczas przeprowadzonych audytów[3] kilkudziesięciu międzynarodowych projektów, doprowadziły mnie do konkluzji — co działa, a co jest przepisem na porażkę.

W książce skupiam się na wymiarach, które uważam za najważniejsze w osiągnięciu sukcesu w analityce, są nimi: cel biznesowy, dane, ludzie, technologia. Uważam, że te aspekty należy szczególnie wziąć pod uwagę i nie wolno o żadnym z nich zapomnieć. Próbuję przedstawić, w jaki sposób łączyć owe wymiary ze sobą, które połączenia są ważne oraz na jakim etapie należy szczególnie się nimi zajmować. Ważniejsze działania rozkładam w czasie, a dokładnie w poszczególnych etapach pracy chief data officera (CDO).

Podsumowanie moich wniosków powinno pomóc osobom, stawiającym sobie za cel rozwój danych w różnych organizacjach. Pomoże także w uzyskaniu szerszego spojrzenia zaangażowanym w pracę nad analityką, co jest niezwykle korzystne dla osobistego rozwoju. Oczywiście nie wszystkie wnioski mogą zostać zastosowane od razu i nie wszystkie mogą być stosowane bez modyfikacji, z pewnością jednak zwiększają szanse lidera analityki na osiągnięcie sukcesu i taki jest główny cel tej książki.

Rys. 1: Cztery główne aspekty analityki prezentowane w książce. Rysunek pokazuje, jaka organizacja powstanie, jeśli niewystarczająco skupimy się na jednym lub większej liczbie koniecznych elementów.

Rys. 2: Cztery główne aspekty analityki prezentowane w książce. Ilustracja przedstawia, jakich rezultatów możemy się spodziewać, jeśli zabraknie jednego lub większej liczby niezbędnych elementów.

[1] The TOGAF® — model rozwoju architektury korporacyjnej, standard rozwijany przez organizację The Open Group, https://www.opengroup.org/togaf

[2] Manifest AGILE: https://agilemanifesto.org/

[3] Autor jest ekspertem Komisji Europejskiej i brał udział w ocenie wielu edycji projektów wnioskujących o dofinansowanie Unii Europejskiej w ramach programu Horizon 2020

Wstęp

Dane stają się jednym z ważniejszych elementów przewagi konkurencyjnej, jest to stwierdzenie coraz częściej powtarzane i coraz bardziej oczywiste. Firmy w naturalny sposób chcą skorzystać z tego trendu, daje on nadzieję na uzyskanie korzyści biznesowych. Niestety, tylko niektóre próby kończą się sukcesem. Przykład to wykorzystanie uczenia maszynowego i sztucznej inteligencji. Inicjatywy w tych obszarach stają się, obok nowoczesnego raportowania i wizualizacji danych ważne w realizacji kierunku, nie są jednak możliwe bez odpowiedniego przygotowania. Firmy, idąc za ogólnymi trendami, bardzo często kończą efektami zupełnie różnymi od zamierzonych. Realizacja samego procesu uczenia maszynowego wymaga, poza optymalnym kodem modelu, na którym w pierwszej kolejności skupiają się badacze, zapewnienia wielu innych aspektów. Dalej na rysunku przedstawiam, jak widzą to badacze z firmy Google.

Moja książka skierowana jest do osób zainteresowanych tym, w jaki sposób poprowadzić organizację w kierunku optymalnego wykorzystania danych dla celów biznesowych, obejmuje elementy kluczowe w osiąganiu sukcesu. Aspekty te poruszane są w czterech spójnych, uzupełniających się wzajemnie rozdziałach, każdy z nich równie potrzebny, wszystkie tworzą jedną całość. Są to:

— cel biznesowy i przejście do strategii biznesowej, opisywane w rozdziale pierwszym,

— technologia, różne jej aspekty, oraz ułożenie elementów technologicznych w spójną, spełniającą cele biznesowe architekturę, często zaawansowana technologia, obejmująca unikalne algorytmy, przetwarzanie rozproszone, wchodzące w obszary od prostego, ale potrzebnego przetwarzania aż do tematów sztucznej inteligencji,

— dane — temat, od którego wychodzimy, zarówno duże, jak i małe, szybko zmienne i te bardziej statyczne, ustrukturyzowane, i te, bez wyraźnej, na pierwszy rzut oka, struktury, surowe, przetworzone, błędne, referencyjne, mające wiele innych cech,

— ludzie tworzący zespoły, współpracujący w organizacji i między różnymi strukturami.

Rys. 3: Kod machine learningowy pokazany jako część całego ekosystemu danych i infrastruktury.

Książka kierowana jest zarówno do decydentów — osób mających wpływ na działania organizacji i jej strategiczne decyzje, jak i do osób pracujących operacyjnie w różnych procesach związanych z danymi. Kierowana jest do analityków, architektów, projektantów systemowych, badaczy danych (data scientist), managerów, administratorów, użytkowników systemów analitycznych, czyli do bardzo szerokiej grupy osób. Celem książki jest pomoc w dostrzeżeniu elementów, które nie zawsze są łatwe do zauważenia w trakcie normalnej pracy. Te właśnie elementy będą szczególnie istotne w osiąganiu sukcesu na różnych poziomach — na poziomie osobistym, na poziomie projektu, programu oraz całej organizacji.

Tytuł „Chief Data Officer” został wybrany nieprzypadkowo, jest to nowa, wyłaniająca się w wielu firmach rola. Funkcja staje się istotna w strukturach nowoczesnych organizacji, ponieważ obejmuje rozległe spojrzenie na wiele aspektów pracy z danymi. Osoby ją sprawujące, wywodzą się z różnych miejsc i mają różne historie, a rola nadal się kształtuje. Zrealizowane w wielu firmach projekty, programy transformacyjne i zmiany rynkowe pozwalają jednak zdefiniować ją już całkiem wyraźnie. Sprawowanie roli CDO zobowiązuje do ciągłej nauki i poszukiwania najlepszych rozwiązań, dlatego książka ma na celu uzbroić czytelnika w dużą dawkę praktycznej i niezbędnej wiedzy, potrzebnej na tej drodze.

1. Cele biznesowe składające się na strategię

Wizja

Od czego rozpocząć tak ambitne zadanie jak próba pomocy organizacji, by efektywnie oprzeć się na danych?

Niektórzy rozpoczynają od najnowszych technologii, inni od złożonych algorytmów, czasami ważna staje się nowoczesna wizualizacja danych. Proponuję rozpoczęcie każdego działania z danymi w organizacji, niezależnie od skali przedsięwzięcia, czy to w skali niewielkiego zadania, projektu, programu, czy też transformacji z wielkimi ambicjami, od odpowiedzi na proste, ale bardzo mocne pytanie. Pytanie to ma kilka odmian, brzmią one następująco: po co?, dlaczego?, w jakim celu?, co chcemy osiągnąć? Tu inspiracją jest książka „Start with why”[1]. Brak pytań na starcie i brak próby odpowiedzi na nie, może stać się źródłem wielu problemów. Jeśli zabraknie odwagi lub wystarczającej otwartości w zadawaniu pytań na różnych poziomach organizacji, może to skutkować inercją działań, powtarzaniem starych przyzwyczajeń czy też realizacją różnych celów, które nie są faktycznym i optymalnym celem wspólnym. Staje się to wielką przeszkodą we właściwym ukierunkowaniu prac.

Na początkowym etapie działania, zanim lider analityki zajmie się operacyjnymi zadaniami, warto by poznał stawiane mu cele. Winny to być cele biznesowe, mające realne przełożenie na wyniki. Wszystko jedno, czy dotyczą strony kosztów, czy też przychodów, rachunku zysków i strat, warto jednak, aby ich wkład do wyżej zdefiniowanych celów firmy była widoczna. Praktyka wskazuje, że na wczesnym etapie lider analityki rzadko może liczyć na komfort klarownie zdefiniowanych oczekiwań względem zakresu jego pracy. Tę pierwszą przeszkodę w swojej pracy musi rozwiązać sam. Jeszcze bez wielkiego zespołu, który mógłby w tym pomóc. Jest to etap, gdy od CDO wymagane są umiejętności analityczne oraz efektywna komunikacja z decydentami w organizacji. Z jednej strony, na podstawie często szczątkowych informacji, sam powinien znaleźć obszary, w których jest w stanie pomóc, a z drugiej winien być dobrym słuchaczem, aby wykorzystywać pozyskaną wiedzę o potrzebach. Potrzeby typu: podnieść przychody o 20% lub zwiększyć efektywność działań w danym obszarze, są jedynie kierunkami inspirującymi. Za nimi musi pójść zestaw działań zmierzających do ich realizacji. Pamiętajmy, że CDO nigdy nie otrzyma gotowej listy wymaganych kroków, ani od osób, które go zatrudniają ani od swojego zespołu. Na wstępnym etapie sam musi być analitykiem i dociekliwie poszukiwać kierunku, który później przekaże innym do szerokiej realizacji. W dalszej części książki odnoszę się do kompetencji analitycznych. Są one niezbędne nie tylko wśród osób zbierających wymagania projektowe lub bezpośrednio rozmawiających z użytkownikami, są pożądane u większości pracowników komórek analitycznych. Delegowanie tego pierwszego, strategicznego zadania, określenia celu pracy komórki analitycznej na pracowników, może nie być dobrym rozwiązaniem. Zadanie tej rangi bardzo mocno determinuje wszystkie następne kroki organizacji i powinno pozostać własnością i pełną odpowiedzialnością lidera. Oczywiście zawsze wskazana jest pomoc i wsparcie uzyskiwane od innych osób, jednak sytuacja, w której CDO jest właścicielem, osobą definiującą cel i rozliczającą się z jego wykonania, zdecydowanie pomaga w dalszych działaniach. Gdy w ramach poszczególnych projektów trzeba celu bronić, ponownie go definiować, czy też komunikować, może nie być czasu na odwoływanie się do konsultantów, potrzebny jest realny decydent. Warto zainwestować w wiedzę wizjonera. Posiadanie wizji, popartej silnymi fundamentami i identyfikowanie się z nią wpływa niezwykle pozytywnie na sukces przedsięwzięcia. To ważne, z punktu widzenia osoby sprawującej tę rolę, jak też istotne dla zarządu, który poszukuje odpowiedniej osoby. W przypadku, gdy pierwsze, strategiczne zadanie jest delegowane na inne osoby, czy też outsourcingowane do zewnętrznych konsultantów, pojawia się pierwszy alarm, że organizacja prawdopodobnie zmierza w złym kierunku. Oczywiście gorzej jest, gdy na wstępnym etapie rozmowa o celu zostanie zupełnie pominięta lub uznana za opcjonalną. W kolejnym rozdziale przybliżę tę tematykę.

Strategia firmy

Jaki może być cel stawiany CDO? Zdarza się, że za celem departamentu jest wdrożenie nowej technologii, jakiej nie mają inni lub takiej, która daje szansę na realizację pewnych niedostępnych wcześniej funkcji i w technologii postrzegają źródło przewagi konkurencyjnej. Tak postawione zadanie angażuje wiele osób i może oczywiście doprowadzić do pewnych pozytywnych rezultatów; na przykład do tego, że rozwiązane zostaną trudne i najbardziej ambitne problemy związane z samym wdrożeniem wspomnianej technologii. Po takim wyniku okazuje się jednak, że czegoś brakuje — użytkowników i monetyzacji. Z biznesowego punktu widzenia uzyskuje się sporo cennego doświadczenia oraz nową pozycję kosztu w rachunku zysków i strat, jednakże nie ma wówczas pozytywnego przełożenia na biznes.

Kolejna, często spotykana sytuacja, to określenie mglistego kierunku, idei pozyskanej z rynku, konferencji bądź raportu firmy doradczej i towarzysząca mu intuicja, prowadząca do podjęcia decyzji o rozpoczęciu projektu, wykorzystującego dany trend rynkowy. To dobry pierwszy krok, kierunek nadany przez kierownictwo, jednak niewystarczający. Jeśli za tym pierwszym krokiem nie pójdą kolejne, definiujące bardziej precyzyjnie cel (na przykład określenie, jaki proces biznesowy ma zostać zmodyfikowany i po co), wtedy to, co wydarzy się później, będzie wynikiem przypadku i nie gwarantuje żadnej korzyści dla organizacji.

Cel powinien być zainicjowany jak najwyżej. W przypadku braku wyraźnego celu, CDO jest zdecydowanie na etapie jego definicji i nie powinien rozpoczynać innych ważnych działań projektowych do momentu, w którym strategia nie zostanie ostatecznie ustalona. Na tym etapie najważniejszym zadaniem jest poznawanie organizacji i znalezienie okazji biznesowych wykorzystania danych.

Jakie są przykłady poprawnie postawionych celów? Powinny one być spójne z kierunkiem strategicznym firmy. Trudność polega jednak na tym, że często owa koncepcja nie jest wprost deklarowana. Sytuacja, w której strategia jest znana wszystkim, w odpowiedni sposób zakomunikowana i realizowana, to ideał. Takie sytuacje należą do rzadkości. Niezależnie od tego, w jaki sposób strategia jest komunikowana, firma zawsze ma jakiś realizowany kierunek biznesowy. Często jest ona syntezą wielu różnych lokalnych planów, różnych osób i grup, co skutkuje brakiem dobrej koordynacji i może być złą wiadomością dla firmy. Tak więc kierunek komunikowany nie zawsze jest realizowany. Ten rozdźwięk jest pochodną skali działań, dynamiki rynku i lokalnej adaptacji do zmian. Wiele osób współpracujących w firmie, szum komunikacyjny, opóźnienia w przekazywaniu informacji, opór organizacji we wdrażaniu kierunków, tworzenie nowych kierunków i samoistnie powstające sieci społecznościowe, powodują, że między kierunkiem oficjalnym i faktycznym istnieje spora różnica. Jest to naturalna sytuacja, dokładnie tak było, jest i tak będzie, nie zmienią tego innowacje społeczne i technologiczne. Mając świadomość takiego modelu, warto rozpoznawać zarówno deklarowaną strategię, dostępną w oficjalnych dokumentach, publikacjach i prezentacjach, jak też faktyczną, realizowaną, przejawiającą się w decyzjach na wielu poziomach organizacji. Decyzje inwestycyjne i ich unikanie, decyzje projektowe, dotyczące ważnych aspektów organizacji, są przejawami faktycznie realizowanej strategii. Aby z poszczególnych decyzji złożyć szerszy obrazek, niezbędne są otwarte oczy, uszy, kontakty zapewniające dostęp do tego, co się dzieje w organizacji i wokół niej. Dodatkowo, aby określić kierunek, do tego niezbędny jest czas. Dopiero rozpoznanie dynamiki tych poszczególnych sygnałów umożliwia zebranie i stworzenie pełnego obrazu realizowanej w firmie strategii. Rozpoznanie strategii to pierwszy krok do możliwości wpływania na nią i wsparcia jej realizacji tym, co CDO będzie miał do dyspozycji, czyli szeroką gamą instrumentów związanych z danymi i analityką. Dobra identyfikacja strategii deklarowanej, realizowanej i jej dynamiki pozwala wejść w prawdziwą dyskusję na poziomie zarządu i z takiej dyskusji może wyjść pożyteczny rezultat — realny, mierzalny, specyficzny cel do realizacji.

Jakie mogą być przykłady takiego celu? Wymieńmy kilka z nich.

Zwiększenie przychodów.

— Pozyskanie nowych klientów. Algorytmy optymalnie wybierające grupy docelowe nowych klientów.

— Optymalizacja wybieranych kanałów dotarcia do klienta.

— Zwiększenie sprzedaży istniejącym klientom. Algorytmy rekomendujące odpowiednie produkty.

— Optymalizacja polityki cenowej, dostosowanie cen do elastyczności produktów. Optymalizacja cen na podstawie informacji o sprzedaży.

Ograniczenie kosztów.

— Optymalizacja czasu pracy, zastąpienie pracy człowieka algorytmem bazującym na danych, np. szacowanie prac inżynierskich na podstawie możliwych do odtworzenia algorytmów, bez udziału eksperta. Przykładem tego może być wstępna diagnoza stanu zdrowia pacjenta na podstawie zebranych danych.

— Optymalizacja kosztów technologii, infrastruktury. Zastąpienie drogiej technologii tańszą, zastąpienie spowodowane lepszymi parametrami technicznymi.

Inwestycje.

— Pozyskanie danych pozwalających wykonać kolejny krok, np. wdrożenie nowej polityki decyzyjnej.

— Pozyskanie możliwości realizacji planowanych analiz i prac na danych poprzez budowę kompetencji analitycznych, technologicznych.

Raportowanie standardowe na rzecz firmy lub innych instytucji.

— Poprawa jakości raportowanych danych, minimalizacja błędów.

W zależności od tego, jakie cele zostały postawione, inaczej buduje się organizację i architekturę. Ważnymi parametrami są także branża, jej dynamika i konkurencyjność, rynek — inaczej wygląda praca na rynku klientów biznesowych a inaczej na rynku konsumenta indywidualnego. Istotnym wyróżnikiem jest moment w cyklu życia organizacji. Inaczej pracuje się ze start-upem, inaczej z dojrzałym bankiem bądź firmą sprzedaży bezpośredniej lub detalistą. Wiele zależy od portfela produktów organizacji, od dynamiki i charakteru tych produktów, ich charakterystyki kosztowej. Duża liczba wymienionych wymiarów, powoduje, że poruszamy się w szerokiej przestrzeni i trudno znaleźć dwie identyczne firmy. Z tego powodu nie da się wprost przenosić doświadczeń między organizacjami. Nie ma złotego środka, jednak jest sposób pozwalający na uzyskanie pierwszego kroku optymalnej strategii analityki — dobrze zdefiniować cele. Cele, które będą współgrały zarówno z realizowaną, jak i z deklarowaną strategią firmy. To bardzo trudne zadanie, prawie niemożliwe do realizacji z zewnątrz organizacji, przez konsultantów, którzy nie mają szansy na pomiar dynamiki zmian w czasie. Konsultanci są w stanie zrealizować audyt wybranych elementów, który jest fotografią aktualnej sytuacji. Potrafią porównać tę fotografię z albumem fotografii widzianych w innych miejscach — u innych klientów. To interesująca usługa i czasami może być przydatna, jednak oparcie strategii na „jednej fotografii” może być ryzykowne. Niezbędna jest rola CDO w strukturze firmy, osoby o kompetencjach umożliwiających określenie spójnego zestawu celów.

Roadmapa celów

Gdy wiemy już, jaki jest kierunek prowadzonych w firmie działań, zarówno ten deklarowany, jak i faktycznie realizowany, możemy szczegółowo zagłębiać się w potrzebach i wymaganiach poszczególnych części organizacji. Zadanie takie wydaje się być trudną i przerastającą jednego człowieka pracą, przecież organizacja jest rozległa i ma wiele różnych wymagań. Wymagania często sprowadzają się do tego, że różne grupy chciałby używać danych i mieć dane wspierające procesy biznesowe, w których uczestniczą. Zwykle realizuje się takie zadanie, uruchamiając duży projekt analityczny. Na projekt składa się wiele rozmów i badanie potrzeb przedstawicieli poszczególnych pionów, departamentów, sekcji. Po dokładnej analizie uwidaczniają się wyniki, powstaje raport, bądź raporty, które pozwalają na dyskusję, jak dalej postępować.

Niezwykle często zadania dnia codziennego odsuwają wyniki projektu analitycznego na dalszy plan. Osoby, które byłyby w stanie pozytywnie uczestniczyć w dalszych pracach, skupiają się na zadaniach bieżących, a do starannie spisanego raportu organizacja wraca dopiero po dłuższym czasie. Okazuje się wtedy, że niektórych pracowników już nie ma, treść prawdopodobnie się zdezaktualizowała i warto byłoby pracę przeprowadzić od nowa — tym razem lepiej i w inny sposób.

Jak uniknąć prowadzenia analiz, które w żaden sposób nie wpływają na rzeczywistość? Postawmy może pytanie inaczej — jak sprawić, aby wyniki analizy wykorzystać maksymalnie?

Należy skorzystać z tego, co zapewniliśmy sobie w poprzednim rozdziale i prace wstępne wykonać inaczej. Dzięki globalnemu spojrzeniu na cele firmy i kierunki strategiczne, do których powinien także kontrybuować obszar danych, Chief Data Officer na początek wybiera jeden lub kilka obszarów, które uważa za biznesowo najważniejsze. Nie oznacza to, że cała reszta potrzeb zostanie pominięta. Jest to po prostu przyłożenie jedynej dostępnej energii — zasobów firmy, na faktycznie istotne potrzeby. Jeśli podczas realizacji tej operacji, organizacja posiada jeszcze jakieś wolne zasoby, oznacza to, że można pozwolić sobie na prace równoległe, na dwa projekty, może trzy. Przy pewnym poziomie pojawi się jednak granica możliwości, nie wolno jej przekroczyć, bo będzie to oznaczało wejście w strefę, w którą bardzo często wchodzą firmy z wielkim apetytem na rezultaty — w strefę fikcji. Pozornie organizacja realizuje sporo zadań, a faktycznie zespoły robią o wiele mniej, ale sporo czasu spędzają na przykład na nieefektywnym przełączaniu się między zadaniami. Dobór najważniejszych tematów nie jest prosty. CDO postawiony przed takim zadaniem ma do rozwiązania problem bardzo podobny do problemu właściciela produktu w metodyce SCRUM[2]. Musi podjąć decyzję, od którego zakresu rozpocząć prace, gdy firma ma wiele potrzeb i ograniczoną ilość zasobów, zarówno deweloperskich, jak i innych niezbędnych do realizacji projektu. Decyzja nie powinna bazować na jednym kryterium. Aby ją podjąć trafnie, trzeba znać bardzo dobrze otoczenie biznesowe oraz możliwości. W przypadku CDO samym produktem definiowanym, a następnie konsekwentnie rozwijanym, jest najczęściej analityka i optymalne wykorzystanie danych w firmie. Grupa użytkowników jest niezwykle szeroka i obejmuje wiele departamentów, często rozdzielonych i pozbawionych spójności w wielu miejscach. Tak globalnie zdefiniowane środowisko wnosi niezwykle dużo złożoności do każdej decyzji. Może ona być upraszczana i rozwiązana jedynie przez osobę mającą do niej klucz. Kluczem dla CDO jest sprawne poruszanie się w temacie strategii biznesowej firmy.

Aby dobrze współdziałać, przy wyborze pierwszych i następnych kroków, CDO powinien uwzględnić następujące czynniki:

— Co bezpośrednio zyska firma realizując daną potrzebę?

— Jak ważna jest to korzyść z punktu widzenia strategii firmy?

— Czy szacunki korzyści, wynikające z realizacji potrzeby, są wiarygodne?

— Czy realizacja potrzeby jest możliwa technicznie? Czy są dostępne wszystkie niezbędne zasoby do realizacji tej potrzeby? Jeśli nie, to czy w trakcie realizacji zasoby te się pojawią?

— Jakie dodatkowe, nieoczywiste korzyści — być może w innych obszarach — przyniesie realizacja potrzeby?

— Jakie aktywa, zasoby lub opcje pojawią się w firmie po realizacji tej potrzeby? Pytanie dotyczy nie bezpośrednich korzyści, ale wyzwalaczy umożliwiających inne prace, odblokowujących je, a wynikających z realizacji danego zadania.

— Ile innych potrzeb zostanie zrealizowanych po wykonaniu danej pracy?

— Ile innych potrzeb zostanie całościowo lub częściowo zrealizowanych przy lekkiej modyfikacji tego, co planowane jest do zrobienia?

— Czy w przyszłości niezbędne będzie wykonanie podobnej pracy, a można by tego uniknąć po lekkiej modyfikacji zakresu obecnego zadania?

Zadając te oraz wiele innych pytań, badamy zależności, współzależności ewentualnego uzupełniania się i wykluczania planowanych prac. Celem jest także identyfikacja wspólnych lokalnych celów, co przy ograniczonych zasobach pozwoli na osiągnięcie zdecydowanie większego, pozytywnego wpływu na realizację strategii biznesowej. Dzięki wnioskom uzyskanym z odpowiedzi na powyższe pytania, ograniczonymi zasobami można uzyskać o wiele więcej pożytku dla organizacji. Być może poszczególne komórki nie dostaną w stu procentach tego, czego oczekiwały, jednak po całościowej analizie zostanie zrealizowany globalny cel i korzyść dla organizacji będzie o wiele większa niż gdybyśmy zadowolili w pełni jednego interesariusza.

W ten sposób, budujemy pewne wewnętrzne zasoby, które stają się niczym opcje nabywane niskim kosztem. Nabywanie opcji wtedy, gdy są tanie i wykorzystywanie ich, gdy stają się wartościowe, powinno być celem strategów analityki i rozwoju obszarów danych, winni stale o nich pamiętać i, co ważne, przekładać je na taktyczne decyzje. W taki sposób, wychodząc od potrzeb całej firmy, budowana jest optymalnie dopasowana strategia obszaru danych.

Testowanie hipotez

Analityka danych, w odróżnieniu od innych obszarów biznesowych, charakteryzuje się tym, że dostarcza informacji i szczególnie ważnej wiedzy o biznesie. Lider analityki powinien umieć to wykorzystać. Wymieniane w poprzednich rozdziałach źródła informacji o strategii i kierunku rozwoju firmy są niezwykle ważne. Jednak prawdziwą siłą zespołu znającego dane, potrafiącego transformować je w wartościowe informacje, jest możliwość sprawdzania teoretycznych założeń na realnych przykładach. Najprostszym potwierdzeniem teoretycznego założenia jest sprawdzenie go na danych historycznych. Poniżej wymieniam przykładowe twierdzenia dotyczące biznesu, które są oparte głównie na intuicji:

— Nowi klienci kupują więcej niż starzy.

— Czas obsługi klienta w godzinach wieczornych zdecydowanie się wydłuża.

— Kobiety kupują więcej produktów spożywczych, mężczyźni elektronikę.

— Osoby młode wolą obsługę przez aplikację mobilną.

Takie ogólne hipotezy dotyczące biznesu, oparte na intuicji, są w większości przypadków prawdziwe, ale przy zejściu do bardziej szczegółowych hipotez intuicja często nie ma już szans z danymi. Efektywny dostęp do danych historycznych połączony z odpowiednim marginesem ufności pozwala z nich bezpiecznie korzystać. Bez zaufania do danych organizacja słusznie zignoruje pochodzące z nich wnioski i prędzej uwierzy doświadczonemu pracownikowi niż analitykowi, za którym stoją mało wiarygodne dane.

Możliwość stawiania i testowania hipotez potencjalnie może być źródłem lepszych decyzji strategicznych. Jednak doprowadzenie do sytuacji, w której hipotezy są realnie weryfikowane, to raczej wyjątek niż reguła. Niezbędne są odpowiednie ramy do uruchomienia powtarzalnego procesu takiej weryfikacji i wnioskowania bazującego na danych. Ramy, to elementy otoczenia projektowego, od postawienia pytania do etapu analizy danych. Projekt może mieć różne oblicza. Sprawdzają się tu niewielkie projekty analityczne oraz hackatony, zakładające udział osób z różnymi kompetencjami, niezbędnymi do weryfikacji hipotezy biznesowej. Zespół biorący udział w projekcie musi mieć dostęp do danych i przynajmniej jedno istotne pytanie biznesowe oraz sprzyjające warunki, w tym czas na wykonanie tego zadania, co wiąże się z wyłączeniem się z innych obowiązków.

Przykładowy przebieg sprintu analitycznego — jako długość przyjmujemy tydzień, ale można sobie wyobrazić inaczej zaplanowany przebieg prac:

Wymaganie

Posiadając wiedzę o strategii biznesowej, o dynamice organizacji i potencjalnych wewnętrznych korzyściach dla firmy oraz plan dalszych kroków strategicznych analityki, możemy zidentyfikować optymalny obszar, którym warto się zająć. Obszar będzie wybrany z wielu możliwości, ale w najlepszy możliwy sposób. Decyzja o wyborze będzie miała istotny wpływ na budowę przewagi nad firmami, które podchodzą do wszystkich prac jednocześnie, bądź też decydują się rozpoczynać od obszarów nie rokujących biznesowo. Co jednak zrobić, aby przewaga ta stała się realna? Jak optymalnie kontynuować rozpoczęte działania? Należy skupić się i jak najdokładniej odczytać wymagania wybranego obszaru i znaleźć jak najszersze zastosowanie dla wdrażanych produktów.

Co to w praktyce oznacza? Określmy kto jest odpowiedzialny za zbieranie wymagań wybranego obszaru i jakie kompetencje powinna mieć taka osoba? Umiejętność prowadzenia analizy biznesowej to główna kompetencja osób pracujących z danymi. Pełną odpowiedź, dotyczącą kompetencji wykorzystywanych do różnych ról, niezbędnych przy budowaniu organizacji opartej o dane, znajdziemy w pozostałych częściach tej książki. Niezależnie od tego czy o owych wymaganiach będzie rozmawiał z partnerem z innej części firmy sam CDO, czy rozmowę kontynuował właściciel jednego z produktów, czy też wyznaczony analityk biznesowy bądź inny członek zespołu, każdy z nich powinien, niezależnie od obszaru i poziomu szczegółowości, posługiwać się warsztatem pracy analityka biznesowego.

Jakie najważniejsze założenia winny przyświecać działaniom takiej osoby? Pierwszym, możliwe, że najważniejszym, jest umiejętność zadawania dobrych pytań. Pozwolą one na rozpoznanie faktycznych potrzeb związanych z danymi, nie należy pytać wyłącznie o sprawy techniczne ani same dane. Analityk powinien skupiać się na problemach, potrzebach i procesach biznesowych, w których pracuje dana osoba bądź komórka organizacyjna. Pracownicy, których wymagania i potrzeby są badane, posługują się pojęciami sobie znanymi, składającymi się na specyficzny język biznesowy, obowiązujący i znany w ich otoczeniu. Wykorzystywane nazewnictwo różni się w zależności od branży, różni się między firmami z tej samej branży, a nawet między poszczególnymi departamentami. Osoba opowiadająca o procesach, w których pracuje, nie zawsze jest w stanie zidentyfikować miejsce, w którym można osiągnąć poprawę, nie ma także wiedzy, jakimi środkami dysponuje firma, aby jej pomóc. W tym miejscu muszą spotkać się dwa punkty widzenia — punkt widzenia osoby znającej swoją rolę i sposób wykonywania pracy, i analityka, który zada pytania i co ważne, wysłucha odpowiedzi. Dla analityka to materiał do skatalogowania, ale też źródło informacji do poszukiwania rozwiązania biznesowego. Rozwiązania, czyli takiego scenariusza, który jest możliwy technicznie do zrealizowania, ma sensowny, akceptowalny poziom kosztów, nie stoi w sprzeczności z innymi technicznymi działaniami i buduje wartość, czyli tworząc go, organizacja nabywa strategiczną opcję w dobrej cenie — aspekt, o którym mówiliśmy wcześniej.

Wymieniłem sporo warunków niezbędnych do pracy analityka. Czy możliwe jest, aby jedna osoba posiadała tak szerokie kompetencje? Czy istnieją osoby jednocześnie wyciągające wnioski, analizujące, optymalizujące rozwiązanie a przy tym wnikliwie rozmawiające z odbiorcą? Czy istnieją osoby, będące w stanie prowadzić taki dialog i jednocześnie poszukiwać rozwiązań? Na pewno nie jest to klasyczny analityk biznesowy, którego zadaniem jest (tak, jak często jest to widziane w projektach) jedynie wysłuchać, uporządkować i zapisać potrzebę, a następnie przekazać ją innej osobie. Dając więcej możliwości i uzbrajając tę osobę w o wiele więcej pełnomocnictw, oddalamy się od starego, kaskadowego modelu pracy, ograniczającego rolę analityka do osoby perfekcyjnie zbierającej wymagania. Zamiast tego, dajemy jej o wiele większe możliwości i inną perspektywę pracy.

Pamiętajmy, że analiza biznesowa według proponowanej tu wizji, to jedynie kompetencja bazowa, podobnie jak znajomość języka obcego, stanowiąca podstawę do której komponowane powinny być inne umiejętności. W optymalnej sytuacji, wielu pracowników analityki, kontaktując się ze swoimi odbiorcami i bazując na informacjach od nich, budują na odpowiednich dla siebie poziomach, w przypisanych im zakresach działań, wizje rozwoju działań. Następnie, wizje te podlegają ustalonym priorytetom, odpowiedniemu uszeregowaniu i wybrane elementy są w odpowiednim momencie realizowane. Nie oznacza to, że będą realizowane od razu i w stu procentach. W wyniku kolekcji wymagań, powstaje lista, która jest wstępnie posortowana w odniesieniu do ważności oraz ułożona pod kątem złożoności realizacji i zależności między zadaniami. Wiele aspektów, które ujawnią się później i mogą wpływać na planowane prace spowoduje, że po kolejnej rozmowie z biznesem lista potrzeb będzie ponownie modyfikowana. To całkiem naturalna sytuacja. Zmiany stale będą nam towarzyszyły. Tego muszą być świadomi także nasi rozmówcy. O tym, jak do tego doprowadzić, będzie mowa w rozdziale dotyczącym współpracy. Na razie przyjmijmy, że wszystkie strony prac kontraktują takie właśnie warunki współpracy — godzenia się na modyfikacje. Na etapie realizacji może się okazać, że niektóre punkty wymagań realizowane są przez zupełnie inne zespoły niż te, które o nich rozmawiały. To także normalna sytuacja, świadcząca o tym, że poszczególne zakresy prac będą przekazywane do zespołów pracujących nad elementami architektury, do których dane wymagania pasują. Nie byłoby korzystne, gdyby osoba dowiadująca się o potrzebie, stawała się automatycznie właścicielem danego zadania bez uwzględniania innych aspektów organizacji pracy zespołów.

Gdy dyskutujemy o potrzebach z rozmówcą, naturalnie pojawia się oczekiwanie, czy też pytanie, które brzmi: na kiedy będzie TO gotowe? W jaki sposób rozmawiać, aby nie przesadzić z oczekiwaniami i nie doprowadzić do zniechęcenia naszych rozmówców? Sposobem jest otwartość w stosunku do organizacji, polegająca na tym, że wszystko, co jest realizowane w temacie danych i związanych z danymi prac, jest jawne i transparentne. Może okazać się, że niektóre wymagania są mało istotne. Wtedy trafiają bardzo nisko na listę zadań danego zespołu i nie powinno to być tajemnicą. Uzasadnienie takich decyzji musi być także jawne i otwarcie komunikowane wraz z całościowym planem prac jako ich element, a nie w oderwaniu od innych zadań. To naturalny sposób pokazania, dlaczego dany punkt jest ważny, a inne, mniej istotne, mogą być zrealizowane później lub wcale. Dyskusja o datach dla poszczególnych, wyrywkowo wybranych funkcjonalności, bez pokazania większego obrazka, niezależnie od tego, czy tym większym obrazkiem jest roadmapa pojedynczego produktu czy też cała roadmapa prac, jest pułapką i nie polecam wchodzenia na tę ścieżkę. Otwartość backlogu pokazuje odbiorcom jeszcze inną rzecz — uzyskują oni informację o pracach, które są planowane dla innych użytkowników, mogą zaplanować ich wykorzystanie dla siebie, o ile uznają je za przydatne. Elementem otwartości jest także rozmowa o wybranych aspektach technicznych. Rozsądne uświadamianie odbiorców biznesowych o złożoności prac, pozwala uzasadniać wiele decyzji biznesowych. Aspekty, które poddają się krytyce, wymagają ponownego sprawdzenia i rewizji planów. Przekazanie wiedzy o zależnościach technicznych i konsekwencjach technicznych, o różnych sposobach realizacji potrzeb i o ich konsekwencjach, pozwala uniknąć wchodzenia w dług technologiczny.

Wymienione aspekty to elementy rozmowy z użytkownikami na temat potrzeb i sposobu ich realizacji. Gdy połączymy taką rozmowę z efektywną współpracą projektową, zacznie się tworzyć organizacja współpracująca, a nie walcząca o zasoby i kierunek działań. Skupimy się na tym w dalszych rozdziałach. W organizacji takiej mogą zanikać granice między użytkownikami a deweloperami, ponieważ obie strony będą wymieniały się wiedzą o rozwijanych produktach i o celach, które im przyświecają. W kolejnym rozdziale pokażemy, na jakich elementach warto się skupić, aby widzieć postęp strategiczny w kluczowych obszarach analityki.

Wsparcie decyzji

W poprzednim rozdziale krążyliśmy wokół wymagań, zależności między nimi i innymi czynnikami, wpływającymi na odpowiednie, strategiczne wybory obszarów, którymi należy się zajmować. Dalej zajęliśmy się analizą potrzeb, przekładającą się w konsekwencji na określenie zakresu prac, związanych z rozwojem technologii, w tym także tych łączących się z analityką danych i z zarządzaniem danymi. Działania te są pewną bazą strategiczną, kierunkiem dla kroków, jakie powinny zostać podjęte, aby strategicznie oprzeć się na danych.

Należy zwrócić szczególną uwagę na to, do czego zostaną wykorzystane efekty podejmowanych przez nas prac. Niezależnie, jaką postać będą miały te produkty (a w dalszych częściach przedstawię ich sporą różnorodność), powinny mieć one wspólną cechę — służyć do podejmowania decyzji. Decyzje mogą dotyczyć konkretnej akcji podejmowanej w firmie albo szeregu różnych sytuacji. Mogą wspierać jeden proces biznesowy i mieć wąski zakres, ale mogą także być materiałem pomocnym do określenia kierunku strategicznego, na który składa się cały zestaw działań. Akcje, następujące po decyzjach biznesowych, zwykle mają możliwy do pomiaru efekt. Mogą wpływać na sprzedaż, koszty wewnętrzne, czy też na efektywność komunikacji, przez co realizują określone cele biznesowe.

Aby efektywnie wspierać decyzje, należy na etapie analizy zidentyfikować zależność pomiędzy podejmowaną decyzją a biznesowym efektem, wyrażanym liczbowo. Wymierna korzyść ma znaczenie, ważne jest także, jak często proces decyzyjny jest powtarzany. Ekstremalnym przypadkiem jest proces decyzji — czy warto wyświetlić reklamę czy też nie, gdy konsument zagląda na stronę internetową. Taka decyzja może być podejmowana automatycznie, setki tysięcy razy na sekundę w ramach platform programatycznych do marketingu cyfrowego. Przykładem z przeciwnego bieguna jest strategiczna decyzja o budżecie przeznaczanym na działania marketingowe w danym miesiącu, w danym kanale komunikacyjnym. Decyzja o wyborze kierunku i wykluczeniu innych tendencji może zostać podjęta, gdy bazujemy na całym zestawie analiz, przygotowanych, przetworzonych, wyczyszczonych, modelowanych zgodnie z najlepszą wiedzą biznesową. Tego typu proces, chociaż występuje z zupełnie inną częstotliwością niż poprzedni przykład, może być realizowany zarówno w oparciu o intuicję, jak i o dane. Nie warto rezygnować ani z intuicji, ani z danych, oba obszary powinny się wzajemnie uzupełniać, dochodzimy wtedy do niezwykle wartościowej synergii i w takiej sytuacji wykorzystanie danych daje niezwykle dużo pożytku organizacji. Przedstawiam spektrum decyzji w graficzny sposób.

Rys. Rodzaje decyzji podejmowanych w firmie dla horyzontu operacyjnego — lewa kolumna i horyzontu strategicznego — prawa kolumna.

Jeśli wymaganie, które w ramach analizy zostało zidentyfikowane przez analityka lub inną osobę zaangażowaną w prace i nie mieści się w powyższej tabeli, to istnieje podejrzenie, że będzie to działanie, które nie będzie miało wielkiego wpływu na decyzje podejmowane w firmie. Warto spojrzeć bardziej przenikliwie i zastanowić się, czy w dłuższej perspektywie, realizacja takiej potrzeby nie zbuduje opcji, które mogłyby zostać w późniejszym czasie wykorzystane. Jeśli nie znajdziemy takich możliwości, to należy z prac rezygnować.

Podsumowując, jeśli za pracami związanymi z danymi nie pojawia się zwiększenie jakości decyzji, rezultatem może być poprawa efektywności procesów, czyli na przykład ułatwienia w pracy czy też automatyzacja. W zależności od procesu, który jest automatyzowany, powstaje pewna wartość dla firmy. Wróćmy jednak do wsparcia decyzji. Aby automatyzować elementy decyzyjne, bardzo często nie można obyć się bez sprzężenia zwrotnego, oddziałującego między efektami akcji a automatycznymi decyzjmi. Mając takie dane, możemy szukać zależności i reguł optymalizujących biznesową funkcję celu. Jest to klasyka z teorii sterowania, wykorzystywana w automatycznych procesach technologicznych. Tym razem chcemy tę teorię wykorzystać w procesach biznesowych.

Rys. 4: Sposób wykorzystania teorii sterowania obiektem do procesu poszukiwania optymalnego modelu decyzyjnego.

Rysunek 4 pokazuje schemat wsparcia decyzji i oparcia się na ich efektach. Dzięki sprzężeniu zwrotnemu nie ma potrzeby przyjmowania wielu założeń z góry, ale, aby uzyskać taki idealny przebieg, niezbędne są wszystkie elementy opisywane w tej książce. Każda z linii przepływu danych to automatyczne zasilanie danymi. Pozyskanie danych surowych, wyłonienie z nich zmiennych, opisujących obiekt decyzyjny w innych wymiarach następuje automatycznie. Po tych etapach odbywa się poszukiwanie reguły decyzyjnej, opartej na wcześniej utworzonych cechach, czyli zmiennych będących przetworzonymi danymi źródłowymi. Gdy decyzja zostanie wygenerowana, następuje zbieranie informacji o tym, czy faktycznie została ona wdrożona w życie i jaki efekt spowodowała. Schemat obejmuje udział technologii do przetwarzania, przechowywania danych ale także do poszukiwania prawidłowości występujących w tych danych. Niezbędne jest stworzenie współpracującego i ukierunkowanego w swych pracach zespołu, pokrywającego wiele potrzebnych kompetencji. Dane z wielu przebiegów takiego procesu są kluczowe do wytrenowania reguły decyzyjnej. Na początku może ona być generyczna i przypadkowa. Po wielu przebiegach, algorytm poszukujący lepszej reguły, dostosowuje swą politykę decyzyjną do tych danych i w ten sposób nasz automatyczny układ adaptuje się do rzeczywistości. Nawet bez wstępnych założeń możemy optymalizować ten proces. Umożliwia nam to teoria sterowania wykorzystana w analityce na danych — w uczeniu maszynowym.

Prace badawcze i antycypacja

W poprzednich rozdziałach skupiliśmy się na jak najlepszym odczytaniu potrzeb firmy, optymalnym doborze kolejności wdrażanych funkcjonalności i tym, jak najlepiej wysłuchać potrzeby. Podkreślałem też ważne miejsce dla optymalizacji decyzji w ważnych biznesowo obszarach. Jest to niezwykle ważna droga, od wysokiego poziomu ogólności do operacyjnych decyzji, realnie wpływających na biznesową funkcję celu. Takie złożone postępowanie jest reakcją na to, w którą stronę zamierza iść organizacja i realizacją kierunku. Nie zawsze wykonanie opisanej ścieżki doprowadzi do ustalenia najlepszego z możliwych działań. Powody tego mogą być różne. Jednym z nich jest to, że jest to jedynie podejście reaktywne. Oczywiście reaktywność będzie zrealizowana w pełni profesjonalnie i niewiele będzie można jej zarzucić. Może jednak nie być wystarczająca, aby wygrać z konkurencją.

Aby dobrze zrealizowane, podejście będące wprost odpowiedzią na wymagania biznesu, uzupełnić brakującym elementem, należy zacząć przewidywać rozwój rynku. Różne osoby, zajmujące się swymi specjalnościami, powinny zastanowić się, jaka przyszłość czeka poszczególne aspekty ich pracy i jak będzie to wpływało na biznes. Nikt inny lepiej tego nie zrobi. Takie podejście to już bardziej sztuka niż rzemiosło i wymaga kreatywności oraz wielkiej ilości bieżących informacji o rozwoju rynku, technologii. To „gra w antycypację”. Głównym jej celem jest wyprzedzenie wydarzeń w sposób analogiczny do tego, w jaki szachista przewiduje najbliższe ruchy przeciwnika, a do powstałych scenariuszy dopasowuje swoje decyzje. Taki sposób myślenia, połączony z budową scenariuszy, jest podstawą do podejmowania decyzji wojennych w sztabach i jest codziennością strategów i wywiadów. Z charakteru pracy tych grup wywodzi się nazwa Business Intelligence, aktualnie kojarzona już głównie z analityką rozumianą technicznie, nie zawsze analityka, która ma prowadzić do zwycięstwa w wojnie. Zastanówmy się, które wymiary warto w taki sposób analizować i jak do takiej analizy podejść?

Produkty

Poszukiwanie nowych produktów wewnętrznych, koncepcji na nie i pomysłów na nowy rodzaj wsparcia biznesu należy prowadzić regularnie. Pomocne jest robienie regularnego przeglądu rynku, konkurencji i dostawców. Do tego celu przydatne są konferencje, sieć kontaktów, artykuły, czy dostęp do serwisów specjalizujących się w publikowaniu nowinek rynkowych. Świadomy celów i możliwości organizacji analityk potrafi interpretować i wykorzystywać taki strumień informacji, jest w stanie efektywnie pozyskiwać pomysły i sposoby często sprawdzone przez innych i wpływać na realizację kolejnych celów. Właśnie badanie otoczenia rynkowego może w ciekawy sposób uzupełnić roadmapę o starannie wybrane możliwości pojawiające się na rynku. Poniżej podaję przykłady pytań, które należy sobie zadawać. Powinny być one pomocne przy takich przeglądach.

— Jakie produkty analityczne są możliwe do realizacji w ramach posiadanych warunków technicznych?

— Jakiego rodzaju modele decyzyjne są prezentowane przez dostawców?

— Jakiego rodzaju modele decyzyjne realizowane są w firmach konkurencyjnych?

— Jakie pomysły z publikacji mogą zostać wykorzystane do analizy dostępnych w firmie danych?

Dane

Podobnie należy regularnie zadawać sobie pytania dotyczące danych. Skupiają się one wokół pytania, jakich nowych danych, oprócz obecnie posiadanych, potrzebujemy? Poniżej przykładowe wskazówki.

— Jakie kroki należy przedsięwziąć, aby pozyskać te dane?

— Jaką wartość uzyska firma, gdy będzie miała te dane? Czy poprawi się jakość tworzonych modeli decyzyjnych? Czy jest miara pokazująca tę poprawę?

— Czy pojawią się nowe miary lub wymiary w raportach? Jakie decyzje zostaną umożliwione po tym rozszerzeniu?

— Czy możliwa jest poprawa świeżości danych? Czy w procesach ładujących nie znajdują się elementy opóźniające? Czy dostawcy mogą przekazywać dane w innym trybie? Co dzięki temu zyskamy? Jakie koszty się z tym wiążą?

— Czy jesteśmy w stanie łączyć dane z różnych źródeł, od różnych dostawców, z różnych systemów? Czy możliwe technicznie jest dodanie kluczy pozwalających łączyć dane w źródłach pozyskania danych? Z jakimi kosztami się to może wiązać? Czy jest wola po stronie dostawców, aby udostępnić takie informacje? Jakiego rodzaju kosztu spodziewa się dostawca za wzbogacenie danych?

Technologia i architektura

— Jakie nowe technologie pojawiły się w wybranych gałęziach oprogramowania opensource?

— Jaki poziom dojrzałości reprezentują?

— Czy to dopiero pomysł, czy też są wnioski z testów lub z wykorzystania produkcyjnego?

— Jakie modyfikacje oprogramowania proponują dostawcy komercyjni?

— W jaki sposób zmianom ulega polityka licencyjna? Czy zmiany wpływają na sposób wykorzystania oprogramowania w firmie?

— Co biznesowo daje użycie nowej wersji oprogramowania lub nowego modułu? Jak wpłynie to na cele biznesowe? Jak wpłynie to na koszty przetwarzania danych, ergonomię, koszty utrzymania, wykorzystanie infrastruktury?

— Jak wpłynie to na łatwość integracji z pozostałymi elementami technicznymi w firmie? Czy wymaga specjalistycznej wiedzy i czy taka wiedza jest dostępna w zespole?

— Czy proces adaptacji pracownika do efektywnego używania lub rozwijanie nowego oprogramowania jest osiągalny?

Taktyka

Wyszliśmy od strategii firmy, rozróżniając deklarowaną od realizowanej. Doszliśmy do tego, że każda firma jakąś strategię realizuje, choćby jej otwarcie nie komunikowała. Omówiliśmy cele biznesowe i analizowaliśmy, jak są one od siebie zależne. Zastanawialiśmy się nad tym, realizacja którego celu i których wymagań pozwala podążać w najbardziej pożądanym biznesowo kierunku.

W tym miejscu chciałbym dodać kolejną, niezwykle ważną kwestię, wpływającą na realizację ustalonej już wstępnie strategii. Każda strategia jest tak dobra, jak taktyka jej realizacji. Cel, bez określenia drogi dotarcia do niego, jest jedynie pięknym, ambitnym marzeniem. W dalszej części książki skupimy się na wszystkich niezbędnych elementach planu taktycznego, po to, aby wysiłek wkładany w utrzymywanie wygrywającej strategii, nie został zmarnowany. Elementy taktyczne, wymieniane w kolejnych rozdziałach muszą być spójnymi częściami całego planu, równie ważnymi, jak same cele biznesowe organizacji. Będą nimi: aspekt projektowy, czyli określenie jak się efektywnie zorganizować w większej grupie osób, aspekt techniczny — w jaki sposób zarządzić architekturą i technologią, i aspekt związany z danymi, ponieważ to one są naszym najważniejszym surowcem, z niego budujemy wartościowe rozwiązania.

Narzędziem spinającym plany strategiczne z realiami następujących po sobie dni, tygodni i miesięcy jest metodyka projektowa. W tym miejscu chciałbym się skupić na połączeniu wysokopoziomowych celów z celami podzielonymi na mniejsze elementy oraz z harmonogramem prac, które należy wykonać w ramach tychże mniejszych elementów. W metodach AGILE naturalnym łącznikiem między wymienionymi poziomami są właściciele produktów. Niezbędny jest wcześniejszy podział całości obszaru (na który chcemy oddziaływać naszą strategią), na mniejsze obszary odpowiedzialności właścicieli produktów. Podział nie może być przypadkowy. Powinien uwzględniać funkcje poszczególnych produktów oraz ich zależności architektoniczne i biznesowe — ten aspekt będzie dokładniej poruszany w części dotyczącej architektury i technologii. Odpowiednie osadzenie w organizacji właściciela produktów otwiera nam dwa kierunki działań. Pierwszy z nich to określanie i aktualizowanie celów dla swojego produktu, drugi to ciągłe pilnowanie realizacji działań w ramach swojego produktu. Pomiędzy tymi dwoma obszarami działań musi być spójność i to ona będzie dawała faktyczne połączenie celów strategicznych z celami produktu i realizowanymi zadaniami. W kolejnych etapach należy rozwinąć współpracę między właścicielami produktów, mającą na celu aktualizację granic, zależności i koordynację prac zależnych od siebie. Nie powinno się to dziać jedynie w wyjątkowych sytuacjach, dobrze by stało się częścią standardowego procesu planowania prowadzonego na kilku poziomach. Najniższym jest poziom zespołu scrumowego, rozwijającego dany produkt. Wyższym będzie poziom taktycznej współpracy właścicieli produktów, zaś najwyższy to poziom strategii i celów firmy. Tak ułożone procesy powodują, że CDO może adaptacyjnie dojść wraz z organizacją do przełożenia wybranych kierunków strategicznych na faktycznie realizowane prace. Roadmapa składa się z sumy działań w ramach poszczególnych produktów, powinna obejmować cały horyzont jego wpływu i działania, które będą odpowiednio angażowały współpracujące z nim inne części organizacji. Należy ją regularnie aktualizować, by była żywa i prawdziwa. Nie ma to być plan teoretyczny, ale winien oddawać prawdziwe zmiany w taktycznych planach zespołów. Jak dojść do takiej sytuacji? O tym w kolejnych częściach książki.

[1] Książka: Start with why, Simon Sinek

[2] Więcej na temat organizowania projektów będzie w kolejnych rozdziałach książki, wtedy też wskażemy niezwykłą ważność metod agile w analityce danych.

2. Dane układające się w procesy

Rola Chief Data Officera w głównej mierze dotyczy danych. W tym rozdziale dotkniemy tematu danych. Skąd się biorą, co się z nimi dzieje, jak i w jakiej formie są przechowywane, czym są dane o danych, jak stworzyć całościową strategię pozyskiwania i przetwarzania danych? To tematy godne zastanowienia. Wchodzimy tu dosyć głęboko w poszczególne zagadnienia, mimo to każde z nich jest oddzielną dziedziną i z powodzeniem może być tematem oddzielnej książki. Na rynku są dostawcy specjalizujący się w poszczególnych zagadnieniach. Tutaj celem jest przedstawienie przekrojowe, czym są dane i jaką rolę odgrywają w całości przedstawianej koncepcji.

Podstawowy proces biznesowy

Rozpoczniemy od nietypowego miejsca — od procesu biznesowego. Proces biznesowy jest to seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu. Proces ów możemy przedstawić za pomocą przykładowego schematu widocznego na Rysunku 5.

Rys. 5: Schematycznie pokazany proces biznesowy

Na całą działalność biznesową organizacji składa się wiele procesów. Nawet firma, która ich nie zdefiniowała, funkcjonuje według mechanizmów obecnych w świadomości jej pracowników. Zestaw kilku współdziałających komórek organizacyjnych, aby efektywnie współpracować musi posługiwać się spójnym modelem pojęciowym. Dzięki takiemu modelowi procesy przebiegające na styku między departamentami mogą sprawnie funkcjonować.

Rys. 6: Przykładowy model pojęciowy wspierający procesy planowania produkcji.

Procesy biznesowe działają w wielu departamentach, uczestniczą w nich dostawcy, partnerzy i klienci. W trakcie normalnego działania procesów, w systemach je wspierających odkładają się dane, które opisują poszczególne działania, zmieniające się stany i transakcje, które miały miejsce. To podstawowe zadanie wielu systemów wspierających działanie przedsiębiorstwa, dużej firmy, start-upu, jak i średniej organizacji. W sytuacjach, w których procesy nie były wspierane systemowo, informacje o nich zapisywano w zeszytach i notatnikach. Procesy bez wsparcia IT w dzisiejszych czasach często posiłkują się notatnikami w postaci przesyłanych arkuszy Excel. To jest sytuacja niewiele różniąca się od tej sprzed wynalezienia komputera. W dojrzałych firmach konsekwentnie zastępowana jest podejściem systemowym. Tak więc dzięki digitalizacji obsługi procesów, z punktu widzenia konsumentów danych, mamy już świadomość, gdzie dane powstają. Dzieje się to blisko procesów biznesowych, w obsługujących je systemach i platformach.

Rozwój systemów IT ciągle postępuje. Od wielu platform wymaga się obecnie, aby były elastycznie skalowalne, czyli aby obsługiwały w razie potrzeby nawet miliony klientów, użytkowników, miliardy zdarzeń generowanych na styku między użytkownikami a firmą. Wymaga się aby pracowały na różnych urządzeniach (np. aplikacja na telefon komórkowy, czujnik zainstalowany w samochodach i tym podobne). Systemy, do tej pory obsługujące transakcje, charakteryzujące się niewielką ilością danych, musiały wyewoluować do takiej postaci, aby dostosować się do wielkiego strumienia zdarzeń i danych. Dzięki odpowiedniej architekturze są one w stanie je obsługiwać i są w stanie operować na strumieniu danych.

Platformy operacyjne generują różne rodzaje danych. Niektóre są ich producentami, inne z kolei pełnią rolę pomocniczą i jedynie przetwarzają dane uzyskane poprzez odpowiednie interfejsy. Każda z platform ma przypisane odpowiednie role tworzenia, przechowywania i przetwarzania odpowiednich klas danych. Gdybyśmy mieli wiele miejsc odpowiedzialnych za przechowywanie tych samych, podstawowych danych klienta, nie wiedzielibyśmy, które ze źródeł zawiera prawdziwą wartość w przypadku różnic. Tak więc odpowiednie zaprojektowanie systemów transakcyjnych, z jasnym podziałem na źródła główne (zwane także z języka angielskiego źródłami typu master) poszczególnych informacji i źródła posiadające jedynie synchronizowaną kopię dla własnych celów, znacznie poprawia możliwości analityczne firmy. Problemy z danymi i ich jakością są zaadresowane już na etapie budowy systemu. Idea uporządkowania systemów operacyjnych z perspektywy danych to cała dziedzina wiedzy pod nazwą Master Data Management[1]. Brak klarownych zasad w operacyjnym środowisku IT powoduje, że w wielu miejscach będzie narastał problem z jakością danych. Podejmowane próby rozwiązywania problemu często nie sięgają istoty choroby, tylko ją zaleczają zamiast eliminować. W firmach najczęściej nie ma kompetentnej osoby, której celem jest rozwiązanie tych problemów, niezależnie od tego w którym miejscu kłopot zostanie zdiagnozowany i przy okazji jakiego procesu się ujawni. Optymalną sytuacją jest powołanie roli CDO i dodanie do zakresu jego odpowiedzialności zarówno wykorzystania biznesowego danych, jak również doprowadzenia do sytuacji, w której dane ze wszystkich zidentyfikowanych źródeł zbierane są w postaci o wystarczającej jakości.

Czy lider analityki musi dokładnie znać architekturę budowanych aplikacji? Nie, to nawet nie zawsze jest możliwe. Systemy transakcyjne, niezależnie od tego, czy są proste i obsługujące nieskomplikowany proces biznesowy z niewielką liczbą transakcji, czy też są poważnymi platformami, skalującymi się do milionów użytkowników, klientów czy urządzeń, są dla CDO źródłem ważnych informacji. Lider analityki wraz z zespołem powinien pozyskiwać wiedzę o biznesie i poznawać istotne z punktu widzenia celów biznesowych procesy. Gdy określimy, gdzie znajdują się wartościowe dane, powinniśmy wiedzieć czy mamy do nich legalny dostęp. Jeśli będzie taka potrzeba, trzeba będzie podjąć niezbędne kroki, aby nabyć je od partnerów, pozyskać odpowiednie zgody lub poczynić inne potrzebne działania, dające nam prawne możliwości używania tych danych. To niezwykle ważne, aby nie zatrzymać się na pomysłach na analitykę, tzn. na przypadkach użycia, ale wraz z zespołem krok po kroku także uzyskać dostęp do danych, niezbędnych do ich realizacji. Do tematu źródeł danych wrócimy jeszcze w rozdziale dotyczącym strategii pozyskiwania danych. Tymczasem skupmy się na pewnych aspektach technicznych.

Procesy zasilające dane

W poprzednim rozdziale zajmowaliśmy się systemami transakcyjnymi firmy. Są one podstawowym źródłem danych do analiz. Aby jednak dane pochodzące z nich stały się dostępne dla analityka, należy je z systemów wydobyć. Dlaczego utrudniać sobie życie, transportując dane poza te systemy? Sporym uproszczeniem, często stosowanym, jest analiza danych w miejscu, w którym powstają. Wtedy jednak musimy liczyć się z wieloma ograniczeniami. Po pierwsze dostęp do wąskiego zakresu danych firmy, co powoduje, że nie jesteśmy w stanie zrobić wielu analiz. Po drugie, pobierając duże ilości danych, ryzykujemy zakłócenia działań operacyjnych. Aby uniknąć komplikacji, buduje się automatyczne procesy, ładujące dane z systemów transakcyjnych do systemów analitycznych.

Rysunek 7 przedstawia klasyfikację systemów w firmie z podziałem na trzy grupy. Dwie pierwsze dostarczają dane surowe do grupy systemów analitycznych. Z kolei systemy analityczne służą do automatycznej, bądź półautomatycznej analizy, w wyniku której powstają decyzje, raporty lub oceny punktowe różnych zjawisk (ang: scoring).

Rys. 7: Podział architektoniczny trzech klas systemów — ang.: systems of records, systems of engagements i systems on insights.

Czym są najbardziej surowe i podstawowe dane? Są to elektroniczne ślady zdarzeń, które zaszły w świecie fizycznym, bądź cyfrowym. Bardzo często występują w postaci logów z systemów, wpisów w bazach danych i z punktu widzenia analityki są traktowane jako dane surowe, nieskażone ingerencją osób, procesów i odzwierciedlające w pełni fakty. Gdy jednak bliżej przyjrzymy się procesom powstawania tych danych, dojdziemy do wniosku, że wszystkie dane odkładane w bazach i przestrzeniach elektronicznych są interpretacją rzeczywistości i nie należy traktować ich jak surowych. To założenie jest mniej ważne dla inżyniera budującego proces transportujący dane, będzie jednak istotne dla analityka bądź badacza danych, którego zadaniem jest interpretacja rzeczywistości stojącej za cyfrowym zapisem przebiegu procesów oraz wyciągnięcie z niego odpowiednich wniosków.

Systemy własne firmy nie są jedynym źródłem danych potrzebnych do prowadzenia analiz. Często szczególnie wartościowe informacje są ulokowane poza firmą. Są one dostępne za darmo lub odpłatnie. Zdarza się, że są produktem sprzedawanym przez wyspecjalizowane do tego firmy, a pozyskanie ich wymaga jedynie podłączenia się do stworzonego dla tego celu interfejsu. Pewną kombinacją dwóch wcześniejszych jest uzyskanie danych od dostawcy w modelu usługowym (ang: software as a service lub data as a service). Określenie źródeł danych zewnętrznych, odpowiednie ich skatalogowanie pod kątem ważności biznesowej, kosztu pozyskania i trudności związanej z pozyskaniem, staje się pierwszym strategicznym krokiem prowadzącym do zdobycia danych wykraczających poza systemy własne. Pierwszym krokiem konsekwentnie realizowanej strategii pozyskiwania danych.

Na rysunku 8 pokazano różne klasy źródeł danych, począwszy od własnych (określanych jako dane first party), danych od partnerów (ang.: second party data), kupowanych na rynku (ang.: third party data), jak również dane udostępniane w trybie otwartym[2].

Rys. 8: Schemat źródeł pozyskania danych danych przez firmę z punktu widzenia ekosystemu współpracujących podmiotów.

Wymieniłem wiele typów źródeł danych. Teraz chciałbym przejść od identyfikacji źródeł do pierwszego elementu przenoszącego jednorazowe zadania analityczne do operacyjnego i automatycznie działającego środowiska. Jednym z warunków niezbędnych do takiego przejścia jest regularność zasilania danymi, czyli „proces” zasilający dane.

Procesem nazywamy rozwiązanie transformujące dane ze źródła do miejsca docelowego, charakteryzuje się wieloma cechami. Jest ono:

— regularne (czyli cykliczne, pracujące w trybie wsadowym — ang.: batchowym) lub pracujące w trybie strumieniowym (ciągle),

— automatyczne (czyli uruchamiane bez udziału człowieka, a jedynie pod minimalnym nadzorem administratora),

— odporne na błędy (czyli automatycznie raportujące problemy z danymi i próbujące automatycznie zmitygować problemy występujące po stronie źródła danych),

— odpowiednio skalowalne (czyli dostosowujące się do dynamicznie zmieniających się ilości danych — w przypadku dużych danych niezbędna cecha),

— w razie potrzeby transformujące model danych źródłowych na docelowy.

Tak zdefiniowany i zbudowany proces zasilający staje się wartością nie tylko dla jednej osoby, potrzebującej wyników jego działania, ale także dla innych odbiorców danych. Odbiorcy to osoby, którym udostępnia się dane i oszczędza ich czas oraz procesy automatyczne, dla których dane wejściowe są podstawą działania. Budowanie procesów zasilających w jednolitych standardach, zgodnie z biznesowo ułożoną roadmapą przyczynia się do tworzenia zdrowych fundamentów organizacji która opiera biznes na danych. Dlaczego tak jest? Kolejne elementy odpowiedzi będą się pojawiały w późniejszych rozdziałach.

Metadane

Operacyjnie działające środowisko analityczne — z centralną rolą hurtowni danych — automatycznie działającym zasilaniem danych, automatycznymi procedurami naliczającymi niezbędne agregaty to rzadko kiedy proste, podręcznikowe rozwiązanie. Chociaż prostota powinna być celem, to w złożonych i dojrzałych rozwiązaniach spotykamy się ze sporą złożonością. Składają się na nią dziesiątki tysięcy zbiorów danych, setki raportów i naliczanych modeli decyzyjnych. Z tych powodów, ale też jak największej automatyzacji, potrzebne są standardy architektoniczne. Architekturą będziemy zajmowali się w późniejszych rozdziałach. Teraz jednak dotkniemy kwestii opisu całego środowiska, różnych jego parametrów i zdarzeń, które w nim zaszły w ujednolicony cyfrowy sposób. Opis środowiska jest przechowywany i uaktualniany jako dodatkowe, techniczne zbiory danych zwane metadanymi.

Metadane, dane o danych[3] — strukturalizowane informacje stosowane do opisu zasobów informacji lub obiektów informacji, dostarczające szczegółowych danych, dotyczących atrybutów zasobów lub obiektów informacji. Stosowane są w celu ułatwienia wyszukiwania, identyfikacji, a także zarządzania tymi zasobami.

Pierwszą rolą metadanych jest opis struktury i przedstawienie zawartości środowiska. Są to informacje takie jak opisy, dokumentacje utworzone przez człowieka, jak i aktualizowane automatycznie. Należą do nich:

— informacje o architekturze środowiska i rozwiązaniach,

— dokumentacja projektowa, utrzymaniowa,

— modele danych, struktury tabel, opisy pól, definicje zbiorów danych,

— opisy przepływów danych, opisy transformacji danych, założenia częstotliwości uruchamiania przepływów,

— opis infrastruktury wewnętrznej lub zewnętrznej.

Kolejną rolą metadanych jest wsparcie administrowania środowiskiem. Rola ta jest realizowana poprzez operacyjne utrzymywanie informacji takich jak:

— godziny uruchomienia poszczególnych procesów zasilających i przetwarzających dane,

— specjalne znaczniki w danych pokazujące na poziomie poszczególnych rekordów, które procesy są odpowiedzialne za załadowanie lub przetworzenie wskazanych danych,

— logi przetwarzania z procesów, logi pokazujące dostęp do danych i wykorzystanie danych, zarówno przez użytkowników, jak i przez automatyczne procesy.

Metadane to informacje o środowisku i o jego dynamice. Mają wiele zastosowań, a najważniejsze z nich to:

— utrzymaniowe — pomagają identyfikować codzienne problemy eksploatacyjne występujące w środowisku, dotykające głównie administratorów lub użytkowników,

— wsparcie rozwoju — ponieważ metadane to aktualizowana dokumentacja żywego systemu, to baza wyjściowa dla osób rozwijających środowisko, wykorzystywana do poszukiwania istniejących jego funkcji, co pozwala zredukować niepotrzebny rozwój, gdy pożądane funkcje są już obecne w systemie i dzięki opisowi są one znane nawet osobom, które nie były ich świadome,

— poprawa jakości danych — badanie, z jakiego powodu psują się wskaźniki jakości danych,

— data lineage — szukanie odpowiedzi, skąd biorą się wartości danych używane w analizach i na raportach, metadane są automatycznym uzasadnieniem prezentowanych na analizach wartości danych.

Metadane nie zawierają danych biznesowych i na ich podstawie nie podejmuje się decyzji biznesowych. Pełnią one rolę wspierającą zarówno dla osób z biznesu, jak i dla obsługi technicznej. Aby wyciągać wnioski, należy posługiwać się danymi właściwymi, a metadane traktować jako ewentualną pomoc. Często ich rola jest niewidoczna dla odbiorców informacji biznesowej. Opis charakteru metadanych daje liderowi analityki skrótowy wgląd w to, co drzemie pod silnikiem budowanej przez jego zespoły inżynierskiej konstrukcji. Wydaje się to konieczne, ponieważ CDO jak każdy generał, musi wiedzieć, co robi jego żołnierz, aby pozwolić pracować przy czynnościach, które choć nie zawsze widoczne, mają wielkie znaczenie dla organizacji.

Bazy danych

Po przybliżeniu zagadnienia operacyjnego zasilania danych, na które przeznacza się najwięcej czasu, energii oraz zasobów w departamentach Business Intelligence, zajmiemy się tematem, na który w literaturze opisującej techniczne problemy analityki danych poświęca się o wiele więcej uwagi. Bazy danych — powodem eksploatowania zagadnień związanych z bazami danych jest ich ewolucja, która jest wynikiem skokowego wzrostu ilości przechowywanych danych, potrzebnych do analiz, często nietypowych postaci danych, i niespotykanej wcześniej dynamiki dużych danych. To tematy niezwykle wymagające oraz ciekawe. Wielkość baz i możliwa do obsłużenia ilość danych jest jednym z najczęściej porównywanych parametrów, to ulubiony temat osób zajmujących się analityką big data. Pamiętajmy, że jest to spore uproszczenie ewolucji technologii, która ciągle postępuje.

Baza, przechowująca zbierane dane, potrzebna jest do gromadzenia danych transakcyjnych ale także dla celów analitycznych. W obu przypadkach potrzebujemy spełnienia innych parametrów technicznych, dlatego stosuje się inne technologie. Dla zapewnienia wymagań operacyjnych potrzebne są cechy transakcyjne baz, charakteryzujące się spójnymi operacjami na poszczególnych rekordach klientów bądź innych obiektów biznesowych. Bazy takie mają możliwości skalowania na wielkie liczby równoległych, krótkich operacji. W przypadku analityki ważniejsze jest przetwarzanie wielkich ilości danych po to, aby je agregować, sumować, wyszukiwać według zadanych wzorców. Do tych zastosowań technologicznie podchodzi się w różny sposób. Samym rozwiązaniom oraz różnicom w modelach przechowywanych danych poświęcę więcej uwagi w rozdziale dotyczącym technologii, tutaj skupmy się na samych funkcjach baz danych.

Funkcją architektoniczną baz operacyjnych bardzo często staje się to, iż dla wybranych zbiorów danych zostają bazą podstawową, zwaną też bazą master. Oznacza to, że ich zawartość jest najważniejsza i w przypadku wątpliwości, które źródło ma prawdziwą wartość atrybutu (adresu klienta, salda na rachunku bądź innej informacji), wiadomo, że należy ją odczytywać z bazy master, a nie z innych miejsc, w których dane mogły się znaleźć jedynie roboczo, bez gwarancji poprawności. Takie założenia umożliwiają normalną pracę na danych operacyjnych. Niestety, wiele firm nie działa w ten sposób i dodawanie funkcji operacyjnych odbywa się bez zwracania uwagi na architekturę danych operacyjnych. W szczególności bez zważania na zagadnienia masterowości danych. Takie postępowanie prowadzi do narastania długu technologicznego w obszarze architektury danych. Dług ten, podobnie jak każdy inny dług, wymaga obsługi, spłaty i staje się problemem w funkcjonowaniu firmy. W przypadku danych rachunki płacą ci, którzy muszą się na danych opierać, analizować i podejmować na ich podstawie decyzje operacyjne i strategiczne. Oni z pewnością zauważą utrudnienia w pracy, będące konsekwencją długu architektonicznego. Podsumowując, brak architektury danych operacyjnych powoduje pracę pod presją, podobną do presji wynikającej z zadłużenia.

Przechodząc z obszaru operacji do analityki warto rozpocząć od tego, że obszary owe mają rozłączne cele i nie warto opierać analityki na bezpośrednim dostępnie do baz danych systemów transakcyjnych. Bywa to powodem zakłócenia ich pracy i nie jest polecane ze względu na stabilność operacji firmy. Z tego powodu najczęstszym schematem pracy jest zasilanie się danymi z systemów transakcyjnych po to, aby je wykorzystać analitycznie.

Odseparowanie się od systemów operacyjnych i posiadanie gotowych, często dostosowanych do potrzeb analitycznych danych, to już wystarczające powody, dla których warto mieć specjalne miejsce do stałego ich przechowywania. Kolejnym istotnym powodem budowy bazy analitycznej jest umożliwienie firmie łączenia różnych faktów, istniejących w oderwaniu od siebie w różnych systemach źródłowych — w systemach z firmy, spoza firmy, źródłach płatnych i otwartych. Taka baza będzie gromadziła wszystkie dane, nawet w nadmiarze po to, aby były gotowe do przeprowadzenia znanych już dziś analiz, ale także po to, aby być gotowym na potrzeby, które pojawią się w późniejszym czasie. Wiele potrzeb, ze względu na trudność lub brak możliwości realizacji, nigdy by się nie pojawiła lub nie ujawniła, gdyby nie rozwiązania hurtowni danych zbudowane w firmach. Zebranie i operacyjna integracja danych w jednym miejscu jest czymś, co daje nowe możliwości biznesowe, takie, których nie było wcześniej. To istotna inwestycja firmy, która opiera decyzje biznesowe na danych. Brak takiej inwestycji na wczesnym etapie i przejście od razu do zastosowań data science lub dashboardowych jest błędem, który prowadzi do sporych trudności we wdrażaniu oczekiwanych rozwiązań. Brak z kolei etapu wcześniejszego, czyli dobrego, gruntownego sprawdzenia potrzeb i celów biznesowych spowoduje, że firma zbuduje techniczne rozwiązanie, które nie będzie miało szansy służyć realnym potrzebom biznesowym. Dlatego właśnie naturalna kolejność działań, sugerowana w kolejnych rozdziałach tej książki, ma na celu zapewnienie, iż budowa organizacji na fundamentach danych przebiega optymalnie.

Rys. 9: Schemat przepływu danych w firmie, uwzględniający elementy typowej architektury wykorzystania danych operacyjnych na cele analityki.

Hurtownia danych bądź środowisko integracji danych nie zawsze będzie miało taką samą postać. W rozdziale opisującym różne modele i alternatywne teorie, stojące u podstaw realizacji takich rozwiązań, przedstawione zostaną niektóre ważniejsze różnice w podejściach. Na etapie decydowania, która droga bardziej pasuje do potrzeb danej firmy lub jej części, należy postanowić o konkretnych rozwiązaniach i wtedy dopiero, znając potrzeby biznesowe, poszukiwać doświadczonych konsultantów, którzy pomogą wybrać najlepszą ścieżkę.

Rys. 10: Naturalna i wskazana kolejność głównych zadań przy budowie hurtowni danych, składająca się na iteracyjny cykl rozwoju analityki.

Informacje i wnioski

Posiadanie danych, świeżych, prawdziwych, zebranych z wystarczająco długiego czasu, zawierających historyczne stany niedostępne już w systemach transakcyjnych, dostosowanych do łatwego użycia to ważny etap w budowie organizacji, która chce podejmować decyzje i działania na ich podstawie. Dane te są traktowane jako surowe, niektóre jako przetworzone i dostosowane formą do łatwiejszego użytkowania ich przez analityka. Dane przetworzone są łatwiejsze w użyciu, ale w wyniku przygotowania tracimy niektóre informacje. Z kolei dane surowe nie są skażone interpretacją i traktowane są często jako te bliższe prawdzie. Jeśli jednak zastanowimy się nad pochodzeniem wszystkich rekordów w naszym systemie analitycznym, to zawsze, dla każdego pojedynczego rekordu, na etapie jego tworzenia zachodzi pewien proces interpretacji rzeczywistości. Niezależnie od tego, czy jest to wygenerowany log, pochodzący ze zdarzenia, którego ślad znalazł się w systemie biznesowym, czy jest to transakcja obsługi klienta, system, który jest odpowiedzialny za jego obsługę zawsze zapisuje wybrane przez programistę informacje. Wiedza jest kodowana w określony założeniami sposób i opisuje pewien wycinek rzeczywistości. To właśnie jest jej interpretacją i ograniczeniem. W chwili zapisu informacji w systemie, bezpowrotnie tracimy jakiekolwiek szanse na większą ilość danych opisujących owo zdarzenie. Z upływem czasu nasze szanse na pełniejszy obrazek maleją — więcej danych już nie dostaniemy. Dane, które pozyskaliśmy, mogą zostać stracone, nadpisane, zepsute, zaszumione, poddane ponownej interpretacji ograniczającej prawdę lub zagregowane do jakiegoś wyższego poziomu, przez co w jeszcze większym stopniu stracimy możliwość wnikania w kolejne utracone detale. Warto o takich podstawowych ograniczeniach związanych z informacją pamiętać. Jest to naturalny proces utraty części wiedzy i mimo zwiększającej się liczby czujników zbierających dane, proces ten nadal będzie nam towarzyszył. Osoby, które budują procesy zasilające dane z systemów operacyjnych do analitycznych, także wnoszą swoje ograniczenia do tego świata. Chociaż hurtownie danych modelowane są najczęściej w sposób umożliwiający dotarcie do najbardziej szczegółowych danych i zezwalające na wgląd w stan danych z wybranego momentu w czasie, to w przypadku niektórych źródeł danych procesu opisanego powyżej nie unikniemy.

Rys. 11: Cykl przepływu danych w procesie analitycznym.

Ważnym elementem w tworzeniu ścieżki transformacji danych w informacje jest analityk, który wnosi swoją interpretację biznesową, odrzuca fakty nieistotne, a skupiająca się na wybranych zagadnieniach. Osobą tą jest analityk. Może on efektywnie pracować jedynie wtedy, gdy jest w stanie odtworzyć kontekst biznesowy danych, dlatego też rola badacza danych w dużym stopniu bazuje na znajomości dziedziny biznesowej. Analityk lub badacz danych nie może zajmować się jedynie suchymi liczbami i dopasowywaniem do nich sposobów prezentacji bądź zaawansowanych algorytmów, bo niczego wartościowego nie stworzy. Dane zmieniają się w informacje jedynie po uwzględnieniu odpowiedniego kontekstu biznesowego. Są one interpretacją faktów, które zaszły, bez kontekstu i wyobrażenia sobie realnych sytuacji biznesowych pozostaną niewykorzystane, przez co stają się bezwartościowe. Dopiero po odtworzeniu kontekstu można próbować poszukiwać odpowiedzi na pytania, które trzeba postawić. Dane, jeśli są reprezentatywne i dostępne, odpowiadają na pytania związane z obszarem biznesowym, którego dotyczą. Należy dążyć do takiego stanu, wtedy dopiero inwestycja, związana z pozyskiwaniem danych, edukowaniem różnych osób ma szanse się zwrócić z wielką nawiązką.

Jeśli osiągniemy etap, gdy dane dotyczące wybranej części działalności biznesowej odpowiadają na postawione pytania, ale odpowiedzi nie zawsze są oczywiste, to i tak na podstawie tych odpowiedzi wyciągać pewne wnioski. Możemy oceniać zależności między obszarami, a co za tym idzie podejmować odpowiednie decyzje. Od wyciągnięcia wniosków do podjęcia decyzji prowadzi długa droga, tym bardziej, że analityk znajdujący odpowiedzi w danych i decydenci to inne osoby. Przejście całej ścieżki decyzyjnej może zabrać cenny czas. Są dwie możliwości rozwiązania tego problemu. Pierwsza to przekazanie narzędzi wspierających decyzje jak najbliżej decydentów. W tym celu stosuje się automatyzację narzędzi, uproszczenie technologii i tzw. self-service. Skracana jest ścieżka między danymi odpowiadającymi na pytania a osobami korzystającymi z tych odpowiedzi. Dlatego istotna jest znajomość potrzeb biznesu i procesów biznesowych, by tak dostosować architekturę rozwiązań, aby wsparcie decyzji było obecne w komórkach biznesowych. Niestety w wielu przypadkach procesy analizy danych pozostają nadal niezwykle skomplikowane i mogą być przeprowadzone przez doświadczonych specjalistów, pracujących najczęściej w centralnych jednostkach analitycznych. W takich przypadkach bardzo dobrze sprawdza się inny sposób — zaangażowanie osób z wiedzą biznesową do prac nad systemami wsparcia ich decyzji, czyli dynamiczne tworzenie mieszanych zespołów, dla osiągania konkretnych celów projektowych. W ten sposób uzyskujemy obecność kompetencji technologicznych, znajomość danych i znajomość procesu biznesowego w jednym miejscu.

W zespołach tak zbudowanych powinniśmy obserwować coraz lepsze zrozumienie i synergię różnych umiejętności i wiedzy. W sposób niewidoczny dla zewnętrznego obserwatora kształtuje się (na coraz wyższym poziomie) proces analizy i komunikowania wniosków i hipotez związanych z posiadanymi danymi. Hipotezy nieprawdziwe są weryfikowane i organizacja uczy się.

Jak doprowadzić do sytuacji, w której cały ten proces będzie otwarty dla zewnętrznego obserwatora, szczególnie dla kadry zarządzającej, bądź dla innych zespołów, które chciałyby go odtworzyć? Wymaga to prezentowania historii stojących za decyzjami, rekomendowanymi przez taki interdyscyplinarny zespół. Pokazywanie, co przyczyniło się do decyzji, jakie ścieżki wnioskowania zostały przyjęte, a jakie odrzucone, układa proces w odpowiednie i zrozumiałe ramy. To próba pokazania spraw (oczywistych dla członków zespołu) zrozumiałym językiem. Sukces odnotowywany jest dopiero wtedy, gdy wiedza obecna w techniczno-biznesowym zespole projektowym zostanie w zrozumiały sposób przekazana osobom niezaangażowanym w prace. Wtedy produkt pracy takiego zespołu umożliwi podjęcie korzystnej decyzji biznesowej. Historia stojąca za wnioskami może być prosta, oczywista i łatwa, jednak dojście do niej nie zawsze jest proste. Wnioski raczej nie mają zastosowania w innej firmie, nawet tej samej branży, są one unikalne poprzez unikalną sytuację każdej firmy, dlatego trudne to kopiowania dla konkurencji.

Kto jest właścicielem danych?

Rozpoczęliśmy od procesów biznesowych, których efektem ubocznym albo głównym są dane o przebiegach tychże procesów. Pisałem o szerokim zbiorze metadanych, obejmujących całe spektrum informacji technicznych: o procesach, architekturze, modelach, strukturach, logach. W poprzednich rozdziałach otworzyliśmy temat danych biznesowych, podlegających właściwej analizie, w wyniku której wyciągane są wnioski. Te elementy budują nam perspektywę wokół danych. Pomijamy na razie technologię, którą zajmiemy się o wiele dokładniej w kolejnych rozdziałach.

Skupmy się na osobach potrzebnych do prawidłowego funkcjonowania danych w organizacji. Osoby pełniące różne role, w różnym zakresie przypisane do danych, pracujące w odpowiednim rygorze i w określonych ramach współpracują ze sobą. Aspekt ten jest niezwykle rzadko w wystarczającym stopniu zarządzany w organizacjach. Brak ustalenia podstawowych ról właścicieli, bądź gospodarzy danych powoduje, że w naturalny sposób, tam, gdzie jest to potrzebne, wyłaniają się oni sami. Zbyt małe wsparcie dla tego procesu powoduje trudności w dotarciu do potrzebnych informacji. Rolą CDO jest z jednej strony wykorzystać naturalny proces wyłaniania się ekspertów i właścicieli obszarów danych, a z drugiej strony nie dopuścić do większej niż potrzeba jego instytucjonalizacji. Zbyt duże sformalizowanie mogłoby zaburzyć naturalne, oddolne procesy. Role i odpowiedzialności to ważny aspekt holistycznego zarządzania danymi, zwanego procesem Data Governance. Nie posługuję się tym hasłem, ponieważ w wielu miejscach ma już przyjęte znaczenie i przekaz mógłby zostać odebrany w nieodpowiedni sposób. Przedstawiam najważniejsze elementy Data Governance, rozkładając je na niewielkie, pasujące do siebie i bardziej zrozumiałe elementy. Powróćmy do ról odpowiedzialnych za dane w organizacji bazującej na danych.

Z operacyjnego punktu widzenia musimy powrócić do schematu przedstawiającego cykl życia danych, który był już przedstawiany. Na na rysunku 12 widzimy dodatkowe szczegóły, są nimi obszary danych. Często będą one tożsame z systemami, które je wytwarzają, jednak nie jest to reguła. Może zdarzyć się sytuacja, że jeden obszar danych będzie obsługiwany przez kilka uzupełniających się systemów. W dalszej części mówimy o nich jako o produktach technicznych, rozwijanych w ramach zespołów AGILE. Teraz jednak skupmy się na danych, które są z nich generowane. Lokalny cel jest taki, by systemy generowały poprawne, czyste i świeże dane, które będzie można łączyć, korelować z innymi źródłami w celu dostosowania ich do formy pozwalającej podjąć lepszą decyzję biznesową niż ta podjęta bez tych danych.

Cel jest jasny, jednak nie zawsze łatwy do osiągnięcia. Już na samym początku cyklu możemy natknąć się na podstawowe problemy, takie jak niedostępność danych źródłowych i niewielki priorytet ich generowania w stosunku do innych ważnych funkcji systemu. Dane mogą napływać, jednak w niedostatecznej jakości. Podobnych problemów może pojawiać się więcej. Niewiele różniące się od siebie listy potencjalnych trudności będą obecne w każdym ze zdefiniowanych obszarów danych. Oznacza to, że każdy temat biznesowy, interesujący badacza danych, analityka raportowego u swego źródła, będzie miał wpisane ryzyko różnego rodzaju braków. Warto wiedzieć, że problemy na poziomie danych źródłowych są wystarczającym powodem do skutecznego uniemożliwienia realizacji nawet najprostszej inicjatywy biznesowej opartej na danych.

Rys. 12: Elementy typowej architektury wykorzystania danych operacyjnych na cele analityki wraz z pokazanymi obszarami danych.

Pomysłem chroniącym organizację przed niektórymi czarnymi scenariuszami jest ustalenie odpowiedniego właścicielstwa danych. Na ideę tę składa się nie tylko mianowanie osób, ale także przypisanie im długoterminowych celów związanych z wybranymi obszarami danych; często stanowisko określa się nazwą data steward. Istotne w poszukiwaniu osób do tych ról jest znalezienie w organizacji specjalistów, zajmujących się problemami danego obszaru. Tych, którzy nie mogą wykonywać swojej pracy z powodu słabej jakości danych analitycznych i operacyjnych, nie mogą podejmować decyzji w oparciu o dane z obszaru, ale posiadają wystarczającą wiedzę na jego temat. Tak zmotywowana osoba staje się optymalnym kandydatem na data stewarda obszaru. Rola właściciela obszaru danych nie jest wyłączną funkcją danej osoby w organizacji. Bardzo często sprawdza się jako rola dodawana do innych obowiązków w firmie. Czasami może pokrywać się z obowiązkami właściciela produktu technicznego[4] — systemu stojącego u podstaw danego obszaru danych, ale nie jest to regułą.

Jak doprowadzić do ukształtowania się odpowiedniej struktury współpracy właścicieli danych? Znając zakres działalności biznesowej firmy, miejsca powstawania danych i głównych ich użytkowników, należy na początku wstępnie zidentyfikować obszary danych. Powinny one być rozłączne, nie nachodzić na siebie, nie ma nic gorszego niż nakładające się obszary odpowiedzialności. Oczywiście obszary te będą współzależne, ponieważ taka jest natura danych i biznesu. Między danymi zachodzą relacje i współpraca między właścicielami danych jest niezbędna, jednak podział musi być jak najbardziej klarowny. Powinien wynikać z żywotnych interesów komórek organizacyjnych i dobrze wpisywać się w cele tych komórek. Nie zależy nam tu na rewolucji. Warto podeprzeć się standardami rynkowymi, które dla większości branż są dostępne i pomagają dokonać inicjalnego podziału mapy danych. Podział nie musi być idealny, błędem jest przeznaczanie na to zbyt dużej ilości czasu, nie powinny to być miesiące. Wstępnie ustalony podział winien być przedmiotem rewizji i adaptacji do rzeczywistości. Nawet w tym elemencie i na takim poziomie warto używać podejścia AGILE i dostosowywać się do coraz lepiej poznawanej rzeczywistości[5].

Rys. 13: Przykładowy podział obszarów danych dla firmy telekomunikacyjnej.

Rys. 14: Przykładowy podział obszarów danych dla firmy mediowej.

Gdy już szczęśliwie dojdziemy do podziału obszarów danych i ich liderów, powinniśmy porozmawiać z nimi o celach, jakie chcielibyśmy osiągnąć w ramach swoich części ekosystemu danych. Mogą one dotyczyć aspektów takich, jak wymienione niżej, jednak nie jest to lista obowiązkowa, a raczej lista, którą warto się inspirować. Koncepcje, które nie dotyczą specyfiki obszaru i firmy należy z tej wstępnej listy wykreślić i skupić się na tych właściwych.

Lista potencjalnych problemów i wynikających z nich proponowanych celów działań:

Powyższa tabela pokazuje jak różne cele, wynikające z aktualnych potrzeb biznesowych i bieżących problemów może mieć data steward. Skupiając się na wybranych kierunkach, nie wolno oczywiście zapominać o podstawach, które już działają. Oprócz podejścia reaktywnego, będącego odpowiedzią na to, co firmie doskwiera w danym momencie, niezwykle istotne są nowe pomysły na wykorzystanie danych. Zarówno wykorzystanie danych z wybranego obszaru, jak i łączenia dalekich sobie obszarów jednocześnie i danych jeszcze niedostępnych w firmie. Miejscem na taką współpracę jest plan strategiczny, będący wspólnym dziełem CDO, data stewardów oraz innych niezbędnych osób.

Strategia danych

Gdy zrealizowane zostaną opisane etapy, czyli podział przestrzeni danych na rozłączne obszary, identyfikacja osób planujących w wymienionych wymiarach rozwój obszaru danych i nadanie im oficjalnie takich celów, możemy przystąpić do nieco trudniejszych zadań. Każdy z obszarów będzie inny, pojawią się różne problemy, ale jest to naturalne. Aby ułatwić pracę początkującego właściciela obszaru danych, wymieniam listę pomocniczą zagadnień. Są to tematy warte przemyślenia po to, by łatwiej wykonać wstępny audyt stanu obszaru. Taki audyt będzie traktowany jako podstawa do dalszych działań.

Tabela jest materiałem pomocniczym dla osoby rozpoczynającej pracę w obszarze danych. Wiedza o tym, jakie pytanie zadać, jest istotna. Jeszcze ważniejsze jest wysłuchanie odpowiedzi i na tej podstawie podjęcie dalszych kroków.

Tyle teorii, a jak proces będzie wyglądał w praktyce? Oczywiście nie da się tego przewidzieć. Przejście od najlepszego, analitycznie ułożonego planu do jego realizacji będzie wymagało mniejszej, bądź większej „walki” w organizacji. Nie będzie to walka z osobami, lecz długi proces dostosowujący aktualną kulturę organizacji do strategii oraz adaptację strategii do kultury i potrzeb. Wiele strategicznych planów zatrzymuje się na etapie realizacji, czyli zostają martwymi dokumentami z niepraktycznymi założeniami. Aby uniknąć takiej sytuacji, do etapu ustalania strategii należy jak najwcześniej włączać osoby, od których będzie zależała jej realizacja. Brak kompromisów z wybranymi interesariuszami i rozwiązania, które są dla nich niekorzystne to brak fundamentów dla strategii. W przypadku strategii danych kluczowymi osobami są liderzy obszarów danych. To oni ustalają i uzgadniają cele w swoich obszarach i to oni decydują o zasobach niezbędnych do poczynienia kolejnych kroków. Osoba dobrze rozumiejąca obszar jest najlepszym decydentem.

W strukturze organizacji nad data stewardami pieczę sprawuje CDO. Może wiązać ich bezpośrednia podległość służbowa lub zależność macierzowa, rodzaj zależności ma drugorzędne znaczenie. Ważniejsze jest, aby decydentami były dobrze zidentyfikowane osoby, reprezentujące cele obszaru danych.

Na proces strategicznego planowania danych, w organizacji składa się kilka kroków. Proces taki powinien być uruchomiony we wszystkich obszarach. Ważnym elementem tego procesu jest dostosowywanie się do różnorodności i zmienności. Adaptacja powinna odbywać się na kilku poziomach — operacyjnym, strategicznym i na poziomie jakości działania całego procesu. Podejście iteracyjne, zaczerpnięte z metodyki AGILE w wersji dla procesu skalowanego na wiele zespołów jest sposobem na maksymalizację szans na przenikanie pomysłów strategicznych do realnej pracy organizacji.

Proponuję kolejne kroki działań:

1. Określenie obszarów danych.

2. Identyfikacja najlepszych właścicieli dla wyłonionych obszarów danych.

3. Ustanowienie właścicieli obszarów w swoich rolach i przyjęcie tej roli przez osoby.

4. Określenie aktualnego stanu obszarów danych, identyfikacja największych problemów, identyfikacja mocnych stron.

5. Określenie regularnego trybu pracy właścicieli obszarów danych i wymiana wiedzy.

6. Określenie backlogu zmian, priorytetyzacja potrzeb w skali całej organizacji przez CDO, potwierdzenie tego kierunku przez decydentów, czyli zarząd.

7. Dodanie zakresu prac do odpowiednich zespołów agile’owych. Realizacja zmian w trybie iteracyjnym, we współpracy i w uzgodnieniu z właścicielami produktów, partnerami, współpracownikami i innymi niezbędnymi osobami.

8. Monitoring obszaru, kluczowych wskaźników dotyczących obszaru, wyników prac. Powrót do punktu 6, cykl uaktualniania backlogu zmian.

9. Pętla strategiczna data stewardów. Powrót do punktu 3 lub 4, cykl uaktualniania strategii obszarów danych.

10. Monitoring pracy i ewentualne modyfikacje obszarów danych, właścicieli, zakresów pracy. Pętla managerska CDO.

Aby taka strategia mogła wejść w życie wymaga, oprócz odpowiedniej kultury, także organizacji współpracy projektowej (będzie omawiane dokładniej w rozdziale piątym), oraz wiedzy technicznej i architektonicznej (zajmiemy się tym w rozdziale czwartym).

Rys. 15: Cykle iteracyjne pracy data stewardów.

[1] MDM — Master Data Management, wikipedia: https://en.wikipedia.org/wiki/Master_data_management

[2] Open data

[3] Definicja za wikipedią, https://pl.wikipedia.org/wiki/Metadane

[4] Znaczenie roli product ownera oraz innych ról scrumowych w świecie danych zostanie opisany w kolejnych rozdziałach.

[5] Podejście: done is better than perfect.

3. Elementy tworzące architekturę

Nie jest to książka skupiająca się szczególnie na technologii, modelowaniu danych, czy tworzeniu modeli uczenia maszynowego (ang: machine learning). Nie zamierzam też zagłębiać się zbyt głęboko w tematykę infrastruktury chmury obliczeniowej. Każdy z wymienionych tematów został dogłębnie opisany w innych opracowaniach, do których tu jedynie się odnoszę. Wymienione zagadnienia, pomimo ich złożoności, są niezbędnymi narzędziami nie tylko dla działu IT, ale także dla CDO. Wiedza o tym, która cegiełka jest ważna w danej biznesowej sytuacji jest nieoceniona i pomaga podejmować trafnie decyzje dotyczące kierunku rozwoju analityki. Niezależnie od tego czy w zakresie obowiązków CDO jest rozwój komponentów technologicznych, wraz z szeroko rozumianym środowiskiem analitycznym, czy raczej będzie polegał na współpracy z szefem informatyki[1] w tym zakresie, to wiedza o aspekcie technologii jest niezbędna. Dlaczego? Głównie dlatego, że wiedza ta zdecydowanie poprawi skuteczność planów i działań. Pomoże efektywnie doprowadzać projekty oraz programy transformacyjne do pomyślnego końca.

Czasami CDO wywodzi się z obszaru technologii, wtedy ma w tym wymiarze łatwiej, chociaż sama praca przy systemach nie daje takiej gwarancji. CDO musi pamiętać o aspekcie technologicznym, rozwiązania, na których bazuje analityka są na tyle specyficzne, że niełatwo jest znaleźć szefów informatyki, którzy mając w zakresie działań szerokie spektrum systemów operacyjnych, równie priorytetowo i dogłębnie analizują i obejmują swoim działaniem obszar analityki danych.

W rozdziale tym przechodzimy od najmniejszej cegiełki, którą tutaj definiujemy, do złożonych systemów czy platform. Pokazuję, jak cele biznesowe, zidentyfikowane wcześniej implikują kierunek rozwoju technologii analitycznej w organizacji.

Podstawowa cegiełka

W dziedzinie zarządzania danymi, obróbki danych i uzyskiwania z nich wartości biznesowej nie popełnimy wielkiego błędu, jeśli przyjmiemy, że podstawową cegiełką niosącą wartość dla organizacji jest raport. Raport definiowany przeze mnie jest niezwykle szeroko: jako wynik jednorazowego zapytania na bazie danych, jako analiza z wykorzystaniem wielu źródeł danych, przygotowana przez osobę znającą te źródła. W dalszej kolejności raport może być wynikiem działania prostego lub bardziej złożonego algorytmu, na przykład drzewa decyzyjnego lub sieci neuronowej. Z punktu widzenia formatu raporty mogą się znacznie od siebie różnić. Różnice będą sugerować, że mamy do czynienia z całkiem odmiennymi produktami opartymi na danych. Formaty wyjściowe mogą rozpoczynać się od najprostszych zestawień w postaci tekstowej, z płaską i czytelną strukturą, poprzez tekstowe formaty zagnieżdżone (np. XML[2], json[3]) — są one czytelne zarówno dla człowieka, jak i dla odbiorców automatycznych — czyli dla innych platform lub narzędzi. Formatem wyjściowym dla użytkownika często jest raport zawierający, oprócz założonej przez twórcę struktury danych, także elementy wizualizacyjne, czyli kolory, kształty i optymalną dla użytkownika reprezentację wyników. W ten sposób dochodzimy do dashboardów, które często są utożsamiane z analityką, czy też z tym, co robi organizacja business intelligence w firmie. Docenianie dashboardów jest pozytywnym sygnałem, który może być zauważony w organizacji. Należy jednak pamiętać, że dashboardy nie istnieją w próżni, podobnie jak zaawansowane rozwiązania sztucznej inteligencji nie istnieją bez całej infrastruktury i architektury, która umożliwia im operacyjne działanie. Wypełnienie tej próżni to niełatwe zadanie. Moja książka ma ambicję pomóc w jego wykonaniu.

Przykładowy, płaski plik tekstowy, rozdzielany przecinkami (format csv):

„Month”, „1958”, „1959”, „1960”

„JAN”, 340, 360, 417

„FEB”, 318, 342, 391

„MAR”, 362, 406, 419

„APR”, 348, 396, 461

„MAY”, 363, 420, 472

„JUN”, 435, 472, 535

„JUL”, 491, 548, 622

„AUG”, 505, 559, 606

„SEP”, 404, 463, 508

„OCT”, 359, 407, 461

„NOV”, 310, 362, 390

„DEC”, 337, 405, 432

Przykład pliku json:

{„menu”:

{„id”: „file”, „value”: „File”, „popup”:

{„menuitem”:

[{„value”: „New”, „onclick”: „CreateNewDoc()”},

{„value”: „Open”, „onclick”: „OpenDoc()”},

{„value”: „Close”, „onclick”: „CloseDoc()”}

] } }}

Przykład pliku XML:

<menu id=„file” value=„File”>

<popup>

<menuitem value=„New” onclick=„CreateNewDoc()” />

<menuitem value=„Open” onclick=„OpenDoc()” />

<menuitem value=„Close” onclick=„CloseDoc()” />

</popup> </menu>

Komponenty rozwiązań analitycznych

Przynajmniej kilkukrotnie argumentowałem, że produkty analityczne bazujące na danych nie istnieją w próżni. Produktami takimi są zarówno dashboardy, ale też zestawienia finansowe, w których twórcy mniej atencji przykładają do aspektu wizualinego, a zdecydowanie więcej do jakości prezentowanych liczb. Produktami są także prezentacje, stanowiące syntezę wniosków, wynikających z zaawansowanego modelowania danych. Są nimi także decyzje generowane automatycznie. Na razie, nie próbując łączyć komponentów w rozwiązania, wymieńmy ich jak najwięcej; są jak klocki używane przez architektów do budowy złożonych rozwiązań. Lista nie będzie nigdy pełna. Będzie ona reprezentowała ewoluujący świat technologii analitycznych. Pokazując reprezentatywne przykłady komponentów, mam na celu wyraźne pogrupowanie w klasy oraz wskazanie kierunku ewolucji technologii w obrębie zdefiniowanych klas. Rozpocznijmy od narzędzi zasilających dane.

Narzędzia zasilania danymi

Cel funkcjonowania narzędzi zasilania danymi jest prosty i dobrze określony. Jest nim regularne dostarczanie danych ze źródła lub z wielu źródeł, a przy okazji przetwarzanie struktury lub postaci tych danych do pożądanej formy w miejscu docelowym.

Regularność oznacza tu, że proces dzieje się automatycznie z zadaną częstotliwością (np. codziennie, co minutę, raz na tydzień). Proces może też być uruchamiany w wyniku zajścia jakiejś akcji, na przykład zdarzeniem nadejścia wiadomości, kliknięciem linku przez użytkownika lub innym podobnym. Ta klasa narzędzi to znane na rynku rozwiązania ETL[4], ale także inne ich odmiany wynikające z przestawienia kolejności liter (ELT, ETLT i tym podobne). Kolejność wymienionych trzech liter (E, T, L) mówi o koncepcji przetwarzania danych przyjętej dla użytego narzędzia. Wybór jednej lub innej koncepcji jest wyborem architekta i musi wynikać ze strategii postępowania z danymi.

Rys. 16: Schematyczny proces ETL.

Rys. 17: Schematyczny proces ELT.

Narzędzia zasilające ewoluowały w stronę narzędzi ułatwiających budowę procesów zasilających poprzez udostępnienie wizualnych edytorów przepływów. Kolejne kroki ewolucji to wykorzystanie infrastruktury chmurowej zamiast serwerów kupowanych do własnej serwerowni, oparcie się na mniejszych porcjach danych i częstych przepływach danych zamiast dużych porcji danych, ładowanych w większych odstępach czasu.

Wymienione trendy pozwalają uzyskać zarówno łatwiejszą skalowalność — w wyniku wykorzystania rozwiązań chmurowych, jak i dużą świeżość danych — dzięki zmniejszeniu opóźnień w ładowaniu zdarzeń i zbliżeniu się do przetwarzania strumienia danych zamiast dużych paczek danych. Tak więc już sam trend ukazuje ważne atrybuty big data[5] — szybkość, różnorodność, poprzez wspomnianą skalowalność — wielkość.

Rys. 18: Przykład projektu przepływu ETL utworzonego w narzędziu służącym do tego.

Rozwiązania do przechowywania danych

Kolejną bardzo ważną klasą komponentów wykorzystywanych do budowy ekosystemu analitycznego są narzędzia do gromadzenia danych.

Aby podejmować jakiekolwiek decyzje bazujące na danych, potrzebna jest baza gromadząca dane aktualne i historyczne. Początkowo do takich celów wykorzystywano uniwersalne silniki baz danych, zbudowane na cele wsparcia rozwiązań transakcyjnych OLTP[6]. Spełniały one podstawowe zadania niezbędne do utworzenia schematów baz danych. Zapewniały obsługę ograniczania uprawnień dostępu do wybranych danych, modelowania danych i skutecznego operacyjnego ich wykorzystania. Uniwersalne silniki baz danych, sprzedawane przez firmy, takie jak Oracle, czy IBM, po jakimś czasie zostały uzupełnione rozwiązaniami otwartymi (np. PostgreSQL, mySQL). Działania transakcyjne, czyli praca na poszczególnych rekordach (np. klientów, wpisów bibliotecznych lub transakcjach bankowych) były i są tym, z czym technologia radzi sobie bardzo dobrze. Tradycyjne bazy, jako dobrze znane, zostały w wielu miejscach zastosowane do podstawowych rozwiązań analitycznych. W przypadku analityki działamy nie na pojedynczych rekordach, lecz na coraz szerszym zakresie danych jednocześnie, nawet na całych zbiorach danych. Ważnymi operacjami, zamiast pojedynczych transakcji zapisu, odczytu i modyfikacji danych na poziomie rekordów stają się odczyty, obejmujące tysiące, setki tysięcy, miliony rekordów, następnie ich filtrowanie, agregacja i wyciąganie cząstkowych wniosków. Taki tryb pracy to analityka, w szczególności zwana OLAP[7].

Przy większych wolumenach danych, zwykłe bazy OLTP przestają wystarczać do działań analitycznych. Silnik zoptymalizowany pod transakcje staje się „wąskim gardłem” i dużym problemem. Rozwiązaniem tego problemu jest dostosowanie technologii bazodanowej do potrzeb. Przez wiele lat budowano specjalistyczne bazy wykorzystywane do analityki. Są to z jednej strony architektury MPP[8], realizujące operacje podobne do tych w klasycznych bazach danych, jednak posiadających cechę zrównoleglenia operacji. Architektura wykorzystuje możliwości podziału dużego zbioru na mniejsze części i procesowania ich oddzielnie i równolegle, na oddzielnych maszynach, zwanych często węzłami. Wspomniana idea operacji równoległych jest analogiczna do zastąpienia zwykłej jednopasmowej drogi autostradą, składającą się z dwóch, trzech lub większej liczby pasów. Użytkownik takiej bazy nie wchodzi w szczegóły techniczne budowy architektury, musi o niej jednak pamiętać projektant rozwiązań. Przykładami takich właśnie rozwiązań są bazy specjalizowane pod hurtownie danych firmy Teradata, Netezza firmy IBM, EMC firmy Greenplum.

Inną gałęzią rozwiązań dla potrzeb analityki są bazy specjalizowane pod analizy wielowymiarowe, zwane potocznie kostkami OLAP. Tu przykładem jest baza MS Analysis Services firmy Microsoft[9].

Podział danych na części stał się typową i całkiem trafną odpowiedzią firm na zjawisko rosnących wolumenów danych. Podobna idea stanowi fundament budowy popularnego rozwiązania tworzenia klastrów big data. Pierwotna idea powstała w laboratoriach google’a jako koncepcja map/reduce[10]. Zakłada ona, oprócz podziału danych na części, realizację operacji analitycznych jako kombinację dwóch najprostszych kroków: map i reduce.

Idea została wykorzystana przez Daug Cutting’a do stworzenia darmowego i otwartego rozwiązania hadoop. Obecnie hadoop jest jedynie pierwowzorem i historycznym pomysłem na radzenie sobie z ilością danych. Powstało wiele rozwiązań czerpiących z tej idei i jednocześnie będących o wiele lepszą implementacją założeń architektonicznych. To, o czym watro pamiętać, to fakt, że zwiększając ilość danych, które chcemy przetwarzać, w pewnym momencie wchodzimy w zakresy wolumenów danych, które nie mieszczą się na żadnej z dostępnych na rynku maszyn. To jest sytuacja, w której należy wykorzystać technologię rozproszoną. Brak jednej maszyny, która zmieści analizowane dane powoduje, że dane muszą zostać w jakiś sposób podzielone. Podział wymusza na projektantach systemu odpowiedź na ważne pytania dotyczące cech, jakie ma spełniać system. Te cechy to: spójność danych, dostępność danych nawet w przypadku awarii dowolnej części klastra i partition tolerance — nie ma fizycznej możliwości spełnić każdej z tych cech jednocześnie.

Rys. 19: Trójkąt trzech ograniczeń dla systemów dużych danych zwany w skrócie CAP (Consistency-Availability-Partition Tolerance).

Hadoop, oprócz większej ilości danych możliwej do przechowywania i analizy, różni się od baz relacyjnych tym, że w głównej mierze jest stworzony do przetwarzania płaskich danych — logów, zdarzeń, a nie prostych czy złożonych relacji. To ważna różnica. Warto wiedzieć, że do innych rodzajów danych powstały jeszcze inne specjalistyczne silniki bazodanowe. Są nimi bazy grafowe (np. Neo4j), bazy klucz/wartość — służące do szybkiego działania na poszczególnych rekordach (np. HBase, Cassandra), bazy dokumentowe, bazy zorganizowane pod kątem przeszukiwania danych tekstowych. Ta spora grupa rozwiązań nosi nazwę noSQL[11]. Inną istotną grupą rozwiązań są bazy pamięciowe[12]. Bazy takie, jako miejsce przechowywania danych gorących, czyli najczęściej używanych, w znacznej mierze używają pamięci, która ostatnio znacznie staniała. Wykorzystanie pamięci powoduje przyspieszenie operacji odczytu danych, czyli komfortu korzystania z nich przez użytkowników. Jedni producenci budują bazy prawie wyłącznie bazujące na pamięci, czego przykładem jest baza SAP HANA, inni natomiast wykorzystują połączenie tradycyjnych dysków, dysków szybkich (SSD) i pamięci dla danych o różnej temperaturze (temperatura określana jest jako częstość używania). To drugie podejście, czyli budowanie hierarchii różnych rodzajów medium do przechowywania danych (pamięci, dysków SSD i dysków HDD) jest standardem wśród producentów hurtowni danych.

Obok aspektów związanych z rodzajem technologii przechowujących dane coraz ważniejsze miejsce zajmują rozwiązania chmurowe, udostępniane dla użytkowników jako usługa. Warta przywołania jest ich najnowsza, dająca deweloperom unikalne możliwości odmiana — rozwiązania „serverless”. Usługi takie zdejmują z korzystających z nich użytkowników konieczność administrowania infrastrukturą serwerową i pozwalają skupić się na aspektach biznesowych i na zarządzaniu warstwą danych. Jest to element ewolucji zmierzającej w stronę rozwiązań ekstremalnie skalowalnych i przyspieszających budowę systemów analitycznych.

Ważną cechą baz danych, jest język zapytań. W przypadku baz OLTP, jak i tych, specjalizowanych pod analitykę, jest to język SQL, jest on najszerzej znany i będzie jeszcze długo wykorzystywany. W przypadku hadoop’a i rozwiązań „serverless” istnieje wiele sposobów dostępu do danych, wśród których występują także odmiany popularnego języka SQL. Język dostępu do danych, jest ściśle powiązany z modelem, w jakim przechowywane są dane, dlatego powrócimy do niego jeszcze w następnym rozdziale.

Przykładowe zapytania SQL:

SELECT COUNT(CustomerID), Country

FROM Customers

GROUPBY Country;

SELECT Name FROM Customers WHERE EXISTS

(SELECT Item FROM Orders

WHERE Customers.ID = Orders.ID AND Price < 50)

Model danych

Dane to podstawa analityki. Hurtownia danych z kolei to prawdziwe serce środowiska analitycznego i trudno wyobrazić sobie efektywną realizację celów biznesowych bez takiego „serca”. Sposób organizacji danych w hurtowni danych zależy w dużej mierze od tego, do jakich zastosowań ma ona służyć, a to może się znacznie różnić w przypadku różnych organizacji. Z tego właśnie powodu cel biznesowy jest traktowany z wielką powagą. Właśnie od tego celu, zdekomponowanego na mniejsze części, a dalej na konkretne analizy, raporty czy mini rozwiązania analityczne, zależy jak optymalnie modelować dane. Optymalizacja powinna przebiegać pod kątem łatwości użycia zgromadzonych danych. Inny jest model danych, gdy potrzebne będzie udostępnianie przekrojowych agregatów sprzedażowych w podziale na regiony sprzedaży, uaktualnianych co 15 minut, inaczej, gdy trzeba namierzać poszczególne transakcje sprzedaży podejrzane o nadużycia, a jeszcze inaczej, gdy zaistnieje potrzeba łączenia transakcji z danymi pochodzącymi z sieci społecznościowych, nie zawsze możliwymi do idealnego połączenia z bazą kliencką.

Decyzje o sposobie ułożenia danych podejmuje się w oparciu o obecne wymagania, ale należy pamiętać, że bieżące wymagania to tylko próbka potrzeb. Aby móc efektywnie dostosowywać się do ewoluujących wymagań biznesu, trzeba traktować nie jako ostateczne wymagania, ale przykłady prowadzące do następnych potrzeb. Takie podejście spowoduje lepszą gotowość na wymagania, które pojawią się w kolejnych etapach projektu lub też w kolejnych projektach realizowanych na zmieniającym się środowisku.

Czym większe doświadczenie i intuicja projektanta hurtowni, tym lepszy efekt dla organizacji i tym lepsze dostosowanie do zmienności biznesu. To ukazuje, w jaki sposób decyzje projektowe, niezwiązane z metodykami projektowymi (o których oczywiście będzie mowa w kolejnych rozdziałach), mogą poprawić zwinność działań, co może zdecydować o powodzeniu projektu bądź programu.

Aby iść pewnie w kierunku sukcesu, warto opierać się na fundamentach sprawdzonych już przez innych. Na rynku analityki trwa ciągła dyskusja dotycząca tego, jak powinna wyglądać hurtownia danych. Obserwujemy różne podejścia do modelowania danych; przykładem są poglądy dwóch badaczy badaczy — Ralpha Kimballa i Billa Inmona. Obaj urodzeni w latach czterdziestych, uznawani są za ojców hurtowni danych. Każdy z nich prezentował odmienne podejście do modelowania danych.

Ralph Kimball widział hurtownię jako wielowymiarowe kostki, zawierające miary i wymiary ułożone hierarchicznie wraz z tabelą faktów, zagregowaną do odpowiedniego poziomu. Odmienne podejście proponował Bill Inmon[13]. To propagator hurtowni tematycznej, opartej na detalicznym, zintegrowanym modelu danych, na którym budowane są data marty spójne z danymi szczegółowymi. Obaj badacze włożyli niemały wkład w rozwój analityki. Ich teorie leżały u podstaw wielu hurtowni danych. Każda z przyjętych filozofii wiąże się z pewnymi zaletami i wadami, co zachęca projektantów do zastanowienia się i świadomego przyjęcia pasującego podejścia.

Rys. 20: Architektura hurtowni danych według podejścia Ralpha Kimballa.

Wraz z popularyzacją analityki danych budowano coraz większą liczbę środowisk analitycznych. Realizacja takiego projektu jest zadaniem trudnym i wymagającym znacznych inwestycji oraz konsekwencji. Platformy analityczne budowano często bez wymaganego przygotowania i bez zdecydowanego podejścia architektonicznego, uzbrojonego w silne podstawy teoretyczne. Zmiana owego podejścia, czasem wielokrotnie w trakcie trwania projektu prowadzi do porażki. Taki rezultat to najczęściej efekt entropii organizacyjnej, wyłaniającej się w naturalny sposób w przypadku braku fundamentów. Entropia i brak stabilnego kierunku, połączonego z właścicielstwem rozwiązania, jest jednym z poważniejszych powodów niepowodzenia projektów hurtowni danych. Oczywiście nie jest to jedyny możliwy powód. Inne liczne powody zostaną przedstawione w pozostałych rozdziałach tej książki.

Rys. 21: Architektura hurtowni danych według podejścia Billa Inmona

Budowa modelu ułatwiającego późniejsze wykorzystanie i odpytywanie hurtowni danych, uwzględniającego także wybraną platformę technologiczną nie jest banalną sprawą. Aby decyzje podejmowane w tym obszarze były trafne (pozwalające uniknąć wielkiego ryzyka dla rozwoju analityki), należy włożyć bardzo dużo pracy w rozpoznanie celów organizacji. Następnie należy przejść przez wymagania realizujące te cele, znaleźć reprezentatywny ich zbiór stanowiący część wspólną i zrealizować projekt. To trudna droga, daje jednak dużą szansę powodzenia. Istnieje także łatwiejszy sposób, realizowany błyskawicznie. Jest nim idea „budowy hurtowni danych w tydzień”. Zdarzają się nawet propozycje sprzedawców, którzy pokazują rozwiązania analityczne budowane nawet w trakcie prezentacji, na oczach klienta, pomijając wszelkie trudne aspekty, o których piszę w tej książce. Klienci są na tyle nieświadomi, że często decydują się skorzystać z takiej przynęty. Powstają rozwiązania typu data lake[14] w miejscu, w którym klient spodziewa się zintegrowanego rozwiązania. Tutaj właśnie kluczową rolę ma do odegrania lider analityki, dobrze przygotowany do swojej roli, powinien ustrzec organizację przed taką pułapką.

W następnym rozdziale skupimy się już nie na modelu danych, ale na pierwszych, prostych aplikacjach korzystających ze zbieranych danych. Zbieranych oznacza regularnie zasilanych, a nie zgromadzonych jednorazowo — gotowych do użycia biznesowego.

Platformy raportowe

Przechodząc od etapu zbierania danych do ich użycia, wróćmy do podstawowej cegiełki analityki. Tak, jak już wcześniej przyjąłem, podstawowym sposobem użycia danych jest realizacja raportu. Raport rozumiemy tu szeroko. Realizacja raportowania jest możliwa i występuje bardzo często, nawet z pominięciem uporządkowanego podejścia do procesów zasilania w dane, opisanych wcześniej. Taka uproszczona sytuacja może być dobrym rozwiązaniem jedynie w niektórych sytuacjach, na przykład tych, które nie wymagają sporej operacjonalizacji, czyli automatyzacji pozyskiwania danych. Przykładami takich sytuacji są jednorazowe analizy, prototypowanie, procesy eksploracji danych.

Raportowanie, w typowym dla rozwiniętej organizacji scenariuszu, będzie bazowało na hurtowni danych, czasami na data marcie i danych cyklicznie tam ładowanych, odpowiednio przetwarzanych i przechowywanych w postaci dostosowanej do tych raportów. Najprostszym i najbardziej trywialnym narzędziem, służącym do realizacji raportu, jest konsola dostępu do bazy, dająca możliwość zadawania zapytań w języku zapytań (w większości przypadków jest nim SQL). Metoda ta, chociaż bardzo skuteczna, to nie jest wystarczająca do realizacji większości potrzeb użytkowników raportowych. Potrzebują oni nie tylko bezbłędnej treści, czyli prawdziwych świeżych i trafnie dobranych danych, lecz także odpowiedniego zaprezentowania ich w formie graficznej. Kolory, kształty i inne elementy wspomagające interpretację danych są niezbędnym elementem platformy raportowej. Innym czynnikiem, pomagającym szybko odczytać informację na raporcie jest ułożenie danych w taki sposób, aby stanowiły one spójną historię „opowiadaną danymi”. Dziedzina zwana z angielskiego storytelling’iem rozwija się intensywnie i jest bezwarunkowo połączona z celami analityki.

Prezentowane dane, dzięki odpowiednio dobranej formie i dopasowane do celu komunikacji i odbiorców, stają się czymś więcej niż jedynie prawdziwymi liczbami. Stają się wartościową informacją. Na podstawie informacji podejmowane są decyzje służące celom biznesowym. Ddecyzje mogą być trafne jedynie przy dobrym zrozumieniu celu biznesowego i właściwym przełożeniu go na pytania do danych. Jeśli tak się stanie, istnieje szansa na znalezienie odpowiedzi. Jeśli nie ma pytań do danych, decydenci mogą się zdać jedynie na intuicję, bądź przypadek. Cała idea wspomaganego danymi procesu decyzyjnego przestaje faktycznie istnieć i staje się jedynie teorią.

Rys. 22: Przykładowa infografika pokazująca kandydatów w wyborach prezydenckich USA z partii demokratycznej wraz z informacją o tym jakie są części wspólne zbiorów osób, które śledzą ich na Twitterze.

Aspekt wspomaganego danymi procesu decyzyjnego jest głównym wątkiem związanym z warstwą raportową i narzędziami służącymi do wsparcia tego procesu. Warto skupić się tu dodatkowo na pewnych szczegółowych cechach rozwiązań, które pomagają w realizacji tej idei.

Czasy, w których narzędzia raportowe były instalowane głównie jako „programy komputerowe”, czyli aplikacje w architekturze tak zwanego grubego klienta, gdzie każdy użytkownik powinien mieć zainstalowany program raportowy, skonfigurowany dostęp do danych, a później powinien uzyskiwać od działu IT uaktualnienia — odchodzą w przeszłość. Taka architektura jest zbyt uciążliwa zarówno dla użytkowników, jak i dla administrujących nią. Chociaż wielką popularnością nadal cieszy się najbardziej popularne narzędzie business intelligence, jakim jest MS Excel, to nowoczesne platformy dają możliwość korzystania z wielu różnych kanałów dostępu. Innym sposobem na dostępu do raportów, dashboardów i wizualizacji jest wersja na przeglądarkę. Nie wymaga ona instalacji oprogramowania. Usługa świadczona jest z internetu, jako platforma SaaS[15], bądź z wewnętrznych zasobów intranetowych firmy. Wymieniana na kolejnym miejscu ale ostatnio stająca się wiodącą, jest wersja na urządzenia mobilne. Warto wspomnieć także o innych interfejsach raportowych, takich jak: raport wysłany mailem i dashboard, gotowy do powieszenia na monitorze w widocznym miejscu firmy. Przykładem wiodących platform raportowych są rozwiązania takie, jak: Tableau, PowerBI. Platformy mają wbudowane wiele innych podstawowych funkcji, na przykład ograniczanie i dostosowywanie uprawnień użytkowników, możliwość eksportu wyników do wielu różnych formatów, możliwości podłączania się do różnych źródeł danych, oraz często funkcje zarządzania danymi, które są przydatne dla mniejszych rozwiązań.

Wśród rozwiązań raportowych wart odnotowania jest trend polegający na przenoszeniu elementów wizualizacyjnych do przeglądarki, wykorzystanie mocy obliczeniowej komputera użytkownika do budowy elementów wizualnych. Odbywa się to poprzez wykorzystanie przeglądarki jako platformy budowy wizualizacji i języka JavaScript wraz z bibliotekami wizualizującymi dane. Sztandarowym przykładem jest d3js[16]. Użycie d3js wymaga, w odróżnieniu od poprzednio wskazywanych możliwości, umiejętności programistycznych na granicy web i data developmentu. To spora różnica i możliwości te nie są dostępne dla każdego. Trend ten jest jednak na tyle silny, że każdy CDO powinien być przynajmniej świadomy jego istnienia.

Data Science

Narzędzia dla badaczy danych, czyli osób zwanych z języka angielskiego data scientist, pełnią z jednej strony bardzo podobną rolę do narzędzi raportowych. Podobieństwo bierze się z faktu, że z punktu widzenia architektonicznego wykorzystywane są w nich dane zebrane wcześniej w hurtowni danych (w rzeczywistości także z innych źródeł). Ale to koniec podobieństw, różnic jest znacznie więcej. Głównym celem tych narzędzi oraz pracy badaczy danych jest użycie dla celów biznesowych szerokiej gamy algorytmów do wydobycia wiedzy z dostępnych danych. W rezultacie tworzone są różnego rodzaju wyniki i wnioski(trudno byłoby je uzyskać w inny sposób), począwszy od najprostszych, poprzez modele opisujące rzeczywistość odwzorowywaną przez dane, aż do modeli zapisanych w sposób formalny w określonym języku programowania lub w postaci kodu PMML[17], które są gotowe do automatycznego stosowania na nowych danych.

Kroki niezbędne do efektywnego tworzenia i wdrażania na produkcyjnych modeli decyzyjnych zostały ustandaryzowane w ramach procesu CRISP[18].

Rys. 23: Model CRISP (ang.: Cross-Industry Standard Process for Data Mining).

Standardowy proces CRISP jest elementem całości architektury techniczno-biznesowej, która może być budowana w organizacji. Nie widać w niej np. elementów raportowania. Są jednak obecne komponenty związane z produkcyjnym ładowaniem danych, w szczególności z procesami ETL, na których skupialiśmy się wcześniej. Widoczny jest tu także nacisk na zrozumienie biznesu i danych. Narzędzia, które pomagają badaczowi danych zrealizować jego cel to bardzo szeroka i dynamicznie rozwijająca się kategoria. Ze względu na to, że należy rozumieć zarówno kontekst biznesowy, jak i dane, narzędzia te muszą posiadać możliwości eksploracji danych realizowany względnie prosto. Powinien posiadać możliwości prostego budowania przepływów danych i wizualizacji.

Skąd taki właśnie zestaw funkcjonalności? Wynika z celu, który jest stawiany badaczowi danych — utworzenie modelu, by wspierał decyzje biznesowe. Budowa modelu wymaga wielu prób, cykli, badań i błędów. Czym krótszy jest cykl narysowany na diagramie CRISP, tym większa szansa na pozytywny rezultat. Aby cykl badawczy był krótki, wszystkie elementy wchodzące w skład jego elementów muszą być realizowane w minimalnym czasie, najlepiej przez jedną osobę. Po etapie badań model, bądź zestaw najlepszych modeli przechodzi do produkcyjnego wykorzystania. Przejście to może oznaczać, że klient przyjmuje jego założenia i realizuje wnioski. Taki scenariusz jest obecny w niektórych modelach niewymagających automatycznej operacjonalizacji. Modele pracujące automatycznie zostają przeniesione na środowisko produkcyjne i działają jako logika uruchamiana w odpowiednim kontekście w sposób zautomatyzowany. Przykładem niech będą modele określające scoring kredytowy, wykonywany dla klienta wnioskującego o pożyczkę. W przypadku rynku reklamy internetowej jest to decyzja po stronie ekosystemu reklamy, dotycząca tego, któremu użytkownikowi internetu wyświetlić daną reklamę — proces jest złożony i uczestniczą w nim po wielu stronach algorytmy decyzyjne, przygotowywane właśnie w oparciu o uniwersalny proces CRISP.

Istnieje wiele narzędzi realizujących metodykę CRISP, zarówno komercyjnych, jak i otwartych. Przykładem pakietu służącego do poszukiwania modeli decyzyjnych jest SAS Enterprise Miner, czy zestaw rozwiązań firmy H2O[19], zaś z narzędzi darmowych, które ostatnio zupełnie zdominowały ten obszar, wyprzedzając większość narzędzi komercyjnych, należy wymienić pakiety języka R i Python’a.

Kolejnym krokiem ewolucji data science jest automatyczne poszukiwanie modeli, a temu przyjrzymy się w kolejnym rozdziale.

Machine Learning

Już przy temacie przygotowywania danych pojawił się termin „model danych”. Obecnie skupiamy się na modelach decyzyjnych, będących celem bloku Modelling obecnego w podejściu CRISP. Termin modelowanie używany jest do określania różnych czynności i z tego powodu może być mylące. Jednak osobom odpowiedzialnym za analitykę nie wolno wpadać w tak prostą pułapkę.

Głównym celem uczenia maszynowego (ang:. Machine Learning) jest automatyczne poszukiwanie i uaktualnianie modelu decyzyjnego, czyli służącego do podejmowania decyzji w różnych krokach procesów biznesowych. Cel nie dla każdego jest jasny. Często zanika w gąszczu haseł marketingowych, używanych przy okazji rozmów o nowych i nieznanych technologiach.

Modele decyzyjne dzielą się na: modele z nadzorcą (ang: supervised), bez nadzorcy (ang.: unsupervised) i to jedna z wielu osi podziału. Warto pamiętać o innym typie modeli, opartym o metodę uczenia ze wzmocnieniem (ang.: reinforcement learning). To scenariusz, w którym optymalizowane są decyzje przypisane agentowi działającemu w środowisku, a celem jest odnalezienie dla niego optymalnej polityki decyzyjnej.

Tworzenie predykcyjnych modeli decyzyjnych opiera się na założeniu, że reguły, obecne w niewielkiej próbce danych uczących, są reprezentatywne dla całego badanego zjawiska. Model tworzony jest na wycinku danych. Badacz danych nigdy nie posiada dostępu do wszystkich możliwych kombinacji zjawiska, widzi jedynie to, co wynika z zebranych danych, zwanych danymi uczącymi. Na nich trenowane są algorytmy. Po etapie treningu model potrafi generować decyzje na bazie nowych danych, czyli podejmować je automatycznie, bez udziału człowieka. Modele oceniane są poprzez sprawdzenie trafności podjętych decyzji. Czym lepsze dopasowanie modelu do zbioru uczącego, który obok danych opisujących zawiera także wzorcowe decyzje (opisane specjalnymi zmiennymi, zwanymi „zmiennymi targetowymi”), tym lepszy model. Jest to jednak tylko jedna strona medalu. Trening, z tak zdefiniowanym celem, prowadzi do znalezienia wzorców, które w krańcowym przypadku „uczą się na pamięć” dostępnych danych. Aby tego uniknąć, stosuje się walidację modeli na danych, których jeszcze model „nie widział” w procesie uczenia. Czym lepsze wyniki na danych, nowych dla modelu tym lepsza jego uniwersalność i ta cecha ma wielkie znaczenie w ocenie jego przydatności do użycia produkcyjnego.

Podczas tworzenia modeli badacze danych rozwiązują wiele problemów, których dobra analiza wymaga oddzielnej książki, taka została zresztą napisana przez Andrew Ng[20]. Szczególnie ważnym zagadnieniem, wstępnie przedstawionym przed chwilą, są błędy modelowania zwane z języka angielskiego: variance i bias. Model musi spełniać jednocześnie dwa cele. Powinien dawać poprawne wyniki na zbiorze uczącym, czyli być do niego dopasowanym, ale tylko do pewnego stopnia. Nie wolno mu nauczyć się danych ze zbioru uczącego na pamięć, bo wtedy nie będzie działał poprawnie na danych spoza zbioru uczącego, czyli nie dostępnych w trakcie treningu modelu.

Dzięki dobremu określeniu miar jakości modeli możemy przejść do automatycznego ich poszukiwania. Nie poruszam tu szczegółowo technik używanych do owego zadania, a jedynie wspominam o jego ramach. Zakres wiedzy jest wystarczający dla lidera analityki, chociaż wejście w szczegóły tego procesu, na przykład poprzez lekturę książki Andrew Ng, bądź udział w jego szkoleniach[21], jest niezwykle interesującą przygodą.

Sztuczna inteligencja

Sztuczna inteligencja[22] stała się dziedziną, w której osoby odpowiedzialne za analitykę w organizacjach upatrują sporej nadziei na nowe rozwiązania biznesowe lub też na skuteczne rozwiązanie starych problemów. Czy pokładanie nadziei w metodach, które rozwijają się niezwykle szybko i nie każdy rozumie, w jaki sposób działają, ma sens i czy podejście takie ma szanse dać realne wyniki? Podobnie, jak przy wielu innych aspektach, nie będę wchodził w detale techniczne. Dla zainteresowanych pozostawiam inne lektury, przykładowo wspomnianą twórczość Andrew Ng. Przedstawię jednak kilka podstawowych aspektów, kluczowych z punktu widzenia podejmowania ważnych decyzji dotyczących tematów wokół hasła „AI”.

Czym jest sztuczna inteligencja? To zbiór metod kognitywnych, oferujących zupełnie inne podejście do rozwiązywania problemów analitycznych niż klasyka ostatnich kilkudziesięciu lat. Dla odróżnienia zakresu działania AI, obecnie wszystkie realne wyniki uzyskane na uczelniach i w biznesie, dotyczą tak zwanej „wąskiej” sztucznej inteligencji[23], skupiającej się na rozwiązywaniu konkretnych problemów, np. rozpoznawaniu obiektów na zdjęciach, identyfikacji danych głosowych, lub decydowaniu za gracza w prostych grach. Nie jest to szeroka sztuczna inteligencja, dotycząca jednocześnie wielu problemów i przypominająca działaniem człowieka. Na taką prawdopodobnie jeszcze długo poczekamy.

Skąd ostatnimi czasy tak duży postęp w tej dziedzinie? Wynika on ze znacznego wzrostu mocy obliczeniowej. Szczególnie istotnym krokiem było pojawienie się na rynku kart graficznych zawierających tysiące niewielkich rdzeni — autonomicznych jednostek obliczeniowych, mogących równolegle operować na niewielkich ilościach danych. Ta równoległość, dostępna w sprzęcie, idealnie pasuje do sztucznych sieci neuronowych. Stało się tak, ponieważ podczas poszukiwania optymalnych wag sieci, w procesie uczenia, następuje wiele równoległych operacji i do tej równoległości idealnie pasuje architektura kart graficznych. Dzięki sieciom neuronowym można budować coraz bardziej skomplikowane, co ważne, nieliniowe modele decyzyjne, gotowe nauczyć się na wielu klasach danych podejmowania decyzji, które nawet dla człowieka wydają się być trudne.

Rys. 24: Podstawowa sieć neuronowa zawierająca trzy warstwy, dwa neurony wejściowe, jeden wyjściowy i cztery neurony w warstwie ukrytej.

Rys. 25: Przykład głębokiej sieci neuronowej.

Możliwość uczenia się sieci neuronowej powstaje nie tylko dzięki silnemu sprzętowi. Istotną rolę odgrywa także odpowiedni algorytm do poszukiwania właściwego rozwiązania. W tym celu wykorzystuje się znane od dawna w nauce podejście rozwiązywania problemów optymalizacyjnych w przestrzeniach wielowymiarowych. Problem optymalizacji to poszukiwanie minimum funkcji wielowymiarowej. Zobrazować go można, ograniczając liczbę wymiarów do dwóch, chociaż w realnych problemach, wymiarów mogą być miliony. Poniższy rysunek ukazuje problem dla dwuwymiarowej przestrzeni, w której trzecim wymiarem jest wartość optymalizowanej funkcji. Zadaniem algorytmu jest znalezienie najniższego punktu na tym rysunku. Jest to spore uproszczenie, jednak daje szansę na wyobrażenie sobie jakiego rodzaju zadanie wykonywane jest w trakcie procesu treningu sieci neuronowej.

Rys. 26: Optymalizacja wielowymiarowa. Uproszczona przestrzeń rozwiązań oraz strzałki wskazujące spadek wartości optymalizowanej funkcji celu.

Analizując ciekawe rozwiązania techniczne, dochodzimy do podstawowego dla decydenta pytania — jak wykorzystać wyłaniające się technologie dla celów biznesowych mojej organizacji? Aby odpowiedzieć na to pytanie, należy przejść całą ścieżkę działań proponowanych w tej książce. Rozpocząć należy od definicji problemu biznesowego, przejść do identyfikacji i pozyskania danych, które mogą posłużyć do wytrenowania modeli. W przypadku sieci neuronowych należy zastanowić się — czy mamy do czynienia z problemem, który jest specyficzny dla danej organizacji i wymaga samodzielnego poszukiwania polityki decyzyjnej, czy też jest on na tyle generyczny, że warto wziąć gotowe rozwiązanie. Przykładem problemów generycznych może być rozpoznawanie obiektów na obrazie. Zostały one już wielokrotnie rozwiązane i konkurowanie z twórcami tych rozwiązań o jeszcze lepszą implementację, może nie mieć biznesowego sensu. W takim przypadku być może warto zastosować gotowe serwisy, dostępne za pomocą interfejsu programistycznego API[24]. Idąc taką ścieżką, organizacja angażuje w trybie software as a service komponent, za którym stoi istotna wartość lub inteligencja. Rolą integratorów pozostaje odpowiednio włączyć ten komponent w architekturę analityki, oraz zadbać o efektywność kosztową rozwiązania. Przykładem takiego podejścia jest implementacja automatów konwersacyjnych[25] bazująca na logice dostarczanej przez zewnętrznego dostawcę, rozwiązania automatycznie tłumaczących tekst i wspomniane tu już operacje na obrazach.

Odrębną ścieżką stosowaną dla indywidualnych problemów decyzyjnych opartych o unikalne dane, dostępne jedynie w danej firmie jest samodzielne budowanie i trenowanie sieci neuronowych. Stosuje się do tego pakiety opensource, takie jak TensorFlow[26], MxNet[27], czy też inne dostępne. Ostatnio biblioteki programistyczne, pełniące takie funkcje rozwinęły się znacząco. Integrują platformę sprzętową z efektywnymi algorytmami optymalizacyjnymi i przystosowanymi do procesu uczenia modeli strukturami danych. Chociaż oprogramowanie to jest coraz łatwiejsze w użyciu, to zastosowanie narzędzi takiej klasy wymaga rzadko występującego zestawu kompetencji. Oprócz kompetencji, realizacja uczenia sieci neuronowej w firmie wymaga konsekwentnie stosowanej strategii pozyskiwania danych. Niezbędna jest także infrastruktura. Można jednak przyjąć, ze względu na dostępność chmury obliczeniowej, że to już rozwiązany problem. Firmy, które chcą poprawy procesów poprzez włączenie w nie sztucznej inteligencji, nie ominą etapu budowy infrastruktury danych, ponieważ cała konstrukcja zaawansowanej analityki bazuje przede wszystkim na danych i odpowiednim ich przygotowaniu, oraz operacjonalizacji.

Architektura rozwiązania

Wszystkie wymieniane powyżej elementy odgrywają ważne role w wielu organizacjach, choć nie zawsze każdy z nich jest wykorzystywany. Często nie ma potrzeby angażowania sztucznej inteligencji, zaawansowanej analityki lub innych komponentów. Zastosowanie odpowiednio dobranego zestawu klocków zależy od konkretnej sytuacji i od tego, jaką układankę chcemy z nich złożyć. Dla podjęcia dobrej decyzji istotne jest miejsce w cyklu rozwoju analityki, sytuacja w której znajduje się w danej firmie środowisko techniczne, potrzeby biznesowe i możliwości, które chcemy zapewnić.

Dlaczego w tym miejscu podejmuję taki temat? Prawdziwą siłą rozwiązań IT, w szczególności budowanych pod potrzeby analityczne organizacji, jest mądre złożenie rozwiązania z poszczególnych elementów. Mądre — oznacza zgodne z celami organizacji, wykorzystujące mocne strony dostępnych komponentów, tanie w utrzymaniu, ale także możliwie do łatwe w rozwoju.

Rys. 27: Architektura rozwiązania, obejmująca modyfikowane elementy całej architektury środowiska oraz osoby zaangażowane w procesy biznesowe działające na bazie tego rozwiązania. Rozwiązanie pokazane jest na tle całego środowiska i jego elementy zaznaczone są symbolem trójkąta.

Głównym celem, stawianym rozwiązaniom IT, które wspierają biznes, jest spełnianie wszystkich wymagań biznesowych, począwszy od najważniejszych — kluczowych dla biznesu, aż do tych, które traktowane są jako opcjonalne. Tak samo ważne jest spełnienie wymagań niefunkcjonalnych, czyli np. wymaganego czasu odpowiedzi, szybkości działania, ergonomii i tym podobnych. Są to równie ważne aspekty, które powinny zostać przewidziane i zaprojektowane przez architekta danego rozwiązania i zrealizowane przez zespół.

Jeśli cechy wymienione do tej pory są oczywiste i niezbędne dla projektu realizującego rozwiązanie, to kolejne, są uwzględniane jedynie w dojrzałych firmach, gdzie liczy się nie tylko krótki horyzont planowania, ale także spojrzenie strategiczne. Te specjalne cechy budowanych rozwiązań, wykraczają poza prostą realizację wymagań. Zapewniają coś więcej — szersze myślenie o architekturze. To na przykład minimalizacja uzależnienia od dostawcy, partnera lub od rzadko występujących zasobów, elastyczność rozwiązania, łatwość utrzymania rozwiązania, otwartość kodu i wiele innych cech, które nie mają bezpośrednio wpływu na odbiór narzędzia czy aplikacji przez użytkownika. Myślenie o architekturze z taką perspektywą ma na celu doprowadzenie do wymiernych efektów, widocznych w rezultatach finansowych, czy to w pozycji kosztów utrzymania, czy w pozycji kosztów rozwoju poprzez minimalizację poprawek błędów w danych. Efekty złej lub zapomnianej architektury mogą negatywnie wpływać na wyniki finansowe firmy, dobra architektura przeciwnie — będzie napędem biznesu.

Aspekt architektoniczny bardzo często jest pomijany, ponieważ nawet bez myślenia o architekturze można zrealizować projekt i dostarczyć wartość biznesową. Problemem rozwiązań, zbudowanych z pominięciem celów architektonicznych, jest związany z nimi, narastający dług architektoniczny. Jest on zbiorem zaszłości, które kumulują się na wszystkich poziomach rozwiązań IT — na poziomie komponentu, na poziomie rozwiązania, czyli połączonych komponentów oraz na najwyższym poziomie — całego środowiska IT. Dług architektoniczny może stać się poważną barierą rozwoju organizacji. Często zdarza się, że firma, ze względu na dług nie jest w stanie rozwijać swych systemów, bo musi skupić się na nieustannych poprawkach do istniejących aplikacji.

Innym przykładem błędu w planowaniu architektury jest realizacja podobnych funkcji przez wiele zespołów. Aby zrealizować cele biznesowe, firma zużywa kilka razy więcej zasobów, zarówno osobowych, jak i technicznych. Niewystarczająca wiedza i wymiana informacji na temat architektury, prowadzi do złych decyzji, a co za tym idzie nieoptymalnego rozwoju środowiska. Istotne jest dokumentowanie rozwijającego się ekosystemu technicznego, jest to koszt, który szybko się zwraca. Dług architektoniczny to bardzo często efekt entropii organizacji i brak działań konserwujących architekturę.

Dojrzałe firmy, z dobrze zdefiniowanymi celami strategicznymi przeciwdziałają takim procesom. Tematem, jak aktywnie im przeciwdziałać długowi architektonicznemu zajmiemy się później, teraz zajmiemy się warstwą najniższą — infrastrukturą techniczną.

Rys. 28: Cztery poziomy architektury: infrastruktura, komponent, rozwiązanie i środowisko.

Infrastruktura

Infrastruktura jest podstawą techniczną budowanych rozwiązań. Niezależnie od tego, jakie są cele biznesowe, czy zostaną podjęte dobre decyzje dotyczące architektury aplikacji, architektury środowiska, zawsze, gdy organizacja decyduje się na jakieś rozwiązania techniczne, niezbędne będzie zagwarantowanie tej podstawy. Infrastruktura może być własna, zakupiona i utrzymywana przez firmę; może także być utrzymywana przez partnera biznesowego. Pomijając kwestie właścicielskie i modele zakupowe, trzeba tę warstwę zapewnić. Udział lidera analityki w zakresie zapewnienia infrastruktury technicznej zależy od struktury organizacji. Najczęściej znajduje się w odpowiedzialności szefa informatyki (CIO), bądź szefa technologii (CTO). W większych firmach rozdzielone są kwestie utrzymania infrastruktury technicznej od aspektów rozwojowych. Bardzo często te podziały kompetencyjne, połączone z trudnościami wynikającymi z tradycyjnego podejścia do technologii, stanowią poważną barierę rozwoju nowoczesnej analityki.

Tradycyjne podejście do rozwoju infrastruktury polegało na tym, że dla każdej potrzeby technologicznej, która wynikała z prowadzonych projektów, kupowano niezbędny sprzęt. W skład listy zakupów wchodziły serwery, komputery, sprzęt dedykowany do backupów i tym podobne, wraz z niezbędnym oprogramowaniem, czyli systemami operacyjnymi, licencjami do oprogramowania biznesowego i innymi pomocniczymi narzędziami. Takie podejście powodowało narastanie złożoności zarówno w serwerowni, gdzie sprzęt znajdował się fizycznie, jak i w przestrzeni oprogramowania. Duże firmy były przekonane, że muszą samodzielnie zarządzać wszystkimi zasobami, utrzymywać je w działaniu, optymalizować wykorzystanie, jak też zarządzać przyrostem danych, użytkowników i generowanym przez nich ruchem. Wszystkie zadania wymagały sporo zaangażowania i wiele zasobów. Wewnętrzna organizacja utrzymująca infrastrukturę, pomimo starań zapewnienia wymaganej jakości obsługi, stawała się mało elastyczna i droga.

Pierwszą odpowiedzią rynku rozwiązań infrastrukturalnych była wirtualizacja. Wirtualizacja oznaczała nieco inną organizację zasobów sprzętowych i była dostępna dzięki specjalnemu oprogramowaniu zarządzającemu. Dało to pierwsze korzyści użytkownikom biznesowym i sponsorom finansującym technologię. Kolejnym krokiem było wykorzystywanie zasobów infrastrukturalnych u specjalizowanych partnerów zewnętrznych, dzięki temu przenoszono na nich trudności związane z operacjami na sprzęcie. Tak rozpoczął się konsekwentnie trwający trend wykorzystania chmury obliczeniowej dla celów biznesowych. Z czasem oferta usług przetwarzania w chmurze stawała się coraz bogatsza i bardziej dostępna. Kompetencje deweloperów w jej użyciu były coraz większe. Dostawcy, zmuszeni wzajemną konkurencją, proponowali coraz bardziej dopasowane do potrzeb użytkowników warianty cenników. Te wszystkie czynniki spowodowały, że zarządzanie usługami chmurowymi stało się specjalnością samą w sobie, ściśle powiązaną z rozwojem aplikacji biznesowych. Rozwój usług zaowocował skróceniem czasu budowy i modyfikacji rozwiązań. Dzięki chmurze uzyskujemy skalowalność i elastyczność zbudowanych rozwiązań. Poprawnie zaprojektowana architektura techniczna pozwala obsłużyć dynamiczne zmiany liczby użytkowników, bez konieczności ciągłego utrzymywania i rekonfigurowania wielkiej infrastruktury.

Ostatnie nowości dostępne na rynku rozwiązań chmury obliczeniowej dają deweloperom możliwość budowy rozwiązań, nawet bez zastanawiania się nad aspektami sprzętowymi. Są to rozwiązania „serverless”. Nazwa wcale nie oznacza, że nie ma w nich serwerów. Programista skupia się przede wszystkim na logice biznesowej, a firma zamiast kupować maszyny, nabywa określoną liczbę wywołań funkcji z logiką biznesową lub zapytań do bazy danych. Trzeba przyznać, że nadal istnieje opór deweloperów wobec wykorzystania rozwiązań chmurowych w obszarach analityki, najczęściej związany jest z brakiem wiedzy o tych możliwościach lub z przyzwyczajeniami. Pokonanie niechęci daje organizacji zwinność w wymiarze infrastruktury, co zdecydowanie wpływa na uzyskanie przewagi nad konkurencją.

Środowisko

Wszystkie dotychczas wymienione elementy (włącznie z danymi zasilaniami, analityką danych, modelami wsparcia decyzji i infrastrukturą), składające się na możliwości biznesowe, wchodzą w skład środowiska analitycznego. Środowisko nie może być tylko zbiorem elementów, które są wdrażane w kolejnych projektach, lecz powinno dobrze zorganizowanym ekosystemem. Taki ekosystem trzeba planowo rozwijać, ma być współpracujący, uzupełniający się i odpowiednio zoptymalizowany aby stanowił poprawnie współpracującą całość.

To piękne cele. Jak jednak dojść do tak opisanego stanu? Należy rozpocząć od zdefiniowania celu, któremu ma służyć środowisko analityczne? Ten cel to coś więcej niż suma celów biznesowych, o których była mowa wcześniej. Skupienie się jedynie na bezpośrednich korzyściach biznesowych, to najprostsza droga do budowy „potworka”, środowiska technicznego sprawiającego jeden z typowych problemów dla jego twórców, osób utrzymujących, używających lub finansujących.

Tworzenie zdrowego środowiska analitycznego interesuje jedynie tych decydentów, którzy wierzą w długoterminowy sukces — prawdziwych właścicieli i gospodarzy. Osoby zainteresowane krótkotrwałym efektem mogą spokojnie ominąć najbliższe rozdziały, jednak nie zachęcam do tego. Zdecydowanie warto stanąć w roli prawdziwego właściciela środowiska, ponieważ realizując długoterminowe cele, tworzymy platformę, która staje się inwestycją przynoszącą korzyść właścicielowi. Platforma staje się źródłem sukcesu i podstawą łatwiejszej, czy też efektywnej pracy dla firmy. Aby jednak tak się stało, należy dobrze przemyśleć całość i konsekwentnie wdrażać przyjętą strategię. Brak całościowego podejścia do architektury środowiska analitycznego jest najbardziej widoczny w przypadku większych organizacji, o większej złożoności, jednak będzie on równie skutecznie przeszkadzał w przypadku firm o mniejszej skali.

Prawdopodobnie nie ma kompletnego zestawu reguł, pozwalających uniknąć złej architektury. Aby przygotować się do zbudowania dobrej, należy pamiętać o ważnych czynnikach, które pomagają w dążeniu do tego celu. Poniżej przedstawiem propozycję rozwiązania tego zagadnienia, widzianą z perspektywy strategii architektury. Organizacja The Open Group proponuje usystematyzowane podejście do rozwoju architektury środowiska — ramy postępowania przedstawia rysunek 29.

Rys. 29: Framework TOGAF, The Open Group.

Framework TOGAF pomaga zdefiniować poszczególne kroki transformacji architektury. To dobre miejsce startu planowania ewolucji środowiska analitycznego. Pokazuje perspektywę strategiczną, w przeciwieństwie do wąskiej perspektywy jednego lub kilku projektów. Polecam głębsze zainteresowanie się tym podejściem po to, aby wykształcić strategiczne spojrzenie na transformację architektury.

Funkcja celu

Cele ustalone na poziomie poszczególnych projektów determinują, co w przypadku ich sukcesu zostanie wdrożone. Na poziomie całego środowiska należy odpowiedzieć sobie na pytania o cele bardziej globalnie. Powinny one być pochodną projektowanej w organizacji roli analityki i danych. Dla różnych firm cele te mogą różnić się znacznie. Poniżej ich przykłady. Są one zdefiniowane na poziomie wyższym niż poziom projektu, determinujących kierunki rozwoju całego środowiska analitycznego.

Przykłady celów:

— Wsparcie prototypownia nowych pomysłów.

— Szybkie wdrażanie nowych wymagań (ang.: time to market).

— Nacisk na jakość danych i dokładność przeliczeń.

— Tanie utrzymanie rozwiązań.

— Optymalizacja kosztów licencji.

— Optymalizacja pracy zespołu, automatyzacja.

— Konieczność wyłączenia elementów istniejącego środowiska.

— Optymalizacja systemów i ustalenie nowej architektury po połączeniu firm.

— Dostosowanie się do zmian prawnych, regulacyjnych powodująca istotne zmiany w środowisku analitycznym.

— Dostosowanie się do zmian otoczenia technologicznego lub wymuszonych zmian partnerów, dostawców.

— Decyzja o zmianie podejścia dot. realizacji prac, tzn. przejście na outsourcing bądź insourcing.

Po zdefiniowaniu celów architektonicznych, które wynikają ze specyfiki biznesu, o wiele łatwiej będzie podejmować decyzje projektowe czy też taktyczne. Kierunek zdefiniowany na wyższym poziomie, będzie wpływał na wybór jednej z kilku możliwych opcji rozwiązań projektowych. Z punktu widzenia projektu opcje mogą być równoważne, jednak z punktu widzenia strategii wybór konkretnej opcji będzie znaczący. W następnym rozdziale zajmiemy się przedmiotem strategii rozwoju architektury.

Strategia rozwoju architektury

Aby środowisko technologiczno-informatyczne efektywnie wspierało cele biznesowe, myśl projektanta czy architekta musi być spójna z potrzebami i celami biznesowymi organizacji. Ze względu na dynamikę zmian nie jest to jednak warunek wystarczający. Oprócz spójności z kierunkiem biznesowym, niezbędne jest aktywne przewidywanie, co będzie potrzebne na następnym etapie, co może jeszcze się przydać. Tylko antycypacja przyszłych potrzeb, czasami ich kreowanie, pomaga efektywnie przygotować się na ich nadejście.

Strategia często bywa rozumiana błędnie jako statyczny plan, podobny do planu pięcioletniego w ustroju socjalistycznym. Stratedzy w korporacjach niestety często ulegają mitowi niezmienności przyszłości i swojego wielkiego wpływu na nią. Aby efektywnie pracować na poziomie strategicznym, trzeba być niezwykle uważnym słuchaczem. Należy dokonywać skutecznej detekcji, zarówno wczesnych trendów w firmie, jak i w branży, co umożliwi pokazanie potrzeb. Musimy wiedzieć, jakie sygnały płyną z rynku narzędzi i sposobów pracy. Niezbędne jest także słuchanie problemów osób pracujących przy zwykłych projektach, realizujących podstawowe funkcjonalności. Słuchanie w tych wszystkich wymienionych wymiarach, sprowadza się do rozmów z wieloma osobami, w tym z szeregowymi pracownikami; to tu, a nie w gabinetach kadry zarządzającej, uzyskać można najcenniejsze informacje. Sprawny lider analityki potrafi rozmawiać z deweloperami, analitykami, architektami i użytkownikami. Jest obecny nie tylko blisko zarządu, ale także na piętrach, na których w pocie i znoju realizowane są projekty. Skutecznie oddziela informacje istotne od mniej ważnych. Pozyskuje je przy okazji innych działań i dzięki doświadczeniu i szerokiemu spojrzeniu potrafi je odpowiednio uwzględniać w planach organizacji. Nie jest to możliwe bez efektywnie rozbudowanej sieci kontaktów, wykraczającej poza jego departament lub komórkę organizacyjną, sięgającej do różnych poziomów organizacji, ale także poza nią.

Mając dostęp do kanałów informacji, zapewniających trafną wiedzę (aktualną i zweryfikowaną, dotyczącą szerokiego spektrum zagadnień), należy ją odpowiednio wykorzystywać. Oznacza to świadome zignorowanie tych informacji, które nic nie wnoszą, a zapamiętanie lub zanotowanie tych, które mogą się przydać później. Wyciągnięcie wniosków i uwzględnienie w bieżących akcjach powinno wpłynąć na plany średnio czy długoterminowe. Po przetworzeniu i analizie oraz podjęciu niezbędnych decyzji potrzebne akcje należy konsekwentnie wprowadzać w życie. Co to oznacza? Może oznaczać przekazanie wybranych informacji do konkretnego projektu. To sytuacja, w której lider staje się spoiwem łączącym oddzielne aktywności, a organizacja zaczyna działać holistycznie (wykorzystuje wzajemnie mocne strony działań uzupełniających się, choć toczących się daleko od siebie); pomaga to także zatrzymać działania „kanibalizujące się” lub redundantne. To niezwykle ważna sprawa.

Patrząc strategicznie, tylko dobrze i mądrze przetworzone informacje wejściowe, mające cechy wymienione już wcześniej, mogą zmienić strategię. Strategii nie zmienia postanowienie zarządu, samo jej ogłoszenie, czy potwierdzenie jej przez kilku ważnych przedstawicieli władz spółki. Efektywnie realizowana i dostosowywana strategia zmienia się poprzez drobne decyzje. To podejście, które jest skuteczną i efektywną realizacją koncepcji agile na poziomie strategicznym. W określeniu jakościowym zmiany kierunku strategicznego nie powinno uczestniczyć zbyt wiele osób. Idealnie, jeśli jest to wąska grupa osób, która ma dostęp do wszelkich informacji niezbędnych do tego. Czasem zmiany wymagają zaangażowania kolejnych osób, które mogą wnieść nowe spojrzenie. Ważne jest, aby osoby te czuły się właścicielami efektów swoich decyzji. Takie przeświadczenie jest częścią sukcesu planowania strategicznego. Nie sprawdzają się tu konsultanci, którzy charakteryzują się podejściem projektowym do prac — realizują zadanie, które ma swój początek i koniec. Konsultant może być jedynie pomocnikiem decydenta.

Podsumowując, decyzje o zmianie kierunku działania najczęściej nie zapadają w szklanych gabinetach, ale na korytarzu, na spotkaniu, podczas warsztatu. Wtedy, kiedy mózgi ludzkie nie boją się używać logiki, korzystając z dostępnych danych wejściowych i wyciągniętych z nich wniosków.

Wszelkie komunikaty informujące o nowych kierunkach to już informacja opóźniona. Firma, czy też jednostki zawsze realizują pewną strategię, na każdym poziomie. Kierunek wynika z uwarunkowań otoczenia, zestawu ludzi i wielu innych czynników, jednak nie zawsze jest on zgodny z oczekiwaniami. Rolą CDO jest poprawnie zidentyfikować prawdziwą, realizowaną, a nie jedynie ogłoszoną strategię, jak również zidentyfikować osoby decyzyjne w temacie strategii i w zależności od celów firmy pozytywnie na nią wpływać. Wpływ ten będzie realizowany na różne sposoby, jednak powinien być skuteczny. Oddziaływanie na kierunek strategiczny, czy to bezpośrednie, czy też z udziałem zespołu lub innych osób, to kluczowe zadanie w firmie, która chce efektywnie wykorzystywać dane.

Rys. 30: Dekompozycja strategicznego kierunku firmy na poszczególne etapy działania w wymiarze biznesowo-technicznym.

[1] Szef informatyki, ang.: CIO -Chief Information Officer

[2] Extensible Markup Language, https://en.wikipedia.org/wiki/XML

[3] JavaScript Object Notation, https://en.wikipedia.org/wiki/JSON

[4] ETL, z ang.: Extract, Transform, Load

[5] Atrybuty big data pochodzące od liter „V”, ang.: Velocity, Variety, Volume, Value

[6] OLTP: ang.: on-line transaction processing

[7] OLAP: ang.: on line analytical processing

[8] MPP: ang.: massive pararell processing

[9] MS Analysis Services, https://docs.microsoft.com/en-us/sql/analysis-services/analysis-services?view=sql-server-2017

[10] “MapReduce: Simplified Data Processing on Large Clusters”, Jeffrey Dean and Sanjay Ghemawat, Google whitepaper

[11] noSQL, ang.: not only SQL

[12] ang.: in-memory

[13] https://en.wikipedia.org/wiki/Bill_Inmon

[14] Data lake — system lub repozytorium danych przechowywanych w naturalnej postaci i modelu, zawiera dane tabelaryczne, często także hierarchiczne oraz binarne. Brak odpowiedniego zarządzania takim systemem powoduje, że staje się zsypem danych nad którym trudno zapanować i uzyskać z niego pożytek biznesowy.

[15] SaaS — ang.: Sofrware as a Service

[16] D3js: nazwa pochodzi od: data driven documents + javaScript, czyli d3js, www: https://d3js.org/

[17] Predictive Model Markup Language — https://en.wikipedia.org/wiki/Predictive_Model_Markup_Language

[18] CRISP — ang.: Cross-Industry Standard Process for Data Mining, Shearer C., The CRISP-DM model: the new blueprint for data mining, Data Warehousing (2000); 5:13—22.

[19] https://www.h2o.ai/

[20] Machine Learning Yearning, Andrew Ng

[21] Szkolenia są udostępnione na platformie https://www.deeplearning.ai/

[22] Sztuczna inteligencja — ang.: Artificial Intelligence

[23] ang: Narrow Artificial Intelligence

[24] ang. Application Programming Interface

[25] ang: chat bots

[26] https://www.tensorflow.org/

[27] https://mxnet.apache.org/

4. Współpracujące zespoły

Przeszliśmy w ramach tej książki przez najważniejsze aspekty biznesowe i techniczne, które powinny pomóc CDO w pracy nad wykorzystaniem danych do celów biznesowych organizacji. Gdybyśmy jednak zakończyli w tym miejscu, nie mielibyśmy kompletu ważnych elementów. Zaplanowalibyśmy idealną strategię, dopasowaną do potrzeb firmy, pięknie wpisującą się w otoczenie rynkowe. Zabrakłoby jedynie … jej realizacji. Cały plan bez wykonania jest jedynie zapisem na papierze. Aby osiągnąć zaplanowane korzyści, należy bezwzględnie przejść do realizacji. Do egzekucji strategii potrzebne są zespoły, struktura i organizacja projektowa. Bez nich możemy skończyć tylko i wyłącznie na planach i na pięknych slajdach. Zespoły i ich efektywna organizacja daje szanse na przejście od planu do realizacji strategii. Tylko jej wdrożenie daje profity.

Bardzo często brak holistycznego podejścia do organizacji zespołów kończy się na realizacji jednego sztandarowego projektu. Udaje się go zrealizować pomimo braku zapewnienia całościowej organizacji. Dzieje się tak dlatego, że w pewnym miejscu znaleźli się kompetentni i dobrze dobrani ludzie, i to oni doprowadzili do sukcesu w wąskim zakresie. Celem kolejnego rozdziału jest przedstawienie sposobów, kroków i metod maksymalizujących szanse na pojawienie się dobrych rezultatów, nie tylko w pojedynczych miejscach, ale jak najszerzej, w całym realizowanym programie wykorzystania danych w firmie.

Role

Do realizacji projektów i wybranych inicjatyw potrzebujemy kompetentnych ludzi. Rozpocznijmy od próby definicji ról, które będą nam niezbędne. CDO najczęściej startuje od pewnego zestawu osób obecnych w organizacji, często zajętych ważnymi operacyjnymi czynnościami. Pracownicy są już przydzieleni do zadań i obowiązków, wynikających z ich kompetencji i indywidualnej historii w firmie. Rzadkością jest sytuacja, choć i takie się zdarzają, w której lider rozpoczynający pracę ma za zadanie zatrudnić cały zespół z rynku. Aby odnaleźć się w takiej sytuacji, jednym z ważniejszych działań jest identyfikacja, kto co potrafi i jaką ma motywację do pracy. Oczywiście to zadanie należy realizować równolegle z innymi, które opisuję w ostatnim rozdziale.

Na kogo zwracać uwagę? Jakich osób szukać? Może takich, które widziały porażki i sukcesy niejednego projektu, posiadają gotowe modele dające wiele odpowiedzi. Nie wszyscy liderzy mają tak bogate doświadczenie, by przewidzieć kto, w jakiej roli i na jakim etapie będzie pomocny, a kiedy niezbędny do realizacji stawianych celów rozwoju obszaru danych i analityki. Często problem złego doboru pracowników jest niezwykle wyraźny. Osoby, które mogłyby pomóc i posiadają przydatne kompetencje, nie są efektywnie wykorzystane do programów transformacyjnych. Takie osoby stają się widzami, obserwują zmagania innych, gorzej przygotowanych do tego zadania. Bardzo często opuszczają firmę. Aby uniknąć takich sytuacji, zacznijmy od skupienia się na kompetencjach szczególnie ważnych dla szeroko rozumianego tematu danych.

Wnikliwy słuchacz

Rozpocznę być może niestandardowo. Uważam, że podstawową kompetencją, która będzie miała znaczenie dla sukcesu transformacji jest … umiejętność słuchania. Brzmi to może dziwnie, jednak to niezwykle ważne, aby dobrze rozumieć procesy zachodzące w firmie, szybko je poznawać i identyfikować miejsca wymagające poprawy i jednocześnie będące możliwe do zmiany. Dobry słuchacz zadaje trafne pytania. Pytania, które realnie drążące problemy biznesowe, techniczne lub inne związane z danymi. Pytania dotykające problemów na różnych poziomach. Umiejętność analizy zjawisk to niezwykle wartościowa kompetencja, która będzie wykorzystywana w wielu miejscach. Idealnie byłoby, gdyby każdy pracownik komórki, czy też departamentu analitycznego posiadał taką umiejętność. Oczywiście nie żyjemy w świecie idealnym i nie zawsze uda się doprowadzić do takiej sytuacji, jednak taki jest cel. W tym kierunku powinny być ułożone szkolenia, a kompetencja ta winna być zdecydowanie nagradzana. Pracownicy charakteryzujący się wnikliwością, umiejętnością drążenia i słuchania powinni stanowić trzon zespołu podległego lub współpracującego z CDO na różnych poziomach.

Osoba z kontaktami

Kolejna przydatna cecha to umiejętność pozyskiwania, utrzymywania i wykorzystywania dobrych kontaktów, zarówno wewnątrz organizacji, jak i z osobami różnych współpracujących firm. Jednostka pracująca na danych, zbierająca dane, wykorzystująca je dla całej firmy lub ekosystemu firm, nie może być izolowana. To przepis na klęskę. Nie może być sytuacji, w której za kontakty z „zewnętrznym światem”, czyli z różnymi komórkami biznesowymi, odpowiedzialny jest jedynie szef lub wąska grupa integratorów. Idealna sytuacja — każdy jest sprzedawcą produktu, który oferuje analityka i każdy jest poszukiwaczem nowych potrzeb. To podejście może być odbierane często bez większego zrozumienia, jednak daje ono szansę lepszego dostosowanie się do potrzeb odbiorców. Wielu zdarzeń nie da się przewidzieć, przykładem tego jest nieprzewidywalny i stale napływający strumień nowych potrzeb. Często nie jesteśmy w stanie określić dokładnie — kiedy, który z wartościowych pomysłów okaże się niezbędny w naszej organizacji. Faktem jest, że realne potrzeby nie powstają w gabinetach top managementu. Gdy tam trafią, mają już za sobą długą drogę — startując od osoby, która ma problem lub pomysł poprzez mniejszą lub większą hierarchię firmową. Umiejętność systematycznego identyfikowania takich przypadków to niezwykle istotna funkcja całego zespołu. Aby zespół rzeczywiście ją realizował, musi mieć postawione odpowiednie cele. Ich wyznaczenie oraz selekcja osób, które mają realną szansę je zrealizować, to właśnie rola lidera. Zespół będzie realizował je za pomocą sieci formalnych i nieformalnych powiązań z odbiorcami, czyli z osobami potrzebującymi naszej pomocy, wsparcia, wiedzy i podejścia. Sieć powinna zostać w pewnym sensie pozyskana poprzez zaangażowanie osób, już na starcie dobrze rozumiejących się z resztą organizacji. Budowa sieci powiązań od zera wymaga więcej wysiłku, jednak często nie ma innej możliwości.

Osoba rozumiejąca dane

Dwie poprzednie kompetencje, choć niezwykle ważne, nie wystarczą, by osiągnąć sukces w produktywnym wykorzystaniu danych. Do zestawu cech trzeba dodać kolejną, podstawową — samą znajomość danych i technicznego podejścia do nich. Idealnie, gdy znajdą się osoby, które kochają pracę z danymi i innej sobie nie wyobrażają, Tacy istnieją! Często można ich spotkać wśród analityków systemowych lub w zespołach raportowych. Zajmują się tam pozyskiwaniem danych z dostępnych baz. Można na nich trafić w zespołach analitycznych, pracujących na rzecz rozmaitych komórek biznesowych. Zazwyczaj są to osoby znające przynajmniej w podstawowej mierze język SQL i używające go na co dzień. Poprzez realizację potrzeb raportowych organizacji nabywają, niejako przy okazji, wiedzę na temat struktur danych, relacji i ta, nie zawsze uświadomiona, kompetencja staje się ważna dla normalnego, operacyjnego funkcjonowania sekcji, w których na co dzień pracują. Pracownicy nabywają umiejętność myślenia przez pryzmat modeli, relacji i sposobów pozyskiwania danych. Dane i informacje to podstawowy surowiec, na którym pracują. Nie od razu są w stanie modelować je na przyszłe potrzeby, jednak w bieżącej sytuacji odnajdują się najczęściej znakomicie, dlatego to skarbnica wiedzy na temat aktualnego stanu danych w firmie.

Deweloper myślący w kategoriach architekta

Kompetencje, wymienione do tej pory, pozwalają na realizację raportów z wielu obszarów, zadanie ważnych pytań biznesowych i nawet znalezienie odpowiedzi. Jednak jeszcze nie dadzą firmie czegoś ważnego — narzędzia lub platformy operacjonalizującej, czy też automatyzującej taki proces. Sytuacja diametralnie zmienia się, gdy w zespole znajdą się osoby, które potrafią dodatkowo stworzyć rozwiązanie zgodne z obowiązującym stanem wiedzy o budowie systemów IT. Takie rozwiązanie ma szanse być wkładem w całościową architekturę środowiska analitycznego i być użytecznym dla wielu potrzeb. Budowa rozwiązań, poprzez wykorzystanie odpowiednich technologii dostępnych na rynku, prowadząca przez optymalny dobór środków do celów biznesowych a następnie układanie tych rozwiązań w architekturę i planowanie jej ewolucji, to wszystko praca, budująca wartości firmy. To dzięki dobrze zaplanowanej i zoptymalizowanej części deweloperskiej w wielu dynamicznie rozwijających się firmach panuje przekonanie o tym, że oprogramowanie będzie miało kluczowe znaczenie w walce konkurencyjnej[1]. Dzięki nowoczesnemu oprogramowaniu tworzymy szansę przejścia z analityki będącej podejściem rzemieślniczym o bardzo ograniczonym zasięgu do jej w pełni industrialnej wersji.

Wizjoner, integrator, modelarz i architekt procesów biznesowych

W tytule pojawia się kilka określeń dla roli, czytając je nasuwać się może wspomnienie o wszechstronnych ludziach renesansu. Niektórzy uważają, że osoby o tak szerokim zakresie kompetencji nie istnieją. Jednak to właśnie dzięki efektywnemu CDO i jego wiedzy można taką osobę wyszukać i ukształtować. Celem i produktem jej działania nie będą raporty, rozwiązania, czy slajdy. Są one jedynie środkami służącymi dla wzrostu efektywności organizacji, lepszego podejmowania decyzji, oszczędności w danym obszarze. Rolą takiego integratora jest zebranie różnych dostępnych cegiełek, czy też komponentów i złożenie z nich wartościowego dla organizacji rozwiązania obejmującego zarówno technologię, dane jak i procesy biznesowe.

Integrator powinien wszystkim wiedzieć, jakie problemy nurtują organizację, efektywnie słuchać i mieć odpowiednie kontakty. Niezbędnie powinien znać możliwości technologii, danych, przynajmniej w stopniu pozwalającym na podejmowanie błyskawicznych decyzji o możliwości bądź braku możliwości realizacji pewnych scenariuszy. Musi mieć zdolność szacowania i planowania projektów, określania korzyści biznesowych wynikających z modyfikacji istniejącego sposobu działania. Dzięki ekspresowemu trybowi działania kluczowe decyzje bądź rekomendacje decyzji podejmowane są bardzo szybko i najczęściej trafnie. To w umysłach takich osób realnie podejmowane są operacyjne działania, decyzje kierunkowe i to tu decyduje się, w którą stronę rozwijana jest analityka. Rolą CDO nie może być obezwładnianie decyzyjności integratora, ale ciągłe wzbogacanie możliwości jego pracy. To dzięki wykształceniu, a często „zbudowaniu” takich osób z wizją swojej pracy i obszaru, CDO będzie odnosił sukcesy. Centralizacja decyzji, która kusi wielu decydentów nie jest rozwiązaniem. Ze względu na złożoność wszystkich aspektów, które opisuję w tej książce, przepisem na efektywne decydowanie i realizację tych decyzji jest autonomia. Autonomia w ramach przekazanej odpowiedzialności powinna być obecna we wszystkich wymienionych do tej pory rolach, jednak w przypadku tej roli jest ona niezwykle ważna. Często organizacje identyfikują tę rolę z istniejącymi managerami, którzy zarządzają ludźmi. Nie jest to takie łatwe, chociaż nie należy wykluczać i takiego połączenia. Jednak liniowe zarządzanie personelem i integracja biznesowa to zupełnie inne role.

Manager

Nie sposób wyobrazić sobie większej organizacji bez osób zarządzających. Wbrew wielu trendom podkreślającym rolę ekspertów, osoby zarządzające nadal stanowią ważną grupę w sytuacji, gdy firma pracuje w większej skali. Dostosowywanie organizacji do dynamicznie zmieniających się potrzeb rynku, reagowanie na nieprzewidziane zdarzenia, odpowiedzialne rekonfiguracje zespołów to jedynie przykładowe zadania managerów. Nie każdy, sprawdzony w innym miejscu manager poradzi sobie z zadaniami czekającymi go w nowoczesnym centrum analityki. Doświadczenia ze stabilnych hierarchicznych struktur, z dobrze ustalonymi zakresami obowiązków i oczekiwanie takiej stabilności w analityce może być przeszkodą.

Jakie kryteria powinien spełniać manager, aby organizacja ludzi zajmujących się danymi osiągnęła sukces? Przede wszystkim należy zacząć od założeń, dających maksymalną szansę sukcesu i na tych założeniach budować koncepcję organizacji projektowej.

Pierwsze założenie jest takie, że pracując na nie zawsze dobrze określonych problemach biznesowych, połączonych z dużą paletą algorytmów i specyficzną technologią, mamy większe wymagania wobec pracowników niż w przypadku klasycznych rozwiązań IT. Analityka bazuje na danych i pracuje z o wiele większym udziałem różnych komórek biznesowych. Ta charakterystyka powoduje, że trzeba efektywnie dostosowywać się do rozpoznawanych potrzeb i nie można pozwolić pracownikom na bezpieczną stabilizację. Zmiana to termin, z którym w analityce i w pracy na danych spotykamy się codziennie.

Takie otoczenie bezpośrednio implikuje sposób, w jaki warto budować organizację. Podstawowym założeniem tego zadania, sprawdzonym na wielu rzeczywistych przypadkach, jest oparcie się na produktach i rozwijających je autonomicznych zespołach. Temat rozwinę w dalszych rozdziałach, jednak założenie to oznacza, że do organizacji będzie niezbędny określony profil osób zarządzających — rola zbliżona scrum masterów, pomagających zespołom i nadająca rytm ich pracy. Opis roli scrum mastera jest znany i można zapoznać się z nim chociażby w książce SCRUM[2].

Innym typem managerów niezbędnych do prawidłowego funkcjonowania organizacji, są osoby spełniające funkcje bliskie klasycznej definicji managera. Myślę tu o osobie identyfikującej się liniowo ze swoim zespołem, dbającej o nich, pilnującej ważnych spraw kadrowych i dobrze rozumiejącej, jakie cele realizują w wypełnianych rolach projektowych. Manager musi dobrze rozumieć strategię analityki. Jednak pewne tradycyjne zadania managerskie są mu w takiej organizacji odebrane i zostają przypisane do projektów, gdzie pracownik jest członkiem zespołu projektowego lub do produktów, w których pełni on rolę rozwojowo-utrzymaniową. Tak rozdzielona rola managera z pomyślnie sprawdza się w dynamicznie rozwijających się organizacjach. Podobne ułożenie organizacji daje szansę, niestety jedynie szansę, a nie gwarancję, na elastyczne zarządzanie kilkoma ważnymi aspektami, o których nie wolno zapomnieć. Są nimi:

— Klasyczne zarządzanie zespołami i pokrycie funkcji HR, włączając w to zatrzymanie pracowników w firmie, rekrutację, przyciągnięcie najlepszych do firmy.

— Zarządzanie celem produktu, włączając w to wizję produktu obecną w głowie właściciela produktu i wszelkie aspekty eksploatacyjne dotyczące produktu, realizowane w zespole.

— Zarządzanie architekturą rozwiązania i spójnością tej architektury z innymi elementami organizacji.

Tak zdefiniowana rola osób zarządzających pozwala komórce analitycznej rozwijać się wtedy, gdy będzie to wymagane i elastycznie dostosowywać się do potrzeb firmy i rynku. Trzy wymienione aspekty będą w takiej organizacji rozłożone pomiędzy managerów różnego rodzaju. Daje to szansę na zarządzenie każdym z nich oraz umożliwia skorzystanie z unikalnych kompetencji i silnych stron poszczególnych managerów. Tak przedefiniowana rola osób zarządzających dobrze sprawdziła się w niektórych firmach, stały się one liderami rynku. Na rysunku 31 zaprezentowano przykładową, płaską strukturę realizująca tę koncepcję.

Rys. 31: Równolegle działające zespoły deweloperskie wraz z trzema instancjami zarządzania różnymi aspektami ich działalności — zarządzanie liniowe, zarządzanie produktem i zarządzanie architekturą/technologią.

Talenty — skąd je brać?

Schematy organizacyjne perfekcyjnie działających firm wypełnione są kompetentnymi osobami, składającymi się na efektywnie działającą strukturę. Tak przynajmniej postrzegana jest organizacja odnosząca sukces, nie widać w niej słabych punktów. Jak wypełnić struktury takimi osobami? Pamiętamy z wcześniejszych rozdziałów, że ważne są nie tylko techniczne, czy biznesowe kompetencje, ale także wiedza o rynku i o samej organizacji. Kompetencje, mając odpowiedni budżet i czas, można pozyskać bezpośrednio zatrudniając nowych pracowników z rynku, dostępni tam są najlepsi specjaliści i często nie unikniemy sytuacji, w której będziemy musieli sięgać po takie osoby, często płacąc sporo. Pamiętajmy jednak, że nawet niezwykle drogi pracownik nie gwarantuje odnalezienia się w kontekście danej firmy czy zespołu.

Aby zwiększyć szanse na skutecznie i płynnie działającą organizację, warto pozyskiwać talenty z wielu źródeł — zarówno z rynku, z innych części organizacji, oraz budować je, bazując na osobach obecnych w firmie. Na budowę talentów w firmie można liczyć, gdy posiadamy dojrzałych liderów. Poziomy dojrzałości liderów doskonale opisał John Maxwell[3]. Filozofia prezentowana przez tego autora jest niezwykle wartościowa także dla CDO. Idealnym liderem na najwyższym — piątym poziomie, jest osoba, która skutecznie i efektywnie buduje kolejnych liderów.

Rys. 32: Poziomy przywództwa według Johna Maxwella.

Pracując z liderami rozumiejącymi cele firmy i identyfikującymi się z nimi, mamy szansę na zbudowanie zespołów, nawet bez mocnej pozycji startowej. Wartością lidera jest umiejętność tworzenia ze zbioru dostępnych osób, współpracującego zespołu, wkomponowanego w organizację i realizującego cele, które zostały mu postawione.

Gdy brakuje pracowników idealnych, lider potrafi skorzystać z osób dostępnych w firmie i stawić czoło wyzwaniom. Siła lidera przejawia się w aktualnej wiedzy o ludziach zatrudnionych w organizacji, ich umiejętnościach i brakach, właściwym motywowaniu, by niemożliwe stało się realne. Warto poznawać swoich ludzi, warto znać także współpracowników. W nowoczesnym podejściu do zarządzania pracownicy traktowani są na równi z klientem, bez zaangażowania pracowników nie ma firmy. Warto pamiętać o potrzebach członków zespołu, o pracy odpowiedniej dla nich i o umiejętnościach, które oferują. Niewykorzystanie ich to wielka strata dla firmy. Często zdarza się, że firma nie w pełni korzysta z kompetencji danej osoby, wtedy przy aktywnym na rynku pracy pracowniku, pojawia się ryzyko odejścia do innej firmy, w której uzyska szansę na ich wykorzystanie. Brak lidera, który będzie w stanie dostrzec taką sytuację i skutecznie zareagować, może być kosztowny. Koszty te nie są widoczne od razu, jednak wpływają negatywnie na działanie organizacji i prowadzą do jej systematycznego osłabiania.

Najwyższy poziom przywództwa to liderzy, którzy kreują innych liderów i taki poziom jest optymalnym poziomem dla CDO. Wybór, czy też budowa liderów przez szefa analityki, połączona z odpowiednim doborem celów, to jedno z ważniejszych jego zadań. Efekty decyzji w tym obszarze będą pojawiały się od razu, jednak ich zauważenie zwykle wymaga wielkiego doświadczenia i przenikliwości. Tym właśnie różnią się szefowie działający efektywnie od tych, którzy nie mają wyników — potrafią dostrzec problemy, gdy są jeszcze nie znaczące i zapobiec ich rozrostowi, ale także zauważyć szanse i potencjał drzemiący w ludziach, niewidoczny dla innych.

Poszukiwanie modelu współpracy

Jakie powinno być miejsce analityki w firmie? Czy powinna być to centralna jednostka, grupująca kompetentne osoby w organizacji, czy też funkcja rozproszona, obecna w wielu departamentach? Takie pytanie zadają sobie prezesi firm. Często odpowiadają na nie intuicyjnie, pozwalają, aby sprawy potoczyły się własną dynamiką. Jak doradzić CEO w tej sprawie? Jak wyglądają doświadczenia firm, które próbowały wcześniej odpowiedzieć sobie na to pytanie?

Istnieją zarówno przykłady firm, w których funkcjonuje model scentralizowany, jak i przykłady drugiego modelu. Oba z nich zostały przedstawione na poniższym rysunku.

Rys. 33: Analityka rozumiana jako zespół osób posiadających kompetencje i świadczące takie usługi dla swoich organizacji, rozproszona między wszystkimi jej potrzebującymi departamentami firmy.

Rys. 34: Funkcja analityki jako centralna komórka świadcząca wewnętrzne usługi dla organizacji.

Te dwa skrajne modele mają swoje plusy i minusy. W modelu centralnym niewątpliwą korzyścią jest naturalna wymiana wiedzy dotyczącej technologii, technik pracy, metod i dostępnych danych. Osoby, realizujące podobne zadania, zostają zebrane w jednej komórce organizacyjnej. Taka centralna komórka odpowiada za realizację potrzeb analitycznych dużej części firmy. Integruje potrzeby, zauważa ich podobieństwo, staje się łącznikiem między departamentami wcześniej niewspółpracującymi ze sobą. Pojawia się wiele korzyści dla firmy. Sukces centralnego departamentu analityki prowadzi naturalnie do wzrostu popularności jego usług w organizacji. Oznacza większą liczbę zadań, co kończy się tym, że przy tych samych zasobach wiele z nich czeka w kolejce do realizacji. Zakres prowadzonych przesuwa się w kierunku potrzeb globalnych i wspólnych dla całej firmy, przez co nie zawsze odpowiada priorytetom wybranych interesariuszy. W sytuacji braku możliwości realizacji poszczególnych potrzeb, ustępują one celom wspólnym. Centralna analityka przestaje przez to być postrzegana przez wielu jako ta, która efektywnie realizuje zgłaszane do niej prace. W wyniku tego powstają tarcia i organizacja sama znajduje obejścia tych problemów. Dzieje się to albo poprzez podbijanie priorytetów zadań przez silniejsze jednostki lub prowadzi do odbudowy lokalnych jednostek analitycznych. Najczęściej organizacja testuje oba rozwiązania. Możliwe oczywiście, że znajduje jeszcze inne. Zaczynają pojawiać się głosy, że centralny departament wprawdzie realizuje wspólne potrzeby, ale nie opłaca się korzystać z jego pomocy.

Jeśli nawet nie pojawią się oficjalne głosy o ponownym powrocie do lokalnych komórek analitycznych, to proces taki się powoli rozpoczyna. W komórkach biznesowych pojawiają się rekrutacje na stanowiska istniejące już w centralnej analityce. Jako argumenty posłużą te właśnie niezrealizowane potrzeby i fakt lepszego zrozumienia biznesu. Znaczenia nabierają argumenty mówiące o tym, że ważna jest bliskość pracy w komórce biznesowej, realizującej wybrane procesy operacyjne na co dzień. Jak uniknąć takiego scenariusza? Poświęcam temu kolejny rozdział.

Hub and spoke

Lekiem na takie trudności organizacyjne, sprawdzającym się w wielu przypadkach, jest rozwiązanie hybrydowe. Łączy ono pozytywne cechy funkcji centralnej i dobrą współpracę z efektywnie działającymi lokalnie komórkami biznesowymi. Model taki znany jest jako „hub and spoke”.

Rys. 35: Funkcja analityki centralnej połączona ze współpracującymi, kompetentnymi jednostkami biznesowymi posiadającymi część zadań analitycznych.

Rozpocznijmy od podziału. Które funkcje warto rozwijać centralnie? Na pierwszym miejscu warto wymienić najbardziej oczywiste — wszystkie funkcje wspólne dotyczące danych, czyli zagadnienia podobne do siebie i jednocześnie rozwiązywane w wielu miejscach firmy. Do zbioru takich działań należy zaliczyć opiekę nad infrastrukturą, niezależnie od tego, czy jest ona utrzymywana w chmurze, czy na własnych maszynach. Kolejnym tematem centralizacji jest zarządzanie i optymalizacja licencji na oprogramowanie. Zarządzanie rozproszone takimi składnikami przeważnie nie daje żadnych korzyści, dlatego warto je centralizować. Kolejnym elementem, który zdecydowanie powinien być centralizowany jest integracja danych. Budowa centralnej bazy danych, hurtowni danych lub rozwiązania data lake, w zależności od decyzji architektonicznej, powinna być procesem centralnym z odpowiednio ułożoną współpracą z komórkami biznesowymi. Raz zapoczątkowane procesy integracji danych analitycznych, zrobione zgodnie ze sztuką, będą dawały wymierne korzyści firmie przez długi czas. Następnym elementem, który musi być zarządzony centralnie jest architektura analityki. Myśl przewodnia powinna ogarniać całe środowisko, a jego projekt musi być realizowany w taki sposób, aby komunikacja między jego komponentami, standardy deweloperskie, zasady wymiany danych i pryncypia biznesowe były wspólne i ustalone w ramach konsensusu.

Ustalenie pryncypiów architektury i kierunku rozwoju środowiska to kolejny ważny punkt styku między centralną analityką a resztą firmy. Każdy dyktator niesłuchający narodu będzie musiał prędzej czy później upaść, podobnie jest w analityce. Jeśli nie ma wspólnego kierunku i realne potrzeby nie znajdą odzwierciedlenia w pracy centralnego departamentu analitycznego, prędzej czy później stanie się on biznesowo martwy. To najgorszy wariant i nie wolno do takiego stanu dopuszczać.

Aby tak się nie stało, warto poruszyć głębiej sprawę współpracy między hubem analitycznym a komórkami biznesowymi. Współpraca jest niezbędna ze względu na wiele wcześniej wymienionych zadań, które powinny być jednak sterowane centralnie.

Pierwszym zadaniem, wartym zainteresowania, jest zbieranie wymagań, począwszy od wymagań biznesowych, po integrację wielu potrzeb i poszukiwanie szans wynikających z rosnących możliwości technicznych. Komórki biznesowe, zajęte swą operacyjną pracą, nie mają czasu ani dużych możliwości na budowę zaawansowanych rozwiązań bazujących na danych i wykraczających poza najprostsze sprawy. Tak więc pierwotna forma współpracy to przekazywanie wymagań, dyskusja o aspektach biznesowych i na temat danych, które dotyczą zmienianych procesów biznesowych. Ta wiedza jest największa właśnie wśród ludzi pracujących na co dzień przy procesach biznesowych. W optymalnym układzie wiedza o biznesie i często o danych jest przyniesiona przez współpracujące jednostki biznesowe i wykorzystana w projekcie, w którym pracują ramię w ramię osoby z biznesu i osoby z centralnej analityki. Te drugie wnoszą do współpracy wiedzę o metodach i technikach przetwarzania danych, o optymalnych architekturach przechowywania i przetwarzania danych, ale także wiedzę biznesową, którą posiadły wcześniej przy okazji innych projektów. Początkowo efekt hub’u, czyli wymiana wiedzy biznesowej nie ma miejsca, jednak po kilku projektach realizowanych dla wielu odbiorców biznesowych, po zintegrowaniu na poziomie warstwy danych wielu źródeł informacji w korporacji, współpraca hub&spoke zaczyna odgrywać prawdziwie kluczową rolę w organizacji.

Jakie zadania nie powinny być zabierane z kompetencji jednostek biznesowych? Po efektywnym ustaleniu współpracy, należy ją przede wszystkim stale monitorować. Cele muszą uwzględniać specjalną rolę komórek biznesowych, ich zadaniem jest samodzielność w pracy na danych. Nie chodzi tu o budowę rozwiązań, ale wykorzystanie danych do podejmowania decyzji na różnych etapach procesów. Mogą to być na przykład decyzje wymagające wielowymiarowej analizy szerokiego zakresu danych. Takie analizy powinny odbywać się w komórkach biznesowych, a jedynie w przypadku braków danych, braków funkcjonalności lub konieczności modyfikacji produkcyjnych rozwiązań analitycznych, pojawia się praca dla centralnych lub mieszanych zespołów projektowych. Operacyjna praca na danych musi być domeną komórek biznesowych. Decyzje podejmowane na podstawie wniosków z danych czy też decyzje automatyczne nie powinny wymagać angażowania osób z komórki centralnej. Oczekiwanie na osoby dostępne do pomocy nad analizą gotowych danych jedynie przeszkodzi w efektywnej pracy. Takie zadania muszą być realizowane samodzielnie w biznesie. Trend pozostawiania tej pracy w komórkach biznesowych łączy się znakomicie z kierunkiem, w którym ewoluują narzędzia wspierające analitykę w firmie. Zakładają one samoobsługę w wielu wymiarach pracy na danych. Samoobsługa[4] jest korzystnym trendem, jednak wiąże się ze sporym architektonicznym i biznesowym ryzykiem. Jeśli nie jest ona osadzona w zdrowej, centralnej architekturze, której integralną częścią są dostępne, zintegrowane dane, samoobsługa doprowadzi do tworzenia wielu podobnych rozwiązań w wielu miejscach w firmie, co będzie skrajnie nieefektywne.

Podsumowując, współpraca między centralną analityką a komórkami biznesowymi potrafi pięknie wykorzystać najlepsze cechy obu stron. Taka współpraca zależy od ludzi. Aby odnaleźć miejsca, w których współpraca będzie najszybciej się rozwijała, należy podchodzić do niej jak do dwóch stron kontraktu, w którym strony wzajemnie mają sobie do zaoferowania coś wartościowego. Zasobami, które stają się przedmiotem kontraktu może być znajomość pewnej biznesowej domeny danych, którą zna tylko wybrana garstka osób, może też być znajomość technologii. Zespoły pochodzące z różnych miejsc organizacji w naturalny sposób różnią się od siebie i ta różnorodność wykorzystana biznesowo jest wielką wartością.

Nawiązanie owocnej współpracy między centralą a jednostkami biznesowymi nie jest łatwe i wymaga od szefa analityki specjalnych zdolności komunikacyjnych i negocjacyjnych. Niezbędna jest także równoległa praca nad wspólnym celem, prowadzona przez liderów organizacji i ekspertów. Odnalezione cele i zasady współpracy wymagają specjalnego komunikowania, zarówno z zespołem jak i z managementem. Jest to niezwykle ciekawa i wielowymiarowa układanka, której złożenie daje niewiarygodny efekt dla organizacji. Nie gwarantuje to oczywiście, że organizacja nie będzie wymagała dalszego wysiłku transformacyjnego i wystarczą „klasyczni” managerowie, widzący swoją rolę jedynie jako „administratorów” biznesu[5]. Nie wolno spoczywać na laurach i przestawać korzystać z napędu transformacyjnego, zmieniającego analitykę. Należy skorzystać z dynamiki dostosowywania firmy do aktualnych potrzeb.

Polityka

Bardzo często słowo polityka kojarzy się źle. Szeregowi pracownicy unikają polityki lub przynajmniej tak deklarują. Dlaczego poruszam ten temat w książce, której celem jest pomoc Chief Data Oficerowi w pracy? Otóż polityka to wszystko, co nas otacza, to sytuacja, w której nasze cele zderzają się z celami innych osób. Polityka jest obecna w strategicznych decyzjach mocarstw, w taktycznych codziennych krokach szefów rządów, ministrów, ale także przy rodzinnym stole podczas porannego śniadania — w sytuacji, gdy cele dzieci różnią się od tego, czego chcą rodzice. Oczywiście są to zdecydowanie różne odmiany polityki i nieporównywalna skala wpływu na losy świata, jednak mechanizmy są dokładnie takie same.

Jak wcześniej wspomnieliśmy, dla skutecznego wprowadzenia wielu technicznych, architektonicznych i biznesowych koncepcji i rozwiązań niezbędna jest odpowiednia organizacja. Organizacja pracy zawsze wychodzi poza ramy struktur, których CDO jest szefem. Wpływ na struktury, którymi się bezpośrednio nie zarządza, wymaga wysokiej klasy sprawności, znajomości samej organizacji i zawiązania umów między równolegle działającymi komórkami, często bez ingerencji w nią wspólnych przełożonych. Umiejętność zawiązania tego typu ekosystemu jest niezwykle ważna. Obejmuje on departamenty, od których CDO zależy, na przykład szefa infrastruktury, szefa informatyki, szefów komórek biznesowych sprawujących kontrolę nad ważnymi procesami biznesowymi. Często niezbędne do współpracy są także departamenty zakupów lub HR. Wymienione jednostki to przykłady sprzymierzeńców niezbędnych w układzie współpracy hub and spoke. Ważnymi graczami są tu także zewnętrzni dostawcy, zarówno danych, jak i technologii czy usług. Nieocenionym sprzymierzeńcem jest sam zarząd. Odpowiednie ustawienie linii współpracy między komórką realizującą analitykę czy też odpowiedzialną za całość danych w firmie a zarządem, będzie bezpośrednio rzutowało na przyszłe efekty oraz na moc sprawczą w organizacji. Aby współpraca była korzystna dla firmy często niezbędne jest przeprowadzenie akcji informacyjno-edukacyjnej, pokazującej co chcemy osiągnąć i jakiej współpracy oczekujemy. CDO, przychodzący z innej organizacji, może posługiwać się zupełnie odmiennym, często niezrozumiałym językiem dla osób sprawujących ważne role w firmie. Niezbędne jest znalezienie wspólnego języka i umiejętność znalezienia jednoczących celów. Jeśli ten ważny krok zostanie zmarginalizowany i odłożony na później, to ryzyko braku biznesowych efektów, widziane zarówno z poziomu CDO, jak i z punktu widzenia firmy, znacznie rośnie.

Ważnym elementem ustaleń z innymi graczami w organizacji są zawiązane formalne lub nieformalne kontrakty między jednostkami. Oprócz tego warto uzgodnić akceptowalny dla stron sposób komunikacji. Chodzi tu zarówno o komunikację, której celem jest przekazanie informacji o efektach naszej pracy, ale także wymiany informacji operacyjnych. Efektem takiej komunikacji powinna być możliwość pozyskiwania wiedzy o biznesie przez osoby z centralnej analityki. Kolejnym elementem, który musi być ustalony ponad głowami pracujących zespołów jest zgoda na sposób pozyskiwania osób (zwanych w wielu firmach nadal zasobami) do projektów. Możliwość angażowania osób oraz pozyskiwania ich wiedzy eksperckiej do wspólnych prac to podstawa, która zostanie opisana bardziej szczegółowo w dalszej części.

Istotnym ustaleniem, które należy potwierdzić z zarządem, jest dostęp do różnych zasobów organizacji oraz podejścia do ustalania priorytetów prac. CDO powinien zagwarantować sobie miejsce na dyskusję na poziomie strategicznym, platformę rozważań o przewidywanym wpływie efektów jego prac na strategię organizacji. Niektóre firmy są świetnie przygotowane na tego typu rozmowy, ale bywają miejsca, gdzie wyciąganie wniosków z działań operacyjnych i wpływanie na strategię, szczególnie w obszarze danych nie istnieje. To jest miejsce dla lidera analityki i jego ważne zadanie. Na linii CDO — zarząd ważne jest jasne i otwarte pokazywanie, w którą stronę aktualnie rozwijany jest obszar danych i z jaką prędkością się rozwija, gdzie jest i gdzie chcemy, aby się znalazł. Działa to na rzecz przejrzystości i pomaga pokazywać przyczyny i konsekwencje działań, w tym także trudności, które mogą nie być znane szerszemu gronu obserwatorów.

Komunikacja na tym poziomie jest ważnym aspektem, szczególnie przedstawienie opisu stanu początkowego, zastanego podczas rozpoczynania misji CDO w organizacji. Poważnym błędem jest pominięcie jakiegokolwiek bilansu otwarcia w organizacji, do której przychodzi nowy lider. Brak takiego bilansu spowoduje rozdźwięk między ciężko pracującym na danych zespołem, podległym CDO a oczekiwaniami reszty firmy. Brak bilansu otwarcia to duży błąd a zarazem przepis na oddaloną w czasie klęskę.

Zasady rozwoju, prowadzonego konsekwentnie i małymi krokami, adaptującego się do zmiennego otoczenia, w dobrze zdefiniowanym kierunku biznesowym, oferowane przez metodyki agile’owe — dają także otwartość i przejrzystość. Należy wykorzystywać te cechy, dzięki nim otwarcie przekazujemy informacje operacyjne i pokazujemy, gdzie jesteśmy i dokąd zmierzamy na poziomie strategicznym. Zanim jednak powrócimy do tematów strategicznych, skupmy się na efektywnym i w wielu miejscach sprawdzonym sposobie realizacji projektów, które się na tę strategię składają.

Projekty

Optymalnie wybrane cele biznesowe, infrastruktura, technologia i architektura, do tego strategia pozyskiwania i przetwarzania danych, to niezbędne elementy układanki, ale bez ostatniego, ważnego elementu stają się pracą teoretyczną lub w najlepszym wypadku testem koncepcji, bez jej realnego wdrożenia w życie. Aby wszelkie przejawy analiz stały się funkcjonującym i dającym korzyści biznesowe rozwiązaniem, należy konsekwentnie je wdrażać. To oczywista sprawa, znana od dawna i pojawiająca się tam, gdzie ludzkość miała do czynienia z technologią, innowacją, próbami poprawy procesów działających po staremu na nowe lub po prostu z chęcią stworzenia czegoś nowego. W tym rozdziale odpowiem na pytania, jak egzekwować wdrażanie określonej koncepcji.

Aby podkreślić znaczenie realizacji pomysłu, warto zdać sobie sprawę z tego, że pomysł, koncepcja czy też plan bez realizacji mają zerową wartość. Dzieje się tak zarówno w środowisku nowo powstających start-upów, jak i w dojrzałej organizacji. Wiele osób nie zgadza się z takim postawieniem sprawy, stąd w korporacjach, zarówno po stronie dostawców, jak i klientów rozwiązań analitycznych i cyfrowych, możemy spotkać teoretyków, unikających angażowania się w część egzekucyjną projektów i nadmiernie podkreślających zasługi tych, którzy planują. Wartość ich pracy jest materializowana i monetyzowana tylko i wyłącznie wtedy, gdy ich plany mają szansę wejść w życie, a to w przypadku danych wprost zależy od jakości planów i koncepcji oraz od skuteczności lidera w ich uruchamianiu. W ten sposób doszliśmy do pracy zespołowej, w której każdy uczestnik ma odpowiedni sobie udział.

Podobnie jak w przypadku innych zagadnień poruszanych w tej książce naszym celem nie jest także szczegółowe zajmowanie się projektami. Dla osób zainteresowanych tą tematyką istnieje wiele pozycji w odpowiedni sposób ją eksplorujących. Przede wszystkim warto rozpocząć od przedstawienia definicji słowa projekt. Według wikipedii jest ona następująca:

Projekt — zbiór aktywności charakteryzujący się następującymi cechami: są ze sobą powiązane w złożony sposób, zmierzają do osiągnięcia celu, często poprzez wytworzenie unikatowego produktu, usługi bądź rezultatu, posiadają zaplanowany z góry początek i koniec.[6]

Bez ustalenia podstawowych definicji, nawet wśród osób o wielkim stażu, można spotkać się z poważnym niezrozumieniem. Zdarza się, że słowa projekt i proces[7] używane są zamiennie, co jest poważnym błędem. W rozumieniu biznesowym projekt ma wytworzyć unikalny produkt, zrealizować cel lub osiągnąć założony rezultat, który może wykraczać znacznie poza aspekt techniczny, w szczególności może trwale zmieniać procesy funkcjonujące w organizacji.

Dla odmiany proces możemy wyobrazić sobie jako odpowiednik linii produkcyjnej w fabryce, która wytwarza to, do czego została powołana. Produktem takiego procesu może być przedmiot fizyczny, może to być decyzja, model lub inne kreowane w trybie powtarzalnym artefakty.

Jeśli już wiemy, czym jest projekt to należy postawić sobie ważne pytanie: jak projekt zrealizować? Nie zastanawiamy się tu, czy warto projekt realizować, jaki powinien być jego zakres, architektura, cel i inne ważne aspekty. O tym było już w poprzednich rozdziałach. W tej chwili zastanawiamy się, jak projekt zaplanować i przeprowadzić. Aby mieć pewność, że to, co zostało zaplanowane, będzie faktycznie zrealizowane, używa się pewnych metodyk, czyli ram postępowania. Najbardziej znane metodyki to PRINCE[8], PMBOOK[9], rodzina metod AGILE i tym podobne. Dają one osobom realizującym projekty odpowiednią, sprawdzoną pomoc i pomagają w przejściu przez gąszcz pułapek. Nasuwa się jednak pytanie — jaką metodę wybrać? Która metoda jest najlepsza dla osiągnięcia celu biznesowego? Dla pokazania różnic między podejściami projektowymi, posłużę się pewnym klasycznym rysunkiem, pokazującym jeden z ważniejszych aspektów zarządzania projektami.

Rys. 36: Trójkąt projektowy pokazujący trzy cele, które działają wbrew sobie i wymagają mądrego kompromisu.

W realnym świecie, pełnym różnych ograniczeń, nie jesteśmy w stanie dotrzymać jednocześnie wszystkich trzech wymienionych na trójkącie obietnic. Realizując projekt i optymalizując jakość efektu powstającego w jego wyniku, musimy zrezygnować przynajmniej częściowo z którejś z nich. Przyjrzyjmy się poszczególnym przypadkom, wtedy trójkąt stanie się oczywisty. Dla projektów, które mają być zrobione na czas, gdy termin oddania rezultatu jest niezmienny, jedynym wyborem w przypadku jakichkolwiek trudności w realizacji, jest rezygnacja z części zakresu lub też organizacja dodatkowych zasobów i zwiększenie kosztu. Gdy najważniejszy jest kompletny zakres, a próbujemy go poszerzyć, nie można tego zrobić bez straty w harmonogramie (czas), lub bez dodatkowych kosztów. Możliwe, że oba czynniki pogorszą się jednocześnie. Podobnie w przypadku zmian związanych z kosztami. Dla przykładu, jeśli zarządzający projektem dowiedzą się, że niezbędne są oszczędności i budżet zostaje zmniejszony, to wpłynie to negatywnie albo na zakres, czyli nie wszystko zostanie zrealizowane, albo na czas i prace zostaną zrealizowane w późniejszym terminie.

Podsumowując — optymalizując projekt i próbując ograniczać jeden z trzech wymienionych wymiarów, zawsze będziemy mieli zmianę na gorsze na jednym lub dwóch pozostałych. Oczywiście w sytuacji, w której projekt miał sporo rezerw i istnieje przestrzeń do optymalizacji, nie będzie takiej sytuacji, ale to zupełnie inny przypadek. Jeszcze innym wyjątkiem od tej reguły jest zastosowanie zupełnie nowej technologii lub innego czynnika zmieniającego reguły gry, ale na takich sytuacjach nie będziemy się tu skupiali.

Jakie konsekwencje dla budowy i rozwoju analityki, a także dla pracy na danych, ma ta reguła? Główne przesłanie jest takie, że niektóre projekty, z dobrze zdefiniowanym zakresem i przewidywalnymi parametrami typu koszt i czas, warto realizować w klasyczny sposób, czyli z zamrożeniem zakresu. Tak na przykład warto budować mosty, budynki i inne dobrze przewidziane i w stu procentach zaprojektowane konstrukcje. Wszelkie zmiany będą dotyczyły czasu lub budżetu i na takie zmiany w kontrolowanych granicach może sobie pozwolić inwestor. W przypadku projektów, w których zakres jest jedynie ideą bądź też jesteśmy pewni, że zakres będzie się zmieniał i jego znajomość będzie większa dopiero z upływem czasu, nie można zakładać, że jest to parametr stabilny. To sytuacja, która często występuje w projektach IT, w projektach zakładających pracę na danych jest trudniej.

Aby mądrze zarządzić taką trudnością, rynek IT oraz twórcy rozwiązań analitycznych coraz częściej decydują się na zwinne metodyki projektowe. Zakładają one zmienność zakresu w trakcie trwania projektu i nie jest to wyjątek, lecz reguła. Zmienność zakresu jest z jednej strony odpowiedzią na brak kompletnej specyfikacji tego, co ma powstać, a z drugiej strony daje elastyczność w dostosowywaniu się do potrzeb biznesowych.

Czy oznacza to, że można rozpocząć projekt zupełnie bez wymagań i bez celu? Stanowczo nie. Jest to moment w którym należy połączyć metodykę projektową ze wszystkim, co było przedstawiane w poprzednich rozdziałach. To miejsce, w którym zwinna realizacja projektu staje się klamrą spinającą wszystkie aspekty pracy na danych. Jak to zrobić? W kolejnych rozdziałach przejdę przez niezbędne elementy, które zapewnią CDO bezpieczny i skuteczny mechanizm realizacji dobrze przemyślanych rozwiązań.

Produkt

Rozważając pobieżnie spektrum metodyk projektowych, zatrzymaliśmy się na tym, że w świecie analityki danych mamy sporą niepewność związaną z tym, co faktycznie jest potrzebne i jak powinien wyglądać zakres prac. Przekłada się to na brak pełnej wiedzy, co powinno być produktem czy też narzędziem pomagającym naszemu biznesowi. Wpływa na to wiele aspektów, rozpoczynając od zmienności biznesu. Do zmienności tej należy się dostosować, podejmując decyzje i realizując je w obszarach specyficznych dla danych. Myślę tu głównie o „grze strategicznej” związanej z pozyskaniem danych, decyzjami architektonicznymi, tematami dotyczącymi talentów. Pewnym i prawdopodobnie jedynym możliwym sposobem na dotarcie do prawdziwej potrzebnej specyfiki produktu jest metoda iteracyjna, czyli realizowana poprzez wykonywanie małych kroków i ciągłą weryfikację, czy kroki są stawiane w odpowiednim kierunku. Takie podejście to sedno metod AGILE. Adaptacja do realnego środowiska pozwala uwzględnić wszystkie wymienione tu aspekty, które mogą nam przeszkodzić w realizacji obranego celu. Aby jednak wiedzieć, w którą stronę idziemy, musimy precyzyjnie definiować cel prac projektowych.

Zwykle podręczniki do metodyk AGILE skupiają się na technikach pozwalających realizować projekty. Są one niezwykle ważne, jednak nie na nich będę się skupiał. Tutaj chciałbym zająć się tym, co jest specyficzne dla realizacji całościowej strategii związanej z rozwojem danych w organizacji. Wszystko rozpoczyna się od celu strategicznego, opisywanego wcześniej. Jest on odpowiednio dekomponowany i wynikają z niego pewne niezbędne do realizacji prace składające się na całą strategiczną „układankę”. Gdy mamy taki zdekomponowany i odseparowany od innych komponent, narzędzie, produkt, czy też funkcję, powinniśmy jako CDO zapewnić osobę utożsamiającą się z tym elementem jako merytoryczny właściciel i gospodarz.

Metodyka projektowa nazywa taką osobę właścicielem produktu (ang: Product Owner) i takiej nazwy będziemy używali. Rola właściciela produktu jest szczególnie ważna. Dysponuje on władzą CDO w zakresie, w jakim została mu ona przekazana, czyli w granicach definicji przynależnemu mu produktu. Dlaczego ta techniczna lub projektowa rola jest tak istotna? Ewolucja firm i organizacji w ramach tzw. „cyfrowej transformacji” powoduje, że w nowej, docelowej rzeczywistości, ku której zmierzają organizacje, to właśnie platformy i narzędzia, jeśli są odpowiednio użyte, stają się elementem przewagi konkurencyjnej i generatorem przychodów, zysków czy oszczędności. Osoba, która kieruje rozwojem elementu platformy, ma istotne znaczenie i wnosi ważny wkład w to gdzie organizacja będzie jutro. To jej decyzje wpływają na faktyczny rozwój i dlatego powinna mieć wszystkie potrzebne informacje do sensownego podejmowania decyzji.

Początkowo cel produktu i jego granice muszą pasować do stawianych mu celów biznesowych, muszą także uwzględniać aspekty architektoniczne i technologiczne. Plan rozwoju produktu powinien brać pod uwagę stan aktualny, wszystkie jego niedociągnięcia, akceptować je jako rzeczywistość zastaną — stan początkowy. Pod uwagę muszą zostać wzięte różne warianty rozwoju, często plany taktyczne wymagające tymczasowych kroków, choćby takie, które będą później wycofane lub naprawione. Plan musi uwzględniać wewnętrzne zależności, włączając wszelkie aspekty techniczne, biznesowe, zasobowe oraz zależności z innymi produktami, danymi i sytuacją biznesową firmy. Panowanie nad tymi wszystkimi elementami układanki to rola właściciela produktu. Dla organizacji pełniący tę rolę, wraz z zespołem za nim stojącym, gwarantuje uzyskanie działającej funkcjonalności. Jest to nie tylko obietnica działania za kilka miesięcy, ale przede wszystkim osiągalny i realizowany plan na funkcjonowanie w okresie przejściowym — teraz, za dwa miesiące i w dłuższym horyzoncie. Za tym planem idą prace rozwojowe i administracyjne, czyli konkretne inwestycje i wydatki.

Właściciel produktu, to osoba realizująca strategię na swoim obszarze i rola za którą stoi odpowiedniej wielkości zespół projektowy, realizujący jego plany i wizję. Taka podstawowa jednostka projektowa nie gwarantuje sukcesu, ale daje ogromną szansę organizacji oraz szefowi analityki na sprawną realizację prawie dowolnie obranego kierunku biznesowego.

Inne role projektowe, które chcielibyśmy wykorzystać w analityce, nie odbiegają specjalnie od kanonu metodyk AGILE, dlatego nie będę specjalnie ich analizował a najważniejsze przywołam dla porządku. Projektom do pomyślnej realizacji potrzebna jest rola wspierająca zespół. W SCRUMIE takie wsparcie uzyskiwane jest dzięki obecności scrum mastera. Osoba ta nie skupia się na strategicznych i operacyjnych aspektach produktu, ale pomaga w codziennych problemach zespołu. Często pomaga w różnych aspektach współpracy i w trudnych sprawach międzyludzkich. Scrum master może pracować w wielu zespołach projektowych bez uszczerbku dla efektów swojej pracy.

Rys. 37: Podstawowy zespól projektowy pracujący w metodyce AGILE/Scrum.

Skupiając się na metodyce i rolach nie można zapomnieć o członkach zespołu projektowego — deweloperach. Zespół liczy od dwóch do ośmiu osób, które realizują zadania zdefiniowane przez właściciela produktu. Zespół powinien być dedykowany do produktu i należy unikać mieszania zespołów. Każde zaburzenie w pracy zespołu, polegające na przesuwaniu osób między zespołami, jest niezwykle ryzykowne i psuje jedność zespołu. Czym lepsza integracja zespołu, tym korzystniejsza jego prędkość, czyli efektywność dostarczania wyników prac. Migracje osób między zespołami należy traktować jako świadomą ingerencję w prace całej organizacji projektowej, która powinna mieć pewien przemyślany cel, nie może być zaś stosowana jako norma.

Przedstawiłem pobieżnie podstawy pracy zwinnej, które są coraz szerzej znane i stosowane. Przy odpowiednim wdrożeniu metod pracy i pamiętaniu o innych aspektach, takich jak strategia, architektura i dane, uzyskujemy zwinność i odpowiedni kierunek prac. To już sporo, jednak podstawy te nie zapewnią automatycznego skalowania i koordynacji prac w wielu zespołach jednocześnie. Tym zajmiemy się w następnym rozdziale.

Ekosystem produktów — skalowanie AGILE

Gdy mamy już pierwszy, działający mechanizm projektowy, dostarczający efektywnie wyniki rozwiązujące problemy biznesowe i realizujące elementy strategii, osiągamy już pierwszy sukces. Kolejnymi celami, do których CDO i management powinien równolegle dążyć, jest doprowadzenie do podobnej sytuacji w innych, ważnych miejscach.

Działające równolegle zespoły są źródłem sporej satysfakcji, efektywna koordynacja między zespołami zastępuje punktowe pozytywne rezultaty sukcesem większej skali.

Rys. 38: Elementy współpracy zespołów zwinnych.

Koordynacja ponad zespołami daje takie wartości, jak: eliminacja tych samych prac wykonywanych w różnych miejscach, zapobieżenie prowadzenia działań w różnych, wykluczających się kierunkach oraz ma także wielkie znaczenie widoczne w warstwie architektury i technologii. Ważny jest także aspekt związany z zasobami. Niezbędne jest wzmacnianie zespołów, które tego potrzebują, czasami kosztem innych. Decyzje na tym poziomie mogą być podejmowane jedynie przez osoby, które mają szerszą perspektywę, niż projektowa i identyfikują się z celami stawianymi organizacji.

Pozytywnym, oczekiwanym efektem takich zmian powinno być „przeszczepienie” dobrego, czy też pożądanego sposobu pracy z jednego zespołu do innego. W tym celu można próbować przenieść wybrane osoby między zespołami. Należy jednak bardzo uważać i monitorować taki proces. Są to jedne z wielu trudnych decyzji mangerskich. Mogą być podejmowane jedynie w przypadku, gdy management rozumie dynamikę wewnątrz zespołów, jak i pomiędzy nimi.

Rys. 39: Przykładowa struktura organizacji obejmująca wiele projektów równocześnie rozwijających w spójny sposób wiele produktów techniczno-biznesowych.

Na rysunku widać szerszą strukturę produktową, uwzględniającą także role architektoniczne i cele biznesowe organizacji. Taka organizacja pracy daje sporą szansę na dopasowanie do celów firmy. Jaka rola w takiej organizacji należy się managerom liniowym i czy ta nowa struktura zastępuje starą, klasyczną? Otóż nie, struktura produktowo-projektowa ma na celu realizację najważniejszych zadań związanych z biznesem. Organizowanie pracy zespołów, ich wzajemną koordynację, działania w sytuacjach niespodziewanych, reorganizacje, pozostają w zakresie obowiązków szefów liniowych. Organizacja nie zajmuje się sama w sobie pozyskiwaniem pracowników, zwalnianiem, aspektami HR’owymi. Te działania niemieszczące się w metodyce projektowej, należą do managerów liniowych. Struktura zarządzania liniowego nie jest już jednak taka, jaka była wcześniej w stabilnych hierarchicznie zarządzanych przedsiębiorstwach, z ustabilizowanymi procesami.

W przypadku jednostek zajmujących się danymi i analityką w firmie niezbędne jest podejście zbliżone roli w której pracownik bierze udział w badaniach i poszukiwaniach naukowych (ang.: research), a w kolejnej części tworzy, niczym rzemieślnik, to, co zostało zaplanowane (ang.: dewelopment). Pracy powtarzalnej i realizowanej od zawsze w ten sam sposób będzie tu niewiele. Dodatkowo należy oczekiwać, że osoby z tak zorganizowanej jednostki będą wpływały na resztę firmy, transformując ją. Najważniejszą zmianą w sposobie funkcjonowania managerów liniowych, w stosunku do tradycyjnej organizacji, jest z jednej strony alokowanie niektórych pracowników do pracy nad produktami, gdzie będą podlegali merytorycznie strukturze właścicieli produktów, a technicznie — architektom, zaś projektowo — liderom projektów. Kierownik liniowy może pełnić niektóre z wymienionych ról, ale to już nie wynika z jego stanowiska managera, ale z jego kompetencji.

Warunki, które powinien spełniać manager liniowy to zrozumienie celów firmy, pełna kontrybucja w tych celach i współpraca z różnymi decydentami, wymienionymi wcześniej. Odpowiedzialność za produkt, dane, architekturę, technologię i pracę zespołu projektowego znalazły się w wymienionych na rysunku innych rolach. Managerowie mają w takim układzie o wiele mniejszą władzę w porównaniu z klasycznym rozumieniem ich zadań. Taka nowa rola nie zawsze odpowiada managerom wychowanym w innej filozofii pracy. Z tego powodu wracam do kwestii doboru kadry przez CDO, jest to kluczowy wybór, determinujący powodzenie jego misji.

Roadmapa

Konsekwentnie wobec poprzednich rozdziałów, jako wiodącą metodykę projektową dla prac związanych z danymi przyjmujemy AGILE. Cały rozwój obszaru opieramy na planowym rozwoju poszczególnych produktów, a te z kolei stanowią składniki środowiska wspierającego i „napędzającego” nasz biznes. Tak powstaje spójna platforma, rozwijana w zdecentralizowany sposób i dzięki koordynacji na wyższym poziomie, powinna ona stawać się coraz bardziej uporządkowana.

W jaki sposób planować następujące po sobie, kolejne wydania takiej platformy? Jak weryfikować strategiczny kierunek, w którym jest rozwijana i w jaki sposób deklarować i dotrzymywać terminów? Często organizacja akceptuje efektywność dostarczania zmian, zdarza się jednak także presja na wyniki. Wymagane staje się przyspieszenie prac i skrócenie terminów ich realizacji. Jak CDO powinien reagować, aby nie zepsuć rodzącej się sprawności i zwinności a zarazem aby sprostać oczekiwaniom odbiorców?

Należy doprowadzić do sytuacji, w której zakres prac realizowany w poszczególnych zespołach projektowych, był znany i komunikowany. Otwartość jest istotną cechą każdego zespołu AGILE. Tablica z zadaniami jest widoczna dla każdego członka zespołu, stan i postęp prac także nie powinien być tajemnicą. Dla dobrze pojętego interesu firmy, CDO wraz z osobami odpowiedzialnymi za prace projektowe, powinien doprowadzić do sytuacji, kiedy przejrzystość staje się normą i jest zrozumiana także na wyższym poziomie zarządczym. Nie każde, szczegółowe zadanie ma na tym poziomie znaczenie, dlatego należy dostosować sposób raportowania do odbiorców tej informacji. Odpowiednim poziomem informacji dla zewnętrznych odbiorców, oczekujących często na rezultaty poszczególnych prac, jest poziom większych grup zadań realizowanych w zespołach. Tak zagregowane informacje to zdecydowanie lepszy poziom komunikacji do managerów, firmy, zarządu czy udziałowców. Odpowiednio wypracowany poziom szczegółowości, dostępność i świeżość tych informacji redukuje znacznie ryzyko niezrozumienia tego, co jest realizowane. Komunikacja pozwala wcześnie wpłynąć na zakres prac osób, do których jest kierowana, pozwala także usuwać ewentualne przeszkody.

Aby taka otwarta i prawdziwa komunikacja o stanie prac funkcjonowała, niezbędne są osoby ją realizujące. Najefektywniej jest wykorzystać do tego role wspierające proces projektowy i stanowiące biuro projektów (ang.: Project Management Office). Dzięki takiej organizacji, zadania wspierające nie będą stanowiły kosztu dla członków zespołów. Komunikacja nie powinna znacznie ich obciążać, do tego celu warto wykorzystać istniejące narzędzia lub platformy wspierające współpracę projektową.

Idealną osobą, która powinna komunikować efekty prac na zewnątrz projektu jest właściciel produktu. W zakres komunikacji powinny wchodzić informacje dotyczące ostatnich dokonań, najbliższych planów, aktualnych problemów, a w dalszej części planów średnio i długoterminowych. Szczególne elementy komunikacji — te opisujące strategię — nie zmieniałyby się zbyt często. Właściciele produktów ustalają takie kierunkowe plany w porozumieniu z CDO i między sobą wtedy, gdy występują między nimi jakiekolwiek zależności. Ułożony w ten sposób plan nie staje się prawdą absolutną na wiele lat. Podlega regularnym przeglądom, a biorą w nich udział odpowiedzialni za poszczególne produkty — właściciele produktów oraz inne konieczne osoby. Podczas przeglądów, odbiór produktu przez odbiorców może wpływać na aktualne plany rozwoju produktu. Po każdej zmianie jednak plany należy uaktualnić, aby przedstawiały aktualnie obowiązujące założenie, pokazujące, co zamierzamy zmieniać, nad czym pracować i jakie są najlepsze szacunki, kiedy to zrobimy, ile czasu potrzebujemy na kolejne kroki? Taki plan w najlepszy sposób oddaje rzeczywistość na wysokim poziomie „bardzo dużych klocków”, które jako zespół układają właściciele produktów. Robią to z pomocą osób technicznych, często architektów i analityków danych.

Tak ułożona roadmapa realizowana jest następnie w poszczególnych zespołach deweloperskich. Dzięki łącznikom między tym planem strategicznym a konkretnymi planami zespołów uzyskujemy spójny obrazek roadmapy wraz z planami rozwojowymi na poziomie kilkuosobowych zespołów projektowych.

AGILE na poziomie strategii

Obszar strategii jest opisywany niezwykle często, z różnych stron i z uwzględnieniem szerokiej gamy czynników. W tym miejscu skupię się jedynie na sprawach, które uważam za niezbędne do skutecznego wykonania pracy przez CDO w organizacji.

Temat strategii jest niezwykle ważny dla lidera, ponieważ spina on wszystkie do tej pory wymienione elementy:

— aspekt biznesowy wraz z celem,

— wykonalność techniczną, architekturę,

— aspekt ludzki, organizacyjny i projektowy,

— zasoby techniczne i inne,

— sprawy związane z danymi.

Z punktu widzenia organizacji projektów można dostrzec, że wszystkie elementy wpływają na siebie. Szczególnie ważny ze strategicznej perspektywy staje się wymiar czasu. Umożliwia uwzględnienie dynamiki zmian we wszystkich wymienionych aspektach, daje też możliwości wpływania na tę dynamikę odpowiednimi decyzjami. Przede wszystkim będą to decyzje inwestycyjne. CDO widzi procesy i zjawiska, narastanie pewnych i zanikanie innych. Dzięki takiemu globalnemu spojrzeniu podejmuje działania; trafne przynoszą wartość organizacji. CDO nie korzysta ze wszystkiego, co podsuwa rynek lub przypadkowi doradcy, ale uwzględnia dłuższy plan i na jego bazie podejmuje ważne dla firmy decyzje.

Strategia bardzo często rozumiana jest jako plan, który poddawany jest ważnym zatwierdzeniom, a następnie jest realizowany. Takie podejście broni status-quo decydentów i buduje ich wizerunek, nie sprawdza się jednak w realnym, dynamicznym biznesie. Biznes, podobnie jak otaczająca nas przyroda, nie znosi próżni i sytuacji w której na szczycie organizacji wszelkie decyzje zostały podjęte i „zamurowane” w statyczną strategię. Jest to stan zupełnie nienaturalny. Są dwie możliwości wyjścia z takiej sytuacji — albo prawdziwe decyzje i realna gra strategiczna prowadzona jest w innym miejscu, na niższym poziomie i staje się niewidoczna dla zarządzających albo sztywno zdefiniowana strategia powoduje regularnie szkody dla firmy.

Dobrą analogią do pracy stratega jest partia szachów. Każda partia ma swoje ramy i nie sposób jej z góry, dokładnie zaplanować. Wiadomo jednak, że spodziewamy się faz takich, jak otwarcie, gra kombinacyjna i fazy końcowej, w której gracz dąży do zwycięstwa. Taki ramowy plan to prawie wszystko, co możemy zaplanować. Warto znać przeciwnika i wiedzieć, jakie sztuczki na danego przeciwnika działają, a jakie będą nieskuteczne. To jednak wszystko. Kolejne fazy partii przenoszą nas już do sytuacji unikalnych i to jest dobre porównanie do startującego w organizacji CDO. Zostaje on postawiony jako gracz do już rozpoczętej partii. Wtedy musi on zrozumieć, jaka myśl towarzyszyła jego stronie, a także, co w danej sytuacji może zrobić i jaki plan jest aktualny. Z matematycznego punktu widzenia to zagadnienie programowania dynamicznego (ang.: dynamic programing[10]).

Rys. 40: Programowanie dynamiczne.

Programowanie dynamiczne pomaga podjąć decyzję i wykonać symulację ilustrującą, jak po decyzji zmieni się otaczające środowisko. Decyzja podjęta na danym etapie wpływa wprost na stan gry w następnych etapach, czyli — albo zawęża nam możliwości w następnym etapie, albo je poszerza. Podobnie dzieje się w kolejnych etapach. Teoria, będąca podstawą rozwiązywania zagadnień programowania dynamicznego, dobrze opisuje sytuację decydenta. Wymiary, które do tej pory opisaliśmy, to części składowe otoczenia. Dla przykładu — podjęcie w styczniu decyzji o wyszkoleniu zespołu w zakresie danej technologii, spowoduje zwiększenie szansy na pomyślną realizację projektu w kwietniu. To prosty przykład, ale patrząc na inne aspekty tej decyzji, dostrzegamy, że może spowodować zmianę strategii technologicznej, ponieważ zespół uzna, iż jeden sposób realizacji pewnych funkcji jest łatwiejszy, a stanie się tak dlatego, że lepiej zna daną ścieżkę. Innym przykładem może być decyzja o inwestycji czasu jednego z zespołów projektowych w rozbudowę produktu w danym kierunku. Decyzja może być podjęta po rozmowie z odbiorcami z organizacji i może wydawać się słuszna, powoduje jednak zaniechanie prac nad innymi aspektami produktu, co nie musi być od początku oczywiste. Tak więc model programowanie dynamicznego pozwala połączyć różne aspekty decyzji z następnymi etapami. Nie oznacza to, że w realnych sytuacjach pracy CDO będzie miał czy też powinien mieć rozpisany taki model. Przeciwnie, uważam, że wystarczy dobre zrozumienie tej idei i myślenie w taki sposób, to już znaczny wyróżnik na rynku dla takiego decydenta.

Czy możemy znaleźć bliższe codziennemu życiu przykłady decyzji strategicznych, opartych na modelu programowania dynamicznego? Spróbujmy! Wyobraźmy sobie wycieczkę przez górskie pasmo. Wiemy, że mamy dotrzeć do chaty. Tymczasem po drodze okazuje się, że drogę tarasuje głaz, nie mieliśmy szansy przewidzieć wcześniej sytuacji i zaplanować jej. Teraz musimy zmienić naszą inicjalną strategię — dostosować się do realiów. W ten sposób doszliśmy do fundamentów działania zwinnego. Wycieczka górska jest analogią wielu działań składających się na dotarcie do obranego celu i jeśli mamy statyczną strategię, nigdy nie dojdziemy do celu w sensownym czasie i koszcie, musimy się dostosować.

Powyższa koncepcja to AGILE na poziomie strategii. Zmiany decyzji podjętych wcześniej i założeń już przyjętych nie są wyjątkiem, ale raczej regułą. Organizacja otwarta na zmiany, w określonych przypadkach, wycofuje się ze swoich decyzji i podejmuje lepsze. Zmiana decyzji obejmuje szerszy obrazek, niedostępną wcześniej wiedzę i wykorzystuje sposób myślenia analogiczny do działania algorytmu programowania dynamicznego. Dodatkową trudnością, jaka tu dochodzi jest niepewność, może ona być redukowana większą ilością posiadanych informacji oraz intuicją. Intuicji nie da się skwantyfikować, niemniej jednak, jeśli CDO chce opierać się także na niej, musi mieć zespół dobrany w taki sposób, aby ufać także decyzjom podejmowanym na ich poziomie i nie psuć ich. To ważny aspekt doboru kadry. Bez zaufania pozostaje centralizacja i wszystkie jej wady. Intuicja nie jest tu alternatywą oparcia się o twarde i dostępne dane — jest dobrym uzupełnieniem i powoduje optymalne wykorzystanie dostępnych informacji.

Czy jest tu miejsce na outsourcing?

Decyzja o tym, czy dane prace zlecać na zewnątrz (czyli stosować outsourcing), czy też raczej budować je wewnętrznie, jest niezmiernie istotna. Wybór kierunku zależy od wielu czynników. Pomimo dosyć bogatych doświadczeń na rynku, dotyczących projektów realizowanych w obu modelach, decydenci często podchodzą do tego wyboru, jakby doświadczeń z nich nie było i ponownie „wchodzą do tej samej rzeki”. Postaram się wymienić najważniejsze czynniki decyzyjne wpływające na wybór modelu pracy. Podam także główne skutki, których możemy się spodziewać.

Aby nie zamykać się na jedną bądź drugą alternatywę, przypomnijmy sobie strukturę produktową. W skład proponowanej struktury wchodzą oddzielnie rozwijane funkcjonalności techniczne, realizujące pewne funkcje biznesowe. Rozwój każdej z nich może następować, jak już wcześniej stwierdziliśmy, w separacji od pozostałych. Wymagana jest odpowiednia integracja z pozostałymi produktami. Oczekiwane jest także spełnianie wymagań biznesowych, wsparcie w realizacji celu biznesowego, przypisanego danemu produktowi, odpowiednie działanie i zachowanie wszelkich aspektów operacyjnych danego rozwiązania. Poprawne odseparowanie rozwoju i utrzymania danego komponentu prowadzi do sytuacji, w której możemy decyzje o insourcingu lub outsourcingu podejmować na poziomie produktów/komponentów. Oznacza to, że istnieje możliwość prowadzenia prac nad wybranymi produktami z wykorzystaniem zespołów wewnętrznych, z kolei inne mogą być oddane do partnera lub też kupione jako całościowa usługa biznesowa (ang.: managed service). Przyjmijmy, że możemy tak robić. Stoi za tym ogromne ryzyko, ale o tym za chwilę.

Wyjdźmy od podstawowego założenia, że cel naszych prac zdefiniowany jest wokół danych w organizacji (tak właśnie postrzegamy rolę CDO). Kierunek rozwoju wiąże się z takimi elementami jak: poprawa jakości danych, efektywnie podejmowane decyzje bazujące na danych, demokratyzacja posiadanych danych, lepsza strategia pozyskiwania danych, zaawansowana analityka. Każde zadanie realizowane będzie zgodnie ze strukturą produktową w różnych zespołach i będzie zbliżało nas do celu wcześniej ustalonego. Będzie niejako przy okazji, równolegle budowało wiedzę w organizacji.

Jeżeli nie zależy nam na zbieraniu wiedzy wewnątrz organizacji, wtedy bez wielkiej szkody możemy korzystać z zalet outsourcingu. Przekazanie istotnych dla firmy zadań wchodzących w aspekty biznesowe, których dużą częścią jest badanie danych, procesów, następnie ich optymalizacja, jest konsekwentnym uzależnianiem się od outsourcingowego partnera. Jeśli partnerem jest firma zewnętrzna, to należy ten problem uwzględnić w decyzji o wybieranym modelu i zweryfikować, co otrzymujemy w zamian i czy jest to partnerstwo dla nas korzystne.

Innym przypadkiem jest partner, który zupełnie nie integruje się do naszego modelu biznesowego, ale tworzy uniwersalny produkt rynkowy, który może być dla naszej firmy przydatny. W tej sytuacji zupełnie nieopłacalne jest odtwarzanie produktu tylko i wyłącznie na nasze cele. Po pierwsze, zrobimy to gorzej niż firma, dla której jest to główny obszar biznesu, a po drugie będziemy w tym zadaniu od dostawcy znacznie bardziej kosztowni. Przykładem może być tu usługa nasłuchu sieci społecznościowych, realizowana przez różne firmy specjalizujące się w tym. Odtworzenie całej technicznej infrastruktury i interfejsów niezbędnych do uruchomienia takiego produktu będzie zadaniem, które wymaga o wiele więcej nakładów niż zakup abonamentu z podobną usługą. Podobnego wyboru warto dokonać w przypadku zapotrzebowania na gotowe usługi infrastrukturalne lub analityczne, dostarczane przez partnerów technologicznych. Tak nabywane elementy, będące jedynie złożonymi narzędziami, należy inteligentnie włączyć we własny ekosystem i to jest już zadanie dla pracowników wewnętrznych. Nawet jeśli w niektórych trudnych zadaniach posiłkują się partnerami czy konsultantami, to pracownicy firmy są w pełni odpowiedzialni za powstającą architekturę techniczno-biznesową. Podsumowując - nie zawsze gdy chcemy kupić bułkę, warto budować piekarnię.

Poniżej przedstawiam najważniejsze kryteria, prowadzące nas do insourcingu, czyli do rozwoju wewnętrznego analityki i projektów opierających firmę na danych:

— zależy nam na tym, aby wiedza pozostała w organizacji,

— wymaga dogłębnego poznania naszego biznesu,

— wpływa na procesy biznesowe,

— wpływa na strategię pozyskiwania i przetwarzania danych,

— istotnie zmienia i wpływa na architekturę środowiska technologicznego,

— ma wpływ na podstawy działania biznesu firmy i stanowi jego ważną przewagę konkurencyjną.

Kryteria, które przemawiają za outsourcing’iem:

— obecność gotowego produktu, którego nie warto odtwarzać,

— produkt łatwy do zastąpienia innym,

— praca odtwórcza, nieciekawa dla członków zespołu,

— praca realizowana własnymi pracownikami byłaby nieefektywna w porównaniu z gotową usługą,

— dobrze określony zakres prac i kryteria jakości usługi.

Biorąc pod uwagę kryteria i aspekty biznesowe, warto przed ostateczną decyzją uważać na funkcjonujące trendy i mody dotyczące zarządzania w tym wymiarze. Środowisko analityki danych oraz IT przeszło falę zachłyśnięcia się outsourcingiem. Korzyści z outsourcingu w wielu przypadkach nie przewyższały kosztów z nim związanych. Szkody wywołane nieodpowiedzialnym podejściem do zlecania najważniejszych procesów na zewnątrz, w tym tych dotyczących analityki i danych, są nadal naprawiane w wielu firmach. Był to dosyć drogi eksperyment, dlatego do decyzji o oddaniu określonego zakresu do partnera, należy podchodzić z wielką ostrożnością. Obecnie króluje model pracy realizowanej przez pracowników wewnętrznych, jednak coraz częściej lokalizowani są oni w Indiach lub Chinach. To jest nowe podejście do outsourcingu jest kolejnym eksperymentem.

Innym kierunkiem eksperymentowania, widocznym na rynku, jest budowa ekosystemów podmiotów skupionych na własnych zakresach biznesowych i integrujących się z użyciem współczesnych interfejsów API, angażujących społeczność twórców opensource. To nowe podejście, które sprawdza się w wielu miejscach i warto mu się bacznie przyglądać.

Kultura organizacyjna

Ostatnim punktem, który chciałbym omówić, dotyczącym współpracy, jest kultura organizacyjna. Znane powiedzenie mówi, że „kultura zjada strategię na śniadanie”. Można mieć wielkie plany, odpowiednio zapewnione wszystkie ważne aspekty projektowe, techniczne, idealną strategię danych, a jednak wszystko może nie zadziałać, ponieważ nie zadbaliśmy o ten element.

Rys. 41: Kultura organizacyjna zjada strategię na śniadanie.

Od kultury organizacji i od promowanych wzorców zależy, w którą stronę będą szły działania poszczególnych osób. Z punktu widzenia trudności wdrożenia, realizacja części technicznej projektu, a nawet realizacja strategii może być łatwiejszym zadaniem niż wprowadzenie odpowiedniej kultury organizacyjnej. Wartością samą w sobie jest kultura, w której realizowane są takie cele, jak wzajemna wymiana doświadczeń zamiast stałego konkurowania, wzajemne szkolenie z umiejętności, które posiadają członkowie zespołów, udostępnianie wyników pracy i otwartość. To piękne hasła, jednak w rzeczywistości współpraca na poziomie zespołu i na poziomie większej organizacji może być błogosławieństwem lub problemem. Wielką rolą CDO i kadry managerskiej jest odpowiednie dawanie przykładu własnym działaniem, wprowadzanie reguł pozwalających ludziom pracować w odpowiedni sposób. Takie działania warto traktować jak każdą inną inwestycję, wymaga ona konsekwencji i czasu i efekty jej w znacznej mierze zależą od ludzi, których udało się nam zatrudnić do organizacji.

Efektem konsekwentnych inwestycji w podniesienie kultury może być większe „przywiązanie” wartościowych pracowników do firmy, zwiększenie wydajności, czy pobudzenie innowacji. Zatrzymanie pracownika poprzez dbałość o niego leży w interesie firmy, po odejściu kluczowego członka zespołu ginie część wiedzy i należy ją odbudować. Gdy pracownik pozostaje w organizacji, jego energie i wiedza służy rozwojowi. Na kulturę organizacji składa się wiele poziomów:

— Odpowiednie ustalenie celów zespołów. Często organizacja planowana jest w taki sposób, że niektóre role są w otwartym konflikcie z innymi. To teoretycznie prowadzi do rozwiązywania problemów ze sprzecznymi kryteriami, jednak ludzie rozwiązując te problemy antagonizują się i zespoły zaczynają walczyć ze sobą. Jeśli istnieje punkt, w którym chcielibyśmy tak ustawiać cele zespołów, aby projektować konflikt, zastanówmy się nad wykorzystaniem mechanizmów wspólnych celów dla tych zespołów.

— Dzielenie się wynikami pracy, otwartość w obszarze technik, sposobów, tricków. To powinno być oczywiste w dzisiejszym świecie. Wiele organizacji wychodzi z tym punktem nawet poza granicę firmy. Nie boją się one publikować wiedzy o wybranych sposobach rozwiązania problemów, podczas gdy w innych miejscach wiele osób nie dzieli się swoimi metodami, nawet w ramach zespołu. Pewne mechanizmy pomagają i wymuszają pozytywne zachowania. Są nimi regularne prezentowanie wyników swoich prac, publikowanie kodów i metod we wspólnym repozytorium, specjalne spotkania grupujące mikrospołeczności w ramach firmy.

— Poziomy przepływ informacji. Punkt ten jest podobny do poprzedniego, dotyczącego dzielenia się technikami pracy. Tym razem chodzi po prostu o informację, którą wymieniamy się nieformalnie: na papierosie (palenia oczywiście nie polecam) lub przy ekspresie z kawą. Kadra zarządzająca często traktuje ten czas jako czas stracony, a jednak w wielu firmach taki przepływ naprawia wiele błędów zarządzających — pomaga dotrzeć informacji tam, gdzie w normalnych strukturach nie miałaby szans. Pozwala na naturalny rozwój wewnątrz firmowych sieci społecznościowych, które mają pozytywny wpływ na funkcjonowanie firmy i mają historię zdecydowanie dłuższą niż to, co uważamy za sieci społecznościowe, czyli facebook czy linkedin.

— Pionowy przepływ informacji. Tu chciałbym odnieść się do oficjalnej hierarchii organizacyjnej, często informacja dostępna na szczycie struktury traktowana jest jako zasób i przewaga nad podległymi pracownikami. Prawdą jest, że nie ma sensu, aby każdy wiedział wszystko, jednak rolą managera jest przekazywać informacje odpowiednie dla swojego zespołu, wpływające na jego pracę, a także zarysowywać etapy następnych działań, które będą miały wpływ na pracę zespołu. Zatrzymanie informacji w głowie managera powoduje, że wprowadzanie jakichkolwiek zmian napotyka poważny opór. Warto o tym pamiętać rekrutując i monitorując pracę managerów liniowych.

— Podobnie istotny jest przepływ informacji w górę, czyli realny postęp prac, szczegółowe informacje o tym, co faktycznie się dzieje w szczególnych przypadkach powinny znaleźć się na biurku managementu i członkowie zespołów powinni wiedzieć, że ktoś ich wysłucha i zrozumie, o czym mówią. Brak zrozumienia powoduje ignorowanie ważnych spraw, wpływa negatywnie na priorytety prac i powoduje zaprzepaszczenie istotnych szans, z których większość pojawia się na najniższym szczeblu organizacji. CDO musi być gotowy na pielęgnację najbardziej wartościowych przypadków, o których się dowiaduje i przekuwanie ich w większe projekty by stały się sukcesem całej organizacji.

[1] ang.: software will eat the world

[2] SCRUM, Mariusz Chrapko

[3] John Maxwell, 5 Levels of Leadership

[4] W literaturze często występuje to pod nazwą ang: self-service business intelligence

[5] Wielu absolwentów studiów Master of Business Administration (MBA) tak pojmuje swoją rolę, jako utrzymanie status-quo i nie reprezentują podejścia transformacyjnego.

[6] Źródło: wikipedia, https://pl.wikipedia.org/wiki/Projekt_(zarz%C4%85dzanie)

[7] Proces (biznesowy) — seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu. Źródło: https://pl.wikipedia.org/wiki/Proces_biznesowy

[8] PRINCE2: https://en.wikipedia.org/wiki/PRINCE2

[9] PMBOK — Project Management Body of Knowledge, źródło:https://www.pmi.org/pmbok-guide-standards

[10] Programowanie dynamiczne to zagadnienie optymalizacyjne, opis z wikipedii: https://en.wikipedia.org/wiki/Dynamic_programming

Pierwsze 100 dni

W poszczególnych rozdziałach wymieniłem wiele elementów, które są przepisem na sukces wykorzystania danych w organizacji — sukces, definiowany specyficznymi dla organizacji celami. Wymienione czynniki mają pomóc, ale od czego zacząć, gdy startuje się w nowej firmie? Na czym skupić się w kolejnych etapach?

W rozdziale tym zajmę się tematem jak hipotetycznie rozłożyć wymienione w książce zagadnienia na etapy do wykonania. W realnych sytuacjach niezbędna będzie modyfikacja planu, jednak wyjście od niego powinno być pomocne i zmniejszyć ryzyko pominięcia ważnego aspektu w odpowiednim czasie.

Etap pierwszy: identyfikacja stanu początkowego

Etap pierwszy skupia się na identyfikacji aktualnej sytuacji, we wszystkich wymienionych wcześniej tematach. Bez tego trudno wyobrazić sobie zarówno zdefiniowanie konkretnego celu, jak również wyciągnięcie jakichkolwiek wniosków z bieżącego stanu i określenie kierunków zmian. Etap pierwszy to także identyfikacja zasobów, kompetencji, nawiązywanie kontaktów i określanie ram współpracy. Dobre wykorzystanie tego czasu to inwestycja w pozostałe etapy i zapewnienie skuteczności podczas dalszych prac. Można zabrać się z zapałem do pracy i kontynuować wcześniejsze kierunki, co może, ale nie musi być najlepszym rozwiązaniem, powinno to być poprzedzone świadomą decyzją. Inną pułapką może być sytuacja, w której lider nie przedstawia raportu otwarcia, a w firmie jest wiele nienazwanych problemów. W takiej sytuacji problemy te stają się jego „zasługą” i poważną trudnością. Skuteczne zdystansowanie się wobec zaszłości i problemów oraz próba ich rozwiązywania bez negatywnego bagażu, daje o wiele większą szansę na pomyślne przejście najtrudniejszych zagadnień. Pierwszy etap dla lidera jest szansą, dla organizacji często jest nadzieją na nowe spojrzenie, krytyczny odbiór tego, co było robione do tej pory. Szansę wynikającą z pierwszego etapu należy wykorzystać. Nie oznacza to, że wszystko, co było realizowane wcześniej jest złe. Należy ograniczać takie negatywne nastawienie, ponieważ to nie jest dobra droga. Elementy pozytywne trzeba wzmacniać, a problemom trzeba się przyglądać i upewnić, że faktycznie są problemami. Pierwsze spojrzenie może nie oddawać prawdziwego obrazu. Po przyjrzeniu się firmom i wielu projektom, pierwsze wnioski w osiemdziesięciu procentach przypadków stają się jednak trafne. Należy jednak pamiętać o pozostałych dwudziestu. Złe decyzje w przypadku nietypowych sytuacji mogą być niezwykle kosztowne, dlatego lepiej jest działać wolniej, ale pewnie, niż odwracać wcześniej wyznaczony kierunek.

Etap drugi: strategia v0.1

W drugim etapie zakładamy, że mamy już przeanalizowaną, w najlepszy możliwy sposób bieżącą sytuację w firmie. „Najlepszy możliwy” nie oznacza „idealny”. Musimy się zgodzić, co do tego, że nigdy nie będziemy mieli idealnego obrazu, idealnych decyzji i nigdy nie pozbędziemy się błędów. To jest niezwykle istotne założenie, pozwala uniknąć stresu i zdecydowanie zwiększa swobodę działań. Otwarta i transparentna komunikacja o adaptacyjnym podejściu i otwarciu na błędy i pomyłki, nawet na poziomie strategii, może być trudna w akceptacji. Jednak warto pielęgnować taką otwartość. Jest to także pozytywne dla zespołu. Po pewnym czasie, zespół zacznie działać w podobnej filozofii. Będzie podejmował coraz odważniejsze decyzje w miejscach, w których są one niezbędne i w zakresie, do którego poszczególni członkowie zespołu mają kompetencje i prawo. Takie podejście pozwoli konsekwentnie klarować obraz tego, jak odbieramy problemy w firmie i bez trudu odciąć stare, gorsze, czy też błędne spojrzenie.

Rzeczywistość przeważnie jest na tyle skomplikowana, że rozpoznawanie poszczególnych aspektów nie może się odbyć w krótkim czasie. Stale dochodzą nowe czynniki powodujące zmiany. Rynek jest dynamiczny, firmy są dynamiczne i podobnie dzieje się z celami i technologią. Podejście adaptacyjne pozwala już po krótkim czasie pokazać nasz sposób widzenia i przez to umożliwia innym korektę, a wszelkie korekty dają szanse na lepsze decyzje. Nie należy rezygnować z takich szans, trzeba ich szukać. Niezmiernie ważne w tym podejściu jest to, że nie przywiązujemy się do wczorajszych decyzji, które okazały się błędne. Jeśli firma wymaga wywiązywania się z obietnic, które po kilku miesiącach tracą sens, należy zainwestować energię w zmianę tego podejścia, odpowiednio komunikując jego konsekwencje. Jest wiele firm, które cementują raz przyjętą strategię i spodziewają się, że jej wysoka ranga, jest podstawą do tego, aby jej nie zmieniać. To podejście zamyka dynamikę zmian i może być wielkim problemem, nawet dla bardzo stabilnych branż.

Nie rezygnujmy z siły, jaką daje adaptacyjne podejście do strategii nawet, gdy nie spodziewamy się wielkich zmian, mocny silnik w samochodzie przydaje się także wtedy, gdy nie wykorzystujemy na co dzień jego mocy, może uratować życie!

Poniższa tabela zawiera zadania potrzebne do zdefiniowania inicjalnej strategii. Nie należy zwlekać z jej komunikacją. Czym wcześniej zostanie ujawniona, tym wcześniej zostanie poprawiona. Bez pierwszego sprawdzenia, nie uzyskamy informacji niezbędnych do określenia właściwego kierunku. Pierwsza strategia nie jest decyzją, ale jest określeniem najbardziej prawdopodobnego kierunku, a także pytaniem postawionym wielu osobom jednocześnie o potwierdzenie tego kierunku.

Etap trzeci: egzekucja i adaptacja

Etap realizacji i przystosowywania się to okres, w którym prędkość działania zespołów jest największa. Najważniejsza staje się realizacja projektów i dostarczanie wartości biznesowej określonej wcześniej, odpowiednie reagowanie na problemy i eliminowanie ich, zapewnienie zasobów i antycypacja problemów, które mogą wystąpić. Lider na tym etapie ma teoretycznie mniej pracy koncepcyjnej, jednak to tylko pozory. Badanie sygnałów dobiegających z projektów, ale także reagowanie na nowe potrzeby, które nie przestają się pojawiać, powoduje konieczność podejmowania ważnych decyzji. Tu niezwykłą rolę odgrywa intuicja i posiadana już znajomość organizacji. Pozwala ona odpowiednio interpretować zwykłe sygnały, dobiegające z różnych miejsc. Warto być blisko realizowanych prac. Nie oznacza to, że musimy operacyjnie pracować w projektach. Dobrym punktem styku z projektami są podsumowania etapów i pokazy nowych funkcjonalności, spotkania właścicieli produktów lub miejsca, w których podejmowane są znaczące decyzje. Nie oznacza to, że CDO powinien podejmować decyzje za członków zespołu, ale winien wnosić swój punkt widzenia i nie blokować pracy. CDO ma ingerować w sytuacjach, gdy zespół nie widzi tego, co widzi lider. Kluczową kompetencją na tym etapie jest konsekwencja w realizacji, nawet w sytuacji wątpliwości i słabszych momentów poszczególnych zespołów. Aby wzmocnić konsekwentne dążenie do celu, ważne stają się aspekty motywacyjne dla zespołu i przestrzeń dająca możliwości realizacji podjętych już zobowiązań.

Etap zamykający: podsumowanie etapu transformacji

Etap ten może zamykać transformację, może kończyć jej istotny okres i jest to przygotowanie kompletnego stanu, w którym znajduje się firma, głównie w celu podjęcia decyzji o następnych strategicznych krokach. Może być przygotowaniem dla ważnych zmian. Zatrudniany CDO powinien mieć w perspektywie etap zamknięcia prac, daje to, zatrudniającemu go zarządowi, bezpieczeństwo kontynuacji biznesowej i pewność, że do kontynuacji misji nie trzeba będzie wymieniać lidera. W przypadku pomyślnego zamknięcia, wskazane jest, aby kontynuować dobrze realizowane zadanie.

Wymienione etapy to typowy przebieg misji CDO wykorzystującego dane na cele biznesowe w skali całej organizacji. We wcześniejszych rozdziałach skupiałem się na poszczególnych wymiarach tego zadania, a były nimi: cel biznesowy, dane, architektura i ludzie. W ostatnim rozdziale dokonałem próby ułożenia tych wszystkich wymiarów na osi czasu — zamknąłem je w kilka etapów.

Rys. 42: Etapy wdrożenia strategii przez CDO.

Nowe potrzeby i uwarunkowania, w których znajdzie się firma, powodują, że transformacja staje się procesem ciągłym. Odpowiednie umiejscowienie w takiej permanentnej transformacji obszaru danych poprawia jej skuteczność. Połączenie istotnej dla firmy transformacji biznesowej ze zmianami w obszarze danych może być optymalnym krokiem dla wielu firm chcących regularnie i nie przypadkowo wygrywać na rynku.

Szanowny czytelniku!

Dziękuję Ci za Twój czas spędzony na lekturze mojej książki. Jeśli udało mi się dostarczyć Ci inspiracji, zwrócić Twoją uwagę na coś ważnego lub dostarczyć wartości, podziel się ze mną. Możliwe, że użyję Twojego przykładu w przyszłości. Jestem otwarty na uwagi i Twoje unikalne doświadczenie. Kontakt do mnie znajdziesz na stronie www.chiefdataofficer.pl.

Mariusz Jażdżyk

Warszawa, listopad 2019