Czego nie budujemy: TMS, nie program księgowy
Zakres SaaS to także lista rzeczy, których świadomie nie budujesz. Jedno zdanie o granicy produktu wycięło z BusiKM moduł biura rachunkowego i 14 tys. linii.
Opublikowano: 6 min czytania
Autor: Łukasz Głowacz, Full-Stack Engineer · Read in English
Spis treści
Najważniejsza decyzja o zakresie BusiKM nie dotyczyła żadnej funkcji, którą zbudowałem. Dotyczyła tych, których nie zbuduję. Zapisałem ją jednym zdaniem w planie wdrożenia z 21 sierpnia: BusiKM jest TMS-em, nie programem księgowym. Od tego zdania zależało, co wchodzi do MVP, co wylatuje z kodu i jak rozmawiam z klientem o tym, czego w produkcie nie będzie.
Pokusa, żeby zrobić wszystko
BusiKM to system dla małych firm transportowych z busami do 3,5 t: zlecenia, trasy, faktury, koszty, kierowcy, czas pracy. Jedną z ról w systemie jest księgowa. Gdy księgowa ma konto w aplikacji, pokusa jest oczywista: skoro dane już tu są, to może od razu prowadzić tu księgi, liczyć podatki i płace, składać deklaracje.
Tak też wyglądał produkt wiosną. W kwietniu zbudowałem moduł dla biur rachunkowych: jedno biuro obsługiwało wiele firm klientów, przełączało się między nimi, miało własne plany abonamentowe i 90-dniowy okres próbny. Kod miał już generator JPK_FA i podsumowanie KPiR. Audyt produktu z 20 sierpnia poszedł nawet dalej i radził dobudować generator JPK_PKPiR i JPK_EWP oraz jeden przycisk „paczka dla księgowej”, który pakuje cały miesiąc do pliku ZIP.
Każda z tych rzeczy brzmiała rozsądnie osobno. Razem robiły z BusiKM program księgowy z modułem transportowym, a to jest inny produkt, z innym rynkiem i innymi konkurentami.
Granica w jednym zdaniu
Plan wdrożenia z 21 sierpnia zaczyna się od zasady naczelnej. Księgowa ma swój program: Insert, Comarch Optima, Symfonię albo inny. Od BusiKM potrzebuje danych transportowych w formie, którą łatwo wczyta do swojego programu. BusiKM nie prowadzi ksiąg, nie liczy podatków, nie liczy płac i nie składa deklaracji. Dostarcza dane: kompletne, poprawnie oznaczone podatkowo i w formacie, który jej program przyjmie.
Z tej zasady wynikły cztery rozstrzygnięcia, każde z krótkim uzasadnieniem:
| Czego nie budujemy | Dlaczego | Co dostarczamy zamiast tego |
|---|---|---|
| JPK_V7M, JPK_PKPiR, JPK_EWP | To deklaracje do urzędu, składa je program księgowej | Dane z poprawnymi oznaczeniami |
| KPiR jako plik | KPiR to księga, prowadzi ją program księgowej | Rejestry sprzedaży i zakupu |
| Płace (ZUS, PIT, netto i brutto) | To osobna dziedzina z własnymi programami | Karta czasu pracy, dni za granicą, diety, zaliczki, kilometry |
| Amortyzacja i harmonogram leasingu | To ewidencja środków trwałych | Forma własności pojazdu i poprawnie oznaczona rata jako koszt |
Ta sama zasada odrzuciła rekomendacje z audytu z poprzedniego dnia. Generator JPK_PKPiR i JPK_EWP wypadł z zakresu na stałe, bo to deklaracje. Paczka ZIP też odpadła, z krótkim uzasadnieniem w planie: księgowa pobiera to, czego potrzebuje.
Plik, nie API
Druga połowa tej decyzji dotyczy sposobu przekazania danych. Na pierwszy rzut oka integracja przez API z programem księgowym wygląda na lepsze rozwiązanie niż plik. Research z audytu pokazał coś innego. Standardem wymiany w Polsce jest plik: Insert czyta EPP, Comarch Optima ma API zależne od wersji i licencji partnerskich, a API Symfonii obsługuje KSeF, nie księgi. Budowanie integracji API do każdego z nich to koszt licencji, utrzymanie po każdej aktualizacji ich programu i zero wartości dla księgowej, która i tak importuje plik.
Dlatego BusiKM ma generatory plików dla trzech programów i od 3 października czwarty format: uniwersalny XLSX, który da się wczytać w każdym programie, także takim, o którym nie słyszałem.
Co wyleciało z kodu
Zasada w planie nic nie zmienia, dopóki kod dalej robi co innego. W kolejnych tygodniach przeszła przez kod krok po kroku:
Dzień przed tym, 30 sierpnia, usunąłem program pilotażowy. Największą zmianą było jednak usunięcie modułu biura rachunkowego 1 września. PR, który to robił, zmienił 194 pliki i usunął 14 116 linii. Zniknęły modele biura i jego zaproszeń, przełączanie między firmami klientów i nagłówek, przez który backend wiedział, w kontekście której firmy działa księgowa z biura. Rola księgowej została, ale teraz jest przypięta do firmy klienta: jedno konto to jedna firma. Obsługa wielu firm przez jedną księgową jest zaplanowana dopiero po MVP.
4 października zestawienie płacowe przestało liczyć składki i podatek. Zostały dane wejściowe dla programu płacowego: czas pracy, dni za granicą per kraj, diety, zaliczki i kilometry. O tym, jak liczę dni za granicą z punktów GPS, pisałem w poście o granicach państw offline.
Gdzie granica jest cienka
Najtrudniej jest tam, gdzie dane i podatki się stykają. 12 października doszły oznaczenia potrzebne do JPK_V7 na fakturach: numer KSeF albo jedno z oznaczeń dla faktur wystawionych poza KSeF, oraz plik JPK_FA(4) zgodny ze schematem Ministerstwa Finansów. To wygląda jak księgowość, ale nią nie jest. BusiKM nie składa deklaracji JPK_V7. Dba tylko o to, żeby faktura miała komplet oznaczeń, z których program księgowej tę deklarację zbuduje. JPK_FA to plik z fakturami, który firma przekazuje urzędowi na żądanie, a faktury powstają właśnie w BusiKM.
Na tej samej granicy leżą daty. Faktura z datą sprzedaży w złym miesiącu trafia do złej deklaracji, dlatego o datach liczonych w czasie polskim pisałem osobno w poście o date.today(). Dane mają być poprawne, bo program księgowej im ufa.
Ile to kosztuje
Rezygnacja z zakresu ma swoją cenę. Klient, który szuka jednego programu do wszystkiego, nie znajdzie go w BusiKM i wybierze kogoś innego. Osobny moduł dla biur rachunkowych zniknął, mimo że już działał, i biuro może dziś pracować w BusiKM tylko jako księgowa przypięta do jednej firmy. Usunięcie 14 tysięcy linii to też przyznanie, że praca z wiosny poszła w kierunku, z którego się wycofałem.
W zamian produkt ma jedną, czytelną obietnicę: dane z transportu trafiają do księgowej poprawne i w jej formacie. Każdą nową funkcję mogę sprawdzić jednym pytaniem: czy to dane transportowe, czy już księgowość. Ta sama tabela, która stoi w planie, jest najprostszym sposobem, żeby pokazać klientowi, co dostanie, a co dalej robi jego księgowa i dlaczego tak jest lepiej dla obu stron.
Jeśli budujesz SaaS, spróbuj zapisać granicę swojego produktu w jednym zdaniu, zanim zaczniesz kolejną funkcję. Jeśli chcesz porozmawiać o zakresie swojego MVP, napisz do mnie.
