Первый этап проходят почти все. Бухгалтерия в учетной программе, продажи в CRM, заявки с сайта в почте, склад в таблице. Каждый инструмент работает, каждый отдел доволен.
Второй этап не проходит почти никто. Спросите, сколько заявок пришло за месяц, и получите три разные цифры от трех человек. Каждая посчитана честно, ни одна не сходится с другими.
Это и есть застревание между автоматизацией отдельных процессов и цифровым предприятием. Ниже разбираем, где именно рвется путь, по каким признакам это видно и сколько стоит связывание того, что уже стоит.
Что называют лоскутной автоматизацией
Термин описывает состояние, когда в компании много рабочих систем и ни одного сквозного процесса. Данные складываются в изолированные хранилища: технологические в одну программу, финансовые в другую, клиентские в третью.
Изнутри это не выглядит проблемой. Каждая система куплена под реальную задачу и задачу решает. Проблема видна только на стыках, а стыками никто не владеет.
Разница между второй и третьей ступенью принципиальная. На второй системы обмениваются данными. На третьей у процесса появляется одно состояние, общее для всех участников, и по нему видно, где заявка находится прямо сейчас.
Разрыв первый: результат живет там, где его сделали
Самая частая поломка выглядит безобидно. Работа сделана, отчет написан, файл лежит в папке исполнителя. Формально процесс автоматизирован. Фактически знание умерло вместе с задачей.
У нас это случилось с собственным конвейером контента. За девять дней августа 2026 года монитор запросов журналистов отработал 11 раз и нашел 92 запроса. Пять превратились в статьи на сайте, 13 получили файл с комментарием. Еще 35 запросов подходили по теме и остались без движения.
Потерялись они по технической причине. Состояние жило в отчете прогона: сегодняшний отчет перекрывался завтрашним, годная тема с дедлайном через неделю исчезала вместе с файлом. Никто не принимал решения выбросить эти 35 тем. Их просто некуда было записать.
27 августа 2026 года состояние вынесли в общую базу. Сейчас там 164 темы, 92 запроса и 72 статьи в одной таблице, у каждой темы есть статус и владелец. Тема больше не может пропасть молча: она либо в работе, либо опубликована, либо закрыта с причиной.
Признак этого разрыва простой. Если ответ на вопрос «а что мы решили в прошлый раз» требует найти нужного человека, состояние процесса хранится в голове, а не в системе.
Разрыв второй: шаг автоматизирован, процесс нет
Второй случай тоньше. Автоматика работает, метрика зеленая, а обещание клиенту не выполнено.
11 августа 2026 года на нашей странице индекса автономности форма обещала прислать разбор в течение рабочего дня. Обработчик формы отправлял письмо только внутрь компании. Цель в веб-аналитике при этом отрабатывала штатно, отчет по конверсиям был зеленый, счетчик заявок рос.
Автоматизирован был шаг: принять заявку и уведомить нас. Процесс, который заканчивается письмом клиенту, автоматизирован не был, и разница между этими двумя вещами не видна ни в одном отчете. Для веб-аналитики конверсия состоялась.
Отсюда правило, которое стоит нам дорого и потому запомнилось: у автоматизированного процесса должно быть событие завершения, наблюдаемое снаружи. Не «форма отправлена», а «клиент получил то, что ему обещали». Как этот участок закрывается технически, разбирали в материале про сквозную аналитику на Метрике и CRM.
Разрыв третий: локальный оптимум против общего
Третий барьер управленческий, и в вопросах отраслевых журналистов он формулируется так: локальный оптимум отдельной установки расходится с общезаводским.
Пример из нашей практики. 8 июля 2026 года мы чинили сервис пересчета метрик на общем рабочем сервере. Правка была применена и проверена, пересчет заработал. Через несколько часов параллельный процесс переписал ее обратно, потому что действовал по устаревшему заданию. Пересчет снова упал.
Оба участника были правы по-своему. Один чинил по факту ошибки, второй выполнял согласованное задание. Не хватало общего состояния: места, где написано, что задание уже неактуально.
В этом и есть суть барьера. Каждый отдел оптимизирует свой участок и делает это грамотно. Сумма грамотных локальных решений дает неработающее целое, и увидеть это можно только с уровня, где виден весь процесс.
Такая же история с рекламой. 22 июля 2026 года наша поисковая кампания потратила за сутки 8449 ₽ против 290 ₽ накануне. Разрез по часам, из которого стало понятно, что бюджет ушел за шестьдесят минут, есть только в веб-аналитике: рекламный кабинет почасовых данных не отдает. Ни одна из двух систем поодиночке ответа не давала.
Четыре уровня зрелости: где вы находитесь
| Уровень | Как выглядит | Проверочный вопрос | Что дает переход дальше |
|---|---|---|---|
| 1. Инструменты | Каждый отдел работает в своей программе, обмен файлами и сообщениями | Сколько раз в неделю данные переносятся руками? | Исчезает ручной перенос и опечатки при копировании |
| 2. Связки | Системы обмениваются данными через выгрузки и вебхуки | Как вы узнаете, что связка перестала работать? | Поломки видно раньше, чем о них сообщит клиент |
| 3. Сквозной процесс | У процесса одно состояние, видны начало, конец и текущий шаг | Где посмотреть, на каком шаге стоит конкретная заявка? | Появляется предмет для управления: очередь, сроки, узкие места |
| 4. Управление по данным | Решения принимаются по цифрам, которые считает система, а не человек | Совпадают ли цифры отдела и общая цифра компании? | Локальные улучшения перестают оплачиваться чужими потерями |
Уровень определяется по самому слабому процессу, а не по самому сильному. Компания с образцовым складским учетом и заявками в общей почте стоит на первом уровне.
Три способа связать то, что уже стоит
Вендоры предлагают один ответ: перевести все на единую платформу. Ответ рабочий и самый дорогой из трех.
| Подход | Кому подходит | Срок до первого результата | Где ломается |
|---|---|---|---|
| Единая платформа вместо парка систем | Компании, готовые переносить процессы целиком и менять привычки отделов | Месяцы, обычно с внешним внедренцем | Отраслевой учет, который в платформу не переносится, остается снаружи и снова становится островом |
| Интеграционный слой поверх существующих систем | Тем, у кого системы менять нельзя: учет, производство, отраслевые программы | Недели | Слой пишется один раз и потом не сопровождается, словарь полей расходится с реальностью |
| Точечные связки по одному процессу за раз | Тем, кому нужен результат до конца квартала и без остановки работы | Дни на первый процесс | Без общего состояния набор связок со временем сам превращается в лоскутное одеяло |
Третий подход мы применяем чаще всего, и у него есть честное ограничение. Он работает, пока каждая связка отдает свое состояние в одно место. Как только связки начинают знать только про себя, компания возвращается на второй уровень с большим количеством кода.
Техническая сторона обычная: обмен по интерфейсу программы, выгрузка по расписанию и словарь соответствия полей. Что именно и за какие деньги мы соединяем, описано в материале про интеграцию систем через API, а частный случай учетной программы разобран в статье про интеграцию сайта с 1С.
Сколько стоит рынок и за что берет деньги
Цены ниже сняты с публичных страниц вендоров 27 августа 2026 года и с тех пор могли измениться.
| Решение | За что считают деньги | Публичная цена на 27.08.2026 |
|---|---|---|
| Битрикс24 | Число пользователей в портале и объем диска | Базовый 2 490 ₽/мес за 5 пользователей, Стандартный 6 990 ₽/мес за 50, Профессиональный 13 990 ₽/мес за 100. На странице показана акционная скидка 35 % |
| ELMA365 | Лицензии на пользователя, отдельно облако и свой сервер | Облако: именная лицензия 10 000 ₽ за год, конкурентная 20 000 ₽ за год. Свой сервер: именная 17 000 ₽ единовременно, конкурентная 34 000 ₽ |
| n8n | Число запусков сценариев в месяц, шаги внутри сценария не считаются | Starter 20 €/мес при годовой оплате за 2 500 запусков, Pro 50 €/мес за 10 000, Business 667 €/мес за 40 000 |
| Связывание существующих систем по часам | Часы разработчика на разбор процесса, связку и правки при изменении полей | 2 500 ₽/ч, оплата по факту, без аванса |
Из таблицы видно устройство рынка. Подписка считается за пользователей или за запуски, то есть растет вместе с размером компании, а не вместе с числом связанных процессов. Компания на пятьдесят человек платит за пятьдесят мест независимо от того, связаны у нее склад с бухгалтерией или нет.
Настоящая стоимость перехода на третий уровень лежит в другом месте. Она измеряется часами на разбор процесса: кто передает работу дальше, в каком виде, что считается завершением. Лицензия эту работу не выполняет.
План на неделю, который сдвигает с места
-
Возьмите один процесс, а не все сразу
Лучше тот, где деньги теряются заметнее всего: обработка входящей заявки, отгрузка, согласование счета. Остальные пока не трогайте.
-
Пройдите его руками от начала до конца
Запишите каждый переход между системами и людьми. Места, где кто-то копирует данные из окна в окно, и есть будущие связки.
-
Назовите событие завершения
Одна проверяемая снаружи вещь: клиент получил письмо, документ подписан, деньги пришли. Внутренние галочки завершением не считаются.
-
Соберите состояние в одном месте
Таблица со статусами на старте подходит. Важно, чтобы у каждой заявки было одно текущее состояние, доступное всем участникам.
-
Поставьте уведомление о поломке
Связка обязана сообщать, что перестала работать. Иначе о ее поломке вы узнаете от клиента, и это будет дороже.
Через неделю такой работы становится видно, нужна ли вообще новая платформа. По нашему опыту в половине случаев хватает двух связок и одной общей таблицы состояний.
Свяжем ваши системы без замены парка программ
Разберем один процесс от заявки до завершения, соединим учет, CRM и сайт, поставим уведомления о поломке связки. Ставка 2 500 ₽/ч, оплата по факту, без аванса.
Частые вопросы
Чем лоскутная автоматизация отличается от нормальной?
Числом систем она не определяется. Компания с десятью программами может работать сквозным процессом, а компания с двумя может стоять на первом уровне. Отличие в том, есть ли у процесса одно общее состояние. Если на вопрос «где сейчас эта заявка» отвечает человек по памяти, а не система, автоматизация лоскутная, сколько бы программ ни было куплено.
Обязательно ли переходить на единую платформу?
Нет, и чаще это лишний расход. Единая платформа оправдана, когда процессы действительно однотипны и их можно перенести целиком. Отраслевой учет, производственные и лабораторные системы в платформу обычно не переносятся, остаются снаружи и снова становятся островами. Дешевле оставить существующие системы и связать их по одному процессу за раз, начиная с того, где потери заметнее.
С чего начать, если процессов много и все важные?
Начинать надо с процесса, у которого измеримая цена сбоя. Обработка входящей заявки подходит почти всегда: стоимость заявки известна, а факт того, что ответа не было, проверяется за минуту. У нас самих три оплаченные заявки пролежали без ответа десять дней, и нашлись они не в отчете, а при ручной проверке почты. Разбор одного такого процесса дает список связок для всех остальных.
Сколько времени занимает связка двух систем?
Если у обеих систем есть программный интерфейс и понятно, какие поля переносить, работа занимает от одного дня до недели. Дольше всего согласовывается словарь соответствия полей: одно и то же поле в двух системах называется по-разному и хранит разное. Отдельно закладывается время на уведомление о поломке связки, без него интеграция считается недоделанной.
Что делать с самописной системой, к которой нет коннекторов?
Готового коннектора для нее не будет, зато есть база данных и возможность дописать два места: прием данных снаружи и отдачу своих наружу. Обе части пишутся в рамках обычной интеграционной задачи. Переезжать на коробочное решение ради связки не требуется, и в случае отраслевого учета переезд обычно обходится дороже, чем доработка.
Посмотрим, где ваш процесс обрывается
Оставьте контакт: разберем один процесс от заявки до завершения, вернем список мест, где данные теряются, и оценку часов на связывание.
