Wpływ AI na biznes najlepiej mierzyć zmianą konkretnego wyniku, który firma już śledzi, na przykład poziomu zapasów. Sama liczba użytych narzędzi, promptów czy tokenów pokazuje aktywność, nie wartość dla firmy. Colleen Aubrey z Amazon Web Services (AWS) opowiedziała się za takim podejściem w wywiadzie dla SiliconANGLE.
Najpierw ustal, jaki wynik biznesowy ma się zmienić. Dopiero potem dobierz sposób sprawdzenia, czy AI rzeczywiście pomaga go osiągnąć.
Mierz wyniki biznesowe, nie aktywność AI
Wskaźnik powinien odpowiadać na pytanie, które uzasadnia projekt: czy zmieniły się na przykład zapasy albo wyniki pracy? Ustal punkt odniesienia przed wdrożeniem i porównuj z nim późniejsze wyniki. Liczba zapytań do modelu lub osób korzystających z narzędzia może pomóc opisać jego użycie, ale sama nie odpowiada na pytanie, czy przedsięwzięcie przyniosło korzyść biznesową.
Samo zestawienie wyników „przed” i „po” nie rozstrzyga jeszcze, co spowodowało zmianę. W tym samym czasie mogły zmienić się inne warunki pracy. Dlatego, jeśli to możliwe, porównuj podobne zespoły wykonujące to samo zadanie, z których jeden korzysta z AI, a drugi pracuje tradycyjnie.
Jak porównać pracę z AI i bez niej
IBM opisuje podejście, w którym podobne grupy realizują ten sam projekt, jedna z użyciem AI, druga bez niej. Następnie porównuje się szybkość, jakość, koszt i dokładność. To daje firmie więcej informacji niż sam wynik po wdrożeniu, choć porównanie nadal zależy od tego, czy zadania i warunki pracy są rzeczywiście podobne.
Warto też rozdzielić wyniki według rodzaju zadania i umiejętności pracowników. IBM zaleca uwzględniać, jak szybko zespół przyswaja nowe narzędzie i jak dobrze łączy się ono z używanymi już rozwiązaniami. Średnia dla całej firmy może bowiem ukryć różnice między pracą, w której AI pomaga, a tą, w której nie daje podobnego efektu.
Co mówią przykłady przypisane AWS
W wywiadzie dla SiliconANGLE opisano przypisywany AWS przykład Wells Vehicle Electronics: w ciągu trzech miesięcy zapasy spadły o 7%, a liczba aktywnie monitorowanych indeksów SKU wzrosła z 20 do 2 000. SKU to jednostka identyfikująca konkretny produkt w ewidencji. Przykład pokazuje biznesowy wynik oraz skalę monitorowania, których nie oddaje sama liczba użyć AI.
Colleen Aubrey powiedziała również, że jej grupa podwoiła tempo wdrożeń produkcyjnych po pracach nad pokryciem testami i kondycją pipeline’ów, czyli procesów automatyzujących budowanie i wdrażanie oprogramowania. To ważny kontekst: tempo zmieniło się po usprawnieniach dotyczących testów i pipeline’ów, a nie w wyniku jednego odizolowanego pomiaru użycia asystenta kodowania.
W oprogramowaniu liczy się cały cykl pracy
Przy tworzeniu oprogramowania liczba wygenerowanych linii kodu ani szybkość pierwszego szkicu nie opisują całego wyniku. GitLab zaleca patrzeć na pełny cykl życia oprogramowania (SDLC), uwzględniając dostarczanie zmian, jakość, bezpieczeństwo oraz późniejszą pracę przy przeglądzie, testach i utrzymaniu. Błędy bezpieczeństwa mogą dołożyć kolejne zadania.
| Obszar pracy | Miary lub wymiary | Zakres |
| Porównanie podobnych zadań | Szybkość, jakość, koszt i dokładność | IBM opisuje te miary przy porównywaniu grup wykonujących ten sam projekt z AI i bez niej. |
| Dostarczanie oprogramowania | Częstotliwość wdrożeń, czas od zmiany do jej wdrożenia, średni czas przywracania działania, odsetek nieudanych zmian i niezawodność | Wskaźniki DORA wymieniane przez GitLab dotyczą dostarczania oprogramowania, a nie wszystkich projektów AI. |
Wskaźniki DORA pomagają opisać, jak zespół dostarcza i przywraca zmiany w oprogramowaniu. Zestawienie ich z jakością, bezpieczeństwem i pracą po wygenerowaniu kodu pozwala uwzględnić także czas poświęcony na przegląd, testowanie i utrzymanie. Dzięki temu większa ilość kodu nie przesłania wysiłku, który może pojawić się na dalszych etapach pracy.
