Внедрить BPMS и не наступить на грабли

Текущие реалии

Внедрение BPM-систем не всегда проходит успешно. Это подтверждает и удручающая статистика реализации многих современных ИТ-проектов. На основании данных компании The Standish Group можно выявить некую закономерность: около половины проектов завершаются либо с превышением сроков или бюджетов, либо лишь частично достигают целевых показателей.

Согласно тем же данным 20% всех проектов попадают в категорию провальных – они останавливаются еще до получения результата. В корне изменить статистику невозможно, но сделать так, чтобы проекты чаще попадали в категорию успешных, вполне по силам. Для этого необходимо обратить внимание на ключевые аспекты при внедрении BPMS .

Поддержка руководства

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

• Достаточно распространены попытки внедрить BPM снизу или с функционального уровня. Но опыт показывает, что без решимости организации в целом преимущества BPM вряд ли могут раскрыться.

• Сильная поддержка руководства – вероятно, наиболее критичный фактор, поскольку лидер влияет на культуру всей организации.

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

BPM + BPMS

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

При внедрении BPM в компании появляются новые роли:

• владелец процесса;

• процессный аналитик;

• процессный архитектор;

• эксперты предметных областей.

На практике при формировании команды внедренцев BPMS никто не забывает про ИТ-специалистов – разработчиков и системных аналитиков, но другие роли зачастую игнорируются. Это в корне неверно.

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

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

Кроме того, процессный аналитик должен знать сценарный язык вашей BPM-системы . Это не способ сэкономить, пытаясь совместить в одном лице несовместимое: разработчика и аналитика, а необходимое условие успешной реализации проекта. Чтобы писать сценарии, к примеру на C# , не требуется быть разработчиком, ведь одним из элементов BPM системы является Low-Code , следовательно, обширных знаний в языке программирования не потребуется.

Соглашение о моделировании

Бесспорным лидером в ходе моделирования бизнес-процессов является нотация BPMN 2.0. Она достаточно строгая, многие процессные движки содержат функцию валидации, которая спасет от детских ошибок. Однако ряд вольностей нотация все же допускает. Следовательно, если не закрепите правила моделирования в собственном документе , есть риск получить плохо управляемые сложные схемы . Понять их можно будет, только играя в игру «Найди выход из лабиринта».

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

Если в компании не существует соглашения о моделировании, то необходимо его создать.

В соглашении обязательно должны присутствовать следующие элементы:

1. Описание новых ролей (владелец процесса, процессный аналитик и т. д.). 

2. Цели и полномочия процессного офиса или центра компетенций по бизнес-процессам. 

3. Правила описания бизнес-процессов в соответствии с назначением и применением (особенности использования нотаций в конкретной организации). 

Автоматизация «коровьих троп»

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

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

• изучить текущий процесс;

• пересмотреть его;

• исключить ошибки.

Другими словами, требуется построить схему TO BE и только после этого приступать к автоматизации.

Кроме того, схема TO BE часто оказывается значительно проще схемы текущего процесса. Это, в свою очередь, существенно упрощает автоматизацию и ускоряет сроки внедрения.

От простого к сложному

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

При автоматизации процессов в BPMS история выглядит совсем иначе. Жизнь процесса только начинается, когда вы его автоматизировали. Схема процесса не растворяется в коде, а по-прежнему остается доступна, и чтобы внести в нее изменения, не потребуется тратить время на анализ кода. 

На первом этапе автоматизации в BPMS ключевыми задачами являются:

• получение работающего процесса;

• скорейший его запуск;

• получение обратной связи;

• постепенное усложнение процесса. 

Такая логичная поэтапная последовательность минимизирует риск того, что проект не дойдет до полноценной работоспособности.

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

На практике, используя движение от простого к сложному, можно использовать фигуру на рисунке. Это два цикла Деминга. Этапы этих циклов совпадают, но цели у них разные.

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

• автоматизацию ручной работы;

• автоматическое или полуавтоматическое принятие решений;

• сбор и агрегацию данных;

• интеграцию с внешними и внутренними системами .

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

Чтобы продемонстрировать все плюсы и минусы рассмотрим радикальные варианты:

• Только стандартные объекты . На одном из проектов коллеги даже усилили этот подход. Кроме использования стандартных объектов, было решено не применять сценарии. Результат – существующего функционала не хватило, проект был признан неуспешным. От внедрения BPMS отказались.

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

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

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

2. Если нужного функционала нет в системе или его недостаточно, только тогда используется собственная разработка.

3. Весь новый функционал оформляется в виде стандартных объектов или процессов, обогащая и совершенствуя BPMS.

Для использования собственной разработки предварительно требуется доказать ее необходимость. Данный подход касается всех элементов BPMS: объектов, функций, экранных форм и других составляющих. 

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

• Поддержка руководства. 

• Комбинированное (совместное) использование BPM + BPMS.

• Соглашение о моделировании. 

• Автоматизация схемы TO BE, а не «коровьих троп». 

• Движение от простого к сложному. 

• Соблюдение баланса между стандартизацией и кастомизацией.