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

От автора

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

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

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

Хочу выразить благодарность моим коллегам: Ляйсан Шарифуллиной, Андрею Краснобаеву, Вячеславу Гончарову, Тамаре Рушновой, Роману Заболотному и Ольге Голубевой, Елене Захаровой, Станиславу Туркову, Елене Тестер, Евгению Галиулину, Александре Мельниковой, Светлане Панкратовой за интересные кейсы по созданию и организации работы процессных офисов.

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

Также хочу поблагодарить Президента ABPMP Russian Chapter Анатолия Белайчука за материал по сертификации и оценке профессиональных компетенций процессных аналитиков.

Отдельно выражаю свою признательность Антону Вагнеру за разработку дизайна книги.

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

Глава 1. Введение.
Зачем нужен процессный офис?

1.1. Операционная эффективность бизнеса

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

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

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

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

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

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

1) отказаться от выставления претензий, начиная с определенной суммы (при этом вносить соответствующих поставщиков в «черный список» или накапливать претензии, а потом выставлять сразу несколько);

2) радикально изменить процесс работы с претензиями, повысив его эффективность;

3) сознательно смириться с возникающими потерями (худший вариант);

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

Когда я говорю о методах повышения операционной эффективности, то в первую очередь имею в виду:

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

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

1.2. Система управления компанией и СУБП

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

• систему стратегического управления;

• систему маркетинга;

• систему продаж;

• систему закупок;

• систему управления персоналом и так далее.

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

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

1. Системы управления компанией.

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

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

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

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

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

Система управления бизнес-процессами (СУБП) — часть общей системы управления. Ее основная цель — помочь руководителям сделать бизнес-процессы компании управляемыми и эффективными. Приведу рабочее определение СУБП:

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

СУБП организации основана на концепции BPM (Business Process Management).

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

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

1. Архитектура бизнес-процессов.

2. Управление бизнес-процессами по целям и показателям.

3. Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ (KPI).

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

5. Практика оптимизации бизнес-процессов и внедрения изменений.

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

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

8. Контроль и аудит бизнес-процессов.

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

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

Хотел бы обратить ваше внимание, что процессный офис является обязательным элементом СУБП.

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

1.3. Что такое процессный офис?

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

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

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

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

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

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

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

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

1.4. Базовая модель работы процессного офиса

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

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

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

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

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

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

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

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

1.5. Для кого написана эта книга?

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

• собственников;

• генеральных директоров;

• директоров по стратегическому развитию;

• директоров по организационному развитию;

• заместителей руководителей организации по эффективности бизнес-процессов;

• вице-президентов по оптимизации бизнес-процессов;

• других руководителей.

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

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

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

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

Глава 2. Организационная структура и роли процессного офиса

2.1. Типовые должности и роли процессного офиса

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

1. Руководитель процессного офиса.

2. Процессный архитектор.

3. Процессный методолог.

4. Ведущий бизнес-аналитик / бизнес-аналитик.

5. Руководитель проектов.

6. Внутренний аудитор.

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

Руководитель процессного офиса

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

---

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

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

Процессный архитектор

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

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

• выполняет моделирование процессов верхнего уровня (архитектурных моделей) в различных нотациях (VAD, IDEF0, DFD);

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

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

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

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

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

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

Дополнительно я приведу здесь описание трудовой функции процессного архитектора из профессионального стандарта. В соответствии с Профессиональным стандартом «Специалист по процессному управлению» №1138 (утвержден приказом Министерства труда и социальной защиты РФ от 17 апреля 2018 г. №248н) процессный архитектор в рамках обобщенной трудовой функции «Проектирование и трансформация процессной архитектуры компании» выполняет следующие трудовые функции:

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

---

Процессный методолог

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

• моделирование бизнес-процессов на верхнем и нижнем уровне («Соглашение по моделированию»);

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

• разработка целей и показателей;

• анализ бизнес-процессов;

• выполнение проектов оптимизации и автоматизации (совместно с ИТ-службой) и др.

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

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

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

В соответствии с профессиональным стандартом «Специалист по процессному управлению» №1138 (утвержден приказом Министерства труда и социальной защиты РФ от 17 апреля 2018 г. №248н) процессный методолог в рамках обобщенной трудовой функции «Проектирование и внедрение СУБП компании» выполняет следующие трудовые функции.

Ведущий бизнес-аналитик / бизнес-аналитик

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

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

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

---

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

В соответствии с профессиональным стандартом «Специалист по процессному управлению» №1138 (утвержден приказом Министерства труда и социальной защиты РФ от 17 апреля 2018 г. №248н) бизнес-аналитик (процессный аналитик) в рамках обобщенной трудовой функции «Проектирование и внедрение СУБП компании» выполняет следующие трудовые функции.

Руководитель проектов

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

• проект анализа и оптимизации кросс-функционального бизнес-процесса;

• проект разработки системы KPI (КПЭ);

• проект автоматизации бизнес-процессов в BPMS или СЭД;

• проект разработки модели компетенций и учебных материалов в области процессного управления;

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

• и т. д.

---

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

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

Внутренний аудитор

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

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

Ключевые функции роли «внутренний аудитор»:

• планирование аудитов;

• подготовка и проведение аудитов;

• формирование заключений и разработка предложений по корректирующим и предупреждающим действиям;

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

• ведение базы знаний результатов аудита.

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

---

Должности и роли процессного офиса в зависимости

от размера бизнеса

В таблице 6 показано, какие роли могут играть сотрудники процессного офиса в зависимости от размера компании.

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

2.2. Структура процессного офиса для компаний различного размера

Структуру процессного офиса определяют следующие факторы:

1) размер компании;

2) положение структурного подразделения в организационной структуре;

3) цели и задачи, поставленные собственником и/или руководителем компании перед процессным офисом;

4) требования по:

а) срокам и масштабу внедрения СУБП;

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

5) ограничение по ресурсам (в первую очередь по людям).

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

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

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

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

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

Организация численностью 100–250 человек

На рис. 3 показана структура данного подразделения для организации численностью 100–250 сотрудников.

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

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

Организация численностью 250–1000 человек

На рис. 4 показана структура процессного офиса для организации численностью 250–1000 сотрудников.

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

Организация численностью 1000–5000 человек

На рис. 5 показана структура процессного офиса для организации численностью 1000–5000 работников.

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

Схема, представленная на рис. 5, на мой взгляд, является оптимальной — сбалансированной по составу и численности.

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

Численность организации более 5000 человек

На рис. 6 показана структура процессного офиса для организации численностью более 5000 сотрудников.

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

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

Отдел автоматизации бизнес-процессов в low-code выполняет автоматизацию (при тесном взаимодействии с ИТ-подразделением) кросс-функциональных бизнес-процессов с использованием BPM-системы (СЭД). Включение этого отдела в процессный офис обусловлено необходимостью устранить узкое место в лице ИТ-департамента организации в части быстрой и гибкой настройки и ввода в эксплуатацию автоматизированных бизнес-процессов в BPMS (например, Elma-365, Comindware и пр.).

Ограничение по численности процессного офиса

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

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

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

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

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

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

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

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

---

Брать бизнес-аналитиков со стажем работы менее 1 года не рекомендуется (если только стажером). При отсутствии другого варианта можно взять работника на испытательный срок, который должен составлять не менее 3 месяцев.

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

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

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

Глава 3. Цели и показатели деятельности процессного офиса

3.1. Эффективность бизнес-процессов

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

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

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

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

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

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

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

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

3.2. Развитие системы управления бизнес-процессами

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

На рис. 7 показан пример оценки уровня зрелости СУБП компании за 2024 год (старт проекта внедрения СУБП) и план на 2025 год.

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

3.3. Качество работы процессного офиса

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

Во-первых, можно измерять качество работы путем выборочной оценки нескольких моделей бизнес-процессов (15–20 шт., в нотациях IDEF0/VAD и BPMN/eEPC) при помощи чек-листа. Кроме того, можно и нужно оценивать качество внутренних регламентирующих документов: регламентов, положений, инструкций. Процессный офис может сам разрабатывать такие документы либо выполнять контроль их соответствия установленным требованиям и проверять на качество. В любом случае ответственность за качество ВНМД лежит на процессном офисе и поэтому может служить индикатором его работы. Оценка качества ВНМД выполняется так же выборочно (8–10 документов) по специальному чек-листу.

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

3.4. Развитие компетенций процессного офиса

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

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

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

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

3.5. Рекомендуемые цели и показатели процессного офиса

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

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

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

Формула для оценки качества ВНМД:

Качество ВНМД в % = (∑ (Оценка ВНМД в баллах
(от 0 до 40) / 40) / (Количество ВНМД)) × 100%

Глава 4. Функции процессного офиса

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

1. Управление функционированием и развитием Системы управления бизнес-процессами (СУБП) компании.

2. Развитие методологии управления бизнес-процессами в компании.

3. Управление архитектурой бизнес-процессов компании.

4. Описание и анализ бизнес-процессов компании.

5. Планирование и внедрение изменений в процессах.

6. Регламентация и стандартизация процессов.

7. Автоматизация (роботизация) бизнес-процессов (совместно с ИТ-подразделениями).

8. Поддержка базы знаний по бизнес-процессам.

9. Развитие процессных компетенций (совместно с департаментом по персоналу).

10. Проведение внутреннего аудита бизнес-процессов компании.

11. Управление подачей предложений сотрудников по улучшению бизнес-процессов.

12. Разработка и внедрение системы целей и показателей для управления бизнес-процессами (в том числе KPI).

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

Ниже представлено подробное описание каждой функции процессного офиса.

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

Кстати, в положениях о структурных подразделениях часто путают следующие сущности: цели, задачи, функции. Например, «Описание бизнес-процессов компании» — это цель, задача или функция? Точно не цель — описание ради описания никому не нужно. Значит, задача? Тоже нет. Почему? «Описать бизнес-процесс управления дебиторской задолженностью „как есть“ в нотации BPMN к 1 апреля 2029 года» — это конкретная задача, строка в плане работы. Но постоянно повторяющаяся по установленной методике деятельность под названием «Описание бизнес-процессов компании» — это функция или процесс, различий нет, если четко определены контекст (границы) и метод выполнения.

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

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

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

4.1. Управление функционированием и развитием Системы управления бизнес-процессами (СУБП) компании

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

---

1. Проведение ежегодной оценки уровня зрелости СУБП

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

Оценку могут проводить сотрудники процессного офиса. Также могут привлекаться внешние эксперты. Обычно оценка занимает около 1–2 недель.

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

2. Разработка, согласование и контроль исполнения плана развития СУБП (ежегодно, ежеквартально)

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

3. Разработка, согласование и контроль исполнения плана описания, анализа, оптимизации, регламентации и автоматизации бизнес-процессов («План работы процессного офиса», ежегодно, ежемесячно)

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

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

---

4. Разработка, согласование и контроль исполнения индивидуальных планов развития сотрудников процессного офиса

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

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

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

5. Выполнение проектов развития СУБП компании

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

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

4.2. Развитие методологии управления бизнес-процессами в компании

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

1. Анализ использования методик управления бизнес-процессами в компании (ежегодно)

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

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

1) использование для обучения сотрудников;

2) использование для контроля качества (схем, проектов регламентов, планов проектов и пр.);

3) использование для разрешения ключевых методических вопросов в рамках проекта внедрения СУБП;

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

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

2. Актуализация «Соглашения по моделированию бизнес-процессов»

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

В начале выполнения проекта внедрения СУБП и создания процессного офиса в первые 2–4 месяца «Соглашение» может изменяться довольно часто, так как у команды проекта появляются новые идеи, команда узнает о функциональных возможностях инструмента моделирования, возникают ограничения и пожелания руководителей верхнего уровня и т. п. В последующем замечаний и предложений становится меньше. Но поскольку контекст меняется (выходят новые версии программы, возникают новые задачи, приходит понимание, как сделать лучше), актуализация «Соглашения» может проводиться ежеквартально или раз в полгода. В дальнейшем нужно актуализировать «Соглашение» стандартно — раз в год.

3. Выполнение контроля качества моделей бизнес-процессов с использованием чек-листов (формальный и содержательный)

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

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

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

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

4. Разработка/актуализация методик и регламентов в области приоритизации, описания, анализа, оптимизации, регламентации и автоматизации бизнес-процессов компании

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

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

4.3. Управление архитектурой бизнес-процессов компании

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

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

2. Поддержание в актуальном состоянии архитектурной модели компании в нотации IDEF0 (VAD)

Это ключевая функция процессного архитектора. На этапе внедрения СУБП разрабатывается архитектура компании на верхнем уровне в нотации IDEF0 или, например, VAD. В некоторых программных продуктах, например в 6-й версии Business Studio, вы можете создать собственную нотацию для моделирования бизнес-процессов верхнего уровня. Но я рекомендую все-таки использовать IDEF0. При этом надо иметь четкое представление о том, как именно использовать IDEF0 для создания модели. Рекомендую ознакомиться с моей книгой «Разработка архитектуры бизнес-процессов компании в Business Studio»:

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

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

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

1) функциональная модель;

2) структурно-функциональная модель;

3) модель на основе бизнес-компетенций;

4) модель на основе цепочек (сети) создания ценности;

5) модель на основе жизненного цикла продукции;

6) модель на основе структуры продуктов компании;

7) модель на основе цикла PDCA;

8) линейный перечень кросс-функциональных процессов;

9) прочие экзотические модели.

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

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

• должны быть определены заинтересованные стороны — ключевые пользователи конкретной модели в архитектуре процессов;

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

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

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

• спроектировать кросс-функциональный бизнес-процесс разработки нового изделия «от идеи до постановки на производство»;

• сформировать модель сквозного бизнес-процесса управления цепочкой поставок в группе компании;

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

• создать процесс сквозного интегрированного планирования;

• выявить все процессы, связанные с планированием и отчетностью;

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

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

• прочее.

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

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

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

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

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

Начиная с версии 6, в Business Studio представлены две нотации для проектирования процессов на верхнем уровне: VAD и IDEF0. Моделировать в VAD можно с использованием встроенного в систему редактора, в IDEF0 — при помощи MS Visio. В 7-й версии Business Studio доступен только встроенный редактор, который поддерживает две рассматриваемые нотации моделирования.

На рис. 11 представлен еще один пример модели архитектуры бизнес-процессов компании, выполненной в нотации VAD.

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

В Business Studio можно создавать несколько представлений архитектуры, в том числе:

1) строить диаграммы с использованием группы функций VAD (как показано на рис. 11, использован тип связи «Композиция»);

2) строить дерево бизнес-процессов на одной диаграмме VAD с использованием типа связи «Композиция»;

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

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

Если при работе в Business Studio 6 выбран редактор MS Visio, то можно моделировать бизнес-процессы верхнего уровня в нотации IDEF0. При этом функциональные возможности по настройке визуального вида модели (вывод на показ параметров, визуальные стили) будут работать так же, как было в версии 5. Нужно понимать, что при использовании встроенного редактора и нотации VAD визуальная настройка модели может быть выполнена с использованием совершенно других, новых функциональных возможностей Business Studio 6 (7) — через стили, которые дают широкие и гибкие возможности по «кастомизации» визуального вида диаграмм.

Многие бизнес-аналитики задаются вопросом: «А какую нотацию лучше использовать для моделирования архитектуры бизнес-процессов компании?» С точки зрения профессионального процессного архитектора разницы нет. Главное — иметь правильный методический подход к созданию архитектуры. Но тем не менее я приведу здесь таблицу сравнительного анализа этих двух нотаций (таблица 9).

Чем нотация VAD привлекает многих руководителей и бизнес-аналитиков? Схемы можно «нарисовать» быстро. Это очевидно ключевое преимущество. Но какой ценой достигается эта быстрота? «Плитку» из «рыбок» в VAD можно сделать, но обоснование структуры бизнес-процессов на каждом уровне остается как бы за кадром. Процессный архитектор обязан использовать четкую методику построения архитектуры, определить границы каждого процесса и увязать их между собой по входам и выходам. Эта информация может быть структурирована в виде таблицы MS Excel, например. Но также она может остаться только в голове архитектора модели, что крайне плохо. Кроме того, отсутствие информации о границах процессов на схеме в нотации VAD может привести к ненужным дискуссиям руководителей при обсуждении архитектурных моделей компании.

Использование нотации VAD на среднем уровне также вызывает вопросы. Дело в том, что это почти BPMN, только без четкой логики — нет движения токенов, нет событий и шлюзов. Но зачем нужна такая «недонотация» — ни структурная, ни исполняемая?

Интересно разобраться, как вообще возникла нотация VAD. Концепция выявления и анализа цепочек создания ценности организации принадлежит Майклу Портеру. Это продуманная и практически полезная методология. Но вот нотация VAD, насколько я понимаю, — это детище профессора А. В. Шеера. Когда-то давно Шееру с его фирмой IDS Scheer нужно было (с маркетинговой точки зрения) отмежеваться от якобы «устаревшего метода функциональной декомпозиции IDEF0» и прикрыться красивой методологией цепочек создания ценности Майкла Портера. Только и всего… Какой-то глубокой методологии рисования «зеленых рыбок» у Шеера не было. Но вернемся к вопросу работы с архитектурой бизнес-процессов.

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

Они обусловлены:

• изменениями структуры компании и границ бизнес-процессов;

• изменением существующих бизнес-процессов;

• созданием новых бизнес-процессов;

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

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

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

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

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

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

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

4. Поддержание справочников архитектурной модели компании

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

• организационная структура;

• ролевая структура;

• документы;

• информация;

• события;

• программные продукты;

• хранилища (базы) данных;

• материальные объекты;

• цели и показатели;

• термины и определения;

• риски;

• проекты;

• прочие.

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

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

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

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

Как проявляется такой подход при создании корпоративной процессной архитектуры? В справочнике процессов возникает куча папок по фамилиям сотрудников, в которых они создают модели процессов, например, в нотации BPMN. При этом единые справочники документов, событий и другие наполняются хаотично, бессистемно, как попало. Различные, ненормированные названия, множество дублирующих друг друга объектов. При этом никакая архитектура бизнес-процессов (в нотации IDEF0 или VAD) не создается.

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

Есть ли альтернатива клиповому моделированию бизнес-процессов? Да, конечно.

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

На рис. 13 показан пример, как выглядит справочник «Деятельность» при создании процессной архитектуры организации с использованием нотации VAD в программном продукте Business Studio 6.

На рис. 14 показан справочник организационной и ролевой структуры (в Business Studio 6 он называется «Оргединицы»). Почему этот справочник должен быть частично заполнен в первую очередь? При создании архитектуры бизнес-процессов на схемах верхнего уровня желательно показывать должности владельцев процессов и наименование подразделений — исполнителей. Руководители верхнего уровня при работе с архитектурными схемами всегда хотят видеть эту информацию.

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

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

Роли в процессах и информационных системах (например, в 1С: ДО) могут создаваться по ходу проектирования бизнес-процессов компании. Заранее неизвестно, какие именно роли потребуются. Но папки для группировки ролей можно и нужно создать заранее. Правильный подход — создавать папки по названию процессных категорий компании.

Но можно и по названию крупных структурных подразделений. Обычно мы используем два уровня группировки ролей в виде папок. На третьем уровне можно создавать сами роли. Кстати, Business Studio позволяет создавать дочерние роли, например у роли «ИТ-администратор» может быть дочерняя роль «Администратор 1С: ДО» и т. п.

Кроме ролей и должностей, Business Studio позволяет создавать так называемые «Группы оргединиц». В такого рода объекты можно включать любые должности и роли из основного справочника с использованием типа связи «Агрегация». Это очень удобно для моделирования различных коллегиальных органов управления, например «Процессный комитет», «Правление», «Временная рабочая группа по проекту оптимизации бизнес-процесса» и т. п.

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

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

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

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

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

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

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

Отмечу, что в Business Studio 6 можно создавать иерархическую структуру документов без использования папок. Это может быть удобно, например, для моделирования пакетов документов, которые состоят из нескольких частей.

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

Отмечу, что документы в справочнике мы рассматриваем в широком смысле, например «Карточка контрагента» в 1С или «Запрос клиента через форму сайта» — это тоже документы.

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

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

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

Для создания статусов используется раздел «Термины» в справочнике «Функциональные объекты». Создавать статусы должен процессный методолог. Более того, желательно запретить остальным участникам проекта создавать свои статусы. Иначе через какое-то время в справочнике будет много мусора — неадекватно определенных, ненужных для моделирования статусов.

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

1) «Договор с клиентом», статусы «Согласован» и «Word»;

2) «Бюджет закупки», статусы «Утвержден» и «Excel»;

3) «Приказ», статусы «Утвержден» и «Бум.»;

4) «Контрагент», статусы «1С: ДО» и «Помечен на удаление»;

5) «Заявление на отпуск», статусы «Шаблон» и «Word».

На рис. 17 показан пример заполнения справочника «Программные продукты».

Можно группировать программное обеспечение с использованием папок, например «Корпоративное ПО», «Пользовательское ПО» и пр.

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

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

На рис. 18 показан справочник «Базы данных». На схемах в нотации BPMN объект из такого справочника выглядит как бочонок. Для описания процессов удобно интерпретировать эти «базы данных» в широком смысле — как хранилища для документов. Пример:

1) договор в формате MS Word разработан и хранится на компьютере — используется объект «ПК работника»;

2) далее договор отправляется по e-mail другому сотруднику — используется объект «Outlook», то есть файл с договором некоторое время «живет» в Outlook;

3) затем сотрудник загружает договор с 1С: ДО — используется объект «1С: ДО»;

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

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

Справочники «Информация» мы, как правило, в проектах не используем, поскольку вполне достаточно справочника «Документы». Если посмотреть свойства объектов «Документ» и «Информация» в Business Studio, то видно, что они практически не отличаются.

Но при моделировании крайне нежелательно плодить лишние сущности, дублирующие друг друга.

Что касается справочника «Материальные объекты», то он используется весьма редко. Для моделей процессов в нотации BPMN вполне достаточно объектов из справочника «Документы».

4.4. Описание и анализ бизнес-процессов компании

1. Формирование временных рабочих групп из сотрудников компании

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

На рис. 19 представлен пример структуры ВРГ. Она включает руководителя ВРГ, несколько (2–3) экспертов в предметной области (руководители и специалисты), бизнес-аналитика процессного офиса. В некоторых случаях может быть внешний эксперт — консультант по управлению, отраслевой эксперт и пр. Общая численность ВРГ не должна превышать 5–7 человек. Если проект сложный, то лучше создать несколько ВРГ по 3–5 человек, чем одну большую группу из 15–20 человек.

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

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

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

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

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

• не могут корректно определить границы и структуру процессов;

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

• забывают про описание входов/выходов;

• нарушают многие правила создания моделей типа work flow, в том числе некорректно используют значки BPMN;

• не фиксируют проблемы;

• прочее.

Фактически такие «модели» приходится потом переделывать «с нуля».

2. Описание и анализ бизнес-процессов (в рамках деятельности рабочих групп по бизнес-процессам или по заданию непосредственного руководителя) в нотациях IDEF0 (VAD) и BPMN (eEPC)

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

Описание бизнес-процессов целесообразно выполнять в специализированном программном продукте (например, Business Studio) в обоснованно, сознательно выбранных нотациях, подходящих для решения поставленных задач. В целом и чаще всего это нотации IDEF0 (VAD) — на верхнем уровне и BPMN — на нижнем.

Создание диаграммы в нотации IDEF0 может выполняться в следующей последовательности:

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

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

3. Определить и создать на диаграмме процессы (от 2 до 12). Обязательно указать процесс «Управление…» вверху диаграммы. Наличие готовой диаграммы с одним процессом (кроме контекстной диаграммы) не допускается. В случае наличия двух процессов на диаграмме рекомендуется пересмотреть диаграмму вышестоящего уровня, уточнить границы и состав процессов.

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

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

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

7. Зафиксировать проблемы и предложения по процессам (при наличии) визуально.

8. Зафиксировать функциональные требования (при наличии) визуально.

9. Показать для каждого блока владельца процесса и исполнителей (подразделения) путем использования настроек визуализации.

10. Обновить номера процессов на диаграмме. При этом процесс «Управление…» должен иметь номер 1.

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

12. Отключить сетку.

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

14. Отправить диаграмму на проверку качества процессному методологу (уведомить о готовности диаграммы).

Создание диаграммы в нотации BPMN выполняется в следующей последовательности:

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

2. Включить режим «Сетка».

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

4. Создать стартовое событие (события) процесса.

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

• задачи;

• шлюзы;

• события;

• информационные системы;

• документы;

• базы данных;

6. Указать статус для каждого документа, использованного в модели.

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

8. При необходимости заполнить атрибут «Требования к срокам» для каждой задачи. Вывести на показ.

9. При наличии информации сформулировать проблемы визуально.

10. При наличии информации сформулировать функциональные требования к ИС визуально.

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

12. Отключить режим «Сетка».

13. Передать схему процесса на согласование процессному методологу (уведомить о готовности схемы).

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

---

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

Ознакомиться с нотацией BPMN и моделированием бизнес-процессов с ее использованием можно в моей книге «Моделирование бизнес-процессов в нотации BPMN в Business Studio 5»:

Пример графической схемы в нотации BPMN, разработанной для целей анализа и проектирования автоматизированного процесса в 1С: ДО, показан на рис. 20.

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

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

3. Проведение моделирующих сессий/совещаний с руководителями и специалистами компании по описанию и анализу бизнес-процессов

Моделирующая сессия — это специальный вид совещания. МС проводится по определенной методике или, другими словами, сценарию.

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

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

4. Инициация проектов оптимизации бизнес-процессов

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

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

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

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

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

5. Валидация моделей бизнес-процессов (в том числе с использованием метода имитационного моделирования бизнес-процессов)

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

1) организовать и выполнить пробную эксплуатацию процесса;

2) выполнить имитационное моделирование.

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

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

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

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

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

4.5. Планирование и внедрение изменений в процессах

1. Разработка уставов и планов проектов оптимизации бизнес-процессов

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

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

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

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

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

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

Состав этапов проекта оптимизации кросс-функционального бизнес-процесса

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

Проектом оптимизации процесса можно считать такой проект, в рамках выполнения которого была подготовлена и использована хотя бы одна схема процесса в нотации BPMN. Это означает, что «проекты улучшений» типа «Замена ламината в офисе» или «Приобретение и монтаж агрегата „А“ в 3-м цеху» к проектам оптимизации административных кросс-функциональных бизнес-процессов компании не относятся (хотя и могут привести к повышению эффективности и пр.). Предлагаемые далее методы и инструменты для проектов такого типа неприменимы или применимы частично.

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

1. Инициация проекта и подготовка к его выполнению.

2. Предварительный анализ.

3. Углубленный анализ и разработка мероприятий по оптимизации.

4. Внедрение изменений.

5. Анализ эффекта от оптимизации процесса.

6. Подведение итогов проекта.

На рис. 21 показан фреймворк (комплекс типовых процессов) рассматриваемого проекта.

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

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

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

Для выполнения проекта удобно использовать так называемый «Органайзер» — файл в MS Excel. Найти его можно на моем сайте www.bpm3.ru. При дальнейшем чтении рекомендую открыть этот документ и, читая книгу, просматривать соответствующие разделы «Органайзера». Представленный ниже материал может быть использован для разработки методики (регламента) выполнения проекта оптимизации кросс-функционального бизнес-процесса в вашей организации.

Методы, инструменты и соответствующие страницы «Органайзера» представлены в таблице 10.

Хотел бы отметить следующее. Заполнение большого количество аналитических таблиц не ведет автоматически к глубокому пониманию причин проблем и проектированию оптимального процесса (то же самое можно сказать и о разработке стратегии компании). Это только инструмент систематизации, упорядочения аналитической работы. Чаще всего проблемы в бизнесе сложные, нестандартные и требуют креативного, даже дерзкого мышления и разработки новых, инновационных подходов. Можно привести примеры предприятий, которые внедрили Lean на производстве, но успешно обанкротились из-за неправильно выбранной стратегии и политики ценообразования. Предлагаемые мной подходы и сам «Органайзер» — это не панацея, а только рабочий инструмент, в дополнение к которому рабочая группа может выбирать и использовать подходящие к контексту методы и инструменты.

Инициация проекта и подготовка к его выполнению

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

В рамках первого этапа проекта формируется ВРГ — временная рабочая группа по проекту. В ее состав включают 3–5 человек — руководителей среднего звена и специалистов из подразделений, через которые проходит кросс-функциональный процесс. Делать ВРГ слишком большой (более 6 человек) нерационально. За ВРГ желательно закрепить бизнес-аналитика из процессного офиса компании. Также нужно назначить кого-то из участников ВРГ руководителем проекта (но не бизнес-аналитика).

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

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

1) Бизнес-контекст, заинтересованные стороны и их потребности.

2) Бизнес-проблема, текущие значения показателей процесса.

3) Цели проекта.

4) Возможный результат проекта, целевые значения показателей процесса.

Для понимания бизнес-процесса как объекта управления рекомендую прочитать мою статью «Типовая модель бизнес-процесса» на сайте www.bpm3.ru.

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

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

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

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

После заполнения листа «1. Карточка проекта» «Органайзера» и согласования с владельцем процесса издается приказ (распоряжение) по компании об инициации проекта. Наименование процесса, цели проекта оптимизации, состав ВРГ, сроки берутся в приказ из «1. Карточки проекта» «Органайзера».

Предварительный анализ

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

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

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

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

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

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

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

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

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

На странице «3. Анализ моделей „Как есть“» «Органайзера» представлена таблица, которую нужно заполнить после создания модели процесса «Как есть». Если вы используете такой инструмент, как, например, Business Studio, то проблемы лучше фиксировать в определенных атрибутах задач и выводить на показ через настройку параметров (или стилей). Можно также создать специальный справочник проблем по типам и использовать его для заполнения.

На рис. 22 показаны возможные типы проблем, которые можно выявить. Определено несколько типов: «Обработка», «Транспортировка», «Ожидание», «Ненужные движения» — это потери (метод Lean). Далее могут быть проблемы, связанные с технологией выполнения процесса и его автоматизацией, мотивацией исполнителей. Возможно, вы дополните перечень своими типами проблем, специфичными именно для вашей организации.

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

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

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

По итогам предварительного анализа и разработки проблемного поля ВРГ оценивает потенциал оптимизации бизнес-процесса и на странице «2. Проблемное поле» заполняет таблицу «4. Возможный потенциал оптимизации».

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

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

ВРГ разрабатывает оперативный план работы для следующего этапа проекта.

Углубленный анализ и разработка мероприятий по оптимизации

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

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

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

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

Результаты анализа причин проблем, информация по подтверждению гипотез заносятся на страницу «4. Углубленный анализ» «Органайзера». Желательно сразу фиксировать в этой таблице идеи и предложения по изменениям.

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

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

• устранение потерь различного вида и организация процесса в соответствии с принципами TPS;

• клиентоцентричность;

• минимизация рисков;

• автоматизация (доработка и интеграция ИС, внедрение BPMS/СЭД, внедрение специализированного ПО, цифровизация — RPA, «Нейронка»);

• разработка SLA и стимулирование участников процесса;

• регламентация и контроль процесса;

• прочие.

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

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

2. Технология управления бизнес-процессом.

3. Ресурсы для выполнения процесса, в том числе персонал.

4. Информационные системы.

5. Интеграция бизнес-процесса с другими процессами компании и контрагентов.

6. Прочее.

---

На странице «Органайзера» «5. Мероприятия» участники ВРГ указывают:

• Наименование мероприятия.

• Наименование процесса/подпроцесса.

• Описание мероприятия.

• Область оптимизации.

• Описание ожидаемого результата.

• Возможные риски и компенсационные мероприятия.

Для каждого мероприятия необходимо определить следующие параметры:

• Плановая трудоемкость, человеко-часов.

• Плановый бюджет, тыс. рублей

• Плановый эффект, тыс. рублей.

• Плановая эффективность (расчет по формуле: (Плановый эффект — Плановые затраты) / Плановые затраты, %).

• Плановый срок, дней.

Далее все мероприятия ранжируются по критерию плановой эффективности, рассчитываются кумулятивные затраты и кумулятивный эффект, в MS Excel строится график «Затраты — эффективность» проекта. Пример графика представлен на рис. 23.

---

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

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

На данном этапе проекта ВРГ выполняет проектирование бизнес-процесса «Как должно быть» в нотации BPMN. Полученные схемы можно разместить на странице «6. Модели „Как должно быть“» «Органайзера».

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

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

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

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

Внедрение изменений

На данном этапе проекта ВРГ используется лист «7. План внедрения» «Органайзера».

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

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

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

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

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

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

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

Анализ эффекта от оптимизации процесса

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

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

По результатам анализа ВРГ формирует график «Затраты/эффективность» по фактическим данным.

Участники ВРГ готовят итоговый отчет по результатам выполнения проекта оптимизации кросс-функционального бизнес-процесса и презентацию в PowerPoint.

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

Подведение итогов проекта

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

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

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

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

3. Контроль выполнения планов проектов оптимизации бизнес-процессов

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

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

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

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

4. Управление коммуникациями в рамках проектов и вовлечением персонала компании в изменения

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

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

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

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

• информационная рассылка;

• периодические публикации новостей и статей на корпоративном портале;

• обновление контента информационного стенда;

• подготовка и публикация коротких видеороликов на внутреннем портале;

• регулярное проведение презентаций результатов проектов;

• проведение внутренних семинаров и конференций по обмену опытом оптимизации и автоматизации бизнес-процессов;

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

• участие с докладами во внешних тематических конференциях, мастер-классах, конкурсах.

Целесообразно разработать методику (регламент) управления изменениями и далее совершенствовать его по мере накопления опыта.

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

Систему управления подачей предложений по улучшениям сотрудниками компании.

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

5. Оценка результативности и эффективности (в том числе экономической) проектов оптимизации бизнес-процессов

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

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

6. Ведение архива проектов оптимизации бизнес-процессов

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

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

4.6. Регламентация и стандартизация процессов

Подробно прочитать о разработке и внедрении в компании Системы стандартизации бизнес-процессов можно в моей книге «Бизнес по правилам: регламенты должны работать»:

Также можно прочитать статью «Фреймворк управления внутренними нормативно-методическими документами компании»:

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

Жизненный цикл ВНМД

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

Принципы документирования бизнес-процессов

При разработке ВНМД необходимо руководствоваться следующими принципами (таблица 11).

Виды внутренних административных регламентов

Виды и описание ВНМД представлены в таблице 12.