Twój przypadek nie ma pola w żadnym formularzu
Prowizja liczona inaczej dla każdego dostawcy, warunek zwrotu, wyjątek dla jednego klienta. Ląduje w dodatkowej kolumnie, w notatce albo w mailu, a tylko jedna osoba wie, gdzie tego szukać.
Rozliczenie z dostawcą, którego towar stoi na Twojej półce. Wpłaty na kontener, który może się nie zapełnić. Umowa, w której jedno puste pole blokuje pieniądze. Takie procesy zwykle obsługuje arkusz i czyjaś pamięć. Buduję systemy, w których reguł pilnuje baza danych, a model dostaje tylko tę część pracy, przy której naprawdę pomaga.
Gotowe narzędzia projektuje się pod typowy przypadek. Twoja przewaga często leży dokładnie w tym, co typowe nie jest.
Prowizja liczona inaczej dla każdego dostawcy, warunek zwrotu, wyjątek dla jednego klienta. Ląduje w dodatkowej kolumnie, w notatce albo w mailu, a tylko jedna osoba wie, gdzie tego szukać.
Płacisz za system, który prowadzi proces do połowy. Druga połowa toczy się obok, w arkuszu i przez telefon, i zjada czas, który miał zostać zaoszczędzony.
Raport dla partnera powstaje z innych liczb niż te, których użyła kasa. Wiadomo tylko, że się różnią. Nie wiadomo, czyja arytmetyka jest błędna.
Na wniosku, umowie albo rozliczeniu puste pole nie wygląda jak szkic, tylko jak udzielona odpowiedź. Wychodzi to dopiero wtedy, gdy ktoś po drugiej stronie odrzuci dokument.
Procesu takiego jak Twój model najpewniej nigdy nie widział. Odpowiedź i tak brzmi przekonująco, a dotyczy Twoich pieniędzy i Twoich klientów.
Ta sama osoba sprzedaje, liczy towar i zamyka miesiąc. Pomyłki po długim dniu nie ma kto wyłapać, a zasada czterech oczu zostaje na papierze.
Nietypowy proces ma zwykle jedną rzecz, na której się zarabia, i kilka, na których można po cichu stracić. Zaczynam od spisania ich wszystkich, zanim powstanie pierwsza linijka kodu.
Zanim powstanie pierwsza linijka kodu, warto przepuścić specyfikację przez kilka rund recenzji, z założeniem za każdym razem, że dokument jest błędny. Taka recenzja wyłapuje reguły, które inaczej ujawniłyby się dopiero na produkcji, na przykład rozliczenie, które obciążyłoby dostawcę za jego własny towar. Te reguły potem pilnują testy, nie pamięć jednej osoby.
Gdy kupujący wpłacają depozyt za udział we wspólnym zamówieniu, a zamówienie może się nie zapełnić, zwrot powinien być automatycznym skutkiem zmiany stanu w systemie, a nie przelewem, o którym ktoś musi pamiętać. Nikt nie płaci dwa razy i żaden depozyt nie zostaje w zawieszeniu.
Umowę o dofinansowanie albo inny dokument z licznymi warunkami może składać system z danych zlecenia: szablon Word z jawnie przypisanymi polami, zamieniany na PDF. Brak wymaganego pola zatrzymuje generowanie, zamiast wypuścić dokument, który tylko wygląda na kompletny.
Automatyczne telefony o statusie zamówienia i SMS-y mogą iść same z procesu zamówień, po polsku i po angielsku. Tam, gdzie w rozmowie pracuje model, może wyłącznie sformułować zdanie i wybrać ścieżkę: każdą zmianę zamówienia i każdą wysyłkę wykonuje deterministyczny kod. Dwukierunkowy agent głosowy wymaga więcej dopracowania niż skrypt czytany przez syntezator, ale ta granica nie zmienia się od pierwszej wersji.
Gdy proces prowadzi osoba, której całym miejscem pracy jest arkusz Google, całe zaplecze może działać właśnie tam: wycena w panelu bocznym, akceptacja oferty jednym kliknięciem w linku z maila, faktura VAT w PDF na dysku i SMS wysyłany automatycznie. Nietypowy proces nie zawsze potrzebuje nowej platformy.
Budując system dla branży, której nie znam od środka, nie zgaduję zasad: to osoba pracująca w tym fachu definiuje, co jest poprawną odpowiedzią. Liczby w wycenie powinny wynikać z rzeczywistych, zamkniętych spraw, nie z oszacowania modelu. Swoją branżę znasz Ty: moja robota to zamienić tę wiedzę w reguły.
Kilka typowych zastosowań w tym obszarze. Twój proces może wyglądać inaczej, dlatego zaczynam od rozmowy o nim.
AI odczytuje dane z dokumentów, których nie da się opisać szablonem, a reguły je sprawdzają.
Wiadomości i zgłoszenia przypisywane do kategorii według tego, co w nich jest, nie według tematu maila.
Odpowiada z instrukcji i cenników firmy i podaje, skąd wziął odpowiedź.
Odbiera telefon, zbiera dane i umawia termin. Resztę przekazuje człowiekowi.
Wskazuje różnice między wersjami umowy albo ofertami kilku dostawców.
Opisy produktów przygotowane z danych technicznych, do zatwierdzenia przed publikacją.
Mechaniczne porównanie źródła z bazą, zanim ktokolwiek uzna przeniesienie za skończone.
Zaczynamy od tego, jak robicie to dziś, i sprawdzamy, która część opłaca się automatyzować.
Dokumenty tłumaczone z zachowaniem Waszej terminologii, do sprawdzenia przez człowieka przed wysyłką.
AI czyta wiadomość i proponuje zadanie z terminem, a Ty je zatwierdzasz jednym kliknięciem.
Cztery kroki. Pierwszy jest bezpłatny i często wystarcza, żeby wiedzieć, czy w ogóle jest o czym rozmawiać.
Rozmawiamy o jednym procesie: co się w nim dzieje, ile razy w miesiącu i gdzie ucieka czas. Jeśli nie ma tu czego automatyzować, powiem to na tej rozmowie.
Dostajesz proces opisany z zaznaczonymi miejscami strat, proponowany zakres, widełki kosztu i szacowany czas, razem z listą rzeczy, których nie warto ruszać.
Każdy etap kończy się czymś, co da się włączyć do pracy i ocenić w liczbach, zanim ruszy kolejny. Zamiast kwartału ciszy i jednego dużego uruchomienia.
Zespół uczy się na Waszych danych, dokumentacja i dostępy zostają po Waszej stronie. Jestem przy pierwszych nietypowych przypadkach, bo te pojawiają się po starcie, nie w dniu uruchomienia.
Zależy od tego, ile wyjątków ma proces i czy przechodzą przez niego pieniądze albo dokumenty dla kogoś z zewnątrz. Pierwsza rozmowa jest bezpłatna. Po obejrzeniu procesu dostajesz widełki dla swojego przypadku, a nie ofertę napisaną w ciemno.
Nie zakładam, że wiem. Uczę się z prawdziwych przypadków, nie z opisu procesu: siedzę przy sprawach, które akurat się pojawiają, i rozwiązuję problemy razem z osobą, która na co dzień wykonuje tę pracę, zamiast przeprowadzić jeden wywiad i zniknąć do kodu. To ona definiuje, co jest poprawną odpowiedzią. Ja wnoszę metodę i odpowiedzialność za to, żeby działało w produkcji.
Właśnie tam najłatwiej o pomyłkę, która brzmi pewnie. Dlatego model dostaje zadania, w których pomyłka nie przesuwa pieniędzy ani zamówień, czyli sformułowanie wiadomości i wybór ścieżki, a liczy, rozlicza i wysyła deterministyczny kod. Formalnego zestawu testów jakości modelu jeszcze nie mam i mówię to od razu.
Czasem tak, a wtedy mówię to wprost. Jeśli nietypowość wynika z przyzwyczajenia, taniej zmienić przyzwyczajenie i kupić gotowe narzędzie. Budować warto tam, gdzie na tej nietypowej części zarabiasz albo gdzie pomyłka kosztuje pieniądze. Czasem najlepszym systemem okazuje się arkusz ze skryptem.
Dostępu do danych pilnuje sama baza danych, a nie ukryty przycisk w aplikacji, więc handlowiec technicznie nie odczyta cudzych klientów. Klucze i hasła do usług są poza kodem. Każda zmiana, zanim trafi na produkcję, przechodzi automatyczne sprawdzenia, w tym skan pod kątem wycieku sekretów. Kod i dane zostają po Waszej stronie.
Tak, i zwykle tak to wygląda: zaczynamy od jednego procesu, a kolejne dochodzą etapami. Kod jest w Waszym repozytorium razem z dokumentacją, więc rozbudowę może zrobić też ktoś inny niż ja.
Trzydzieści minut wystarczy, żeby powiedzieć, czy jest tu co automatyzować. Jeśli nie ma, usłyszysz to wprost, zanim powstanie jakakolwiek oferta.
Bez zobowiązań. Bez oferty, zanim zrozumiem proces.
Zobacz, co już zbudowałem →albo napisz na hello@kamiljan.com · LinkedIn