Бизнес-процесс на ладони: простые методы анализа и оптимизации
Бизнес-процесс на ладони: простые методы анализа и оптимизации
В статье Владимира Репина представлено описание четырех методов анализа бизнес-процесса: визуальный анализ графической схемы, анализ времени выполнения, анализ потерь, анализ потенциала автоматизации. Рассматривается использование принципов «вертикального» и «горизонтального сжатия для определения возможностей по оптимизации процесса. Статья может быть полезна сотрудникам компании, перед которыми поставлена задача выполнить анализ бизнес-процесса и разработать мероприятия по его улучшению.
Четыре метода анализа бизнес-процесса
BPM (Business Process Management) как направление менеджмента, как совокупность методов и инструментов существует довольно давно. За эти годы разработано и опробовано на практике значительное количество методов анализа бизнес-процессов. Они отличаются условиями применимости и целям, сложностью и требованиями к квалификации экспертов, проводящих анализ.
В данной статье я хотел бы рассмотреть четыре метода анализа процессов, которые вполне может использовать любой сотрудник организации, хотя бы в начальной степени овладевший навыками создания графических схем процессов в нотации BPMN (или, шире, — Work Flow). К числу этих методов относятся:
1. визуальный анализ графической схемы процесса;
2. анализ времени выполнения процесса;
3. анализ потерь, возникающих при выполнении процесса;
4. анализ потенциала автоматизации процесса
Использование указанных методов позволяет глубже понять процесс, выявить причины проблем, связанных с его выполнением, и разработать мероприятия, необходимые для его оптимизации.
В качестве исходного примера для проведения анализа и оптимизации будем рассматривать следующий бизнес-процесс, схема которого представлена на рис 1.
На данном учебном примере разберем указанные выше методы анализа и принципы оптимизации.
Предполагается, что читатели знакомы с базовыми аспектами описания процессов в нотации BPMN. Но даже если вы не знаете эту нотацию, условные обозначения на рис. 1 вполне понятны для сотрудников, которые в своей практике сталкивались с задачей описания процессов в нотациях типа Work Flow.
В процессе участвуют пять сотрудников, два из которых являются руководителям, а три – специалистами. Роль А – сотрудник, инициирующий выполнение процесса. Он же – потребитель результата процесса – расчета количества и стоимости. Роль Б – руководитель, согласующий расчет перед предоставлением его руководителю вышестоящего уровня (Роль Д), утверждающему расчет. Роль В и Роль Г – это специалисты, выполняющие расчеты.
Обратите внимание, что на схеме процесса указаны информационные системы (MS Outlook, MS Excel), которые поддерживают выполнение задач. Для задач выполняемых вручную (точнее «ногами») использован маркер ручной задачи (ладошка).
Далее в статье рассмотрены методы анализа бизнес-процесса на примере разбора представленной схемы (разработана в Business Studio 5).
Анализ графической схемы бизнес-процесса
Перед тем, как проводить визуальный анализ графической схемы бизнес-процесса необходимо убедиться в том, что:
- схема не содержит формальных ошибок (нарушения требований нотации, логические ошибки, несоответствие задач по масштабу и проч.);
- схема действительно описывает существующий процесс (модель «как есть»), а не что-то среднее между текущим и будущим состоянием.
Последний пункт является весьма важным. Дело в том, что неопытные сотрудники довольно часто либо упрощают схему, либо отображают на ней не реальный ход процесса, а некоторое искаженное (иногда намеренно) представление, полученное от его участников. Важно понимать, что только схемы процесса «как есть», адекватно (с достаточной точностью) отражающая реальное состояние дел, может быть эффективно использована для анализа процесса и принятия решений по его оптимизации.
Визуальный анализ графической схемы процесса можно выполнять следующим образом. Необходимо обратить внимание на:
• задачи, создающие ценность;
• задачи, не создающие ценность;
• передача результата процесса его потребителю;
• возвраты;
• дублирование задач;
• чрезмерный контроль;
• узкие места.
На рис. 2 показан результат визуального анализа графической схемы процесса.
В первую очередь обратите внимание на задачи (операции), которые точно не создают ценность. Это задачи «Распечатать и передать расчет на согласование» и «Передать расчет на согласование», которые выполняются вручную, точнее ногами (исполнитель ходит от кабинета к кабинету).
Далее на схеме выделены цветом четыре операции, при выполнении которых создание ценности находится под сомнением. Например, какую ценность создает задача «Проверить расчет количества» и почему без нее нельзя обойтись? Возможно, она дублирует задачу «Выполнить расчет количества», которую выполняет Роль В. Для ответа на такого рода вопросы необходим углубленный анализ каждой выполняемой задачи.
На схеме показано три возврата, которые приводят к существенному увеличению длительности процесса в целом.
Две операции «Проверить и согласовать расчет» и «Проверить расчет», быстрее всего, являются узким местом, так как их выполняют руководители. Как правило, процессы «застревают» на руководителям на длительное время, так как они загружены множеством дел и не могут оперативно отреагировать. Задача «Проверить расчет», вероятно, представляет собой избыточный контроль, которого можно избежать.
На схеме так же видно, что потребитель процесса (в данном случае – это Роль А, инициатор) не получает результат выполнения процесса – «Расчет». Ему нужно писать и звонить руководителю (Роль Д), выяснять статус и потом «ногами» забирать нужный ему документ. Это плохо.
По результатам содержательного визуального анализа графической схемы процесса выявлены следующие проблемы:
• результат выполнения процесса не передается его потребителю;
• 18% задач не создают ценность, 36% задач – создание ценности под вопросом;
• три возврата, которые увеличивают длительность процесса;
• дублирование задач;
• чрезмерный контроль;
• узкие места (задачи, выполняемые руководителями).
Далее необходимо выполнить анализ времени выполнения бизнес-процесса.
Анализ времени выполнения бизнес-процесса
На рис. 3 показан анализ времени выполнения процесса. Для каждой задачи определяют три показателя:
- нормативное время выполнения, минут;
- фактическая трудоемкость, минут;
- календарное время выполнения, минут.
Нормативное время выполнения – это время, которое тратит исполнитель задачи в идеальных условиях – когда есть все необходимые данные, информационные системы работают, исполнитель здоров и его никто не отвлекает. Нормативную длительность можно определить путем хронометража, по справочникам (если они доступны) или методом экспертной оценки (определяет руководитель).
Фактическая трудоемкость – это реальное время, которое сотрудник, в среднем, тратит на выполнение задачи. Она может быть определена экспертным путем или при помощи хронометража.
Календарная длительность выполнения задачи – это разница во времени между началом и завершением выполнения задачи. Используется усредненная величина по всем выполненным задачам за определенный период, например, месяц.
Почему фактическая трудоемкость и календарная длительность могут отличаться? Все просто – процесс может простаивать по различным причинам. Например, руководителю поступил документ на согласование. Реальная фактическая трудоемкость его работы надо документом, например, — 5 минут. Фактическая календарная длительность, в среднем, — 6 часов (с учетом повторного выполнения). То есть большую часть времени документ просто ждет в очереди на обработку. Очевидно, что необходимо организовать выполнения бизнес-процессов так, чтобы нормативное время и календарное время отличались как можно меньше.
Обратите внимание, что нормативное выполнения процесса в целом – около 2,8 часов, а фактическая календарная длительность – 32 часа, то есть почти в одиннадцать раз больше!
На рис. 4 показано время выполнения процесса в виде диаграммы. Видны следующие ограничения, устранение которых позволит существенно сократить длительность процесса. Бизнес-процесс дольше всего простаивает на следующих задачах:
• Проверить расчет.
• Проверить и согласовать расчет.
• Распечатать и передать расчет на согласование.
• Передать расчет на согласование.
• Выполнить расчет количества.
• Выполнить расчет стоимости.
Углубленный анализ указанных задач и разработка мероприятий по оптимизации помогут существенно сократить время выполнения бизнес-процесса в целом.
Например, целесообразно выполнить анализ ценности задачи по проверке и утверждению расчета руководителем. Так же нужно устранить хождения (отнес-принес) при передаче документа на согласование. Отдельного рассмотрения требуют задачи «Выполнить расчет количества» и «Выполнить расчет стоимости». Они тоже являются узким местом в процессе с точки зрения времени его выполнения.
Замечу, что можно выполнить анализ стоимости выполнения отдельных задач процесса и рассчитать стоимость выполнения одного экземпляра процесса в целом. Но данный расчет для сложных процессов (содержащих возвраты) целесообразно делать с использованием методов имитационного моделирования (это тема для отдельной статьи).
Анализ потерь при выполнении бизнес-процесса
Следующий вид анализа, который целесообразно выполнить – это анализ потерь, возникающих при выполнении бизнес-процесса. Можно использовать классическую классификацию потерь (TPS) учитывая, что эти потери в своеобразной форме могут возникать и при выполнении процессов в офисе (не на производстве):
- потери, связанные с перепроизводством;
- потери, связанные с ожиданием;
- потери, связанные с транспортировкой;
- потери, связанные самой обработкой;
- потери, связанные с ненужными запасами;
- потери, связанные с ненужными движениями;
- потери, связанные с производством дефектной продукции.
На рис. 5 показаны потери, которые были выявлены при проведении анализа процесса. Условные обозначения для потерь выбраны произвольно (без использования какой-либо нотации).
Более подробно потери и риски, возникающие при выполнении задач процесса показаны в Таблице 1. Так же в таблице показаны возможные последствия.
Таблица 1. Потери и риски при выполнении процесса.
№ | Наименование процесса/задачи | Потери | Риски | Последствия |
0 | Бизнес-процесс в целом | Повторение задач из-за возвратов. Распечатка и ручное перемещение документа | Формирование некорректного расчета (с ошибками) | Принятие ошибочных управленческих решений. Финансовые потери |
1 | Поставить/скорректировать задачу на подготовку расчета | Потери времени на ручное оформление заявки. | Отправка заявки по e-mail – риск ее потери | Увеличение сроков выполнения процесса |
2 | Выполнить расчет количества | Ручной перенос данных из базы в MS Excel, корректировка формул | Риск ошибок при ручном переносе данных | Ошибки в расчете. Увеличение сроков |
3 | Получить данные для прогноза | Ручной перенос данных из сети | Риск ошибок. Недостоверные исходные данные | Ошибки в расчете. Увеличение сроков |
4 | Проверить расчет количества | Дублирование другой задачи | Риск пропуска ошибок | Ошибки в расчете. Увеличение сроков |
5 | Выполнить расчет стоимости | Ожидание расчета. Ручной расчет в MS Excel | Риск ошибок | Ошибки в расчете. Увеличение сроков |
6 | Распечатать и передать расчет на согласование | Распечатка документа. Доставка «ногами» | — | Увеличение сроков |
7 | Проверить и согласовать расчет | Возможно, дублирование. Перенос данных с бумаги во временную форму в MS Excel. Ожидание. | Риск пропуска ошибок при проверке расчета | Ошибки в расчете. Увеличение сроков |
8 | Передать расчет на согласование | Доставка «ногами» | — | Увеличение сроков |
9 | Получить информацию о статусе согласования | — | — | — |
10 | Проверить расчет | Возможно дублирование. Ожидание. | Риск пропуска ошибок при проверке расчета | Ошибки в расчете. Увеличение сроков |
11 | Утвердить расчет | Работа с бумажной версией документа. | Потеря утвержденного документа | Увеличение сроков |
После анализа потерь целесообразно выполнить анализ потенциала автоматизации бизнес-процесса.
Анализ потенциала автоматизации бизнес-процесса
На рис. 6 показаны результаты анализа потенциала автоматизации бизнес-процесса в BPMS. Некоторые задачи (ручные) можно будет исключить. Одну задачу «Выполнить расчет количества» выполнять скриптом. Остальные задачи могут выполняться участниками процесса с использованием соответствующих экранных форм в BPMS.
Однако, тот факт, что задачи можно автоматизировать в BPM-системе совершенно не означает, что это нужно делать. Прежде всего, необходимо разработать мероприятия по оптимизации бизнес-процесса, используя определенные принципы, и уже после этого автоматизировать модель процесса «как должно быть».
Разработка мероприятий по оптимизации бизнес-процессов
Давайте применим принципы «вертикального» и «горизонтального» сжатия для оптимизации бизнес-процесса.
• Вертикальное «сжатие» — сокращение уровней функциональной иерархии, задействованных в выполнении процесса.
• Горизонтальное «сжатие» — сокращение времени выполнения операций, количества операций, устранение (минимизация) возвратов.
С учетом указанных принципов, а так же результатов анализа процесса, сформулированы мероприятия по его оптимизации, представленные в таблице 2.
Таблица 2. Мероприятия по оптимизации бизнес-процесса.
№ | Наименование процесса/задачи | Мероприятия |
0 | Бизнес-процесс в целом | Автоматизация процесса в BPMS.Интеграция с внешними системами. Исключение ручных операций. Делегирование полномочий.Определение SLA с привязкой к KPI. |
1 | Поставить/скорректировать задачу на подготовку расчета | Постановка задачи в формализованной экранной форме BPMS. |
2 | Выполнить расчет количества | Выполнение задачи скриптом в BPMS. |
3 | Получить данные для прогноза | Интеграция для автоматического получения данных (скрипт). Удобный интерфейс для проверки. SLA на 60 минут с момента поступления задачи (влияние на KPI). |
4 | Проверить расчет количества | Устранение задачи из процесса. |
5 | Выполнить расчет стоимости | Полуавтоматический расчет стоимости. |
6 | Распечатать и передать расчет на согласование | Устранение задачи из процесса. |
7 | Проверить и согласовать расчет | Делегирование полномочий на принятие решения.Удобный интерфейс для проверки. SLA на 120 минут с момента поступления задачи (влияние на KPI). |
8 | Передать расчет на согласование | Устранение задачи из процесса. |
9 | Получить информацию о статусе согласования | Всплывающее уведомление из BPMS. Возможно, автоматическая отправка сообщения на WhatsApp. |
10 | Проверить расчет | Устранение задачи из процесса. |
11 | Утвердить расчет | Устранение задачи из процесса. |
Схема бизнес-процесса, полученного по результатам оптимизации, представлена на рис. 7.
Диаграмма по времени выполнения задач бизнес-процесса «Как должно быть» (прогноз) показана на рис. 8.
Нормативное время выполнения процесса – 0,8 часа (сокращение в 3,4 раза).
Прогнозируемое календарное время выполнения процесса (с учетом установленных SLA – максимальное время реагирования на поступившую на выполнение задачу) – 4,3 часа (сокращение в 7,4 раза).
Оценить повышение качества расчета можно будет только набрав определенную статистику выполнения бизнес-процесса после внедрения всех мероприятий по его оптимизации и автоматизации.
Резюме
Мы рассмотрели несколько методов анализа, принципы оптимизации и применили их на условном примере бизнес-процесса формирования некоторого расчета (сметы, скидки, бюджета проекта и т.п.).
Качественная графическая схема является хорошим инструментом структурирования ваших знаний о бизнес-процессе. Если вы используете инструмент, например Business Studio 5, то эти знания можно формализовать непосредственно в системе и сделать доступными в виде гипертекстовой информации на внутреннем web-портале (с использованием технологии BS Portal).
В случае, если руководители компании заинтересованы в развитии системной практики работы с бизнес-процессами, целесообразно формализовать ряд методов анализа процессов, обучить руководителей и сотрудников этим методам и активно использовать при выполнении проектов описания, анализа, оптимизации и автоматизации бизнес-процессов.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»
Апрель 2021 г.
BPM-2021: вопросы и ответы
BPM-2021: вопросы и ответы
19 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран. По ходу конференции участники задали большое количество вопросов. Многие вопросы были сформулированы в чате конференции, поэтому во время ее проведения не всегда была возможность ответить на них развернуто. В статье мы восполняем этот недостаток. Наталья Косарева (НК) и Владимир Репин (ВР) подробнее ответили на многие вопросы участников. Презентации спикеров конференции и видео докладов можно посмотреть по ссылке выше.
Введение
18 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран.
Подводя итоги конференции, мы проанализировали состав участников, выбрали наиболее интересные вопросы и сформулировали на них ответы.
На рис. 1 представлена структура участников по половой принадлежности.
Интересно отметить, что женщины заметно больше мужчин интересуются темой процессного управления. Эта статистика подтверждается нашими личными наблюдениями за кадровым составом подразделений внутреннего орг. развития (это там, где работают бизнес-аналитики).
На следующем рис. 2 представлена диаграмма по уровням должностей участников конференции.
Любопытно отменить, что интерес к конференции был ярко выражен у руководителей подразделений (в первую очередь, в области орг. развития и СМК) и специалистов – бизнес-аналитиков, системных аналитиков и т.п. При этом главные и ведущие специалисты, вероятно, либо «уже в теме» (или считают, что «в теме»), либо настолько загружены текущей работой, что не смогли уделить время конференции. Впрочем, это только гипотезы.
На рис. 3 представлена структура участников конференции по типам организаций. Интересно отменить, что тема процессного управления оказалась важной для ВУЗов (6%) и органов государственной власти (4%).
Далее в статье представлены наиболее интересные вопросы участников конференции в соответствии со структурой BPM CBOK 3.0 и ответы на них. Часть вопросов была задана в чате конференции. Во время ее проведения не всегда была возможность ответить на них развернуто. Ниже мы восполняем этот недостаток.
Управление бизнес-процессами
Вопрос: Можно ли немного рассказать о связи процессов с финансовыми и бюджетными структурами. Например, для процесса управления «Бюджетирование», являются ли входами бюджеты ЦФО? Или бюджеты ЦФО — это интерфейсы между владельцем процесса бюджетирования и владельцами других процессов?
Ответ (НК): С моей точки зрения, бюджеты, которые не видоизменяются в других процессах, являются неким правилом, ориентиром. Если в бюджетной структуре происходит изменение бюджета, в связи с ее обязанностями по корректировке бюджета, то «бюджет» будет являться входом.
Ответ (ВР): Документы – это в любом случае не интерфейсы, ведь они пересекают границы ответственности. Границы процесса бюджетирования могут быть определены по-разному. Если формирование бюджетов ЦФО не входит в процесс «Бюджетирование», то очевидно, что бюджеты ЦФО (как результат другого процесса) могут являться входами для процесса «Бюджетирование». Так что это вопрос определения границ процесса.
Вопрос: «На примере последнего слайда Вы противопоставили развитие процессного управления и такие вещи, как развитие культуры, горизонтальных связей и т.п. Почему они противопоставлены? Нужно и то, и другое, как мне кажется».
Ответ (ВР): Нет, я не вкладывал такой смысл в слайды и не говорил этого. Как-раз наоборот, высокий уровень корпоративной культуры в части исполнительской дисциплины, коммуникаций, командной работы над проблемами, вовлеченности в улучшения будет только большим «плюсом» при внедрении технологий процессного управления. Наоборот, в бюрократической структуре с низкой исполнительской дисциплиной и слабыми горизонтальными связями процессное управление внедрять крайне тяжело.
Вопрос: «Зачем нужно уделять особое внимание управлению процессами, если можно решать задачи повышения прибыли другими способами?»
Ответ (НК): Прибыль = Выручка — Затраты. Следовательно, повышения прибыли можно достигать, либо увеличением выручки, либо уменьшением затрат. Процессное управление может способствовать изменению обеих составляющих. Например, для повышения выручки совершенствовать скрипты общения с клиентами, которые способствуют их притоку и доведения до покупки. Процессы, повышающие качество продукции, также способствуют увеличению количества клиентов и совершению существующими клиентами повторной покупки. Уменьшению затрат способствует стандартизация процессов, а для этого их необходимо увидеть, регламентировать и контролировать с помощью показателей с целью дальнейшего улучшения. Когда процессы выполняются по установленным стандартам, то люди не тратят время на раздумывания, как им лучше выполнить его. При стандартизации можно собирать статистические данные и смотреть статистическую устойчивость процесса. Улучшать можно только статистически устойчивые процессы.
Ответ (ВР): Каждая компания проходит разные этапы жизненного цикла. Область деятельности и масштаб компаний так же совершенно разные. Поэтому ответить на этот вопрос можно только применительно к конкретной компании, находящейся в конкретной ситуации. В целом, ответ – да. Можно эффективно решать задачи повышения прибыли другими способами. Но если компания достигла определенного размера и уровня зрелости, то внедрение процессного подхода становится неизбежным для того, чтобы уйти от практики «ручного управления» бизнесом, получить возможность делегировать полномочия и сделать процессы «прозрачными», контролируемыми, управляемыми.
Вопрос: «Можно ли в цифрах просчитать эффект для представления руководству?»
Ответ (НК): Все зависит от уровня зрелости учета на вашем предприятии. В продолжении ответа на предыдущий вопрос: эффект от внедрения может выражаться, либо в получении дополнительной прибыли от выпуска более качественной продукции, либо в уменьшении расходов в связи с устранением потерь.
Знание стоимости выполнения процесса помогает команде правильно назначить приоритет процессам, заслуживающим первоочередного рассмотрения. Организация может выбрать следующие критерии приоритетности:
• процессы, взаимодействующие с клиентом;
• процессы, оказывающие большое влияние на доходы;
• кросс-функциональные процессы, нуждающиеся в координации.
Каждому из этих факторов можно присвоить шкалу и определять приоритетность, исходя из суммы баллов.
Ответ (ВР): Можно. Но для этого нужно провести достаточно глубокую диагностику ситуации в компании и определить потенциал повышения эффективности. Для решения этой задачи целесообразно создать команду, включающую внутренних экспертов, внешних процессных методологов/аналитиков и отраслевых экспертов. Сравнение с практиками других успешных компаний особенно важно и позволяет сразу «высветить» проблемные места, оценить потенциал роста выручки, сокращения затрат и проч.
Вопрос: «Исходя из каких критериев можно рекомендовать выбор метода описания процессов (функциональные /сквозные)?»
Ответ (НК): Чтобы сложная современная организация оставалась конкурентоспособной, ВРМ и функциональное управление обязаны в ней уживаться и сотрудничать:
• функциональное управление гарантирует работоспособность несметного числа функциональных дисциплин, которые требуются организации для создания продукции и услуг;
• ВРМ гарантирует, что работа этого несметного числа функций координируется так, что продукция и услуги создаются с максимальной производительностью и эффективностью.
Ответ (ВР): Выбор зависит от целей и масштаба вашего проекта. Если вы хотите разобраться с процессами внутри отдела, то это будут «функциональные» процессы, которые могут не иметь законченной ценности в целом для компании и ее клиентов. Это не плохо и не хорошо. Это факт…. Если цель состоит в построении архитектуры бизнес-процессов компании, то нужно начинать с анализа деятельности всех подразделений, то есть с определения функциональных процессов. Если же цель проекта, например, быстро описать и автоматизировать конкретный бизнес-процесс на межфункциональном уровне, то нужно будет определять сквозной бизнес-процесс.
Вопрос: «Я правильно понимаю, что теперь на сквозной процесс не надо ломать голову и искать одного Владельца процесса. Так как это была та ещё задачка (невыполнимая), а исходя из теории так должно было бы быть. Сегодня Ваш слайд расставил все на свои места».
Ответ (НК): Э. Деминг в своей книге «Выход из кризиса» писал: «Разделенная ответственность означает, что не отвечает никто». Если цель ставится по всему сквозному процессу, то и ответственный должен быть один.
Ответ (ВР): Почему не надо? Надо! Если вы определяете сквозной процесс, то, очевидно, планируете его улучшать и потом оперативно управлять. Так что нужно будет выбрать и назначить ответственного за эту работу. А вот называть ли его «владельцем» и какие полномочия давать, это уже другой вопрос.
Вопрос: «Правильно ли понимаю, что рекомендуете с разной степенью глубины описывать разные процессы в рамках компании?»
Ответ (НК): В зависимости от уровня процессной зрелости организации управление эффективностью процессов различается углом зрения и глубиной. Один из первых шагов процессной команды – определение границ анализируемого процесса. Это ответственное решение, так как от него будет зависеть, как далеко зайдет проект, сколько бизнес-функций он затронет и какое воздействие на процессы и пользователей вверх и вниз по потоку работ окажут изменения. После того как рамки анализа заданы, аналитик должен выбрать глубину анализа: достаточно ли рассмотреть уровень действий или следует также проанализировать все входы и выходы?
Ответ (ВР): Глубина декомпозиции системы определяется целью ее разработки и квалификацией специалистов, которые потом будут с ней работать. Я рекомендую описывать процессы с той степенью глубины, которая нужна для принятия решений по улучшению процессов. Решения эти могут быть разного масштаба. Например, описание процессов в нотации IDEF0 на верхнем уровне помогло обосновать структурные изменения в организации – была создана новая, эффективная орг. структура, перераспределена ответственность за процессы на верхнем уровне. Другой пример: описание процесса в нотации BPMN помогло увидеть, насколько сложен, запутан реальный процесс, и принять решения по его реорганизации с последующим выходом на проект автоматизации в BPMS.
Вопрос: «Я правильно понимаю, что «сквозные» процессы собираются из отдельных уже описанных / стандартизованных процессов? Если да, то в чем ценность / смысл такой сборки? Или «выделены отдельные процессы» означает только то, что они названы / идентифицированы?»
Ответ (НК): Согласно определению АВРМР, «процесс» является кросс-организационным и включает в себя все работы, необходимые для создания и предоставления продукции или услуги. При этом процесс может быть разбит на подпроцессы, которые выполняются подразделениями как последовательность взаимосвязанных и последовательных действий – на потоки работ. После того, как эта структура определена, можно организовать мониторинг процесса путем объединения информации на уровне потоков работ, включая передачу ответственности между подразделениями.
Верхний уровень процессной иерархии составляет сквозной процесс. Затем он разбивается (декомпозируется) вплоть до отдельных действий, где и выполняется процессная работа. Процесс должен быть декомпозирован достаточно глубоко, чтобы показать, из каких действий он состоит и как эти действия дополняют друг друга в создании конечной продукции.
Ответ (ВР): Ценность — в непрерывности. Стыковка процессов в единый, непрерывный сквозной процесс, особенно при условии его автоматизации, дает очень хороший эффект для бизнеса: сроки выполнения, устранение потерь, удобство для клиентов.
Вопрос: «Как определить владельца процесса и разделить границы между внутренний заказчик/поставщик»?»
Ответ (НК): Самое главное – обеспечить непрерывность процесса и передачу ответственности. Лучше всего этого достигать при совместном обсуждении.
Ответ (ВР): Границы процессов – это всегда вопрос внутренних договоренностей. Не настолько важно, где граница. Гораздо важнее, что процессы стыкованы между собой непрерывным образом, что отсутствуют зоны безответственности (пересечения ответственности). При этом, конечно, важно понимать потребности каждого внутреннего заказчика. В разных частях организации (с учетом типа бизнеса) методы определения сквозных процессов могут быть разные. Простой критерий – «сквозной процесс проходит через несколько подразделений» — это не метод его определения. В целом, определение сквозных процессов – это инструмент менеджмента. Если просто спрашивать, «Что вы делаете для такого-то процесса?», можно получить большой объем плохо структурированной информации, которую почти невозможно будет использовать. Другими словами, описание процессов «снизу вверх» без архитектуры, как правило, не дает хорошего результата.
Вопрос: «Почему поиск и прием нового сотрудника — сквозной процесс. Этим же может заниматься одно подразделение».
Ответ (НК): В разных компаниях по разному: все зависит от размеров и организационной структуры компании.
Ответ (ВР): Может и один человек заниматься, если у вас небольшая компания. Но в средней и большой компании в процессе поиска и приема нового сотрудника участвует несколько разных подразделений: служба персонала, служба безопасности, бухгалтерия, внешнее мед. учреждение, руководитель подразделения-заказчика и проч. Процесс может быть достаточно сложным и, очевидно, сквозным.
Вопрос: «Правильно ли поняла по вашему слайду о функциях и процессах, что деятельность по бюджетированию является функцией? Если — да, то почему эта функция имеет все определяющие для процесса характеристики — повторяемость, регламентированность, наличие заказчика и показателей качества. Пример показателей — отклонение план\факт, своевременность подготовки бюджетов».
Ответ (НК): Модели потоков работ обычно описывают, что должно быть сделано для выполнения процесса. Это модели более детальные по сравнению с моделями процессов предприятия и моделями бизнес-процессов. Модели потоков работ разбиваются на действия (их также называют задачами или процедурами). Действия в модели потоков работ выполняются «функциями»: должностями, подразделениями, системами.
Ответ (ВР): А что такое вообще «Функция»? Если абстрактная способность что-то делать, то нам такое определение не нужно. А если функция имеет все нужные характеристики, то это уже процесс, но не сквозной, а локализованный в одном структурном подразделении. Это нормально.
Вопрос: «Какие принципы существуют при определении границ процесса. Как показывает моя практика — целостный результат коллеги понимают по-разному. Для кого-то это договор закупки подписан, для кого-то договор исполнен, для кого-то отсутствует возможность применить к нему исковую давность».
Ответ (НК): Все определяется целями компании, а также выбором приоритетов, о которых говорили выше: знание стоимости выполнения процесса помогает команде правильно назначить приоритет процессам, заслуживающим первоочередного рассмотрения, а также определению границ.
Ответ (ВР): Границы процесса определяются по входам/выходам и событиям. Но еще раз подчеркну: важно не просто определить границы отдельного процесса, а стыковать все процессы между собой по входам/выходам и событиям, добиваясь непрерывности и отсутствия зон безответственности.
Вопрос: «Обеспечение производства услугами подрядчиков куда помещаем: в операционную или обслуживающую систему?»
Ответ (НК): Компания сама определяет. Генри Минцберг в организационной структуре выделяет еще «Техноструктуру», которая как раз занимается обеспечением производства.
Ответ (ВР): Скорее, в обслуживающую.
Вопрос: «А управление, как процесс, Вы не выделяете?»
Ответ (НК): Управление – это самый важный процесс с точки зрения устранения потерь и повышения эффективности компании. Большинство организаций продолжает фокусироваться на небольших улучшениях структурированных процессов, в то время как возможности дифференциации процессов в большей степени кроются в деятельности работников умственного труда. Эта деятельность в значительной степени не структурирована – она не является рутинной, и для нее не характерно последовательное и предсказуемое выполнение. Ведущие мировые экономики зависят от успеха работников умственного труда. Успех в отраслях сферы услуг определяется использованием знаний.
Ответ (ВР): Да, конечно. При создании архитектуры бизнес-процессов для каждого процесса 1-3 уровня всегда определяем процесс «управления процессом». При его декомпозиции показываем процессы, связанные с целеполаганием, планированием, организацией, мониторингом и контролем, принятием решений, анализом, контролем исполнения регламентов и проч. Если не определять такие процессы в архитектуре, то как потом регламентировать и автоматизировать деятельность руководителей по управлению бизнес-процессами?
Вопрос: «Однако, а как же быть с процессами управления? Как быть с классическими схемами с управляющей и управляемой подсистемами и обратными связями?»
Ответ (НК): Работники умственного труда оказываются среди тех, кто больше всех сопротивляется улучшению процессов. Они видят в этом принижение значимости их опыта и уникальной интуиции. Однако такое отношение отражает давнее ошибочное восприятие улучшения процессов.
Ответ (ВР): При формировании моделей в нотации IDEF0 это можно легко показать. Мы так и делаем.
Моделирование процессов
Вопрос: «На верхнем уровне при моделировании не используете IDEF0? Комбинирование IDEF0 и BPMN на ваш взгляд не эффективно?»
Ответ (ВР): это зависит от используемого программного продукта для описания бизнес-процессов. Например, в Business Studio 5 мы активно используем нотацию IDEF0 для построения моделей процессов на верхнем уровне. Это модели так называемого структурного типа. Их основная задача – построение модели сложной системы – архитектуры процессов компании. Такую же задачу решает, например, нотация VAD в системе ARIS. Есть и другие нотации, которые можно применять для построения структурных моделей, например DFD (Data Flow Diagram). В свою очередь, нотация BPMN является отличным выбором для описания процессов Work Flow (поток работы) для целей анализа, регламентации и подготовки к автоматизации в BPMS. Например, комбинация нотаций IDEF0 (для верхнего уровня) и BPMN (для нижнего) в Business Studio 5 весьма эффективна.
Вопрос: «Какая «временная последовательность» может быть в диаграмме IDEF0 (верхний уровень 8-процессной модели)?»
Ответ (ВР): Никакая. IDEF0 – это модель структурного типа. Она принципиально не показывает «временную последовательность» выполнения процессов в отличии от нотаций типа Work Flow (CFFC, eEPC, BPMN).
Вопрос: «Выделяете ли Вы требования к моделируемым БП, до начала моделирования»?
Ответ (ВР): Да, конечно. Практически в каждом проекте создается (на основе типового) Соглашение по моделированию бизнес-процессов (Стандарт описания бизнес-процессов). В этом документе фиксируются все требования к моделям бизнес-процессов в используемых нотациях (например, IDEF0 и BPMN). Кроме того, всегда важно понимать цель моделирования процесса, метод и точку зрения.
Вопрос: «В «Бережливом производстве» есть инструмент картирование процесса. Рекомендуете ли его?».
Ответ (НК): Карта потока создания ценности (КПСЦ) входит в нотации, рекомендуемые BPM CBOK. Использование нотаций зависит от целей компании.
КПСЦ используется.
• Чтобы вовлечь в анализ процесса его исполнителей.
• Там, где не требуются полноценные средства моделирования.
• Там, где четко заданы требования по стоимости и продолжительности процесса.
Преимущества.
• Простота и легкость применения.
Недостатки.
• Плоские модели.
• Репозиторий не предусмотрен.
• Невозможно использовать для решения сложных задач.
Ответ (ВР): Если Вы имеете в виду Toyota Value Stream Map (VSM), то его можно рекомендовать для решения конкретного круга задач – анализа цепочки создания ценности в рамках существующей производственной модели и построении новой модели «вытягивающего» производства на основе принципов TPS. Если ваша задача – описать процессы для последующей автоматизации в BPMS, то метод VSM вам, конечно, не подойдет.
Анализ процессов
Вопрос: «Описание и анализ чем отличается от стандартизации?»
Ответ (НК): Одна из целей BPM СВОК – стимулировать читателей к использованию общей, согласованной терминологии в области ВРМ. Чтобы все друг друга понимали, определения должны быть согласованы с бизнес-руководителями, с IT и бизнес-партнерами. Но тут возникает культурно-политическая проблема: чье определение будет признано истинным и выбрано для всеобщего употребления? Пока термины и акронимы не согласованы, пользы от стандартов сбора информации будет немного в плане выработки общего понимания того, что представляют собой операции и как их следует совершенствовать.
Что такое описание и анализ по BPM CBOK?
Описание процесса должно соответствовать назначению и применению:
• Соответствие назначению подразумевает, что описание процесса содержит всю необходимую информацию для ответа на вопросы, кто, что, где, когда, зачем и как делает.
• Соответствие использованию подразумевает, что описание процесса структурировано таким образом, чтобы представлять эту информацию максимально эффективно, учитывая потребности целевой аудитории.
Анализ процессов дает представление о действиях процесса и измеряет результаты этих действий, сопоставляя их с целями организации.
Анализ процессов выполняется с помощью различных методов, в том числе составления диаграмм, интервьюирования, имитации действий и других. Он часто включает в себя изучение бизнес-среды, организационного контекста процесса, факторов, влияющих на операционную среду, отраслевых особенностей, правительственных и отраслевых нормативов, требований рынка и конкуренции.
Ключевые факторы, подлежащие рассмотрению при анализе процессов:
• стратегия бизнеса;
• цели процесса;
• ключевые проблемы на пути к достижению целей;
• вклад процесса в общую цепочку создания ценности;
• организация и бизнес-роли, обеспечивающие процесс.
Ответ (ВР): Да, конечно. Целью описания и анализа может быть, например, оптимизация процесса и/или подготовка к его автоматизации. Кроме того, создание регламента на основе описания процесса еще не означает его стандартизацию. Чтобы стандартизовать процесс нужно внедрить регламент и добиться того, чтобы соответствующие процессы выполнялись в соответствии с этим регламентом. Т.е. нужна Система стандартизации, а не просто отдельные регламенты.
Проектирование процессов
Вопрос: «На первый взгляд, проектирование процессов «снизу вверх» (путем выделения классов процессов и построения типовой модели объекта класса) всегда приводит к модели «as is». Или все-таки нет?»
Ответ (НК): Проектирование процесса включает изучение существующего процесса и его подпроцессов и анализ того, как он может быть усовершенствован или фундаментально пересмотрен для достижения желаемого результата.
Ответ (ВР): В этом вопросе несколько скрытых смыслов. Во-первых, проектирование «снизу вверх» редко приводит к нормальному архитектурному решению. Это как строить завод «хоз. способом» — построить можно, но потом будут постоянные проблемы: то не продумали, сё не продумали, там упало, тут развалилось и т.п. Во-вторых, что есть «as is»? Многие, когда делают описание «как есть», сильно отрываются от реальности. В итоге, считают, что делали «как есть», а по факту получили «как смогли изобразить свои представления о том, как есть, опираясь не неточные и непроверенные данные». Неумение моделировать, например, в нотации BPMN, комбинируется с недостоверными данными и их субъективной интерпретацией… Для получения действительно адекватной модели «как есть» нужно быть серьезным профессионалом и опираться на проверенные, достоверны данные. Чем точнее модель «как есть», тем она дороже. Но здесь возникает вопрос, а насколько такая модель нужна, если анализ процесса в целом показывает, что он никуда не годный? Речь идет о том, что степень приближения модели «как есть» к реальности должна быть разумной, обусловленной целями и задачами конкретного проекта.
Вопрос: «Чем отличается описание процессов «для автоматизации» от описания процессов «как есть» или «как будет»?»
Ответ (НК): Группа, отвечающая за проектирование бизнеса, должна иметь представление о технических аспектах проектирования, создания и внедрения бизнес-усовершенствований. Аналогично группа от IT должна иметь представление о подходах к трансформации бизнеса. Ограничения и доступные варианты будут сильно различаться в зависимости от того, опирается ли проектирование процесса на генерацию BPMS-приложений.
Существуют два основных подхода к проектированию новой модели. Первый заключается в проектировании такого усовершенствования, которое можно целиком реализовать одним изменением. Второй заключается в разработке модели, которая была бы оптимальной, но (пока) не реализуемой на практике из-за дороговизны, из-за радикальности, из-за недостижимых изменений IT и т.д. В этом случае разрабатываются одна или несколько промежуточных версий, приближающих нас к «оптимальной» модели «как будет».
Эффективность компании напрямую зависит от качества процессов и правил. Но сегодня к ним добавляется еще один элемент: способность компании воспринимать изменения и быстро к ним адаптироваться. И еще меньше тех, кто способен на быстрые изменения, и кто может контролировать большую часть происходящих в компании изменений. Одна из причин – неспособность IT-инфраструктуры и унаследованных IT-приложений компаний среднего и крупного масштаба поддерживать требуемый темп изменений. IT-подразделения завалены заявками на доработку информационных систем, с которыми не могут справиться. В большинстве операций возникают «белые пятна» — ручная работа, обусловленная ограниченными возможностями автоматизации и быстротой изменений.
Ответ (ВР): Всем. Начнем с того, что модели «Как есть» и «Как будет» могут делаться не для автоматизации. Модели «для автоматизации» тоже могут быть разными. Поэтому в этом вопросе вы пытаетесь сравнивать «круглое» и «теплое» — в чем разница?
Управление эффективностью процессов
Вопрос: «Максимальное кол-во KPI на одного человека, которые работают эффективно?»
Ответ (НК): Объем внимания у взрослого человека составляет 5-7 элементов, на это и стоит ориентироваться. У меня в компании у сотрудников был один верхний интегрированный показатель эффективности, который каскадировался на три составных.
Ответ (ВР): KPI не работают. Работают системы: целеполагания и планирования, управленческого учета, оперативного контроля и управления, материального стимулирования. Количество KPI само по себе ничего не значит. Важно, как они используются в рамках данных систем. С точки зрения конкретного человека, оценка больше, чем по 3-5 показателям становится сложной для восприятия. Это затрудняет понимание и снижает возможность концентрации.
Вопрос: «Для оценки бизнес-процессов, что предпочтительнее использовать KPI или OKR?»
Ответ (НК): ОKR применяется при управлении изменениями и инновациями (Change and Disrupt), а KPI — больше при управлении процессами (Run).
Ответ (ВР): KPI – показатели. Они используются не сами по себе, а в рамках определенной системы. В OKR тоже есть показатели.
Процессная трансформация
Вопрос: «Классификация типов управления… Чье авторство разработки? Или обще признанное с методологической точки зрения?»
Ответ (ВР): Авторство Владимира Репина. Подготовил специально для конференции. Меня давно волновал вопрос, может ли компания быть успешной без бизнес-процессов? Классики жанра, такие как М. Хаммер, устами своих последователей твердили нам, что «… компанию делают успешной и конкурентоспособной ее бизнес-процессы». После долгих размышлений над этим вопросом я все-таки понял: это не так! Компанию делают успешной множество факторов: личность собственника, текущий момент, коллектив, наследство в виде активов, медленная смерь конкурентов, гос. поддержка, удача и т.п. Когда мы говорим о процессах – есть они в компании или нет, — надо четко определить, что мы поднимаем под понятием «процесс». Если это «деятельность по преобразованию входов в выходы», то такую деятельность можно успешно выполнять безо всяких там процессов. Да, будут потери. Да, результат будет каждый раз немного разный. Но если на рынке нашелся клиент на такой результат, купил, и мы в прибыли, то обошлось без бизнес-процессов. Другое дело, как я писал выше, когда компания вырастает до определенного размера, ей становится выгодно заниматься определением реальных процессов (целенаправленная, повторяющаяся, стабильная последовательность действий, приводящая к получению заданного результата).
Вопрос: «А что если руководитель подразделения не берет на себя роль владельца сквозного БП? Как можно повлиять\замотивировать?»
Ответ (НК): Должна быть заинтересованность вышестоящего руководства, а уж у него есть административные ресурсы для вовлечения.
Ответ (ВР): Всяко-разно. Можно, например, утвердить положение о Владельце процесса, а потом назначить приказом.
Процессная организация
Вопрос: «Архитектура бизнес-процессов — это реестр сквозных процессов? Или организационная структура с функционалом подразделений — это тоже архитектура бизнес-процессов?»
Ответ (НК): Вариант 1-й архитектуры бизнес-процессов — реестр процессов в виде справочника, перечня процессов в Word. Вариант 2-й архитектуры бизнес процессов – это модель, в которой вы понимаете, как ваши процессы связаны с точки зрения информационных и материальных потоков, с точки зрения управленческих воздействий, обратных связей. Модель позволяет вам понять в каких границах работают процессы и точно определить для них показатели. Архитектура процессов –это основа для того, чтобы внедрять системную практику работы с процессами.
Ответ (ВР): В каком-то смысле – да. Недостаток Реестра может состоять в том, что непонятны, не уточнены границы процессов. Это означает, что сам Реестр довольно «сырой». При декомпозиции могут потребоваться существенные действия по его изменению. Если же при создании Реестра процессы были стыкованы по входам/выходам (т.е. определены границы), то такой Реестр можно рассматривать в качестве архитектуры бизнес-процессов организации.
Вопрос: «Архитектура процессов и карта основных бизнес-процессов — не одно и то же?»
Ответ (ВР): Нет, если речь идет об одной картинке, на которой представлены «рыбками» основные процессы.
Вопрос: «Как описывать архитектуру процессов? Самостоятельно или внешними специалистами?»
Ответ (НК): Зависит от целей и возможностей компании. Например, Вы захотели съесть борщ. Первый вариант: пойти в ресторан и там его заказать. Второй вариант: изучить книгу с рецептами, сходить на рынок, все закупить, приготовить, подождать, когда он настоится, потому что борщ лучше есть на второй день. Выбирайте сами.
Ответ (ВР): Все зависит от наличия в вашей компании процессного архитектора/методолога и бизнес-аналитиков. Если они есть, то можно разработать архитектуру самим. Если их нет, а нужно быстро, то целесообразно заказать эту работу у внешних консультантов.
Управление процессами организации
Вопрос: «10 атрибутов Системы управления бизнес-процессами — какие из них наиболее важно добавлять к 1-ому и 2-ому подходам (1. регламентация и 2. BPM-проект)».
Ответ (ВР): Не нужно их добавлять. Нужно выбрать ваш путь – будете или нет создавать Систему управления бизнес-процессами, как часть общей Системы управления компанией.
Вопрос: «Есть ли продуманный граф причинно-следственных связей 10-ти атрибутов? С чего начинать? Если мы поставили себе цель, по бизнес-процессам выйти на 5 уровень, это реально сделать за год? Если мы сейчас находимся на 2-ом уровне».
Ответ (НК): Можно все. Зависит лишь от желания руководства и финансовых ресурсов. За первые 4 месяца войны из-под удара агрессора были выведены 8 млн. человек, 2,5 тысячи промышленных предприятий, 1,5 тысячи колхозов и совхозов. По своим масштабам и эффективности этот проект не имеет аналогов в мировой истории. Нет ничего невозможного.
Ответ (ВР): Такого графа нет. Была попытка его нарисовать, но схема оказалась слишком сложной – не стал публиковать. А вот график Ганта по внедрению СУБП есть. Его можно посмотреть в моих статьях и видео на канале Youtube. Да, реально за год перейти со 2-ого на 5-й уровень (оценка 0,5, шкала 0-1), если вы имеете в виду шкалу, представленную на диаграмме в моей презентации.
Вопрос: «Вы показывали оценку зрелости компании по 10 факторам СУБП. Есть у вас методики оценки финансового эффекта (эффективности) при изменении уровня зрелости в целом и по каждому из показателей?»
Ответ (ВР): Нет, пока такую методику не разрабатывал, так как сделать это весьма сложно. У вас есть методики оценки финансового эффекта от совершенствования процесса конструирования изделий, управления персоналом или развития корпоративной культуры? Вряд ли. Но, тем не менее, многие собственники компаний убеждены, что это делать нужно.
Вопрос: «В своей практике консультанта и продавца консалтинговых услуг я давно чувствовал нехватку методики оценки зрелости организации с точки зрения ее готовности к тем или иным работам в области бизнес-анализа. Мог бы я надеяться, что Вы или другой выдающийся профессионал однажды подготовит такую методику, которая позволит нам, специалистам, качественно оценивать организацию с точки зрения ее способности успешно внедрить конкретные наши работы / предложения?»
Ответ (ВР): Вопрос интересный. Такая методика, правда не в формализованном виде, у меня есть. Приходится оценивать возможность внедрения системы на этапе принятия решения – работать с конкретным клиентом или нет. Думаю, мы ее подготовим и опубликуем в ближайшее время.
Наталья Косарева,
эксперт-практик в области развития производственных систем, руководитель группы сервисных компаний по всей территории России, организатор кубка Гастева А.К. в 2019 году.
Владимир Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»
Март 2021 г.
Моделирование программных продуктов в Business Studio 5
Моделирование программных продуктов в Business Studio 5
В статье Владимира Репина рассмотрены функциональные возможности по использованию программных продуктов при создании моделей бизнес-процессов в нотации BPMN в Business Studio 5. Обсуждаются преимущества и недостатки представленных способов. Материал может быть полезен при разработке Соглашения (стандарта) по моделированию бизнес-процессов вашей организации.
Зачем моделировать программные продукты в Business Studio?
В статье речь пойдет об использовании объектов справочника «Программные продукты» в моделях бизнес-процессов в нотации BPMN в Business Studio 5. Например, можно для каждой операции процесса указывать конкретный программный продукт, который используется при ее выполнении. Программные продукты являются элементами общей модели организации и хранятся в соответствующем разделе более общего справочника «Объекты деятельности».
Для чего нужна информация о программных продуктах на схемах типа Work Flow (eEPC, BPMN)? Конечно, в модели такого типа нас интересует, прежде всего, корректный (без логических ошибок) алгоритм выполнения процесса. Движение документов на схеме, взаимодействие по входам-выходам с другими процессами, описание используемого программного обеспечения, рисков и прочих объектов делают из графической схемы модель бизнес-процесса. Это дает нам возможность выполнять анализ процесса «как есть», находить проблемы и выявлять их причины, определять потенциал повышения эффективности процесса за счет реализации ряда мероприятий.
Автоматизация процесса является одним из возможных направлений его совершенствования. Для того, чтобы выполнить анализ существующих проблем в этой области и обосновать необходимость изменений, как раз и нужно использовать программные продукты при моделировании бизнес-процессов в нотации BPMN.
Формирование структуры программных продуктов в справочнике
В Business Studio 5 можно создать структуру используемых в компании программных продуктов в справочнике «Объекты деятельности/Программные продукты». На рис. 1 показан пример структуры программных продуктов компании.
В начале создается объект справочника «Информационная система», например «1С». Затем для нее может быть добавлен «Модуль ИС», например «1С: Бухгалтерия». Далее, при необходимости, внутри модуля можно создать «Функцию ИС». В целом, группировка по модулям и функциям может быть многоуровневая.
Нужно ли создавать сложную, многоуровневую структуру? Если используемые в вашей компании информационные системы достаточно просты, то не нужно чрезмерно усложнять справочник. Но если у вас внедрены такие системы, как SAP, то многоуровневый справочник может быть весьма удобен. При его аккуратном использовании в моделях вы сможете получить потом детальную аналитику, какие именно функции информационных систем используются при выполнении конкретных операций процесса.
Три способа использования программах продуктов на схеме процесса в нотации BPMN
Способ № 1. Привязка через интерфейс
Рассмотрим три основных способа использования программных продуктов в моделях бизнес-процессов в нотации BPMN. На рис. 2 показана схема процесса (учебный пример). По правой кнопке открыты «Свойства» операции «Собрать информацию». Из справочника программных продуктов в список «Программные продукты» перетянут мышкой продукт «MS Word».
Далее нужно выбрать тип связи программного продукта и операции процесса. Можно использовать два типа связей: «поддерживает» и «выполняет» (вы можете создать любой новый тип связи при необходимости). Какой из них выбрать?
Зачем вообще указывать тип связи? Это нужно в том случае, если мы хотим в дальнейшем анализировать процесс и выгружать определенные аналитические отчеты. Например, мы хотим узнать, какие информационные системы (продукты) используются при выполнении бизнес-процессов, каковая степень автоматизации процессов с использованием систем определенного класса и т.д. Так же это может быть полезным при выполнении проектов развития ИТ-архитектуры компании и автоматизации процессов.
При использовании типа связи важно принять решение, в каких случаях она может использоваться, и четко закрепить эти требования, например в Соглашении по моделированию.
Тип связи «поддерживает» можно, например, интерпретировать следующим образом. Привязка программного продукта к операции с этим типом связи означает, что:
- операция выполняется сотрудником, и при этом:
- какие-то действия выполняются сотрудником в соответствующей информационной системе.
Тип связи «выполняет» можно интерпретировать следующим образом:
- операция выполняется полностью автоматически в соответствующей информационной системе.
Действительно, что значит, что программное обеспечение что-то «выполняет»? Может ли MS Word что-то «выполнять» сам без участия человека? С моей точки зрения, нет. А вот например, антивирусная система может приступить к проверке автоматически, по расписанию, без участия человека. В этом случае операция «Проверить РС на вирусы» будет полностью автоматический и будет «выполняться» соответствующей информационной системой.
Итак, аккуратно привязав программные продукты через интерфейс к операциям процесса мы сможем потом получить требуемый аналитический отчет. Недостатком такого подхода является тот факт, что на самой схеме процесса не видно, какие именно программные продукты используются. Для этих целей можно использовать второй способ – визуализацию.
Способ № 2. Визуализация на схеме
Программные продукты можно просто перетаскивать мышкой на схему процесса в виде фигуры. Но чтобы это сделать, в Business Studio 5 сначала нужно выбрать тип фигуры. При открытой схеме процесса надо выбрать мышкой программные продукты в палитре элементов и нажать правую кнопку. Далее поставить галочку напротив «Фигура», как показано на рис. 3. После этого можно перетаскивать программные продукты из справочника на диаграмму.
На рис. 4 показан результат визуализации использования программных продуктов на схеме процесса. Для каждой операции процесса показаны программные продукты, которые поддерживают их выполнение.
Обратите внимание, что размеры и цвета значков изменены (вручную). Визуальный вид и цвет значков можно закрепить в Соглашении по моделированию. В следующей версии Business Studio будет добавлена функциональная возможность управлять цветами объектов в зависимости от значения параметров.
Визуально представление программных продуктов на схеме имеет одно большое преимущество с точки зрения анализа и оптимизации бизнес-процесса: сразу становятся очевидными проблемы, связанные с автоматизацией, в том числе:
• недостаточная автоматизация или ее отсутствие;
• переход информации из одной системы в другую (косвенно), т.е. низкая степень интеграции и риски возникновения ошибок;
• использование чрезмерно сложных программных инструментов без необходимости;
• неэффективное выполнение операций, связанное с ограничениями возможностей программного обеспечения и человеческим фактором;
• прочие.
Более глубокий анализ указанных проблем дает возможность обосновать мероприятия по улучшению процесса и внедрению новых информационных систем, например iBPMS+RPA вместо тяжеловесной, неудобной и устаревшей СЭД.
На рис. 5 стоит обратить внимание на тот факт, что программные продукты, привязанные визуально, сразу появляются в соответствующем списке. Но если сначала внести объект в список в свойствах операции, то визуально он не будет показан на схеме. Таким образом, у вас есть возможность выбора варианта использования в зависимости от поставленных задач.
Как быть в случае, если операция выполняется полностью автоматически? На рис. 6 показан один из допустимых вариантов. Можно одновременно использовать маркер автоматического выполнения («вызов внешней функции или сервиса») и тип связи «выполняет». По типу связи вы всегда сможете отфильтровать все операции процессов, выполняемые автоматически. Кстати, в Business Studio 5 можно настраивать визуализацию параметров для стрелок, используемых в модели. Это удобно.
При использовании указанного подхода, автоматически выполняемая операция может быть показана на дорожке любого исполнителя.
Если вы не хотите выводить в регламент бизнес-процесса операции, выполняемые автоматически, то можно в шаблоне отчета применить соответствующий фильтр по типу связи программного продукта с процессом.
Способ № 3. Представление в виде отдельной дорожки
В Business Studio 5 появилась возможность использовать программное обеспечение в качестве дорожки на схеме в нотации BPNN. На рис. 7 показана измененная схема процесса, на которой модуль «FI-CO» показан в виде дорожки. Дополнительно для наглядности использован маркер автоматического выполнения операции.
Обратите внимание, что тип связи программного обеспечения с операцией процесса – «выполняет». Таким образом, можно визуально показывать программное обеспечение в качестве полноценного участника процесса.
Способ представления программного продукта на схеме процесса (в виде отдельной дорожки) является весьма спорным.
Хотя, возможно, это будет удобно для описания алгоритмов выполнения процессов, полностью автоматизированных в различных системах: веб-сервисы, BPMS, RPA, ERP.
Преимущества и недостатки методов представления программных продуктов в моделях процессов в нотации BPMN
В следующей таблице представлено сравнение трех методов представления программных продуктов на схеме процесса в нотации BPMN.
Критерии сравнения | Метод 1. Привязка через интерфейс | Метод 2. Визуализация на схеме | Метод 3. Представление в виде отдельной дорожки |
Полнота | «-» Невозможно вывести объект на показ на схеме. При последующей визуализации (вручную) на схеме возникает дублирование объектов в списке | «+» При визуальной привязке объект автоматически попадает в список «Программные продукты» для операции. | «+» Объект автоматически попадает в список «Программные продукты» для операции. Нет дублирования. |
Возможность визуального анализа | «-» Отсутствует | «+» Есть. | «+» Есть. |
Наглядность и удобство визуального анализа | «-» Отсутствует | «+» Есть. Наглядно и понятно. | «-+» Есть, риск усложнения схемы за счет создания дополнительных дорожек |
Возможность формирования аналитических отчетов | «+» Есть. | «+» Есть. | «+» Есть. |
Мы рассмотрели различные подходы к моделированию программных продуктов на схемах бизнес-процессов в нотации BPMN в Business Studio 5.
На мой взгляд, визуализация на схеме в виде значков (не дорожек) является предпочтительным вариантом с точки зрения решения задачи анализа и оптимизации бизнес-процесса. В этом случае автоматически выполняемая операция может быть показана на дорожке любого исполнителя.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»
Январь 2021 г.
Использование имитационной модели процесса в Business Studio для анализа и обоснования проекта оптимизации
Использование имитационной модели процесса в Business Studio для анализа и обоснования проекта оптимизации
В статье представлены результаты имитационного моделирования процесса «Рассмотрение и согласование оперативных заявок» в среде Business Studio. Выполнен анализ процесса «как есть». Определены направления оптимизации процесса. Разработана модель «как должно быть». Путем имитации процесса определен потенциальный экономический эффект от возможного проекта оптимизации, в т.ч. за счет автоматизации в BPMS. Статья может быть интересна специалистам в области организационного развития, использующим модели процессов в нотации BPMN в среде Business Studio.
Введение
В рамках проектов оптимизации необходимо не только представить заказчику целевую графическую диаграмму процесса, но и выполнить определенный расчет при помощи модели. Такой расчет дает возможность обосновать экономический эффект и снизить неопределенность в принятии решений.
Измерение – это совокупность снижающих неопределенность наблюдений. И если учесть тот факт, что многие решения, например стоит ли внедрять новую ИС, принимаются компаниями в условиях неопределенности, то даже незначительное ее снижение способствует более удачному выбору.
Проводя имитационное моделирование бизнес-процесса, мы снижаем неопределенность в части трудоемкости процесса, его оптимальности, вариативности. Можем боле объективно судить о способах его оптимизации, особенно выходя на автоматизацию.
В данной статье рассматривается имитационная модель реального процесса «Рассмотрение и согласование оперативных заявок». крупной промышленной компании. Используемый инструмент имитационного моделировании – Business Studio 4.2.
Заявки на вывод в ремонт оборудования подаются с целью предварительной проработки возможности вывода в ремонт, в т.ч. с учетом:
• режима работы оборудования;
• текущей схемы;
• ранее разрешенных заявок;
• совмещения работ различных подразделений на данном и смежном оборудовании.
Цель процесса – эффективное управление оборудованием за счет обоснованного, корректного и оперативного вывода в ремонт. Формально, результат процесса – это согласованная, утвержденная заявка, внесённая в сменное задание.
Автоматизация процесса практически отсутствует.
Цель анализа модели состояла в определении и обосновании путей оптимизации процесса путем расчета средней длительности (одного экземпляра процесса) и суммарных затрат на выполнение процесса за месяц. Результаты имитационного моделирования и анализа представлены ниже.
Исходная модель процесса для анализа «как есть» (80% заявок, поступающих в процесс, содержат ошибки).
Диаграмма процесса «как есть» представлена на рис.1. Участниками процесса являются:
• Инициатор подачи заявки.
• Оперативный персонал, в оперативном ведении у которого находится оборудование.
• Технический руководитель объекта.
• Оперативный персонал, в оперативном управлении у которого находится оборудование.
Стоимость рабочего времени указанных ресурсов была определена. Так, например, стоимость одного человека-часа инициатора подачи заявки составляет 212 рублей в час.
На рис. 2 показана интенсивность запуска процесса (нагрузка на процесс). В месяц поступает около 1200 оперативных заявок на обработку. Фактически, заявки могут готовиться в любое время, но процесс запускается только в период с 16 до 18-00 ежедневно. В другое время заявки просто не рассматриваются.
На схеме процесса показано время выполнения каждой операции. Например, для операции «Рассмотреть и согласовать заявку (совместимость)» сверху указано «Норм.Константа (0:05:00)». Это означает, что нормативное время выполнения данной операции составляет 5 минут. Там, где снизу операции написано «Ож.Константа…» это означает время ожидания выполнения из-за, например, отсутствия ресурса и проч.
Обратим внимание, что время выполнения первой операции процесса «Оформить оперативную заявку» не является константой. Около 64% всех заявок оформляется 5 минут. В 27% случаев необходимо собирать данные для заявки, а это занимает 15 минут. В 9% случаев сбор данных занимает 20 минут.
Такое дискретное распределение было выбрано, т.к. реальный закон распределения времени формирования заявок неизвестен, учета нет. Со слов экспертов по процессу «в 20-30% случаев заявка формируется 15-20 минут из-за необходимости сбора данных». Довольно неточное определение, к сожалению.
На схеме процесса (см. рис. 1) красным цветом показана вероятность перехода по соответствующим стрелкам после шлюзов. Так, например, переход по стрелке «да» после шлюза «Имеются критичные ошибки в заявке?» будет осуществляться с вероятностью 80% и т.п.
Имитация процесса проводилась для одного месяца – ноября 2018 г. По результатам имитации получены следующие данные:
• среднее время выполнения одного экземпляра процесса — 2 часа 40 минут;
• суммарная стоимость процесса за месяц – 128 тыс. рублей.
Анализ отчета по результатам имитации, сгенерированного Business Studio, показывает, что самая дорогая операция в рамках одного экземпляра процесса – это операция «Оформить оперативную заявку». Она стоит 32 рубля.
Измененная схема процесса — 10% заявок с ошибками.
В первом варианте модели 80% заявок поступают с ошибками. Это приводят к тому, что процесс практически сразу завершается неудовлетворительным результатом (отказом от обработки заявки), т.е. фактически работает вхолостую. Возможно, в действительности это не совсем так, но со слов участников всё выглядит именно таким образом.
Было принято решение выполнить имитацию для случая полной загрузки процесса — когда только 10% заявок имеют критические ошибки (требуется их переделка). Кстати, устранение ошибок при оформлении заявок – это первое необходимое действие по оптимизации процесса.
По результатам имитации для случая с 10% ошибочных заявок получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 день и 6 часов (!);
• суммарная стоимость процесса за месяц – 320 тыс. рублей.
Видно, что поскольку процесс работает «в полную силу», во время имитации периодически возникает очередь на обработку заявок. Иногда длинна этой очереди достигает 10 часов. Если бы все заявки были корректными и не отклонялись, реальный процесс сразу бы стал нежизнеспособным (сотрудники «разгребали» бы заявки почти целый рабочий день и более).
Оптимизация процесса
Итак, какие же проблемы можно отметить в результате имитации процесса. Прежде всего это:
• ошибки при формировании заявок и долгий (относительно) поиск данных для их заполнения;
• 47% операций процесса – это операции типа «Передать» или «Получить, которые не добавляют никакой ценности (ни с точки зрения инициатора, ни с точки зрения компании);
• практически полностью ручной труд, ручная передача информации, риск ошибок (человеческий фактор);
• ключевые операции процесса не автоматизированы (сбор данных и выполнение расчетов выполняются вручную);
• данные, необходимые для выполнения процесса, дезинтегрированы (находятся в разных базах данных и программных продуктах, на бумаге);
• внутри процесса возникают (неоправданные) задержки.
На рис. 4 визуально показаны некоторые предложения по оптимизации процесса путем автоматизации и устранения операций, не добавляющих ценность.
Полный список предложений следующий:
• заполнение заявок должно выполняться без ошибок и без ожидания данных (данные должны быть доступны в функциональной информационной системе);
• необходимо сокращение времени формирования заявок до 3 минут в 80% случаев;
• необходимо устранить операции типа «Передать» и «Получить»;
• необходима автоматизация самого процесса в системе класса BPM (Business Process Management);
• ряд операций необходимо сделать полностью автоматическими, например, «Сформировать/Внести заявку в сменное задание»;
• требуется создание единой базы данных в рамках функциональной ИС по управлению работой и обслуживанием оборудования;
• для всех операций необходимо сокращение времени выполнения операций за счет автоматизации.
С учетом сформулированных выше предложений по оптимизации была сформирована следующая схема процесса (см. рис. 5). Нас схеме показаны зеленые значки – ИС – функциональная информационная система, поддерживающая выполнение процесса. Оранжевые значки – BPMS, в которой реализован процесс. Значок человечка в левом верхнем углу операции означает, что она выполняется с использование экранных форм BPMS. Значок шестеренки означает, что операция выполняется полностью автоматически информационными системами.
По результатам имитации оптимизированного процесса получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 час 34 минуты;
• суммарная стоимость процесса за месяц – 106 тыс. рублей.
Кстати, после оптимизации процесса операция «Оформить оперативную заявку» перестала быть самой дорогой…
Выводы по результатам имитационного моделирования процесса
В следующей таблице показано сравнение двух вариантов: «нагруженного» корректными заявками процесса «как есть» и процесса после оптимизации.
Таблица. Сравнение процессов «как есть» и «как должно быть».
№ | Процесс | Средняя длительность одного экземпляра процесса | Стоимость процесса за год |
1 | Процесс «как есть» | 1 800 минут | 3,84 млн. рублей |
2 | Процесс «как должно быть» | 94 минуты | 1,27 млн. рублей |
Улучшение процесса | Сокращение длительности в 19 раз | Сокращение затрат на 67%, 2,57 млн. рублей |
Таким образом, потенциальный годовой эффект от оптимизации процесса «Рассмотрение и согласование оперативных заявок» может составит 2,57 млн. рублей.
Если предположить, что автоматизация этого процесса в BPMS (включая стоимость лицензий и настройку) одновременно с автоматизацией в функциональной информационной системе составит 300 тыс. рублей (процесс, в общем-то, простой), то эффективность такого проекта составит 856%. Даже если взять в расчет риски ошибок в расчетах и увеличения стоимости работ по проекту, эффект все равно может быть достаточно велик.
Однако, это эффект может остаться на бумаге в том случае, если не произойдет:
• увеличение объемов добычи при сохранении численности обслуживающих подразделений;
• сохранения объемов добычи при сокращении численности обслуживающих подразделений.
Речь идет от том, бумажный эффект может стать реальным в случае, если сотрудники будут использовать высвобожденное за счет оптимизации процесса время на выполнение другой полезной работы, либо высвобожденная численность сотрудников будет сокращена.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ю.А. Федосеев
Начальник отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»
А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»
Декабрь 2018 г.
Моделирование бизнес-процессов в нотации BPMN начинающими: типовые ошибки
Моделирование бизнес-процессов в нотации BPMN начинающими: типовые ошибки
В статье Владимира Репина рассмотрены типовые ошибки, которые допускают сотрудники организации, начинающие осваивать моделирование бизнес-процессов в среде Business Studio с использованием нотации BPMN. Обсуждается вопрос о возможности и целесообразности использования данной нотации для комплексного описания бизнес-процессов организации силами собственных сотрудников.
Введение
Задача «описания всех бизнес-процессов» компании многими специалистами рассматривается как нецелесообразная в силу того, что она крайне трудоемка и не дает очевидного практического результата в краткосрочной перспективе, например, явного прироста прибыли компании. Тем не менее, собственники и топ-менеджеры многих крупных компаний именно так ставят задачу: «описать все процессы». Причины такой постановки задачи различны: желание сделать «прозрачной» компанию, подготовиться к автоматизации, радикально снизить затраты, провести реинжиниринг и проч.
Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.
Методология комплексного описания процессов организации с использованием конкретного инструмента – это не просто описание нотации моделирования в части используемых значков. Это более сложный объект для разработки. Отмечу, что Методология в целом не является предметом этой статьи (будет рассмотрена позже). Методология комплексного описания процессов должна быть подробно описана в «Соглашении по моделированию» компании.
С человеческими ресурсами все тоже довольно сложно. Другими словами, их просто нет. Найти на рынке готового специалиста со знаниями методологии и инструмента, навыками моделирования в нотации BPMN, опытом в предметной области (например, сварка танков под вакуумом рентгеновским лазером) невозможно. Вывод один – массовое обучение и вовлечение в проект описания бизнес-процессов руководителей и специалистов подразделений.
В данной статье рассматриваются типовые ошибки, которые допускают сотрудники, впервые занявшиеся моделированием процессов вообще и, в частности, в нотации BPMN.
Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.
Исходные данные для анализа
Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25-30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio – это нотация «Процедура) или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.
Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В.В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.
Во второй день рассматривались более сложные примеры и выполнялось комплексное задание на описание группы связанных между собой процессов. Это задание выполнялось в небольших рабочих группах по 2-3 человека. После описания процессов группы выполняли анализ качества моделей на основе чек-листа. Проводился разбор ошибок.
Далее сотрудники, прошедшие обучение, включались во временные рабочие группы по описанию процессов. ВРГ разрабатывали графические схемы процессов. Выполнялся анализ качества этих схем и разбор ошибок (дистанционно или на рабочих сессиях).
Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.
Несмотря на проведенное обучение, разбор ошибок и наличие «Соглашения по моделированию», по ходу практической работы сотрудники допускали ряд ошибок, что вполне нормально для людей, делающих что-то в первый раз.
Многие из выявленных ошибок являются типичными, т.е. повторяются от модели к модели. Причем ряд этих ошибок можно назвать содержательными, т.е. они не связаны с нотацией BPMN, как таковой. Нужно хорошо знать предметную область и саму методологию моделирования (не рисование одной схемы, а именно комплексное моделирование системы процессов компании), чтобы не допускать такие ошибки.
Ряд ошибок возникает из-за произвольного, интуитивного использования (трактования) значков нотации BPMN, что приводит к серьезному искажению смысла моделей. Ниже подробно рассмотрены ошибки, допускаемые новичками в моделировании процессов.
Типовые ошибки моделирования, допускаемы начинающими
Проблема мышки
Первая и, вероятно, самая главная проблема при моделировании процессов в нотации BPMN начинающими – это проблема «Мышки» (я использую этот термина на обучении вместо токена). Для многих сотрудников понимание сути потока работ и мышки, которая бегает от одной операции процесса к другой по стрелкам типа sequence flow, является довольно сложным. Но если не концентрировать внимание на потоке и не отслеживать мысленно различные пути мышки, то можно упустить из вида многие детали реального процесса. Модель в этом случае становится весьма неточной. В ней упускается множество практически важных моментов. В результате, схема вроде как нарисована, но ни выполнить ее анализ, ни обосновать изменения нельзя. Это одна из причин разочарования некоторых руководителей в графических схемах бизнес-процессов как в практическом инструменте развития бизнеса.
Оборванные входы-выходы
Следующая проблема – это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.
Как правило, это означает, что сотрудники не изучили процесс в достаточной степени и не могут сказать, какие документы/информация нужны для выполнения операций, откуда они берутся и куда передаются.
Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.
Второй аспект содержательный. Довольно часто сотрудники показывают выход в другой процесс, но на графической схеме этого процесса нет соответствующего входа. Если подняться на уровень выше – на диаграмму в нотации IDEF0, там тоже нет соответствующих стрелок.
Бывает обратная ситуация – на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие – низкое качество модели компании в целом.
Вообще говоря, модель процесса в BPMN в первую очередь должна показывать поток операций, последовательно выполняемых по определенной логике. Но отображение документов (информации, баз данных, модулей информационных систем) на схеме является практически важным. Во-первых, это заставляет сотрудников продумать каждый шаг и выявить необходимую для выполнения работы информацию и документы. Определить, в чем заключается результат каждой операции, куда и в какой форме он передается. Тоже самое касается и процессов. Между ними тоже должна быть выполнена «стыковка по входам/выходам».
На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.
На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.
Некорректная логика процесса
Вторая проблема – это довольно легкомысленное отношение к логике процесса, что ведет к появлению логических ошибок на схеме. Процесс нарисован, но работать (исполняться) не будет — остановится на какой-то операции и дальше не пойдет. Хотя на обучении подробно рассматриваются примеры логических ошибок (некорректное применение шлюзов, например), на практике сотрудники их довольно часто допускают. На первых порах необходим постоянный контроль схем со стороны опытного бизнес-аналитика или методолога проекта.
Непонимание межпроцессного взаимодействия
Моделирование межпроцессного взаимодействия при помощи отправки-получения сообщений является наиболее сложным аспектом для начинающих.
Во-первых, многие интерпретируют маркер в виде конверта как некоторый документ, отправляемый от одной операции процесса к другой. Это понимание на основе бытового здравого смысла приводит к некорректному использованию событий отправки сообщения между операциями одного процесса, без отправки в другой процесс. Некоторые искренне удивляются, почему это ошибка – «ведь результат работы (конверт) отправлен из одной операции в другую?!».
Вторая проблема состоит в том, что отправку сообщений между разными процессами начинают показывать везде, где только можно, причем без всякого содержательного смысла:
• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) – с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное – через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 – отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.
Понятно, что при дальнейшем использовании моделей для автоматизации в конкретной BPMS нужно будет уточнять ситуации, возникающие при отправке-получении сообщений. Но для проекта комплексного моделирования процессов очень важно, чтобы сотрудники понимали, для чего, как и когда они «запускают» на выполнение другие процессы, как синхронизируют свой процесс с ними.
Использование таймеров
Событие-таймер используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку события-таймера: «Не позднее 2-го числа месяца». Когда должен сработать таймер – непонятно. Другой пример – «Ежедневно» (см. рис. 4).
Так же, часто используют граничные события-таймеры, в названии которых указывают нормативную длительность выполнения процесса. Но при этом данный таймер не прерывает выполнение операции и не передает управление на другую операцию процесса.
Описание процесса для одного объекта, которых в реальности множество
Начинающим рисовальщикам процессов довольно тяжело осознать эту проблему. Она состоит в описании процесса для одного объекта обработки, которых на самом деле несколько (счета, заявки и т.п.). Необходимость работы с ними возникает в разное время. Перед обработкой нужно выяснить сколько документов нужно обработать, в каком порядке и т.д. Таким образом, довольно существенный кусок работы, от понимания которого зависит качество модели, остается «за кадром».
Процесс в процессе (рекурсия)
Довольно часто можно наблюдать такую картину. Берем для анализа процесс под каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс! Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные, сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.
Красота схемы
Здесь все печально. Только 10-15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы – залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.
Накопление опыта и исправление ошибок
По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2-3 модели процессов в неделю), через 1-1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.
Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.
Выводы
При использовании минимального набора объектов и маркеров, нотация BPMN вполне доступна для изучения сотрудниками, не имеющими опыта графического описания бизнес-процессов.
Очень важно провести базовое обучение, акцентирующее внимание на важнейших правилах и типовых ошибках использования нотации BPMN для описания процессов. В первую очередь важно обратить внимание на следующее:
- «мышка» или идеология исполняемых процессов;
- информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
- корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
- соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
- корректное использование событий-таймеров;
- четкое отслеживание множественных объектов для обработки;
- визуальная наглядность схемы («Красота схемы»).
Ошибки, неизбежно возникающие при описании процессов начинающими, нужно своевременно выявлять. По ходу проекта очень важен постоянный методический контроль работы временных рабочих групп. Несмотря на большое количество ошибок, допускаемых сотрудниками на первом этапе, в дальнейшем качество моделей улучшается. Это возможно при постоянном методическом контроле и помощи со стороны Процессного офиса компании.
Критически важно иметь в организации хорошо проработанное Соглашение по моделированию, в котором представлены все требования, необходимые для комплексного описания большого количества процессов на разных уровнях иерархии.
Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ – так же критически важные аспекты моделирования бизнес-процессов.
В целом, с учетом опыта выполненных проектов, можно сделать вывод, что комплексное описание бизнес-процессов силами собственных сотрудников организации в нотации BPMN в среде Business Studio возможно и практически целесообразно.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Сентябрь 2018 г.
Добавить комментарий Отменить ответ
Деловая игра на основе имитации процесса в Business Studio
Деловая игра на основе имитации процесса в Business Studio
В статье Владимира Репина описана деловая игра по оптимизации бизнес-процесса, основанная на использовании имитационной модели, созданной в среде Business Studio. Цели игры – анализ процесса, поиск узких мест и «муды» (потерь), разработка предложений по оптимизации процесса. Рабочие группы анализируют процесс и предлагают ряд мероприятий по его оптимизации. Выполняется экспертная оценка предложений, отбираются практические реализуемые. Затем процессы перепроектируются в Business Studio с учетом обоснованных изменений. Проводится имитационное моделирование. Различные варианты моделей сравниваются между собой на основе показателей длительности выполнения и стоимости результата процесса. Игра может использоваться при проведении базового курса обучения процессному управлению в компаниях, в программах MBA и проч.
Введение
Цели деловой игры, предлагаемой вниманию читателя, следующие:
- получение навыков анализа процесса (технология выполнения, время выполнения, узкие места, потери) при помощи его графической схемы;
- наглядная демонстрация понятий «экземпляр» процесса, «нагрузка» на процесс, вариабельность процесса;
- наглядная демонстрация влияния технологии выполнения процесса на длительность его выполнения и стоимость полученного результата;
- понимание того факта, что уровень развития корпоративной культуры (и еще тип организации, степень ее процессной зрелости) ограничивают возможности реорганизации процессов с целью повышения их эффективности.
Игра может проводиться в рамках программы обучения методам процессного управления сотрудников компании наряду с другими практическими заданиями (например, игра «За и против регламентации бизнес-процессов», задание по определению границ процесса и т.п.).
Сценарий игры
Организация
На группу участников (4-8 человек) распечатывается цветная схема процесса в формате А2.
Дополнительно распечатывается форма перечня предложений по оптимизации (2 листа на каждую группу, всего 6 листов).
Все участники делятся на 3 группы:
- Команда «А» (выбирает себе название).
- Команда «Б» (выбирает себе название).
- Команда экспертов (желательно включить в нее несколько топ-менеджеров).
Объявляются цели и правила игры. Цель игры – достижение лучших показателей за счет оптимизации бизнес-процесса. Используется два показателя: 1) длительность выполнения процесса; 2) стоимость результата процесса (в данном примере – это коммерческое предложение).
Демонстрация модели
Проводится демонстрация имитационной модели бизнес-процесса (с анимацией хода процесса в Business Studio).
Обсуждаются результаты имитации.
Обсуждаются целевые показатели процесса: 1) длительность выполнения; 2) стоимость результата процесса; 3) качество (количество ошибок и т.п.).
На рис. 1 представлена исходная схема процесса «Формирование КП клиенту». КП – коммерческое предложение. Речь идет о торгово-производственной компании B2B, которая выпускает стандартный ассортимент, но может по требованию заказчиков вносить конструктивные изменения в модели изделий, использовать другие материалы, цвета и т.п.
В процессе участвуют несколько сотрудников:
• Менеджер, ответственный за формирование КП клиенту (2 шт.);
• Начальник отдела продаж (1 шт.);
• Начальник Инженерно-технического отдела (1 шт.);
• Инженер Инженерно-технического отдела (1 шт.);
• Начальник ФЭО (1 шт.);
• Экономист ФЭО, ответственный за расчет стоимости изделия для КП (1 шт.);
• Коммерческий директор (1 шт.).
Каждая операция процесса имеет определенную длительность. Некоторые операции начинаются не сразу, а с задержкой. Это сделано для того, чтобы учесть факт загрузки руководителей в других процессах (которые не используются при имитации), что ведет к невозможности сразу приступить к выполнению операции. Время выполнения показано над операцией (Раб.Константа…). Задержка перед выполнением (если она есть) – под операцией процесса (Ож.Константа).
Процесс выполняется руководителями и специалистами. Практически после каждой операции процесса указаны шлюзы типа «Исключающее ИЛИ». Процесс ветвится – потоки работы разделяются с учетом вероятности. Например, после операции «Проверить расчет параметров изделия» в 20% случаев нужно переделать расчет, т.к. он содержит неточности (ошибки). Вероятности перехода показаны на схеме визуально в процентах красным шрифтом (это сделано вручную – в Business Studio нет возможности визуализировать вероятность перехода на схеме).
Стоимость рабочего времени участников процесса задана в модели. Менеджер получает 150 рублей в час, Начальник отдела продаж – 200 рублей в час и т.п. Другие показатели затрат (например, амортизация оборудования или затраты на аренду офиса) не заданы, т.к. не влияют на результаты игры.
Нагрузка на процесс задана в параметрах стартового события — всего в месяц может запускаться 21 экземпляр процесса (т.е. должно быть подготовлено двадцать одно коммерческое предложение). Данное количество выбрано постоянным, чтобы обеспечить одинаковые исходные условия для всех групп, участвующих в игре.
На рис. 2 показан фрагмент пошаговой имитации процесса в Business Studio. Пошаговая имитация используется для демонстрации понятия потока работ (Work Flow) и понятия «экземпляр» процесса.
После пошаговой имитации, запускается имитация на интервале 1 календарный месяц.
По итогам одной из имитаций процесса получены следующие значения его показателей (они варьируются для разных имитаций, но это не критично для целей проведения игры):
- средняя длительность процесса формирования коммерческого предложения – 9 дней 5 часов 24 минуты;
- средняя стоимость подготовки коммерческого предложения — 3203,18 рублей.
Очевидно, что при такой длительности клиент просто может не дождаться подготовки запрашиваемого коммерческого предложения.
Анализ процесса и формулирование предложений
Все команды (включая команду экспертов) анализируют процесс и заполняют форму перечня предложений. Во время анализа можно рисовать фломастерами на схеме А2, делать пометки, записи и проч.
Каждое предложение по изменению процесса должно быть обосновано, т.е. должна быть аргументирована возможность его практической реализации, определены необходимые условия, ресурсы и методы, оценены риски. Если предложения касаются автоматизации, то желательно оценить возможный бюджет и сделать оценку «затраты/эффективность».
Оценка предложений
Команда экспертов получает от других команд и оценивает предложения по оптимизации процессов с точки зрения практической реализуемости. Например, полное устранение из процесса руководителей и выполняемых ими операций промежуточного контроля невозможно для организации с жесткой функционально-иерархической структурой и репрессивным стилем менеджмента.
Одновременно другие команды готовятся к «защите» своих предложений, выбирая ярких докладчиков и готовя наглядные пособия (цветные плакаты типа «Ударим бизнес-процессами по низкой эффективности и разгильдяйству»).
Защита предложений
Команды представляют свои предложения по оптимизации процесса (3-5 минут).
Представили команды экспертов дают аргументированную оценку предложениям.
Затем группы могут потратить некоторое время на дискуссию.
Ведущий игры расставляет необходимые акценты, выполняя модерацию по ходу игры.
По результатам обсуждения команда экспертов оставляет только те предложения по изменению процессов, которые, по их мнению, могут быть практически реализованы.
Изменение модели процесса и выполнение имитации
Ведущим игры вносятся изменения в модели процессов. Это, кстати, хорошая возможность ознакомить участников с методами описания процессов в среде Business Studio.
Проводится имитация измененных моделей бизнес-процессов.
Определяются показатели процессов Команды «А» и Команды «Б».
Определяется победитель. Совместно обсуждаются итоги игры.
Примеры результатов выполнения игры
Приведу пример результатов изменения процесса двумя группами, участвовавшими в игре.
Одну группу можно условно назвать «Сдержанной», а другую «Радикальной».
Предложения «Сдержанной» группы по изменению процесса вполне реализуемы в жесткой командно-административной структуре без заметных материальных затрат. Они предложили использовать формализованную заявку, убрать операции постановки задачи специалистам, убрать операцию подписания КП Коммерческим директором.
По результатам имитации оптимизированного процесса получены следующие данные:
- средняя длительность процесса формирования коммерческого предложения – 2 дня 12 часов 48 минут;
- средняя стоимость подготовки коммерческого предложения — 1361,25 рублей.
Видно, что достигнуто заметное улучшение показателей бизнес-процесса, причем за счет довольно простых изменений.
Предложения «Радикальной» группы могут быть реализованы, пожалуй, только в случае перехода на «бирюзовые» методы организации бизнеса и при тотальной автоматизации процесса, которая стоит заметных денег. Кроме того, компания должна быть достаточно проактивной, т.е. не пытаться подстроиться под всех клиентов, а выпускать только стандартный продукт (в данном случае я не хотел бы обсуждать корректность или некорректность этих тезисов – они были предложены группой).
Схема процесса, полученная после «внедрения» изменений, предложенных «Радикальной» группой, представлена на рис. 4.
По результатам имитации этого процесса получены следующие данные:
- средняя длительность процесса формирования коммерческого предложения – 38 минут;
- средняя стоимость подготовки коммерческого предложения — 47,98 рублей.
Таким образом, достигнуты следующие изменения после «оптимизации» процесса «Формирование КП клиенту»:
- по длительности процесс улучшен в 350 раз;
- по стоимости подготовки КП процесс улучшен в 67 раз.
Выводы
Вниманию читателя представлен сценарий деловой игры и примеры моделей процессов, полученные при ее проведении.
С использованием Business Studio можно создавать и использовать для учебных целей любые сложные модели сквозных процессов.
Очень важно, что по итогам проведения игры у ее участников появляются желание и базовые практические навыки, необходимые для описания, анализа и оптимизации процессов организации.
Кстати, при желании, можно организовать и провести такую деловую игру в вашей компании. Ее длительность около 4 часов. Буду рад сотрудничеству.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Апрель 2018 г.
Добавить комментарий Отменить ответ
Тотальное описание бизнес-процессов компании: «за» и «против»
Тотальное описание бизнес-процессов компании: «за» и «против»
В статье Владимира Репина рассматривается проблематика тотального описания бизнес-процессов компании с целью анализа загрузки исполнителей и сокращения их численности. Приводится методика анализа загрузки исполнителей в процессах. Обсуждаются «плюсы» и «минусы» такого подхода. Приводится экономическое обоснование проекта.
Введение
Тотальным описанием бизнес-процессов компании будем называть проект, в рамках которого выполняется четыре основных шага:
• описание ВСЕХ процессов компании «как есть»;
• анализ процессов, в т.ч. загрузки исполнителей;
• описание ВСЕХ процессов компании «как должно быть»;
• внедрение изменений, в т.ч. трансформация организационной структуры и сокращение численности штата.
Для понимания масштаба такого тотального описания приведу пример. Компания численностью 2 тыс. человек. Общее количество процессов операционного уровня, которое необходимо описать, — около 1000. Это означает, что мы должны разработать тысячу схем формата А4 (8-15 шагов на каждой) для того, чтобы все действия (операции), выполняемые сотрудниками, попали в модель. Дальнейший анализ загрузки исполнителей позволит решить задачу оптимизации численности и исключения ненужных должностей из орг. структуры компании.
Можно ли сократить численность сотрудников без тотального описания процессов? Да, можно. Многие так и делают. Часто просто дают руководителям отделов плановый % сокращения. Но я этот случай не рассматриваю. Если руководству компании нужно четкое и понятное обоснование, то без понимания реально выполняемых процессов не обойдешься. Некоторые гос. компании, накаченные бюджетными деньгами, сначала активно увеличивают штат. Потом, через некоторое время, менеджмент спохватывается, но уволить просто так никого нельзя – все уже при деле, а начальники отделов просят еще людей. Чем больше в твоем отделе (управлении) людей, тем более уважаемый ты человек. Впрочем, для крупных частных компаний это тоже вполне типичная картина.
Мой личный опыт участия в некоторых проектах «тотального» описания процессов и примеры компаний, которые мне известны, говорят о недостаточной результативности такого подхода. Проблема состоит в следующем. Этап описания процессов «как есть» длится очень долго (от 6 месяцев и более). На выходе команда проекта получает толстые тома схем, с которыми дальше сложно работать. Потом делается попытка выполнить анализ процессов и обоснование необходимых изменений. Потом еще много месяцев рисуют модели «как должно быть». За это время процессы уже успевают поменяться… Считаю более правильным подход, когда сначала создается процессная архитектура бизнеса, а затем выполняется работа по описанию, анализу и оптимизации процессов, причем последовательно – начиная с наиболее важных к менее важным процессам. По каждому процессу должен быть достигнут практический эффект от оптимизации.
Но если все-таки без тотального описания бизнес-процессов не обойтись? Как быть в этом случае? В следующем разделе представлен методический подход к выполнению такого проекта.
Возможный методический подход
Для тотального описания бизнес-процессов компании необходимо:
- убедить команду топ-менеджеров в необходимости изменений и найти лидеров;
- разработать архитектуру процессов компании;
- установить и настроить систему бизнес-моделирования;
- создать необходимые компетенции у команды проекта;
- разработать методики (описания и анализа процессов, в т.ч. загрузки исполнителей);
- выполнить описание, анализ и оптимизацию процессов, в т.ч. разработку моделей «как должно быть», анализ загрузки исполнителей, расчет изменения численности сотрудников и исключения ненужных должностей;
- разработать перспективную организационную структуру и штатное расписание;
- выполнить организационные изменения, в т.ч. орг. структуры и штатного расписания.
Создание и убеждение команды топ-менеджеров и поиск лидера (лидеров) проекта – задача во многом «политическая» и в данной статье не обсуждается.
Для разработки архитектуры процессов нужна команда экспертов, члены которой смогут по-новому взглянуть на бизнес компании и построить модель на основе видения перспективных цепочек создания ценности или, говоря шире, — перспективной бизнес-модели. При этом акцент должен делаться на сквозные процессы и эффективность управления инвестируемым капиталом собственников по всей цепочке процессов, по всему жизненному циклу продуктов компании. Наличие адекватной архитектуры процессов – это залог успешного выполнения проекта тотального описания процессов. Запутанная, сложная архитектура или архитектура, имеющая мало общего с реальностью, приведут к построению рыхлой и запутанной процессной модели бизнеса.
Создание компетенций у команды проекта. Прежде чем решать этот вопрос, нужно найти людей в эту команду. Кто может в нее войти? Можно попытаться провести кастинг среди крупных консалтинговых компаний, но вряд ли даже крупные компании способны выставить 20-30 специалистов «фулл-тайм» на много месяцев проекта. Если даже смогут, то цена будет космическая. Выхода два – набирать новых людей в штат, либо учить своих.
Увеличение численности штата на старте проекта, целью которого является его сокращение, не вдохновляет руководство. Поэтому остается вариант искать ресурсы внутри. Но здесь тоже проблема – либо в проект отдают заведомо лишних, ненужных людей, либо вообще отказываются отдавать кого-либо из боязни прослыть неэффективным руководителем, у которого «люди не загружены работой». Как быть в такой ситуации? Возможны разные варианты. Собственник бизнеса может выделить в проект людей своим волевым решением. В гос. компании можно сформировать команду проекта из руководителей отделов, включенных в кадровый резерв. Практика описания и анализа процессов будет им исключительно полезна. Когда они будут включены в команду, то сами смогут найти у себя в отделах толковых исполнителей – будущих «писателей процессов». Еще один способ – использование практикантов, студентов, закрепленных за отдельными подразделениями. Но это не лучший вариант.
МОЖНО СФОРМИРОВАТЬ КОМАНДУ ПРОЕКТА ИЗ РУКОВОДИТЕЛЕЙ ОТДЕЛОВ, ВКЛЮЧЕННЫХ В КАДРОВЫЙ РЕЗЕРВ. ПРАКТИКА ОПИСАНИЯ И АНАЛИЗА ПРОЦЕССОВ БУДЕТ ИМ ИСКЛЮЧИТЕЛЬНО ПОЛЕЗНА.
Методическое обеспечение проекта является очень важным. Нужно разработать методики описания и анализа процессов, в том числе в части загрузки исполнителей. Поскольку анализ и оптимизация загрузки исполнителей является ключевой целью проекта, то методику анализа в этой области целесообразно проработать подробно. Необходимо будет выполнить анализ существующих нормативов, планового и фактического времени выполнения операций, количества запусков каждого процесса и определить загрузку сотрудников, выполнив математический расчет. В идеальном случае, можно использовать имитационные модели процессов, но их подготовка сама по себе весьма трудоемка.
Для выполнения задачи описания процессов создаются небольшие рабочие группы (РГ) по 2-3 человека + эксперты (начальники подразделений). Внешние консультанты могут осуществлять методическое сопровождение, координацию и контроль качества описания процессов (в т.ч. на основе чек-листов). Еженедельно РГ отчитываются о проделанной работе – представляют схемы процессов, результаты анализа процессов, предложения по улучшению.
На этапе описания процессов целесообразно использовать подход, объединяющий разработку моделей «как есть» и «как должно быть» в единую группу работ, которая выполняется РГ в течение короткого периода времени (несколько недель):
• формируются модели процессов «как есть», выполняется фиксация текущего состояния процессов (количество запусков, время выполнения, перечень проблем);
• выполняется анализ проблем и выявление их причин;
• выполняется анализ и разработка/корректировка норм трудоемкости выполнения операций процесса;
• разрабатываются и обсуждаются предложения по оптимизации процессов;
• формируются схемы оптимизированных процессов («как должно быть»).
По ходу описания и анализа очень важно активно вовлекать руководителей в процесс поиска возможных улучшений. Целесообразно привлечь в команду специалистов по бережливому производству, ТРИЗ и, что особенно важно в наше время, по автоматизации в 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, т.е. 4 человека. Допустим, фактически занимают должность – 10 человек. С учетом норматива численности, потенциально можно сократить 5 человек.
Шаг 5. Анализ персональных данных сотрудника.
Выявляются исключительные компетенции каждого сотрудника, которые важны для компании. Сотрудник, обладающий исключительными компетенциями, не может быть просто так уволен. Кроме компетенций в расчет принимаются: формальная квалификация, опыт работы, возраст, состояние здоровья, личные качества. Например, можно выполнить анализ личных качеств в соответствии с профилем, требуемым компанией: инновационность, коммуникабельность, способность работать в команде, исполнительность и проч. В зависимости от типа должности и специализации состав критериев и веса могут меняться. В результате выполняется расчет рейтинга сотрудника. Если в компании внедрена система грейдов, то набор критериев для оценки должностей уже есть. В противном случае его придется создавать. Для получения оценки должностей в полуавтоматическом режиме стоит разработать систему, похожую на «Скоринг» в банках.
Шаг 6. Анализ возможности сокращения сотрудников.
Выполняется рейтинговая оценка сотрудников, занимающих одну должность. Делается вывод в возможности сокращения сотрудников. Результаты фиксируются в базе данных и включаются в отчет.
Шаг 7. Анализ возможности исключения должности.
В случае, если должность занимает один сотрудник и его загрузка в процессах недостаточная (например, менее 50%), то рассматривается возможность исключения должности из орг. структуры компании. При этом определяются должности, на которые может быть перераспределена нагрузка сотрудника в процессах.
ТОТАЛЬНОЕ ОПИСАНИЕ ПРОЦЕССОВ ПОЗВОЛЯЕТ НЕ ТОЛЬКО ВЫЯВИТЬ «ЛИШНИХ ЛЮДЕЙ», НО И ПЕРЕРАСПРЕДЕЛИТЬ ЗАДАЧИ ТАК, ЧТОБЫ ОНИ НЕ «ПОВИСЛИ» ПРИ УВОЛЬНЕНИИ СОТРУДНИКОВ.
Вообще говоря, для оптимизации организационной структуры совершенно не обязательно выполнять тотальное описание процессов. Если у Генерального директора 28 заместителей, два из которых управляют 80% ресурсов компании, то очевидно, что организационная структура не является сбалансированной, оптимальной. В этом случае можно разработать перспективную структуру (на уровне 1-3 уровней управления) только на основе анализа перспективной бизнес-модели компании. Однако, в дальнейшем при реорганизации придется нарушить устоявшуюся иерархическую структуру властных полномочий, что будут весьма рискованно как для спонсора, так и для команды проекта. При тотальном описании и анализе бизнес-процессов можно обосновать изменение структуры более мягко, на более длительном временном интервале, что делает задачу реорганизации структуры менее рискованной.
План оптимизации орг. структуры должен четко описывать этапы исключения (перераспределения) должностей и подразделений в привязке к календарю, необходимые мероприятия по разъяснительной работе, поиску рабочих мест для увольняемых сотрудников, обучению и аттестации и проч. Степень жесткости при сокращении персонала определяется корпоративной культурой и ситуацией, в которых находится компания. Для компании, близкой к банкротству это делать нужно быстро и жестко.
Далее возникает проблема внедрения изменений. Очевидно, что одновременно управлять изменениями всех процессов невозможно. Поэтому после определения оптимальной численности сотрудников и оптимальной организационной структуры нужно приступить к сокращению персонала, а руководителям подразделений дать в руки схемы процессов «как должно быть» и объявить принцип: «Мы обоснованно сократили численность и сформировали модели «как должно быть» — работу по процессам дальше организуйте сами». При этом, конечно, должны быть KPI (в т.ч. результат, затраты, время, качество), от которых существенно зависит премия руководителей. Безусловно, на данном этапе очень важно управлять настроениями сотрудников, обеспечивать максимальную степень коммуникаций и поддерживать лидерство.
Экономическое обоснование проекта тотального описания бизнес-процессов
Сделаем простой расчет – экономическое обоснование описания процессов для указанного в начале статьи случая – 2000 человек персонала и 1000 операционных процессов в компании.
Предположим, что средняя зарплата (с учетом налогов и взносов) – 30 тыс. рублей в месяц. Общий ФОТ составит 720 млн. рублей в год.
Трудоемкость описания 1000 процессов из расчета 40-а человеко-часов на 1 процесс – 40 тыс. часов (норматив, выработанный длительной практикой консалтинга по описанию и анализу бизнес-процессов). К этому времени добавим по 4 часа на анализ загрузки каждого исполнителя (с учетом использования полуавтоматизированной системы «скоринга»). В итоге получится трудоемкость проекта – 48 тыс. человеко-часов. Чтобы выполнить проект за год потребуется 25 экспертов. Предположим, что зарплата экспертов – 60 тыс. в месяц. Общий ФОТ на проект – 18 млн. рублей в год.
В случае, если по итогам проекта удается сократить только 10% численности персонала эффект составит 72 млн. рублей. Эффективность проекта будет равной 400%.
Выводы
Подводя итоги, сравним «плюсы» и «минусы» проекта тотального описания бизнес-процессов с целью сокращения численности персонала.
К «Плюсам» можно отнести:
• значительный экономический эффект для бизнеса;
• встряска персонала компании и подготовка к необходимым изменениям (в т.ч. инновационным);
• сокращение численности и трансформация орг. структуры, основанная на результатах анализа процессов и четкой методике расчета;
• процессная архитектура и процессная модель компании, которая в дальнейшем используется для оптимизации, стандартизации и автоматизации процессов;
• развитие культуры процессного управления.
«Минусы» (риски) проекта:
• высокая сложность и заметная длительность (от 1 года и более);
• сопротивление руководящего состава и сотрудников;
• риск получения погрешности расчетов из-за использования средних величин (средняя частота операций, средняя длительность операций и т.п.);
• отсутствие достоверных данных и адекватных нормативов.
В целом, в случае поддержки проекта командой топ-менеджеров и наличия среди них лидеров изменений, «плюсы» существенно перевешивают «минусы». Проект сложный и довольно дорогой, но для крупных компаний, перед которыми стоит задача выжить, он может дать существенный эффект.
В.В. Репин, к.т.н., доцент, консультант по управлению.
Август 2017 г., Москва
Добавить комментарий Отменить ответ
Анализ графической схемы процесса
Анализ графической схемы процесса
В статье Владимира Репина графическая схема рассматривается как инструмент анализа процесса. Приводятся условия, необходимые для создания качественной схемы процесса. Осуждается метод верификации схемы при помощи чек-листа. Предлагаются возможные направления содержательного анализа схемы процесса. Материал статьи может быть полезен руководителям и специалистам, занятым в области организационного развития компаний.
Введение
По данным статистики 65% компаний занимаются описанием бизнес-процессов, из них в 41% компаний используют специальное программное обеспечение типа Business Studio. (The State of Business Process Management 2016, Paul Harmon, www.bptrends.com). Результатом описания процессов являются графические схемы, выполненные в различных нотациях. Схемы могут быть либо простые и читаемые, либо сложные и запутанные. Но в любом случае, это некоторый упорядоченный по определенным принципам набор шагов, который позволяет визуально представить себе, как выполняется процесс.
Схемы используются для различных целей: анализа процессов, реорганизации, подготовки к автоматизации, документирования (создания регламентов), управления рисками, внедрения методов бережливого производства, обучения сотрудников и проч.
В данной статье я рассматриваю вопросы использования графических схем для выполнения анализа процесса с целью его дальнейшей трансформации, реорганизации, оптимизации, совершенствования. Эти действия по изменению процесса можно называть по разному, но цель всегда одна – изменение характеристик процесса для обеспечения соответствия возможностей процесса стратегии развития компании, повышения его производительности, сокращения сроков выполнения, роста эффективности. В современной ситуации можно добавить еще готовность процесса к внедрению инновационных технологий (цифровизация, интернет вещей, big data и т.п.).
ПЕРВЫЙ ШАГ К ОПТИМИЗАЦИИ ПРОЦЕССА – ЭТО ПОНИМАНИЕ ПРОЦЕССА
Умение создавать корректные графические схемы процессов и выполнять их анализ является ключевой компетенций специалистов по организационному развитию. И не только их, а и любого менеджера, которые хочет активно использовать современный инструмент управления под названием Business Process Management.
Возможности и ограничения анализа графической схемы процесса
Графические схемы можно условно разбить на две больших группы: схемы процессов верхнего уровня и схемы операционных процессов.
На схемах верхнего уровня представляют процессные категории и процессные группы. Как правило, для описания используют нотации структурного типа (например, IDEF0). С их помощью легко показать, из каких частей состоят процессы и описать основные связи между ними (физические и материальные потоки). Но схемы этого типа не показывают потоки работ.
Схемы операционных процессов создают при помощи нотаций совершенного другого типа – Work Flow (eEPC, CFFC, BPMN, «Процедура» Business Studio). Базовый принцип создания таких схем – описание цепочки выполнения операций процесса в хронологическом порядке (строго одна за другой).
В зависимости от типа, графические схемы процессов можно использовать для выполнения следующих видов аналитической работы:
Верхний уровень (структурная модель):
• архитектура процессов компании;
• бенчмаркинг архитектуры процессов компании с процессными фреймворками (например, APQC, SCOR, eTOM, ITIL и проч.);
• взаимодействие (стыковка по входам/выходам);
• зоны ответственности топ-менеджеров (определение владельцев и менеджеров процессов);
• привязка целей и показателей;
• визуализация проблемных зон.
Операционный уровень (модель Work Flow):
• анализ технологии выполнения процесса (дублирование, узкие места, возвраты и проч.);
• value-анализ;
• анализ потерь;
• анализ времени выполнения;
• анализ рисков;
• имитационное моделирование (графическая схема – основа для создания имитационной модели).
Какую информацию невозможно получить путем анализа графической схемы? Очевидно, что это различного рода расчеты и анализ большого массива данных, связанных с выполнением процесса или других процессов, на который данный процесс оказывает влияние. Так же графическая схема не нужна для анализа Парето или Исикавы, проведения SWOT-анализа процесса и других подобных методов анализа. Другим словами, если вы хотите провести анализ проблем, связанных с выполнением процесса, или оценить процесс в целом по ряду параметров, то совершенно не обязательно начинать с формирования графической схемы. Но если речь идет о детальном анализе с учетом технологии выполнения процесса, то схема может стать очень полезным инструментом.
Качество и верификация графической схемы процессы
Практика показывает, что качество графической схемы, ее адекватность реальному процессу является ключевым фактором успеха использования схемы для целей анализа процесса. На рис. 1. показан примеры некорректной схемы процесса. Сложная схема вверху рисунка – это процесс работы с дебиторской задолженностью, разработанный недостаточно опытным бизнес-аналитиком (красным показаны замечания к схеме). Ниже справа показан фрагмент схемы. Внизу слева – фрагмент схемы другого процесса, разработанной сотрудниками, неискушенными в моделировании процессов.
Процесс, представленный на рис. 1., чрезмерно усложнен, причем без реальной необходимости. Сложность этой схемы – результат отсутствия опыта моделирования и желания глубоко разобраться с реально выполняемым процессом. Можно ли предоставлять такую схему на согласование бизнес-заказчику? На мой взгляд, нет. Нужно ее существенно упростить, сделать читаемой. При этом может потребоваться перейти на следующий уровень декомпозиции. Это нормально. Зато со схемой можно будет работать.
Другой пример – рис. 2. Эта схема сделана на грани профанации. К сожалению, такого рода схемы до сих продолжают встречаться в компаниях, даже в крупных, у которых достаточно средств на создание нормальной системы работы в этой области.
Чем же определяется качество графических схем? Можно отметить следующие аспекты:
• наличие в компании «Соглашения по моделированию»;
• знания, навыки и опыт у «проектировщиков процессов» (бизнес-аналитиков, сотрудников, ответственных за описание процессов);
• система контроля;
• возможность групповой работы над схемой (моделирующие сессии, обсуждение схемы на внутреннем web-портале, «защита» схемы и т.п.).
«Соглашение по моделированию» определяет требования к использованию конкретных нотаций для описания процессов, требования к наименованиям, кодификации и т.п. Кроме того, в него может быть включен чек-лист контроля качества процессов (об этом чуть ниже). Наличие «Соглашения» является необходимым, но не достаточным условием создания качественных моделей процессов.
Очень важно подобрать и обучить специалистов, сформировать у них навыки сбора информации и описания процессов. Правильный путь – это проведение обучения практикой с последующим выполнением 2-3 учебно-практических заданий под контролем опытного эксперта. Далее нужно будет внедрить систему контроля качества графических схем, например на основе чек-листа. Еще одним важным аспектом является возможность групповой работы над схемами процессов – в рамках команды проекта, с участием внешнего эксперта, путем проведения моделирующих сессий, «защит» схем и т.п.
Чек-лист для контроля качества графической схемы процесса может содержать несколько разделов, например:
• тип модели процесса (аналитическая, для имитации, для автоматизации);
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий;
• отсутствие логических ошибок;
• аккуратность исполнения схемы, визуальная наглядность.
Подробно каждый пункт чек-листа и методика работы с ним представлены в моей статье «Как проверить качество графической схемы процесса?», которая опубликована на портале FineXpert.ru (http://finexpert.ru/view/kak_proverit_kachestvo_graficheskoy_skhemy_protsessa/892).
Время и деньги, затраченные на создание системы работы с графическими схемами процессов, в т.ч. нужных компетенций у сотрудников, окупится многократно. Важно помнить, что:
ЧЕМ АДЕКВАТНЕЕ МОДЕЛЬ, ТЕМ БОЛЬШЕ ШАНСОВ ВЫЯВИТЬ РЕАЛЬНЫЕ ПРОБЛЕМЫ ПРОЦЕССА
Пример анализа графической схемы процесса
На рис. 3. представлен пример графической схемы процесса. Процесс выполняют 10 участников из различных функциональных подразделений различных бизнес-единиц компании. Т.е. это типичный сквозной (межфункциональный) процесс.
При проведении визуального анализа достаточно очень небольшого времени, чтобы определить недостатки этого процесса. Обратите внимание, что на схеме процесса:
1 представлено 5 возвратов (перехода процесса на предыдущий этап);
2 количество повторяемых шагов при однократном возврате: 14;
3 количество информационных систем: 5 (MS Excel, 1С, АСУ «Транспорт», «Финансы», SAP).
4 доля контрольных операций: 57% (сверки, согласования, визирования);
5 доля операций по корректировке данных/документов (после возвратов): 19%.
Если сложить долю контрольных операций и операций по корректировке, то получится 76%. Но добавляют ли эти операции ценность для внутреннего клиента процесса? Ответ очевиден – нет. Таким образом из всего процесса только 24% операций добавляют хоты бы какую-то ценность.
Тот факт, что по ходу выполнения процесса данные 5 раза переносятся из одной системы в другую, причем местами вручную, приводит к ряду проблем: задержкам, потерям, ошибкам.
В целом, глядя на схему процесса рис. 3. можно утверждать, что процесс явно неэффективный. Получает ли компания результат? Да, получает. Но какой ценой? Сколько работы делается непродуктивно (не ведет сразу к нужному результату)? Можно ли сделать процесс быстрее и эффективнее? Можно ли поручить часть работы роботам? Да, наверное. Но прежде всего, нужно желание руководства компании избавиться от таких неэффективных процессов.
Виды анализа, для которых можно использовать графическую схему процесса
Выше я привел список аспектов, по которым можно выполнять визуальный анализ процесса. Это важно, так как для других методов анализа необходимо, кроме схемы, получать дополнительную информацию.
Условно, можно сформулировать три ситуации, когда мы используем графическую схему.
I. Формальный визуальный анализ схемы
Этот метод базируется на чек-листе контроля качества (верификации), который в свою очередь определяется требованиями Соглашения по моделированию (в т.ч. нотации) – см. выше.
II. Визуальный анализ + содержательный анализ
Можно предложить ряд пунктов, по которым можно и нужно визуально анализировать процесс, используя дополнительную информацию качественного характера:
• создает ли процесс ценность для клиентов (внутренний, внешних) и завершается ли он передачей результатов клиентам;
• содержательные ошибки, в т.ч. отсутствие необходимых операций;
• физическая нереализуемость (одновременное выполнение нескольких операций одним исполнителем);
• возвраты (переделки работы);
• дублирование операций (прямое или косвенное);
• чрезмерный контроль (проверка результатов работы одного исполнителя несколькими начальниками);
• узкие места (несколько веток процесса сходятся на операции, выполняемой одним исполнителем);
• возвраты в прошлое (переход на предыдущие этапы процесса, которые привязаны к конкретному времени);
• «процессная грыжа» (ничем не обоснованное описание других процессов в рамках схемы процесса);
• неоднородность масштаба операций (по длительности, трудоемкости);
• бенчмаркинг;
• анализ рисков.
Указанные пункты могут быть также оформлены в виде чек-листа.
Бенчмаркинг. Его можно выполнять путем визуального сравнения различных схем процессов. Но делать это приходится с изрядной долей креатива, т.к. архитектура процессов (и как следствие границы процессов) различны в разных организациях.
Анализ рисков может выполняться содержательно, а схема процесса использоваться для визуализации и дальнейшего обсуждения рисков процесса командой проекта оптимизации.
III. Визуальный анализ + количественный анализ
Графическая схема может стать основой для совмещенного, визуального и количественного анализа процесса. Структура операций процесса может быть перенесена из графический схемы в таблицы MS Excel, где дальше с ними будут производиться расчеты определенного типа. После выполнения расчетов можно вернуться к схеме и визуализировать на ней необходимую информацию.
К числу методов совмещенного визуального и количественного анализа процессов можно отнести:
• анализ степени автоматизации процесса (при разработке технического задания на автоматизацию);
• анализ времени выполнения (нормативное время выполнения, фактическое время выполнения);
• VALUE-анализ + анализ потерь (удобно выполнять совместно);
• имитационное моделирование процесса (производительность процесса, загрузка исполнителей, узкие места, расход ресурсов, стоимость результатов процесса).
Вообще говоря, имитационное моделирование нужно рассматривать отдельно. Качественная графическая схема процесса является необходимым условием создания имитационной модели.
Кроме указанных выше методов, для современных процессов можно ввести понятие «Цифровизация ready» и/или «Роботизация ready». Это означало бы, что процесс осмыслен и готов к тотальной цифровизации и роботизации – определены операции, которые необходимо цифровизовать (или цифровизировать) и т.п.
Резюме
Графические схемы являются мощным инструментом анализа процессов. Но для того, чтобы воспользоваться этим инструментом нужно:
• научиться создавать качественные схемы процессов;
• разработать Методику анализа процессов с использованием графических схем;
• обучить руководителей и специалистов, сформировать у них навыки разработки графических схем и их использования в рамках проектов анализа и оптимизации бизнес-процессов компании.
В.В. Репин, к.т.н., доцент, консультант по управлению.
Май 2017 г.
Добавить комментарий Отменить ответ
7 шагов к процессной организации бизнеса
7 шагов к процессной организации бизнеса
Что такое Процессная организация? Насколько сложно ориентировать Ваш бизнес на процессы? Какой эффект это может дать? В статье Владимира Репина рассматриваются характеристики Процессной организации и ее преимущества. Представлено описание семи универсальных шагов процессной трансформации бизнеса.
Эффект от оптимизации одного процесса
Довольно часто мне задают вопрос: «Как доказать руководству, что оптимизация процесса дает эффект?». Предлагаю простой пример. На рисунке 1 представлен несложный операционный процесс — всего три участника – два исполнителя и руководитель. Процесс включает пять операций и четыре точки ветвления. После каждой из них возможен возврат и переделка работы. После операции № 3 вероятность возврата – 20%, после операции 5 – 10%. Это экспертная оценка. Например, руководитель в среднем «заворачивает» на доработку 10% документов и т.п.
На рисунке показана стоимость каждой операции в рублях. Как ее определить? Самый простой способ: а) оценить нормативное время выполнения операции; б) определить стоимость 1 минуты рабочего времени исполнителя (хоты бы по его зарплате) – будет 5-10 рублей в минуту; в) умножить нормативное время на стоимость одной минуты. Легко рассчитать, что в идеальном варианте (при выполнении без возвратов) стоимость выполнения процесса в целом составит 120 рублей.
Далее. Предположим, что за месяц было запущено и выполнено 1000 экземпляров этого процесса. Другими словами, процесс 1000 раз выполнялся по данному алгоритму, но с разными исходными данными (они, кстати, на рисунке не показаны). Получается 120 тыс. рублей в месяц и 1,44 млн. рублей в год. Это идеальный вариант.
В случае, если возникают возвраты, стоимость процесса составит 1,64 млн. рублей в год вследствие повторного выполнения операций процесса (читатель может самостоятельно проверить расчет). Но повторное выполнение операций – это потери, или «муда», как говорят японцы. Что-то было сделано не так: с ошибками, с неточными исходными данными и т.п.
Общие потери за год только по одному этому простому процессу составляют 204 тыс. рублей или 14%! При этом я даже не говорю про затраты другого типа и возможные потери: расходные материалы, электроэнергия, амортизация оборудования и т.п. Замечу, что по ходу выполнения процесса возможны ожидания, простои и т.п.
Итак, вы видите эффект на примере простейшего процесса. А сколько в вашей компании таких и гораздо более сложных процессов? Несколько тысяч. Возможный потенциал оптимизации – миллионы, вероятно, десятки миллионов рублей для крупной организации. Эти деньги лежат, фактически, под ногами. Но чтобы их взять, нужно выработать новую стратегию процессной трансформации бизнеса и начать регулярную «процессную работу».
В целом, эффект от процессной трансформации бизнеса может быть следующим:
• устранение потерь различных видов;
• сокращение сроков выполнения процессов;
• повышение качества продукции и услуг;
• увеличение конкурентоспособности бизнеса;
• рост удовлетворенности клиентов;
• рост объемов продаж и прибыли;
• изменение корпоративной культуры;
• выживание бизнеса в долгосрочной перспективе.
Видение процессной организации
Итак, руководитель решил вплотную заняться процессами организации. Как ему дальше поступить? Брать каждый процесс (из тысячи) и оптимизировать? Понятно, что это заведомо тупиковый путь. Бизнес должен постепенно измениться внутренне. Можно сказать, переродиться в Процессную организацию. Каковые ее ключевые черты? О Процессной организации писали многие. Один из наиболее комплексных подходов был сформулирован Майклом Хаммером в модели оценки зрелости процессной организации PEMM (Process and Enterprise Maturity Model). Еще одним документом, весьма полезным для осмысления возможностей, является BPM CBOK – свод знаний в области управления бизнес-процессами. Любому руководителю желательно его прочитать.
Обратимся к модели PEMM Майкла Хаммера. Она представлена в таблице 1.
Таблица сложная. Она требует вдумчивого чтения. Важно смотреть на систему оценки комплексно. Например, переход к Процессной организации без определения сквозных процессов и создания органов управления (процессный комитет, владелец процесса, комитет по процессу) на межфункциональном уровне невозможен. Только синергетическая совместная работа межфункциональных команд по сквозным процессам при поддержке руководства может обеспечить желаемый эффект. До тех пор, пока сотрудники разделены барьерами структурных подразделений построение Процессной организации невозможно.
Пример. В одной крупной российской компании очень «хотели» заниматься процессами, но только в рамках жесткой традиционной функциональной структуры. Декларировали необходимость оптимизации процессов, но ничего конкретного для этого не делали. Возможно, в этой компании сложится собственный «жёстко-бюрократично-функциональный» метод управления сквозными процессами. Хотя вряд ли… Законы природы изменить нельзя.
Обратим внимание на 4-й уровень зрелости организации (П-4). Первый аспект согласно Хаммеру – это Менеджмент. Вы можете задать себе следующие вопросы:
• управление бизнес-процессами для топ-менеджеров – это способ ведения бизнеса?
• вовлечены ли ваши сотрудники в новую, процессо-ориентированную среду, активное участие в проектах улучшений?
• высшее руководство – одна команда, выполняющая стратегическое управление для постоянного повышения эффективности бизнеса?
• ваш стиль управления – влияние и целеполагание, а не жесткий контроль (оптимальное сочетание «A» и «I» для тех, кто читал Адизеса)?
Естественно, отвечать на эти вопросы нужно искренне, без самообмана. К сожалению, далеко не в каждой компании можно наблюдать такую ситуацию.
Второй аспект – Культура. Рассматривая организацию под этим углом, необходимо обратить внимание на следующее:
• практика работы команд по улучшению процессов с участием поставщиков и потребителей;
• сотрудничество по всей цепочке поставок для повышения качества обслуживания конечных потребителей;
• сотрудники считают своей личной целью высочайшее качество обслуживания клиентов и эффективность компании;
• сотрудники с пониманием относятся к необходимости постоянных изменений.
Обратите внимание, что Хаммер делает акцент на интеграцию, причем на межорганизационном уровне. Если вы откроете BPM CBOK, написанный ведущими мировыми специалистами много позднее, вы найдете там описание перспективной модели интеграции компании вдоль цепочки создания ценности с использованием современных технологий (облака, BPMS).
Следующий, третий аспект – Наличие специалистов по бизнес-процессам. Перевод довольно условный. Если говорить шире, речь идет о наличии носителей компетенций на всех уровнях управления:
• имеется достаточно много специалистов в области перестройки и реализации процессов, управления проектами, программного менеджмента и управления изменениями;
• управление процессами и изменение процессов становятся ключевыми элементами системы работы (анализ, планирование изменений, выполнение задач и внедрение процессно-ориентированных инноваций).
Четвертый аспект в модели PEMM Майкла Хаммера – это Структура управления процессами. Для зрелой организации она характеризуется следующим образом:
• модель бизнес-процессов компании интегрирована с поставщиками и потребителями, используется для стратегического развития бизнеса;
• владельцы процессов;
• совет по бизнес-процессам;
• руководящий Комитет с участием представителей поставщиков и потребителей;
• совместная работа владельцев процессов с ВП поставщиков и потребителей.
Если вас заинтересовала модель Хаммера, то после ее глубокого изучения целесообразно сформулировать Концепцию создания процессной организации для вашего бизнеса. Структура такого документа может, например, содержать следующие разделы:
- Цели и принципы Процессной организации.
- Архитектура, сквозные процессы, интеграция на межфункциональном и межорганизационном уровне.
- Управление процессам (Процессный совет, владельцы процессов, менеджеры процессов, Процессный офис, Цели и показатели для управления процессами).
- Методики (PDCA, оптимизация процессов, управление изменениями и проч.).
- Компетенции (руководителей и специалистов).
- Командная работа, вовлечение персонала.
- Мотивация (руководителей и специалистов).
- Культура организации.
Другой вариант – доработка вашей Стратегии с учетом указанных выше пунктов.
Для примера, в таблице 2 представлен результат мой субъективной экспертной оценки типичной российской торгово-производственной компании численностью до 500 человек («собирательный образ»). Зеленый цвет – утверждение полностью соответствует действительности, желтый – менее 50%, красный – менее 25%, черный – 0%.
Семь шагов процессной трансформации бизнеса
Каким же образом осуществить переход от обычной, функционально ориентированной компании к Процессной организации? Часто этот вопрос чрезмерно усложняют и не приступают к его решению. Иногда в крупных компаниях руководители только говорят, что «хотят процессов», а на самом деле их всё устраивает. В этом случае делают вид, что процессами занимаются (например, проводят обзорное обучение или устраивают кастинг внешних консультантов в рамках проекта «реинжиниринга» и т.п.), но в реальности дело не сдвигается с мертвой точки.
Если, все таки, собственники и топ-менеджеры готовы реально работать в этом направлении, то им может быть интересен следующий взгляд на «дорожную карту» создания Процессной организации. Она включает семь шагов:
- Самооценка.
- Видение.
- Архитектура и управление.
- Организация.
- Компетенции.
- Анализ.
- Внедрение.
Самооценка. Существует множество разных подходов к самооценке, но общее одно – понять ключевые элементы системы во взаимосвязи на каждом уровне развития. Необходимо разработать свою корпоративную методику самооценки (например, на основе модели PEMM или требований BPM CBOK), провести самооценку и понять текущее состояние организации.
Видение. Далее необходимо разработать видение (концепцию) Процессной организации. Основываться можно так же на указанных выше источниках (PEMM, BPM CBOK, CMMI, ISO 15504 и др.), информации о других компаниях, своем здравом смысле.
Архитектура и управление. Эта группа работ дорожной карты включает в себя создание архитектуры процессов компании. Не важно, что у вас может получиться что-то слишком сильно напоминающее функциональную структуру. По ходу процессной трансформации архитектура процессов еще не раз поменяется.
Пример. В некоторых крупных компаниях руководители говорит такую фразу: «Карту процессов верхнего уровня мы уже давно сделали. Давайте не будем ее трогать». Когда я слышу такую фразу, то понимаю, что в этой компании переход к эффективным процессам никому не нужен.
Управление — это создание органов, которые необходимы для Процессной организации. К их числу можно отнести:
• Совет по процессам (Процессный комитет на уровне компании в целом).
• Владельцы процессов.
• Менеджеры процессов.
Необходимо определить порядок работы, ответственность и полномочия процессных органов управления. Далее, по ходу процессной трансформации их можно будет дополнить/изменить. Важны понимание и готовность топ-менеджеров активно взаимодействовать с новыми органами управления, цель которых – оптимизация системы сквозных процессов компании.
На данном этапе нужно определить цели и показатели процессной трансформации бизнеса. Кроме того, назначенные владельцы процессов должны разработать цели и показатели, а затем использовать их для мониторинга и улучшения сквозных процессов.
Организация. Нужно создать в компании реальную систему работы с процессами: методики, инструменты, ресурсы, действующие процессы. Для этого в помощь топ-менеджерам нужно создать Процессный офис, разработать необходимый минимум регламентов его работы, выбрать и установить программный продукт, разработать план проекта на 5-6 месяцев. Будет замечательно, если в Процессном офисе со временем появится Процессный архитектор и Процессный методолог.
Компетенции. После появления Процессного офиса необходимо создать в компании минимальный уровень компетенций для работы с процессами. Это означает разработку учебных программ и материалов (в т.ч. на «пилотных» примерах), проведение массового обучения руководителей и специалистов. Целесообразно комбинировать обычное обучение с обучением действием, создавая межфункциональные рабочие группы и давая им простые «домашние» задания. Отдельное обучение необходимо провести для владельцев и менеджеров процессов.
Анализ. Когда рабочие группы сформированы, нужно сразу приступить к анализу «пилотных» сквозных процессов. Цель анализа – выявление проблем и определение возможностей оптимизации процессов, разработка конкретных мероприятий по изменению. Это, так сказать, первая волна процессных изменений в бизнесе.
Внедрение. Разработанные на этапе анализа мероприятия должны быть внедрены. По ходу необходимо развить компетенции рабочих групп в области управления изменениями. Возможно, стоит создать Проектный офис, установить систему управления проектами и т.п. Но на первых порах это можно делать даже в MS Excel. Выполнение проектов «первой волны» дает возможность активно продвигать идеи процессной трансформации в «массы», вовлекать персонал и проч. Далее вашей организации предстоит освоить регулярную, планируемую работу по процессной трансформации бизнеса, причем обязательно с обратной связью и оценкой эффективности процессов, проектов, элементов системы управления.
Представленная выше «дорожная карта» довольно условна. Вы можете трансформировать ее с учетом ситуации в компании и вашего понимания. Однако, нельзя пропускать ключевые, системообразующие моменты, такие как определение сквозных процессов, создание органов процессного управления, назначение владельцев процессов, создание Процессного офиса, обучение межфункциональных команд, выполнение и анализ эффективности «пилотных» проектов.
Выводы
Создание Процессной организации – не так сложно, как кажется. Нужно просто захотеть это сделать. Люди изначально, внутренне ориентированы на интеграцию, сотрудничество, синергию. Процессная организация – это способ раскрытия внутренних психологических потребностей ваших сотрудников. В этом смысле, почти преступление — начинать процессную трансформацию бизнеса с массовых сокращений персонала. Людей нужно сделать ваши союзниками, а не скрытыми оппонентами, препятствующими изменениями. Подумайте о своих скрытых желаниях — кем вы больше ходите быть: султаном, восседающим на вершине организационной пирамиды, или тренером команды, способной на новые, яркие достижения в бизнесе.
Возвращаясь к конкретике, можно включить ряд мероприятий по переходу к Процессной организации в вашу Стратегию. Есть ли в ней сегодня пункты о развитии системы управления, архитектуры бизнеса? Или представлены только инвестиции в «заводы и пароходы» (т.е. экстенсивное развитие бизнеса)? Стоит внимательно проанализировать этот документ.
И еще раз о самооценке уровня зрелости. Это первое, с чего стоит начать, двигаясь по пути процессной трансформации бизнеса.
В.В. Репин, к.т.н., доцент, консультант по управлению.
Февраль 2017 г.
Добавить комментарий Отменить ответ
Оценка уровня зрелости процесса по методике ГОСТ Р ИСО/МЭК 15504-2.
Оценка уровня зрелости процесса по методике ГОСТ Р ИСО/МЭК 15504-2.
В статье рассматривается возможность применения для оценки любого процесса организации технологии, представленной в стандарте ГОСТ Р ИСО/МЭК 15504-2. Материал может быть интересен специалистам, использующим (разрабатывающим) собственную методику оценки уровня зрелости как отдельных процессов, так и системы процессов организации в целом.
Введение
Зачем оценивать уровень зрелости процесса? Это вполне справедливый вопрос любого владельца или руководителя бизнеса. Как эта оценка повлияет на увеличение прибыли компании? Очевидно, что оценка, сама по себе, не может повлиять на реальную деятельность. На нее влияют руководители. Именно они по результатам оценки реальных возможностей процессов могут решить, что и как нужно менять, чтобы процессы соответствовали целям организации, эффективным образом раскрывали свой потенциал.
Существуют различные подходы к оценке зрелости процессов. Среди них есть подход, который проработан в области информационных технологий в стандартах серии ГОСТ Р ИСО/МЭК 15504. В данной статье сделана попытка интерпретировать стандарт ГОСТ Р ИСО/МЭК 15504-2 так, чтобы можно было проводить оценку зрелости любых процессов организации. В самом стандарте сказано, что документ: «… распространяется на оценку процессов и ее применение для улучшения и определения возможностей процесса. Настоящий стандарт устанавливает минимальный набор требований к проведению оценки, соблюдение которых обеспечит объективность, беспристрастность, непротиворечивость, повторяемость результатов оценки, представляющих оцениваемый процесс».
В документе вводятся понятия «Оценка» и «Возможность». Замечу, что в рассматриваемом стандарте ни разу не используется термин «Зрелость». Тем не менее, далее в статье я буду пользоваться термином «зрелость процесса».
Отмечу, что Стандарт разрешает использовать его материалы: «…пользователи настоящего стандарта могут свободно воспроизводить соответствующие материалы как часть любой модели оценки процесса…». Модель оценки процесса, в том виде, в каком я хочу представить читателю (таблица критериев и уровней) в тексте ГОСТ Р ИСО/МЭК 15504-2 отсутствует. Методика описана там текстом, что не очень удобно для восприятия и использования.
Стандарт говорит следующее: «Возможности процесса определяют по шестибалльной шкале, позволяющей оценить возможности от самых низких — неполный процесс, до самых высших — оптимизирующий процесс. Шкала отражает возрастание возможностей выполнения процесса от осуществления, которое не способно достичь выходов процесса, до осуществления, которое способно обеспечить текущие и планируемые бизнес-цели». Можно заменить термин «осуществление» на «выполнение». Тогда текст становится более читаемым и понятным. Например, если при выполнении процесса мы наблюдаем недопустимый уровень брака, то это означает, что не достигаются целевые результаты процесса – уровень «0» — «Неполный процесс». Наоборот, если при выполнении процесса мы полностью достигаем всех поставленных целей и уверены, что достигнем этих и других целей в будущем, то процесс находится на уровне «Оптимизирующий».
Итак, важнейшей задачей оценки разработчики Стандарта считают выявление возможностей процесса обеспечивать достижение текущих и перспективных целей организации. Очевидно, что это определение является универсальным и подходит для любого процесса, а не только в области информационных технологий.
По итогам внимательного чтения документов ГОСТ Р ИСО/МЭК 15504-1-2009 и ГОСТ Р ИСО/МЭК 15504-2 я сделал для себя вывод, что процессы желательно оценивать по следующим четырем аспектам:
- Возможности достижения целей организации.
- Текущий потенциал процесса (например, производительность).
- Возможности (потенциал) улучшения процесса.
- Культура непрерывного улучшения процесса.
На рис. 1 представлен пример, в шутливой форме поясняющий эти аспекты.
Допустим наша цель: «Совершать поездки быстро, комфортно с минимальных расходом топлива, без лишних понтов». Обычный автомобиль «Запорожец» — возможности по достижению целей низкие – уровень «прокачки» близок к нулю. Текущий потенциал – низкий (износ, в машине тесно, едет медленно и т.п.). Возможности улучшения – весьма ограничены. Культура улучшения процесса – задача не стоит. «Порше» — возможности по достижению целей высокие – можно доехать быстро и с комфортом. Потенциал – невысокий (всего 2 пассажира, хотя и с комфортом). Возможности улучшения — незначительные (из машины на заводе уже выжали всё, что можно). Культура – специфическая. «Форд» — цели достигаются оптимально. Потенциал – хороший (5 пассажиров комфортно + багаж). Возможности улучшения (тюнинг) – значительные. Культура – высокая.
Другой пример – процесс обслуживания клиентов в отделении Сбербанка – см. таблицу. Это, конечно, мой личный взгляд на ситуацию в Сбербанке.
2004 год | 2017 год | |
Возможности достижения целей организации | Низкие | Высокие |
Текущий потенциал процесса | Ограничен (как следствие – большие очереди) | Высокий |
Возможности (потенциал) улучшения процесса | Отсутствуют | Средние |
Культура непрерывного улучшения процесса | Отсутствует | Присутствует, но развита недостаточно |
Каким же образом измерить возможности процесса? Хотя в Стандартах серии 15504 можно выделить указанные выше аспекты, измерять предлагается набор так называемых атрибутов (критериев), по которым определяется уровень возможностей процесса. Т.е. все четыре аспекта свернуты в линейный список критериев. Итак, давайте рассмотрим собственно критерии и уровни оценки возможностей процесса.
Критерии и уровни оценки зрелости процесса
Стандарт вводит следующие уровни возможностей процесса. Поскольку я несколько не удовлетворен определениями Стандарта, то попытался немного переформулировать названия:
Определение стандарта | Определение автора статьи | |
Уровень 0 | Неполный процесс | Невыполняемый процесс |
Уровень 1 | Осуществленный процесс | Выполняемый процесс |
Уровень 2 | Управляемый процесс | Управляемый процесс |
Уровень 3 | Установленный процесс | Стандартизированный процесс |
Уровень 4 | Предсказуемый процесс | Прогнозируемый процесс |
Уровень 5 | Оптимизирующий процесс | Непрерывно улучшаемый процесс |
Для каждого уровня от «0» до «5» в ГОСТ Р ИСО/МЭК 15504-2 описаны критерии, по которым нужно проводить оценку возможностей процесса. Критерии сгруппированы по нескольким аспектам. После сведения всех этих критериев в таблицу, получается следующая картина.
Надписи на рис. 2. весьма мелкие, поэтому зарегистрированным пользователям портала можно скачать файл MS Excel.
Определения стандарта | Определения, предлагаемые автором статьи |
Осуществление процесса | Выполнение процесса |
Управление осуществлением | Управление выполнением процесса |
Управление рабочим продуктом | Управление рабочим продуктом |
Определение процесса | Стандартизация процесса |
Развертывание процесса | Управление развертыванием процесса |
Измерение процесса | Управление эффективностью процесса |
Контроль процесса | Управление вариациями процесса |
Инновация процесса | Планирование улучшений в процессе |
Оптимизация процесса | Управление изменениями процесса |
Как видно из таблицы, атрибуты (критерии) оценки процесса сгруппированы по следующим разделам:
Оценка процесса проводится путем сбора данных, на основании которых можно экспертно (или при помощи определенных шкал, если их специально разработать) определить уровень достижения каждого критерия. Стандарт рекомендует использовать следующую шкалу рейтингов (цветовое кодирование предложено автором статьи):
Таким образом, нужно для каждого атрибута оценить уровень достижения. Далее определяется уровень возможностей (зрелости) процесса в целом при помощи следующей таблицы, которую предлагает использовать Стандарт ГОСТ Р ИСО/МЭК 15504-2:
В таблице MS Excel (рис.2.) приведен пример оценки критериев для некоторого условного процесса. Видно, что при такой оценке процесс находится между уровнями «1» и «2».
Интерпретация структуры критериев оценки возможностей процесса
Считаю важным обсудить некоторые вопросы по структуре и содержанию критериев (атрибутов).
Осуществление процесса
Здесь все понятно. Если процесс выполняется и мы получаем приемлемый результат, то зрелось процесса соответствует Уровню 1.
Можно определить и использовать несколько критериев второго уровня декомпозиции, которые реально измерить, например:
• План/факт по объему производства (например, при отклонении более минус 25% значение критерия равно «0» и т.п.);
• План/факт по уровню брака;
• План/факт по срокам поставки;
• …
Далее нужно определить веса, чтобы свернуть все критерии второго уровня в один критерий «Осуществление процесса». Таким образом, мы можем перейти от субъективной экспертной оценки к оценке, основанной на расчетах конкретных цифр. К сожалению, не всегда это можно сделать так просто, как в данном случае.
Управление осуществлением
Внимательный анализ критериев этого подраздела говорит о том, что в процессе внедрен регулярный менеджмент: целеполагание, планирование, мониторинг и регулирование (принятие оперативных решений). Ответственность и взаимодействие исполнителей четко определены. Можно ли оцифровать критерии этого подраздела? Видимо, да. Причем с разной степенью детализации.
Управление рабочим продуктом
Критерии этого раздела вполне четко сформулированы и могут быть оцифрованы. Однако при этом придется учитывать специфику продукта (услуги) компании.
Определение процесса
Очень интересный подраздел. Можно интерпретировать его следующим образом. Создана модель процесса, причем с учетом его взаимодействия с другими процессами организации (в рамках архитектуры бизнеса). Как сам алгоритм выполнения процесса, так и требования к его исполнителям (компетентности, роли) стандартизованы.
Развертывание процесса
Можно интерпретировать критерии данного раздела в том смысле, умеем ли мы грамотно организовывать работу процесса по установленным стандартам. Например, внесены изменения в технологию производства и проведена модернизация оборудования. Есть ли у нас отлаженный процесс и компетенции по внедрению этих изменений в процесс? Хочу обратить внимание читателя, что содержательно некоторые критерии данного раздела похожи на критерии раздела «Оптимизация процесса». Там тоже речь идет об умении управлять изменениями.
Измерение процесса
В простейшем случае управлять процессом можно только с использованием показателей план/факт по объему полученного результата (в «Управлении осуществлением»). В «Измерение процесса» можно говориить, на мой взгляд, о наличии системы целей, сбалансированных показателей и управления эффективностью (Performance Management).
Контроль процесса
Судя по смыслу представленных критериев, данный раздел правильнее было бы назвать «Управление вариациями процесса». Представленные критерии вполне можно оцифровать.
Инновация процесса
Возможно, в данном разделе речь идет о цикле постоянного улучшения процесса PDCA в части «Планировать». В критериях говорится об анализе «возможностей» улучшений, а не о внедрении самих улучшений. Поэтому я бы назвал данный раздел «Планирование улучшений в процессе».
Оптимизация процесса
Судя по формулировкам критериев, раздел создан для оценки возможностей по управлению изменениями. Поэтому я бы так его и назвал «Управление изменениями процесса». Кстати, в определениях критериев раздела термин «Оптимизация» не используется. В целом, критерии раздела вполне могут быть оцифрованы.
Резюме
Мы рассмотрели системы критериев и уровней оценки возможностей процесса, рекомендуемые стандартом ГОСТ Р ИСО/МЭК 15504-2. На мой взгляд, подход, сформулированный в стандартах, можно использовать для оценки зрелости любого процесса, не только в области информационных технологий. Читатель может творчески переосмыслить представленный материал и создать (изменить) методику оценки зрелости процессов для своей компании. Эта методика может быть использована в рамках проекта внедрения процессного управления и последующей деятельности по постоянному совершенствованию процессов компании.
В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.
Январь 2017 г.