System biura rachunkowego: cztery rzeczy, które muszą w nim być, zanim jakakolwiek automatyzacja się przyjmie

Wąskie gardło, które wczorajszy wpis nazwał i zostawił

Biuro rachunkowe prawie nigdy nie integruje się z ERP klienta. Integruje się z kanałami, przez które dokumenty i tak muszą przejść, a od obowiązku KSeF większość przechodzi przez jeden. Tak brzmiał wczorajszy wpis i nic w nim nie odwołuję. Zostawił jednak coś wiszącego w powietrzu: te kanały muszą gdzieś dostarczać. Pobranie z KSeF, wyciąg z banku, skrzynka pocztowa kończą w tym samym miejscu, w systemie biura. I to tam widziałem więcej zatrzymanych projektów automatyzacji niż po stronie wszystkich klientów razem wziętych.

Schemat powtarza się na tyle wiernie, że umiem go opowiedzieć jeszcze przed spotkaniem startowym. Biuro kupuje albo buduje coś, co pobiera dokumenty, dopasowuje linie wyciągu, przygotowuje dekretacje. Konektor działa od pierwszego dnia, wszyscy zadowoleni. Potem agent zadaje systemowi biura pytanie, na które system nie umie odpowiedzieć, albo próbuje odłożyć wynik w miejsce, którego po prostu nie ma. Kilka tygodni później projekt po cichu zamienia się z powrotem w człowieka z arkuszem.

Nikt nie nazywa tego porażką, bo nic się nie zepsuło. System nigdy nie był ustawiony jako strona dla pracy automatycznej. Był ustawiony pod ludzi, którzy brakujący kontekst noszą w głowach.

Ten wpis jest o tym, co system biura musi umieć, zanim którykolwiek z poprzednich tekstów tej serii w ogóle zacznie działać. To nie jest porównanie programów. Każdy produkt na polskim rynku to potrafi. Prawie żadne biuro nie ustawiło swojego tak, żeby potrafił.

Czterdziestu klientów, czterdzieści baz

Zacznijmy od faktu, który zaskakuje każdego, kto nigdy nie siedział w biurze od środka: popularne polskie systemy trzymają jedną bazę na firmę. Comarch ERP Optima tak. enova365 tak. Linia InsERT tak. Dla firmy z jednymi księgami to rozsądny projekt. Dla biura z czterdziestoma klientami oznacza czterdzieści baz, a w każdej własne kartoteki kontrahentów, własny plan kont, własne ustawienia, własny stan wersji.

Moduły dla biur zasłaniają to przed człowiekiem. Biuro Rachunkowe w Optimie daje listę firm, przełączanie, operacje seryjne i listy kontrolne w poprzek baz. enova365 ma narzędzia wielofirmowe i portal klienta na wierzchu. Człowiek siedzi w jednym interfejsie i nie czuje szwów.

Agent czuje każdy.

Każda baza to osobne połączenie z osobnymi danymi dostępowymi, więc pytanie o konto serwisowe nie pada raz, tylko czterdzieści razy, a w Optimie każda z tych sesji zajmuje licencję operatora. Każda baza mogła być aktualizowana innego dnia, więc dryf pól własnych, który opisywałem jako pięciominutową akcję jednego administratora, robi się czterdziestoma administratorami, a kilku z nich to młodsi pracownicy samego biura. I każda baza od lat przyjmowała dane od tego, kto akurat obsługiwał danego klienta, bez żadnej kontroli względem pozostałych trzydziestu dziewięciu.

Architektury nie zmienicie. Możecie za to przestać udawać, że biuro to jeden system. Do wyceny, do dostępów, do monitoringu biuro jest portfelem małych instalacji, które łączy wspólny ekran logowania. Reszta tego tekstu z tego wynika.

Cztery pytania, na które system musi odpowiedzieć o każdym dokumencie

Test, który robię teraz przed każdą wyceną, wygląda tak. Bierzecie dokument, dowolny, który przyszedł w zeszłym tygodniu. Patrzycie wyłącznie na to, co pokazuje system, bez pytania kolegi z sąsiedniego biurka, i odpowiadacie na cztery pytania.

Czyj jest? Który klient, która baza. Oczywiste dla faktury z KSeF, bo NIP siedzi w strukturze. Nieoczywiste dla zdjęcia, które żona klienta przesłała z prywatnej skrzynki, dla skanu z uciętym nagłówkiem, dla faktury od dostawcy, który obsługuje trzech Waszych klientów naraz.

Gdzie jest? Fizyczne albo cyfrowe miejsce w tej chwili. W platformie do obiegu, w skrzynce, w buforze, w księgach, w folderze na czyimś pulpicie o nazwie „do wyjaśnienia". W większości biur co najmniej dwa z tych miejsc leżą całkowicie poza systemem księgowym, więc odpowiedź systemu brzmi „nie ma", a to nie to samo co „nie istnieje".

W jakim jest stanie? Przyjęty, zidentyfikowany, zapytany, zaksięgowany, odrzucony, czeka na klienta. Jeśli jedyne stany, jakie zna Wasz system, to „brak" i „zaksięgowane", wszystko pomiędzy mieszka w czyjejś pamięci.

Kto go ostatnio dotykał? Nie po to, żeby kogoś winić. Po to, żeby przekazać robotę dalej. Osoba, która odłożyła dokument we wtorek, bo stawka VAT wyglądała podejrzanie, w czwartek ma wolne, a dokument jest teraz niczyj.

Kiedy robię to na dwudziestu losowych dokumentach w biurze, które nigdy o tym nie myślało, liczba pytań bez odpowiedzi wypada między piętnaście a trzydzieści na osiemdziesiąt. To nie jest zarzut wobec zespołu. To opis tego, gdzie naprawdę mieszka proces: w ludziach, nie w systemie.

A agent pracuje wyłącznie na tym, co system trzyma. Piętą achillesową biura nie jest ERP klienta. Jest nią te dwadzieścia pięć procent procesu, które nie ma reprezentacji nigdzie, gdzie maszyna mogłaby ją odczytać.

Stan między „nie ma" a „zaksięgowane"

Z czterech pytań trzecie jest tym, w którym automatyzacja naprawdę się podłącza. Dlatego dostaje osobną sekcję.

I Optima, i enova365 mają stan dla dokumentu, który istnieje, ale nie został jeszcze zaksięgowany. Optima nazywa to buforem i pisałem już, dlaczego agent powinien się na nim zatrzymywać; enova365 ma własne stany dokumentów o tym samym skutku. Większość biur, które odwiedzam, używa tego na jeden z dwóch sposobów. Albo wcale, bo księgowanie od razu jest szybsze, a sprawdzający to ta sama osoba co księgujący. Albo jako parkingu dla problemów, bez reguły, co tam trafia i kiedy stamtąd wychodzi.

Agentowi potrzebny jest bufor jako obieg, nie jako parking. Wszystko, co agent wytwarza, proponowana dekretacja, dopasowana linia wyciągu, dokument przypisany do klienta, oflagowany duplikat, musi lądować w stanie, który jest widoczny, do przejrzenia i jeszcze nieostateczny. To drugi z czterech poziomów uprawnień, proponuj zamiast zapisuj, przełożony na konkretne miejsce w konkretnym systemie. Bez niego zostają dwa scenariusze, oba złe: agent pisze do ksiąg i biuro musi mu ufać w pełni od pierwszego dnia, albo agent pisze do bocznej tabeli i nikt tam nigdy nie zagląda.

Stąd pytanie do odpowiedzenia jeszcze przed pierwszą linijką integracji. Jaki udział dokumentów z zeszłego miesiąca w ogóle przeszedł przez bufor? Jeśli poniżej dziesięciu procent, pierwszy miesiąc projektu to nie konektor. To zmiana sposobu księgowania, żeby stan „do przejrzenia" w ogóle istniał i agent miał co wypełniać.

Przy okazji naprawia się coś jeszcze. Kiedy bufor staje się prawdziwym stanem, udział dokumentów w systemie do 10. przestaje być liczbą, którą szacujecie na oko, i staje się liczbą, którą system raportuje.

Jeden dostawca, czterdzieści pisowni

Teraz kartoteki kontrahentów. Tu problem czterdziestu baz robi największe szkody i tu prawie nikt nie zagląda.

Weźcie trzech dostawców, którzy pojawiają się na największej liczbie faktur w całym portfelu. Operator kart paliwowych, telekom, sieć z artykułami biurowymi. Każdy istnieje raz w rzeczywistości i raz w KSeF. W Waszym biurze istnieje raz na każdą bazę klienta, która kiedykolwiek dostała od niego fakturę, wpisany przez tę osobę, która akurat w tamtym miesiącu obsługiwała klienta. Wyeksportujcie listę kontrahentów z pięciu największych baz i policzcie. W biurach, w których to robiłem, ten sam telekom występował w trzech do siedmiu różnych pisowniach na pięć baz. I to zanim dojdziemy do kartotek bez NIP-u, z NIP-em z literówką albo do tej założonej na nazwisko handlowca.

Dla człowieka to drobna irytacja. Dla dopasowywania to wyrok, bo i rozliczanie wyciągów, i przypisywanie faktur działają na kontrahencie jako kluczu łączącym. Agent szuka dostawcy po NIP-ie, znajduje trzy kartoteki i albo zgaduje, albo staje. Każde zatrzymanie to dokument z powrotem w kolejce człowieka.

Naprawa jest nieefektowna i należy do biura, nie do dostawcy oprogramowania: jedna kanoniczna kartoteka na NIP na bazę, duplikaty scalone, numer rachunku bankowego uzupełniony z ostatniej faktury. W biurze z czterdziestoma klientami to tydzień pracy młodszego pracownika. Przesuwa odsetek dokumentów przechodzących bez poprawek bardziej niż jakikolwiek wybór modelu. To dokładnie ten sam wniosek co z audytu pola opisu we wpisie o wyciągach: sufit wyznaczają dane, które biuro już ma, a nie oprogramowanie, które ktoś zamierza kupić.

Droga powrotna do klienta

Czwarta rzecz, którą system musi umieć, jest tą, której nikt nie wymienia, bo wskazuje na zewnątrz. Każda automatyzacja, która wykrywa brakujący dokument, złą stawkę VAT, fakturę bez zamówienia za nią, produkuje pytanie do klienta. Gdzie to pytanie idzie?

W większości biur mailem, pisanym ręcznie, przez tego, kto zauważył. Czasem telefonem. Czasem czeka na comiesięczną rozmowę. Klient odpowiada albo nie, a odpowiedź ląduje w skrzynce, której system nie widzi.

Jeśli pytania generuje agent, biuro potrzebuje kanału, którego agent może użyć bez człowieka przy klawiaturze, a odpowiedź klienta musi wrócić do dokumentu, którego dotyczy. Portale klienta przy Optimie, enova365 i platformach do obiegu istnieją dokładnie po to. Większość jest wyłączona albo włączona dla trzech klientów w ramach testu sprzed dwóch lat. Tu też w praktyce mieszkają uprawnienia KSeF: każdy klient musi nadać biuru prawo do pobierania swoich faktur, a biuro z czterdziestoma klientami ma czterdzieści uprawnień do zdobycia, zapisania i pilnowania. Kanał, który już dociera do każdego klienta, zamienia to w jedną wysyłkę. Bez niego to czterdzieści telefonów.

Nie automatyzujcie pytania, dopóki odpowiedź nie ma gdzie wylądować.

Dwugodzinny test gotowości

Nic z tego nie wymaga konsultanta. Trzy ćwiczenia, dwie godziny, do zrobienia przez samo biuro.

1. Dwadzieścia dokumentów, cztery pytania. Losowe dokumenty z zeszłego tygodnia, odpowiedzi wyłącznie na podstawie systemu. Policzcie te bez odpowiedzi. Powyżej jednej czwartej znaczy, że proces mieszka w ludziach.
2. Trzech dostawców, pięć baz. Wyeksportujcie listy kontrahentów, policzcie, ile razy występuje każdy z trzech najczęstszych dostawców. Podzielcie przez pięć. Wszystko powyżej jedynki to wskaźnik duplikatów, z którym będziecie walczyć.
3. Udział bufora w zeszłym miesiącu. Jaka część dokumentów przeszła przez stan „do przejrzenia” przed zaksięgowaniem? Poniżej dziesięciu procent znaczy, że propozycje agenta nie mają gdzie trafić.

Każde ćwiczenie daje jedną liczbę. Każda mówi, gdzie muszą pójść pierwsze tygodnie projektu, zanim konektor zacznie cokolwiek zarabiać. I każda przewiduje, czy automatyzacja się przyjmie, lepiej niż ERP klienta, demo dostawcy czy liczba osób w biurze. We wpisie o harmonogramie wdrożenia nazwałem opóźnienie dostępów najlepszym predyktorem startu produkcyjnego. Po stronie biura jego odpowiednikiem jest ten test.

Co to zmienia w kolejności prac

Wczorajsza inwentaryzacja mówi, które kanały zbudować i którzy dwaj albo trzej klienci uzasadniają konektor. Dzisiejszy test mówi, czy biuro jest w stanie przyjąć to, co te kanały dostarczą. Zróbcie dzisiejszy pierwszy. Kanały są tańszą częścią i tą, którą dostawcy chcą Wam sprzedać, bo działające pobieranie z KSeF wygląda jak postęp. Jest postępem tylko wtedy, gdy pobrane dokumenty lądują gdzieś, gdzie mają klienta, stan i właściciela.

Kolejność, która naprawdę zadziałała w każdym biurze, gdzie projekt się utrzymał: porządek w kartotekach i dyscyplina bufora w pierwszym miesiącu, bez żadnej automatyzacji; kanały KSeF i bankowy w drugim, zasilające bufor; pierwsze propozycje agenta w trzecim, przeglądane przez te same osoby, które wcześniej robiły to ręcznie. Tak właśnie wdrażam agentów AI dla firm i tak wygląda w praktyce integracja z enova365. Biura, które pominęły pierwszy miesiąc, wszystkie do niego wróciły. Później i z konektorem już pracującym na brudnych danych.

Prowadzicie biuro i nie wiecie, czy Wasz system przeszedłby cztery pytania? Napiszcie do mnie. Test gotowości zajmuje dwie godziny i nie widziałem jeszcze takiego, w którym wszystkie trzy liczby wyszły tam, gdzie powinny. Widziałem za to kilka, po których pierwszy miesiąc pracy był zupełnie jasny.