Case study

ERP dla STAVIA

Case budowy rozwiązania operacyjnego na bazie prawdziwych potrzeb biznesowych.

Portfolio procesu

Decyzje, wdrożenia, wynik.

Ten case dokumentuje sytuację wyjściową, problem, wykonane działania i rezultat.

StatusW trakcie

ERP dla STAVIA jest case study budowy systemu operacyjnego na podstawie realnych potrzeb firmy. To nie jest publiczny opis szczegółów biznesowych ani wewnętrznej logiki organizacji. Celem case’a jest pokazanie sposobu myślenia: jak zamieniać codzienny chaos operacyjny w strukturę, statusy, odpowiedzialność i decyzje.

Ten projekt jest ważny także dla KERNAL, bo pokazuje źródło wielu decyzji produktowych: dobry system nie zaczyna się od funkcji. Zaczyna się od zrozumienia procesu.

Kontekst

STAVIA prowadzi klienta przez wieloetapowy proces: od pozyskania leada, przez mailing, ofertowanie, uzgodnienia i zatwierdzenie umowy, aż po przygotowanie harmonogramu budowy. Każdy etap wymaga jasnego statusu, dokumentów i komunikacji.

ERP obejmuje pełną obsługę leada i klienta. Zdefiniowano w nim 60 statusów, które opisują kolejne stany procesu i uruchamiają odpowiednie działania operacyjne.

Problem

Przed wdrożeniem praca opierała się przede wszystkim na Excelu. Przy rozbudowanym procesie sprzedażowym oznaczało to ręczne pilnowanie kolejnych kroków, komunikacji i aktualnego etapu każdej sprawy.

Najbardziej widocznym skutkiem był czas potrzebny na przygotowanie oferty. Bez wspólnego procesu i automatyzacji średnio zajmowało to 7 dni.

Co zrobiłem

Najpierw proces, potem ekran

Zmapowałem cały proces obsługi leada i klienta, a następnie przełożyłem go na moduły, reguły oraz 60 jednoznacznych statusów. System prowadzi sprawę od pozyskania przez ofertowanie i umowę do harmonogramu budowy.

Status jako język operacyjny

Status jest jednocześnie informacją dla zespołu i początkiem właściwego kolejnego działania. Automatyzacje komunikacji reagują na zdarzenia w ERP i wspierają codzienną obsługę spraw bez dokładania kolejnych ręcznych list.

Bezpieczny zakres publiczny

Ten case pokazuje sposób pracy, ale nie ujawnia wrażliwych danych, logiki handlowej ani szczegółów procesów, które powinny pozostać wewnątrz firmy.

Proces realizacji

Wdrożenie zastąpiło arkusz uporządkowanym procesem. Pierwszy etap pozostawił liczenie ceny poza systemem, ale kolejna iteracja przeniosła kalkulację do kontrolowanego silnika webowego opartego na analizie technicznej, cennikach i jawnych formułach.

  • opis procesu i jego granic,
  • ustalenie właścicieli i punktów decyzyjnych,
  • zdefiniowanie 60 statusów operacyjnych,
  • automatyzacja wybranych komunikatów i przypomnień,
  • testy E2E procesu sprzedażowego i usuwanie błędów blokujących kolejne etapy.

Kalkulator ofert w systemie

Przygotowanie oferty zostało wsparte przez kontrolowany kalkulator działający na podstawie danych z wcześniejszej analizy projektu. Zespół nadal zachowuje możliwość weryfikacji zakresu i korekty założeń przed przedstawieniem propozycji klientowi.

Portal oferty i reakcja na zdarzenia

Po akceptacji wewnętrznej klient otrzymuje czytelny dostęp do oferty i może wybrać dalszy krok: zaakceptować kierunek, poprosić o optymalizację albo zrezygnować. Opiekun widzi zmianę i może zareagować w odpowiednim momencie.

Moduł Dni Otwartych

W lipcu 2026 powstała wewnętrzna warstwa obsługi zapisów na Dni Otwarte. Pozwala przygotować terminy, porządkować zgłoszenia i prowadzić dalszą komunikację z uczestnikami. Publiczny formularz i pełne uruchomienie procesu pozostają kolejnym krokiem.

Efekt

ERP działa produkcyjnie i porządkuje pełną obsługę leada oraz klienta. Najbardziej mierzalnym rezultatem jest skrócenie średniego czasu przygotowania oferty z 7 do 3 dni.

  • 60 statusów opisujących pełny proces,
  • 7 → 3 dni — średni czas przygotowania oferty,
  • kilkaset zdarzeń miesięcznie obsługiwanych produkcyjnie przez automatyzacje e-mail i SMS,
  • jeden uporządkowany proces zamiast pracy opartej na Excelu,
  • webowy kalkulator etapów oferty oparty na analizie technicznej i cennikach.

Wpływ na KERNAL

Praca nad ERP dla STAVIA wzmacnia kierunek KERNAL: systemy powinny porządkować decyzje, statusy i odpowiedzialność. To samo założenie przenosi się później na marketing. Różni się domena, ale mechanizm jest podobny: mniej zgadywania, więcej procesu.

Dzięki temu KERNAL nie powstaje jako abstrakcyjny produkt AI. Powstaje na bazie realnych doświadczeń z budowy systemów operacyjnych.

Status

Rdzeń systemu, wsparcie przygotowania ofert, widok klienta i automatyzacje komunikacji są gotowe. Dalszego domknięcia wymagają wybrane etapy procesu oraz pełne uruchomienie zapisów na Dni Otwarte.

Gotowe

  • pełna obsługa leada i klienta,
  • 60 statusów operacyjnych,
  • automatyzacje komunikacji i przypomnień,
  • webowy kalkulator ofert i portal oferty klienta,
  • produkcyjna obsługa kilkuset zdarzeń miesięcznie.

Następne

  • domknięcie wybranych modułów umów i analiz,
  • publiczny formularz i uruchomienie Dni Otwartych,
  • dalsze testy E2E i optymalizacja procesu,
  • wyciąganie lekcji dla KERNAL.

Lessons learned

System zaczyna się od odpowiedzialności

Jeśli nie wiadomo, kto podejmuje decyzję, narzędzie nie rozwiąże problemu. Może go tylko lepiej ukryć.

Statusy muszą być proste

Dobry status pomaga działać. Zły status tworzy kolejną warstwę niepewności.

Operacje i marketing mają wspólny problem

W obu przypadkach chodzi o to samo: mniej rozproszenia, więcej decyzji, większa kontrola nad wykonaniem.