Analiza danych dla menedżerów. Jak zrozumieć i wykorzystać dane dostępne w twojej firmie - ebook

PODZIĘKOWANIA

Ta książka stanowi kulminację wielu lat burz mózgów, dyskusji i wprowadzania zmian.

Chcielibyśmy podziękować wielu osobom, od których otrzymaliśmy komentarze, sugestie i wsparcie podczas pisania, recenzowania i poszukiwania pomysłów. Są to między innymi Alan Friedman, Jerry Friedman, Alysen Friedman, Arthur Goldwag, Daniel Guetta, Caroline Bastian, Jeff Chen, Kim Sweeny, Paul Thurman, Sam Natarajan, Lathan Liou i Tina Seelig.

Na podziękowania za zestawienie odnośników w całym rękopisie zasłużyli Shreya Parchure, Matt Swanson i Christian Caravaglia.

Chcielibyśmy podziękować również Mylesowi Thompsonowi i Brianowi Smithowi za wskazówki i opinie, kiedy w ramach tego projektu przekształcaliśmy wstępny szkic w produkt końcowy.

Doceniamy umiejętności redaktorskie Bena Kolstada i Marielli T. Poss.

A.S.: Chciałbym podziękować współautorowi, Howardowi Friedmanowi, za możliwość współpracy w tym ważnym projekcie. Czerpanie z wieloletniego doświadczenia pisarskiego i pedagogicznego Howarda było naprawdę pouczające. Jego cierpliwość, wspaniałomyślność i mentoring ukształtowały mnie jako pisarza i osobę.

Chcę podziękować swojej najbliższej rodzinie za nieustające wsparcie i otuchę. Priya Swaminathan, Sam Natarajan, Goutham Swaminathan, Raji Natarajan, Veeraswamy Natarajan, Kamala Natarajan (imienniczka bohaterki tej książki) – dziękuję.

Moim przyjaciołom, Lathanowi Liou, Lucii Tu, Ivánowi Lópezowi i Menace Narayanan, dziękuję za bezcenne opinie i inspiracje podczas tworzenia tej książki. Szczególnie dziękuję Pranayowi Nadelli, z którym opracowałem 30-dniowy kurs „Wykrywanie fałszywych statystyk w prawdziwym życiu”, będący bogatym źródłem inspiracji dla wielu rozdziałów tej książki.

Na koniec dziękuję też swoim mentorom, kolegom i współpracownikom, od których dowiedziałem się tak wielu rzeczy na temat statystyki, analizy danych, pisania, komunikacji oraz współpracy interdyscyplinarnej. Są to: S.V. Subramanian, Vikram Patel, Arthur Kleinman, Daniel Corsi, Gidon Eshel, Tinku Thomas, Olivier Humblet, Jeremy Snider, Arjun Sondhi, Blythe Adamson, Brian Segal, David Mou i Sid Salvi.

H.F.: Chciałbym zacząć od podziękowania współautorowi tej książki, Akshayowi Swaminathanowi, który był dla mnie błyskotliwą inspiracją i wspaniałym współtwórcą. Bez jego wizji ta książka ugrzęzłaby na wiele lat w martwym punkcie.

Serdecznie dziękuję Shui Chen i Howardowi Chenowi Friedmanowi Jr za ich miłość, otuchę i wsparcie.

Jestem wdzięczny Arthurowi Goldwagowi, który podczas pisania tej książki był dla mnie przyjacielem i mentorem.

Inspiracją dla dużej części tej książki byli wielcy przywódcy i współpracownicy, z którymi działałem w przeszłości. Osoby, którym chcę tu podziękować, to: Prakash Navaratnam, Joe Gricar, Kim Heithoff, Nathan Hill, Dorie Clark, Mark Jordan, David Todd, Nelson Lin, Whit Bundy, Jack Harnett, Kyle Neumann, Xena Ugrinsky, Afsheen Afshar, Charles Solomon, Armen Kherlopian, Emma Arakelyan, Armen Aghinyan, Arby Leonian, Conner Raikes, Derrick Perkins, Gavin Miyasato, Mohit Misra, Vamsi Kasivajjala, Wlad Perdomo, Mark Jordan, Rachel Schutt, Brandt McKee, Jason Mozingo, Daniel Lasaga, Russ Abramson, Natalia Kanem, Diene Keita, Julitta Onabanjo, Will Zeck, Anneka Knutsson, Arthur Erken, Ramiz Alakbarov, Frank Rotman i Peter Schnall.1 NARZĘDZIA PRACY

Steve i Shu Money Financial

W domu Steve był zawsze trochę złotą rączką. Wykonywał drobne prace hydrauliczne i elektryczne, a jego dumą i radością był zestaw szafek, które samodzielnie zaprojektował, zbudował i zamontował. Na jego stole warsztatowym można było znaleźć niemal wszystkie narzędzia, jakie można sobie wyobrazić: elektryczne szlifierki, pełny zestaw wierteł i frezów, strugi, ponad trzydzieści typów śrubokrętów i piłę stołową. Umiejętnie posługiwał się każdym narzędziem i wiedział, kiedy i gdzie każde z nich powinno być używane, a kiedy nie powinno.

Ale Steve nie siedział teraz w domu. Wpatrywał się w ekran komputera, będąc na półmetku swojej dwuletniej rotacyjnej pracy w Shu Money Financial. Była to jego pierwsza prawdziwa praca zaraz po ukończeniu studiów MBA w Columbia Business School. Dlaczego podjął tę pracę w branży kredytów konsumenckich? Firma Shu Money Financial niezmiennie była zaliczana do grona najlepszych pracodawców w Stanach Zjednoczonych. Dużo inwestuje w swoich pracowników i traktuje ponad dwudziestotysięczną załogę jak jedną wielką rodzinę. „Shusterzy” – jak mówią o sobie pracownicy Shu – są dumni z tego, że korzystają z najnowocześniejszej technologii, rzucając akronimami i żargonem, który Steve z trudem mógł zrozumieć.

Głównym zadaniem Steve’a było kierowanie opracowywaniem nowej strategii priorytetyzacji spraw wysyłanych do Departamentu Windykacji. Przepływ klientów do tego departamentu jest prosty. Jeśli klient nie spłaci żadnej części zadłużenia z ostatnich sześciu miesięcy, dług jest uznawany za „zły”. Tak dzieje się w przypadku każdego produktu finansowego oferowanego przez Shu Money Financial – zadłużenia karty kredytowej, linii kredytowej, kredytu samochodowego lub hipotecznego. Klient ze złym długiem jest wtedy przekazywany do Departamentu Windykacji, którego zadaniem jest odzyskanie możliwie największej kwoty.

Tego ranka Steve spotkał się z firmowym zespołem specjalistów ds. danych. Na początek koledzy pokazali mu oszałamiająco długą listę języków programowania, narzędzi programistycznych oraz metod wdrażania stosowanych w ciągu ostatnich trzech lat. Oczy mu zabłysły, kiedy członkowie zespołu opowiadali o swoich produktach danych, które dostarczyli innym jednostkom w firmie. To był pierwszy projekt, który zespół specjalistów ds. danych realizował dla Departamentu Windykacji.

Steve był poruszony i przytłoczony. Chciał zrozumieć wszystko, o czym wspominali członkowie zespołu specjalistów ds. danych, i nie wprawić się w zakłopotanie. Chciał, żeby postrzegali go jako kompetentnego przyszłego lidera firmy. Zaczął myśleć o dyskusji na temat badania danych i znów poczuł ucisk w piersiach.

Jednak zaraz przypomniał sobie, że to nie on tworzy rozwiązanie. On jest klientem.

Zamiast zestawiać arkusze papieru ściernego o różnej ziarnistości, drewno, wiertła i piły, musiał zachowywać się jak klient. Gdyby kupował szafki i wynajmował kogoś do ich zamontowania, wiedziałby, jakie powinny mieć wymiary, gdzie je zamontować i jak dokładnie je użytkować. Zleciłby specjalistom od szafek przygotowanie rozwiązania i zadbałby, żeby produkty zaspokajały jego potrzeby.

To go trochę uspokoiło. Nie musiał być ekspertem od każdego narzędzia w zestawie do badania danych. Jego zadaniem było skupienie się na problemie, który miał do rozwiązania. Choć jest prawdą, że różne narzędzia lepiej pasują do różnych rozwiązań, nie zamierzał podejmować decyzji co do tego, z jakich urządzeń do przechowywania danych, programów, języków programowania i innych narzędzi skorzystać. Musiał jedynie zrozumieć opcje i konsekwencje rekomendacji zespołu specjalistów ds. danych. Gdyby miał jakieś szczególne potrzeby lub ograniczenia, musiałby zadbać o to, by członkowie zespołu specjalistów ds. danych dobrze je zrozumieli i żeby wymagania co do projektu zostały uwzględnione w ich rekomendacjach i rozwiązaniach. Na przykład to, że być może będzie trzeba wdrożyć to rozwiązanie w ciągu najbliższych dwóch miesięcy, że będzie potrzebował jasnego określenia kamieni milowych i oczekiwanych efektów i że koszt całego projektu nie może przekroczyć 50 tysięcy dolarów.

Głównym celem Steve’a było rozwiązanie problemu biznesowego. W tym wypadku jego zadaniem była lepsza priorytetyzacja pracy Departamentu Windykacji.

Myśląc o Departamencie Windykacji jak o firmie z własnym rachunkiem zysków i strat, Steve chciał zmaksymalizować sumę odzyskanych środków, równocześnie minimalizując niezbędne koszty operacyjne. Departament miał środki wystarczające jedynie na podjęcie poważniejszych działań wobec ograniczonej liczby przypadków. W innych klienci po prostu otrzymywali automatyczny e-mail albo powiadomienie telefoniczne, co zazwyczaj skutkowało brakiem kontaktu z klientem i – co nie dziwi – nieodzyskaniem środków. Większość długów była sprzedawana zewnętrznym agencjom windykacyjnym. Dysponując ograniczonymi środkami, Steve nie mógł po prostu zwiększyć dwu- lub trzykrotnie zatrudnienia w Departamencie Windykacji, ponieważ to najprawdopodobniej jeszcze bardziej obniżyłoby zyski jednostki.

Chciał przede wszystkim zrozumieć aktualnie stosowane metody priorytetyzacji klientów i przypisywania ich opiekunom z Departamentu Windykacji. Odkrył, że obecna metoda jest dość prosta. Każdy klient, który kiedykolwiek dokonał jakiejś płatności, był zaliczany do kategorii 1. Każdy klient, który nigdy nie zapłacił, ale utrzymywał jakiś kontakt e-mailowy lub telefoniczny z Departamentem Obsługi Klienta, Departamentem Windykacji lub inną jednostką banku, trafiał do kategorii 2. Wszyscy klienci, którzy nigdy niczego nie zapłacili i w ogóle nie nawiązali kontaktu z żadnym z tych departamentów, stanowili kategorię 3. Te zasady klasyfikacji zostały stworzone przez poprzedniego dyrektora Departamentu Windykacji w oparciu o intuicję i kilkudziesięcioletnie doświadczenie zawodowe.

Steve rozumiał, że jego celem jest zwiększenie zyskowności Departamentu Windykacji przez poprawę nadawania priorytetów w pracy. Natychmiast zauważył, że priorytetyzacja dokonywana według aktualnych zasad nie opiera się na podejściu, w którym na podstawie danych można by prognozować, którzy klienci najprawdopodobniej spłacą przynajmniej część zadłużenia oraz jakiej wielkości spłaty można się spodziewać. Aktualna polityka w tym zakresie polegała na uproszczonym podejściu do priorytetyzacji obłożenia pracą z wykorzystaniem wiedzy o dotychczasowych zachowaniach klienta do podjęcia decyzji, w jaki sposób odzyskiwać dług obecnie i w przyszłości. Zmienne stosowane w tych zasadach biznesowych mogą mieć pewne zalety, na przykład słuszne wydaje się założenie, że klienci, którzy wcześniej płacili Shu Money Financial, prawdopodobnie będą bardziej skłonni zapłacić w przyszłości. Może jednak istnieć wiele innych czynników pozwalających prognozować prawdopodobieństwo otrzymania przyszłych wpłat, ich przewidywaną wysokość oraz to, jak będzie reagował klient i jakie będą najkorzystniejsze sposoby współpracy z nim. Na takie pytania można poszukiwać odpowiedzi, stosując podejście oparte na danych. W tym celu trzeba zebrać odpowiednie dane o klientach, a potem systematycznie je analizować, nie polegając wyłącznie na intuicji i doświadczeniu. Steve uświadomił sobie, że gdyby potrafił przewidzieć, którzy klienci z największym prawdopodobieństwem spłacą najwyższe kwoty, mógłby zoptymalizować priorytetyzację klientów pod kątem zasobów ludzkich, czasu i pieniędzy, jakimi dysponował jego departament. W tym schemacie długi o najniższej prawdopodobnej kwocie do odzyskania otrzymywałyby najniższy priorytet albo byłyby sprzedawane zewnętrznej agencji windykacyjnej.

Steve umówił kolejne spotkanie z zespołem specjalistów ds. danych, aby przedyskutować swój problem i zrozumieć, na czym polegają proponowane rozwiązania. Przed spotkaniem przejrzał podstawowe informacje na temat danych, systemów danych oraz architektury danych. Jego skromnym celem była możliwość zadawania dobrych pytań.

Przepływ danych

Podstawowy przepływ danych składa się z pięciu etapów: zbierania danych, przechowywania, przygotowania, eksploracji i modelowania, w tym eksperymentowania i prognozowania (rysunek 1.1). W ramach procesu przepływu danych zespół specjalistów ds. danych przygląda się kluczowym czynnikom i podejmuje kluczowe decyzje, które będą miały wpływ na produkt końcowy. Potoki danych przenoszą dane do określonych etapów przez zautomatyzowane zbieranie i przechowywanie danych. Ta automatyzacja może być zaplanowana cyklicznie lub uruchamiana przez określone wydarzenie. Jakość danych i procesy transferu danych są monitorowane za pomocą generowanych alertów, ale decyzje muszą być podejmowane stosownie do wymogów kontroli jakości. Wprowadzenie standardów danych wymaga zrozumienia zarówno danych, jak i biznesu.

Standardowe podejście do zbierania elementów danych z różnych źródeł, a potem ich integracji, czyli przenoszenia do jednej lokalizacji, jest znane jako proces ETL (z ang. extract, transform, load, czyli wyładowanie ze źródeł, przeprocesowanie i załadowanie do miejsca docelowego). Etap ekstrakcji zachodzi wtedy, kiedy dane są po raz pierwszy wyładowywane ze źródła. Źródłami mogą być zarówno istniejące bazy danych, jak i nowo tworzone źródła, począwszy od danych kupowanych w hurtowniach, przez dane pozyskiwane z internetu, aż po standaryzowane relacyjne bazy danych klientów. Departament Windykacji posiada wewnętrzne dane na temat zakupów i płatności klientów oraz historii ich kontaktów – rozmów telefonicznych, e-maili i listów. Ma również dostęp do zewnętrznych danych z raportów biur kredytowych, z baz danych ludzi zmieniających miejsce zamieszkania, z wpisów niektórych klientów w mediach społecznościowych, a nawet z rejestru zgonów. Posiada również szczegółowe informacje na temat demografii różnych lokalizacji geograficznych i lokalnych wskaźników ekonomicznych, takich jak na przykład powtarzające się wzorce w ruchu pieszym. Wszystkie te dane można wydobyć ze źródeł i potencjalnie załadować do analizy.

Rysunek 1.1. Etapy przepływu danych

Etap procesowania lub przetwarzania ma kluczowe znaczenie dla zapewnienia jakości danych. Może on obejmować identyfikację i usuwanie niespójności oraz brakujących wartości, standaryzację formatowania, usuwanie zdublowanych rekordów i błędnie wprowadzonych danych wejściowych. W przypadku Steve’a musiał on zadbać o to, aby zespół specjalistów ds. danych zapewnił właściwą kontrolę nad danymi wejściowymi. Potrzebna jest pewność, że dane wejściowe są zdecydowanie pozbawione nieprawidłowości i że nie identyfikują błędnie klientów noszących to samo nazwisko. To wymaga od zespołu specjalistów ds. danych wykonania logicznej weryfikacji źródeł danych oraz poszczególnych zmiennych pochodzących z tych źródeł. Wiadomo, że osoba znajdująca się w bazie danych nie może mieć więcej niż 130 lat. To bardzo prosty przykład błędnych danych, ale co zrobić z osobą, która codziennie dzwoni do Departamentu Obsługi Klienta? Czy to prawdziwa informacja, czy błąd punktu danych? Wiemy wprawdzie, że 130-latek to błąd danych, ale będzie lepiej, jeśli zespół specjalistów ds. danych nawiąże bliską współpracę z ekspertami biznesowymi, aby wspólnie wymyślić kilka sposobów sprawdzenia jakości tych danych. Kontrola jakości jest niezbędna nie tylko dla zagwarantowania poprawności wyczyszczonych danych, ale również dla zapewnienia, że nie odrzucamy prawdziwych punktów danych nawet wtedy, kiedy wyraźnie odstają od reszty zbioru. W sytuacji, kiedy liczba telefonów o rzędy wielkości przewyższa średnią, możemy zachować tę informację (jeśli jest prawdziwa) i potem zastosować procesowanie, definiując nową zmienną odpowiadającą kategorii częstotliwości telefonów od klienta.

Zastosowanie nieprzeprocesowanych danych może prowadzić do niepoprawnych wyników. Problemy z danymi wejściowymi, takie jak nieodpowiednie potraktowanie brakujących danych, błędne wprowadzenie danych lub nieprawidłowe formatowanie, mogą skutkować błędnym modelowaniem i wątpliwej jakości prognozami. Rozważmy prostą sytuację, w której czasami zostają błędnie wprowadzone dane personalne klienta. Shu Financial faktycznie nie ma 130-letnich klientów, jednak baza danych zawiera kilka takich błędów na wejściu. Bez wyczyszczenia danych te niepoprawnie wprowadzone mogą potencjalnie mieć negatywny wpływ na trafność prognoz dla wszystkich klientów, a nie tylko dla tych, których dane wprowadzono z błędami.

Te przeprocesowane dane muszą zostać załadowane do swojej docelowej lokalizacji. Dane można załadować w całości jednorazowo lub robić to przyrostowo w zaplanowanych interwałach. Ładowanie przyrostowe polega na dodawaniu kolejnych rekordów do lokalizacji docelowej tylko wtedy, kiedy przeprocesowane dane zawierają nowe informacje w stosunku do tego, co już się tam znajduje.

W pewnych sytuacjach klient może być źródłem bardzo trafnych spostrzeżeń i przemyśleń związanych z procesami i decyzjami; w innych przypadkach zespół specjalistów ds. danych najczęściej będzie musiał postępować zgodnie ze standardami korporacji. Wprawdzie Steve ma specyficzne wymagania i problemy związane z tym konkretnym projektem, jednak wszystkie dobre architektury danych mają pewne podstawowe cechy i spełniają kilka podstawowych wymagań. Musi istnieć metoda umożliwiająca ich skalowanie i muszą one być dostępne dla użytkowników (z minimalnym czasem niedostępności), bezpieczne i spełniać zadania odpowiadające potrzebom klienta, a także być sensowne pod względem kosztów.