Decyzje, których nie przekazuje się AI

Każda dyrekcja, która zaczyna pracować z AI, prędzej czy później napotyka to pytanie: jaką decyzję może podjąć system, a jaka pozostaje przy człowieku. Pytanie brzmi prosto. Odpowiedź często taka nie jest, ponieważ granica nie leży w samej decyzji, lecz w tym, co organizacja wokół niej zorganizowała.

Dlaczego na to pytanie nie da się odpowiedzieć za pomocą listy

Nie istnieje stała lista decyzji, które z definicji muszą pozostać ludzkie. Decyzja o zwolnieniu, odmowa udzielenia kredytu, ocena medyczna: to przykłady często przywoływane, ale powód, dla którego są delikatne, różni się w zależności od organizacji. W jednej instytucji chodzi o odpowiedzialność prawną, w innej o nieodwracalność wyniku, w trzeciej o brak odpowiedniego marginesu błędu. Kto kopiuje listę od innej organizacji, kopiuje odpowiedź bez zadania sobie pytania.

Co działa, to rozłożenie samej decyzji na czynniki: jaki jest wpływ, gdy coś pójdzie źle, czy wynik da się naprawić, i czy jest ktoś, kto może ten wynik opowiedzieć i za niego odpowiadać. Te trzy pytania leżą u podstaw tego, co gdzie indziej nazywa się regułami agentów: ustalonymi granicami, które określają, kiedy system może kontynuować pracę, a kiedy musi się zatrzymać i włączyć człowieka.

Dlaczego to pytanie organizacyjne, a nie techniczne

Wielkie jest pokuszenie, by przekazać to pytanie działowi IT, jak gdyby chodziło o ustawienie, które konfiguruje się jednorazowo. To nie działa, z prostej przyczyny: reguła agenta jest wiarygodna tylko wtedy, gdy organizacja wokół niej jest w porządku. Jeśli nikt nie wie, kto jest właścicielem procesu, nikt nie może określić, kto jest punktem eskalacji. Jeśli dane nie są w porządku, system nie wie, kiedy trafia na wyjątek wymagający udziału człowieka. Podstawowe wymiary organizacji — zarządzanie, infrastruktura, zarządzanie danymi — mają zatem pierwszeństwo przed pytaniem, które decyzje mogą zostać zautomatyzowane. Bez tej podstawy każda granica, którą wyznaczy Pan/Pani, jest granicą jedynie na papierze.

To jest jednocześnie powód, dla którego to pytanie rzadko żyje w jednym miejscu organizacji. Dyrekcja widzi ryzyko, CIO widzi wykonalność techniczną, właściciel procesu widzi codzienną praktykę. Jak sprowadzić te trzy perspektywy do jednego punktu, zanim tempo automatyzacji stanie się źródłem niezgody, opisano na stronie jak prowadzić rozmowę o tempie między zarządem a dyrekcją. Kto zadaje to pytanie dopiero, gdy pierwszy pilotaż już trwa, zadaje je za późno.

Co pomiar dojrzałości robi, a czego nie robi

Pomiar dojrzałości hybridresourcing.com pokazuje, czy organizacja ma podstawy, by wyznaczać takie granice w sposób sensowny. Siedem wymiarów, pięć poziomów od baseline do intelligence, oraz runda plotowania, w której kilka osób ocenia niezależnie od siebie. Ten rozrzut jest często najbardziej użytecznym elementem: jeśli CHRO ustawia dojrzałość danych na activation, a CIO na baseline, wiadomo, że najpierw musi odbyć się rozmowa, zanim powstanie reguła na papierze, której nikt nie będzie w stanie wykonać.

Czego pomiar nie robi, to nie mówi, która decyzja w Pana/Pani organizacji może zostać zautomatyzowana. Mierzy gotowość, nie przydatność konkretnego zadania. Mówi, czy organizacja może unieść to, co AI potrafi, nie co AI konkretnie by przejęło. To rozróżnienie między unoszeniem a przejmowaniem to różnica między niesieniem AI a przejmowaniem przez AI, i jest to rozróżnienie, które ta strona świadomie zachowuje: wynik pomiaru nie jest przepustką i nie jest zakazem, jest zdjęciem stanu, w jakim organizacja znajduje się w danym momencie.

To zdjęcie się starzeje. Organizacja, która dziś w zakresie zarządzania danymi ma wynik foundation, za rok może być na poziomie activation, albo równie dobrze może się tam zatrzymać. Jak często warto powtarzać pomiar i od czego to zależy, można przeczytać na stronie jak często należy powtarzać pomiar dojrzałości. Jednorazowy pomiar, który znika w szufladzie, ma małą wartość; pomiar, który ponownie uruchamia rozmowę w dyrekcji, ma wartość dużą.

Czego to nie rozwiązuje

Pomiar nie rozwiązuje różnicy opinii w Pana/Pani dyrekcji. Uwidacznia ją, a to nie jest to samo. Jeśli Pana/Pani zarząd i dyrekcja od dłuższego czasu nie zgadzają się co do tempa wdrażania AI, przyczyna często leży głębiej niż w braku faktów: chodzi o apetyt na ryzyko, o to, kto jest za co odpowiedzialny, o to, co się dzieje, gdy ktoś otwiera okno czatu i myśli, że dzięki temu wprowadził AI do organizacji. To, czego nie widać, gdy zna się tylko okno czatu, jest właśnie tą częścią organizacji, o którą chodzi w tym pytaniu: infrastruktura, reguły, ludzie, którzy wiedzą, kiedy system musi się zatrzymać. Dlaczego Pana/Pani dyrekcja nie zgadza się co do tempa, wyjaśniono na tej stronie, i często bardziej użyteczne jest przeprowadzenie tej rozmowy najpierw, niż czekanie, aż pilotaż się zatrzyma i pytanie i tak wróci na stół.

Od gotowości do zadania

Ta strona dotyczy granicy, którą wyznacza się z góry: jaka decyzja pozostaje przy człowieku, niezależnie od tego, co system technicznie potrafi. Gdy ta granica jest już z grubsza wyznaczona, pytanie przesuwa się w kierunku samej pracy: jakie zadania w ramach tej granicy są odpowiednie do przekazania, a jaka część funkcji, niezależnie od gotowości organizacji, pozostaje pracą ludzką. Na to pytanie pomiar dojrzałości nie odpowiada. Skan pracy FTE TO AI oblicza dla każdego zadania, jaka część pracy może zostać przejęta przez AI, i tym samym łączy się z punktem, w którym ta strona się kończy: nie czy Pana/Pani organizacja jest gotowa, ale co konkretnie leży na półce do przekazania, gdy będzie gotowa.