Ошибки описания бизнес-процессов предприятия. Часть 2

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

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

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

1. Ошибки определения функциональных границ проекта

У заказчика часто возникает вопрос: как определить необходимый и достаточный список бизнес-процессов предприятия для описания? С одной стороны, есть опасение забыть важные бизнес-процессы. С другой стороны, количество бизнес-процессов в списке влияет на стоимость работы по описанию, поэтому заказывать лишнее не хочется.

Рекомендую заказчикам описаний бизнес-процессов для своих предприятий воспользоваться методом великого итальянского скульптора Микеланджело Буонарроти, который «брал камень и отсекал всё лишнее». В качестве исходного «камня» можно использовать, например, структуру классификации бизнес-процессов, разработанную Американским Центром производительности и качества, или референтную отраслевую модель предприятия. У каждого опытного разработчика бизнес-процессов есть своя «типовая» структура, есть она и у нас.

Если вам сложно самостоятельно «отсечь всё лишнее», посоветуйтесь с консультантом. Имея для обсуждения «исходный камень», вы снизите риски определения границ проекта до минимума.

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

2. Ошибки определения необходимой детализации

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

Какой критерий позволяет заключить, что дальнейшая детализация не требуется и описание бизнес-процесса закончено? Только подтверждение заказчиком понятности описания. Иногда окончательное решение о понятности описания принимается только после тренинга участников бизнес-процессов. Например, в приведённом выше примере, если оператор заполняет форму без затруднений, описание достаточное. Если же вопросы остаются, описание бизнес-процесса нужно детализировать.

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

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

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