AI i architektura procesów biznesowych: jedno zatwierdzone źródło wiedzy

Asystent może w kilka sekund ogólnie opisać proces od zamówienia do płatności. Nie wyjaśni jednak, dlaczego zespół finansowy zatwierdza jeden wyjątek, a inny kieruje dalej, ani dlaczego magazyn pomija regułę zapasu bezpieczeństwa. Takie informacje składają się na architekturę procesów biznesowych, ale tylko wtedy, gdy zostaną zapisane.

Nie chodzi o to, czy AI zmieni pracę nad architekturą. Już ją zmienia. Pytanie brzmi, co nadal pozostaje po Państwa stronie: definicje, priorytety, kompromisy i zatwierdzanie. Nasze stanowisko jest proste: popieramy AI, ale jeszcze bardziej stawiamy na ludzi. AI powinno ograniczać pracę towarzyszącą podejmowaniu decyzji, a nie odbierać ludziom prawo do decydowania.

Dlaczego AI i architektura procesów biznesowych się uzupełniają

Bez AI architekturę tworzy się ręcznie, a między przeglądami szybko się dezaktualizuje. AI bez architektury to szybki, pewny siebie generalista.

Utrzymanie aktualnej architektury procesów biznesowych jest kosztowne, gdy trzeba ręcznie zbierać, rysować, opisywać i sprawdzać wszystkie informacje. AI obniża koszt przygotowania pierwszej wersji i przeglądania całego krajobrazu procesów. Asystentowi nie brakuje zdolności rozumowania, brakuje mu za to wiedzy o Państwa procesach. Jeśli otrzyma surowe tabele, musi sam odtworzyć workflow. Jeśli dostanie uporządkowaną architekturę, może odpowiadać na podstawie modelu, dokumentacji, ról i pomiarów rzeczywistych procesów.

Na tym polega połączenie: AI zapewnia szerokie możliwości, a architektura dostarcza rzetelnej wiedzy. Nie chodzi o dodanie AI do diagramu. Chodzi o połączenie AI z miejscem, w którym organizacja zapisuje, jak działa.

Różnica polega na tym, czy asystent ma dostęp do danych, czy do wiedzy o procesach. Kontekst procesowy MCP obejmuje samo połączenie. Trudniejsze pytanie, na które odpowiada ta strona, brzmi: co asystent zastaje po połączeniu? Cyfrowy bliźniak organizacji również zależy od tego, czy model i dane są powiązane z pomiarami i decyzjami.

Jak wygląda spójne źródło wiedzy

Architektura procesów biznesowych to powiązana struktura opisująca przebieg pracy. Obejmuje strumienie wartości, procesy, podprocesy i działania, przypisane do nich role, obsługujące je systemy, dokumenty i artefakty, a także status i wersję każdego elementu. To jedno miejsce, a nie jeden plik.

Hierarchia pomaga poruszać się po architekturze ludziom. Asystent korzysta z powiązań. Zbiór diagramów może pokazać, gdzie znajduje się proces, ale nie odpowie na pytania: „Co od niego zależy?”, „Kto za niego odpowiada?” ani „Która wersja jest zatwierdzona?”. Do tego potrzebny jest graf powiązań, a nie szafka na dokumenty.

Tę koncepcję określa się czasem jako architekturę BPM, architekturę procesów przedsiębiorstwa lub architekturę zarządzania procesami biznesowymi. Nazwa jest mniej istotna niż powiązania: jedno miejsce dla każdego faktu i jedna odpowiedź na pytanie „Która wersja jest aktualna?”.

Framework taki jak APQC zapewnia wspólne nazewnictwo dla hierarchii. Nie zawiera jednak Państwa procesów, właścicieli ani wyjątków. To organizacja ustala i zapisuje te informacje.

Niepowiązany model może się przydać podczas warsztatów. Powiązany model pozwala przejść od strumienia wartości do konkretnego działania i uzyskać odpowiedź asystenta na tej samej ścieżce. Dlatego warto go aktualizować.

Katalog procesów, który łączy hierarchię, procesy i ich status w jednej strukturze

W czym AI przyspiesza pracę nad architekturą, a gdzie nie powinno podejmować decyzji

AI najlepiej sprawdza się przy zadaniach, których wynik można zweryfikować, oraz przy przygotowaniu pierwszej wersji, którą człowiek może poprawić. Praca nad architekturą obejmuje wiele takich zadań.

Granica między tymi obszarami nie wynika z możliwości AI, lecz z uprawnień. AI może lepiej od człowieka przygotować model, a mimo to nie mieć prawa decydować o sposobie działania Państwa firmy.

W praktyce warto powierzać AI zadania, których wynik podlega weryfikacji, a decyzje wymagające właściciela pozostawić ludziom. Projekt modelu, podsumowanie, lista brakującej dokumentacji czy propozycja usprawnienia mogą zostać sprawdzone. Zmiana progu zatwierdzania, wyznaczenie nowego właściciela lub wycofanie kontroli to już inna sprawa. Takie zmiany modyfikują wspólne ustalenia, a o nich muszą decydować osoby, których dotyczą.

Dlaczego decyzji o kulturze i celach nie można powierzyć AI

Architektura procesów zapisuje wybory dotyczące sposobu działania organizacji. Wynikają one ze strategii i kultury, a nie z danych.

Dwie firmy mogą realizować ten sam proces od zamówienia do płatności, korzystać z tego samego systemu ERP i obsługiwać podobne wolumeny, a mimo to potrzebować różnych architektur. Jedna poniesie dodatkowe koszty, by dotrzymać obietnicy dostawy, druga będzie chronić marżę i renegocjować warunki. W jednej lokalni menedżerowie zatwierdzają wyjątki, w drugiej decyzje zapadają centralnie. Modele mogą wyglądać podobnie, ale właściwe decyzje będą inne.

Cele określają, co organizacja chce optymalizować: szybkość, koszty, odporność, zgodność czy nakład pracy klienta. Kultura wpływa na sposób podejmowania decyzji, osoby zapraszane do konsultacji, zasady dopuszczania wyjątków i granice, których organizacja nie chce przekraczać. Dziennik zdarzeń nie zawiera tych informacji, a wiele z nich nie trafia też do dokumentów. Znają je osoby, które realizują proces.

Asystent może przyswoić zapisane przez Państwa informacje, ale nie ponosi odpowiedzialności za decyzje, które za nimi stoją. Większy model tego nie zmieni. Odpowiedzialność wymaga osoby, którą można zapytać o powody podjętej decyzji.

Jak przygotować dokumentację dla ludzi i AI?

Dokumentację należy pisać przede wszystkim z myślą o ludziach. Jasność potrzebna współpracownikowi jest równie ważna dla asystenta, a osobny zestaw dokumentów przeznaczony wyłącznie dla maszyn szybko rozminie się z tym pierwszym.

Osoba otwierająca opis procesu chce wiedzieć, co on obejmuje, dlaczego istnieje, kto za niego odpowiada, gdzie występują wyjątki i co zrobić dalej. Asystent potrzebuje tych samych informacji, zapisanych w strukturze, po której może się poruszać. Model pokazuje mu kroki i powiązania. Dokumentacja wyjaśnia ich znaczenie. Artefakty dostarczają dowodów. Role określają uprawnienia.

Dlatego zasada „pisz mniej, ale wyjaśniaj powody” sprawdza się lepiej niż rozbudowany szablon. Opis, który wyjaśnia, dlaczego wymagane jest zatwierdzenie, pomoże nowej osobie i asystentowi zapytanemu, czy można z niego zrezygnować. Samo powtórzenie informacji z diagramu nie pomoże ani jednemu, ani drugiemu.

Trzy sposoby dostępu, jedno źródło. Portal procesów służy osobom wykonującym pracę. Serwer MCP obsługuje zgodne z nim asystenty. MCP jest otwartym standardem, więc to samo połączenie działa w różnych klientach. REST API służy skryptom i integracjom do przesyłania danych lub uruchamiania symulacji. Żaden z tych kanałów nie przechowuje osobnej kopii architektury.

Tak wygląda cała architektura workflow: jedno uporządkowane źródło i trzy ścieżki dostępu, bez dodatkowej wersji prawdy. Portal nie publikuje wersji roboczych, a asystent nie ma powodu, by je odczytywać.

Braki sprawiają, że AI zaczyna zgadywać

Niepisana reguła nie jest neutralna. To puste miejsce, które model wypełni czymś, co wydaje się prawdopodobne.

Nieopisana bramka staje się decyzją, której nazwę wymyśla asystent. Nieprzypisana rola zmienia się w „zespół”. Nieudokumentowany wyjątek zostaje uznany za standardowy przebieg. Proces bez opisu staje się podsumowaniem jego struktury, a nie celu. Asystent rzadko odpowiada „Nie wiem”. Zamiast tego podaje najbardziej prawdopodobną odpowiedź, opartą na tym, jak wyglądają procesy w innych organizacjach.

W praktyce kontrola polega na tym, by jasno określić to, co już wiadomo. Jeśli coś pozostanie niedookreślone, AI podejmie decyzję za Państwa i zrobi to z pełnym przekonaniem.

Ocena jakości modelu pomaga dostrzec te braki. Wskaźnik jakości modelu na obszarze roboczym pokazuje wynik procentowy i listę niespełnionych kontroli: niepowiązane elementy, brakujące etykiety, niezrównoważone bramki oraz brak dokumentacji lub ról. Administratorzy mogą określić, które kontrole obowiązują na poszczególnych poziomach architektury, więc wynik 100% oznacza spełnienie wszystkich wymagań dla danego poziomu.

Wynik warto traktować jako listę zadań związanych z wiedzą, a nie ocenę. Niespełniona kontrola oznacza, że nie podjęto jakiejś decyzji albo nie zapisano ważnego faktu. Najistotniejsze braki rzadko dotyczą błędów na diagramie. Brak dokumentacji i ról wskazuje na niejasne intencje i odpowiedzialność, czyli obszary, w których asystent ma najmniej dowodów i najwięcej miejsca na domysły. Jakość modelu to zatem nie tyle ocena modelującego, ile mapa spraw, o których organizacja jeszcze nie zdecydowała.

Kontrole jakości modelu wskazują nieudokumentowane działania, brakujące role i błędy w modelowaniu

Wersje pozwalają zachować kontrolę

Architektura, która zmienia się bez zapisu zmian, nie jest źródłem prawdy. To tylko bieżąca opinia.

Każdy proces ma status: wersja robocza, w trakcie weryfikacji, zatwierdzony, wycofany lub zarchiwizowany. Publikacja tworzy migawkę wersji, którą użytkownicy przeglądający portal procesów mogą zobaczyć. Osoba weryfikująca może zatwierdzić proces, nadać wersji nazwę i opublikować ją w jednym kroku. Katalog pokazuje, co jest aktualne, czeka na weryfikację lub straciło aktualność. W architekturze procesów przegląd, który nadzór nad architekturą przedsiębiorstwa przewiduje dla całej architektury, odbywa się przy każdej zmianie. Jeśli organizacja ma już proces przeglądu architektury, tutaj stosuje się tę samą procedurę, tylko w krótszym cyklu.

Historia wersji ma szczególne znaczenie przy korzystaniu z AI. Można nazwać migawkę, porównać ją z wersją roboczą, przejrzeć grupy zmian, zatwierdzić je lub odrzucić, przywrócić wcześniejszy stan i opublikować konkretną wersję. Decyzje z przeglądu pozostają powiązane z migawkami, których dotyczyły, więc późniejsza edycja nie przejmuje po cichu wcześniejszego zatwierdzenia.

Taką zasadę stosujemy w przypadku AI. Asystent powinien korzystać z wersji zatwierdzonej lub opublikowanej, a nie z wersji roboczej, której nikt jeszcze nie sprawdził. Propozycja AI trafia do weryfikacji jako zmiana, a nie jako edycja, która staje się obowiązująca tylko dlatego, że jest wygodna. Wersja stanowi uzgodnienie między osobami podejmującymi decyzje a systemami, które odczytują ich ustalenia. Szerszy model operacyjny, obejmujący właścicieli, częstotliwość przeglądów i zatwierdzanie zmian, opisuje nadzór nad procesami.

Historia publikacji i statusy pokazują, którą wersję procesu zatwierdziła organizacja

Co AI może zrobić po zatwierdzeniu architektury

Dzięki uporządkowanej, zatwierdzonej architekturze asystent przestaje podawać ogólne porady i zaczyna wykonywać pracę, której wyniki można sprawdzić.

• Przeanalizować proces i zaproponować usprawnienia warte przetestowania, wraz z uzasadniającymi je danymi.
• Przygotować projekt dokumentacji działania na podstawie modelu, artefaktów i powiązanych procesów.
• Zaproponować przypisania RACI na podstawie zdefiniowanych już ról, do sprawdzenia przez człowieka.
• Odpowiadać na pytania dotyczące całego krajobrazu procesów: które procesy nie mają właściciela, gdzie brakuje dokumentacji i co zmieniło się od ostatniej zatwierdzonej wersji.
• Przygotować pierwszy model lub pierwszą wersję architektury na podstawie dokumentów, do weryfikacji proces po procesie.
• Przygotować parametry symulacji i porównać proponowaną zmianę z obecnym procesem.

Do żadnego z tych zadań asystent nie musi podejmować decyzji. Wystarczy, że jego działanie ograniczają architektura i zasady zatwierdzania.

Serwer MCP umożliwia każdemu zgodnemu z nim asystentowi dostęp do tych informacji. W planie Enterprise ograniczony klucz API udostępnia procesy i modele BPMN, dokumentację, role i RACI, metadane o osobach i strukturze organizacji, statystyki procesów oraz narzędzia analityczne ProcessMind. Narzędzia do zapisu są dostępne, jeśli klucz ma odpowiednie uprawnienia, ale zwracają propozycje i najpierw pokazują podgląd zmian bez ich wprowadzania. Dopiero potem człowiek może je zatwierdzić. Wywołania są przypisywane do klucza i zapisywane w dzienniku audytu. Przesyłanie zbiorów danych, mapowanie danych i symulacje są dostępne przez REST API, ponieważ to operacje, a nie decyzje.

W tym miejscu przydaje się też AI Assistant. Odpowiada na pytania o proces, wskazuje dashboardy i modele, na których opiera odpowiedź, a proponowaną zmianę przedstawia w formie zestawienia różnic do weryfikacji. Asystent jest użyteczny dzięki temu, że jego działanie ma jasno określone granice.

Agenci również stają się częścią modelu operacyjnego. Asystent działający na procesie potrzebuje właściciela, określonego zakresu i miejsca w architekturze, podobnie jak system lub rola. Jeśli agent może zaproponować zmianę, architektura powinna wskazywać osobę odpowiedzialną za jej przyjęcie. Tak można nadzorować agentów AI bez tworzenia osobnego frameworka: stają się kolejnym elementem opisywanym w architekturze.

Jak zacząć od małego zakresu?

Nie trzeba opisywać całej organizacji, zanim AI zacznie być użyteczne. Wystarczy jeden spójny obszar, który dotyczy rzeczywistej decyzji.

1. Wybierzcie jeden strumień wartości i kilka procesów

   Wybierzcie obszar pracy, który już budzi dyskusje, ma właściciela i mierzalny wynik. Na początek wystarczy jedno zatwierdzenie, przekazanie pracy lub pętla poprawek.

2. Najpierw wskażcie właścicieli i osoby weryfikujące

   Przypiszcie role i RACI, zanim włączycie asystenta. Uprawnienia muszą być określone, zanim AI będzie mogło je odczytać, a osoba weryfikująca powinna odpowiadać za architekturę.

3. Dokumentujcie w potrzebnym zakresie

   Opiszcie każde działanie, przypiszcie mu rolę i wyraźnie określcie jego granice. Pomińcie informacje, z których nikt nie skorzysta. Kompletna, ale nieczytana architektura to kolejny folder z diagramami.

4. Spełnijcie wymagania dotyczące jakości

   Poprawcie elementy bez etykiet, powiązań i dokumentacji. Pozostałe braki potraktujcie jako plan działań, a nie listę usterek.

5. Opublikujcie wersję i połączcie jednego asystenta

   Zadajcie pytanie, na które znacie odpowiedź, i porównajcie ją z informacjami w obszarze roboczym. Poprawna odpowiedź potwierdza, że źródło jest uporządkowane. Błędna wskazuje na brak.

6. Ustalcie regularny harmonogram przeglądów

   Sprawdźcie jakość modelu, zmiany od poprzedniej wersji i usprawnienia zaproponowane przez AI. Każdą propozycję zatwierdźcie, odrzućcie lub odłóżcie na później, a następnie zapiszcie uzasadnienie.

Pierwszy obszar pozwala sprawdzić podejście. Drugi opracowuje się szybciej. Architektura rozwija się wraz z podejmowanymi decyzjami, a nie w ramach jednorazowej kampanii dokumentacyjnej.

Architektura to wspólne ustalenia

AI zwiększa wartość dokumentacji. Model, który wcześniej przydawał się tylko podczas warsztatów, może teraz określać, co każdy asystent w firmie powie o przebiegu pracy.

Wartość z AI uzyskają nie te organizacje, które mają najwięcej agentów, lecz te, których wiedza jest jasno opisana, ma właścicieli, pozostaje aktualna i została zatwierdzona. Potrzebne są też miejsce, w którym ludzie mogą się z nią zapoznać, oraz sposób, by asystenci mogli z niej korzystać.

Tak widzimy podział zadań. AI czyta, przygotowuje projekty i sprawdza. Ludzie decydują, co jest prawdą. Architektura dokumentuje wspólne ustalenia.