Шрифт:
Пример. В торговой компании среднего размера директор поставил задачу сотруднику за три месяца подробно описать шесть ее основных процессов. При этом конкретные требования к результату (формат описания, степень детализации процессов и т. д.) установлены не были. В итоге удалось описать лишь незначительную часть процессов, а сотрудник перешел работать в другую организацию. Очевидно, что цели описания процессов были поставлены руководителем некорректно.
Цели описания процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть:
• анализ и последующая оптимизация процессов;
• разработка регламентирующих документов;
• подготовка к автоматизации процессов;
• прочее.
В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества BPTrends и посетители соответствующего сайта (Северная Америка – 36 %, Европа – 32 % и т. д.). Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия «бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессному управлению.
BPTrends: «Моделирование процессов – актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, так и детализированными изображениями осуществленных шагов и принятых решений в ходе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация в ходе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин “моделирование процесса” использовался очень широко для возможности рассмотрения всех видов моделирования…»
В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 4.2.1. По сути, на ней показаны цели моделирования (описания) бизнес-процессов.
Рис. 4.2.1. Как вы используете моделирование бизнес-процессов?
На первом месте (81 %) стоит пункт «Вместе с реинжинирингом и совершенствованием процессов». Это означает, что около 81 % компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов.
На втором месте – пункт «Для передачи информации о процессе». Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п.
4.2.2. Нотация моделирования процессов
Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно будет использовать описания процессов для формирования регламентирующих документов. Департамент по работе с персоналом заинтересован в выгрузке из системы моделирования должностных инструкций. Важно понимать, что описание процесса в среде моделирования содержит гораздо больше информации, чем показано на его графической схеме (независимо от нотации). Но именно эта информация необходима при регламентации, формировании отчетов и т. д.
При выборе нотации полезно обратить внимание на следующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление – полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML [83] ) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или IT-отдела, а преимущества процессного подхода не будут реализованы в полной мере.
83
Unify Modeling Language – унифицированный язык моделирования.
Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN [84] 2.0.
Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне:
• в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
• быстрота и низкая трудоемкость создания графических схем для целей регламентации;
84
Business Process Modeling Notation – нотация и модель бизнес-процессов.
• схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
• простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны – обучение можно проводить силами сотрудников отдела организационного развития);
• схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов организации.
4.2.3. Репозиторий и среда моделирования процессов
Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно – у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете ее, включаете в регламент, согласуете его с руководителями и т. п. Через два месяца нужно сделать еще один документ по той же процедуре. Кроме вас еще несколько руководителей и специалистов компании время от времени мастерят регламенты процессов. В результате в организации появляется множество схем, описанных в различных форматах и инструментах. Они хаотично хранятся в файлах на компьютерах разных пользователей. Как можно оценить такое положение дел? Неужели так работать удобно? Скорее всего, нет. Сложившуюся ситуацию можно охарактеризовать так: