Для этого блога я хочу, чтобы вы представили региональную страховую компанию, чья команда по работе с претензиями занимается приемом и рассмотрением заявок в Pega. На протяжении более десяти лет рабочий процесс накапливал уровни проверки: претензия поступает, проверяющий сверяет условия полиса, а шлюз принятия решений направляет ее на оплату или отказ.
Ожидания клиентов не изменились, но изменилось то, насколько быстро ожидаются решения и какая часть этой проверки все еще требует участия человека. Каждый квартал, в течение которого этот процесс остается «замороженным» на платформе, которую трудно расширять, — это еще один квартал, в течение которого конкурент, работающий на более адаптивном решении, сокращает разрыв в цикле обработки.
Этот разрыв между тем, как процесс работает сегодня, и тем, что могли бы улучшить инструменты ИИ, является веской причиной рассмотреть возможность выхода за рамки Pega. В предыдущих статьях этой серии, «Накапливающиеся расходы при работе на Pega» и «Готовы расстаться с Pega?», рассматривались аргументы в пользу изменений и варианты миграции. Здесь мы рассмотрим саму работу по преобразованию: где ИИ помогает, где он может не справиться и где человеческий контроль остается необходимым.
Начните с конвертера — и знайте его ограничения
У Camunda уже много лет есть путь миграции с Pega. Первоначальный подход, доступный и сегодня, — это бесплатный конвертер с открытым исходным кодом в репозитории GitHub. Это проект Maven, который вы запускаете локально: укажите на XML-экспорт из Pega, и он создаст файл BPMN, сохраняющий структуру исходного процесса.
У конвертера есть четкие ограничения. Потоки Pega не используют BPMN в качестве своего стандартного процесса, поэтому перевод без потерь невозможен. Результат — это структурная отправная точка, а не готовый исполняемый процесс. Таблицы решений, коннекторы или сопоставление данных требуют проверки в Camunda Modeler, прежде чем они будут готовы к эксплуатации. Инструмент имеет то же ограничение, что и любой структурный конвертер: он может перемещать фигуры, но не может принимать решения о том, что эти фигуры должны означать в вашей среде.
Что меняет ProcessOS
Рассмотрим вымышленную страховую компанию с десятилетним процессом обработки претензий в Pega. Обнаружение выявляет несколько проверок, которые повторяют друг друга. Переработанный рабочий процесс мог бы устранить дублирование, направлять претензии с низким уровнем риска через агента и сохранять одобрение человеком выше определенного порога. Это результат, отличный от простого переноса существующего процесса.
ProcessOS меняет подход к преобразованию. Он использует документацию, системные журналы и информацию от людей, которые управляют процессом, чтобы понять его текущее состояние и обосновать переработанный рабочий процесс. Цель состоит не в том, чтобы переписать или переместить каждый существующий шаг. Цель — определить, где должны действовать люди, агенты и системы.
Такой подход также формирует процесс миграции: короткие рабочие сессии, частая проверка, привлечение профильных экспертов, когда это необходимо, и работа инженеров непосредственно в среде заказчика.
Где преобразование только с помощью ИИ становится рискованным
Преобразование только с помощью ИИ создает риски, которые не всегда очевидны. Рассмотрим две ошибки, которые могут не проявиться при развертывании. Условие шлюза может потерять префикс FEEL, поэтому Camunda считывает его как фиксированную строку, а не как выражение, и условие никогда не вычисляется. Действие вызова (call activity) может пропустить настройку распространения переменных, что без предупреждения изменит данные, возвращаемые в родительский процесс.
ИИ может помочь с кодом и очисткой, но качество преобразования зависит от модели и задачи. Детерминированный конвертер дает воспроизводимый результат; результат, созданный ИИ, требует тщательной проверки. Ни один из подходов не может решить, имеет ли смысл бизнес-правило, как итоговая согласованность влияет на решение или соблюдено ли требование аудита. Эти суждения принадлежат людям, которые понимают процесс.
Пример перехода с Pega на BPMN
Возьмем простой процесс запроса-проверки в Pega с решением об одобрении/отклонении. Экспортируйте модель в XML, затем используйте Claude с навыком моделирования BPMN от Camunda, чтобы создать BPMN-модель первого прохода.
Исходный процесс содержит специфические для Pega элементы, имена и логику принятия решений. XML-экспорт предоставляет входные данные для преобразования, показанного ниже.
Результат — это BPMN-модель с задачей службы, представляющей подпроцесс, исключающим шлюзом для принятия решения, ветвями с метками «Одобрено» и «Отклонено» и сходящимся шлюзом перед конечным событием. Это структурный первый проход, аналогичный по назначению результату детерминированного конвертера, но созданный с помощью рабочего процесса с поддержкой ИИ.
Он не готов к эксплуатации. Имена задач являются заполнителями, а условия ветвления все еще нужно связать с исполняемой логикой принятия решений. Более сложные процессы требуют дополнительных подпроцессов, ветвления и проблем с макетом. Перед развертыванием команды должны уточнить модель, настроить ее поведение и проверить каждый путь на соответствие исходным бизнес-требованиям.
Практическая последовательность миграции
Миграция с Pega на Camunda 8 состоит из пяти шагов: оценка, преобразование, очистка, реинжиниринг и проверка. Каждый шаг требует контрольной точки перед переходом к следующей работе.
- Оценка. Изучите реальный процесс Pega — а не только его документацию — и оцените сложность перед преобразованием.
- Преобразование модели. Используйте конвертер Pega-to-BPMN или проверенный подход «от обнаружения к модели», чтобы создать структурную базу. Проверьте результат перед продолжением.
- Использование ИИ для кода и очистки. ИИ может помочь с кодом коннекторов, сопоставлением данных и уточнением модели при условии тестирования и проверки. Не следует предполагать, что он сам по себе создаст исполняемый и правильный результат.
- Реинжиниринг вместо перемещения. ProcessOS оправдывает свое название здесь: он использует то, как процесс работает сегодня, в качестве контекста для того, как он должен работать сейчас, включая места, где агент может разумно выполнить шаг, который раньше человек должен был делать вручную.
- Проверка результата. Согласуйте логику принятия решений, предположения о согласованности данных и требования аудита с владельцами процесса перед запуском. Убедитесь, что реализация фиксирует записи, необходимые для аудиторских обязательств организации.
Используйте ИИ там, где он помогает. Возлагайте на людей ответственность за решения, требующие бизнес-суждения. Агентская оркестрация объединяет агентов, людей и системы в скоординированный процесс с явным контролем и прозрачностью того, как выполняется работа.
Готовы выйти за рамки Pega? Изучите услуги по миграции и лицензионные стимулы Camunda. Получите подробную информацию о вашей миграции.
