Интегрированные системы управления бизнес-процессами (Business Process Management Suite, BPMS) – это платформы для разработки и выполнения бизнес-приложений, предлагающие базовый набор средств моделирования, анализа, репозитория процессов и правил, имитационного моделирования, средства разработки и среду для выполнения процессно-ориентированных бизнес-приложений, средства анализа эффективности, мониторинга и отчетности.

Системы BPMS поддерживают следующие этапы управления бизнес-процессами:

● моделирование процессов;

● моделирование данных;

● определение формул;

● определение бизнес-правил;

● определение участников;

● определение точек интеграции;

● имитационное моделирование процессов;

● исполнение процессов;

● мониторинг процессов.

Функциональность систем BPMS:

● визуализация процессов;

● имитационное моделирование процессов;

● мониторинг действий;

● создание и использование бизнес-правил;

● интеграция систем и данных;

● выполнение потоков работ;

● поддержка процессной нотации.

В следующей таблице функциональность BPMS рассматривается более подробно.

Системы BPMS обладают двумя взаимосвязанными преимуществами: скорость изменения бизнес-приложений и контроль операций на различных уровнях детализации. Системы BPMS обладают гибкостью, позволяющей быстро адаптировать приложения к меняющимся бизнес-потребностям, конкурентному давлению и рыночным возможностям. Характерный срок разработки и внедрения приложения – 10 недель при развертывании в облаке и до года, если развертывается полная локальная инфраструктура.

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

Ключевые компоненты прикладной архитектуры систем BPMS показаны на следующем рисунке.

Большинство BPMS поддерживают сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA) и благодаря этому легко интегрируются с устаревшими приложениями.

BPMS дают возможность быстро перепроектировать операции и бизнес-процессы, а сервис-ориентированная архитектура обеспечивает модульный подход к изменению бизнес-процессов. Модули при этом называют сервисами. Модульность способствует повторному использованию данных, бизнес-моделей, правил и т. д. Их легко модифицировать на уровне модели, чтобы затем из нее повторно сгенерировать приложение. Техническая архитектура платформ BPMS показана на рис. 8.3.

В следующей таблице перечислены уровни инфраструктуры BPM/SOA.

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

● Движок бизнес-правил (rules engine) представляет собой программное обеспечение для выявления, описания, оптимизации и обеспечения качества технологических и бизнес-правил.

● Система управления бизнес-правилами (Business Rule Management System, BRMS) в дополнение к этому предоставляет репозиторий, позволяющий сопоставлять правила друг с другом на предмет противоречий определений или контекста, что обеспечивает качество и отсутствие дублирования. Хотя это программное обеспечение скорее относится к технологическому, так как определение правил требует подготовки и опыта и в ИТ, и в бизнесе, новые графические нотации и шаблоны делают определение и конфигурирование правил более дружественным по отношению к пользователям.

На практике правила выглядят как выражения если – то: если (событие или значение), то сделать что-то. Поскольку список того, что надо учитывать при принятии решений, может быть достаточно длинным и сложным, определение правил может оказаться серьезной задачей.

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

● операционные правила;

● правила принятия решений;

● правила потока процесса;

● процедурные правила и политики;

● правила использования/защиты данных;

● правила разграничения доступа;

● правила мониторинга и отчетности;

● технические правила, связанные с запросами к данным, преобразованием данных, интерфейсами между приложениями и т. п.;

● юридические правила;

● финансовые правила;

● правила мониторинга и измерений;

● регуляторные правила.

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

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

В следующей таблице представлена общая схема классификации правил BRMS.

То, как правила описаны и закодированы, сказывается на работе компьютерных приложений. Если правила чересчур сложные (например, несколько уровней логики; длинная цепочка вычислений; несколько интеграционных вызовов), их выполнение может быть медленным. Если подряд вызывается слишком много медленных правил, медленным будет приложение. Поэтому кодирование и использование правил должно тщательно проверяться на соответствие внутреннему стандарту, являющемуся адаптированной версией рекомендаций поставщика ПО.

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

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

Репозиторий содержит определения бизнес- и технологических правил. Репозитории правил обычно используются для:

● централизованной кодификации знаний организации:

○ описания шаблонов правил взаимодействия с клиентами, таких как соответствие требованиям, кросс-сейл и ап-сейл и т. п., включая:

■ скоринговые карты (скоринг и ранжирование);

■ деревья принятия решений (на основе логики если – то);

■ карты принятия решений (на основе значений одной или двух переменных);

■ таблицы решений (на основе серии условий);

○ создания, согласования, тестирования и внедрения правил;

○ хранения правил и предоставления к ним общего доступа;

● поиска имеющихся описаний правил с целью:

○ задания последовательности шагов в модели процесса;

○ генерации приложений BPMS;

○ модернизации унаследованных приложений;

○ формирования требований к интерфейсам унаследованных приложений;

● вызова правил из программного кода и мониторинга таких вызовов:

○ устранения противоречий между правилами и избыточности;

○ выявления правил, больше не соответствующих требованиям законодательства;

○ повышения качества правил – ясности, целостности, отсутствия дублирования;

○ анализа SLA, KPI, формул шести сигм и т. п.;

● контроля качества и целостности правил и наборов правил:

○ управления изменениями правил;

○ управления созданием новых правил;

○ формирования полной картины использования правила для оценки последствий его изменения;

○ тестирования правил;

○ управления доступом к правилам;

● анализа зависимостей в использовании правил и их взаимосвязей по схеме что – если:

○ аналитики по историческим и текущим данным;

○ развертывания правил для использования в приложениях и в BPM-системах;

● валидации используемых правилами данных;

● использования, редактирования и тестирования данных;

● использования унаследованных данных.

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

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

Движок правил (rules engine) – это программное обеспечение, дающее возможность непрограммистам добавлять правила и изменять их логику. Движок правил позволяет:

● экстернализировать правила – отделить их от прикладного программного обеспечения и хранить в стандартном формате, используя стандартный словарь;

● хранить правила в центральном репозитории правил;

● ускорить внесение изменений в ПО благодаря полной информации о правилах и использующих их программах;

● создавать гибкие описания правил (со ссылками на унаследованные приложения, интервью, документы);

● повышать качество правил и стимулировать их повторное использование;

● тестировать правила (на предмет избыточности, пробелов, нарушений логики и т. п.);

● контролировать версии;

● делать правила наглядными;

● быстрее оптимизировать приложения и бизнес-операции благодаря экстернализации правил;

● централизованно скорректировав правило, изменить бизнес-логику везде, где оно используется.

DMN (Decision Modeling and Notation) – новый стандарт модели и нотации принятия решений, дополняющий BPMN. DMN стандартизирует бизнес-правила, благодаря чему их можно переносить между разными программными продуктами и разными организациями. Следует ожидать, что на стандарт DMN перейдут системы BRMS и поддерживающие описание и исполнение бизнес-правил системы BPMS.

За последние 20 лет системы BPMS прошли путь от простых средств моделирования потоков работ до комплексных интегрированных наборов модулей, формирующих полную операционную платформу и среду. В ходе эволюции системы BPMS дополнились новыми технологиями: разработка с (без) минимальным кодированием (no-code/low-code), мобильный доступ и социальное взаимодействие, роботизация процессов (RPA), искусственный интеллект (ИИ), машинное обучение, блокчейн и смарт-контракты. Современные BPMS могут развертываться как в локальной ИТ-инфраструктуре, так и в облаке.

Новое поколение процессно-ориентированных платформ называется Intelligent Business Process Management Suites (iBPMS) – интеллектуальные системы управления бизнес-процессами.

BPMS, как и большинство других технологий, быстро эволюционируют. Ранние энтузиасты устремились в отрасль, ожидая увидеть революционные достижения. По мере того как интерес к оптимизации бизнес-процессов и к построению более эффективных бизнес-моделей проявляют все большее число предприятий, технологии BPM тоже должны становиться более эффективными. Системы iBPMS явились результатом такой эволюции; реализуя функциональность интеллектуальной аналитики, они повышают отдачу от BPM.

В дополнение к основной функциональности BPMS, перечисленной выше, платформы iBPMS предоставляют следующую функциональность:

● Продвинутая аналитика. Выявление закономерностей, формирование прогнозов, выработка рекомендаций на основе передовых технологий анализа данных, см. раздел 8.2.4.1.

● Искусственный интеллект. Системы, способные обучаться и рассуждать как люди, см. раздел 8.3.2.

● Мобильный BPM. Предоставляет доступ к приложениям сотрудникам, работающим удаленно в полевых условиях, тем самым обеспечивая их полными данными, быстрым откликом, устраняя дублирование. Приложения разрабатываются быстро за счет минимального кодирования (low-code), интегрируются с офисом через облако и поддерживают разнообразные процессы – от логистики до согласования, монтажа и контроля качества.

● Социальный BPM. Интеграция с Facebook, Instagram, LinkedIn и т. п. Социальный BPM позволяет организациям слышать голос социальных сетей, хотя пока что это не считается лучшей практикой. Социальный BPM – это обоюдоострый меч, он обеспечивает обратную связь по продуктам и услугам (положительную и отрицательную), заставляющую компании реагировать. Более полезное применение социального BPM – внутри корпоративных сетей для поддержки совместной работы распределенных глобальных команд.

● Облачный BPM. Современным трендом является предложение BPMS в виде облачного сервиса.

● Автоматическое выявление процессов (process mining). Анализ бизнес-процессов на основе журналов событий, см. раздел 8.2.4.3.

● Роботизация процессов (RPA). Разновидность технологии автоматизации бизнес-процессов, основанная на программных роботах (ботах), см. раздел 8.3.1.

● Предсказательная аналитика. Аналитика, учитывающая временной аспект, см. раздел 8.3.2.

● Интернет вещей (Internet of Things, IoT). Система взаимосвязанных вычислительных и других устройств с уникальными идентификаторами, способных обмениваться данными без взаимодействия человека с человеком или человека с компьютером. См. раздел 8.3.5.

● Блокчейн (смарт-контракты). Технология, которая напрямую управляет передачей активов между сторонами после выполнения определенных условий; позволяет автоматически исполнять договорные обязательства. См. раздел 8.3.2.

● Динамический кейс-менеджмент (Dynamic Case Management, DCM). Поддержка исключений из правил, дающая возможность быстро принимать разумные решения в непредсказуемых сценариях см. раздел 8.2.4.2.

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

В этом разделе рассматриваются не традиционные системы управления базами данных (СУБД), а последние разработки, такие как NoSQL. Технология NoSQL (Not-only-SQL) разработана для обработки больших, неструктурированных, мультимедийных данных в новых цифровых приложениях. Технология NoSQL способна справиться с задачами обработки больших данных в современных веб-приложениях и сервисах, для которых характерны большой объем и разнообразие данных, высокие требования к масштабируемости, производительности и отказоустойчивости.

Разработка приложений для работы с данными начинается с того, что администраторы баз данных вместе с аналитиками проясняют связи между сущностями и создают диаграммы «сущность – связь». Однако цифровые тренды и изобретение NoSQL для управления большими данными заметно изменили подходы к проектированию, управлению и физическому размещению баз данных – они становятся объектно-ориентированными, графовыми, документо-ориентированными и т. д. У каждой есть своя оптимальная область применения.

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

Интересно, что в начале 1990-х годов мы также наблюдали появление интеллектуальных СУБД. SQL, стандартный и самый популярный язык баз данных, постоянно развивается. Он включил в себя функциональность декларативного искусственного интеллекта. Аналогичным образом базы данных NoSQL включают в себя аналитическую функциональность, в том числе для неструктурированных и мультимедийных данных, хранящихся в СУБД.

На следующем рисунке показана эволюция СУБД в сторону интеллектуальных СУБД (Intelligent Database Management System, iDBMS).

Еще одно направление эволюции – появление интегрированных архитектур данных и процессов, обеспечивающих мониторинг и управление процессами в реальном времени на основе данных. Кроме того, «форсажем» и для процессов, и для данных служат технологии искусственного интеллекта.

Динамический кейс-менеджмент (Dynamic Case Management, DCM) – это управление работой в рамках кейса с использованием технологий автоматизации и оптимизации. В данном контексте кейс – это совокупность информации о конкретном экземпляре чего-либо, например о человеке, компании, инциденте или проблеме. Именно возможность делать исключения из правил позволяет быстрее принимать разумные решения в непредсказуемых сценариях.

Появление концепции кейс-менеджмента является результатом исследований умственного труда. Согласно исследованию Tallyfy, две трети рабочего времени работника умственного труда тратятся на неструктурированную и зачастую непредсказуемую работу, как показано на следующем рисунке.

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

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

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

Важным аспектом динамического кейс-менеджмента является выявление типовых шаблонов. Forrester Research выделяет три вида деятельности, подпадающих под кейс-менеджмент:

1. Исследование (расследование).

2. Запрос на обслуживание.

3. Управление инцидентами.

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

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

Примеры: запросы регулятора, регулирование ИТ, запросы на аудит, слияния и поглощения, поиск, выемка и предоставление электронной информации.

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

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

Запросы на обслуживание по своей природе инициируются событиями. В качестве примера можно привести службу поддержки, куда поступают и где регистрируются звонки с запросами. Регистрация клиента и адаптация нового сотрудника также инициируются событиями и могут рассматриваться как запросы на обслуживание.

Примеры: администрирование льгот, обслуживание клиентов, обработка претензий, выдача кредитов, андеррайтинг.

Применяется в отраслях: страхование, банковское дело, здравоохранение, ИТ-услуги, контакт-центры и другие организации, взаимодействующие с клиентами.

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

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

Управление инцидентами охватывает вспомогательные процессы, в которых все должно пройти определенным образом, но полная автоматизация которых невозможна. Работа по управлению инцидентами может (но не обязательно) включать следующие составляющие:

● применение:

○ политик;

○ правил;

○ отслеживания;

● аудиторские журналы;

● понимание того, как выполняется работа, включая:

○ единообразие;

○ прослеживаемость;

○ прозрачность.

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

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

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

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

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

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

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

Динамический кейс-менеджмент реализует систему хранения и систему доступа к контенту любого типа, как показано на следующем рисунке:

Динамический кейс-менеджмент – это надстройка над системой хранения, отвечающая на вопросы что (данные, файлы, записи или ссылки на них) и как (метаданные, аудиторский след, контекст решений и действий).

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

Process mining – это технология автоматического выявления процессов по журналам событий информационных систем, которую реализуют системы iBPMS. Применение process mining мы рассмотрели в разделе 5.6.10, в данном разделе более подробно рассматриваются технологические аспекты.

Созданная в 2009 году рабочая группа IEEE в конце 2011-го опубликовала манифест, предложивший автоматическое выявление процессов в качестве нового инструмента перепроектирования, контроля и поддержки бизнес-процессов. Тогда же, в 2011 году, опубликовал первую книгу на эту тему профессор Виль ван дер Алст, один из отцов автоматического выявления процессов. (Книга Process Mining: Data Science in Action, второе издание которой вышло в 2016 году, входит в список рекомендуемой литературы.)

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

Программное обеспечение для автоматического выявления процессов предлагают свыше 20 вендоров, в основном из США (Hyland, Kofax, Worksoft и TimelinePi) и Германии (Celonis, Lana, PAFnow, Scheer, Signavio, Software AG).

Gartner Group периодически публикует рейтинги поставщиков программного обеспечения BPMS. Ниже приведен рейтинг от IV квартала 2018 года – так называемый магический квадрант (Gartner Magic Quadrant).

В следующей таблице представлен альтернативный рейтинг Gartner Peer Review, составляемый по отзывам заказчиков. (С текущим рейтингом можно ознакомиться по адресу: .)

Большинство перечисленных поставщиков предлагают системы iBPMS, следующие трендам применения искусственного интеллекта и минимального программирования (low-code, no-code). Отрасли, идеально подходящие для low-code BPMS:

● образование;

● финансы и страхование;

● госсектор;

● здравоохранение;

● производство;

● технологии и телекоммуникации.