Читать онлайн «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0». Страница 40

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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