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

Помимо планируемых сценариев использования ПО BPM, необходимо рассмотреть вопросы взаимодействия с внешними базами данных, а также такими источниками информации, как файлы Word и Excel, унаследованные приложения и корпоративные системы, в частности ERP.

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

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

Регулирование – это компромисс между контролем и гибкостью. Чем больше контроля сверху, тем меньше гибкости для пользователей, архитекторов и разработчиков приложений. Потребность в контроле при использовании BPMS возрастает, но при этом сильной стороной BPMS является скорость изменений, что подразумевает минимум контроля. Таким образом, две цели противоречат друг другу. Это извечная проблема, но сегодня дело приобретает новый поворот. С помощью BPMS мы теперь можем делать то, чего раньше не могли, и в результате вместо вопроса «Можем ли мы это сделать?» перед нами зачастую встает вопрос «Нужно ли нам это делать?».

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

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

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

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

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

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

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

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

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

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

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

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