Эволюция BPM

Эволюция BPM

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

История возникновения BPM

Термин BPM — Business Process Management, стал регулярно использоваться в повседневной работе менеджеров относительно недавно, примерно с начала 2000-х годов. Он обозначает концепцию управления предприятием, в рамках которой вся его деятельность рассматривается как набор (совокупность) бизнес-процессов, имеющих определенные характеристики, на которые менеджмент может тем или иным образом влиять. Как следствие — влиять на сами бизнес-процессы. Существует технологический инструментарий для практической реализации концепции BPM — системы (решения) категории BPMS (Business Process Management System).

Несмотря на новизну BPM и BPMS, сама по себе идея рассматривать работу предприятия как совокупность бизнес-процессов существует достаточно давно. Правомерно говорить, что первые системные наработки в данной области появились в начале 20 века. Один из общепризнанных примеров таких наработок — труды американского инженера Фредерика Тэйлора, основоположника научной организации труда и управления (и автора концепции «тейлоризма»).

В 80-х годах японская корпорация Motorola разработала концепцию «Шесть сигм» — которая в 90-х годах была подхвачена американцами из General Electric. Это уже практически состоявшаяся BPM-концепция, предусматривающая оптимизацию каждого бизнес-процесса, которая достигается, в частности, посредством сведения к минимуму ошибок в операционной деятельности. В том числе — с задействованием инструментария управления качеством, а также обязательным учетом KPI, отражающих эффективность управления бизнес-процессами. Концепция «Шесть сигм» успешно используется многими современными предприятиями до сих пор, поскольку неоднократно доказала свою состоятельность — достигнутую в том числе за счет качественной проработки теоретической базы.

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

В 90-х годах, невзирая на влияние мощной волны компьютеризации западных экономик, перспективность BPM-концепций поначалу не была очевидна для IT-гигантов. Ведущую роль в продвижении и развитии новых программных решений играли небольшие разработчики, сумевшие, вместе с тем, вырасти в узнаваемые в своем сегменте бренды — Vitria, Intalio, Collaxa.

В среде разработчиков BPMS появился ряд фундаментальных, систематизирующих технологических принципов обеспечения функционирования приложений. В их числе — внедрение универсального языка XML, который дал возможность реализовать прочтение разнотипных данных в рамках единого потока, и, как следствие, производить эффективную обработку таких данных. Впоследствии на базе XML-скриптов возник специализированный язык моделирования BPEL (Business Process Exchange Language), ставший де-факто основным в сегменте.

К началу 2000-х годов сформировались более или менее четкие требования к BPMS. На арене появились, наконец, крупные игроки — масштабов Oracle, купившей в конечном итоге успешную Collaxa и начавшей серьезно инвестировать в растущий сегмент.  В образованную в 2004-м году BPM Standards Group вошли бренды IBM, SAP. В результате их совместной работы появились основополагающие описания концепции BPM. Разработчики установили, что BPM — это, прежде всего, совокупность разных технологий, не способных составить BPM по отдельности.

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

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

Компании, ставшие «пионерами» внедрения BPMS, устанавливали, что на практическое задействование моделирования на первых двух уровнях уходит не более 80% ресурсов предприятия. Однако, со временем программный уровень стал более ресурсоемким в силу необходимости достаточно частого внесения корректировок и доработок в ключевые программные модули рассматриваемых систем. Главный фактор возникновения такой необходимости — практическое применение средств BPM в рамках широчайшего круга задач, которые решаются такими средствами.

Какие задачи решает BPM?

Речь идет, прежде всего, о таких ключевых базовых задачах как:

  • Формализация бизнес-процессов.
    Для каждого бизнес-процесса подбирается формальное описание, соответствующее тем процедурам, которые составляют бизнес-процесс, некий понятийный аппарат для таких процедур, благодаря которому можно задавать правила управления каждой из них (и, соответственно, самим бизнес-процессом).
  • Исполнение бизнес-процессов.
    Предполагается формирование среды, в которой можно, согласно процессу, произвести те или иные значимые действия (заполнить информацию, произвести расчет, передать данные).
  • Управление бизнес-процессами.
    На основании понятийного аппарата, разработанного на этапе формализации, разрабатывается «нормативная база» — совокупность правил и алгоритмов, на основании которых осуществляется управление процедурами, составляющими бизнес-процесс.
  • Сбор статистики.
    В рамках решения соответствующей задачи собирается «правоприменительная практика» по отмеченной «нормативной базе», причем, выраженная, как правило в крайне репрезентативных и точных цифрах, дающих менеджеру (или другому пользователю на соответствующем уровне моделирования) возможность понять, за счет чего можно улучшить «нормативную базу».
  • Управление изменениями.
    В свою очередь, возникает задача по отслеживанию эффективности соответствующих улучшений. Для ее решения может задействоваться широкий круг инструментов — как статистических, так и аналитических, опять же, учитывающих специфику каждой процедуры в рамках бизнес-процесса.

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

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

Какие задачи стоят перед заказчиками BPMS?

К числу основных направлений, о которых идет речь, можно отнести:

  • организацию производственных процессов;
  • организацию рабочих мест;
  • обеспечение хранения и обработки данных;
  • обеспечение взаимодействия внутренней информационной системы предприятия с внешними;
  • сбор статистики, формирование отчетности.

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

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

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

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

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

Современные BPMS: текущие и перспективные возможности

Главный тренд в развитии современных BPM систем заключается в том, что они постепенно превращаются в полноценные информационные системы. Это значит, что инструментарий для решения описанных выше типовых задач на таких системах дополняется механизмами, обеспечивающими, в частности:

  • интеграции корпоративной BPMS с различными внешними модулями (и внешними информационными системами);
  • подключение пользовательских интерфейсов;
  • настройку различных моделей данных.

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

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

Соответствующими инструментами могут выступать, таким образом, специальные конструкторы приложений: технологичные No-Code платформы. Такие конструкторы позволяют осуществлять настройку необходимых механизмов (как для классических задач построения бизнес-процессов, так и для создания пользовательских интерфейсов, настройки интеграций и т.д.) без привлечения программистов. Данные решения работают вне сред выполнения BPMS-модулей и не предусматривают корректировки их программного кода. Как правило, для практической реализации концепции No-Code вполне достаточно компетенций уровня Citizen Developer, которые может приобрести любой работник предприятия с техническим или финансовым образованием.

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

  • удобство задействования пользовательского инструментария (когда нет необходимости часто задействовать консалтинг, тратить время на освоение сложных руководств);
  • сниженные требования к компетенциям в команде внедрения (когда при необходимости нужным навыкам работы с расширением модулей можно обучить любого сотрудника уровня Citizen Developer, и притом за короткий срок);
  • наличие минимума зон ответственности при внедрении расширенных модулей (что является прямым следствием сведения к минимуму вероятности критичных для деятельности предприятия ошибок при таком внедрении);
  • наличие минимума точек интеграции внутрикорпоративных и внешних модулей (в свою очередь, это фактор сведения к минимуму ошибок);
  • упрощенная техническая поддержка используемых приложений (нет необходимости регулярно привлекать IT-специалистов с высокой квалификацией).

Отдельно стоит сказать об отдельном преимуществе инновационных инструментов для настройки BPMS, функционирующих на базе No-Code (как и тех, что работают на базе близкой концепции Low-Code) — в оперативности настройки бизнес-процессов под установленные требования. Классическая схема предполагает более глубокую настройку, но она, как правило, происходит значительно медленнее, чем та, что характерна для задействования модулей No-Code. Отсюда возможности ускоренного реагирования предприятия на те же изменения условий в бизнесе.

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

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

Такое масштабирование может быть реализовано, как вариант, за счет применения различных средств машинного обучения — Machine Learning. Эффективность внедрения подобных технологий в обозримом будущем, несомненно, станет одним из ключевых критерием конкурентоспособности разработок в сегменте BPM.

Безусловный критерий пользования такими разработками в новых условиях и в рамках отмеченных инновационных механизмов — сохранение того уровня функционала, который характеризует классическую схему. Менеджерам следует отдавать себе отчет в том, что технологически такая схема в чистом виде в той мере совершенна, в какой степени качественно квалифицированный Citizen Developer выполнит свою работу в части доработки или настройки модулей BPMS. При наличии достаточного времени он это сделает на No-Code конструкторе, скорее всего, не хуже программиста классической разработки. Вместе с тем, по экономическим критериям новый подход значительной лучше классического благодаря новациям, базирующимся в том числе на использовании технологичных и, как показывает практика внедрения продуктов FIS Platform, эффективных решений по управлению бизнес-процессами. Кроме того, наша практика позволяет наблюдать уникальное свойство конструкторов: они способы объединять в себе не только преимущества No-Code концепции, но и классического подхода.

Российский рынок IT-решений, приспособленных для создания и управления BPMS как полноценными информационными системами, находится на ранней стадии формирования. Сейчас данный сегмент представлен решениями с кардинально разными подходами как к управлению процессами, так и к внедрению различных платформенных опций и технологических концепций — в том числе реализации принципов No-Code и Low-Code. Между отдельными решениями прослеживается существенная разница в стадиях развития: есть те, в которых внедрение той или иной концепции носит явно экспериментальный характер, а есть стабильные решения, готовые к немедленному внедрению — в том числе и за счет задействования новых и эффективных технологических концепций, в отрасль или даже группу отраслей.

Как показывает успешная практика внедрения продуктов FIS Platform — среды разработки BPM систем на базе концепции No Code, предприятия в высокой степени заинтересованы в приобретении таких решений в силу обоснованного снижения издержек на обеспечение функционирования BPMS.