Dlaczego nowa aplikacja nie powinna być kopią Excela 1:1?
W wielu firmach decyzja o stworzeniu aplikacji zaczyna się od konkretnego pliku. Jest arkusz, który przez lata był rozwijany, uzupełniany, poprawiany i dostosowywany do codziennej pracy zespołu. Zawiera dane, formuły, statusy, komentarze, kolory, ręczne korekty, raporty i kilka zakładek, których znaczenie rozumieją tylko wybrane osoby.
Naturalna prośba brzmi wtedy: “chcemy przenieść ten Excel do systemu”.
To zrozumiałe. Arkusz jest znany, działa od dłuższego czasu i opisuje realny sposób pracy firmy. Problem w tym, że aplikacja zaprojektowana jako kopia Excela 1:1 bardzo często powiela jego ograniczenia. Zamiast uporządkować proces, zamienia plik w niewygodny formularz online. Zamiast zmniejszyć liczbę wyjątków, utrwala je w nowym narzędziu. Zamiast poprawić kontrolę, tworzy cyfrową wersję tego samego chaosu.
Dlatego Excel jest bardzo dobrym punktem startu do analizy. Nie powinien jednak być gotowym projektem aplikacji.
Droższy Excel to nadal Excel
Jeśli nowa aplikacja tylko odtworzy stare kolumny, kolory, komentarze i ręczne obejścia, firma nie rozwiąże problemu. Dostanie ten sam chaos — tylko w droższym narzędziu.
Excel ma układ komórkowy, aplikacja powinna mieć układ procesowy
Excel porządkuje informacje w komórkach, kolumnach, wierszach i zakładkach. To świetne podejście do analiz, zestawień, kalkulacji i pracy roboczej. Użytkownik może szybko dodać kolumnę, zmienić formułę, skopiować zakres danych albo przygotować własny widok.
Aplikacja działa inaczej. Jej zadaniem nie jest tylko przechowywanie informacji w tabeli. Dobrze zaprojektowana aplikacja powinna prowadzić użytkownika przez proces.
W Excelu użytkownik widzi dużą tabelę i sam wie, co ma zrobić dalej. W aplikacji powinien dostać właściwy ekran, właściwe pola, właściwe akcje i właściwe ograniczenia wynikające z jego roli. Handlowiec nie musi widzieć wszystkich technicznych kolumn. Manager nie musi edytować danych źródłowych, jeśli jego zadaniem jest akceptacja. Osoba odpowiedzialna za raport nie musi ręcznie sprawdzać, czy ktoś wypełnił wymagane pola
Przykład: arkusz do obsługi ofert może mieć kilkadziesiąt kolumn: klient, produkt, rabat, marża, status, komentarz, data wysłania, osoba odpowiedzialna, koszt, wersja oferty, uwagi zarządu, data akceptacji. W Excelu to wszystko znajduje się obok siebie. W aplikacji lepszym rozwiązaniem może być podział na: kartę klienta, formularz oferty, kalkulację, akceptację marży, historię zmian i raport skuteczności.
To nie jest kosmetyczna różnica. To zmiana z układu “tabela z danymi” na układ “proces z rolami i decyzjami”.
Nie każda kolumna jest wymaganiem biznesowym
Jednym z najważniejszych etapów analizy jest odróżnienie realnych wymagań od obejść, które powstały tylko dlatego, że arkusz miał swoje ograniczenia.
W firmowych Excelach często znajdują się kolumny, które nie opisują procesu, ale pomagają go ręcznie obsłużyć. Na przykład:
- kolumna “do sprawdzenia”, bo nie ma formalnego statusu,
- kolumna “uwaga”, bo nie ma miejsca na komentarze i historię decyzji,
- kolumna “wersja”, bo plik jest kopiowany i wysyłany między osobami,
- kolumna “czy wysłane”, bo nie ma automatycznego powiadomienia,
- kolumna “stary status”, bo ktoś musi ręcznie kontrolować zmianę,
- kolumna “poprawione ręcznie”, bo formuła nie obsługuje wyjątków.
Gdy taka kolumna zostanie przeniesiona do aplikacji bez analizy, powstaje ryzyko, że system będzie wymagał od użytkownika ręcznego uzupełniania informacji, które powinny wynikać z procesu automatycznie.
Jeżeli użytkownik musi zaznaczać, że sprawa została wysłana, być może aplikacja powinna sama zapisać ten fakt po wysłaniu wiadomości. Jeżeli ktoś wpisuje ręcznie datę akceptacji, być może system powinien zapisywać ją automatycznie w momencie kliknięcia “zaakceptuj”. Jeżeli kolumna służy do oznaczania wyjątków, trzeba sprawdzić, jakie to wyjątki i czy można je obsłużyć regułą, statusem albo osobną ścieżką procesu.
Dlatego pytanie nie brzmi: “jakie kolumny mają znaleźć się w aplikacji?”. Lepsze pytanie brzmi: “po co ta kolumna istnieje i jaką potrzebę biznesową obsługuje?”.
Masz Excela, którego nikt nie chce już ruszać?
To często znak, że arkusz stał się zbyt ważny, zbyt skomplikowany albo zbyt ryzykowny, żeby dalej działał w obecnej formie.
Pokaż nam swój plik. Sprawdzimy, czy warto go uporządkować, zautomatyzować, zamienić w dashboard czy przenieść do aplikacji.
Kolor komórki to nie status procesu
W Excelu bardzo często znaczenie danych wynika nie tylko z wartości w komórkach, ale też z formatowania. Kolor oznacza pilność, pogrubienie oznacza akceptację, przekreślenie oznacza rezygnację, a czerwone tło oznacza problem.
Dla osoby, która pracuje z plikiem codziennie, to może być czytelne. Dla aplikacji taki zapis jest jednak zbyt nieformalny.
Jeżeli kolor oznacza status, trzeba nazwać status. Jeżeli czerwone tło oznacza błąd, trzeba określić regułę błędu. Jeżeli żółte pole oznacza “czeka na decyzję”, trzeba ustalić, kto podejmuje decyzję, w jakim terminie i co dzieje się po jej podjęciu.
W aplikacji status powinien być elementem procesu, a nie dekoracją danych. Powinien wpływać na dostępne akcje, widoczność informacji, powiadomienia, raporty i odpowiedzialność.
Przykład:
w arkuszu zamówień kolor niebieski oznacza “do przygotowania”, żółty “czeka na klienta”, zielony “gotowe”, czerwony “problem”. W aplikacji te kolory mogą zostać zastąpione konkretnymi statusami. Dzięki temu można filtrować sprawy po statusie, wysyłać powiadomienia, mierzyć czas przebywania w danym etapie i sprawdzić, gdzie proces najczęściej się blokuje.
To jest wartość aplikacji. Nie samo przeniesienie kolorów z arkusza, ale zamiana nieformalnych oznaczeń w kontrolowany proces.
Jeżeli kolor w Excelu oznacza decyzję, to warto go nazwać
Czerwone pole, żółte tło albo zielona komórka często oznaczają coś ważnego: problem, akceptację, opóźnienie albo zakończony etap. W aplikacji takie informacje nie powinny zależeć od tego, czy ktoś pamięta znaczenie kolorów. Powinny być jasne dla każdego użytkownika i widoczne w raportach.
Łukasz Rompca
właściciel evolabs.dev
Formularz nie powinien być długą tabelą do uzupełnienia
Częsty błąd przy projektowaniu aplikacji na podstawie Excela polega na tym, że wszystkie kolumny z arkusza stają się polami jednego dużego formularza.
Technicznie da się to zrobić. Biznesowo często nie ma to sensu.
Użytkownik otrzymuje ekran z kilkudziesięcioma polami, z których część nie dotyczy jego roli, część jest potrzebna dopiero później, część powinna być wyliczana automatycznie, a część wynika z danych w innych modułach. Taka aplikacja szybko staje się uciążliwa. Użytkownicy zaczynają omijać pola, wpisywać dane robocze, tworzyć własne skróty albo wracać do Excela, bo “tam było szybciej”.
Lepsze podejście polega na sprawdzeniu, kto i kiedy potrzebuje danej informacji.
Niektóre pola są potrzebne na początku procesu. Inne dopiero przy akceptacji. Część widzi tylko księgowość. Część powinna być widoczna dla zarządu, ale nieedytowalna. Część powinna wynikać z cennika, słownika, integracji albo wcześniejszego wyboru.
Dobrze zaprojektowana aplikacja nie pokazuje wszystkiego wszystkim. Pokazuje to, co jest potrzebne do wykonania konkretnego kroku.
Trzeba oddzielić dane, reguły i raporty
W Excelu dane, reguły i raporty często żyją w jednym miejscu. W jednej zakładce są dane źródłowe, w drugiej formuły, w trzeciej zestawienie, w czwartej korekty, a w piątej raport dla zarządu. Czasem te warstwy są wymieszane jeszcze bardziej: część formuł znajduje się obok danych, a raport powstaje przez ręczne filtrowanie i kopiowanie zakresów.
W aplikacji warto te elementy rozdzielić.
Dane to informacje, które opisują rzeczywistość biznesową: klient, zamówienie, oferta, koszt, projekt, pracownik, umowa, produkt, status. Reguły to sposób działania procesu: co można edytować, kiedy wymagana jest akceptacja, jak liczona jest marża, kiedy wysłać powiadomienie, co jest błędem, jakie pola są obowiązkowe. Raporty to sposób prezentacji danych: widoki, zestawienia, wskaźniki, filtry, eksporty, porównania.
Ile kosztuje ręczne kopiowanie danych między Excelem, CRM i ERP?
W firmach korzystających z kilku narzędzi jednocześnie Excel bardzo często staje się miejscem ręcznego łączenia danych. Informacje pochodzą z CRM, ERP, systemu fakturowego, sklepu internetowego, formularzy, maili, plików CSV albo innych arkuszy. Ktoś musi je pobrać, wkleić, dopasować, uzupełnić brakujące pola i sprawdzić, czy wszystko się zgadza.
W firmach korzystających z kilku narzędzi jednocześnie Excel bardzo często staje się miejscem ręcznego łączenia danych. Informacje pochodzą z CRM, ERP, systemu fakturowego, sklepu internetowego, formularzy, maili, plików CSV albo innych arkuszy. Ktoś musi je pobrać, wkleić, dopasować, uzupełnić brakujące pola i sprawdzić, czy wszystko się zgadza.
Taka praca jest kosztowna z kilku powodów. Po pierwsze, zajmuje czas. Po drugie, jest podatna na pomyłki, bo wystarczy wkleić dane w złe miejsce, pominąć fragment tabeli albo nie zauważyć zmiany formatu eksportu. Po trzecie, trudno ją kontrolować. Jeżeli wynik raportu zależy od kilkunastu ręcznych kroków, firma musi ufać, że każdy z nich został wykonany poprawnie.
Jeżeli te trzy warstwy zostaną pomieszane, aplikacja może stać się trudna w rozwoju. Każda zmiana raportu będzie wyglądała jak zmiana danych. Każda zmiana reguły będzie wymagała sprawdzania wielu ekranów. Każdy wyjątek będzie dopisywany jako kolejne pole.
Oddzielenie danych, reguł i raportów daje większą kontrolę. Pozwala rozwijać proces bez przebudowy całego narzędzia. Ułatwia też odpowiedź na pytanie, co naprawdę trzeba zbudować, a co jest tylko sposobem prezentacji informacji.
Historia zmian nie powinna być komentarzem w komórce
W arkuszach komentarze często pełnią rolę pamięci procesu. Ktoś dopisuje, dlaczego zmienił wartość. Ktoś zaznacza, że klient poprosił o korektę. Ktoś wpisuje powód odrzucenia. Ktoś inny dopisuje aktualizację po rozmowie telefonicznej.
To działa, dopóki proces jest prosty i obsługiwany przez mały zespół. Przy większej liczbie osób komentarze szybko przestają wystarczać.
Aplikacja powinna zapisywać historię zmian w sposób uporządkowany. Kto zmienił dane, kiedy, z jakiej wartości na jaką, w jakim statusie była sprawa i jaka akcja została wykonana. Nie zawsze trzeba pokazywać użytkownikowi pełny techniczny zapis zmian, ale system powinien mieć możliwość odtwórczą.
Ma to znaczenie nie tylko przy błędach. Historia zmian pomaga analizować proces. Pokazuje, gdzie pojawiają się opóźnienia, które decyzje są cofane, jakie wyjątki występują najczęściej i które etapy wymagają doprecyzowania.
To kolejny przykład różnicy między kopią arkusza a systemem. Kopia arkusza daje miejsce na komentarz. System daje odpowiedzialność i ślad decyzyjny.
Aplikacja powinna ograniczać błędy, a nie tylko je przechowywać
Jeżeli Excel pozwala wpisać dowolną wartość, użytkownicy często wpisują dane w różnych formatach. Ten sam status może mieć kilka nazw. Data może być tekstem. Nazwa klienta może występować w kilku wersjach. Kwoty mogą być wpisane z różnymi walutami albo bez podatku. Część pól może być pusta, mimo że później raport zakłada ich obecność.
Przeniesienie takiego układu 1:1 do aplikacji nie rozwiązuje problemu. Aplikacja powinna wprowadzać walidacje i ograniczenia tam, gdzie mają sens biznesowy.
Nie chodzi o utrudnianie pracy użytkownikom. Chodzi o to, żeby system pomagał im wprowadzać dane poprawnie już na początku procesu. Lista wyboru zamiast dowolnego tekstu. Pole obowiązkowe tam, gdzie brak danych blokuje dalszy etap. Automatyczne sprawdzenie wartości, jeśli przekroczenie progu wymaga akceptacji. Komunikat, gdy użytkownik próbuje wykonać akcję bez wymaganych informacji.
Dzięki temu firma nie musi później ręcznie poprawiać danych przed raportem. Jakość danych powstaje w trakcie procesu, a nie dopiero na końcu.
Błędy w arkuszach są częstsze, niż się wydaje
W jednym z często cytowanych podsumowań badań nad arkuszami używanymi w firmach wskazano, że 94% analizowanych arkuszy zawierało błędy.
W prostym zestawieniu to może być drobiazg. W arkuszu, który służy do ofert, budżetów, raportów albo planowania pracy — to już ryzyko kosztownych decyzji.
Źródło: Powell, Baker, Lawson, Errors in Operational Spreadsheets.
(https://mba.tuck.dartmouth.edu/spreadsheet/product_pubs_files/errors.pdf?utm_source=chatgpt.com)
Nie wszystko z Excela musi trafić do pierwszej wersji systemu
Arkusze rozwijane przez lata często zawierają wiele elementów, które są używane rzadko, historycznie albo przez pojedyncze osoby. Przy projektowaniu nowego rozwiązania łatwo założyć, że wszystko musi zostać przeniesione od razu.
To zwykle zwiększa koszt, wydłuża projekt i komplikuje pierwszą wersję.
Lepszym podejściem jest ustalenie, które elementy są kluczowe dla procesu, które są potrzebne później, a które można zostawić poza systemem albo obsłużyć inaczej. Niektóre raporty mogą być eksportem. Niektóre pola mogą zostać przeniesione do kolejnego etapu. Niektóre ręczne korekty mogą okazać się niepotrzebne po uporządkowaniu reguł. Niektóre zakładki mogą być tylko archiwum.
Pierwsza wersja systemu powinna rozwiązywać najważniejszy problem biznesowy, nie odtwarzać całej historii arkusza.
Zanim zbudujesz system, policz koszt obecnego sposobu pracy
Jeśli zespół nadal ręcznie poprawia dane, sprawdza wersje pliku, szuka błędów i przygotowuje raporty, to firma już ponosi koszt — nawet jeśli sam Excel wydaje się darmowy.
Kiedy jednak warto zachować podobieństwo do Excela?
Nie chodzi o to, żeby całkowicie ignorować dotychczasowy sposób pracy. Arkusz jest ważnym punktem odniesienia, bo użytkownicy znają jego logikę, nazwy, układ danych i sposób myślenia.
W niektórych miejscach podobieństwo do Excela może pomóc. Dotyczy to szczególnie widoków tabelarycznych, eksportów, prostych zestawień, masowej edycji danych albo raportów operacyjnych. Jeżeli zespół przez lata pracował na tabeli, nie zawsze warto zastępować ją wyłącznie kartami i formularzami.
Różnica polega na tym, że podobieństwo powinno być świadomą decyzją projektową, a nie domyślnym założeniem.
Można zachować tabelaryczny widok danych, ale jednocześnie wprowadzić role, walidacje, statusy, historię zmian i kontrolę procesu. Można umożliwić eksport do Excela, ale nie traktować pliku jako głównego źródła prawdy. Można pokazać użytkownikom znane nazwy pól, ale uporządkować je w logiczne sekcje.
Celem nie jest zerwanie z Excelem za wszelką cenę. Celem jest usunięcie tych elementów, które utrudniają kontrolę i rozwój procesu.
Kiedy jednak warto zachować podobieństwo do Excela?
Przed projektowaniem systemu warto przejść przez kilka pytań kontrolnych.
-
1. Czy dana kolumna opisuje realną informację biznesową, czy tylko obejście?
Jeżeli kolumna istnieje po to, żeby ręcznie pilnować czegoś, co system może wykonać automatycznie, nie powinna być przenoszona bezpośrednio. -
2. Kto potrzebuje tej informacji i na którym etapie?
Jeżeli pole jest używane tylko przez jedną rolę, nie musi być widoczne dla wszystkich użytkowników. -
3. Czy dana wartość powinna być wpisywana ręcznie, wybierana z listy czy wyliczana?
To proste pytanie często ujawnia wiele miejsc, w których aplikacja może zmniejszyć liczbę błędów. -
4. Czy kolor, komentarz albo filtr oznacza ukryty status procesu?
Jeżeli tak, trzeba nazwać ten status i określić, jakie akcje są z nim związane. -
5. Czy raport korzysta z danych źródłowych, czy z ręcznie przygotowanego zestawienia?
Jeżeli raport wymaga wielu ręcznych kroków, być może problemem nie jest sam raport, ale brak uporządkowanego modelu danych. -
6. Czy ten element jest potrzebny w pierwszej wersji?
Nie każda funkcja z arkusza musi znaleźć się w pierwszym etapie. Część może poczekać, jeśli nie wpływa na główny proces. -
7. Co powinno się zmienić, gdy przestaniemy być ograniczeni strukturą Excela?
To jedno z najważniejszych pytań. Nowe narzędzie nie musi dziedziczyć wszystkich ograniczeń pliku.
Nie musisz być specjalistą od aplikacji
Wystarczy, że pokażesz nam arkusz, który dziś sprawia problem. My sprawdzimy, co można z nim zrobić, ile może kosztować zmiana i czy taka inwestycja ma sens dla Twojej firmy.
Najpierw logika procesu, potem projekt systemu
Dobra aplikacja nie powstaje przez przepisanie arkusza do formularzy. Powstaje przez zrozumienie, jak firma pracuje i jak powinna pracować po uporządkowaniu procesu.
Excel pokazuje bardzo dużo: dane, wyjątki, ręczne działania, raporty, kalkulacje i miejsca, w których użytkownicy musieli stworzyć obejścia. To cenny materiał analityczny. Trzeba go jednak zinterpretować.
Najpierw warto nazwać proces. Potem określić role, dane, statusy, decyzje, reguły, wyjątki i raporty. Dopiero na końcu projektować ekrany, formularze, automatyzacje, dashboardy albo aplikację.
Czasem po takiej analizie okaże się, że pełna aplikacja nie jest potrzebna. Wystarczy uporządkować arkusz, dodać automatyzację, przygotować dashboard albo wdrożyć prostsze workflow. Czasem przeciwnie – analiza pokaże, że arkusz od dawna obsługuje proces, który wymaga stabilniejszego systemu.
W obu przypadkach decyzja jest lepsza, bo wynika z logiki procesu, a nie z układu istniejącego pliku.
Mniej ręcznego raportowania, szybszy dostęp do danych
Dla firmy logistycznej EvoLabs stworzyło system, który zebrał dane operacyjne w jednym miejscu i dał zarządowi bieżący wgląd w kluczowe informacje.
Zamiast ręcznie składać raporty z wielu źródeł, firma może szybciej sprawdzać dane i podejmować decyzje na podstawie aktualnych informacji.
Podsumowanie
Excel może być bardzo dobrym początkiem. Często jest pierwszą wersją procesu, dokumentacją wyjątków i praktycznym zapisem tego, jak firma naprawdę działa. Nie powinien jednak automatycznie stawać się projektem aplikacji.
Aplikacja skopiowana z Excela 1:1 może powielić problemy, które miała rozwiązać: zbyt wiele pól, niejasne statusy, ręczne obejścia, brak odpowiedzialności, mieszanie danych z raportami i konieczność wykonywania czynności, które system powinien obsłużyć sam.
Dlatego przed projektowaniem rozwiązania trzeba oddzielić dane, reguły i raporty. Trzeba sprawdzić, które kolumny są rzeczywistymi wymaganiami, a które są tylko śladem dotychczasowego sposobu pracy. Trzeba nazwać role, statusy, walidacje, wyjątki i historię zmian.
Celem nie jest stworzenie “Excela w przeglądarce”. Celem jest usprawnienie procesu.
{Przeczytaj kolejne artykuły z serii
„Od Excela do aplikacji”}
7 sygnałów, że firmowy Excel przestał wystarczać
Ile naprawdę kosztuje firmę Excel?
Aplikacja zamiast Excela — kiedy to ma sens, a kiedy nie?
Jak przejść od Excela do aplikacji? Proces krok po kroku
Dlaczego aplikacja nie powinna być kopią Excela 1:1?
Najpierw porządkujemy logikę, potem projektujemy system
W EvoLabs pomagamy firmom spojrzeć na arkusz jak na proces biznesowy, a nie tylko plik do przepisania.
Analizujemy dane, role użytkowników, reguły, statusy, raporty, wyjątki i miejsca, w których obecny sposób pracy wymaga ręcznej kontroli. Dopiero po takim uporządkowaniu można świadomie zdecydować, czy najlepszym kierunkiem będzie poprawa arkusza, automatyzacja, dashboard, workflow czy dedykowana aplikacja.
Jeżeli ważny proces w Twojej firmie działa dziś w Excelu lub Google Sheets, warto zacząć od analizy jego logiki.