Technooptymizm, czyli o narzędziach do przepalania budżetu firmy

Według raportu The GenAI Divide: State of AI in Business 2025, nawet 95% firm, które wdrożyły duże modele językowe do ogólnych zastosowań, nie odnotowało żadnej wymiernej stopy zwrotu. Zero. Podobny wniosek wyciągnięto w badaniu The state of AI na zlecenie McKinseya. Czytamy w nim, że choć adaptacja generatywnej sztucznej inteligencji jest obecnie bardzo szeroka, to ponad 80% respondentów nie dostrzega namacalnego wpływu AI na poziomie całego przedsiębiorstwa.

Przywołując powyższe szacunki, nie chodzi mi o deprecjonowanie wartości sztucznej inteligencji samej w sobie, tylko o uplastycznienie bardziej złożonego zjawiska, które lubię nazywać technooptymizmem bez pokrycia.

Nie masz problemu, ale masz narzędzie

Technooptymizm ma określony rytm. Najpierw pojawia się nowe cudowne narzędzie. Potem przychodzi szum w mediach społecznościowych, wszyscy chcą je mieć, budżety puchną, wdrożenia ruszają. W końcu, po paru, najdalej parunastu miesiącach wychodzi na jaw, że zespół używa zakupionego narzędzia od święta, połowy funkcji nikt nie zna, a zwrotu z inwestycji trzeba szukać z lupą. Nie piszę tego tylko na bazie statystyk i raportów. Widzę ten mechanizm regularnie u klientów oraz w rozmowach z ludźmi, którzy po fakcie są zdumieni, jak łatwo dali się naciągnąć na zbędny zakup.

Zabawny jest fakt, że teoretycznie każdy z nas wie, jak się przed tym zjawiskiem zabezpieczyć. Przecież wystarczy najpierw zdefiniować konkretny, mierzalny problem występujący w organizacji, potem wyprowadzić z niego potrzebę, a dopiero na końcu szukać optymalnego narzędzia, które na tę określoną potrzebę odpowiada. Krótko mówiąc, należy zachować jedyną logiczną kolejność działań. Jeśli nie znasz problemu, możesz kupić najdroższe narzędzie na rynku, zamówić prawdziwy kombajn do wszystkiego – który w praktyce nie posłuży do niczego.

Narzędzie musi być środkiem, nie celem. Każdy z nas rozumie tę zasadę. I jednocześnie, na płynąc z falą technooptymistycznego entuzjazmu, każdy z nas od czasu do czasu o niej zapomina.

Zbieraj nisko wiszące owoce

Jednak zdefiniowanie problemu to tylko połowa sukcesu. Należy jeszcze zadać sobie inne pytanie: czy aby na pewno musimy kupować coś nowego, czy może wystarczy zacząć szerzej wykorzystywać narzędzie, które już posiadamy?

Nisko wiszące owoce proszą się o to, żeby je zbierać. Dopiero kiedy dorodny owoc wisi trochę wyżej, poza zasięgiem ręki, sensowne staje się kupowanie wyższej drabiny.

Przekładając to na problem narzędzi, musimy przemyśleć bilans kosztów i zysków. Po jednej stronie szali znajduje się koszt rozszerzenia już istniejącego rozwiązania na nowy obszar. Po drugiej, całkowita cena wdrożenia czegoś zupełnie nowego. Mówimy o licencji, ale też integracji, szkoleniach, czasie wdrożenia oprogramowania i nieuchronnym przejściowym spadku efektywności. Zazwyczaj to pierwsze wychodzi taniej. Nie zawsze, ale zazwyczaj.

„Mówimy o licencji, ale też integracji, szkoleniach, czasie wdrożenia i nieuchronnym przejściowym spadku efektywności”.

Sęk w tym, że zaskakująco wiele organizacji nie wie, czym już dysponuje. Excel jest tu moim ulubionym przykładem. Pospolity arkusz kalkulacyjny z pakietu Office – narzędzie dostępne wszędzie, znane każdemu i rozwijane od dekad – przez przeciętnego użytkownika wykorzystywane jest może w 10-15%. Nie inaczej bywa z bardziej zaawansowanymi platformami. Bez kogoś, kto naprawdę zna potencjał danego narzędzia – organizacja nie jest w stanie odpowiedzieć na pytanie, czy potrzebuje czegoś nowego.

Odpowiedzią jest odruch kompensacyjny. Skoro zespół nie potrafi wydobyć wartości i zarządzać narzędziem, które ma pod ręką, łatwo dochodzi do przekonania, że potrzebuje kolejnego. W ten sposób rośnie stos programów, platform i aplikacji, z których połowa robi to samo. Zamiast usprawnienia procesów dochodzi do rozpraszania danych i podnoszenia kosztu poznawczego codziennej pracy.

Co mam na myśli? Zbyt wiele aplikacji na pokładzie sprawia, że ludzie przeskakują między interfejsami, szukają tych samych informacji w kilku miejscach i obsługują dane podwójnie – a każde z tych narzędzi miało przecież skracać pracę. Ten rodzaj chaosu ma nawet swoją nazwę: SaaS sprawl.

Warto rozróżnić go od podobnego zjawiska shadow IT. W tym drugim przypadku pracownicy instalują lub subskrybują narzędzia na własną rękę, bez wiedzy, czy nawet zgody działu IT. Klasyczny przykład: zespół marketingu zaczyna używać jakiegoś niszowego programu do projektowania, płaci prywatną kartą, i nikt informatyków w firmie o tym nie wie. To działanie poza oficjalnym obiegiem. Ma swoje konsekwencje, ponieważ sprawia, że w organizacji mogą funkcjonować obok siebie systemy, o których wielu pracowników nie ma pojęcia. Ogranicza to również możliwości kontroli nad przepływem danych, w tym tych wrażliwych.

SaaS sprawl odbywa się w pełnym świetle. Zarząd zatwierdził narzędzie, IT o nim wie, faktury przechodzą przez księgowość. Problem pojawia się w momencie, kiedy tych oficjalnych, legalnie opłaconych narzędzi stale przybywa, ale nikt nie zajmuje się pilnowaniem, czy nie pełnią one bliźniaczych funkcji. Dwa różne działy kupują osobne subskrypcje do podobnych aplikacji. Oba mają przykładowo moduł do raportowania, przy czym każdy zaciąga dane z innego miejsca. Żadne z nich nie komunikuje się z drugim. Dane ulegają rozproszeniu, raporty się rozmijają, a koszt poznawczy pracy rośnie w zatrważającym tempie. Opłata za licencję to w tym wszystkim najmniejszy kłopot.

Kiedy jest TEN moment?

Załóżmy jednak, że potrzeby firmy są już rozsądnie zdefiniowane i naprawdę wiemy, czego szukamy. Kiedy właściwie wiadomo, że czas na nowe rozwiązanie?

Odpowiedź leży w mierzeniu przepustowości. Każdy proces w formie można podzielić na ogniwa, gdzie każde ogniwo ma swoją wydolność – określoną liczbę operacji, które jest w stanie obsłużyć w jednostce czasu. Jeśli masz tę liczbę i śledzisz, ile operacji faktycznie wykonujesz, masz wczesne ostrzeżenie. Kiedy docierasz do 80% przepustowości, a prognozy wskazują na dalszy wzrost, to jest moment, żeby szukać rozwiązania. Najlepiej jeszcze przed tym, zanim ogniwo pęknie.

Wymaga to jednak pewnej dyscypliny operacyjnej. A co w organizacjach, które tej dyscypliny nie mają – albo po prostu tego nie śledzą? Wtedy wąskie gardła wychodzą same. Manifestują się w postaci frustracji, przeciążenia, błędów, rotacji ludzi. To jest droższy alarm, ale działa. Jeśli słyszysz sygnały z zespołu o tym, że coś jest za wolne, za trudne, za dużo – to już jest problem, który powinien być sygnałem do szukania rozwiązania. Nie na następny rok, tylko na zaraz.

Kto powinien zarządzać narzędziami?

Decyzja o wdrożeniu narzędzia zależy od polityki wewnętrznej każdej organizacji. Tu też rządzą schematy. Albo ostatnie słowo należy do samego CEO, często najbardziej podatnego na uroki technooptymizmu; albo decyduje dział IT, który z kolei nie zawsze rozumie kontekst biznesowy; albo – co chyba najgorsze – każdy oddział firmy decyduje osobno, bez spójnej wizji stosu technologicznego.

Moim zdaniem optymalne podejście to rodzaj „komitetu”, zdolnego połączyć w sobie dwie kluczowe funkcje:

• Funkcja finansowa. Każde wdrożenie powinno mieć zbadaną i zrozumiałą dla wszystkich ścieżkę prowadzącą do mierzalnej wartości: wzrost przychodów, albo przez obniżenie kosztów. Bez tego jest to po prostu zakup na wiarę.
• Funkcja techniczna. Odpowiedzialna za spójność z istniejącym stosem. Narzędzie, które świetnie działa w izolacji, ale nie integruje się z resztą infrastruktury, generuje nieoczywiste koszty, ukryte i nawarstwiające się przez kolejne lata.

Prosty przykład. Jeśli organizacja żyje w ekosystemie Microsoftu, to produkt z tej samej stajni ma na starcie lepszą integrację z tym, czego codziennie używają ludzie. To nie znaczy, że zawsze jest koniecznie najlepszy ze wszystkich programów na rynku. Ale koszt asymilacji zewnętrznych rozwiązań jest realny, wysoki i wpływa na końcowy rachunek.

Dowód wykonalności

A co po zakupie licencji? Jedna z najdroższych iluzji w organizacjach brzmi mniej więcej tak: zamówiliśmy świetne narzędzie, więc problem jest rozwiązany. Wystarczy to jako tako skonfigurować, a reszta jakoś się ułoży.

Nie, samo nic się nie układa. Jeżeli w to uwierzysz, to prawdopodobnie czeka Cię następujący scenariusz: projekt pilotażowy wszystkich zachwyci, demo zda egzamin, na spotkaniu wszyscy wstaną i będą klaskać.

A potem narzędzie wyląduje w szufladzie, gdzie zostanie zapomniany.

W branży funkcjonuje termin Proof of Concept (PoC), czyli po polsku dowód wykonalności. To taki wstępny tekst pokazujący, że rozwiązanie może działać perfekcyjnie – przynajmniej od strony technicznej, w kontrolowanych warunkach, na wyselekcjonowanych danych, obsługiwany przez ludzi, którzy to zbudowali. PoC nie dowodzi natomiast, że narzędzie będzie funkcjonować stabilnie z prawdziwymi danymi, prawdziwymi użytkownikami, prawdziwymi kosztami operacyjnymi i zwykłym codziennym chaosem. Różnica jest zasadnicza. Coś może działać na papierze i podczas prezentacji, a jednocześnie kompletnie nie nadawać się do stabilnego stosowania na co dzień. Firmy inwestują w pilotaż, ogłaszają sukces i próbują skalować rozwiązanie, zanim odpowiedzą sobie na elementarne pytania, dotyczące integracji czy codziennego zarządzania tematem.

Konieczne jest rozważne zarządzanie narzędziami w firmie. Bez intensywnego szkolenia i pokazania ludziom, jak konkretne oprogramowanie wnosi wartość do ich rutynowej pracy (ważne: nie abstrakcyjnie, ale konkretnie w ich zadaniach), większość będzie korzystać z 10% możliwości, albo nie będzie korzystać wcale. Jest to przepalanie budżetu w najczystszej postaci.

Pozostaję zwolennikiem wymogu, aby wraz z zamówionym narzędziem dostarczać zespołowi wzorzec jego użytkowania na konkretnym stanowisku. Nie ma sensu, żeby ktoś musiał samodzielnie badać funkcje, które odkrył i przetestował ktoś inny już dawno temu. Najlepsze praktyki powinny być punktem startu, nie punktem dojścia. Odkrywanie własnych skrótów, preferencji i trików – jak najbardziej, niech każdy szuka. Ale podstawy? Te powinny zostać dostarczone na etapie wdrożenia.

Łatwość wejścia i… wyjścia

A co się stanie, kiedy w bliższej lub dalszej przyszłości zechcemy z zakupionego rozwiązania zrezygnować? Żyjemy w dynamicznym środowisku technologicznym. Narzędzia powstają, znikają, są przejmowane, zmieniają modele cenowe, przestają być aktualizowane lub rozwijane. Nawet jeżeli narzędzie samo w sobie pozostaje dziś przydatne, musimy sprawdzić, czy nie po cichu nie krępuje nam ono rąk. Wchodząc do nawet najpiękniejszego ogrodu, warto mieć pewność, że nikt nie zamyka za nami furtki.

Szczególnym i coraz powszechniejszym przejawem tego niebezpieczeństwa jest tzw. vendor lock-in. Sytuacja, w której organizacja tak głęboko wrasta w ekosystem jednego dostawcy oprogramowania, że wyjście staje się technicznie karkołomne i finansowo bolesne. Dane zapisywane są w ich formacie, procesy zbudowane wokół ich API, zespół zna tylko ich specyficzny interfejs. Nawet jeżeli formalnie możesz odejść w każdej chwili, koszt migracji i przepisania integracji sprawia, że zostaniesz na długie lata. A vendor o tym wie, co przy kolejnych odnowieniach kontraktu zwykle przekłada się na wzrost cen subskrypcji.

Z tego powodu kryteria wyboru narzędzia, które stosuję, obejmują nie tylko cenę wdrożenia i nauki, koszt bieżącej obsługi, czy możliwość integracji, ale również potencjalny koszt wyjścia. Dopiero te cztery wymiary razem dają dość przyzwoity obraz tego, co właściwie kupujemy. Uwzględniam nie tylko funkcjonalność usługi, ale całą ekonomię stojącą za rozważaną decyzją.

Nie każda organizacja potrzebuje nowego narzędzia. Zwykle bardziej potrzebuje dobrej diagnozy – i właśnie od tego zaczynamy pracę z naszymi klientami.