Автоматизация бизнес-процессов: с чего начать и чем автоматизировать
Разбираем, какой процесс автоматизировать первым, чем его закрывать и как посчитать эффект до того, как подписан первый договор.
Коротко
Коротко
- Автоматизация начинается не с выбора системы, а с одного процесса, у которого есть владелец и измеримый результат.
- Способов закрыть процесс шесть, и они отличаются не ценой, а тем, чем вы за них платите — сроком, гибкостью или зависимостью от вендора.
- Готовая система выигрывает, пока процесс типовой. Как только в нём появляются свои роли, маршруты и расчёты, начинается доработка, и она обычно дороже самой системы.
- Интеграции — самая недооценённая строка любой сметы. Именно они решают, будет процесс сквозным или останется автоматизированным на одном участке.
- Эффект считается по четырём величинам, и все четыре можно замерить до старта проекта.
Что считается автоматизацией, а что цифровизацией
Слова «автоматизация» и «цифровизация» в разговоре про процессы почти всегда используют как синонимы, и от этого страдает постановка задачи. Разница между ними практическая.
Цифровизация переводит работу в электронный вид. Договор перестал ходить бумажной папкой, заявка приходит не запиской, а формой. Но человек по-прежнему смотрит, кому её передать, и переносит данные руками.
Автоматизация убирает эти самые руки. Заявка сама попадает к нужному согласующему, сама уходит на следующий шаг, сама уведомляет инициатора. У процесса появляются правила, которые исполняет система, и статус, который видно без вопроса «а где мой заказ».
Отсюда рабочий критерий, который стоит применять к любому проекту. Если после изменения кто-то в компании перестал переносить данные из одного окна в другое — это автоматизация. Если данные просто стали электронными — это шаг к ней, но пока не она.
Цифровизация переводит работу в электронный вид. Договор перестал ходить бумажной папкой, заявка приходит не запиской, а формой. Но человек по-прежнему смотрит, кому её передать, и переносит данные руками.
Автоматизация убирает эти самые руки. Заявка сама попадает к нужному согласующему, сама уходит на следующий шаг, сама уведомляет инициатора. У процесса появляются правила, которые исполняет система, и статус, который видно без вопроса «а где мой заказ».
Отсюда рабочий критерий, который стоит применять к любому проекту. Если после изменения кто-то в компании перестал переносить данные из одного окна в другое — это автоматизация. Если данные просто стали электронными — это шаг к ней, но пока не она.
Четыре уровня зрелости: где вы сейчас
Разговор о том, чем автоматизировать, бессмысленно начинать, не поняв, откуда вы стартуете. Уровни ниже — это не оценка компании, а способ выбрать следующий шаг, потому что с каждого уровня разумный шаг только один.
Самая частая ошибка на нулевом уровне — попытка перескочить сразу на третий и купить платформу управления процессами. Платформа приедет в компанию, где процессы не описаны, и превратится в дорогой список задач.
Уровень | Как выглядит | Что болит | Разумный следующий шаг |
0. Почта и таблицы | Заявки в мессенджерах, учёт в общих файлах, версии расходятся | Задачи теряются, история решений живёт в переписке | Один процесс перевести в систему целиком, от заявки до результата |
1. Учёт в одной системе | Работает 1С или CRM, остальное вокруг неё вручную | Данные дублируются, отчёты собираются руками | Связать первые две системы и убрать двойной ввод |
2. Связанные системы | Обмен настроен, справочники общие | Процессы всё равно рвутся между отделами, регламент живёт в документе | Описать сквозной процесс и передать его правила системе |
3. Управляемые процессы | Маршруты, роли и сроки внутри системы, статусы видны | Изменение процесса требует релиза и очереди в ИТ | Сократить цикл изменений, чтобы правка не ждала квартал |
Самая частая ошибка на нулевом уровне — попытка перескочить сразу на третий и купить платформу управления процессами. Платформа приедет в компанию, где процессы не описаны, и превратится в дорогой список задач.
Какой процесс автоматизировать первым
Первым берут процесс, у которого сходятся четыре признака. Он повторяется часто, в нём участвует больше двух человек, у ошибки в нём есть цена в деньгах или во времени, и результат можно измерить до и после. Если хотя бы один признак не сходится, эффект будет, но доказать его не выйдет — а второй проект утверждают именно по результатам первого.
Таблица ниже показывает, что обычно берут первым в каждой функции и чем это закрывается. Третья колонка важнее второй. Она отвечает на главный вопрос — хватит ли готового решения.
Обратите внимание, где в третьей колонке стоит «своё». Это не про сложность процесса, а про его неповторимость. Отпуск оформляют все компании, но правила согласования у каждой свои, и готовая система заставит их переписать под себя.
Когда процесс выбран, задачу нужно поставить: требования, роли и данные собираются по одной схеме — она разобрана в гайде по разработке корпоративного приложения.
Таблица ниже показывает, что обычно берут первым в каждой функции и чем это закрывается. Третья колонка важнее второй. Она отвечает на главный вопрос — хватит ли готового решения.
Функция | Что берут первым | Чем закрывается |
Продажи | Единая база клиентов и воронка со статусами | Готовая CRM, пока процесс типовой; своя система, когда появляются свои этапы и расчёты |
Снабжение | Заявка на закупку с порогами согласования | Доработка учётной системы или своё решение под регламент |
Склад | Приёмка, размещение, инвентаризация | Готовая система адресного хранения |
Финансы | Согласование счетов и платёжный календарь | Готовое решение, если суммы и лимиты стандартные |
HR | Заявки на отпуск, командировку, справки | Своё решение — регламенты в каждой компании разные |
ИТ и АХО | Заявки в службы и учёт обращений | Готовая система заявок или свой контур под нестандартные сроки |
Производство | Наряды, сменные задания, простои | Отраслевая система, часто с доработкой |
Обратите внимание, где в третьей колонке стоит «своё». Это не про сложность процесса, а про его неповторимость. Отпуск оформляют все компании, но правила согласования у каждой свои, и готовая система заставит их переписать под себя.
Когда процесс выбран, задачу нужно поставить: требования, роли и данные собираются по одной схеме — она разобрана в гайде по разработке корпоративного приложения.
ЕСТЬ ШЕСТОЙ СПОСОБ
Ассистент, который собирает систему по описанию процесса
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы, собирает из её компонентов формы, роли, права и маршруты и проверяет сборку. Разворачивает приложение сама платформа. Дальше формы и правила меняются в чате.
От заказной разработки это отличается устройством цикла. Там между потребностью и рабочей системой стоит очередь в ИТ-отдел и релиз на каждую правку. Здесь очереди нет.
Ассистент, который собирает систему по описанию процесса
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы, собирает из её компонентов формы, роли, права и маршруты и проверяет сборку. Разворачивает приложение сама платформа. Дальше формы и правила меняются в чате.
От заказной разработки это отличается устройством цикла. Там между потребностью и рабочей системой стоит очередь в ИТ-отдел и релиз на каждую правку. Здесь очереди нет.
- рабочее приложение к следующей неделе, а не к следующему кварталу
- правки в чате — форма, поле, роль, маршрут — без нового релиза
- заявленный эффект: в 10–50 раз меньше трудозатрат на типовое решение
Шесть способов автоматизации и чем вы платите за каждый
Это ядро выбора. Способы отличаются не столько стоимостью, сколько тем, что вы отдаёте в обмен на скорость. Вендор редко сравнивает варианты честно, потому что продаёт один из них.
Ни один способ не лучше остальных. У каждого есть зона, где он работает, и точка, за которой он начинает мешать. Три следующие главы разбирают три самые частые развилки.
На практике способы почти всегда комбинируются, и это нормальный итог проекта. Учёт остаётся в готовой системе, потому что там ему и место. Заявки и согласования уезжают на платформу, где их правила можно менять без релиза. Между ними встаёт интеграция, а на участке, где у чужой программы нет API, работает робот. Выбор «одно из шести» на бумаге в жизни превращается в раскладку по участкам процесса, и полезнее сразу думать в этой логике.
Способ | Что получаете | Срок первого результата | Чем платите |
Настройка готовой системы | Процесс в логике вендора, с его полями и статусами | Дни и недели | Подстройкой процесса под систему, платой за пользователей |
Low-code платформа своими руками | Процесс в своей логике, собранный вашими специалистами | Недели и месяцы | Временем своих людей и обучением, зависимостью от платформы |
Сборка ассистентом на low-code | Процесс в своей логике, собранный по описанию | Дни и недели | Границей возможностей платформы, на которой всё разворачивается |
Интеграции между системами | Данные ходят сами, двойной ввод исчезает | Недели | Поддержкой обменов и разбором сбоев |
RPA — робот на интерфейсе | Робот повторяет действия человека в чужой программе | Дни и недели | Хрупкостью: обновился интерфейс — робот встал |
Заказная разработка | Система точно под задачу, без ограничений платформы | Месяцы | Сроком, сметой и релизным циклом на каждое изменение |
Ни один способ не лучше остальных. У каждого есть зона, где он работает, и точка, за которой он начинает мешать. Три следующие главы разбирают три самые частые развилки.
На практике способы почти всегда комбинируются, и это нормальный итог проекта. Учёт остаётся в готовой системе, потому что там ему и место. Заявки и согласования уезжают на платформу, где их правила можно менять без релиза. Между ними встаёт интеграция, а на участке, где у чужой программы нет API, работает робот. Выбор «одно из шести» на бумаге в жизни превращается в раскладку по участкам процесса, и полезнее сразу думать в этой логике.
Когда хватит настройки готовой системы
Готовое решение выигрывает, пока процесс типовой. Проверить это можно одним приёмом. Опишите процесс так, как он идёт сейчас, и попробуйте пересказать его словами системы, которую рассматриваете. Если пересказ получается без оговорок вида «а у нас ещё» — берите готовое.
Оговорки, которые появляются чаще всего и всегда означают доработку. Своя ролевая модель, где сотрудник видит только свой филиал. Согласование, которое ветвится в зависимости от суммы. Расчёт по собственной формуле. Обмен с системой, у которой нет описанного API.
Есть и обратный критерий — проверяемые признаки того, что своё решение обойдётся дешевле готового. Их четыре, и каждый проверяется до пилота.
Один признак ничего не значит. Два и больше — повод считать свой вариант всерьёз.
Здесь стоит быть честным до конца. Часть задач действительно закрывается настройкой, и рассказывать компании про свою разработку в таком случае — способ потерять доверие на второй встрече. Готовое решение выигрывает и в другом случае, менее очевидном. Если процесс у вас пока не описан, готовая система навяжет ему хоть какую-то дисциплину, и это лучше, чем автоматизировать хаос.
Оговорки, которые появляются чаще всего и всегда означают доработку. Своя ролевая модель, где сотрудник видит только свой филиал. Согласование, которое ветвится в зависимости от суммы. Расчёт по собственной формуле. Обмен с системой, у которой нет описанного API.
Есть и обратный критерий — проверяемые признаки того, что своё решение обойдётся дешевле готового. Их четыре, и каждый проверяется до пилота.
- Стоимость доработки, которую вам назвали, сопоставима со стоимостью самой системы или превышает её.
- Число пользователей растёт, и лицензия за каждого превращает разовую покупку в постоянный платёж, который дальше только увеличивается.
- Процесс придётся менять чаще одного раза в квартал, и каждое изменение проходит через вендора или интегратора.
- В процессе есть расчёт или правило, которого нет ни в одной готовой системе, и вокруг него приходится строить обходные пути.
Один признак ничего не значит. Два и больше — повод считать свой вариант всерьёз.
Здесь стоит быть честным до конца. Часть задач действительно закрывается настройкой, и рассказывать компании про свою разработку в таком случае — способ потерять доверие на второй встрече. Готовое решение выигрывает и в другом случае, менее очевидном. Если процесс у вас пока не описан, готовая система навяжет ему хоть какую-то дисциплину, и это лучше, чем автоматизировать хаос.
Когда нужна сборка на low-code
Low-code становится разумным выбором на стыке двух условий. Процесс уже свой, и его придётся менять — не один раз, а постоянно, потому что меняется бизнес.
Обычная разработка на этом стыке проигрывает по цикличности. Каждое изменение проходит постановку, оценку, разработку, тестирование и релиз. На платформе то же изменение — правка в конфигурации.
Термины в этой области размыты, и на них стоит договориться заранее. No-code означает сборку без программирования вовсе, low-code — сборку, где для нетиповых мест остаётся возможность дописать логику кодом. Практическая разница не в объёме кода, а в том, где вы упрётесь в потолок. No-code упирается быстрее, зато в него заходят без разработчика.
Что меняет ИИ-ассистент в этой схеме. Сборка на low-code своими руками требует человека, который знает платформу и умеет проектировать процессы. Такого человека либо нанимают, либо учат, и это отдельный проект внутри проекта. Ассистент снимает это условие. Описание процесса на человеческом языке он переводит в описание приложения на объектном языке платформы и собирает результат из готовых компонентов. Придумать несуществующий тип поля или права, которых в платформе нет, он не может по построению — и это главное отличие от свободной генерации кода.
Тот же выбор в разрезе конкретных задач — форма, реестр, согласование с порогами сумм — разобран в статье про разницу low-code и no-code.
Обычная разработка на этом стыке проигрывает по цикличности. Каждое изменение проходит постановку, оценку, разработку, тестирование и релиз. На платформе то же изменение — правка в конфигурации.
Термины в этой области размыты, и на них стоит договориться заранее. No-code означает сборку без программирования вовсе, low-code — сборку, где для нетиповых мест остаётся возможность дописать логику кодом. Практическая разница не в объёме кода, а в том, где вы упрётесь в потолок. No-code упирается быстрее, зато в него заходят без разработчика.
Что меняет ИИ-ассистент в этой схеме. Сборка на low-code своими руками требует человека, который знает платформу и умеет проектировать процессы. Такого человека либо нанимают, либо учат, и это отдельный проект внутри проекта. Ассистент снимает это условие. Описание процесса на человеческом языке он переводит в описание приложения на объектном языке платформы и собирает результат из готовых компонентов. Придумать несуществующий тип поля или права, которых в платформе нет, он не может по построению — и это главное отличие от свободной генерации кода.
Тот же выбор в разрезе конкретных задач — форма, реестр, согласование с порогами сумм — разобран в статье про разницу low-code и no-code.
Когда без заказной разработки не обойтись
Есть класс задач, где платформа становится ограничением. Признаки прямые.
В этих случаях разумно разделять периметр. Ядро пишут под задачу, а внутренние контуры вокруг него — заявки, согласования, кабинеты, реестры — собирают на платформе. Смысл разделения экономический. Внутренние системы редко оправдывают полноценный проект разработки по отдельности, но вместе съедают заметную долю бэклога ИТ-отдела.
- Продукт публичный и высоконагруженный, а требования к отклику и отказоустойчивости прописаны в договоре с клиентом.
- Ядро продукта — собственный алгоритм, и он и есть ваше конкурентное преимущество.
- Нужен уникальный интерфейс, за который клиент платит отдельно.
- Требования безопасности предполагают контур, куда платформа не встаёт.
В этих случаях разумно разделять периметр. Ядро пишут под задачу, а внутренние контуры вокруг него — заявки, согласования, кабинеты, реестры — собирают на платформе. Смысл разделения экономический. Внутренние системы редко оправдывают полноценный проект разработки по отдельности, но вместе съедают заметную долю бэклога ИТ-отдела.
Интеграции: главная строка сметы
В обзорах автоматизации интеграции обычно упоминают как техническую деталь. На практике они стоят дороже самой автоматизации и решают, будет процесс сквозным или останется автоматизированным на одном участке.
Причина в том, что цена интеграции определяется не вашей системой, а чужой. Если у системы на другой стороне есть описанный API, связка идёт быстро. Если API нет, данные забирают из выгрузок, и на каждую выгрузку нужен разбор формата и сверка.
Что закладывать в проект, кроме самой связки.
Причина в том, что цена интеграции определяется не вашей системой, а чужой. Если у системы на другой стороне есть описанный API, связка идёт быстро. Если API нет, данные забирают из выгрузок, и на каждую выгрузку нужен разбор формата и сверка.
Что закладывать в проект, кроме самой связки.
- Обработку отказов. Система на другой стороне однажды не ответит, и вопрос лишь в том, встанет процесс или заявка дождётся в очереди.
- Сверку. Кто-то должен видеть, что в двух системах одинаковые данные. Это регулярная работа, и её закладывают в процесс на старте вместе с самой связкой.
- Разбор ошибок. Молчаливый сбой обмена обнаруживают через неделю по расхождению в отчёте, и это самый дорогой способ его обнаружить.
- Владельца обмена на вашей стороне. Человека, который знает, что связка существует.
КОГДА ПРОЦЕСС ИЗМЕНИТСЯ
Правка процесса не должна стоить релиза
Автоматизация ломается не в момент запуска, а через полгода, когда процесс меняется. Добавили филиал, поменяли порог согласования, ввели новую роль — и система, собранная под прежние правила, начинает мешать вместо помощи.
У Nolan изменение живёт в том же режиме, что и первая сборка. Вы описываете правку в чате, ассистент вносит её в описание приложения и проверяет сборку, а разворачивает результат платформа. Форма, поле, роль, маршрут — без нового релиза и без сметы на доработку.
Собранное приложение при этом не заперто в конструкторе. По нему формируется итоговое ТЗ и документация на функциональность, и дальше разработку ведут по этому описанию.
Правка процесса не должна стоить релиза
Автоматизация ломается не в момент запуска, а через полгода, когда процесс меняется. Добавили филиал, поменяли порог согласования, ввели новую роль — и система, собранная под прежние правила, начинает мешать вместо помощи.
У Nolan изменение живёт в том же режиме, что и первая сборка. Вы описываете правку в чате, ассистент вносит её в описание приложения и проверяет сборку, а разворачивает результат платформа. Форма, поле, роль, маршрут — без нового релиза и без сметы на доработку.
Собранное приложение при этом не заперто в конструкторе. По нему формируется итоговое ТЗ и документация на функциональность, и дальше разработку ведут по этому описанию.
- изменение процесса не ждёт очереди в ИТ-отделе
- итоговое ТЗ и документация на собранное приложение
- отечественные языковые модели и размещение в РФ
Данные: почему без единого источника автоматизация не работает
У каждой сущности должно быть одно место, где она хранится, и одна система, которая имеет право её менять. Пока это условие не выполнено, любая автоматизация будет воспроизводить расхождения быстрее, чем человек успевал их замечать.
Признак нарушения простой. Спросите у трёх сотрудников из разных отделов, сколько у компании активных клиентов. Если ответы различаются, у сущности «клиент» нет единого источника, и первым проектом должен стать именно он. Маршруты согласования подождут.
Второе условие — справочники. Один и тот же контрагент, написанный в трёх системах тремя способами, превращает любую сверку в ручную работу. Приведение справочников к общему виду выглядит скучной задачей и почти всегда даёт эффект больше, чем следующий за ней проект.
Третье условие касается права на изменение. У каждой сущности должна быть одна система-хозяин, и остальные получают данные от неё только на чтение. Нарушение этого правила выглядит удобным на старте — менеджеру разрешили поправить адрес клиента и в CRM, и в учётной системе — а через полгода никто не может сказать, какая запись верная. Правило простое. Если данные меняются в двух местах, конфликт не вопрос вероятности, а вопрос времени.
Признак нарушения простой. Спросите у трёх сотрудников из разных отделов, сколько у компании активных клиентов. Если ответы различаются, у сущности «клиент» нет единого источника, и первым проектом должен стать именно он. Маршруты согласования подождут.
Второе условие — справочники. Один и тот же контрагент, написанный в трёх системах тремя способами, превращает любую сверку в ручную работу. Приведение справочников к общему виду выглядит скучной задачей и почти всегда даёт эффект больше, чем следующий за ней проект.
Третье условие касается права на изменение. У каждой сущности должна быть одна система-хозяин, и остальные получают данные от неё только на чтение. Нарушение этого правила выглядит удобным на старте — менеджеру разрешили поправить адрес клиента и в CRM, и в учётной системе — а через полгода никто не может сказать, какая запись верная. Правило простое. Если данные меняются в двух местах, конфликт не вопрос вероятности, а вопрос времени.
Что спросить у вендора до пилота
Пилот — самый дорогой способ узнать про ограничения системы, поэтому часть вопросов задают до него. Шесть, которые экономят больше всего времени.
- Как в системе описывается наше правило. Не «поддерживается ли», а именно как. Просите показать на своём примере, с порогами и ветвлением, которые у вас реально есть.
- Кто вносит изменения после запуска и в какие сроки. Ответ «настраивается без программиста» уточняйте до конкретики — какой сотрудник, какой квалификации, сколько времени занимает типовая правка.
- Что происходит с данными при отказе от системы. В каком виде вы их получите и останется ли работоспособной логика процесса.
- Как система ведёт себя, когда смежная не отвечает. Этот вопрос отделяет продуманную интеграцию от демонстрационной.
- Что входит в поддержку, а что считается доработкой. Граница между этими понятиями у каждого вендора своя, и именно она определяет расходы второго года.
- Есть ли внедрение в вашей отрасли и можно ли поговорить с этим заказчиком. Отказ отвечать на этот вопрос сам по себе информативен.
ИИ в процессах: что работает в 2026, а где ставить его нельзя
Языковые модели вошли в процессы, и разговор о них полезно вести без хайпа. Есть задачи, где они дают устойчивый результат уже сейчас.
И есть граница, за которую ИИ в процессе не заводят. Решение, которое имеет последствия для человека или денег, не должно приниматься моделью без проверки. Отказ по заявке, согласование платежа, оценка сотрудника — здесь модель готовит материал, а решает человек. Причина не в качестве модели, а в ответственности — за отказ отвечает тот, кто его подписал.
Отдельная связка, которая в 2026 работает лучше всего — робот плюс модель. Робот делает механическую часть в чужом интерфейсе, модель разбирает неструктурированный вход. Так закрывают участки, где нет API и нет шансов его получить.
- Классификация обращений и заявок по теме и приоритету.
- Извлечение данных из документов, где формат не фиксирован.
- Черновик ответа для оператора, который тот правит и отправляет.
- Поиск по базе знаний, когда сотрудник не знает точной формулировки.
- Разбор того, как процесс идёт на самом деле, по журналам систем.
И есть граница, за которую ИИ в процессе не заводят. Решение, которое имеет последствия для человека или денег, не должно приниматься моделью без проверки. Отказ по заявке, согласование платежа, оценка сотрудника — здесь модель готовит материал, а решает человек. Причина не в качестве модели, а в ответственности — за отказ отвечает тот, кто его подписал.
Отдельная связка, которая в 2026 работает лучше всего — робот плюс модель. Робот делает механическую часть в чужом интерфейсе, модель разбирает неструктурированный вход. Так закрывают участки, где нет API и нет шансов его получить.
Как считать эффект
Эффект автоматизации считают по четырём величинам, и все четыре замеряются до старта проекта. Замер до — единственный способ потом доказать результат, и его почти всегда пропускают.
Формула для третьей строки работает как черновик бизнес-кейса. Возьмите процесс согласования, в котором участвуют четверо, каждый тратит на случай около двадцати минут, а случаев в месяц двести. Это примерно двести шестьдесят часов работы в месяц. Подставьте свою стоимость часа и умножьте на двенадцать — получится годовая цифра, с которой уже можно идти к финансовому директору. Дальше от неё вычитают стоимость решения и владения им.
Точность такого расчёта невысокая, и это нормально. Его задача — показать порядок величины и понять, окупается ли проект в разы или в процентах.
Часть эффекта в такую арифметику не попадает, но на защите бюджета работает не хуже. Снятый риск, когда согласование перестаёт зависеть от одного человека в отпуске. Прозрачность, из-за которой руководитель видит загрузку без запроса отчёта. Удержание людей, для которых исчезла самая унылая часть работы. Эти вещи не считаются в рублях, поэтому их формулируют отдельным абзацем к расчёту и не пытаются подогнать под таблицу.
Что мерим | Как замерить до старта | Что показывает после |
Время цикла | Сколько календарных дней проходит от заявки до результата, по десяти последним случаям | Насколько процесс стал быстрее |
Доля ошибок | Сколько случаев из ста ушло на переделку или сверку | Сколько ручной работы исчезло вместе с ошибками |
Стоимость операции | Время участников на один случай, умноженное на стоимость их часа | Экономию в деньгах на объёме за год |
Прозрачность | Сколько времени уходит на ответ «где мой заказ» | Исчезла ли отдельная работа по сбору статусов |
Формула для третьей строки работает как черновик бизнес-кейса. Возьмите процесс согласования, в котором участвуют четверо, каждый тратит на случай около двадцати минут, а случаев в месяц двести. Это примерно двести шестьдесят часов работы в месяц. Подставьте свою стоимость часа и умножьте на двенадцать — получится годовая цифра, с которой уже можно идти к финансовому директору. Дальше от неё вычитают стоимость решения и владения им.
Точность такого расчёта невысокая, и это нормально. Его задача — показать порядок величины и понять, окупается ли проект в разы или в процентах.
Часть эффекта в такую арифметику не попадает, но на защите бюджета работает не хуже. Снятый риск, когда согласование перестаёт зависеть от одного человека в отпуске. Прозрачность, из-за которой руководитель видит загрузку без запроса отчёта. Удержание людей, для которых исчезла самая унылая часть работы. Эти вещи не считаются в рублях, поэтому их формулируют отдельным абзацем к расчёту и не пытаются подогнать под таблицу.
Чек-лист готовности к автоматизации
Проект стоит начинать, когда сходятся все пять пунктов. Если не сходится хотя бы один, сначала закрывают его.
Отдельно про исключения. В описании процесса их часто опускают как редкие случаи, а потом именно они съедают половину проекта. Правило простое — если исключение случается чаще одного раза в месяц, оно часть процесса.
- Процесс описан так, как он идёт сейчас, включая исключения и обходные пути.
- У процесса есть владелец — человек, который отвечает за результат и имеет право менять правила.
- Данные, которые процессу нужны, лежат в системах, а не в личных файлах участников.
- Есть кому принимать результат: сотрудники, которые будут в системе работать, знают о проекте.
- Замерены четыре величины из предыдущей главы.
Отдельно про исключения. В описании процесса их часто опускают как редкие случаи, а потом именно они съедают половину проекта. Правило простое — если исключение случается чаще одного раза в месяц, оно часть процесса.
Российский рынок и импортозамещение
Контекст, в котором принимаются решения об автоматизации, за последние три года изменился. Ниже сводка по классам систем, которая пригодится при выборе.
Главный барьер импортозамещения в процессах не в отсутствии модулей, а в недостаточной глубине их реализации. Отечественный аналог закрывает восемьдесят процентов функций, а оставшиеся двадцать оказываются теми, на которых держался процесс. Именно там и появляется доработка, и её объём стоит выяснять до подписания договора.
Реестр отечественного ПО при этом стоит читать как фильтр, а не как аргумент качества. Через него проходит большинство российского рынка, и наличие записи говорит о формальном соответствии требованиям, но не о том, что система подойдёт вашему процессу.
Класс систем | Что на рынке | Что учесть |
ERP | Рынок оценивается примерно в 110 млрд ₽, доля отечественных решений по итогам 2026 года около 75 %. Ведущие вендоры — «1С», «Галактика», «Турбо», Global ERP, «Парус» | Миграция с зарубежной ERP занимает по оценкам 18–36 месяцев, и 58 % компаний ещё остаются на SAP |
BPM | Топ-10 поставщиков заработали на BPM-проектах около 15,6 млрд ₽ за 2024 год, лидер — BPMSoft. Зрелая тройка — BPMSoft, ELMA365, Directum RX | Сегмент замедлился после нескольких лет быстрого роста, компании осторожнее в расходах |
RPA | Четыре платформы делят рынок: ROBIN от SL Soft в банках и корпорациях, Primo RPA в среднем бизнесе и госсекторе, PIX Robotics в ритейле и логистике, Sherpa RPA в enterprise | ROBIN занял нишу ушедшего UiPath; выбор платформы обычно определяется отраслью |
Low-code | Рынок оценивают в 9–13 млрд ₽ по 2025 году с прогнозом около 30 млрд ₽ к 2030-му, доля отечественных решений растёт с 35 % до 55 % | В реестре отечественного ПО есть nocode.ru, ELMA365, BPMSoft, Comindware |
Главный барьер импортозамещения в процессах не в отсутствии модулей, а в недостаточной глубине их реализации. Отечественный аналог закрывает восемьдесят процентов функций, а оставшиеся двадцать оказываются теми, на которых держался процесс. Именно там и появляется доработка, и её объём стоит выяснять до подписания договора.
Реестр отечественного ПО при этом стоит читать как фильтр, а не как аргумент качества. Через него проходит большинство российского рынка, и наличие записи говорит о формальном соответствии требованиям, но не о том, что система подойдёт вашему процессу.
Типичные ошибки
Пять сценариев, которые повторяются чаще всего.
- Автоматизировали хаос. Процесс не был описан, и система закрепила беспорядок, сделав его быстрее. Лечится только откатом к описанию.
- Начали с самого сложного. Первым проектом взяли производство или финансы, где больше всего участников и согласований. Результата нет полгода, доверие к автоматизации потеряно.
- Не назначили владельца. Проект вёл ИТ-отдел, бизнес наблюдал со стороны, готовую систему никто не считает своей.
- Забыли про интеграции. Автоматизировали участок, данные на входе и выходе продолжают переноситься руками, сквозного процесса не получилось.
- Автоматизировали то, что стоило отменить. Самый частый и самый обидный случай. Прежде чем автоматизировать согласование, стоит спросить, зачем в нём четыре подписи.
Покажем Nolan на вашем процессе
Свяжемся в течение одного рабочего дня. Без спама.
Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе
1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»
Компания «Технологии возврата»
3 года занимается разработкой и развитием ИИ
Из описания — в готовое приложение