Приоритетные бизнес процессы верхнего уровня компании - Контакты компаний и предприятий на Adresa.top

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

Количество процессов верхнего уровня

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

Правило 1. На верхнем уровне деятельность компании должна быть разбита на 15-20 бизнес-процессов верхнего уровня.

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

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

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

Практика показала, что при работе с процессами любая компания в итоге придет к 15-20 бизнес-процессам на верхнем уровне, которое, повторюсь, является оптимальным. Конечно есть небольшие компании, как например рассмотренная в части 5 компания «Видеомир», в которой было выделено 12 бизнес-процессов верхнего уровня. Также есть крупные компании, в которых приходится выделять много обеспечивающих бизнес-процессов, добавляя к типовому перечню такие обеспечивающие процессы как промышленная безопасность, экологическая безопасность, обеспечение электроэнергией и др. — в результате чего перечень процессов верхнего уровня может достигать количества 22-24 и даже выше. Но в среднем, как показывает практический опыт на верхнем уровне количество бизнес-процессов составляет значение 15-20.

Важность процессов верхнего уровня

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

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

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

Пример. В торговой компании, занимающейся дистрибуцией лекарств (подробнее сотрите часть 5) в группе управленческих бизнес-процессов имеется процесс по управлению товарным запасом (рис. 20). Ранее на верхнем уровне этого процесса не было, так как он входил в состав бизнес-процесса закупки лекарств и был на втором уровне. Однако, с этим процессом связаны три ключевые проблемы и соответствующие им ключевые показатели.
Первый проблемный ключевой показатель — это величина товарного запаса, который достигал значения 6 месяцев продаж. То есть на складе товара лежало на 6 месяцев продаж и склад за год оборачивался всего лишь 2 раза. Таким образом оборачиваемость товарного запаса были слишком низкой, а его величина и соответственно затраты на складирование и поддержание товарного запаса были слишком высокими.
Вторым проблемным ключевым показателем по товарном запасу, являлся ассортиментный дефицит, который в определенный периоды времени достигал значения 20%. Когда клиенты направляли в компанию заказы на поставку лекарств, то оказывалось что по 20% ассортиментным позициям, товар на складе отсутствует. Соответственно компания теряла выручку, а удовлетворенность клиентов снижалась, и они переключались на других поставщиков лекарств. Основной причиной большого ассортиментного дефицита было то, что отсутствующий товар негде было размещать на складе, так как склад был забит большим количеством другого товара. То есть основная причина была связана с большим товарным запасом.
И третий проблемный ключевой показатель — это доля неликвидной продукции, которая также была высокой. Под неликвидной продукцией в компании считались лекарства со сроком годности менее 6 месяцев. Такие лекарства приходилось продавать с существенными скидками, то есть неликвидная продукция быстро обесценивалась и приводила к финансовым потерям. Причиной большого количества неликвидной продукции, как и большого товарного запаса были излишние закупки.

Когда руководители компании изучали опыт работы дистрибьютеров лекарств в других странах, то увидели, что там средняя величина товарного запаса составляет 2 месяца продаж. То есть при одном и том же объеме продаж товарным запас был в 3 раза меньше и требуемый размер склада тоже, соответственно затраты на складирование и поддержание товарного запаса также в 3 раза были меньше. Также было понятно, что все три проблемы товарного запаса взаимосвязаны и что ключевая причина трех проблем связана с излишними закупками и отсутствию должной работы по управлению товарным запасом.
Сначала в торговой компании ответственным за эти показатели являлся отдел закупок, так как процесс по управлению товарным запасом входил в состав процесса закупок. Но отдел закупки не смог обеспечить улучшение этих трех ключевых показателей по двум причинам:
• отдел закупок был сконцентрирован на других своих основных процессах — это поиск поставщиков, формирование заказов на поставку, их отслеживание и др.;
• поставщики лекарств большими скидками стимулировали отдел закупок закупать в прок.
В итоге руководством компании было принято решение о выведении процесса по управлению товарным запасом на верхний уровень и назначении другого ответственного за этот процесс (владельца процесса). Теперь процесс по управлению товарным запасом непосредственно контролировал генеральный директор, а выполнением этого процесса занималась новая служба управления товарным запасом. Эта служба формировала отчетность по товарному запасу, анализировала ее и предлагала инициативы по оптимизации товарного запаса. Генеральный директор рассматривал эти отчеты и инициативы, принимал решения, а также контролировал как это влияет на ключевые показатели по товарному запасу. В результате этой работы в течение года все три проблемы по товарному запасу были устранены, а соответствующие три ключевых показателя были значительно улучшены.

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

Утверждение процессов верхнего уровня

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

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

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

Рис. 20. Карта процессов верхнего уровня торговой компании

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

Рис. 21. Карта процессов верхнего уровня производственной компании.

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

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

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

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

Рис. 22. Матрица распределения ответственности за процессы верхнего уровня производственной компании

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

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

* * *

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

Источник

Вход для
партнеров

Услуги и поддержка > Методические материалы

Технологии процессного управления

Консультация
по услугам 1С

Заявка на
авторский надзор
проектов

Заявка на услуги
ЦКТП

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

Шесть основных шагов

Классика построения организации

Можно сказать, что построение организации состоит из трех основных фаз: разработка стратегии, разработка бизнес-процессов и проектирование на их основе организационной структуры (рис. 1).

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

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

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

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

Рис. 1. Классика построения организации

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

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

Строим процессное управление

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

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

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

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

Рис. 2. Система процессного управления

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

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

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

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

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

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

Задачи, которое решает процессное управление

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

Оптимизация бизнес-процессов и улучшение их ключевых показателей (KPI):

повышение результативности;
снижение стоимости;
сокращение длительности;
повышение качества и уменьшение операционных рисков.

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

Десять решаемых задач

Ещё раз перечислим 10 основных задач, решаемых с помощью методов и инструментов процессного управления. Эти задачи взаимосвязаны и часто в проектах по описанию и улучшению бизнес-процессов решаются вместе.

Оптимизация бизнес-процессов и улучшение их ключевых показателей (KPI):

повышение результативности;
снижение стоимости;
сокращение длительности;
повышение качества и уменьшение операционных рисков.

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

В этой и следующей частях статьи каждую из этих 10 задач я рассмотрю подробнее.

Задача 1: Оптимизация бизнес-процессов и улучшение их ключевых показателей

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

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

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

Рис. 3. Базовые ключевые показатели бизнес-процесса

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

Задача 2: Прозрачность, контролируемость и управляемость бизнеса, наведение порядка, реализация стратегии

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

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

Рис. 4. Выделение бизнес-процессов и определение владельцев процессов

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

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

Задача 3: Построение эффективной организационной структуры, реструктуризация

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

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

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

Ещё пример: в другой компании перечень бизнес-процессов включал 36 различных процессов, связанных с закупками. А в организационной структуре эти процессы выполняли 36 различных отделов, которые были разбросаны по различным частям организационной иерархии. Не слишком ли много закупок?

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

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

Задача 4: Проектирование новых бизнес-направлений и бизнес-процессов

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

Рис. 5. Схема процесса по банковскому продукту «Автокредитование»

Задача 5: Тиражирование бизнеса, унификация бизнес-процессов и организационных структур

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

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

Рис. 6. Унификация бизнес-процессов и организационной структуры распределенной компании

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

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

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

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

Задача 6: Автоматизация деятельности и внедрение информационной системы

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

Рис. 7. Бизнес-процессы и информационная система

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

Задача 7: Правильный подбор персонала, мотивация, уменьшение зависимости от персонала

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

Задачи службы персонала можно разделить на три подзадачи:

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

Правильный подбор персонала

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

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

Эффективная мотивация

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

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

Уменьшение зависимости компании от персонала

Под зависимостью от персонала понимаются два важных аспекта:

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

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

Второй пример — это проектный институт, разрабатывающий проектную документацию, который столкнулся с проблемой передачи знаний. Средний возраст главных инженеров проектов в институте составлял 65 лет и шел в вверх. Необходимо было привлекать молодых специалистов, но сколько времени потребуется на передачу имеющихся знаний? Через сколько лет молодой специалист, который учился в институте 5 лет на инженера сможет стать опытным главным инженером? Оказалось, что на это требуется 15-20 лет. Причины были связаны с тем, что 15-20 лет требовалось чтобы изучить различные организационные аспекты бизнес-процессов, связанные с разработкой и сдачей заказчику проектной документации. Главные инженеры их знали, но эти знания были в головах.

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

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

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

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

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

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

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

Задача 9: Снижение издержек, расчет себестоимости продуктов и услуг, переход на процессное бюджетирование

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

Снижение издержек

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

Рис. 9. Разработка стоимостной модели бизнес-процесса

Расчёт себестоимости продуктов и услуг

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

Процессное бюджетирование

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

Задача 10: Повышение рыночной стоимости, инвестиционной привлекательности, имиджа, выход на новые рынки, сертификация на соответствие требованиям стандарта ISO 9000

Последняя важнейшая задача — это повышение привлекательности компании в глазах заинтересованных сторон:

акционеров и кредиторов;
клиентов;
поставщиков;
персонала;
партнёров и других контрагентов.

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

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

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

Системный подход к описанию бизнес-процессов

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

Процесс и функция

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

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

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

Рис. 10. Бизнес-процесс «Подготовка ценового предложения клиенту»

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

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

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

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

Рис. 11. Декомпозиция бизнес-процесса и названия уровней

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

Интересно также рассмотреть подходы, используемые западными компаниями. Например, организация APQC, которая занимается стандартизацией и разработкой типовых моделей бизнес-процессов, в том числе и отраслевых на первом уровне использовала понятие «процессная категория», на втором уровне «процессная область», на третьем — «процесс», на четвертом «действие», а на пятом «задача» (рис 11).

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

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

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

Способы описания бизнес-процессов

Существуют два разных способа описания бизнес-процесса: упрощенный способ — вертикальное описание и детальное горизонтальное описание процесса (рис. 12).

Рис. 12. Вертикальное и горизонтальное описание бизнес-процессов

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

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

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

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

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

Совмещение подходов к описанию процессов

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

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

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

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

Классификация процессов верхнего уровня

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

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

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

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

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

Рис. 13. Классификация бизнес-процессов верхнего уровня

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

Необходимо отметить, что в общем случае не принципиально к какой из трех рассмотренных групп отнесен конкретный бизнес-процесс. Польза такой классификации состоит в том, что она позволяет бизнес-процессы верхнего уровня, которых обычно бывает 15-20, разбить на три равные группы по 5-7 процессов, что делает карту процессов верхнего уровня более наглядной и повышает эффективность функционирования системы процессного управления компанией.

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

Компания с различными видами деятельности

Первый пример — компания «Видеомир», которая занимается тремя разно-профильными видами деятельности (рис. 14):

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

Рис. 14. Виды деятельности компании «Видеомир».

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

Рис. 15. Дерево процессов верхнего уровня компании «Видеомир»

Пример дерева бизнес-процессов верхнего уровня компании «Видеомир» приведен на рис.15. В результате было выделено 12 бизнес-процессов верхнего уровня. Отметим, что это пример небольшой компании, численность сотрудников которой составляет 200 человек из который 40 человек — это административно-управленческий персонал, а 160 человек — это линейный персонал, представленный продавцами, работающих в магазинах.

Компания, работающая на различных рынках

Второй пример — торговая компания, которая является дистрибьютером лекарств на трех различных рынках (рис 16):

оптовая торговля лекарствами;
торговля лекарствами на аптечном рынке Москвы и Московской области;
торговля лекарствами на аптечном рынке в регионах.

Рис 16. Виды деятельности торговой компании

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

Рис 17. Карта процессов верхнего уровня торговой компании

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

Производственная компания

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

Рис 18. Виды деятельности производственной компании

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

Рис 19. Карта процессов верхнего уровня производственной компании

Существует три правила выделения бизнес-процессов верхнего уровня

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

Три правила выделения процессов верхнего уровня

Количество процессов верхнего уровня

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

Важность процессов верхнего уровня

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

Утверждение процессов верхнего уровня

Рис. 20. Карта процессов верхнего уровня торговой компании

Рис. 21. Карта процессов верхнего уровня производственной компании.

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

Рис. 22. Матрица распределения ответственности за процессы верхнего уровня производственной компании

Реинжиниринг и постоянное совершенствование

Эволюционные и революционные улучшения бизнес-процессов

Все методы оптимизации бизнес-процессов можно поделить на две группы (рис. 23).

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

Вторая группа — это методы, которые революционно меняют бизнес-процесс и существенно улучшают его ключевые показатели. Такие методы получили название «методы реинжиниринга бизнес-процессов».

Рис. 23. Реинжиниринг и постоянное совершенствование бизнес-процессов

Основные черты постоянного совершенствования:

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

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

Основные черты реинжиниринга являются:

фундаментальность изменений;
радикальность изменений;
существенность изменений.

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

Реинжиниринг в отличие от постоянного совершенствования нельзя применять одновременно по всем бизнес-процессам. Одновременно реинжинирить можно не более 20% от всех процессов компании.

Рис. 24. Совмещение эволюционного и революционного улучшений бизнес-процесса

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

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

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

Пример реинжиниринга в коммерческом банке

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

Процесс до реинжиниринга

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

С точки зрения клиента процесс имел четыре точки или окна контакта с сотрудниками банка (в процессном управлении это называют количеством выходов процесса) и клиенту приходилось отстоять очередь в четырех разных окнах. В результате длительность процесса составляла в среднем 40 минут.

Рис. 25. Процесс до реинжиниринга

Первый этап реинжиниринга

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

Рис. 26. Процесс после первого этапа реинжиниринга

Второй этап реинжиниринга

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

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

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

Рис. 27. Процесс после второго этапа реинжиниринга

Третий этап реинжиниринга

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

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

Рис. 28. Процесс после третьего этапа реинжиниринга

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

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

Пример реинжиниринга в производственной компании

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

Рис. 29. Процесс ремонта автотранспорта до реинжиниринга

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

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

Рис. 30. Процесс ремонта автотранспорта после реинжиниринга

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

Напомню еще раз

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

Сергей Ковалев

Цикл статей впервые был опубликован в журнале «Управляем предприятием».

Полезные материалы

Регламент корпоративной технической поддержки пользователей «1С:Предприятие 8 КОРП»
Управление корпоративными проектами
Управление содержанием проекта
Управление требованиями и содержанием в проекте
Оценка сроков и стоимости проекта на ранних стадиях
Подходы к планированию проектов
Оценка стоимости проектов

Поиск по разделу

технологии

Отзывы заказчиков

Директор по ИТ АО «Щербинский лифтостроительный завод»

Илья Заянц

Благодаря внедрению «1С:ERP Управление предприятием» на предприятии появилась современная информационная система, которая помогла осуществить перевод регламентированного и складского учета на платформу из исторически используемых на предприятии систем с переносом справочников НСИ.
Аналитик угледобывающей компании «Колмар»

Полина Харитонова

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

Андрей Сунцов

В результате внедреня «1С:Управление холдингом» мы обладаем подсистемой, предназначенной для автоматизации бухгалтерского и налогового учета, включая подготовку обязательной (регламентированной) отчетности организации. На текущий момент в подсистеме отражено 919487 документов в бухгалтерском и налоговом учете.
Директор по информационным технологиям ООО «ОБИ ФЦ»

Дмитрий Панычев

В связи с прекращением продаж и поддержки решений SAP было принято решение в кратчайшие сроки перейти на решение «1С:ERP Управление предприятием». В системе предусмотрено оформление практически всех первичных документов торгового, складского учета, а также документов движения денежных средств. В перспективе ожидается сокращение комплексных трудозатрат по регистрации операций в системе на 30-35%.

Источник

Время на прочтение
4 мин

Количество просмотров 7.1K

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

Введение

Карта процессов верхнего уровня (КПВУ) — это схематичное изображение деятельности (деятельность = процесс) компании, процессный “скелет” компании. Это один из ключевых элементов BPM (Business Process Management). Полистав альбом КПВУ можно в целом понять, что и как компания делает, какие подразделения в каких процессах участвуют.

Обычно отрисовку верхнеуровневых схем выполняют в нотации VAD (value added chain diagram).

Выжимку из КПВУ можно представить в виде половинчатой матрицы RACI, в которой заполняются только владелец бизнес-процесса и его участники:

Accountable (сокращение A) – подотчетный, утверждающий. Это видимо владелец процесса, а он должен быть одним (иначе будет по Райкину: «рукава и пуговицы»). Хотя часто в RACI под Accountable понимается что-то иное, судя по указанию нескольких «А» для одного процесса (задачи). Подробнее о Владельцах процессов (process owner) можно почитать тут: Process Roles — Who are the Process Owners? https://www.brcommunity.com/articles.php?id=b668
Responsible (сокращение R) – ответственный непосредственно за выполнение работы, исполнитель бизнес-процесса (executors)
Consulted (C) – консультант и Informed (I) – роль, которой нужно направить уведомляемые о выполнении процесса — обе эти роли не рассматриваем.

Матрица RACI (матрица ответственности ролей в бизнес-процессах) предназначена для четкого распределения обязанностей и зон ответственности среди участников бизнес-процессов.

На всякий случай шаблон RACI в Excel

Странно. Так как ключевая роль у владельца процесса (A), то непонятно почему такую матрицу не назвали ARCI?

Задача

Нарисовать КПВУ и далее автоматически по ней построить матрицу RACI (половинчатую). Иметь возможность для анализа приведенных данных (поиск, фильтры, группировка), т.е. поместить названия процессов и роли (и связи между ними) в аналитическую табличку (Excel, google table и т.п.) или базу данных. Когда в компании полсотни подразделений и сотня верхнеуровневых процессов, то подобный инструмент становится очень актуальным.

Пожелания к инструментам: free & open source и наличие развертывания на корпоративном сервере.

1. Карта процессов верхнего уровня

Можно верхнеуровневые процессы рисовать в Visio и его BPM-развитиях, начиная с Бизнес-студии. Но желателен free & open source. Это позволит создать единый стандарт подход к подобным вещам. Связка Visio-Excel-VBA позволяет решить поставленную задачу, включая связку VAD с RACI, но она не перспективна.

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

Карты верхнеуровневых процессов:

Ссылка на пример Карты верхнеуровневых процессов в drawio

При вводе данных по каждому процессу мы используем заполнители (placeholders), как показано на рисунке:

Формочка для заполнения заполнителей такая:

2. Обработка в Google Sheets

Google Sheets — это не Open Source, но для демонстрации хороший инструмент. Я храню схемы процессов в xml, поэтому и экспортировать ничего не нужно. Если что, в drawio есть кнопка экспорта в xml.

Пара возникших проблем.

Вначале пробовал парсить через функцию IMPORTXML(). Не вышло. Другие файлы парсит, но на этот выдает «Н/Д Не удалось обработать данные в формате XML». Даже для простых XPath-запросов типа «/«, «//«. Почему? Второй проблемой оказалось получить прямую ссылку с google drive. Для IMPORTXML нужна прямя ссылка, но разные: https://drive.google.com/uc?export=download&confirm=no_antivirus&id=[your_XML_file_id] не помогло. Поэтому использовал DropBox c заменой окончания исходной ссылки «? dl = 0» на «? dl = 1».

В итоге бросил упражнения с IMPORTXML.

Для разбора xml использовал незатейливый скрипт.

В xml данные placeholders хранятся так:

Пробегаемся по файлу, находим нужные имена placeholders и выводим их значения в промежуточную табличку (функции slice, indexOf):

Так как используются placeholders, то мы можем использовать в схеме любые графические примитивы: VAD-кораблики, прямоугольники, кружки.

Далее из вспомогательной таблички строим саму матрицу (полу-RACI):

Алгоритм такой: вручную расставляем в первой строке названия подразделений. Иначе ни как, хотя бы потому, что слева обычно указываются все front-подразделения, потом middle, далее back office и все обеспечивающие. Компу сложно рассказать про это.

Далее пробегаемся по вспомогательной табличке и сравниваем поля «Владелец» и «Исполнитель» с шапкой итоговой матрицы RACI (половинчатой). Если имеется равенство по Владельцу, то пишем «А» (Accountable), если по Исполнителю, то «R» (Responsible).

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

Заключение

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

Перспектива

Drawio diagram.net — достаточно удобная система, кроме того, это free + Open Source + облако + On-Premise, поэтому вследствие прочих равных функциональных характеристик имеет преимущества между схожими системами, включая, LucidChart.

Если с Drawio интегрировать базу данных или хотя бы Excel (наподобие связки с Excel в Visio), то получится уже «половина» ARIS. Интеграция позволит двухстороннюю связь между схемой и объектом в БД. Например, достаточно синхронизировать вышерассмотренные заполнители (placeholders) с одноименными объектами в БД. Есть такие решения?

ARIS-подобное на Open Source — когда то должно же появиться. Пока нет ни одной Open Source Free системы класса BPM-BPA. Хочется верить, что светлое (свободное) будущее BPM когда-нибудь, да наступит…

Источник

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

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

Что такое бизнес-процессы

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

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

История появления термина

В 70-е годы ХХ века впервые описали термин «бизнес-процесс». Потребность в четких нотациях бизнес-процессов IDEF0 возникла при переходе к информатизации и разработке информационных систем. Использование последних значительно усложнило организацию труда и управление на предприятиях. От привычной словесной формы инструктирования работников стали переходить к описаниям процессов взаимодействия по моделям «человек – человек» и «человек – машина».

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

Зачем нужны бизнес-процессы

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

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

Ключевые понятия процессного подхода

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

Каждый инструмент имеет:

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

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

поставщики ресурсов;
последовательность действий;
конечный пользователь;
иные участники;
риски;
показатель эффективности.

Уровни бизнес-процессов

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

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

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

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

Классификация бизнес-процессов

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

по степени сложности;
по виду деятельности;
по месту в структуре организации;
по функциям подразделений;
по степени детализации или комплексности;
по исполняемости.

Рассмотрим, что входит в каждую группу.

По степени сложности

Монопроцессы – цикличные односложные операции.
Вложенные процессы – последовательности монопроцессов.
Связанные процессы – последовательности монопроцессов, выполняемые по предварительно заданной схеме.

По виду деятельности

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

По месту в структуре организации

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

По функциям подразделений

Управленческие.
Финансовые.
Складские.
Логистические.
Производственные.

По степени детализации или комплексности

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

По исполняемости

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

Виды бизнес-процессов

Существует множество видов бизнес-процессов, которые можно разделить на 6 категорий:

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

Также разделяют бизнес-процессы:

По форме:

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

По функции:

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

Правила описания бизнес-процесса

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

Завершенность или ответ на ключевой вопрос

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

Краткость и лаконичность

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

Использование типовых нотаций

Существуют общепринятые международные обозначения, которые и должны использоваться в описаниях. Это стандарты IDEF3, BPMN 2.0, BPMN и другие. Они позволяют читать и правильно трактовать бизнес-процесс любому человеку. Применение личных выдуманных обозначений недопустимо.

Понятность

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

Указание участников

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

Описание бизнес-процессов

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

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

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

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

Описание бизнес-процессов проходит в 11 шагов. Разберемся, что делает бизнес-аналитик на каждом из них.

Шаг 1. Определяем цель описания

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

Шаг 2. Определяем цели бизнес-процесса

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

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

Шаг 3. Подключаем руководителей отделов

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

Шаг 4. Разговариваем с сотрудниками

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

Шаг 5. Выделяем приоритетные задачи

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

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

Шаг 6. Фиксируем начало и конец бизнес-процесса

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

Шаг 7. Определяем ключевые точки бизнес-процесса

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

Например, в сфере продаж ключевыми точками будут:

получение контактов клиента;
переговоры;
обсуждение цены и других условий сотрудничества;
выставление счета.

Каждая ключевая точка имеет развилки, которые тоже предстоит описать. Развилок может быть много, а новые ветки мероприятий присоединяются с помощью операторов «и» / «или».

Шаг 8. Составляем предварительное описание

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

Шаг 9. Согласуем детали с компетентными специалистами и руководителями

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

Шаг 10. Демонстрируем финальный вариант

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

Шаг 11. Оформляем описание

Финальный этап – оформление готового документа. К текстовому описанию и графической нотации прилагаются модели, планы и другие документы.

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

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

Текстовый

Самый распространенный формат, предполагает изложение большого объема текста словами.

Плюсы

Минусы

не требует спец. навыков для оформления;
прост в реализации.

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

Табличный

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

Плюсы

Минусы

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

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

Графический

Модели и схемы – самый удобный и предпочтительный формат описания.

Плюсы

Минусы

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

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

Схема бизнес-процессов

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

Схема строится в 9 этапов:

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

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

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

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

Создание бизнес-процессов на предприятии

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

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

Анализ

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

Анализ необходим, если:

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

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

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

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

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

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

Иногда описание бизнес-процессов путают с должностными инструкциями. Это совершенно разные документы.

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

Этапы описания

Существует 2 модели описания бизнес-процессов:

Модель «как есть» (в переводе с английского – as is). Демонстрирует текущие бизнес-процессы, которые нужно изучить и описать.
Модель «как должно быть» (переводится как to be). Создается исходя из анализа предыдущей модели, если нынешние бизнес-процессы оказываются неэффективными, несовершенными.

Модель «как есть» строится следующим образом:

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

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

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

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

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

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

Можно выделить 4 этапа BPM, прохождение каждого из которых находится под чутким управлением менеджера.

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

Как появилось BPM

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

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

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

Модель зрелости BPM

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

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

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

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

Структурное моделирование – применяется для исследования текущих и разработки новых систем. Здесь есть три подвида:

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

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

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

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

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

- SADT – используется для создания функциональной модели.
- DFD – стандарт для макропроцессов в бизнесе.
- WFD – стандарт для бизнес-процессов нижнего уровня с возможностью демонстрации последовательности работ с учетом времени.
- ARIS – применяется для создания, анализа, внедрения и улучшения бизнес-процессов.
- EPC – показывает вход и выход процесса в ходе моделирования сложных комплексов.
- STD – показывает, как ведет себя система при внешнем управляющем воздействии.
- UML – описывает требования к ИС.
- ERM – описывает концепцию бизнес-процесса.
- FCD – описывает действия, исполнителей, оборудование и данные с помощью символов.
- RAD – описывает и анализирует функциональные элементы, наглядно демонстрирует их взаимодействие.
- ANSI – набор блок-схем для демонстрации хода процесса.
- IDEF – набор инструментов для разделения и объединения блоков (IDEF0), изображения процесса (IDEF3) и др.
- Unified Modeling Language – средства визуализации, конструирования, документирования систем и процессов.
- Цветные сети Петри – демонстрируют переходы, изображают события и действия.
- Дорожки Брюса Силвера – дополнение к другим нотациям, применяется, чтобы показать, как переходит ответственность от одного участника к другому.

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

Сравнение нотаций

Выше перечислено много различных нотаций, но на практике чаще всего применяется две наиболее популярные – BPMN и ARIS eEPS. Сравним их.

BPMN

ARIS eEPS

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

Показывает статусы документов.
Демонстрирует события до и после каждой операции.
Использует логические операторы.
Позволяет имитировать процесс наиболее корректно.
Крупные диаграммы.
Трудоемкое моделирование.
Ограниченная семантика.

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

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

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

Программы:

Bizagi Process Modeler;
Visual Paradigm;
ELMA BPM;
Fox Manager;
ARIS Express;
Business Studio;
ABC-FlowCharter;
CorelFlow;
Visio;
Proplan;
Ablauf-Profi;
Vamos-BE;
SYCAT;
AENEIS;
ARISToolset;
AIBAS;
Camunda-modeler.

Онлайн-сервисы:

сайт Diagram.ly;
сервис на сайте yWorks.

Внедрение бизнес-процессов

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

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

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

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

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

Можно выделить 2 большие группы методов оптимизации:

Методы «здравого смысла».
Методы «бережливого производства».

Рассмотрим, что входит в каждую группу.

Методы «здравого смысла»:

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

Методы «бережливого производства» предполагают:

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

Потребность в оптимизации бизнес-процессов можно обнаружить вскоре после их запуска.

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

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

Так, с помощью автоматизации бизнес-процессов удается проще и быстрее решать следующие задачи:

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

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

Преимущества внедрения процессного управления

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

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

Реинжиниринг и постоянное совершенствование

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

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

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

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

Постоянное совершенствование характеризуется:

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

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

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

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

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

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

На основании выявленных проблем были поставлены цели:

организовать поставку ЛКМ в срок;
ускорить изготовление и поставку готового продукта клиентам до прописанных в договоре 10 дней.

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

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

Ошибки при внедрении систем управления

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

Источник

Введение

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

В статье рассматриваются темы:

Деятельность организации: это процессы или функции? Что на самом деле мы моделируем в модели «процессов верхнего уровня»?
Возможность использования нотации IDEF0 для модели верхнего уровня.
На какие части можно поделить деятельность организации?
Принцип «модульности» при проектировании архитектуры системы.
Принцип «автономности» при проектировании архитектуры организационной системы.
Особенности создания модели «верхнего уровня» в нотации IDEF0.

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

Понятие «Онтология» и теория множеств для конструирования классов онтологии.
4D-экстенсионализм.
Нотация для экземпляров и классов (Matthew West «Developing high quality data models», ISO 15926–2 «Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model»).
Понятия и методы системной инженерии.

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

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

Например, если мы говорим «стол» и показываем на него пальцем, то 99% аналитиков согласятся с нами. Если мы говорим, что это «мебель» — более высокий класс, то с нами согласятся 98% аналитиков. Но если мы возьмем понятие «сквозной процесс», то дать четкое определение и, согласно этому определению, однозначно выделить сквозной процесс в реальности аналитики вряд ли смогут. У всех будут разные ответы.

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

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

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

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

Процессы могут происходить в разное время и в разном месте. В класс мы объединяем те, которые считаем похожими. И при этом количество операций в их составе может быть разным! Вспомните: на диаграмме процесса (типовой модели) есть развилки и циклы, которые приводят к разному составу операций у конкретных процессов в реальности.

Количество получившихся классов процессов — поменьше, но тоже очень велико — сотни и тысячи. Что делать дальше? Дальше, по логике, нужно включать классы процессов во все более абстрактные классы и подниматься по уровням модели все выше и выше. Зачем? Чтобы на самом верхнем уровне (bird’s-eye view) получить компактную модель, удовлетворяющую следующим требованиям:

Модель может поместиться в голову человека «целиком».
Модель должна быть понятна неподготовленному человеку. (А, в идеале, подходить на роль учебного материала для новичков.)
Модель должна давать четкий ответ на вопрос: что именно делает компания. А для этого очень желательно, чтобы выполнялось требование 4.
Модель должна отражать связи операций по входам и выходам.

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

Дэвид А. Марка и Клемент МакГоуэн
Методология структурного анализа и проектирования (SADT)

Какие проблемы возникают при создании модели верхнего уровня? Те, кто пытались это сделать для существующего бизнеса (а с этого начинают почти все знакомые мне аналитики), уже знают, что:

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

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

APQC Process Classification Framework (PCF) — Cross Industry — Version 7.2.1 September 26, 2019

APQC PCF- это одна из самых известных «классификаций процессов».

Характеристики:

Создавалась для бенчмаркинга компаний (сравнения между собой);
13 верхнеуровневых категорий процессов: 6 операционных и 7 управления и поддержки;
Глубина: местами до 5 уровня. Всего 1264 элемента (Activity) на 4 уровне.

Критика:

Переусложненная онтология: 2 сущности для группировки процессов (Category, Process Goup, 3 сущности для декомпозиции процессов (Process, Activity, Task):
Строго заданное фиксированное количество уровней.
На практике попытка выдержать классификацию по жестко заданному количеству уровней часто терпит фиаско. Представьте, если бы вам сказали, что абсолютно любую систему (например, стол или атомную станцию) вы можете декомпозировать не более, чем на 5 уровней;

Понятность модели вызывает вопросы. Например, операционные процессы включают почему-то такую группу как «1.0 Разработка видения и стратегии». И в ней в рамках «1.2 Develop business strategy» выделяется деятельность по организационному проектированию, как маленький кусочек:

OPERATING PROCESSES
1.0	Develop Vision and Strategy
1.2	Develop business strategy
1.2.5	Create organizational design
1.2.5.1	Evaluate breadth and depth of organizational structure
1.2.5.2	Perform job-specific roles mapping and value-added analyses
1.2.5.3	Develop role activity diagrams to assess hand-off activity
1.2.5.4	Perform organization redesign workshops
1.2.5.5	Design the relationships between organizational units
1.2.5.6	Develop role analysis and activity diagrams for key processes
1.2.5.7	Assess organizational implication of feasible alternatives
1.2.5.8	Migrate to new organization

Нет связи по входам и выходам.

Типовые модели экосистемы Business Studio

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

8-процессная модель Тимура Кадыева

Выполнена в нотации IDEF0, операции сгруппированы по жизненному циклу элементов предприятия и внешних объектов.

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

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

Типовые структуры процессов СТУ

Это переработка модели процессов Тимура Кадыева в реестр процессов и локализация его на следующие виды деятельности:

Оказание услуг (PDF);
Проектная деятельность (PDF);
Производство (PDF);
Управляющая компания (PDF).

Можно сказать, что это аналог классификатора «APQС». И, кстати, он тоже используется для бенчмаркинга, причем автоматизированного, на портале www.bizdiag.com.

Модель Игоря Лозовицкого

Модель является примером использования деления деятельности на Основную, Управления и Поддерживающую. На мой взгляд, это является плюсом модели, т. к. это позволяет сфокусироваться на определенном аспекте функционирования компании. Так, например, легко выделяется цепочка создания ценности в Сфере основной деятельности.

В модели выделено 18 групп процессов, разбитых по трем сферам. Модель выполнена в IDFE0, но для верхнеуровневого «презентационного» представления используется нотация VAD.

Процессы или функции?

Теперь самое время точно определиться с понятиями, с которыми мы имеем дело в верхнеуровневой модели деятельности компании. И начнем мы по традиции с критических высказываний в сторону классификатора APQC:

«Одна организация, называемая APQC, опубликовала межотраслевую рамочную модель классификации процессов (Process Classification Framework, далее PCF), — иерархическую структуру, состоящую из категорий, групп процессов, отдельных процессов и видов деятельности. К сожалению, очень немногие из процессов и видов деятельности, перечисленные в PCF соответствуют понятиям процесс и деятельность, в том значении, котором их определяет BPMN. Большинство из них относятся к постоянно протекающим бизнес-функциям типа «управлять X», а не действиям в дискретных экземплярах процесса с четко определенным началом и окончанием…

…У меня нет цели придираться именно к APQC. Эта проблема широко распространена в литературе по бизнес-архитектуре и управлению бизнес-процессами. Мне приходилось сталкиваться с ситуациями, когда команда BPM-архитекторов определяла перечень основных «видов деятельности», которые не являлись дискретными повторяющимися действиями, с четко определенными начальными и конечными точками, а потом поручала специалистам по моделированию процессов связать их вместе, чтобы описать процесс от начала до конца, что не представляется возможным.»

Bruce Silver
BPMN Method and Style

Независимо от Брюса Силвера я также пришел к выводу о том, что понятия, которыми мы оперируем в модели деятельности верхнего уровня, носят вневременной характер. То есть, мы не можем указать на временные границы, например, таких видов деятельности «Разработка видения и стратегии» или «Разработка и управление продуктами и услугами» (примеры из APQC). Зато мы можем сказать, что мы точно знаем, что такая деятельность есть и время от времени она дает свои конкретные результаты!

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

Композиция;
Агрегация;
Классификация (включение члена в класс).

Давайте разберем их подробнее. В результате Композиции и Агрегации получается целый объект. Главное здесь в том, что мы получаем именно объект, имеющий свои 4D-границы, и на который, при желании, можно показать пальцем. Например, когда мы говорим о том, что процесс делится на части, мы имеем ввиду именно отношение композиции, т. к. и части, и целое являются объектом-операцией. Здесь можно зафиксировать промежуточный результат. Мы установили, что, когда мы двигаемся ниже по уровням иерархии от уровня процессов, мы имеем дело с отношением композиции.

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

Давайте попробуем подумать про понятие «Класс».

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

Понятие «Класс» и операция «Классификация» как нельзя лучше описывает то, что мы делаем в модели деятельности верхнего уровня с классами процессов. Например, включение классов процессов из APQC «1.1.1.6 Анализ демографии» или «1.2.6.1 Идентификация организационных целей» (если мы, конечно, считаем, что члены этих классов — это процессы, имеющие начало и конец) в качестве членов в класс «1.0 Разработка видения и стратегии» означает, что все конкретные процессы в рамках определенной компании: которые уже были выполнены, которые выполняются в данный момент, которые будут выполняться в будущем, — имеют отношение к деятельности по разработке стратегии. А процессы всех классов, которые, как мы решили, относятся к разработке стратегии, собственно, и являются этой деятельностью.

Мы можем аналогичным образом получить и промежуточные уровни нашей модели. Для этого мы можем ввести в модели подклассы класса «1.0 Разработка видения и стратегии». Но отношение здесь будет уже другое — специализация (класс-подкласс). Членами этих подклассов по-прежнему будут классы процессов.

Давайте отразим это уже в более формализованной нотации «экземпляров и классов».

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

Прочитать данную онтологию можно следующим образом:

Некоторые операции являются процессами;
#Процесс1 состоит из операций #Операция1 и #Операция2;
Процессы собираются в классы процессов;
Классы процессов собираются в классы классов процессов.

Использование нотации IDEF0 для создания моделей деятельности верхнего уровня

Давайте сделаем паузу в наших умственных упражнениях и рассмотрим старую добрую нотацию IDEF0. Как известно, это нотация для функционального моделирования, которая используется для создания моделей верхнего уровня. Она базируется на методологии структурного анализа и проектирования (SADT), описанной в книге Дэвид А. Марка и Клемент МакГоуэн «Методология структурного анализа и проектирования (SADT)».

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

Методология структурного анализа и проектирования (SADT)

Эта методология знаменита, в частности, тем, что подарила нам понятие «Декомпозиция функции». Удивительно, но в книге не дается определение функции! Что-то похожее на определение появляется в базирующимся на нем стандарте IDEF0:

«Function: An activity, process, or transformation (modeled by an IDEF0 box) identified by a verb or verb phrase that describes what must be accomplished.»

INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

К данному определению у меня всегда было много вопросов. Например, если функция — это и есть процесс, то зачем придумывать новое понятие? Что нового оно дает?

Давайте разбираться. В описании нотации IDEF0 подчеркивается вневременной характер модели:

«Arrows do not represent flow or sequence as in the traditional process flow model.»

INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

А семантика входов и выходов функции включает в себя принципы:

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

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

Я думаю, уже стало понятно, к чему я клоню. Тот объект, который у нас появился раньше, и подходит на определение понятия «Функция»:

Следствия из такого определения:

Функцию мы можем собрать из любых классов процессов, как нам заблагорассудится.
Можно выбрать любой критерий включения в класс. Например, как в примере выше, мы можем считать, что определенные классы процессов имеют отношение к разработке стратегии.
Или мы теперь можем легко решить очередную философскую проблему — что такое бухгалтерский учет — процесс или не процесс? Бухгалтерский учет — это, конечно, не процесс. Это функция, включающая все классы процессов, относящихся к предметам бухгалтерского учета.
Один класс процессов может входить в несколько функций (и это не грех, как принято считать сейчас. Мир слишком многогранен, чтобы его можно было описать одной таксономией).
Мы можем обобщать функции до бесконечности вверх. Между родительской и дочерней функцией существует отношение класс-подкласс. На нижнем уровне, когда в функцию оказывается включен только один класс процессов, обычно осуществляют смену типа модели и переходят к созданию типовой модели процессов класса (описывающей все процессы класса). При этом дальнейшее разбиение на части происходит с использованием связи композиция.
Подобный подход давно поддерживала система Business Studio. Теперь мы знаем, что это означает с точки зрения теории.
Стрелки между функциями моделируют объекты, перемещающиеся между функциями. Это значит, что в реальности найдутся два конкретных процесса между которыми будут перемещаться конкретные объекты. Но как в любой модели классов (с указанием соответствующей кратности на конце связи) не все связи будут существовать между каждыми двумя процессами. При объединении стрелок, моделирующих интерфейсы функций, в более крупные стрелки, имеет место аналогичный функциям подход.

Замечания об онтологии

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

Также очень хорошо, если ваша онтология синхронизирована с другими. В описанном случае, мне кажется, это удалось. Онтология не противоречит IDEF0, а также языкам BPMN и Archimate.

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

Bruce Silver
BPMN Method and Style

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

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

Язык Archimate 3.1

Источник