Czy Wasze dane nadają się do AI? Test stu przypadków

Trzy strony na naszej witrynie mówią to samo: zanim zaczniecie projekt, spróbujcie wyeksportować ostatnie sto przypadków procesu jako jedną tabelę. Piszemy o tym w poradniku jak wdrożyć AI w firmie, w tekście o tym, ile kosztuje wdrożenie AI, i na stronie automatyzacji AI. Żadna z nich nie pokazuje jednak, jak ten test przeprowadzić w każdym źródle osobno i co z niego wychodzi. Ten tekst zaczyna się tam, gdzie tamte się kończą.

Przygotowanie danych do AI to w naszej metodyce wdrożenia część pierwszej fazy — audytu i wyboru procesu — a nie punkt na liście przed startem. Poniżej opisuję tę połowę audytu, którą możecie zrobić sami: pięć testów dla pięciu źródeł, siedem problemów, które te testy mogą ujawnić, i kartę oceny, która kończy się decyzją. Test robi się dla jednego procesu, nie dla całej firmy. Zajmuje jedno popołudnie na proces i powinna go przeprowadzić osoba, która ten proces prowadzi na co dzień, a nie dział IT — bo tylko ona wie, czy w danych widać to, co naprawdę się wydarzyło.

Jedno zastrzeżenie co do zakresu: chodzi o dane procesu, czyli sprawy, zamówienia, faktury, zgłoszenia i decyzje. Jeżeli planujecie asystenta, który odpowiada na pytania na podstawie dokumentów firmy, kryteria są inne — zaczynacie wtedy od pytania, czy potrzebujecie agenta AI (programu, który sam wykonuje kroki zadania), czy chatbota, który tylko odpowiada na pytania; różnicę wyjaśniamy osobno: agent AI czy chatbot.

Zanim zaczniecie: sto spraw, jedna tabela i kolumna wyniku

Najpierw ustalcie, co jest jedną sprawą: jedno zamówienie, jedna reklamacja, jedna faktura do zatwierdzenia. Test polega na tym, żeby dla stu różnych spraw zebrać w jednej tabeli wszystko, czego potrzebowałaby osoba, która ma je obsłużyć, oraz to, jak każda z nich się skończyła.

Weźcie ostatnie sto zakończonych spraw. Jeżeli ostatnie tygodnie były nietypowe, wylosujcie sto spraw z dłuższego okresu. Jeżeli proces jest sezonowy, losujcie z pełnego cyklu, na przykład z ostatnich dwunastu miesięcy. Przy sprawdzaniu źródeł dołóżcie też kilka spraw otwartych, porzuconych albo przekazanych do rozstrzygnięcia innej osobie. Mogą ujawnić braki danych, które umknęłyby przy sprawdzaniu samych spraw zakończonych. Zapis wyniku sprawdzajcie tylko w sprawach zakończonych. Jeżeli w procesie zdarzają się rzadkie, ale kosztowne sprawy, dołóżcie też kilka znanych spraw tego rodzaju, bo w losowej setce może nie być żadnej. Sto spraw to wstępne rozpoznanie, a nie pomiar: pokazuje, gdzie leżą dane i czego brakuje, ale nie daje dokładnych udziałów. Nawet przy stu losowo wybranych sprawach udział wynoszący około połowy jest znany tylko z dokładnością mniej więcej 10 punktów procentowych w każdą stronę (wyliczenie podajemy w źródłach). A to, że w stu sprawach nie znaleźliście żadnego braku, nie dowodzi, że braków nie ma.

Przed testem odpowiedzcie na trzy pytania wstępne z karty. Pierwsze obowiązuje zawsze, także wtedy, gdy test zostaje w firmie: administrator danych (firma lub osoba, która decyduje, po co i jak przetwarza się dane osobowe) ustala zakres eksportu, wskazuje dane potrzebne do testu oraz dane do usunięcia lub zamaskowania, bo test ich nie potrzebuje — osobowe, ale też na przykład wewnętrzne ceny czy marże, także w polach opisowych — i upewnia się, że je usunięto lub zamaskowano. Ustala też, kto w firmie może korzystać z kopii danych, gdzie kopia będzie zapisana i przetwarzana w czasie testu (na przykład tylko w systemach firmy lub na firmowym koncie w chmurze w uzgodnionym regionie, a nie na prywatnym laptopie, prywatnym dysku w chmurze czy w publicznym czacie AI), jak długo będzie przechowywana i kiedy zostanie usunięta. Drugie dotyczy tylko pliku, który ma trafić na zewnątrz: administrator osobno potwierdza przekazanie — do kogo trafi plik, gdzie dane będą przetwarzane, kto po stronie odbiorcy uzyska dostęp, jak długo będą tam przechowywane i jak zostaną usunięte. W ramach tego samego warunku firma sprawdza, czy umowy z kontrahentami i zobowiązania do poufności pozwalają przekazać zawartość pliku wskazanemu odbiorcy — dotyczy to także poufnych materiałów kontrahentów, nie tylko danych osobowych. Eksport nie opuszcza firmy, dopóki oba warunki nie są spełnione. Samo maskowanie nie zastępuje potwierdzenia przekazania, bo zamaskowane dane nadal mogą być danymi osobowymi. Wracam do tego niżej, przy trzecim ustaleniu.

Ostatnie pytanie wstępne dotyczy materiałów, które nie są wyłącznie Wasze. Jeśli w próbce są materiały partnerów albo dane z zewnętrznego serwisu, sprawdźcie najpierw, czy umowa lub regulamin pozwala ich użyć do testu (pytanie 0c). Jeśli nie wiecie, zapytajcie osobę odpowiedzialną za umowy lub prawnika. Odpowiedź „nie” oznacza wynik „jeszcze nie”: test może się zacząć dopiero wtedy, gdy potwierdzicie, że firma może użyć tych danych.

Pobierzcie kartę oceny jako plik CSV, czyli zwykły plik tekstowy z tabelą, w którym kolumny rozdzielają średniki. To pusty arkusz z trzema pytaniami wstępnymi, dwudziestoma pytaniami z pięciu testów opisanych niżej, kolumnami na wynik, ustalenia i następny krok oraz wierszami na końcową decyzję. Otwiera się w Excelu i w Arkuszach Google. Jeżeli Excel pokaże całą tabelę w jednej kolumnie, zaimportujcie plik przez „Dane → Z tekstu/CSV” i wybierzcie średnik jako separator.

Część 1. Test źródło po źródle

Każde źródło ma cztery pytania. Odpowiedź „tak” oznacza, że źródło zalicza test w tym punkcie. Odpowiedź „nie” nie dyskwalifikuje procesu. Przy każdej odpowiedzi „nie” zapiszcie, czego brakuje, i przypiszcie numer jednego z siedmiu ustaleń z części drugiej, jeżeli jego opis pasuje. Jeżeli „nie” nie pasuje do żadnego z nich, zostawcie numer pusty, ale opiszcie brak, jego wpływ na pilotaż, następny krok (kolumna „Następny krok”) i to, kto go wykona (kolumna „Kto naprawia”). Wynik karty pozostaje „jeszcze nie”, dopóki nie ustalicie wpływu braku na pilotaż, następnego kroku i tego, kto go wykona. Jeżeli Wasz proces nie korzysta z danego źródła, pomińcie je.

Sam układ tabeli to nie wszystko: kolumna może istnieć, a w wielu sprawach być pusta. Dla każdego pola potrzebnego do decyzji policzcie, w ilu ze stu spraw brakuje wartości. Jeżeli każda sprawa zajmuje jeden wiersz, puste komórki w danej kolumnie w tych stu sprawach policzy funkcja LICZ.PUSTE w Excelu. Jeżeli sprawa zajmuje kilka wierszy, sprawdźcie je razem i każdą sprawę z brakującą wartością policzcie raz. Policzcie też, w ilu sprawach wszystkie potrzebne pola są wypełnione: braki w różnych polach mogą dotyczyć różnych spraw, więc każde pole osobno może mieścić się w dopuszczalnym poziomie, a kompletnych spraw może być za mało. Jeżeli każda sprawa zajmuje jeden wiersz, możecie w Excelu włączyć filtr, w każdej potrzebnej kolumnie kolejno odznaczyć puste komórki, pozostawiając wcześniejsze filtry włączone, i policzyć pozostałe sprawy. Jeżeli sprawa zajmuje kilka wierszy, przejrzyjcie wszystkie jej wiersze razem i policzcie sprawy kompletne. Dopuszczalny poziom braków i to, ile kompletnych spraw potrzeba, osoba prowadząca proces określa razem z kryterium sukcesu pilotażu. W kolumnie „Czego brakuje” zapiszcie dla każdego takiego pola liczbę spraw z brakiem i dopuszczalny poziom, a pod tą listą liczbę spraw kompletnych i to, ile ich potrzeba. Jeżeli liczba spraw z brakiem przekracza dopuszczalny poziom albo spraw kompletnych jest za mało, opiszcie wpływ na pilotaż, następny krok i to, kto go wykona. Dopóki nie są ustalone oba progi i nie jest rozstrzygnięte ewentualne przekroczenie albo niedobór, wynik pozostaje „jeszcze nie”.

1. Eksport z ERP lub innego systemu

ERP to system, w którym firma prowadzi zamówienia, magazyn i faktury. To samo dotyczy CRM, czyli systemu do obsługi relacji z klientami, systemu zgłoszeń czy programu księgowego — każdego systemu, w którym proces zostawia ślad.

• Czy sto spraw da się wyeksportować do jednego pliku bez przepisywania? Zalicza: plik CSV albo Excel w kwadrans. Nie zalicza: zrzuty ekranu, kopiowanie po jednej sprawie albo prośba do dostawcy systemu.
• Czy każdy wiersz opisuje ten sam rodzaj zapisu? Może to być sprawa albo pozycja zamówienia. Jeżeli jedna sprawa zajmuje kilka wierszy, każdy musi mieć jej numer, a do próby liczycie sto różnych spraw, nie sto wierszy.
• Czy jest kolumna z wynikiem sprawy? Zatwierdzono czy odrzucono, jaka kwota korekty, do kogo skierowano sprawę. Bez niej nie da się sprawdzić, czy system podpowiada dobrze.
• Czy numery spraw i kontrahentów są zgodne z numerami w pozostałych źródłach? Ten sam format numeru zamówienia, ten sam NIP, a nie raz NIP, a raz skrócona nazwa firmy. Przy okazji porównajcie w kilku sprawach te same pola — kwotę, termin, status — między źródłami. Różne wartości to ustalenie 2.

2. Skrzynka pocztowa

• Czy wiadomo, które wątki należą do procesu? Osobny adres, folder albo etykieta. Jeżeli zamówienia przychodzą na pięć prywatnych skrzynek, już to jest ustaleniem.
• Czy dane potrzebne do decyzji da się odczytać z wiadomości, formularza albo załącznika? Sam załącznik nie oznacza niezaliczenia. Nie zalicza, jeżeli załącznik jest nieczytelnym skanem, a treść brzmi tylko „w załączeniu przesyłam”.
• Czy wątek da się przypisać do konkretnej sprawy i połączyć z jej pozostałymi danymi? Na przykład przez numer zamówienia w temacie wiadomości.
• Czy wynik sprawy jest zapisany w wątku albo w powiązanym zapisie w innym źródle? Nie zalicza, jeżeli decyzję przekazano przez telefon i nigdzie jej nie zapisano.

Nawet gdy wszystkie cztery odpowiedzi brzmią „tak”, sprawdźcie, czy proces jest zapisany gdzieś poza pocztą. Jeżeli poczta jest jedynym zapisem procesu, wpiszcie w karcie ustalenie 7.

3. Skany i pliki PDF

• Czy PDF ma warstwę tekstową? Otwórzcie plik, naciśnijcie Ctrl+F i wyszukajcie słowo widoczne na stronie. Znalezienie go potwierdza tekst w tym miejscu, ale nie w całym pliku, więc sprawdźcie kilka stron. Jeżeli wyszukiwanie nic nie znajduje, spróbujcie innego słowa i skopiowania zdania do zwykłego tekstu. Brak czytelnego wyniku oznacza, że plik trzeba będzie najpierw odczytać. Jeżeli warstwa tekstowa jest, porównajcie w co najmniej jednym pliku każdego wzoru dokumentu kluczowe wartości — kwotę, datę, NIP, numer zamówienia — z tym, co widać na stronie: warstwa tekstowa z automatycznego odczytu może mieć błędy w cyfrach, a poprawny odczyt jednego wzoru nie przesądza o pozostałych. Rozbieżności traktujcie jak ustalenie 4, a wzory, których nie sprawdziliście, wpiszcie w kolumnie „Czego brakuje” i jako wynik wpiszcie „nie”.
• Czy wiecie, ile różnych wzorów dokumentu jest w stu sprawach? Jeden wzór od jednego nadawcy to inna sytuacja niż czterdzieści wzorów od czterdziestu nadawców.
• Czy plik jest przypisany do sprawy? Numer sprawy w nazwie pliku albo w folderze, a nie „skan_0042.pdf” w zbiorczym katalogu.
• Czy potrzebne dane są czytelne mimo pieczątek i dopisków? Pieczątka na kwocie albo odręczny dopisek w miejscu numeru zamówienia to informacja, którą warto znać przed projektem, a nie w jego trakcie.

4. Excel na wspólnym dysku

• Czy każdy wiersz opisuje ten sam rodzaj zapisu, a jedna kolumna — jedną informację? To zasada „uporządkowanych danych” opisana w literaturze o analizie danych: każda zmienna w kolumnie, każda obserwacja w wierszu. Jeżeli termin albo osoba odpowiedzialna są potrzebne do obsługi sprawy, powinny mieć osobne kolumny; zapisanie ich tylko w „Uwagach” nie zalicza tego punktu.
• Czy istnieje jedna aktualna wersja pliku? Nie zalicza: „rejestr_final_v2_Ania.xlsx” obok „rejestr_final_v3.xlsx”.
• Czy znaczenie jest zapisane także słowami, a nie wyłącznie kolorem? Jeżeli czerwony kolor wiersza oznacza „pilne”, przy eksporcie do CSV ta informacja znika. Potrzebna jest kolumna, która zapisuje ją słowami.
• Czy arkusz ma kolumnę z wynikiem sprawy? To samo pytanie co przy systemie — i równie ważne.

5. Notatki i rozmowy

• Czy ustalenia z rozmów są gdzieś zapisywane? Notatka w CRM, komentarz w zgłoszeniu, wpis w arkuszu.
• Czy notatka ma datę i numer sprawy? Bez nich nie da się jej przypisać do żadnego wiersza.
• Czy notatki da się zebrać i przypisać do spraw? Jeżeli są rozproszone między zeszytem, telefonem i komunikatorami, sprawdźcie osobno, jak zebrać je z każdego z tych miejsc.
• Czy z notatki wynika, dlaczego zapadła decyzja? „Rabat 5%” mówi, co się stało. „Rabat 5%, bo stały klient i opóźniona dostawa” mówi, według jakiej zasady.

Część 2. Siedem ustaleń, na które trafia test

To opis sytuacji, które ten test ma wychwycić — wzorce, a nie opisy konkretnych firm ani statystyka. Każde ustalenie ma ten sam układ: objaw, przyczyna, co z tym zrobić i jaki ma wpływ na projekt. Wpływ ma trzy wartości:

• blokuje pilotaż — bez naprawy pilotażu nie da się zmierzyć albo w ogóle uruchomić;
• dodaje fazę przygotowania danych — przed pilotażem dochodzi osobny etap pracy;
• dodaje regułę w procesie — trzeba coś rozstrzygnąć i zapisać, a rozwiązanie będzie tę zasadę stosować.

Rząd wielkości podajemy jako „dni” albo „tygodnie”, bez liczb. To orientacja, a nie obietnica terminu: liczba zależy od Waszego procesu, a widełki podane bez jego znajomości byłyby zgadywaniem.

1. Brak kolumny z wynikiem

Objaw: w danych widać, co przyszło, ale nie widać, jak sprawa się skończyła. Jest zamówienie, ale nie wiadomo, czy przyjęto je bez zmian. Jest reklamacja, ale nie wiadomo, czy ją uznano.

Przyczyna: decyzja zapada w rozmowie albo w mailu i nikt nie wpisuje jej wyniku do tabeli, bo do tej pory nie był tam nikomu potrzebny.

Co z tym zrobić: najpierw sprawdzić, czy wynik da się odtworzyć z późniejszych śladów, na przykład z faktury korygującej albo zmiany statusu w systemie. Jeżeli nie, zacząć zapisywać go od dziś, w jednej kolumnie z kilkoma stałymi wartościami.

Wpływ: blokuje pilotaż, dopóki nie ma zapisanych wyników, które osoba prowadząca proces uzna za punkt odniesienia. To ustalenie stawiamy na pierwszym miejscu, bo bez wyniku nie da się porównać propozycji systemu z tym, co zrobił człowiek, więc nie da się zmierzyć, czy pilotaż się udał. Uwaga: zapisany wynik mówi, co zrobiono, a nie czy zrobiono dobrze. Przed pilotażem osoba prowadząca proces przegląda wyniki w próbie, poprawia te, które uważa za błędne, i razem z wykonawcą ustala, od jakiego wyniku pilotaż uzna się za udany. Jeżeli w badanym okresie zmieniły się zasady — na przykład cennik albo reguły zatwierdzania — zapiszcie przy sprawie, która wersja wtedy obowiązywała, i oceniajcie pilotaż według zasad obowiązujących dziś: sprawy rozstrzygnięte według starszych reguł pomińcie albo poprawcie ich wynik według obecnych, zachowując zapis pierwotnej decyzji. Pominięte sprawy zastąpcie sprawami rozstrzygniętymi według obecnych zasad, tak żeby próba nadal obejmowała pełny cykl procesu i rzadkie, ale kosztowne sprawy. Jeżeli takich spraw jest jeszcze za mało, karta pokazuje „jeszcze nie”, dopóki się nie zbiorą. Kto naprawia: Wy. Rząd wielkości: dni, jeżeli wyniki da się odtworzyć; tygodnie, jeżeli trzeba poczekać, aż zbiorą się nowe.

2. Trzy wersje prawdy

Objaw: ta sama sprawa ma w systemie inną kwotę niż w arkuszu, a w mailu jeszcze inny termin. Każde źródło z osobna wygląda na poprawne.

Przyczyna: dane są przepisywane ręcznie między miejscami i poprawka trafia tylko do jednego z nich.

Co z tym zrobić: dla każdego pola wskazać źródło, któremu ufacie — na przykład kwota z systemu, termin z potwierdzenia mailowego. To decyzja o danych, a nie o tym, kto w firmie ma rację.

Wpływ: dodaje regułę w procesie. Kto naprawia: Wy decydujecie, wykonawca wbudowuje regułę w rozwiązanie. Rząd wielkości: dni.

3. Dane osobowe w polu „uwagi”

Objaw: w kolumnie opisowej, w notatce albo w treści maila są numery telefonów, adresy, informacje o zdrowiu czy sytuacji rodzinnej — rzeczy, których proces wcale nie potrzebuje.

Przyczyna: wolne pole przyjmuje wszystko, a ludzie wpisują to, co akurat jest pod ręką.

Co z tym zrobić: zanim eksport opuści firmę, usunąć albo zamaskować zbędne dane osobowe w treści pól opisowych, zachowując informacje potrzebne do testu. O tym, co i jak maskować, decyduje administrator danych — a jeśli w firmie powołano inspektora ochrony danych (IOD), z jego udziałem. O tym, czy eksport może trafić do wykonawcy lub modelu, administrator danych decyduje osobno, przed wysłaniem; samo maskowanie nie zastępuje tej decyzji. W rozwiązaniu można dodać warstwę pośrednią, która usuwa lub maskuje wskazane zbędne dane przed wysłaniem do modelu; opisaliśmy ją w tekście o RODO, czyli ogólnym rozporządzeniu o ochronie danych, w części „Wyślij mniej”.

Wpływ: dodaje regułę w procesie. Kto naprawia: decyzja należy do Was, filtr buduje wykonawca. Rząd wielkości: dni.

4. Skany bez warstwy tekstowej lub z błędami w tekście

Objaw: na sprawdzonych stronach ani wyszukiwanie widocznych słów, ani kopiowanie zdań nie daje czytelnego tekstu — potrzebne dane są zapisane jako obraz. Dokumenty są zdjęciami kartek, czasem krzywymi, czasem z pieczątką na kwocie. Albo tekst jest, ale kluczowe wartości — kwota, data, NIP — nie zgadzają się z tym, co widać na stronie.

Przyczyna: dokumenty przychodzą na papierze albo ktoś skanuje je do obrazu, nie do tekstu.

Co z tym zrobić: odczyt dokumentu staje się osobnym krokiem, który trzeba sprawdzić na Waszych plikach, zanim zbuduje się resztę. Warto też zapytać nadawców, czy mogą przysyłać pliki elektroniczne zamiast skanów. Przy fakturach jest jeszcze inna droga, opisana niżej.

Wpływ: dodaje fazę przygotowania danych. Kto naprawia: wykonawca buduje i sprawdza odczyt, Wy rozmawiacie z nadawcami. Rząd wielkości: dni przy jednym wzorze dokumentu, tygodnie przy wielu.

5. System bez eksportu

Objaw: danych nie da się wyciągnąć inaczej niż przez zrzut ekranu albo przepisanie.

Przyczyna: stary system, wersja bez modułu raportów albo licencja, która nie obejmuje dostępu do danych.

Co z tym zrobić: sprawdzić trzy drogi: raport zapisywany jako plik, API (interfejs, przez który inne programy mogą pobierać dane z systemu) i eksport przygotowany przez dostawcę systemu na zamówienie.

Wpływ: blokuje pilotaż, dopóki jedna z tych dróg nie zadziała. Kto naprawia: Wy, razem z dostawcą systemu. Rząd wielkości: dni lub tygodnie — zależnie od tego, która droga jest dostępna, ile pracy wymaga i jak szybko odpowie dostawca systemu.

6. Niezgodne identyfikatory

Objaw: w mailu jest „zam. 123”, w systemie „ZAM/2026/000123”, a w arkuszu nazwa klienta zamiast NIP-u. Każda sprawa daje się dopasować ręcznie, ale nie automatycznie.

Przyczyna: każde źródło powstało osobno i nikt nie uzgodnił, jak zapisywać numery.

Co z tym zrobić: spisać zasadę dopasowania — który numer jest główny i jak przekształcić pozostałe — a tam, gdzie zasady nie da się ustalić, prowadzić prostą tabelę powiązań.

Wpływ: dodaje regułę w procesie. Kto naprawia: wykonawca, na podstawie Waszej listy przypadków. Rząd wielkości: dni.

7. Proces żyje w mailu

Objaw: cała sprawa — zapytanie, ustalenia, decyzja — jest w wątkach mailowych pisanych wolnym tekstem. W systemie pojawia się dopiero wynik albo nie pojawia się nic.

Przyczyna: mail jest najprostszym narzędziem i nikt nie potrzebował niczego więcej.

Co z tym zrobić: dla nowych spraw wprowadzić formularz albo stały szablon wiadomości z kilkoma polami. Historię z maili da się wykorzystać, ale jej odczytanie jest osobną pracą.

Wpływ: dodaje fazę przygotowania danych. Kto naprawia: formularz — Wy, odczyt historii — wykonawca. Rząd wielkości: dni na formularz albo na odczyt historii; tygodnie, jeżeli trzeba zebrać nowe dane.

Siedem ustaleń w jednej tabeli

Dwie zmiany, które ograniczają przygotowanie danych

Faktury kosztowe: KSeF zamiast skanów

Faktury otrzymywane przez KSeF, czyli Krajowy System e-Faktur, przychodzą jako plik o stałej strukturze, a nie jako obraz, więc w ich przypadku odczyt skanu można pominąć — co z tego wynika dla księgowości, opisujemy przy automatyzacji księgowości.

Zamówienia i zgłoszenia: formularz zamiast wolnego maila

Formularz z polami na numer klienta, numer zamówienia i termin nie wymaga żadnego AI, a porządkuje nowe sprawy od dnia wprowadzenia. Żeby przy okazji zniknęły niezgodne identyfikatory, formularz musi używać tych samych numerów co system. Wynik sprawy i tak trzeba dopisać po jej zakończeniu.

Karta oceny: pilotaż, przygotowanie danych czy „jeszcze nie”

Po teście macie odpowiedzi na pytania wstępne, wyniki testów i listę braków — z numerem ustalenia albo bez niego. Decyzja wynika z najgorszego z nich:

Jeżeli wynik brzmi „pilotaż”, odłóżcie część spraw — w tym kilka rzadkich, ale kosztownych, jeśli takie macie — zanim wykonawca zacznie budować, i nie udostępniajcie mu ich ani przy budowie, ani przy poprawkach. Dopiero przy sprawdzaniu pilotażu rozwiązanie dostaje dane tych spraw, bez zatwierdzonych odpowiedzi i tylko w takim stanie, w jakim były wtedy, gdy zapadała decyzja w sprawie — bez późniejszych statusów, korekt i notatek, z których dałoby się odczytać wynik. Osoba prowadząca proces porównuje propozycje rozwiązania z zatwierdzonymi odpowiedziami według uzgodnionego wcześniej kryterium sukcesu.

Wynik „jeszcze nie” wymaga wyjaśnienia albo usunięcia przeszkody, a gdy brakuje zapisanej historii decyzji, obowiązuje zasada ze strony czego nie robimy: „Jeśli historia decyzji istnieje tylko w czyjejś głowie, najpierw trzeba ją spisać”.

Wypełniona karta jest też najlepszym materiałem na pierwszą rozmowę z wykonawcą: pokazuje stan danych w Waszym procesie, więc rozmowa może od razu dotyczyć zakresu, a nie domysłów. Jak zakres i koszt wynikają ze stanu danych, rozpisaliśmy w tekście o tym, ile kosztuje wdrożenie AI, a całość projektu — na stronie wdrożenie AI w firmie.

Źródła — stan na 12 października 2026 roku

• NIST/SEMATECH e-Handbook of Statistical Methods, 7.2.4.1 „Confidence intervals” — przedział ufności dla udziału metodą Wilsona, przy poziomie ufności 95%. Dla stu losowo wybranych spraw i udziału około połowy połowa szerokości przedziału wynosi około 9,6 punktu procentowego; przy zerze znalezionych braków górna granica przedziału wynosi około 3,7%. Obliczenia własne według wzoru z podręcznika; dotyczą próby losowej, a nie dowolnie wybranych ostatnich spraw.
• Hadley Wickham, „Tidy Data”, Journal of Statistical Software 59(10), 2014 — zasada: każda zmienna to kolumna, każda obserwacja to wiersz.
• Microsoft — funkcja LICZ.PUSTE — liczenie pustych komórek w zakresie; odczyt 12 października 2026 r.
• Rozporządzenie (UE) 2016/679 (RODO) — art. 5 ust. 1 lit. c (minimalizacja danych) oraz art. 37–39 (inspektor ochrony danych); odczyt 12 października 2026 r.
• Zakres obowiązkowego KSeF — strona Ministerstwa Finansów: otrzymywanie faktur przy użyciu KSeF obowiązkowe od 1 lutego 2026 r., z wyłączeniami przewidzianymi w ustawie; przepisy przejściowe do końca 2026 r. dotyczą wystawiania faktur, nie ich odbierania; odczyt 12 października 2026 r.