AI-Disrupt на open-source BPM
На связи производственная команда компании “Хоулмонт”. Мы занимаемся развитием российской платформы OpenBPM. Это так называемый BPM-движок и набор профессиональных инструментов, сгруппированных вокруг него для комплексной автоматизации предприятий. Сегодня мы представляем новый взгляд на разработку процессных приложений.
Мы верим в то, что полностью статичные (рисованные) схемы бизнес процессов постепенно изживут себя и уйдут в прошлое. И будущее за «оживающими в моменте» схемами, которые позволяют не только верифицировать намерения бизнеса, но и подробно проработать роли, зоны ответственности, интеграции, ресурсы, риски, сроки реализации и финансовые показатели.
И мы не только верим, но и знаем, как это будет выглядеть! Давайте посмотрим вместе.
Краткое содержание:
Начинаем.
Фаза 0 – Общий контекст предприятия
Простой загрузки скиллов сегодня уже категорически не достаточно, необходимы полноценные шлюзы к источникам знаний, которые могут динамически появляться, видоизменяться, исчезать. И при этом быть представлены совершенно в разных форматах и на различных устройствах хранения.
Причем для знаний крайне важна не только доступность, но и интерпретируемость и актуальность, поэтому имеет смысл рассматривать различные схемы для их кэширования и канонизации.
Для знаний было бы замечательно иметь возможность контролировать то, какие именно факты стали для них опорой, с учетом конкретной предметной области и периода актуальности. Последнее вообще является ключевой бедой всех баз знаний, так как источники нужно сортировать не по популярности, а по уровням достоверности и свежести фактов. Причем, если так получается, что факты, отобранные из базы знаний по результатам контекстного поиска, противоречат друг другу, то агент обязан об этом прямо предупредить, а не молча выбирать что-то “наиболее подходящее по фазе луны” и завязывать на это всю дальнейшую бизнес-логику в процессе.
В категорию знаний также относятся всевозможные текстовые регламенты и соглашения о моделировании.
И еще один момент. Про модель ролевого доступа к базам знаний можно написать отдельную статью. Здесь лишь отметим, что вопрос этот очень важный и что через такую “дыру” в спецификацию для разработки могут “протечь” корпоративные и/или персональные данные. Поэтому агенты - это те же сотрудники, и на них точно также должны распространяться права и категории ограниченного доступа к информации.
Фаза 1 – Давай с тобой поговорим
Предметная область, в свою очередь, может быть задана/очерчена/ограничена посредством шаблонов, это уже годами проверенный подход, доказавший свою надежность и эффективность.
Режим интерактивного взаимодействия, похожего на интервью, также хорошо себя зарекомендовал в бизнес-анализе. Но важно уметь не только задавать правильные вопросы, но и подсказывать пользователю наиболее вероятные варианты для быстрых ответов. То есть задавать направления для уточнения и расширения постановки. А также, с самых первых шагов, измерять и контролировать полноту создаваемой спецификации.
Результатом интервью, то есть результатом первичного взаимодействия агента с пользователем, является формирование структуры намерений, опирающихся на факты, почерпнутые из баз знаний для конкретной предметной области. А дальше нам уже предстоит эти намерения подтвердить (верифицировать), создав набор исполняемых артефактов, который будет являться прототипом для целевого процессного приложения. Создает артефакты, естественно, агент, но у пользователя есть возможность их точечно отредактировать.
Фаза 2 – Создаем артефакты
Хороший пример по зонам ответственности. В кредитном конвейере Комплаенс-офицер сам не исполняет задачи, но именно он реализует логику принятия решений на основе таблиц бизнес-правил. И поэтому он является полноправным участником процесса, которого никак нельзя “потерять”. Агент помогает нам учесть такие ситуации.
Ещё один сложный участок - интеграции. На этапе прототипа нам, казалось бы, можно обойтись без них. Но тогда наша спецификация будет не полной. Поэтому интеграции необходимо реализовать, хотя бы в режиме “замкнутых самих на себя” петель (external task на моках), но при этом с полноценным описанием форматов данных и контрольными примерами.
А вот сгенерировать тестовые примеры, то есть правдоподобные и согласованные пакеты данных, и при этом не раскрыть “персоналку” и особо не повторяться - это получается прям отдельная категория творческих задач, с которыми AI-агент на сегодняшний день уже достаточно хорошо справляется.
Отдельного внимания заслуживают нефункциональные требования, открытые вопросы и ограничения, не все из которых получается полноценно проработать на этапе интервью. Эти риски должны быть выявлены и явно задокументированы в приложениях к общей спецификации на разработку. Таким образом, агент подготовил почву для комплексной отладки процесса.
Фаза 3 – Гоняем в sandbox
Прогон в “песочнице” должен быть похож на игру, максимально быстрым и комфортным. Агент скомплектовал для нас уже наполненные по данным прикладные кейсы, с заранее известными исходами. Мы можем воспользоваться ими в качестве начальных шаблонов, но при этом имеем возможность менять данные.
В процессе прогонов нет необходимости постоянно заставлять оператора перелогиниваться, так как смену сессионного окружения можно реализовать и контролировать автоматически.
Прозрачности прогонам добавляет и так называемый “журнал событий”, из которого становится понятно не только куда, но и почему, на сновании чего мы свернули в той или иной развилке маршрута. И, разумеется, прогонов в песочнице должно быть несколько, никак не меньше всех типичных (а лучше и не только типичных) вариантов по бизнес-кейсам.
Фаза 4 – Сводим спецификацию
Сборка агентом пакета для реализации - самый ответственный этап. Тут важно, чтобы на выходе был полностью согласованный комплект процессных артефактов, спецификация и приложения к ней для промышленной разработки. И при этом итоговое процессное решение должно иметь низкий порог входа, быть совместимым с технологическим ландшафтом конкретной компании, опираться на популярные/понятные технологии, чтобы не "пугать" потом корпоративные службы ИТ и Информационную безопасность.
Фаза 5 – Ты меня понял, осилишь?
Имея достаточно подробную спецификацию для разработки, можно с уверенностью проводить оценку, как по времени, так и по необходимым для реализации ресурсам. Такую оценку можно обсудить и с "живым" техлидом, и с другим "исполнительным агентом". А также наметить задачи по внедрению, масштабированию, мониторингу, бизнес-анализу и последующему совершенствованию автоматизируемых процессов.
Однако, ни с людьми, ни с агентами, нет никакой гарантии, что спецификация будет реализована в полном объеме. Поэтому имеет смысл рассматривать жизненный цикл спецификации как самостоятельного артефакта, то есть замкнуть цикл обратной связи после реализации. Чтобы потом нам в явном виде стали видны расхождения между тем, что планировалось к реализации на этапе верификации намерений бизнеса, и тем, что реально получилось реализовать конкретной командой разработчиков. И вот с этим дальше уже можно будет итеративно работать.
Если спецификация прошла реализацию и сверку, она становится самым надежным фактом во всей нашей базе знаний, то есть система начинает сама вытеснять устаревшие сведения своими же проверенными артефактами.
Кто пользователь этого нового класса ПО?
Мы видим так, что разрабатываем простой и надежный инструмент для так называемых бизнес-инженеров или для business technologist, если следовать современной методологии Gartner (https://www.gartner.com/en/documents/5673955). Это автоматизация бизнес-процессов на базе AI, которая не требует долгого погружения. Конечным бенефициаром здесь является бизнес-заказчик, он же, в пределе, сам сможет управлять новой AI-поверхностью и подтверждать/реализовывать свои намерения на современных open-source технологиях.
Зачем здесь BPMN?
Потому что бизнес-процессы - это пока что про людей, про “человеков”, которые реально выполняют перемещение/трансформацию/анализ или обработку материальных объектов, документов, информации в окружающем их реальном мире. А людям, в силу особенностей восприятия, требуется наглядность.
Где же здесь IDP и куда делись разработчики?
Описанная выше "Фаза 5" предполагает передачу собранного и верифицированного прототипа на уровень профессиональной разработки. С последующей имплементацией в dev-sec-fin-bpm-ops пайплайны конкретного корпоративного контура. Так что инженеры без работы в любом случае не останутся. Более того, если со стороны бизнеса гипотезы и инсайты начнут проверять быстрее и чаще, то и работы инженерам значительно прибавится.
Зачем вообще это нужно?
Цель - проверять гипотезы и отрабатывать бизнес инсайты намного раньше конкурентов, мгновенно выводить продукты на рынок, перестраивать бизнес, делая его более гибким и чутко реагирующим на предпочтения рынка, на внешние и на внутренние вызовы.
Вместо эпилога
Это достаточно длинный и амбициозный путь, который нашей команде еще предстоит пройти до запуска описанных инициатив на продуктивной среде. Но мы твердо намерены предоставить нашим клиентам лучшие в своем классе платформы для комплексной автоматизации бизнеса.
Пожалуйста, присоединяйтесь! Мы будем рады попутчикам и помощникам на этом пути.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.