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

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

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

Анализ процессов — это первый шаг к визуализации, совершенствованию и управлению процессами, именно поэтому анализ процессов набирает популярность, как показано на рисунке 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!

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

«Классический» взгляд на бизнес-процесс

Довольно долгое время я использовал в своей работе, методических и учебных материалах следующую картинку (рис.1), при помощи которой пояснял определение бизнес-процесса и обсуждал основные сущности, из которых он состоит. Чертеж является оригинальным скорее с точки зрения дизайна, чем содержательно. В стандартах СМК, во многих учебниках и публикациях других авторов типовую схему процесса представляют именно так.

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

Собственник компании внедрил в организации процессный подход и гордо рассказывает руководителю другой, дружественной компании о том, что у него любой сотрудник знает, что такое процесс. Тот спрашивает: «А как ты это докажешь?». В ответ собственник говорит: «Идем в любой отдел и спросим любого сотрудника». Так и они и сделали. Зашли в первый попавшийся кабинет и собственник спросил одного из сотрудников: «Скажи-ка, любезный, что такое «Процесс»?». Сотрудник вскочил со своего места и выпалил: «Это то, что имеет вход и выход!».

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

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

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

«Полная» модель бизнес-процесса

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

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

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

Если смотреть на процесс с точки зрения собственника или владельца процесса, то анализ схемы лучше начинать сверху. В первую очередь, для собственника важен бизнес-результат процесса. Что это за сущность? Давайте обсудим на примере процесса «Продажи». Что является бизнес-результатом этого процесса? Когда я задаю такой вопрос на тренингах, как правило, слушатели всегда в начале отвечают: «Прибыль». Это ошибка. Компания может иметь большую выручку, но работать в убыток, без прибыли. Кроме того, на прибыль влияют не только продажи, но и производство, сервис и прочее – затратная часть.

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

Таблица 1. Процесс «Продажи». Пример.

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

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

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

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

Так же важным является определение ограничений при выполнении процесса и разработке его новых версий, например, «Полное импортозамещение» в закупках, «При подборе персонала на руководящие должности — в приоритете свои работники» для управления персоналом и проч.

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

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

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

Выводы

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter, Процессный методолог проектов «КИС» и «АРС».

Май 2024 г.

www.bpm3.ru

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

Введение. Что понимается под операционной эффективностью?

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

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

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

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

На каждый процесс тратятся ресурсы. Но вот насколько бизнес-результат таких процессов покрывает эти затраты? Например, бизнес-процесс формирования претензии поставщику в крупной организации требует значительных ресурсов (в первую очередь, — это рабочее время специалистов и руководителей), но вот окупается ли он? Например, выполнение одного экземпляра такого процесса обходится компании в 50-60 тысяч рублей, а убыток (неустойка) по претензии составляет всего 30 тыс. рублей. Насколько это рентабельно или эффективно? Ответ очевиден, но что с этим делать? Варианта три: 1) отказаться от выставления претензий, начиная с определенной суммы (при этом, вносить соответствующих поставщиков в «черный список»); 2) радикально изменить процесс работы с претензиями, повысив его эффективность; 3) сознательно смириться с возникающими потерями (худший вариант). Но, сначала необходимо научиться считать стоимость процессов, как минимум. А чтобы считать их стоимость, процессы надо научиться ранжировать по их ресурсоёмкости и влиянию на результат, конечный продукт, потому что одновременно описать и смоделировать все процессы невозможно.

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

Некоторые тренды

Какие методы используют компании для повышения операционной эффективности? Обратимся к результатам исследования, которое ежегодно проводит The Process Excellence (PEX) Network — глобальное сообщество, включающее более 190,000 BPM-профессионалов и руководителей, которые хотят улучшить свой бизнес благодаря реализации процессного подхода к управлению и совершенствованию операционной деятельности компании. Исследование за 2023 год было переведено российской компанией Comindware в рамках сотрудничества с PEX Network. В статье мы приведем лишь несколько ключевых графиков.

На рис. 1 представлены методологии и решения, которые компании (преимущественно, североамериканские) используют для повышения операционной эффективности.

Согласно исследования PEX, 39% респондентов применяют методы бережливого производства (3-е место). На втором месте — методы бизнес-анализа и анализа данных (41%). На первом (47%) — методы управления изменениями. Что интересно, BPM (Business Process Management) используют только 32% опрошенных компаний.

На рис. 2 представлена информация о том, в какие решения компании планируют инвестировать деньги. На первом месте (41%) – Бизнес-анализ и анализ данных. Вполне очевидно, что именно эти методы могут позволить быстрее осуществлять цифровую трансформацию, создавая новые программно-аппаратные решения для повышения операционной эффективности. На втором месте (35%) – Искусственный интеллект, использование которого однозначно является ключевой составляющей цифровой трансформации. На третьем месте (33%) – собственно сама цифровая трансформация. На четвертом (31%) – просто автоматизация процессов. Моделирование процессов и Business Process Management почти делят 4-ое место.

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

Глядя на рис. 2, важно почеркнуть, что компании планируют инвестировать, в первую очередь, в бизнес-анализ, затем искусственный интеллект, цифровую трансформацию (частью которой, собственно, и является искусственный интеллект), автоматизацию рабочих процессов (Work Flow), моделирование и BPM в целом.

Хайп-лин, бережливый BPMN и прочие «диковинные звери»

Практика российских компаний, судя по многим известным нам проектам, запущенным в крупных и средних компаниях, а так же результатам ежегодного конкурса «BPM-проект года» (проводится ABPMP Russian Chapter), подтверждает рейтинг методов повышения операционной эффективности, представленный на рис. 1. Сегодня стало модно использовать термин «Бережливое управление», особенно в гос. компаниях. Этот подход рассматривается некоторыми как главная методология повышения операционной эффективности.
Когда говорят «Бережливое», то подразумевается группа методов Lean, хотя, перевод «Бережливое» не передаёт заложенных оттенков смысла и многими руководителями воспринимается дословно. Методы Lean, все-таки, относятся к 70-80-ым годам 20 века. У кого-то они работают, но для современной компании цифровая трансформация бизнеса может дать намного больше преимуществ.

Но что мы наблюдаем сейчас в российской практике? У нас много компаний и профессионалов, которые системно внедряют TPS (Toyota Production System), преимущественно на производствах. Авторам приходилось видеть практически идеально внедренную TPS на российских машиностроительном производстве, заводе металлоконструкций и проч. Но при этом бизнес-процессы в области оперативного управления, маркетинга, продаж и закупок, управления финансами и персоналом оставляли желать лучшего.

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

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

Возникающая в компании «движуха» обставлена всеми необходимыми атрибутами Lean: созданием команд, лозунгами, стендами с огромными картами процессов и проч. Да, где-то это дает эффект, но, повторимся, системные изменения в компании не происходят. Зато у руководителей есть, что показать Совету директоров или вышестоящей организации (особенно важно для гос. органов): красивые презентации по результатам проекта. Это симулякр, имитация, «Карго-культ». Мы называем такое явление – «Хайп-Lean». То есть, этто — не настоящий, системно внедряемый Lean (и тем более TPS), а его внешняя имитация. Это болезнь. И первый шаг к ее успешному лечению – назвать вещи свои именами.

Нас не удивит, если в ближайшее время на рынке появятся «новые» концепции, обещающие руководителям компаний очередные быстрые и легкие победы, например: «Бережливый BPM, включая бережливый BPMN», «Бережливая цифровизация», «Цифровой Lean», «Тощий CRM» и тому подобные диковатые монстры – плоды некорректных маркетинговых «генетических» экспериментов.

Так какой же метод можно взять в качестве базы, платформы для системного повышения операционной эффективности бизнеса?

BPM – как ключевой метод повышения операционной эффективности бизнеса

BPM – Business Process Management, как совокупность принципов, методов, инструментов и компетенций в настоящему времени уже стал вполне сложившимся, зрелым. Для первичного знакомства с ним можно обратиться к русскому переводу книги «BPM CBOK 4.0: Свод знаний по управлению бизнес-процессами». Как же BPM помогает развивать организацию?

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

СУБП организации основана на совокупности знаний и методов BPM. Процессный офис отвечает за внедрение СУБП в организации. Как же можно представить себе структуру этой системы? Мы предлагаем следующий возможный взгляд:

1. Архитектура бизнес-процессов.
2. Управление бизнес-процессами по целям и показателям.
3. Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ (KPI).
4. Практика описания и анализа бизнес-процессов.
5. Практика оптимизации бизнес-процессов и внедрения изменений.
6. Автоматизация бизнес-процессов (в BPMS).
7. Стандартизация бизнес-процессов.
8. Контроль и аудит бизнес-процессов.
9. Корпоративная система обучения персонала методам процессного управления.
10. Процессный офис.

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

Ключевым элементом, базой СУБП является Архитектура бизнес-процессов компании. Очевидно, что она является важнейшей частью общей корпоративной Архитектуры, для построения которой можно применять методологию ArchiMate и, например, современный российский программный продукт Business Studio 6, моделируя все необходимые аспекты: от заинтересованных сторон и их целей, цепочки создания ценности и компетенций бизнеса, до операционных процессов в нотации BPMN, технологической платформы и структуры используемых данных.

Подход BPM и СУБП, как его практическая реализация в конкретной компании, позволяют комплексно решать задачу повышения операционной эффективности. Но как именно? Как проектировать эффективные бизнес-процессы? BPM хорош тем, что он интегрирует в себе лучшие методы проектирования и внедрения эффективных бизнес-процессов:

• научные методы (в т.ч. основанные на теории очередей и систем массового обслуживания);
• методы регулярного менеджмента (четкие зоны ответственности исполнителей, стыковка по входам/выходам, идентификация и прослеживаемость и др.);
• методы оптимизации технологии выполнения процесса (устранение узких мест, устранение избыточного контроля и ненужных согласований, распараллеливание работ и прочие);
• методы поиска и устранения потерь (Lean);
• методы анализа рисков и проектирования робастных процессов;
• методы автоматизации (в СЭДО, BPMS);
• методы цифровизации (BI, RPA, «нейронка» и другие).

Проектируя исполняемый процесс в современной нотации BPMN (стандарт ИСО с 2013 года) вы можете использовать любые доступные и понятные команде проекта методы анализа и разработки эффективных бизнес-процессов. При этом именно BPM, как платформа, объединяет, интегрирует различные подходы и методы. Возникает необходимость в тесном сотрудничестве специалистов различных направлений: менеджеров по трансформации, бизнес-аналитиков, специалистов по Lean, профессионалов в области цифровизации и прочих. Это дает синергетический эффект. Другим словами, когда вы оптимизируете бизнес-процесс, вы не просто устраняете потери, которые лежат на поверхности («Хайп-Lean»), но проектируете новый, совершенный процесс, обладающий высокой операционной эффективностью. Фрагментарные улучшения не позволяют оценить процесс в целом, систему (архитектуру) процессов, — тем более. Они «перегоняют» узкие с одного места в процессе в другое, подобно, как воздушные пузыри при наклеивании плёнки на стекло.

Приведем свежий практический пример. В условиях импортозамещения одной организации необходимо было перейти с Axapta на 1С-ERP. Руководителем была поставлена задача описать задачи, «которые выполняются в Axapta». Однако, мы подошли шире и, с использованием нотации BPMN и инструмента Business Studio, сформировали полное описание группы процессов «Как есть». Сразу стало очевидно, что при выполнении процессов возникают потери: ручные операции, перегрузки из системы в систему и проч.

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

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

Выводы

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

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

Если у вас еще не создан Процессный офис и СУБП, то целесообразно обратить внимание на концепцию и методы BPM, заняться системным внедрением методов проектирования и управления бизнес-процессами. Это приведет к заметному, а главное, — постоянному росту операционной эффективности вашей компании.

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

А.Е. Манюхин,
консультант по управлению, партнер BPM3.RU

Январь 2024 г.

www.bpm3.ru

В статье описан реальный проектный опыт внедрения процессного подхода в компании «Фронтсайд» с применением программного продукта Business Studio, приведены примеры моделей бизнес-процессов, а также результаты проекта.

Компания «Фронтсайд»

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

Начало проекта

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

В ноябре 2022 года был запущен проект по внедрению процессного подхода с применением программного продукта Business Studio.

Целями проекта являлись:

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

Спонсором проекта выступил генеральный директор Дмитриев А.В., руководителем проекта была назначена Котик Н.П., были выбраны эксперты Теплова Е.Б., Дворецкий С.А, а также приглашены консультанты Репин В.В. и Калошина Л.Н.

Разработка архитектуры и моделирование бизнес-процессов

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

Затем ключевые специалисты были обучены работе в Business Studio на популярном тренинге В.В. Репина «Business Studio 5: моделирование, анализ и регламентация бизнес-процессов».
Задачей ключевых сотрудников было непосредственное описание, моделирование и анализ бизнес-процессов компании в программном продукте Business Studio, а также дальнейшее обучение рядовых сотрудников.
Для моделирования бизнес-процессов верхнего уровня была выбрана нотация IDEF0. Данная нотация используется для создания функциональной модели, отображающей структуру и процессы системы, а также потоки информации и материальных объектов, связывающие эти процессы. На схеме, смоделированной в IDEF0, наиболее наглядно можно отобразить входы, выходы, управляющие воздействия и механизмы бизнес-процесса.

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

1. Рыночная информация (поступающая с Рынка).
2. Потребность в товарах и услугах (поступающая от Клиентов).
3. Сырье и сервисы (от Поставщиков).
4. Человеческие ресурсы (поступающие из Общества).
5. Финансовые ресурсы (от Собственников).

В результате осуществления деятельности определены следующие выходы:

1. Информация для рынка (передается на Рынок).
2. Товары и услуги (для Клиентов).
3. Потребность в сырье и сервисах (передаются Поставщикам).
4. Специалисты (возвращаются в Общество).
5. Возврат инвестиций (Собственникам).

Управляющее воздействие на осуществление деятельности компании оказывают:

1. Видение и цели Собственников.
2. Эстетические нормы Общества.
3. Законы, нормы и правила Государства.

Далее архитектура бизнес-процессов «Фронтсайд» была декомпозирована на 7 подпроцессов (рис.2):

1. Управление бизнесом компании «Фронтсайд».
2. Маркетинг.
3. Продажи.
4. Исполнение заказов.
5. Обеспечение операционной деятельности.
6. Обслуживание производственной инфраструктуры предприятия.
7. Управление техническим развитием и обеспечение качества.

Бизнес-процесс «Исполнение заказов» состоит из пяти ключевых для бизнеса блоков:

1. Управление исполнением заказов.
2. Снабжение.
3. Производство.
4. Складская логистика.
5. Транспортная логистика.

Вовлечение сотрудников в проект

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

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

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

Оптимизация бизнес-процессов «На ходу»

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

При таком подходе важно сразу оценить, как предложенные изменения повлияют на другие бизнес-процессы. Поэтому руководитель проекта принимал решения по каждому конкретному предложенному случаю и направлению. Где-то было принято решение моделировать процессы «as is», где-то «to be», а если были выявлены процессы, которых нет, но в разработке которых нуждается компания, то они были включены в план моделирования.

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

Моделирование бизнес-процессов в нотации BPMN

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

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

Пример бизнес-процесса

При моделировании бизнес-процесса «Контроль исполнения договора поставки» (рис. 4) эксперты отмечали, что все семь типов договоров контролируются совершенно по-разному, за них отвечают разные специалисты, поэтому будет семь совершенно разных бизнес-процессов Контроля исполнения Заказов поставщиков (по типам договоров).

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

Особенности выполнения проекта

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

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

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

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

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

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

Котик Н.П., Директор по развитию компании «Фронтсайд»: «…Без методов бережливого производства процессный подход, как мне кажется, работает не так эффективно. Модель без использования инструментов бережливого производства будет не оптимальной. Это очень кропотливая и длительная работа, которая позволяет увидеть каждую мелочь, каждое несовершенство процесса, зафиксировать инциденты. В общем виде процессный подход и бережливое производство – про то, как выстроить процесс и найти потери…»

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

Достигнутые результаты

Проект внедрения Системы управления бизнес-процессами в компании «Фронтсайд» продолжается. Но уже можно говорить, что были достигнуты следующие ключевые результаты:
• Построена архитектура бизнес-процессов компании в нотации IDEF0. Модели декомпозированы до процессов в нотации BPMN.
• Были внесены изменения в организационную структуру предприятия.
• Внутри компании сформировалась крепкая команда единомышленников, которые готовы внедрять улучшения в свои процессы. Те сотрудники, которые не поддерживают улучшения, не готовы меняться сами и менять свои процессы, покинули компанию. Из положительных моментов также можно отметить обновление персонала.

Трудности и рекомендации

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

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

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

Котик Н.П.,
Директор по развитию компании «Фронтсайд»

Калошина Л.Н.,
Ведущий консультант по бизнес-процессам команды BPM3.RU

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

Сентябрь 2023 года

В статье Андрея Манюхина приводятся примеры визуализации процессных моделей как в общепризнанных нотациях в среде  Business Studio, так и в свободных нотациях. Разбираются плюсы и минусы, условия применения тех или иных способов визуализации процессных моделей.  Статья адресована как бизнес-аналитикам, так и менеджерам, которые интересуются процессным управлением.

Введение

Современные условия характеризуются слабым представлением бизнес-заказчиков о профессиональных стандартах для специалистов в области описания и оптимизации бизнес-процессов. В этой связи хочется напомнить о существовании такого стандарта (https://abpmp.org.ru/resource/profstandard/). Много «около-процессных» специалистов заявляют об оптимизации бизнес-процессов: в последнее время набирают популярность, так называемые, «подразделения операционных улучшений», которые обычно занимаются точечными фрагментарными улучшениями на уровне операций, но преподносят это как бизнес-процессы. В результате, бизнес-заказчик теряется в многообразии методов, часто разочаровывается, появляется предвзятое негативное отношение к описанию и оптимизации бизнес-процессов, в их настоящем понимании.

Команда консультантов BPM3.RU имеет обширную практику построения процессных архитектур и в данной статье автор делает попытку систематизировать подходы и предоставить читателю наиболее оптимальные для каждой конкретной ситуации.

Правильный подход, ставший классикой

Рассмотрим построение процессной архитектуры на примере процессной модели закупок для операционной деятельности. Данная модель создана мной на основе практик российских и зарубежных производственных компаний в учебных целях. Модель создана с точки зрения директора по закупкам. На рис.1 представлена контекстная диаграмма (А-0).

Понимая окружение (контекст) процесса операционных закупок, декомпозируем процесс на 6 процессных категорий (групп процессов), как показано на рис.2.

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

• Единый владелец группы процессов,
• Единый результат (выход) группы процессов.

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

Процессная модель операционных закупок в виде реестра представлена на рис. 3.

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

В реестре расписаны варианты проведения аварийной закупки, их восемь, далее я указал количество вариантов по каждому типу закупочной процедуры. В итоге, по закупке товаров получается 44 сценария, плюс – столько же по услугам. Итого, получается 88 (!) сценариев и, соответственно, процессов. Очевидно, что ряд подпроцессов будет дублирован n количество раз. Хорошо, что я семантически верно обозначил эти процессы, на практике бывает, что так чётко названия не обозначают, и появляется сотня процессов, найти нужный из которых можно только путём последовательного перебора… Такие решения часто понятны только их создателям. А бизнес-заказчик всегда одной из важных целей ставит порядок и прозрачность процессов и зон ответственности…

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

Тот же самый процесс с помощью ссылок можно сделать в нотации BPMN, как показано на рис.6.

В реестре обычно для таких процессов завожу папку «Типовые цепочки процессов (on-demand chains of models)», как показано на рис.7.

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

Несомненными плюсами такого подхода являются: 1) возможность представления архитектуры процессов, сгруппированной в логике цепочки создания ценности с отражением владельцев групп процессов, 2) возможность представления архитектуры процессов в виде сценариев, последовательности запуска тех или иных процессов. Оба представления, как показывает практика, востребованы бизнес-заказчиками.

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

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

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

Сценарий закупки у единственного поставщика представлен на рис.9.

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

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

Выводы

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

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

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

А.Е. Манюхин,

МВА, консультант по управлению

Май 2023 г.

www.bpm3.ru

В статье Владимира Репина приводятся примеры моделей бизнес-процессов «As is» («Как есть»), «To be Medium» («Как должно быть, переходная»), «To be Max» («Как должно быть, целевая») в нотации BPMN в Business Studio. Представленный методический подход к описанию процессов позволяет визуально увидеть переход от существующей ситуации к перспективной. Это важно для собственников и руководителей организации для решения задачи обоснования изменений и планирования автоматизации и цифровизации бизнес-процессов организации.  

Введение

Описание бизнес-процессов «As is» («Как есть») является отправной точкой для оптимизации и автоматизации бизнес-процессов организации.

Важно отметить, что эту работу нужно делать с точки зрения бизнес-заказчика, а не программиста. Процесс должен быть описан целиком со всеми его нюансами, а не только действия, выполняемые сотрудниками, например, в 1C-ERP или СЭД. Ограниченная точка зрения на процесс может привести к тому, что не будут выявлены значимые проблемы и выработаны адекватные решения по его изменению.

Для решения указанной задачи должен использоваться адекватный метод, позволяющий четко определять на схемах процессов:

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

Команда консультантов BPM3.RU выработала свой методический подход к разработке моделей в нотации BPMN в Business Studio. BPMN используется  как единый язык, понятный всем заинтересованным сторонам в организации.

Ознакомиться в нашим подходом можно в статьях «Моделирование информационных потоков в нотации BPMN в Business Studio 5» и «Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN».

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

Примеры моделей бизнес-процессов в нотации BPMN в Business Studio

На рис. 1 представлена модель бизнес-процесса заключения договора с клиентом «Как есть». Ключевые особенности этого процесса:

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

Видно, что процесс выполняется с использованием MS Outlook и вручную.

Одним из подпроцессов является процесс «Согласование договора с клиентом». Он является типовым (повторно выполняемым). Модель «Как есть» этого процесса представлена на рис. 2. Процесс практически весь «ручной». По ходу его выполнения от задачи к задаче передается бумажный комплект документов.

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

Далее рабочая группа из специалистов продаж, юристов и консультантов команды BPM3.RU разработала несколько моделей нового процесса. Модель «To be Medium» (переходная) представлена на рис. 3.

Новый процесс целиком выполняется в информационной системе: 1C-ДО или BPMS. На схеме представлены комментарии, отражающие ключевые нюансы процесса.

Данная схема была использована в качестве Технического задания для подготовки прототипа исполняемого бизнес-процесса на платформе Elma-365.

Если сравнить рисунки 2 и 3, то изменения процесса очевидны. Руководители и специалисты, обученные нотации BPMN, сразу видят различия. Схема является удобным инструментом формирования ТЗ на автоматизацию – можно обойтись без длинного текстового описания требований, особенно в случае автоматизации процесса с использованием No-code/Low-code системы.

На рис. 4 показана модель бизнес-процесса «Согласование договора с клиентом» в версии «To be Max».

Особенностями модели «To be Max» (перспектива на 1,5-2 года) являются:

• использование Личного кабинета клиента для автоматического взаимодействия с организацией;
• полная автоматизация ряда задач в 1C-ERP;
• использование RPA-модуля (возможно, нейронной сети) для распознавания и сравнения версий договоров, получения/отправки договоров через «Контур.Диадок» и проч.

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

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

Сравнение моделей «As is», «To be Medium», «To be Max»: свет в окне

В таблице 1 приводится содержательное сравнение моделей «As is», «To be Medium», «To be Max», которое показывает, как изменяются бизнес-процессы при их трансформации из текущего состояния в перспективное.

Таблица 1.

Выводы

Моделирование бизнес-процессов от «As is» к «To be Medium» и «To be Max» в нотации BPMN в Business Studio дает руководителям компании такие преимущества, как:

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

Один из главных эффектов от описания процессов «As is», «To be Medium», «To be Max», во многом, психологический. Руководители смотрят на схемы и говорят: «А что, так можно будет?». Они видят, насколько изменится бизнес-процесс, станет меньше ручной, бумажной работы, возрастет скорость выполнения процессов, повысится эффективность.

Удачи в оптимизации и цифровой трансформации ваших бизнес-процессов!

В.В. Репин,

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

Май 2023 г.

www.bpm3.ru

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

Введение

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

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

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

Требования к графической схеме бизнес-процесса

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

Контекст – в компании создан Процессный офис, который использует программный продукт Business Studio для моделирования и анализа бизнес-процессов в нотации BPMN. Разработан и используется внутренний стандарт по описанию процессов («Соглашение по моделированию»).

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

Цель – выполнить описание и анализ бизнес-процесса «Как есть» для выявления возникающих проблем и разработки мероприятий по оптимизации/цифровизации бизнес-процесса, создания модели процесса «Как должно быть».

Важно отметить, что возможность визуального анализа определяется качеством и аналитической полнотой графической схемы. Логически некорректная модель с отсутствием какой-либо аналитики («Голый поток Work Flow») вряд ли подойдет для решения указанной выше задачи.

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

1. Отсутствие нотационных и логических ошибок.
2. Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем.
3. Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика).
4. Визуальная наглядность и красота схемы (стиль).

Кратко пройдемся по этим критериям. Отсутствие нотационных и логических ошибок является базовым требованием. Схема, содержащая ошибки, тем более, логические, — непригодна для анализа. Для формального контроля качества схемы можно использовать чек-лист, который может содержать, например, следующие разделы:
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий (стартовых, промежуточных, завершающих);
• логические ошибки;
• адекватное описание множества обрабатываемых в рамках процесса объектов;
• архитектурные ошибки (дублирование группы задач вместо использования «Типового процесса» и проч.);
• неоднородность по масштабу выполняемых задач;
• аккуратность исполнения схемы, наглядность.

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

Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика). Речь идет о том, что модель действительно соответствует процессу «Как есть», то есть содержит все реально выполняемые задачи без пропусков, упрощений и т.п.

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

Адекватная реальности семантика. Нотация BPMN является весьма сложной. Важно понимать, что она была разработана для проектирования исполняемых в BPM-системе процессов. Движок такой BPM-системы, если объяснять не уходят в технические детали, интерпретирует значки нотации BPMN определенным образом и генерирует исполняемый код без участия человека. При исполнении бизнес-процесса в BPM-системе семантика графической схемы реализуется через соответствующий функционал. Например, могут быть использованы такие решения, как: межпроцессное взаимодействие путем отправки/получения сообщений, граничные события различного типа, завершение процесса типа «Terminate», триггеры, сигналы, компенсации и прочее.

Но в реальном, неавтоматизированном бизнес-процессе (типичный пример: Outlook + функциональная система) ничего этого нет – передача информации, остановки, уведомления осуществляются вручную сотрудниками. Поэтому схема бизнес-процесса «Как есть», созданная бизнес-аналитиком с использованием сложной семантики BPMN, реализуемой только в BPM-системе, в действительности не соответствует реально выполняемому процессу. При чтении такой схемы совершенно непонятно, как выполняется процесс в действительности.

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

Если цель – создание модели бизнес-процесса для исполнения в конкретной BPMS, то создавать эту модель «Как должно быть» нужно понимая, какой конкретно функционал имеет система, то есть какие возможности нотации BPMN она поддерживает.

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

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

Какие проблемы можно выявить, анализируя схему бизнес-процесса?

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

• Технология выполнения процесса: некорректный состав, последовательность выполнения задач процесса, дублирование, отсутствие бизнес-правил.
• Дезинтеграция процесса по информационным системам (ручной перенос информации (документов) из системы в систему).
• Потеря важной информации (документов) при выполнении процесса.
• Отсутствие необходимой интеграции между процессами.
• Возвраты, излишние согласования.
• Узкие места.
• Задачи, не добавляющие ценность, потери.

Ниже рассмотрим каждую из указанных видов проблем.

Технология выполнения бизнес-процесса

Пример. Коллеги из довольной крупной компании разработали схему процесса «Создание, согласование и закрытие заявки на подбор» — см. рис. 3.

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

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

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

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

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

Еще один пример отсутствия бизнес-правила представлен на рис. 5. Менеджеры работают с заказчиками по-разному. Ряд заказчиков подписывает договор и присылает его скан, ряд – нет. Четко не определено, должны ли менеджеры требовать от заказчиков присылать подписанные сканы договоров или достаточно версии в формате MS Word и протокола разногласий и т.д.

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

Дезинтеграция процесса по информационным системам

На том же рис. 6 видно, что бизнес-процесс не интегрирован по информационным системам – наблюдается ручная передача информации в Outlook, ручная выгрузка из АСУ в MS Excel, потом в MS Word, сохранение в pdf-формат, звонки и e-mail-ы клиентам.

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

Потеря важной информации (документов) при выполнении процесса

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

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

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

Отсутствие необходимой интеграции между процессами

На рис. 7 показан фрагмент бизнес-процесса приемки товара на склад гипермаркета торговой сети. В случае, если количество мест больше, чем указано в накладной, кладовщик «уведомляет менеджера по закупу» по яндекс-почте.

Но менеджер по закупку может: 1) случайно удалить письмо; 2) увидеть письмо со значительной задержкой; 3) отложить работу с поставщиков «на потом» без контроля сроков. Таким образом, проблема, возникшая в одном бизнес-процессе и нуждающаяся в решении, не связана с запуском на исполнение другого процесса. Кроме того, информации о проблеме не зафиксирована в системе и может быть потеряна.
Представленный выше пример весьма типичный. Очень часто можно увидеть на схемах ситуацию типа: «Уведомить менеджера…», «Переслать информацию в такой-то отдел» и т.п.

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

Возвраты, излишние согласования

При выполнении бизнес-процессов часто возникают возвраты. Например, на рис. 8 показан возврат на повторное согласование договора.

Чем плохи возвраты? Они: 1) многократно увеличивают длительность выполнения процесса; 2) увеличивают затраты; 3) могут негативно влиять на качество результата процесса; 4) негативно сказываются на отношении сотрудников к работе (бесконечные переделки и уточнения, повторное выполнение одних и тех же задач мало кому понравится).

В свое время Филипп Кросби, известный специалист в области менеджмента качества, сформулировал принцип «Делать всё правильно с первого раза». Почему же сотрудникам сложно его придерживаться? В чем причины возвратов? Думаю, в следующем. К ним приводят:
• нечетко поставленные задачи;
• недостаток информации у исполнителя;
• некачественные входы (информация);
• отсутствие методик/бизнес-правил у исполнителя;
• недостаточная квалификация исполнителя;
• ошибки («человеческий фактор»).

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

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

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

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

Не стоит исключать и человеческий фактор: физическая усталость, моральное утомление (например, в случае выполнения рутинной, монотонной работы по разнесению УПД из «Контур.Диадок» в 1C-ERP при крайне медлительной работе программы), негативное отношение к выполняемой работе и, в целом, — к компании, отсутствие лояльности и т.д.

Но в чем коренные причины указанных выше проблем? Кто виноват? Сами сотрудники? Нет. Еще дедушка Эдвардс Деминг, специалист мирового масштаба и отец новой философии управления, говорил, что 95% проблем, возникающих у сотрудников при выполнении процессов, обусловлены не плохим отношением людей к работе, а теми бизнес-процессами, системой, которую создали сами менеджеры компании.

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

Эту мысль ярко демонстрирует еще один пример, показанный на рис. 9. В рамках представленного бизнес-процесса исполнитель вносит изменения в некий важный и довольно сложный документ. Затем идет параллельное согласование его специалистами, а уже потом последовательное согласование руководителями.
На рис. 9 видно огромное количество согласующих лиц, причем после каждого руководителя процесс может вернуться к началу. Говорить о том, сколько времени занимает такое процесс, даже не хочется… В лучшем случае, в крупной компании – это месяцы.

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

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

Узкие места

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

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

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

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

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

Задачи, не добавляющие ценность, потери

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

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

Выводы

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

1. чек-лист формального анализа качества графической схемы бизнес-процесса;
2. чек-лист содержательного анализа для выявления проблем и определения возможных мероприятий по оптимизации процесса.

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

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

Февраль 2023 г.

Вы можете посмотреть видео по данной теме:

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

Введение

В настоящее время моделирование бизнес-процессов в нотации BPMN является одним из инструментов, используемых в компаниях для понимания процессов «Как есть», разработки мероприятий по их оптимизации/цифровизации, формирования регламентирующих документов. Многие компании используют для описания процессов современный программный продукт Business Studio 5.

Участие в большом количестве проектов, в которых выполнялось моделирование бизнес-процессов в нотации BPMN в Business Studio, а так же проведение аудита качества (формального и содержательного анализа) схем бизнес-процессов различных организаций, позволило мне сделать следующие выводы:

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

Важно отметить, что нотация BPMN в ее текущей версии не предназначена для адекватного моделирования потоков информации и межпроцессного взаимодействия с точки зрения отображения входов/выходов бизнес-процессов. Этот факт является существенным ограничением. Но проблема может быть решена с использованием функциональных возможностей Business Studio.

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

Постановка задачи

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

Первое. Точка зрения – руководитель 1-2 уровня компании, заинтересованный в оптимизации и цифровизации бизнес-процесса в целом. Обратите внимание, что точка зрения, например, ИТ-специалиста, ответственного за внедрение какой-либо информационной системы (ERP, ЭДО, CRM и проч.) может существенно отличаться от точки зрения руководителя, то есть от «бизнесовой» точки зрения.

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

Итак, схема бизнес-процесса в нотации BPMN в Business Studio 5 должна содержать:

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

Посмотрим, как можно решить указанную задачу средствами Business Studio 5. Разбирать метод будем на простом и наглядном примере.

Пример модели бизнес-процесса в нотации BPMN в Business Studio

На рис. 1 представлена простейшая схема подготовки, согласования и утверждения некоторого документа «Х». Это, можно сказать, «голый» поток работы (Work Flow). Есть ли компании, которые ТАК моделируют процессы? Как это ни странно, да, есть. Наблюдал в нескольких организациях. Отсутствие возвратов (после согласования/утверждения) и полное отсутствие информации/документов объясняют желанием «упростить» схему и сделать ее «наглядной» для бизнес-пользователей. При этом информацию «о действиях в случае отклонений» выносят в приложения к нормативному документу, а входы/выходы прописывают вручную прямо в самом проекте регламента, а не выгружают автоматически из Business Studio. Использование такого «ручного» труда, на мой взгляд, сродни покупке профессионального перфоратора, который потом не включают в розетку, а долбят дырки в стене вручную.

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

Что можно сделать с такой схемой? Прежде всего, отобразить реальный поток работы – возвраты после согласований.

На рис. 2. показана схема со шлюзами, которые нужны, чтобы показать возвраты после согласования в случае, если есть замечания/корректировки к проекту документа.

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

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

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

Моделирование информационных потоков на схемах в нотации BPMN в Business Studio

На рис. 3 показана схема с потоком документов, точнее, с движением одного документа (частный случай в рамках нашего учебного примера).
Для того, чтобы показать это движение, использована пунктирная стрелка типа «Association» (термин BPMN).

Если смотреть на схему непредвзято, с точки зрения здравого смысла, то можно задаться вопросом: «Дает ли наличие таких стрелок и значков «Документ “Х”» какую-то дополнительную аналитическую информацию?». Скорее «Нет», чем «Да». Но лишней работы по моделированию это добавляет точно. Возникает вопрос: «А может тогда лучше вообще не показывать эти документы»? Бизнес-аналитики некоторых компаний, которые моделируют движение документов на таком абстрактном уровне, постепенно вообще отказываются от визуализации документов на схемах.

Отмечу, что в проектах мы принципиально не используем справочник «Бумажные документы», только – «Электронные документы», чтобы не дублировать сущности. Так же не используем справочник «Информация». Почему? Любая информация в бизнесе, даже неструктурированное письмо по e-mail или сообщение по WhatsApp, может рассматриваться в качестве документа. Если в Business Studio одновременно использовать справочник «Электронные документы» и «Информация», то может возникнуть ненужная путаница.

С точки зрения анализа реального процесса «Как есть» схема рис. 3 опять неполна и не может быть эффективно использована. Что можно сделать?

На рис. 4 показаны статусы документов. Например, после задачи «Подготовить проект документа» Документ «Х» имеет статусы «Проект» и «Word». Они указывают на то, что документ создан в формате MS Word (статус – «Word») и готов для согласования (статус – «Проект»).

После задачи «Согласовать проект документа», Документ «Х» приобретает статусы «Несогласован» и «Word» или «Согласован» и 1С-ДО, то есть статусы определяются контекстно.

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

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

В справочнике «Термины» мы используем следующую группировку статусов (показаны примеры статусов):

1. По жизненному циклу документов:
   1.1. Проект
   1.2. Согласован
   1.3. Утвержден
   1.4. Подписан компанией
   1.5. Подписан клиентом
   1.6. …
2. По форме:
   2.1. Устно
   2.2. Бум.
   2.3. Excel
   2.4. Word
   2.5. e-mail
   2.6. Скан в pdf
   2.7. Скан скан-копии в pdf
3. Внутри ИС:
   3.1. 1C-ERP
   3.2. CRM
   3.3. Business Studio
   3.4. Контур.Диадок
   3.5. …
4. Формализован/неформализован:
   4.1. Неформ.
   4.2. Форма
   4.3. Шаблон

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

Моделирование ресурсов (хранилищ данных) на схемах в нотации BPMN в Business Studio

На рис. 5 показаны объекты типа «База данных» для того, чтобы показать, посредством какого ресурса (среды, хранилища) осуществляется переда документа от задачи к задаче.

Вообще, довольно часто бизнес-аналитики интерпретируют эти объекты как программное обеспечение (хотя для этого есть отдельный одноименный справочник в Business Studio). Это некорректно, на мой взгляд.

Что такое база данных в современных условиях? Можно ли использовать, например, SQL Server без необходимой для доступа к данным прикладной программной оболочки? Конечно, нет. Поэтому мы используем в проектах справочник «Базы данных» в широком смысле в качестве ресурсов – мест хранения документов (информации), например:

1. Корпоративные ресурсы:
   1.1. 1С
   1.1.1. 1С-ERP
   1.1.2. 1С-ERP-CRM
   1.1.3. 1C-ДО
   1.2. Архивы электронные
   1.2.1. Архив Бухгалтерии
   1.2.2. Архив Юр.службы
   1.2.3. …
   1.3. Архивы бумажные
   1.3.1. Архив Бухгалтерии
   1.3.2. Архив Юр.службы
   1.3.3. …
   1.4. Outlook
   1.5. Сервер
   1.6. WhatsApp
   1.7. ..
2. Персональные ресурсы:
   2.1. РМ сотрудника
   2.2. РС
3. Внешние ресурсы:
   3.1. ЭТП поставщика
   3.2. ЭДО
   3.3. …

На рис. 5 показано, что Документ «Х» передается от задачи «Подготовить проект документа» к задаче «Согласовать проект документа» посредством MS Outlook, то есть «временным прибежищем» для этого документа служит Outlook. Некоторые компании, кстати, умудряются до 80% всех рабочих документов хранить в Outlook, что является проблемой (путаница в версиях документов, долгий поиск, перегрузка сервера, риск потери важной информации и проч.).

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

Моделирование информационных систем на схемах в нотации BPMN в Business Studio

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

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

Информационные системы берутся из справочника Business Studio «Программные продукты», который может быть структурирован, например: так:

1. Офисное ПО:
   1.1. MS Office
   1.1.1. MS Word
   1.1.2. MS Excel
   1.1.3. MS Outlook
   1.1.4. …
2. Корпоративное ПО:
   2.1. 1C-ERP
   2.1.1. 1C-ERP-CRM
   2.1.2. 1C-ДО
   2.1.3. …
   2.2. Business Studio
   2.3. BI
   2.4. …
3. Специальное ПО:
   3.1. Контур.Диадок
   3.2. Контур.Фокус
   3.3. Telegram.Чат-бот
   3.4. ЭТП поставщика…
4. Сетевое и серверное ПО:
   4.1. …

В версии Business Studio 5 нельзя настроить визуальный размер и цвет значков выбранного типа один раз для всей рабочей базы. Это приходится делать вручную на каждой схеме. Мы делаем значок программного обеспечения в виде небольшого четырехугольника и закрашиваем его в «фирменный цвет» соответствующий информационной системы, например, 1С – в желтый.

Информационные системы (программные продукты) связываются с задачами двумя различными видами входящих связей:

• «Поддерживает» — в случае, если ИС используется сотрудником при выполнении задачи;
• «Выполняет» — в случае, если задача выполняется целиком автоматически.

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

В чем разница между информационными системами (программными продуктами) и ресурсами? Почему недостаточно использовать что-то одно? На рис. 6 видно, что для подготовки документа используется MS Word, а передается документ через MS Outlook. То есть представление информационных систем и ресурсов на схеме бизнес-процесса не дублирует друг друга, как может показаться на первый взгляд. Эти два аспекта дополняют друг друга и делают модель аналитически полной.

Зачем одновременно показывать на схеме информационные системы и статусы документов? Ведь и так «всё понятно»? Не всё так просто… Например, документ может быть подготовлен в 1С, выгружен в MS Word и доработан вручную, а потом в виде скана в pdf отправлен клиенту через WhatsApp. В данном примере для выполнения задачи использовалось три программных продукта, но ресурсом (хранилищем), использованным для отправки документа, был WhatsApp. Ресурсами, используемыми для хранения файлов MS Word и pdf, могли быть «РС» (т.е. жесткий диск компьютера сотрудника) или сервер компании.

Моделирование межпроцессного взаимодействия по входам/выходам на схемах в нотации BPMN в Business Studio

Моделирование потоков документов (информации) будет не полным, если не показать взаимодействие между разными бизнес-процессами по входам/выходам.

В нотации BPMN в Business Studio 5 для решения этой задачи можно использовать следующую конструкцию – см. рис. 7. Мы связываем бизнес-процесс «Подготовить данные для проекта документа “Х”» (показан на схеме как свернутый пул) стрелкой типа «Message Flow» с задачей бизнес-процесса «Подготовить проект документа». Такая связь в нотации BPMN означает отправку и получение сообщения. По сути, это управляющее воздействие одного экземпляра процесса на другой экземпляр. Но в Business Studio мы сознательно идем на нарушение стандарта и интерпретируем такую связь просто – один бизнес-процесс поставляет на вход другого бизнес-процесса документы (информацию).

Далее к стрелке «Message Flow» привязывается конкретный документ. На рис. 7 – это «Данные для подготовки документа “Х”». Статус показывает, что это документ в формате MS Excel, а привязанная «База данных» показывает, что ресурсом (хранилищем) для этого документа служит файл-сервер компании.

Таким образом, рассматриваемый контекст нужно читать так: «Бизнес-процесс «Подготовить данные для проекта документа “Х”» когда-то (вполне возможно, что намного раньше, чем стартовал процесс «Подготовить, согласовать и утвердить документ») в процессе своего выполнения создал файл MS Excel и положил его на файл-сервер. Через какое-то время процесс «Подготовить, согласовать и утвердить документ» при выполнении задачи «Подготовить проект документа» обратился к файл-серверу и взял оттуда этот документ.

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

На рис. 8 представлен пример схемы бизнес-процесса, разработанной с использованием представленного в статье метода.

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

Выводы

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

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

Однако, если вы хотите, чтобы ваши схемы бизнес-процессов «Как есть» в нотации BPMN в Business Studio 5 могли реально использоваться для анализа и принятия решений по оптимизации/цифровизации процессов, то представленный методический подход целесообразно использовать.

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

Удачи в проектировании подробных и практически полезных моделей бизнес-процессов в нотации BPMN в Business Studio!

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

Январь 2023 г.

Возможно, вам будет интересно посмотреть видео по этой теме: