Rozważmy proces tworzenia zlecenia serwisowego, który może być realizowany przez przepływ oparty na API, agenta wywołującego ten przepływ albo agenta obsługującego interfejs aplikacji. Podczas demonstracji każdy z nich tworzy zlecenie. Decyzja budżetowa zależy jednak od tego, co dzieje się w całym zbiorze spraw: przy niekompletnych zgłoszeniach, nieudanych próbach, niepewnym wyniku zapisu, ręcznych korektach i bieżącym utrzymaniu.
Porównuj całkowity koszt poprawnie zakończonego procesu, a nie reklamowaną cenę tokenów, licencji użytkowników czy pojedynczych działań. Elastyczność agenta uzasadnia jego koszt operacyjny wtedy, gdy zmierzona wartość obsługi różnorodnych przypadków przewyższa dodatkowe koszty wykonania, nadzoru i utrzymania. Takie porównanie wymaga jednakowych granic zadania i niezależnej weryfikacji wyników.
Zdefiniuj jednakowo zakończone zadanie, zanim porównasz koszty
W hipotetycznej ocenie procesu tworzenia zleceń serwisowych przyjmij za początek otrzymanie zgłoszenia od uprawnionej osoby, a za koniec poprawne zapisanie zlecenia w systemie docelowym wraz z wymaganym zatwierdzeniem i potwierdzeniem. Określ, jakie typy zgłoszeń kwalifikują się do obsługi, które pola muszą być poprawne i w jakim terminie proces ma się zakończyć. Zastosuj te warunki do każdej implementacji.
Nie porównuj deterministycznego przepływu otrzymującego zweryfikowane dane ustrukturyzowane z agentem interpretującym nieustrukturyzowane zgłoszenie, jeśli nie uwzględniasz kosztu przygotowania danych dla przepływu. Podobnie nie uznawaj, że agent zakończył proces, gdy przygotował jedynie wersję roboczą, którą ktoś musi sprawdzić i zapisać. W obu przypadkach część pracy zostaje przeniesiona poza granice kalkulacji kosztów.
Rozdziel wyniki na następujące kategorie: poprawnie zakończone bez interwencji, poprawnie zakończone z interwencją, odrzucone zgodnie z zasadami, nierozwiązane i zakończone niepoprawnie. Przypadki zakończone z pomocą człowieka mogą być zaliczane do wykonanej pracy, o ile uwzględnisz koszt tej pomocy. Prawidłowe odrzucenie świadczy o użytecznym działaniu mechanizmu kontroli, ale nie powinno bez wyraźnego zaznaczenia stawać się zakończonym zleceniem serwisowym w mianowniku wskaźnika.
W analizie inwestycji w ERP opartej na weryfikacji procesu Digiventi zaleca porównywanie tego samego zakresu pracy i wymagań kontrolnych, z uwzględnieniem nieudanych prób, testów, weryfikacji, monitorowania i nakładu na wsparcie. Tutaj zakładamy, że decyzja dotycząca platformy już zapadła. Węższe pytanie brzmi: który model wykonania zasługuje na stały budżet operacyjny.
Porównuj modele wykonania, a nie etykiety agentów
Zacznij od deterministycznego przepływu opartego na API, jeśli można określić dopuszczalne dane wejściowe, reguły biznesowe i wspierane działania. Jego ocena nadal musi obejmować walidację, błędy integracji i przywracanie poprawnego działania. Właściwym punktem odniesienia nie jest wyidealizowany przepływ, który nigdy nie zawodzi, lecz implementacja możliwa do utrzymania, spełniająca te same wymagania dotyczące zakończenia procesu co agent.
Wariant hybrydowy warto przetestować wtedy, gdy interpretacja zgłoszenia wymaga elastyczności, ale transakcja biznesowa ma już ustaloną ścieżkę wykonania. W dyskusji o ERP i AI praktyk opisuje agenta, który pyta, czy przetworzyć fakturę, a następnie wywołuje istniejący przepływ zamiast samodzielnie ją przetwarzać. Istotne rozróżnienie architektoniczne dotyczy tu podjęcia decyzji, co wywołać, oraz wykonania transakcji. Nie jest to dowód, że wariant hybrydowy będzie tańszy.
Oceń wykonanie przez agenta obsługującego interfejs komputera, czyli computer-use, gdy proponowana ścieżka rzeczywiście wymaga interakcji z interfejsem aplikacji. Poproś zespół o wykazanie, dlaczego wspierane API lub istniejące przepływy nie mogą odpowiednio obsłużyć zadania. Następnie zmierz wyniki ścieżki interfejsowej względem tego samego rezultatu biznesowego, uwzględniając odzyskiwanie kontroli po operacji o niepewnym wyniku.
| Wariant | Kiedy go rozważyć | Dowody wymagane przed zatwierdzeniem |
|---|---|---|
| Przepływ deterministyczny | Można określić dane wejściowe i reguły, a aplikacja udostępnia wspierane działania. | Poprawna obsługa kwalifikujących się przypadków, wyjątków i ponownych zgłoszeń. |
| Agent wywołujący przepływy | Zgłoszenia wymagają różnej interpretacji, ale wykonanie transakcji może pozostać kontrolowane. | Poprawny wybór przepływu, zweryfikowane parametry i potwierdzone wykonanie. |
| Agent computer-use | Proponowane zadanie wymaga ścieżki wykonania przez interfejs. | Poprawny stan aplikacji, odzyskiwanie kontroli w określonych granicach i zmierzony nakład nadzoru. |
Spotkanie społeczności Microsoft ERP dostarcza użytecznego ostrzeżenia przed zakładaniem, że elastyczność jest niedroga. Uczestnicy opisują tworzenie zleceń serwisowych z użyciem agentów computer-use, przepływów i aplikacji, a następnie wskazują duże zużycie tokenów związane z komponentami AI, w tym obsługą komputera powiązaną z modelami Claude. Traktuj to jako obserwację praktyków dotyczącą tej implementacji, a nie ogólny benchmark kosztów agentów computer-use.
Zbuduj arkusz kosztów zgodny z rzeczywistym sposobem rozliczania
Dla każdego wariantu przygotuj arkusz zawierający kategorię kosztu, jednostkę rozliczeniową określoną w umowie, obowiązującą stawkę, zaobserwowane zużycie, zasadę alokacji i osobę odpowiedzialną za dane dowodowe. Zapisz datę, walutę, region i warunki zobowiązania, z których wynika każda stawka. Ocena zużycia w Copilot Studio powinna zaczynać się od warunków handlowych obowiązujących w danej dzierżawie, a nie od zapamiętanej ceny czy uprawnień innej organizacji.
Microsoft w przewodniku wdrażania automatyzacji agentowej opisuje przepływy w chmurze i przepływy pulpitu Power Automate jako zwykle licencjonowane na użytkownika lub bota, a przykład wykonywania przepływów w ramach stałej opłaty wyraźnie zastrzega limitami uczciwego użytkowania. To rozróżnienie modeli licencjonowania, a nie potwierdzenie aktualnych uprawnień ani oferta cenowa. Poproś osobę odpowiedzialną za licencje o potwierdzenie konkretnego SKU, wymagań wstępnych, pojemności i limitów dla proponowanego wdrożenia.
| Kategoria kosztu | Co zapisać |
|---|---|
| Licencje i pojemność | Wymagane licencje użytkowników, procesów lub botów, jednostki zużycia, zobowiązania, pojemność w cenie, opłaty za przekroczenie limitów i wymagania wstępne. |
| Użycie modelu | Model i wersja; kategorie danych wejściowych, wyjściowych i buforowania, jeśli mają zastosowanie; zmierzone zużycie i stawki umowne. |
| Narzędzia i wykonanie | Wywołania przepływów, opłaty za konektory lub API, środowisko computer-use, czas wykonania i narzędzia rozliczane osobno. |
| Błędy i ponowienia | Wszystkie próby wykonania, ponowna interpretacja, ponowne zgłoszenia, porzucona praca i zużycie podczas przywracania działania. |
| Praca ludzi | Czas rutynowej weryfikacji, obsługi wyjątków, korekt, eskalacji i uzgadniania wyników, według stawek pracy właściwych dla organizacji. |
| Obserwowalność i wsparcie | Rejestrowanie zdarzeń, przechowywanie danych, pulpity monitorujące, przeglądy operacyjne, reagowanie na incydenty i zobowiązania dotyczące wsparcia. |
| Utrzymanie | Zmiany integracji, reguł, promptów, modeli i interfejsów; testy regresji i nakład na wdrożenia. |
| Założenia dotyczące wolumenu | Liczba kwalifikujących się spraw, struktura przypadków, szczyty obciążenia, współbieżność, odsetek zakończeń i alokacja współdzielonej pojemności. |
Przypisz każdą opłatę do rzeczywistego sposobu jej naliczania. Jeśli opłata za zużycie platformy obejmuje wykonanie modelu, nie dodawaj hipotetycznej faktury za bezpośrednie korzystanie z modelu. Jeśli narzędzie lub model są rozliczane osobno, zachowaj tę pozycję. Pokaż zarówno dodatkowy wydatek pieniężny, jak i koszty operacyjne z pełną alokacją, aby istniejące licencje nie znikały z TCO automatyzacji agentowej ani nie były wielokrotnie przypisywane do różnych przepływów.
Oddziel nakłady wdrożeniowe od bieżącej eksploatacji, a następnie uwzględnij je jawnie przy porównywaniu kosztów całkowitych w wybranym horyzoncie inwestycyjnym. Poproś o założenia dotyczące utrzymania każdego wariantu, zamiast przyjmować, że API, prompty czy interfejsy nie wymagają utrzymania. Niski rachunek za wykonanie nie stanowi pełnego porównania, jeśli dany wariant wymaga znacznego, stałego nakładu prac inżynierskich.
Mierz próby wykonania i niezależnie weryfikuj zakończenie
Przygotuj dopuszczony do użycia zestaw testowy reprezentujący docelową pracę: zwykłe zgłoszenia, niekompletne informacje, niejednoznaczne instrukcje, błędy aplikacji i niepewne wyniki transakcji. Zachowaj jednakową strukturę przypadków dla wszystkich wariantów. Dokumentuj wyłączenia, aby ścieżka przetestowana wyłącznie na prostych przypadkach nie była przedstawiana jako rozwiązanie obejmujące cały proces.
Nadaj sprawie biznesowej identyfikator, który będzie towarzyszył zgłoszeniu we wszystkich próbach wykonania. Przed testami wymagaj od zespołu wdrożeniowego demonstracji eksportu telemetrii i jej korelacji z uruchomieniami przepływów, wywołaniami narzędzi oraz rekordami biznesowymi. Proponowany rejestr pomiarowy powinien zawierać:
- Identyfikator sprawy, kategorię danych wejściowych i oczekiwany rezultat biznesowy.
- Konfigurację implementacji, wersję modelu, jeśli dotyczy, oraz znaczniki czasu wykonania.
- Identyfikatory prób, wywołane narzędzia lub przepływy, błędy, ponowienia i raportowane zużycie.
- Powód interwencji człowieka, czas aktywnej obsługi i wykonaną korektę.
- Identyfikator rekordu w systemie docelowym, niezależnie sprawdzoną poprawność i końcowy status sprawy.
Nie uznawaj komunikatu agenta „gotowe” za potwierdzenie zakończenia. W scenariuszu zlecenia serwisowego zweryfikuj rekord docelowy, wymagane pola, uprawnienia i brak niezamierzonego duplikatu. Jeśli podczas zapisu upłynie limit czasu, poproś zespół o pokazanie, jak przed ponowieniem ustala, czy zlecenie już istnieje. Przypisz koszt sprawdzenia i przywrócenia poprawnego działania do tej sprawy.
Gdy interpretacja dokumentu jest częścią procesu, zdefiniuj poprawność przed oceną ekonomiczną. Wykorzystaj testy odbiorowe ekstrakcji danych z dokumentów, aby rozróżniać wartości brakujące, niepoprawne i niemające oparcia w dokumencie, a następnie przenieś wynikający z tego nakład na weryfikację i korekty do arkusza kosztów. Przekonujące podsumowanie nie powinno zastępować pól biznesowych potrzebnych do wykonania zadania.
Przetestuj również operacyjne działanie mechanizmów kontroli wydatków. Ustal, czy skonfigurowany próg wywołuje alert, ogranicza tempo, odrzuca nowe zadania czy zatrzymuje wykonanie oraz czy egzekwowanie ograniczenia jest opóźnione. Sprawdź, co dzieje się ze sprawami oczekującymi i będącymi w toku, kto może wznowić przetwarzanie i jak działa bezpieczna ścieżka awaryjna. Nie zatwierdzaj budżetu, zakładając, że alert, zakup przedpłacony lub limit liczby wywołań stanowią nieprzekraczalny limit wydatków.
Użyj arkusza progu opłacalności zamiast zakładać oszczędności
Dla każdego wariantu oblicz:
Koszt poprawnie zakończonego procesu = całkowity koszt operacyjny objęty zakresem pomiaru w danym okresie ÷ liczba niezależnie zweryfikowanych, poprawnych zakończeń w tym okresie.
Licznik obejmuje wydatki na próby nieudane i nierozwiązane, a nie tylko udane uruchomienia. Obok wyniku kosztowego raportuj odsetek zakończeń, udział spraw wymagających pomocy człowieka i czas realizacji. W przeciwnym razie ścieżka pozostawiająca trudne sprawy bez rozwiązania może wyglądać atrakcyjnie, mimo że nie spełnia wymagań operacyjnych.
W arkuszu planistycznym przyjmij, że F oznacza stały koszt cykliczny, V wolumen kwalifikujących się spraw, A średni zmienny koszt wykonania na kwalifikującą się sprawę wraz z ponowieniami, H średni koszt pracy ludzi na kwalifikującą się sprawę, a Q odsetek spraw zakończonych poprawnie. Następnie porównaj [F + V × (A + H)] ÷ (V × Q) dla poszczególnych wariantów. To model planistyczny, a nie wynik pomiaru. Wypełnij go danymi dotyczącymi własnej pracy i przypisz utrzymanie do odpowiedniej kategorii kosztów stałych lub zmiennych.
Zmieniaj założenia dotyczące wolumenu, struktury przypadków, nakładu interwencji i utrzymania, aby ustalić, przy jakich warunkach zmienia się rekomendacja. Agent może uzasadnić wyższy koszt, realizując wartościowe warianty, których przepływ nie potrafi obsłużyć w uzgodnionych granicach. Wariant hybrydowy może zasługiwać na zatwierdzenie dzięki połączeniu interpretacji z ustalonym sposobem wykonania. Jeśli ścieżka deterministyczna już spełnia wymagania, zażądaj wyraźnego uzasadnienia finansowania dodatkowej elastyczności.
Przed zatwierdzeniem cyklicznych wydatków poproś właściciela procesu i sponsora finansowego o akceptację granic zadania, raportu zweryfikowanych zakończeń i arkusza analizy wrażliwości. Jeśli potrzebujesz pomocy w ocenie architektury wykonania i projektu pomiarów, omów swój proces ze specjalistami Digiventi ds. danych i AI w technologiach Microsoft.
