Arkusze kalkulacyjne Excel nie są profesjonalnym narzędziem do analizy danych.
Przemycając tę tezę w mojej aktywności spotykam się czasem z chęcią jej obalenia. Słyszę argumenty typu:
- przecież firmy na Excelu stoją
- Excel jest prosty, przez co dostępny, a programowanie jest trudne, przez co dla wielu niedostępne
- wszyscy chcą data science / machine learning / artificial intelligence, a prawda jest taka, że większość firm potrzebuje dobrych analityków potrafiących porządnie obsłużyć Excela.
Wbrew pozorom, zgadzam się z większością tych argumentów i nie zamierzam się z nimi kłócić. Tylko, że żaden ten argument nie obala mojej początkowej tezy, twierdzącej, że Excel nie jest dobrym programem do analizy. Bardziej są to przesłanki w stylu: wszyscy robią to źle, więc my też będziemy. Jeżeli 90% firm robi coś źle, to fakt, że są w większości nie zmienia tego, że nadal robią to źle.
Czy excel to zło wcielone? Oczywiście, że nie. Uważam, że jest dobrym narzędziem na początek, zarówno jeżeli mówimy o osobie zaczynającej przygodę z analityką danych (wspominam o tym w poście Jak zostać DA), czy o młodej firmie, która ma inne rzeczy na głowie niż profesjonalizacja narzędzi IT i Excel jej jak najbardziej wystarczy do prostego raportowania. W dodatku moje zarzuty dotyczą się Excela w formie najczęściej używanej przez firmy, czyli w postaci arkuszy kalkulacyjnych, a nie dodatków typu PowerQuery itd.
Powtarzalność
Z czego wynika główny problem Excela? Głównie z jego jednej, ale niesamowicie istotnej cechy.
PEP8, czyli zbiór wytycznych, jak pisać czysty kod w Pythonie ma takie piękne stwierdzenie na początku:
code is read much more often than it is written
Z analizą danych jest tak samo. Każdy, kto pracuje jako analityk wie, że rzadko tworzy się analizę od samego początku. Dużo częściej musimy pracować nad czymś, co już istnieje – zmienić coś, dodać, usunąć, zidentyfikować błąd lub po prostu zrozumieć, co zostało zrobione.
Analiza robiona w programie, który polega na klikaniu myszką w różne przyciski jest nie do odtworzenia. Nie dotyczy się to oczywiście tylko Excela, ale wszystkich programów działających na graficznych interfejsach. I o ile jesteśmy w stanie zidentyfikować część kroków lub oczywiste pomyłki np. błąd w formule czy źle użytą funkcję, to nigdy się nie dowiemy, że ktoś coś źle przekopiował, przez przypadek coś nacisnął lub usunął jakiś wiersz. Nigdy się też nie dowiemy, skąd się wzięły dane w arkuszu, czy są poprawne i kompletne. Przez brak możliwości odtworzenia analizy od początku do końca nie jesteśmy w stanie ani potwierdzić jej poprawności, ani samodzielnie jej odtworzyć. Jedyne co jesteśmy w stanie zrobić, to wykonać ją w całości od nowa (jeżeli wiemy, skąd wziąć dane), ale jeżeli znowu popełnimy jakiś błąd – to wracamy do punktu wyjścia.
Co jest zatem alternatywą?
Przeniesienie analizy do kodu.
Mając wszystkie kroki określone ściśle w kodzie (w jakimś języku programowania) możemy kroku po kroku odtworzyć dane na których była zrobiona analiza oraz wszystkie etapy ich przetwarzania. Jeżeli zrobiliśmy jakiś błąd, czyli albo zaciągnęliśmy złe dane, albo źle je przekształciliśmy, możemy to zidentyfikować i to naprawić. Obojętne jest to, czy my wcześniej pracowaliśmy na tej analizie, czy ktoś inny – możemy samodzielnie ją zmienić lub sprawdzić jej poprawność i założenia – czyli wszystko to, co jest wymagane od pracy analityka, a praktycznie niemożliwe do wykonania w Excelu.
W tym momencie dochodzimy do argumentu, że przecież programowanie jest trudne, przez co dostępne tylko dla wąskiej grupy analityków. Po co marnować tygodnie czasu na naukę, żeby zrobić to, co zrobiliśmy w Excelu w pół godziny?
Po pierwsze, nie musicie od razu sięgać po mega skomplikowany język programowania – wystarczy, że przeniesiecie analizę do języka SQL. Tłumaczyłam to już w innych artykułach (jak się nauczyć SQL i jak zostać analitykiem danych) – SQL naprawdę prostym językiem do nauki, przez co dostępnym do nauczenia przez większość osób, które ogarniają Excela.
Prawda jest też taka, że wysiłek włożony w naukę programowania vs korzyści z niej płynące absolutnie nie mają liniowej zależności. Na samym początku musicie włożyć ogrom energii, żeby odtworzyć proste funkcje w Excelu, jednak z czasem będziecie potrzebować do tego coraz mniej czasu. Na końcu nie tylko wykonacie zadanie szybciej, ale też zrobicie rzeczy, których Excel na oczy nie widział. Więc argument, że Excel jest prostszy i szybszy ma rację bytu tylko wtedy, gdy nie potrafimy programować albo dopiero zaczynamy się uczyć.
Jest jeszcze kolejna prawda, tym razem brutalna. Sorry, że to piszę, ale jeżeli ktoś nie potrafi nauczyć się SQL, to nie powinien zajmować się analizą danych. Sam syntaks SQLowy jest prosty w porównaniu do zrozumienia zagrożeń i błędów wynikających ze złej analizy. Analiza danych może się wydawać prosta, bo ma niski próg wejścia – no bo kto nie potrafi zbudować prostego wykresu w Excelu. Jednak różnica między jakąś analizą, a dobrą jest kolosalna i o ile zrobienie tej pierwszej jest trywialne, to ta druga już jest trudną sztuką do opanowania (tu znajdziesz artykuł jak analizować dane). I w całej tej sztuce SQL stanowi jeden z mniejszych problemów.
Off topic: Podobnie sprawa wygląda z uczeniem maszynowym (ML) i nauką Pythona. Powstaje coraz więcej programów działających na zasadzie drag-and-drop, które umożliwiają nam zbudowanie modelu uczenia maszynowego bez znajomości programowania. Błagam, nie róbcie tego! Napisanie takiego kodu w pythonie to raptem kilka linijek, i nijak się to ma do zrozumienia całej koncepcji ML i miliona rzeczy, które mogą pójść nie tak. Jeżeli ktoś nie potrafi ogarnąć podstawowego Pythona, nie ogarnie machine learningu!
Czemu zatem nie VBA?
Powróćmy do Excela i omówienia jeszcze VBA. VBA jest językiem programowania służącym do zautomatyzowania obliczeń w Excelu. Jakby nie patrząc – jest to język programowania, więc powinien on rozwiązać problemy o których wcześniej wspominałam. Dlaczego więc znowu jestem na nie? Ponieważ dla mnie automatyzacja analizy w Excelu za pomocą VBA jest jak cytat z klasyka:
To, że jesteśmy w dupie to jasne. Problem w tym, że zaczynamy się w niej urządzać
Czyli bierzemy złe narzędzie do analizy danych, Excela, i próbujemy to naprawić przykrywając je VBA. Nie prościej jednak zrobić krok w tył i zacząć porządnie od samego początku? Jeżeli już musimy włożyć wysiłek w naukę programowania, to po co ograniczać się do języka, który działa tylko na Excelu? Nie lepiej to zrobić na języku uniwersalnym, który po pierwsze jest prostszy, a po drugie umożliwi nam zrobienie wszystkiego tak jak chcemy, bez ograniczania się do ograniczeń tego programu?
Kiedy warto używać Excela
Żeby było jasne – nie twierdzę, że należy odinstalować Excela i nigdy w życiu już go nie włączać. Jak już wspomniałam na początku, będzie w pełni wystarczającym narzędziem dla młodych, rozwijających się firm, które potrzebują programu z małym progiem wejścia szybko dającym możliwość wykonania prostej analizy. W dodatku będzie dobrym narzędziem do obróbki danych dla osób, którzy nie zajmują się tym zawodowo, np. dla osoby pracującej w HR, która raz na jakiś czas ma zrobić prosty raport.
Excel nie jest po prostu profesjonalnym narzędziem dla tzw. data-driven companies, które bazują podejmowanie decyzji biznesowych na danych czy nawet automatyzują procesy za ich pomocą.
To także nie znaczy, że nie powinien być w ogóle używany przez specjalistów od danych w tych firmach – sama go używałam, gdy pracowałam jako analityk, ale nie było to moje główne narzędzie pracy. Tłumaczyłam to już w poście jak zostać analitykiem danych, że Excel przydawał mi się do zadań okołoanalizowych, np. do zrobienia prostych kalkulacji sprawdzających czy kod SQL zwraca to co powinien.
Google Sheet > Excel
Jeżeli już potrzebujecie arkuszów kalkulacyjnych, dużo bardziej niż Excel sprawdzają się arkusze z Google Sheet. Działają one praktycznie jak Excel, tylko są online, przechowywane na dysku Google. Do ich używania musicie mieć jednak konto firmowe Google, więc wiadomo, że nie są opcją dla każdego.
Dlaczego arkusze Google Sheet są lepsze:
- zapisują się automatycznie, przez co nigdy nie znajdziecie się w sytuacji, że zapomnieliście czegoś zapisać (lub nie zdążyliście, bo Excel się zawiesił)
- jeżeli coś zepsujemy, to możemy powrócić do poprzednich wersji
- bardzo łatwo możemy się nimi dzielić z innymi, a nawet określać jaki dostęp będą mieć te osoby (dostęp do edycji, dodawania komentarzy, czy tylko oglądania)
- możemy pracować wspólnie z innymi w tym samym czasie na 1 pliku
- są bezpieczniejsze – możemy być pewni, że nie dostanie się do osób poza naszą firmą (chyba, że podzielimy się nimi to intencjonalnie).
Podsumowanie
Podsumowując, uważam, że Excel nie jest profesjonalnym narzędziem do analizy danych, ponieważ opiera się na interfejsie graficznym, a nie na kodzie, zatem nie można dokładnie odtworzyć analizy przeprowadzonej za jego pomocą.
Hej, ja tylko dodam że dużo kroków wstępnej obróbki danych można zapisać w Power Query.
ale i tak excel ma swoje ograniczenia i na liczbę wierszy i ogólnie wydajnym narzędziem nie jest.
P. s. Fajny blog, same konkrety, pozdrawiam!
Pingback: Czysty kod SQL – Crappy Data
Bardzo fajny i rzeczowy blog, aż chce się czytać kolejny i kolejny post.
Pozdrawiam!
Bardzo konkretne i rzeczowe argumenty. Pomogły mi mentalnie po wczorajszej rozmowie rekrutacyjnej na stanowisko Data Scientista do dużego, m…ega banku.
Dodam ze od ponad 2,5 roku pracuje i poszerzam swoją wiedzę jako DS, właściwie nie używając excela tylko Pythona i bibliotek np. Pandas.
Na rozmowie poległam. Pierwszy raz w życiu czułam się jakby była „na innej ścieżce”.
Dla nich ważny był tylko excel i umiejetność klikania, przedstawiania, sortowania itd. Masakra.
Pytałam kilka razy czy są pewni ze to stanowisko Data Scientista i jakie mają plany z nim związane?
Robienie raportów w excelu dla klienta ubezpieczeniowego.
Poległam …
Pozdr