Вечный реинжиниринг

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

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

Большинство статей описания причин неудач BPM-проектов начинаются с тезисов «они недостаточно качественно описывали процессы», «не было структурированного описания требований» и т.д. Все это очевидно. Отметим другое: существенное отличие западных внедрений от российских заключается в наличии «видения» там и его отсутствия здесь. В чем заключается это видение, и почему его нет?

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

Так же как прежде чем садиться за руль автомобиля, нужно сначала выучить теорию, для внедрения BPM нужно понять, как он работает?

Как устроен ВРМ

ВРМ-система, если рассматривать ее с точки зрения архитектуры IT, является надстройкой над виртуальной машиной Java (JVM). Техническое предназначение этой надстройки: определить структуру типов данных и логику работы с этими типами данных.

Но если все так просто, естественным образом появляется вопрос, можно ли обойтись стандартным средством, в котором ведется Java-разработка, не покупая дорогостоящие ВРМ-системы? Например, многие используют платформу Eclipse для этих целей. Да, конечно, можно. Почти все возможно реализовать в Eclipse, используя различные бесплатные дополнения. Результатом разработки на ВРМ будут те же содержащие код файлы, что и в Eclipse, которые затем направляются в компилятор (место, где они превращаются в Java-код), предназначенный для подготовки и передачи кода в JVM.

В чем же тогда ценность ВРМ-системы? Существенное отличие в том, на какого пользователя ориентирована система: BPM ориентирован на бизнес-аналитика, а платформа Eclpise — на подготовленного технического пользователя. То есть после внедрения управление инструментом ВРМ должно быть передано из IT-департамента в бизнес, чтобы использовать платформу по целевому назначению. Для этого подавляющее большинство ВРМ-платформ было спроектировано в соответствии с нотацией BPMN 2.0, в соответствии с которой проекты по бизнес-анализу и оптимизации бизнес-процессов выполняют большинство крупных консалтинговых компаний.

BPMN 2.0 (Business Process Model and Notation) содержит в себе типовое обозначение типовых элементов, из которых состоит любой бизнес-процесс. Это некий «набор цветных карандашей», который позволяет «нарисовать» абсолютно любой сложности процесс на структурированном уровне бизнес-анализа. Простой пример такого отображения — моделирование бизнес-процесса в формате Swimlane (бассейн), когда рисуются горизонтальные плавательные дорожки с зонами ответственности и процесс, который является последовательностью из комбинаций действий, условий и событий. В этом формате легко представить, как продавец формирует предложение покупателю.

Ориентированность на бизнес закладывает фундаментальные отличия в форме проектирования и разработки:

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

а) каждый процесс состоит из комбинации этапов и переходов между ними. Основные типы этапов процесса:

- Human Task (этап, требующий участия пользователя, иными словами, требуется какой-то ввод данных от пользователя),

- Service Task (этап, когда вызывается выполнение предопределенного сервиса или процедуры),

- Script Task (этап, включающий в себя выполнение конкретного программного описанного в теле этапа);

б) для перехода с этапа на этап используются условия перехода или gateway;

в) на каждом уровне этап, процесс или gateway используют набор переменных, которые определяет бизнес-пользователь.

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

Резюмируя устройство ВРМ, можно сказать, что любое программирование в ВРМ является, по сути, процессом моделирования в соответствии с нотацией BPMN 2.0. Именно для этого компании, внедряющей ВРМ, и нужно поднимать культуру бизнес-анализа.

Чтобы ВРМ работал качественно и позволял быстро запускать новые процессы и изменения на уровне простой логики без реинжиниринга и переработки реализованной части, нужно чтобы:

Все переменные ВРМ были привязаны к понятным бизнес-сущностям.
Количество Script Task в процессе было минимальным по отношению к другим этапам, то есть в нем не должно быть никакого запускаемого кода.

Основные ошибки при внедрении ВРМ

Конечно, подрядчики и многие айтишники будут убеждать в том, что можно сделать все что угодно на ВРМ, просто программируя. Да, можно. Но, как было отмечено выше, ВРМ для этого не нужен. Фактически краеугольным камнем начала работы в нем является определение модели данных. Этот термин довольно тяжело входит в жизнь банков и для многих бизнес-аналитиков является чуждым. Причина в том, что, к сожалению, в вузах сейчас учат программировать, но не учат правильно моделировать, используя CASE-средства. Наша система подготовки IT-специалистов и специалистов по бизнес-анализу отстала на несколько десятилетий. Единственная возможность изучить хотя бы основы — идти работать в международные консалтинговые компании на начальные позиции.

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

Внутри «Открытия», прежде чем внедрять ВРМ, мы определили цели:

Нужен инструмент, который позволит легко дирижировать процессами внутри CRM-платформы, связанными с привлечением и обслуживанием клиентов.
Нужен инструмент, который позволит сократить время на автоматизацию процессов за счет адаптивной архитектуры и «повторного использования» однотипных этапов процессов, сервисов и процедур. Один из революционных лозунгов, который декларировался в IT: «Нет системному программированию! Мы переходим в CASE-программирование». Это существенно меняет формат реализации IT-задач, переходя от формата спортивного программирования в формат управляемого конвейера. Для бизнеса выгода в том, что существенно сокращается время выхода на рынок, вывода нового процесса. Например, захотели изменить или создать новый процесс по продаже карт — пожалуйста, и программирования по минимуму.
Необходимо вовлечение бизнеса в управление и автоматизацию процессов, то есть фактически передача в бизнес этапа проектирования бизнес-процессов с помощью ВРМ.

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

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

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

Платформа ВРМ слишком «гибкая», в ней можно сделать абсолютно все. Поэтому в банке должен быть лидер на уровне бизнес-архитектора и IT, способный контролировать качество моделирования процесса. Преимущества ВРМ могут похоронить жажда и желание запрограммировать и быстрее достичь результата.
Моделирование процесса требует составления и проектирования модели данных (Enterprise Data Model, EDM), в которой будут описаны все бизнес-сущности, которыми оперирует организация. Все переменные должны быть связаны с этой моделью. Перескочив этот этап, организация гарантированно попадет в ситуацию, когда у нее будет несколько тысяч непонятных переменных в процессах, которыми как-то придется управлять.
Настройки процессов вариативны и должны раскрывать выгодно весь потенциал ВРМ. Процесс не должен быть слишком тяжел для визуального понимания. Если, посмотрев на экран, вы не понимаете смысл, то результат моделирования можно считать неуспешным. С другой стороны, процесс не должен быть слишком простым — например, последовательным исполнением. В этом случае ВРМ точно не нужен, и он будет являться излишними затратами для организации.
В ВРМ есть огромный соблазн использовать напрямую программный код на этапах процесса (с помощью Script Taks). Это ловушка для IT-специалистов, многие из которых по старинке любят программировать. Данная возможность была оставлена производителем как ручной тормоз на случай экстренных сложных ситуаций, когда по-другому никак не получается. К сожалению, довольно часто она используется далеко не по назначению. В этом случае роль и преимущества ВРМ теряются, и он превращается в обычный планировщик запуска программного кода (то есть большой компилятор).
Каждый из элементов ВРМ должен использоваться строго по назначению. Например, условия перехода между этапами процесса должны быть описаны в элементах ВРМ Gateway, а не где-то еще. К сожалению, многие интеграторы тут грешат и фактически программируют движение по процессу на уровне программного кода, изменить который становится довольно тяжело. Не должно быть никаких таблиц переходов, справочников условий, которые можно создать, ведь платформа позволяет.

Где деньги?

Как это все связано с выгодой, прибылью и прямыми затратами или чем полезен «Принцип подобия»? Влияние самое прямолинейное. Чем больше процессов упорядочено и разложено в соответствии с моделью данных BPM, тем больше новых уникальных элементов в нее было включено. Это довольно интересный подход, его можно сравнить с ростом Римской империи, которая, захватывая территории, упорядочивала жизнь на них и собирала из них лучшее.

Как это все выглядит на этапе моделирования процесса. Допустим, у банка есть процесс рассмотрения банковской кредитной карты, описанный в ВРМ, который состоит из этапов: «Заведение заявки», «Верификация клиента», «Принятие решения», «Выгрузка заявки в бек». На этот процесс банк потратил Х средств, он был успешно внедрен и также успешно работает.

Теперь банк хочет автоматизировать процесс рассмотрения кредитной заявки. Здесь, есть два варианта:

Вариант 1 — построить процесс с нуля с этапами: «Заведение заявки», «Верификация клиента», «Принятие решения», «Выгрузка заявки в бек». Стоимость автоматизации этого процесса уже относительно известна и составляет Х средств. Иными словами, для автоматизации двух процессов организация потратит в сумме 2Х средств. Продолжая ряд, мы придем к выводу, что автоматизация N схожих процессов будет стоить N*Х средств.

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

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

В этом случае реализация каждого последующего подобного процесса будет стоить меньше реализации его предшественника. Это довольно интересная зависимость, и она напрямую связана с качеством проектирования и наличия видения. Именно они позволяют обеспечить постепенное снижение стоимости изменений (Total Cost of Change) для автоматизации подобных процессов.

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

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