Fiasko projektów związanych z analizą danych często bywa wynikiem błędnego zdefiniowania problemu. Odpowiednie podejście na wczesnym etapie może temu zapobiec.
Inicjatywy z dziedziny data science stanowczo zbyt często kończą się niepowodzeniem – szacuje się, że dotyczy to ponad 80% z nich. Poświęciliśmy lata na badanie czynników przyczyniających się do tego, że sukcesy przychodzą tak rzadko, i odkryliśmy wśród nich pewien problem, któremu poświęca się zbyt mało uwagi: nader często zespoły od razu przystępują do pracy z danymi, nie uzgodniwszy najpierw, jaki właściwie problem chcą rozwiązać. Ten pierwotny brak zrozumienia sprawia, że projekt zostaje skazany na porażkę, zanim jeszcze na dobre się rozpocznie.
Oczywiście nie jest to nowy problem. Albertowi Einsteinowi często przypisuje się słowa: „gdybym miał godzinę na uratowanie planety, poświęciłbym 59 minut na zdefiniowanie problemu – i minutę na jego rozwiązanie”.
Główne źródło niepowodzenia bierze się z faktu, że nader często zespoły przystępują do pracy z danymi, nie uzgodniwszy najpierw, jaki właściwie problem chcą rozwiązać.
Zastanówmy się, jak często analitycy muszą rozpocząć pracę od „uporządkowania danych” – zwykle jak najszybciej i jak najmniejszym kosztem. Może to wydawać się rozsądne, ale takie spojrzenie pomija kluczowe pytanie: dlaczego? Dlaczego w zbiorze są „złe” dane? Skąd się wzięły? Czy niepasujące punkty danych faktycznie są efektem pomyłki, czy może jednak są poprawne, a tylko zaskakujące? Czy podobne anomalie pojawią się w przyszłości? Jak jakość danych wpłynie na ten konkretny projekt i na szerszą działalność firmy? W wielu przypadkach okazuje się, że zadaniem powinno być wykrycie i eliminacja pierwotnych przyczyn wystąpienia anomalii w zbiorze danych.
Zbyt często widzimy, jak ludzie albo zakładają, że rozumieją problem, i w pośpiechu ruszają, by go rozwiązać, albo nie dbają o zbudowanie konsensusu niezbędnego do znalezienia skutecznego rozwiązania. Uważamy, że kluczem do powodzenia projektów analityki danych jest dostrzeżenie wagi jasnego zdefiniowania problemu i dokonanie tego zgodnie ze sprawdzonymi zasadami. To wyzwanie nie dotyczy tylko zespołów programistycznych – obserwujemy, że liczne inicjatywy biznesowe, polityczne czy związane z zarządzaniem lub mediami, na różnych szczeblach, są trapione przez niewłaściwe zdefiniowanie problemu.
PRZECZYTAJ TAKŻE
Dlaczego projekty z zakresu analizy danych nie przynoszą spodziewanych rezultatów
Nowe technologie | Digitalizacja Mayur P Joshi , Ning Su , Robert D. Austin , Anand K. SundaramOrganizacje mogą uzyskać konkretne korzyści biznesowe dzięki zaawansowanej analizie, jeśli tylko uda im się zidentyfikować i pokonać pięć typowych przeszkód.
Krok w stronę właściwego określenia problemu
Data science posługuje się metodą naukową w rozwiązywaniu często złożonych (lub wielopłaszczyznowych) i nieustrukturyzowanych problemów z wykorzystaniem danych i analityki. W analityce określenie „wyprawa na połów” (fishing expedition) dotyczy projektu, któremu nie nadano na samym początku właściwych ram, w efekcie czego praca polega na ślepym przeszukiwaniu zbioru danych pod kątem niespodziewanych korelacji. Tego rodzaju „łowienie” trendów nie jest zgodne z duchem efektywnej analizy danych, ale występuje powszechnie, toteż o poprawnym zdefiniowaniu problemu trzeba pamiętać przede wszystkim.
Wcześniej proponowaliśmy tworzenie „pomostów” organizacyjnych między zespołami data science i jednostkami biznesowymi, prowadzonych przez liderów innowacji – osoby posługujące się zarówno językiem analityków, jak i menedżerów – podlegające bezpośrednio dyrektorom wykonawczym. Taki lider to idealny kandydat do przejęcia pełnej odpowiedzialności za przestrzeganie poniższych zasad.
Włącz do projektu odpowiednich ludzi. Chcąc pozyskać poprawne dane wejściowe do określenia problemu, musisz już na samym początku włączyć w prace wszystkie kluczowe osoby, których wkład jest niezbędny, żeby projekt zakończył się sukcesem. W końcu analityka danych to interdyscyplinarny i transdyscyplinarny sport drużynowy. W zespole powinni znaleźć się „właściciele” problemu, dostarczyciele danych, osoby odpowiedzialne za analitykę oraz osoby zajmujące się wszelkimi aspektami implementacji rozwiązań. Możesz rozważyć poszczególne aspekty projektu, posługując się macierzą RACI: wyszczególnić osoby wykonujące zadania (responsible), osoby decyzyjne (accountable), osoby, z którymi należy się skonsultować (consulted) oraz osoby, które trzeba poinformować o stanie prac (informed).
Pamiętaj, że precyzyjne zdefiniowanie problemu wymaga ciężkiej pracy. Często widzimy, że definicja problemu zmienia się, w miarę jak próbuje się ją doprecyzować. Liderzy projektów analityki danych powinni zachęcać do dyskusji, nie oszczędzać czasu i szczegółowo dokumentować proces określania problemu w jego trakcie. Dzięki temu można mieć pewność, że wszyscy zgodzą się co do istoty problemu, zanim przejdzie się do szukania rozwiązań.
Nie myl problemu z propozycją rozwiązania. Wyobraź sobie bank, który traci udział w rynku kredytów konsumenckich i którego zarząd uważa, że konkurenci posługują się bardziej zaawansowanymi modelami. Łatwo stąd przeskoczyć do definicji problemu brzmiącej mniej więcej tak: „zbudować bardziej wyrafinowane modele ryzyka kredytowego”. W takim postawieniu sprawy kryje się jednak założenie, że to właśnie bardziej szczegółowy model jest rozwiązaniem problemu spadającego udziału w rynku – założenie przyjęte bez rozważenia możliwych alternatyw takich jak zwiększenie liczby pracowników przyznających kredyty, lepsze szkolenia sprzedażowe czy walka z nowymi konkurentami za pomocą skuteczniejszego marketingu. Mylenie problemu z proponowanym środkiem zaradczym w zasadzie gwarantuje, że problem nie zostanie dobrze zrozumiany, ogranicza też kreatywność i zmusza do szukania rozwiązań po omacku. Lepsza definicja problemu brzmiałaby: „przeanalizować przyczyny utraty udziału w rynku kredytów konsumenckich i zaproponować rozwiązania możliwe do wdrożenia”. Być może rozwiązaniem będą bardziej zaawansowane modele – a być może nie.
Odróżniaj problemy pośrednie od głębszej praprzyczyny. W naszym pierwszym przykładzie istnienie anomalii w zbiorze danych jest problemem pośrednim, którego praprzyczyną jest to, co doprowadziło do powstania tych anomalii. Co ważne, stwierdzenie: „nie wiemy dostatecznie dużo, żeby w pełni zdiagnozować źródła anomalii danych”, to uczciwe podsumowanie stanu rzeczy, wskazujące na konieczność przeprowadzenia mniejszego podprojektu.
Nie zamykaj fazy określania problemu, dopóki jego definicja nie spełnia poniższych kryteriów.
1. Nie grozi szkodami. Może nie być jasne, jak rozwiązać zdefiniowany problem, ale musi być oczywiste, że jego rozwiązanie będzie korzystne dla biznesu. Jeśli są co do tego wątpliwości, problem trzeba doprecyzować. Weźmy wcześniejszy przykład z bankiem. Wprawdzie istniejące modele można łatwo dostosować tak, żeby wnioski kredytowe rzadziej były odrzucane, jednak to mogłoby znacząco podnieść poziom ryzyka – a to jest nieakceptowalne. Właściwym celem powinno być zwiększenie udziału w rynku bez zwiększonego ryzyka, stąd „rozwiązania możliwe do wdrożenia” w podanej wyżej definicji problemu.
2. Uwzględnia warunki brzegowe. W przykładzie z bankiem możemy przyjąć, że wdrożenie bardziej zaawansowanych modeli ryzyka wymagałoby zatrudnienia dodatkowych wysoko wykwalifikowanych pracowników zajmujących się kredytami – bank może być temu niechętny. Wszelkie warunki brzegowe, dotyczące na przykład czasu, budżetu, technologii oraz zasobów ludzkich, powinny być wyrażone wprost, żeby uniknąć sytuacji, w której definicja problemu jest niezgodna z celami biznesowymi.
3. Obejmuje macierz odpowiedzialności (lub jej odpowiednik). Zgodna współpraca ma decydujące znaczenie, więc zadbaj o to, żeby wszystkie osoby zaangażowane w poszukiwanie rozwiązania w pełni rozumiały swoje role i zakres odpowiedzialności. Jeszcze raz polecamy macierz RACI.
4. Jest akceptowana przez interesariuszy. Nieprawidłowa czy kontrowersyjna definicja problemu często wywołuje opór w szeregach organizacji. W ekstremalnych przypadkach nieprzekonane osoby mogą podjąć próby odstrzelenia projektu, doprowadzenia do jego klęski. Postaraj się wypracować powszechny (choć niekoniecznie jednogłośny) konsensus w sprawie definicji problemu w gronie liderów, osób zaangażowanych w rozwiązywanie problemu oraz końcowych klientów (czyli tych, których obejmą zmiany).
Wszyscy – zarówno analitycy danych, jak i liderzy biznesu czy polityki – musimy nauczyć się właściwie definiować właściwe problemy.
Poświęcanie czasu na ścisłe zdefiniowanie problemu może wywoływać dyskomfort. Ostatecznie żyjemy i pracujemy w kulturze, która domaga się efektów, i chcemy natychmiast przejść do działania. Tymczasem pójście na skróty na tym etapie przypomina stawianie wozu przed koniem – po prostu nie działa. Nie ma alternatywy dla głębszego namysłu, zaangażowania właściwych ludzi i poświęcenia czasu na zrozumienie istoty problemu. Wszyscy – zarówno analitycy danych, jak i liderzy biznesu czy polityki – musimy nauczyć się właściwie definiować właściwe problemy.
PRZECZYTAJ TAKŻE
Podejmuj decyzje na podstawie właściwych danych
Prowadzenie firmy | Zarządzanie usługami IT, Podejmowanie decyzji Stefano Puntoni , Bart de LangheAnalitycy często nie potrafią generować wniosków, które pomagałyby w podejmowaniu trafnych decyzji biznesowych, ale to nie ich wina. Przywódcy muszą zadbać o to, aby analityka bazowała na potrzebach decyzyjnych.
