Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

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

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

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

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

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

Каждое правило должно быть протестировано по отдельности – и его описание, и реализация в машине бизнес-правил. Затем должны быть протестированы наборы. Юридический и финансовый отделы должны проконтролировать результаты тестирования на предмет соответствия требованиям закона и финансовой дисциплины. Также следует протестировать эффективность правил: неудачно закодированные правила могут замедлить информационную систему, а следовательно, бизнес.

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

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

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

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

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

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

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

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

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

Вот некоторые вопросы, которые встанут перед IТ.

• Какое программное обеспечение максимально соответствует требованиям процесса?

• Накладывает ли текущая инфраструктура ограничения на возможную модель бизнеса?

• Возможно ли быстро внедрить новую модель бизнеса?