Регламент реализации проектов BPM

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

1.1. Титульный лист

Описание подраздела: Подраздел определяет состав и порядок оформления реквизитов титульного листа Регламента по ГОСТ Р 7.0.97-2025, включая гриф утверждения и уровень утверждающего должностного лица.

Как оформить титульный лист регламента в соответствии с требованиями ГОСТ Р 7.0.97-2025?

Инструкция по заполнению:

Заполните реквизиты титульного листа: логотип и полное наименование организации, гриф утверждения, полное название документа, номер версии, дату введения в действие, город и год. Утверждающим для регламента, распространяющегося на проекты изменения бизнес-процессов всей организации, как правило, выступает [Генеральный директор] или [Директор по операционной эффективности]; уровень утверждения должен быть не ниже уровня руководителей, чьи процессы затрагиваются проектами.

Пример:

[ЛОГОТИП / ПОЛНОЕ НАИМЕНОВАНИЕ ОРГАНИЗАЦИИ]

УТВЕРЖДАЮ

[Генеральный директор]

_____________ [И.О. Фамилия]

«___» ____________ 20__ г.

РЕГЛАМЕНТ РЕАЛИЗАЦИИ ПРОЕКТОВ ИЗМЕНЕНИЯ, ОПТИМИЗАЦИИ И ВНЕДРЕНИЯ НОВЫХ БИЗНЕС-ПРОЦЕССОВ

Версия 1.0

Дата введения в действие: [дата]

[Город]

[Год]

1.2. Лист согласования

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

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

Инструкция по заполнению:

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

Пример:

1.3. Оглавление

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

• 1. БАЗОВЫЕ СТАРТОВЫЕ РАЗДЕЛЫ НМД
• 1.1. Титульный лист
• 1.2. Лист согласования
• 1.3. Оглавление
• 1.4. Лист регистрации изменений
• 1.5. Область применения
• 1.6. Нормативные ссылки
• 1.7. Термины, определения и сокращения
• 2. ОБЩИЕ ПОЛОЖЕНИЯ: НАЗНАЧЕНИЕ, СТАТУС И МЕТОДОЛОГИЧЕСКАЯ БАЗА
• 2.1. Назначение, цели и задачи Регламента
• 2.2. Статус Регламента и его место в иерархии нормативно-методических документов
• 2.3. Методологическая база Регламента
• 2.4. Порядок разрешения противоречий
• 2.5. Пользователи Регламента
• 3. ОБЛАСТЬ ПРИМЕНЕНИЯ И ГРАНИЦЫ РЕГЛАМЕНТА
• 3.1. Область применения регламента
• 3.2. Типы проектов, уровни процессной архитектуры и организационный охват
• 3.3. Исключения из области действия регламента
• 3.4. Разграничение со смежными контурами проектного управления
• 3.5. Передача потребности в автоматизации в контур ИТ-проектов
• 3.6. Передача потребности в организационной трансформации
• 3.7. Инициирование проектов стандартизации и регламентации
• 4. ТЕРМИНЫ И ОБЪЕКТЫ УПРАВЛЕНИЯ
• 4.1. Правила применения терминологии регламента
• 4.2. Порядок применения терминов при расхождении с внешними стандартами
• 4.3. Объекты управления и их взаимосвязь
• 5. КЛАССИФИКАЦИЯ ПРОЕКТОВ ПРОЦЕССНЫХ ИЗМЕНЕНИЙ
• 5.1. Типы проектов процессных изменений
• 5.2. Классификация по масштабу, сложности и уровню влияния
• 5.3. Разграничение проекта изменения и текущего совершенствования (PDCA)
• 5.4. Влияние классификации на выбор трека реализации
• 6. ПРИНЦИПЫ И ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА ИЗМЕНЕНИЯ
• 6.1. Принципы реализации проектов изменений
• 6.2. Стадии жизненного цикла проекта изменения
• 6.3. Контрольные точки (gates) между стадиями
• 6.4. Предельные сроки (SLA) стадий жизненного цикла
• 6.5. Соотнесение жизненного цикла с циклом непрерывного совершенствования
• 6.6. Приостановка и досрочное прекращение проекта
• 7. РОЛИ, ОТВЕТСТВЕННОСТЬ И КОЛЛЕГИАЛЬНЫЕ ОРГАНЫ
• 7.1. Ролевая модель проекта процессного изменения
• 7.2. Функции и полномочия Процессного офиса по стадиям жизненного цикла
• 7.3. Порядок назначения на роли и требования к компетенциям
• 7.4. Матрица ответственности RACI по стадиям жизненного цикла
• 7.5. Коллегиальный орган принятия решений
• 7.6. Эскалация проблем и конфликтов ответственности
• 8. ИНИЦИИРОВАНИЕ И УПРАВЛЕНИЕ ПОРТФЕЛЕМ ИНИЦИАТИВ
• 8.1. Источники и триггеры инициатив
• 8.2. Право инициирования и роль Процессного офиса как инициатора
• 8.3. Состав обоснования инициативы
• 8.4. Регистрация, маршрутизация и первичная экспертиза. Единый реестр инициатив и проектов
• 8.5. Оценка целесообразности и приоритизация инициатив в портфеле
• 8.6. Решение о запуске проекта и работа с отклонёнными, отложенными, дублирующими и объединяемыми инициативами
• 9. АНАЛИЗ ТЕКУЩЕГО СОСТОЯНИЯ ПРОЦЕССА
• 9.1. Методы анализа текущего состояния «as-is»
• 9.2. Требования к модели «как есть» и фиксации выявленных проблем
• 9.3. Показатели процесса и фиксация базовых значений
• 9.4. Анализ влияния изменения на смежные процессы и системы управления
• 9.5. Идентификация рисков реализации изменения
• 10. ПРОЕКТИРОВАНИЕ ЦЕЛЕВОЙ МОДЕЛИ ПРОЦЕССА
• 10.1. Выбор нотации моделирования
• 10.2. Требования к целевой модели TO-BE
• 10.3. Сопоставимость моделей AS-IS и TO-BE
• 10.4. Оценка ожидаемого эффекта изменения
• 10.5. План перехода к целевому процессу
• 11. СОГЛАСОВАНИЕ И УТВЕРЖДЕНИЕ ПРОЕКТНЫХ РЕШЕНИЙ
• 11.1. Состав пакета документов и требования к оформлению
• 11.2. Контур обязательного согласования и согласительные сессии
• 11.3. Предельные сроки рассмотрения и действия при их нарушении
• 11.4. Урегулирование разногласий согласующих сторон
• 11.5. Утверждение проектных решений и придание целевой модели обязательного статуса
• 12. ВНЕДРЕНИЕ ИЗМЕНЕНИЙ И КОММУНИКАЦИИ
• 12.1. План внедрения изменения и подтверждение ресурсов
• 12.2. Выбор стратегии внедрения
• 12.3. Коммуникации, обучение и поддержка участников процесса
• 12.4. Актуализация нормативных документов и синхронное вступление в силу
• 12.5. Условия и процедура отката (rollback)
• 12.6. Период стабилизации и признание изменения внедрённым
• 13. МОНИТОРИНГ, ОЦЕНКА ЭФФЕКТА И ЗАКРЫТИЕ ПРОЕКТА
• 13.1. Мониторинг показателей после внедрения
• 13.2. Plan-Fact анализ и отчёт об оценке эффекта
• 13.3. Действия при недостижении планового эффекта
• 13.4. Передача процесса в операционное управление и роспуск рабочей группы
• 13.5. Основания и процедуры закрытия проекта
• 13.6. Извлечённые уроки (lessons learned)
• 14. ДОКУМЕНТИРОВАНИЕ, ВЕРСИОННОСТЬ И УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ
• 14.1. Состав документов и артефактов по стадиям жизненного цикла
• 14.2. Хранение, актуализация и доступ к материалам проекта
• 14.3. Версионность проектных документов и прослеживаемость решений
• 14.4. Публикация моделей и актуализация архитектуры процессов по итогам внедрения
• 14.5. Внесение изменений в утверждённую целевую модель и план внедрения
• 14.6. Управление зависимостями и конфликтами параллельных проектов
• 15. КОНТРОЛЬ СОБЛЮДЕНИЯ РЕГЛАМЕНТА И ЗАКЛЮЧИТЕЛЬНЫЕ ПОЛОЖЕНИЯ
• 15.1. Контроль соблюдения требований Регламента
• 15.2. Отчётность процессного офиса о состоянии портфеля проектов изменений
• 15.3. Ответственность за нарушение требований Регламента
• 15.4. Вступление Регламента в силу и доведение требований до пользователей
• 15.5. Срок действия, пересмотр и внесение изменений
• 15.6. Приложения: унифицированные формы и шаблоны
• ПРИЛОЖЕНИЯ
• Приложение А. Глоссарий терминов и сокращений
• Приложение Б. Паспорт проекта изменения
• Приложение В. Карта жизненного цикла проекта изменения
• Приложение Г. Классификация проектов процессных изменений
• Приложение Д. Матрица RACI проекта процессного изменения
• Приложение Е. Единый реестр инициатив и проектов
• Приложение Ж. Аналитический комплект стадии анализа (AS-IS)
• Форма Ж.1. Отчёт об анализе текущего состояния процесса (AS-IS)
• Форма Ж.2. Реестр проблем, потерь и узких мест процесса AS-IS
• Форма Ж.3. Фиксация базовых значений показателей процесса
• Приложение З. Комплект целевой модели (TO-BE)
• Форма З.1. Паспорт целевой модели (TO-BE)
• Форма З.2. Карта соответствия операций AS-IS / TO-BE
• Форма З.3. План перехода к целевой модели (roadmap)
• Приложение И. Комплект согласования
• Форма И.1. Лист согласования пакета проектных документов
• Форма И.2. Протокол согласительной сессии
• Форма И.3. Протокол разногласий
• Приложение К. Комплект внедрения
• Форма К.1. План внедрения изменения
• Форма К.2. План коммуникаций и обучения
• Форма К.3. Чек-лист готовности к запуску
• Форма К.4. Акт о завершении внедрения
• Приложение Л. Комплект мониторинга и закрытия
• Форма Л.1. План мониторинга показателей процесса после внедрения
• Форма Л.2. Акт передачи процесса в операционное управление
• Форма Л.3. Итоговый отчёт по проекту
• Форма Л.4. Реестр извлечённых уроков
• Приложение М. Реестр рисков проекта процессного изменения
• Приложение Н. Комплект управления конфигурацией проекта процессного изменения
• Н.1. Реестр документов и артефактов проекта по стадиям жизненного цикла
• Н.2. Форма запроса на изменение плана внедрения
• Н.3. Матрица зависимостей и пересечений параллельных проектов
• Приложение О. Отчёт процессного офиса о состоянии портфеля проектов изменений
• Приложение П. Смежные контуры управления изменениями
• П.1. Матрица разграничения контуров управления проектами изменений
• П.2. Лист передачи потребности в организационной трансформации
• П.3. Карточка эскалации
• Приложение Р. Схемы: место Регламента в системе НМД и взаимосвязь объектов управления
• Р.1. Место Регламента в иерархии НМД организации
• Р.2. Схема взаимосвязи объектов управления

1.4. Лист регистрации изменений

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

Как фиксируется история версий регламента и на каком основании вносятся изменения?

Инструкция по заполнению:

Заполните первую строку таблицы данными о первичном утверждении документа. Все последующие изменения вносите отдельными строками с указанием затронутых разделов и основания (протокол Процессного комитета, приказ, результаты планового пересмотра). Установите периодичность планового пересмотра регламента: 1 раз в год; внеплановый пересмотр проводится при изменении смежных НМД ([Методика оценки экономической целесообразности], [Регламент управления процессной архитектурой]) или организационной структуры.

Пример:

1.5. Область применения

Описание подраздела: Подраздел устанавливает организационный и функциональный охват Регламента (проекты изменения процессов уровней L0–L4), категории работников, для которых его требования обязательны, и перечень исключений со ссылками на регулирующие смежные НМД.

На какие проекты, подразделения и категории работников распространяется регламент и что явно исключено из его действия?

Инструкция по заполнению:

Определите четыре контура: организационный охват (головная организация / группа компаний / филиалы / ДЗО), функциональный охват (типы проектов процессных изменений и уровни процессов L0–L4), целевую аудиторию (3–5 категорий ролей) и исключения. Сформулируйте 4–6 исключений с обоснованием и ссылкой на документ, который регулирует исключённую область; это защитит регламент от конфликтов со смежными НМД.

Пример:

1.5.1. Настоящий Регламент устанавливает единый порядок реализации проектов изменения, оптимизации и внедрения новых бизнес-процессов в [Название организации], включая [филиалы и ДЗО: указать охват].

1.5.2. Регламент распространяется на проекты, объектом которых являются бизнес-процессы уровней L0–L4, независимо от инициировавшего подразделения. Для изменений процессов верхних уровней (L0–L1), затрагивающих процессную архитектуру, решения на гейтах принимает Процессный комитет, а изменения архитектуры проводятся через Change Request по [Регламент управления процессной архитектурой].

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

1.5.4. Из области применения Регламента исключаются:

• проекты автоматизации и роботизации бизнес-процессов реализуются по [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33]; настоящий Регламент действует в части процессной составляющей изменения, создание решения автоматизации с момента передачи заявки регулируется указанным регламентом;
• текущие корректировки моделей процессов без изменения логики их выполнения вносятся через процедуру Change Request по [Регламент управления процессной архитектурой];
• инвестиционные и капитальные проекты, не связанные с изменением бизнес-процессов, реализуются по [внутренний документ по управлению инвестиционными проектами];
• организационно-штатные изменения, не затрагивающие модели бизнес-процессов, реализуются по [внутренний документ по организационному развитию];
• приоритизация портфеля процессов и расчёт экономической целесообразности как самостоятельные процедуры выполняются по [Методика приоритизации бизнес-процессов] и [Методика оценки экономической целесообразности] соответственно; настоящий Регламент лишь определяет стадии, на которых их результаты обязательны.

1.6. Нормативные ссылки

Описание подраздела: Подраздел содержит перечень внешних стандартов (ГОСТ, ISO, BPM CBOK, BPMN) и внутренних НМД, на которые опирается Регламент, а также правило применения актуальных версий и приоритета документов при противоречиях.

На какие внешние стандарты и внутренние документы опирается регламент?

Инструкция по заполнению:

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

Пример:

1.6.1. Внешние нормативные документы и стандарты (перечень примерный, например):

• ГОСТ Р 7.0.97-2025 «Организационно-распорядительная документация. Требования к оформлению документов»;
• ГОСТ Р ИСО 9001-2015 (ISO 9001:2015) «Системы менеджмента качества. Требования»: в части улучшения процессов;
• ГОСТ Р ИСО 9004-2019 «Менеджмент качества. Качество организации. Руководство по достижению устойчивого успеха организации»;
• ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»;
• ISO 21502:2020 «Project, programme and portfolio management. Guidance on project management»;
• ISO 31000:2018 «Risk management. Guidelines»: в части управления рисками проектов изменений;
• BPM CBOK 4.0 (Guide to the Business Process Management Common Body of Knowledge): методологическая основа управления изменениями процессов;
• OMG BPMN 2.0.2: нотация моделирования процессов AS-IS/TO-BE для кандидатов на автоматизацию и публикуемых моделей.

1.6.2. Внутренние нормативные документы:

• [Политика процессного управления], версия [N], утверждена [дата];
• [Положение о процессном офисе], версия [N], утверждено [дата];
• [Регламент управления процессной архитектурой], версия [N], утверждён [дата];
• [Методика приоритизации бизнес-процессов], версия [N], утверждена [дата];
• [Методика оценки экономической целесообразности], версия [N], утверждена [дата];
• [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33], версия [N], утверждён [дата].

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

1.7. Термины, определения и сокращения

Описание подраздела: Подраздел определяет сокращения и ключевые термины Регламента (AS-IS/TO-BE, гейт, бизнес-кейс, владелец выгод и др.) с указанием источников определений в смежных НМД.

Какие термины и сокращения необходимы читателю для однозначного понимания регламента?

Инструкция по заполнению:

Заполните таблицу сокращений и таблицу терминов. Используйте приведённые ниже канонические формулировки без изменений, поскольку они согласованы со смежными НМД; термины, уже определённые в глоссариях [Положение о процессном офисе] и [Методика оценки экономической целесообразности], не переопределяйте, а ссылайтесь на источник. Дополните таблицу 5–10 терминами, специфичными для содержательных разделов вашей редакции регламента, соблюдая алфавитный порядок (сначала латиница, затем кириллица).

Пример:

1.8. Перечень вопросов документа

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

Как быстро найти раздел документа, отвечающий на конкретный вопрос?

Инструкция по заполнению:

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

Пример:

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

2.1. Назначение, цели и задачи Регламента

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

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

Инструкция по заполнению:

Опишите 3–5 системных проблем текущей практики реализации изменений бизнес-процессов в [Название организации] (например: отсутствие единого жизненного цикла инициатив, потеря инициатив после приоритизации, неподтверждённость эффектов). Сформулируйте одну главную цель Регламента и 4–6 задач, обеспечивающих её достижение, в форме нумерованного списка. Завершите перечнем из 3–5 целевых результатов применения с измеримыми индикаторами (например «доля проектов изменений, завершённых с подтверждённым эффектом, составляет не менее [N]%»).

Пример:

Регламент разработан для устранения следующих проблем текущей практики [Название организации]:

1. инициативы по изменению бизнес-процессов, включённые в Реестр приоритетов процессов, не переводятся в проекты по единой процедуре: до [40]% приоритизированных процессов не получают дальнейшего движения;

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

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

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

Для достижения цели Регламент решает следующие задачи:

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

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

3. обеспечивает преемственность: вход из процедур инициации и приоритизации ([Положение о процессном офисе], [Методика приоритизации бизнес-процессов]) и выход в процедуры подтверждения эффекта ([Методика оценки экономической целесообразности]);

4. устанавливает требования к проектным документам и порядку их согласования.

Целевые результаты применения Регламента: доля инициатив категорий приоритета A–B (по [Методика приоритизации бизнес-процессов]), переведённых в проекты в течение [30] календарных дней, составляет не менее [90]%; доля проектов изменений, завершённых с подтверждённым эффектом, составляет не менее [70]%; срок прохождения стадии анализа AS-IS не превышает [N] рабочих дней.

2.2. Статус Регламента и его место в иерархии нормативно-методических документов

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

Какое место занимает Регламент в иерархии нормативно-методических документов организации и с какими внутренними документами он связан?

Инструкция по заполнению:

Укажите уровень Регламента в иерархии НМД организации (Устав → Стратегия → Политики → Положения → Методологии → Регламенты) и документ верхнего уровня, во исполнение которого он разработан. Заполните таблицу из 5–7 связанных внутренних НМД с указанием характера связи (вышестоящий / смежный / детализирующий) и предмета разграничения: что регулирует смежный документ и что остаётся в предмете настоящего Регламента. Разграничение должно исключать дублирование процедур (в частности, инициации, приоритизации и оценки эффекта).

Пример:

Регламент относится к уровню «Регламенты» иерархии НМД [Название организации], разработан во исполнение [Политики процессного управления] и детализирует порядок реализации проектов изменений бизнес-процессов в рамках системы управления бизнес-процессами (СУБП). Регламент не является общим регламентом проектного управления организации и не распространяется на проекты, не связанные с изменением бизнес-процессов.

2.3. Методологическая база Регламента

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

Какие внешние стандарты и методологии формируют методологическую базу Регламента и по какому принципу отбираются реально применимые к нему источники?

Инструкция по заполнению:

Приведите таблицу из 4–6 внешних стандартов и методологий, применённых при разработке Регламента, с указанием конкретной области применения каждого источника в тексте документа (перечень примерный: не копируйте типовой список, включайте только источники, положения которых реально использованы). Сформулируйте 2–3 критерия отбора источников (например: применимость к жизненному циклу изменений процессов, совместимость с уже принятыми в организации НМД, наличие русскоязычной нормативной основы). Укажите, что внешние источники применяются в части, не противоречащей законодательству РФ и внутренним НМД.

Перечень примерный; состав методологической базы должен отражать фактически использованные источники:

Отбор внешних источников осуществляется процессным офисом по следующим критериям: (1) источник регулирует предмет Регламента, то есть жизненный цикл изменений бизнес-процессов, а не смежные области; (2) положения источника совместимы с действующими внутренними НМД организации; (3) применение источника не создаёт избыточных требований для проектов классов [C–D] (по [Методика оценки экономической целесообразности]). Внешние стандарты применяются в части, не противоречащей законодательству РФ и внутренним НМД [Название организации].

2.4. Порядок разрешения противоречий

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

Как разрешаются противоречия между требованиями Регламента, другими внутренними документами и внешними методическими источниками?

Инструкция по заполнению:

Установите иерархию приоритетов при коллизиях (законодательство РФ → Устав → Политики → Положения → Методологии/Методики → Регламенты → внешние методические источники) и правило приоритета специальной нормы над общей для документов одного уровня. Опишите процедуру разрешения противоречия в 3–4 шага: кто фиксирует коллизию, кто готовит заключение (процессный офис), какой коллегиальный орган принимает решение (действующий Процессный комитет; новый орган не создаётся) и в какой срок инициируется изменение документа. Укажите порядок действий работника до разрешения коллизии.

Пример:

При выявлении противоречий применяется следующий порядок приоритетов: законодательство РФ и обязательные требования; Устав и решения органов управления [Название организации]; [Политика процессного управления]; положения и методики ([Положение о процессном офисе], [Методика оценки экономической целесообразности], [Методика приоритизации бизнес-процессов]); настоящий Регламент; внешние методические источники (BPM CBOK, BABOK и иные), носящие рекомендательный характер. При противоречии документов одного уровня приоритет имеет документ, специально регулирующий спорный предмет.

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

2.5. Пользователи Регламента

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

Какие подразделения, коллегиальные органы и категории работников являются пользователями Регламента?

Инструкция по заполнению:

Заполните таблицу пользователей Регламента из 6–8 строк по трём группам: структурные подразделения, коллегиальные органы, категории работников (роли). Для каждого пользователя укажите характер применения Регламента (обязательное исполнение / принятие решений / ознакомление) и разделы, обязательные к применению. Используйте действующие коллегиальные органы организации: Процессный, Архитектурный и Инвестиционный комитеты; новые органы настоящим Регламентом не вводятся.

Пример:

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

3.1. Область применения регламента

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

Какова область применения и каковы границы действия настоящего регламента?

Инструкция по заполнению:

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

Пример:

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

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

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

3.2. Типы проектов, уровни процессной архитектуры и организационный охват

Описание подраздела: Подраздел определяет типы проектов процессных изменений (оптимизация, реинжиниринг, внедрение нового процесса, организационное изменение процессной модели) с привязкой к уровням архитектуры L0–L4, организационному охвату и классам проектов A–D, а также статус инициатив Quick Win.

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

Инструкция по заполнению:

Заполните таблицу типов проектов процессных изменений (4–6 типов: например, оптимизация действующего процесса, реинжиниринг, внедрение процесса «с нуля», организационное изменение процессной модели; Quick Win не является отдельным типом, а представляет собой признак инициативы по [Методика приоритизации бизнес-процессов], фиксируемый дополнительно к типу, см. п. 5.1) с указанием для каждого типа охватываемых уровней процессной архитектуры (L0–L4) и организационных единиц. Приведите маппинг типов проектов на треки реализации и на классы проектов A–D по [Методика оценки экономической целесообразности]; трек автоматизации укажите со ссылкой на [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33], п. 1.2, не дублируя его содержание.

Пример:

Примечание: инициативы Quick Win (категория по [Методика приоритизации бизнес-процессов]) не образуют отдельного типа проекта: признак Quick Win фиксируется дополнительно к типу (п. 5.1), по умолчанию соответствует классу D по [Методика оценки экономической целесообразности] и упрощённому треку (п. 5.4); типовой охват составляет L3–L4, одно подразделение / один участок процесса.

3.3. Исключения из области действия регламента

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

Какие виды инициатив и работ исключаются из области действия регламента?

Инструкция по заполнению:

Перечислите в таблице 5–7 видов инициатив и работ, не подпадающих под действие регламента, для каждого укажите обоснование исключения и регулирующий НМД или контур управления, в который такая инициатива направляется. Не включайте в перечень пограничные случаи, требующие разграничения по критериям: они рассматриваются в подразделе 3.4.

Пример:

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

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

Как разграничиваются проекты процессных изменений с общекорпоративным проектным управлением и проектами автоматизации/роботизации?

Инструкция по заполнению:

Определите 4–6 критериев разграничения (объект управления, доминирующий тип результата, доля ИТ-составляющей в объёме работ, инициирующий орган, применяемый жизненный цикл) и сведите их в таблицу по трём контурам: процессные изменения (настоящий регламент), общекорпоративное проектное управление, автоматизация/роботизация. Опишите правило для смешанных проектов: какой контур является ведущим и как принимается решение об отнесении (например, решением Процессного комитета по представлению процессного офиса); зафиксируйте, что проект относится ровно к одному ведущему контуру, а взаимодействие с остальными оформляется передачей потребности (подразделы 3.5, 3.6).

Пример:

При наличии признаков нескольких контуров решение об отнесении проекта к ведущему контуру принимается Процессным комитетом по представлению процессного офиса в срок не более [5] рабочих дней с даты регистрации инициативы. Проект относится ровно к одному ведущему контуру; потребности, выходящие за его рамки, оформляются передачей в смежный контур в порядке подразделов 3.5 и 3.6 настоящего регламента. Для смешанных проектов с долей ИТ-работ более [30]% и не более [50]% ведущий контур определяется по доминирующему типу результата решением Процессного комитета с обязательным заключением [Комитета по автоматизации] (контур [№33]). Разграничение зон ответственности с корпоративным проектным офисом установлено [Положение о процессном офисе, п. 9.2.7].

3.5. Передача потребности в автоматизации в контур ИТ-проектов

Описание подраздела: Подраздел устанавливает процедуру оформления и передачи потребности в автоматизации в контур ИТ-проектов (заявка по регламенту №33 с приложением моделей AS-IS/TO-BE и базовых показателей) и принцип сохранения ответственности за процессную часть изменения за руководителем процессного проекта и владельцем процесса.

Как оформляется и передаётся в контур ИТ-проектов потребность в автоматизации, выявленная в ходе процессного проекта, и как при этом сохраняется ответственность за процессную часть изменения?

Инструкция по заполнению:

Опишите процедуру передачи из 4–6 шагов: фиксация потребности в проектной документации, подготовка заявки на автоматизацию по форме и в порядке [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33], п. 5.2 (с обязательным приложением моделей AS-IS/TO-BE в нотации BPMN 2.0.2 и базовых значений показателей процесса), регистрация заявки Процессным офисом ([№33], п. 5.2), решение Комитета по автоматизации на этапе приоритизации заявок. Отдельно зафиксируйте принцип сохранения ответственности: за процессную часть изменения (модель TO-BE, регламентация, показатели, эффект процессной составляющей) отвечает руководитель процессного проекта и владелец процесса; новых форм заявки не вводите, используется форма по [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33]. Формат: нумерованный список шагов с указанием сроков и ответственных.

Пример:

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

2. Заявка на автоматизацию оформляется по форме и в порядке, установленным [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33], п. 5.2. К заявке прилагаются: модель AS-IS и модель TO-BE автоматизируемого участка процесса в нотации BPMN 2.0.2, базовые значения показателей процесса, зафиксированные в соответствии с [Методика оценки экономической целесообразности], п. 3.1, реестр проблем, потерь и узких мест автоматизируемого участка (форма Ж.2), а при наличии также результаты Impact Analysis по форме [Регламент управления процессной архитектурой, Прил. В].

3. Заявка согласовывается владельцем процесса и подаётся в порядке, установленном [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33], п. 5.2 (регистрацию и первичную экспертизу выполняет Процессный офис; Комитет по автоматизации принимает решение на этапе приоритизации заявок), в срок не более [10] рабочих дней с даты фиксации потребности, но не ранее согласования модели TO-BE автоматизируемого участка.

4. Решение об открытии ИТ-проекта принимается в контуре [Регламент реализации проектов по автоматизации и роботизации бизнес-процессов, №33]; отказ или отложенное решение не приостанавливает процессный проект: в модель TO-BE включается неавтоматизированный вариант выполнения операций.

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

3.6. Передача потребности в организационной трансформации

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

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

Инструкция по заполнению:

Опишите порядок оформления листа передачи потребности в организационной трансформации (состав сведений: описание потребности, затрагиваемые подразделения и роли, связь с моделью TO-BE, ожидаемый вклад в эффект) и маршрут его согласования: владелец процесса → директор по персоналу / подразделение организационного развития → коллегиальный орган. Разграничение ответственности представьте таблицей на 4–5 строк по составляющим изменения; зафиксируйте правило: перераспределение функций между ролями внутри процесса относится к предмету настоящего регламента, а изменение организационной структуры, штатной численности и системы мотивации относится к предмету контура организационных изменений.

Пример:

Лист передачи потребности в организационной трансформации (Приложение [X]) оформляется руководителем процессного проекта, согласовывается владельцем процесса и направляется в [подразделение организационного развития] в срок не более [10] рабочих дней с даты фиксации потребности. За процессную часть изменения ответственность сохраняется в контуре настоящего регламента; отказ от организационной трансформации должен учитываться при уточнении модели TO-BE и оценке достижимости эффекта.

3.7. Инициирование проектов стандартизации и регламентации

Описание подраздела: Подраздел устанавливает сценарии инициирования проектов стандартизации и регламентации на основе описанных процессов и критерии их разграничения с проектами изменений (изменение логики процесса, обязательность стадий AS-IS/TO-BE, наличие подтверждаемого эффекта).

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

Инструкция по заполнению:

Опишите 2–3 сценария инициирования: разработка/актуализация НМД как обязательный результат внутри процессного проекта (входит в его состав работ) и разработка НМД на основе ранее описанных процессов как отдельный проект стандартизации (передаётся в контур управления НМД). Приведите 3–4 критерия разграничения (меняется ли логика процесса или только фиксируется существующая; наличие измеримого эффекта, требующего подтверждения по [Методика оценки экономической целесообразности]; необходимость стадий анализа AS-IS и проектирования TO-BE) в формате таблицы или списка; укажите, что основанием для отдельного проекта стандартизации служит утверждённая модель процесса из репозитория процессной архитектуры.

Пример:

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

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

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

4.1. Правила применения терминологии регламента

Описание подраздела: Подраздел закрепляет правила применения терминологии Регламента: приоритет определений из действующих НМД организации, условия введения собственных терминов и правило замены термина «baseline» формулировкой «базовые значения показателей процесса». Сам терминологический аппарат (термины и сокращения) приведён в подразделе 1.7 и здесь не дублируется.

Какие правила применения терминологии (приоритет глоссариев действующих НМД, условия введения собственных терминов, замена термина «baseline») необходимо закрепить в регламенте?

Инструкция по заполнению:

Сформулируйте 3–4 правила нумерованным списком. Определения должны заимствоваться из действующих НМД организации в первую очередь: термины «владелец процесса», «AS-IS/TO-BE», «паспорт инициативы», «бизнес-кейс», «владелец выгод», «эффект внедрения» применяются по [Методике оценки экономической целесообразности, п. 1.4], а термины «процессный офис» и «заявка на оптимизацию» по [Положению о процессном офисе, Приложение 17]; собственные определения допускаются только для терминов, отсутствующих в глоссариях смежных НМД (например, «проект изменения процесса», «трек реализации»), и не могут изменять определения смежных НМД. Вместо термина «baseline» в значении исходных значений показателей должна использоваться формулировка «базовые значения показателей процесса» (фиксация выполняется по [Методике оценки экономической целесообразности, п. 3.1]), поскольку в [Регламенте управления процессной архитектурой] термин «baseline» закреплён за версией архитектуры. Перечень терминов и сокращений не дублируйте, дайте ссылку на подраздел 1.7; порядок разрешения коллизий с внешними стандартами установлен п. 4.2.

Пример:

1. Термины «владелец процесса», «модель AS-IS», «модель TO-BE», «паспорт инициативы», «бизнес-кейс», «владелец выгод», «эффект внедрения» применяются в значениях, установленных [Методикой оценки экономической целесообразности, п. 1.4]; термины «процессный офис» и «заявка на оптимизацию» применяются в значениях, установленных [Положением о процессном офисе, Приложение 17]; полный перечень терминов и сокращений приведён в подразделе 1.7.

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

3. Термин «baseline» в значении исходных значений показателей не применяется: используется формулировка «базовые значения показателей процесса» ([Методика оценки экономической целесообразности, п. 3.1]), поскольку в [Регламенте управления процессной архитектурой] термин «baseline» закреплён за утверждённой версией архитектуры.

4. Порядок применения терминов при расхождении внутренних определений с внешними стандартами (ГОСТ Р ИСО 9000, BPM CBOK 4.0, BABOK v3.0) и разрешения терминологических коллизий установлен п. 4.2 настоящего Регламента.

4.2. Порядок применения терминов при расхождении с внешними стандартами

Описание подраздела: Подраздел устанавливает иерархию источников терминологии (глоссарии внутренних НМД, ГОСТ Р ИСО 9000, BPM CBOK 4.0 и BABOK v3.0) и правила разрешения коллизий при расхождении определений, включая коллизии терминов «baseline», «gap analysis» и категорий A–E. Закрепляет ответственность процессного офиса за поддержание единого глоссария и порядок внесения в него изменений.

Каков порядок применения терминов процессного управления при расхождении внутренних определений с внешними стандартами?

Инструкция по заполнению:

Установите иерархию источников терминологии (3–4 уровня приоритета: глоссарии внутренних НМД → ГОСТ Р ИСО 9000 → BPM CBOK 4.0 / BABOK v3.0 → иные внешние источники) и правило разрешения коллизий нумерованным списком из 4–5 пунктов. Отдельной таблицей на 3–4 строки зафиксируйте известные терминологические коллизии между НМД организации и внешними стандартами (формат: «Термин / Значение в настоящем Регламенте / Конфликтующее значение / Правило применения»), обязательно включив коллизии «baseline» и «gap analysis». Укажите, кто отвечает за поддержание единого глоссария и порядок внесения в него изменений (2–3 предложения).

Пример:

При расхождении определений должен применяться следующий порядок приоритета источников: (1) глоссарии вышестоящих и смежных НМД: [Положение о процессном офисе, Приложение 17] и [Методика оценки экономической целесообразности, п. 1.4]; (2) термины, закреплённые в разделе 4 настоящего Регламента, для понятий, отсутствующих в глоссариях смежных НМД (собственные определения настоящего Регламента не могут изменять определения смежных НМД, см. п. 4.1); (3) ГОСТ Р ИСО 9000; (4) BPM CBOK 4.0 и BABOK v3.0. Использование термина во внешнем значении, отличном от закреплённого, допускается только с явной оговоркой в тексте документа. Ответственность за поддержание единого глоссария несёт процессный офис; изменения глоссария оформляются в порядке актуализации настоящего Регламента.

4.3. Объекты управления и их взаимосвязь

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

Какие объекты управления (инициатива, проект изменения, бизнес-процесс, целевая модель, эффект) выделяются в регламенте и как они взаимосвязаны?

Инструкция по заполнению:

Выделите 5–7 объектов управления таблицей «Объект управления / Назначение / Ключевые атрибуты / Ответственный за ведение / Связанные объекты», указав для каждого объекта учётный документ (паспорт инициативы, устав проекта, карточка эффекта и т.п.). Опишите логику взаимосвязи объектов 2–3 предложениями по цепочке жизненного цикла: инициатива (вход из заявки на оптимизацию и РПП) → проект изменения → модели AS-IS/TO-BE бизнес-процесса → эффект внедрения; кардинальность связей зафиксируйте явно: инициатива по итогам рассмотрения отклоняется, откладывается, объединяется с другими либо преобразуется в проект; проект может иметь одну или несколько инициатив-оснований (п. 8.6); одна инициатива не порождает более одного активного проекта; один проект охватывает один или несколько процессов. Приведите схему взаимосвязи объектов в нотации, принятой в организации, и вынесите её в приложение.

Пример:

Объекты управления образуют сквозную цепочку жизненного цикла изменения: инициатива, поступившая по заявке на оптимизацию или из реестра приоритетов процессов, после положительного решения преобразуется в проект изменения либо объединяется с другими инициативами в один результирующий проект (п. 8.6); проект может иметь одну или несколько инициатив-оснований, при этом одна инициатива не порождает более одного активного проекта; проект охватывает один или несколько бизнес-процессов, для каждого из которых формируются модели AS-IS и TO-BE и фиксируются базовые значения показателей; по итогам внедрения для проекта формируется карточка эффекта, мониторинг которого выполняется по [Методике оценки экономической целесообразности]. Идентификаторы связанных объектов должны указываться во всех учётных документах для обеспечения сквозной прослеживаемости.

Описание раздела: Раздел устанавливает систему классификации проектов процессных изменений, применяемую для выбора глубины процедур Регламента: типы проектов, шкалу масштаба и критерии разграничения проекта изменения и текущего совершенствования (PDCA). Определяет порядок назначения трека реализации (упрощённого, стандартного, расширенного) по матрице «тип × масштаб» с уточнением по классу проекта и состав обязательных процедур для каждого трека. Классификация согласована с классами проектов A–D и категориями приоритета A–E смежных методик и не переопределяет их.

Опишите в настоящем разделе систему классификации проектов процессных изменений, применяемую для выбора глубины процедур настоящего Регламента. Классификация должна быть согласована с классами проектов A–D по [«Методика оценки экономической целесообразности», №34] и категориями приоритета A–E по [«Методика приоритизации бизнес-процессов», №6] и не должна их дублировать или переопределять.

5.1. Типы проектов процессных изменений

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

Какие типы проектов изменений выделяются в организации (оптимизация, реинжиниринг, внедрение процесса «с нуля», организационное изменение) и каковы критерии отнесения инициативы к каждому типу?

Инструкция по заполнению:

приведите закрытый перечень 4–6 типов проектов процессных изменений; для каждого типа укажите определение, 2–3 проверяемых критерия отнесения и типовой результат. Оформите таблицей «Тип проекта / Определение / Критерии отнесения / Типовой результат»; тип присваивается Процессным офисом при регистрации инициативы, поступившей в порядке, установленном [«Положение о процессном офисе», №2, п. 9.3]. Оговорите, что тип проекта присваивается независимо от класса проекта A–D по [№34] и категории приоритета A–E по [№6], и определите правило выбора типа для смешанных инициатив (по преобладающему объёму изменений).

Пример:

Примечание: инициативы категории Quick Win (по [№6]) не образуют отдельного типа проекта: признак Quick Win фиксируется дополнительно к типу и учитывается при выборе трека реализации (п. 5.4).

5.2. Классификация по масштабу, сложности и уровню влияния

Описание подраздела: Подраздел задаёт трёхуровневую шкалу масштаба проекта (локальный, кросс-функциональный, сквозной) с измеримыми критериями разграничения: число подразделений, уровень процессов L0–L4, число ролей, охват ИТ-систем и влияние на внешнего клиента. Масштаб определяется по наивысшему из достигнутых уровней хотя бы по одному критерию и применяется совместно с классом проекта.

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

Инструкция по заполнению:

задайте шкалу из трёх уровней масштаба (локальный, кросс-функциональный, сквозной) и 4–6 измеримых критериев разграничения: число затрагиваемых подразделений, уровень затрагиваемых процессов L0–L4, число затрагиваемых ролей, охват ИТ-систем, влияние на внешнего клиента. Оформите таблицей «Критерий / Локальный / Кросс-функциональный / Сквозной» и укажите правило: масштаб определяется по наивысшему из достигнутых уровней хотя бы по одному критерию. Оговорите, что масштаб применяется совместно с классом проекта A–D по [№34], а не вместо него, и что для проектов с затрагиваемыми ИТ-системами взаимодействие с контуром автоматизации осуществляется по [«Регламент реализации проектов по автоматизации и роботизации бизнес-процессов», №33].

Пример:

5.3. Разграничение проекта изменения и текущего совершенствования (PDCA)

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

По каким критериям инициатива признаётся проектом изменения, а не текущим совершенствованием в рамках операционной деятельности (цикл PDCA)?

Инструкция по заполнению:

сформулируйте 5–7 пороговых критериев признания инициативы проектом (длительность, трудоёмкость, число подразделений, необходимость изменения НМД и публикуемых моделей процессов, необходимость оценки экономического эффекта по [№34], изменение базовых значений показателей процесса). Задайте решающее правило (например, инициатива признаётся проектом при выполнении [2] и более критериев) и укажите, что решение фиксирует Процессный офис при регистрации заявки, поданной по [№2, п. 9.3, Прил. 15], без введения дополнительных форм. Оформите таблицей-чек-листом.

Пример:

Пример решающего правила: инициатива признаётся проектом процессного изменения при выполнении не менее двух критериев из таблицы. В остальных случаях улучшение реализуется владельцем процесса в рамках цикла PDCA (операционная деятельность) без применения настоящего Регламента; при этом изменения моделей процессов выполняются в порядке [№5], а результат учитывается при очередном цикле приоритизации по [№6].

5.4. Влияние классификации на выбор трека реализации

Описание подраздела: Подраздел определяет три трека реализации (упрощённый, стандартный, расширенный) и алгоритм их назначения: базовый трек определяется по матрице «тип проекта × масштаб», итоговый уточняется по классу проекта A–D. Фиксирует отличия треков по составу гейтов, обязательных документов и согласующих органов, а также правила повышения трека и применения упрощённого трека для инициатив Quick Win.

Как классификация проекта определяет глубину применения процедур регламента и выбор упрощённого, стандартного или расширенного трека реализации?

Инструкция по заполнению:

определите три трека реализации (упрощённый, стандартный, расширенный) и единый алгоритм назначения трека: базовый трек определяется по матрице «Тип проекта × Масштаб (п. 5.2)», итоговый трек уточняется по классу проекта A–D по [№34]; матрица и правило уточнения едины с Приложением Г. Для каждого трека укажите в отдельной таблице (3–5 строк) глубину применения процедур: состав обязательных стадий и гейтов (в синхронизации с Gate 0–4 по [№34]), перечень обязательных и исключаемых проектных документов, согласующий орган. Зафиксируйте, что назначенный трек может быть повышен решением Процессного комитета (по [№2, п. 9.5]), но не может быть понижен относительно расчётного, а для инициатив Quick Win (по [№6]) по умолчанию применяется упрощённый трек.

Матрица назначения базового трека (единая с Приложением Г):

Правило уточнения по классу проекта (по [№34]): для класса A назначается расширенный трек независимо от значения матрицы; для класса B трек не может быть ниже стандартного; для классов C–D применяется значение матрицы. Признак Quick Win (по [№6]) по умолчанию даёт упрощённый трек, если по классу проекта не требуется более высокий.

Отличия треков (пример):

Упрощённый трек сокращает форму, но не отменяет обязательные результаты: фиксация AS-IS, целевое состояние, базовые и целевые значения показателей, план и акт внедрения, Plan-Fact анализ выполняются в облегчённом формате; стадии 2–3 и 6–7 жизненного цикла объединяются со смежными (пп. 6.2, 6.4).

Описание раздела: Раздел закрепляет принципы реализации проектов процессных изменений и единый жизненный цикл проекта (от регистрации инициативы до подтверждения эффекта и закрытия). Устанавливает стадии жизненного цикла с завершающими артефактами, контрольные точки (гейты) с критериями прохождения и перечнем решений, предельные сроки (SLA) стадий и порядок приостановки и досрочного прекращения проекта. Жизненный цикл синхронизирован с контрольными точками экономической оценки и циклом непрерывного совершенствования процессов.

Опишите в настоящем разделе принципы, на которых строится реализация проектов процессных изменений, и единый жизненный цикл проекта (от регистрации инициативы до подтверждения эффекта). Жизненный цикл должен быть синхронизирован с контрольными точками экономической оценки по [«Методика оценки экономической целесообразности», №34] (таблица соответствия гейтов приведена в п. 6.3) и не должен переопределять порядок расчёта и подтверждения эффекта, установленный [№34], а также порядок подачи заявок, установленный [«Положение о процессном офисе», №2, п. 9.3].

6.1. Принципы реализации проектов изменений

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

Какие принципы процессного подхода (ориентация на клиента процесса, сквозная ответственность владельца процесса, управление на основе данных) закладываются в основу реализации проектов изменений?

Инструкция по заполнению:

сформулируйте 6–8 принципов реализации проектов изменений, обязательно включив ориентацию на клиента процесса, сквозную ответственность владельца процесса и управление на основе данных; остальные принципы подберите из практики BPM CBOK (непрерывное совершенствование, приоритизация по ценности, прозрачность решений). Оформите таблицей «Принцип / Содержание / Проявление в требованиях настоящего Регламента», чтобы каждый принцип был привязан к конкретным нормам документа, а не оставался декларацией.

Пример:

6.2. Стадии жизненного цикла проекта изменения

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

Каковы стадии жизненного цикла проекта изменения (от регистрации инициативы до подтверждения эффекта) и какие артефакты фиксируют завершение каждой стадии?

Инструкция по заполнению:

определите 6–8 последовательных стадий жизненного цикла, начиная с регистрации инициативы (в порядке [№2, п. 9.3, Прил. 15], без введения дополнительной формы инициации) и заканчивая подтверждением эффекта и закрытием (в порядке [№34, разд. 12]). Оформите таблицей «Стадия / Содержание работ / Ответственный / Артефакт завершения стадии»; для каждой стадии укажите ровно один завершающий артефакт, факт утверждения которого означает завершение стадии. Оговорите, что состав обязательных стадий зависит от трека реализации (п. 5.4): для упрощённого трека стадии [2–3] и [6–7] объединяются со смежными.

Пример:

6.3. Контрольные точки (gates) между стадиями

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

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

Инструкция по заполнению:

установите 4–5 контрольных точек между стадиями п. 6.2, соотнесённых с видами экономической оценки и точками Stage-Gate по [№34] (таблица соответствия приведена после таблицы гейтов); содержание Gate 1–3 настоящего Регламента отличается от одноимённых точек [№34], поэтому во внешних коммуникациях указывайте вид оценки по [№34]. Оформите таблицей «Контрольная точка / Положение в жизненном цикле / Критерии прохождения (3–4 проверяемых условия) / Возможные решения / Орган, принимающий решение»; закрытый перечень решений на каждом гейте: «продолжить», «продолжить с условиями», «вернуть на доработку», «приостановить», «прекратить» (в порядке п. 6.6). Укажите, что состав обязательных гейтов определяется треком реализации (п. 5.4), а решения фиксируются протоколом и вносятся в паспорт инициативы.

Пример:

Соответствие гейтов настоящего Регламента видам экономической оценки и точкам Stage-Gate по [№34, разд. 1.3, 2.5]: Gate 0 соответствует предварительной оценке (Gate 0 «Идея» по [№34]); Gate 1 является внутренней контрольной точкой диагностики (самостоятельной точки [№34] не имеет); Gate 2 соответствует полной оценке (бизнес-кейс/ТЭО) и решению Go/No-Go, то есть точке защиты бизнес-кейса (Gate 1 Stage-Gate по [№34]); Gate 3 соответствует пересчёту оценки при изменении параметров проекта ([№34, п. 12.1]); Gate 4 соответствует Plan-Fact анализу и закрытию ([№34, разд. 12.2]). Во взаимодействии с контуром [№34] указывается вид экономической оценки, а не номер гейта настоящего Регламента.

6.4. Предельные сроки (SLA) стадий жизненного цикла

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

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

Инструкция по заполнению:

установите предельные сроки для 5–7 ключевых стадий и решений (квалификация инициативы, диагностика, проектирование TO-BE, принятие решения на гейте, внедрение) с дифференциацией по трекам реализации (п. 5.4); сроки мониторинга эффекта не устанавливайте, они определены [№34, разд. 12] (3/6/12 месяцев; контрольная точка 24 месяца применяется для проектов классов A–B по [№34, разд. 12.2]). Оформите таблицей «Стадия или событие / Точка отсчёта / SLA по трекам»; отдельным абзацем опишите механизм контроля: кто отслеживает сроки, периодичность отчётности, порядок эскалации при нарушении (по [№2, п. 9.7]) и порядок санкционирования переноса срока.

Пример:

Контроль соблюдения SLA осуществляет Процессный офис на основе данных паспортов инициатив: ежемесячно формируется отчёт о состоянии портфеля проектов изменений с выделением проектов, нарушивших SLA или приближающихся к порогу [80]% срока. При нарушении SLA применяется эскалация в порядке [№2, п. 9.7]: уведомление руководителя проекта и владельца процесса направляется в день фиксации нарушения, вынесение вопроса на Процессный комитет производится при просрочке более [10] рабочих дней. Перенос предельного срока допускается однократно на стадию и санкционируется органом соответствующего гейта с фиксацией в паспорте инициативы. Данные о соблюдении SLA используются для расчёта KPI процессного офиса по [№2, п. 7.3, Прил. 13].

6.5. Соотнесение жизненного цикла с циклом непрерывного совершенствования

Описание подраздела: Подраздел соотносит стадии жизненного цикла проекта изменения с фазами цикла PDCA и цикла управления процессами по BPM CBOK. Описывает два контура совершенствования (проектный и операционный) и правило перехода между ними через новую инициативу и очередной цикл приоритизации.

Как жизненный цикл проекта изменения соотносится с циклом непрерывного совершенствования процессов (PDCA, цикл управления процессами по BPM CBOK)?

Инструкция по заполнению:

постройте таблицу соответствия «Стадия жизненного цикла (п. 6.2) / Фаза PDCA / Фаза цикла управления процессами по BPM CBOK» для всех стадий. Отдельным абзацем опишите два контура совершенствования и правило перехода между ними: улучшения, не признанные проектом (п. 5.3), реализуются владельцем процесса в операционном цикле PDCA, а результаты закрытых проектов возвращаются в цикл управления процессами через мониторинг показателей и очередную приоритизацию по [№6].

Пример:

Пример описания контуров: жизненный цикл проекта изменения представляет собой «большой» цикл PDCA уровня системы управления бизнес-процессами. После закрытия проекта (фаза Act) улучшенный процесс передаётся владельцу процесса, который продолжает управлять им в «малом» операционном цикле PDCA без применения настоящего Регламента. Отклонения показателей, выявленные в операционном цикле и превышающие пороги п. 5.3, оформляются новой инициативой в порядке [№2, п. 9.3] и проходят приоритизацию по [№6]; тем самым обеспечивается непрерывность совершенствования.

6.6. Приостановка и досрочное прекращение проекта

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

Каковы триггеры и порядок досрочного прекращения или приостановки проекта на каждой стадии?

Инструкция по заполнению:

определите для каждой группы стадий жизненного цикла 2–3 триггера приостановки и прекращения (утрата актуальности, отрицательный пересчёт бизнес-кейса по [№34], недоступность ресурсов, изменение приоритетов по [№6], блокирующие результаты Impact Analysis) и оформите таблицей «Стадии / Триггеры / Инициатор / Орган, принимающий решение». Решение о прекращении принимается коллегиально: правом инициировать обладают Процессный офис, владелец процесса, руководитель проекта и Спонсор, но единоличное решение о прекращении не принимает ни одна роль, включая Процессный офис; для проектов классов A–B по [№34] решение принимается с участием Спонсора в порядке [№34, п. 12.1]. Отдельным абзацем опишите порядок из 4–5 шагов: инициирование, анализ последствий, решение, фиксация и распоряжение результатами; ограничьте предельный срок приостановки.

Пример:

Пример порядка: (1) инициатор направляет в Процессный офис мотивированное представление с указанием триггера и подтверждающих данных; (2) Процессный офис в срок [5] рабочих дней готовит анализ последствий (выполненные затраты, влияние на смежные проекты и НМД, обязательства перед подразделениями); (3) орган по таблице выше принимает решение о приостановке (на срок не более [3] месяцев) или прекращении; (4) решение протоколируется и вносится в паспорт инициативы, созданные артефакты (модели, отчёты о диагностике) архивируются и остаются доступными для повторного использования; (5) при прекращении инициатива возвращается в реестр приоритетов процессов с пересмотром приоритета по [№6, разд. 9], а по приостановленному проекту по истечении срока приостановки принимается решение о возобновлении либо прекращении. Возобновление приостановленного проекта осуществляется с последнего пройденного гейта с подтверждением актуальности базовых значений показателей по [№34, п. 3.1].

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

Опишите в настоящем разделе ролевую модель проектов процессных изменений, порядок назначения на роли, распределение ответственности по стадиям жизненного цикла и порядок работы коллегиального органа. Ролевая модель должна опираться на статус и функции Процессного офиса по [«Положение о процессном офисе», №2, п. 8.2] и включать Владельца выгод по [«Методика оценки экономической целесообразности», №34, п. 2.1]; новые коллегиальные органы не вводятся без разграничения полномочий с Процессным комитетом ([№2, п. 9.5]), Архитектурным комитетом ([«Регламент управления процессной архитектурой», №5, п. 6.5]), Комитетом по автоматизации ([«Регламент реализации проектов по автоматизации и роботизации бизнес-процессов», №33]) и Инвестиционным комитетом ([№34]).

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

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

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

Инструкция по заполнению:

приведите закрытый перечень 7–9 ролей проекта процессного изменения: Инициатор, Спонсор проекта, Руководитель проекта, Владелец процесса, Владелец выгод (по [№34, п. 2.1]), Финансовый контролёр (по [№34, п. 2.1]), Процессный офис, Участник рабочей группы, Ответственный за внедрение; при необходимости также Методолог процессного офиса. Для каждой роли укажите определение, 3–5 обязанностей и 2–3 права; оформите таблицей «Роль / Обязанности / Права». Используйте определение Владельца процесса как должностного лица, наделённого полномочиями и ресурсами и отвечающего за результаты процесса (по [№5], [№34]); зафиксируйте правило совмещения ролей (какие роли допустимо совмещать одним лицом, а какие совмещать не допускается, например Руководитель проекта и Владелец выгод).

Пример:

Правило совмещения ролей: допускается совмещение роли Инициатора с любой ролью рабочей группы, а роли Ответственного за внедрение с ролью Участника рабочей группы. Не допускается совмещение одним лицом ролей Руководителя проекта и Владельца выгод, а также Владельца выгод и Финансового контролёра (разграничение по [№34, п. 2.1]). Бизнес-аналитик входит в состав рабочей группы; в матрицах RACI (п. 7.4, Приложение Д) учитывается в составе роли «Рабочая группа».

7.2. Функции и полномочия Процессного офиса по стадиям жизненного цикла

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

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

Инструкция по заполнению:

распределите функции Процессного офиса по стадиям жизненного цикла проекта (раздел 5 настоящего Регламента) в таблице «Стадия / Функции / Полномочия», не переопределяя статус и общие функции Процессного офиса, установленные [№2, п. 8.2]. Отдельно зафиксируйте два специальных полномочия: (1) право возврата инициативы на доработку Инициатору с указанием причин и срока повторной подачи (не более [2] возвратов подряд, далее вопрос выносится на Процессный комитет); (2) право инициировать остановку неудачного внедрения, при этом решение об остановке принимает не Процессный офис единолично, а Процессный комитет с учётом позиции Спонсора проекта в порядке [№34, п. 12.1]. Укажите 2–4 функции на каждую стадию.

Пример:

7.3. Порядок назначения на роли и требования к компетенциям

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

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

Инструкция по заполнению:

опишите порядок назначения для трёх категорий (Руководитель проекта, участники рабочей группы, Ответственный за внедрение): кто предлагает кандидатуру, кто согласует, каким документом оформляется назначение (распоряжение/приказ), в какой срок с момента одобрения инициативы ([3–5] рабочих дней). Опишите основания и порядок освобождения от роли (увольнение, длительное отсутствие свыше [N] дней, ненадлежащее исполнение по представлению Процессного офиса) и правило передачи дел. Требования к компетенциям и обучению оформите таблицей «Роль / Требования к компетенциям / Обязательное обучение / Периодичность подтверждения» на 3–4 строки, опираясь на BPM CBOK 4.0 и профстандарты Минтруда.

Пример порядка назначения: кандидатура Руководителя проекта предлагается Владельцем процесса по согласованию с Процессным офисом и утверждается Процессным комитетом одновременно с одобрением инициативы; назначение оформляется распоряжением [Должность руководителя] в течение [3] рабочих дней с даты протокола. Участники рабочей группы делегируются руководителями подразделений по запросу Руководителя проекта с фиксацией доли рабочего времени (не менее [20]%). Освобождение от роли оформляется тем же порядком с одновременным назначением преемника и передачей дел по акту в течение [5] рабочих дней.

7.4. Матрица ответственности RACI по стадиям жизненного цикла

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

Как распределяется ответственность между ролями по стадиям жизненного цикла в формате матрицы RACI?

Инструкция по заполнению:

заполните матрицу RACI «стадии жизненного цикла × роли» на 7–8 ролей (Инициатор, Спонсор, Руководитель проекта, Владелец процесса, Владелец выгод, Процессный офис, Рабочая группа, Процессный комитет). Для каждой стадии должен быть назначен ровно один A (Accountable); R (Responsible) может быть несколько; допускаются комбинации A/R. Проверьте согласованность матрицы с распределением полномочий по пп. 7.1–7.2 и с гейтами Gate 0–4 по [№34]; полную версию матрицы с детализацией до активностей внутри стадий вынесите в приложение.

Пример:

7.5. Коллегиальный орган принятия решений

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

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

Инструкция по заполнению:

закрепите в качестве коллегиального органа по проектам процессных изменений Процессный комитет, действующий по [№2, п. 9.5], не создавая новый орган; опишите его состав применительно к проектам изменений (5–7 позиций: председатель, руководитель Процессного офиса в качестве ответственного секретаря, владельцы затрагиваемых процессов, [финансовый директор] и [ИТ-директор] с правом совещательного голоса), перечень из 5–7 полномочий (одобрение и возврат инициатив, утверждение назначений, прохождение гейтов, повышение трека реализации, остановка проекта с учётом позиции Спонсора по [№34, п. 12.1], разрешение эскалаций), кворум (не менее [2/3] состава), порядок голосования и периодичность заседаний. Разграничьте компетенцию таблицей на 3–4 строки: изменения процессной архитектуры и утверждение публикуемых моделей проводятся через Change Request по [№5, п. 4.2] в инстанциях, определяемых типом и масштабом изменения ([№5, пп. 4.1, 4.2.4, 6.5, 6.6]: минорные рассматривает руководитель Процессного офиса, мажорные рассматривает Архитектурный комитет / Процессный комитет); заявки на автоматизацию рассматривает Комитет по автоматизации по [№33, п. 5.2]; Go/No-Go по экономической целесообразности классов A–B принимает Инвестиционный комитет по [№34].

Пример:

Пример порядка работы: заседания Процессного комитета по проектам изменений проводятся не реже [1] раза в месяц; внеочередные заседания созываются по инициативе председателя, Процессного офиса или Спонсора проекта в срок не позднее [5] рабочих дней. Решения принимаются простым большинством при кворуме [2/3]; при равенстве голосов решающим является голос председателя. Решения оформляются протоколом в течение [3] рабочих дней и обязательны для всех участников проектов изменений.

7.6. Эскалация проблем и конфликтов ответственности

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

Каковы триггеры, уровни и сроки эскалации проблем и конфликтов ответственности (включая «белые пятна» на стыках процессов) и кто выступает финальным арбитром?

Инструкция по заполнению:

задайте 4–6 триггеров эскалации (отклонение сроков стадии свыше [10] рабочих дней, недостижение промежуточных показателей, отказ подразделения выделить ресурсы, конфликт ответственности между владельцами смежных процессов, выявление «белого пятна», то есть зоны на стыке процессов без назначенного ответственного) и три уровня эскалации с предельными сроками рассмотрения на каждом. Оформите таблицей «Уровень / Кто рассматривает / Срок / Типовые вопросы»; зафиксируйте маршрут по [№2, п. 9.7], финального арбитра ([Генеральный директор] либо председатель Процессного комитета) и правило для «белых пятен»: до решения арбитра временную ответственность принимает Владелец процесса-поставщика результата, а Процессный офис в течение [10] рабочих дней готовит предложение о закреплении зоны ответственности. Если разрешение конфликта или «белого пятна» требует изменения границ процессов (элементов процессной архитектуры), вопрос передаётся на медиацию Архитектурного комитета и оформляется в порядке [№5, пп. 6.4, 8.7]; разногласия по оценкам и категориям приоритета процессов по настоящему пункту не эскалируются, они разрешаются по [«Методика приоритизации бизнес-процессов», №6, разд. 4.3].

Пример:

Пример записи об эскалации: «[15.03.20__] Руководитель проекта [ФИО] зафиксировал отказ [Департамента продаж] выделить эксперта в рабочую группу (триггер Т-3). Уровень 1 не урегулирован в срок [3] рабочих дней; [20.03.20__] вопрос передан на уровень 2 руководителю Процессного офиса. Решение: ресурс выделен с [25.03.20__], доля времени [20]%».

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

Опишите в настоящем разделе порядок инициирования проектов процессных изменений и управления портфелем инициатив Процессного офиса: от возникновения инициативы до решения о запуске проекта. Раздел не вводит новой формы заявки (подача заявки на оптимизацию осуществляется в порядке [«Положение о процессном офисе», №2, п. 9.3, Прил. 15]) и не переопределяет критерии приоритизации по [«Методика приоритизации бизнес-процессов», №6] и методику оценки экономической целесообразности по [«Методика оценки экономической целесообразности», №34]; настоящий раздел устанавливает дальнейший жизненный цикл инициативы после её подачи.

8.1. Источники и триггеры инициатив

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

Какие источники и триггеры инициатив (отклонения KPI/PPI, результаты аудитов, стратегические цели, предложения владельцев процессов и подразделений) признаются настоящим Регламентом?

Инструкция по заполнению:

приведите закрытый перечень 6–8 источников инициатив; для каждого источника укажите триггер (событие или условие возникновения), режим поступления (плановый цикл / по событию) и первичный документ-основание. Оформите таблицей «Источник / Триггер / Режим / Документ-основание». Обязательно включите реестр приоритетов процессов (РПП) по [№6] и результаты мониторинга эффекта завершённых проектов через 3/6/12/24 месяца по [№34, разд. 12] как плановые источники Процессного офиса; оговорите, что перечень источников не ограничивает право подачи инициатив в порядке [№2, п. 9.3].

Пример:

8.2. Право инициирования и роль Процессного офиса как инициатора

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

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

Инструкция по заполнению:

приведите перечень 5–7 категорий лиц и органов, обладающих правом инициирования, с указанием основания и порядка подачи для каждой категории; оформите таблицей «Инициатор / Основание инициирования / Порядок подачи». Отдельным абзацем зафиксируйте 3–4 случая, когда инициатором выступает Процессный офис (инициативы из РПП по [№6], системные отклонения показателей по нескольким процессам, недостижение эффекта по [№34, разд. 12], поручения Процессного комитета). Укажите, что независимо от инициатора применяется единая форма заявки по [№2, Прил. 15]; введение дополнительных форм подачи не допускается.

Пример:

Процессный офис выступает инициатором в случаях: (1) включения процесса в категории A–B РПП по итогам цикла приоритизации по [№6]; (2) выявления системных отклонений KPI/PPI, затрагивающих [2] и более процессов; (3) недостижения планового эффекта завершённого проекта по данным Plan-Fact анализа по [№34, разд. 12]; (4) исполнения поручений Процессного комитета. Круг инициаторов не может быть уже установленного [№2, п. 9.3].

8.3. Состав обоснования инициативы

Описание подраздела: Подраздел определяет обязательные элементы обоснования инициативы с требованиями к содержанию и заполнению каждого элемента. Устанавливает, что на этапе инициирования достаточно предварительной оценки ожидаемого эффекта без полного расчёта NPV/ROI.

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

Инструкция по заполнению:

определите 7–9 обязательных элементов обоснования инициативы с требованиями к содержанию каждого элемента; оформите таблицей «Элемент обоснования / Содержание / Требование к заполнению». Укажите, что обоснование формируется в составе заявки по [№2, Прил. 15] и при регистрации дополняется Процессным офисом до паспорта инициативы по [№34]; на этапе обоснования приводится предварительная (качественная или порядковая) оценка ожидаемого эффекта, а полный расчёт эффекта (NPV/ROI) выполняется на последующих стадиях в порядке [№34] и на этапе инициирования не требуется.

Пример:

8.4. Регистрация, маршрутизация и первичная экспертиза. Единый реестр инициатив и проектов

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

Какова процедура регистрации, маршрутизации и первичной экспертизы инициативы Процессным офисом и как ведётся единый реестр инициатив и проектов?

Инструкция по заполнению:

опишите процедуру из 5–7 последовательных шагов с ответственными и предельными сроками в рабочих днях; оформите таблицей «Шаг / Содержание / Ответственный / Срок». В первичную экспертизу включите проверки: полнота обоснования (п. 8.3), отнесение к проекту изменения либо к циклу PDCA (по разд. 5), выявление дублирования с реестром, определение затрагиваемых НМД и моделей процессов, предварительное отнесение к контуру автоматизации по [№33, п. 5.2]. Отдельным абзацем задайте 10–12 обязательных полей единого реестра инициатив и проектов и статусную модель инициативы (например: «зарегистрирована → на экспертизе → на приоритизации → одобрена к запуску / отклонена / отложена / объединена»); укажите систему ведения реестра ([СЭД / BPM-система / реестр Процессного офиса]) и периодичность его актуализации.

Пример:

Обязательные поля единого реестра инициатив и проектов: регистрационный номер; дата регистрации; наименование инициативы; инициатор; источник (п. 8.1); затрагиваемый процесс (код по реестру процессов); затрагиваемые подразделения; статус; категория приоритета A–E (по [№6]); класс проекта A–D (по [№34]), фиксируемый после запуска; ответственный от Процессного офиса; связанные инициативы и проекты (дубликаты, объединения); реквизиты решений (протоколы); плановая дата очередного пересмотра. Реестр актуализируется не реже [1] раза в [месяц] и представляется Процессному комитету в составе отчётности о портфеле.

8.5. Оценка целесообразности и приоритизация инициатив в портфеле

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

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

Инструкция по заполнению:

зафиксируйте, что критерии, веса и скоринговая модель приоритизации не переопределяются настоящим Регламентом: применяются модель и категории приоритета A–E по [«Методика приоритизации бизнес-процессов», №6] (инициативы Quick Win реализуются первыми), а оценка экономической целесообразности выполняется по [№34]; настоящий пункт вправе вводить только 2–4 дополняющих критерия уровня инициативы (не процесса), уточняющих очерёдность внутри одной категории приоритета. Приведите дополняющие критерии таблицей «Критерий / Шкала / Применение»; опишите механизм увязки со стратегией (обязательный маппинг каждой инициативы на стратегическую цель, доля инициатив без связи со стратегией составляет не более [N]%) и укажите орган, утверждающий очерёдность реализации: Процессный комитет (по [№2, п. 9.5]), с периодичностью пересмотра очерёдности не реже [1] раза в [квартал].

Пример:

Очерёдность реализации инициатив в портфеле утверждает Процессный комитет по представлению Процессного офиса. Изменение категории приоритета A–E осуществляется только по правилам [№6]; дополняющие критерии настоящего пункта категорию не изменяют.

8.6. Решение о запуске проекта и работа с отклонёнными, отложенными, дублирующими и объединяемыми инициативами

Описание подраздела: Подраздел устанавливает порядок принятия решения о запуске проекта, оформляемого как Gate 0, и фиксируемые в протоколе атрибуты. Определяет правила работы с отклонёнными, отложенными, дублирующими и объединяемыми инициативами, включая уведомление инициатора и сроки повторного рассмотрения.

Каков порядок принятия решения о запуске проекта и работы с отклонёнными, отложенными, дублирующими и объединяемыми инициативами?

Инструкция по заполнению:

опишите порядок принятия решения о запуске: орган (Процессный комитет по [№2, п. 9.5]; решение о запуске оформляется как Gate 0, единая точка открытия проекта для всех классов; для проектов классов A–B по [№34] решение Go/No-Go Инвестиционного комитета принимается позднее, на Gate 2 при полной оценке бизнес-кейса по [№34]), основание (заключение первичной экспертизы, категория приоритета по [№6], утверждённая очерёдность по п. 8.5), фиксируемые в протоколе атрибуты (класс проекта, трек реализации по разд. 5, куратор, ориентировочные сроки). Затем задайте правила работы с каждым из четырёх исходов таблицей «Решение / Основание / Обязательные действия / Срок повторного рассмотрения»: для каждого исхода предусмотрите уведомление инициатора с мотивировкой в срок не более [N] рабочих дней и фиксацию решения в едином реестре (п. 8.4).

Пример:

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

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

Опишите в настоящем разделе порядок проведения стадии анализа текущего состояния («as-is») процесса в рамках проекта процессного изменения: обязательные методы анализа, требования к модели «как есть», порядок фиксации базовых значений показателей процесса, анализ влияния изменения на смежные процессы и системы управления, а также идентификацию рисков реализации. Результаты стадии анализа являются входом для проектирования целевого состояния (TO-BE) и для оценки экономической целесообразности в порядке [«Методика оценки экономической целесообразности», №34]; настоящий раздел не переопределяет методику расчёта эффекта, а фиксирует требования к аналитической базе проекта.

9.1. Методы анализа текущего состояния «as-is»

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

Какие методы анализа текущего состояния «as-is» (анализ метрик, анализ первопричин, функционально-стоимостной анализ, методы бережливого производства) обязательны к применению и в каком объёме в зависимости от типа проекта?

Инструкция по заполнению:

приведите перечень из 5–8 методов анализа текущего состояния (анализ метрик процесса, анализ первопричин («5 почему», диаграмма Исикавы), функционально-стоимостной анализ, картирование потока создания ценности VSM, анализ потерь по классификации бережливого производства, хронометраж, интервьюирование участников процесса) и задайте матрицу обязательности применения в разрезе типов проектов (разд. 5) и треков реализации (п. 5.4). Оформите таблицей «Метод / Назначение / Обязательность по трекам»; используйте градации «обязателен / рекомендован / по решению руководителя проекта». Укажите минимальный объём применения каждого обязательного метода (например, «анализ первопричин проводится не менее чем для [3] ключевых проблем») и требование фиксировать результаты каждого применённого метода в отчёте об анализе текущего состояния.

Пример:

Применимость по типам проектов (разд. 5): для внедрения процесса «с нуля» методы анализа AS-IS не применяются; вместо них обязательны анализ требований заинтересованных сторон и нормативных требований, анализ процессов-аналогов (бенчмаркинг) и проектирование SIPOC / потока создания ценности целевого процесса; для реинжиниринга VSM и анализ первопричин обязательны независимо от трека; для организационного изменения процессной модели обязателен анализ ролевой структуры и матрицы RACI процесса.

Пример фиксации объёма: для проекта оптимизации процесса «Обработка заявок клиентов» (стандартный трек) выполнен анализ метрик за период [12] месяцев, анализ первопричин для 4 ключевых проблем методом «5 почему», выборочный хронометраж 15 экземпляров процесса. Результаты сведены в отчёт об анализе текущего состояния и рассмотрены Процессным офисом.

9.2. Требования к модели «как есть» и фиксации выявленных проблем

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

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

Инструкция по заполнению:

установите 5–7 требований к модели AS-IS: нотация (для кандидатов на автоматизацию и моделей, публикуемых в репозитории, применяется строго BPMN 2.0.2 в соответствии с [«Регламент управления процессной архитектурой», №5] и [«Регламент реализации проектов по автоматизации и роботизации бизнес-процессов», №33]; для внутренних рабочих моделей допускается [нотация по выбору] с оговоркой), уровень детализации (до операций уровня [L3–L4]), охват (не менее [90]% экземпляров процесса по объёму), подтверждение модели владельцем процесса и ключевыми участниками, версионирование и публикация выполняются в порядке [№5]. Отдельно определите структуру реестра проблем: каждая проблема фиксируется с привязкой к операции модели, классификацией (потеря, узкое место, дублирование функций, разрыв ответственности, избыточный контроль), количественной оценкой последствий и подтверждающими данными. Оформите требования списком, а реестр проблем таблицей на [5–7] граф.

Пример фрагмента реестра проблем (форма приведена в Приложении [X]):

Модель AS-IS считается принятой после письменного подтверждения владельцем процесса её соответствия фактическому исполнению; расхождения между регламентированным и фактическим исполнением процесса фиксируются в реестре проблем отдельным типом «отклонение от НМД».

9.3. Показатели процесса и фиксация базовых значений

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

Какие показатели используются для оценки текущей результативности и эффективности процесса и как фиксируется их базовое значение для последующего сравнения?

Инструкция по заполнению:

определите обязательный минимальный набор из 4–6 групп показателей процесса (результативность: достижение результата и качество; эффективность: время цикла, стоимость экземпляра, трудоёмкость; удовлетворённость потребителя процесса) и требования к фиксации базовых значений показателей процесса: период измерения составляет не менее [12] месяцев или полный бизнес-цикл (по [№34, п. 3.1]; сокращение периода допускается с обоснованием, например при отсутствии сезонности или для нового процесса, по согласованию с Процессным офисом и Владельцем выгод), источник данных, метод расчёта, дата фиксации, подтверждение владельцем процесса. Базовые значения фиксируются в порядке, установленном [«Методика оценки экономической целесообразности», №34, п. 3.1], включаются в паспорт инициативы и используются для последующего Plan-Fact анализа эффекта по [№34, разд. 12]; собственную методику расчёта эффекта не вводите. Оформите таблицей «Показатель / Метод расчёта / Источник данных / Базовое значение / Период измерения».

Пример:

Базовые значения показателей утверждаются владельцем процесса и Процессным офисом до начала проектирования TO-BE; изменение базовых значений после утверждения допускается только с обоснованием и повторным утверждением. При передаче инициативы в контур автоматизации базовые значения прикладываются к заявке в порядке [№33, п. 5.2].

9.4. Анализ влияния изменения на смежные процессы и системы управления

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

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

Инструкция по заполнению:

установите обязательность проведения анализа влияния (Impact Analysis) по форме [«Регламент управления процессной архитектурой», №5, Приложение В] для стандартного и расширенного треков и определите 6–8 обязательных объектов оценки: смежные процессы (по входам/выходам модели), организационная структура и роли, НМД и рабочие документы, показатели смежных процессов, ИТ-системы и интеграции (при их затрагивании взаимодействие ведётся по [№33]), требования систем менеджмента качества (ISO 9001), управления рисками (ISO 31000) и управления персоналом. Для каждого объекта укажите метод выявления влияния (анализ связей моделей в репозитории, RACI-анализ, интервью владельцев смежных процессов) и обязательное согласование результатов с владельцами затронутых процессов. Оформите таблицей «Объект влияния / Метод выявления / Характер влияния / Затронутая сторона / Требуемое согласование»; изменения процессной архитектуры оформляются через Change Request в порядке [№5].

Пример:

Отчёт об анализе влияния прикладывается к материалам гейта, синхронизированного с Gate по [№34]; при выявлении влияния на процессную архитектуру инициируется Change Request по [№5, п. 4.2]; второй контур утверждения архитектурных изменений настоящим Регламентом не создаётся.

9.5. Идентификация рисков реализации изменения

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

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

Инструкция по заполнению:

определите обязательный классификатор из 5–7 категорий рисков реализации, идентифицируемых на стадии анализа: риски сопротивления изменениям (персонал, руководители среднего звена), организационные, методологические (некорректная модель AS-IS, неполные данные), ресурсные, технологические (при затрагивании ИТ-систем), риски недостижения эффекта, регуляторные. Установите порядок оценки по шкале «вероятность × влияние» (матрица [5×5]) в соответствии с ISO 31000 и [«Политика управления рисками», при наличии] и правила влияния на план внедрения: для каждого риска уровня «высокий» и выше в план внедрения включаются обязательные мероприятия, для рисков сопротивления обязателен план коммуникаций и вовлечения; совокупный уровень риска учитывается при выборе стратегии внедрения (пилот / поэтапно / единовременно) по п. 12.2. Оформите реестр рисков таблицей на [5] граф; решение о приостановке или прекращении проекта по результатам оценки рисков принимается коллегиальным органом в порядке п. 6.6.

Пример:

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

Описание раздела: Раздел устанавливает требования к проектированию целевой модели процесса TO-BE: перечень допустимых нотаций моделирования и порядок их выбора, обязательный состав атрибутов целевой модели и правила обеспечения её сопоставимости с моделью AS-IS. Определяет процессный порядок оценки ожидаемого эффекта изменения по методике оценки экономической целесообразности и обязательные блоки плана перехода к целевому процессу, включая организационно-штатные мероприятия, актуализацию НМД и изменение системы мотивации.

10.1. Выбор нотации моделирования

Описание подраздела: Подраздел определяет перечень допустимых нотаций моделирования (BPMN 2.0.2, IDEF0, EPC) и критерии выбора нотации в зависимости от масштаба проекта, уровня декомпозиции и назначения модели. Устанавливает обязательность BPMN 2.0.2 для публикуемых моделей и кандидатов на автоматизацию, порядок фиксации выбранной нотации в уставе проекта и запреты на смешение и произвольную смену нотаций.

Какие нотации моделирования (BPMN, EPC, IDEF0) применяются для описания состояний AS-IS и TO-BE и чем определяется выбор нотации для проектов разного масштаба?

Инструкция по заполнению:

Приведите перечень допустимых нотаций моделирования (3-4 нотации) и критерии выбора нотации в зависимости от масштаба проекта, уровня декомпозиции процесса (L0–L4) и назначения модели. Оформите таблицей «Масштаб проекта / Уровень модели / Нотация / Обоснование». Обязательно зафиксируйте: для процессов, являющихся кандидатами на автоматизацию (передача по [НМД «Регламент реализации проектов по автоматизации и роботизации бизнес-процессов», №33]), и для моделей, публикуемых в репозитории процессов ([НМД «Регламент управления процессной архитектурой»]), применяется исключительно BPMN 2.0.2; выбор иной нотации допускается только для рабочих (непубликуемых) моделей.

Пример:

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

Утверждённый перечень нотаций: BPMN 2.0.2 является основной нотацией для всех публикуемых моделей и кандидатов на автоматизацию; IDEF0 применяется для верхнеуровневой функциональной декомпозиции (только рабочие, непубликуемые модели); EPC допускается только для рабочих (непубликуемых) моделей при описании цепочек событий и функций по согласованию с процессным офисом. Выбор нотации фиксируется в уставе проекта при инициации и согласуется с процессным офисом. Не допускается: смешение элементов разных нотаций в одной диаграмме; применение нотаций, не входящих в утверждённый перечень; публикация в репозитории процессов моделей в нотациях, отличных от BPMN 2.0.2. Модели состояний AS-IS и TO-BE одного процесса должны выполняться в одной и той же нотации.

10.2. Требования к целевой модели TO-BE

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

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

Инструкция по заполнению:

Сформулируйте обязательный состав атрибутов целевой модели (8-10 атрибутов) в виде таблицы «Атрибут / Содержание требования / Форма фиксации». Требования должны обеспечивать полноту паспорта целевой модели: границы (событие начала и завершения), входы/выходы с поставщиками и потребителями, роли участников, матрица ответственности RACI, контрольные точки, целевые значения КПЭ, интерфейсы со смежными процессами.

Пример:

Опишите порядок проверки целевой модели на соответствие требованиям: кто проверяет (процессный офис выполняет нормоконтроль, владелец процесса проверяет содержание), в какой срок, что является результатом проверки. Укажите, что при затрагивании архитектуры процессов изменение проводится через запрос на изменение (Change Request) по [НМД «Регламент управления процессной архитектурой»].

Целевая модель TO-BE подлежит нормоконтролю процессного офиса в срок не более [5] рабочих дней с даты представления. Содержательную проверку выполняет владелец процесса. Модель, затрагивающая архитектуру процессов организации, вносится в репозиторий через запрос на изменение (Change Request) в порядке, установленном [НМД «Регламент управления процессной архитектурой»]. Целевая модель без заполненного паспорта и RACI-матрицы к согласованию не принимается.

10.3. Сопоставимость моделей AS-IS и TO-BE

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

Как обеспечивается сопоставимость текущей и целевой моделей процесса?

Инструкция по заполнению:

Перечислите 4-6 правил обеспечения сопоставимости моделей: единая нотация и уровень декомпозиции, единые границы процесса, единый набор показателей, единый глоссарий ролей и объектов, ведение карты соответствия операций. Опишите назначение карты соответствия (трассировка «операция AS-IS → операция TO-BE → тип изменения») и её табличный формат. Укажите, что выявление разрывов между AS-IS и TO-BE (gap analysis) выполняется в терминах [НМД «Регламент управления процессной архитектурой»].

Пример:

Опишите требования к фиксации базовых значений показателей процесса (соответствует термину «базовая линия» по [НМД «Методика оценки экономической целесообразности», п. 3.1], см. п. 1.7) до начала проектирования TO-BE: без зафиксированных базовых значений сопоставление и последующая оценка эффекта не допускаются. Укажите ответственного за ведение карты соответствия.

Базовые значения показателей процесса фиксируются в порядке, установленном [НМД «Методика оценки экономической целесообразности»], до утверждения целевой модели. Карту соответствия операций AS-IS/TO-BE ведёт [руководитель проекта / бизнес-аналитик]; полнота трассировки (каждая операция AS-IS отнесена к одному из типов: сохранена, изменена, исключена, автоматизирована) проверяется процессным офисом.

10.4. Оценка ожидаемого эффекта изменения

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

Каковы правила оценки ожидаемого эффекта изменения: методика расчёта, горизонт оценки, источники данных и ответственный за расчёт?

Инструкция по заполнению:

Укажите, что методика расчёта эффекта, горизонт оценки, требования NPV/ROI и порядок подтверждения эффекта настоящим Регламентом не устанавливаются, они определены [НМД «Методика оценки экономической целесообразности»]. Опишите только процессную часть (4-5 пунктов): на какой стадии проекта оценка обязательна, кто инициирует и выполняет расчёт (владелец выгод, финансовая служба), какие исходные данные передаются из моделей AS-IS/TO-BE и карты соответствия, куда включается результат (бизнес-кейс/ТЭО для прохождения Gate). Оформите таблицей «Шаг / Ответственный / Вход / Выход».

Пример:

Оценка ожидаемого эффекта обязательна до вынесения целевой модели на утверждение и выполняется по [НМД «Методика оценки экономической целесообразности»]. Целевая модель, по которой расчёт эффекта не выполнен или не верифицирован, к прохождению Gate не допускается. Сравнение фактического и планового эффекта после внедрения выполняется в рамках Plan-Fact анализа по указанной методике. При наличии связанной заявки или проекта автоматизации ([№33]) эффект разграничивается между процессной и автоматизационной составляющими; двойной учёт одного эффекта в бизнес-кейсах обоих контуров не допускается, порядок атрибуции определён [НМД «Методика оценки экономической целесообразности»].

10.5. План перехода к целевому процессу

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

Что включает план перехода (roadmap) к целевому процессу в части организационно-штатных мероприятий, разработки НМД и изменения системы мотивации?

Инструкция по заполнению:

Определите обязательные блоки плана перехода (4-6 блоков): организационно-штатные мероприятия (изменение оргструктуры, штатного расписания, должностных инструкций), разработка и актуализация НМД, изменение системы мотивации (пересмотр КПЭ ролей, увязка с целевыми показателями процесса), обучение персонала, коммуникации. Для каждого блока укажите состав мероприятий, ответственного и требуемое согласование. Оформите таблицей на 4-5 строк.

Пример:

Опишите требования к атрибутам плана перехода: каждое мероприятие должно иметь срок, ответственного, результат и признак завершения; план должен быть согласован с владельцами затрагиваемых смежных процессов и утверждён одновременно с целевой моделью. Укажите порядок актуализации плана (не реже [1] раза в [месяц] до завершения перехода).

План перехода утверждается одновременно с целевой моделью TO-BE и является основанием для стадии внедрения. Каждое мероприятие плана должно содержать: срок, ответственного, ожидаемый результат и измеримый признак завершения. Мероприятия по изменению системы мотивации вводятся в действие не ранее утверждения актуализированных НМД по процессу. Согласование и утверждение разрабатываемых и актуализируемых процессных НМД выполняются в порядке [№2, п. 9.4]. Актуализация плана выполняется руководителем проекта не реже одного раза в [месяц] с информированием процессного офиса.

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

11.1. Состав пакета документов и требования к оформлению

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

Каков состав пакета документов, выносимых на согласование (модель «to-be», план внедрения, оценка эффекта, анализ влияния), и какие требования предъявляются к его оформлению?

Инструкция по заполнению:

Определите обязательный состав пакета проектных документов (5-7 документов) в виде таблицы «Документ / Содержание / Требования к оформлению / Основание». Включите: целевую модель TO-BE с паспортом, план внедрения (перехода), оценку ожидаемого эффекта (по [НМД «Методика оценки экономической целесообразности»]), анализ влияния (Impact Analysis по форме [НМД «Регламент управления процессной архитектурой»]), пояснительную записку и лист согласования. Укажите, что оформление документов должно соответствовать ГОСТ Р 7.0.97-2025 и требованиям к моделям разд. [10] настоящего Регламента.

Пример:

Опишите порядок проверки комплектности и нормоконтроля пакета: кто проверяет (процессный офис), в какой срок, последствия некомплектности. Укажите 2-3 условия, при которых пакет не принимается к согласованию (отсутствие верифицированного расчёта эффекта, отсутствие анализа влияния, несоответствие моделей требованиям разд. [10]).

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

11.2. Контур обязательного согласования и согласительные сессии

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

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

Инструкция по заполнению:

Определите контур обязательного согласования (6-8 согласующих) и последовательность этапов в виде таблицы «Очередь / Согласующий / Предмет согласования». Установите правило: согласующие одной очереди рассматривают пакет параллельно, очереди проходятся последовательно; переход к следующей очереди выполняется после урегулирования замечаний предыдущей. Состав контура определяется по результатам анализа влияния и согласуется с процессным офисом в порядке, установленном [НМД «Положение о процессном офисе»]; обязательно включаются владельцы всех затрагиваемых процессов и владелец выгод.

Пример:

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

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

11.3. Предельные сроки рассмотрения и действия при их нарушении

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

Каковы предельные сроки рассмотрения документов на каждом этапе согласования и порядок действий при их нарушении?

Инструкция по заполнению:

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

Пример:

Опишите условия применения правила «согласовано по умолчанию» (2-3 условия): истечение предельного срока при подтверждённом получении пакета, отсутствие запроса о продлении; а также исключения, на которые правило не распространяется (например, согласование [юридической службой] и владельцем изменяемого процесса). Укажите допустимость однократного продления срока и его предел.

При непредставлении замечаний в предельный срок пакет считается согласованным данным согласующим по умолчанию, о чём процессный офис делает отметку в листе согласования. Правило не применяется к владельцу изменяемого процесса, [юридической службе], а также к [финансовой службе] (Финансовый контролёр по [№34, п. 2.1]) в части верификации оценки эффекта и к [ИТ-директору] в части реализуемости ИТ-изменений. Согласующий вправе однократно запросить продление срока не более чем на [3] рабочих дня с обоснованием; запрос направляется до истечения основного срока.

11.4. Урегулирование разногласий согласующих сторон

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

Как разрешаются разногласия согласующих сторон и каков механизм вынесения неурегулированных разногласий на коллегиальный орган?

Инструкция по заполнению:

Опишите ступенчатый механизм урегулирования разногласий (3 уровня) в виде таблицы «Уровень / Способ урегулирования / Участники / Предельный срок / Результат»: уровень 1: рабочее урегулирование и согласительная сессия; уровень 2: эскалация руководителям согласующих сторон при участии руководителя процессного офиса; уровень 3: вынесение на [Процессный комитет] (новый коллегиальный орган не создаётся; статус и полномочия комитета определены [НМД «Положение о процессном офисе»]). Укажите распределение по компетенции: разногласия по архитектуре процессов выносятся на [Архитектурный комитет] по [НМД «Регламент управления процессной архитектурой»], а по оценке эффекта и финансированию на [Инвестиционный комитет] по [НМД «Методика оценки экономической целесообразности»].

Пример:

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

Неурегулированные разногласия оформляются протоколом разногласий по Приложению [X] с изложением позиций сторон и оценкой последствий каждого варианта решения. Материалы к заседанию [Процессного комитета] направляются его членам не позднее чем за [3] рабочих дня до заседания. Решение коллегиального органа обязательно для всех сторон согласования и отражается в листе согласования; повторное вынесение того же разногласия без новых обстоятельств не допускается.

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

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

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

Инструкция по заполнению:

Определите уровни утверждения в зависимости от класса проекта (по [НМД «Методика оценки экономической целесообразности»]): для локальных изменений утверждение проводит [Спонсор проекта / владелец процесса], для кросс-функциональных [Процессный комитет], а для проектов, проходящих Gate с решением Go/No-Go, утверждение проводится в порядке [НМД «Методика оценки экономической целесообразности»]. Укажите форму утверждения (протокол коллегиального органа и/или приказ [руководителя организации]) и перечислите варианты решений (4-5 вариантов) таблицей «Решение / Условия принятия / Последствия».

Пример:

Опишите момент приобретения целевой моделью обязательного статуса (2-3 положения): с даты утверждения либо с даты введения в действие, указанной в приказе; обязательность для всех участников процесса; порядок публикации утверждённой модели. Зафиксируйте разграничение: настоящий Регламент утверждает проектное решение (целевую модель, план внедрения, обязательства по эффекту) в составе проекта изменения; внесение изменений в архитектуру процессов и публикация модели в репозитории выполняются через запрос на изменение (Change Request) по [НМД «Регламент управления процессной архитектурой»]; отдельный (повторный) контур утверждения модели не проводится.

Целевая модель приобретает обязательный статус для всех участников процесса с даты введения в действие, указанной в приказе об утверждении, а при её отсутствии с даты утверждения протоколом. Утверждённая модель передаётся в репозиторий процессов через запрос на изменение (Change Request) в порядке [НМД «Регламент управления процессной архитектурой»]; решение об утверждении проектного решения по настоящему Регламенту признаётся основанием запроса без повторного содержательного согласования модели. До введения целевой модели в действие исполнение процесса осуществляется по действующей (AS-IS) регламентации.

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

12.1. План внедрения изменения и подтверждение ресурсов

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

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

Инструкция по заполнению:

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

Пример:

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

12.2. Выбор стратегии внедрения

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

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

Инструкция по заполнению:

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

Пример:

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

12.3. Коммуникации, обучение и поддержка участников процесса

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

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

Инструкция по заполнению:

Опишите порядок формирования плана коммуникаций: выделение 3-5 целевых аудиторий (руководители затрагиваемых подразделений, исполнители изменяемых операций, смежные процессы, топ-менеджмент), ключевые сообщения и каналы для каждой аудитории, минимальный график информирования (например, за [20], [10] и [1] рабочий день до запуска). Определите требования к обучению: формы (инструктаж, очное/дистанционное обучение, рабочие инструкции), обязательность для ролей, чьи действия меняются в целевой модели, способ фиксации прохождения обучения. Укажите распределение ответственности за подготовку материалов (Руководитель проекта, Владелец процесса, [подразделение обучения/HR], Процессный офис в части методологической поддержки) и порядок поддержки после запуска (контактное лицо, канал приёма вопросов, срок реагирования). Оформите план коммуникаций таблицей на 4-5 строк.

Пример:

Обучение является обязательным для всех работников, чьи роли или операции изменяются в целевой модели процесса. Прохождение обучения фиксируется в [листе ознакомления / системе дистанционного обучения]; работник, не прошедший обучение, не допускается к выполнению изменённых операций. Материалы обучения (рабочие инструкции, памятки) готовит Руководитель проекта совместно с Владельцем процесса; методологическую поддержку оказывает Процессный офис. В период внедрения действует [горячая линия / выделенный канал] поддержки со сроком ответа не более [1] рабочего дня.

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

Описание подраздела: Подраздел устанавливает порядок актуализации документов, затрагиваемых изменением (НМД, должностные инструкции, формы отчётности, модели в репозитории), с ответственными и сроками готовности. Закрепляет правило синхронного вступления в силу изменённых документов и запуска целевой модели единым приказом и запрет запуска процесса при неутверждённых редакциях документов.

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

Инструкция по заполнению:

Опишите порядок формирования перечня затрагиваемых документов (на основе Impact Analysis, выполненного на стадии анализа): НМД, должностные инструкции, положения о подразделениях, формы отчётности, справочники ИТ-систем. Определите ответственных за актуализацию каждого типа документов и требование о включении сроков актуализации в план внедрения. Зафиксируйте правило синхронного вступления в силу: единая дата введения в действие изменённых документов и запуска целевой модели процесса, оформляемая [единым приказом/распоряжением]; изменения процессных моделей в репозитории проводятся через Change Request по [НМД «Регламент управления процессной архитектурой»]. Приведите таблицу-перечень типов документов с ответственными на 4-5 строк.

Пример:

Все документы, затрагиваемые изменением, вводятся в действие единым [приказом] с датой, совпадающей с датой запуска целевой модели процесса. Не допускается запуск изменённого процесса при неутверждённых редакциях затрагиваемых НМД и должностных инструкций: данное условие включается в чек-лист критериев готовности к запуску. Утратившие силу редакции документов помечаются как недействующие в [реестре НМД / СЭД] в день вступления в силу новых редакций. Согласование и утверждение актуализируемых процессных НМД выполняются в порядке [№2, п. 9.4].

12.5. Условия и процедура отката (rollback)

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

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

Инструкция по заполнению:

Определите 3-5 критериев признания проблемы внедрения критической (остановка процесса или недопустимое нарушение сроков/качества его результатов, нарушение обязательных требований, недостижение минимально допустимых значений показателей относительно базовых значений показателей процесса, реализация риска с ущербом выше [порога]). Опишите процедуру отката по шагам: фиксация проблемы, экспресс-анализ причин силами Руководителя проекта и Владельца процесса в срок не более [2] рабочих дней, вынесение вопроса на решение, выполнение отката, информирование участников. Разграничьте контуры: откат опубликованной в репозитории версии модели выполняется по процедуре отката версии архитектуры [№5, п. 9.3]; при наличии на процессе работающих решений автоматизации требуется согласование с владельцем решения и [CoE] в порядке [№33, разд. 12, 16]. Укажите, что решение об откате принимает [Спонсор проекта] по представлению Владельца процесса (при разногласиях решение принимает [Процессный комитет]); Процессный офис единолично решение не принимает. Отдельно опишите порядок действий для процессов «с нуля», где откат невозможен (приостановка процесса и план корректирующих действий). Условия отката оформите нумерованным списком, а процедуру списком шагов со сроками.

Пример:

Основаниями для инициирования отката являются: (1) остановка выполнения процесса более чем на [1] рабочий день по причинам, связанным с целевой моделью; (2) нарушение обязательных требований [законодательства/регулятора]; (3) снижение ключевых показателей процесса более чем на [30]% относительно базовых значений показателей процесса, зафиксированных до внедрения; (4) реализация риска внедрения с оценкой ущерба свыше [порогового значения]. Решение об откате принимает [Спонсор проекта] по представлению Владельца процесса в срок не более [1] рабочего дня с момента вынесения вопроса; при разногласиях вопрос эскалируется в [Процессный комитет]. Откат выполняется по заранее описанному в плане внедрения сценарию возврата к базовой версии процесса с одновременным восстановлением действия прежних редакций документов. Сценарий отката должен включать порядок выверки данных и транзакций, обработанных по отменяемой модели TO-BE (повторная обработка, перенос либо аннулирование), с фиксацией результатов выверки в [журнале проекта]. Для процессов, внедряемых «с нуля», вместо отката применяется приостановка процесса с утверждением плана корректирующих действий. Факт отката фиксируется в [журнале проекта], повторный запуск допускается только после устранения причин и повторного подтверждения готовности по чек-листу. Если целевая модель к моменту отката опубликована в репозитории процессов, возврат к предыдущей версии модели выполняется по процедуре отката версии архитектуры [№5, п. 9.3]; настоящий пункт регулирует организационный откат исполнения процесса и восстановление действия прежних редакций документов. Если на затрагиваемом процессе эксплуатируются решения автоматизации/роботизации, решение об откате принимается по согласованию с владельцем решения и [Центром компетенций (CoE)]; изменение или приостановка решения автоматизации выполняется в порядке [№33, разд. 12, 16].

12.6. Период стабилизации и признание изменения внедрённым

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

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

Инструкция по заполнению:

Определите порядок установления периода стабилизации: длительность по умолчанию (например, [1-3] полных отчётных цикла процесса, но не менее [1] и не более [3] месяцев), основания для продления, расширенный период для процессов «с нуля» и организационных изменений. Опишите режим наблюдения в период стабилизации: усиленный мониторинг показателей относительно базовых значений показателей процесса, регулярность контрольных встреч, порядок обработки инцидентов и мелких доработок. Задайте 4-6 условий признания изменения внедрённым (устойчивое выполнение процесса по целевой модели, отсутствие открытых критических проблем, достижение целевых операционных показателей, завершение обучения, актуализация всех документов) и укажите, кто и каким документом фиксирует признание (акт/протокол, утверждаемый [Спонсором проекта] по представлению Владельца процесса). Отметьте, что последующий мониторинг эффекта выполняется по [НМД «Методика оценки экономической целесообразности»] и в настоящем разделе не переопределяется. Условия оформите таблицей-чек-листом на 4-6 строк.

Пример:

Период стабилизации устанавливается в плане внедрения и составляет по умолчанию [2] полных отчётных цикла процесса, но не менее [1] месяца с даты запуска; для процессов «с нуля» и организационных изменений он составляет не менее [2] месяцев. В период стабилизации Владелец процесса еженедельно контролирует операционные показатели, а выявленные отклонения регистрируются и устраняются в приоритетном порядке.

Признание изменения внедрённым оформляется [актом о завершении внедрения], который готовит Руководитель проекта, визирует Владелец процесса и утверждает [Спонсор проекта]. С даты утверждения акта проект переходит к стадии закрытия и мониторинга эффекта, выполняемого в порядке и в сроки, установленные [НМД «Методика оценки экономической целесообразности» (мониторинг через 3/6/12/24 месяца)].

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

13.1. Мониторинг показателей после внедрения

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

Какие показатели и в течение какого периода после внедрения подлежат мониторингу для подтверждения планового эффекта и приживаемости процесса?

Инструкция по заполнению:

Определите состав показателей мониторинга (5-7 показателей) двух групп: показатели эффекта (для подтверждения плановых значений из бизнес-кейса/ТЭО) и показатели приживаемости процесса (доля операций, выполняемых по целевой модели, отсутствие возвратов к прежнему порядку работы, исполнение контрольных точек). Оформите таблицей «Группа / Показатель / Источник данных / Периодичность измерения / Ответственный за сбор». Укажите, что контрольные точки мониторинга ([3/6/12/24] месяцев после внедрения) и порядок подтверждения эффекта установлены [НМД «Методика оценки экономической целесообразности»] и настоящим Регламентом не переопределяются; сопоставление ведётся с базовыми значениями показателей процесса, зафиксированными до начала изменений.

Пример:

Опишите правила организации мониторинга (3-4 правила): период мониторинга определяется классом проекта и горизонтом подтверждения эффекта по [НМД «Методика оценки экономической целесообразности»]; перечень показателей и их плановые значения фиксируются в плане мониторинга до завершения стадии внедрения; изменение перечня показателей в ходе мониторинга допускается только по решению [коллегиального органа].

План мониторинга формируется руководителем проекта совместно с владельцем выгод до завершения стадии внедрения и включает: перечень показателей, базовые и плановые значения, источники данных, периодичность измерения, контрольные точки [3/6/12/24] месяцев и ответственных. Мониторинг приживаемости процесса ведётся не менее [6] месяцев с даты ввода целевого процесса в действие; мониторинг эффекта ведётся в течение горизонта, установленного [НМД «Методика оценки экономической целесообразности»] для соответствующего класса проекта.

13.2. Plan-Fact анализ и отчёт об оценке эффекта

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

Как проводится сопоставление фактических значений показателей с базовыми и плановыми и кто отвечает за подготовку отчёта об оценке эффекта?

Инструкция по заполнению:

Опишите порядок Plan-Fact анализа (сопоставление факта, плана и базовых значений по [НМД «Методика оценки экономической целесообразности»]) в виде последовательности из 4-5 шагов таблицей «Шаг / Ответственный / Срок / Результат»: сбор фактических значений, сопоставление с базовыми и плановыми, анализ причин отклонений, подготовка отчёта об оценке эффекта, рассмотрение отчёта [коллегиальным органом]. Закрепите персональную ответственность: подготовку отчёта обеспечивает владелец выгод при методической поддержке [финансовой службы] и процессного офиса; укажите пороги существенности отклонений (например, свыше [10]% от планового значения), требующие обязательного анализа причин.

Пример:

Определите обязательный состав отчёта об оценке эффекта (5-6 разделов списком): фактические, плановые и базовые значения показателей; выявленные отклонения и их причины; оценка приживаемости процесса; предложения по корректирующим мерам; заключение о подтверждении эффекта. Укажите, что методика расчёта и верификация значений выполняются по [НМД «Методика оценки экономической целесообразности»].

Отчёт об оценке эффекта готовится владельцем выгод к каждой контрольной точке мониторинга и включает: сопоставление фактических значений с базовыми и плановыми, анализ причин отклонений, оценку приживаемости процесса и заключение о подтверждении эффекта. Корректность расчётов верифицируется [финансовой службой] по [НМД «Методика оценки экономической целесообразности»]. Отчёт представляется в процессный офис не позднее [15] рабочих дней после контрольной точки и выносится на ближайшее заседание [коллегиального органа]. При наличии связанного проекта автоматизации ([№33]) эффект в отчёте разграничивается между процессной и автоматизационной составляющими; двойной учёт одного эффекта не допускается (п. 10.4).

13.3. Действия при недостижении планового эффекта

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

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

Инструкция по заполнению:

Определите шкалу реагирования на недостижение эффекта (3-4 уровня) таблицей «Величина отклонения / Корректирующие меры / Срок реализации / Кто принимает решение». Предусмотрите типовые меры: дополнительное обучение и коммуникации, донастройка процесса без изменения целевой модели, корректировка целевой модели (при затрагивании архитектуры процессов реализуется через Change Request по [НМД «Регламент управления процессной архитектурой», №5, п. 4.2]), пересмотр плановых значений эффекта. Зафиксируйте, что решения о существенных мерах (пересмотр плановых значений, повторный проект, признание эффекта недостигнутым) принимает [коллегиальный орган] по представлению Спонсора проекта; процессный офис единолично такие решения не принимает.

Пример:

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

План корректирующих мероприятий формируется владельцем процесса совместно с владельцем выгод в течение [10] рабочих дней с даты решения и содержит: перечень мер, сроки, ответственных и целевые значения показателей. Контроль исполнения ведёт процессный офис. Повторная оценка эффекта проводится к следующей контрольной точке мониторинга; при повторном недостижении планового эффекта вопрос выносится на [коллегиальный орган] с вариантами решения: пересмотр плановых значений, инициирование нового проекта изменения либо фиксация фактически достигнутого эффекта. Пересмотр плановых значений эффекта допускается только при документально подтверждённом изменении внешних условий или границ проекта либо подтверждённой ошибке исходных допущений, по решению [коллегиального органа] с заключением Финансового контролёра ([№34]); пересмотр плановых значений по причине неисполнения мероприятий проекта не допускается.

13.4. Передача процесса в операционное управление и роспуск рабочей группы

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

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

Инструкция по заполнению:

Определите критерии стабилизации процесса (3-5 критериев: достижение плановых значений показателей приживаемости в течение [2-3] последовательных периодов измерения, актуализированные НМД введены в действие, персонал обучен, контрольные точки исполняются) и состав передаваемого владельцу процесса пакета. Опишите процедуру передачи: оформляется актом передачи процесса в операционное управление за подписями руководителя проекта, владельца процесса и процессного офиса. Оформите состав пакета передачи таблицей «Объект передачи / Форма / Кто передаёт».

Пример:

Опишите порядок роспуска рабочей группы (3-4 положения): роспуск оформляется [приказом / распоряжением] на основании акта передачи; участники освобождаются от проектных ролей с даты роспуска; определите порядок оценки вклада участников и передачи её результатов [руководителям подразделений / в систему мотивации]; незакрытые мероприятия мониторинга передаются владельцу процесса и владельцу выгод.

Процесс считается стабилизированным при достижении показателей приживаемости не ниже [90]% в течение [3] последовательных периодов измерения и введении в действие всех актуализированных НМД. Передача оформляется актом передачи процесса в операционное управление в течение [10] рабочих дней с даты подтверждения стабилизации. Роспуск рабочей группы оформляется [распоряжением] на основании акта; обязанности по продолжению мониторинга эффекта до финальной контрольной точки переходят к владельцу процесса и владельцу выгод. Руководитель проекта представляет [руководителям подразделений] оценку вклада участников рабочей группы.

13.5. Основания и процедуры закрытия проекта

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

Что является основанием для закрытия проекта и какие процедуры закрытия обязательны?

Инструкция по заполнению:

Перечислите основания закрытия проекта (4-5 оснований списком): плановое закрытие после передачи процесса в операционное управление и подтверждения эффекта (либо фиксации решения [коллегиального органа] по итогам финальной контрольной точки); досрочное закрытие по решению [коллегиального органа] (утрата актуальности, недостижимость целей, изменение приоритетов по [НМД «Методика приоритизации бизнес-процессов»]). Определите обязательные процедуры закрытия таблицей «Процедура / Ответственный / Срок / Результат»: подготовка итогового отчёта, архивирование проектных материалов, утверждение закрытия [коллегиальным органом], передача сведений для пересмотра приоритета процесса.

Пример:

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

Проект подлежит закрытию после подписания акта передачи процесса в операционное управление, рассмотрения отчёта об оценке эффекта [коллегиальным органом], а также публикации модели «как внедрено» и актуализации карты процессов (п. 14.4, [№5]); продолжение мониторинга до финальной контрольной точки [12/24] мес. не препятствует закрытию, при этом обязанности мониторинга закрепляются решением о закрытии за владельцем процесса и владельцем выгод. Проект считается закрытым с даты протокола [коллегиального органа]. Материалы проекта хранятся в [СЭД / репозитории] не менее [5] лет; результаты закрытия учитываются при очередном цикле приоритизации процессов по [НМД «Методика приоритизации бизнес-процессов»].

13.6. Извлечённые уроки (lessons learned)

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

Как накапливаются и используются извлечённые уроки для совершенствования регламента и практики процессного офиса?

Инструкция по заполнению:

Опишите порядок сбора извлечённых уроков (3-4 положения): итоговая сессия рабочей группы до её роспуска, фиксация уроков в реестре извлечённых уроков процессного офиса, обязательный раздел итогового отчёта. Определите структуру записи реестра таблицей «Атрибут / Содержание» либо приведите пример реестра на 3-4 записи с атрибутами: стадия жизненного цикла проекта, описание ситуации, причина, рекомендация, статус применения.

Пример:

Определите механизм использования уроков (3-4 механизма списком): анализ реестра процессным офисом не реже [1] раза в [полугодие] с подготовкой предложений по изменению настоящего Регламента и типовых форм; обязательная проверка применимых уроков руководителем проекта при инициации нового проекта; доведение обобщённых уроков до руководителей проектов и владельцев процессов; вынесение системных уроков на [коллегиальный орган].

Реестр извлечённых уроков ведёт процессный офис. Итоговая сессия по извлечённым урокам проводится руководителем проекта с участием рабочей группы до её роспуска; записи вносятся в реестр в течение [5] рабочих дней. Процессный офис не реже [1] раза в [полугодие] анализирует реестр и формирует предложения по совершенствованию настоящего Регламента, типовых форм и практики сопровождения проектов; системные уроки выносятся на [коллегиальный орган]. При инициации нового проекта руководитель проекта обязан ознакомиться с применимыми записями реестра и отразить учёт уроков в уставе (паспорте) проекта.

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

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

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

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

Инструкция по заполнению:

приведите реестр обязательных и опциональных документов проекта изменения бизнес-процесса в разрезе стадий жизненного цикла (12–18 артефактов), в форме таблицы «Стадия / Документ / Шаблон / Обязательность / Ответственный за подготовку». Не дублируйте шаблоны смежных НМД: для паспорта инициативы и бизнес-кейса ссылайтесь на [«Методика оценки экономической целесообразности», №34], для заявки на оптимизацию на [Положение о процессном офисе, №2, Приложение 15], для форм Change Request и Impact Analysis на [Регламент управления процессной архитектурой, №5]. Отдельно задайте единую маску именования файлов и требования к оформлению по ГОСТ Р 7.0.97-2025 (титульные реквизиты, нумерация версий в имени файла).

Пример:

Единая маска именования файлов проекта: [Код проекта]_[Тип документа]_v[X.Y]_[ГГГГММДД]. Пример: PRJ-2026-014_План-внедрения_v1.2_20260315. Документы, не соответствующие маске и утверждённым шаблонам, не должны приниматься процессным офисом к согласованию.

14.2. Хранение, актуализация и доступ к материалам проекта

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

Как организуются хранение, актуализация и доступ к материалам проекта в репозитории процессов и какие сроки хранения устанавливаются?

Инструкция по заполнению:

опишите структуру хранения (корпоративный репозиторий процессов, раздел проектов; типовая структура папок по стадиям ЖЦ), правила актуализации (кто и с какой периодичностью проверяет актуальность, например ежеквартально) и матрицу доступа для 4–6 ролей (чтение / редактирование / публикация). Установите сроки хранения по категориям материалов таблицей на 3–5 строк; укажите порядок архивирования после закрытия проекта и запрет локального хранения рабочих версий вне репозитория.

Пример:

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

14.3. Версионность проектных документов и прослеживаемость решений

Описание подраздела: Подраздел задаёт правила версионности проектных документов (мажорные и минорные версии, статусы документа) с отсылкой к смежному НМД по версионированию моделей процессов. Устанавливает механизм прослеживаемости каждой утверждённой версии до решения-основания через лист регистрации изменений.

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

Инструкция по заполнению:

задайте правила версионности проектных документов (мажорная версия X.0 присваивается после утверждения, минорная X.Y соответствует рабочим правкам; статусы «черновик / на согласовании / утверждён / архив»). Версионирование моделей процессов НЕ переопределяйте, дайте ссылку на [Регламент управления процессной архитектурой, №5]. Опишите механизм прослеживаемости: лист регистрации изменений в каждом документе, обязательная ссылка на основание (протокол, запрос на изменение), связь «версия документа → решение органа управления»; приведите пример листа регистрации изменений таблицей на 3–4 строки.

Пример:

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

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

Описание подраздела: Подраздел определяет последовательность действий команды проекта от завершения внедрения до публикации модели «как внедрено» в корпоративном репозитории и актуализации карты процессов, с предельными сроками и нормоконтролем. Закрепляет, что проект не считается закрытым до публикации обновлённых моделей.

Каков порядок публикации обновлённых моделей в корпоративном репозитории и актуализации карты (архитектуры) процессов по итогам внедрения?

Инструкция по заполнению:

опишите последовательность из 4–6 шагов от завершения внедрения до публикации модели «как внедрено» со сроками и ответственными (список или таблица). Порядок публикации моделей и внесения изменений в архитектуру процессов задан [Регламентом управления процессной архитектурой, №5]; настоящий раздел определяет только обязанность команды проекта инициировать публикацию и Change Request по №5, а также предельные сроки. Зафиксируйте: публикуемые модели выполняются строго в нотации BPMN 2.0.2; проект не считается закрытым до публикации обновлённых моделей и актуализации карты процессов.

Пример:

По итогам внедрения руководитель проекта в срок не позднее [10] рабочих дней после подтверждения перехода на целевой процесс должен: (1) привести модель TO-BE в соответствие фактически внедрённому состоянию («как внедрено»); (2) передать модель в процессный офис на нормоконтроль (соответствие стандартам моделирования по [№5, п. 7.2]); (3) при выявлении отклонений фактически внедрённого состояния от опубликованной при внедрении целевой модели инициировать Change Request на изменение архитектуры процессов в порядке, установленном НМД [№5] (при отсутствии отклонений повторный Change Request не требуется, действует модель, опубликованная к дате запуска по п. 12.4); (4) обеспечить публикацию утверждённой модели в корпоративном репозитории с одновременным переводом предыдущей версии в архив; (5) проконтролировать актуализацию карты (архитектуры) процессов и реестра процессов. Отметка о публикации вносится в итоговый отчёт проекта.

14.5. Внесение изменений в утверждённую целевую модель и план внедрения

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

Каков порядок внесения изменений в утверждённую целевую модель или план внедрения в ходе реализации проекта?

Инструкция по заполнению:

опишите процедуру управления изменениями уровня проекта: инициирование запроса на изменение, оценка влияния на сроки / бюджет / ожидаемый эффект, уровни утверждения в зависимости от существенности (2–3 категории изменений). Разграничьте контуры: изменения утверждённой целевой модели, затрагивающие архитектуру процессов, проводятся исключительно через Change Request по [НМД №5, п. 4.2]; изменения плана внедрения (сроки, ресурсы, состав мероприятий) проводятся по внутренней процедуре проекта, утверждаемой [Спонсором проекта] или [Процессным комитетом]. Если изменение затрагивает ожидаемый эффект, укажите обязательность повторной оценки по [НМД №34]. Приведите таблицу категорий изменений на 3 строки.

Пример:

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

14.6. Управление зависимостями и конфликтами параллельных проектов

Описание подраздела: Подраздел определяет механизм контроля зависимостей параллельных проектов через единый реестр и матрицу «проект × затрагиваемые процессы» с проверкой пересечений при инициации и каждом Change Request. Устанавливает правила разрешения конфликтов по приоритету категории процесса, запрет параллельного изменения одной модели и порядок эскалации в коллегиальный орган.

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

Инструкция по заполнению:

опишите механизм контроля зависимостей: ведение процессным офисом единого реестра проектов с матрицей «проект × затрагиваемые процессы», обязательную проверку пересечений при инициации и при каждом Change Request, а также правила разрешения конфликтов (3–4 правила: приоритет по категории A–E согласно [НМД №6], последовательность внесения изменений в общий процесс, запрет параллельного изменения одной модели). Укажите порядок эскалации неразрешённых конфликтов в [Процессный комитет] и формат матрицы зависимостей (таблица на 3–4 строки).

Пример:

При выявлении конфликта процессный офис должен в срок не позднее [5] рабочих дней организовать согласительное совещание руководителей затрагиваемых проектов и владельца процесса. Приоритет отдаётся проекту с более высокой категорией приоритета по [НМД №6]; при равенстве приоритетов и недостижении согласия решение принимает [Процессный комитет]. Одновременное внесение изменений в одну модель процесса двумя проектами не допускается: изменения вносятся последовательно, через единый Change Request по НМД [№5]. При инициации проекта и при каждом Change Request процессный офис проверяет затрагиваемые процессы также по реестру решений автоматизации/роботизации ([НМД №33]); при выявлении пересечения [CoE / Комитет по автоматизации] уведомляется до утверждения целевой модели.

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

15.1. Контроль соблюдения требований Регламента

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

Какова периодичность и процедура контроля соблюдения регламента и кто его проводит?

Инструкция по заполнению:

Определите 3-4 вида контроля соблюдения Регламента (текущий нормоконтроль, контроль на контрольных точках Gate, плановый аудит, выборочный контроль) и для каждого укажите периодичность, субъект контроля, предмет проверки и оформляемый результат. Оформите таблицей «Вид контроля / Периодичность / Кто проводит / Предмет контроля / Результат». Опишите процедуру: основание для проверки, срок её проведения, порядок фиксации и устранения выявленных несоответствий (план корректирующих действий со сроками и ответственными).

Пример:

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

По каждому выявленному несоответствию руководитель проекта в срок не более [5] рабочих дней представляет в процессный офис план корректирующих действий с указанием сроков и ответственных. Контроль устранения осуществляет процессный офис. При неустранении несоответствия в установленный срок вопрос выносится на ближайшее заседание [коллегиального органа]; предложение об остановке проекта рассматривается в порядке, установленном п. 6.6 настоящего Регламента и [НМД «Методика оценки экономической целесообразности»].

15.2. Отчётность процессного офиса о состоянии портфеля проектов изменений

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

Какова периодичность, формат и адресаты отчётности процессного офиса о состоянии портфеля проектов изменений?

Инструкция по заполнению:

Определите 3-4 вида отчётности процессного офиса (оперативный статус-отчёт, портфельный отчёт, годовой отчёт) с указанием периодичности, формата и адресатов. Оформите таблицей «Отчёт / Периодичность / Формат и состав / Адресаты». Укажите обязательный минимальный состав портфельного отчёта: статус проектов по стадиям жизненного цикла, соблюдение сроков и контрольных точек, данные Plan-Fact анализа достигнутых эффектов по [НМД «Методика оценки экономической целесообразности»], перечень эскалаций и рисков.

Пример:

Опишите порядок подготовки и представления отчётности (источники данных: [информационная система управления проектами / реестр проектов], сроки представления, ответственный за достоверность) и связь с отчётностью по смежным НМД: данные о подтверждении эффектов формируются по [НМД «Методика оценки экономической целесообразности»], данные о приоритетах формируются по [НМД «Методика приоритизации бизнес-процессов»]. Укажите 2-3 предложения.

Отчётность формируется процессным офисом на основании данных [реестра проектов изменений] и статус-отчётов руководителей проектов. Ответственность за достоверность данных по проекту несёт руководитель проекта, а за полноту и своевременность сводной отчётности отвечает [руководитель процессного офиса]. Показатели достигнутых эффектов включаются в отчётность в значениях, подтверждённых в порядке [НМД «Методика оценки экономической целесообразности»]. Отчётность о портфеле проектов изменений входит в систему отчётности процессного офиса, установленную [№2, разд. 12.1], и не образует параллельного контура отчётности.

15.3. Ответственность за нарушение требований Регламента

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

Какие меры ответственности применяются при нарушении требований регламента?

Инструкция по заполнению:

Установите принцип персональной ответственности участников проектов изменений в рамках их ролей (раздел [7] настоящего Регламента) и перечислите применяемые меры: дисциплинарная ответственность в соответствии с [Трудовым кодексом РФ] и локальными нормативными актами, учёт нарушений при оценке КПЭ и премировании, отстранение от роли в проекте. Оформите таблицей «Типовое нарушение / Мера реагирования / Кто применяет» на 4-5 строк. Меры должны быть соразмерны нарушению и применяться в установленном в организации порядке.

Пример:

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

Факт нарушения фиксируется процессным офисом в заключении по итогам контроля с уведомлением работника и его непосредственного руководителя. Дисциплинарные взыскания применяются в порядке, установленном [Трудовым кодексом РФ] и [Правилами внутреннего трудового распорядка]; настоящий Регламент самостоятельных видов взысканий не устанавливает. Учёт нарушений при оценке КПЭ осуществляется в соответствии с [Положением о премировании].

15.4. Вступление Регламента в силу и доведение требований до пользователей

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

Каков порядок вступления регламента в силу и доведения его требований до пользователей?

Инструкция по заполнению:

Опишите порядок введения Регламента в действие: утверждение [приказом генерального директора / решением уполномоченного органа], дата введения в действие, публикация в [СЭД / базе НМД организации], ознакомление целевой аудитории. Перечислите 4-5 мероприятий по доведению требований (публикация, рассылка, ознакомление под подпись ключевых ролей, вводное обучение, включение в программу адаптации) с ответственными и сроками в форме списка или таблицы. Отдельно установите переходные положения для проектов, начатых до вступления Регламента в силу.

Пример:

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

1. публикацией Регламента и приложений в [СЭД / базе НМД] ([ответственный: процессный офис]) в течение [3] рабочих дней с даты утверждения;

2. информационной рассылкой владельцам процессов и руководителям подразделений в течение [5] рабочих дней;

3. ознакомлением под подпись лиц, назначаемых на роли по разделу [7] Регламента, при назначении на роль;

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

5. включением обзора Регламента в программу адаптации [руководителей подразделений].

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

15.5. Срок действия, пересмотр и внесение изменений

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

Каков порядок пересмотра и внесения изменений в регламент и кто отвечает за поддержание его в актуальном состоянии?

Инструкция по заполнению:

Установите срок действия документа (до отмены или замены), периодичность планового пересмотра (для регламента не реже [1] раза в год) и 4-6 оснований внепланового пересмотра (изменение оргструктуры, изменение смежных НМД, результаты аудита, накопленные запросы на изменение). Назначьте владельца документа, ответственного за поддержание актуальности ([процессный офис]), и опишите процедуру внесения изменений: инициация, согласование, утверждение тем же порядком, что и первичное утверждение, фиксация в листе регистрации изменений. Оформите основания пересмотра списком, а процедуру 3-4 предложениями.

Пример:

Регламент действует до его отмены или замены новой версией. Плановый пересмотр проводится не реже [1] раза в год; по итогам пересмотра оформляется либо новая версия, либо заключение об отсутствии необходимости изменений. Основаниями внепланового пересмотра являются:

• изменение организационной структуры, состава [коллегиальных органов] или распределения полномочий;
• изменение смежных НМД: [НМД «Положение о процессном офисе»], [НМД «Регламент управления процессной архитектурой»], [НМД «Методика приоритизации бизнес-процессов»], [НМД «Регламент реализации проектов по автоматизации и роботизации бизнес-процессов», №33], [НМД «Методика оценки экономической целесообразности»];
• результаты аудитов и контроля соблюдения Регламента, свидетельствующие о неработоспособности отдельных процедур;
• накопление [3] и более согласованных запросов на изменение Регламента;
• изменения законодательства и стандартов, применённых в Регламенте.

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

15.6. Приложения: унифицированные формы и шаблоны

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

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

Инструкция по заполнению:

Приведите перечень приложений к Регламенту таблицей «Приложение / Наименование формы / Назначение и стадия применения / Кто заполняет». Не дублируйте формы, установленные смежными НМД: форма заявки на оптимизацию применяется по [НМД «Положение о процессном офисе»], формы расчёта и подтверждения эффекта применяются по [НМД «Методика оценки экономической целесообразности»]; для таких форм в таблице указывается ссылка на источник вместо собственного приложения. Нумеруйте приложения буквами (А, Б, В...).

Пример:

Сформулируйте 4-5 общих правил заполнения форм: обязательность всех полей формы (при неприменимости поля ставится отметка «не применимо» с обоснованием), запрет изменения структуры формы без изменения Регламента, ведение форм в [информационной системе / СЭД], требования к идентификации (номер проекта, версия документа, дата, подписи), место и срок хранения заполненных форм.

Все поля унифицированных форм подлежат заполнению; при неприменимости поля проставляется отметка «не применимо» с кратким обоснованием. Изменение структуры форм допускается только путём внесения изменений в настоящий Регламент в порядке п. 15.5. Формы ведутся в [информационной системе управления проектами / СЭД]; каждая заполненная форма должна содержать идентификатор проекта, версию, дату и сведения о подписавших лицах. Заполненные формы хранятся в [электронном архиве проекта] в течение [5] лет с даты закрытия проекта.

Приложение А. Глоссарий терминов и сокращений

Дополните каркас глоссария до 15–20 терминов, применяемых в настоящем Регламенте. При расхождении определений применяйте порядок приоритета источников по разделу 4: настоящий Регламент → глоссарии смежных НМД ([«Положение о процессном офисе», №2, Прил. 17], [«Методика оценки экономической целесообразности», №34, п. 1.4]) → ГОСТ Р ИСО 9000 → BPM CBOK 4.0. Собственные определения вводите только для терминов, отсутствующих в глоссариях смежных НМД.

Дополните таблицу сокращений с учётом раздела 4 настоящего Регламента (5–8 позиций).

Приложение Б. Паспорт проекта изменения

Паспорт оформляется Процессным офисом при решении о запуске проекта (Gate 0) на основе паспорта инициативы по [№34] и актуализируется при прохождении каждого гейта. Финансовая модель и расчёт эффекта в паспорт не включаются: в разделе 6 паспорта указываются только реквизиты бизнес-кейса, разработанного по [«Методика оценки экономической целесообразности», №34].

1. Реквизиты проекта

2. Классификация (по разделу 5)

3. Команда проекта

4. Вехи проекта (по разделу 6, в составе трека)

5. Базовые значения показателей процесса (фиксация по [№34, п. 3.1])

6. Ссылка на бизнес-кейс

Приложение В. Карта жизненного цикла проекта изменения

Применяйте карту как сводный справочник при планировании проекта: состав обязательных стадий, артефактов и гейтов определяется треком реализации (п. 5.4), сроки мониторинга эффекта установлены [№34, разд. 12] и в карте не переопределяются. Отметка «нет» означает, что стадия (гейт) для трека не обязательна либо объединяется со смежной.

Соответствие гейтов видам экономической оценки по [№34]: Gate 0 соответствует предварительной оценке (Gate 0 «Идея»); Gate 2 соответствует полной оценке и Go/No-Go (точка защиты бизнес-кейса, Gate 1 Stage-Gate по [№34]); Gate 3 соответствует пересчёту при изменении параметров ([№34, п. 12.1]); Gate 4 соответствует Plan-Fact анализу ([№34, разд. 12.2]); см. п. 6.3.

Чек-лист прохождения контрольной точки (Gate 0–4)

Чек-лист заполняется Руководителем проекта и проверяется Процессным офисом до передачи материалов в орган гейта; критерии для каждого гейта установлены п. 6.3, ниже приведён образец для Gate 2. Решение принимается только из закрытого перечня п. 6.3 и вносится в паспорт проекта (Приложение Б).

Приложение Г. Классификация проектов процессных изменений

Определите трек реализации по матрице: строка соответствует типу проекта (п. 5.1), столбец соответствует масштабу (п. 5.2); полученный трек уточняется по классу проекта A–D (по [№34]) в порядке п. 5.4 и может быть только повышен решением Процессного комитета, но не понижен. Для инициатив Quick Win (по [№6]) по умолчанию применяется упрощённый трек.

Правило уточнения по классу (п. 5.4): для проектов класса A (по [№34]) назначается расширенный трек независимо от матрицы; для класса B трек не может быть ниже стандартного; для классов C–D применяется значение матрицы.

Чек-лист отнесения инициативы к проекту процессного изменения (п. 5.3)

Заполняется Процессным офисом при первичной экспертизе инициативы. Инициатива признаётся проектом изменения при выполнении не менее [2] критериев; в остальных случаях улучшение реализуется владельцем процесса в цикле PDCA без применения настоящего Регламента.

Приложение Д. Матрица RACI проекта процессного изменения

Матрица детализирует распределение ответственности п. 7.4 до ключевых активностей стадий жизненного цикла. Для каждой активности назначается ровно один A (Accountable); допускаются комбинации A/R; при формировании конкретного проекта исключите активности, не входящие в назначенный трек (Приложение В). Обозначения ролей: Инициатор (Ини), Спонсор (Сп), Руководитель проекта (РП), Владелец процесса (ВП), Владелец выгод (ВВ), Процессный офис (ПО), Рабочая группа (РГ), Ответственный за внедрение (ОВ), Процессный комитет (ПК), владельцы смежных процессов (ВСП).

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

Распоряжение оформляется в течение [3] рабочих дней с даты протокола об одобрении инициативы (п. 7.3); участники рабочей группы включаются по согласованию с руководителями подразделений с фиксацией доли рабочего времени.

[ПОЛНОЕ НАИМЕНОВАНИЕ ОРГАНИЗАЦИИ]

РАСПОРЯЖЕНИЕ № [__] от «___» ________ 20__ г.

О назначении руководителя проекта и рабочей группы по проекту [наименование, ПИ-20__-№]

На основании протокола [Процессного комитета] № [__] от [дата] и в соответствии с п. 7.3 [настоящего Регламента]:

1. Назначить руководителем проекта [должность, И.О. Фамилия] с [дата].

2. Сформировать рабочую группу в составе согласно таблице.

3. Руководителям подразделений обеспечить участие работников в объёме указанной доли рабочего времени.

4. Контроль исполнения возложить на [должность, И.О. Фамилия].

[Должность руководителя] ____________ [И.О. Фамилия]

Приложение Е. Единый реестр инициатив и проектов

Реестр ведётся Процессным офисом в [СЭД / BPM-системе] по составу полей п. 8.4, актуализируется не реже [1] раза в месяц и представляется Процессному комитету в составе отчётности о портфеле. Статусная модель: зарегистрирована → на экспертизе → на приоритизации → одобрена к запуску / отклонена / отложена / объединена; после запуска проекта статус ведётся по стадиям раздела 6.

Форма заключения первичной экспертизы инициативы

Заключение готовится Процессным офисом в сроки по п. 8.4 (шаги 3–4) и является основанием для решения Процессного комитета. Рекомендация выбирается из закрытого перечня; повторная форма заявки не вводится: вход в экспертизу образует заявка по [№2, п. 9.3, Прил. 15] либо инициатива Процессного офиса (п. 8.2).

Приложение Ж. Аналитический комплект стадии анализа (AS-IS)

Заполните комплект по итогам стадии анализа текущего состояния процесса. Комплект состоит из трёх форм: отчёт об анализе (Ж.1), реестр проблем, потерь и узких мест (Ж.2) и форма фиксации базовых значений показателей процесса (Ж.3). Комплект является обязательным входом для Gate стадии анализа и для разработки целевой модели (Приложение З). Оценка влияния изменения на смежные модели архитектуры (Impact Analysis) выполняется по форме Приложения В НМД «Регламент управления процессной архитектурой» [№5] и в настоящий комплект не дублируется.

Форма Ж.1. Отчёт об анализе текущего состояния процесса (AS-IS)

Заполните реквизитную часть и все разделы отчёта. Объём аналитической части составляет 3–7 страниц; выводы формулируйте так, чтобы каждая выявленная проблема была прослеживаема до записи в реестре Ж.2. Модель процесса AS-IS прикладывается отдельным файлом; для кандидатов на автоматизацию и публикуемых моделей строго в нотации BPMN 2.0.2 [№5, №33].

Структура отчёта:

Пример заполнения раздела 7 «Выводы и гипотезы улучшений»:

Форма Ж.2. Реестр проблем, потерь и узких мест процесса AS-IS

Внесите в реестр каждую выявленную проблему, потерю или узкое место отдельной строкой с указанием корневой причины и денежной либо натуральной оценкой потерь. Присваивайте идентификаторы вида П-01, П-02... Приоритет определяйте по влиянию на показатели процесса и цели проекта; реестр служит основой карты соответствия AS-IS/TO-BE (форма З.2).

Пример заполнения:

Форма Ж.3. Фиксация базовых значений показателей процесса

Зафиксируйте базовые значения показателей процесса до начала изменений в порядке, установленном разделом 3.1 НМД «Методика оценки экономической целесообразности» [№34]. Включите 3–7 показателей, по которым будет подтверждаться эффект; для каждого укажите метод и период измерения, без этого Plan-Fact анализ по [№34] невозможен. Период измерения составляет не менее [12] месяцев или полный бизнес-цикл ([№34, п. 3.1]); для выборочных методов (хронометраж, опрос) обеспечьте репрезентативность выборки с учётом сезонности, сокращение периода допускается только с обоснованием по п. 9.3. Зафиксированные значения не подлежат изменению после прохождения Gate стадии анализа; форма финансовой модели не дублируется: применяется шаблон [№34].

Пример заполнения:

Приложение З. Комплект целевой модели (TO-BE)

Заполните комплект по итогам стадии проектирования целевого состояния. Комплект состоит из паспорта целевой модели (З.1), карты соответствия операций AS-IS/TO-BE (З.2) и плана перехода (З.3). Утверждение целевой модели как изменения архитектуры бизнес-процессов оформляется запросом на изменение (Change Request) по НМД [№5] (раздел 4.2, форма CR приведена в [№5]); настоящий комплект описывает целевую модель как результат проекта и форму CR не заменяет и не дублирует.

Форма З.1. Паспорт целевой модели (TO-BE)

Заполните все поля паспорта. Целевые значения показателей указывайте в паре с базовыми значениями из формы Ж.3; не вводите новые показатели, отсутствующие в фиксации. Если целевая модель предполагает автоматизацию, укажите это в поле «Требования к автоматизации»: передача в контур автоматизации выполняется заявкой по НМД [№33] (раздел 5.2) с приложением моделей AS-IS/TO-BE.

Форма З.2. Карта соответствия операций AS-IS / TO-BE

Сопоставьте каждую операцию текущей модели с целевым состоянием. Используйте типы изменения: «без изменений», «изменена», «объединена», «исключена», «новая», «автоматизирована». Каждая строка с изменением должна ссылаться на запись реестра Ж.2 или на цель проекта; изменения «без обоснования» не допускаются. Карта используется для оценки влияния на исполнителей и формирования плана обучения (форма К.2).

Пример заполнения:

Форма З.3. План перехода к целевой модели (roadmap)

Разбейте переход от AS-IS к TO-BE на 3–6 этапов с измеримыми результатами. Для каждого этапа укажите связь с контрольными точками (gates) проекта; последовательность внедрения быстрых улучшений (Quick Win) определяется приоритетами по НМД [№6]. План перехода детализируется в план внедрения (форма К.1) после согласования комплекта.

Пример заполнения:

Приложение И. Комплект согласования

Используйте комплект на стадии согласования пакета проектных документов. Комплект состоит из листа согласования пакета (И.1), протокола согласительной сессии (И.2) и протокола разногласий (И.3). Согласование выполняется в порядке, установленном разделом 11 настоящего Регламента и НМД [№2] (раздел 9.4); изменения архитектуры процессов утверждаются через Change Request по НМД [№5]; форма CR настоящим комплектом не дублируется.

Форма И.1. Лист согласования пакета проектных документов

Перечислите состав пакета и всех согласующих. Состав согласующих определяется по затронутым процессам и подразделениям (владельцы затрагиваемых процессов включаются обязательно). Результат согласования: «согласовано», «согласовано с замечаниями» (замечания приводятся в приложении к листу) или «не согласовано» (разногласия вносятся в форму И.3). Срок согласования каждым согласующим составляет не более [5] рабочих дней.

Состав пакета проектных документов:

Согласующие лица:

Форма И.2. Протокол согласительной сессии

Оформляйте протокол по каждой согласительной сессии, проводимой при наличии замечаний или разногласий. По каждому вопросу фиксируйте принятое решение и ответственного за исполнение. Неурегулированные разногласия переносите в протокол разногласий (И.3) с эскалацией в порядке раздела [7] (п. 7.6) настоящего Регламента.

Рассмотренные вопросы и решения:

Пример заполнения:

Подписи: Председатель: [И.О. Фамилия] ______ Секретарь: [И.О. Фамилия] ______

Форма И.3. Протокол разногласий

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

Пример заполнения:

Приложение К. Комплект внедрения

Используйте комплект на стадии внедрения изменения. Комплект состоит из плана внедрения (К.1), плана коммуникаций и обучения (К.2), чек-листа готовности к запуску (К.3) и акта о завершении внедрения (К.4). Запуск целевого процесса допускается только при положительном заключении по чек-листу К.3, зафиксированном решением коллегиального органа проекта.

Форма К.1. План внедрения изменения

Детализируйте утверждённый план перехода (форма З.3) до конкретных мероприятий с ответственными и критериями выполнения. Включите мероприятия по актуализации НМД, настройке систем, изменению полномочий и контролю первых результатов. Изменения содержания или сроков проекта в ходе внедрения оформляются в порядке управления изменениями проекта; изменения моделей архитектуры оформляются через Change Request по [№5].

Пример заполнения:

Форма К.2. План коммуникаций и обучения

Определите для каждой целевой аудитории (по карте З.2 это все роли с изменяемыми обязанностями) содержание коммуникации, формат и признак выполнения. Обучение планируйте до даты запуска; охват исполнителей изменяемых операций составляет 100%. Коммуникации о ходе проекта в адрес органов управления ведутся в порядке отчётности по разделу [11] настоящего Регламента.

Пример заполнения:

Форма К.3. Чек-лист готовности к запуску

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

Решение о запуске: [запуск разрешён / запуск разрешён с условиями / запуск отложен]; решение [наименование коллегиального органа], протокол № [N] от [дата].

Форма К.4. Акт о завершении внедрения

Оформите акт по факту выполнения плана внедрения и стабилизации целевого процесса. В акте зафиксируйте фактические результаты относительно критериев плана К.1 и первые фактические значения показателей. Акт является основанием для перехода к стадии мониторинга и не подтверждает достижение экономического эффекта: эффект подтверждается Plan-Fact анализом по [№34] на контрольных точках мониторинга.

Результаты внедрения:

Открытые вопросы, передаваемые на стадию мониторинга: [перечень либо «отсутствуют»].

Подписи:

Приложение Л. Комплект мониторинга и закрытия

Используйте комплект на стадии мониторинга результатов и закрытия проекта. Комплект состоит из плана мониторинга показателей (Л.1), акта передачи процесса в операционное управление (Л.2), итогового отчёта по проекту (Л.3) и реестра извлечённых уроков (Л.4). Методика подтверждения эффекта, форма Plan-Fact анализа и порядок решений по отклонениям не дублируются: применяется НМД «Методика оценки экономической целесообразности» [№34] (раздел 12).

Форма Л.1. План мониторинга показателей процесса после внедрения

Составьте план до запуска целевого процесса. Мониторинг ведётся по показателям, зафиксированным в форме Ж.3, на контрольных точках 3, 6 и 12 месяцев после внедрения (для проектов классов A–B дополнительно 24 месяца) в соответствии с [№34, раздел 12; точка 24 мес. установлена разд. 12.2]. Фактические значения и отклонения оформляются Plan-Fact анализом по форме [№34]; в настоящей форме планируются только состав показателей, ответственные и сроки измерений.

Пример заполнения:

Форма Л.2. Акт передачи процесса в операционное управление

Оформите акт после подтверждения стабилизации процесса (п. 13.4), как правило до закрытия проекта и не позднее первой контрольной точки мониторинга эффекта по [№34]. С даты подписания акта ответственность за результаты и показатели процесса несёт владелец процесса; проектная команда освобождается от сопровождения, за исключением обязательств по плану мониторинга Л.1.

Состав передаваемых элементов:

Особые условия и оговорки: [перечень либо «отсутствуют»].

Подписи: Передал: [И.О. Фамилия] ______ [дата] Принял: [И.О. Фамилия] ______ [дата] Согласовано (руководитель процессного офиса): [И.О. Фамилия] ______ [дата]

Форма Л.3. Итоговый отчёт по проекту

Подготовьте отчёт к закрытию проекта. Отчёт обобщает результаты всех стадий; подтверждение экономического эффекта приводится ссылкой на результаты Plan-Fact анализа по [№34]; расчёты в отчёте не дублируются. По итогам закрытия инициируйте пересмотр приоритета процесса в реестре приоритизации в порядке НМД [№6] (раздел 9).

Сводные результаты проекта:

Выводы и решение о закрытии: [выводы; решение: закрыть / закрыть с условиями; поручение о пересмотре приоритета процесса по [№6, раздел 9]].

Форма Л.4. Реестр извлечённых уроков

Заполните реестр на итоговой ретроспективе проекта с участием ключевых членов команды. Включите 5–15 уроков, как негативных, так и позитивных (что стоит повторять). Формулируйте урок как проверяемую рекомендацию, применимую в будущих проектах; реестр передаётся в процессный офис для учёта при планировании следующих проектов и актуализации настоящего Регламента.

Пример заполнения:

Приложение М. Реестр рисков проекта процессного изменения

Заполните реестр рисков на стадии анализа, до Gate 1 настоящего Регламента (п. 9.5); риски включаются в финансовую модель бизнес-кейса в порядке [№34, разд. 9.4]. Актуализируйте реестр не реже одного раза в [месяц / отчётный период]. Для каждого риска укажите категорию по классификатору М.1, оцените вероятность и влияние по шкале 1–5, назначьте владельца риска. Риски категории «Эффект» не пересчитывайте: используйте данные бизнес-кейса по №34; риски, требующие решения выше уровня руководителя проекта, эскалируйте по карточке Приложения П (П.3).

М.1. Классификатор категорий рисков

М.2. Форма реестра рисков

Стратегии реагирования: снижение означает мероприятия по уменьшению вероятности/влияния; принятие означает контроль по триггеру без превентивных мер (ранг ≤ [6]); передача означает перенос последствий на третью сторону или смежный контур; уклонение означает изменение плана внедрения (через запрос по форме Н.2). Риск с рангом ≥ [15] подлежит эскалации в течение [2] рабочих дней.

Пример заполнения:

Приложение Н. Комплект управления конфигурацией проекта процессного изменения

Комплект применяется руководителем проекта для управления составом и версиями проектных документов. Версии моделей процессов, Change Request на модели и публикация в репозитории регулируются НМД «Регламент управления процессной архитектурой» (№5); настоящий комплект охватывает ТОЛЬКО проектные документы и план внедрения. Заполните реестр Н.1 при инициации и актуализируйте на каждом гейте; форму Н.2 используйте при любом изменении утверждённого плана внедрения; матрицу Н.3 ведёт процессный офис по всем активным проектам портфеля.

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

Перечислите все управляемые документы проекта. Не создавайте локальных копий форм смежных НМД, указывайте ссылку на источник формы. Стадии синхронизированы с гейтами Gate 0–4 настоящего Регламента (соответствие видам экономической оценки по №34 приведено в п. 6.3).

Пример заполнения:

Н.2. Форма запроса на изменение плана внедрения

Форма применяется к утверждённому плану внедрения и иным проектным документам. Запрос на изменение моделей процессов и архитектуры оформляется отдельно, как Change Request по №5 (п. 4.2); переоценка эффекта при существенном изменении выполняется по правилам №34. Решение по запросу принимает [Процессный комитет / Спонсор проекта]; единоличное решение процессного офиса не допускается.

Н.3. Матрица зависимостей и пересечений параллельных проектов

Матрицу ведёт процессный офис по всем активным проектам изменений портфеля, актуализация выполняется при запуске/закрытии проекта и при каждом одобренном запросе Н.2. В ячейке пересечения укажите код связи; для связей типа Д и П синхронизация вех обязательна, конфликт типа Р разрешается по приоритетам категорий A–E (№6).

Коды связей: Д: зависимость, при которой результат одного проекта является входом другого; П: пересечение по одному процессу/подразделению; Р: конфликт за общий ресурс (команда, бюджет, эксперты); А: общая ИТ-система / смежная заявка на автоматизацию (координация с контуром №33); нет: связь отсутствует.

Пример заполнения:

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