W tym artykule
Adam zadał mi pytanie, po którym zamilkłem na dłużej, niż wypada: „Nie rozumiem, co tu jest wow. Claude i tak wchodzi w ten kod i musi go przeanalizować. Więc co takiego zrobiła ta platforma?” To najlepsze pytanie, jakie usłyszałem przy pokazywaniu Open Mercato — i najbardziej niewygodne, bo dotyczy rzeczy, którą mam za oczywistą. A oczywista nie jest.
Ten wpis jest odpowiedzią na pytanie Adama, tylko rozłożoną na części. To nie lista najładniejszych funkcji, tylko pięć rzeczy, które najczęściej rozstrzygają rozmowę — plus szósta, moduł magazynowy, który doszedł dosłownie w trakcie nagrywania materiału o tej platformie. Celowo piszę „rzeczy”, a nie „moduły”: jedna z tych pięciu w ogóle nie jest modułem i właśnie ona odpowiada Adamowi. Przy każdej piszę też, czego nie robi, bo demo bez tej części to nie demo, tylko reklama.
Jak wygląda takie demo
Zasadę mam jedną i trzymam się jej od dawna: nie pokazuję pustego systemu. Przed spotkaniem wrzucam do niego kilka realnych nazw z firmy klienta — jego produkty, jego statusy, jego działy. Dwadzieścia minut roboty, a różnica jest taka, że zamiast oceniać narzędzie, ludzie zaczynają w nim pracować na sucho i sami znajdują to, czego im brakuje.
Druga zasada: pokazuję kolejność, nie zestaw ikon. Najpierw dane, potem to, kto co widzi, potem to, co dzieje się samo, a dopiero na końcu rzeczy ładne. W tej kolejności pierwsza piątka modułów układa się właściwie sama — i tak samo układa się potem wdrożenie.
Trzecia zasada wyszła z potknięć: nie każę nikomu patrzeć na wielkie moduły, tylko na szczegóły w środku. Duży system na pierwszym ekranie przytłacza — „o matko, ile tu opcji” słyszałem nie raz. Za to gdy pokażę historię zmian na karcie technicznej i zapytam, kto u nich ma prawo ją edytować, a kto tylko podejrzeć, rozmowa zmienia się z oceniania interfejsu na projektowanie własnej firmy. Wtedy pada zdanie, na które czekam: „tę tablicę i tę historię chcę u siebie”.
1. Własne pola i encje bez czekania na dewelopera
Moduł, który najczęściej kończy dyskusję „czy to się da dopasować do nas”. Z poziomu panelu dokładasz własne pole do istniejącego bytu — zamówienia, klienta, zlecenia — albo całą własną encję, i nie wymaga to wdrożenia nowej wersji systemu ani zgłoszenia do kogokolwiek. Dla kogoś, kto siedział w zamkniętym ERP, to brzmi podejrzanie: tam jedno dodatkowe pole potrafi być osobnym zleceniem na „rozwiązanie customowe”, wycenionym i odłożonym na kwartał.
Pod spodem definicje pól i ich wartości siedzą w osobnych tabelach, a warstwa zapytań umie po nich filtrować i je pokazywać. W praktyce znaczy to, że pole dodane w panelu jest obywatelem pierwszej kategorii: wchodzi na listę, do filtrów, do wyboru kolumn, do eksportu i do API. To cała różnica między „polem dodatkowym” a „polem, które da się rozliczyć”.
- 1
Słowniki zamiast list zaszytych w kodzie
Typy produktów, rodzaje materiału, działy, powody reklamacji — wszystko, co w narzędziach low-code ląduje na sztywno w rozwijanej liście. Tutaj zmiana oferty przestaje być zgłoszeniem do programisty i staje się pracą osoby, która tę ofertę zna.
- 2
Formularze, które pilnują sensu
Do pola dokładasz walidator i sposób wyświetlania. Dzięki temu „szerokość w centymetrach” zostaje liczbą, a nie polem tekstowym, w którym po roku znajdziesz „ok. 25” i „25-27”. Raport z takich danych jest wart tyle, ile najgorszy wpis w kolumnie.
- 3
Ten sam mechanizm dla każdego wdrożenia
Dopasowanie pod klienta nie jest forkiem kodu, tylko konfiguracją. To brzmi jak szczegół techniczny, dopóki nie przychodzi aktualizacja platformy — wtedy okazuje się, że to była najważniejsza decyzja architektoniczna w całym projekcie.
I teraz szczera obserwacja, której sprzedawca platformy nigdy nie powie: w momencie, w którym pada słowo „encja”, nietechniczny użytkownik uderza w mur. Techniczny wie, o co chodzi; reszta widzi tylko, że coś jest potężne i niezrozumiałe. Moc i zrozumiałość ciągną w przeciwne strony — im więcej platforma pozwala skonfigurować, tym łatwiej zgubić osobę, dla której to budujesz. Tu jest robota wdrożeniowca: przetłumaczyć „encję” na język klienta i ustawić to za niego, zamiast zostawiać mu surowy, potężny panel. Druga strona tej samej pułapki: możliwość dodania pola to nie to samo co decyzja, jakie pole dodać. Widziałem formularze z czterdziestoma polami, z których używano ośmiu — a pozostałe trzydzieści dwa skutecznie zniechęcały ludzi do wypełniania czegokolwiek.
2. Uprawnienia, organizacje i audyt — o co nikt nie prosi, a potrzebują wszyscy
Nikt nie umawia się na spotkanie, żeby obejrzeć system uprawnień. Ale kiedy u producenta ortez dziecięcych pokazałem, że technik na hali widzi kartę techniczną i pomiary, a nie widzi wywiadu medycznego ani telefonu do rodzica, rozmowa na dwadzieścia minut zmieniła temat. Z mojej strony wyglądało to tak, że włączyłem role i zespoły, nie grzebałem w konfiguracji i po prostu zadziałało — na zarządzaniu ludźmi wyszło z tego jakieś czterokrotne przyspieszenie względem tego, co ta sama firma miała wcześniej: własnego, ręcznie dłubanego panelu pracowników bez struktury zespołu. Cztery rzeczy, które za tym stoją:
- Każdy rekord zna swoją organizację i tenanta. To nie jest filtr dopisany do listy, tylko warstwa, przez którą przechodzi każde zapytanie i każde API. Firma z oddziałami dostaje drzewo organizacji, a nie kopię systemu na każdy oddział.
- Uprawnienia per rola i per osoba. Jedna osoba z wyjątkiem od reguły nie wymusza wymyślania nowej roli — a takie wyjątki są w każdej firmie, zwykle nazywają się imieniem i nazwiskiem.
- Kto, co i kiedy przestawił. W firmach przed wdrożeniem słyszę zawsze ten sam zestaw zdań: „a dlaczego to poszło”, „ja tego nie widziałem”, „kto to zmienił”. To pytanie pada w najgorszym możliwym momencie, a system, który nie umie na nie odpowiedzieć, jest w wewnętrznym sporze bezużyteczny.
- Szyfrowanie wrażliwych pól w spoczynku. Przy danych medycznych to nie jest opcja, tylko warunek wejścia. To jedyny moduł z tej piątki, o którym klient czasem mówi wprost: „tego akurat potrzebuję na wczoraj”.
Jak to wygląda na realnych danych osobowych — role, minimalizacja danych i tablet na hali produkcyjnej — opisałem w case study systemu dla producenta ortez. Ciekawostka z tamtego wdrożenia: to klientka zawęziła dostęp technikom, nie my. Dobry system uprawnień poznaje się po tym, że pozwala właścicielowi firmy podjąć taką decyzję samodzielnie.
A teraz rzecz, która zmienia rozmowę o pieniądzach. Uprawnienia i dziennik zmian to z perspektywy programisty najtrudniejsza i najnudniejsza część każdego systemu — dlatego w narzędziach, z których migrują nasi klienci, zaawansowane uprawnienia i audyt siedzą w najdroższym pakiecie. Otwierasz cennik, przewijasz do kolumny „Enterprise” i tam je znajdujesz. Tutaj to jest fundament, nie dopłata — i to jest różnica, którą widać dopiero w rachunku za drugi rok.
3. Workflow i reguły biznesowe — moment, w którym system zaczyna pracować sam
Do tej pory pokazywałem ekrany. Tutaj pokazuję, że po zmianie statusu dzieje się coś bez udziału człowieka: leci powiadomienie, tworzy się zadanie, zamówienie rezerwuje towar, planista dostaje nową pozycję na tablicy. Pod spodem to zdarzenia domenowe i subskrybenci, którzy przetwarzają je trwale, z kolejką — a nie „przy okazji” w trakcie zapisywania formularza.
Różnica wobec scenariusza w Make czy n8n jest czysto praktyczna: reguła siedzi tam, gdzie są dane. Nie płacisz od liczby operacji, nie utrzymujesz sklejki na zewnątrz i nie tłumaczysz sobie rano, dlaczego scenariusz stanął o trzeciej w nocy. To nie znaczy, że Make jest zły — do łączenia różnych systemów bywa najlepszym możliwym wyborem. Znaczy tylko, że proces wewnątrz jednego systemu to nie jest jego warstwa.
I szczera granica, której fani klikania nie mówią: jak nawalisz za dużo klocków, przepływ robi się nieczytelny i trudny do utrzymania. Proste rzeczy wyklikujesz i to jest ogromna wartość, bo osoba nietechniczna widzi logikę i sama ją przestawia. Skomplikowane schodzą piętro niżej, do kodu — ale bez przesiadki na inne narzędzie, w tym samym systemie i na tych samych danych. Do tego dochodzi rzecz, którą docenia się dopiero po roku: platforma wymusza pisanie testów. W narzędziu low-code nie możesz zepsuć testów, bo ich po prostu nie ma — i dowiadujesz się o zepsuciu od użytkownika.
4. AI jest tu w dwóch miejscach — i tylko jedno z nich to moduł
Tu wracamy do pytania Adama — i tu muszę rozdzielić dwie rzeczy, które łatwo zlepić w jedno, bo obie nazywa się „AI w Open Mercato”. Pierwsza nie jest modułem i nie ma jej w żadnym menu: to sposób, w jaki platforma prowadzi programistę i jego asystenta przy budowaniu systemu. Druga jest zwykłym modułem, który użytkownik widzi i klika. Zacznę od tej pierwszej, bo to ona odpowiada na „co takiego zrobiła ta platforma”.
Mechanizm jest prosty. Puść zwykłego asystenta AI na duży projekt, a zacznie chodzić wszędzie, otwierać każdy plik, gubić się i robić rzeczy, o które nikt nie prosił. Tutaj tego nie robi, bo platforma ma własny katalog instrukcji, specyfikacji i wyspecjalizowanych agentów. Mówię o tym zawsze tak samo: ja go tam nie wpuszczam — on wie, że ma tam wejść, bo tak zbudowano tę platformę. W praktyce zanim powstanie kod, pomysł przechodzi przez sito: rozbicie na problem biznesowy, reguły biznesowe i dopiero specyfikację techniczną, pytania o aktorów, stany i przejścia, koszt problemu w liczbach, słownik pojęć, a na końcu checklisty — bezpieczeństwo, wydajność, uprawnienia, ryzyko. Kiedyś to wszystko musiał spamiętać programista.
Efekt tego rusztowania jest policzalny: przy dobrze zrobionej specyfikacji trafność pierwszej wersji modułu to moim zdaniem 70–90%, a nie „coś, co wygląda podobnie do tego, co chciałem”. I to jest właściwa odpowiedź na pytanie Adama: platforma nie dała mi lepszego modelu, tylko miejsce, w którym model nie ma jak się zgubić.
Druga połowa tej samej historii to już zwykły moduł, czyli coś, co użytkownik widzi i klika. Asystent działa wewnątrz systemu, na tych samych danych co zalogowana osoba i — co ważniejsze — z jej uprawnieniami. Nie odpowie handlowcowi na pytanie o dane, do których handlowiec nie ma dostępu, i nie jest osobnym czatem obok, do którego trzeba kopiować rekordy.
Umie też wykonać akcję, a nie tylko podsumować: założyć rekord, przypisać zlecenie, uzupełnić brakujące pole, wyciągnąć dane z maila i wrzucić je we właściwe miejsce. Na demo pokazuję to na czymś banalnym — poproszeniu o zestawienie, którego nie ma w żadnym raporcie — bo najlepiej widać wtedy, że asystent chodzi po strukturze systemu, a nie po jego zrzutach ekranu.
I uczciwie: to moduł, który na demo robi największe wrażenie, a najczęściej rozczarowuje w trzecim miesiącu. Powód nigdy nie leży w modelu — asystent po prostu nie ma po czym chodzić. Jeśli jeden status oznacza dwie różne rzeczy naraz, a połowa wiedzy firmy siedzi w arkuszu na czyimś pulpicie, AI odziedziczy dokładnie ten bałagan i poda ci go pewnym tonem. Dlatego w tym zestawieniu stoi na czwartym miejscu, a nie na pierwszym.
5. Portal klienta i partnera — najprostsza rzecz o największym efekcie
U producenta sprzętu wellness wyglądało to tak: dystrybutorzy dzwonili z pytaniem „na jakim etapie jest moje zamówienie”, a odpowiadał na to jeden z dwóch współwłaścicieli, z dowolnego miejsca na świecie i o dowolnej porze. Portal to ten sam system i te same dane, tylko inny widok i inne uprawnienia — klient loguje się i widzi swoje zamówienia, dokumenty i statusy. Zero synchronizacji, zero drugiego źródła prawdy.
To także najłatwiejszy moduł do policzenia przed wdrożeniem: dziesięć telefonów dziennie razy kwadrans to pół etatu, którego nikt nigdy nie zaplanował. A przy okazji zmienia pozycję firmy — producent, który daje partnerom podgląd zleceń, przestaje być anonimowym podwykonawcą i staje się dostawcą, który ma system. To argument, który u moich klientów działał w rozmowach handlowych mocniej niż jakakolwiek oszczędność.
Ta sama mechanika ratuje wdrożenia w drugą stronę, do środka firmy. Najczęstszy powód, dla którego ludzie nie korzystają z systemu, to nie brak funkcji, tylko ich nadmiar: ktoś robi jedną powtarzalną rzecz, a dostaje ekran z czterdziestoma polami, na którym musi znaleźć jeden przycisk. Technik na hali dostaje u nas widok, na którym są jego zlecenia, jego kalendarz i dwie akcje, których używa w dziewięciu przypadkach na dziesięć. Dlatego na warsztatach mówię zawsze to samo: przyprowadź tę osobę i pokaż, co robi naprawdę — zrobimy ekran pod nią, a nie pod schemat systemu.
Szósta rzecz, która doszła w trakcie pisania: moduł WMS
Ten akapit powstał w dziwnych okolicznościach. Nagrywałem materiał o tej platformie, przygotowałem demo — a w trakcie obróbki okazało się, że pod spodem doszedł kolejny moduł: WMS. Czekałem na niego od miesięcy, bo do tej pory magazyn był tym miejscem w demo, w którym musiałem powiedzieć „to dobudujemy”. A u producenta czy w hurtowni magazyn nie jest dodatkiem do procesu — jest procesem. Tempo, w jakim ta platforma dokłada moduły, jest zresztą osobną historią: demo nagrane w poniedziałek bywa nieaktualne w piątek.
- 1
Magazyn dostaje mapę
Strefy, regały, adresy lokalizacji i stan liczony per lokalizacja, a nie jedną liczbą na cały magazyn. Tam, gdzie to ma znaczenie — spożywka, kosmetyki, chemia — dochodzą partie i daty przydatności wraz z podglądem tego, co się właśnie kończy.
- 2
Sprzedaż widzi magazyn
Na zamówieniu widać dostępność w rozbiciu na magazyny, rezerwacja powstaje przy potwierdzeniu, a zwalnia się przy anulowaniu. Braku towaru nie zgłasza klient telefonem — widać go na karcie zamówienia, zanim ktokolwiek zadzwoni.
- 3
Przyjęcie, odłożenie, korekta
Przyjęcie z dokumentem i obsługą rozbieżności, odłożenie towaru na docelową lokalizację i uproszczona inwentaryzacja w trzech krokach: policz, zobacz różnicę, zaksięguj. Do tego korekty stanu robione z panelu, a nie plikiem CSV przez informatyka.
I teraz część, której nie usłyszysz w prezentacji producenta: to jest młody moduł. Plan na najbliższy kwartał celuje w domkniętą pętlę „przyjmij, odłóż, stan się zgadza” plus minimalną, ale realną integrację ze sprzedażą. Świadomie zostaje poza nim pełna kompletacja falowa z optymalizacją tras, pakowanie z produkcyjną integracją kurierską, śledzenie partii i numerów seryjnych na poziomie zgodności regulacyjnej oraz bogate reguły wyboru magazynu.
Czego żadna z tych rzeczy nie załatwi
Ta część zwykle wypada z prezentacji, a jest w niej najwięcej prawdy o tym, jak wygląda wdrożenie. Trzy rzeczy, których nie kupisz razem z modułem:
- Nie zastąpią rozpoznania procesu. W ostatnim dużym wdrożeniu discovery trwał dłużej niż zbudowanie pierwszych trzech modułów: sześciogodzinny warsztat, około sześćdziesięciu pytań i przejście z kartką całej drogi zamówienia — od handlowca, przez administrację i produkcję, po osobę, która pakuje, wysyła i wystawia dokumenty. Nie dlatego, że coś poszło źle, tylko dlatego, że przez rok pracy w narzędziu low-code nikt w firmie nie musiał tego procesu nazwać. Ta wygoda wraca z odsetkami przy przeprowadzce.
- Nie wciągną za ciebie ludzi do procesu. Wniosek, który wypowiedzieliśmy z Adamem po jednym z wdrożeń, brzmiał brutalnie: nie da się polegać w stu procentach na właścicielu firmy. Model materiałów zbudowany na wiedzy właścicielki wymagał przeprojektowania w tydzień po tym, jak do systemu weszli technicy z hali i pokazali, że kluczowy wymiar znany jest w zupełnie innym momencie procesu. Bierz kolejne osoby do rozmowy wcześniej, niż wydaje ci się to potrzebne.
- Nie zdejmą kosztu utrzymania. Rdzeń jest na licencji MIT i nie ma opłat od użytkownika, ale system musi gdzieś stać, ktoś musi robić aktualizacje i wiedzieć, czego nie ruszać. W abonamencie płacisz właśnie za to, że robi to dostawca. Bez choćby jednej osoby technicznej to się nie uda — i tu dobra wiadomość jest taka, że jedna wystarczy: to nie jest platforma wymagająca zespołu, ale nie jest też narzędziem, które właściciel firmy obsłuży sam z panelu.
- Nie wybaczą modyfikowania rdzenia. Kod jest twój i możesz w nim zmienić wszystko — ale jeśli nadpiszesz moduł rdzeniowy zamiast rozszerzyć go w przewidziany sposób, to zapłacisz za to przy pierwszej aktualizacji. Ironia jest taka, że aktualizację najczęściej robisz po to, żeby wziąć nowy moduł (na przykład magazynowy) — i wtedy okazuje się, że twoja własna zmiana sprzed pół roku przestała działać.
Jest też czwarta rzecz, mniej oczywista: moduł, którego nie włączysz, nie kosztuje, ale też nic nie daje. Widziałem wdrożenia, w których świetny mechanizm uprawnień leżał nieużywany przez pół roku, bo nikt nie miał czasu usiąść i rozpisać, kto właściwie ma co widzieć. Godzina takiej rozmowy zwraca się szybciej niż jakakolwiek funkcja z tej listy.
Co z tego wynika
Kolejność w tym zestawieniu nie jest przypadkowa — pokrywa się z kolejnością, w jakiej te rzeczy wchodzą we wdrożeniu. Najpierw dane, potem widoczność, potem ruch, a dopiero na końcu to, co dobrze wygląda na zdjęciach: asystent i portal. Magazyn wchodzi tam, gdzie firma faktycznie ma magazyn, i ani chwili wcześniej. Odwrotna kolejność też jest możliwa — kończy się systemem, który robi wrażenie na demo i nie jest używany w marcu. A jeśli mam podsumować te pięć rzeczy jednym zdaniem, to brzmi ono tak: to nie jest „mniej kodu”, tylko mniej decyzji podejmowanych od zera. W systemie, w którym lecą dane pacjentów albo pieniądze klientów, mniej decyzji od zera znaczy mniej miejsc, w których coś pójdzie nie tak.
Jeśli nie znasz jeszcze samej platformy, zacznij od wprowadzenia do Open Mercato albo po prostu wejdź na publiczne demo i poklikaj — z jednym zastrzeżeniem: na pierwszy rzut oka wyda ci się przytłaczające, więc nie patrz na liczbę modułów, tylko na szczegóły w środku. Jeśli siedzisz dziś w narzędziu wewnętrznym i zastanawiasz się, czy to już sufit — jest osobne porównanie z Retoolem. A jeśli wolisz zobaczyć to na konkretnej firmie, opisałem wdrożenie w szwalni, gdzie punktem wyjścia było pół roku w low-code.
Mateusz Kozłowski
Założyciel flowbiz · Ekspert automatyzacji procesów
Wdrażam automatyzacje, integracje i AI w średnich firmach na Pomorzu i w Kujawsko-Pomorskiem.
