Rozwiązania oparte na sztucznej inteligencji często zawodzą, gdy specjaliści ds. danych nie weryfikują swoich założeń. W każdej dziedzinie przyjęcie postawy początkującego może okazać się pomocne.
Wieloletnie doświadczenie we wdrażaniu uczenia maszynowego (ML) w firmach, zarządzaniu nim i analizie jego funkcjonowania pokazało nam, że niepowodzenia projektów często wynikają z tego, że utalentowane i dobrze wyposażone zespoły data science przeoczają lub błędnie interpretują z pozoru proste elementy kontekstu biznesowego. Te braki stanowiły istotną przeszkodę w poprawnym rozumieniu danych, ich otoczenia oraz potrzeb użytkowników końcowych, co ostatecznie zagrażało efektywności i wartości, jaką modele ML mogłyby przynieść w praktyce.
Zauważyliśmy, że drobne błędy i nieporozumienia rzadziej prowadzą do porażek, gdy zespoły deweloperskie ściśle współpracują z działem biznesowym i zadają odpowiednią liczbę pytań, aby w pełni zrozumieć proces oraz problem, z którym się mierzą. Choć pytanie może wydawać się proste, często nie jest integralną częścią kultury danej organizacji, zespołu czy nawet całej branży. W wielu przypadkach demonstrowanie wiedzy i kompetencji jest jedynym sposobem na wykazywanie się w strukturach organizacyjnych. Mimo że specjaliści ds. danych zazwyczaj wyróżniają się zaawansowanymi umiejętnościami technicznymi, często brakuje im tzw. umiejętności miękkich, które są kluczowe do nawiązywania głębokiej, precyzyjnej komunikacji i zrozumienia z partnerami biznesowymi.
Jednocześnie partnerzy biznesowi nierzadko mają opory przed zadawaniem pytań i nie zawsze mają świadomość, jakie informacje lub kontekst mogą okazać się istotne dla zespołów data science. Zarówno po stronie biznesu, jak i zespołów technicznych konieczna jest intensywna współpraca, aby ich interakcje umożliwiały nowe odkrycie, a czasem nawet prowadziły do zakwestionowania założeń i w konsekwencji zidentyfikowania najistotniejszych aspektów kontekstu biznesowego.
Aby zapewnić sukces projektom ML dzięki wartościowym interakcjom, liderzy muszą promować kulturę, która normalizuje i ceni zadawanie pytań z perspektywy początkującego, zachęcając do odłożenia na bok ego oraz wcześniejszych doświadczeń. Jeden ze specjalistów ds. danych, z którym współpracowaliśmy, zauważył, że popełnia najmniej błędów, gdy działa w nowym kontekście, gdzie musi zadawać wiele pytań. Ale jakie pytania należy zadawać? W tym artykule przedstawiamy trzy przykłady dużych projektów ML, które zakończyły się niepowodzeniem, i analizujemy, jak zadawanie właściwych pytań z perspektywy początkującego mogłoby poprawić współpracę między specjalistami ds. danych a partnerami biznesowymi, zwiększając szanse na osiągnięcie sukcesu i stworzenie realnej wartości biznesowej.
SCENARIUSZ 1. Zadaj pytanie: „Jaki jest proces biznesowy?”, a nie: „Jaki jest zestaw danych?”
Podczas pierwszego spowolnienia gospodarczego wywołanego pandemią COVID‑19 lokalny zespół finansowy w międzynarodowej firmie detalicznej dostrzegł, że niektórzy klienci mogą przetrwać kryzys przy niewielkim wsparciu, inni będą bardziej narażeni na ryzyko bankructwa. Zastanawiali się, czy zespół ds. analizy danych mógłby pomóc przewidzieć, którzy klienci prawdopodobnie ogłoszą upadłość w najbliższych miesiącach. Tego rodzaju prognozy pozwoliłyby zespołowi finansowemu zidentyfikować wypłacalnych klientów i wesprzeć ich w trudnym czasie, tymczasowo zwiększając im limity kredytowe. Jednocześnie zminimalizowaliby ryzyko związane z klientami, którzy mogą wkrótce zbankrutować.
Zespół finansowy zwrócił się do zespołu IT z prośbą o przeprowadzenie analizy, a ten z kolei zaangażował centralny zespół ds. danych firmy, aby opracować odpowiedni model predykcyjny. Wykorzystując dostarczone dane, centralny zespół z sukcesem stworzył model, który w testach offline, opartych na danych historycznych, działał bardzo dobrze. Specjaliści ds. danych byli w stanie precyzyjnie przewidzieć, którzy klienci prawdopodobnie przestaną spłacać swoje zobowiązania. Jednak po wdrożeniu modelu w praktyce jego skuteczność znacznie spadła – okazał się bezużyteczny do przewidywania bankructw klientów z miesiąca na miesiąc mimo obiecujących wyników uzyskanych w testach i fazie prototypowej.
Brakujące ogniwo: zrozumienie procesu
Centralny zespół ds. analizy danych miał do dyspozycji kompletny oraz przekonujący zestaw danych, jednak ze względu na ograniczoną współpracę z zespołem, który zamówił model i miał go używać, nie zrozumiał kluczowych procesów biznesowych. Zespół nie miał wystarczającej wiedzy na temat procedur prawnych związanych z bankructwem w danym kraju ani o tym, w jaki sposób firma rejestrowała istotne wydarzenia związane z upadłością. Model został zbudowany na podstawie zmiennej wskazującej klientów, którzy już przestali regulować zobowiązania, a trenowano go, wykorzystując typowe wzorce transakcji tuż przed oznaczeniem klienta jako niewypłacalnego.
W rzeczywistości na osi czasu klientów ogłaszających bankructwo występowały trzy kluczowe etapy: najpierw klient przestawał wywiązywać się ze swoich zobowiązań, następnie składał wniosek o upadłość do sądu, a na końcu sąd wydawał orzeczenie o bankructwie. Zespół ds. danych nie wiedział, że klienci nie byli oznaczani jako niewypłacalni w momencie, gdy zaprzestawali regulowania płatności, ale dopiero po wydaniu orzeczenia przez sąd. W zestawie danych treningowych wszyscy klienci już byli oznaczeni jako niewypłacalni. Nie zdawano sobie sprawy, że w rzeczywistych warunkach na kontach klientów status niewypłacalności nie będzie widoczny przez mniej więcej rok od pierwszego braku płatności. Innymi słowy, model opierał się na danych, które w praktyce nie byłyby dostępne podczas rzeczywistego działania systemu predykcyjnego – problem znany w środowisku data science jako wyciek danych (target leakage).
Jak zauważyła Kate Jordan, data scientist w Octagram Analytics, specjaliści ds. danych często są szkoleni, by myśleć w kategoriach zestawu danych, który mają przed sobą, oraz ewentualnych dodatkowych informacji, które mogą być dostępne i istotne dla analizy. Skupiając się na samym zestawie danych, często pomijają kontekst operacyjny systemu, w którym model zostanie wykorzystany. Jordan napotkała podobne przypadki, gdzie specjaliści analizowali zestawy danych zawierające wszystkie zmienne, nie zdając sobie sprawy, że niektóre z nich nie były faktycznie rejestrowane w systemie w czasie rzeczywistym, w momencie gdy model miał analizować dane i na ich podstawie podejmować decyzje. Przestrzegła przed przekazywaniem zespołom ds. danych „sterylnych” zestawów danych, zachęcając do zadawania pytań: „Jaki jest proces?” oraz „Jak działa system i jaki jest przepływ danych?”.
Jedną z powszechnie stosowanych praktyk branżowych, która pomaga zespołom data science zrozumieć procesy biznesowe i znaleźć odpowiedzi na kluczowe pytania, jest obserwacja całego procesu biznesowego. Uważamy, że niezależnie od lokalizacji zespołu analitycznego w strukturze firmy data scientist zajmujący się danym problemem powinien tymczasowo zostać przypisany do odpowiedniego działu, a także poświęcić znaczną ilość czasu na obserwację codziennej pracy, poznanie wykorzystywanych narzędzi oraz identyfikację obszarów, w których występują nieefektywności. Taka bezpośrednia obserwacja procesu biznesowego oraz praca w otoczeniu użytkowników końcowych to nie tylko skuteczny sposób na zrozumienie problemu, lecz także solidna baza do przyszłego wdrożenia rozwiązania. Ważnym elementem tego podejścia jest również stworzenie diagramu, który krok po kroku przedstawia cały proces, umożliwiając lepsze zrozumienie jego przebiegu i wzajemnych zależności.
Liderzy biznesowi powinni doceniać i promować te działania, które wspierają głębokie zrozumienie kontekstu biznesowego. Zamiast przekazywać scentralizowanym zespołom ds. danych „sterylny”, pozbawiony kontekstu zestaw informacji do analizy, należy umożliwić im pełny wgląd w procesy biznesowe i systemy operacyjne. Dzięki temu analizy będą nie tylko dokładne, ale także użyteczne.
Przeczytaj artykuł, by dowiedzieć się, kim są decydenci i jakie kroki podejmują oraz jakie mają motywacje?
