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

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

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

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

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

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

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

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

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

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

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

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

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