Jeden rekord, trzy prawdy: czyli o formularzach w low-code'ach

Handlowiec otwiera kartę kontrahenta, bo chce sprawdzić, o czym rozmawiali miesiąc temu i czy jest szansa na dosprzedaż. Księgowa otwiera tę samą kartę, bo potrzebuje numeru konta, statusu VAT i historii płatności. Serwisant otwiera ją z telefonu na parkingu pod firmą klienta, bo chce wiedzieć jedno: jaki sprzęt tam stoi i co było przy nim robione ostatnio.

Trzy osoby, jeden rekord - i jeden formularz, zaprojektowany tak, żeby pomieścić potrzeby wszystkich.

Czyli niczyje.

Systemy nie umierają, bo nie działają

Przez lata wdrożeń ERP nauczyłem się jednej rzeczy: system prawie nigdy nie przegrywa na funkcjach. Przegrywa na ekranach.

Badania nad wdrożeniami automatyzacji pokazują to dość brutalnie. Kiedy użytkownicy zaczynają omijać system, wdrożenie jest porażką niezależnie od tego, czy technicznie wszystko działa. Powstają procesy-cienie: nieoficjalne obejścia, notatki na boku, arkusze „tylko dla naszego działu". Nieudane wdrożenia notują adopcję niższą o 40–60 procent od udanych - a niska adopcja nakręca spiralę: mniej użycia to mniej informacji zwrotnej, mniej informacji zwrotnej to brak poprawek, brak poprawek to jeszcze mniej użycia.

Excel obok systemu nie powstaje z lenistwa. Powstaje w dniu, w którym ktoś trzeci raz z rzędu scrolluje przez trzydzieści pól, żeby znaleźć jedno. Nikt nie ogłasza buntu. Ktoś po prostu zakłada arkusz „do pracy", bo tam ma to, czego potrzebuje, w kolejności, w jakiej tego potrzebuje. Pół roku później firma ma dwa źródła prawdy i zebranie, na którym pada pytanie, czemu dane w systemie się nie zgadzają.

Zgadzają się. Tylko nikt ich tam nie wpisuje.

Skąd się bierze formularz dla wszystkich

Nie biorę tego zjawiska z powietrza - sam takie formularze projektowałem. Mechanizm jest zawsze ten sam.

Przy wdrożeniu najwięcej uwagi dostaje model danych. I słusznie: pola, relacje, walidacje, to jest fundament. Problem w tym, że ekran powstaje potem jako pochodna modelu. Obiekt ma czterdzieści pól, więc formularz ma czterdzieści pól. Ktoś w trakcie analizy dorzucił „a przydałoby się jeszcze pole na uwagi transportowe" - i ono też ląduje na ekranie, dla wszystkich, na zawsze. Kompletność zaczyna udawać użyteczność.

Platformy low-code, paradoksalnie, ten problem pogłębiają. Skoro formularz się „wyklikał" i wygląda porządnie, łatwo uznać, że jest dobry. W analizach ograniczeń low-code powraca dokładnie ten wątek: wizualny edytor usypia czujność projektową, a aplikacje wychodzą funkcjonalnie kompletne i jednocześnie męczące w codziennym użyciu. Narzędzie przyspieszyło budowanie ekranu - ale nie zadało za nikogo pytania, kto i po co będzie na ten ekran patrzył.

A odpowiedź na to pytanie jest w każdej firmie taka sama: różni ludzie, po różne rzeczy.

Ekran to nie widok na bazę. To widok na czyjąś pracę

To jest odwrócenie, wokół którego zbudowaliśmy formularze w Opero: obiekt i formularz to dwie osobne rzeczy.

Obiekt - na przykład kontrahent albo zlecenie serwisowe - jest jeden. Ma swoje pola, relacje i walidacje, i to się nie zmienia. Ale formularzy na tym obiekcie może być wiele: osobne dla podglądu, edycji i tworzenia rekordu, przypisane konkretnym rolom. Handlowiec, księgowa i serwisant dostają trzy różne ekrany na ten sam rekord. Dane pozostają jedne.

Wróćmy do trójki z początku.

Handlowiec widzi na górze historię kontaktów, otwarte szanse sprzedaży i notatki z ostatnich rozmów. Sekcja finansowa? Jest, ale zwinięta na dole - czasem chce zerknąć, czy klient płaci w terminie, zanim zaproponuje większy kontrakt, więc nie ma powodu jej ukrywać. Ale nie musi się przez nią przebijać przy każdym otwarciu karty.

Księgowa widzi rachunki bankowe, status VAT, warunki płatności i listę nierozliczonych faktur. Historia rozmów handlowych jej nie obchodzi i na jej formularzu po prostu nie istnieje. Jej ekran do edycji pozwala poprawić dane rozliczeniowe - i tylko je, bo pola handlowe są na tym formularzu niedostępne do zapisu. To nie jest wyłącznie kwestia wygody. To też mniej okazji, żeby ktoś przypadkiem nadpisał coś, za co odpowiada inny dział.

Serwisant dostaje najkrótszy formularz z całej trójki: adres z nawigacją, osoba kontaktowa na miejscu, lista urządzeń i trzy ostatnie wizyty. Wszystko, co da się przeczytać w dwie minuty na telefonie, stojąc na parkingu. Reszta karty kontrahenta go nie dotyczy, więc jej nie ma.

Kluczowe jest to, że żadna z tych osób nie dostała „okrojonego widoku pełnego formularza". Każda dostała formularz zaprojektowany od jej pracy, nie od struktury tabeli.

Formularz, który reaguje

Osobne formularze per rola to pierwszy krok. Drugi to formularz, który reaguje na to, co się w nim dzieje.

W Opero każde pole i każda sekcja może mieć warunek widoczności. Sekcja danych do faktury pojawia się dopiero wtedy, gdy kontrahent jest oznaczony jako firma. Pole „powód reklamacji" istnieje tylko przy zgłoszeniu typu reklamacja. Formularz zaczyna się od kilku pytań i rozwija razem z odpowiedziami, zamiast witać użytkownika pełną ścianą pól, z których większość go dziś nie dotyczy.

To temat na osobny tekst, więc tutaj tylko go sygnalizuję. Ale mechanizm jest ten sam: ekran podąża za sytuacją, nie za schematem bazy.

Co ten mechanizm zmienia we wdrożeniu

Jest jeszcze jedna konsekwencja rozdzielenia obiektu od formularza, mniej oczywista, a dla mnie równie istotna: zmiana ekranu przestaje być zmianą systemu.

Kiedy formularz jest sztywno zszyty z modelem danych, każda korekta ekranu to ingerencja w coś, co działa na produkcji - więc nikt nie chce jej robić i formularze zastygają w kształcie z dnia wdrożenia, choć firma dawno pracuje inaczej. Kiedy formularz jest osobnym bytem, można go poprawić w tydzień po tym, jak księgowość zgłosi, że czegoś jej brakuje. A zgłosi - bo pierwsza wersja każdego formularza jest zgadywaniem. Różnica polega na tym, czy to zgadywanie da się tanio skorygować.

I tu wracam do badań z początku, bo jest w nich jeszcze jeden wynik, który mnie nie zaskoczył: zespoły najskuteczniej torpedują systemy, przy których projektowaniu nikt ich nie zapytał o zdanie. W jednym z opisywanych przypadków dział obsługi klienta dostał automatyczny routing zgłoszeń, uznał jego decyzje za słabe i wypracował własne, ręczne przekierowywanie - automatyzacja działała technicznie bez zarzutu i nie robiła nic. Formularze per rola niczego tu same nie załatwią. One tylko obniżają koszt reagowania na to, co ludzie powiedzą. Rozmawiać z nimi nadal trzeba.

Dobry ekran nie naprawi złego procesu

Żeby było jasne: nie twierdzę, że formularze rozwiązują wdrożenia. Jeśli w firmie nikt nie wie, kto zatwierdza zlecenie, trzy dopracowane ekrany tego nie zmienią. Proces trzeba najpierw ustalić - na papierze, w rozmowie, gdziekolwiek.

Ale odwrotność jest równie prawdziwa i dużo rzadziej wypowiadana na głos: zły ekran zabije nawet dobrze poukładany proces. Po prostu zrobi to wolniej i ciszej. Jednym Excelem na raz.

Dlatego kiedy oglądam wdrożenie - nasze czy cudze - nie zaczynam od listy funkcji. Zaczynam od pytania, jak wygląda ekran, który konkretna osoba widzi dwadzieścia razy dziennie. Bo to tam, a nie w silniku procesów, rozstrzyga się, czy system będzie używany.

Jeden rekord. Tyle prawd, ile osób z nim pracuje. System, który tego nie umie, będzie miał jedną prawdę w bazie i drugą - w arkuszach, których nigdy nie zobaczy.