Jeśli prowadzisz szkołę tańca i interesujesz się tym, jak działają najmocniejsze organizmy na rynku, to Salsa Libre prawdopodobnie nie jest Ci obca. To jedna z tych szkół, którym przyglądają się i mniejsi, i więksi. Nie tylko ze względu na markę, ale też dlatego, że od lat bardzo świadomie buduje swoje zaplecze organizacyjne, operacyjne i technologiczne.

Właśnie dlatego ten projekt jest ciekawy. Nie dotyczy szkoły, która dopiero zaczyna porządkować chaos po pierwszych latach działania. Dotyczy dużej, dojrzałej, niesieciowej szkoły, która już wcześniej robiła wiele rzeczy dobrze, ale doszła do momentu, w którym dotychczasowy model pracy z danymi i raportami zaczął pokazywać swoje ograniczenia.

Nie chodziło tu tylko o wprowadzenia na siłę nowej technologii. Problem był bardziej przyziemny i dużo bardziej realny: szkoła rosła, danych przybywało, raportów i wyjątków też, a razem z nimi rosła ilość ręcznej pracy potrzebnej do tego, żeby w ogóle utrzymać sensowny obraz sytuacji.

Przez długi czas ten model dało się utrzymać. W przypadku szkoły tej skali oczywiste jest, że w grę wchodzi już system obsługi kursów, z którego regularnie pobiera się dane i raporty. Później te dane trafiały do arkuszy, z jednych zestawień powstawały kolejne, a część procesów wspierały dodatkowe skrypty i robocze narzędzia.

To nie było absurdalne ani „źle zrobione”. Przeciwnie: na wcześniejszym etapie rozwoju szkoły był to pragmatyczny model działania, a tam, gdzie pojawiały się skrypty automatyzujące część pracy, wręcz całkiem nowoczesny jak na realia wielu szkół.

Z czasem jednak taki układ zaczął coraz wyraźniej pokazywać swój koszt. Rosła ręczna praca. Rosło ryzyko błędów. Coraz trudniej było rozwijać kolejne procesy bez dokładania następnych obejść, rozproszonych pomocniczych arkuszy i dodatkowej wiedzy trzymanej w głowie jednej osoby. W pewnym momencie przestało już chodzić o wygodę.Zaczęło chodzić o to, czy szkoła ma wystarczająco stabilne zaplecze danych i operacji, żeby dalej rosnąć w uporządkowany sposób.

Najtrudniejsze było to, że tej zmiany nie dało się zrobić przez prostą rewolucję. Bieżąca praca szkoły musiała toczyć się dalej. Payroll nie mógł się zatrzymać. Raporty nie mogły nagle zniknąć. Zespół nie mógł z dnia na dzień dostać zupełnie nowego środowiska, które wymagałoby zmiany wszystkich nawyków. Trzeba więc było zbudować dojrzalszy system pod spodem, ale zrobić to tak, żeby z perspektywy codziennej pracy szkoła nie zapłaciła za tę zmianę zbyt wysokiej ceny.

To właśnie było osią tego projektu: przejść z modelu opartego głównie na ręcznie sklejanych raportach i operacyjnych arkuszach do bardziej uporządkowanego systemu danych, automatyzacji i rozliczeń, ale bez zatrzymywania szkoły po drodze.

Żeby dobrze zrozumieć sens tej zmiany, trzeba zacząć od jednej rzeczy: problemem nie było samo istnienie arkuszy. Google Sheets przez długi czas bardzo dobrze spełniały swoją rolę. Pozwalały szybko budować zestawienia, rozwijać robocze procesy i reagować na bieżące potrzeby szkoły bez wielkich inwestycji i bez czekania na „idealny system”.

To właśnie dlatego wiele szkół tak długo na nich pracuje. Arkusze są elastyczne, tanie i dają dużą sprawczość. W połączeniu ze skryptami i operacyjną pomysłowością potrafią naprawdę długo nieść organizację.

Problem zaczyna się wtedy, gdy szkoła przestaje być prostym organizmem. Kiedy rośnie liczba kursantów, grup, raportów, wyjątków i powiązań między danymi, arkuszowy model nie znika od razu, ale zaczyna coraz częściej wymagać ręcznego podtrzymywania. To właśnie wydarzyło się tutaj.

Dane sprzedażowe i operacyjne trzeba było regularnie pobierać z systemu, doklejać do istniejących zestawień, pilnować spójności, a potem dalej przetwarzać w kolejnych arkuszach i raportach. Z jednych tabel powstawały następne. Część procesów payrollowych i komunikacyjnych była już wspierana przez własne skrypty automatyzujące pracę wokół arkuszy. To nadal działało, ale coraz bardziej było widać, że całość trzyma się nie tylko na narzędziach, ale też na pamięci, czujności i ręcznej pracy konkretnej osoby.

W takim modelu koszt nie pojawia się od razu jako spektakularna awaria. On narasta po cichu. Coraz więcej czasu schodzi na przygotowanie danych. Coraz trudniej odtworzyć, skąd dokładnie wzięła się dana liczba. Coraz łatwiej o drobne rozjazdy między zestawieniami. Coraz trudniej też rozwijać nowe procesy bez dokładania kolejnych obejść.

Dochodzi do tego jeszcze jeden problem, który przez długi czas łatwo lekceważyć: arkusze wyglądają tak, jakby mogły przyjąć wszystko. Przy małych i średnich zbiorach danych naprawdę łatwo odnieść wrażenie, że ich pojemność i wydajność są praktycznie wystarczające na zawsze. Dopiero po kilku latach pracy na rosnącej bazie danych okazuje się, że ten komfort ma granice. Arkusze zaczynają się wieszać, cięższe raporty i przeliczenia przestają dawać pełne poczucie bezpieczeństwa, a w tle pojawia się bardzo nieprzyjemne pytanie: czy to na pewno policzyło się poprawnie?

Jest też drugi koszt, bardziej codzienny i mniej widowiskowy, ale bardzo realny. Arkusz przyjmie wiele, ale nie wszystko da się w nim sensownie zabezpieczyć. Z czasem wokół takich narzędzi zaczyna powstawać cały zestaw cichych instrukcji: nie usuwaj tego wiersza, nie wycinaj tej komórki, nie zmieniaj tego układu, bo rozpadnie się formuła. To jest męczące dla właściciela procesu, męczące dla użytkowników i obciążające dla wszystkich, którzy później patrzą na liczby menedżersko i chcą po prostu wiedzieć, czy mogą im ufać.

To było szczególnie ważne w obszarach, które dla szkoły mają realny ciężar operacyjny i organizacyjny. Raporty nie służyły tu tylko do oglądania liczb. Były elementem codziennej pracy, podstawą do oceny sytuacji szkoły i wsparciem dla rozliczeń z instruktorami oraz współpracownikami. Im bardziej rosła skala, tym mocniej było widać, że taki model zaczyna być czasochłonny, trudny do skalowania i mało wygodny, jeśli ktoś chce mieć aktualny obraz szkoły częściej niż od czasu do czasu.

Właśnie w tym momencie arkusze przestały być po prostu wygodnym narzędziem. Zaczęły być ograniczeniem dla dalszego porządkowania operacji i danych. I to był realny punkt wyjścia tego projektu.

W wielu podobnych historiach najłatwiej brzmi rada: skoro dotychczasowy model przestaje działać, to trzeba go po prostu wymienić. W praktyce duże szkoły rzadko mogą sobie pozwolić na takie czyste cięcie.

Tutaj to ograniczenie było bardzo wyraźne od początku. Bieżąca praca szkoły musiała toczyć się dalej. Rozliczenia nie mogły się zatrzymać. Raporty nie mogły zniknąć na kilka tygodni tylko dlatego, że pod spodem powstaje nowa architektura danych. Zespół nie mógł dostać z dnia na dzień całkiem nowego środowiska, które wymagałoby zmiany wszystkich przyzwyczajeń i codziennej logiki działania.

To był nie tylko problem techniczny, ale też organizacyjny i psychologiczny. Każda większa zmiana ma swój koszt. Jeśli nowy system wymaga od ludzi nauczenia się wszystkiego od początku, nawet najlepsza architektura pod spodem może przegrać z codzienną praktyką szkoły. W takim środowisku bardzo łatwo zbudować coś ambitnego technologicznie, ale trudnego do przyjęcia operacyjnie.

Dlatego celem nie było „zastąpić wszystko czymś nowym”. Celem było raczej przejąć cięższą pracę pod spodem, a jednocześnie oszczędzić zespołowi kosztu zbyt dużej zmiany na froncie. Nowe zaplecze danych miało uporządkować procesy, ale codzienna praca ludzi miała pozostać możliwie bliska temu, co już znali i rozumieli.

To bardzo ważna część tej historii, bo właśnie tutaj ten projekt przestaje być zwykłą migracją danych. Zaczyna być próbą zbudowania dojrzalszego systemu bez przerywania działania szkoły i bez wywracania ludziom pracy w imię samej technologicznej elegancji.

W praktyce oznaczało to podejście warstwowe. Zamiast robić jedną wielką zmianę, trzeba było uporządkować wejścia do systemu, przejąć cięższą logikę danych pod spodem i zostawić zespołowi możliwie bezpieczny sposób pracy na co dzień. Dopiero taki układ dawał szansę, żeby nowa architektura naprawdę została w organizacji na dłużej, a nie skończyła jako ambitny projekt zbyt oderwany od realiów szkoły.

Skoro nie dało się po prostu zatrzymać szkoły i wymienić całego środowiska pracy, potrzebna była inna logika zmiany. Najważniejsza decyzja była tu dość prosta, ale miała duże konsekwencje: nie rozwijać dalej dziesiątek luźnych arkuszy i pochodnych zestawień, tylko zacząć porządkować operacyjne wejścia do systemu i stopniowo przenosić cięższą logikę danych do bardziej stabilnej warstwy pod spodem.

W tej decyzji ważną rolę odegrało też coś jeszcze: szkoła była już mocno osadzona w środowisku Google i dobrze się w nim poruszała. To oznaczało, że zamiast budować zupełnie nowy, obcy ekosystem, lepiej było dobrać narzędzia w taki sposób, żeby pozostać możliwie blisko świata, który organizacja już zna. To zmniejszało koszt zmiany i zwiększało szansę, że nowe rozwiązanie będzie naprawdę używane.

To oznaczało odejście od modelu, w którym arkusze są jednocześnie:

• miejscem wprowadzania danych,
• miejscem ich przetwarzania,
• miejscem raportowania,
• i miejscem ratowania wyjątków.

Przy małej skali taki układ bywa bardzo skuteczny. Przy większej zaczyna mieszać role, które lepiej rozdzielić.

Dlatego część operacyjnych „excelików” została przeniesiona do AppSheet. Najprościej mówiąc, AppSheet pozwolił zamienić część arkuszowych procesów na prostsze, bardziej uporządkowane narzędzia do codziennej pracy, ale bez odrywania zespołu od środowiska, które już znał.

Nie chodziło więc o to, żeby zachwycać się nowym narzędziem. Chodziło o to, żeby zachować dla zespołu możliwie podobną ergonomię pracy, a jednocześnie zacząć zbierać dane wejściowe w bardziej uporządkowanej i przewidywalnej formie. To była ważna różnica. Celem nie było zafundowanie ludziom nowego świata. Celem było uporządkowanie inputów bez dokładania niepotrzebnego kosztu zmiany.

Pod spodem cięższa warstwa zaczęła trafiać do centralnej bazy danych i narzędzi do automatycznego przetwarzania danych, również dobranych wewnątrz ekosystemu Google. Tam można już było pracować dużo dojrzalej niż w jednym dużym arkuszu. Dane z systemów mogły być najpierw przechowywane w surowej postaci, potem porządkowane i przeliczane do formy pośredniej, a dopiero na końcu zamieniane w dane gotowe pod raporty, payroll i dalsze automatyzacje. Dzięki temu nie trzeba było liczyć wszystkiego jednym rzutem bezpośrednio z danych źródłowych.

Dzięki takiemu układowi stopniowo znikała potrzeba ręcznego „doklejania miesięcy”, przepisywania danych między zestawieniami i utrzymywania coraz bardziej kruchego układu zależności w samych arkuszach.

To była chyba najważniejsza decyzja w całym projekcie: nie traktować zmiany jako jednej wielkiej migracji z narzędzia A do narzędzia B, tylko jako uporządkowanie całego przepływu. Od bardziej sensownych inputów operacyjnych, przez centralną warstwę danych, aż po stabilniejsze raportowanie i rozliczenia. Dzięki temu szkoła nie dostała tylko „nowej technologii”. Dostała bardziej logiczny model pracy z danymi.

Kiedy patrzy się na taki projekt z zewnątrz, łatwo wyobrazić go sobie jako jedną zmianę: przenieśli dane z miejsca A do miejsca B i gotowe. W praktyce tutaj powstał znacznie szerszy system, który porządkuje zarówno dane, jak i część pracy operacyjnej wokół nich.

W centrum tej zmiany znalazła się wspólna warstwa danych. Zamiast opierać się głównie na ręcznie dokładanych raportach i kolejnych arkuszach, szkoła dostała centralne miejsce, do którego można automatycznie pobierać dane z używanych systemów, przechowywać je, porządkować i dalej przeliczać. To stworzyło zupełnie inną bazę do pracy niż wcześniejszy model, w którym wiedza o stanie szkoły była rozproszona między wieloma plikami i roboczymi zestawieniami.

Na tym fundamencie została zbudowana logika regularnych synchronizacji. Dane nie muszą już być w tak dużym stopniu ręcznie przenoszone i dokładane miesiąc po miesiącu. Zostały przygotowane procesy, które pobierają je automatycznie, zapisują przebieg działania i pozwalają odtwarzać, co się wydarzyło, jeśli coś wymaga sprawdzenia. To bardzo ważny detal, bo przy większej skali nie wystarczy już samo „żeby się zaciągnęło”. Potrzebna jest też kontrola nad tym, czy proces rzeczywiście przebiegł poprawnie.

Najprościej mówiąc, w systemie zaczęły pojawiać się bezpieczniki. Takie miejsca, które dają sygnał, jeśli coś potencjalnie poszło nie tak, coś się nie odświeżyło albo jakiś etap wymaga uwagi. To trochę jak kontrolki i lampki ostrzegawcze, dzięki którym nie trzeba zgadywać, czy można ufać temu, co widać w raporcie. Przy danych tej skali taki spokój i przewidywalność są bardzo dużo warte.

Równolegle powstała warstwa, która porządkuje dane z różnych źródeł i pozwala je sensownie łączyć. W tym projekcie bardzo ważne było nie tylko uporządkowanie danych z głównego systemu szkoły, ale też przygotowanie gruntu pod łączenie ich z innymi miejscami, w których żyje relacja z klientem i sprzedaż. Dzięki temu system nie kończy się na samym raportowaniu. Zaczyna budować wspólny obraz tego, co dzieje się w szkole i wokół klienta.

Duża część pracy poszła też w uporządkowanie warstwy payrollowo-operacyjnej. To jest obszar, który często z zewnątrz wydaje się mniej widowiskowy niż dashboardy czy automatyzacje marketingowe, ale dla szkoły bywa znacznie ważniejszy. Powstał bardziej stabilny proces przygotowania danych do rozliczeń z instruktorami i współpracownikami, razem z lepszym zapleczem do dokumentów, podsumowań i miesięcznej pracy operacyjnej.

Miłym, ale wcale nie błahym efektem ubocznym tej zmiany były też nowe, estetyczne formatki HTML z miesięcznym podsumowaniem wynagrodzenia. Zamiast surowego arkusza czy roboczego eksportu szkoła może przekazać ludziom czytelne podsumowanie spójne z własną identyfikacją wizualną. To może wyglądać jak detal, ale w praktyce buduje wizerunek szkoły także od środka, jako uporządkowanego i profesjonalnego miejsca pracy.

Samo przepięcie tego procesu było zresztą osobnym wyzwaniem. W payrollu nie ma komfortu długiego okresu przejściowego. Po zamknięciu miesiąca jest tylko kilka dni, żeby wszystko policzyć, sprawdzić i wypuścić dalej. Decyzja, że „od tego miesiąca przełączamy się na nowy model”, niesie więc dużą odpowiedzialność. Żeby to zrobić bezpiecznie, wszystko trzeba było wcześniej przygotować, przetestować i mieć realną pewność, że zadziała wtedy, kiedy będzie naprawdę potrzebne.

Pod spodem pojawiły się też fundamenty dalszej automatyzacji. System jest już przygotowany do regularnego uruchamiania procesów, reagowania na wybrane zdarzenia i stopniowego przejmowania kolejnych zadań, które wcześniej wymagały ręcznej obsługi. To nie jest jeszcze historia o „wszystkim zautomatyzowanym”. To jest historia o tym, że szkoła dostała bazę, na której automatyzacje mają sens i nie są już tylko kolejnymi doklejanymi obejściami.

Najkrócej: nie powstał tu pojedynczy raport ani pojedyncza integracja. Powstało uporządkowane zaplecze danych i procesów, które zaczyna działać jak wspólny system, a nie zbiór sprytnych, ale coraz trudniejszych do utrzymania rozwiązań.

Najciekawsze w tym projekcie jest to, że z perspektywy codziennej pracy szkoły ta zmiana nie przyszła w formie widowiskowej rewolucji. I właśnie o to chodziło.

Nie było pożaru. Nikt nie utknął nagle z nowym narzędziem, którego nie rozumie. Nie było paraliżu pracy ani tygodni chaosu potrzebnych do tego, żeby „wdrożyć zmianę”. Pod wieloma względami największym sukcesem operacyjnym było właśnie to, że ta przebudowa odbyła się bardzo cicho. Zespół nie musiał płacić za nową architekturę nadmiernym kosztem codziennej pracy.

To może brzmieć mało spektakularnie, ale w praktyce jest ogromną wartością. W wielu projektach technologicznych najwięcej energii zużywa się nie na samą zmianę jakości, tylko na gaszenie skutków ubocznych wdrożenia. Tutaj udało się przeprowadzić dużą zmianę pod spodem tak, żeby na froncie nie zostawić po sobie zgliszcz.

Jednocześnie efekty były bardzo realne i bardzo szybko odczuwalne. Po pierwszym etapie przepięcia szkoła miała świeże i wiarygodne dane już na samym początku miesiąca. Wcześniej dojście do takiego stanu potrafiło zająć nawet kilkanaście dni, a przy największych problemach z arkuszami zdarzały się też dużo większe opóźnienia. Po drugim etapie sytuacja zmieniła się jeszcze mocniej: świeże dane zaczęły czekać codziennie rano.

To jest zmiana, która z zewnątrz może wyglądać jak detal operacyjny, ale w praktyce mocno wpływa na sposób zarządzania szkołą. Co innego pracować na obrazie sytuacji sprzed kilkunastu dni, a co innego mieć aktualne dane dostępne praktycznie od ręki. To skraca dystans między tym, co dzieje się w szkole, a tym, co naprawdę widać w liczbach.

Co ważne, efekt tej zmiany był odczuwalny szybciej, niż można było się spodziewać. Już po wdrożeniu pierwszych etapów było jasne, że projekt nie jest tylko porządkiem technicznym na zapleczu, ale realnie wyprzedza dotychczasowe tempo pracy szkoły na danych.

To z kolei otworzyło kolejny, bardzo ważny etap: skoro świeże i wiarygodne dane są już dostępne, trzeba dobrze zdecydować, jak najlepiej z nich skorzystać.

I tu pojawia się ważne rozróżnienie. Same dane nie rozwiązują jeszcze wszystkiego. Dane trzeba jeszcze sensownie zsyntetyzować: zamienić na dobre raporty, czytelne widoki, użyteczne KPI i sensowne decyzje. Ten projekt nie kończy się więc na pytaniu „czy dane są?”, tylko prowadzi do znacznie ciekawszego pytania: „jak najlepiej wykorzystać to, że wreszcie można im ufać i mieć je na czas?”.

Druga zmiana jest jeszcze bardziej ekscytująca, bo dotyczy obszarów, które wcześniej były raczej marzeniem niż realnym planem. Kiedy szkoła ma już porządną warstwę danych i automatyczne odświeżanie, dużo bliżej stają się rzeczy takie jak komunikacja urodzinowa, urodzinowe upominki, prostsze programy lojalnościowe czy bardziej świadoma praca na relacji z klientem. Na samym początku trudno nawet zdecydować, co uruchamiać najpierw. To jest ten moment, w którym porządek w danych przestaje być tylko zapleczem operacyjnym, a zaczyna realnie pracować na sprzedaż, relacje i markę szkoły.

Z zewnątrz taki projekt może wyglądać jak techniczne zaplecze, którego na co dzień prawie nie widać. I w pewnym sensie właśnie tak jest. Najlepsze tego typu zmiany często nie objawiają się wielkim show na froncie, tylko tym, że szkoła zaczyna działać spokojniej, pewniej i bardziej przewidywalnie.

W Salsa Libre nie chodziło o to, żeby „wdrożyć nowinki” albo zbudować coś efektownego dla samego efektu. Chodziło o stworzenie takiego zaplecza danych i operacji, które udźwignie skalę szkoły, zdejmie część ręcznej pracy, poprawi zaufanie do liczb i otworzy drogę do rzeczy, które wcześniej były trudne albo zbyt kruche, żeby je sensownie uruchamiać.

Właśnie dlatego ten case wydaje mi się ciekawy nie tylko jako historia jednego projektu. Taka skala operacji i takie potrzeby dotyczą raczej policzalnej grupy szkół. Ale sama lekcja jest szersza: w pewnym momencie przestaje chodzić o samą technologię, a zaczyna chodzić o porządek w danych i w logice biznesowej. Jeśli ten porządek jest zaniedbany, organizacja wcześniej czy później zaczyna płacić za to wolniejszym rozwojem, większą ręczną pracą i coraz trudniejszym podejmowaniem decyzji.

I chyba to jest najlepsze podsumowanie tej pracy: nie zbudowaliśmy po prostu kolejnego raportu ani kolejnego narzędzia. Udało się zbudować podstawę, na której szkoła może dalej rosnąć bardziej świadomie, z lepszym spokojem operacyjnym i z dużo większym potencjałem na kolejne sensowne automatyzacje.