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

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

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

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

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

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

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

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

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

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

Что же, всё-таки, такое управление бизнес-процессами? В Глоссарии Ассоциации профессионалов по процессному управлению (ABPMP Russian Chapter, https://abpmp.org.ru/resource/bpm-glossary/) дается следующее определение:

«BPM (Управление бизнес-процессами, УБП)

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

    а) анализа, проектирования, внедрения, управления и непрерывного совершенствования сквозных процессов и

    б) регулирования отношений в области процессного управления (Governance).

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

Красиво сказано, спору нет. Но смущает две вещи: 1) взгляд через «модели процессов», то есть опять «рисование»; 2) ну совершенно не понятно, кто и что должен делать…. И вряд ли кто-то из руководителей реальной компании процитирует такое определение из Глоссария в ответ на вопрос: «Как Вы управляете бизнес-процессами»?

Если свести весь BPM к изменению схем и последующей маршрутизации экземпляров процессов в BPMS руководителем, то это как-то совсем слабо и совершенно «не тянет» на управление бизнес-процессами с Большой буквы… Хотя, может это оно и есть? С точки зрения поставщика BPM-системы, наверное…

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

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

Кейс. На одной из сессий по описанию бизнес-процессов собственник весьма успешной компании из сектора телекоммуникаций сказал: «…то, что мы сейчас делаем (схемы) хорошо, но как-то механистично… Да, видно, кто и что должен делать. Да, видны документы… Но КАК именно делать? Как создавать ценность для клиентов? Какие принципы закладывать в эту работу? Что должно мотивировать сотрудников ориентироваться на ключевые, базовые принципы создания ценности? Какие ограничения при этом существуют? Схемы ответа на этот вопрос не дают…». То есть в понимании собственника разработка бизнес-процесса – это не столько рисование схем в BPMN, сколько создание системы работы, которая способна «непрерывно поставлять ценность для клиентов». А это уже серьезная задача для владельца процесса… Для ее решения была создана модель целей, ценностей, принципов и ограничений на языке Archimate в Business Studio 6.

Владелец бизнес-процесса: кто он?

Начнем с определения владельца бизнес-процесса. В Глоссарии ABPMP приводится следующая формулировка (обратите внимание, что определение дается через понятие «роль»):

«Лицо, исполняющее эту роль, несет постоянную ответственность и отчитывается за успешное проектирование, разработку, исполнение и эффективность всего сквозного (кросс-функционального) бизнес-процесса».

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

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

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

Обратите внимание, что владелец должен управлять ходом процесса. Иначе – это вовсе не владелец.  

Можно составить следующее более полное определение владельца процесса:

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

Используя данную формулировку, можно четко определить, чем может и должен управлять владелец бизнес-процесса. Это:

1. Цели, показатели, планы/отчеты, контрольные процедуры по процессу.
2. Методы и инструменты оперативного управления процессом.
3. Контекст процесса: входы/выходы (включая требования, методы и инструменты контроля), интеграция с поставщиками/потребителями.
4. Технология выполнения процесса (модели/схемы в нотациях – только инструмент проектирования алгоритма выполнения).
5. Оборудование.
6. Средства измерения процесса.
7. Среда выполнения процесса.
8. Персонал (количество, компетенции, система стимулирования).
9. ИТ-системы, поддерживающие выполнение процесса (включая экземпляры процесса в случае их наличия в автоматизированной системе).
10. Риски процесса.

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

Теперь понятно, почему при наличии «рисования» управление бизнес-процессами НЕ наступает. Причина проста – руководители не работают как владельцы бизнес-процессов, не осознают себя таковыми. В лучшем случае, 60-70% их времени уходит на «управление персоналом».

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

Этапы развития (уровни зрелости) владельца бизнес-процесса по Майклу Хаммеру

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

На первом уровне зрелости «портрет» владельца процесса (ВП) выглядит следующим образом (Таблица 1):

Таблица 1. Уровень 1

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

В российской практике можно довольно часто встретить в должностных инструкциях формулировку «…имеет право требовать…». Фактически это означает, что на Уровне 1 у ВП нет никаких заметных полномочий, но ему «…поручено повысить эффективность процесса». Как это он будет делать – непонятно. Уговаривать можно долго… Но тот факт, что ВП занимается регламентацией и объясняет порядок выполнения работы участникам процесса, — это уже хорошо, лучше, чем ничего.  

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

Уровень 2 (Таблица 2) – уже всё гораздо серьезнее. ВП теперь не просто маска, а реальная, официальная должность высшего управленческого звена.

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

Таблица 2. Уровень 2

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

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

На Уровне 3 (Таблица 3) ВП занимается только бизнес-процессом, то есть не совмещает функциональное управление подразделениями и «процессный менеджмент». 

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

Таблица 3. Уровень 3

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

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

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

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

Таблица 4. Уровень 4

Как мы видим, в концепции Майкла Хаммера роль владельца бизнес-процесса меняется от локального «регламентатора» и «уговаривателя», до титанической фигуры масштаба собственников бизнеса, реально воздействующего на бизнес-модель компании, ее архитектуру, цепочку создания ценности, интеграцию с поставщиками и потребителями…

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

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

«Портрет» реального владельца бизнес-процесса

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

Таблица 5. Виды бизнес-процессов.

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

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

В таблице 6 представлено описание владельцев в зависимости от масштаба процессов.

Таблица 6. Владельцы процессов различного масштаба.

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

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

Таблица 7. Модель функций, ответственности и полномочий владельца процесса.

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

При реальном создании института владельцев процессов нужно четко определить/создать:

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

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

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

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

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

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

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

Из реального примера, попытки в нескольких компаниях назначить владельца процесса Поставка товара с центрального склада в розничный магазин, с установлением понятного показателя OTIF (on time in full) – показывающего своевременность и полноту объема поставки, проваливались из-за нежелания потенциального владельца процесса брать на себя ответственность за этапы процесса после того, как товар был передан ответственным за доставку получателю. Основное обоснование: «… дальнейшую приемку и разбирательства при недопоставке или перепоставке товара делают сотрудники не моей бизнес-функции…». Желания влиять на сотрудников других бизнес-функций у владельца не было, как и желания брать ответственность за достижение целевых показателей процесса в целом.

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

Выводы

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

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

В.В. Репин,

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

Февраль 2024 г.

www.bpm3.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Январь 2024 г.

www.bpm3.ru

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Май 2023 г.

www.bpm3.ru

Введение. Что такое СУБП?

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

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

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

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

Как понять, есть ли в вашей компании такая система и оценить ее текущий уровень развития? Есть довольно много различных методик оценки. Я предлагаю оценивать СУБП по десяти основным направлениям.

Структура СУБП компании и оценка уровня ее зрелости

Кратко опишу разделы, по которым может проводиться оценка уровня зрелости СУБП[1]:

Таблица 1. Структура СУБП.

На рис. 1 показан пример оценки уровня зрелости СУБП некоторой организации. Видно, что в 2022 году оценка была весьма невысокая. На 2023 года руководство компании запланировало существенное развитие системы, например разработку архитектуры бизнес-процессов, развитие практики описания, анализа и внедрения изменений и проч.

Роль СУБП в развитии бизнеса

Собственникам и руководителям важно понимать роль СУБП в развитии компании. На рис. 2 показано текущее состояние бизнеса и перспективное состояние, характеризующееся кратным ростом масштабов.

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

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

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

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

Проект внедрения СУБП: видение и цели

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

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

Созданная в рамках проекта Система работы с бизнес-процессами даст возможность:

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

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

Во время или перед формализацией видения СУБП руководителям полезно ознакомиться с опытом других компаний, провести бенчмаркинг. Найти партнеров для бенчмаркинга можно на сайте https://bpmaward.ru – там размещается информация (доклады, видео) о компаниях-финалистах конкурса «BPM-проект года», который проводит Ассоциация профессионалов управления бизнес-процессами (ABPMP Russian Chapter), https://abpmp.org.ru.

Ролевая структура проекта внедрения СУБП

В рамках проекта для крупной организации (холдинг) можно говорить о следующей ролевой структуре (см. Таблицу 2).

Таблица. 2. Ролевая структура проекта

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

Основные этапы проекта внедрения СУБП

Типовой проект внедрения СУБП включает следующие группы работ (этапы):

0. Определение видения и целей внедрения СУБП.

1. Организация деятельности Процессного офиса.

2. Разработка методик СУБП.

3. Внедрение Business Studio.

4. Проектирование архитектуры бизнес-процессов (IDEF0).

5. Описание и анализ бизнес-процессов «Как есть» (BPMN).

6. Описание бизнес-процессов «Как должно быть» (BPMN).

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

8. Разработка системы обучения и аттестации персонала.

9. Проведение внутренних аудитов.

10. Проведение оценки зрелости СУБП.

11. Планирование развития СУБП и бизнес-процессов компании на 20__ год.

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

Этап 0 «Определение видения и целей внедрения СУБП» может довольно долго, например, 2-3 месяца (на рис. 3 – меньше). Руководителям компании нужно разработать и согласовать видение и цели внедрения. В этом могут помочь учебно-практические сессии, на которых внешний эксперт расскажет о целях внедрения, методах и инструментах СУБП, возможных этапах проекта, роли руководителей, рисках и проч.

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

Этап 2 включает разработку ключевых методик СУБП. Должны быть созданы: 

1. Глоссарий СУБП.
2. Концепция СУБП («Стандарт внедрения СУБП» или «Стандарт внедрения процессного управления»).
3. «Соглашение по моделированию бизнес-процессов» (нотации IDEF0 и BPMN).
4. Регламент моделирования и анализа бизнес-процесса.
5. Регламент выполнения проекта оптимизации сквозного бизнес-процесса.
6. Методика разработки целей и показателей для управления процессами.
7. Методика выбора процессов для оптимизации.
8. Стандарт управления ВНМД, включая формы регламентов (на платформе Business Studio)
9. Регламент автоматизации процесса (в BPMS).
10. Методика оценки зрелости СУБП.
11. Прочие.

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

Этап 3 – внедрение инструмента Business Studio. Он довольно длинный, так как после покупки и инсталляции системы нужно будет:

• создать пользователей и определить для них права доступа;
• настроить структуру системных справочников, в том числе ввести в базу орг.структуру компании;
• разработать шаблоны отчетов для автоматической выгрузки из Business Studio регламентов и других документов;
• настроить и сформировать html-публикацию (BS Portal);
• прочее.

Выполнение Этапа 4 «Проектирование архитектуры бизнес-процессов» может занять от 1 до 2,5 месяцев в зависимости от сложности структуры и бизнес-процессов компании. В Business Studio разрабатываются архитектурные модели бизнес-процессов в нотации IDEF0 на 1-3 уровнях (контекст, архитектура, модели категорий и групп). В зависимости от масштаба компании и сложности бизнес-процессов может потребоваться создать от 8-12 моделей (уровни 0, 1, 2) до 60-80 (уровень 3) в нотации IDEF0. На следующем уровне декомпозиции уже, как правило, используется нотация BPMN.

В рамках Этапа 5 «Описание и анализ бизнес-процессов «Как есть»» выполняется описание бизнес-процессов в нотации BPMN с фиксацией проблем и предложений по улучшению процессов, функциональных требований к информационным системам.  Важно отметить, что цель «описать все процессы» не ставится. Выбирается 1-2, максимум, 3 категории бизнес-процессов, которые являются наиболее важными для компании в текущем контексте. Например, это могут быть категории «Продажи», «Закупки» и «Логистика» или «R&D», «Управление ассортиментом и запасами» и т.п. Руководителям компании нужно определиться с выбором ключевых, наиболее важных для развития бизнеса категорий процессов и начинать детальное описание и анализ именно с них. То есть выбираются «пилотные» категории (группы) процессов, которые нужно оптимизировать в первую очередь.

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

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

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

Ближе к концу года, при наличии внедренных регламентов выполнения бизнес-процессов, выполняется Этап 9 «Проведение внутренних аудитов». Далее аудиты бизнес-процессов проводятся регулярно в соответствии с Программой аудитов.

Этап 10 «Проведение оценки зрелости СУБП» выполняется с использованием соответствующей методики в конце года (начало декабря). Его результатом является Отчет по оценке уровня зрелости СУБП. Для получения объективной картины оценка может проводиться внешними экспертами.

Результаты оценки уровня зрелости СУБП используются при выполнении Этапа 11 «Планирование развития СУБП и бизнес-процессов компании на 202_ год», в рамках которого обсуждаются полученные результаты, разрабатывается и утверждается План развития СУБП на следующий год.

На рис. 3 видно, что с момента завершения Этапа 7 «Оптимизация и регламентация бизнес-процессов» СУБП организации начинается работать в постоянном, штатном режиме. Выбираются следующие категории (группы) бизнес-процессов для анализа и оптимизации и проч.

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

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

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

Процессный офис

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

1. Управление функционированием и развитием СУБП Компании.
2. Развитие Методологии управления бизнес-процессами в Компании.
3. Управление архитектурой бизнес-процессов Компании.
4. Описание и анализ бизнес-процессов Компании.
5. Планирование и внедрение изменений в процессах.
6. Регламентация и стандартизация процессов.
7. Автоматизация (роботизация) бизнес-процессов (совместно с ИТ-подразделениями Компании).
8. Поддержка базы знаний по бизнес-процессам.
9. Развитие процессных компетенций (совместно с Департаментом по персоналу Компании).
10. Проведение внутреннего аудита бизнес-процессов Компании.
11. Управление подачей предложений сотрудников по улучшению бизнес-процессов.
12. Разработка и внедрение системы целей и показателей для управления бизнес-процессами (в т.ч. KPI).

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

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

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

Следующий важный и основной документ – это План/отчет Процессного офиса. В него включаются следующие задачи:

1. описание и анализ бизнес-процессов «Как есть»;
2. разработка мероприятий по оптимизации бизнес-процессов, в том числе проектирование бизнес-процессов «Как должно быть» (промежуточный и перспективный варианты);
3. разработка/актуализация регламентов и других внутренних нормативно-методических документов (ВНМД);
4. отмена ВНМД;
5. автоматизация бизнес-процессов в BPMS;
6. проведение обучения и аттестации сотрудников (в области процессного управления);
7. другие задачи.

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

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

Для моделей в нотации BPMN можно привести следующее определение:

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

Нормативное время создания модели в нотации BPMN для одного нормо-процесса «Как есть» может быть определено в пределах от 4 до 8 часов работы бизнес-аналитика. В этот время входят:

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

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

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

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

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

Одним из ключевых факторов успеха проекта внедрения СУБП является вовлечение руководителей и специалистов в «процессную работу».  К числу эффективных методов вовлечения можно отнести:

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

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

Риски проекта внедрения СУБП и компенсационные мероприятия

Проект внедрения СУБП, как части новой системы управления организацией, подвержен вполне типовым рискам, к числу которых можно отнести:

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

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

Таблица 3. Риски проекта внедрения СУБП и компенсационные мероприятия

Чтобы избежать указанных выше рисков нужно, в первую очередь, сформулировать видение и цели внедрения СУБП в документе «Концепция внедрения…». Далее необходимо понять, какие бизнес-процессы для компании являются ключевыми в текущем контексте и зачем их нужно трансформировать. Проект внедрения СУБП должен помочь решить ключевые проблемы бизнеса (Business Challenge). Кроме этого, нужно выделить на проект адекватные ресурсы и привлечь экспертов (в штат или в качестве внешних консультантов) – носителей методологии и опыта внедрения в других компаниях.

Выводы

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

Проект внедрения СУБП вполне реально выполнить за 8-10 месяцев. К этому сроку будут созданы основы системной практики управления бизнес-процессами, которую потом нужно будет развивать и совершенствовать.

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

Удачи во внедрении Системы управления  бизнес-процессами на платформе Business Studio!

В.В. Репин,

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

Март 2023 г.

www.bpm3.ru

[1] В рамках авторской Методики Владимира Репина.

[2] BI — Business Intelligence.

[3] OKR — Objectives and Key Results, «цели и ключевые результаты».

[4] Моделирующая сессия (МС) – специальный тип совещания, которое проводится по определенной методике с целью описания и анализа бизнес-процесса.

[5] BPMS – Business Process Management System.

[6] СЭД – Система электронного документооборота.

[7] КиПД – Корректирующие и предупреждающие действия.

[8] Нормо-процесс – схема в нотации BPMN, содержащая до 12 задач, шлюзы, документы, ресурсы и информационные системы. Авторское определение Владимира Репина.

[9] ИПР – Индивидуальный план развития.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Узкие места

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Февраль 2023 г.

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

Январь 2023 г.

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

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

Цели создания Фреймворка

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

Общая модель Системы стандартизации бизнес-процессов (ССБП)

На рис. 1 представлена общая модель (Фреймворк) Системы стандартизации бизнес-процессов (ССБП) компании.

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

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

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

Принцип построения Фреймворка ССБП – жизненный цикл внутренних нормативно-методических документов компании (регламенты, положения, инструкции): от разработки и ввода в действие, до анализа использования и отмены ВНМД. Не нужно путать ВНМД с планово-отчетными и организационно-распорядительными документами. Для управления документами указанных типов нужны другие бизнес-процессы. Они не входят в рассматриваемый Фреймворк.

1. Управление регламентацией процессов

На рис. 2 представлена схема процесса «Управление регламентацией процессов». На ней представлен контур управления ССБП: ежегодный и ежемесячный.

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

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

План может создаваться на год по месяцам с последующей ежемесячной корректировкой. Форма плана – файл в MS Excel. Документ может включать в себя одновременно плановую и фактическую информацию.

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

Если у вас есть возможность, то целесообразно автоматизировать планирование и отчетность в специализированной системе.

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

Проект Плана рассматривается и утверждается на Процессном комитете. Если у вас нет Процессного комитета, то его роль могут играть Комитет по ИСМ, Совет директоров или просто ЕИО (Генеральный директор).

Далее ежемесячно, например, 20 числа каждого месяца, Бизнес-аналитик Процессного офиса выполняет анализ исполнения Плана РАО на месяц и готовит соответствующий Отчет.

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

В случае необходимости он выполняет корректировку Плана РАО. В этом случае проект Плана РАО с корректировками передается на рассмотрение и утверждение на Процессом комитете. Далее цикл продолжается.

2. Разработка/корректировка ВНМД

На рис. 3 представлена схема процесса «Разработка/корректировка ВНМД». Участники процесса показаны при помощи ролей: «Разработчик ВНМД», «Руководители, согласующие ВНМД», «Бизнес-аналитик».

Разработчик ВНМД приступает к разработке в соответствии с Планом. В зависимости от ситуации, могут использоваться следующие документы: 1) модель (модели) бизнес-процесса в нотации BPMN (согласованная); 2) текущая версия ВНМД; 3) предложения по корректировке/дополнению ВНМД, накопленные в базе знаний, в том числе – предложения сотрудников.

В рамках рассматриваемого Фреймворка формирование проекта ВНМД осуществляется в Business Studio путем заполнения необходимых атрибутов модели: текстового описания задач процесса, привязки целей и показателей, определения методов контроля, привязки форм рабочих документов и т.п. После подготовки проекта ВНМД, разработчик, в качестве самоконтроля, проверяет документ с использованием чек-листа. Если по ходу работы выясняется, что необходимо изменить схему процесса, инициируется процесс «Описание процесса в нотации BPMN».

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

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

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

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

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

3. Ввод ВНМД в действие

На рис. 4 показана схема процесса «Ввод ВНМД в действие». Разработчик ВНМД запрашивает у Бизнес-аналитика код ВНМД. Бизнес-аналитик присваивает ВНМД код в соответствии с утвержденными правилами и вносит проект ВНМД в Реестр ВНМД.

Разработчик ВНМД готовит проект приказа о вводе ВНМД в действие и, в качестве приложения к нему, — План внедрения ВНМД.

Здесь нужно сделать небольшое отступление. Как вы думаете, когда руководитель ставит свою подпись «Утверждаю» на проекте регламента, это магическое действие? Любое магическое действие должно приводить к мгновенному исполнению задуманного (это – шутка). Когда новый ВНМД утверждается, означает ли это, что его требования начинают мгновенно и правильно выполнять сотрудники организации? Конечно, нет. Прежде всего, они должны узнать о том, что новый документ введен в действие. Затем ознакомиться с ним. Понять требования и научиться их исполнять. Это даже вопрос не одного дня, а целого переходного периода. Не говоря уже о том, что необходим контроль исполнения требований нового регламента со стороны руководителей. Именно поэтому внедрение ВНМД – это не только утверждение соответствующего документа, это – целый процесс, который должен быть запланирован и выполнен в организации. Для этого создается План внедрения ВНМД.

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

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

Если замечаний нет, то комплект документов передается на утверждение. Комплект включает: 1) согласованный проект ВНМД; 2) проект приказа в вводе ВНМД в действие; 3) План ввода ВНМД в действие.

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

Далее владелец процесса/руководитель подразделения организует выполнение плана внедрения ВНМД.

4. Размещение ВНМД в архиве, на портале и уведомление о статусе

На рис. 5 представлена схема процесса «Размещение ВНМД в архиве, на портале и уведомление о статусе». Выполняет процесс Бизнес-аналитик Процессного офиса.
На схеме показаны два стартовые события: «ВНМД утвержден» и «ВНМД отменен». Далее представлены два разных потока работы.

В случае, когда ВНМД утвержден, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. сканирует ВНМД и помещает оригинал ВНМД в архив документов компании;
3. размещает ВНМД в базе Business Studio (публикация на портале BS Portal выполняется автоматически по расписанию);
4. выполняет рассылку уведомлений в вводе ВНМД в действие (например, по e-mail).

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

В случае, когда ВНМД отменен, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. удаляет ВНМД из Business Studio;
3. помещает оригинал ВНМД в архив отмененных документов;
4. утилизирует оригинал ВНМД (при необходимости);
5. выполняет рассылку уведомлений об отмене ВНМД (например, по e-mail).

Особенностью рассматриваемого процесса является использование:
• Реестра ВНМД;
• внутреннего портала (базы знаний компании по бизнес-процессам);
• бумажного архива ВНМД.

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

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

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

5. Выдача учтенных копий ВНМД

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

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

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

6. Контроль необходимости актуализации ВНМД

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

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

Ответственные за актуализацию предоставляют отчеты о статусе (нужна/не нужна) актуализации и планируемых датах ее начала.

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

7. Отмена ВНМД

Следующий процесс Фреймворка (рис. 8) – это «Отмена ВНМД». В случае, если необходимо отменить ВНМД, Бизнес-аналитик подготавливает проект приказа об отмене действия ВНМД. Руководитель, утверждающий ВНМД, утверждает приказ. Бизнес-аналитик помещает приказ об от мене ВНМД на сервер.

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

8. Анализ использования ВНМД

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

Один раз в полгода (или ежегодно) Бизнес-аналитик последовательно выполняет следующие задачи:

• проводит анкетирование сотрудников по ВНМД для выявления их актуальности и практической полезности;
• анализирует статистику использования ВНМД на внутреннем web-портале (сколько раз смотрели документы, как долго и т.п.);
• выполняет анализ результатов аудитов в части несоответствий по ВНМД;
• выполняет анализ предложений сотрудников по улучшениям ВНМД (поданных, внедренных).

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

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

9. Обучение и аттестация по ВНМД

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

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

Далее он готовит/корректирует вопросы для аттестации. Для этого используется Методика подготовки вопросов и действующие ВНМД.

Технически вопросы для аттестации могут быть занесены в соответствующие атрибуты процессов (и других объектов) в базе данных Business Studio.

Затем Бизнес-аналитик готовит формы для аттестации, например, на внутреннем портале компании или с использованием сервиса Яндекс-формы.

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

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

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

После проведения соответствующего обучения разработчики ВНМД уведомляют Бизнес-аналитика и руководителей подразделений о проведенном обучении.

10. Контроль исполнения ВНМД руководителями

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

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

По итогам проведения контроля его результаты (факт, причины, предложения) фиксируются в журнале контроля ВНМД (в электронном виде).

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

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

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

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

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

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

Таблица сравнительного анализа

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

Андрей Краснобаев, Директор по качеству СТД «Петрович», практик в области организационного развития.

Вячеслав Гончаров, Начальник управления технологического сопровождения АО «Концерн «Уралвагонзавод».

Наталья Косарева, Руководитель компании. Эксперт в области организационного развития. Эксперт в области аудита производственных систем. Организатор Кубка Гастева. Член ABPMP Russian Chapter

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

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

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

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

Выводы

В статье представлен Фреймворк Системы стандартизации бизнес-процессов компании (ССБП). Это часть общей Системы управления бизнес-процессами (СУБП).
Использовать представленный в статье материал вы можете следующим образом:

1. сравнить существующие у вас процессы и решения с представленными во Фреймворке;
2. найти отличия (то есть провести так называемый «маппинг»);
3. дополнить/скорректировать вашу модель работы с ВНМД;

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

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

Апрель 2022 г.

Методология или Методика

В Википедии вы можете найти следующее определение Методологии: «Методоло́гия (от греч. μεθοδολογία — учение о способах) — учение о методах, способах и стратегиях исследования предмета». Так же там приводится информация о том, что «Практическая… Методология… — это программа (алгоритм), набор приёмов и способов того, как достичь желаемой практической цели…».

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

С другой стороны, я бы мог не упоминать термин «Методология» вообще. Но разработка регламентов СУБП требует конкретной методической основы. Они не могут быть созданы без какого-либо обоснования.

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

3. Разработка Методологии и регламентация процессов СУБП.
   3.1. Регламентация деятельности Процессного офиса.
   3.1.1. Разработка Положения о процессном офисе.
   3.1.2. Разработка формы Плана/отчета Процессного офиса.
   3.1.3. Разработка нормативов для Процессного офиса.
   3.1.4. Разработка индивидуальных форм отчетности сотрудников Процессного офиса.
   3.1.5. Разработка ИПР сотрудников Процессного офиса.
   3.2. Регламентация процессов СУБП.
   3.2.1. Разработка Положения о Процессном комитете.
   3.2.2. Разработка Положения о владельце сквозного процесса.
   3.2.3. Разработка формы Плана/отчета по описанию, анализу, оптимизации, регламентации и автоматизации процессов.
   3.2.4. Разработка формы плана/отчета развития СУБП.
   3.3. Регламентация процесса описания, анализа и оптимизации процессов.
   3.3.1. Разработка Соглашения по моделированию процессов.
   3.3.2. Разработка Регламента описания и анализа процесса.
   3.3.3. Разработка Регламента внедрения изменений в процесс.
   3.3.4. Разработка Регламента подготовки ТЗ на автоматизацию процесса.
   3.4. Регламентация процессов управления ВНМД.
   3.4.1. Разработка структуры и форм ВНМД.
   3.4.2. Разработка Регламента управления ВНМД.
   3.5. Разработка Регламента оценки уровня зрелости СУБП.

В данной статье я подробнее остановлюсь на подразделе «3.1. Регламентация деятельности Процессного офиса».

Процессный офис

BPM CBOK определяет «Процессный офис» (Business Process Management Office) и/или «Центр компетенции BPM» как подразделение, задачами которого являются:
• стандартизация процессов;
• унификация средств и методов работы с процессами;
• обучение принципам и методам BPM (Business Process Management);
• общий надзор за проектированием процессов и интеграция процессов на уровне предприятия;
• мониторинг и предоставление отчетов по показателям процессов для их владельцев и высшего руководства.

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

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

Положение о Процессном офисе

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

1. Общие положения.
2. Организационная структура Процессного офиса.
3. Цели и показатели деятельности Процессного офиса.
4. Выполняемые бизнес-процессы (функции).
5. Права.
6. Ответственность.
7. Требования к компетенции бизнес-аналитиков.
8. Нормирование труда бизнес-аналитиков.
9. Взаимодействие с другими подразделениями.
10. Оценка деятельности и стимулирование сотрудников Процессного офиса.
11. Приложения.
    a. Форма «План/отчет по работе Процессного офиса».
    b. Форма «План/отчет сотрудника за неделю».
    c. Форма «Индивидуальный план развития сотрудника».

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

Функции Процессного офиса

К основным функциям процессного офиса можно отнести:

1. Управление архитектурой процессов компании.
2. Организация и координация «процессной работы».
3. Описание и анализ процессов.
4. Планирование и внедрение изменений в процессах.
5. Регламентация и стандартизация процессов.
6. Участие в проектах автоматизации (роботизации) процессов.
7. Поддержка базы знаний по процессам (на web-портале компании).
8. Методология и контроль (схемы процессов, ВНМД).
9. Развитие процессных компетенций.
10. Предоставление аналитических отчетов руководству.

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

Планы, которые использует Процессный офис

В рамках СУБП может использоваться несколько различных видов планов, в том числе:
• План мероприятий по развитию СУБП на год (методология, инструменты, ВНМД, компетенции).
• План/отчет по описанию, анализу, оптимизации, регламентации и автоматизации процессов.
• Оперативный план/отчет по работе Процессного офиса.

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

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

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

Второй план – это План/отчет по описанию, анализу, оптимизации, регламентации и автоматизации процессов. Форма этого плана разрабатывается при выполнении группы работ «Регламентация процессов СУБП». Это сводный план по всей компании. Он включает задачи и проекты по указанным направлениям, например, сколько процессов планируется описать и регламентировать, сколько автоматизировать и т.д. Опять же, исполнителями проектов могут быть структурные подразделения, а не только бизнес-аналитики Процессного офиса. Важно отметить, что при формировании плана необходимо оценивать трудоемкость всех задач в человеко-часах и учитывать ресурс времени руководителей и специалистов, которые реально может быть выделен для их выполнения.

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

Нормативы для Процессного офиса

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

Указанные нормы определены для так называемого «Нормо-процесса». Это условный процесс, который включает до 15 шагов и умещается на листе формата А4. Если не вводить понятие «Нормо-процесс», то деятельность бизнес-аналитиков Процессного офиса будет сложно планировать.

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

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

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

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

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

Более подробно ознакомиться с этой темой вы сможете, посмотрев видео на моем канале:

Индивидуальные формы отчетности сотрудников Процессного офиса

Руководителю Процессного офиса важно понимать, сколько времени тратят бизнес-аналитики для получения конкретного результата. Например, была поставлена задача собрать информацию по процессу, провести одно интервью и сформировать графическую схему в нотации BPMN. На все было отведено 10 часов. В результате сотрудник представил схему из 4 шагов и в отчете указал фактическую трудоемкость 4 рабочих дня (32 часа). Что делать в этом случае? Десять часов на описание одного «Нормо-процесса» — достаточно много. Часто для этого хватает и 3 часов, если процесс простой. Для сложных случаев (4 интервью, 15 шагов, сложная логика) десяти часов может не хватить. В рассматриваемом примере схему из 4 шагов можно было сделать за 2-3 часа, включая интервью. Факт – 32 часа. Скорее всего, с данным бизнес-аналитиком придется расставаться (хотя бы потому, что он спокойно поставил в отчет 32 часа на решение простой задачи, завысив трудоемкость более, чем в три раза!).

Итак, чтобы видеть реальную картину Руководителю Процессного офиса нужен индивидуальный «План/Отчет» бизнес-аналитика за неделю. Он может быть подготовлен в MS Excel. Структура документа довольно проста: дата/день недели, задача, план и факт в часах, результат (ссылки на документы, модели и т.п.).

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

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

Индивидуальные планы развития сотрудников Процессного офиса

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

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

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

В частности, бизнес-аналитику можно поставить цель пройти сертификацию по Профессиональному стандарту «Специалист по процессному управлению» (утвержден приказом Министерства труда и социальной защиты Российской Федерации от «17» апреля 2018 г. № 248н.) или сертификацию OMG CERTIFIED EXPERT IN BPM™ 2 (OCEB™ 2), что несколько сложнее (нужно свободно знать английский язык и быть профи в BPM).

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

В целом, я считаю наличие системы работы с ИПР важной частью деятельности Процессного офиса.

Что дальше?

Далее в статьях серии я рассмотрю следующие аспекты разработки Методологии и регламентов СУБП:
• Регламентация процессов СУБП.
• Регламентация процесса описания, анализа и оптимизации процессов.
• Регламентация процессов управления ВНМД.
• Разработка Регламента оценки уровня зрелости СУБП.

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС», руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы.

Август 2020 г.

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

История вопроса

В декабре 2012 года на конференции «ПРОЦЕССНОЕ УПРАВЛЕНИЕ: сегодня и завтра» я прослушал весьма интересный доклад Наталии Самариной, Начальника отдела организационного развития ЗАО «ЮИТ Санкт-Петербург». В рамках доклада приводилась информация о методе описания процессов, используемом ООР в «ЮИТ». Это была так называемая «Моделирующая сессия» — совещание по структурированию процессов с привлечением руководителей и специалистов подразделений (см. рис. 1 – фото из опубликованного доклада).

Метод весьма заинтересовал, и я решил ознакомиться с ним ближе – съездил в Питер в компанию «ЮИТ». Наталия любезно разрешила присутствовать на одной из МС, которые регулярно проводятся в компании.

Моделирующая сессия

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

В начале МС бизнес-аналитик кратко рассказывает о целях ее проведения и методическом походе. Затем на флипчарте рисуется контекстная диаграмма процесса (процесс как «черный ящик»). Сверху указываются нормативные документы. Определяется структура подпроцессов. Обсуждаются основные входы/выходы. Далее выбирается один из подпроцессов, который рассматривается детальнее.
При описании подпроцесса используется любопытная технология визуализации. На большие листы упаковочной бумаги, прикрепленные в доске, последовательно наклеивают липкие листочки разного цвета. Светлые (белые) листки используются для описания операций, исполнителей и событий. Название операций пишут синим цветом, исполнителей – зеленым, события – черным. Дополнительно используют желтые листки меньшего размера. Они служат для отображения развилок процесса (ветвления процесса с применением оператора «ИЛИ») – см. рис. 2.

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

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

Алгоритм проведения сессии

Используя знания о методе проведения МС в «ЮИТ» мы разработали свою версию данного подхода. На рис. 3. Показана схема процесса проведения МС. При проведении МС мы дополнительно используем проектор, который выводит на большой экран таблицу MS Excel, содержащую список операций рассматриваемого процесса («домашняя заготовка» бизнес-аналитиков).

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

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

Преимущества и недостатки МС

Стоит обсудить преимущества МС и риски, которые могут возникнуть при ее проведении в компании.

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

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

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

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

Резюме

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

В.В. Репин, к.т.н., доцент, консультант по управлению.

Сентябрь 2013 г.

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

Технологии и компетенции ООР

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

1. технология планирования и учета деятельности ООР, в том числе нормирование работы БА;
2. технология описания (моделирования) и регламентации бизнес-процессов;
3. технология работы со средой моделирования процессов;
4. технология оптимизации бизнес-процессов (реинжиниринга);
5. технология обучения сотрудников компании.

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

Планирование и учет деятельности ООР

Технология планирования и учета деятельности ООР должна включать такие аспекты, как формирование плана работы ООР на месяц, формирование еженедельных отчетов БА, формирование отчета по выполнению плана ООР на месяц.
План работы ООР не может быть самодостаточным или, другими словами, оторванным от других планов компании. Он должен базироваться на общем плане описания, анализа, оптимизации и аудита бизнес-процессов организации. Это может быть один план или комплект планов. Такой план может отличаться от плана работы ООР в том случае, если в бизнес-единицах (далее — БЕ) компании есть свои бизнес-аналитики, которые административно подчиняются руководителям БЕ. Если компания относительно небольшая и БЕ не выделены, отдельного подразделения внутреннего аудита нет, то план работы ООР может совпадать с общим планом описания, анализа, оптимизации и аудита бизнес-процессов организации.
План работы ООР должен быть в достаточной степени напряженным (т.е. не должно быть простоя ресурсов), но в тоже время практически реализуемым. Формирование такого плана – всегда поиск некоторого компромисса между целями топ-менеджера и возможностями ООР.

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

Таблица 1. Нормативы деятельности бизнес-аналитиков

В таб. 1 использовано понятие «Нормо-процесс» – это графическая схема в формате А4, содержащая 12-20 операций. Так же упоминается «моделирующая сессия» (далее — МС) –это совещание, на котором по определенной технологии проводится описание бизнес-процесса. МС проводится бизнес-аналитиками ООР с привлечением руководителей и специалистов, участвующих в выполнении процесса.
В зависимости от существующих компетенций БА и других факторов (например, общая корпоративная культура в компании, наличие команды менеджеров и т.п.) нормативы могут меняться.

Технология описания (моделирования) и регламентации бизнес-процессов

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

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

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

Технология работы со средой моделирования процессов

В современной компании неразумно описывать бизнес-процессы «на коленке», т.е. используя такие инструменты, как MS Word, MS Excel, MS Visio или Power Point. Целесообразно создать электронный репозиторий или, другими словами, базу знаний компании по бизнес-процессам. Для этого используются инструментальные средства моделирования, например Business Studio 4.0 или iGrafx 2013.
Описание процессов в современной среде моделирования предполагает выбор и использование стандартной нотации, например «Процедура» Business Studio, BPMN, eEPC.
Для эффективной работы со средой моделирования ООР необходимы, как минимум, два нормативных документа:

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

1. ОБЩИЕ ПОЛОЖЕНИЯ
   1.1.Назначение и область действия
   1.2.Используемые сокращения
   1.3.Термины и определения
   1.4.Нормативные ссылки
   2.ВЕДЕНИЕ СПРАВОЧНИКОВ В «BUSINEES STUDIO»
   2.1.Справочник «Процессы»
   2.2.Справочник «Субъекты»
   2.3.Справочник «Объекты деятельности»
   2.4.Справочник «Управление»
   3.ОПИСАНИЕ ПРОЦЕССОВ В «BUSINEES STUDIO»
   3.1.Элементы нотации «Процедура» «Business Studio»
   3.2.Описание операций процесса
   3.3.Использование стрелок типа «связь предшествования»
   3.4.Использование стрелок типа «поток документов»
   3.5.Использование событий
   3.6.Использование блока «Решение»
   3.7.Использование междиаграммных ссылок
   3.8.Использование сносок
   4.СХЕМЫ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ В «BUSINEES STUDIO»
   4.1.Используемые графические элементы
2. ЗАПОЛНЕНИЕ АТРИБУТОВ ОБЪЕКТОВ МОДЕЛИ
   5.1.Заполнение атрибутов процесса
   5.2.Заполнение атрибутов операции процесса
   5.3.Заполнение атрибутов стрелок
   5.4.Заполнение атрибутов субъекта деятельности
   5.5.Заполнение атрибутов объекта деятельности
   5.6.Заполнение атрибутов целей и показателей

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

1.ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Назначение и область действия
1.2. Используемые сокращения
1.3. Термины и определения
1.4. Нормативные ссылки

2. ОБЩЕЕ ОПИСАНИЕ ПРОЦЕССА
   2.1. Общее описание процесса
   2.2. Графическая схема процесса
   2.3. Цели и показатели
   2.4.Методы контроля исполнения процесса
3. ОПИСАНИЕ ПОДПРОЦЕССОВ
   3.1.Регулярная проверка и актуализация справочников
   3.2.Внесение изменений в справочник процессов
   3.3.Внесение изменений в справочник «Субъекты»
   3.4.Внесение изменений в справочники «Объекты деятельности» и «Управление»
   3.5.Управление правами пользователей
   3.6.Импорт/экспорт данных из BS в формате xml
   3.7.Внесение изменений в мета-модель и применение к БД
   3.8. Внесение изменений в шаблоны отчетов
   3.9.Переход с версии на версию
   3.10. Обслуживание базы данных
4. ПРИЛОЖЕНИЯ Данный регламент используется БА, ответственными за поддержание электронного репозитория бизнес-процессов компании.

Технология оптимизации бизнес-процессов (реинжиниринга)

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

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

Технология обучения сотрудников компании

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

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

Компетенции бизнес-аналитиков

В наши дни бизнес-аналитик ООР – это человек с широким кругозором, высокой культурой мышления, коммуникабельный и, конечно, обладающий профильными компетенциями (описание, анализ, оптимизация и регламентация бизнес-процессов).
Очевидно, что подобрать идеальных сотрудников в компанию практически невозможно. Но вполне реально разработать набор тестовых вопросов и заданий для оценки кандидатов на должность БА, чтобы обеспечить приемлемый уровень. Конечно, нотациям и программам для моделирования можно научить. Важнее, чтобы кандидат имел аналитический склад ума, грамотно умел общаться с людьми, получая и обрабатывая информацию. Но наличие профильных знаний все таки является большим «плюсом».
В ООР довольно часто возникает следующая проблема. БА не могут на равных разговаривать с руководителями. Они не помогают руководителям анализировать процессы, не задают нужные вопросы, не предлагаю подходы и решения по оптимизации. БА только слушают, фиксируют информацию и формируют графические схемы. Но деятельность ООР должна быть ориентирована на бизнес, на повышение его эффективности. Если БА подходят к своей работе формально и являются только «писателями», то эффект получается низкий. Поэтому, на мой взгляд, целесообразно постоянно развивать компетенции бизнес-аналитиков по следующим направлениям:
• применение теории ограничений (ТОС);
• анализ потерь при выполнении процессов (и шире – Lean в целом);
• аналитические методы (графический и трендовый анализ, корреляционный анализ, построение контрольных карт Шухарта и проч.);
• методы ТРИЗ;
• командообразование;
• психология (в т.ч. методики эмоционального лидерства).

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

Практический пример

Рассмотрим пример внедрения указанных выше технологий в ООР конкретной торгово-производственной компании численностью несколько тысяч человек.
В таб. 2 показаны некоторые изменения, которые произошли в компании в период с начала декабря 2012 года по начало мая 2013 года.

Таблица 2. Изменения в деятельности ООР.

На следующих рисунках показано сравнение ситуации в компании в 2012 и 2013 годах по четырем аспектам:
• мнение руководителей о существующей системе процессов;
• мнение руководителей о графических схемах процессов;
• оценка степени актуальности базы регламентирующих документов компании;
• оценка руководителями существующей системы управления ЖЦ НМД.

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

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

На рис. 2 видно, что в 2012 году руководители весьма низко оценивали графические схемы процессов, разрабатываемые БА ООР. В 2013 году ситуация радикально изменилась. Более половины руководителей считают графические схемы наглядными и понятными, используют их в работе.

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

Анализ диаграмм рис. 4 показывает, что необходимо продолжать работу по совершенствованию технологии управления ЖЦ НМД. Например, можно пойти по пути создания web-портала для внедрения безбумажной технологии регламентации бизнес-процессов компании (например, используя Business Studio Portal).

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

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

Резюме

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

В.В. Репин, к.т.н., доцент, консультант по управлению.

Август 2013 г.