Робот останавливается по пяти причинам, и на четыре из них вы не влияете: 38 % падений дают обновления автоматизируемой системы, 22 % — данные, которых не было в тестовой выборке, 18 % — инфраструктура и учётные записи, 14 % — смена правил доступа на чужой стороне. Собственные изменения процесса дают всего 8 %. Итого 92 % поломок происходит за пределами вашей зоны контроля — и именно поэтому поддержка робота стоит дороже поддержки обычной интеграции.
Это не аргумент против роботов. Это аргумент за то, чтобы считать сценарий не разовой покупкой, а расходной строкой на весь срок его жизни. Годовая эксплуатация парка из пяти unattended-роботов в модельном расчёте ниже выходит 2 692 000 ₽ — 44 867 ₽ на робота в месяц, без учёта разработки сценариев.
Ниже разбираем механику поломок, годовую смету, три приёма, которые снижают число ремонтов вдвое, и состав SLA, без которого поддержка робота превращается в неконтролируемую почасовку. Общая механика RPA и срок жизни сценария по типам систем разобраны отдельно в материале как устроен RPA и где он ломается.
Пять причин остановки и доля каждой
Доли ниже — практические, для парка роботов на смеси браузерных и настольных приложений. У сценария, который работает только на замороженной внутренней системе, первая строка будет заметно меньше; у сценария на портале маркетплейса — заметно больше. Важна не точная цифра, а порядок: три четверти поломок вызваны чужими изменениями, а не ошибками разработчика.
| Причина | Доля | Как выглядит | Что снижает |
|---|---|---|---|
| Обновление автоматизируемой системы | 38 % | Сдвинулось поле, добавилась колонка, появилось окно с уведомлением о новинках | Привязка по объектной модели, тестовый прогон после каждого релиза |
| Данные, которых не было в тестовой выборке | 22 % | Пустое поле, длинное наименование, новый статус, документ с нулевой суммой | Обучающая выборка из реальных данных за 3 месяца, ветка «не знаю» с выходом на человека |
| Инфраструктура и учётные записи | 18 % | Истёк пароль служебной записи, слетела сессия, кончилось место на диске, обновился браузер | Служебная запись без срока действия пароля, мониторинг ресурсов машины |
| Смена правил доступа на чужой стороне | 14 % | Появилась капча, включили двухфакторный вход, добавили экран согласия, ввели лимит запросов | План отхода на ручной регламент, переговоры о служебном доступе |
| Собственные изменения процесса | 8 % | Новый склад, новая номенклатурная группа, изменённый регламент согласования | Владелец процесса, который предупреждает подрядчика до изменения, а не после |
Вторая строка недооценена чаще остальных. Робот проверяется на тех документах, которые дал заказчик, — а заказчик даёт типичные. Первый нетипичный приходит на второй неделе эксплуатации: наименование в 400 символов, отрицательное количество, дата в другом формате. Поэтому обучающая выборка собирается не «на глаз», а сплошняком за три месяца, и в неё специально включают всё странное.
Горизонтальная линейчатая диаграмма из пяти полос, отсортированных по убыванию. Сверху вниз: «Обновление автоматизируемой системы — 38 %», «Данные вне тестовой выборки — 22 %», «Инфраструктура и учётные записи — 18 %», «Смена правил доступа на чужой стороне — 14 %», «Собственные изменения процесса — 8 %». Первые четыре полосы объединены слева фигурной скобкой с подписью «92 % — вне зоны контроля компании». Ось подписана в процентах. Чертёжная сетка, приглушённая палитра, подписи по-русски.
Почему это происходит вообще
Причина одна и она архитектурная. Робот не понимает, что он делает: он не знает, что такое накладная, поставщик или сумма НДС. Он знает, что в третьем поле сверху надо ввести то, что лежало в четвёртой колонке файла. Смысл операции живёт в голове у автора сценария, а в самом сценарии живёт только последовательность движений.
Интеграция ломается, когда меняется договорённость о данных. Робот ломается, когда меняется картинка на экране. Первое согласуют, второе — нет.
Отсюда следует неприятный вывод: надёжность робота не растёт от качества разработки после определённого предела. Хороший подрядчик уменьшит долю поломок по второй и третьей строкам почти до нуля, но первую и четвёртую он не контролирует — их контролирует чужая компания, у которой свой план релизов. Практическое следствие: договариваться надо не о безотказности, а о скорости восстановления. Именно это и фиксируется в SLA на поддержку.
Годовая смета: парк из пяти роботов
Считаем реальный ландшафт средней компании: пять unattended-сценариев — разнос банковской выписки, перенос заказов из кабинета маркетплейса, выгрузка отчётов из личного кабинета оператора, сверка остатков и загрузка накладных. Все пять работают ночью, три из них — на браузерных системах, два — на настольных приложениях. Лицензия взята по середине рыночной вилки 150 000–400 000 ₽ за unattended-робота в год.
Сверим с расчётом на одного робота из разбора механики RPA: там владение выходило 38 600 ₽ в месяц, из которых 7 500 ₽ — амортизация разработки, то есть чистая эксплуатация 31 100 ₽. Разница с парком — 13 767 ₽ на робота в месяц, и она раскладывается ровно на четыре строки: 5 833 ₽ — более дорогая лицензия (250 000 ₽ против 180 000 ₽ в год), 3 333 ₽ — оркестратор, которого у одиночного робота нет, 600 ₽ — инфраструктура, 4 000 ₽ — дежурство. Никакой магии масштаба здесь нет: парк дороже поштучно, пока роботов мало, и дешевле, когда их становится больше десяти.
20 000 ₽ в месяц на парк из пяти роботов покрывают конкретную работу: настроенные уведомления о падении, разбор инцидента в тот же день, повторный запуск с точки остановки и ежемесячный отчёт о простоях. Если подрядчик готов «поддерживать по факту обращения», у вас нет поддержки — у вас есть почасовка после того, как проблему нашёл ваш бухгалтер. Из чего вообще складывается абонплата, разобрано в материале про стоимость поддержки.
Устойчивые селекторы: 702 000 ₽ разницы в год
Главный технический рычаг — способ, которым робот находит элемент на экране. Привязка по координатам («кликни в точку 640 на 380») пишется быстрее и ломается от любого сдвига. Привязка по объектной модели («найди поле с именем „Контрагент“») требует больше работы и переживает перекраску, смену темы и изменение масштаба.
Разница считается прямо. Парк на устойчивых селекторах даёт три переделки на робота в год и восемь часов ручного добора в месяц — это и есть смета выше. Тот же парк на координатах даёт шесть переделок и четырнадцать часов: переделки вырастают с 450 000 ₽ до 900 000 ₽, простои — с 336 000 ₽ до 588 000 ₽. Годовая смета парка уходит с 2 692 000 ₽ до 3 394 000 ₽ — 702 000 ₽ разницы, или 56 567 ₽ на робота в месяц вместо 44 867 ₽.
- 1Записать способ привязки в техническое задание
Формулировка: «привязка к элементам интерфейса выполняется по объектной модели приложения или по уникальным атрибутам элемента; привязка по экранным координатам и по распознаванию изображения допускается только для элементов, у которых иных признаков нет, с обоснованием в отчёте».
- 2Потребовать перечень исключений при сдаче
Подрядчик отдаёт список шагов, где пришлось использовать координаты, с указанием причины. Этот список — карта будущих поломок: именно эти шаги упадут первыми при следующем обновлении.
- 3Разделить гарантию и переделку в договоре
Поломка из-за неустойчивой привязки на шаге, где объектная модель была доступна, — гарантийный случай подрядчика. Поломка из-за реального изменения структуры формы — платная переделка по смете. Без этого разделения любой ремонт становится платным.
- 4Проверить устойчивость до приёмки
Обновить автоматизируемую систему на тестовом контуре и прогнать сценарий. Если он падает после планового обновления конфигурации 1С, вы получите тот же результат на бою через месяц: обновления конфигураций выходят регулярно и без согласования с вами.
Сравнение двух составных столбцов годовых расходов. Левый столбец «Устойчивые селекторы — 2 692 000 ₽» с подписанными сегментами: лицензии 1 250 000, переделки 450 000, простои 336 000, дежурство 240 000, инфраструктура 216 000, оркестратор 200 000. Правый столбец «Привязка по координатам — 3 394 000 ₽» с теми же сегментами, но переделки 900 000 и простои 588 000. Между столбцами стрелка с подписью «702 000 ₽ в год». Внизу подписи «3 переделки на робота» и «6 переделок на робота». Чертёжная сетка, приглушённая палитра, подписи по-русски.
Контрольные точки: узнать о поломке в тот же день
Вторая по величине статья расходов после лицензий — не ремонт, а время между поломкой и её обнаружением. Робот, вставший в ночь на вторник и найденный в пятницу, стоит четыре смены ручного ввода и разбор того, какие документы прошли, а какие нет. Робот, вставший в ночь на вторник и обнаруженный в 7 утра, стоит один звонок.
- 1Уведомление о неуспешном завершении
Оркестратор пишет в рабочий канал: сценарий, время, номер шага, скриншот на момент падения. Базовый уровень, настраивается за час, закрывает случай явной остановки.
- 2Уведомление о неначатом запуске
Более важное и почти всегда забытое: робот не упал, он вообще не стартовал — не отработало расписание, машина ушла в перезагрузку, истёк пароль. Правило простое: если к 07:00 нет отметки об успешном завершении, уходит уведомление, даже если ошибок не было.
- 3Сверка контрольной суммы
Защита от тихого сбоя, при котором робот продолжает работать и вводить неверно. На вход подано 412 строк — в учётной системе должно появиться 412 документов на ту же общую сумму. Расхождение блокирует следующий запуск и уходит ответственному.
- 4Ежемесячный отчёт о простоях
Число падений, причина каждого, часы простоя, часы ручного добора. Это единственный способ через полгода понять, окупается робот или уже нет, и он же даёт основание для решения о выводе сценария из эксплуатации.
Разработка контрольной точки и сверки стоит 6–10 часов на сценарий — при рыночной ставке инженера 3 000 ₽/час это 18 000–30 000 ₽ разово, то есть 10–15 % стоимости разработки сценария. Экономия на этой строке — самая дорогая экономия в проекте: без неё вы узнаёте о поломке от бухгалтера в конце месяца. Общие принципы наблюдения за автоматизированными процессами разобраны в материале про мониторинг автоматизации.
Разница между двумя режимами считается прямо. Без контрольных точек средняя поломка обнаруживается через три-четыре смены: за это время накапливается 24–32 часа ручного добора по 700 ₽, то есть 17 000–22 000 ₽ на один инцидент. С контрольными точками тот же инцидент стоит 8 часов и 5 600 ₽. При трёх поломках в год разница — около 40 000 ₽ на сценарий, и она перекрывает стоимость разработки самих контрольных точек уже в первый год.
Схема из четырёх горизонтальных полос-уровней, сверху вниз. Уровень 1 «Уведомление о падении» — подпись «сценарий, шаг, скриншот; настройка за час». Уровень 2 «Уведомление о неначатом запуске» — подпись «нет отметки к 07:00 — уведомление уходит». Уровень 3 «Сверка контрольной суммы» — подпись «412 строк на входе = 412 документов на выходе; расхождение блокирует запуск». Уровень 4 «Ежемесячный отчёт о простоях» — подпись «падения, причины, часы простоя, часы ручного добора». Справа вертикальная шкала с подписями «17 000–22 000 ₽ за инцидент без контроля» и «5 600 ₽ с контролем». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Регламент обновлений и учётные записи
Два организационных правила, которые снимают больше поломок, чем любая техническая мера. Первое касается релизов, второе — доступов.
- 1Любое обновление автоматизируемой системы сначала накатывается на тестовый контур, там прогоняются все сценарии, затем обновляется бой. Если тестового контура нет, его заводят — отлаживать робота на боевой базе означает регулярно объяснять, откуда взялись документы-призраки. Данные для такого контура готовят обезличенными: боевые персональные данные в тестовую копию не переносят.
- 2Робот работает под отдельной служебной учётной записью с ограниченным набором прав, а не под логином сотрудника. Личный логин означает три беды сразу: увольнение сотрудника останавливает робота, действия робота неотличимы от действий человека в журнале, а права робота равны правам человека — то есть избыточны. Принцип разбирается подробно в статье про минимальные права доступа.
- 3У служебной записи снят срок действия пароля или заведён регламент его смены с уведомлением подрядчика. Истёкший пароль — банальнейшая причина простоя, и она же самая обидная: робот исправен, сценарий цел, просто никто не нажал кнопку.
- 4У каждого сценария есть владелец со стороны компании — человек, который знает, что робот делает, и предупреждает подрядчика об изменениях в процессе заранее. Без владельца восьмипроцентная строка «собственные изменения» вырастает втрое.
Отдельная и регулярно всплывающая проблема: робота настраивали под записью подрядчика, проект закончился, доступ формально не передан. Робот работает, но управлять им некому, а через год выясняется, что учётная запись до сих пор активна и имеет права на изменение документов. Передача доступов оформляется актом при закрытии проекта — подробности в разборе про забытые учётные записи подрядчика.
Горизонтальная лента времени из пяти этапов слева направо. «День 0: вендор выпустил релиз» — «День 0: обновляется тестовый контур» — «День 1: прогон всех сценариев на тесте, отметка «пройдено / упало»» — «День 1: правка упавших шагов, оценка по смете» — «День 2: обновление боевой системы». Под лентой пунктирная ветка от третьего этапа вниз к блоку «упало — обновление боя откладывается». Слева от ленты вертикальная подпись «регламент фиксируется в SLA». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Что должно быть в SLA на поддержку робота
Типовой SLA на программное обеспечение к роботу не подходит: он написан про доступность сервиса, а у робота нет сервиса — у него есть ночное окно, в которое результат обязан оказаться в учётной системе. Шесть пунктов ниже — минимальный состав, который делает поддержку измеримой.
| Пункт SLA | Что именно фиксируется | Ориентир |
|---|---|---|
| Время реакции | Отсчёт идёт от срабатывания уведомления мониторинга, а не от обращения сотрудника | 30 минут в рабочее время, 2 часа ночью |
| Время восстановления | Разделено на два класса: правка привязки и переписывание участка сценария | 4 часа и 3 рабочих дня |
| Окно результата | К какому часу данные обязаны быть в учётной системе после ночного прогона | 07:00 по рабочим дням |
| Тестовый прогон после обновления | Обязанность подрядчика прогнать все сценарии на тестовом контуре после релиза | 1 рабочий день после обновления |
| Отчёт о простоях | Число падений, причина, часы простоя, часы ручного добора по каждому сценарию | Ежемесячно, до 5-го числа |
| Граница абонплаты | Что входит в фиксированную сумму, а что считается отдельной переделкой по смете | 20 000 ₽/мес на парк, переделка от 30 000 ₽ |
Седьмой пункт — не про сроки, а про выход: право компании получить сценарии в читаемом виде и техническое описание привязок при расторжении. Без него смена подрядчика означает переписывание всех сценариев заново. Полный состав работ по сопровождению и порядок их приёмки разобраны отдельно в материале о том, что входит в поддержку системы.
Отдельно проговаривается граница между гарантией и платной переделкой, иначе она проговаривается потом и не в вашу пользу. Разумное деление такое: если сценарий упал на шаге, где подрядчик использовал привязку по координатам при доступной объектной модели, ремонт гарантийный. Если упал из-за реального изменения структуры формы на чужой стороне — это переделка по смете от 30 000 ₽. Без этого разделения любой ремонт оказывается платным, и годовой счёт на поддержку становится непредсказуемым.
Когда робота дешевле выключить, чем поддерживать
Поддержка не бесконечна: у сценария есть точка, после которой ремонт перестаёт быть экономически осмысленным. Четыре признака проверяются по отчёту о простоях за последние двенадцать месяцев.
- Расходы на переделки за год превысили стоимость разработки сценария заново. При разработке 180 000 ₽ это шесть переделок по 30 000 ₽. Значит, система изменилась настолько, что вы платите за догонялки, а не за автоматизацию.
- У смежной системы появился интеграционный контур. Обмен по контракту дешевле робота примерно втрое в эксплуатации. Здесь правильное решение — не чинить, а переносить операцию, даже если робот сейчас работает.
- Часы ручного добора сравнялись с часами, которые робот экономит. Порог окупаемости при ставке 700 ₽/час — от 40 до 83 часов в месяц в зависимости от системы. Если робот экономит 60 часов, а простои съедают 25, реальная экономия ушла под порог.
- Процесс изменился настолько, что сценарий переписывается больше чем наполовину. Это не ремонт, это новый проект — и оценивать его надо как новый, вместе с вопросом, нужен ли робот вообще.
И последнее, что стоит держать в голове при планировании бюджета. Поддержка робота — это не страховка от поломок, это плата за скорость их устранения. Продавать вам безотказный сценарий никто не может: у чужой системы свой план релизов, и он не согласуется с вашим. Честный подрядчик называет не вероятность падения, а срок восстановления и стоимость переделки — и в этом единственное измеримое обещание, которое здесь вообще возможно.
