Decyzje o danych, których inżynier nie powinien podejmować za Was

Inżynier może zbudować proces, który pobiera dokumenty, sprawdza ich świeżość i zapisuje pochodzenie każdego fragmentu. Nie powinien jednak decydować, jak świeży musi być cennik, żeby system mógł na jego podstawie odpowiadać klientom, ani czy warto płacić za ponowne zeskanowanie archiwum umów.

Te decyzje wyglądają na techniczne, a są biznesowe. Gdy nikt po stronie biznesu ich nie podejmuje, podejmuje je inżynier — domyślnie, rozsądnie z jego perspektywy i bez informowania kogokolwiek. Dowiadujecie się o nich przy pierwszym sporze.

Pięć decyzji, które należą do Was

Kto jest właścicielem każdego źródła. Nie systemu, tylko treści. Ktoś, kto wie, co oznacza pusty plik w poniedziałek rano, i kto dostaje alert, gdy ładowanie zawiedzie.

Jak świeże muszą być dane. Cennik może wymagać aktualizacji w ciągu godzin, regulamin w ciągu dni, archiwum zakończonych projektów nigdy. Jeden próg dla wszystkiego jest albo za drogi, albo za luźny, a różnicę zna tylko ktoś, kto wie, do czego te dane służą.

Co zrobić z dokumentami, których nie da się odczytać. Części skanów nie da się wiarygodnie sparsować, niezależnie od narzędzia. Czy naprawiać je u źródła, pominąć jawnie, czy kierować do człowieka, zależy od ich wartości — a tę zna biznes, nie proces.

Dane osobowe: podstawa i retencja. Które dane osobowe w ogóle muszą trafić do systemu, na jakiej podstawie i jak długo je trzymać. To rozstrzyga się z prawnikami i z inspektorem ochrony danych, jeśli firma go wyznaczyła — przed budową procesu, bo doklejanie ochrony danych później kosztuje znacznie więcej.

Kto widzi liczby jakości. Gdy kompletność albo świeżość spada, kto się o tym dowiaduje i co może z tym zrobić. Metryka jakości, której nikt nie widzi, to metryka, na którą nikt nie reaguje.

Dokumenty, których nie da się odczytać

Tę decyzję łatwo odłożyć, bo wygląda na szczegół. Upraszcza ją jedno pytanie: ile ten dokument jest wart, jeśli system ma go poprawnie przeczytać?

Infografika

Które dokumenty warto naprawiać u źródła

Dobrze czytelneSłabo czytelne

Bierzemy, jak sąWchodzą do procesu bez dodatkowej pracy i bez priorytetu.

Ścieżka głównaPełne kontrole, pochodzenie i najściślej pilnowana świeżość.

Pomijamy jawnieOznaczone i policzone, żeby nikt nie zakładał, że są w systemie.

Naprawa u źródłaPonowne skanowanie albo ręczna weryfikacja — decyzja budżetowa biznesu.

Niska wartośćWysoka wartość

Proces, który po cichu produkuje kiepski tekst z części dokumentów, jest gorszy od takiego, który je oznacza i liczy. Oznaczenie zamienia ukryty problem w pozycję budżetową, o której ktoś może zdecydować.

Ile to kosztuje Waszego czasu

Mniej, niż się wydaje, jeśli jest zaplanowane. Właściciel źródła: kilka rozmów na starcie, a potem odbieranie alertów. Decyzje o świeżości i dokumentach: krótkie spotkanie na źródło, z propozycjami i skutkami przygotowanymi przez zespół. Dane osobowe: jedna runda z prawnikami przed budową, a nie trzy po niej. Łącznie to zwykle mniej czasu niż jedno spotkanie wyjaśniające, dlaczego system odpowiedział klientowi na podstawie nieaktualnego cennika.

Najdroższym wariantem jest brak decyzji. Projekt albo czeka, albo idzie dalej na wartościach domyślnych, które ktoś odkryje w najmniej wygodnym momencie.

Jak wygląda dobrze podjęta decyzja

Krótko i na piśmie. Dla każdego źródła: kto jest właścicielem, jaki próg świeżości obowiązuje i kto dostaje alert, gdy zostanie przekroczony. Dla dokumentów: które klasy idą ścieżką główną, które są pomijane jawnie i ile ich jest. Dla danych osobowych: co trafia do systemu, na jakiej podstawie i na jak długo.

Taki zapis mieści się na jednej stronie na źródło i jest wart więcej, niż wskazuje jego objętość. Przy pierwszym sporze — z klientem, z audytorem albo między działami — odpowiedź na pytanie, dlaczego system odpowiedział tak, a nie inaczej, zaczyna się właśnie od niego. Bez niego zaczyna się od szukania kogoś, kto pamięta.

Jak poznać, że decyzje nie zapadają

Pytania od zespołu danych wiszą w skrzynce tygodniami. W dokumentacji mnożą się zdania zaczynające się od „przyjęliśmy założenie, że…”. Harmonogram się przesuwa, choć nikt nie zgłasza problemu technicznego.

Każdy z tych objawów oznacza, że ktoś podejmuje decyzję biznesową bez mandatu. Nie dlatego, że chce, tylko dlatego, że proces musi wiedzieć, co zrobić z danymi, a nikt mu tego nie powiedział.

W inżynierii danych dla AI te pytania stawiamy na samym początku, przy badaniu tego, co jest — bo wtedy odpowiedź kosztuje jedno spotkanie, a nie przebudowę procesu.