10.5.1. Стандарты и методологии BPM

We use cookies. Read the Privacy and Cookie Policy

Сегодня многие компании реализовали с помощью BPMS точечные решения специфических проблем, не выработав при этом стандарты и не утвердив методологию. Еще больше осложняет дело наличие в одной компании или даже департаменте BPMS от нескольких поставщиков, вокруг каждой из которых складывается отдельная группа людей от бизнеса и IТ, каждая со своим уставом. В такой компании может возникнуть политическая «война» за то, чья BPMS станет стандартом компании. Каждая из сторон много вложила, и никто не хочет страдать из-за смены BPMS и, как следствие, перехода на новые приложения. Поэтому очень важно как можно быстрее сформировать централизованную группу, отвечающую за управление BPM. Такие группы часто называют центрами компетенции. Решение политических вопросов, связанных с развертыванием BPMS, является непростой задачей, как правило, требующей участия высшего руководства. И даже при этом условии перейти к единой BPMS организации, уже использующей в своей деятельности несколько систем, бывает непросто. При поспешном переходе убытки могут оказаться слишком велики – в таком случае оправданной будет стратегия опоры на нескольких поставщиков.

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

Пока преждевременно говорить о наличии каких-то общепризнанных на уровне отраслей или компаний стандартов в области использовании BPMS. BPM и технологии BPMS все еще молоды, и задачей ABPMP и других подобных объединений является выработка таких стандартов. А пока надо двигаться вперед и разрабатывать для своей компании стандарты использования ПО, методы моделирования и т. п. Это важно с точки зрения взаимопонимания между группами внутри компании. Эти стандарты должны включать:

• способ сбора и состав информации, которая будет применяться для настройки системы;

• набор символов, используемых для моделирования (обычно это стандартный BPMN);

• репозиторий;

• ограничения доступа и применимые нормативно-правовые требования;

• архитектуру: модели из разных проектов должны соответствовать друг другу, вместе составляя единую модель предприятия;

• стандартные условия, уровни сервиса и т. п.;

• регулирование.