Kennisbank

Co Pański proces mówi o wymaganiach wobec narzędzia

Dostawca prędzej czy później zapyta: co system powinien umieć? Odpowiedź nie leży u dostawcy i nie w liście funkcjonalności, którą zaznaczyły już inne firmy. Odpowiedź leży w Pańskim własnym procesie: jakie punkty danych są zbierane, kto je dostarcza, skąd pochodzą i co idzie źle, gdy nikt na nie nie patrzy.

Kolejność, którą najczęściej pomija się

Typowa droga wygląda tak: najpierw wybiera się narzędzie, następnie je konfiguruje, a dopiero potem odkrywa się, jakie dane muszą skąd pochodzić. Taka kolejność działa odwrotnie do zamierzonego efektu, ponieważ narzędzie nie ma opinii na temat Pańskiego procesu. Ono prosi o dane wejściowe, a te dane wejściowe muszą skąd pochodzić. Jeśli to coś — rejestr punktów danych, przypisanie odpowiedzialności, źródła — jeszcze nie istnieje, konfiguracja narzędzia zamienia się w poszukiwania, których nikt nie zaplanował.

Inna kolejność zaczyna się od procesu. Najpierw ustala się, jakie punkty danych są potrzebne, kto je dostarcza, z jakiego systemu lub jakiego arkusza kalkulacyjnego pochodzą i jakie reguły jakości do nich należą. Dopiero potem staje się jasne, jakie wymagania narzędzie właściwie musi spełniać. Nie abstrakcyjne wymagania, takie jak „przyjazne dla użytkownika” czy „skalowalne”, ale konkretne wymagania, takie jak: musi łączyć się z tym konkretnym systemem źródłowym, musi umieć rozróżnić trzech właścicieli w ramach jednego punktu danych, musi sygnalizować odchylenie, gdy liczba wykracza poza wcześniej ustaloną marżę.

Dlaczego ta kolejność nie jest przypadkowa

Ta kolejność nie jest preferencją metody; wynika z tego, co funkcjonalnie logicznie poprzedza narzędzie. Narzędzie może otrzymać wymagania tylko wtedy, gdy istnieje coś, z czego te wymagania można wyprowadzić. Tym czymś jest proces: przepływ danych od źródła do raportu, wraz z wszystkimi krokami ręcznymi, przekazaniami i założeniami, które do niego należą. Bez tego przeglądu organizacja formułuje wymagania na podstawie tego, co narzędzie umie, a nie na podstawie tego, czego potrzebuje proces. To wydaje się subtelną różnicą, ale decyduje o tym, czy narzędzie później będzie odpowiadać rzeczywistości, czy stanie obok niej.

Wiąże się to z pytaniem jak wybrać narzędzie, nie żałując tego później: żal często nie powstaje z powodu złego narzędzia, ale z powodu narzędzia, które musiało odgadywać wymagania, ponieważ nikt ich nie zapisał.

Co kosztuje odwrotna kolejność

Gdy najpierw pojawia się narzędzie, a proces dopiero później, powstają dwa rodzaje kosztów. Pierwszy to bezpośrednia reorganizacja: funkcjonalność, która nie odpowiada potrzebom, integracje, które trzeba jeszcze zbudować, pola, które pozostają puste, bo nikt nie wie, kto powinien je wypełnić. Drugi koszt jest mniej widoczny, ale bardziej dotkliwy: narzędzie zacznie generować raporty, które wyglądają porządniej, podczas gdy liczby stojące za nimi wciąż nie są możliwe do wyśledzenia do źródła czy właściciela. To ryzyko jest szerzej opisane na stronie o tym, co kosztuje umieszczenie narzędzia nad niezorganizowanym procesem: narzędzie skrywa problem, zamiast go rozwiązywać.

Pytanie, która kolejność wypada korzystniej finansowo, zależy od tego, ile punktów danych, systemów i właścicieli już istnieje i ile z nich nie jest jeszcze udokumentowane. Przy niewielkim procesie z małą liczbą źródeł szkoda wynikająca z odwrotnej kolejności jest ograniczona. Przy procesie rozproszonym na wiele działów, systemów i arkuszy kalkulacyjnych, szkoda ta rośnie z każdym punktem danych, który nie został wyjaśniony, zanim narzędzie o niego zapyta. Ten rachunek jest przedstawiony na stronie najpierw kupić narzędzie czy najpierw zorganizować proces: co kosztuje ta różnica.

Co musi być gotowe najpierw

Zanim narzędzie może otrzymać wymagania, musi istnieć przegląd tego, jakie punkty danych są potrzebne do raportowania, skąd pochodzi każdy punkt danych, kto jest odpowiedzialny za poprawność i jaka reguła decyduje, czy wartość jest wiarygodna. Ten przegląd nie jest dokumentem technicznym ani samym narzędziem; jest rejestrem, który stanowi podstawę dla każdego kolejnego kroku, niezależnie od tego, czy tym krokiem jest narzędzie, proces ręczny, czy kombinacja obu.

Pytanie, jakie wymagania funkcjonalne z tego wynikają, jest więc w istocie pytaniem: co znajduje się w tym rejestrze i czego jeszcze w nim brakuje? Dopóki to pytanie nie zostanie odpowiedziane, każde wymaganie wobec narzędzia pozostaje domysłem. Ta zależność między wymaganiami a leżącym za nimi procesem jest dalej rozwinięta na stronie o tym, jakie wymagania funkcjonalne wynikają z Pańskiego własnego procesu i co kosztuje niewłaściwa kolejność.

Most do samej pracy

Gdy rejestr punktów danych i przypisanie odpowiedzialności są już uporządkowane, pytanie przesuwa się od tego, co narzędzie powinno umieć, do tego, co dzieje się z ludźmi, którzy obecnie wykonują tę pracę: zbieranie, kontrolowanie i przepisywanie liczb z arkuszy kalkulacyjnych i systemów. Część tych zadań jest powtarzalna i podlega ustalonym regułom, i to jest właśnie ten rodzaj pracy, którego część można przekazać AI. [Skan pracy FTE TO AI](https://ftetoai.nl) wylicza dla każdego zadania, jaką jego część można zautomatyzować, dzięki czemu staje się jasne, gdzie ludzie są wciąż potrzebni, a gdzie pracę można przekazać systemowi, który kontroluje i dostarcza dane według ustalonych reguł.