24. Метод полного описания бизнес процессов и последовательность его выполнения. Метод полного описания бизнес-процессов

Этот метод рассчитан на организацию, поставившею свой целью реальному улучшение деятельности в разумные сроки. Данный метод помогает навести порядок в управлении, а затем переходить к внедрению элементов процессного управления. Полным он называется потому, что основан на детальном анализе информационных и материальных потоков организации и четком определении пересечений с этими потоками границ подразделений. Типичный срок анализа и улучшения ситуации с процессами для данного метода – 1 – 1,5 года.

Руководство компании не ставит жестких сроков выполнения проекта и не ожидает «революционных» изменений эффективности.

Основной целью работ в данном случае является построение системы управления процессом или системы менеджмента, ориентированной на процессы. Напомним, что выполнение непосредственно процедур начинается уже после определения целей проекта.

Шаг 1.Определить внешних клиентов организации входы и выходы для организации в целом.

Механизм здесь такой же как и в предыдущем методе. Небольшой нюанс. При определении выходов нежно указывать агрегированные результаты. Не «накладная на отгрузку», а «документы на отгрузку», не «Готовые изделие», а «готовые изделия».

Шаг 2. Привязать полученные входы/выходы к подразделениям организации.

Этот шаг 2 существенно отличается от предыдущего метода, а именно выделяются не основные процессы, а структурные подразделения организации. Для этого так же используются положения об организации, и др . документы. Далее внешние входы связываются с подразделениями. У же на этом этапе может возникнуть ситуация, когда одни и те же входы/выходы связаны с несколькими подразделениями. Здесь нужно анализировать конкретную ситуацию: либо это необходимо для протекания процесса, либо имеет место дублирование функций, которое необходимо на стадии оптимизации процессов ликвидировать.

Шаг 3. Определить внутренние входы/выходы и недостающие вспомогательные процессы.

Здесь важно выявит все типы входов -/выходов, нельзя допускать излишней детализации.

Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.

На этом этапе рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений. Для каждого подразделения формируют перечень выполняемых в нем функций. Именно на этом этапе начинает сказываться элемент субъективности, так как в формализованных источниках информации мы сможем определить только 30-40% выполняемых функций.

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

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

Здесь же нужно придумать название процессу:

- на основании содержания выполняемых работ и полученных результатов;

- на основании классификации процессов;

- на основании наименования процессов схемы жизненного цикла продукта.

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

Результатом работы на этом этапе является четкое понимание деятельности подразделений путем ее структуризации по бизнес – процессам. Субъективности выделения бизнес – процессов уровня подразделений является здесь минимальной.

Шаг 6. Используя входы/выходы между подразделениями сгруппировать бизнес – процессы подразделений в бизнес процессы организации.

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

Шаг 7. Сформировать матрицы ответственности по каждому подразделению. На их основе составить матрицы ответственности бизнес – процессов организации.

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

К недостаткам данного метода можно отнести:

1. Высокую трудоемкость для средних и крупных организаций

2. Значительный отрезок времени

3. Сложность компоновки бизнес – процессов организации и бизнес –процессов подразделений

Сравнительный анализ подходов

№	Критерий сравнения	Метод I	Метод II
1	Степень субъективности	Высокая	Незначительная
2	Полнота описания деятельности	Фрагментарное описание	Полное описание
3	Длительность выполнения проекта	2-3 месяца	6-12 месяцев
4	Корректность полученных моделей процессов	40-80 % соответствия реальным процессам	80-90 % соответствия реальным процессам
5	Степень участия руководства и сотрудников организации в проекте	Незначительная	Высокая
6	Трудоемкость выполнения	Средняя	Высокая
7	Степень риска неудачи проекта (при наличии поддержки руководства)	30-70 %	0%
8	Степень риска неудачи проекта (при отсутствии поддержки руководства)	80-100%	20-30 %
9	Возможность использования результатов проекта	20-40%	80-90%