Статья Хазал Симсек с комментариями Владимира Репина

В переводе статьи Хазал Симсек представлены комментарии Владимира Репина по всем разделам. Опытным бизнес-аналитикам может быть интересен взгляд автора статьи, которая четко не отделяет методы анализа процессов от программного обеспечения, их реализующего. Начинающим бизнес-аналитикам будет интересен обзор современных методов анализа с ремарками об их практической применимости.

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

Анализ процессов — это первый шаг к визуализации, совершенствованию и управлению процессами, именно поэтому анализ процессов набирает популярность, как показано на рисунке 1.

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

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

Таким образом, в этой статье мы расскажем о 18 лучших инструментах анализа процессов в трех категориях:

• Программное обеспечение.
• Методы.
• Диаграммы.

Владимир Репин. Серьезная заявка автора и громкие слова. Что ж, посмотрим что будет на деле.

Что такое анализ процессов?

Анализ бизнес-процессов оценивает процессы для выявления характера и первопричины неэффективности. Анализ процессов может помочь:

• улучшить процессы;
• автоматизировать избыточные задачи и действия;
• обеспечить стандартизацию и соответствие требованиям.

Владимир Репин. Автор статьи использует для определенных процессов термин «Redundant tasks and activities», предлагая их автоматизировать. Скорее всего, она имеет в виду процессы и задачи, выполнение которых человеком избыточно с точки зрения создания ценности. Речь, очевидно, идет об автоматизации (роботизации) рутинных задач, которая позволяет сотрудникам сосредоточиться на более сложных и интересных задачах, что повышает их удовлетворённость и мотивацию, ведет к развитию профессиональных навыков.

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

Process analysis software (программное обеспечение для анализа процессов)

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

Что такое Process Intelligence?

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

Владимир Репин. В Интернете можно найти разные определения термина Process Intelligence, например такое: «Это практика сбора и анализа данных по процессу для выявления узких мест и повышения операционной эффективности. Process Intelligence позволяет бизнес-аналитикам выявлять каждый этап рабочего процесса, ответственный персонал, продолжительность всего процесса, среднее время ожидания и проблемы с процессом». Tadviser.ru приводит следующее определение: «Process Intelligence (PI) — это комбинация технологий управления бизнес-процессами (BPM) и бизнес-аналитики (BI). PI выводит стратегическое и операционное управление на новый уровень. Если измерение степени успешности бизнеса с помощью Business Intelligence дает его результаты, но не показывает различные пути их достижения, то PI помогает получить лучшие бизнес-результаты лучшими из возможных способов».

1. Process mining

Process mining — это аналитическая дисциплина и технология для сбора, анализа и моделирования бизнес-процессов на основе технологических данных, записанных в ИТ-системах.

Владимир Репин. Process Mining – это технология непрерывного восстановления карт реальных бизнес-процессов на основе данных, хранящихся в информационных системах предприятия. Построенные карты процессов используются для расчёта расширенной аналитики, позволяющей повысить операционную эффективность предприятия, доходность его продуктов или услуг (Tadviser.ru).

2. Task mining

Анализ задач или Task Intelligence — это технология для отслеживания взаимодействия пользователей на рабочих местах, например выполнения задач в электронных таблицах.

Владимир Репин. Task Mining — это технология, позволяющая полно и достоверно воссоздать последовательность действий в рамках бизнес-операций. Она фиксирует и исследует элементарные действия в рамках каждого шага процесса (заполнение полей, переходы между вкладками и окнами и другие взаимодействия с интерфейсами рабочих приложений), восстанавливает их последовательность и оценивает эффективность. Основные цели Task Mining: 1) определить, чем именно и когда заняты сотрудники; 2)     посчитать количество выполняемых операций и трудозатраты на них; 3)     идентифицировать и проанализировать повторяющиеся паттерны, чтобы найти способы их оптимизации и/или роботизации. Полученные данные помогают улучшить эффективность рабочих процессов и уменьшить время, затрачиваемое на рутинные задачи. Если основная задача Process Mining – это восстановление  фактического хода бизнес-процесса в компании, то Task Mining, в свою  очередь, — это оцифровка деятельности сотрудников и подсчёт трудозатрат, определение нагрузки и эффективности работы. То есть Process Mining выполняется для отдельных задач (https://rb.ru). Мнение еще одного эксперта: «Важен анализ пользовательской активности, то есть исследование активностей сотрудников в течение их рабочего дня: сколько времени человек провел за рабочим компьютером, какие приложения использовал, с кем внутри сети взаимодействовал и др. Для этого используются решения класса Task Mining/Process Discovery».

3. Process modeling (моделирование процессов)

Программное обеспечение для моделирования процессов моделирует процессы и выполняет эти модели.

Владимир Репин. Здесь автор немного лукавит – ПО для моделирования, как правило, не исполняет процессы, то есть это не BPM-система. Хотя, например, в Business Studio можно не только моделировать процессы в различных нотациях, но и запускать их на имитацию. Эту имитацию можно рассматривать как выполнение, цель которого состоит в получении данных о средней длительности и стоимости выполнения процессов. Например, вы сделали модель «Как есть», путем имитации рассчитали ее характеристики, а потом повторили эти действия для модели «Как должно быть». Сравнив результаты можно сделать выводы о потенциальном эффекте от оптимизации бизнес-процесса… В данном контексте речь идет о системах класса CA (Corporate Architecture), в которых можно разрабатывать архитектуру бизнес-процессов (и не только) организации, моделировать процессы в различных нотациях и проч.

4. A digital twin of an organization (цифровой двойник организации)

Цифровой двойник организации (DTO) создает виртуальные модели процессов, услуг или организационных структур для моделирования сценариев.

Владимир Репин. Программный аналог физического устройства, моделирующий внутренние процессы, технические характеристики и поведение реального объекта в условиях воздействий помех и окружающей среды. Важной особенностью цифрового двойника является то, что для задания на него входных воздействий используется информация с датчиков реального устройства, работающего параллельно. Работа возможна как в онлайн, так и в офлайн режимах. Далее возможно проведение сравнения информации виртуальных датчиков цифрового двойника с датчиками реального устройства, выявление аномалий и причин их возникновения (Tadviser.ru)… На мой взгляд, этот метод отнесен к методам анализа некорректно. Если вам уже удалось создать адекватный цифровой двойник, то это означает, что вы очень глубоко знаете свои бизнес-процессы и соответствующие проблемы. То есть к моменту создания цифрового двойника эти проблемы уже должны быть, в основном, решены.

5. Process mapping (составление карт процессов)

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

Владимир Репин. Возникает вполне закономерный вопрос, чем, собственно Process mapping отличается от Process modeling? Картирование (мапинг) могут делать обычные сотрудники, используя примитивные, но интуитивно понятные нотации (за редким исключением, например – Toyota Value Stream Map). Например, всем известная крупнейшая промышленная организация в РФ в рамках своей «Производственной системы» картирует процессы, но не моделирует их, например, в BPMN. Надо сказать, что для ряда задач картирование при помощи примитивных, укрупненных представлений вполне решает свои задачи (например, в рамках проектов в области бережливого производства). Но для автоматизации и цифровизации такое картирование не годится. Примерно так же видят разницу между Process mapping и Process modeling  коллеги из Bizagi: «Process mapping — это процесс создания визуальной диаграммы шагов в потоке деятельности, которая создаёт бизнес-процесс. Он фокусируется на диаграммах существующих процессов в качестве точки отсчёта. Process modeling — это графическое представление бизнес-процессов или рабочих процессов в деталях и в контексте бизнес-операций. Модель процесса включает элементы документации процесса и учитывает всю информацию, необходимую для правильного выполнения процесса и его интеграции в более широкую организацию.  Process modeling — это более динамичный и гибкий подход, который ставит процессы в контекст всей организации. Он поддерживает процессы жизненного цикла и непрерывное улучшение». В общем, отмежевались они маркетингово от устаревшего термина «маппинг».

6. Business Process Management  (программное обеспечение для управления бизнес-процессами)

Программное обеспечение для управления бизнес-процессами (BPM) автоматически анализирует процессы и управляет ими.

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

7. Workflow Аnalysis Software  (программное обеспечение для анализа рабочих процессов)

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

Владимир Репин. В том, что автор статьи выделил такой метод анализа, есть некоторое лукавство, если не сказать неточность. Исторически, подход Work Flow появился довольно давно (более 30 лет назад). На тот момент фактически не было стандартов для моделирования исполняемых процессов. Вендоры Workflow-систем (прадедушки и прабабушки современных BPMS) создавали свои визуальные конструкторы процессов «кто во что горазд» (хотя потом, в 1993 году была создана  Workflow Management Coalition (WfMC)). В целом, стандартизации не было. Теперь у нас есть BPMN и мощные системы класса BPМ, которые, помимо своей основной функции автоматизации исполнения бизнес-процессов, предоставляют замечательные возможности для сбора и анализа аналитической информации по процессам. Имея современные методы и инструменты для моделирования бизнес-процессов и их последующей автоматизации в BPMS я бы не стал вообще выделять Work Flow в качестве какого-то отдельного метода анализа (если конечно нет цели пустить пыль в глаза клиентов умными терминами). Тем не менее, наши западные коллеги до сих пор пишут про Work Flow так: «…это системный подход, который используется для оценки, анализа и оптимизации потока задач, процессов и информации в организации. Он включает в себя изучение того, как выполняется работа, выявление узких мест, неэффективности и областей улучшения для повышения производительности, эффективности и производительности (itexus.com)…». Общие слова. Даром что уже давно есть ABPMP и BPM CBOK. Найдите три отличия от Process Modeling и Business Process Management…

Методы анализа процессов

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

Владимир Репин. Автор статьи почему-то продолжает сквозную нумерацию, смешивая программные продукты для анализа и сами методы анализа процессов. Строго говоря, это некорректно. Например, тот же Process mining имеет под собой определенную методологию и математику, а поддерживающих данный метод программных продуктов на рынке много. Другое дело, что без автоматизации Process mining остается только на бумаге, в теории.

8. Gap analysis (анализ пробелов)

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

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

Владимир Репин. По мнению специалистов: «… GAP-анализ (gap — «разрыв» или «зазор») — метод, который изучает несоответствия между текущим состоянием и желаемым. Он сравнивает фактическую производительность с запланированной, анализирует, насколько качество или внешний вид продукции соответствует ожиданиям клиентов. Главная цель GAP-анализа — обнаружение разрывов между целями и возможностями компании и подбор способов для их устранения…».  Вопрос только в том, насколько обосновано это желаемое состояние. Например, мы спроектировали модель бизнес-процесса «Как есть» на основе таких радикальных изменений, что внедрить их либо слишком дорого, либо слишком рискованно. В этом случае ценность от GAP-анализа будет не слишком высокая.

9. Value-added analysis (анализ добавленной стоимости)

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

• определения процессов, повышающие ценность бизнеса;
• определения процессов создания реальной добавленной стоимости (RVA);
• выявления процессов, не связанных с добавленной стоимостью (NVA)

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

Владимир Репин. Что касается Value-added analysis, то его использование сопряжено с некоторыми трудностями. Дело в том, что с разных точек зрения один и тот же процесс может добавлять ценность для бизнеса, а для клиента – нет. Что с ним тогда делать? Многие, так называемые, «вспомогательные» процессы жизненно необходимы компании, в то время как для клиента они совершенно не нужны.

10. Root cause analysis  (анализ корневых причин)

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

• Руководства и инструкции.
• Оборудование, измерительные устройства и инструменты.
• Такие процедуры, как запрос заказа, и проч.
• Деятельность сотрудников.
• Окружающую среду как на объекте, так и за его пределами.

Владимир Репин. Данный метод очень старый и относится к важнейшим методам менеджмента качества: «… Анализ корневой причины берет свое начало в атомном военно-морском флоте США, где адмирал Хайман Риковер установил высокие стандарты операционной эффективности для систем и персонала. Большинство ранних методов анализа корневой причины были разработаны в сотрудничестве специалистов атомного флота и сотрудников Комиссии по атомной энергии США (Atomic Energy’ Commission – AEC, ныне Nuclear Regulatory Commission – NRC), занимавшихся проектированием, эксплуатацией, обслуживанием и заправкой топливом морских ядерных реакторов… Анализ корневой причины – это структурированный исследовательский процесс, который позволяет распознавать и обсуждать глубинные убеждения и практики, приводящие к низкому уровню качества. Корневая причина — это основной причинный фактор, который, если его исправить или устранить, предотвращает повторение ситуации. Существуют разногласия относительно того, следует ли относить сбой к одной корневой причине (что-то, что действует как электрический выключатель) или к группе корневых причин. Это может зависеть от принятой в организации таксономии корневых причин. Методы анализа корневой причины могут быть полезны как для диагностики, так и для предотвращения проблем с качеством, защитой окружающей среды и техники безопасности. Некоторые специалисты не хотят признавать, что корневые причины кроются в ценностях и культуре организации, но пока анализ не доходит до этого уровня, организация не начинает бороться с корневыми причинами….»

11. Observational analysis  (анализ наблюдений)

Этот метод показывает пропущенные этапы и отсутствующие действия в реальных процессах. Для анализа наблюдений может потребоваться:

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

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

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

12. Experience examination analysis  (анализ опыта сотрудников)

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

• неэффективность процессов и потенциальные причины, которые ее предопределяют;
• выявить хорошо функционирующие процессы  и happy path.

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

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

Владимир Репин. Анализ кратчайшего пути процесса может быть полезен для выявления факторов, влияющих на процесс и действий персонала, которые могут исключить эти факторы. Так же можно выявить требования к ресурсам, получаемым из других процессов, требования к работе автоматизированных систем (скорость, производительность и проч.). Вопрос простой: как удалось сотрудникам выполнить за 2 дня процесс, который обычно занимает неделю? Какие факторы на это повлияли? Или, например, почему в одном филиале отгрузка товара занимает, в среднем, 4 часа, а в другом – 2.

 13. Predictive analysis (прогнозный анализ)

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

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

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

14. Impact analysis  (анализ взаимного воздействия)

Анализ воздействия — это важный показатель для оценки воздействия взаимодействий между процессами, системами и приложениями.

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

Владимир Репин. «Impact Analysis (импакт анализ) — это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты. Затронутые области требуют большего внимания во время проведения регрессионного тестирования…». Думаю, этот метод уже ближе к методам бизнес-анализа (см. BABOK), чем к классическим методам анализа бизнес-процессов. Не совсем понятно, зачем автор статьи включил его в список.

15. Failure mode effects analysis (FMEA)  (анализ последствий отказов):

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

Владимир Репин. Метод довольно старый и многим, особенно менеджерам по качеству, хорошо известный. «FMEA (failure modes and effects analysis) – анализ причин и последствий отказов. Метод анализа, применяемый в менеджменте качества для определения потенциальных дефектов (несоответствий) и причин их возникновения в изделии, процессе или услуге. Он применяется для выявления проблем до того, как они проявятся и окажут воздействие на потребителя….»

Диаграммы и графики

Диаграммы  широко используются для визуализации или моделирования процессов. Некоторые из этих методов визуализации могут быть использованы для анализа процессов.

16. Flowchart mapping (построение блок-схем)

Блок-схемы процессов отображают простые процессы в виде отдельных этапов в последовательном порядке. Диаграмма иллюстрирует:

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

Владимир Репин. Представленная автором статьи диаграмма довольно примитивна (странно, почему не был приведен пример в нотации BPMN): знакомая всем «схема с ромбиками» (ANSI, 1974 год). Совершено очевидно, что такой формат представления устарел, хотя в некоторых компаниях его до сих пор используют. Но большинство организаций перешли или переходят на нотацию BPMN (с нотаций CFFC, eEPC и других «доморощенных» нотаций).  

17. Spaghetti diagram (диаграмма-спагетти)

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

Владимир Репин. Еще раз о несистемности подачи материала автором статьи. Спагетти-диаграмму невозможно построить без программного продукта класса Process Mining, но этот класс уже был рассмотрен под номером 1. Возможно, что эту статью вообще писал ИИ, а автор только немного ее правил.

18. Fishbone diagram (диаграмма рыбьей кости)

Диаграммы «Рыбья кость» показывают причинно-следственные связи проблемы в данном процессе. Они сочетаются с анализом первопричин. Диаграммы «Рыбья кость» учитывают:

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

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

Заключение

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

 Успехов при внедрении технологий BPM!

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

Четыре метода анализа бизнес-процесса

BPM (Business Process Management) как направление менеджмента, как совокупность методов и инструментов существует довольно давно. За эти годы разработано и опробовано на практике значительное количество методов анализа бизнес-процессов. Они отличаются условиями применимости и целям, сложностью и требованиями к квалификации экспертов, проводящих анализ.

В данной статье я хотел бы рассмотреть четыре метода анализа процессов, которые вполне может использовать любой сотрудник организации, хотя бы в начальной степени овладевший навыками создания графических схем процессов в нотации BPMN (или, шире, — Work Flow). К числу этих методов относятся:
1. визуальный анализ графической схемы процесса;
2. анализ времени выполнения процесса;
3. анализ потерь, возникающих при выполнении процесса;
4. анализ потенциала автоматизации процесса

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

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

На данном учебном примере разберем указанные выше методы анализа и принципы оптимизации.

Предполагается, что читатели знакомы с базовыми аспектами описания процессов в нотации BPMN. Но даже если вы не знаете эту нотацию, условные обозначения на рис. 1 вполне понятны для сотрудников, которые в своей практике сталкивались с задачей описания процессов в нотациях типа Work Flow.

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

Обратите внимание, что на схеме процесса указаны информационные системы (MS Outlook, MS Excel), которые поддерживают выполнение задач. Для задач выполняемых вручную (точнее «ногами») использован маркер ручной задачи (ладошка).

Далее в статье рассмотрены методы анализа бизнес-процесса на примере разбора представленной схемы (разработана в Business Studio 5).

Анализ графической схемы бизнес-процесса

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

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

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

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

На рис. 2 показан результат визуального анализа графической схемы процесса.

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

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

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

На схеме так же видно, что потребитель процесса (в данном случае – это Роль А, инициатор) не получает результат выполнения процесса – «Расчет». Ему нужно писать и звонить руководителю (Роль Д), выяснять статус и потом «ногами» забирать нужный ему документ. Это плохо.

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

Далее необходимо выполнить анализ времени выполнения бизнес-процесса.

Анализ времени выполнения бизнес-процесса

На рис. 3 показан анализ времени выполнения процесса. Для каждой задачи определяют три показателя:

1. нормативное время выполнения, минут;
2. фактическая трудоемкость, минут;
3. календарное время выполнения, минут.

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

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

Календарная длительность выполнения задачи – это разница во времени между началом и завершением выполнения задачи. Используется усредненная величина по всем выполненным задачам за определенный период, например, месяц.

Почему фактическая трудоемкость и календарная длительность могут отличаться? Все просто – процесс может простаивать по различным причинам. Например, руководителю поступил документ на согласование. Реальная фактическая трудоемкость его работы надо документом, например, — 5 минут. Фактическая календарная длительность, в среднем, — 6 часов (с учетом повторного выполнения). То есть большую часть времени документ просто ждет в очереди на обработку. Очевидно, что необходимо организовать выполнения бизнес-процессов так, чтобы нормативное время и календарное время отличались как можно меньше.

Обратите внимание, что нормативное выполнения процесса в целом – около 2,8 часов, а фактическая календарная длительность – 32 часа, то есть почти в одиннадцать раз больше!

На рис. 4 показано время выполнения процесса в виде диаграммы. Видны следующие ограничения, устранение которых позволит существенно сократить длительность процесса. Бизнес-процесс дольше всего простаивает на следующих задачах:

• Проверить расчет.
• Проверить и согласовать расчет.
• Распечатать и передать расчет на согласование.
• Передать расчет на согласование.
• Выполнить расчет количества.
• Выполнить расчет стоимости.

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

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

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

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

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

1. потери, связанные с перепроизводством;
2. потери, связанные с ожиданием;
3. потери, связанные с транспортировкой;
4. потери, связанные самой обработкой;
5. потери, связанные с ненужными запасами;
6. потери, связанные с ненужными движениями;
7. потери, связанные с производством дефектной продукции.

На рис. 5 показаны потери, которые были выявлены при проведении анализа процесса. Условные обозначения для потерь выбраны произвольно (без использования какой-либо нотации).

Более подробно потери и риски, возникающие при выполнении задач процесса показаны в Таблице 1. Так же в таблице показаны возможные последствия.

Таблица 1. Потери и риски при выполнении процесса.

После анализа потерь целесообразно выполнить анализ потенциала автоматизации бизнес-процесса.

Анализ потенциала автоматизации бизнес-процесса

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

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

Разработка мероприятий по оптимизации бизнес-процессов

Давайте применим принципы «вертикального» и «горизонтального» сжатия для оптимизации бизнес-процесса.

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

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

Таблица 2. Мероприятия по оптимизации бизнес-процесса.

Схема бизнес-процесса, полученного по результатам оптимизации, представлена на рис. 7.

Диаграмма по времени выполнения задач бизнес-процесса «Как должно быть» (прогноз) показана на рис. 8.
Нормативное время выполнения процесса – 0,8 часа (сокращение в 3,4 раза).
Прогнозируемое календарное время выполнения процесса (с учетом установленных SLA – максимальное время реагирования на поступившую на выполнение задачу) – 4,3 часа (сокращение в 7,4 раза).
Оценить повышение качества расчета можно будет только набрав определенную статистику выполнения бизнес-процесса после внедрения всех мероприятий по его оптимизации и автоматизации.

Резюме

Мы рассмотрели несколько методов анализа, принципы оптимизации и применили их на условном примере бизнес-процесса формирования некоторого расчета (сметы, скидки, бюджета проекта и т.п.).
Качественная графическая схема является хорошим инструментом структурирования ваших знаний о бизнес-процессе. Если вы используете инструмент, например Business Studio 5, то эти знания можно формализовать непосредственно в системе и сделать доступными в виде гипертекстовой информации на внутреннем web-портале (с использованием технологии BS Portal).
В случае, если руководители компании заинтересованы в развитии системной практики работы с бизнес-процессами, целесообразно формализовать ряд методов анализа процессов, обучить руководителей и сотрудников этим методам и активно использовать при выполнении проектов описания, анализа, оптимизации и автоматизации бизнес-процессов.

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»

Апрель 2021 г.

В статье представлены результаты имитационного моделирования процесса «Рассмотрение и согласование оперативных заявок» в среде 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 тыс. рублей.

Кстати, после оптимизации процесса операция «Оформить оперативную заявку» перестала быть самой дорогой…

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

В следующей таблице показано сравнение двух вариантов: «нагруженного» корректными заявками процесса «как есть» и процесса после оптимизации.

Таблица. Сравнение процессов «как есть» и «как должно быть».

Таким образом, потенциальный годовой эффект от оптимизации процесса «Рассмотрение и согласование оперативных заявок» может составит 2,57 млн. рублей.

Если предположить, что автоматизация этого процесса в BPMS (включая стоимость лицензий и настройку) одновременно с автоматизацией в функциональной информационной системе составит 300 тыс. рублей (процесс, в общем-то, простой), то эффективность такого проекта составит 856%. Даже если взять в расчет риски ошибок в расчетах и увеличения стоимости работ по проекту, эффект все равно может быть достаточно велик.

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

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Ю.А. Федосеев
Начальник отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

Декабрь 2018 г.

В условиях кризиса сокращение численности персонала является одним из факторов выживания компании. Но необоснованное сокращение численности существенно увеличивает риски не выполнения процессов в срок и с нужным качеством. А это может привести к потере клиентов, сокращению выручки и, как следствие, к банкротству организации. Может ли руководитель опираться на простую формулу для расчета численности персонала? Какова вероятность принять неправильное управленческое решение? Как можно использовать процессный подход и имитационное моделирование бизнес-процессов для определения оптимальной численности персонала? В статье Владимира Репина обсуждаются эти вопросы на примере моделей процессов, разработанных в среде Business Studio 4.0.

Введение

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

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

«Простой» процесс

На рис. 1. показан простейший бизнес-процесс. Он заключается в том, что три сотрудника, находящиеся на различных должностях, последовательно выполняют три операции по созданию документа для внешнего заказчика: находят нужную информацию, подготавливают и передают заказчику некоторый документ. Каждая операция (согласно хронометражу) длится 10 минут. Заявки от заказчиков поступают равномерно с интервалом в 5 минут (всего около 2000 заявок в месяц). Получится ли у нас рассчитать на пальцах, сколько сотрудников нужно для подготовки документов? Основным ограничением является срок подготовки документа – «в течение 1 рабочего дня с момента подачи заявки». Давайте попробуем. Полезное время работы сотрудника – 22860 минут = 10560 минут. Время, требуемое одному сотруднику для обработки заявки, составит 2000*10 минут = 20 000 минут. Очевидно, что нужно иметь двух сотрудников на должности А, чтобы обработать все заявки.

Посмотрим теперь, что будет в реальной ситуации. Для этого опишем рассматриваемый бизнес-процесс и проведем его имитационное моделирование в среде Business Studio 4.0. Для начала, пусть на каждой должности находится по одному сотруднику.

Результаты имитации процесса показывают (см. рис. 1), что в феврале 2015 года на вход процесса поступило 1920 заявок. Из них только 958 (почти 50%) было выполнено к концу месяца. На первой операции процесса возникла очередь длинной 6 дней 16 часов. Наши расчеты «на пальцах» подтвердились. Давайте посмотрим, что будет, если увеличить численность всех сотрудников вдвое. На рис. 2. показаны результаты соответствующей имитации.

На рис.2 видно, что практически все заявки были выполнены. Длина очереди почти нулевая. Это означает, что численность по два сотрудника на каждой должности является оптимальной численностью для получения результата данного процесса (документ выдается «в течение 1 рабочего дня с момента подачи заявки» и даже быстрее). При этом мы, конечно, не учитывали прогулы, пьянки и беременность.
Любой скажет, что такие расчеты легко сделать безо всякого описания и имитационного моделирования процесса. Безусловно, это можно сделать (в т.ч. учесть % неявки персонала на работу, беременность и другие факторы при помощи коэффициентов, как это делают опытные нормировщики). Но давайте посмотрим, можно ли будет так просто выполнить расчет в более реальной практической ситуации.

«Сложный» процесс

Усложним процесс следующим образом:

1. заявки поступают неравномерно в течение дня;
2. операции процесса выполняются не точно 10 минут, а их длительность имеет некоторое распределение (минимум – 6, максимум – 14 минут);
3. существует определенный уровень «брака» при подготовке документов – 5% (выявляется потребителями при получении документов).

На рисунках 3, 4 и 5 показаны распределения соответствующих параметров, используемых при имитации.

На рис. 3. видно, что пиковая нагрузка приходится на три часа дня.

В целом, распределения на рис. 3 и 4 подобраны так, чтобы общее количество заявок в месяц составляло около 2000, как и в предыдущем случае.

На рис. 5. показано распределение времени выполнения операций процессов. Видно, что матожидание времени выполнения составляет 10 минут.

Вопрос. Кто-то может рассчитать «на пальцах» по простой формуле, сколько сотрудников потребуется для результативного выполнения такого процесса? Вряд ли… Кто-то скажет, что можно сделать расчет «по среднему», но он не будет учитывать пиковые нагрузки, которые для реального бизнеса и представляют наибольший интерес… И это только один простейший процесс. А сколько в организации сложных процессов? Обосновывая численность персонала по формуле, мы можем допустить ошибку, которая приведет либо:
А) потерям из-за избыточного количество сотрудников;
Б) снижению результативности бизнес-процессов, недовольству клиентов и т.п.

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

На рис. 6 видно, что к сотруднику, выполняющему операцию «Находит нужную информацию» стоит очередь из заявок, длинна которой на конец месяца составляет немногим более 2 дней. Т.е. мы не выполняем требования «В течение 1 рабочего дня с момента подачи заявки». Попытаемся увеличить численность сотрудников до 9 человек. На рис. 7. показаны результаты соответствующей имитации.

На рис. 7 видно, что при численности 9 человек (3 человека на каждой должности), очереди заявок практически нет.

Давайте предположим, что нам удалось провести работы по улучшению процесса, которые обеспечили:
1) сокращение среднего времени выполнения каждой операции процесса на 30%;
2) сокращению уровня брака до 1%.

Результаты имитации оптимизированного процесса показаны на рис. 8.

На рис. 8. мы видим, что очереди вообще нет. В связи с этим возникает подозрение, что сотрудники недостаточно загружены работой. Действительно, если посмотреть график работы сотрудника, занимающего должность С (рис. 9) видно, что он недостаточно загружен в первой половине дня, т.е. до пиковой нагрузки. Возникают мысли, как организовать работу так, чтобы в первой половине дня выводить меньше сотрудников и устранить соответствующие потери. Но это уже совсем другая история…

Выводы

В данной статье мне хотелось обратить внимание читателя на следующие моменты:

1. определение численности персонала «на пальцах» (по формуле с коэффициентами) может приводить к ошибкам и, как следствие, к росту потерь. Необоснованное сокращение численности персонала может нанести вред организации;
2. описание и анализ процессов (в т.ч. имитационное моделирование) дают возможность обосновать меры по их оптимизации;
3. методы и инструменты описания и анализа процессов должны использоваться в организации единой командой, состоящей из:
   a. руководителей подразделений (постановка задачи, обеспечение информацией, организация работ, анализ процессов и принятие решений по оптимизации, организация и контроль реализации решений);
   b. бизнес-аналитиков (описание процессов, имитационное моделирование, анализ процессов, разработка мероприятий по оптимизации);
   c. специалистов по нормированию труда (сбор данных для формирования имитационной модели, анализ результатов имитации процесса, участие в разработке мер по оптимизации).

В.В. Репин,
к.т.н., доцент,
тренер, консультант,
Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

Январь 2015 г.