Excel nie jest problemem, dopóki nie zaczyna sterować firmą
Arkusz jest jednym z najlepszych narzędzi biznesowych. Można go uruchomić w kilka minut, dopisać kolumnę bez wdrożenia i szybko sprawdzić nowy sposób liczenia ceny. Dla małej liczby ofert działa znakomicie.
Problem pojawia się wtedy, gdy plik przestaje być kalkulatorem, a zaczyna pełnić rolę bazy danych, konfiguratora produktu, systemu uprawnień, historii zmian i generatora dokumentów.
Nagle istnieją pliki:
oferta_final.xlsx,oferta_final_poprawiona.xlsx,oferta_final_poprawiona_klient.xlsx,oferta_final_v7_OSTATECZNA.xlsx.
Cena zależy od formuł, które rozumie jedna osoba. Handlowiec kopiuje poprzednią ofertę, usuwa stare dane i liczy, że niczego nie pominął. Zatwierdzenie odbywa się na czacie. Aktualny PDF leży w innym wątku niż komentarze klienta.
To nie jest wada Excela. Narzędzie zostało po prostu przesunięte daleko poza rolę, do której pasowało.
Aplikacja ofertowania zaczyna mieć sens nie wtedy, gdy arkusz wygląda brzydko. Zaczyna mieć sens, gdy obecny proces produkuje błędy, blokuje ludzi i utrudnia sprzedaż.
Jak rozpoznać, że proces wyrósł z arkusza
Najważniejszym sygnałem nie jest liczba kolumn. Jest nim brak jednego źródła prawdy.
Proces wymaga uporządkowania, jeśli:
- kilka osób pracuje na kopiach tego samego pliku,
- nie wiadomo, która wersja została wysłana klientowi,
- ceny są ręcznie przepisywane z innych systemów,
- rabaty nie mają jasnych limitów,
- oferta wymaga akceptacji przełożonego, ale akceptacja nie zostawia śladu,
- zmiana jednego parametru wymaga poprawienia kilku arkuszy,
- dokumenty powstają przez kopiowanie danych do Worda albo PDF-a,
- handlowiec nie widzi statusu sprawy bez pytania innych osób,
- oferta zawiera błąd, którego źródła nie da się później odtworzyć,
- odejście jednej osoby oznacza utratę wiedzy o sposobie wyceny.
Warto policzyć nie tylko liczbę błędów. Trzeba policzyć czas poświęcony na szukanie plików, sprawdzanie wersji, poprawianie dokumentów i odpowiadanie na pytania, na które system powinien znać odpowiedź.
Pięć minut stracone na jednej ofercie wygląda niewinnie. Przy setkach ofert miesięcznie staje się etatem ukrytym w procesie.
Aplikacja ofertowania nie jest formularzem z przyciskiem PDF
Najprostszy ekran może rzeczywiście wyglądać jak formularz. Użytkownik wybiera klienta, produkty, parametry oraz rabat. Na końcu generuje dokument.
Wartość systemu znajduje się jednak pod interfejsem. Aplikacja musi wiedzieć:
- kto przygotowuje ofertę,
- dla jakiej organizacji i kontaktu,
- według jakiego cennika,
- w jakiej walucie,
- z jaką stawką podatku,
- z jakim terminem ważności,
- które pozycje są opcjonalne,
- kto może zmienić cenę,
- kto zatwierdził rabat,
- która wersja została wysłana,
- czy klient ją zaakceptował.
Jeżeli te informacje istnieją tylko w wygenerowanym PDF-ie, system nadal nie kontroluje procesu. Produkuje ładniejszy plik, ale nie buduje wiedzy o sprzedaży.
Dobra aplikacja ofertowania przechowuje dane strukturalnie. Dokument jest jednym z rezultatów procesu, a nie jego jedynym zapisem.
Najpierw proces, później ekran
Przepisywanie arkusza jeden do jednego do aplikacji jest częstym błędem. Firma dostaje nowy interfejs, ale zachowuje wszystkie stare obejścia.
Przed implementacją trzeba rozrysować rzeczywisty przepływ:
zapytanie
-> kwalifikacja
-> konfiguracja rozwiązania
-> wycena
-> akceptacja wewnętrzna
-> wysłanie klientowi
-> negocjacje i nowa wersja
-> akceptacja lub odrzucenie
-> przekazanie do realizacji
Nie każda firma potrzebuje wszystkich etapów. W jednej handlowiec sam zatwierdza cenę. W innej rabat powyżej pięciu procent wymaga zgody dyrektora. Czasami oferta staje się zamówieniem, czasami dopiero wejściem do osobnego systemu.
To właśnie te różnice uzasadniają własne narzędzie. Gotowy system obsługuje proces statystyczny. Aplikacja dedykowana ma odwzorować proces, który rzeczywiście działa w firmie — po wcześniejszym usunięciu zbędnych kroków.
Automatyzowanie chaosu daje szybszy chaos.
Model danych zamiast arkusza przeniesionego do przeglądarki
W arkuszu jeden wiersz może zawierać klienta, produkt, ilość, rabat, notatkę i status. W aplikacji te pojęcia powinny mieć jawne relacje.
Przykładowy model może zawierać:
Organization
Contact
Offer
OfferRevision
OfferItem
Product
PriceList
Approval
Attachment
ActivityLog
Oferta należy do klienta. Ma kolejne rewizje. Każda rewizja zawiera pozycje zapisane z cenami obowiązującymi w momencie jej utworzenia. Akceptacja wskazuje osobę, czas i zakres decyzji. Historia aktywności pokazuje, co wydarzyło się później.
To rozdzielenie ma praktyczne znaczenie. Zmiana obecnego cennika nie może po cichu zmienić oferty wysłanej dwa miesiące wcześniej. Usunięcie produktu z katalogu nie może usunąć go z dokumentów historycznych.
Model danych powinien opisywać biznes, a nie układ komórek w pliku.
Silnik cenowy musi być przewidywalny
W prostym przypadku cena to ilość pomnożona przez stawkę. W realnym procesie dochodzą progi, warianty, pakiety, marża, transport, rabaty, waluty, podatki i wyjątki zapisane w umowach.
Reguły cenowe powinny być:
- jawne,
- wersjonowane,
- testowalne,
- możliwe do wyjaśnienia użytkownikowi,
- oddzielone od wyglądu formularza.
Jeżeli wynik wynosi 143 820 zł, handlowiec powinien wiedzieć dlaczego. System powinien pokazać cenę bazową, zastosowane reguły, rabat i elementy dodatkowe. „Tak policzył algorytm” nie jest wyjaśnieniem.
Nie każda reguła musi od razu dostać rozbudowany edytor administracyjny. W MVP część konfiguracji może być zarządzana przez zespół techniczny. Ważne, żeby logika nie była porozrzucana między frontendem, szablonem PDF i webhookiem.
Najgroźniejsza jest sytuacja, w której ekran pokazuje jedną kwotę, backend zapisuje drugą, a generator dokumentu liczy trzecią.
Wersjonowanie oferty nie jest dodatkiem
Klient prosi o zmianę zakresu. Handlowiec usuwa dwie pozycje, dodaje rabat i wysyła nowy dokument. Co dzieje się ze starą wersją?
Nadpisanie rekordu niszczy historię negocjacji. Skopiowanie całej oferty tworzy luźne duplikaty. Poprawnym rozwiązaniem jest jawna rewizja.
Każda wersja powinna zachować:
- numer,
- datę utworzenia,
- autora,
- zakres i ceny,
- powód zmiany,
- status,
- informację o wysłaniu,
- powiązane akceptacje.
Dzięki temu wiadomo, która wersja obowiązuje i dlaczego wynik różni się od poprzedniego. Można też porównać zmiany bez otwierania dwóch PDF-ów na osobnych monitorach.
Historia jest potrzebna również po sprzedaży. Zespół realizacyjny musi dostać zakres zaakceptowany przez klienta, nie ostatni szkic znaleziony w folderze.
Akceptacje i uprawnienia chronią marżę
System nie powinien utrudniać pracy, ale musi rozróżniać odpowiedzialności.
Przykładowe role to:
- handlowiec przygotowujący ofertę,
- opiekun klienta,
- osoba zatwierdzająca rabat,
- administrator cenników,
- zespół realizacyjny z dostępem tylko do zaakceptowanego zakresu,
- audytor mający dostęp do historii bez możliwości edycji.
Samo ukrycie przycisku na froncie nie jest zabezpieczeniem. Uprawnienia muszą być egzekwowane w API. Użytkownik bez prawa do zatwierdzania rabatu nie może wykonać tej operacji przez ręcznie wysłane żądanie.
Warto też unikać jednej roli „admin”, która może wszystko. Im bardziej wrażliwe są ceny i umowy, tym ważniejsze stają się precyzyjne uprawnienia oraz log zdarzeń.
PDF jest wynikiem, nie bazą danych
Dokument nadal jest potrzebny. Klient może chcieć pobrać PDF, przesłać go dalej albo dołączyć do wewnętrznego procesu zakupowego.
Generator powinien korzystać z zapisanej rewizji oferty. Dzięki temu dokument można odtworzyć bez ponownego liczenia według aktualnych reguł.
Trzeba ustalić między innymi:
- szablony dla różnych marek lub oddziałów,
- numerację ofert,
- warunki handlowe,
- sposób prezentacji pozycji opcjonalnych,
- wersje językowe,
- załączniki,
- datę ważności,
- podpisy i dane osób odpowiedzialnych.
Nie warto zaczynać projektu od perfekcyjnego edytora dokumentów. Najpierw system musi poprawnie przeprowadzić ofertę przez proces. Ładny PDF wygenerowany z błędnych danych nadal jest błędną ofertą.
Integracje powinny usuwać przepisywanie danych
Aplikacja ofertowania rzadko działa całkowicie samodzielnie. Klienci mogą znajdować się w CRM-ie, produkty w ERP-ie, stany w systemie magazynowym, a zaakceptowana oferta powinna uruchamiać projekt albo zamówienie.
Integracja ma sens, gdy usuwa podwójne wprowadzanie danych. Nie każdą synchronizację trzeba jednak budować w pierwszym wydaniu.
Najczęstsze kierunki to:
- CRM — klient, kontakt i szansa sprzedażowa,
- ERP — produkty, ceny, podatki i zamówienia,
- system księgowy — dane nabywcy i dokumenty,
- e-mail — wysyłka oraz rejestrowanie komunikacji,
- podpis elektroniczny — akceptacja dokumentu,
- magazyn — dostępność i terminy,
- narzędzia projektowe — przekazanie zaakceptowanego zakresu.
Każda integracja potrzebuje odpowiedzi na pytanie o właściciela danych. Jeśli adres klienta różni się w CRM-ie i ERP-ie, który system ma pierwszeństwo? Bez tej decyzji automatyzacja przyspieszy rozprowadzanie błędu.
Backend i integracje są często ważniejsze od samego formularza. Więcej o takim podejściu opisujemy na stronie backend development.
Co powinno znaleźć się w MVP
MVP nie powinno odtwarzać całego procesu wraz ze wszystkimi wyjątkami z ostatnich dziesięciu lat.
Rozsądny pierwszy zakres może obejmować:
- logowanie i podstawowe role,
- klientów oraz osoby kontaktowe,
- tworzenie oferty,
- katalog najważniejszych produktów lub usług,
- podstawowe reguły cenowe,
- pozycje własne,
- wersjonowanie,
- prostą akceptację,
- generowanie PDF,
- statusy,
- historię najważniejszych działań,
- eksport danych.
Po wdrożeniu można sprawdzić, które wyjątki występują naprawdę. Część z nich okaże się reliktem starego procesu. Część będzie wymagała osobnej funkcji. Dzięki temu rozwój wynika z użycia, a nie z listy życzeń stworzonej przed pierwszym logowaniem.
Dobry MVP zamyka jeden proces od początku do końca. Dziesięć niedokończonych modułów nie daje takiej wartości jak jedna działająca ścieżka przygotowania i wysłania oferty.
Ile trwa stworzenie systemu ofertowania
Nie da się uczciwie wycenić systemu na podstawie liczby ekranów. Dwa podobne formularze mogą mieć zupełnie inną logikę cenową, integracje i wymagania bezpieczeństwa.
Na czas realizacji wpływają przede wszystkim:
- liczba ról i etapów akceptacji,
- złożoność cenników,
- liczba wariantów dokumentu,
- jakość danych źródłowych,
- integracje,
- migracja historii,
- wymagania audytowe,
- sposób wdrożenia i utrzymania.
Pierwszy działający proces może powstać etapami. Najpierw jedna grupa użytkowników, jeden typ oferty i jedno źródło produktów. Kolejne oddziały, cenniki oraz integracje dochodzą po ustabilizowaniu podstaw.
To bezpieczniejsze niż wielomiesięczna budowa ogromnego systemu, którego nikt nie użył przed oficjalnym startem.
Kiedy własna aplikacja się nie opłaca
Nie każdy arkusz trzeba natychmiast zastępować dedykowanym systemem.
Budowa może nie mieć sensu, gdy:
- firma przygotowuje kilka prostych ofert miesięcznie,
- proces jest standardowy i mieści się w dobrym CRM-ie,
- reguły zmieniają się tak często, że organizacja sama nie zna procesu,
- problemem jest brak dyscypliny, a nie ograniczenie narzędzia,
- nikt nie będzie właścicielem systemu po wdrożeniu,
- koszt błędów i ręcznej pracy jest niższy niż koszt utrzymania aplikacji.
Czasami wystarczy uporządkować szablon, zabezpieczyć formuły, ustalić nazewnictwo i podłączyć prostą automatyzację. Dedykowana aplikacja nie jest nagrodą za posiadanie skomplikowanego arkusza.
Jeśli gotowe narzędzie pokrywa większość procesu bez krytycznych obejść, warto zacząć od niego. Własny system jest uzasadniony wtedy, gdy różnica między procesem firmy a możliwościami SaaS-u staje się trwała i kosztowna.
Jak policzyć opłacalność
Najpierw trzeba policzyć koszt obecnego procesu:
czas przygotowania oferty
+ czas akceptacji
+ poprawki i ponowne wprowadzanie danych
+ koszt błędów
+ utracone szanse sprzedażowe
+ utrzymanie obecnych narzędzi
Następnie porównujemy go z kosztem wdrożenia, utrzymania i rozwoju aplikacji.
Nie wszystkie korzyści da się sprowadzić do czasu handlowca. System może skrócić wdrożenie nowej osoby, ujednolicić marże, pokazać przyczyny odrzuceń i przekazać realizacji pełny zakres bez kolejnego spotkania.
Nie warto jednak dopisywać fikcyjnych oszczędności, żeby uzasadnić projekt. Jeżeli zwrot wymaga nierealnego wzrostu sprzedaży, narzędzie prawdopodobnie nie rozwiązuje wystarczająco ważnego problemu.
Checklista przed rozpoczęciem
- Ile ofert powstaje tygodniowo i miesięcznie?
- Ile czasu zajmuje przygotowanie jednej oferty?
- Gdzie najczęściej pojawiają się błędy?
- Które reguły cenowe są stałe, a które uznaniowe?
- Kto może udzielać rabatów?
- Jak wygląda akceptacja wewnętrzna?
- Czy trzeba zachować wszystkie wersje?
- Skąd pochodzą dane klientów, produktów i cen?
- Do jakiego systemu trafia zaakceptowana oferta?
- Które integracje są niezbędne w pierwszej wersji?
- Czy istnieją dane historyczne wymagające migracji?
- Kto będzie właścicielem procesu i produktu?
- Jak zmierzymy poprawę po wdrożeniu?
Podsumowanie
Excel nie jest przeciwnikiem aplikacji ofertowania. Jest dobrym etapem odkrywania procesu. Pozwala szybko sprawdzić reguły, zanim firma zainwestuje we własny system.
Moment zmiany przychodzi wtedy, gdy arkusz nie tylko przechowuje dane, ale zaczyna zastępować bazę, workflow, uprawnienia, historię i integracje. Wtedy każda kolejna formuła zwiększa zależność od narzędzia, którego nie da się sensownie rozwijać jak produktu.
Dobra aplikacja nie kopiuje arkusza do przeglądarki. Porządkuje proces, nadaje danym strukturę, pilnuje wersji, chroni reguły cenowe i usuwa ręczne przepisywanie informacji.
Jeżeli firma traci czas na szukanie aktualnej oferty, poprawianie tych samych danych i wyjaśnianie, skąd wzięła się cena, problem nie leży już w wyglądzie Excela. Problemem jest brak systemu.
Systemy B2B