Dlaczego Excel i VBA są słabe?

Excel nie jest profesjonalnym narzędziem do analizy danych. Kropka.

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. Firmy opierające swoją analizę na Excelu są po prostu słabymi firmami, które na danych się nie znają, i nawet jeżeli 90% z nich robi to źle, to dalej jest to źle.

Z czego wynika główny problem Excela? Głównie z jego jednej, ale niesamowicie istotnej cechy.

Powtarzalność

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. 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ć. Excel jest dobrym narzędziem do obróbki danych oraz prostego raportowania 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 analityków danych. To także nie znaczy, że nie powinien być przez te osoby w ogóle używany – 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
  • bezpieczniejsze – możemy być pewni, że nie dostanie się do osób poza naszą firmą (chyba, że podzielimy się nimi to intencjonalnie).

Co dalej?

Samo przeniesienie analizy do kodu jest warunkiem koniecznym, ale niewystarczającym, żeby być dobrym analitykiem. Mam wrażenie, że przeskok między jakimś analitykiem, a dobrym analitykiem jest większym przeskokiem niż między nie-analitykiem, a jakimś analitykiem. Zachęcam do śledzenia kolejnych postów, które będą poruszać te tematy, oraz mediów społecznościowych, aby nie przegapić tych postów:

2 thoughts on “Dlaczego Excel i VBA są słabe?”

  1. 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!

  2. Pingback: Czysty kod SQL – Crappy Data

Comments are closed.