Większość tekstów o „dodaniu AI do produktu” zaczyna się od AI. Ten zaczyna się od miejsca, w którym świadomie z niego zrezygnowaliśmy.
Partner zgłosił się do nas ze znajomym problemem: proces kluczowy dla biznesu, który wciąż działał niemal wyłącznie na arkuszach kalkulacyjnych. Dane napływały codziennie od szerokiej sieci zewnętrznych partnerów, każdy w swoim formacie, bez wspólnej struktury i bez wspólnego wglądu w to, na jakim etapie coś jest. Wąskim gardłem nie była sama praca, tylko ręczne koordynowanie jej.
To dokładnie ten typ problemu, wokół którego nasz zespół dedykowanych rozwiązań IT buduje dedykowane oprogramowanie: zastąpienie ręcznego procesu platformą, która importuje napływające dane, kieruje je do właściwych specjalistów wewnętrznych, śledzi status od początku do końca i daje wszystkim jeden, aktualny widok tego, co się dzieje.
Stos technologiczny narzucił partner, i to było w porządku. Angular na froncie, NestJS na backendzie, Microsoft SQL Server jako baza danych, wszystko dopasowane do tego, co znał i miał utrzymywać dalej niewielki wewnętrzny zespół techniczny partnera. Nasi programiści domyślnie wybraliby coś innego. To nie miało znaczenia. Zespół, który przejmuje to po nas, ma głos w tym, na czym to zbudowano, i to prosty kompromis: nasza krótkoterminowa preferencja kontra ich długoterminowa odpowiedzialność za utrzymanie.
Ciekawy problem nie był techniczny, tylko strukturalny. Każdy zewnętrzny partner eksportował dane inaczej. Inne nazwy kolumn, inny układ, inne konwencje dla tych samych informacji. Zanim jakikolwiek specjalista wewnętrzny mógł zająć się sprawą, ktoś musiał ręcznie przekształcić plik do spójnej postaci. Ten etap przeformatowywania był głównie narzutem operacyjnym: nie wymagał tej oceny merytorycznej, dla której potrzebni byli specjaliści, ale był żmudną, podatną na błędy pracą stojącą między napływem danych a właściwą analizą.
To jedyne miejsce, w którym użyliśmy AI. Odpowiada za import i mapuje napływające pliki do spójnej struktury wewnętrznej, nawet jeśli arkusze źródłowe różnią się układem, nazwami kolumn lub konwencjami. Niepewne mapowania są flagowane do weryfikacji przez człowieka, zamiast być akceptowane automatycznie. Zakres tego, co robi AI, jest celowo wąski: normalizacja formatu, nie podejmowanie decyzji. AI nie podejmuje ani nie zatwierdza ocen merytorycznych, które następują potem. Te zostają po stronie specjalistów partnera. W procesie, w którym błędna decyzja może mieć bezpośrednią konsekwencję finansową lub zgodnościową, AI jest przydatne do przygotowania uporządkowanych danych wejściowych, nie do zastępowania odpowiedzialnej decyzji człowieka. Do tej granicy nasz zespół AI Development wraca właściwie przy każdym regulowanym lub obarczonym wysoką stawką projekcie.
Reszta platformy to dokładnie to, czego można się spodziewać po dobrze zbudowanym narzędziu wewnętrznym: kolejka do przydzielania pracy w zespole, śledzenie statusu, na którym faktycznie można polegać, i wbudowana komunikacja przypisana do każdej sprawy, żeby pytania nie ginęły w wątkach e-mail.
Praca z małym, szczupłym zespołem partnera zmienia sposób dostarczania projektu. Nie było czasu na czekanie między spotkaniami na szczegółowe specyfikacje, więc się o nie nie ubiegaliśmy. Partner dał nam ogólny, wysokopoziomowy brief i regularne cykle demo, a nasz dedykowany zespół podejmował decyzje UX i logiki biznesowej bezpośrednio, weryfikując je na żywo przy każdym demo. Taki model działa tylko z partnerem, który ufa zespołowi na tyle, by pozwolić mu szybko podejmować praktyczne decyzje produktowe, przy jednoczesnym lekkim zapisie kluczowych decyzji, feedbacku z demo i punktów akceptacji. Pozwolił poruszać się szybciej niż cięższy proces specyfikacja-akceptacja, bez utraty traceability potrzebnej do późniejszego utrzymania.
W rezultacie powstał proces, który wcześniej działał na rozproszonych arkuszach, a teraz działa na platformie z jednym jasnym widokiem operacyjnym, gdzie jedyne AI w pętli robi tę część pracy, której nikt nie chciał robić ręcznie.