Sektor ICT w dużej mierze składa się z pracy, którą można podzielić na rozpoznawalne etapy: pisanie kodu według specyfikacji, testowanie względem ustalonych kryteriów, prowadzenie dokumentacji, klasyfikowanie zgłoszeń, konfigurowanie infrastruktury, sporządzanie raportów. Obok tego istnieje praca, której właśnie nie da się ująć w etapy: wybór architektury, który zaważy na latach, klient opisujący problem, którego jeszcze nikt nie rozwiązał, zespół musiał wyważyć termin i wymóg jakościowy względem siebie. Oba rodzaje pracy występują w tych samych funkcjach, często u tej samej osoby tego samego dnia.
Ta mieszanka wyjaśnia, dlaczego AI nie pojawia się tu jako projekt, lecz jako pełzająca zmiana. Część pracy zawsze była pracochłonna, choć nie była złożona: przekształcanie kodu z jednego języka na inny, generowanie skryptów testowych, przeszukiwanie logów pod kątem znanego wzorca. Gdy AI przejmuje tę część w całości lub częściowo, na papierze nic się nie zmienia w strategii — mapa drogowa, obietnica wobec klienta, poziom usług pozostają takie same — ale założenie leżące u ich podstaw, czyli ile osób i godzin potrzeba, by tę obietnicę zrealizować, przestaje być automatycznie prawdziwe.
Tego, co dzieje się w ICT, nie da się streścić jako „AI zastępuje programistów”. Praca dzieli się na trzy kategorie, które przebiegają przez niemal każdą funkcję. Niektóre zadania AI może wykonywać samodzielnie: generowanie ustrukturyzowanego kodu, przekłady między systemami, powtarzalne testy. Inne zadania przebiegają częściowo: AI przedstawia propozycję — zmianę w kodzie, ocenę ryzyka, podsumowanie incydentu — a człowiek ją zatwierdza lub odrzuca, z odnotowanym powodem. A trzecia kategoria pozostaje pracą ludzką: rozmowa z klientem o tym, co właściwie ma na myśli, decyzja o wdrożeniu systemu do produkcji lub nie, odpowiedzialność za to, co pójdzie nie tak.
Podział między tymi trzema kategoriami nie jest stały. W firmie z dużą ilością systemów legacy i słabo ustandaryzowaną dokumentacją udział trzeciej kategorii jest wyższy niż w firmie z nowoczesną, dobrze udokumentowaną infrastrukturą. W zespole, który organizuje nadzór jako stały element procesu — kogoś, kto rzeczywiście ocenia propozycje AI, a nie tylko je zatwierdza jednym kliknięciem — więcej pracy przesuwa się do drugiej kategorii bez utraty jakości. W zespole bez takiego nadzoru AI pozostaje ograniczone do pojedynczych eksperymentów i niewiele się zmienia, mimo że technologia jest dostępna.
Powód, dla którego dotyczy to stołu zarządu, a nie tylko działu IT, jest taki, że strategie w tym sektorze często opierają się na założeniu dotyczącym pojemności: ile pojemności deweloperskiej potrzeba, by zrealizować mapę drogową, ile pojemności wsparcia, by utrzymać poziom usług, ile czasu seniorów, by szkolić juniorów. Jeśli AI przejmuje część pracy z pierwszej lub drugiej kategorii, zmienia się liczba uwolnionych godzin i pojemności fte — nie o stały procent, to zależy od systemów, dyscypliny w procesie i stopnia nadzoru, ale kierunek zmiany jest pewny.
Pytanie strategiczne brzmi więc nie, czy AI przejmuje pracę, lecz czy plan wciąż zakłada dawny podział. Mapa drogowa oparta na stałej pojemności deweloperskiej, model cenowy zakładający stałą liczbę godzin wsparcia na klienta, program szkoleniowy zbudowany na założeniu, że praca juniora pozostaje taka sama — to wszystko założenia, które przez tę zmianę mogą wygasnąć bez ogłoszenia. Nikt ich formalnie nie wycofuje; po prostu pozostają w planie, podczas gdy rzeczywistość pod nimi się zmienia. To inny wzorzec niż na przykład w usługach finansowych, gdzie regulacje częściowo wyznaczają tempo automatyzacji, czy w budownictwie, gdzie fizyczna realizacja stawia inną granicę temu, co AI może przejąć. W ICT granica jest często mniej fizyczna i mniej prawna, a przez to szybciej się przesuwa — co raczej zwiększa niż zmniejsza ryzyko milcząco przestarzałego założenia.
Dwie firmy w tym samym podsektorze mogą wyglądać tu bardzo różnie, a różnica ta rzadko tkwi w dostępności narzędzi AI — te są dostępne dla obu. Tkwi ona w tym, czy istnieje działający mechanizm nadzoru, który ocenia wyniki AI z odnotowanym powodem, czy dokumentacja i systemy są w porządku, tak by AI mogła z nich coś zrobić, oraz czy zarząd niedawno kazał zweryfikować założenia leżące u podstaw strategii względem tego, co operacyjnie już się zmieniło. Firmy bez tego ostatniego sterują strategią, która na papierze wciąż się zgadza, podczas gdy leżące u jej podstaw założenie o pojemności dawno zostało wyprzedzone.
Ta zmiana dotyczy również pytania, kto powinien siedzieć przy stole podczas takiej weryfikacji — nie tylko zarząd, ale też osoby, które faktycznie widzą, jak praca się zmienia, co opisano w przeglądzie tego, kto powinien uczestniczyć w przeglądzie strategii. O ile ta zmiana dotyka decyzji personalnych, obowiązują dla nich odrębne wymogi prawne; ta strona dotyczy strategii, nie tych decyzji.
Na pytanie leżące u podstaw — którą pracę w tej firmie AI może rzeczywiście przejąć, którą częściowo, a która pozostanie pracą ludzką — odpowiada się za pomocą skanu pracy FTE TO AI, zadanie po zadaniu, zamiast na podstawie szacunku dla całego sektora. Zanim ten skan wchodzi w grę, jest mniejszy krok: bezpłatna kontrola założeń, krótka runda, w której wskazuje Pan/Pani swoje najważniejsze założenia strategiczne i przy każdym z nich widzi, kiedy ostatnio zostało ono faktycznie potwierdzone. Dzięki temu widać, które założenia wciąż stoją mocno, a które po cichu zaczęły się przesuwać. Pełny strategiczny test odporności, zestawiający obraz z zewnątrz z autooceną zarządu, jest w przygotowaniu.
Stel uw vraag. Vaak zit de echte vraag een laag dieper — daar mag ik naar vragen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.