Wyobraźmy sobie sponsora biznesowego z obszaru finansów, który ma zatwierdzić modernizację ERP, ponieważ proponowana platforma zawiera agenta do przetwarzania faktur. Podczas demonstracji agent odczytuje dane z faktury i przygotowuje zapis księgowy. Decyzja inwestycyjna jest trudniejsza: trzeba ustalić, czy ten proces wymaga zmiany platformy, czy może działać z obecnym ERP i czy nadal przynosi wartość po uwzględnieniu weryfikacji przez człowieka, obsługi wyjątków oraz kosztów eksploatacji.
Najpierw sfinansuj weryfikację, dopiero potem zobowiązuj się do zmiany platformy. Zdefiniuj proces o ograniczonym zakresie, ustal jego obecne obciążenie pracą i ryzyko błędów, a następnie przetestuj wymagany dostęp oraz mechanizmy kontrolne. Dopiero wtedy zdecyduj, czy zmodernizować ERP, rozszerzyć obecny system, czy najpierw spełnić warunki wstępne. Dostęp do AI powinien być elementem uzasadnienia biznesowego inwestycji w ERP, a nie jego konkluzją.
Oddziel potencjał usprawnienia procesu od decyzji o modernizacji
Zapisz wymaganie operacyjne bez wskazywania produktu. „Ograniczyć nakład pracy potrzebny do przygotowania kwalifikujących się faktur od dostawców do zatwierdzenia” to wymaganie, które da się przetestować. „Wdrożyć finanse oparte na agentach AI” nie jest takim wymaganiem. Określ zdarzenie rozpoczynające proces, oczekiwany rezultat biznesowy, transakcje objęte zakresem i przypadki, które muszą pozostać poza pilotażem.
W dyskusji o transformacji przedsiębiorstw pada zalecenie, aby zaczynać tam, gdzie procesy i informacje są bardziej uporządkowane, a następnie rozwijać rozwiązanie iteracyjnie. Poprawa jakości danych jest też wskazana jako wartościowa praca sama w sobie, a nie problem, który można ominąć decyzją o modernizacji ERP. Dla sponsora oznacza to konieczność rozróżnienia między nieodpowiednią platformą a nieodpowiednim procesem wybranym na początek.
Ustal punkt odniesienia przed wyborem rozwiązania AI. Poproś właściciela procesu o udokumentowanie wolumenu transakcji, czasu aktywnej obsługi, czasu oczekiwania, pracy związanej z korektami oraz przyczyn powstawania wyjątków. Oddziel pracę, którą można wyeliminować, od tej, która zostanie przeniesiona na osoby weryfikujące lub zespoły wsparcia. Uzgodnij, jak zostanie wykorzystany uwolniony czas, zanim przedstawisz go jako korzyść finansową.
Szersze przesłanki wymiany systemu ujmij w osobnym uzasadnieniu inwestycji. Możliwość dalszego utrzymania i wsparcia, pokrycie procesów oraz ograniczenia organizacyjne należą do oceny, czy usprawnić, czy wymienić ERP. Tutaj pytanie jest węższe: czy proces wspierany przez AI wnosi wystarczającą dodatkową wartość, aby uzasadnić przypisaną mu część wydatków na platformę.
Zweryfikuj dostęp, zanim porównasz AI wbudowaną w ERP z zewnętrznymi agentami
Webinar o ERP i AI dla MŚP rozróżnia AI działającą wewnątrz produktu ERP od zewnętrznej AI połączonej z nim przez interfejsy. Omawia także architekturę hybrydową, w której agenci działają nad warstwą backendową ERP. Są to możliwości architektoniczne rozważane przez rozmówców, a nie dowód dostępności lub niezawodności konkretnej integracji.
Wykorzystaj to rozróżnienie, prosząc o alternatywne sposoby realizacji tego samego zadania. Warto rozważyć rozwiązanie wbudowane, jeśli dostawca potrafi zademonstrować wymagany proces, uprawnienia i zasady wsparcia w proponowanym środowisku. Warto rozważyć rozwiązanie zewnętrzne, jeśli obecny ERP udostępnia niezbędne informacje i wspierane operacje. Żadna opcja nie powinna być preferowana tylko dlatego, że jest natywna albo niezależna.
Poproś każdy zespół o mapę dostępu: jakie rekordy odczytuje rozwiązanie, jak aktualne muszą być te dane, jakie operacje wywołuje i w ramach czyjej tożsamości. Wymagaj demonstracji z reprezentatywnymi uprawnieniami, a nie na nieograniczonym koncie administratora. Nazwa konektora lub udany eksport danych to słaba odpowiedź, jeśli proponowany proces wymaga również dostępu do statusu zatwierdzenia, wyników księgowania lub przywracania poprawnego stanu po wystąpieniu wyjątku.
W przypadku funkcji wbudowanej uzyskaj potwierdzenie właściwe dla danego produktu: obsługiwanych wersji, edycji, modeli wdrożenia, dostępności regionalnej i wymaganych subskrypcji. W przypadku zewnętrznego agenta zweryfikuj wspierane interfejsy, uwierzytelnianie, dozwolone operacje transakcyjne i odpowiedzialność za wsparcie integracji. Oddzielnie oznacz funkcje w wersji zapoznawczej i zobowiązania z planu rozwoju produktu, odróżniając je od możliwości zademonstrowanych w proponowanym środowisku.
Webinar dla MŚP zaleca także analizę otwartości rozwiązania, zależności od konkretnego modelu językowego i dopasowania do logiki biznesowej. Przełóż to na praktyczny test zależności: zapytaj, co trzeba zmienić po zmianie modelu, konektora lub wersji ERP. Jeśli bezpośrednią przeszkodą jest dostęp do danych, osobno określ zakres prac z obszaru inżynierii danych i AI, aby warunek niezbędny do integracji nie stał się niewyjaśnioną przesłanką wymiany platformy.
Jasno określ uprawnienia do transakcji i testuj scenariusze błędów
Dyskusja o transformacji przedsiębiorstw opisuje architekturę, która ogranicza działanie modeli językowych przez kontrolowany kontekst, deterministyczne przepływy pracy, mechanizmy weryfikacji i miarodajne źródła danych. Webinar dla MŚP również zakłada udział człowieka w orkiestracji procesów biznesowych ERP. Są to zalecenia wynikające z dyskusji. Wykorzystaj je do określenia tego, co ma wykazać pilotaż, zamiast zakładać, że którakolwiek kategoria produktów zapewnia te zabezpieczenia.
Oznacz każdy krok procesu jako interpretację, rekomendację, zatwierdzenie lub wykonanie. W pilotażu obsługi faktur AI może proponować odczytane wartości i dekretację. Wymagaj, aby dopuszczenie do księgowania, kontrola uprawnień i akceptacja zapisu przez księgę główną nadal podlegały jednoznacznym regułom. Wskaż osobę zatwierdzającą przypadki niejednoznaczne oraz rolę uprawnioną do zmiany tych reguł. Płynnie sformułowane wyjaśnienie nie powinno zastępować egzekwowanego ograniczenia uprawnień.
Hipotetyczny scenariusz oceny: agent otrzymuje fakturę, przygotowuje proponowany zapis księgowy i wysyła go do ERP. Samo pomyślne przesłanie komunikatu nie jest wystarczającym dowodem spełnienia kryteriów odbioru. Poproś zespół o pokazanie, czy zapis został zaakceptowany, jak zachowano możliwość prześledzenia dokumentu źródłowego i zatwierdzenia oraz jak dział finansów uzgadnia wynik. Następnie wprowadź brak potwierdzenia przyjęcia, sprzeczne dane dostawcy i przerwanie odpowiedzi po wysłaniu żądania.
Dla każdego wyjątku wymagaj demonstracji, czy rozwiązanie zatrzymuje działanie, prosi o weryfikację, czy ponawia próbę. Sprawdź, jak przed ponownym wysłaniem ustala, czy transakcja już istnieje, oraz kto rozstrzyga przypadek o niepewnym wyniku. Przypisz odpowiedzialność za przywrócenie poprawnego stanu zespołowi ERP, zespołowi integracyjnemu i właścicielowi procesu. Jeśli odpowiedź brzmi „agent się tym zajmuje”, pozostaw sprawę otwartą do czasu, aż będzie można zweryfikować zachowanie rozwiązania i odpowiedzialność za nie.
Przetestuj również użytkownika, który nie ma dostępu do odpowiedniej jednostki organizacyjnej lub transakcji. Zapisz, jakie informacje otrzymuje model, co opuszcza środowisko ERP, jakie obowiązują zasady retencji i jak odbiera się dostęp. Jeśli pilotaż wymaga trwałego rozszerzenia, oceń jego utrzymanie i odpowiedzialność za nie w ramach decyzji o zatwierdzeniu modyfikacji ERP, zamiast akceptować nieudokumentowaną zależność w ramach eksperymentu z AI.
Mierz zaakceptowane rezultaty biznesowe, a nie wyniki demonstracji
Przed uruchomieniem pilotażu uzgodnij kryteria odbioru z finansami lub operacjami. Mierz cały proces: zaakceptowane wyniki, błędne propozycje, wyjątki, zmiany decyzji przez człowieka, nakład pracy na weryfikację, korekty i nierozstrzygnięte przypadki. Pokazuj, do jakiej liczby przypadków odnoszą się wskaźniki. Wykluczenie trudnych transakcji może być uzasadnione ograniczonym zakresem, ale musi też ograniczać prognozowane korzyści.
Jako przykład mierzalnego kryterium erp.io proponuje test odczytu danych z faktur wymagający co najmniej 99% poprawności pól nagłówka w próbie co najmniej 200 faktur od dziesięciu dostawców, których faktury są najbardziej zróżnicowane. To kryterium proponowane przez wydawcę, a nie wykazany wynik produktu ani zweryfikowany próg branżowy. Jego użyteczną cechą jest konkretność. To kontroler finansowy powinien zdecydować, które pola, błędy i cechy próby mają znaczenie dla danego procesu.
Nie pozwól, aby poprawność odczytu danych zastąpiła ocenę poprawności transakcji. Sprawdź, czy propozycja wskazuje właściwego dostawcę, podmiot, ujęcie księgowe i ścieżkę zatwierdzania, a następnie zweryfikuj końcowy rezultat biznesowy. Raportuj nakład pracy na weryfikację obok jakości. Jeśli każda propozycja wymaga szczegółowego sprawdzania, sponsor powinien widzieć tę zależność, a nie tylko liczbę wygenerowanych wyników.
Oprzyj porównanie komercyjne na tym samym obciążeniu pracą i tych samych wymaganiach kontrolnych. Poproś o osobne warunki dotyczące uprawnień do korzystania z wbudowanej AI, zużycia zasobów zewnętrznego modelu, subskrypcji platformy, dostępu do API, wsparcia integracji i bieżącego utrzymania. Zapytaj, jak rozliczane są ponowienia, nieudane próby i użycie testowe. Porównaj te koszty z punktem odniesienia i uwzględnij pracę po stronie klienta związaną z weryfikacją, monitorowaniem i wsparciem. Nie przeliczaj wyniku pilotażu na korzyść roczną bez podania założeń dotyczących wolumenu kwalifikujących się przypadków i warunków eksploatacji.
Oprzyj zgodę na kolejną inwestycję na karcie decyzji po pilotażu
Zakończ pilotaż kartą decyzji zatwierdzoną przez właściciela biznesowego i zweryfikowaną przez osoby odpowiedzialne za architekturę, bezpieczeństwo oraz finanse. Powinna ona zachowywać dowody potrzebne do odróżnienia obiecującej demonstracji od modelu operacyjnego, który uzasadnia finansowanie:
- Proces i punkt odniesienia: zdarzenia rozpoczynające i kończące, kwalifikujące się przypadki, obecny nakład pracy, ryzyko błędów i wyłączenia.
- Dostęp i dostępność: zweryfikowane wymagania produktu, interfejsy, uprawnienia i wszelkie zależności od funkcji zapoznawczych lub planu rozwoju produktu.
- Zakres kontroli: deterministyczne reguły weryfikacji, zatwierdzenia przez człowieka, granice bezpieczeństwa, dowody audytowe i zabronione działania.
- Wyjątki i odpowiedzialność: reguły zatrzymania, sposób ponawiania prób, uzgadnianie wyników, przywracanie poprawnego stanu i role odpowiedzialne za wsparcie.
- Wyniki i ekonomika: zaakceptowane rezultaty, nakład pracy na weryfikację, błędy, koszty eksploatacji i nierozstrzygnięte kwestie komercyjne.
Rekomenduj modernizację, gdy wymagana funkcja została zademonstrowana, jej wymagania dotyczące platformy zostały zweryfikowane, a łączne uzasadnienie biznesowe przemawia za wydatkiem. Kontynuuj prace na obecnym ERP, gdy proces o ograniczonym zakresie spełnia kryteria odbioru dzięki integracji, którą można utrzymywać i wspierać. Odłóż inwestycję w uruchomienie produkcyjne, gdy nierozstrzygnięte pozostają kwestie danych, dostępu, kontroli lub odpowiedzialności, i zamiast tego zatwierdź konkretne prace przygotowawcze.
Przed zatwierdzeniem modernizacji motywowanej AI poproś zespół o wskazanie dokładnego wyniku pilotażu, który sprawia, że zmiana platformy jest konieczna. Jeśli potrzebujesz konsultantów funkcjonalnych lub programistów do oceny procesu ERP i wymagań integracyjnych, omów zakres ze specjalistami ERP w Digiventi.
