Wizualizacja jest jedną z dróg pozwalających na efektywne wykorzystanie danych w procesie podejmowania decyzji. Jednocześnie, realizując proces transformacji cyfrowej, przedsiębiorstwa poszukują rozwiązań, które podniosą efektywność pracy (np. działu finansowego) poprzez wdrażanie zautomatyzowanych rozwiązań. Narzędzia business intelligence, w zamierzeniu mają pomóc w procesie analitycznym, ograniczając manualną pracę związaną z zestawianiem danych z różnych źródeł. Nadto, ich zadaniem jest przedstawienie tych danych w atrakcyjniej wizualnie formie.
Wdrożenia narzędzi tego typu należą w mojej ocenie do trudniejszych. Dzieje się tak dlatego, że są z nimi wiązane zwykle duże (jeśli nie rozbudowane) oczekiwania. Stety/ niestety, szybko rozwiewa je rzeczywistość. W dalszej części tego postu chciałbym zastanowić się, co może być przyczyną takiego stanu rzeczy.
Problem 1: raporty mają charakter techniczny i są nadmiernie skomplikowane.
Raporty nie ułatwiają analizy, bo de facto zawierają wszystkie możliwe do użycia dane, wymiary i ich przecięcia. Nawigacja po takiej "wizualizacji" jest skomplikowana, zwłaszcza gdy poszczególne elementy nie są zmapowane do terminologii stosowanej przez biznes. Zamiast tego korzysta się z opisów zawartych wprost w bazie danych. Poszczególne zapytania procesują się niemiłosiernie długo. W efekcie, z takich rozwiązań może korzystać w najlepszym razie analityk danych, o ile nie wyłącznie IT.
Możliwe rozwiązania:
Wprowadzenie hierarchizacji danych: tam gdzie tylko to możliwe, dane powinny być prezentowane w formie hierarchii, nie osobnych wymiarów. Ograniczy to liczbę wymiarów dostępnych "na wejściu". Możliwe będzie przeprowadzenie wstępnej analizy bez konieczności długiego oczekiwania na wynik.
A jak już mówimy o wstępnej analizie, to preferowane powinny być rozwiązania typu self - service. Czyli takich, gdzie raporty są co do zasady generowane przez końcowych odbiorców albo tzw. "power użytkowników" (np. analityków FP&A). Oznacza to, że do stworzenia raportu nie jest wymagana specjalistyczna wiedza (np. znajomość języka programowania).
Można rozważyć wybór rozwiązania "popularnego" (np. Tableau, PowerBI). Dlaczego? Dla popularnych rozwiązań jest dostępna wiedza: podręczniki, filmy instruktażowe, blogi. Łatwiej jest nam wtedy znaleźć rozwiązanie problemu, który nas zatrzymał na jakimś etapie pracy z narzędziem. W innym przypadku będziemy często skazani na dostawcę rozwiązania, co wygeneruje koszt i będzie czasochłonne.
Należy przeprowadzać cykliczne badania raportów: kto i jak często z nich korzysta oraz w jaki sposób? Co przyciąga uwagę, a co nie? Narzędzie BI powinno umożliwiać minimum generowanie statystyk użycia. Można przeprowadzić też np. badania ankietowe, analizę tzw. heat mapy czy (o zgrozo!) porozmawiać z użytkownikami.
Problem 2: raporty i analizy nie są jakkolwiek powiązane z decyzjami i wynikami.
Nierzadko dashboardy czy raporty KPI stosowane w organizacji są tak naprawdę zbiorami wszystkich wskaźników, jakie jest w stanie mierzyć organizacja, albo wszystkich, jakie odbiorcy/ odbiorcom raportu przyszły do głowy w chwili zbioru wymagań. W efekcie, wdrożone narzędzie nie służy do niczego. Łatwo to będzie zaobserwować po malejącej z czasem liczbie wizyt w danym narzędziu.
Możliwe rozwiązania:
Dashboard czy raport musi prezentować informacje relewantne dla menedżera / menedżerów. Co jest relewantne? Przede wszystkim to, co pokazuje cel tego menedżera i poziom jego realizacji. Kropka.
Druga kwestia, to fakt, że każdy raport po publikacji nie może być pozostawiony sam sobie. Oznacza to konieczność regularnej weryfikacji poziomu jego wykorzystania, w szczególności przez osoby wskazane jako kluczowych użytkowników. Jeżeli okaże się, że osoby te nie korzystają z raportu/ dashboardu to trzeba niezwłocznie dowiedzieć się, co może być tego przyczyną. Można to zrobić w drodze spotkań, ankiet czy innej metody, działającej w danej organizacji. Alternatywna ścieżka to po prostu odebranie uprawnień do raportu lub jego wyłączenie, niemniej takich działań nie rekomenduję.
Narzędzia powinny być dostosowane do użytkownika. Najprostszy przykład - zarząd przedsiębiorstwa powinien otrzymywać informacje skondensowane, łatwo "ogarnialne" na wyświetlaczu komputera czy telefonu. Użytkownik "operacyjny" np. handlowiec, może otrzymać informację bardziej szczegółową, a najlepiej narzędzie umożliwiające tworzenie i szybkie modyfikowanie dowolnych kwerend. Krytyczne jest, aby poszczególne elementy wymiarów opisane były zgodnie ze znaną mu / jej nomenklaturą. Estetyka czy łatwość użycia mogą znaleźć się na nieco dalszym planie.
Kadencja raportów powinna być związana z kadencją biznesu i trybem podejmowania decyzji. Jeżeli nasz biznes może być zniekształcony przez wydarzenia/ trendy w trybie dziennym czy godzinowym, to dashboard czy raport powinien aktualizować się analogicznie (tylko z pewnym opóźnieniem). Z drugiej strony, czy jest sens codziennie aktualizować raport prezentujący dane księgowe, które rozpoznawane są z kadencją miesięczną?
Raporty powinny być zrozumiałe. Warto zadbać o odpowiednią dokumentację dla poszczególnych miar. Można też rozważyć cykliczne spotkania/ warsztaty z użytkownikami raportów celem z jednej strony ich przeszkolenia, z drugiej - zebrania pomysłów i potrzeb na nowe raporty.
Raporty powinny mieć wielu użytkowników. Zwłaszcza jeżeli powołanie kolejnego dashboardu / raportu / źródła danych wiąże się z wysokim kosztem krańcowym. Nie powinno się robić takich rozwiązań dla kilku osób, nawet jeżeli te osoby to prezes i zarząd. Oczywiście, trudno jest takim interesariuszom czasem odmówić. W praktyce może się okazać, że przygotowanie danego raportu nie jest związane z dużym krańcowym nakładem. Wtedy nie jest to problem. W przeciwnej sytuacji warto przynajmniej uświadomić zlecającego jakie są za i przeciw.
Problem 3: w przedsiębiorstwie funkcjonuje wiele różnych rozwiązań BI.
Sęk w tym, że rzadko udaje się, aby dane rozwiązanie idealnie odpowiadało na potrzeby konkretnego użytkownika. Power pivot jest prosty w użyciu, ale możliwości kreowania wizualizacji przy jego pomocy są ograniczone. Power BI jest znakomity, bardzo łatwa jest dystrybucja raportów, w tym raportów mobilnych, zawiera potężny kombajn wstępnej obróbki danych. Ale trudno się z niego raportuje, a odpowiedniki niektórych wizualizacji z Excela wyglądają słabo. Tableau ma specyficzny interface oraz sposób działania z perspektywy użytkownika rozwiązań Microsoftu. Dodatkowo niektóre funkcje (jak np. formatowania warunkowe) są pracochłonne w przygotowaniu (przynajmniej gdy robi się to poraz pierwszy).
Może się to wszystko skończyć sytuacją, gdzie w przedsiębiorstwie funkcjonuje wiele rozwiązań BI, adresujących różne potrzeby. Abstrahując od kwestii czysto operacyjnych, jak koszty, takie rozwiązanie jest po prostu nieefektywne i zamiast wspierać, komplikuje podejmowanie decyzji (np. poszczególne narzędzia nie "komunikują się" ze sobą).
Możliwe rozwiązania:
Scentralizowanie wdrożeń i skuteczne zarządzanie architekturą systemów. Jest to przede wszystkim zadanie dla Działu IT, ale i FP&A. Bałagan w systemach jest czymś, co należy zwalczać, a nie potęgować. Business partner IT z ramienia FP&A może np. wnieść wiedzę i znajomość systemów wspierających prace swojego działu. Jest w stanie też wyłapać sytuacje, gdzie różne narzędzia adresują podobne jeśli nie te same problemy, komunikując się z biznesem.
Nigdy (ale to nigdy) nie zaczynamy wdrożeń od narzędzia. Czyli takich wdrożeń, gdzie przynoszone jest wybrane rozwiązanie, które na siłę staramy się wdrożyć (i znaleźć dla niego zastosowanie). Zamiast tego, dążymy do sytuacji gdy zawsze zaczynamy od potrzeby jaką jakieś narzędzie ma zaadresować. Liczba wdrożeń "od narzędzia" jest miarą skuteczności sprzedawców rozwiązań BI (żart). Ważne jest przy tym, aby partner z którym wdrożenie będziemy realizować był gotów na większe inwestycje w nas (czasu, zasobów) celem zbudowania długoterminowej współpracy. Szukajmy rozwiązań adresujących nasze potrzeby w możliwie największym stopniu. A jeśli takiego nie ma, to "przetestujmy" w tym zakresie potencjalnego partnera, który nie powinien mieć problemu z rekomendacją narzędzi czy rozwiązań, które w połączeniu z jego narzędziem w sposób kompletny odpowiedzą na nasze RFP.
Reasumując, jest wiele rzeczy, które mogą pójść nie tak z wdrożeniami narzędzi business intelligence. Niemniej warto w nie inwestować. Należy taką inwestycję traktować nie jak instalację kolejnego programu z wykresami, a wydarzenie o krytycznym znaczeniu z perspektywy zarządzania przedsiębiorstwem. Postawienie takiego priorytetu, w mojej ocenie, zdeterminuje w znacznym stopniu sukces ewentualnego wdrożenia.
Podobne posty: