Разумным сроком описания бизнес процессов организации является

Методология «полного» описания бизнес-процессов рассчитана на органи­зации, поставившие своей целью реальное улучшение деятельности в разумные сроки. Данная методология помогает, в первую очередь, навести порядок в уп­равлении, а затем переходить к внедрению элементов процессного управле-ния. «Полным» метод назван вследствие того, что он основан на детальном анализе информационных и материальных потоков организации и четком опре­делении пересечений с этими потоками границ подразделений. Типичный срок анализа и улучшения ситуации с процессами для данного метода — один-полто-ра года. Руководство компании не ставит жестких сроков выполнения проекта и не ожидает «революционных» изменений эффективности. Основной целью ра­бот в данном случае яааяется построение системы управления процессами орга­низации или системы менеджмента, ориентированной на процессы.

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

140__________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению

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

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

Шаг 1. Определить внешних клиентов организации (окружения) и входы/выхо­ды для организации в целом (рис. 3.14).

Рис. 3.14. Метод II Шаг 1. Определение окружения организации и внешних входов/выходов.

При выполнении первого шага рассматривается организация в целом и ее окружение так же, как и в методе I. Определяются внешние входы и выходы. Результатом работ является спецификация входов/выходов и окружения органи­зации. Важно отметить, что входы/выходы должны быть указаны в специфика­ции на верхнем уровне. Например, было бы неправильно включать в специфика­цию такие позиции, как «накладная», «готовое изделие» и т.п. Нужно включать агрегированные позиции: «документы на отгрузку», «готовые изделия» и т.п.

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

Глава 3 Описание и анализ бизнес-процессов 141

Шаг 2 существенно отличается от метода I, а именно: выделяются не основ­ные процессы, а структурные подразделения организации. Сделать это можно довольно легко, так как границы функциональных подразделений достаточно четко очерчены. Рабочая группа может использовать положение об организаци­онно-штатной структуре организации и другие необходимые документы.

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

Очевидно, что субъективность работ по привязке входов/выходов к подраз­делениям на этом этапе минимальная или вообще отсутствует.

Шаг 3. Определить внутренние входы/выходы для каждого подразделения орга­низации (рис 3.16).

Рис. 3.16. Метод II. Шаг 3. Определение внутренних входов/выходов для каждого подразделения.

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

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

На шаге 4 рассматривается деятельность каждого подразделения в отдельно­сти. Более четко определяются границы подразделений.

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

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

кции, реально выполняемые в подразделениях, как правило, отражены в суще­ствующих документах лишь на 30—40%. Дело в том, что положения о подразде­лениях, инструкции и другие документы редко пересматриваются и не являют­ся актуальными.

Такое положение обусловлено, в первую очередь, отношением руководства организации к регламентирующей документации и отсутствием системы работы с ней. На наш взгляд, такое положение дел является характер­ным для российских организаций. В других странах (Европа, Япония, США) в крупных компаниях система упрачьном виде.

Почему мы сделали такой вывод? Дело в том. что подавля­ющее число организаций развитых стран сертифицировано в соответствии с МС ИСО серии 9000, одним из требований которых является управление до­кументацией. В настоящее время в России многие руководители осознают важ­ность регламентации работы при помощи документации процессов и иниции­руют соответствующие проекты.

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

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

Глава 3 Описание и анализ бизнес-процессов_______________________________ 143

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

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

Рис. 3.18. Метод II. Шаг 5. Группирование функций подразделения по процессам.

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

Другая часть функций может войти во вспомогательные процессы. Некоторую часть функций, вероятно, будет затруднительно отнести к какому-либо процессу верхнего уровня. При внимательном рассмотрении такие функ­ции могут оказаться внутренними функциями подразделения. Среди них могут быть и такие, которые не нужны ни подразделению, ни организации в целом и подлежат устранению (рис. 3.19).

Чем руководствоваться при наименовании бизнес-процессов, по которым распределены функции подразделения? Возможны следующие варианты:

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

2) на основе классификации процессов (см. выше);

3) на основе наименования процессов схемы жизненного цикла продукции
(см. рис. 3.20).

При использовании первого подхода (ему соответствует рис. 3.19) названия бизнес-процессов подразделения определяют исходя из состава выполняемых

Рис. 3.19. Объединение процессов подразделений в процессы организации в целом.

работ и полученных результатов (пример: «процесс формирования плана от­грузки на квартал» или «процесс бюджетирования деятельности подразделения»), На практике многие полученные цепочки процессов подразделения могут при­надлежать одному более крупному процессу уровня организации в целом. Так, например, несколько бизнес-процессов уровня отдела сбыта будут являться со­ставляющими процесса «Сбыт» для организации в целом.

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

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

Нежелательно давать выделенным процессам подразделения произвольные названия, так как это будет препятствовать определению сквозных бизнес-про­цессов организации в целом на следующем этапе. Нельзя также рассматривать процессы подразделения «плоскими», т.е. состоящими только из работ, выпол­няемых исполнителями на местах, без руководителей. Следует помнить, что любая цепочка процесса нуждается в планировании, учете, анализе и управле­нии. Выделенные процессы подразделений должны быть «объемными» (т.е. от­ражать деятельность руководителей), а не просто отражать плоскую последова­тельность выполнения функций.

Результатом работы на шаге 5 является четкое понимание деятельности под­разделений путем ее структуризации по бизнес-процессам. Обратим внимание, что субъективность выделения бизнес-процессов уровня подразделения на ос­нове его выходов и выполняемых функций является минимальной.

Рис.3.20. Жизненный цикл продукции.

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

Рис. 3.21. Метод II. Шаг 6. Формирование бизнес-процессов организации из бюнес-процессояподразделений.

На шаге 6 интегрируют бизнес-процессы уровня подразделений в сквозные бизнес-процессы уровня организации в целом. Существующие между подразде­лениями информационные и материальные потоки являются при этом указате­лями связи между процессами подразделений.

Таким образом, все функции подразделений оказываются отнесенными к опре­деленным бизнес-процессам.

Еще раз подчеркнем, что бизнес-процессы организации, представленные на рис. 3.21 в виде «плоских» процессов, на самом деле являются «объемными». Попытка отобразить «объемность» процессов показана на рис. 3.22.

Рис. 3.22. «Объемные» бизнес-процессы.

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

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

Итак, метод II («полный») позволяет детально описать деятельность органи­зации, корректно выделяя бизнес-процессы на основе информационных и ма­териальных потоков и однозначно связывая функции подразделений с процес­сами. При использовании метода II не должно быть «потерянных» функций, т.е. функций, не вошедших ни в один бизнес-процесс. Таким образом, все функ­ции организации оказываются привязанными к конкретным бизнес-процессам. Бизнес-процессы формируются не субъективно, а на основе реальных потоков информации и материальных ресурсов между подразделениями.

Рис. 3.23. Метод II Шаг 7. Формирование мафии ответственности по бизнес-процессам.

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

• высокую трудоемкость применения метода для средних и крупных орга­
низаций;

• значительную длительность описания (8—12 месяцев);

• сложность компоновки бизнес-процессов организации из бизнес-процес­
сов подразделений.

Источник: stydopedia.ru

Выбор методологии описания бизнес-процессов организации

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

• ? большой объем (содержат много процессов, функций, документов — более 10 000 объектов);
• ? низкое качество (фрагментарность описания, «потерянные» функции и документы, отсутствие описания необходимых элементов процесса, комментариев к процессам, анализа проблем и т.п.). Такое состояние полученных моделей процессов можно попытаться объяснить несоответствием привлеченных для работы ресурсов (время, люди) и масштабом работ. Но простой расчет показывает, что для корректного детального описания процессов деятельности организации с численностью 3—5 тыс. человек потребуется два-три года работы пяти—восьми аналитиков. Тем не менее руководители организаций, инициирующие проекты, часто не оценивают сложность такой работы. В некоторых проектах были попытки задействовать одновременно более 15 аналитиков для описания процессов. К сожалению, такой подход не решает проблему. Дело в том, что полученный огромный комплект моделей процессов никто не может оперативно (за те же два- три месяца) проанализировать, выявить причины проблем, определить адекватные мероприятия по реорганизации.

Для чего же используют «ускоренный» метод? Опыт общения с руководителями служб крупных предприятий и холдингов показывает, что руководство этих организаций часто ставит задачу локального описания некоторых выделенных бизнес-процессов на первом этапе (первый—третий месяцы), следующих — на втором (четвертый— шестой месяцы) и т.д. При таком подходе появляется необходимость выделять часть процессов и заниматься их описанием. В этом случае

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

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

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

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

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

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

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

Очевидно, что субъективность работ по привязке входов (выходов) к подразделениям на этом этапе минимальная или вообще отсутствует.

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

Шаг 4. Определить перечень функций, выполняемых в каждом подразделении. Рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений. Для каждого подразделения формируют перечень выполняемых в нем функций. Именно на этом этапе начинает сказываться элемент субъективности.

Функции, реально выполняемые в подразделениях, как правило, отражены в существующих документах лишь на 30—40%. Дело в том, что положения о подразделениях, инструкции и другие документы редко пересматриваются и не являются актуальными. Это объясняется в первую очередь отношением руководства организации к регламентирующей документации и отсутствием системы работы с ней.

На наш взгляд, такое положение дел является характерным для российских организаций. В других странах (Европа, Япония, США) в крупных компаниях система управления документацией существует хотя бы в формальном виде. Почему мы сделали такой вывод? Дело в том, что подавляющее число организаций развитых стран сертифицировано в соответствии с МС ИСО—9000, одним из требований которых является управление документацией. В настоящее время в России многие руководители осознают важность регламентации работы при помощи документации процессов и инициируют соответствующие проекты.

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

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

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

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

Чем руководствоваться при наименовании бизнес-процессов, по которым распределены функции подразделения? Возможно несколько вариантов:

• 1) на основе состава выполняемых работ и полученных результатов;
• 2) на основе классификации процессов;
• 3) на основе наименования процессов схемы жизненного цикла

продукции (рис. 7.13).

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

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

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

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

Нежелательно давать выделенным процессам подразделения произвольные названия, так как это затруднит определение сквозных

Рис. 7.13. Жизненный цикл продукции

сл бизнес-процессов организации в целом на следующем этапе. Нельзя также рассматривать процессы подразделения «плоскими», т.е. состоящими только из работ, выполняемых исполнителями на местах, без руководителей. Следует помнить, что любая цепочка процесса нуждается в планировании, учете, анализе и управлении. Выделенные процессы подразделений должны быть «объемными» (т.е. отражать деятельность руководителей), а не просто отражать плоскую последовательность выполнения функций.

Результатом работы на шаге 5 является структуризация деятельности подразделений по бизнес-процессам. Обратим внимание, что субъективность выделения бизнес-процессов уровня подразделения на основе его выходов и выполняемых функций является минимальной.

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

Таким образом, все функции подразделений оказываются отнесенными к определенным бизнес-процессам.

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

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

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

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

• ? высокую трудоемкость применения метода для средних и крупных организаций;
• ? значительную длительность описания (8—12 месяцев);
• ? сложность компоновки бизнес-процессов организации из бизнес-

Источник: bstudy.net

Тотальное описание бизнес-процессов: за и против

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

Тотальное описание компании включает четыре основных шага:

• описание ВСЕХ процессов компании «как есть»;
• их анализ;
• описание ВСЕХ процессов компании «как должно быть»;
• внедрение изменений, трансформация организационной структуры и сокращение численности штата.

Если в компании трудится две тыс. чел., а количество процессов, которое необходимо описать, — около тысячи, то это означает, что нужно разработать тысячу схем формата А4 (8–15 шагов на каждую). Согласитесь, масштабная задача.
Можно ли обойтись без этого? Да, можно. Многие так и делают — просто дают руководителям отделов плановый процент сокращения штата. Но я этот случай не рассматриваю. Если компании нужно четкое обоснование оптимизации, то без анализа реально выполняемых процессов не обойтись.
Однако личный опыт участия в подобных проектах говорит об их недостаточной результативности. Проблема в том, что этап описания процессов «как есть» длится очень долго — от шести месяцев и более. На выходе команда получает толстые тома схем, с которыми сложно работать. Потом начинается анализ рабочих операций и обоснование изменений, и еще много месяцев рисуют модели «как должно быть». За это время процессы успевают поменяться.
Более правильным представляется подход, когда сначала создается процессная архитектура бизнеса, а затем выполняются описание, анализ и оптимизация операций, причем последовательно — от наиболее важных к менее существенным. По каждому процессу должен быть достигнут практический эффект от оптимизации.
Но как быть, если без тотального описания не обойтись?

Методический подход

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

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

Прежде чем решать вопрос создания компетенций у команды проекта, следует найти подходящих людей. Можно провести кастинг в консалтинговых компаниях, но вряд ли даже крупные организации способны выставить 20–30 специалистов на много месяцев проекта. Если даже смогут, то цена будет космическая. Выхода два: нанимать новых людей либо учить своих.
Увеличение численности штата на старте проекта, целью которого является её сокращение, не вдохновляет руководство. Поэтому остается вариант искать ресурсы внутри компании. Но здесь тоже проблема: либо в проект предлагают заведомо лишних, ненужных сотрудников, либо вообще отказываются отдавать из боязни прослыть неэффективным руководителем, у которого люди не загружены работой. Как быть в такой ситуации?
Возможны разные подходы. Собственник бизнеса может назначить сотрудников в проект волевым решением. В госкомпании можно сформировать команду из руководителей отделов, включенных в кадровый резерв. Практика описания и анализа процессов будет им исключительно полезна, к тому же они смогут найти у себя в отделах толковых исполнителей — будущих «писателей процессов». Еще один, но не лучший вариант — привлечение практикантов, студентов, закрепленных за подразделениями.

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

Для описания процессов создаются небольшие рабочие группы (РГ) по человека + эксперты (начальники подразделений). Внешние консультанты могут осуществлять методическое сопровождение, координацию и контроль качества ( на основе ). Еженедельно РГ отчитываются о проделанной работе — представляют схемы процессов, результаты анализа процессов, предложения по улучшению.
На этапе описания процессов целесообразно использовать подход, объединяющий разработку моделей «как есть» и «как должно быть» в единую группу работ, которая выполняется РГ в течение короткого периода времени (нескольких недель):

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

По ходу описания и анализа важно активно вовлекать руководителей в поиск возможных улучшений. Целесообразно привлечь в команду специалистов по бережливому производству, теории решения изобретательских задач (ТРИЗ) и, что особенно важно в наше время, по автоматизации в BPMS и цифровизации (знатоков методов Индустрии 4.0).
Оптимизированные модели процессов дают возможность провести необходимые вычисления и ответить на вопрос, сколько времени занимает выполнение операций в целом. Затем выявить для каждого исполнителя его плановое время загрузки в процессах с учетом нормативов длительности выполнения каждого действия и среднего количества операций, совершаемых в течение месяца. Если окажется, что это время существенно меньше фонда рабочего времени, то исполнителя можно сокращать. Также необходимо рассмотреть возможность исключения должностей из оргструктуры компании.

Алгоритм анализа

Шаг 1
Классификация типа должности
Определяется тип должности: менеджер, работник, специалист, рабочий.

Шаг 2
Анализ загрузки должности
В моделях процессов компании исполнителями являются должности и роли. Каждая роль связана с конкретной должностью. Должность может выполнять несколько ролей в разных процессах. Анализ процессов дает информацию о нормативной трудоемкости каждой операции и количестве операций, совершающихся в процессах за месяц. Рассчитывается общая трудоемкость выполнения операций в для должности.
Пример: 10 процессов х 3 операции х 3 раза в день х 22 рабочих дня х 15 мин. = 29 700 мин.

Шаг 3
Анализ структуры рабочего времени должности
Определяются: время на подготовку к работе, постановку и выполнение разовых поручений, совещания и перерывы, опоздания, прогулы, больничные (последние три можно брать как средние для компании по типу должности).
Рассчитывается рабочее время, доступное для совершения операций в процессах в течение месяца (общее календарное рабочее время минус сумма всего остального времени). Если должность занимают несколько сотрудников, то доступное время умножается на их количество.

Шаг 4
Расчет нагрузки на одного исполнителя
Общая трудоемкость выполнения операций в процессах сопоставляется с фондом рабочего времени сотрудников, занимающих должность.
Пример: 22 рабочих дня х 6 ч. х 60 мин. = 7 920 мин. (реальная формула более сложная).
Расчетное количество необходимых сотрудников составляет 29 700: 7 290 = 3,75, четыре чел. Допустим, фактически должность занимают 10 чел. С учетом норматива численности потенциально можно сократить пятерых.

Шаг 5
Анализ персональных данных сотрудника
Выявляются исключительные компетенции каждого работника, которые важны для компании. Сотрудник, обладающий исключительными компетенциями, не может быть уволен просто так. Кроме компетенций, в расчет принимаются формальная квалификация, опыт работы, возраст, состояние здоровья, личные качества. Например, можно выполнить анализ личных качеств в соответствии с требуемым профилем: инновационность, коммуникабельность, способность работать в команде, исполнительность. В зависимости от типа должности и специализации состав критериев может меняться.
В результате рассчитывается рейтинг сотрудника. Если в компании внедрена система грейдов, то набор критериев для оценки должностей уже есть. В противном случае его придется создавать. Для получения оценки должностей в полуавтоматическом режиме стоит разработать систему, похожую на банковский скоринг (оценку кредитоспособности).

Шаг 6
Анализ возможности сокращения сотрудников
Выполняется рейтинговая оценка сотрудников, занимающих одну должность. Делается вывод о возможности сокращения. Результаты фиксируются в базе данных и включаются в отчет.

Шаг 7
Анализ возможности исключения должности
В случае, если должность занимает один сотрудник и его загрузка в процессах недостаточная (например, менее 50%), то рассматривается возможность ее исключения из оргструктуры компании. При этом определяются должности, на которые может быть перераспределена эта нагрузка.

Надо сказать, что для оптимизации организационной структуры совершенно необязательно выполнять тотальное описание процессов. Если у генерального директора 28 заместителей, два из которых управляют 80% ресурсов компании, то очевидно, что оргструктура не сбалансирована. В этом случае можно разработать перспективную структуру (на первых трех уровнях управления) только на основе анализа перспективной компании.
Однако в дальнейшем при реорганизации придется нарушить устоявшуюся иерархическую систему властных полномочий, что будет весьма рискованно как для спонсора, так и для команды проекта. При тотальном описании и анализе можно обосновать изменение структуры более мягко, на более длительном временном интервале.
План оптимизации оргструктуры должен четко описывать этапы исключения (перераспределения) должностей и подразделений в привязке к календарю, необходимые мероприятия по разъяснительной работе, поиску рабочих мест для увольняемых сотрудников, обучению и аттестации. Степень жесткости при сокращении персонала определяется корпоративной культурой и ситуацией, в которой находится компания. Для организации, близкой к банкротству, делать это нужно быстро и жестко.

Далее возникает проблема внедрения: очевидно, что одновременно управлять изменениями всех процессов невозможно. Поэтому после определения оптимальной численности сотрудников и наилучшей организационной структуры нужно приступить к сокращению персонала, а руководителям подразделений дать в руки схемы процессов «как должно быть», планы мероприятий по их оптимизации ( автоматизации) и объявить принцип: «Мы обоснованно сократили численность и сформировали модели „как должно быть“ — проекты оптимизации процессов дальше выполняйте сами». При этом, конечно, должны быть KPI ( результат, затраты, время, качество), от которых существенно зависит премия менеджеров. Безусловно, на данном этапе важно управлять настроением сотрудников, обеспечивать максимальную степень коммуникаций и поддерживать лидерство.

Экономическое обоснование проекта

Сделаем простой расчет — экономическое обоснование описания процессов для примера, приведенного в начале статьи: в компании трудятся две тыс. чел., количество операционных процессов — одна тыс. Предположим, что средняя зарплата (с учетом налогов и взносов) — 30 тыс. руб. в мес. Общий фонд оплаты труда составит 720 млн руб. в год.
Трудоемкость описания одной тыс. процессов из расчета 40 на один процесс (норматив, выработанный длительной практикой консалтинга по описанию и анализу ) составляет 40 тыс. часов. К этому времени добавим по четыре часа на анализ загрузки каждого исполнителя (с учетом использования полуавтоматизированной системы скоринга). В итоге трудоемкость проекта — 48 тыс. . Чтобы выполнить проект за год, потребуется 25 экспертов. Предположим, что зарплата этих специалистов — 60 тыс. в мес. Общий ФОТ на проект — 18 млн руб. в год.
В случае, если по итогам проекта удается сократить только 10% численности персонала, эффект составит 72 млн руб. Эффективность проекта — 400%.

Выводы

Сравним плюсы и минусы проекта тотального описания с целью сокращения численности персонала.
К плюсам можно отнести:

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

Минусы (риски) проекта:

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

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

ГЛОССАРИЙ

BPMS/BPMT

(англ. Business Process Management System/Tool — система/инструмент управления )
Технологическое программное обеспечение для поддержки концепции BPM.

BPM

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

Грейдинг

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

Опубликовано по материалам:
Журнал «Business Excellence» № 2 (февраль) 2018

Источник: www.businessstudio.ru