Решение для автоматизации бизнес-процессов выбирают не по функциональности и не по известности поставщика. Сначала фиксируют сам процесс, его экономику, ограничения и измеримый результат. Затем требования сопоставляют с классом решения, считают TCO и проверяют гипотезу пилотным проектом. Если случается ошибка при выборе, ее почти всегда объясняют тем, что недооценили интеграции, качество данных, сопротивление пользователей или стоимость сопровождения.
Автоматизация бизнес-процессов это изменение выполнения повторяемых операций с помощью корпоративных систем, правил и интеграций для достижения измеримого результата. Она не равна цифровизации, которая может включать новый канал продаж или продукт. Автоматизация бизнес-процессов отвечает за конкретную работу: согласование договора, обработку заявки, закрытие закупки.
Цели автоматизации и границы проекта
Цель автоматизации бизнес-процессов должна описывать результат процесса, а не факт внедрения технологии. Формулировка «внедрить BPM-платформу» не говорит о ценности. А формулировка «сократить медианный срок согласования договора с 12 до 6 рабочих дней при сохранении контроля полномочий» уже говорит о результате.
Под границами проекта понимается набор процессов, подразделений, систем, данных и ролей, которые входят в первую очередь автоматизации. Они нужны, чтобы пилотный проект не превратился в бесконечную череду организационных изменений. Сначала фиксируют ограниченные границы проекта, а расширяют их только при подтвержденном результате.
Для крупной российской компании цели обычно лежат в пяти плоскостях:
- снижение операционных затрат на одну операцию;
- сокращение времени цикла бизнес-процесса;
- снижение доли ручного труда и повторного ввода данных;
- повышение соблюдения SLA, регламентов и полномочий;
- улучшение качества данных для управленческой отчетности.
Сокращение трудозатрат, переделок и ручных передач между подразделениями снижает операционные затраты. Устранение ожидания в почте, Excel и неформальных согласованиях сокращает срок выполнения задач. Управляемость растет за счет единого журнала статусов, действий и исключений.
В проект необходимо включить не только функциональные требования. Нужен владелец бизнес-процесса, который вправе менять регламент. Нужны исходная метрика, целевое значение, перечень систем-источников и систем-получателей. Отдельно фиксируются требования ИБ, правила хранения данных и список исключений, остающихся за сотрудником.
В проект обязательно закладывают критерий остановки. Если эффект не подтверждается, масштабирование прекращают.
Не все требует автоматизации. Иногда проблема не в системе, а в лишнем согласующем или противоречивом регламенте. Поэтому важно сначала убрать лишний шаг, потом внедрять платформу, иначе компания автоматизирует очередь из ненужных процессов.
Карта процессов и выбор кандидатов на автоматизацию
Процесс-кандидат на автоматизацию называют повторяемым бизнес-процессом с измеримыми потерями, понятными правилами и владельцем, готовым менять способ работы. Первым берут не самый сложный процесс. Рациональнее выбрать тот, где эффект можно увидеть без многолетней перестройки архитектуры.
Карту процессов удобно собирать в три слоя: клиентские, обеспечивающие и управленческие процессы. Для каждого слоя фиксируют частоту, длительность, трудозатраты, ошибки, используемые системы и точки ожидания.
Практический алгоритм состоит из четырех шагов:
- Измерить текущий бизнес-процесс на фактических данных за период, а не по оценкам сотрудников.
- Нарисовать путь операции: вход, решение, передача, выход и исключение.
- Найти главный источник потерь: ожидание, ручной ввод, поиск информации, ошибки или дублирование.
- Отобрать 3—5 процессов и оценить их по единой балльной модели: эффект, реализуемость и риск.
Обычно дискуссии о выборе платформы заходят в тупик, потому что стороны опираются на субъективные экспертные оценки и разное видение процесса. Анализ исторических данных и логов операций всего за два-три месяца снимает большинство вопросов: он оцифровывает процесс, обнажая реальные затраты времени и денег на конкретные шаги. Карта процесса «как есть» (As Is) — это еще не целевая ИТ-архитектура и не техническое задание. Но именно она показывает, как бизнес-логика работает на самом деле, а не как ее идеализируют в регламентах и на стратегических встречах.
Как выбрать решение для автоматизации бизнес-процессов
Решение для автоматизации бизнес-процессов выбирают через сопоставление требований процесса, класса продукта, ограничений архитектуры и TCO. Такая последовательность снижает риск купить раздутую систему и не закрыть главную проблему .
Выбор решения укладывается в семь шагов:
- Описать целевой бизнес-процесс и обязательные исключения.
- Сформировать функциональные, интеграционные, нагрузочные, ИБ- и эксплуатационные требования.
- Выбрать класс решения: CRM, BPM, ERP, корпоративный сервис, RPA (robotic process automation, роботизированная автоматизация процессов) или LLM-сценарий.
- Составить короткий список из 3—5 продуктов либо вариантов заказной разработки.
- Проверить демонстрацию на собственных сценариях и обезличенных или тестовых данных.
- Рассчитать TCO на горизонте не менее трех лет.
- Запустить пилотный проект с заранее согласованными KPI.
Принято считать, что крупной компании нужна одна «единая» платформа. Но это работает, только если процессы действительно едины, а управление данными уже зрелое. Композируемая, или модульная, архитектура часто снижает зависимость от одного поставщика. Процесс собирается из совместимых компонентов, а не из монолита.
По прогнозам Gartner, к 2026 году композируемый подход будут использовать до 60% предприятий. А к 2027 году 80% крупных организаций внедрят практики платформенной инженерии. Для российского корпоративного сектора это не просто абстрактные ориентиры, а маркеры выживания систем после импортозамещения. Успех автоматизации сегодня зависит не столько от выбора конкретного продукта «из коробки», сколько от архитектурной гибкости: сможет ли компания самостоятельно развивать, масштабировать и перестраивать это ИИ-решение уже после завершения пилота .
Сравнение типов решений для автоматизации
CRM, BPM, ERP и другие корпоративные сервисы решают разные задачи автоматизации бизнес-процессов. CRM: система для управления взаимодействиями с клиентами, лидами, сделками и сервисными обращениями. BPM: платформа для моделирования, исполнения и контроля сквозных бизнес-процессов. ERP: система для планирования и учета ресурсов предприятия, включая финансы, закупки, производство, запасы и персонал.
BPM-платформа управляет процессом, а корпоративный сервис работает иначе: он дает пользователю интерфейс для конкретной операции. Часто нужны оба компонента. Сервис самообслуживания принимает заявку, BPM-платформа маршрутизирует ее по правилам, а ERP-система становится источником учетных данных.
В российских системах интеграционный слой имеет отдельное значение. Для обмена между системами могут рассматриваться 1С:Шина, DATAREON, Digital Q.Integration, Bercut ESB, «СмартВиста», «Галактика ESB» и другие. Конкретный выбор зависит от протоколов, событийной архитектуры, требований к журналированию и уже работающего ландшафта.
Критерии выбора и оценка совокупной стоимости владения
При выборе оценивают соответствие процессу, интеграции, масштабируемость, сопровождение, ИБ и TCO. Под TCO понимают совокупную стоимость владения решением за весь плановый период эксплуатации, включая внедрение, лицензии, инфраструктуру, интеграции, поддержку и развитие.
Ориентир «заказная разработка от 3 млн ₽» не означает бюджет всей программы автоматизации. Итоговая оценка зависит от объема процесса, количества интеграций, требований ИБ и правил эксплуатации.
TCO растет из-за высокой частоты изменений (или обновлений) в контрактах обмен, версий систем и обработки сбоев в интеграциях. Согласование архитектуры, сегментация и контроль доступа удлиняют срок запуска, если того требует ИБ. Низкое качество мастер-данных повышает стоимость эксплуатации: оно оборачивается ручными исправлениями и инцидентами.
До выбора проверяют шесть вещей:
- права на данные, экспорт и переносимость при смене поставщика;
- наличие API, документации и тестовой среды;
- модель лицензирования при росте числа пользователей;
- требования к отказоустойчивости, допустимой потере данных (RPO, целевая точка восстановления) и времени восстановления сервиса (RTO, целевое время восстановления);
- возможность независимого сопровождения;
- стоимость обязательных доработок после запуска.
Корпоративные сервисы и операционная экономия
Корпоративный сервис называют внутренним цифровым продуктом, через который сотрудник, руководитель или партнер получает стандартную услугу без ручного посредничества. К этой категории относятся портал заявок, кабинет сотрудника, сервис согласования командировок и каталог ИТ-услуг. И это лишь несколько типичных примеров, на самом деле таких продуктов гораздо больше.
Корпоративный сервис снижает операционные затраты, когда уменьшает число касаний и время одной операции. Экономия бюджета не равна сокращению штата. Она может выражаться в высвобождении времени, снижении расходов на подрядчиков, меньшем числе ошибок или отсутствии потребности расширять операционную команду при росте нагрузки.
В качестве компонентов рабочего места могут рассматриваться «МойОфис» и Р7-Офис. Среди таск-трекеров: YouGile, Kaiten, Yandex Tracker и Weeek. Для корпоративного сервиса проверяют интеграции, роли, журналирование и модель поддержки.
LLM в корпоративных бизнес-процессах
LLM называют большой языковой моделью, которая обрабатывает и генерирует текст, извлекает сведения, классифицирует обращения и формирует черновики ответов. LLM не должна принимать необратимые решения в критичном процессе без заданных правил, проверки и аудита.
LLM внедряют поэтапно. Берут текстовый процесс, готовят данные, задают ограничения, запускают пилот и сравнивают KPI до и после. В качестве типового первого сценария обычно выбирают поиск по внутренней базе знаний с указанием источника ответа.
Безопасное внедрение LLM строится на семи шагах:
- Выбрать сценарий с высокой долей текста и низкой ценой ошибки.
- Собрать документы, FAQ, регламенты и примеры корректных ответов.
- Настроить права доступа: модель видит только данные, разрешенные конкретному пользователю.
- Определить участие сотрудника в проверке: он подтверждает результат в спорных или рискованных случаях.
- Ввести журналирование запросов, ответов, источников и исправлений.
- Провести пилот длительностью 4—8 недель и оценить качество.
- Масштабировать сценарий только при подтвержденной пользе и приемлемом риске.
LLM ускоряет обработку: готовит черновик, ищет и извлекает данные. Но LLM не заменяет бизнес-правила. Модель может ошибаться, и это стоит держать в голове при любом сценарии.
Результат проверяет человек.
Выбор сценариев внедрения LLM
Сценарий внедрения LLM выбирают по трем осям: бизнес-польза, реализуемость и риск. У первого пилота должен быть понятный поток данных, измеримый KPI и контролируемая цена ошибки.
Для российских проектов отдельно проверяют размещение данных, трансграничную передачу, доступ поставщика к журналам и соответствие внутренним требованиям ИБ. Внешняя модель и чувствительные данные без обезличивания плохо сочетаются на старте. Сначала лучше снять риски. Потом добавлять амбиции.
Пилотный проект и масштабирование
Пилотный проект нужен, чтобы проверить гипотезу эффекта на ограниченном участке. Он не нужен для демонстрации красивого интерфейса. У пилота должен быть один процесс, одна целевая группа, период измерения и заранее утвержденные критерии успеха.
К масштабу переходят, только когда одновременно выполнены шесть условий:
- достигнут целевой KPI или подтвержден экономический эффект;
- качество операций не ухудшилось;
- критичные интеграции работают стабильно;
- пользователи прошли обучение и знают новый регламент;
- определены владелец продукта и бюджет сопровождения;
- ИБ-служба приняла целевую схему эксплуатации.
Обучение сотрудников входит в состав внедрения, а не идет приложением к нему. Исполнителям нужны короткие сценарные инструкции и практика на типовых операциях. Руководителям нужны правила контроля KPI и обработки исключений. Службе поддержки необходимы база знаний, маршруты эскалации и доступ к журналам.
Управление изменениями начинается до запуска. Полезно назначить представителей подразделений, показать им процесс «до» и «после», собрать возражения, затем опубликовать результаты пилота. Жалоба сотрудника на непонятный новый статус заявки почти всегда означает не «сопротивление персонала», а плохо описанный сценарий.
Метрики эффективности автоматизации
KPI автоматизации должны связывать работу решения с результатом бизнес-процесса. Метрика без исходного значения не доказывает эффект. Метрика без источника данных не выдерживает проверки.
Российские условия выбора и внедрения решений
В России выбор решения для автоматизации бизнес-процессов требует проверки технологической независимости, доступности поддержки, совместимости с локальным стеком и требований ИБ.
При выборе инфраструктуры проверяют стратегию размещения данных. Среди российских провайдеров крупнейшие доли у Cloud.ru (32,5%), РТК-ЦОД (13,7%), Yandex Cloud (11%), Selectel (7,1%) и MWS (5%). По данным исследования MWS Cloud (ноябрь 2025 года, 700 компаний), 41% организаций уже используют несколько облачных провайдеров одновременно. Эти цифры показывают общую картину рынка, но не заменяют оценку рисков и стоимости для конкретного проекта.
Строгую проверку обязаны проходить проекты с государственным финансированием, в госсекторе или в критически важных отраслях. Для большинства коммерческих компаний это не обязательное требование, но пункты полезно учитывать при выборе решений:
- реестр российского ПО, если он обязателен для организации или проекта;
- совместимость с Astra Linux, РЕД ОС, «Альт»; для мобильных устройств нужна совместимость с «Авророй»;
- поддержка СУБД Postgres Pro, Tantor, Pangolin или Jatoba;
- возможность работы с DWH на Arenadata или Greenplum;
- поддержка Kubernetes-платформ: Deckhouse, «Штурвал», MWS Container Platform или «Боцман»;
- интеграция с SIEM, например MaxPatrol SIEM, KUMA, RuSIEM или Security Vision;
- интеграция с системами управления идентификацией и доступом (IdM/IAM): Avanpost, Platform V IDM, RooX UIDM;
- план миграции и выгрузки данных.
FAQ по выбору автоматизации и внедрению LLM
Что делать, если процесс одновременно подходит и под CRM, и под BPM?
Если процесс одновременно про работу с клиентом и про согласование, решение принимают по тому, что чаще является узким местом. Для коммерческой работы обычно выбирают CRM, а для маршрута и правил берут BPM-платформу.
Всегда ли экономия от корпоративного сервиса означает сокращение штата?
Нет. В большинстве случаев эффект складывается из высвобожденного времени сотрудников и отсутствия необходимости расширять команду при росте нагрузки, а не из увольнений.
Должен ли человек проверять каждый результат LLM?
Не каждый: проверка обязательна в спорных или рискованных случаях, а не для рутинных однозначных ответов. Чем выше цена ошибки, тем обязательнее подтверждение сотрудником перед тем, как результат уходит дальше.
Какой сценарий LLM не стоит выбирать для первого пилота?
Автоматическое принятие решения по заявке считается самым рискованным сценарием, и его не стоит запускать первым: цена ошибки высокая, а правила и исключения обычно проработаны не до конца. Первым логичнее взять сценарий с низким или средним риском, например, поиск по базе знаний.
Что делать, если исходные показатели процесса никогда не собирались до автоматизации?
Реальный эффект без базовой линии показать нельзя. Целевые значения KPI в этом случае устанавливают при запуске пилота: замеряют текущее состояние прямо перед стартом, а не восстанавливают задним числом для презентации.