Бизнес-процессы. Моделирование, внедрение, управление - Владимир Репин

• границы процессов, представленные в матрицах, могут отражать субъективный взгляд руководителей (в том числе их желание изменить свои или чужие зоны ответственности за счет изменения определения состава процессов и входов/выходов);

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

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

• фиксируют существующие формы документов, при помощи которых осуществляется взаимодействие;

• анализируют, согласованы ли соответствующие формы документов с поставщиками/потребителями, утверждены ли они документально;

• при необходимости корректируют формы документов (разрабатывают новые формы);

• проводят совещания с поставщиками/потребителями (внутренними и внешними) и согласуют соответствующие формы;

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

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

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

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

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

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

3.8. Список литературы

1. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012.

2. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. М.: Стандарты и качество, 2007.

3. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

4. Бьёрн А. Бизнес-процессы. Инструменты совершенствования. – М.: Стандарты и качество, 2003.

5. Де Гиус А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.: Стокгольмская школа экономики в Санкт-Петербурге, 2004.

Глава 4

Описание бизнес-процессов организации

4.1. Цели описания бизнес-процессов организации

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

Понятие «модель процесса» в книге имеет более широкий смысл, чем «схема процесса». Схема процесса – это графическое изображение процесса в определенном формате, а модель процесса – это его комплексное описание (в том числе и схема). Под термином «среда моделирования процессов» я понимаю специализированное программное обеспечение для описания процессов.

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

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

Таблица 4.1.1. Возможные ситуации с описанием процессов

Как правило, с увеличением численности сотрудников в организации используются более четкие, формальные методики описания процессов и соответствующие инструменты – средства моделирования. Бывают и исключения, когда в компании из 100 человек методики описания процессов четко сформулированы и используются, а в крупной, солидной организации они находятся в зачаточном состоянии и бессистемно применяются отдельными специалистами (например, в департаменте управления рисками).

Сформулируем цели описания процессов для организаций разного размера.

Небольшая организация (10–100 человек)

Возможные цели описания процессов (моделирования) в небольшой организации:

1. Четкое определение зон ответственности руководителей по ключевым направлениям деятельности.

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