Jak zaplanować PoC, żeby dał decyzję, a nie demo

Krótka odpowiedź: zanim zaczniesz PoC, spisz na jednej stronie pytanie, na które ma odpowiedzieć (tak albo nie), dane, na których ma pracować, próg, od którego wynik uznasz za wystarczający, i datę, po której podejmujesz decyzję niezależnie od tego, co pokaże. Jeśli którejś z tych czterech rzeczy nie da się spisać, to nie jest jeszcze czas na PoC, tylko na rozmowę.

Ten tekst pokazuje, jak te cztery pola wyglądają wypełnione, na jednym przykładzie od początku do końca.

Przykład: 500 umów, 6 pól, jedna decyzja

Przykład ilustracyjny. Firma i liczby są fikcyjne, ale policzone tak, jak liczy się je w prawdziwym PoC.

Firma leasingowa dostaje miesięcznie około 480 umów od pośredników, w PDF i w skanach. Trzy osoby przepisują z nich dane do systemu: numer umowy, NIP klienta, kwotę finansowania, okres, stawkę, datę pierwszej raty. Jedna umowa to średnio 6 minut pracy i nie każda przechodzi bez poprawki.

Pytanie do PoC nie brzmi “czy AI pomoże nam w obsłudze umów”. Brzmi tak:

Czy system odczyta 6 pól z 500 umów tak, że co najmniej 92 procent pól nie wymaga poprawki przez pracownika?

Tak postawione pytanie da się rozstrzygnąć. Reszta jednej strony:

Pole	Wartość w przykładzie
Pytanie	6 pól z 500 umów, co najmniej 92 procent pól bez poprawki
Dane	500 umów z ostatnich 3 miesięcy, w tym co najmniej 100 skanów i wszystkie 4 wzory umów w obiegu; wyciąg z systemu, bez dostępu do produkcji
Wzorzec	120 umów sprawdzonych ręcznie przez osobę, która robi to na co dzień (720 pól)
Próg	wdrażamy od 92 procent; nie wdrażamy poniżej 75; pomiędzy: wdrożenie z człowiekiem w pętli
Koszt sprawdzania	ile sekund zajmuje pracownikowi sprawdzenie jednej umowy z wynikiem systemu
Data	decyzja 6 tygodni od startu, na spotkaniu z jednym dokumentem

Co wyszło

System odczytał 3 000 pól (500 umów x 6). Po sprawdzeniu na wzorcu (720 pól): 634 pola bez poprawki, czyli 88 procent; 12 procent do poprawki. Wynik jest pod progiem wdrożenia (92) i nad progiem odrzucenia (75), czyli w strefie “wdrożenie z człowiekiem w pętli”.

Do tego liczba, która przesądza: sprawdzenie jednej umowy z wynikiem systemu zajęło pracownikowi średnio 40 sekund, wobec 6 minut ręcznego przepisania. Przy 480 umowach miesięcznie:

	Ręcznie	Z systemem i sprawdzaniem każdej umowy
Czas na umowę	6 min	40 s
Czas na 480 umów	48 godzin	5,3 godziny
Pola do poprawki	(błędy ręczne nieliczone w PoC)	12 procent, czyli około 350 pól miesięcznie

Decyzja na spotkaniu: wdrażamy z człowiekiem w pętli. Pracownik sprawdza każdą umowę na ekranie z podświetlonymi polami, a system oznacza pola, których nie jest pewien. Osobno zapisano, czego PoC nie sprawdził: integracji z systemem leasingowym, wolumenu z dwóch lat wstecz i pracy na umowach spoza czterech wzorów.

To jest wynik PoC, który daje decyzję. Ten sam PoC bez wzorca i bez progu skończyłby się zdaniem “wygląda obiecująco” i drugą iteracją bez daty końca.

Cztery pola, po kolei

Pytanie

Jedno pytanie, jeden proces, jedno wąskie gardło. Test: czy da się odpowiedzieć “tak” albo “nie”. “Czy narzędzie skraca czas obsługi reklamacji” nie jest pytaniem do PoC. “Czy narzędzie przygotuje projekt odpowiedzi na reklamację, który pracownik zaakceptuje bez poprawek w co najmniej 7 przypadkach na 10” jest.

Jeśli w rozmowie pojawia się drugi proces, zapisz go na listę na później. Dużo rzeczy zrobionych połowicznie nie da decyzji o żadnej z nich.

Dane

PoC pracuje na Twoich danych, z całym bałaganem: skany pod kątem, brakujące strony, trzy formaty tej samej faktury, pola wypełnione po swojemu przez trzy oddziały. W przykładzie wyżej próbka celowo zawiera co najmniej 100 skanów i wszystkie cztery wzory umów, bo wynik na samych “ładnych” PDF-ach nic nie mówi o produkcji.

Trzy rzeczy do ustalenia przed startem:

1. Kto wyciąga próbkę i kiedy. Ten krok łatwo nie doszacować, bo wymaga zgód, anonimizacji albo dostępu do systemu, którym zarządza ktoś inny.
2. Ile danych potrzeba. Nie cały rok, tylko tyle, żeby wynik był wiarygodny i żeby w próbce były przypadki trudne, nie tylko typowe.
3. Kto zna prawidłową odpowiedź. W przykładzie to 120 umów sprawdzonych ręcznie. Bez wzorca PoC kończy się opinią, nie wynikiem.

Dane osobowe w próbce to osobny wątek: co RODO i wytyczne organów mówią o pseudonimizacji i o umowie z dostawcą, zestawia Radar AthenaVault.

Próg

Trzy liczby ustalone przed startem, nie po obejrzeniu wyników: próg wdrożenia, próg odrzucenia i co robisz pomiędzy. W przykładzie 92 / 75 / człowiek w pętli. Wynik 88 procent wygląda dobrze albo źle w zależności od nastroju na spotkaniu, chyba że próg został zapisany wcześniej.

Do tego miara kosztu sprawdzania: ile czasu pracownika zajmuje sprawdzenie wyniku. System z 95 procentami trafności, który wymaga przeczytania każdego wyniku od nowa, może być gorszy od systemu z 85 procentami, który sam oznacza, czego nie jest pewien, i skraca sprawdzanie do sekund.

Data

PoC bez daty końca staje się projektem. Jako punkt wyjścia przyjmij cztery do sześciu tygodni: tyle, żeby zbudować, przetestować na próbce i poprawić raz. Na koniec jedno spotkanie i jeden dokument: pytanie, wynik względem progu, koszt sprawdzania, lista rzeczy, których PoC nie sprawdził, rekomendacja. Decyzja zapada na tym spotkaniu.

Czego PoC nie sprawdza

Warto to spisać wprost przed startem, żeby nikt nie był zaskoczony przy wdrożeniu:

• integracji z systemami produkcyjnymi (PoC pracuje na wyciągu, nie na żywym CRM czy ERP),
• wydajności przy pełnym wolumenie,
• uprawnień, logowania, śladu audytowego,
• utrzymania: kto poprawia, gdy dostawca zmieni format dokumentu,
• umowy: PoC ma osobną, krótką umowę, wdrożenie to osobna umowa; jeśli Twoja firma podlega DORA, listę tego, co musi zawierać umowa z dostawcą ICT, zestawia Radar AthenaVault.

To wszystko jest robotą wdrożeniową i ma swoją wycenę. PoC odpowiada na pytanie, czy w ogóle warto ją zaczynać.

Szablon jednej strony

Do skopiowania. Wersja do pobrania: poc-jedna-strona.md.

PoC: <nazwa procesu>                                   data startu: ____  decyzja: ____

1. PYTANIE (tak / nie)
   Czy system ______________________ tak, że co najmniej ____ procent ______ nie wymaga ______?

2. DANE
   Próbka: ____ dokumentów / rekordów z okresu ____, w tym przypadki trudne: ____
   Kto wyciąga: ____   do kiedy: ____   anonimizacja: tak / nie   dostęp do produkcji: nie
   Wzorzec: ____ sztuk sprawdzonych ręcznie przez: ____

3. PRÓG
   Wdrażamy od: ____ procent     Nie wdrażamy poniżej: ____ procent
   Pomiędzy: ____________________ (iteracja / zmiana zakresu / człowiek w pętli)
   Koszt sprawdzania: ____ sekund na dokument (mierzone w PoC)

4. DATA
   Spotkanie decyzyjne: ____   Uczestnicy: ____
   Dokument na spotkanie: pytanie, wynik vs próg, koszt sprawdzania, czego nie sprawdzono, rekomendacja

Czego ten PoC NIE sprawdza: integracje / wolumen / uprawnienia / utrzymanie / ________

Jak podchodzimy do tego w xdivision

Budujemy oprogramowanie od 2013 roku, w pięciu obszarach usług. Proof of Concept jest jednym z nich i obejmuje prototyp, walidację i decyzję o skalowaniu. Prototyp powstaje po to, żebyś sprawdził założenia i technologię w praktyce, zanim zdecydujesz o skalowaniu. Pracę zaczynamy od briefu i discovery: warsztatu z Twoim zespołem, na którym ustalamy cele, KPI i ograniczenia. Cztery pola z tego tekstu mieszczą się w tym warsztacie.