Pilotaż systemu KYC: jak przeprowadzić proof of concept, który da odpowiedzi - nie slajdy

Firmy tracą 2-4 miesiące na "pilotaże", które w rzeczywistości są rozbudowanymi demami. Dostawca przygotowuje środowisko, dobiera scenariusze i grupę testową. Efekt: wszystko działa sprawnie, wyniki wyglądają świetnie, kontrakt zostaje podpisany - a realne problemy wychodzą dopiero po trzech miesiącach produkcji.

Proof of concept systemu KYC - czyli zdalnej weryfikacji tożsamości klientów - to narzędzie do redukcji ryzyka zakupowego - ale tylko wtedy, gdy jest zaprojektowany przez kupującego, nie przez dostawcę. Ten artykuł opisuje jak go przeprowadzić, żeby na końcu mieć dane, nie prezentację.

Co pilotaż KYC powinien (i nie powinien) testować

PoC ma odpowiedzieć na pytania twojej organizacji. Nie na pytania dostawcy.

Różnica między demo a proof of concept jest fundamentalna:

• Demo - dostawca pokazuje jak działa system na swoich przykładach, w swoim środowisku, z góry wybraną grupą użytkowników
• PoC - twoja firma testuje system na swoich danych, z realną grupą docelową, w środowisku zbliżonym do produkcyjnego

Demo jest zawsze udane. PoC może nie przejść - i właśnie o to chodzi.

Co warto testować w PoC:

• Skuteczność weryfikacji na twoim konkretnym segmencie klientów. Każdy system weryfikacji tożsamości zachowuje się inaczej na różnych segmentach - klienci 60+ mają statystycznie inny completion rate niż klienci 25-35. Dostawca pokaże ci wyniki dla "typowego użytkownika" - sprawdź, czy twój klient to typowy użytkownik.
• Czas ukończenia weryfikacji przez klienta końcowego - mierzony od momentu otwarcia linku do statusu "zweryfikowano", nie od naciśnięcia "start" w panelu dostawcy.
• Zachowanie systemu przy niejednoznacznych dokumentach i weryfikacji biometrycznej: uszkodzony dowód, słabe oświetlenie, zdjęcie wykonane na starszym smartfonie, imię z polskimi znakami lub literami spoza alfabetu łacińskiego. Osobno przetestuj liveness check - wykrywanie żywotności to element, który najczęściej zawodzi na starszym sprzęcie lub przy słabym oświetleniu.
• Ścieżka eskalacji - co dokładnie się dzieje, gdy automatyczna decyzja jest niemożliwa. Kto dostaje powiadomienie, w jakim czasie, w jakiej formie.
• Integracja z twoim środowiskiem - nawet w formie mocka. Jeśli weryfikacja działa "w oderwaniu", a potem okazuje się, że twój system CRM nie obsługuje formatu danych zwracanego przez API, to nie jest problem, który wyjdzie w PoC.

Czego PoC nie musi testować:

• Pełnej zgodności regulacyjnej - to nie jest sprint testowy, to praca prawna i certyfikacyjna, którą weryfikujesz na etapie wyboru systemu do weryfikacji tożsamości, nie podczas pilotażu.
• Skalowalności na poziomie produkcyjnym - to sprawdzasz przez SLA, architekturę i referencje, nie przez 2-tygodniowy test na 80 użytkownikach. Jeśli jesteś na wcześniejszym etapie i dopiero rozważasz jak zautomatyzować procesy KYC, wróć do pilotażu po wybraniu dostawcy do testów.
  
  

Jak zdefiniować zakres PoC - zanim zaangażujesz dostawcę

Najkosztowniejszy błąd w procesie pilotażu: zapraszasz dostawcę do "przeprowadzenia PoC" bez zdefiniowania co chcesz wiedzieć po jego zakończeniu. Dostawca optymalizuje pod wrażenie, nie pod twoje pytania. I trudno mu to wypominać - po prostu robi to co mu wychodzi najlepiej.

Zanim wyślesz pierwsze zapytanie o PoC, zdefiniuj:

1. Pytania, na które PoC ma odpowiedzieć - maksimum 3-5.

Przykłady pytań, które mają sens:

• "Czy completion rate przekroczy 80% w naszym segmencie klientów (MŚP, właściciele jednoosobowych działalności)?"
• "Czy mediana czasu weryfikacji zmieści się w 3 minutach na urządzeniu mobilnym?"
• "Czy system poprawnie odczytuje dane z dowodów wydanych przed 2010 rokiem?"
• "Czy ścieżka eskalacji jest operacyjnie akceptowalna dla naszego zespołu KYC?"

Pytania bez sensu: "Czy system spełni nasze wymagania?" i "Czy klienci będą zadowoleni?"

2. Progi sukcesu - konkretne liczby, niezadowalający poziom".

Jeśli nie wiesz jakie liczby są realistyczne, poproś dostawcę o benchmarki z wdrożeń u klientów o podobnym profilu. Dobry dostawca ma te dane. Jeśli nie ma - to też jest informacja.

Dla porównania: wdrożenie weryfikacji tożsamości w segmencie leasingowym daje czas weryfikacji rzędu kilkudziesięciu sekund przy standardowych dokumentach - tak jak w przypadku klientów BNP Paribas Leasing Solutions, gdzie identyfikacja trwa kilkadziesiąt sekund przy wymaganiach sprowadzonych do dowodu osobistego i kamery.

3. Przypadki brzegowe - lista scenariuszy, które musisz przetestować.

Przypadki brzegowe nie pojawiają się w demo dostawcy. Dlatego musisz je wskazać sam: dokumenty z uszkodzoną warstwą optyczną, klienci z dwoma imionami, weryfikacja na słabym połączeniu internetowym, stary sprzęt. Lista przypadków brzegowych wynika bezpośrednio z tego, jakie metody weryfikacji tożsamości planujesz wdrożyć - każda ma inny profil ryzyka i inne scenariusze awaryjne.

4. Środowisko testowe - sandbox z prawdziwą integracją czy czyste demo w panelu.

Różnica jest zasadnicza. PoC w sandboxie dostawcy bez żadnej integracji z twoim systemem jest bliższy demo niż prawdziwemu testowi.

Co przygotować po swojej stronie przed uruchomieniem PoC

To najczęściej pomijany etap. Firmy zakładają, że "dostawca wszystko przygotuje". W praktyce PoC utyka, bo po stronie klienta brakuje zasobów lub decyzji.

Przed startem pilotażu po twojej stronie muszą być gotowe:

• Dostęp do systemu docelowego (lub jego mockup) - CRM, LOS, backoffice, cokolwiek ma odbierać wyniki weryfikacji. Jeśli integrujesz się przez API, warto mieć chociaż środowisko deweloperskie gotowe do odbierania webhooków.
• Określenie formatu danych - co system KYC ma zwracać i w jakiej strukturze. Brak tej decyzji przed PoC sprawia, że testujesz narzędzie, a nie integrację.
• Reprezentatywna grupa testowa - kto będzie przechodzić weryfikację. Wewnętrzni pracownicy to zły wybór: znają proces, mają motywację żeby "pomóc systemowi" i nie reprezentują twojego klienta. Najlepiej: zewnętrzni testerzy z profilu twojej grupy docelowej lub - jeśli możliwe - realni klienci w kontrolowanym środowisku.
• Właściciel PoC po stronie biznesowej - jedna konkretna osoba, która ma uprawnienia do podjęcia decyzji na podstawie wyników. Bez właściciela PoC może zakończyć się sukcesem, ale organizacja i tak nie podejmie decyzji przez kolejne 2 miesiące.
• Zakres danych testowych - kwestia nieoczywista z perspektywy RODO. Czy możesz testować na danych produkcyjnych klientów? Lub na zanonimizowanych albo sztucznie wygenerowanych? Ta decyzja musi zapaść przed startem, nie w trakcie.
  
  

Jak przeprowadzić PoC - etapy i harmonogram

Realistyczny harmonogram dla PoC weryfikacji tożsamości to 2-4 tygodnie robocze. Krótszy test - poniżej tygodnia - zazwyczaj nie daje statystycznie istotnych wyników, zwłaszcza gdy grupy testowe są małe lub dobrane niereprezentacyjnie.

Tydzień 1 - przygotowanie:

• Konfiguracja środowiska testowego po stronie dostawcy
• Przygotowanie grupy testowej i briefing (bez "podpowiadania" jak działa system - to zaburza wyniki)
• Uzgodnienie listy scenariuszy testowych z przypadkami brzegowymi
• Ustalenie kto po twojej stronie monitoruje wyniki na bieżąco

Tydzień 2-3 - realizacja:

• Uruchomienie weryfikacji w kontrolowanej grupie
• Codzienny monitoring completion rate i flag systemowych - nie czekaj na raport na koniec
• Dokumentowanie przypadków problematycznych z pełnym opisem scenariusza
• Bieżący kontakt z dostawcą przy problemach - ale każda interwencja dostawcy podczas PoC powinna być odnotowana (wpływ na wyniki)

Tydzień 4 - analiza:

• Zebranie danych do zdefiniowanych pytań
• Porównanie z progami sukcesu
• Analiza przypadków brzegowych
• Przygotowanie raportu wewnętrznego - osobno dla CTO, osobno dla compliance, osobno dla biznesu

Jedna praktyczna wskazówka: poproś dostawcę o dostęp do dashboardu na żywo w trakcie testu. Dobry dostawca nie ma z tym problemu. Jeśli odmawia lub "dashboard nie jest jeszcze gotowy" - to sygnał ostrzegawczy.

Jak ocenić wyniki PoC - metryki, które mają znaczenie

Nie wszystkie liczby, które dostawca wrzuci do raportu, mają znaczenie dla twojej decyzji. Oto metryki oceny systemu do weryfikacji tożsamości w trakcie PoC, które rzeczywiście pomagają podjąć decyzję:

Czego NIE mierzyć w PoC jako główne kryterium:

Ceny per weryfikacja - to negocjujesz po PoC, nie w jego trakcie. Traktowanie kosztu jako głównego kryterium w fazie pilotażu odwraca priorytety: najpierw sprawdź czy system działa dla twoich klientów, potem rozmawiaj o warunkach.

Completion rate to metryka, której warto wymagać od dostawcy z porównywalnymi wdrożeniami. MHC Mobility - firma zarządzająca flotą ponad 13 500 pojazdów w regionie CEE - zebrała po wdrożeniu 90% pozytywnych opinii od klientów na temat nowego procesu podpisywania umów z weryfikacją tożsamości.

To benchmark, który mówi więcej niż slajd z "wysokim poziomem satysfakcji".

Jak przedstawić wyniki PoC wewnątrz organizacji

PoC zakończył się sukcesem. Teraz musisz uzyskać zielone światło wewnętrznie - i to jest etap, na którym wiele projektów grzęźnie przez kolejne miesiące.

Główny błąd: wysyłasz ten sam raport do wszystkich. Efekt: każdy czyta inną część, każdy ma inne zastrzeżenia na spotkaniu decyzyjnym i ostatecznie nikt nie jest właścicielem decyzji.

Różne persony potrzebują różnych argumentów:

• Zarząd / CFO: czas onboardingu przed i po, koszt obecnego procesu (w tym ukryte koszty: błędy ludzkie, poprawki, opóźnienia) vs TCO systemu, ryzyko regulacyjne przy status quo.
• Compliance Manager: jak system radził sobie z przypadkami brzegowymi i niejednoznacznymi dokumentami, ścieżka audytowa wynikowa, zgodność z eIDAS i ustawą AML, format raportu weryfikacji jako dowód przy ewentualnej kontroli.
• CTO: wyniki integracji w środowisku testowym, latency API, model hubowy vs single vendor, SLA i polityka wersjonowania API.
• Dyrektor Operacyjny: completion rate i jego wpływ na konwersję w onboardingu, wskaźnik eskalacji i co to oznacza dla obciążenia zespołu KYC, czas weryfikacji i jego wpływ na doświadczenie klienta.

Przygotuj cztery oddzielne dokumenty lub cztery sekcje jednego raportu z wyraźnym labelingiem "dla kogo". Spotkanie decyzyjne przebiega sprawniej, gdy każdy uczestnik wie z góry, której części raportu dotyczy jego opinia.

Najczęstsze przyczyny nieudanych pilotaży KYC

Nieudany PoC to nie zawsze problem z systemem. Częściej to problem z tym jak PoC był zaprojektowany. Warto przy tym pamiętać, że część najczęstszych błędów w procesach KYC ujawnia się dopiero po wdrożeniu - PoC jest właśnie narzędziem, które pozwala je wykryć wcześniej.

1. Brak zdefiniowanych pytań na starcie. PoC "udał się" - ale nikt nie wie co z tym zrobić, bo nie było żadnych progów sukcesu ani konkretnych pytań decyzyjnych. Efekt: spotkanie podsumowujące, ogólna dyskusja i brak decyzji.
2. Testowanie na wewnętrznych pracownikach. Pracownicy znają system (bo dostawca ich przeszkolił), mają motywację żeby proces się udał i nie reprezentują profilu klienta końcowego. Wyniki są systematycznie zawyżone.
3. Zbyt optymistyczna grupa testowa. Celowy lub nieświadomy dobór "łatwych" przypadków - młodych użytkowników ze smartfonami, nowych dokumentów, standardowych imion i nazwisk. Completion rate wygląda świetnie, dopóki nie pojawią się realni klienci.
4. Brak dostępu do prawdziwego środowiska technicznego. PoC odbywa się w panelu dostawcy, bez żadnej integracji z systemami klienta. To test UX narzędzia, nie test wdrożenia.
5. Zmiana zakresu w trakcie. Dostawca "dodaje funkcje" lub "poprawia konfigurację" w trakcie PoC żeby poprawić wyniki. Każda taka zmiana powinna być odnotowana - bo to już nie jest test systemu "z pudełka".
6. Brak właściciela decyzji po stronie klienta. PoC kończy się, wyniki są pozytywne, ale organizacja i tak nie podejmuje decyzji przez kolejne 2 miesiące, bo "trzeba jeszcze skonsultować z zarządem". Właściciel decyzji musi być wyznaczony przed startem pilotażu.

Krzysztof Gozdek, dyrektor działu Legal & Compliance w MHC Mobility, podsumował podejście do wdrożenia krótko: "Jak najszybciej rozpocząć proces wdrażania i testowania narzędzia, na najbardziej problematycznym procesie, który utrudnia pracę back-office'u."

To podejście odwrotne do typowej rady "zacznij od czegoś małego" - i właśnie dlatego warto je przemyśleć przy projektowaniu zakresu PoC. Testowanie na mało reprezentatywnym procesie daje mało reprezentatywne wyniki.

Najczęściej zadawane pytania

Ile trwa pilotaż systemu KYC?

Realny PoC weryfikacji tożsamości trwa 2-4 tygodnie robocze. Krótszy test (poniżej tygodnia) zazwyczaj nie daje statystycznie istotnych wyników - zwłaszcza jeśli grupy testowe są małe lub dobrane niereprezentacyjnie. Przy dobrze przygotowanym środowisku technicznym po obu stronach można zamknąć PoC w 2 tygodnie. Główne zmienne to: gotowość środowiska testowego, dostępność grupy testowej i czas potrzebny na zebranie minimalnej liczby przypadków (rekomendowane minimum: 50-100 weryfikacji).

Ile osób powinno uczestniczyć w PoC weryfikacji tożsamości?

Minimum 50-100 przypadków weryfikacji, żeby wyniki miały sens statystyczny. Poniżej tego progu completion rate może wahać się przypadkowo o 15-20 punktów procentowych, co uniemożliwia wyciąganie wniosków. Przy małych grupach jedna seria nieudanych weryfikacji (np. kilku użytkowników na starym sprzęcie) może zaniżyć wyniki do poziomu, który nie odzwierciedla rzeczywistości.

Czy do PoC systemu do weryfikacji tożsamości są potrzebne prawdziwe dane klientów?

Niekoniecznie. Możliwa jest weryfikacja na danych pracowników lub specjalnie przygotowanej grupie testerów - ale tylko wtedy, gdy są oni reprezentatywni dla docelowego segmentu klientów pod względem wieku, sprzętu i znajomości procesów cyfrowych. Dane testowe muszą obejmować realne przypadki brzegowe. Jeśli decydujesz się na dane produkcyjne klientów, potrzebujesz odpowiedniej podstawy prawnej lub zgody zgodnej z RODO - tę kwestię warto rozstrzygnąć przed startem, nie w trakcie.

Czym różni się PoC od demo systemu do weryfikacji tożsamości?

Demo pokazuje możliwości systemu na danych i scenariuszach wybranych przez dostawcę. PoC odpowiada na pytania twojej organizacji, na twoich danych, w środowisku zbliżonym do produkcyjnego. Kluczowa różnica: w demo kontrolę nad zmiennymi ma dostawca. W PoC - kupujący. Demo jest zawsze udane. PoC może nie przejść.

Co jeśli wyniki PoC są poniżej zdefiniowanego progu sukcesu?

Masz trzy opcje: negocjować z dostawcą konkretne poprawki konfiguracyjne lub techniczne jako warunek kontraktu produkcyjnego, zmienić dostawcę, albo zrewidować progi sukcesu - jeśli analiza pokazuje, że były nierealistyczne dla specyfiki twojego segmentu. PoC, który "nie przeszedł", jest równie wartościowy jak ten który "przeszedł" - dostarcza konkretną informację zamiast ogólnych wrażeń z prezentacji.

Jak długo trwa pełne wdrożenie systemu do weryfikacji tożsamości po zakończeniu PoC?

PoC i pełna integracja to dwa różne etapy z różnymi harmonogramami. Przy dobrej dokumentacji API i dedykowanym wsparciu dostawcy - od kilku dni (MVP lub pierwsza metoda weryfikacji) do kilku tygodni (pełna integracja z systemami backoffice i ścieżką onboardingu). Główna zmienna to złożoność środowiska technicznego po stronie klienta.

Następny krok

Przed podpisaniem umowy z dostawcą KYC warto przeprowadzić proof of concept na realnych danych. Autenti umożliwia pilotaż - skontaktuj się, żeby ustalić zakres. Umów rozmowę o pilotażu.