Свяжитесь с нами

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

Документ охватывает модель governance и органы принятия решений, жизненный цикл с Gate Criteria, методику приоритизации портфеля и расчёта бизнес-кейса, стандарты разработки и управления версиями, полный цикл тестирования, требования ИБ, порядок Hypercare, управление инцидентами и изменениями, систему KPI, а также процедуры тиражирования, управления знаниями и закрытия проектов.

Скачать материал бесплатно

Данные не найдены
Это требование закона о рекламе. Мы не спамим — вы всегда можете отписаться.
Файл отправим по почте
42страницы готового документа
3месяца экономии времени
48раз скачано

Что внутри шаблона:

1
Жизненный цикл проекта (9 этапов) и Gate Criteria
2
Модель governance: Комитет, CoE, Архитектурный совет и матрица RACI
3
Скоринговая модель приоритизации и методика расчёта FTE, ROI, TCO, Payback
4
Стандарты артефактов: структура PDD, SDD, BRD и реестра исключений
5
Инженерные стандарты RPA: REFramework, именование, Git-стратегия ветвления
6
Полный цикл тестирования: Unit, Functional, Integration, UAT и управление дефектами
7
Чек-лист Go/No-Go, регламент Hypercare и комплект документации (20 шаблонов)
8
KPI проектов и CoE, порядок PIR (1/3/6/12 месяцев) и структура Lessons Learned

Кому будет полезен:

Директорам по цифровой трансформации и руководителям CoE RPA
Проектным менеджерам проектов по автоматизации
Бизнес-аналитикам и архитекторам решений
Разработчикам и QA-инженерам RPA
Руководителям подразделений — спонсорам проектов

Шаблон нормативного документа

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

Регламент · ред. 1.0

📄 Как получить файл. Полный текст документа опубликован на странице для ознакомления. Чтобы скачать готовый файл и использовать его в работе, заполните форму на странице: ссылку для скачивания пришлём на вашу почту.
Содержание
  1. 1ОБЩИЕ ПОЛОЖЕНИЯ
  2. 2GOVERNANCE И УПРАВЛЕНИЕ ПРОЕКТАМИ
  3. 3РОЛИ И МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ
  4. 4ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
  5. 5ПОРТФЕЛЬ ИНИЦИАТИВ И ПРИОРИТИЗАЦИЯ
  6. 6ВЫБОР ТЕХНОЛОГИИ И АРХИТЕКТУРА
  7. 7АНАЛИЗ И ПРОЕКТИРОВАНИЕ
  8. 8РАЗРАБОТКА И ИНЖЕНЕРНЫЕ СТАНДАРТЫ
  9. 9ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
  10. 10ТЕСТИРОВАНИЕ И ПРИЁМКА
  11. 11ВВОД В ЭКСПЛУАТАЦИЮ И HYPERCARE
  12. 12ЭКСПЛУАТАЦИЯ И УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
  13. 13МАСШТАБИРОВАНИЕ И ТИРАЖИРОВАНИЕ
  14. 14УПРАВЛЕНИЕ ЗНАНИЯМИ
  15. 15КОНТРОЛЬ ЭФФЕКТОВ И KPI
  16. 16ЗАКРЫТИЕ ПРОЕКТА И ВЫВОД ИЗ ЭКСПЛУАТАЦИИ
  17. 17ДОПОЛНИТЕЛЬНЫЕ АСПЕКТЫ

ОБЩИЕ ПОЛОЖЕНИЯ

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

1.1. Цель, задачи и ожидаемые результаты

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

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

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

Сформулируйте 1 генеральную цель и 4-6 задач. Укажите связь с базовым Регламентом. Определите 4-5 измеримых результатов. Приведите ссылки на стратегические документы.

Пример:

Цель: Установить единый порядок реализации проектов автоматизации от инициации до закрытия.

Задачи:

  1. Определить этапы жизненного цикла и критерии перехода (Gate Criteria)
  2. Установить состав обязательных артефактов и требования к ним
  3. Регламентировать порядок принятия проектных решений
  4. Обеспечить интеграцию с архитектурой предприятия
  5. Стандартизировать инженерные практики разработки

Связь с базовым Регламентом: Настоящий документ детализирует проектную методологию, определённую в разделах 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Автоматизация через UI6-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
Тип интеграцииBackendFrontend

1.4. Глоссарий проектных терминов

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

Какие ключевые понятия, термины, роли, артефакты и сокращения закреплены в глоссарии?

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

Приведите 15-20 терминов проектной методологии. Структурируйте по категориям: артефакты, этапы, роли, технические термины.

Пример:

Проектные артефакты:

ТерминОпределение
PDDProcess Definition Document — описание процесса AS-IS/TO-BE
SDDSolution Design Document — техническое проектирование
BRDBusiness 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. При противоречии с базовым — приоритет базового
  2. При противоречии с Политикой ИБ — приоритет ИБ
  3. Спорные вопросы — на Комитет по автоматизации

1.6. Обязательные принципы реализации проектов

Описание подраздела: Подраздел формулирует принципы с критериями проверки соответствия.

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

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

Сформулируйте 6-8 принципов. Для каждого укажите критерий проверки и точку контроля.

Пример:

ПринципКритерийТочка контроля
Оптимизация до автоматизацииTO-BE содержит ≥2 улучшенийGate Review Анализ
Архитектурное соответствиеЗаключение ИТ-архитектораGate Review Проектирование
Переиспользование компонентов≥30% из библиотекиCode Review
Security by DesignЧек-лист ИБ заполненGate Review Проектирование
Полнота документированияЧек-лист 100%Gate Review Внедрение
Обработка исключенийМатрица заполнена, тесты OKUAT

GOVERNANCE И УПРАВЛЕНИЕ ПРОЕКТАМИ

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

2.1. Владелец методологии и органы управления

Описание подраздела: Подраздел определяет должностных лиц и коллегиальные органы.

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

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

Укажите владельца и его обязанности (4-5 пунктов). Определите коллегиальные органы. Приведите схему governance.

Пример:

Владелец методологии: Директор по цифровой трансформации

Обязанности:

  1. Утверждение и актуализация Регламента
  2. Разрешение методологических споров
  3. Контроль эффективности на основе KPI
  4. Инициирование стратегических изменений

Органы управления:

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

2.2. Порядок принятия проектных решений

Описание подраздела: Подраздел устанавливает правила принятия решений и уровни полномочий.

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

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

Классифицируйте типы решений (3-4 уровня). Определите орган для каждого. Укажите сроки.

Пример:

Тип решенияОрган/ЛицоСрок
Включение (бюджет > 3 млн)Комитет10 р.д.
Включение (бюджет ≤ 3 млн)Директор по ЦТ5 р.д.
Архитектурное согласованиеАрхитектурный совет5 р.д.
Согласование ИБСлужба ИБ5 р.д.
Ввод в эксплуатациюВладелец + CoE3 р.д.

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Архитектура, SDDEnterprise Architecture
RPA-разработчикРазработка, unit-тестыСертификация платформы
QA-инженерТест-кейсы, тестированиеМетодологии QA

Матрица RACI:

ЭтапСпонсорPMBAArchitectDevQA
ИнициацияARCIII
АнализARRCII
ПроектированиеARCRCC
РазработкаIRCCRC
ТестированиеIRCCCR
ВнедрениеARCCRC

3.2. Центр компетенций (CoE) и полномочия

Описание подраздела: Подраздел определяет структуру и полномочия CoE.

Какова структура и полномочия Центра компетенций? Имеет ли он право вето?

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

Опишите структуру CoE (3-4 направления). Определите полномочия, включая право вето.

Пример:

Структура CoE:

  1. Группа методологии и архитектуры
  2. Группа разработки
  3. Группа эксплуатации
  4. Группа качества

Полномочия:

ПолномочиеУсловия
Право ветоПроцесс не оптимизирован; зрелость < 3
Архитектурное согласованиеВсе проекты
Code ReviewПеред каждым релизом
Ресурсное планированиеЕженедельно

3.3. Владелец решения после закрытия проекта

Описание подраздела: Подраздел определяет порядок передачи ответственности.

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

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

Определите владельца и обязанности (5-6 пунктов). Разграничьте ответственность между владельцем, CoE и ИТ.

Пример:

Владелец: Владелец бизнес-процесса (BPO)

Обязанности:

  1. Контроль бизнес-эффектов и KPI
  2. Инициирование изменений
  3. Принятие решений об эскалации
  4. Ответственность за данные
  5. Инициирование вывода из эксплуатации
ОбластьВладелецCoEИТ
Бизнес-результатыACI
РаботоспособностьCRC
ИнфраструктураICA

3.4. Требования к квалификации команды

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

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

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

Определите требования для 5-6 ролей. Укажите сертификации и опыт.

Пример:

РольОпытСертификации
Solution Architect≥5 лет ИТ, ≥2 RPAПлатформа (Advanced), TOGAF
Senior Developer≥3 года RPAПлатформа (Advanced)
Developer≥1 год RPAПлатформа (Associate)
Business Analyst≥2 года BACBAP (желат.)
QA Engineer≥2 года QAISTQB (желат.)

ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

Описание раздела: Раздел определяет этапы жизненного цикла, критерии перехода (Gate Criteria) и контрольные точки.

4.1. Этапы жизненного цикла

Описание подраздела: Подраздел устанавливает последовательность этапов от инициации до закрытия.

Какие этапы жизненного цикла проекта устанавливаются — от инициации до закрытия и вывода из эксплуатации?

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

Определите 7-9 этапов с целями и результатами. Укажите типовую длительность. Приведите схему.

Пример:

ЭтапЦельРезультатыДлительность
ИнициацияУтверждение бизнес-кейсаПаспорт проекта1-2 нед.
АнализИзучение AS-IS/TO-BEPDD, BRD2-3 нед.
ПроектированиеАрхитектура решенияSDD1-2 нед.
РазработкаСоздание решенияКод, unit-тесты3-5 нед.
ТестированиеВерификация качестваПротоколы, UAT2-3 нед.
ВнедрениеРазвёртывание в PRODАкт ввода1 нед.
HypercareСтабилизацияПодтверждение2-4 нед.
ЭксплуатацияШтатная работаKPIБессрочно
Закрытие/ВыводЗавершениеLessons Learned1-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 согласованПодписанный PDDBA
Модели AS-IS/TO-BE утвержденыМодели в репозиторииBA
Реестр исключений заполненРеестрBA
Оптимизация подтвержденаЗаключениеПроцессный офис

Gate 3: Проектирование → Разработка

КритерийАртефактОтветственный
SDD согласованПодписанный SDDArchitect
Архитектурное согласованиеЗаключениеИТ-архитектор
Согласование ИБЗаключение ИБСлужба ИБ
Среда подготовленаАкт готовностиАдминистратор

Gate 4: Разработка → Тестирование

КритерийАртефактОтветственный
Code Review пройденОтчётLead Developer
Unit-тесты OKОтчётРазработчик
Код в репозиторииMergeРазработчик
Тест-план согласованПланQA

Gate 5: Тестирование → Внедрение

КритерийАртефактОтветственный
Функциональное тестирование OKПротоколQA
UAT пройденПротокол, Sign-offSME
Critical дефектов нетОтчёт JiraQA
Документация готова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 RPA5 р.д.
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 критериев с весами. Опишите шкалу. Укажите формулу расчёта.

Пример:

КритерийВесШкала
ROI25%1: <50%, 5: >200%
Срок окупаемости20%1: >24 мес., 5: <6 мес.
Стратегическая значимость20%1: низкая, 5: критическая
Техническая готовность15%1: требует НИОКР, 5: типовое
Риски10%1: высокие, 5: минимальные
Готовность заказчика10%1: не вовлечён, 5: полная

Формула: Приоритет = Σ (Оценкаᵢ × Весᵢ)

БаллКатегорияДействие
4.0-5.0P1Немедленный запуск
3.0-3.9P2Плановая реализация
2.0-2.9P3Backlog
<2.0P4Отложено

5.6. Расчёт бизнес-кейса и защита паспорта

Описание подраздела: Подраздел определяет методику расчёта эффекта и порядок защиты.

Как рассчитывается экономический эффект и стоимость владения? Каков порядок защиты бизнес-кейса?

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

Приведите формулы (ROI, TCO, FTE, Payback). Укажите источники данных. Опишите процедуру защиты.

Пример:

ПоказательФормула
FTE-экономия(Время × Кол-во × 12) / 1920
Годовая экономияFTE × Стоимость FTE
TCO (3 года)Внедрение + 3 × Ежегодные
ROI(Экономия − Затраты) / Инвестиции × 100%
PaybackИнвестиции / (Экономия − Затраты) × 12

Процедура защиты:

  1. Подготовка Паспорта (PM, BA, CoE)
  2. Внутренняя экспертиза (ПО)
  3. Защита на Комитете
  4. Принятие решения
  5. Оформление запуска

ВЫБОР ТЕХНОЛОГИИ И АРХИТЕКТУРА

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

6.1. Критерии выбора технологического подхода

Описание подраздела: Подраздел устанавливает правила выбора между технологиями.

Какие критерии применяются для выбора: RPA vs BPM vs доработка ИС vs API-интеграция?

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

Разработайте дерево решений. Определите 6-8 критериев сравнения. Приведите матрицу применимости.

Пример:

ХарактеристикаRPABPMLow-codeAPI
Legacy без API
Участие людей⚠️
Частые изменения⚠️
Объём >10000/день⚠️⚠️⚠️
Быстрый TTM⚠️⚠️

6.2. Архитектурное согласование

Описание подраздела: Подраздел определяет порядок согласования архитектуры.

Как определяется целевая архитектура? Как проводится согласование с ИТ-ландшафтом?

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

Опишите процедуру (5-6 шагов). Определите критерии обязательного согласования ARB. Приведите чек-лист.

Пример:

ШагДействиеСрок
1Подготовка SDD
2Подача запроса1 р.д.
3Первичный анализ2 р.д.
4Заседание ARB (при необходимости)3 р.д.
5Выдача заключения1 р.д.

Критерии обязательного ARB:

  1. Интеграция с ≥3 системами
  2. Нестандартные технологии
  3. Обработка ПДн
  4. Критичность уровня 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:

  1. Общие сведения
  2. Описание AS-IS
  3. Входы и выходы
  4. Участники и роли
  5. Информационные системы
  6. Бизнес-правила
  7. Описание TO-BE
  8. Границы автоматизации
  9. Реестр исключений
  10. Метрики и KPI

Структура SDD:

  1. Общие сведения
  2. Архитектура решения
  3. Компоненты
  4. Модель данных
  5. Интеграции
  6. Обработка исключений
  7. Безопасность
  8. Производительность
  9. Развёртывание
  10. Зависимости

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-001COMP-001TC-001Passed

РАЗРАБОТКА И ИНЖЕНЕРНЫЕ СТАНДАРТЫ

Описание раздела: Раздел определяет стандарты разработки, управления версиями и качества кода.

8.1. Стандарты разработки

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

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

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

Определите 8-10 стандартов. Опишите механизм контроля. Приведите чек-лист Code Review.

Пример:

СтандартОписаниеКонтроль
Naming ConventionsPascalCase/camelCaseCode Review
Структура проектаMain, Exceptions, UtilitiesCode Review
Модульность1 компонент = 1 функцияCode Review
REFrameworkДля транзакционных процессовCode Review
Exception HandlingTry-Catch для внешних вызововАвтотесты
LoggingStart, End, Exception, Key StepsАвтотесты
Config ExternalizationПараметры в configАвтотесты
No Hardcoded CredentialsТолько Credential VaultCode 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
ПроектированиеХранение credentialsSDD
РазработкаCredential VaultCode Review
ТестированиеОбезличивание данныхАкт
ВнедрениеОтдельные УЗ для средЗаявка

9.2. Управление учётными записями роботов

Описание подраздела: Подраздел определяет жизненный цикл УЗ.

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

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

Опишите жизненный цикл (4-5 этапов). Укажите правила именования.

Пример:

ЭтапДействиеСрок
СозданиеЗаявка ЗУЗ-013 р.д.
Назначение правЗаявка на доступ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
EmailЗамена домена

10.3. Порядок проведения UAT

Описание подраздела: Подраздел определяет процедуру UAT.

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

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

Опишите процедуру (5-7 шагов). Определите критерии успешности.

Пример:

ШагДействиеОтветственныйСрок
1Подготовка сценариевQA + SME5 р.д. до UAT
2СогласованиеBA2 р.д.
3Подготовка средыQA + Admin2 р.д.
4Проведение UATSME3-5 р.д.
5Фиксация результатовQA1 р.д.
6Sign-offSME1-2 р.д.

Критерии успешности: 0 Critical, 0 Major (или workaround), ≤5 Minor

10.4. Управление дефектами

Описание подраздела: Подраздел устанавливает классификацию и SLA.

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

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

Определите классификацию (4 приоритета). Укажите SLA. Опишите жизненный цикл.

Пример:

ПриоритетОписаниеSLAВлияние
CriticalБлокирует основной сценарий4 часаБлокирует Sign-off
MajorСущественное отклонение8 часовБлокирует
MinorЕсть workaround3 р.д.Может быть отложен
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Администратор
2Backup текущей версииАдминистратор
3РазвёртываниеАдминистратор
4КонфигурацияАдминистратор
5Smoke-тестQA
6Активация расписанияАдминистратор

Право на деплой: Администраторы RPA (именной список) Окно: Рабочие дни, 18:00-22:00

11.4. Комплект документации

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

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

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

Определите перечень (8-10 документов). Приведите чек-лист.

Пример:

ДокументНазначениеРазработчик
RunbookОперационные инструкцииРазработчик
Инструкция пользователяРабота с роботомBA
Инструкция администратораНастройкаАдминистратор
Схема интеграцийВзаимосвязиArchitect
Паспорт роботаДля реестраPM
Реестр исключенийНештатные ситуацииBA
План откатаКритические сбоиАдминистратор
Контакты эскалацииМатрицаPM

11.5. Обучение пользователей

Описание подраздела: Подраздел определяет порядок обучения.

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

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

Определите категории обучаемых. Опишите форматы. Укажите критерии успеха.

Пример:

КатегорияСодержаниеФорматДлительность
ПользователиВзаимодействиеE-learning2 часа
ОператорыОбработка ошибокПрактикум4 часа
АдминистраторыМониторингТехническое8 часов

ЭКСПЛУАТАЦИЯ И УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ

Описание раздела: Раздел определяет порядок поддержки, управления инцидентами и изменениями.

12.1. Модель поддержки

Описание подраздела: Подраздел определяет уровни поддержки.

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

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

Определите 3 уровня с SLA. Укажите распределение. Опишите эскалацию.

Пример:

УровеньФункцииИсполнительSLA
L1Мониторинг, перезапускService Desk + Admin30 мин
L2Анализ, конфигурацияCoE RPA4 часа
L3Доработка кодаCoE RPA (Senior)8 часов

12.2. Управление инцидентами

Описание подраздела: Подраздел определяет процедуру обработки инцидентов.

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

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

Опишите процедуру (5-6 шагов). Укажите правила RCA.

Пример:

ШагДействиеИсполнительСрок
1ОбнаружениеМониторинг
2РегистрацияL115 мин
3ДиагностикаL130 мин
4ЭскалацияL1 → L2По SLA
5РешениеL2/L3По SLA
6RCA (Major/Critical)L2/L35 р.д.

12.3. Управление изменениями

Описание подраздела: Подраздел определяет процедуру изменений.

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

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

Классифицируйте изменения (3 типа). Опишите процедуру.

Пример:

ТипПримерыПроцедураТестирование
StandardРасписание, конфигУведомлениеSmoke
NormalБизнес-логикаПолный CRПолное
EmergencyКритическая ошибкаУскоренноеМинимальное

12.4. Обеспечение непрерывности

Описание подраздела: Подраздел определяет требования к непрерывности.

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

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

Определите RTO/RPO. Опишите fallback-процедуры.

Пример:

КритичностьRTORPOFallback
Критический2 часа15 минРучной режим
Высокий4 часа1 часРучной режим
Средний8 часов4 часаОтложенная обработка

МАСШТАБИРОВАНИЕ И ТИРАЖИРОВАНИЕ

Описание раздела: Раздел определяет критерии и процедуры тиражирования.

13.1. Критерии и процедуры тиражирования

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

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

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

Определите критерии пригодности. Опишите процедуру.

Пример:

КритерийТребование
Стабильность≥ 98% за 3 месяца
Модульность≥ 70% переиспользуемых
ДокументированностьПолный комплект
ПараметризуемостьНастройка через конфиг

Процедура:

  1. Анализ применимости (1-2 нед.)
  2. Адаптация конфигурации (1 нед.)
  3. Тестирование (1-2 нед.)
  4. Обучение (1 нед.)
  5. Запуск + 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%
Успешность UATPassed/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

Процедура:

  1. Инициация и обоснование
  2. Согласование (5 р.д.)
  3. План перехода (10 р.д.)
  4. Уведомление (за 10 р.д.)
  5. Остановка робота
  6. Отзыв доступов (5 р.д.)
  7. Архивирование (5 р.д.)
  8. Утилизация лицензий (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Акт выводаВывод

Поддержка