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

Отмечу, что при переносе информации из модели верхнего уровня в таблицу процессов организации не всегда возникает однозначное соответствие, поскольку:

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

• процессы могут быть перегруппированы (для получения более адекватного решения);

• некоторые процессы могут быть сгруппированы (то есть изменен уровень);

• некоторые процессы могут быть добавлены на основе стратегического ви2дения собственников;

• прочее.

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

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

3.6. Определение процессов подразделений

Для наполнения системы процессов организации на третьем-четвертом уровнях нужна информация о деятельности структурных подразделений. На рис. 3.6.1 показан алгоритм определения процессов структурного подразделения организации.

Рис. 3.6.1. Алгоритм определения процессов структурного подразделения

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

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

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

Рис. 3.6.2. Структурная схема процессов подразделения

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

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

Результат выполнения шага 3 – схема и перечень процессов подразделения. Общее количество выделенных процессов не должно превышать восемь – двенадцать. Рекомендуемое количество – шесть – восемь.

На шаге 4 для каждого выделенного процесса подразделения определяются входящие в него операции (подпроцессы[81]). Общее количество операций для каждого процесса не должно превышать 8–12.

На шаге 5 заполняется матрица процессов подразделения, которая включает:

• перечень процессов и операций (то есть два уровня процессного представления);

• информацию о границах процессов и операций (входы/выходы и события);

• информацию об ответственности за выполнение процессов и операций (в форме матрицы ответственности).

Возможная форма матрицы процессов подразделения показана в табл. 3.6.1.

На шаге 5 осуществляют анализ, уточнение (по входам/выходам) и согласование матрицы процессов подразделения. Акцент здесь делается на согласовании ви́дения процессов подразделения его руководителем и специалистами. Согласование входов/выходов процессов на межфункциональном уровне может производиться позже, на стадии формирования, анализа и согласования системы процессов организации в целом.

Пример. Далее в таблице показан фрагмент матрицы процессов отдела по работе с клиентами телекоммуникационной компании (пример с цепочкой ценностей этой же компании предлагался выше).

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

Таблица 3.6.1. Процессы отдела по работе с клиентами (фрагмент)

3.7. Согласование границ процессов

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

Согласование границ удается адекватно выполнить на том уровне процессов, где возникают реальные потоки ресурсов (документов, продуктов). Для документов можно определить шаблоны, по которым они должны заполняться, сроки передачи из отдела в отдел и т. п.

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

Как я уже говорил, на этапе первичного анализа и выделения процессов создаются матрицы процессов подразделений, которые потом используются при создании общей системы процессов, но:

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

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