Dlaczego projekt AI kończy się na dziale IT, a nie przy pracy

Projekt AI, który zatrzymuje się na dziale IT, to zwykle nie problem techniczny. To projekt, który nigdy nie zyskał właściciela poza IT. IT budowuje model, potok danych, integrację — i czeka na kogoś, kto powie, jaka praca ma teraz przebiegać inaczej. Jeśli takiej osoby nie ma, albo nie ma ona mandatu, projekt zostaje tam, gdzie go zbudowano.

Przesunięcie, które już dzieje się dzisiaj

W częściach każdej firmy praca już się przesuwa. Nie jako ogłoszenie, lecz jako praktyka: część pracy system może wykonać samodzielnie, część pracy system może wykonać, o ile człowiek zatwierdza lub odrzuca wynik z uzasadnieniem, a część pozostaje pracą ludzką, ponieważ osądu, odpowiedzialności lub kontaktu z klientem nie można od niej oddzielić. Ten podział na trzy części przebiega praktycznie przez każdy proces — nie na poziomie działu, lecz na poziomie zadania.

Różnica między firmą, w której to działa, a firmą, w której projekt zatrzymuje się na dziale IT, rzadko leży w technice. Leży w tym, kto ustalił, które zadania należą do jakiej kategorii, i kto ma uprawnienia, aby powiedzieć: ta praca się przesuwa, a ta pozostaje jak jest. Bez tego ustalenia IT budowuje coś, czego nikt nie odważy się wdrożyć do produkcji, bo nikt nie podjął decyzji, którą to wymaga.

Gdzie projekt się zatrzymuje

Projektowi AI, który zatrzymuje się na dziale IT, zwykle brakuje jednej z trzech rzeczy:

Ambicji, która wykracza poza pilotaż. Jeśli odpowiedziano na pytanie „czy możemy to zbudować”, ale nie na pytanie „jaka praca zmienia się przez to strukturalnie”, nie ma nic, co można by skalować. Którą ambicję lepiej odłożyć o rok opisuje rozróżnienie między ambicją, która jest osiągalna teraz, a ambicją, która najpierw wymaga czegoś innego.

Odpowiedzi na pytanie, co system może, a czego nie może decydować bez nadzoru. Ta odpowiedź nie leży w IT, lecz w dziale, który wykonuje pracę, oraz w compliance. Co robi Pan/Pani, gdy ambicja jest możliwa, ale compliance nie opisuje, co się dzieje, gdy technika jest gotowa, zanim gotowe są ramy.

Prawa do decyzji poza IT. Ktoś w linii biznesowej — nie w architekturze — musi móc powiedzieć, że zadanie się przesuwa i że uwolniona pojemność zostaje wykorzystana gdzie indziej. Dopóki ta decyzja leży w IT, projekt też tam zostaje, ponieważ IT nie ma tego mandatu i nie powinno go mieć.

Co test robi, a czego nie robi

Test ambicji ustala, czym jest ambicja na czterech poziomach — wizja, stan docelowy, konkretny target oraz stan, który ten target wymaga — i sprawdza dla każdego wymiaru, czy organizacja jest na to gotowa. To nie jest pomiar tego, co system potrafi technicznie. To ocena tego, co organizacja musi jeszcze uregulować, zanim praca faktycznie się przesunie: prawa do decyzji, nadzór, dane, odpowiedzialność.

Ta ocena nigdy nie jest jednoznaczna. Jest tak dobra, jak informacje, na których się opiera, a te informacje są często niekompletne w momencie, gdy zarząd zaczyna z nimi pracować. Wymiar, który wygląda na gotowy, ponieważ nikt nie zadał właściwego pytania, nie jest gotowy — taki wynik mówi w tym momencie przede wszystkim o tym, czego jeszcze nie zbadano. Odwrotnie, wymiar może wyglądać źle, choć problem jest niewielki, gdy ktoś otrzyma uprawnienia, aby go rozwiązać. Test porządkuje, w którym miejscu znajduje się organizacja; nie zastępuje badania samych zadań.

Na pytanie leżące u podstaw — jaka praca w tej firmie może faktycznie zostać przejęta przez AI, częściowo lub całkowicie — odpowiada się za pomocą skanu pracy FTE TO AI na poziomie zadania, a nie działu czy funkcji. To rozróżnienie jest potrzebne, ponieważ projekt oceniany na poziomie funkcji zawsze zatrzymuje się na dziale IT: funkcje się nie zmieniają, zadania tak.

Gdzie to wpisuje się w większą całość

Pojedynczy projekt AI, który się zatrzymuje, jest zwykle symptomem. Często nie ma ciągłego obrazu tego, jak osiem wymiarów gotowości rozwija się w czasie, i ten sam wymiar rok po roku pozostaje wąskim gardłem, bez tego, że ktoś to nazwie — zob. co robi Pan/Pani z wymiarem, który od lat się blokuje. Ambicja, która na papierze wydaje się niewielka, często wymaga capabilities, które stają się widoczne tylko wtedy, gdy ktoś ustawi je obok ośmiu wymiarów; to przełożenie jest tematem jakich capabilities potrzebuje moja organizacja dla tej ambicji. A projekt nie zatrzymuje się na dziale IT, jeśli kierownictwo już jest ze sobą w sporze o to, co ambicja oznacza — o tym mowa w jak doprowadzić mój zarząd do wspólnego stanowiska.

Do decyzji personalnych wynikających z takiego procesu zawsze mają zastosowanie odpowiednie wymogi prawne; test ambicji i gotowości nie stanowi dla nich podstawy i nie jest w tym celu przeznaczony.

Co można zrobić teraz