ОБЩИЕ ПОЛОЖЕНИЯ
Описание раздела: Раздел определяет цель, задачи и область применения Регламента в контексте проектной реализации инициатив по автоматизации. Устанавливает взаимосвязь с базовым Регламентом.
1.1. Цель, задачи и ожидаемые результаты
Описание подраздела: Подраздел формулирует целевое назначение Регламента как методического руководства по управлению проектами автоматизации.
Каковы цель, задачи, назначение и ожидаемые результаты Регламента — что именно он должен обеспечить в организации?
Инструкция по заполнению:
Сформулируйте 1 генеральную цель и 4-6 задач. Укажите связь с базовым Регламентом. Определите 4-5 измеримых результатов. Приведите ссылки на стратегические документы.
Пример:
Цель: Установить единый порядок реализации проектов автоматизации от инициации до закрытия.
Задачи:
- Определить этапы жизненного цикла и критерии перехода (Gate Criteria)
- Установить состав обязательных артефактов и требования к ним
- Регламентировать порядок принятия проектных решений
- Обеспечить интеграцию с архитектурой предприятия
- Стандартизировать инженерные практики разработки
Связь с базовым Регламентом: Настоящий документ детализирует проектную методологию, определённую в разделах 4-7 базового Регламента (РГА-001).
| Результат | Целевой показатель |
|---|---|
| Средний срок проекта | ≤ 12 недель |
| Доля отклонённых на приёмке | ≤ 5% |
| Доля переиспользуемых компонентов | ≥ 40% |
1.2. Область применения и границы
Описание подраздела: Подраздел определяет организационные, процессные и технологические границы применения.
На какие подразделения, процессы, ИТ-системы, типы инициатив распространяется действие Регламента? Какие границы и исключения установлены?
Инструкция по заполнению:
Определите 3-4 критерия обязательного применения (бюджет, FTE, критичность). Укажите организационные единицы. Перечислите исключения с обоснованием.
Пример:
Критерии обязательного применения:
| Критерий | Пороговое значение |
|---|---|
| Бюджет проекта | ≥ 500 000 руб. |
| FTE-экономия | ≥ 0.5 FTE |
| Интеграция с ИС | ≥ 2 систем |
Исключения:
| Категория | Альтернативный порядок |
|---|---|
| Микроавтоматизация (до 200 тыс.) | Упрощённая процедура (Приложение А) |
| Пилотные PoC | Отдельный порядок |
| Срочные hotfix | Экстренный порядок |
1.3. Классы решений и квалификация инициатив
Описание подраздела: Подраздел устанавливает классификацию технологических решений и порядок квалификации.
Какие классы решений охватывает Регламент? Как проводится квалификация? Какие определения введены для разграничения «автоматизации» и «роботизации»?
Инструкция по заполнению:
Определите 5-7 классов решений с характеристиками. Установите критерии отнесения к классу. Приведите чёткие определения автоматизации vs роботизации.
Пример:
Классификация решений:
| Класс | Характеристика | Типовой срок |
|---|---|---|
| RPA | Автоматизация через UI | 6-10 недель |
| BPM/Workflow | Оркестрация с участием людей | 12-16 недель |
| Low-code/No-code | Минимальный код | 4-8 недель |
| OCR/IDP | Обработка документов | 8-12 недель |
| AI/ML | Машинное обучение | 12-20 недель |
| API-интеграция | Программные интерфейсы | 4-8 недель |
Разграничение:
| Аспект | Автоматизация | Роботизация (RPA) |
|---|---|---|
| Способ | API, БД, файлы | Пользовательский UI |
| Тип интеграции | Backend | Frontend |
1.4. Глоссарий проектных терминов
Описание подраздела: Подраздел закрепляет специфические термины, дополняющие глоссарий базового Регламента.
Какие ключевые понятия, термины, роли, артефакты и сокращения закреплены в глоссарии?
Инструкция по заполнению:
Приведите 15-20 терминов проектной методологии. Структурируйте по категориям: артефакты, этапы, роли, технические термины.
Пример:
Проектные артефакты:
| Термин | Определение |
|---|---|
| PDD | Process Definition Document — описание процесса AS-IS/TO-BE |
| SDD | Solution Design Document — техническое проектирование |
| BRD | Business Requirements Document — бизнес-требования |
| Runbook | Операционная инструкция для эксплуатации |
Проектные события:
| Термин | Определение |
|---|---|
| Gate Review | Контрольная точка с оценкой готовности к переходу |
| Hypercare | Период повышенной поддержки после Go-Live |
| Go/No-Go | Формальное решение о готовности к переходу |
Технические термины:
| Термин | Определение |
|---|---|
| Business Exception | Исключение из-за данных или бизнес-правил |
| System Exception | Техническая ошибка системы |
| Attended Robot | Робот под контролем пользователя |
| Unattended Robot | Автономный робот на сервере |
1.5. Иерархия нормативных документов
Описание подраздела: Подраздел определяет место Регламента в системе НМД и порядок разрешения коллизий.
На какие внешние и внутренние документы опирается Регламент? Какова иерархия и порядок разрешения коллизий?
Инструкция по заполнению:
Изобразите иерархию (4-5 уровней). Определите порядок приоритета. Укажите правила актуализации.
Пример:
Иерархия:
Уровень 1: Внешние регуляторные требования
↓
Уровень 2: Стратегия и политики организации
↓
Уровень 3: Базовый Регламент (РГА-001)
↓
Уровень 4: Настоящий Регламент (РГА-002)
↓
Уровень 5: Рабочие инструкции и шаблоны
Порядок разрешения коллизий:
- При противоречии с базовым — приоритет базового
- При противоречии с Политикой ИБ — приоритет ИБ
- Спорные вопросы — на Комитет по автоматизации
1.6. Обязательные принципы реализации проектов
Описание подраздела: Подраздел формулирует принципы с критериями проверки соответствия.
Какие принципы автоматизации/роботизации являются обязательными? Какие критерии соответствия применяются?
Инструкция по заполнению:
Сформулируйте 6-8 принципов. Для каждого укажите критерий проверки и точку контроля.
Пример:
| Принцип | Критерий | Точка контроля |
|---|---|---|
| Оптимизация до автоматизации | TO-BE содержит ≥2 улучшений | Gate Review Анализ |
| Архитектурное соответствие | Заключение ИТ-архитектора | Gate Review Проектирование |
| Переиспользование компонентов | ≥30% из библиотеки | Code Review |
| Security by Design | Чек-лист ИБ заполнен | Gate Review Проектирование |
| Полнота документирования | Чек-лист 100% | Gate Review Внедрение |
| Обработка исключений | Матрица заполнена, тесты OK | UAT |
GOVERNANCE И УПРАВЛЕНИЕ ПРОЕКТАМИ
Описание раздела: Раздел определяет модель управления проектами, органы принятия решений, порядок эскалации и контроля.
2.1. Владелец методологии и органы управления
Описание подраздела: Подраздел определяет должностных лиц и коллегиальные органы.
Кто является владельцем Регламента и методологии? Какова модель управления?
Инструкция по заполнению:
Укажите владельца и его обязанности (4-5 пунктов). Определите коллегиальные органы. Приведите схему governance.
Пример:
Владелец методологии: Директор по цифровой трансформации
Обязанности:
- Утверждение и актуализация Регламента
- Разрешение методологических споров
- Контроль эффективности на основе KPI
- Инициирование стратегических изменений
Органы управления:
| Орган | Полномочия | Периодичность |
|---|---|---|
| Комитет по автоматизации | Портфель, бюджет, стратегия | Ежемесячно |
| Архитектурный совет | Архитектурные решения | По запросу |
| Операционный комитет CoE | Приоритизация backlog | Еженедельно |
2.2. Порядок принятия проектных решений
Описание подраздела: Подраздел устанавливает правила принятия решений и уровни полномочий.
Какие решения требуют коллегиального рассмотрения? Каким органом и по каким правилам они принимаются?
Инструкция по заполнению:
Классифицируйте типы решений (3-4 уровня). Определите орган для каждого. Укажите сроки.
Пример:
| Тип решения | Орган/Лицо | Срок |
|---|---|---|
| Включение (бюджет > 3 млн) | Комитет | 10 р.д. |
| Включение (бюджет ≤ 3 млн) | Директор по ЦТ | 5 р.д. |
| Архитектурное согласование | Архитектурный совет | 5 р.д. |
| Согласование ИБ | Служба ИБ | 5 р.д. |
| Ввод в эксплуатацию | Владелец + CoE | 3 р.д. |
2.3. Контроль соответствия и аудит проектов
Описание подраздела: Подраздел определяет механизмы контроля соблюдения требований.
Как обеспечивается аудит и контроль соответствия Регламенту? Кто несёт ответственность за корректирующие мероприятия?
Инструкция по заполнению:
Определите виды контроля с периодичностью. Укажите чек-листы. Опишите порядок фиксации несоответствий.
Пример:
| Вид контроля | Периодичность | Исполнитель |
|---|---|---|
| Gate Review | На каждом этапе | Процессный офис |
| Code Review | Перед релизом | CoE RPA |
| Аудит документации | При завершении | Процессный офис |
| Выборочный аудит | Ежеквартально | Внутренний аудит |
2.4. Актуализация Регламента
Описание подраздела: Подраздел устанавливает порядок внесения изменений.
Каков порядок актуализации Регламента?
Инструкция по заполнению:
Укажите периодичность пересмотра. Определите триггеры (4-5 событий). Опишите процедуру согласования.
Пример:
| Параметр | Значение |
|---|---|
| Плановый пересмотр | Ежегодно, IV квартал |
| Экспертиза предложения | 5 р.д. |
| Согласование | 10 р.д. |
| Вступление в силу | Через 10 р.д. после утверждения |
Триггеры: изменение стратегии, новая платформа, системные проблемы (>3 инцидентов), регуляторные изменения.
2.5. Ответственность за нарушение требований
Описание подраздела: Подраздел определяет виды нарушений и меры ответственности.
Какая ответственность определена за нарушение требований Регламента?
Инструкция по заполнению:
Классифицируйте нарушения (3 категории). Определите санкции. Приведите примеры.
Пример:
| Категория | Примеры | Санкции |
|---|---|---|
| Критические | Запуск без ИБ; фальсификация | Взыскание; отстранение |
| Существенные | Пропуск Gate; неполная документация | Предупреждение; обучение |
| Незначительные | Отклонение от code style | Замечание; корректировка |
РОЛИ И МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ
Описание раздела: Раздел определяет проектные роли, их ответственность и модель взаимодействия.
3.1. Проектные роли и матрица ответственности
Описание подраздела: Подраздел детализирует роли с распределением по методологии RACI.
Какие роли участвуют в проектах? Какова матрица RACI на каждом этапе жизненного цикла?
Инструкция по заполнению:
Определите 10-12 ролей. Составьте матрицу RACI по этапам. Укажите требования к компетенциям.
Пример:
Проектные роли:
| Роль | Функции | Требования |
|---|---|---|
| Спонсор | Ресурсы, эскалация, приёмка | Уровень директора |
| PM | Сроки, бюджет, риски | Сертификация PM |
| Business Analyst | Требования, модели | BABOK, BPMN |
| Solution Architect | Архитектура, SDD | Enterprise Architecture |
| RPA-разработчик | Разработка, unit-тесты | Сертификация платформы |
| QA-инженер | Тест-кейсы, тестирование | Методологии QA |
Матрица RACI:
| Этап | Спонсор | PM | BA | Architect | Dev | QA |
|---|---|---|---|---|---|---|
| Инициация | A | R | C | I | I | I |
| Анализ | A | R | R | C | I | I |
| Проектирование | A | R | C | R | C | C |
| Разработка | I | R | C | C | R | C |
| Тестирование | I | R | C | C | C | R |
| Внедрение | A | R | C | C | R | C |
3.2. Центр компетенций (CoE) и полномочия
Описание подраздела: Подраздел определяет структуру и полномочия CoE.
Какова структура и полномочия Центра компетенций? Имеет ли он право вето?
Инструкция по заполнению:
Опишите структуру CoE (3-4 направления). Определите полномочия, включая право вето.
Пример:
Структура CoE:
- Группа методологии и архитектуры
- Группа разработки
- Группа эксплуатации
- Группа качества
Полномочия:
| Полномочие | Условия |
|---|---|
| Право вето | Процесс не оптимизирован; зрелость < 3 |
| Архитектурное согласование | Все проекты |
| Code Review | Перед каждым релизом |
| Ресурсное планирование | Еженедельно |
3.3. Владелец решения после закрытия проекта
Описание подраздела: Подраздел определяет порядок передачи ответственности.
Кто является владельцем решения после закрытия проекта? Кто несёт ответственность за данные?
Инструкция по заполнению:
Определите владельца и обязанности (5-6 пунктов). Разграничьте ответственность между владельцем, CoE и ИТ.
Пример:
Владелец: Владелец бизнес-процесса (BPO)
Обязанности:
- Контроль бизнес-эффектов и KPI
- Инициирование изменений
- Принятие решений об эскалации
- Ответственность за данные
- Инициирование вывода из эксплуатации
| Область | Владелец | CoE | ИТ |
|---|---|---|---|
| Бизнес-результаты | A | C | I |
| Работоспособность | C | R | C |
| Инфраструктура | I | C | A |
3.4. Требования к квалификации команды
Описание подраздела: Подраздел устанавливает минимальные требования к компетенциям.
Какие требования к квалификации участников проектной команды?
Инструкция по заполнению:
Определите требования для 5-6 ролей. Укажите сертификации и опыт.
Пример:
| Роль | Опыт | Сертификации |
|---|---|---|
| Solution Architect | ≥5 лет ИТ, ≥2 RPA | Платформа (Advanced), TOGAF |
| Senior Developer | ≥3 года RPA | Платформа (Advanced) |
| Developer | ≥1 год RPA | Платформа (Associate) |
| Business Analyst | ≥2 года BA | CBAP (желат.) |
| QA Engineer | ≥2 года QA | ISTQB (желат.) |
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
Описание раздела: Раздел определяет этапы жизненного цикла, критерии перехода (Gate Criteria) и контрольные точки.
4.1. Этапы жизненного цикла
Описание подраздела: Подраздел устанавливает последовательность этапов от инициации до закрытия.
Какие этапы жизненного цикла проекта устанавливаются — от инициации до закрытия и вывода из эксплуатации?
Инструкция по заполнению:
Определите 7-9 этапов с целями и результатами. Укажите типовую длительность. Приведите схему.
Пример:
| Этап | Цель | Результаты | Длительность |
|---|---|---|---|
| Инициация | Утверждение бизнес-кейса | Паспорт проекта | 1-2 нед. |
| Анализ | Изучение AS-IS/TO-BE | PDD, BRD | 2-3 нед. |
| Проектирование | Архитектура решения | SDD | 1-2 нед. |
| Разработка | Создание решения | Код, unit-тесты | 3-5 нед. |
| Тестирование | Верификация качества | Протоколы, UAT | 2-3 нед. |
| Внедрение | Развёртывание в PROD | Акт ввода | 1 нед. |
| Hypercare | Стабилизация | Подтверждение | 2-4 нед. |
| Эксплуатация | Штатная работа | KPI | Бессрочно |
| Закрытие/Вывод | Завершение | Lessons Learned | 1-2 нед. |
Схема:
[Инициация]→[Анализ]→[Проектирование]→[Разработка]→[Тестирование]→[Внедрение]→[Hypercare]→[Эксплуатация]
↓ ↓ ↓ ↓ ↓ ↓ ↓
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5 Gate 6 [Вывод]
4.2. Критерии перехода между этапами (Gate Criteria)
Описание подраздела: Подраздел определяет обязательные критерии для перехода на следующий этап.
Какие критерии готовности (Gate Criteria) должны быть выполнены для перехода между этапами?
Инструкция по заполнению:
Для каждого Gate определите 4-6 критериев. Укажите артефакты. Определите процедуру Gate Review.
Пример:
Gate 1: Инициация → Анализ
| Критерий | Артефакт | Ответственный |
|---|---|---|
| Паспорт утверждён | Подписанный Паспорт | Спонсор |
| Ресурсы выделены | Приказ | PM |
| Команда сформирована | Матрица ресурсов | PM |
| Kick-off проведён | Протокол | PM |
Gate 2: Анализ → Проектирование
| Критерий | Артефакт | Ответственный |
|---|---|---|
| PDD согласован | Подписанный PDD | BA |
| Модели AS-IS/TO-BE утверждены | Модели в репозитории | BA |
| Реестр исключений заполнен | Реестр | BA |
| Оптимизация подтверждена | Заключение | Процессный офис |
Gate 3: Проектирование → Разработка
| Критерий | Артефакт | Ответственный |
|---|---|---|
| SDD согласован | Подписанный SDD | Architect |
| Архитектурное согласование | Заключение | ИТ-архитектор |
| Согласование ИБ | Заключение ИБ | Служба ИБ |
| Среда подготовлена | Акт готовности | Администратор |
Gate 4: Разработка → Тестирование
| Критерий | Артефакт | Ответственный |
|---|---|---|
| Code Review пройден | Отчёт | Lead Developer |
| Unit-тесты OK | Отчёт | Разработчик |
| Код в репозитории | Merge | Разработчик |
| Тест-план согласован | План | QA |
Gate 5: Тестирование → Внедрение
| Критерий | Артефакт | Ответственный |
|---|---|---|
| Функциональное тестирование OK | Протокол | QA |
| UAT пройден | Протокол, Sign-off | SME |
| Critical дефектов нет | Отчёт Jira | QA |
| Документация готова | Runbook | Разработчик |
Gate 6: Внедрение → Hypercare
| Критерий | Артефакт | Ответственный |
|---|---|---|
| Решение в PROD | Акт развёртывания | Администратор |
| Мониторинг настроен | Подтверждение | Администратор |
| Пользователи обучены | Журнал | PM |
| Акт ввода подписан | Акт | Владелец |
ПОРТФЕЛЬ ИНИЦИАТИВ И ПРИОРИТИЗАЦИЯ
Описание раздела: Раздел определяет порядок формирования, управления и приоритизации портфеля.
5.1. Управление портфелем инициатив
Описание подраздела: Подраздел устанавливает правила формирования и управления портфелем.
Как формируется и управляется портфель инициатив по автоматизации/роботизации?
Инструкция по заполнению:
Опишите воронку (5-6 статусов). Определите правила перехода. Укажите метрики портфеля.
Пример:
| Статус | Описание | Критерий перехода |
|---|---|---|
| Идея | Заявка поступила | Регистрация |
| Квалификация | Первичная экспертиза | Соответствие критериям |
| Оценка | Бизнес-кейс | ROI ≥ 100% |
| Приоритизация | Ранжирование | Решение Комитета |
| В реализации | Проект запущен | Приказ |
| Завершён | Проект закрыт | Акт ввода |
5.2. Процедура подачи и рассмотрения заявки
Описание подраздела: Подраздел определяет порядок подачи заявки и её рассмотрения.
Кто имеет право инициировать заявку? Какие входные данные обязательны? Каков порядок рассмотрения?
Инструкция по заполнению:
Определите круг лиц. Приведите обязательные поля заявки. Опишите процедуру (6-8 шагов) с SLA.
Пример:
Право инициации: Владелец процесса, руководитель подразделения (начальник отдела+)
Обязательные поля:
| Поле | Пример |
|---|---|
| Наименование процесса | Обработка входящих счетов |
| Описание проблемы | Ручной ввод 200+ счетов/день |
| Ожидаемый эффект | Экономия 2 FTE |
| Объём операций | 4500 счетов/месяц |
Процедура:
| Шаг | Действие | Исполнитель | SLA |
|---|---|---|---|
| 1 | Подача заявки | Инициатор | — |
| 2 | Регистрация | Процессный офис | 1 р.д. |
| 3 | Первичная экспертиза | Процессный офис | 3 р.д. |
| 4 | Техническая экспертиза | CoE RPA | 5 р.д. |
| 5 | Расчёт бизнес-кейса | ПО + Финансы | 5 р.д. |
| 6 | Приоритизация | Комитет | 5 р.д. |
5.3. Критерии готовности процесса-кандидата
Описание подраздела: Подраздел устанавливает минимальные критерии для включения в портфель.
Какие минимальные критерии должен выполнить «процесс-кандидат»? Какие «красные флаги» блокируют запуск?
Инструкция по заполнению:
Определите 8-10 критериев с пороговыми значениями. Укажите «красные флаги». Приведите скоринговую модель.
Пример:
| Критерий | Пороговое значение | Вес |
|---|---|---|
| Регламентированность | Процесс описан в НМД | 15% |
| Стабильность | Изменения ≤ 2 раз/год | 12% |
| Объём транзакций | ≥ 300/месяц | 10% |
| Структурированность данных | ≥ 80% в электронном виде | 12% |
| Формализуемость правил | ≥ 90% по чётким правилам | 15% |
| Уровень исключений | ≤ 15% нетиповых | 10% |
«Красные флаги»:
| Условие | Действие |
|---|---|
| Процесс не описан | Направить на описание |
| Изменения чаще 1 раза/месяц | Отложить |
| ROI < 50% | Искать альтернативы |
| Юридические ограничения | Частичная автоматизация |
5.4. Оценка зрелости и готовности среды
Описание подраздела: Подраздел определяет методику оценки зрелости процесса.
Как оценивается зрелость процесса и готовность среды? Какие действия при недостаточной зрелости?
Инструкция по заполнению:
Приведите модель зрелости (5 уровней). Определите минимальный уровень. Опишите план действий при недостаточной зрелости.
Пример:
| Уровень | Характеристика | Пригодность |
|---|---|---|
| 1 - Начальный | Хаотично, нет документации | Не пригоден |
| 2 - Повторяемый | Базовое описание | Требуется стандартизация |
| 3 - Определённый | Стандартизирован, есть регламент | Пригоден с оговорками |
| 4 - Управляемый | Есть метрики, контроль | Рекомендуется |
| 5 - Оптимизируемый | Непрерывное улучшение | Приоритет |
Минимальный уровень: 3 (Определённый)
5.5. Методика приоритизации
Описание подраздела: Подраздел устанавливает критерии и веса для ранжирования.
Какие критерии приоритизации используются и как они взвешиваются?
Инструкция по заполнению:
Определите 5-7 критериев с весами. Опишите шкалу. Укажите формулу расчёта.
Пример:
| Критерий | Вес | Шкала |
|---|---|---|
| ROI | 25% | 1: <50%, 5: >200% |
| Срок окупаемости | 20% | 1: >24 мес., 5: <6 мес. |
| Стратегическая значимость | 20% | 1: низкая, 5: критическая |
| Техническая готовность | 15% | 1: требует НИОКР, 5: типовое |
| Риски | 10% | 1: высокие, 5: минимальные |
| Готовность заказчика | 10% | 1: не вовлечён, 5: полная |
Формула: Приоритет = Σ (Оценкаᵢ × Весᵢ)
| Балл | Категория | Действие |
|---|---|---|
| 4.0-5.0 | P1 | Немедленный запуск |
| 3.0-3.9 | P2 | Плановая реализация |
| 2.0-2.9 | P3 | Backlog |
| <2.0 | P4 | Отложено |
5.6. Расчёт бизнес-кейса и защита паспорта
Описание подраздела: Подраздел определяет методику расчёта эффекта и порядок защиты.
Как рассчитывается экономический эффект и стоимость владения? Каков порядок защиты бизнес-кейса?
Инструкция по заполнению:
Приведите формулы (ROI, TCO, FTE, Payback). Укажите источники данных. Опишите процедуру защиты.
Пример:
| Показатель | Формула |
|---|---|
| FTE-экономия | (Время × Кол-во × 12) / 1920 |
| Годовая экономия | FTE × Стоимость FTE |
| TCO (3 года) | Внедрение + 3 × Ежегодные |
| ROI | (Экономия − Затраты) / Инвестиции × 100% |
| Payback | Инвестиции / (Экономия − Затраты) × 12 |
Процедура защиты:
- Подготовка Паспорта (PM, BA, CoE)
- Внутренняя экспертиза (ПО)
- Защита на Комитете
- Принятие решения
- Оформление запуска
ВЫБОР ТЕХНОЛОГИИ И АРХИТЕКТУРА
Описание раздела: Раздел определяет критерии выбора технологии, порядок архитектурного согласования и требования к средам.
6.1. Критерии выбора технологического подхода
Описание подраздела: Подраздел устанавливает правила выбора между технологиями.
Какие критерии применяются для выбора: RPA vs BPM vs доработка ИС vs API-интеграция?
Инструкция по заполнению:
Разработайте дерево решений. Определите 6-8 критериев сравнения. Приведите матрицу применимости.
Пример:
| Характеристика | RPA | BPM | Low-code | API |
|---|---|---|---|---|
| Legacy без API | ✅ | ❌ | ❌ | ❌ |
| Участие людей | ⚠️ | ✅ | ✅ | ❌ |
| Частые изменения | ❌ | ✅ | ✅ | ⚠️ |
| Объём >10000/день | ⚠️ | ⚠️ | ⚠️ | ✅ |
| Быстрый TTM | ✅ | ⚠️ | ✅ | ⚠️ |
6.2. Архитектурное согласование
Описание подраздела: Подраздел определяет порядок согласования архитектуры.
Как определяется целевая архитектура? Как проводится согласование с ИТ-ландшафтом?
Инструкция по заполнению:
Опишите процедуру (5-6 шагов). Определите критерии обязательного согласования ARB. Приведите чек-лист.
Пример:
| Шаг | Действие | Срок |
|---|---|---|
| 1 | Подготовка SDD | — |
| 2 | Подача запроса | 1 р.д. |
| 3 | Первичный анализ | 2 р.д. |
| 4 | Заседание ARB (при необходимости) | 3 р.д. |
| 5 | Выдача заключения | 1 р.д. |
Критерии обязательного ARB:
- Интеграция с ≥3 системами
- Нестандартные технологии
- Обработка ПДн
- Критичность уровня 1-2
6.3. Требования к средам и релизный процесс
Описание подраздела: Подраздел устанавливает требования к контурам и релизам.
Какие требования к средам (Dev/Test/Preprod/Prod)? Как регламентируется релизный процесс?
Инструкция по заполнению:
Определите характеристики каждой среды. Опишите процедуру продвижения. Укажите правила Configuration Management.
Пример:
| Среда | Назначение | Данные | Доступ |
|---|---|---|---|
| DEV | Разработка | Синтетические | Разработчики |
| TEST | Тестирование | Обезличенные | Dev, QA |
| UAT | Приёмка | Обезличенные | QA, SME |
| PROD | Эксплуатация | Реальные | Оркестратор |
Релизный процесс:
[DEV] --Code Review--> [TEST] --QA Sign-off--> [UAT] --UAT Sign-off + CR--> [PROD]
АНАЛИЗ И ПРОЕКТИРОВАНИЕ
Описание раздела: Раздел определяет требования к артефактам, стандарты моделирования и правила обработки исключений.
7.1. Обязательные артефакты
Описание подраздела: Подраздел устанавливает состав, структуру и требования к артефактам.
Какие артефакты обязательны? Каков стандарт структуры PDD и SDD?
Инструкция по заполнению:
Определите 6-8 документов. Приведите структуру PDD и SDD (10-15 разделов). Укажите правила согласования.
Пример:
| Артефакт | Этап | Согласующие |
|---|---|---|
| PDD | Анализ | Владелец, SME, ПО |
| BRD | Анализ | Владелец, Architect |
| Реестр исключений | Анализ | SME, Architect |
| SDD | Проектирование | ИТ-архитектор, ИБ |
| Матрица интеграций | Проектирование | ИТ-архитектор |
Структура PDD:
- Общие сведения
- Описание AS-IS
- Входы и выходы
- Участники и роли
- Информационные системы
- Бизнес-правила
- Описание TO-BE
- Границы автоматизации
- Реестр исключений
- Метрики и KPI
Структура SDD:
- Общие сведения
- Архитектура решения
- Компоненты
- Модель данных
- Интеграции
- Обработка исключений
- Безопасность
- Производительность
- Развёртывание
- Зависимости
7.2. Стандарты моделирования процессов
Описание подраздела: Подраздел устанавливает требования к нотации и качеству моделей.
В какой нотации и с какой глубиной описываются модели AS-IS и TO-BE?
Инструкция по заполнению:
Укажите нотацию. Определите уровень детализации. Опишите процедуру валидации.
Пример:
| Параметр | Требование |
|---|---|
| Нотация | BPMN 2.0 |
| Инструмент | [Корпоративный BPMS] или Visio |
| Детализация | До операций от 30 сек. |
| Разделение ролей | Пулы/дорожки человек/робот |
Для RPA обязателен уровень L5 (атомарные действия).
7.3. Оптимизация перед автоматизацией
Описание подраздела: Подраздел определяет обязательность оптимизации.
Обязателен ли этап оптимизации перед автоматизацией? Что считается допустимой оптимизацией?
Инструкция по заполнению:
Установите правило. Определите границы допустимой оптимизации. Опишите критерии эскалации на реинжиниринг.
Пример:
Правило: Модель TO-BE должна содержать ≥2 улучшений относительно AS-IS.
| Вид | Допустимость |
|---|---|
| Устранение дублирования | ✅ |
| Параллелизация операций | ✅ |
| Упрощение маршрутизации | ✅ |
| Изменение оргструктуры | ❌ |
| Доработка ИС | Отдельный проект |
7.4. Проектирование обработки исключений
Описание подраздела: Подраздел устанавливает требования к обработке исключений.
Как фиксируются требования к обработке Business Exceptions и System Exceptions?
Инструкция по заполнению:
Определите классификацию (2-3 типа). Укажите атрибуты реестра. Опишите стандартные паттерны.
Пример:
| Тип | Определение | Обработка |
|---|---|---|
| Business Exception | Данные/правила | Очередь ручной обработки |
| System Exception | Техническая ошибка | Повторы (3), эскалация |
| Application Exception | Ошибка RPA | Скриншот, перезапуск |
Структура реестра:
| ID | Тип | Описание | Условие | Обработка | Эскалация |
|---|
7.5. Трассируемость требований
Описание подраздела: Подраздел определяет требования к трассируемости.
Как обеспечивается трассируемость от бизнес-кейса до тестов?
Инструкция по заполнению:
Опишите модель трассируемости. Определите инструмент. Приведите пример матрицы.
Пример:
Модель:
Бизнес-цель → Требование → Компонент → Тест-кейс → Результат
| Цель | Требование | Компонент | Тест | Статус |
|---|---|---|---|---|
| Сокращение времени 80% | REQ-001 | COMP-001 | TC-001 | Passed |
РАЗРАБОТКА И ИНЖЕНЕРНЫЕ СТАНДАРТЫ
Описание раздела: Раздел определяет стандарты разработки, управления версиями и качества кода.
8.1. Стандарты разработки
Описание подраздела: Подраздел устанавливает обязательные стандарты кодирования.
Какие стандарты разработки обязательны? Как обеспечивается их соблюдение?
Инструкция по заполнению:
Определите 8-10 стандартов. Опишите механизм контроля. Приведите чек-лист Code Review.
Пример:
| Стандарт | Описание | Контроль |
|---|---|---|
| Naming Conventions | PascalCase/camelCase | Code Review |
| Структура проекта | Main, Exceptions, Utilities | Code Review |
| Модульность | 1 компонент = 1 функция | Code Review |
| REFramework | Для транзакционных процессов | Code Review |
| Exception Handling | Try-Catch для внешних вызовов | Автотесты |
| Logging | Start, End, Exception, Key Steps | Автотесты |
| Config Externalization | Параметры в config | Автотесты |
| No Hardcoded Credentials | Только Credential Vault | Code Review |
8.2. Управление версиями
Описание подраздела: Подраздел определяет правила работы с VCS.
Как организуется управление версиями, кодом и пакетами?
Инструкция по заполнению:
Укажите VCS. Опишите стратегию ветвления. Определите правила Merge Request.
Пример:
VCS: Git ([Корпоративный GitLab])
| Ветка | Назначение | Правила |
|---|---|---|
| main | Продуктив | Только через MR после UAT |
| develop | Интеграция | Merge после Code Review |
| feature/{ID} | Разработка | От develop |
| release/{ver} | Подготовка релиза | Для UAT |
| hotfix/{ID} | Срочные исправления | От main |
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
Описание раздела: Раздел определяет требования ИБ к проектам.
9.1. Требования ИБ к проектам
Описание подраздела: Подраздел устанавливает требования ИБ по этапам проекта.
Какие требования ИБ обязательны? Кто проводит контроль?
Инструкция по заполнению:
Определите 8-10 требований. Укажите этап проверки. Опишите процедуру согласования.
Пример:
| Этап | Требование | Артефакт |
|---|---|---|
| Анализ | Классификация данных | Раздел PDD |
| Проектирование | Управление доступом | SDD |
| Проектирование | Хранение credentials | SDD |
| Разработка | Credential Vault | Code Review |
| Тестирование | Обезличивание данных | Акт |
| Внедрение | Отдельные УЗ для сред | Заявка |
9.2. Управление учётными записями роботов
Описание подраздела: Подраздел определяет жизненный цикл УЗ.
Как организуется управление учётными записями роботов?
Инструкция по заполнению:
Опишите жизненный цикл (4-5 этапов). Укажите правила именования.
Пример:
| Этап | Действие | Срок |
|---|---|---|
| Создание | Заявка ЗУЗ-01 | 3 р.д. |
| Назначение прав | Заявка на доступ | 2 р.д./система |
| Ротация пароля | Автоматически | 90 дней |
| Блокировка | При инциденте | 4 часа |
| Удаление | При выводе | 5 р.д. |
Формат: svc_rpa_{подразделение}{процесс}{среда}
ТЕСТИРОВАНИЕ И ПРИЁМКА
Описание раздела: Раздел определяет виды тестирования, порядок UAT и критерии приёмки.
10.1. Виды и критерии тестирования
Описание подраздела: Подраздел устанавливает обязательные виды тестирования.
Какие виды тестирования обязательны и блокирующие для PROD?
Инструкция по заполнению:
Определите 5-6 видов. Укажите критерии прохождения. Определите минимальное покрытие.
Пример:
| Вид | Цель | Критерий | Блокирует |
|---|---|---|---|
| Unit | Компоненты | 100%, 0 ошибок | Да |
| Функциональное | Требования | 100%, 0 Critical | Да |
| Интеграционное | Взаимодействие ИС | Все проверены | Да |
| Регрессионное | После изменений | Базовые OK | Да |
| UAT | Приёмка бизнесом | Sign-off | Да |
10.2. Работа с тестовыми данными
Описание подраздела: Подраздел определяет требования к тестовым данным.
Как организуется работа с тестовыми данными и обезличивание?
Инструкция по заполнению:
Определите категории данных. Опишите процедуру обезличивания.
Пример:
| Категория | Среды | Обезличивание |
|---|---|---|
| Синтетические | DEV | Не требуется |
| Обезличенные | TEST, UAT | Обязательно |
| Продуктивные | Только PROD | — |
| Тип данных | Метод маскирования |
|---|---|
| ФИО | Замена на случайные |
| ИНН | Генерация фиктивного |
| Телефон | Маска +7916*4567 |
| Замена домена |
10.3. Порядок проведения UAT
Описание подраздела: Подраздел определяет процедуру UAT.
Каков порядок UAT? Каковы критерии успешности?
Инструкция по заполнению:
Опишите процедуру (5-7 шагов). Определите критерии успешности.
Пример:
| Шаг | Действие | Ответственный | Срок |
|---|---|---|---|
| 1 | Подготовка сценариев | QA + SME | 5 р.д. до UAT |
| 2 | Согласование | BA | 2 р.д. |
| 3 | Подготовка среды | QA + Admin | 2 р.д. |
| 4 | Проведение UAT | SME | 3-5 р.д. |
| 5 | Фиксация результатов | QA | 1 р.д. |
| 6 | Sign-off | SME | 1-2 р.д. |
Критерии успешности: 0 Critical, 0 Major (или workaround), ≤5 Minor
10.4. Управление дефектами
Описание подраздела: Подраздел устанавливает классификацию и SLA.
Как фиксируются дефекты и управляются исправления?
Инструкция по заполнению:
Определите классификацию (4 приоритета). Укажите SLA. Опишите жизненный цикл.
Пример:
| Приоритет | Описание | SLA | Влияние |
|---|---|---|---|
| Critical | Блокирует основной сценарий | 4 часа | Блокирует Sign-off |
| Major | Существенное отклонение | 8 часов | Блокирует |
| Minor | Есть workaround | 3 р.д. | Может быть отложен |
| Trivial | Косметика | 5 р.д. | Может быть отложен |
ВВОД В ЭКСПЛУАТАЦИЮ И HYPERCARE
Описание раздела: Раздел определяет критерии Go/No-Go, процедуру ввода и Hypercare.
11.1. Критерии готовности к вводу в эксплуатацию
Описание подраздела: Подраздел устанавливает критерии Go/No-Go.
Каковы критерии готовности к вводу в эксплуатацию (Go/No-Go)?
Инструкция по заполнению:
Определите 10-12 критериев. Приведите чек-лист.
Пример:
| Критерий | Подтверждение |
|---|---|
| UAT Sign-off | Протокол |
| Critical дефектов нет | Отчёт Jira |
| Согласование ИБ | Заключение |
| Архитектурное согласование | Заключение |
| Документация передана | Чек-лист |
| Пользователи обучены | Журнал |
| Мониторинг настроен | Подтверждение |
| План отката согласован | Документ |
| Change Request утверждён | CR в системе |
| УЗ PROD созданы | Подтверждение |
11.2. Период Hypercare
Описание подраздела: Подраздел определяет режим Hypercare.
Как регламентируется период Hypercare?
Инструкция по заполнению:
Определите длительность и режим. Укажите критерии выхода. Опишите роли.
Пример:
| Параметр | Значение |
|---|---|
| Длительность | 2-4 недели |
| Режим поддержки | 8:00-22:00 |
| SLA на реакцию | Critical: 15 мин |
Критерии выхода:
| Критерий | Значение | Период |
|---|---|---|
| Успешность | ≥ 95% | Последние 7 дней |
| Critical инциденты | 0 | За весь период |
| Ручные вмешательства | ≤ 5% | Последние 7 дней |
11.3. Регламент развёртывания
Описание подраздела: Подраздел определяет порядок деплоя.
Каков регламент переноса между средами? Кто имеет право на деплой в PROD?
Инструкция по заполнению:
Опишите процедуру (5-6 шагов). Укажите право на деплой. Определите процедуру отката.
Пример:
| Шаг | Действие | Исполнитель |
|---|---|---|
| 1 | Проверка CR | Администратор |
| 2 | Backup текущей версии | Администратор |
| 3 | Развёртывание | Администратор |
| 4 | Конфигурация | Администратор |
| 5 | Smoke-тест | QA |
| 6 | Активация расписания | Администратор |
Право на деплой: Администраторы RPA (именной список) Окно: Рабочие дни, 18:00-22:00
11.4. Комплект документации
Описание подраздела: Подраздел определяет состав документации.
Какая документация должна быть передана в эксплуатацию?
Инструкция по заполнению:
Определите перечень (8-10 документов). Приведите чек-лист.
Пример:
| Документ | Назначение | Разработчик |
|---|---|---|
| Runbook | Операционные инструкции | Разработчик |
| Инструкция пользователя | Работа с роботом | BA |
| Инструкция администратора | Настройка | Администратор |
| Схема интеграций | Взаимосвязи | Architect |
| Паспорт робота | Для реестра | PM |
| Реестр исключений | Нештатные ситуации | BA |
| План отката | Критические сбои | Администратор |
| Контакты эскалации | Матрица | PM |
11.5. Обучение пользователей
Описание подраздела: Подраздел определяет порядок обучения.
Каков порядок обучения пользователей и переобучения сотрудников?
Инструкция по заполнению:
Определите категории обучаемых. Опишите форматы. Укажите критерии успеха.
Пример:
| Категория | Содержание | Формат | Длительность |
|---|---|---|---|
| Пользователи | Взаимодействие | E-learning | 2 часа |
| Операторы | Обработка ошибок | Практикум | 4 часа |
| Администраторы | Мониторинг | Техническое | 8 часов |
ЭКСПЛУАТАЦИЯ И УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
Описание раздела: Раздел определяет порядок поддержки, управления инцидентами и изменениями.
12.1. Модель поддержки
Описание подраздела: Подраздел определяет уровни поддержки.
Как организуется поддержка? Как распределяется ответственность?
Инструкция по заполнению:
Определите 3 уровня с SLA. Укажите распределение. Опишите эскалацию.
Пример:
| Уровень | Функции | Исполнитель | SLA |
|---|---|---|---|
| L1 | Мониторинг, перезапуск | Service Desk + Admin | 30 мин |
| L2 | Анализ, конфигурация | CoE RPA | 4 часа |
| L3 | Доработка кода | CoE RPA (Senior) | 8 часов |
12.2. Управление инцидентами
Описание подраздела: Подраздел определяет процедуру обработки инцидентов.
Как управляются инциденты и исключения выполнения?
Инструкция по заполнению:
Опишите процедуру (5-6 шагов). Укажите правила RCA.
Пример:
| Шаг | Действие | Исполнитель | Срок |
|---|---|---|---|
| 1 | Обнаружение | Мониторинг | — |
| 2 | Регистрация | L1 | 15 мин |
| 3 | Диагностика | L1 | 30 мин |
| 4 | Эскалация | L1 → L2 | По SLA |
| 5 | Решение | L2/L3 | По SLA |
| 6 | RCA (Major/Critical) | L2/L3 | 5 р.д. |
12.3. Управление изменениями
Описание подраздела: Подраздел определяет процедуру изменений.
Как регламентируется управление изменениями?
Инструкция по заполнению:
Классифицируйте изменения (3 типа). Опишите процедуру.
Пример:
| Тип | Примеры | Процедура | Тестирование |
|---|---|---|---|
| Standard | Расписание, конфиг | Уведомление | Smoke |
| Normal | Бизнес-логика | Полный CR | Полное |
| Emergency | Критическая ошибка | Ускоренное | Минимальное |
12.4. Обеспечение непрерывности
Описание подраздела: Подраздел определяет требования к непрерывности.
Как обеспечивается непрерывность при сбоях автоматизации?
Инструкция по заполнению:
Определите RTO/RPO. Опишите fallback-процедуры.
Пример:
| Критичность | RTO | RPO | Fallback |
|---|---|---|---|
| Критический | 2 часа | 15 мин | Ручной режим |
| Высокий | 4 часа | 1 час | Ручной режим |
| Средний | 8 часов | 4 часа | Отложенная обработка |
МАСШТАБИРОВАНИЕ И ТИРАЖИРОВАНИЕ
Описание раздела: Раздел определяет критерии и процедуры тиражирования.
13.1. Критерии и процедуры тиражирования
Описание подраздела: Подраздел устанавливает правила тиражирования.
Как регламентируется тиражирование и масштабирование?
Инструкция по заполнению:
Определите критерии пригодности. Опишите процедуру.
Пример:
| Критерий | Требование |
|---|---|
| Стабильность | ≥ 98% за 3 месяца |
| Модульность | ≥ 70% переиспользуемых |
| Документированность | Полный комплект |
| Параметризуемость | Настройка через конфиг |
Процедура:
- Анализ применимости (1-2 нед.)
- Адаптация конфигурации (1 нед.)
- Тестирование (1-2 нед.)
- Обучение (1 нед.)
- Запуск + Hypercare (2 нед.)
УПРАВЛЕНИЕ ЗНАНИЯМИ
Описание раздела: Раздел определяет порядок фиксации и распространения знаний.
14.1. База знаний и Lessons Learned
Описание подраздела: Подраздел устанавливает структуру базы знаний.
Как организуется управление знаниями? Как фиксируется опыт?
Инструкция по заполнению:
Опишите структуру базы. Определите процедуру Lessons Learned.
Пример:
Структура:
База знаний RPA/
├── Методология/ (Регламенты, Шаблоны, Стандарты)
├── Решения/ [По подразделениям]/ [Решение]/ (Документация, LL)
├── Компоненты/ (Библиотека переиспользования)
└── FAQ и Troubleshooting/
Процедура LL:
| Когда | Что | Кто |
|---|---|---|
| Завершение этапа | Краткие заметки | PM |
| Закрытие проекта | Полная сессия | Команда |
| PIR (3/6/12 мес.) | Дополнение | ПО |
КОНТРОЛЬ ЭФФЕКТОВ И KPI
Описание раздела: Раздел определяет систему показателей и пост-проектный аудит.
15.1. Контроль достижения эффектов
Описание подраздела: Подраздел устанавливает процедуру мониторинга эффектов.
Как проводится контроль достижения эффектов? С какой периодичностью постаудит?
Инструкция по заполнению:
Определите периодичность. Укажите сравниваемые показатели. Опишите корректирующие действия.
Пример:
| Срок | Фокус | Ответственный |
|---|---|---|
| 1 месяц | Стабильность | CoE RPA |
| 3 месяца | Операционные KPI | ПО |
| 6 месяцев | Экономический эффект 50% | ПО |
| 12 месяцев | Полный ROI | ПО + Финансы |
Корректирующие действия:
| Отклонение | Действие |
|---|---|
| ROI < 80% | Анализ, план оптимизации |
| ROI < 50% | Эскалация на Комитет |
| Стабильность < 90% | Приоритетное устранение |
15.2. Система KPI
Описание подраздела: Подраздел определяет показатели проектов и CoE.
Какие KPI используются? Какие KPI для CoE?
Инструкция по заполнению:
Определите 8-10 KPI проектов. Укажите 5-6 KPI CoE.
Пример:
KPI проектов:
| KPI | Формула | Цель |
|---|---|---|
| Соблюдение сроков | Факт/План | ≥ 90% |
| Соблюдение бюджета | Факт/План | ≤ 110% |
| Достижение ROI | Факт/План | ≥ 80% |
| Успешность UAT | Passed/Total | ≥ 95% |
KPI CoE:
| KPI | Цель | Периодичность |
|---|---|---|
| Количество внедрений | План | Квартал |
| Среднее время проекта | ≤ 12 недель | Квартал |
| Утилизация команды | 70-85% | Месяц |
| Переиспользование | ≥ 40% | Квартал |
| Удовлетворённость | ≥ 4.0/5.0 | Квартал |
ЗАКРЫТИЕ ПРОЕКТА И ВЫВОД ИЗ ЭКСПЛУАТАЦИИ
Описание раздела: Раздел определяет процедуры закрытия и вывода решений.
16.1. Закрытие проекта
Описание подраздела: Подраздел устанавливает процедуру закрытия.
Как регламентируется закрытие проекта?
Инструкция по заполнению:
Опишите процедуру (5-6 шагов). Приведите чек-лист.
Пример:
| Шаг | Действие | Результат |
|---|---|---|
| 1 | Подтверждение выхода из Hypercare | Акт |
| 2 | Сессия Lessons Learned | Отчёт |
| 3 | Финализация документации | Комплект |
| 4 | Передача на сопровождение | Акт приёма |
| 5 | Архивирование артефактов | Архив |
| 6 | Закрытие в системе | Статус |
16.2. Вывод из эксплуатации
Описание подраздела: Подраздел определяет порядок decommissioning.
Каков порядок вывода решения из эксплуатации?
Инструкция по заполнению:
Определите основания. Опишите процедуру (6-8 шагов).
Пример:
| Основание | Инициатор |
|---|---|
| Процесс упразднён | Владелец |
| Реализовано в ИС | ИТ-архитектор |
| ROI < 0 | ПО |
| Устаревание платформы | CoE |
Процедура:
- Инициация и обоснование
- Согласование (5 р.д.)
- План перехода (10 р.д.)
- Уведомление (за 10 р.д.)
- Остановка робота
- Отзыв доступов (5 р.д.)
- Архивирование (5 р.д.)
- Утилизация лицензий (5 р.д.)
ДОПОЛНИТЕЛЬНЫЕ АСПЕКТЫ
17.1. ESG-аспекты
Описание подраздела: Подраздел определяет учёт ESG-факторов.
Как учитываются ESG-аспекты в проектах автоматизации?
Инструкция по заполнению:
Определите применимые критерии. Опишите меры по социальным аспектам (высвобождение).
Пример:
| Аспект | Критерий | Мера |
|---|---|---|
| E | Энергоэффективность | Оптимизация расписания |
| E | Сокращение бумаги | Учёт в бизнес-кейсе |
| S | Влияние на персонал | План переквалификации при >1 FTE |
| G | Прозрачность | Полное логирование |
ПРИЛОЖЕНИЯ
Перечень приложений
Какие приложения обязательны к Регламенту?
Инструкция по заполнению:
Приведите перечень (15-20 документов). Укажите код, наименование, назначение.
Пример:
| Код | Наименование | Этап |
|---|---|---|
| РГА-П01 | Заявка на автоматизацию | Инициация |
| РГА-П02 | Паспорт проекта | Инициация |
| РГА-П03 | Шаблон PDD | Анализ |
| РГА-П04 | Шаблон BRD | Анализ |
| РГА-П05 | Реестр исключений | Анализ |
| РГА-П06 | Шаблон SDD | Проектирование |
| РГА-П07 | Чек-лист архитектуры | Проектирование |
| РГА-П08 | Чек-лист ИБ | Проектирование |
| РГА-П09 | Чек-лист Code Review | Разработка |
| РГА-П10 | Шаблон тест-плана | Тестирование |
| РГА-П11 | Шаблон тест-кейса | Тестирование |
| РГА-П12 | Протокол тестирования | Тестирование |
| РГА-П13 | Протокол UAT | Тестирование |
| РГА-П14 | Чек-лист готовности | Внедрение |
| РГА-П15 | Акт ввода | Внедрение |
| РГА-П16 | Заявка на УЗ робота | Внедрение |
| РГА-П17 | Шаблон Runbook | Внедрение |
| РГА-П18 | Паспорт робота | Внедрение |
| РГА-П19 | Шаблон Lessons Learned | Закрытие |
| РГА-П20 | Акт вывода | Вывод |