Dostawca usług ICT składa się z warstw pracy, które mają ze sobą niewiele wspólnego. Jest budowa i utrzymanie kodu, jest rozwiązywanie zgłoszeń i incydentów, jest architektura i projektowanie, jest zarządzanie projektem w kierunku klienta, i jest presales: oferty, proof of concept, techniczne uzasadnienie przetargu. W tych kategoriach liczba godzin różni się ogromnie w zależności od zlecenia. Dział wsparcia działa na wolumenie i powtarzalności. Zespół architektury działa na niewielkiej liczbie osób z dużym doświadczeniem. Wynik transakcji jest determinowany przez to, którą z tych warstw klient uznaje za najważniejszą, a to różni się w zależności od przetargu, klienta i momentu w projekcie.
Trzy kategorie, które występują wszędzie — AI przejmuje zadanie, AI pracuje w kierunku wyniku z człowiekiem, który zatwierdza lub odrzuca, albo praca pozostaje pracą ludzką — przebiegają przez cały sektor ICT, i nie równomiernie. Obsługa zgłoszeń dla znanych problemów jest częściowo możliwa do zautomatyzowania; pierwsza triage, rozpoznanie wzorca, zaproponowanie rozwiązania na podstawie wcześniejszych przypadków. Generowanie kodu dla rutynowych fragmentów oprogramowania przesuwa się w kierunku AI z recenzentem, który zatwierdza wynik. Decyzje architektoniczne, tłumaczenie niejasnego życzenia klienta na działający system oraz utrzymywanie zaufania u zleceniodawcy pozostają na razie pracą ludzką, ponieważ wymagana jest tam ocena, której nie da się wyprowadzić z wzorca w istniejących danych.
Przesunięcie, które to powoduje, nie dotyczy tego, czy AI dobrze radzi sobie z kodowaniem. Dotyczy tego, co dzieje się z porównaniem między dostawcami, gdy część tej pracy dzieje się sama. Czas reakcji na wsparcie był wynikiem obsady i planowania; jeśli triage odbywa się w dużej mierze automatycznie, szybkość nie jest już dowodem dobrego zespołu, lecz dobrze skonfigurowanego systemu, a taki system konkurenci mogą równie dobrze kupić lub zbudować. Co wtedy pozostaje jako wyróżnik, to nie sama szybkość, lecz to, co dzieje się w przypadkach, których system nie rozwiązuje — kto przez to przechodzi, a kto zostawia klienta czekającego.
Ten sam wzorzec występuje w procesach ofertowych. Ułożenie technicznej propozycji z istniejących komponentów jest pracą, którą można częściowo zautomatyzować. Gdy dzieje się to u kilku podmiotów w jednym przetargu, przesuwa się to, w czym klient wciąż widzi różnicę: nie w szybkości propozycji, lecz w tym, czy propozycja jest właściwa dla tej konkretnej sytuacji, i w tym, kto może to wyjaśnić bez oparcia się na szablonie.
Czy firma ICT już tak to zorganizowała, zależy od tego, gdzie kieruje swoich ludzi. Podmiot, który swoich doświadczonych architektów wciąż w dużej mierze angażuje do pisania standardowego kodu, zostawia niewiele zdolności na rozmowę z klientem, w której zapada decyzja o transakcji. Podmiot, który już przesunął tę pracę — AI dla rutynowej części, ludzie dla oceny — uwolnił te godziny właśnie na ten element, na którym teraz się wygrywa. Nie jest to wybór podejmowany w jednym kwartale; wynika z wcześniejszych decyzji dotyczących narzędzi, tego, kto wykonuje jaki rodzaj pracy, oraz tego, jakie zaufanie organizacja ma do nadzoru nad zautomatyzowanym wynikiem. To, co pracodawca robi w związku z tym ze swoim personelem, jest sprawą pracodawcy; obowiązują tu odrębne wymogi prawne, niezależnie od tego, jaka praca jest technicznie możliwa do przekazania.
Ta dynamika nie jest unikalna dla ICT. To samo przesunięcie — od wolumenu i szybkości do oceny i wyjaśnienia — przebiega inaczej w sektorze usług finansowych, gdzie punktem zaczepienia są porada i ocena ryzyka, a jeszcze inaczej w budownictwie, gdzie planowanie i kalkulacja się przesuwają, ale wykonanie na placu budowy pozostaje pracą ludzką. Na pytanie, jaka praca w tej konkretnej firmie już się przesunęła, a jaka nie, można odpowiedzieć za pomocą [skanu pracy, który dla każdego zadania ocenia, czy AI je przejmuje, częściowo przejmuje pod nadzorem, czy nie](https://ftetoai.nl) — jest to odrębny krok, niezależny od porównania z konkurencją.
Ryzyko tego przesunięcia nie polega na tym, że dostawca przegrywa, lecz na tym, że nie wie, na czym przegrywa. Oferta, która mówi, że jest szybsza, strona internetowa obiecująca stabilność, prezentacja handlowa oparta na ekspertyzie — to wszystko są twierdzenia, a twierdzenia stają się przewagą tylko wtedy, gdy można je uzasadnić w porównaniu z tym, co klient widzi u innych. Kto stwierdził już zaległość w jednym wymiarze, może przeczytać w podejściu do nadrabiania zaległości w konkretnym wymiarze, jakie są tam opcje, a kto chce udokumentować twierdzenie, zanim klient o nie zapyta, znajdzie w weryfikacji własnych twierdzeń o jakości pod względem uzasadnienia, jak to zrobić systematycznie.
Określ, na czym Pana/Pani firma uważa, że wygrywa — szybkość, cena, ekspertyza, wiarygodność — i sprawdź, które z tych twierdzeń jest Pan/Pani w stanie już dziś poprzeć dowodami w porównaniu z konkurentem. To właśnie robi bezpłatny test wymiarowy: nie pełny benchmark, ale pierwszy obraz tego, które twierdzenia są solidne, a które wciąż wisiedzą w powietrzu. Pełny benchmark konkurencyjny, z matrycą dowodową dla każdego wymiaru, jest w budowie.