Większość firm utożsamia dziś przeprowadzenie analizy z wpisaniem odpowiednich formuł do arkuszy kalkulacyjnych. Zwróćmy jednak uwagę, że w ciągu trzech dekad od chwili stworzenia i udostępnienia arkusza kalkulacyjnego w świecie biznesu wystąpiły potężne ruchy „tektoniczne”, które nieodwracalnie zmieniły warunki funkcjonowania firm na rynku. Współczesne przedsiębiorstwa muszą myśleć w kategoriach milionów indywidualnych klientów, a nie garstki segmentów, i żeby uniknąć kłopotliwego przekształcania procesów od podstaw w przypadku pojawienia się problemów, potrzebują rozwiązań wielokrotnego użytku. Co więcej, każde z nich chce korzystać z najnowszych odkryć technologicznych – używać uczenia maszynowego i sztucznej inteligencji, a nie tylko stosować regresję do każdego problemu analitycznego, z którym ma do czynienia. Krótko mówiąc, firmy powinny szkolić pracowników w pisaniu kodu, a nie formuł, ponieważ wykonywanie zadań będzie w przyszłości wymagało nie tylko myślenia analitycznego, ale też algorytmicznego.
Zmiana podejścia i sposobu myślenia ma ogromne znaczenie. Być może dla większości firm kodowanie jest kompetencją głęboko ukrytą w zakamarkach działu IT albo wyłączną domeną doborowej grupy analityków danych (data scientists). To błąd, ponieważ organizacje, w których kod stanie się naturalnym, powszechnie stosowanym językiem analizy we wszystkich jednostkach biznesowych, mają szanse rozwijać się i wprowadzać innowacje szybciej niż konkurenci.
Praktyka, w której kod zajmuje kluczową pozycję, jest korzystna dla firmy z trzech powodów.
Po pierwsze, powszechna umiejętność kodowania umożliwia odseparowanie danych od analizy danych, co pozwala poszczególnym zespołom pracować efektywniej niezależnie od efektywności pozostałych. Gdy dane są wyraźnie oddzielone od analizy, każdy zespół może skupić całą uwagę na „swoim” elemencie, a tym samym przyspieszyć postępy prac nad konkretnym zagadnieniem.
Po drugie, kod można bez problemu podzielić na moduły, dzielić się nim z innymi i używać go wielokrotnie – na tej zasadzie opiera się przecież koncepcja otwartego kodu źródłowego i otwartego oprogramowania. Architekci programów komputerowych poświęcili lata na stworzenie narzędzi ułatwiających śledzenie, modyfikowanie i współdzielenie efektów swojej pracy. Stosując się do podstawowych reguł programowania, takich jak kontrola wersji, zespoły mają szansę osiągnąć większą wydajność i efektywniej współpracować ze sobą, ponieważ aktualizacje plików kodu można śledzić przez całą długość ich życia i z łatwością cofnąć wprowadzone zmiany.
Po trzecie, kod jest lepszy od formuł w arkuszu zarówno w przypadku prostej, jak i skomplikowanej analizy. Przełomowe odkrycia w dziedzinie uczenia się maszyn czy technologie sztucznej inteligencji są implementowane w postaci kodu, toteż klonując kod używany przez badaczy, każdy może mieć dostęp do najnowocześniejszych aktualnie technik analizy – szybko i nieodpłatnie.
Co zatem muszą zrobić menedżerowie, żeby przestawić wszystkich pracowników firmy z wpisywania poleceń do arkusza na pisanie kodu? Jak wynika z badań mojego zespołu, firmy będące liderami w tej dziedzinie zrobiły to metodą trzech następujących kroków.
**Burzymy wieżę Babel.**Jak wiadomo, warunkiem koniecznym dobrej współpracy jest dobra komunikacja, bariery językowe utrudniają bowiem albo wręcz uniemożliwiają dzielenie się pomysłami czy wymianę poglądów. Dotyczy to nie tylko pisemnej korespondencji czy bezpośrednich rozmów, ale też w równym stopniu kodowania. Tyle że przetworzenie w umyśle koncepcji zapisanej w kilkunastu językach programowania wymaga fachowej wiedzy, a poza tym jest niezwykle skomplikowane w sensie poznawczym.
Jak rozwiązać ten problem?
Wybrać język programowania na potrzeby analizy (najlepiej jeden, a najwyżej dwa) i przyjąć go jako standard w całej firmie; będzie to język, którym „mówi” każdy pracownik. Rzecz jasna, wybrany standard nie będzie idealnie dopasowany do każdej sytuacji, poza tym ludzie mogą mieć uzasadnione wątpliwości co do wybranego standardu i nie zaakceptują wyboru, dlatego zespoły powinny przygotować się na znane skądinąd protesty i opór wobec decyzji kierownictwa. Aby uspokoić przeciwników i nie przeciągać sporu w nieskończoność, kierownictwo powinno zaproponować przegląd standardów co dwa lata.
Dobrym wstępem do pierwszego kroku jest przyjrzenie się pracy ekspertów i wyciągnięcie stosownych wniosków. Ekspertami będą w tym przypadku osoby z istotnych dla firmy działów operujących głównie liczbami, darzone szacunkiem przez swoich współpracowników i przełożonych. Mogą się na przykład wywodzić z działu finansów czy marketingu, a także z kierownictwa jakiejkolwiek grupy produktowej, której produkt wymaga analizy. Właśnie takie podejście zastosowała jedna z globalnych instytucji usług finansowych: jak się okazało, najlepsi w firmie analitycy danych posługiwali się językiem Python, co więcej, nawet ich początkujący koledzy używali kodu Pythona przez aplikację Jupyter Notebook, a jest to narzędzie stosowane w środowisku naukowym do przeprowadzania i dokumentowania za pomocą kodu odtwarzalnych badań.
W momencie wyboru narzędzi i metod pracownicy, którzy latami starali się doskonalić swoje praktyczne umiejętności matematyczne, będą z pewnością zawzięcie bronili swoich racji i przypuszczalnie poczują się usatysfakcjonowani, gdy preferowane przez nich standardy zostaną formalnie przyjęte w całej firmie.
Te osoby staną się w organizacji agentami zmiany, liderami i nauczycielami, dlatego eksponowanie ich dokonań i wzmacnianie siły oddziaływania jest nie tylko dobrą praktyką biznesową, ale też korzystną dla firmy strategią zarządzania talentami.
**Tworzymy repozytoria kodu współdzielonego (składające się z modułów oprogramowania dla wielu procesów) do wspólnego wewnętrznego użytku.**Gdy pracownicy nauczą się formułować swoje pomysły we wspólnym języku, firma powinna udać się po wskazówki do społeczności otwartego oprogramowania, ponieważ tam znajdzie wskazówki w kwestii tworzenia własnych repozytoriów kodów współdzielonych oraz baz wiedzy. Dzięki repozytoriom pracownicy będą mogli szybko i łatwo dzielić się opracowanymi przez siebie kodami, oszczędzając innym odkrywania Ameryki na nowo.
Tak jak w przypadku każdego scentralizowanego systemu, organizacja powinna zadbać o należyte zabezpieczenie i autoryzację dostępu do repozytoriów, a także wprowadzić zróżnicowane poziomy uprawnień, stosownie do wewnętrznych standardów poufności lub reguł ochrony własności intelektualnej. Warto nad tym popracować, ponieważ ogromna przestrzeń (dokładnie mówiąc, cyberprzestrzeń), w której pomysły mogą się swobodnie rozwijać dzięki zaangażowaniu wielu osób, jest potężnym motorem postępu i źródłem wielu korzyści dla firmy.
Mając do dyspozycji repozytoria kodów, rozmaite grupy pracowników organizacji mogą używać tych samych plików kodu do rozwiązywania podobnych problemów. Tak się może zdarzyć na przykład wtedy, gdy zespół marketingu w banku potrzebuje informacji o klientach zainteresowanych refinansowaniem kredytu hipotecznego, aby móc im zaoferować pewne produkty, a jednocześnie zespół finansowy potrzebuje danych o wysokości refinansowania, ponieważ właśnie pracuje nad budżetem i fakturowaniem. Istota problemu jest identyczna w obu przypadkach, pytanie bowiem brzmi: ilu klientów byłoby zainteresowanych refinansowaniem oraz którzy by się na nie zdecydowali?. Dlaczego zatem nie uzyskać odpowiedzi za pomocą tego samego kodu?
Dobrym sposobem dającym szybki efekt jest tworzenie repozytorium kodu na potrzeby wybranego projektu i zaproszenie do współpracy nad jego rozwojem szerszej grupy. Dzięki platformom otwartych kodów online, takim jak GitHub i Bitbucket, zadanie jest stosunkowo łatwe. Najlepiej zacząć od projektów niekontrowersyjnych i umożliwiających szerokie zastosowanie, na przykład od prognozowania szeregów czasowych związanych z analizą, od segmentacji klientów czy od obliczania elastyczności cen.
Niektóre firmy idą dalej: upubliczniają swoje wewnętrzne repozytoria. Liderzy technologii informacyjnych, tacy jak Google i Microsoft, robią to już od jakiegoś czasu, ale obecnie korzyści z tego rodzaju strategii zaczęły dostrzegać również firmy z innych sektorów. Na przykład pewien operator telekomunikacyjny wprowadził swoje repozytoria kodów dzielonych na platformy otwartego oprogramowania, dzięki czemu może nie tylko korzystać z pomocy współpracowników zewnętrznych, ale też wyznaczać standardy dla całego sektora telekomów.
Wprowadzamy kod do codziennej praktyki firmy. Organizacje, które chcą osiągnąć możliwie największą korzyść z nowoczesnych narzędzi analizy, stoją przed ostatnim i najtrudniejszym zadaniem: muszą z modelowania opartego na kodzie uczynić regułę, a nie wyjątek. Pisanie kodu musi stać się codzienną praktyką firmy, tak zwyczajną i odruchową jak dołączanie arkusza kalkulacyjnego do e‑maila. Jest to nie lada wyzwanie, wymaga bowiem zmiany nie tylko sposobu myślenia, lecz także przyzwyczajeń. Na szczęście można tę zmianę przyspieszyć za pomocą praktycznych strategii.
Pierwsza polega na komunikowaniu klarownych i konkretnych oczekiwań od pracowników na każdym szczeblu i firmy, które rzeczywiście uważają analizę za strategiczny priorytet, robią to sumiennie, nie szczędząc wysiłków. W komunikatach do wszystkich pracowników członkowie kierownictwa nieustannie podkreślają wagę dążenia do doskonałości w obszarze analizy, konieczność zmiany podejścia oraz swoje przekonanie o słuszności wyboru tej drogi; podczas spotkań z całą załogą jednoznacznie łączą nowy sposób myślenia z ogólną strategią organizacji, a o planowanej zmianie informują często zarówno akcjonariuszy firmy, jak i wszystkich graczy rynkowych, akcentując swoje dążenia wszędzie, gdzie to możliwe, od corocznych sprawozdań dla Komisji Papierów Wartościowych i Giełd po spotkania z inwestorami.
Druga strategia przeprowadzenia owej zmiany szybko i płynnie zakłada ochronę pracowników w okresie przejściowym oraz zapewnienie im czasu na szkolenie. Przynosi ona dobre efekty, ponieważ zdobycie technicznych umiejętności na odpowiednim poziomie wymaga skupienia uwagi, informacji zwrotnej, czasu i nabycia wprawy przez powtarzanie czynności. Obecnie zarówno firmy, jak i pojedyncze osoby mają do wyboru całą gamę możliwości, począwszy od obozów szkoleniowych do masowych otwartych kursów online (Massive Open Online Course – MOOC), a skończywszy na dostępnych w sieci instrukcjach dostosowanych do indywidualnych potrzeb. W opinii mojego zespołu każda z tych form szkolenia jest dobra, pod warunkiem że uczestnicy szkolenia mogą każdorazowo poświęcić na naukę określony blok czasowy, a nie biegać nieustannie między biurkiem a salą zajęć. Dekoncentracja z powodu tej bieganiny ma ogromny negatywny wpływ na przyswajanie nowej wiedzy. Przy pełnej koncentracji zdobycie umiejętności kompetentnego programisty nie jest zadaniem przekraczającym ludzkie możliwości, dlatego menedżerowie nie powinni spisywać na straty żadnego pracownika.
Trzecia strategia, najważniejsza ze względu na jej oddziaływanie, polega na stworzeniu struktury realnego wsparcia. Pracownicy muszą wiedzieć, do kogo zwrócić się w potrzebie, ponieważ merytoryczna pomoc udzielona w porę pozwala w znacznym stopniu opanować stres i lęk przed uczeniem się nowego. Trudno jednak oczekiwać postępów w doskonaleniu nowych umiejętności, gdy prośbami o pomoc będzie nieustannie zasypywana ta sama garstka orłów w sztuce programowania. Przytłoczeni pytaniami bardzo szybko padną ze zmęczenia. Na szczęście pomocy można szukać także gdzie indziej – u osób, które postawiły już pierwsze kroki na tej drodze i mogą być mentorami tych, którzy jeszcze na nią nie weszli. Menedżerowie z kolei powinni nie tylko informować swoje zespoły o konieczności przestawiania się na nowy typ zadań, lecz także przygotować się do nowej roli – ratownika, którego zespoły w pierwszej kolejności wezwą na pomoc w razie potrzeby. Wiadomo, że nic nie motywuje do nauki czegoś nowego silniej niż świadomość, że za chwilę trzeba będzie tego uczyć innych.
Jedno jest pewne, nie taki diabeł straszny, jak go malują. Jeśli będziemy uważnie czytać drogowskazy, a jest ich wiele, nie zbłądzimy w wędrówce do nowego świata. Odpowiedzi na nasze pytania – czy to znalezione w wyszukiwarce, czy w materiałach ze szkoleń, czy u kolegów nauczycieli – są prawie zawsze proste i uniwersalne. Niektóre zawierają odsyłacze do bogatych repozytoriów otwartych kodów źródłowych, gdzie znajdziemy rozwiązania każdego wariantu problemu. Ogólnie rzecz biorąc, nie można tego samego powiedzieć o arkuszach kalkulacyjnych, gdzie z przemieszanych ze sobą danych i analiz trudno wyodrębnić rozwiązanie nękającego nas problemu, a tym bardziej takie, które da się wielokrotnie stosować i doskonalić. A już z pewnością napotkamy problemy, gdy owo rozwiązanie wymaga więcej niż jednej czynności.
O autorze
David Waller jest wspólnikiem w firmie Oliver Wyman Labs, gdzie pełni funkcję szefa działu nauki o danych i analiz. Prowadzi projekty wykorzystujące zaawansowane metody uczenia statystycznego i uczenia maszynowego do rozwiązywania problemów współczesnego biznesu.
