Как нужно разрабатывать регламенты бизнес-процессов в 21 веке

Как нужно разрабатывать регламенты бизнес-процессов

Автор: Кручинецкий С.М., руководитель компании «Питер-Консалт», ksm@piter-consult.ru.

Как нужно разрабатывать регламенты бизнес-процессов В одной из статей раздела "Мифов управленческого консалтинга" я писал о том, как не нужно регламентировать бизнес-процессы в 21 веке. Давайте теперь разберемся, как нужно разрабатывать регламенты бизнес-процессов при их внедрении средствами ИТ.

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

Не будем долго останавливаться на разделе "Общие положения". Если вы не хотите путаницы, не забудьте при разработке регламента бизнес-процесса указать его название, статус (в работе, утверждён и т.д.), дату изменения статуса, ответственного и другие параметры, принятые в системе электронного документооборота.

А вот все остальные данные, которые нужно указать в регламенте бизнес-процесса при его разработке, зависят от нотации (набора правил), в которой выполнена графическая схема бизнес-процесса. Примеры бизнес-процессов, разработанных в разных нотациях, можно посмотреть по приведённой ссылке.

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

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

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

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

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

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