Все BPM-системы одинаково неуниверсальны
Наследница класса workflow, BPM-система всегда ориентировалась на поток работ, а не информацию, рождающуюся в ходе процесса. Из-за того, что термином «процесс» при желании можно обозначить все что угодно, возникают идеи об универсальности BPM.
Содержание |
 | Константин Истомин Исполнительный директор компании Directum |
Почему одного BPM мало
Контент и документы имеют значение
На разных этапах любого процесса могут появляться различные артефакты (документы, записи), что уже выходит за границы «классической» BPM-автоматизации. Процессы и контент, информация, которая рождается при исполнении процедур, — часто неотделимы друг от друга. Бизнес-данные, полученные в ходе работы, могут быть необходимы, чтобы считать результат процесса достигнутым. То есть процессы возникают в контексте данных.
Даже если понимать контент узко как документы, все равно оказывается, что управление ими сегодня выходит за рамки создания и маршрутизации внутри компании. Легитимность и юридическая значимость электронных документов дали новый виток развития корпоративных систем — в них появились инструменты проставления и усовершенствования электронных подписей, поддержки актуальных форматов и типов юридически значимых документов, интеграции с сервисами межкорпоративного ЭДО.
Работа с электронным подписанием — отдельное большое направление, без которого сегодня невозможны бизнес-процессы любой крупной организации.
Ограниченная гибкость
BPM строится вокруг процесса и тех этапов, которые необходимо пройти, чтобы достигнуть цели. Все шаги должны быть заранее определены, зафиксированы в процедуре и всегда четко исполняться — для BPM нежелательны какие-либо отклонения от строго размеченной схемы.
В реальности нетиповые процессы могут зависеть от такого количества переменных, что будут уникальными в каждом новом случае. Здесь речь, скорее, пойдет уже о динамическом управлении — кейс-менеджменте, для которого отклонения не просто допустимы, а неизбежны и являются частью подхода. Конечная цель процесса тут важнее, нежели пути ее достижения, и исполнители, занимающиеся кейсом, сами задают последовательность шагов в зависимости от обстоятельств.
Low-code BPM-платформа — панацея?
Если классической BPMS не хватает гибкости, то инструменты low-code решают эту проблему на уровне платформы и открывают возможности для построения решений, учитывающих потребности конкретной компании. Только такие проекты всегда требуют сложной разработки и внедрения, больших временных и ресурсных затрат.
Нужна ли организациям «платформа»? Если мы говорим о задачах бизнеса, то компании скорее требуется готовое решение, быстро и недорого.
В разных процессах задачи могут быть специфическими, вполне конкретными и со своими нюансами, артефактами и требованиями. Пример: требуется настроить планирование отпусков для компании со штатом 5 тыс. сотрудников, согласование графика и массовое ознакомление с приказами, плюс возможность переноса отпуска. Для делопроизводства — регламенты с листами согласования, нумерацией, регистрацией в дело, отправкой и контролем поручений и т.д. И аналогично для других сфер — управление проектами, Service Desk, закупки и другие.
Если платформа не может предложить решение этих задач в разумный срок, будет ли она интересна клиенту? Мало кто готов сегодня тратить время на создание бизнес-приложений с нуля. Поэтому на базе платформы создается прикладной слой приложений от вендора под конкретный класс задач. Для того чтобы компания могла гибко адаптировать систему под меняющиеся требования, поверх этого «этажа» располагается кастомизированный слой заказчика.
Слои no-code, low-code и кастомизация
В реальности в крупных компаниях система всегда обрастает доработками. Если требования заказчика очень серьезные, то «простая настройка» в low-code-платформе может превратиться в путаницу с монструозным нагромождением неочевидных комбинаций, выражений и кусков кода, которые вставлены в разных местах. Изнутри код может получиться настолько путаным, что в нем будет множество белых пятен для аналитика, «неконтролируемых» вставок на JavaScript, Type Script и т.д.
Не стоит забывать и о ресурсоемкости no/low-code-разработки. Динамические вычисления, на которых базируется технология, снижают производительность и быстродействие системы. Заметен этот эффект станет при масштабировании системы на новых пользователей и при росте объемов данных.
В контексте low-code и «гражданского программирования», когда порог доступности изменений в системе снижается, нужно позаботиться о том, чтобы систему случайно не «сломали». Ведь настройка ИС становится доступной бизнес-пользователям, людям без специальной ИТ-подготовки. И чем больше появляется возможностей гибкой адаптации, тем выше риск ошибочных действий и вывода системы из строя. Ошибки в настройке и разработке могут отражаться на работе большого числа пользователей и иметь серьезные последствия для компании.
Чтобы снизить отрицательное воздействие no/low-code на продукты Directum, мы вынесли инструменты в отдельные слои разработки. Так не страдает производительность, и дополнительно разграничиваются зоны компетенций бизнес-пользователей (аналитиков) и разработчиков.
Одновременно нужно понимать, что любые задачи без кода или с помощью low-code не решить. В системе должны быть инструменты для глубокой кастомизации: иногда приходится углубляться в программирование, настраивать интеграцию или оптимизировать код под конкретные операции. Удобные инструменты нужны и для разработчика, и на уровне аналитика/пользователя.
Прикладной логики на уровне заказчика может быть много, особенно если говорить о крупных компаниях, поэтому настройка должна легко «считываться», быть прозрачной. В системе Directum RX аналитик может разбить сложную задачу на простые куски, создавать варианты процессов, по критериям и приоритетам задать, по какой схеме пойдет процесс.
Готовые адаптивные решения
Существует расхожее мнение, что с помощью low-code реально цифровизировать все. Сделать, действительно, можно многое, вопрос в ресурсах. И если мы говорим о разумных сроках, то шансы достичь желаемых результатов выше в случае, если в нашем распоряжении есть основа, которую можно гибко адаптировать.
Экосистема решений — ключевое преимущество Directum. Мы разрабатываем и совершенствуем их на единой low-code-платформе. Но клиенты получают не базовый инструмент, а готовые решения, которые можно доработать под индивидуальные требования. Такой подход экономит деньги и время наших заказчиков. Отдельно отмечу, что решения на базе Directum RX учитывают разнообразный консалтинговый бэкграунд, правильно спроектированы, поддерживаются и обновляются в прикладной части и платформе.
К готовым прикладным блокам относятся и средства интеграции, наборы коннекторов. Сегодня для бизнеса актуальны связки с операторами ЭДО, витринами данных для ФНС, Госключом. В ближайшем будущем могут стать обязательными интеграции с ГосЭДО и операторами копирования данных. В таких условиях отказ от готовой основы обозначает для компании-клиента постоянную доработку решений своими силами, и такие самописные системы будут постепенно деградировать. В программном обеспечении с регулярным обновлением поддерживается актуальность, это позволяет компаниям не останавливаться в постоянном развитии информационных систем.
***
Может ли BPM-система быть универсальным инструментом автоматизации процессов? Выше мы детально разобрали, почему классической BPM и даже Low-code BPM-платформой не закрыть всех потребностей современной компании.
При цифровизации бизнес-процессов оптимально исходить из задач организации и ее текущего состояния. Компании может быть мало готового решения, и даже инструменты no-code и low-code не учтут всех нюансов адаптации, потребуется глубокая кастомизация на уровне платформы. Или же компании нужно автоматизировать настолько специфический процесс, пусть и небольшой, что готового решения для него просто не окажется — тут не обойтись без разработки с нуля.
Ситуации могут быть разными, они могут требовать нетривиальных подходов и инструментария. Важно при принятии решения обращать внимание на конечную цель для бизнеса и соотношение затрат и эффекта.
