Как обстоят дела с ИИ в реальном мире? Узнайте из опыта Лили Ван, CIO в Barclays, и Бернхарда Шаффрика, главного аналитика Forrester, которые исследуют, как предприятия преодолевают разрыв между инвестициями в ИИ и получаемыми результатами.

В этом пошаговом руководстве вы узнаете о последних способах использования агентного ИИ и о том, как уже сегодня воспользоваться агентной оркестрацией с Camunda.

Каждый руководитель в сфере технологий знает это ощущение. Заходишь в зал для совещаний, где собраны недовольные руководители отделов, и у всех — истории о системах, которые не взаимодействуют друг с другом, о данных, застрявших в изолированных хранилищах, и о процессах, требующих ручного вмешательства на каждом этапе. Обещания цифровой трансформации кажутся всё более недостижимыми, когда организация функционирует скорее как набор изолированных островков, чем как связанное целое.

Эта проблема уже не просто вопрос технологий. Это ключевая бизнес-задача, которая обходится организациям в миллионы потерянной производительности, упущенных возможностей и конкурентных потерь. Исследования McKinsey показывают, что 90 процентов компаний сейчас реализуют проекты цифровой трансформации, но большинство сталкиваются с фундаментальной проблемой — обеспечить эффективное взаимодействие своих систем.

Жестокая ирония заключается в том, что отдельные приложения стали мощнее и сложнее, а само предприятие в целом стало более фрагментированным. Каждая новая система обещает решение конкретной задачи, но в итоге все они вместе создают сеть сложности, которая может задушить операционную эффективность.

Однако выход есть. Платформы оркестрации перестают быть просто удобными инструментами для управления процессами и становятся основным приложением, от которого зависит, будет ли предприятие процветать или выживать.

5 сентября 1977 года Вояджер-1 отправился в свой вояж по Солнечной системе. Не могу сказать, что прям помню, как это было, но впечатление осталось — тогда много говорили об этом. Ну или такой был у меня информационный пузырь вокруг астрономии. Жили мы тогда возле планетария, и я шастал туда, ну как минимум, пару раз в неделю. Или это мне сейчас так кажется. В общем, увлекался звездами.

В те годы аппараты уже привычно летали на Венеру и Марс, но это практически рядом, а тут такое — замахнулись выйти в дальний космос! И таки получилось! Уже в 1990 году оба Вояджера покинули пределы Солнечной системы. Когда читал про их план полета, казалось, что это будет совсем не скоро, а уже и все сроки прошли. А он все летит…

В стратегии автоматизации наступил критический момент для руководителей предприятий. Потенциальные возможности AI-агентов, способных автономно принимать решения в сложных бизнес-процессах, привлекли внимание советов директоров. Но реальность, стоящая за заявлениями многих поставщиков, отличается. Несмотря на то что вендоры активно используют терминологию ИИ, разрыв между обещаниями и реальными возможностями никогда не был столь велик.

Этот разрыв приводит к реальным последствиям для организаций, принимающих стратегические решения в области технологий. Ошибка в выборе ведет не только к растрате бюджета, но и может надолго затормозить инициативы цифровой трансформации. Чтобы отличить настоящие инновации от искусного маркетинга, нужно выходить за рамки поверхностных функций и исследовать фундаментальные возможности, которые определяют следующее поколение средств автоматизации бизнес-процессов.

Есть множество инструментов для создания AI-агентов, и в основе им нужно три вещи. Во-первых, им нужно понимать свою основную цель и правила, в рамках которых они должны работать. Например, вы можете создать агента и сказать ему: «Ты здесь, чтобы помогать клиентам с общими запросами о существующих услугах банка». Во-вторых, нам нужен промпт — это запрос к агенту, который агент может попытаться выполнить. И наконец, нужен набор инструментов — это действия и системы, к которым агент имеет доступ, чтобы исполнить запрос.

Большинство конструкторов агентов объединяют эти три требования в одну статическую, синхронную систему, но в Camunda мы решили этого не делать. Мы обнаружили, что это создаёт слишком много ограничений для применения, не масштабируется и сложно поддерживается. Чтобы преодолеть эти ограничения, мы придумали концепцию, которая позволяет разделить эти требования и полностью визуализировать агента так, чтобы открыть его для гораздо большего числа сценариев использования — не только на техническом уровне, но и в такой форме, которая снимает многие опасения у людей, добавляющих AI-агентов в свои основные процессы.

Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:

Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?

Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).

На дворе лето, середина года уже позади. Самое время оглянуться назад и критически взглянуть на прогнозы, которые делались в декабре-январе. Итак, давайте посмотрим, что обещали нам по части BPM в 2025 году и что из этого сбылось, а что осталось лишь в фантазиях авторов этих прогнозов. В принципе все писали более-менее одно и то же, поэтому для разбора взял один рандомный прогноз «BPM Solution for 2025: Trends and Updates».

Когда речь заходит о производительности BPM-ldb;rf, главным показателем является пропускная способность заданий и таймеров. Проще говоря: чем больше заданий или таймеров выполняется за определённый промежуток времени, тем быстрее смогут продолжать выполнение процессы или кейсы, которые их используют.

Как получить прозрачность в бизнес-процессах, если архитектура строится на микросервисах и событийных потоках? В своей статье Бернд Рюкер, сооснователь Camunda, делится практическими подходами к отслеживанию и управлению процессами в распределённых системах. Он объясняет, как переход от простого мониторинга событий к полноценной оркестрации помогает лучше понимать происходящее, своевременно реагировать на инциденты и сохранять контроль над сложными бизнес-операциями. В статье разбираются плюсы и минусы различных подходов — от Elastic-подобного мониторинга до использования движков рабочих процессов, а также рассматривается важность баланса между оркестрацией и хореографией.

Добро пожаловать во второй пост серии о Flowable Async Executor. В первой части мы рассмотрели базовые понятия: что такое асинхронные задания и таймеры, и почему они полезны при построении BPMN- и CMMN-моделей. В последнем разделе мы также показали общую схему новой архитектуры Async Executor.

Исключения являются частью любого процесса. Разработчики, создающие бизнес-процессы, должны уметь обрабатывать исключения в бизнес-кейсе, чтобы гарантировать, что сам процесс устойчив и может продолжаться после возникновения сбоев. Логика обработки исключений различается в зависимости от вашей задачи и инструментов, которые у вас есть в распоряжении. В этой заметке я попытался определить различные методы обработки исключений, используя язык паттернов. Каждый паттерн следует определённой структуре, называемой Контекст (общая ситуация, в которой проблема повторяется), Проблема (формулировка), Условия (условия, при которых можно рекомендовать предложенные решения) и Решение. Итак, давайте приступим.

Flowable Async Executor (также известный как Job Executor) — это ключевой компонент Flowable. По сути, это многократно используемый, автономный компонент, работающий внутри различных движков Flowable и обеспечивающий асинхронное выполнение логики.

Примечание: Этот пост является продолжением предыдущего, так как многие читатели спрашивали, что происходит, когда у асинхронных заданий заканчиваются попытки повторного выполнения.

Я много общаюсь о микросервисных архитектурах с «не-Java-людьми» — будь то разработчики на C#, энтузиасты Node.JS/JavaScript или GoLang. Все они сталкиваются с необходимостью оркестрации в микросервисной архитектуре — или просто хотят использовать workflow, упорядочивание действий, обработку таймаутов, Saga и компенсации, а также другие полезные возможности.

Open Source BPM-платформа Camunda отлично подходит для этих задач. Ориентированность на разработчиков — один из ключевых принципов продукта, но при изучении документации может показаться, что она рассчитана в основном на Java-разработчиков. Платформа предоставляет множество точек расширения и интеграции, но всё это реализуется на Java. Значит ли это, что другим разработчикам путь закрыт?

Нет! На самом деле, запустить Camunda и работать с ней без знания Java очень просто — архитектуру можно выстроить так, чтобы писать код на любом удобном языке. В этом посте:

Low code стремительно ворвался в корпоративный ландшафт, чего от него никто не ожидал. Мы думали — ну, да, занятная вещица, пусть пользователи поиграют в программистов, лишь бы работать не мешали. А сегодня куда ни глянь, все хотят, чтоб даже у серьезных энтерпрайз-решений обязательно были какие-то хотя бы элементы лоукода. Но зачем?

Не знаю, как у вас, но моя жизнь состоит из хаотичных «воркфлоу» и «процессов», полных сюрпризов и неожиданных ошибок, которые не работают так, как ожидается, потому что я сама немного сумасшедшая, забывчивая и непредсказуемая. Однако в бизнесе такой хаос недопустим, и именно поэтому компании стремятся автоматизировать свои процессы и обращаются к разработчикам, чтобы мы нашли решение. К счастью, существует множество платформ, позволяющих создавать надёжные, масштабируемые и управляемые воркфлоу, которые можно визуализировать так, чтобы любой заинтересованный (с техническими знаниями или без) мог видеть, что происходит в процессе. Эта статья — краткое введение в платформы автоматизации воркфлоу Camunda и Flowable, демонстрация примера автоматизации, лучшие практики и основные сложности при использовании этих платформ.

Как перейти от первых проектов к успешной автоматизации сотен процессов с помощью гибкого пошагового подхода.

Нам часто задают такие вопросы:

— Как масштабировать внедрение Camunda в рамках всей компании?

— Как создать корпоративную платформу для управления процессами?

Мы видим, как масштабно Camunda используется в таких компаниях, как Goldman Sachs (3000 процессов, 8000 пользователей в день), Societe Generale (600 процессов, 60 000 завершённых задач в месяц, 7500 активных пользователей) или 24Hour Fitness (800 процессов, 230 миллионов выполнений активностей в день). Как нам достичь такого уровня?

Увы, регулярно приходится сталкиваться с решениями, которые только осложняют жизнь. И хочется спросить их разработчиков — а вы чем думали, когда это делали?

Конечно, есть универсальная отмазка: так хотел заказчик. Да, к сожалению, это так. Действительно решает заказчик. Но можно его хотя бы попытаться переубедить. Ну или не участвовать совсем в тупых проектах.

Кстати, такая же ситуация в архитектуре. Если вы видите на улицах какие-то уродливые дома, они появились не потому, что архитекторы были криворукие. Решение о том, каким будет дом, принимает заказчик. И предполагать у него наличие художественного вкуса было бы большой натяжкой. Потому и появляется вот такое:

Вы начали свой первый проект, используя автоматизацию бизнес-процессов как сервис с Camunda Cloud? Одной из первых задач будет набросать базовую архитектуру вашего решения. Этот блог-пост поможет вам ответить на важные начальные вопросы: как подключить движок выполнения процессов Zeebe к вашему приложению или к внешним системам? Что такое job worker, какую роль он играет и сколько их вообще нужно?