Zależność od dostawcy inferencji AI zwykle nie kryje się w samym modelu. Powstaje w sposobie pobierania danych finansowych, regułach zapisanych w panelu, formacie raportu i dostępie do historii korekt. Analizę najlepiej prowadzić od końca procesu. Punktem wyjścia jest dokument potrzebny do zamknięcia miesiąca, a dalej dane, konfiguracja i elementy dostępne wyłącznie w danej usłudze. Taki porządek pokazuje, czy proces da się uruchomić w innym prywatnym środowisku, ile pracy wymaga zmiana i które ograniczenia firma świadomie akceptuje. Nie obiecuje migracji bez wysiłku, ale usuwa z niej najgroźniejsze niewiadome.
Najpierw raport, nie model
Finanse korzystają z inferencji wtedy, gdy otrzymują materiał przydatny do klasyfikacji kosztów, kontroli dokumentów albo obsługi wyjątków. Raport powinien wskazywać okres, źródło, liczbę dokumentów, sumę kwot i ręczne korekty. Bez tych informacji trudno stwierdzić, czy obejmuje pełny cykl, czy tylko część danych dostępnych w chwili obliczeń.
Model może podpowiedzieć konto, oznaczyć brak pola lub skierować fakturę do wyjaśnienia. Ostateczna akceptacja i zapis księgowy należą do procesu firmy. Przy zmianie dostawcy trzeba zachować rezultat analizy wraz z identyfikatorami dokumentów, statusami i powodami korekt, na których opiera się dalsza praca.
Własny opis danych
Paczka wejściowa nie może być zrozumiała wyłącznie dla bieżącej aplikacji. Potrzebuje nazwy źródła, zakresu pól, czasu pobrania, wersji słownika, zasad czyszczenia i formatu przekazywanego do modelu. Dopiero wtedy można zestawić ją z ERP bez ponownego pobierania rekordów, które zdążyły się zmienić.
W danych finansowych podstawową kontrolę dają liczba dokumentów, suma kwot i kompletność okresu. Rozbieżność może powstać przed uruchomieniem inferencji, na przykład przez pominięty eksport albo zmianę statusu faktury. Kolejne obliczenie na tej samej paczce nie naprawi błędu źródła.
Prywatne środowisko ogranicza krąg usług i osób mających dostęp do materiału roboczego, lecz samo nie ustala uprawnień. Konto techniczne powinno odczytywać tylko potrzebne pola, finanse otrzymywać raport i wyjątki, a administracja zarządzać konfiguracją bez dostępu do treści szerszej niż niezbędna do utrzymania zadania.
Okres przechowywania danych roboczych wynika z potrzeby wyjaśnienia operacji oraz zasad firmy. Zbyt krótka historia utrudni analizę korekty, a bezterminowe gromadzenie każdej paczki zwiększy ilość chronionych informacji. Zasada powinna być znana przed wyborem usługi, nie dopiero po pierwszym żądaniu usunięcia danych.
Konfiguracja poza panelem dostawcy
Najtrudniej przenoszą się reguły czyszczenia, mapowania pól, szablony zapytań, wersje zależności, harmonogramy i uprawnienia. Często są rozproszone między panelem, zgłoszeniami oraz wiedzą osób, które uruchamiały proces. Eksport samego modelu nie odtworzy połączenia z ERP ani formatu raportu oczekiwanego przez finanse.
Konfiguracja powinna mieć wersję, opis wejścia i oczekiwany rezultat. Trzeba również wiedzieć, gdzie przechowywane są sekrety i kto może udostępnić je w nowym środowisku. Nie oznacza to wpisywania haseł do dokumentacji. Chodzi o odtworzenie sposobu bezpiecznego podania danych dostępowych.
Materiały przenośne nie muszą tworzyć rozwiązania uruchamianego jednym kliknięciem. Mają ograniczyć liczbę ustawień rekonstruowanych z dawnych ekranów oraz wiadomości. Dobrym kryterium jest możliwość wyjaśnienia procesu osobie, która nie brała udziału w pierwszym wdrożeniu.
Co pozostanie po zmianie usługi?
Dostawca może kontrolować harmonogram zadań, kolejkę, bazę raportową, panel akceptacji, uwierzytelnianie i własny format danych. Każdy z tych elementów wymaga innego sposobu zastąpienia. Wymiana modelu bywa prostsza niż przeniesienie otoczenia, w którym finanse korzystają z jego odpowiedzi.
Przed umową trzeba rozdzielić dane i reguły należące do firmy, elementy możliwe do eksportu oraz funkcje specyficzne dla usługi. Ta ostatnia grupa nie musi dyskwalifikować rozwiązania. Jej koszt powinien być jednak widoczny, podobnie jak czas potrzebny na zbudowanie odpowiednika.
Koszt wyjścia jest częścią kosztu usługi
Alternatywne środowisko wymaga zasobów, administracji, ochrony danych i aktualnej konfiguracji. Dla procesu o małej tolerancji na przerwę może działać stale. W innym przypadku wystarczy okresowe uruchomienie procesu poza główną usługą, aby nie opierać planu migracji na założeniach.
Firma z góry ustala, ile może czekać na wznowienie raportowania i jak stary zestaw danych finansowych nadal nadaje się do użycia. Próba obejmuje ERP, eksport, aplikację inferencyjną i publikację raportu, bo uruchomienie jednego komponentu nie przywraca całego procesu.
Koszt zmiany obejmuje też pracę kontrolera. Po migracji trzeba porównać liczbę dokumentów, sumy, wybrane klasyfikacje, uprawnienia i wyjątki. Technicznie działająca aplikacja nie gwarantuje, że raport nadaje się do zamknięcia okresu bez dodatkowych korekt.
Firma może zaakceptować część zależności po poznaniu ceny wyjścia i zachowaniu dostępu do danych, reguł oraz konfiguracji. Granicą jest awaria usługi, która odbiera możliwość wykonania podstawowego rozliczenia, albo utrata dostępu do własnych informacji. Bezpieczny wybór dostawcy wymaga poznania tego kosztu przed pierwszym produkcyjnym raportem, zamiast podczas negocjowania zmiany.