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

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

Чтобы этого добиться, сбор информации необходимо стандартизовать – определить, какую информацию от кого следует требовать, как ее проверять, организовывать и хранить, порядок ее использования и обновления.

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

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

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

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

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

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

Кроме того, многие проекты страдают от терминологической путаницы. Использование относящихся к BPM и процессной трансформации терминов и акронимов различается от компании к компании, от проекта к проекту и от одной проектной команды к другой. Частично это объясняется тем, что многие термины не имеют общепризнанных определений. Это, конечно, плохо, но гораздо хуже расхождение в терминах и определениях между разными подразделениями одной организации. Как показывает опыт, во избежание расхождений между подразделениями и между бизнесом и IТ необходимо давать определения даже вещам из разряда «это всем известно». Чтобы все друг друга понимали, определения должны быть согласованы с бизнес-руководителями, с IТ и бизнес-партнерами. Но тут возникает культурно-политическая проблема: чье определение будет признано истинным и выбрано для всеобщего употребления? Реальность такова, что выработка общего словаря является непростой задачей.