Bezpłatny fragment - Chief Data Officer

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, 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, 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 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.

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.

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”. 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. 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.

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.

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.

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.

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ć.

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. 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).

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.

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