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

Структура по ГОСТ Р 7.0.97-2025 обеспечивает юридическую силу и статус обязательного документа.

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

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

Обязательные элементы по ГОСТ: наименование организации с ОПФ, гриф утверждения (должность, подпись, дата), полное название документа, версия (X.Y), дата введения. Внизу: город и год разработки.

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

С какими должностными лицами согласовывается Регламент?

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

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

Генерируется автоматически в Word (Ссылки → Оглавление). После заполнения обновите: ПКМ → Обновить поле → Обновить целиком.

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

Как организован учет изменений?

Таблица: Версия (X.Y.Z), Дата, Раздел, Содержание изменения, Основание (приказ/протокол), Утвердил (должность, ФИО), Подпись. Пересмотр: не реже раза в год или при существенных изменениях.

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

На кого распространяется Регламент?

Укажите территориальный охват (головная/вся группа/международные подразделения), целевые роли (архитекторы, владельцы L0-L3, ПО, HR, руководители), уровни архитектуры (L0-L2 обязательно, L3-L4 опционально).

• Организационный охват: вся группа / головная организация / конкретные дивизионы
• Целевые роли: главный архитектор, архитекторы процессов, владельцы L0-L3, методологи ПО, HR-специалисты
• Уровни архитектуры: L0-L2 обязательно для всех / L3-L4 для критичных процессов

Какие процессы охватывает Регламент?

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

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

На какие документы ссылается Регламент?

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

Внешние документы:

• ГОСТ Р 7.0.97-2025 - Организационно-распорядительная документация
• ISO 9001:2015 (раздел 4.4), ГОСТ Р 54869-2011 - Процессный подход
• BPM CBOK v4 - Process Architecture, Process Governance
• BABOK v3 - Enterprise Architecture, Organization Modeling
• Профстандарт "Специалист по процессному управлению" (трудовая функция B/02.6)

Внутренние документы (укажите №№ и даты):

• Политика по внедрению процессного подхода (приказ №___ от __.__.____)
• Положение о процессном офисе (приказ №___ от __.__.____)
• Положение о владельцах процессов
• Организационная структура компании (актуальная)
• Стратегия развития компании на период [указать]

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

Какие сокращения применяются?

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

• БП - бизнес-процесс
• ПА - процессная архитектура
• ОС - организационная структура
• ВП - владелец процесса
• ПО - процессный офис
• BPM - Business Process Management
• BPMN 2.0.2 - стандарт моделирования процессов
• KPI - ключевой показатель эффективности
• RACI - Responsible, Accountable, Consulted, Informed
• HRIS - кадровая информационная система

Какие термины требуют определения?

Определите ключевые термины четко и однозначно для исключения разночтений.

• Процессная архитектура - структурированная модель всех процессов с иерархией и зависимостями
• Уровни архитектуры - L0 (области), L1 (группы), L2 (процессы), L3 (процедуры), L4 (операции)
• Декомпозиция - разбиение процесса высокого уровня на составные процессы нижнего уровня
• Владелец процесса - должностное лицо с ресурсами и полномочиями, ответственное за результаты
• Архитектор процессов - специалист ПО по разработке, поддержке и развитию архитектуры
• Baseline - утвержденная базовая версия архитектуры, точка отсчета для изменений
• Change Request - формализованная заявка на изменение элемента архитектуры
• Impact Analysis - анализ влияния изменений на смежные элементы архитектуры и оргструктуру

2.1. Назначение и цель

Какова цель Регламента?

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

Какие задачи решает?

Перечислите 5-7 конкретных задач, показывающих практическую ценность.

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

2.2. Статус документа

Какой статус имеет Регламент?

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

2.3. Решаемые проблемы

Какие проблемы решает Регламент?

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

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

2.4. Связь с другими документами

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

Покажите иерархию: Политика (стратегия) → Регламент (операции) → методики. Обеспечьте непротиворечивость.

• Политика по внедрению процессного подхода
• Положение о процессном офисе
• Данный Регламент
• Положение о владельцах
• Методология BPMN
• Политика по внедрению процессного подхода
• Методология процессного управления
• Положение об организационной структуре
• Устав организации
• ISO 9001 (при использовании)
• BPM CBOK (при использовании)

3.1. Принципы построения процессной архитектуры

На каких принципах строится процессная архитектура организации?

Сформулируйте 7-10 ключевых принципов:

• Ориентация на создание ценности для клиента (внешнего и внутреннего)
• Сквозное управление процессами (end-to-end) независимо от границ подразделений
• Иерархическая декомпозиция от высокого уровня к детальному
• Полнота охвата всех видов деятельности организации
• Отсутствие дублирования и пересечений процессов на одном уровне
• Согласованность со стратегическими целями организации
• Гибкость и возможность эволюции архитектуры
• Применимость единых стандартов и нотаций

3.2. Структура архитектуры

Какова структура архитектуры?

Опишите иерархию: L0 (области) → L1 (группы) → L2 (процессы) → L3 (процедуры) → L4 (операции). Укажите обязательные (обычно L0-L2) и опциональные уровни.

• L0 - Домен - верхний уровень группировки по функциям (5-10 областей)
• L1 - Группа процессов - сквозные end-to-end и кросс-функциональные бизнес-процессы (обычно 30-60 процессов)
• L2 - Процессы - детальные последовательности действий
• L3 - Процедуры - совокупность элементарные
• х действий (опционально для критичных)

Какие представления используются?

Определите форматы визуализации для разных целей и аудиторий.

• Иерархическое представление - дерево процессов с уровнями декомпозиции
• Группы процессов - графическое представление вложенности процессов
• Value Chains - сквозные процессы от клиента до клиента
• Матричное - таблица процессы vs подразделения с ролями
• Взаимосвязи - диаграммы потоков входов/выходов между процессами

3.3. Классификация

Как классифицируются процессы?

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

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

Дополнительные классификации?

Укажите дополнительные разрезы для управления и приоритизации.

• По критичности: критичные / важные / стандартные
• По зрелости: 1-5 уровень (по модели зрелости организации)
• По охвату: сквозные / межфункциональные / функциональные
• По регулированию: регулируемые (законодательством) / нерегулируемые
• По автоматизации: автоматизированные / полуавтоматизированные / ручные
• По регламентации: детально регламентированные / частично / творческие

3.4. Декомпозиция

Какие правила декомпозиции?

Критерии качества: полнота (части = целому), непересечение, управляемость (3-9 элементов), однородность, функциональная связность.

• Полнота - декомпозированные части полностью покрывают родительский процесс
• Непересечение - процессы не дублируют друг друга
• Управляемость - 3-9 элементов на уровне (правило 7±2)
• Однородность - сопоставимая детализация элементов уровня
• Функциональная связность - объединение по единой цели

Когда применяется агрегирование?

Объединение при: избыточной детализации, единый владелец, реорганизация, стандартизация типовых процессов.

• Упрощение при избыточной фрагментации архитектуры
• Объединение процессов с единым владельцем
• Консолидация после реорганизации и слияния
• Стандартизация типовых однородных процессов

3.4. Именование и кодирование

Система именования?

Стандарт: [Глагол] + [Объект] + [Контекст], длина 3-7 слов, уникальность. Язык: русский/английский/двуязычие.

• Формат: [Глагол] + [Объект] + [Контекст] - "Управление закупками сырья"
• Длина: оптимально 3-7 слов
• Язык: русский / английский / двуязычие (указать для вашей организации)
• Уникальность: каждое название однозначно идентифицирует процесс

Система кодов?

Иерархическая: L0=XX (буквы), L1=XX.YY, L2=XX.YY.ZZ. Укажите ответственного за реестр, правила резервирования. Коды стабильны - не меняются и не переиспользуются.

• L0: XX - две буквы (СЛ-Продажи, ПР-Производство, ФН-Финансы)
• L1: XX.YY - область + номер (СЛ.01, СЛ.02)
• L2: XX.YY.ZZ - процесс + процесс более низкого уровня (СЛ.01.03)
• L3-L4: продолжение по аналогии через точку

3.5. Атрибуты процессов

Обязательные атрибуты?

Минимальный набор для каждого процесса: код, название, уровень, классификация, владелец, цель, входы/выходы, клиенты/поставщики, KPI (3-5), риски, IT-системы, регламенты, статус, версия.

• Код и название процесса - уникальный идентификатор и наименование
• Уровень (L0-L4) и классификация (основной/обеспечивающий/управленческий)
• Владелец процесса - ФИО, должность, подразделение
• Цель, входы, выходы - целевой результат, инициация, продукты
• Клиенты и поставщики - потребители результатов и источники входов
• KPI процесса - 3-5 ключевых показателей с целевыми значениями
• Риски - основные риски с мерами контроля
• IT-системы, регламенты, статус, версия

Опциональные атрибуты?

Дополнительно: зрелость (CMMI 1-5), автоматизация (%), связь со стратегией, комплаенс, бюджет.

• Уровень зрелости по CMMI (1-5) для приоритизации развития
• Степень автоматизации (%) для планирования цифровизации
• Связь со стратегическими целями и их вес
• Требования комплаенс (SOX, GDPR, отраслевые)
• Бюджет процесса (операционные затраты и инвестиции)
• Скорость процесса

3.6. Карта процессов организации

Как выглядит и поддерживается карта процессов?

Опишите:

• Формат карты процессов (графическая схема / древовидная структура / матрица)
• Инструменты создания и хранения (BPM-система / Visio / специализированное ПО)
• Версионность и актуализация карты
• Доступность для сотрудников (корпоративный портал / BPM-система)
• Визуальные стандарты (цветовое кодирование, нотация)

3.7. Реестр процессов

Как ведется реестр процессов организации?

Опишите структуру реестра:

• Обязательные атрибуты процесса: ID, название, тип, владелец, версия, статус, дата актуализации
• Дополнительные атрибуты: цель, границы, входы/выходы, KPI, риски, уровень зрелости, степень автоматизации
• Инструмент ведения реестра (Excel / база данных / BPM-система)
• Ответственный за ведение реестра (процессный офис)
• Периодичность актуализации (ежеквартально / по мере изменений)

4.1. Типы изменений процессной архитектуры

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

Классифицируйте изменения по масштабу и сложности:

4.1.1. Минорные изменения (Minor Changes)

Определите критерии и примеры:

• Критерии: актуализация названий, незначительные уточнения границ, добавление метаданных
• Не требуют согласования архитектурного комитета
• Утверждаются руководителем процессного офиса
• Срок внесения: 5 рабочих дней

4.1.2. Мажорные изменения (Major Changes)

Определите критерии и примеры:

• Критерии: добавление нового процесса L1-L2, изменение классификации, изменение границ процесса, смена владельца
• Требуют согласования на архитектурном комитете
• Утверждаются процессным комитетом
• Срок внесения: 20 рабочих дней

4.1.3. Архитектурные трансформации (Architecture Transformations)

Определите критерии и примеры:

• Критерии: пересмотр всей процессной архитектуры или значительной части (>20% процессов), изменение принципов построения архитектуры
• Инициируются стратегическими изменениями (M&A, смена бизнес-модели, цифровая трансформация)
• Реализуются как отдельный проект с планом и бюджетом
• Утверждаются генеральным директором или советом директоров
• Срок реализации: от 3 месяцев до 1 года

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

4.2.1 Инициирование изменений

Какие триггеры инициируют изменения?

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

• Стратегические изменения - новая стратегия, изменение бизнес-модели, выход на новые рынки
• Организационные изменения - реорганизация, слияния/поглощения, открытие филиалов
• Результаты оптимизации - выявленные улучшения по итогам проектов
• Внедрение IT-систем - автоматизация, цифровая трансформация, RPA/AI
• Изменения законодательства - новые регуляторные требования
• Аудиты и проверки - выявленные несоответствия
• Инициативы улучшения - предложения от владельцев, сотрудников, клиентов

Кто инициирует изменения?

Определите роли с правом инициирования. Форма: Change Request (Приложение Б) с указанием инициатора, описания, обоснования, предварительной оценки влияния.

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

Какая форма заявки используется?

Используется стандартизированная форма Change Request Form (детальный шаблон в Приложении Б). Обязательные разделы: идентификация, описание AS-IS/TO-BE, обоснование, предварительная оценка влияния.

• Раздел 1: Идентификация - номер заявки, дата, инициатор (ФИО, должность, контакты)
• Раздел 2: Описание - затрагиваемые процессы (коды), текущее состояние, предлагаемое изменение
• Раздел 3: Обоснование - бизнес-причины, выгоды, связь со стратегией
• Раздел 4: Предварительная оценка - смежные процессы, влияние на структуру/IT, сложность
• Раздел 5: Согласование - визы владельца процесса и архитектора

4.2.2. Анализ влияния (Impact Analysis)

Кто проводит анализ влияния?

ПО (архитектор процессов) с привлечением владельцев смежных процессов и HR. Срок проведения: [указать количество] рабочих дней с момента поступления заявки.

• Ответственный: архитектор процессов из процессного офиса
• Участники: владельцы смежных процессов, специалисты HR, при необходимости - IT
• Срок: [5-10] рабочих дней в зависимости от сложности изменения

Какие аспекты анализируются?

Используется форма Impact Analysis Template (Приложение В). Анализируются все аспекты: влияние на процессы, структуру, владельцев, IT, документы, KPI, риски, ресурсы. Масштаб: низкое/среднее/высокое.

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

Как оценивается масштаб влияния?

Градация по масштабу определяет дальнейший маршрут согласования и уровень утверждения.

• Низкое влияние - локальные изменения в пределах одного процесса/подразделения
• Среднее влияние - изменения затрагивают несколько процессов/подразделений
• Высокое влияние - системные изменения архитектуры в целом или оргструктуры

4.2.3. Согласование изменений

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

Маршруты дифференцируются по масштабу влияния (определенному в п.4.2). Для каждого уровня: состав согласующих, сроки, утверждающая инстанция.

• Низкое влияние: владелец процесса → руководитель ПО (утверждает). Срок: [3-5] дней
• Среднее влияние: владелец → смежные владельцы → ПО → HR → функциональный директор (утверждает). Срок: [7-10] дней
• Высокое влияние: полный маршрут среднего + ИТ-директор + финансовый директор → Архитектурный комитет → генеральный директор (утверждает). Срок: [15-20] дней

Какие критерии применяются при согласовании?

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

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

4.2.4. Утверждение изменений

Кто принимает окончательное решение об утверждении?

Утверждающая инстанция определяется масштабом влияния (см. п.4.3). Решение фиксируется в: приказе/распоряжении, протоколе Архитектурного комитета, системе управления изменениями.

• Низкое влияние - утверждает руководитель процессного офиса
• Среднее влияние - утверждает функциональный директор (курирующий процессную область)
• Высокое влияние - утверждает генеральный директор или правление после рассмотрения комитетом

Как документируется решение об утверждении?

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

• Приказ/распоряжение - для изменений высокого влияния с формулировкой решения
• Протокол Архитектурного комитета (Приложение З) - фиксация обсуждения и голосования
• Система управления изменениями (BPM-система/Jira) - обновление статуса заявки
• Лист согласования с визами - хранится с материалами Change Request

4.2.5. Внедрение и коммуникация изменений

Как организуется внедрение утвержденных изменений?

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

• Разработка плана внедрения - этапы, сроки, ответственные, контрольные точки
• Актуализация карты процессов - внесение изменений в BPM-систему
• Обновление атрибутов процессов - паспорта, регламенты, KPI
• Синхронизация с оргструктурой - изменения в HRIS, штатном расписании (при необходимости)
• Коммуникация изменений - информирование всех заинтересованных сторон
• Обучение затронутых сотрудников - при необходимости проведение тренингов
• Контроль внедрения - мониторинг выполнения плана и достижения целей

Какие каналы используются для коммуникации изменений?

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

• Корпоративный портал - публикация актуализированной версии архитектуры
• Email-рассылка - уведомление ключевых стейкхолдеров с кратким описанием
• Совещания владельцев процессов - обсуждение влияния изменений
• Обучающие сессии - при значительных изменениях для затронутых сотрудников
• Система управления знаниями - обновление справочных материалов

4.2.5. Контроль и мониторинг

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

Укажите механизм:

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

4.3. Версионность архитектуры

Как управляются версии процессной архитектуры?

Система версионирования обеспечивает отслеживание истории изменений и возможность отката при необходимости.

• Формат версии: X.Y.Z - где X=мажорная (значительные изменения), Y=минорная (добавление/изменение), Z=патч (корректировки)
• Дата версии - дата утверждения изменений
• Описание изменений - краткое резюме что изменилось в версии
• Хранение версий - в BPM-системе с возможностью просмотра истории

Как обеспечивается целостность версий?

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

• Запрет прямого редактирования действующей версии - только через Change Request
• Автоматическое создание новой версии при утверждении изменений
• Архивирование предыдущих версий с сохранением доступа на чтение
• Логирование всех изменений с указанием автора, даты и обоснования

5.1. Анализ соответствия процессов и структуры

Как проверяется соответствие архитектуры и оргструктуры?

Методика анализа выявляет рассогласования для своевременного устранения.

• Построение матрицы процессы vs подразделения - визуализация ответственности
• Проверка наличия владельцев - все процессы должны иметь назначенных владельцев
• Анализ дублирования - выявление процессов, выполняемых несколькими подразделениями
• Выявление разрывов - процессы без ответственных или подразделения без процессов
• Оценка загрузки - соответствие объема процессов ресурсам подразделений

Как часто проводится анализ соответствия?

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

• Плановый анализ - [указать периодичность: ежеквартально/раз в полгода/ежегодно]
• Внеплановый анализ - при реорганизации, значительных изменениях в архитектуре
• Ответственный за проведение - процессный офис совместно с HR-службой

5.2. Приведение оргструктуры в соответствие

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

Алгоритм действий для устранения рассогласований.

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

Кто принимает решение о направлении изменений?

Решение принимается коллегиально на основе объективных критериев.

• Архитектурный комитет принимает решение о векторе изменений
• Критерии: стратегическая целесообразность, операционная эффективность, масштаб, затраты, риски

5.3. Матрица ответственности RACI

Как определяется ответственность на уровне архитектуры?

Матрица RACI (Приложение Г) обеспечивает четкое распределение ролей.

• R (Responsible) - исполнитель, выполняющий работу процесса
• A (Accountable) - владелец процесса, несущий конечную ответственность (только один)
• C (Consulted) - консультанты, с которыми согласовываются решения
• I (Informed) - информируемые о ходе и результатах процесса

Как матрица RACI связана с оргструктурой?

Роли привязываются к конкретным должностям и подразделениям.

• Каждая роль RACI привязана к должности/подразделению в оргструктуре
• Владелец процесса (A) - обязательно руководитель соответствующего уровня
• Исполнители (R) - сотрудники подразделений по штатному расписанию
• При изменении структуры автоматически пересматривается RACI

5.4. Назначение владельцев процессов

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

Алгоритм обеспечивает непрерывность управления процессами.

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

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

Критерии выбора обеспечивают эффективное управление процессом.

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

5.5. Процедура при реорганизации

Какие действия при слиянии подразделений?

Алгоритм при консолидации структурных единиц.

• Инвентаризация процессов - выявление всех процессов обоих подразделений
• Анализ дублирования - поиск идентичных/похожих процессов
• Унификация процессов - выбор лучшей практики или разработка нового
• Назначение единого владельца - руководитель объединенного подразделения
• Актуализация архитектуры - объединение/упрощение процессной модели
• Гармонизация регламентов - единые стандарты выполнения

Какие действия при разделении подразделений?

Алгоритм при декомпозиции структурных единиц.

• Распределение процессов - определение, какие процессы за каким подразделением
• Декомпозиция сквозных процессов - разбиение на процессы при необходимости
• Назначение владельцев - отдельные для каждого нового подразделения
• Определение интерфейсов - правила взаимодействия между разделенными процессами
• Актуализация архитектуры - детализация процессной модели
• Разработка SLA - соглашения об уровне обслуживания между подразделениями

5.6. Разрешение конфликтов при матричном управлении

Как разрешаются конфликты ответственности?

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

• Приоритизация задач - четкое определение приоритетов (процессные vs функциональные)
• Четкая матрица RACI - прозрачное распределение ответственности
• Регламент эскалации - процедура разрешения спорных ситуаций
• Совместное планирование - координация загрузки ресурсов

Какой механизм эскалации применяется?

Уровни эскалации для разрешения конфликтов.

• Уровень 1: Диалог владелец процесса - функциональный руководитель
• Уровень 2: Руководитель процессного офиса
• Уровень 3: Функциональный директор верхнего уровня
• Уровень 4: Архитектурный комитет
• Уровень 5: Генеральный директор / правление (финальная инстанция)

5.7. Анализ процессной нагрузки подразделений

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

Опишите механизм:

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

6.1. Матрица ролей в управлении архитектурой

Какие роли участвуют в управлении архитектурой?

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

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

6.2. Права и обязанности ролей

Каковы права и обязанности архитектора процессов?

Определение полномочий и ответственности ключевой роли.

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

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

Роль, несущая операционную ответственность за процесс.

• Обязанности: управление процессом, достижение KPI, инициирование улучшений, актуализация описаний
• Права: распоряжение ресурсами процесса, изменение регламентов (согласованно), участие в комитете

6.3. Процедура назначения ответственных

Как происходит назначение на роли?

Формализованная процедура обеспечивает прозрачность.

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

6.4. Механизм эскалации решений

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

Уровни эскалации с указанием сроков рассмотрения на каждом уровне.

• L1: Владелец процесса / Архитектор процессов - 2-3 рабочих дня
• L2: Руководитель процессного офиса - 3-5 рабочих дней
• L3: Функциональный директор - 5-7 рабочих дней
• L4: Архитектурный комитет - до следующего заседания
• L5: Генеральный директор - финальная инстанция

6.5. Архитектурный комитет

Какова роль и полномочия комитета?

Коллегиальный орган для принятия ключевых решений.

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

Каков состав комитета?

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

• Председатель: [укажите должность - обычно СЕО или COO]
• Секретарь: руководитель процессного офиса (ведет протоколы)
• Члены: функциональные директора, главные владельцы процессных областей, HR-директор, ИТ-директор

Как организована работа архитектурного комитета?

Определите:

• Регулярные заседания: [ежеквартально / раз в полгода]
• Внеочередные: по необходимости при критичных изменениях
• Протокол заседания: оформляется по шаблону (Приложение З)
• Подготовка повестки: за 5 рабочих дней до заседания секретарем
• Кворум: не менее 50% членов комитета \+ председатель
• Принятие решений: консенсус или простое большинство голосов
• Протоколирование: протокол заседания в течение 3 дней
• Хранение протоколов: в BPM-системе / SharePoint

6.6. Процессный комитет

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

Опишите функции в контексте архитектуры (основное описание процессного комитета - в Положении о ПО):

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

7.1. Требования к карте процессной архитектуры

Какие требования к карте?

Стандарты оформления для единообразия и понятности.

• Форматы: BPMN 2.0.2 для детальных схем, схемы Visio/Draw.io для верхнеуровневых
• Уровни детализации: L0-L2 обязательно для всех процессов
• Визуальное кодирование: цвета по типам (основные-синий, обеспечивающие-зеленый, управленческие-желтый)
• Актуальность: обновление в течение [X] дней после утверждения изменений

Где хранится и публикуется карта?

Централизованное хранение и доступность для пользователей.

• Основное хранилище: BPM-система с контролем версий
• Публикация: корпоративный портал в разделе процессного управления
• Пример структуры: см. Приложение Е (карта 3 уровней)

7.2. Стандарты моделирования процессов

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

Основной стандарт и дополнительные нотации по необходимости.

• Основной: BPMN 2.0.2 для моделирования бизнес-процессов
• Дополнительно: Value Chain или SIPOC для стратегического уровня
• RACI-диаграммы: для визуализации ответственности

7.3. Репозиторий процессной архитектуры

Где и как хранится процессная архитектура?

Требования к централизованному хранилищу.

• BPM-система как единый источник истины (Single Source of Truth)
• Контроль версий с историей всех изменений
• Разграничение доступа по ролям (просмотр/редактирование)
• Функции поиска и фильтрации по атрибутам
• Экспорт в различные форматы (PDF, Visio, Excel)
• Интеграция с HRIS для синхронизации владельцев и структуры

Как организовано резервное копирование?

Обеспечение сохранности данных архитектуры.

• Периодичность: [ежедневно / еженедельно] автоматическое резервирование
• Хранение резервных копий: [срок] в защищенном хранилище
• Процедура восстановления: [указать ответственного и регламент]

7.4. Схемы взаимосвязей процессов и структуры

Как оформляются взаимосвязи?

Типы схем для визуализации зависимостей.

• Диаграммы входов-выходов между процессами (потоки)
• Матрицы процессы vs подразделения (таблица ответственности)
• Схемы зависимостей процессов (граф взаимосвязей)
• Карты интерфейсов между процессами (точки передачи)

7.5. Шаблоны паспортов процессов

Аналог Карточка процесса в stormbpmn.com

Какая информация содержится в паспорте процесса?

Стандартизированная структура паспорта (шаблон в Приложении Ж).

• Раздел 1: Идентификация - код, название, уровень, классификация, версия
• Раздел 2: Ответственность - владелец с привязкой к должности, участвующие подразделения, RACI
• Раздел 3: Описание - цель, триггеры запуска, входы/выходы, клиенты/поставщики
• Раздел 4: Показатели - таблица KPI с целевыми значениями, таблица рисков с митигацией
• Раздел 5: Ресурсы - используемые IT-системы, бюджет, численность (FTE)
• Раздел 6: Документация - регламенты, инструкции, шаблоны, ссылка на BPMN-модель

8.1. KPI качества архитектуры

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

Ключевые метрики с целевыми значениями.

• Полнота архитектуры = (Количество процессов с описанием) / (Общее количество процессов) × 100%. Цель: 100% для ключевых процессов
• Актуальность архитектуры = (Количество процессов, актуализированных за период) / (Общее количество процессов) × 100%. Цель: 100% в год
• Покрытие владельцами = (Процессы с назначенными владельцами) / (Общее количество ключевых процессов) × 100%. Цель: 100%
• Среднее время обработки заявки на изменение (дни). Цель: минорные ≤5 дней, мажорные ≤20 дней
• Количество конфликтов по границам процессов за период. Цель: тренд на снижение
• Непротиворечивость - количество выявленных конфликтов (цель <5%)
• Детализация - соответствие требуемым уровням L0-L2

8.2. Процедура регулярного аудита

Как проводится аудит архитектуры?

Периодическая проверка качества и соответствия.

• Периодичность: [ежегодно / раз в полгода]
• Ответственный: процессный офис или служба внутреннего аудита
• Инструмент: чек-лист аудита (Приложение Д) по всем аспектам
• Результат: отчет с выявленными несоответствиями и планом устранения

8.3. Gap Analysis (анализ разрывов)

Как выявляются и устраняются разрывы?

Методология сравнения текущего и целевого состояния.

• Определение AS-IS - текущее состояние архитектуры
• Определение TO-BE - целевое состояние архитектуры
• Идентификация GAP - разрывы между AS-IS и TO-BE
• Приоритизация разрывов - по критичности и ресурсам
• План устранения - конкретные действия с ответственными и сроками
• Контроль устранения - мониторинг выполнения плана

8.4. Отчетность по состоянию архитектуры

Какая отчетность ведется?

Регулярная отчетность для разных уровней управления.

• Ежемесячная: KPI качества архитектуры, количество и статус изменений
• Ежеквартальная: состояние архитектуры, выявленные разрывы, планы развития
• Ежегодная: результаты аудита, достижение целей, стратегические рекомендации

Кому предоставляется отчетность?

Целевые аудитории отчетов.

• Руководитель процессного офиса - вся детальная отчетность
• Топ-менеджмент - ежеквартальные и годовые отчеты
• Архитектурный комитет - материалы к заседаниям

8.5. Плановый пересмотр архитектуры

Как часто пересматривается архитектура?

Регулярность обеспечивает актуальность.

• Полный пересмотр: [ежегодно / раз в 2 года] - оценка всей архитектуры
• Частичный пересмотр: ежеквартально - анализ изменений за период
• Инициатор: процессный офис с привлечением владельцев

Какие критерии инициируют пересмотр?

Триггеры для внепланового пересмотра.

• Изменение стратегии компании
• Накопление значительного количества изменений
• Критичные результаты аудита
• Кардинальное изменение бизнес-модели

8.6. Процедура создания нового процесса в архитектуре

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

Опишите пошаговую процедуру:

• Шаг 1: Инициатор обосновывает необходимость нового процесса (обоснование: новый вид деятельности / выделение из существующего процесса)
• Шаг 2: Процессный офис проверяет, нет ли дублирования с существующими процессами
• Шаг 3: Определяется уровень нового процесса (L1/L2/L3), место в иерархии, классификация
• Шаг 4: Назначается кандидат на роль владельца процесса
• Шаг 5: Согласование на архитектурном комитете (для L1) или утверждение руководителем ПО (для L2-L3)
• Шаг 6: Внесение процесса в реестр и карту процессов
• Шаг 7: Формальное назначение владельца процесса (приказ/распоряжение)
• Шаг 8: Планирование описания и документирования процесса

8.7. Процедура изменения границ процесса

Как изменяются границы существующего процесса?

Опишите:

• Шаг 1: Инициатор (обычно владелец процесса) подает заявку с обоснованием изменения границ
• Шаг 2: ПО анализирует влияние на смежные процессы, выявляет всех затронутых владельцев
• Шаг 3: Согласование со всеми затронутыми владельцами процессов
• Шаг 4: При наличии конфликта - вынесение на архитектурный комитет для медиации
• Шаг 5: Утверждение изменения (АК для мажорных, руководитель ПО для минорных)
• Шаг 6: Актуализация реестра, карты процессов, RACI-матриц, регламентов

8.8. Процедура ликвидации (архивации) процесса

Как выводится процесс из архитектуры?

Опишите:

• Основания: прекращение вида деятельности, слияние с другим процессом, аутсорсинг
• Процедура согласования: владелец процесса → архитектурный комитет → процессный комитет
• Действия при ликвидации: перевод статуса процесса в "Архивный", сохранение в истории реестра, удаление с текущей карты процессов
• Архивация документации процесса на срок не менее 5 лет

8.9. Процедура назначения / смены владельца процесса

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

Опишите:

• Основания для смены: изменение оргструктуры, уход сотрудника, реорганизация процесса
• Требования к владельцу: уровень должности не ниже [указать], наличие полномочий и ресурсов для управления процессом
• Процедура назначения: предложение процессного офиса / HR → согласование с кандидатом → утверждение процессным комитетом → издание приказа
• Передача ответственности: проведение встречи нового и прежнего владельцев, передача документации, актуализация реестра
• Срок: смена владельца должна быть завершена в течение 30 дней с момента инициирования

8.10. Процедура ежегодной актуализации архитектуры

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

Опишите годовой цикл:

• Сроки: ежегодно в Q4 (октябрь-ноябрь)
• Инициатор: процессный офис
• Шаг 1: ПО рассылает запрос всем владельцам процессов на подтверждение актуальности (чек-лист: границы, RACI, KPI, документация)
• Шаг 2: Владельцы в течение 10 дней отвечают с подтверждением или с заявками на изменения
• Шаг 3: ПО обрабатывает заявки по стандартной процедуре изменений
• Шаг 4: Подготовка сводного отчета о состоянии архитектуры для процессного комитета
• Шаг 5: Утверждение актуализированной версии архитектуры на процессном комитете
• Шаг 6: Публикация новой версии (смена мажорной/минорной версии)

9.1. Baseline архитектуры

Что такое baseline и как он актуализируется?

Утвержденная базовая версия как точка отсчета.

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

9.2. Правила управления версиями

Как организовано версионирование?

Система управления версиями обеспечивает прослеживаемость.

• Формат: X.Y.Z (X-мажорная, Y-минорная, Z-патч)
• Автоматическое создание при утверждении изменений
• Фиксация даты, автора, описания изменений
• Связь с номером Change Request

9.3. Процедура отката изменений (Rollback)

Когда применяется откат?

Ситуации, требующие возврата к предыдущей версии.

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

Как выполняется откат?

Процедура восстановления предыдущей версии.

• Фиксация проблемы и принятие решения об откате
• Восстановление предыдущей версии из архива
• Уведомление всех заинтересованных сторон
• Анализ причин и корректирующие действия

9.4. Управление зависимостями между элементами

Как управляются зависимости в архитектуре?

Виды зависимостей и методы управления.

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

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

Механизмы проверки и поддержания связей.

• Автоматические проверки в BPM-системе при изменениях
• Анализ влияния (Impact Analysis) перед изменениями
• Регулярные аудиты корректности связей

9.5. Процесс миграции между версиями

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

Поэтапный процесс минимизирует риски.

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

10.1. Каскадирование стратегических целей

Как цели транслируются на архитектуру?

Методика связи стратегии с процессами.

• Анализ стратегических целей компании
• Определение критичных процессов для достижения целей
• Установление связи цель-процесс с весовыми коэффициентами
• Декомпозиция на KPI процессов нижних уровней
• Назначение ответственных владельцев за достижение
• Мониторинг вклада процессов в стратегические цели

10.2. Методика анализа вклада процессов

Как оценивается вклад процессов в цели?

Количественная и качественная оценка значимости.

• Определение связи KPI процесса с целями компании
• Оценка веса процесса для достижения каждой цели
• Анализ текущей эффективности процесса
• Расчет интегрального вклада процесса
• Ранжирование процессов по стратегической значимости

10.3. Приоритизация изменений по стратегической значимости

Как приоритизируются изменения в архитектуре?

Критерии для определения приоритетов инициатив.

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

Какая матрица используется для приоритизации?

Визуальный инструмент для принятия решений.

• Матрица: стратегическая ценность (ось Y) vs сложность внедрения (ось X)
• Приоритет 1: высокая ценность + низкая сложность (Quick Wins)
• Приоритет 2: высокая ценность + высокая сложность (Стратегические проекты)
• Приоритет 3: низкая ценность + низкая сложность (Возможности)
• Приоритет 4: низкая ценность + высокая сложность (Отложить/отменить)

10.4. Связь архитектуры с Balanced Scorecard

Как архитектура интегрирована с BSC?

Связь по четырем перспективам BSC.

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

Как каскадируются KPI?

Иерархия целей от стратегии до операций.

• Уровень 1: Цели BSC организации
• Уровень 2: KPI процессных областей (L0)
• Уровень 3: KPI процессов (L1-L2)
• Уровень 4: KPI процессов низкого уровня и исполнителей
• Прозрачная связь обеспечивает вклад каждого в стратегию

11.1. Отражение автоматизированных процессов

Как отражаются автоматизированные процессы в архитектуре?

Атрибуты для учета цифровизации.

• Степень автоматизации - процент автоматизированных операций
• Используемые IT-системы - перечень с назначением
• Автоматизированные этапы - отметки на схемах процессов
• Роботизированные операции (RPA) - боты с функциями
• AI/ML компоненты - алгоритмы и модели

11.2. Процедура при внедрении новых IT-систем

Что происходит при внедрении систем?

Обязательная актуализация архитектуры.

• ИТ-департамент информирует ПО о планируемом проекте
• Анализ влияния на процессы - какие процессы затронуты
• Актуализация архитектуры - добавление систем в атрибуты
• Пересмотр степени автоматизации процессов
• Обновление паспортов и схем процессов
• Обучение владельцев процессов работе с системой

11.3. Связь процессной и прикладной архитектуры

Как связаны процессная и IT-архитектура?

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

• Процессная архитектура → формирует требования к IT
• Прикладная архитектура → обеспечивает поддержку процессов
• Единая модель: процесс - приложение - данные
• Синхронизация изменений в обеих архитектурах

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

Координация между процессным офисом и ИТ.

• Архитектор процессов + Архитектор приложений работают совместно
• Решения согласовываются на Архитектурном комитете
• Совместное планирование проектов автоматизации

11.4. Процедура при RPA и AI внедрениях

Как отражаются RPA/AI проекты?

Специфика роботизации и искусственного интеллекта.

• Идентификация кандидатов для автоматизации - анализ процессов
• Оценка целесообразности - расчет ROI
• Разработка TO-BE процесса с роботами/AI
• Актуализация архитектуры - отражение новых возможностей
• Внедрение и мониторинг эффективности
• Корректировка при необходимости

11.5. Интеграция BPM-системы и HRIS

Какие требования к интеграции систем?

Двусторонняя синхронизация данных.

• BPM → HRIS: информация о владельцах процессов, роли RACI
• HRIS → BPM: структура подразделений, должности, сотрудники
• Автоматическое обновление при изменениях в любой системе
• Контроль целостности данных - выявление расхождений

Какова периодичность синхронизации?

Частота обновления данных между системами.

• Автоматическая синхронизация: [ежедневно / в реальном времени]
• Ручная сверка и контроль: [ежемесячно / ежеквартально]
• Ответственный: администратор BPM-системы совместно с HR

12. ОБУЧЕНИЕ И РАЗВИТИЕ КОМПЕТЕНЦИЙ

12.1. Программы обучения по ролям

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

Дифференцированное обучение по целевым аудиториям.

• Архитекторы процессов - углубленный курс: BPM CBOK, BPMN 2.0.2, методы анализа, инструменты
• Владельцы процессов - основы процессного управления, работа с архитектурой, KPI, улучшения
• Топ-менеджмент - стратегия процессного управления, роль архитектуры, принятие решений
• HR-специалисты - синхронизация процессов и структуры, назначение владельцев
• Сотрудники - базовая процессная грамотность, понимание своего места в процессах

12.2. Процедура онбординга владельцев процессов

Как вводятся в должность новые владельцы?

Программа адаптации для новых владельцев.

• Ознакомление с Регламентом и Положением о владельцах
• Изучение процессной архитектуры организации
• Детальное знакомство с подотчетными процессами
• Предоставление доступа к BPM-системе и обучение работе
• Закрепление наставника из опытных владельцев
• Контрольная точка через [1-3 месяца] для оценки адаптации

12.3. Базы знаний и справочные материалы

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

Централизованное хранилище знаний.

• Регламенты и методологии процессного управления
• Шаблоны документов (Change Request, Impact Analysis, паспорта)
• Примеры лучших практик и успешных кейсов
• FAQ по процессному управлению и работе с архитектурой
• Видеоуроки и записи вебинаров
• Библиотека кейсов и сценариев изменений

Где размещены материалы?

Доступность знаний для всех пользователей.

• Корпоративный портал - раздел "Процессное управление"
• BPM-система - встроенная справка и руководства
• Ответственный за актуализацию: процессный офис

12.4. Развитие компетенций архитекторов процессов

Как развиваются архитекторы?

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

• Сертификация: BPM CBOK, CBPP (Certified Business Process Professional)
• Участие в профессиональных конференциях и форумах
• Обмен опытом с архитекторами других компаний
• Внутренние мастер-классы и воркшопы
• Самообучение по новым методологиям и инструментам

Как оценивается уровень компетенций?

Система оценки и планирования развития.

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

# ПРИЛОЖЕНИЯ

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

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

Агрегирование - объединение процессов нижнего уровня в процесс верхнего

Baseline - утвержденная базовая версия, точка отсчета

End-to-end процесс - сквозной процесс от начала до конца

Gap Analysis - анализ разрывов между AS-IS и TO-BE

Impact Analysis - анализ влияния изменений

Rollback - откат изменений к предыдущей версии

Value Chain - цепочка создания ценности

Дополните специфичными терминами вашей организации.

Приложение Б. Change Request Form

Стандартная форма заявки на изменение архитектуры.

1. Идентификация заявки:

Номер заявки (автоматически), дата подачи, инициатор (ФИО, должность, подразделение, контакты)

2. Описание изменения:

Затрагиваемые элементы (коды процессов), текущее состояние AS-IS, предлагаемое изменение TO-BE, тип изменения

3. Обоснование:

Бизнес-причины, ожидаемые выгоды, связь со стратегией

4. Предварительная оценка:

Смежные процессы, влияние на структуру/IT, ориентировочная сложность

5. Согласование: подписи владельца и архитектора

Приложение В. Impact Analysis Template

Детальная форма анализа влияния изменений.

Структура формы:

1) Идентификация - номер CR, аналитик, дата

2) Анализ влияния на процессы - прямое, косвенное, матрица

3) Влияние на оргструктуру - владельцы, штат, функции

4) Влияние на IT - системы, трудоемкость

5) Влияние на документацию - регламенты, обучение

6) Риски - описание рисков и меры митигации

7) Ресурсы - трудозатраты, бюджет, сроки

8) Заключение - масштаб влияния (низкий/средний/высокий), рекомендация

Приложение Г. Матрица RACI

Таблица распределения ответственности: Действие | Архитектор | Владелец | ПО | HR | Топ-менеджмент

Примеры строк матрицы:

Разработка архитектуры: R=Архитектор, A=ПО, C=Владельцы, I=HR, I=Топ-менеджмент

Инициирование изменений: R=Владелец, A=Владелец, C=Архитектор, I=ПО

Анализ влияния: R=Архитектор, A=ПО, C=Владельцы+HR, I=Топ-менеджмент

Утверждение изменений: R=ПО, A=Топ-менеджмент, C=Архитектор, I=Все

Актуализация карты: R=Архитектор, A=ПО, C=Владелец, I=Все

Дополните всеми ключевыми действиями из разделов Регламента.

Приложение Д. Чек-лист аудита

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

Блок 1: Полнота архитектуры

☐ Все процессы представлены, L0-L2 описаны, нет пробелов

Блок 2: Актуальность

☐ Обновления в последний период, нет устаревших, версии актуальны

Блок 3: Владельцы

☐ Все назначены, достаточные полномочия, RACI заполнена

Блок 4: Стандарты

☐ Именование, BPMN 2.0.2, шаблоны соблюдены

Блок 5: Синхронизация с оргструктурой

☐ Нет разрывов, нет дублирования, интеграция работает

Блок 6: Документация

☐ Карта актуальна, паспорта заполнены, регламенты соответствуют

Блок 7: Управление изменениями

☐ Через CR, версионность корректна, история зафиксирована

Приложение Е. Пример карты архитектуры

Визуальное представление 3 уровней архитектуры.

L0 - Домены:

СТР - Стратегическое управление, СЛ - Продажи, ПР - Производство, ЛГ - Логистика, ФН - Финансы, ПС - Персонал, ИТ - IT

L1 - Группы процессов (пример для СЛ):

СЛ.01 Управление клиентской базой, СЛ.02 Маркетинг, СЛ.03 Продажи B2B, СЛ.04 B2C, СЛ.05 CRM

L2 - Процессы (пример для СЛ.03):

СЛ.03.01 Лидогенерация, .02 Квалификация, .03 КП, .04 Переговоры, .05 Договор

Вставьте фактическую схему вашей организации.

Приложение Ж. Паспорт процесса

Стандартизированная структура паспорта:

РАЗДЕЛ 1: Идентификация

Код, название, уровень, классификация, версия, дата

РАЗДЕЛ 2: Ответственность и оргструктура

Владелец (ФИО, должность, подразделение), участвующие подразделения, RACI

РАЗДЕЛ 3: Описание

Цель, триггеры, входы, выходы, клиенты, поставщики

РАЗДЕЛ 4: Показатели

Таблица KPI (показатель-формула-цель-ответственный), таблица рисков

РАЗДЕЛ 5: Ресурсы

IT-системы, бюджет, численность (FTE)

РАЗДЕЛ 6: Документация

Регламенты, инструкции, шаблоны, ссылка на BPMN

Приложение З. Протокол Архитектурного комитета

Шаблон протокола заседания:

Протокол №___ от [дата], время, место

Председатель, секретарь, присутствовали (список)

ПОВЕСТКА ДНЯ: пункты с нумерацией

РЕШЕНИЯ по каждому пункту: обсуждение, принятое решение

ПОСТАНОВИЛИ: формулировка, ответственные, сроки

Голосование: ЗА/ПРОТИВ/ВОЗДЕРЖАЛИСЬ

Подписи: председатель, секретарь, члены комитета

Приложение И. Сценарии изменений (кейсы)

Примеры типовых ситуаций:

КЕЙС 1: Внедрение CRM

Триггер: решение о внедрении, Затрагивает: СЛ.01/03/05, Действия: паспорта+атрибуты+автоматизация, Согласование: среднее

КЕЙС 2: Слияние отделов продаж

Триггер: приказ о реорганизации, Действия: инвентаризация→унификация→владелец→архитектура, Согласование: высокое, комитет

КЕЙС 3: Оптимизация закупок

Триггер: результаты анализа, Действия: CR→упрощение→регламент, Согласование: среднее

Дополните кейсами вашей организации.

Приложение К. Регистр рисков

Типовые риски управления архитектурой:

1) Устаревание архитектуры

Вероятность: средняя, Влияние: высокое, Митигация: аудиты, напоминания, KPI актуальности

2) Рассогласование процессов и структуры

Средняя/высокое, Митигация: интеграция BPM-HRIS, процедура при реорганизации

3) Отсутствие commitment владельцев

Средняя/среднее, Митигация: KPI в оценке, поддержка топ-менеджмента

4) Избыточная бюрократия

Средняя/среднее, Митигация: дифференциация маршрутов, автоматизация

5) Несоответствие стандартам

Низкая/среднее, Митигация: обучение, автопроверки, аудиты

Дополните специфичными рисками вашей организации.

КОНЕЦ ШАБЛОНА

После заполнения всех разделов:

• Замените все вопросы (синий курсив) на конкретные ответы для вашей организации
• Удалите все инструкции (серый курсив)
• Заполните или разработайте все приложения
• Обновите оглавление через MS Word (Ссылки → Обновить оглавление)
• Согласуйте с ключевыми стейкхолдерами: владельцы TOP-процессов, финансы, HR, риски
• Проведите пилотное применение на нескольких процессах, соберите feedback
• Доработайте методику на основе результатов пилота
• Утвердите на процессном комитете / правлении с протоколированием решения
• Проведите обучение всех участников (координатор 8ч, эксперты 3ч, владельцы 4ч)