Od czego zacząć realne wdrożenia AI? (podsumowanie webinaru)
Jak wytypować pierwszy proces, policzyć, czy wdrożenie się opłaca, i przekonać zarząd, który słyszał na konferencji o 300% przyspieszenia? W drugim live'ie AI Leaders rozmawialiśmy o małych krokach, które faktycznie prowadzą do dużych przyrostów.
„Najlepiej wydane pieniądze na sztuczną inteligencję to pieniądze zainwestowane w..." - tym niedokończonym zdaniem Paula Skrzypecka otworzyła drugi live AI Leaders, 31 sierpnia o 19:00. Gośćmi byli Inga Apiecionek, która na co dzień prowadzi wdrożenia AI u klientów, oraz Przemek Jurgiel-Żyła, z funduszu Movens Capital.
Rozmawialiśmy o tym, jak wdrażać AI małymi krokami, tak żeby doprowadziły do sensownego rezultatu biznesowego, a nie do kolejnego efektownego eksperymentu. Paula od razu uprzedziła, że fanką małych kroków nie jest, więc będzie upierdliwa.
(link do nagrania na końcu artykułu)
Najlepiej i najgorzej wydane pieniądze
Dla Ingi najlepiej wydane firmowe pieniądze to te, które realnie zmieniają procesy albo przebudowują duży kawałek biznesu, na przykład odwracają flow dostarczania produktów do sklepu. Przemek dorzucił swoje kryterium: dobre wdrożenie coś upraszcza i przyspiesza, a nie dokłada ludziom nowego procesu do obsługi.
Najgorzej? Licencje ChatGPT dla wszystkich pracowników „na YOLO", bez pokazania przykładów i bez sprawdzenia, czy ktokolwiek z nich korzysta. Drugi wariant to brak liczenia pieniędzy: jeśli dział IT może na dowolnym poziomie palić tokeny na najszybszych modelach po API, firma zobaczy kiedyś rachunek, którego się nie spodziewała. Trzeci Inga zna jako najbardziej kosztowny w długim terminie. Projekt będący oczkiem w głowie prezesa: ktoś był na konferencji, zobaczył demo i firma musi to mieć, bez pytania zespołu, jak ludzie naprawdę pracują.
(artykuł dostępny jest pod adresem: aileaders.pl/od-czego-zaczac-realne-wdrozenia-ai-podsumowanie-webinaru - jeśli jeszcze nie jesteś zapisany/-a na nasz newsletetter, to zapraszamy do zostawienia swojego maila)
Jak wytypować pierwszy proces
Jeżeli w firmie nie robiliście jeszcze nic, najważniejsze jest zacząć. Inga ostrzegała przed pułapką odwrotną: jeśli otworzycie temat od wielkiej tabelki decyzyjnej i ustalania parametrów oceny, spalicie się, zanim zrobicie pierwszy krok. Frameworki poukładają się po drodze.
Sam framework działa raczej jak sito, które odsiewa procesy nienadające się na początek. Zanim wybierzesz pierwszy, sprawdź:
- Czy jest właściciel biznesowy, czyli osoba, która odpowiada za ten proces i której zależy na wyniku.
- Czy masz dostęp do danych. Przemek dodał pytanie kontrolne: czy dane są w ogóle wyekstrahowane, bo bywają skanami albo papierem.
- Czy umiesz policzyć, ile ten proces kosztuje dzisiaj.
- Czy masz metrykę, którą ocenisz, czy eksperyment się udał.
Przemek zaczął z drugiej strony: od tego, co w organizacji najbardziej boli. Warunkiem wstępnym jest wiedza o własnych procesach, bo część firm nie ma ich zmapowanych. Potem szukaj procesu powtarzalnego, którego nikt nie chce robić, takiego gorącego kartofla przerzucanego między działami.
Inga zwróciła uwagę, że na warsztatach najpierw pada wierzchołek góry lodowej: generowanie treści, czyszczenie danych. Dopiero po dłuższej rozmowie o tym, gdzie zespół realnie przepala czas, okazuje się, że najbardziej bolące punkty siedzą w zakamarkach, o których nikt nie chce myśleć.
Licz cały proces, nie pojedynczy etap
Pytanie od widza z LinkedIna: jak policzyć czas, który idzie na sprawdzenie tego, co wyprodukowało AI? Czy są zadania, w których AI pracuje szybciej, ale cały proces staje się droższy, bo rośnie koszt kontroli?
Inga policzyła to na przykładzie artykułu. Sprawna osoba pisze tekst w dwie godziny. Wersja z agentem: pół godziny na spromptowanie, kilka minut i kilka dolarów na wygenerowanie, a potem trzy godziny weryfikacji danych i poprawiania języka. Uzysku nie ma. Ale ten sam rachunek wygląda inaczej dla kogoś, kto tej biegłości nie ma i wyjściowo potrzebowałby nie dwóch, tylko ośmiu czy szesnastu godzin.
Podobnie w developmencie. Na generowaniu kodu oszczędność jest realna, ale trzeba doliczyć dobre opisanie zadania i sprawdzenie, czy wynik jest zgodny z architekturą. Uzysk wychodzi wtedy nie dwa razy, tylko na przykład 20%. I to jest liczba, z którą warto iść do zarządu, który usłyszał na konferencji o 300%.
Czy 20% wystarczy? Zależy, ile te 20% waży. Jeśli wytworzenie technologii kosztuje pół miliona złotych, a optymalizacja oszczędza 10 tysięcy miesięcznie, rachunek się nie spina. Liczyć trzeba całość: wdrożenie, utrzymanie w całym okresie i zmienność cen modeli. Z drugiej strony 20% bywa dużo, jeśli przy okazji nie generujesz długu technologicznego i odblokowujesz zasoby, które szły na testowanie i naprawianie usterek z przeszłości. Znaczenie ma punkt wyjścia: Inga podała przykład optymalizacji systemu decydującego o przepływach finansowych, gdzie szacowany wzrost marży o 2 do 3%, policzony kontrfaktycznie na danych historycznych, dotyczył skali 10 miliardów złotych.
Osobna sprawa to dobór wskaźnika. Liczba wygenerowanych treści nie jest KPI, bo nie mówi nic ani o koszcie, ani o przychodzie. Jeśli treści obsługują klientów, mierz NPS. Jeśli są publiczne, mierz zasięg wśród nowych odbiorców. Koszt dzisiejszy złap w roboczogodzinach. Produktywność też nie sprowadza się do czasu: to samo zadanie w tym samym czasie może być zrobione dwa razy lepiej. Część wdrożeń robi się zresztą dla wizerunku. Odwrotne ustawienie również jest strategią: „działamy craftowo, nie używamy AI" profiluje ofertę równie skutecznie.
Bywa wreszcie tak, że pierwsze wdrożenie w ogóle nie polega na sztucznej inteligencji, tylko na doborze lepszych narzędzi. Przemek opisał warsztat w izbie gospodarczej, gdzie problemem nie była niechęć do AI, tylko brak narzędzi: zespół ręcznie przeglądał 30 stron ministerstw, żeby zebrać materiał do newslettera. AI nie pisało tych newsletterów lepiej, pomogło znaleźć rozwiązania, które zebrały dane w jednym miejscu. Paula dorzuciła pytanie, które musiało paść: czy sprawdziły, że mogą te strony skrapować.
Jak przyjść z tym do zarządu
Punkt zero: znać nastawienie zarządu i wiedzieć, na co ci ludzie zwracają uwagę.
Potem, zdaniem Ingi, zaczynasz od bolącego problemu opisanego liczbami. Ile czasu dział traci, jaka okazja wam ucieka. Nie od tego, że masz fajny model albo że byłeś na kursie. Zaraz za tym pokazujesz, dokąd chcesz dojść i jakimi krokami. Kroki są istotne, bo częstym błędem jest obiecanie zarządowi punktu docelowego, do którego droga okazuje się bardzo długa. Lepiej dać roadmapę z przyrostami i momentami weryfikacji, czy warto iść dalej.
Przemek dołożył regułę z prowadzenia spółek: pokazuj rozwiązania, nie problemy. „Mamy taki problem, proponujemy takie rozwiązanie" rozmawia się dużo lepiej niż „mamy taki problem, znajdźcie sposób". Liczy się też zaangażowanie wnioskodawcy, bo człowiek z obserwacjami, pomysłem i ścieżką dojścia jest punktowany wyżej niż ktoś, kto zgłasza problem i czeka, aż ktoś inny coś z nim zrobi.
Jeśli organizacja nie jest przekonana do AI, nie zaczynaj od kobyły. Duży projekt oznacza dużą inwestycję, przesuwanie zasobów i większy opór po stronie odbiorcy komunikatu. Nisko wiszące owoce pokazują, że da się szybko i tanio optymalizować, a przy okazji uczą ludzi, że AI ich nie zastępuje. A co, jeśli propozycja okaże się błędna? Przemek odpowiedział z perspektywy inwestora: fundusz lubi ludzi, którzy nie boją się popełniać błędów, bo wygrywają ci, którzy podejmują ryzyko.
Chmura czy własne serwery
Kolejne pytanie od widza: czy dominują modele zewnętrzne i chmura, czy własne serwery z GPU i pełna lokalizacja danych.
Zdaniem Przemka większość wdrożeń opiera się na infrastrukturze, która już istnieje (cloud). Własna wymaga konkretnego uzasadnienia: dane muszą być wyłącznie wasze, bo obliguje do tego ustawa (bank, instytucja płatnicza, windykacja), potrzebujecie wysokiej niezawodności albo przewidywalności, na przykład przy własnym, mocno sfine tunowanym modelu. Poza tymi przypadkami to głównie dodatkowe koszty, bo zanim skończycie setup, technologia będzie już dalej.
Inga potwierdziła to od strony przetargów, gdzie własna infrastruktura bywa wpisana jako must have. Jej firma przedstawia wtedy dwa cenniki: wariant przez API, z modelami dostępnymi w Unii Europejskiej, odizolowanymi i bez trenowania na danych klienta, oraz wariant enterprise na infrastrukturze klienta. Najwięcej klientów ostatecznie wraca do pierwszego ze względów kosztowych.
Nieudany projekt, który zostawia fundament
Co jeśli projekt nie dowiózł zakładanego zwrotu, ale po drodze powstał komponent używany dziś w innym procesie? Dla Ingi to sukces, pod warunkiem że firma przyzna się do wyniku i wyciągnie wnioski. Zespół nauczył się liczyć, pierwotny projekt mógł wyewoluować, a gotowe komponenty stają się podstawą narzędziownika dla kolejnych wdrożeń.
Przemek radził przestawić myślenie na eksperymenty. Błędy będą, a AI pozwala dojść do pierwszych wniosków szybciej i przetestować więcej wariantów. Granica jest jedna: powtarzanie w kółko tego samego błędu z nadzieją, że za jedenastym razem zniknie, nie jest eksperymentowaniem. Duża firma jest przy tym jak toczący się walec, który da się delikatnie korygować, a mała powinna skupić się na skokach do przodu, a nie na analizowaniu, dlaczego but na chwilę przykleił się do asfaltu. Częścią wspólną, jak podsumowała Paula, jest umiejętność podejmowania decyzji.
Co zostawić po projekcie
Najtańszy kolejny projekt to taki, który korzysta z tego, co już zbudowaliście. Inga proponuje sprawdzić, czy z gotowego fragmentu mogą skorzystać inne działy oraz czy istnieją procesy sąsiadujące, oparte na tych samych danych i integracjach. Po projekcie warto zostawić:
- opis biznesowy: na co graliście i jaki problem to rozwiązuje,
- listę integracji i danych, przydatną przy mapowaniu kolejnych procesów,
- listę kontaktów, łącznie z prawnikami,
- dokumentację, bo powtarza się to, co zostało sensownie opisane,
- opis tego, jak wam się to udało, w tym rzeczy miękkie: jak przekonaliście osoby, które dały budżet.
Ten ostatni punkt zdarza się najrzadziej, a zdaniem Przemka zmienia najwięcej. Bez wymiany wiedzy każdy zespół wyważa otwarte drzwi i popełnia te same błędy od nowa.
Jedna rzecz do zrobienia jutro rano
Przemek: zacząć to robić, czasem nieumiejętnie, ale zacząć. Wysłuchać wszystkich stron, w tym prawnika, poznać zagrożenia, ale nie bać się wszystkiego, bo najłatwiej powiedzieć, że nie chcemy zmiany, więc RODO.
Inga: zapytać zespoły wprost, co robią z shadow AI, czyli do czego używają prywatnych narzędzi. Nie po to, żeby to zamiatać. Przy kawie wychodzą rzeczy, których nikt nie powiedziałby szefowi, a proces, który ktoś usprawnił sobie prywatnym modelem, bywa najlepszym kandydatem do optymalizacji. Przemek dodał, że shadow AI jest realnym problemem, a przenoszenie go w ustrukturyzowane procesy to element dbania o bezpieczeństwo organizacji i o odpowiedzialność zarządu.
Ostatnia myśl od Ingi: jeśli widzisz w zespole kogoś zdrowo zaangażowanego w nowe narzędzia, daj mu przestrzeń, żeby zaraził resztę. W wielu firmach ludzie testują różne rzeczy w domu i nie dzielą się tym w pracy, co blokuje przepływ pomysłów.
Pełna rozmowa, przykłady liczbowe i odpowiedzi na pytania uczestników są w nagraniu:
OBEJRZYJ NAGRANIE NA YOUTUBE (nie zapomnij zasubskrybować kanału)
A jeśli szukasz punktu startu na jutro: sprawdź, który proces w Twojej firmie jest gorącym kartoflem, i policz, czy ma właściciela, dostępne dane i policzalny koszt.