ОБЩИЕ ПОЛОЖЕНИЯ
Описание раздела: Раздел определяет цели, область применения, основные термины и принципы автоматизации и роботизации бизнес-процессов в организации. Устанавливает связь регламента со стратегическими документами и нормативную базу его разработки.
1.1. Цели и задачи регламента
Описание подраздела: Подраздел определяет целевое назначение регламента и его связь со стратегическими инициативами организации в области цифровой трансформации.
Каковы цели внедрения регламента и его связь со стратегией цифровой трансформации организации?
Инструкция по заполнению:
Сформулируйте 3-5 целей внедрения регламента и опишите связь с программой цифровой трансформации. Укажите ожидаемые бизнес-эффекты (сокращение трудозатрат, повышение качества, снижение операционных рисков). Приведите ссылки на стратегические документы организации.
Пример:
Цели внедрения регламента:
- Стандартизация подходов — установление единых правил и процедур автоматизации и роботизации бизнес-процессов во всех подразделениях организации
- Повышение операционной эффективности — сокращение трудозатрат на рутинные операции на 30-40% за счёт внедрения программных роботов
- Снижение операционных рисков — минимизация человеческих ошибок при выполнении типовых операций с высокой степенью повторяемости
- Обеспечение масштабируемости — создание методологической базы для тиражирования успешных решений по автоматизации
- Поддержка цифровой трансформации — реализация инициатив Программы цифровой трансформации на 2024-2027 гг. (утв. приказом № 125 от 15.03.2024)
Связь со стратегией: Регламент разработан в рамках реализации Стратегического направления 3 «Операционная эффективность» Стратегии развития организации до 2030 года и обеспечивает достижение целевого показателя «Доля автоматизированных процессов — не менее 45%».
1.2. Область применения
Описание подраздела: Подраздел определяет границы действия регламента: охватываемые подразделения, категории процессов и уровни процессной архитектуры.
На какие подразделения, категории бизнес-процессов и уровни процессной архитектуры распространяется действие регламента, а какие являются исключениями?
Инструкция по заполнению:
Перечислите подразделения, на которые распространяется регламент. Укажите категории процессов (основные, обеспечивающие, управленческие, развитие) и уровни архитектуры (L0-L4). Определите явные исключения с обоснованием. Приведите таблицу с классификацией области применения.
Пример:
Область применения регламента:
| Критерий | Включено в область применения | Исключения |
|---|---|---|
| Подразделения | Все структурные подразделения центрального аппарата и филиалов | Подразделения, работающие с гостайной |
| Категории процессов | Основные, обеспечивающие, управленческие | Процессы физического производства |
| Уровни архитектуры | L2 (группы процессов), L3 (процессы), L4 (подпроцессы) | L0-L1 (стратегический уровень) |
| Типы автоматизации | RPA, IPA, BPMS, low-code/no-code платформы | ERP/CRM системы (отдельный регламент) |
Обоснование исключений: Процессы, связанные с обработкой сведений, составляющих государственную тайну, регулируются специальным порядком в соответствии с Законом РФ «О государственной тайне».
1.3. Термины и определения
Описание подраздела: Подраздел закрепляет понятийный аппарат, используемый в регламенте, для обеспечения однозначного толкования терминов всеми участниками процесса.
Какие термины и определения закрепляются в регламенте (RPA, BPMS, программный робот, цифровой сотрудник, оркестратор, low-code/no-code, IPA)?
Инструкция по заполнению:
Приведите глоссарий из 15-20 ключевых терминов с определениями. Используйте официальные источники (ISO, ГОСТ, BPM CBOK) где возможно. Структурируйте термины в алфавитном порядке или тематических группах. Укажите источник определения.
Пример:
| Термин | Определение | Источник |
|---|---|---|
| BPMS (Business Process Management System) | Программная платформа для моделирования, исполнения, мониторинга и оптимизации бизнес-процессов | BPM CBOK v4 |
| DES (Discrete Event Simulation) | Дискретно-событийное моделирование, метод имитационного моделирования, который представляет систему как последовательность мгновенных событий, происходящих в определенные моменты времени, и анализирует изменение состояния системы между этими событиями | |
| IPA (Intelligent Process Automation) | Интеллектуальная автоматизация процессов, объединяющая RPA с технологиями искусственного интеллекта и машинного обучения | — |
| Low-code/No-code платформа | Среда разработки приложений с минимальным использованием программного кода или без него | — |
| RPA (Robotic Process Automation) | Технология автоматизации бизнес-процессов с использованием программных роботов, имитирующих действия человека в пользовательских интерфейсах | IEEE 2755-2017 |
| Оркестратор | Центральный компонент RPA-платформы для управления, планирования и мониторинга работы программных роботов | — |
| Программный робот (бот) | Программное обеспечение, выполняющее заданную последовательность действий в информационных системах по заранее определённым правилам | — |
| Цифровой сотрудник | Программный робот, которому присвоена учётная запись, организационная роль и набор полномочий в информационных системах организации | — |
| FTE (Full-Time Equivalent) | Единица измерения трудозатрат, эквивалентная полной занятости одного сотрудника | — |
1.4. Нормативные основания
Описание подраздела: Подраздел определяет внешние и внутренние документы, на основании которых разработан регламент и которыми руководствуются участники процесса.
Какие внешние и внутренние нормативные документы являются основанием для разработки регламента?
Инструкция по заполнению:
Укажите 5-8 внешних нормативных документов (законы, стандарты, отраслевые требования) и 5-8 внутренних документов (политики, положения, регламенты). Приведите полные реквизиты документов. Разделите на категории: обязательные к применению и рекомендательные.
Пример:
Внешние нормативные документы (обязательные):
- Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»
- Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»
- ГОСТ Р ИСО 9001-2015 «Системы менеджмента качества. Требования»
- ГОСТ Р 7.0.97-2025 «Унифицированная система организационно-распорядительной документации»
Внешние нормативные документы (рекомендательные):
- BPM CBOK v4 — Свод знаний по управлению бизнес-процессами
- IEEE 2755-2017 — Guide for Terms and Concepts in Intelligent Process Automation
Внутренние нормативные документы:
- Стратегия развития организации до 2030 года (утв. Советом директоров, протокол № 5 от 20.12.2023)
- Политика в области цифровой трансформации (ПЛТ-001-2024)
- Положение о процессном управлении (ПЛЖ-015-2023)
- Политика информационной безопасности (ПЛТ-003-2023)
1.5. Принципы автоматизации и роботизации
Описание подраздела: Подраздел формулирует базовые принципы, которыми руководствуется организация при принятии решений об автоматизации и роботизации бизнес-процессов.
Какие принципы автоматизации и роботизации принимаются в организации?
Инструкция по заполнению:
Сформулируйте 6-8 принципов автоматизации с кратким пояснением каждого (2-3 предложения). Принципы должны отражать стратегические приоритеты организации: экономическая целесообразность, безопасность, масштабируемость, человекоцентричность. Приведите примеры применения принципов.
Пример:
| № | Принцип | Описание | Пример применения |
|---|---|---|---|
| 1 | Экономическая обоснованность | Каждая инициатива по автоматизации должна иметь положительное экономическое обоснование со сроком окупаемости не более 18 месяцев | Отклонение проекта с ROI менее 20% |
| 2 | Приоритет стандартизации | Автоматизации подлежат только стандартизированные процессы с формализованными правилами выполнения | Обязательная оптимизация процесса перед роботизацией |
| 3 | Безопасность by design | Требования информационной безопасности учитываются на этапе проектирования, а не после разработки | Обязательное согласование ТЗ с ИБ-службой |
| 4 | Масштабируемость решений | Архитектура решений должна обеспечивать возможность тиражирования и увеличения нагрузки | Использование переиспользуемых компонентов |
| 5 | Человек в контуре управления | Критические решения и исключения обрабатываются сотрудниками, робот выполняет рутинные операции | Эскалация нетиповых случаев оператору |
| 6 | Прозрачность и аудируемость | Все действия роботов логируются и доступны для анализа и аудита | Хранение логов не менее 3 лет |
ОРГАНИЗАЦИОННАЯ СТРУКТУРА И РАСПРЕДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ
Описание раздела: Раздел определяет участников процесса автоматизации и роботизации, их роли, полномочия и ответственность. Устанавливает принципы взаимодействия между подразделениями и порядок эскалации.
2.1. Матрица ролей и ответственности
Описание подраздела: Подраздел определяет все роли, участвующие в процессе автоматизации, их функции и зоны ответственности на каждом этапе жизненного цикла.
Какова матрица ролей и зон ответственности участников процесса автоматизации (владелец процесса, бизнес-заказчик, процессный офис, CoE RPA, ИТ, разработчик, архитектор, администратор)?
Инструкция по заполнению:
Составьте матрицу RACI для 8-10 ключевых ролей по этапам жизненного цикла автоматизации. Приведите описание каждой роли (2-3 предложения) и требования к компетенциям. Укажите организационную принадлежность каждой роли.
Пример:
Описание ролей:
| Роль | Описание | Подразделение | Требования к компетенциям |
|---|---|---|---|
| Владелец процесса | Руководитель, несущий ответственность за результаты бизнес-процесса и принимающий решение о его автоматизации | Бизнес-подразделение | Знание процесса, навыки управления изменениями |
| Бизнес-заказчик | Представитель подразделения, формирующий требования к автоматизации и принимающий результат | Бизнес-подразделение | Экспертиза в предметной области |
| Процессный офис | Методологическое сопровождение, контроль соответствия стандартам, ведение реестра автоматизации | Процессный офис | BPM CBOK, методологии моделирования |
| CoE RPA | Центр компетенций по RPA: экспертиза, разработка, поддержка решений | ИТ / CoE RPA | RPA-платформы, программирование |
| ИТ-архитектор | Проектирование архитектуры решений, интеграционные требования | ИТ-департамент | Enterprise Architecture, интеграции |
| Разработчик RPA | Разработка и тестирование программных роботов | CoE RPA | UiPath/Automation Anywhere/etc. |
| Администратор RPA | Управление инфраструктурой, оркестратором, мониторинг | ИТ-эксплуатация | Администрирование, мониторинг |
| Служба ИБ | Согласование требований безопасности, аудит решений | Служба ИБ | Информационная безопасность |
Матрица RACI:
| Этап | Владелец процесса | Бизнес-заказчик | Процессный офис | CoE RPA | ИТ-архитектор | Разработчик | Администратор | Служба ИБ |
|---|---|---|---|---|---|---|---|---|
| Инициация | A | R | C | C | I | I | I | I |
| Оценка и приоритизация | A | R | R | C | C | I | I | C |
| Анализ AS-IS | A | R | R | C | C | I | I | I |
| Проектирование TO-BE | A | C | R | R | R | C | I | C |
| Разработка | I | C | C | A | C | R | I | C |
| Тестирование | I | R | C | A | C | R | C | C |
| Внедрение | A | R | C | R | C | R | R | C |
| Эксплуатация | A | I | C | C | I | C | R | C |
A — Accountable (ответственный), R — Responsible (исполнитель), C — Consulted (консультируемый), I — Informed (информируемый)
2.2. Владелец регламента
Описание подраздела: Подраздел определяет должностное лицо, ответственное за поддержание регламента в актуальном состоянии и координацию его применения.
Кто является владельцем регламента и несёт ответственность за его актуализацию?
Инструкция по заполнению:
Укажите должность владельца регламента и его основные обязанности по поддержанию документа (4-5 пунктов). Определите периодичность пересмотра и триггеры внеплановой актуализации. Укажите заместителя владельца регламента.
Пример:
Владелец регламента: Директор по цифровой трансформации
Обязанности владельца:
- Обеспечение актуальности регламента и его соответствия стратегическим целям организации
- Инициирование пересмотра регламента при изменении внешних требований или внутренних процессов
- Рассмотрение и утверждение предложений по изменению регламента
- Контроль соблюдения требований регламента подразделениями
- Разрешение спорных вопросов толкования положений регламента
Заместитель владельца: Руководитель Центра компетенций RPA
Периодичность пересмотра: Ежегодно, не позднее 31 январяч
Триггеры внепланового пересмотра: изменение законодательства, смена RPA-платформы, существенное изменение организационной структуры
2.3. Ответственность за действия программных роботов
Описание подраздела: Подраздел определяет принципы распределения ответственности за результаты работы программных роботов и порядок разбора инцидентов.
Как распределяется ответственность за ошибки, совершённые программным роботом?
Инструкция по заполнению:
Опишите 3-4 принципа распределения ответственности за ошибки роботов. Разграничьте ответственность между владельцем процесса, разработчиком и администратором в зависимости от типа ошибки. Приведите таблицу с классификацией ошибок и ответственных лиц.
Пример:
Принципы распределения ответственности:
- Принцип причинности — ответственность несёт сторона, чьи действия или бездействие стали причиной ошибки
- Принцип разделения контуров — бизнес отвечает за корректность требований, ИТ — за качество реализации
- Принцип документирования — решения и согласования фиксируются, что позволяет установить ответственного
- Принцип эскалации — при невозможности установить причину вопрос выносится на Комитет по автоматизации
Матрица ответственности по типам ошибок:
| Тип ошибки | Описание | Ответственный | Действия |
|---|---|---|---|
| Ошибка в бизнес-логике | Робот выполнил некорректное действие согласно ТЗ | Бизнес-заказчик | Корректировка ТЗ, доработка робота |
| Ошибка разработки | Робот работает не в соответствии с ТЗ | Разработчик RPA | Исправление кода, регрессионное тестирование |
| Ошибка эксплуатации | Сбой инфраструктуры, недоступность систем | Администратор RPA | Восстановление работоспособности |
| Ошибка интеграции | Изменение интерфейса смежной системы | Владелец смежной системы | Уведомление, адаптация робота |
| Ошибка данных | Некорректные входные данные | Владелец процесса | Контроль качества данных |
ОТБОР И ОЦЕНКА ПРОЦЕССОВ-КАНДИДАТОВ
Описание раздела: Раздел определяет критерии и процедуры отбора бизнес-процессов для автоматизации и роботизации, методы оценки их пригодности и экономического потенциала.
3.1. Критерии пригодности процесса
Описание подраздела: Подраздел устанавливает критерии первичной оценки процессов-кандидатов для включения в портфель автоматизации.
Какие критерии (чек-лист) используются для первичной оценки пригодности процесса к автоматизации или роботизации?
Инструкция по заполнению:
Разработайте чек-лист из 10-15 критериев пригодности процесса к автоматизации. Сгруппируйте критерии по категориям: технические, организационные, экономические. Укажите пороговые значения и весовые коэффициенты для скоринговой модели.
Пример:
Чек-лист оценки пригодности процесса к автоматизации:
| № | Критерий | Категория | Вес | Пороговое значение | Оценка (0-5) |
|---|---|---|---|---|---|
| 1 | Стандартизированность процесса | Организационный | 15% | Процесс регламентирован и стандартизирован | |
| 2 | Структурированность данных | Технический | 12% | Данные в электронном структурированном виде | |
| 3 | Объём транзакций | Экономический | 10% | Не менее 500 транзакций в месяц | |
| 4 | Стабильность процесса | Организационный | 10% | Изменения не чаще 2 раз в год | |
| 5 | Правила принятия решений | Технический | 12% | Чёткие, формализуемые правила | |
| 6 | Количество исключений | Технический | 8% | Не более 20% исключительных случаев | |
| 7 | Трудоёмкость операций | Экономический | 10% | Не менее 2 FTE на процесс | |
| 8 | Частота ошибок | Экономический | 8% | Текущий уровень ошибок > 2% | |
| 9 | Доступность систем | Технический | 5% | API или стабильный UI | |
| 10 | Готовность бизнес-заказчика | Организационный | 10% | Выделен ресурс для сопровождения проекта |
Пороговый балл для включения в портфель: ≥ 3.5 из 5.0 (средневзвешенная оценка)
3.2. Оценка потенциала автоматизации
Описание подраздела: Подраздел определяет методику комплексной оценки процессов-кандидатов, включая оценку зрелости, потенциала и экономического обоснования.
Как проводится оценка зрелости, потенциала автоматизации и технико-экономического обоснования (FTE, ROI, сложность, сроки окупаемости)?
Инструкция по заполнению:
Опишите методику оценки по 3-4 направлениям: зрелость процесса, технический потенциал, экономическое обоснование. Приведите формулы расчёта ключевых показателей (FTE-экономия, ROI, срок окупаемости). Укажите источники данных для расчётов и ответственных за их предоставление.
Пример:
Методика комплексной оценки процесса-кандидата:
1. Оценка зрелости процесса (шкала 1-5):
| Уровень | Характеристика | Рекомендация |
|---|---|---|
| 1 — Начальный | Процесс не формализован | Не рекомендуется к автоматизации |
| 2 — Повторяемый | Есть базовое описание | Требуется стандартизация |
| 3 — Определённый | Процесс регламентирован | Возможна автоматизация с доработкой |
| 4 — Управляемый | Есть метрики и контроль | Рекомендуется к автоматизации |
| 5 — Оптимизируемый | Постоянное улучшение | Приоритет для автоматизации |
2. Расчёт экономического эффекта:
| Показатель | Формула | Пример расчёта |
|---|---|---|
| FTE-экономия | (Время операции × Количество операций × 12) / 1920 часов | (15 мин × 2000 шт × 12) / 1920 = 1.87 FTE |
| Годовая экономия (руб.) | FTE-экономия × Средняя стоимость FTE | 1.87 × 1 800 000 = 3 366 000 руб. |
| Затраты на внедрение | Разработка + Лицензии + Инфраструктура | 800 000 + 400 000 + 200 000 = 1 400 000 руб. |
| ROI | (Годовая экономия − Годовые затраты) / Инвестиции × 100% | (3 366 000 − 400 000) / 1 400 000 × 100% = 212% |
| Срок окупаемости | Инвестиции / (Годовая экономия − Годовые затраты) × 12 мес. | 1 400 000 / 2 966 000 × 12 = 5.7 мес. |
Пороговые значения для утверждения: ROI ≥ 100%, срок окупаемости ≤ 18 мес.
ИНИЦИАЦИЯ И ПРИОРИТИЗАЦИЯ
Описание раздела: Раздел определяет порядок подачи и рассмотрения заявок на автоматизацию, механизмы приоритизации и управления портфелем инициатив.
4.1. Порядок инициации заявки
Описание подраздела: Подраздел устанавливает процедуру подачи заявки на автоматизацию, требования к её содержанию и порядок согласования.
Каков порядок инициации заявки на автоматизацию и кто обладает полномочиями для её утверждения?
Инструкция по заполнению:
Опишите пошаговую процедуру инициации заявки (5-7 шагов). Укажите требования к содержанию заявки, сроки рассмотрения на каждом этапе. Определите уровни утверждения в зависимости от масштаба инициативы (бюджет, FTE, стратегическая значимость).
Пример:
Процедура инициации заявки:
| Этап | Действие | Ответственный | Срок | Результат |
|---|---|---|---|---|
| 1 | Формирование заявки по форме РГА-01 | Бизнес-заказчик | — | Заполненная заявка |
| 2 | Первичная экспертиза заявки | Процессный офис | 3 р.д. | Заключение о соответствии критериям |
| 3 | Техническая экспертиза | CoE RPA | 5 р.д. | Оценка сложности и сроков |
| 4 | Экономическая оценка | Финансовый контроль | 3 р.д. | Расчёт ROI и бюджета |
| 5 | Приоритизация | Комитет по автоматизации | 5 р.д. | Приоритет и очередь реализации |
| 6 | Утверждение к реализации | Уполномоченное лицо | 2 р.д. | Приказ о запуске проекта |
Уровни утверждения:
| Параметры инициативы | Уровень утверждения |
|---|---|
| Бюджет до 500 тыс. руб., FTE-экономия до 1 | Руководитель CoE RPA |
| Бюджет 500 тыс. — 3 млн руб., FTE 1-5 | Директор по цифровой трансформации |
| Бюджет свыше 3 млн руб. или FTE > 5 | Комитет по цифровой трансформации |
| Стратегические инициативы | Правление |
4.2. Управление очередью задач
Описание подраздела: Подраздел определяет принципы и механизмы приоритизации инициатив и управления портфелем задач на автоматизацию.
Как формируется, приоритизируется и управляется очередь (backlog) задач на автоматизацию?
Инструкция по заполнению:
Опишите модель приоритизации с 4-6 критериями и их весами. Укажите периодичность пересмотра приоритетов и триггеры перепланирования. Определите правила управления backlog: добавление, удаление, изменение приоритета.
Пример:
Модель приоритизации инициатив:
| Критерий | Вес | Шкала оценки |
|---|---|---|
| Экономический эффект (ROI) | 30% | 1 — ROI < 50%, 5 — ROI > 200% |
| Срок окупаемости | 20% | 1 — > 24 мес., 5 — < 6 мес. |
| Стратегическая значимость | 20% | 1 — низкая, 5 — критическая |
| Техническая готовность | 15% | 1 — требует НИОКР, 5 — типовое решение |
| Готовность бизнес-заказчика | 15% | 1 — низкая вовлечённость, 5 — полная готовность |
Итоговый приоритет: Взвешенная сумма баллов (макс. 5.0)
Категории приоритета:
- P1 (4.0-5.0): Немедленная реализация, выделение ресурсов в приоритетном порядке
- P2 (3.0-3.9): Плановая реализация в текущем квартале
- P3 (2.0-2.9): Резерв, реализация при наличии свободных ресурсов
- P4 (< 2.0): Отложено / Отклонено
Управление backlog:
- Периодичность пересмотра: еженедельно (статус-встреча CoE RPA)
- Полный пересмотр приоритетов: ежемесячно (Комитет по автоматизации)
- Триггеры перепланирования: изменение стратегии, критический инцидент, изменение ресурсов
АНАЛИЗ И ПРОЕКТИРОВАНИЕ
Описание раздела: Раздел определяет требования к анализу текущего состояния процессов, проектированию целевой модели и формированию технического задания на автоматизацию.
5.1. Описание процесса AS-IS
Описание подраздела: Подраздел устанавливает требования к формату, нотации и уровню детализации описания текущего состояния процесса.
Какие требования предъявляются к описанию процесса «как есть» (AS-IS): формат, нотация, уровень детализации?
Инструкция по заполнению:
Определите обязательную нотацию и инструменты моделирования. Укажите требуемый уровень детализации (до операций/действий). Перечислите обязательные атрибуты описания процесса (8-10 атрибутов). Приведите пример структуры паспорта процесса AS-IS.
Пример:
Требования к описанию AS-IS:
| Параметр | Требование |
|---|---|
| Нотация моделирования | BPMN 2.0 (обязательно), EPC (допустимо для legacy) |
| Инструмент моделирования | [Наименование BPMS организации] или Visio/draw.io |
| Уровень детализации | До уровня действий исполнителя (L4), шаги длительностью от 1 минуты |
| Формат представления | Графическая модель + текстовое описание + таблица операций |
Обязательные атрибуты описания:
| № | Атрибут | Описание |
|---|---|---|
| 1 | Наименование процесса | Уникальное название согласно реестру процессов |
| 2 | Владелец процесса | Должность и ФИО |
| 3 | Входы процесса | Перечень входных данных/документов с источниками |
| 4 | Выходы процесса | Перечень результатов с потребителями |
| 5 | Участники | Роли и подразделения, задействованные в процессе |
| 6 | Информационные системы | Перечень ИС, используемых в процессе |
| 7 | Объём операций | Количество транзакций в месяц/год |
| 8 | Трудоёмкость | Время выполнения операций (мин.), FTE |
| 9 | Текущие проблемы | Болевые точки, ошибки, задержки |
| 10 | Бизнес-правила | Формализованные правила принятия решений |
5.2. Проектирование модели TO-BE
Описание подраздела: Подраздел определяет стандарты и нотации для проектирования целевой модели автоматизированного процесса.
Какие стандарты и нотации обязательны при проектировании целевой модели процесса «как будет» (TO-BE)?
Инструкция по заполнению:
Укажите обязательные нотации и стандарты проектирования. Определите требования к описанию взаимодействия человек-робот. Опишите правила декомпозиции процесса на автоматизируемые и ручные операции. Приведите пример оформления модели TO-BE.
Пример:
Стандарты проектирования TO-BE:
| Аспект | Стандарт/Требование |
|---|---|
| Нотация процесса | BPMN 2.0 с использованием пулов и дорожек для разграничения человек/робот |
| Нотация интеграций | Sequence Diagram (UML) для взаимодействия с ИС |
| Описание алгоритмов | Блок-схемы или псевдокод для сложной логики |
| Бизнес-правила | Decision Model and Notation (DMN) или таблицы решений |
Требования к модели TO-BE:
- Чёткое разграничение операций: «Робот», «Человек», «Человек + Робот»
- Явное указание точек передачи управления между человеком и роботом
- Описание обработки исключений и эскалации
- Спецификация входных/выходных данных для каждой операции робота
- Указание SLA для автоматизированных операций
Цветовое кодирование на диаграммах (опионально):
- 🟦 Синий — операции робота
- 🟩 Зелёный — операции человека
- 🟨 Жёлтый — точки контроля и принятия решений
- 🟥 Красный — обработка исключений
5.3. Техническое задание
Описание подраздела: Подраздел определяет состав и структуру технического задания на разработку решения по автоматизации.
Каков состав и структура технического задания (ТЗ) или паспорта инициативы?
Инструкция по заполнению:
Приведите структуру ТЗ из 10-15 разделов. Укажите обязательные и опциональные разделы. Определите требования к детализации функциональных и нефункциональных требований. Приведите пример оглавления ТЗ.
Пример:
Структура технического задания:
| № | Раздел | Статус | Содержание |
|---|---|---|---|
| 1 | Общие сведения | Обязательный | Наименование, заказчик, исполнитель, сроки |
| 2 | Цели и задачи | Обязательный | Бизнес-цели, измеримые KPI |
| 3 | Описание AS-IS | Обязательный | Текущий процесс, проблемы, объёмы |
| 4 | Описание TO-BE | Обязательный | Целевой процесс, границы автоматизации |
| 5 | Функциональные требования | Обязательный | Детальные требования к функциям робота |
| 6 | Нефункциональные требования | Обязательный | Производительность, доступность, безопасность |
| 7 | Требования к данным | Обязательный | Входные/выходные данные, форматы, валидация |
| 8 | Требования к интеграции | Обязательный | Перечень ИС, способы интеграции |
| 9 | Требования к ИБ | Обязательный | Согласованные требования службы ИБ |
| 10 | Обработка исключений | Обязательный | Сценарии исключений, эскалация |
| 11 | Критерии приёмки | Обязательный | Условия успешной приёмки решения |
| 12 | Ограничения и допущения | Опциональный | Известные ограничения, предположения |
| 13 | Глоссарий | Опциональный | Специфические термины предметной области |
| 14 | Приложения | Опциональный | Формы документов, примеры данных |
5.4. Выбор технологии и платформы
Описание подраздела: Подраздел определяет порядок и критерии выбора технологии, платформы и инструментов для реализации автоматизации.
Как осуществляется выбор технологии, платформы и инструментов автоматизации?
Инструкция по заполнению:
Укажите стек разрешённых технологий и платформ организации. Опишите критерии выбора между альтернативами (RPA vs BPMS vs low-code). Определите порядок согласования отклонений от стандартного стека. Приведите матрицу выбора технологии.
Пример:
Стандартный технологический стек:
| Категория | Стандартное решение | Альтернатива |
|---|---|---|
| RPA-платформа | [Основная платформа организации] | Согласование с ИТ-архитектором |
| BPMS | [Основная платформа организации] | — |
| Low-code | [Основная платформа организации] | — |
| OCR/ICR | [Интегрированный модуль] | Внешние сервисы по согласованию |
| ML/AI | [Облачная платформа организации] | Согласование с CoE AI |
Матрица выбора технологии:
| Характеристика процесса | RPA | BPMS | Low-code | Традиционная разработка |
|---|---|---|---|---|
| Работа с UI legacy-систем | ✅ | ❌ | ❌ | ❌ |
| Сквозной процесс с участием людей | ⚠️ | ✅ | ✅ | ⚠️ |
| Высокая частота изменений | ⚠️ | ✅ | ✅ | ❌ |
| Интеграция через API | ⚠️ | ✅ | ✅ | ✅ |
| Сложная бизнес-логика | ❌ | ✅ | ⚠️ | ✅ |
| Быстрый time-to-market | ✅ | ⚠️ | ✅ | ❌ |
✅ — оптимально, ⚠️ — возможно с ограничениями, ❌ — не рекомендуется
РАЗРАБОТКА И ТЕСТИРОВАНИЕ
Описание раздела: Раздел определяет требования к процессам разработки, тестирования и приёмки решений по автоматизации.
6.1. Среды разработки и эксплуатации
Описание подраздела: Подраздел устанавливает требования к разделению сред и правила перемещения решений между контурами.
Какие требования предъявляются к средам разработки, тестирования и промышленной эксплуатации (разделение контуров)?
Инструкция по заполнению:
Опишите 3-4 среды (разработка, тестирование, предпром, прод) и их назначение. Укажите требования к изоляции сред и правила доступа. Определите процедуру продвижения кода между средами. Приведите схему контуров.
Пример:
Контуры и их назначение:
| Контур | Назначение | Данные | Доступ |
|---|---|---|---|
| DEV (Разработка) | Разработка и отладка решений | Синтетические тестовые данные | Разработчики RPA |
| TEST (Тестирование) | Функциональное и интеграционное тестирование | Обезличенные копии прод-данных | Разработчики, Тестировщики, Бизнес-заказчик |
| UAT (Предпром) | Пользовательское приёмочное тестирование | Обезличенные копии прод-данных | Бизнес-заказчик, Тестировщики |
| PROD (Продуктив) | Промышленная эксплуатация | Реальные данные | Оркестратор (автозапуск), Администраторы |
Правила продвижения между контурами:
DEV → TEST: Code Review + Unit Tests Passed
TEST → UAT: Функциональное тестирование пройдено, Интеграционные тесты OK
UAT → PROD: UAT Acceptance Sign-off + Security Review + Change Request Approved
Требования к изоляции:
- Среды физически или логически изолированы
- Учётные записи роботов уникальны для каждой среды
- Прод-данные запрещены в DEV и TEST без обезличивания
6.2. Стандарты разработки
Описание подраздела: Подраздел определяет стандарты кодирования, архитектурные принципы и требования к качеству кода.
Какие стандарты кодирования и архитектурные принципы должны соблюдаться при разработке?
Инструкция по заполнению:
Укажите 5-7 обязательных стандартов кодирования (именование, комментирование, структура проекта). Опишите архитектурные принципы (модульность, переиспользование). Определите требования к Code Review. Приведите примеры правильного и неправильного кода.
Пример:
Стандарты кодирования RPA:
| № | Стандарт | Описание | Пример |
|---|---|---|---|
| 1 | Именование проектов | {Подразделение}{Процесс}{Версия} | FIN_InvoiceProcessing_v1.0 |
| 2 | Именование компонентов | {Действие}{Объект}{Детализация} | Get_InvoiceData_FromSAP |
| 3 | Комментирование | Заголовочный комментарий + комментарии к блокам логики | // Получение данных счёта из SAP |
| 4 | Обработка исключений | Try-Catch для всех внешних вызовов | Обязательный лог ошибки |
| 5 | Логирование | INFO — ключевые шаги, ERROR — ошибки, DEBUG — отладка | Использование стандартного логгера |
| 6 | Конфигурация | Все параметры в config-файле, не в коде | Пути, таймауты, учётные данные |
| 7 | Модульность | Переиспользуемые компоненты в библиотеке | Модуль работы с SAP, модуль отправки email |
Архитектурные принципы:
- REFramework: Использование стандартного фреймворка для транзакционных процессов
- Page Object Model: Инкапсуляция UI-элементов для устойчивости к изменениям интерфейса
- Separation of Concerns: Разделение бизнес-логики, работы с данными и UI-взаимодействия
6.3. Управление версиями
Описание подраздела: Подраздел определяет правила версионирования кода и конфигураций решений.
Как регламентируется управление версиями программного кода и конфигураций?
Инструкция по заполнению:
Укажите систему контроля версий и правила работы с ней. Опишите стратегию ветвления (branching strategy). Определите правила именования версий (semantic versioning). Приведите пример жизненного цикла версии.
Пример:
Система контроля версий: Git ([корпоративный GitLab/GitHub])
Стратегия ветвления:
| Ветка | Назначение | Правила |
|---|---|---|
| main | Продуктивная версия | Только через Pull Request после UAT |
| develop | Интеграционная ветка | Слияние feature-веток после Code Review |
| feature/{ID}_{name} | Разработка функционала | Создаётся от develop, удаляется после merge |
| hotfix/{ID}_{name} | Срочные исправления | Создаётся от main, merge в main и develop |
| release/{version} | Подготовка релиза | Создаётся от develop для UAT |
Semantic Versioning: MAJOR.MINOR.PATCH
- MAJOR: Критические изменения, несовместимость с предыдущей версией
- MINOR: Новый функционал, обратная совместимость сохранена
- PATCH: Исправление ошибок, без изменения функционала
Пример: 2.3.1 — версия 2, функционал расширения 3, патч 1
6.4. Тестирование
Описание подраздела: Подраздел определяет виды тестирования, их порядок и требования к документированию результатов.
Каков порядок проведения функционального, интеграционного и пользовательского приёмочного тестирования (UAT)?
Инструкция по заполнению:
Опишите 3-4 вида тестирования с указанием целей, ответственных и критериев прохождения. Укажите требования к тест-кейсам и тестовым данным. Определите процент покрытия тестами. Приведите шаблон протокола тестирования.
Пример:
Виды тестирования:
| Вид | Цель | Ответственный | Критерий прохождения |
|---|---|---|---|
| Unit-тестирование | Проверка отдельных компонентов | Разработчик | 100% компонентов протестировано |
| Функциональное | Проверка соответствия ТЗ | QA-инженер | 100% функциональных требований покрыто |
| Интеграционное | Проверка взаимодействия с ИС | QA-инженер + ИТ | Все интеграционные сценарии пройдены |
| UAT | Подтверждение бизнес-заказчиком | Бизнес-заказчик | Подписан протокол приёмки |
| Регрессионное | Проверка после изменений | QA-инженер | Существующий функционал не нарушен |
Требования к тест-кейсам:
- Уникальный идентификатор (TC-{процесс}-{номер})
- Описание предусловий и шагов
- Ожидаемый результат
- Тестовые данные
- Связь с требованием из ТЗ
Минимальное покрытие: 100% критического функционала, 80% общего функционала
6.5. Критерии приёмки
Описание подраздела: Подраздел определяет критерии успешной приёмки решения и порядок подписания протокола.
Каковы критерии успешной приёмки решения и кто подписывает протокол?
Инструкция по заполнению:
Сформулируйте 5-7 обязательных критериев приёмки. Укажите допустимые отклонения и порядок их согласования. Определите состав подписантов протокола приёмки. Приведите форму протокола приёмки.
Пример:
Критерии успешной приёмки:
| № | Критерий | Метрика | Допустимое отклонение |
|---|---|---|---|
| 1 | Функциональная полнота | 100% требований ТЗ реализовано | Некритичные требования — до 5% |
| 2 | Стабильность работы | Успешных запусков ≥ 95% | — |
| 3 | Производительность | Время обработки ≤ указанного в ТЗ | +10% |
| 4 | Корректность результатов | Ошибок обработки ≤ 1% | — |
| 5 | Безопасность | Заключение службы ИБ — положительное | — |
| 6 | Документация | Полный комплект документации передан | — |
| 7 | Обучение | Пользователи обучены, подтверждение получено | — |
Подписанты протокола приёмки:
- Бизнес-заказчик (обязательно)
- Владелец процесса (обязательно)
- Руководитель CoE RPA (обязательно)
- Представитель службы ИБ (при наличии требований ИБ)
Протокол включает: дату, участников, результаты тестирования, перечень замечаний (при наличии), решение о приёмке, подписи.
ВНЕДРЕНИЕ И ИНТЕГРАЦИЯ
Описание раздела: Раздел определяет порядок ввода решений в эксплуатацию и требования к интеграции с существующими информационными системами.
7.1. Ввод в эксплуатацию
Описание подраздела: Подраздел устанавливает процедуру перехода от тестирования к промышленной эксплуатации.
Каков порядок ввода решения в опытно-промышленную и промышленную эксплуатацию?
Инструкция по заполнению:
Опишите этапы ввода в эксплуатацию: ОПЭ (пилот), ПЭ (промышленная). Укажите критерии перехода между этапами, длительность ОПЭ, состав участников. Определите порядок отката при критических проблемах. Приведите чек-лист готовности к вводу в ПЭ.
Пример:
Этапы ввода в эксплуатацию:
| Этап | Длительность | Цель | Критерий перехода |
|---|---|---|---|
| ОПЭ (Опытно-промышленная эксплуатация) | 2-4 недели | Валидация в реальных условиях на ограниченном объёме | Стабильность ≥ 95%, ошибки устранены |
| ПЭ (Промышленная эксплуатация) | Бессрочно | Полноценная работа на всём объёме данных | — |
Чек-лист готовности к ПЭ:
| № | Пункт проверки | Статус |
|---|---|---|
| 1 | UAT успешно завершён, протокол подписан | ☐ |
| 2 | ОПЭ завершена успешно (≥ 95% успешных запусков) | ☐ |
| 3 | Все критические замечания ОПЭ устранены | ☐ |
| 4 | Документация актуализирована и передана | ☐ |
| 5 | Учётные записи робота созданы в PROD | ☐ |
| 6 | Расписание запусков согласовано | ☐ |
| 7 | Мониторинг и алертинг настроены | ☐ |
| 8 | Процедура эскалации инцидентов согласована | ☐ |
| 9 | Обучение пользователей проведено | ☐ |
| 10 | Change Request на ввод в ПЭ утверждён | ☐ |
Процедура отката: При критических проблемах — остановка робота, возврат к ручному выполнению, уведомление CoE RPA в течение 30 минут.
7.2. Интеграция с информационными системами
Описание подраздела: Подраздел определяет требования и подходы к интеграции автоматизированных решений с ИТ-ландшафтом организации.
Как обеспечивается интеграция автоматизированных решений с существующими информационными системами?
Инструкция по заполнению:
Опишите 3-4 способа интеграции (API, UI, файловый обмен, БД) с указанием приоритетности и ограничений. Укажите требования к документированию интеграций. Определите порядок согласования с владельцами смежных систем. Приведите матрицу выбора способа интеграции.
Пример:
Способы интеграции (в порядке приоритета):
| Приоритет | Способ | Описание | Когда использовать | Ограничения |
|---|---|---|---|---|
| 1 | API (REST/SOAP) | Интеграция через программные интерфейсы | Система имеет документированный API | Требует согласования нагрузки |
| 2 | Файловый обмен | Экспорт/импорт файлов через общую папку или SFTP | Системы без API, пакетная обработка | Задержка в получении данных |
| 3 | База данных | Прямое чтение/запись в БД | Отчётность, миграция данных | Только чтение, согласование с DBA |
| 4 | UI (RPA) | Взаимодействие через пользовательский интерфейс | Legacy-системы без других способов | Зависимость от стабильности UI |
Порядок согласования интеграции:
- Направление запроса владельцу системы (форма ЗИТ-01)
- Техническое согласование с ИТ-архитектором
- Согласование требований к нагрузке и SLA
- Получение доступов и документации
- Тестирование интеграции в TEST-среде
Требования к документированию: Для каждой интеграции создаётся Integration Design Document (IDD) с описанием эндпоинтов, форматов данных, обработки ошибок.
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ И УПРАВЛЕНИЕ ДОСТУПОМ
Описание раздела: Раздел определяет требования информационной безопасности к автоматизированным решениям и порядок управления доступом цифровых сотрудников.
8.1. Требования информационной безопасности
Описание подраздела: Подраздел устанавливает обязательные требования ИБ к решениям по автоматизации и программным роботам.
Какие требования информационной безопасности и защиты данных предъявляются к автоматизированным решениям и программным роботам?
Инструкция по заполнению:
Перечислите 8-10 обязательных требований ИБ. Укажите требования к защите данных (шифрование, маскирование). Определите порядок согласования с службой ИБ. Приведите чек-лист ИБ-требований для приёмки.
Пример:
Обязательные требования ИБ:
| № | Требование | Описание | Контроль |
|---|---|---|---|
| 1 | Аутентификация | Использование индивидуальных УЗ для каждого робота | Аудит УЗ ежеквартально |
| 2 | Авторизация | Минимально необходимые права (принцип least privilege) | Согласование матрицы доступа |
| 3 | Шифрование данных | Шифрование credentials в хранилище (AES-256) | Проверка при аудите |
| 4 | Защита в transit | Использование TLS 1.2+ для всех соединений | Сканирование уязвимостей |
| 5 | Логирование | Запись всех действий робота для аудита | Хранение логов ≥ 3 лет |
| 6 | Изоляция сред | Разделение DEV/TEST/PROD, разные УЗ | Проверка конфигурации |
| 7 | Защита от инъекций | Валидация и санитизация входных данных | Code Review |
| 8 | Управление secrets | Хранение в Credential Vault, не в коде | Автоматическая проверка |
| 9 | Контроль изменений | Все изменения через CR с согласованием ИБ | Процесс Change Management |
| 10 | Резервное копирование | Backup кода и конфигураций согласно политике | Тестирование восстановления |
Порядок согласования с ИБ:
- На этапе проектирования: согласование ТЗ (срок 5 р.д.)
- Перед вводом в ПЭ: проверка реализации требований (срок 3 р.д.)
- Периодический аудит: ежегодно
8.2. Управление учётными записями
Описание подраздела: Подраздел определяет порядок создания, управления и контроля учётных записей программных роботов.
Как организовано управление учётными записями, правами доступа и идентификацией «цифровых сотрудников»?
Инструкция по заполнению:
Опишите жизненный цикл учётной записи робота (создание, изменение, блокировка, удаление). Укажите правила именования и атрибуты УЗ. Определите порядок ротации паролей и ключей. Приведите форму заявки на создание УЗ робота.
Пример:
Жизненный цикл УЗ робота:
| Этап | Инициатор | Исполнитель | Срок | Документ |
|---|---|---|---|---|
| Создание | Владелец процесса | ИТ-администратор | 3 р.д. | Заявка ЗДС-01 |
| Назначение прав | Владелец процесса | Администратор ИС | 2 р.д. | Матрица доступа |
| Изменение прав | Владелец процесса | Администратор ИС | 2 р.д. | Заявка на изменение |
| Ротация пароля | Автоматически | Credential Vault | 90 дней | Лог ротации |
| Блокировка | Владелец процесса / ИБ | ИТ-администратор | 4 часа | Служебная записка |
| Удаление | Владелец процесса | ИТ-администратор | 5 р.д. | Заявка на удаление |
Правила именования УЗ:
- Формат: svc_rpa_{подразделение}_{процесс}_{среда}
- Пример: svc_rpa_fin_invoice_prod
Обязательные атрибуты УЗ:
- Наименование робота
- Владелец (должность, ФИО)
- Подразделение
- Перечень ИС с уровнем доступа
- Дата создания
- Срок действия (если временная)
8.3. Соблюдение законодательства
Описание подраздела: Подраздел определяет требования к соблюдению законодательства при автоматизации бизнес-процессов.
Как обеспечивается соблюдение требований законодательства при автоматизации?
Инструкция по заполнению:
Перечислите ключевые законодательные требования (ФЗ-152, отраслевые требования). Опишите меры по обеспечению соответствия. Укажите порядок проверки compliance при разработке и эксплуатации. Определите ответственность за нарушения.
Пример:
Применимые законодательные требования:
| Нормативный акт | Область применения | Меры соответствия |
|---|---|---|
| ФЗ-152 «О персональных данных» | Обработка ПДн роботами | Согласие субъекта, минимизация данных, обезличивание в тестах |
| ФЗ-149 «Об информации» | Работа с информацией | Классификация информации, ограничение доступа |
| ФЗ-63 «Об электронной подписи» | Подписание документов | Использование квалифицированной ЭП где требуется |
| Отраслевые требования | [Специфика отрасли] | [Конкретные меры] |
Процедура compliance-проверки:
- На этапе инициации: определение применимых требований (чек-лист)
- На этапе проектирования: включение требований в ТЗ
- Перед вводом в ПЭ: проверка реализации требований
- В эксплуатации: периодический аудит (ежегодно)
Ответственность: Нарушение требований законодательства влечёт дисциплинарную, административную или уголовную ответственность согласно действующему законодательству.
ЭКСПЛУАТАЦИЯ И МОНИТОРИНГ
Описание раздела: Раздел определяет порядок эксплуатации автоматизированных решений, требования к мониторингу и оценке эффективности.
9.1. Мониторинг работоспособности
Описание подраздела: Подраздел устанавливает требования к мониторингу работы программных роботов в режиме реального времени.
Как осуществляется мониторинг работоспособности и производительности автоматизированных процессов в режиме реального времени?
Инструкция по заполнению:
Опишите инструменты и дашборды мониторинга. Укажите ключевые метрики мониторинга (5-7 метрик). Определите пороговые значения для алертов. Приведите пример дашборда мониторинга.
Пример:
Инструменты мониторинга:
- Оркестратор RPA-платформы (встроенные дашборды)
- Корпоративная система мониторинга [наименование]
- Интеграция с Service Desk для автоматической регистрации инцидентов
Метрики мониторинга:
| Метрика | Описание | Целевое значение | Порог алерта |
|---|---|---|---|
| Успешность запусков | % успешно завершённых запусков | ≥ 98% | < 95% |
| Время выполнения | Среднее время обработки транзакции | ≤ Baseline + 20% | > Baseline + 50% |
| Очередь задач | Количество задач в ожидании | ≤ 100 | > 500 |
| Доступность робота | Uptime робота | ≥ 99.5% | < 99% |
| Использование лицензий | % использования лицензий | 70-90% | > 95% или < 50% |
| Ошибки бизнес-исключений | % транзакций с бизнес-ошибками | ≤ 5% | > 10% |
| Системные ошибки | Количество системных сбоев | 0 в день | ≥ 3 в день |
Эскалация алертов:
- Warning → Уведомление администратору RPA
- Critical → Уведомление CoE RPA + владельцу процесса
- Emergency → Эскалация на руководство ИТ
9.2. KPI автоматизации
Описание подраздела: Подраздел определяет систему показателей для оценки эффективности автоматизации.
Какие KPI и метрики используются для оценки эффективности автоматизации?
Инструкция по заполнению:
Приведите 10-12 KPI с формулами расчёта. Сгруппируйте по категориям: операционные, экономические, качественные. Укажите целевые значения и периодичность измерения. Определите ответственных за достижение.
Пример:
Система KPI автоматизации:
| Категория | KPI | Формула | Целевое значение | Периодичность | Ответственный |
|---|---|---|---|---|---|
| Операционные | |||||
| Успешность выполнения | Успешные запуски / Всего запусков × 100% | ≥ 98% | Ежедневно | Администратор RPA | |
| Утилизация роботов | Время работы / Доступное время × 100% | 70-85% | Еженедельно | CoE RPA | |
| Среднее время обработки | Сумма времени / Кол-во транзакций | ≤ Target | Ежедневно | Администратор RPA | |
| Доступность решений | Uptime / Плановое время × 100% | ≥ 99.5% | Ежемесячно | Администратор RPA | |
| Экономические | |||||
| FTE-экономия | Сэкономленные часы / 1920 | Согласно бизнес-кейсу | Ежемесячно | Процессный офис | |
| ROI портфеля | (Экономия − Затраты) / Инвестиции × 100% | ≥ 150% | Ежеквартально | Директор по ЦТ | |
| Стоимость транзакции | Общие затраты / Кол-во транзакций | ≤ Целевая | Ежемесячно | CoE RPA | |
| Качественные | |||||
| Точность обработки | Корректные транзакции / Всего × 100% | ≥ 99% | Ежемесячно | Владелец процесса | |
| Сокращение ошибок | (Ошибки до − Ошибки после) / Ошибки до × 100% | ≥ 80% | Ежеквартально | Владелец процесса | |
| Развитие | |||||
| Количество роботизированных процессов | Абсолютное число | Согласно плану | Ежеквартально | Директор по ЦТ | |
| Скорость внедрения | Среднее время от инициации до ПЭ | ≤ 12 недель | Ежеквартально | CoE RPA |
9.3. Оценка бизнес-результатов
Описание подраздела: Подраздел определяет порядок оценки фактического достижения бизнес-результатов после внедрения.
Как организована оценка фактического достижения бизнес-результатов после внедрения (Post-implementation review)?
Инструкция по заполнению:
Опишите процедуру Post-Implementation Review (PIR). Укажите сроки проведения (через 1, 3, 6, 12 месяцев). Определите состав оцениваемых параметров и критерии успеха. Приведите форму отчёта PIR.
Пример:
Процедура Post-Implementation Review (PIR):
| Этап PIR | Срок после ввода в ПЭ | Цель | Ответственный |
|---|---|---|---|
| PIR-1 | 1 месяц | Подтверждение стабильности работы | Администратор RPA |
| PIR-2 | 3 месяца | Оценка достижения операционных KPI | CoE RPA |
| PIR-3 | 6 месяцев | Оценка экономического эффекта | Процессный офис |
| PIR-4 | 12 месяцев | Итоговая оценка ROI, lessons learned | Директор по ЦТ |
Состав отчёта PIR:
| Раздел | Содержание |
|---|---|
| Общая информация | Название решения, даты, участники |
| Операционные показатели | Факт vs План: успешность, время, объёмы |
| Экономические показатели | Факт vs План: FTE-экономия, ROI, затраты |
| Качественные показатели | Точность, удовлетворённость пользователей |
| Проблемы и риски | Выявленные проблемы, реализованные риски |
| Lessons Learned | Уроки для будущих проектов |
| Рекомендации | Предложения по оптимизации |
Критерии успешности внедрения:
- Достижение ≥ 80% плановой FTE-экономии
- ROI ≥ 80% от планового
- Успешность выполнения ≥ 95%
- Отсутствие критических инцидентов
СОПРОВОЖДЕНИЕ И УПРАВЛЕНИЕ ИНЦИДЕНТАМИ
Описание раздела: Раздел определяет порядок технической поддержки, управления инцидентами и изменениями в автоматизированных решениях.
10.1. Техническая поддержка
Описание подраздела: Подраздел устанавливает уровни поддержки, SLA и порядок обращения за помощью.
Каков SLA и порядок организации технической поддержки и сопровождения решений?
Инструкция по заполнению:
Определите 3 уровня поддержки (L1, L2, L3) с описанием функций. Укажите SLA для каждого приоритета инцидента (время реакции, время решения). Опишите каналы обращения и режим работы поддержки. Приведите матрицу эскалации.
Пример:
Уровни технической поддержки:
| Уровень | Функции | Исполнитель | Режим работы |
|---|---|---|---|
| L1 | Приём обращений, первичная диагностика, типовые решения | Service Desk | 24/7 |
| L2 | Анализ и устранение инцидентов, настройка, мониторинг | Администраторы RPA | 8:00-20:00, Пн-Пт |
| L3 | Сложные доработки, исправление кода, архитектурные изменения | Разработчики CoE RPA | 9:00-18:00, Пн-Пт |
SLA по приоритетам:
| Приоритет | Описание | Время реакции | Время решения | Пример |
|---|---|---|---|---|
| P1 — Critical | Полная остановка критичного процесса | 15 мин | 4 часа | Робот не запускается, блокировка бизнеса |
| P2 — High | Существенная деградация работы | 30 мин | 8 часов | Ошибки в 50%+ транзакций |
| P3 — Medium | Частичные проблемы, есть workaround | 2 часа | 24 часа | Единичные ошибки, замедление |
| P4 — Low | Косметические проблемы, вопросы | 8 часов | 5 р.д. | Вопросы по функционалу |
Каналы обращения:
- Портал Service Desk (приоритетный)
- Email: rpa-support@company.ru
- Телефон: доб. 1234 (только для P1)
10.2. Управление инцидентами
Описание подраздела: Подраздел определяет процедуру обработки инцидентов и сбоев в работе автоматизированных процессов.
Каков порядок управления инцидентами и сбоями в работе автоматизированных процессов?
Инструкция по заполнению:
Опишите жизненный цикл инцидента (5-7 этапов). Укажите роли и ответственность на каждом этапе. Определите критерии классификации инцидентов. Приведите схему процесса управления инцидентами.
Пример:
Жизненный цикл инцидента:
| Этап | Действия | Ответственный | Срок |
|---|---|---|---|
| 1. Обнаружение | Автоматический алерт или обращение пользователя | Мониторинг / Пользователь | — |
| 2. Регистрация | Создание тикета в Service Desk, присвоение приоритета | Service Desk (L1) | 15 мин |
| 3. Диагностика | Первичный анализ, попытка решения типовыми методами | L1 / L2 | Согласно SLA |
| 4. Эскалация | Передача на следующий уровень при необходимости | L1 → L2 → L3 | 30 мин без прогресса |
| 5. Решение | Устранение причины инцидента | L2 / L3 | Согласно SLA |
| 6. Верификация | Подтверждение решения пользователем | Пользователь | 24 часа |
| 7. Закрытие | Документирование решения, закрытие тикета | Service Desk | — |
Классификация инцидентов:
| Тип | Описание | Действия |
|---|---|---|
| Бизнес-исключение | Некорректные входные данные, отклонение от правил | Обработка вручную, анализ причин |
| Системная ошибка | Сбой робота, недоступность системы | Перезапуск, эскалация на ИТ |
| Ошибка логики | Некорректная работа согласно ТЗ | Исправление кода (L3) |
| Изменение среды | Изменение UI/API смежной системы | Адаптация робота (L3) |
10.3. Управление изменениями
Описание подраздела: Подраздел определяет порядок внесения изменений в автоматизированные процессы.
Как осуществляется управление изменениями в автоматизированных процессах и при обновлении смежных систем?
Инструкция по заполнению:
Опишите процедуру управления изменениями (RFC). Классифицируйте изменения по типам и уровням согласования. Укажите требования к тестированию изменений. Определите порядок координации с владельцами смежных систем.
Пример:
Классификация изменений:
| Тип изменения | Описание | Согласование | Тестирование |
|---|---|---|---|
| Стандартное | Типовые, низкорисковые изменения (конфиг, расписание) | Руководитель CoE RPA | Smoke-тест |
| Нормальное | Изменение логики, добавление функционала | CAB (Change Advisory Board) | Полный цикл тестирования |
| Экстренное | Срочное исправление критической ошибки | Владелец процесса + CoE RPA | Минимальное, откат при проблемах |
Процедура внесения изменений:
- Инициация: Создание RFC (Request for Change) с описанием и обоснованием
- Оценка: Анализ влияния, трудозатрат, рисков
- Согласование: Утверждение согласно классификации
- Реализация: Разработка и тестирование в DEV/TEST
- Развёртывание: Внедрение в PROD в согласованное окно
- Верификация: Проверка корректности работы
- Закрытие: Документирование, закрытие RFC
Координация со смежными системами:
- Подписка на уведомления об изменениях от владельцев ИС
- Участие в CAB смежных систем при изменениях, влияющих на роботов
- Регрессионное тестирование при обновлениях смежных систем
АУДИТ И ОПТИМИЗАЦИЯ
Описание раздела: Раздел определяет порядок проведения аудита автоматизированных процессов и требования к логированию для обеспечения прозрачности.
11.1. Аудит автоматизированных процессов
Описание подраздела: Подраздел устанавливает процедуру периодического аудита зрелости, качества и эффективности решений.
Как проводится периодический аудит зрелости, качества и эффективности автоматизированных процессов?
Инструкция по заполнению:
Определите периодичность и виды аудита (внутренний, внешний). Опишите критерии оценки (5-7 направлений). Укажите состав аудиторской команды и порядок формирования отчёта. Приведите чек-лист аудита.
Пример:
Виды и периодичность аудита:
| Вид аудита | Периодичность | Цель | Исполнитель |
|---|---|---|---|
| Операционный аудит | Ежеквартально | Оценка KPI, выявление отклонений | Процессный офис |
| Технический аудит | Ежегодно | Проверка качества кода, архитектуры | CoE RPA + внешний аудитор |
| Аудит ИБ | Ежегодно | Соответствие требованиям безопасности | Служба ИБ |
| Аудит зрелости | Ежегодно | Оценка уровня зрелости практик RPA | Внешний консультант |
Критерии оценки:
| Направление | Критерии | Вес |
|---|---|---|
| Операционная эффективность | Достижение KPI, стабильность работы | 25% |
| Качество кода | Соответствие стандартам, документированность | 20% |
| Безопасность | Соблюдение требований ИБ, управление доступом | 20% |
| Governance | Соответствие регламентам, полнота документации | 15% |
| Экономическая эффективность | Достижение ROI, контроль затрат | 20% |
Результат аудита: Отчёт с оценкой по направлениям, выявленными несоответствиями, рекомендациями и планом корректирующих мероприятий.
11.2. Логирование и аудиторский след
Описание подраздела: Подраздел определяет требования к логированию действий для обеспечения прозрачности и возможности аудита.
Какие требования предъявляются к логированию действий для обеспечения аудиторского следа?
Инструкция по заполнению:
Определите обязательные события для логирования (8-10 типов). Укажите формат и атрибуты записей лога. Установите сроки хранения и требования к защите логов. Приведите пример записи лога.
Пример:
Обязательные события для логирования:
| № | Событие | Уровень | Обязательные атрибуты |
|---|---|---|---|
| 1 | Запуск робота | INFO | Timestamp, Robot ID, Process, Trigger |
| 2 | Завершение робота | INFO | Timestamp, Robot ID, Status, Duration |
| 3 | Начало/завершение транзакции | INFO | Transaction ID, Status, Duration |
| 4 | Вход в информационную систему | INFO | System, User, Timestamp |
| 5 | Чтение/запись данных | DEBUG | System, Operation, Data ID |
| 6 | Бизнес-исключение | WARNING | Transaction ID, Exception Type, Details |
| 7 | Системная ошибка | ERROR | Error Code, Stack Trace, Context |
| 8 | Критическая ошибка | CRITICAL | Full Diagnostics, Alert Sent |
| 9 | Изменение конфигурации | AUDIT | User, Parameter, Old/New Value |
| 10 | Обращение к credentials | AUDIT | Credential Name, Robot ID |
Формат записи лога:
[2024-03-15T10:23:45.123Z] [INFO] [RBT-FIN-001] [TRX-12345]
Process: InvoiceProcessing | Action: ReadInvoice |
System: SAP | Duration: 1.23s | Status: Success
Требования к хранению:
- Срок хранения: не менее 3 лет
- Защита от модификации: write-once storage
- Резервное копирование: согласно политике backup
- Доступ: только для аудиторов и администраторов
ВЫВОД ИЗ ЭКСПЛУАТАЦИИ
Описание раздела: Раздел определяет порядок вывода решений из эксплуатации или их существенной модернизации.
12.1. Процедура вывода из эксплуатации
Описание подраздела: Подраздел устанавливает основания, процедуру и требования к выводу автоматизированных решений из эксплуатации.
Каков порядок вывода решения из эксплуатации или существенной модернизации?
Инструкция по заполнению:
Определите основания для вывода из эксплуатации (4-5 причин). Опишите этапы процедуры (5-7 шагов). Укажите требования к архивированию и передаче знаний. Приведите чек-лист вывода из эксплуатации.
Пример:
Основания для вывода из эксплуатации:
| Основание | Описание | Инициатор |
|---|---|---|
| Отсутствие бизнес-потребности | Процесс упразднён или существенно изменён | Владелец процесса |
| Замена системой | Функционал реализован в новой ИС | ИТ-архитектор |
| Экономическая нецелесообразность | Затраты превышают экономию | Процессный офис |
| Технологическое устаревание | Платформа не поддерживается | CoE RPA |
| Существенная модернизация | Требуется полная переработка решения | CoE RPA |
Процедура вывода из эксплуатации:
| Этап | Действия | Ответственный | Срок |
|---|---|---|---|
| 1 | Инициация решения о выводе, обоснование | Владелец процесса | — |
| 2 | Согласование с заинтересованными сторонами | Процессный офис | 5 р.д. |
| 3 | Планирование перехода (ручной режим / новое решение) | CoE RPA + Бизнес | 10 р.д. |
| 4 | Уведомление пользователей | Владелец процесса | 10 р.д. до отключения |
| 5 | Остановка робота, отзыв доступов | Администратор RPA | В согласованную дату |
| 6 | Архивирование кода и документации | CoE RPA | 5 р.д. |
| 7 | Удаление из реестра, освобождение лицензий | Процессный офис | 5 р.д. |
Требования к архивированию:
- Код и конфигурации сохраняются в архивной ветке репозитория
- Документация переносится в архивный раздел базы знаний
- Логи сохраняются согласно политике хранения (3 года)
- Метаданные в реестре процессов отмечаются как «Архивный»
ДОКУМЕНТИРОВАНИЕ И БАЗА ЗНАНИЙ
Описание раздела: Раздел определяет требования к документированию проектов автоматизации и ведению корпоративной базы знаний.
13.1. Требования к документированию
Описание подраздела: Подраздел устанавливает состав обязательной документации и требования к её оформлению.
Какие требования предъявляются к документированию проектов, кода, алгоритмов и ведению базы знаний?
Инструкция по заполнению:
Определите состав обязательной документации для каждого решения (8-10 документов). Укажите требования к оформлению и актуализации. Опишите структуру базы знаний и правила её ведения. Приведите шаблон карточки решения в базе знаний.
Пример:
Состав обязательной документации:
| № | Документ | Этап создания | Ответственный | Актуализация |
|---|---|---|---|---|
| 1 | Паспорт инициативы | Инициация | Бизнес-заказчик | При изменении scope |
| 2 | Техническое задание | Проектирование | Процессный офис | При изменении требований |
| 3 | Модель процесса AS-IS | Анализ | Бизнес-аналитик | — |
| 4 | Модель процесса TO-BE | Проектирование | Бизнес-аналитик | При существенных изменениях |
| 5 | Solution Design Document | Разработка | Разработчик RPA | При архитектурных изменениях |
| 6 | Тест-кейсы и протоколы | Тестирование | QA-инженер | При изменении функционала |
| 7 | Руководство пользователя | Внедрение | Разработчик RPA | При изменении интерфейса |
| 8 | Руководство администратора | Внедрение | Администратор RPA | При изменении инфраструктуры |
| 9 | Акт ввода в эксплуатацию | Внедрение | Владелец процесса | — |
| 10 | Lessons Learned | Завершение PIR | Процессный офис | — |
Структура базы знаний:
База знаний RPA/
├── Методология/
│ ├── Регламенты и политики
│ ├── Шаблоны документов
│ └── Стандарты разработки
├── Решения/
│ ├── [Подразделение]/
│ │ └── [Название решения]/
│ │ ├── Документация
│ │ ├── Модели процессов
│ │ └── Lessons Learned
├── Компоненты/
│ └── Переиспользуемые модули
└── FAQ и Troubleshooting/
ОБУЧЕНИЕ И РАЗВИТИЕ КОМПЕТЕНЦИЙ
Описание раздела: Раздел определяет порядок обучения и развития компетенций сотрудников в области автоматизации и роботизации.
14.1. Программы обучения
Описание подраздела: Подраздел устанавливает требования к обучению различных категорий сотрудников, взаимодействующих с автоматизированными решениями.
Как организовано обучение и развитие компетенций сотрудников, взаимодействующих с автоматизированными процессами?
Инструкция по заполнению:
Определите целевые группы обучения (4-5 групп) и программы для каждой. Укажите форматы обучения и периодичность. Опишите требования к сертификации ключевых ролей. Приведите матрицу компетенций.
Пример:
Целевые группы и программы обучения:
| Целевая группа | Программа | Формат | Длительность | Периодичность |
|---|---|---|---|---|
| Пользователи | Работа с роботизированными процессами | E-learning | 2 часа | При внедрении + ежегодно |
| Бизнес-заказчики | Основы RPA, формирование требований | Очный тренинг | 1 день | При первом проекте |
| Бизнес-аналитики | Process Mining, Design Thinking для RPA | Очный тренинг | 3 дня | Ежегодно |
| Разработчики RPA | Платформа RPA (базовый/продвинутый) | Очный + практика | 5 дней | Сертификация + ежегодно |
| Администраторы | Администрирование оркестратора | Очный тренинг | 2 дня | При назначении |
Требования к сертификации:
| Роль | Обязательная сертификация | Срок действия |
|---|---|---|
| Разработчик RPA | Сертификат вендора платформы (Advanced) | 2 года |
| Архитектор решений | Сертификат вендора + Enterprise Architecture | 2 года |
| Администратор RPA | Сертификат вендора (Administration) | 2 года |
Матрица компетенций:
| Компетенция | Пользователь | Заказчик | Аналитик | Разработчик | Администратор |
|---|---|---|---|---|---|
| Понимание RPA | Базовый | Базовый | Продвинутый | Эксперт | Продвинутый |
| BPMN-моделирование | — | Базовый | Продвинутый | Базовый | — |
| Разработка роботов | — | — | — | Эксперт | Базовый |
| Администрирование | — | — | — | Базовый | Эксперт |
РЕСУРСНОЕ ОБЕСПЕЧЕНИЕ И ВЗАИМОДЕЙСТВИЕ С ПОДРЯДЧИКАМИ
Описание раздела: Раздел определяет порядок управления ресурсами автоматизации (лицензии, инфраструктура) и взаимодействия с внешними исполнителями.
15.1. Управление лицензиями и инфраструктурой
Описание подраздела: Подраздел устанавливает порядок управления лицензиями, инфраструктурой и распределения затрат.
Как осуществляется управление лицензиями, инфраструктурой и распределение затрат между бизнес-единицами?
Инструкция по заполнению:
Опишите модель лицензирования и порядок учёта лицензий. Укажите правила распределения затрат (showback/chargeback). Определите процедуру запроса дополнительных ресурсов. Приведите пример расчёта стоимости для бизнес-единицы.
Пример:
Модель лицензирования:
| Тип лицензии | Количество | Стоимость (год) | Распределение |
|---|---|---|---|
| Оркестратор | 1 | [Сумма] | Централизованно (CoE RPA) |
| Разработческие лицензии | [N] | [Сумма] | Централизованно (CoE RPA) |
| Runtime (attended) | [N] | [Сумма] | По бизнес-единицам |
| Runtime (unattended) | [N] | [Сумма] | По бизнес-единицам |
Модель распределения затрат (Chargeback):
| Статья затрат | Метод распределения | Формула |
|---|---|---|
| Лицензии Runtime | По количеству роботов | N роботов × Стоимость лицензии |
| Инфраструктура | По потреблению ресурсов | vCPU × Тариф + RAM × Тариф + Storage × Тариф |
| Разработка (CoE) | По трудозатратам | Человеко-часы × Тариф CoE |
| Поддержка | Фиксированный % от стоимости решения | 15% от TCO решения в год |
Пример расчёта для бизнес-единицы:
| Статья | Расчёт | Сумма (год) |
|---|---|---|
| Runtime (2 unattended) | 2 × 800 000 руб. | 1 600 000 руб. |
| Инфраструктура | 4 vCPU + 16 GB RAM | 240 000 руб. |
| Поддержка | 15% × 1 840 000 | 276 000 руб. |
| Итого | 2 116 000 руб. |
15.2. Взаимодействие с подрядчиками
Описание подраздела: Подраздел определяет порядок взаимодействия с внешними подрядчиками и вендорами.
Каков порядок взаимодействия с внешними подрядчиками и вендорами?
Инструкция по заполнению:
Определите сценарии привлечения подрядчиков и критерии выбора. Укажите требования к договорам (SLA, NDA, передача прав). Опишите порядок приёмки работ и контроля качества. Приведите чек-лист оценки подрядчика.
Пример:
Сценарии привлечения подрядчиков:
| Сценарий | Описание | Критерии применения |
|---|---|---|
| Аутстаффинг | Предоставление специалистов для работы под управлением CoE | Пиковые нагрузки, временная нехватка ресурсов |
| Аутсорсинг разработки | Передача проекта под ключ | Сложные проекты, отсутствие компетенций |
| Консалтинг | Экспертиза, аудит, обучение | Новые направления, оценка зрелости |
| Managed Services | Передача эксплуатации | Оптимизация затрат, фокус на бизнесе |
Требования к договорам:
| Требование | Описание |
|---|---|
| NDA | Обязательное соглашение о неразглашении |
| SLA | Согласованные уровни сервиса с штрафными санкциями |
| Передача прав | Исключительные права на код и документацию передаются заказчику |
| Качество кода | Соответствие стандартам организации, Code Review |
| Гарантийный период | Не менее 6 месяцев бесплатного исправления дефектов |
| Exit-стратегия | Условия и порядок прекращения сотрудничества |
Порядок приёмки работ:
- Code Review силами CoE RPA
- Тестирование согласно тест-плану
- Проверка документации на полноту
- Подписание акта приёма-передачи
УПРАВЛЕНИЕ РЕГЛАМЕНТОМ И КОНТРОЛЬ ИСПОЛНЕНИЯ
Описание раздела: Раздел определяет порядок актуализации регламента, контроля его исполнения и ответственность за нарушения.
16.1. Актуализация регламента
Описание подраздела: Подраздел устанавливает процедуру пересмотра и управления версиями регламента.
Каков порядок пересмотра, актуализации регламента и управления его версиями?
Инструкция по заполнению:
Укажите периодичность планового пересмотра и триггеры внепланового. Опишите процедуру внесения изменений (5-6 шагов). Определите порядок согласования и утверждения. Приведите пример листа регистрации изменений.
Пример:
Периодичность пересмотра:
- Плановый пересмотр: ежегодно, в IV квартале
- Внеплановый: при наступлении триггерных событий
Триггеры внепланового пересмотра:
- Изменение законодательства или внешних стандартов
- Существенное изменение организационной структуры
- Смена RPA-платформы или технологического стека
- Выявление существенных пробелов в регламенте
- Решение руководства о стратегических изменениях
Процедура внесения изменений:
| Этап | Действие | Ответственный | Срок |
|---|---|---|---|
| 1 | Инициация изменения (предложение + обоснование) | Любой сотрудник | — |
| 2 | Экспертиза предложения | Процессный офис | 5 р.д. |
| 3 | Подготовка проекта изменений | Процессный офис | 10 р.д. |
| 4 | Согласование с заинтересованными сторонами | Владелец регламента | 10 р.д. |
| 5 | Утверждение изменений | [Уполномоченное лицо] | 5 р.д. |
| 6 | Публикация и уведомление | Процессный офис | 2 р.д. |
Версионирование: MAJOR.MINOR (например, 2.3)
- MAJOR: существенные изменения структуры или содержания
- MINOR: уточнения, дополнения, исправления
16.2. Контроль исполнения
Описание подраздела: Подраздел определяет механизмы контроля соблюдения требований регламента и ответственность за нарушения.
Каков порядок контроля исполнения требований регламента и ответственность за их нарушение?
Инструкция по заполнению:
Опишите механизмы контроля (аудиты, проверки, KPI). Укажите виды нарушений и применяемые санкции. Определите порядок рассмотрения спорных ситуаций. Приведите примеры типичных нарушений и мер реагирования.
Пример:
Механизмы контроля:
| Механизм | Периодичность | Исполнитель | Результат |
|---|---|---|---|
| Операционный мониторинг | Непрерывно | Администратор RPA | Дашборд, алерты |
| Аудит соответствия | Ежеквартально | Процессный офис | Отчёт о несоответствиях |
| Проверка документации | При приёмке | CoE RPA | Чек-лист |
| Анализ инцидентов | Ежемесячно | CoE RPA | Отчёт о нарушениях |
Классификация нарушений и санкции:
| Тип нарушения | Примеры | Санкции |
|---|---|---|
| Критическое | Нарушение ИБ, несанкционированный доступ, подлог данных | Дисциплинарное взыскание, отстранение |
| Существенное | Запуск в ПЭ без согласования, отсутствие документации | Предупреждение, план корректировки |
| Незначительное | Отклонение от стандартов кодирования, неполное логирование | Замечание, обязательство исправить |
Порядок рассмотрения нарушений:
- Выявление и фиксация нарушения
- Уведомление ответственного лица и его руководителя
- Запрос объяснений (3 р.д.)
- Рассмотрение владельцем регламента
- Принятие решения о санкциях
- Контроль устранения нарушения
16.3. Приложения к регламенту
Описание подраздела: Подраздел определяет состав приложений к регламенту: шаблоны, формы и чек-листы.
Какие приложения к регламенту необходимы (шаблоны, формы, чек-листы)?
Инструкция по заполнению:
Приведите перечень всех приложений к регламенту (10-15 документов). Укажите назначение каждого приложения и этап использования. Определите ответственного за актуализацию каждой формы.
Пример:
Перечень приложений:
| № | Код | Наименование | Назначение | Этап |
|---|---|---|---|---|
| 1 | РГА-01 | Заявка на автоматизацию | Инициация проекта | Инициация |
| 2 | РГА-02 | Чек-лист оценки пригодности | Первичная оценка процесса | Отбор |
| 3 | РГА-03 | Форма экономического обоснования | Расчёт ROI, FTE | Отбор |
| 4 | РГА-04 | Паспорт процесса AS-IS | Описание текущего состояния | Анализ |
| 5 | РГА-05 | Шаблон технического задания | Формирование требований | Проектирование |
| 6 | РГА-06 | Шаблон Solution Design Document | Проектирование решения | Проектирование |
| 7 | РГА-07 | Шаблон тест-кейса | Разработка тестов | Тестирование |
| 8 | РГА-08 | Протокол тестирования | Фиксация результатов | Тестирование |
| 9 | РГА-09 | Протокол приёмки (UAT) | Приёмка решения | Внедрение |
| 10 | РГА-10 | Чек-лист готовности к ПЭ | Проверка перед запуском | Внедрение |
| 11 | РГА-11 | Заявка на создание УЗ робота | Управление доступом | Внедрение |
| 12 | РГА-12 | Карточка решения в базе знаний | Документирование | Эксплуатация |
| 13 | РГА-13 | Отчёт PIR | Оценка результатов | Эксплуатация |
| 14 | РГА-14 | Запрос на изменение (RFC) | Управление изменениями | Эксплуатация |
| 15 | РГА-15 | Акт вывода из эксплуатации | Завершение жизненного цикла | Вывод |
