Коротко: за последние годы мы в компании провели десятки диагностик автоматизации в компаниях разного размера. И почти всегда провал проекта закладывается не в момент внедрения, а на несколько месяцев раньше — в четырёх решениях, которые принимают до того, как написана первая строчка кода. Разберу их на сквозном кейсе: аудит диверсифицированного холдинга из девяти предприятий, где мы прошли путь от «а сколько мы вообще теряем» до готовой дорожной карты.
Про автоматизацию в бизнесе принято говорить как про технологию: какую модель взять, какой стек, сколько GPU. Причём в последние пару лет любой такой проект по умолчанию называют «внедрением ИИ» — хотя на деле под капотом обычно смесь: где-то нейросеть, где-то распознавание документов, где-то простые правила, а где-то ИИ вообще не нужен. Это нормально, и дальше я буду говорить «автоматизация», подразумевая весь этот спектр. Важно другое: за годы диагностик мы убедились, что технология — самая предсказуемая часть проекта. Она либо работает, либо нет, и это видно быстро. Проваливаются проекты на другом — на решениях, которые принимаются до внедрения и почти никогда не обсуждаются публично. Расскажу про четыре таких решения на одном сквозном кейсе.
Кейс такой. К нам пришёл диверсифицированный холдинг — девять предприятий из совершенно разных отраслей: вывоз и переработка отходов, сельское хозяйство, производство, гостиница, юридические услуги. Объединяет их управляющая компания, которой нужно видеть всю группу целиком. Запрос был типовым: «хотим внедрить ИИ, посоветуйте, с чего начать».
Решение первое: посчитать цену бездействия, а не стоимость внедрения
Есть вопрос, ответ на который безошибочно отличает подготовленную команду внедрения от неподготовленной. Он звучит так: «А сколько мы теряем прямо сейчас, если ничего не делать?» На презентациях решений по автоматизации его рано или поздно задаёт финансовый директор — и в этот момент обычно выясняется, что у команды есть детальный расчёт стоимости решения, но нет цифры стоимости проблемы. Разговор с самого начала идет не с того конца: обсуждаем цену решения, не назвав цену того, что оно устраняет.
Поэтому мы и начинаем не с презентации технологий и решений, а с глубокого и вдумчивого знакомства с устройством компании и последующим расчетом в деньгах и цифрах.
Методика простая до банальности: по каждому процессу считаем три величины — как часто он повторяется, сколько времени занимает один цикл и сколько человек в нём задействовано. Перемножаешь — получаешь часы в месяц. Часы переводишь в деньги по реальным ставкам ФОТ с начислениями. Цифры со слов сотрудников перепроверяем по выгрузкам из учётных систем: люди называют время, когда всё идёт по плану, а системы фиксируют реальность — с переделками, простоями и повторными заходами.
В холдинге, о котором идёт речь, мы перебрали так 47 процессов. По одиннадцати отобранным набралось 2 464 человеко-часа в месяц на задачах, которые не требуют человеческого участия. Автоматизация снимает из них около 2 000 часов — это эквивалент примерно двенадцати штатных единиц, если считать по норме продуктивного времени. Не «двенадцать человек под сокращение», а двенадцать полных ставок рабочего времени, которое сейчас уходит на рутину, а могло бы уходить на задачи, где нужен человек. В деньгах по ставкам ФОТ группы — от 8,9 до 13,5 миллиона рублей в год, в зависимости от сценария.
И вот что показательно с точки зрения управления. Эти потери никто не чувствовал. Они размазаны по десяткам сотрудников и сотням мелких операций — никто не жалуется, что каждое утро тратит двадцать минут на сведение таблицы, это просто работа. Потерю невозможно ощутить как проблему, пока кто-то не сведёт её в одну цифру.
Когда собственник видит не «стоимость автоматизации», а «цену бездействия», разговор меняется. Вопрос «стоит ли внедрять» отпадает сам собой. Поэтому первое решение, которое определяет судьбу проекта, — считать не то, во что обойдётся технология, а то, во что уже обходится её отсутствие.
Решение второе: выбрать очередь, а не хвататься за самое дорогое
Когда у директора на руках список процессов с ценой каждого, первый инстинкт — взяться за самый дорогой. Логика железная: где теряем больше всего, там и чиним первым. И почти всегда она ведёт проект в стену.
Самый дорогой процесс дорогой не случайно. Он большой, разветвлённый, завязан на много людей и систем — потому и потери на нём крупные. Но ровно эти же свойства делают его тяжёлым для автоматизации. Берёшь в работу самое дорогое — берёшь самое сложное: вкладываешь больше всего, ждёшь дольше всего, рискуешь сильнее всего. Первый же проект буксует полгода — и у руководства готов вывод: «ИИ у нас не работает». Хотя подвела не технология, а выбор, с чего начать.
Поэтому мы давно не оцениваем процессы по одной цифре потерь. Каждый проходит через две независимые шкалы от одного до десяти. Первая — влияние на бизнес: сколько денег, времени и риска снимает автоматизация. Вторая — сложность реализации: однозначны ли правила, есть ли данные, сколько систем придётся связать. Оси независимы: высокое влияние не означает высокую сложность. Бывает дорого и легко, бывает дёшево и адски трудно.
Хороший первый кандидат живёт в одном углу карты: высокое влияние при низкой сложности. Разберу на реальных оценках из проекта.
Распознавание паспортов и сканов — влияние 10, сложность 3. Ручной ввод персональных данных идёт постоянно, ошибки дорогие, а технически это зрелая задача: OCR плюс валидация полей по справочникам, минимум интерпретации. Согласование договоров — влияние 8, сложность 2: поток документов из разных каналов, но задача сводится к единому потоку и проверке по чек-листу рисков. Управленческая отчётность на отдельном предприятии — влияние 10, сложность 2: сам процесс сбора внутри одной системы формализуем, показатели заданы классификатором. Одна оговорка, она понадобится дальше: низкая сложность здесь относится к сбору отчётности в пределах одного контура. Сшивание отчётности всех девяти предприятий в единую картину — отдельная и куда более тяжёлая задача, к ней вернусь в разделе про данные. Эти три процесса — верхний угол, берём в первую очередь.
А вот контроль закупок на злоупотребления — влияние 8, но сложность 6. И речевая аналитика звонков — влияние 5 при сложности 8: распознавание речи в реальном времени, отраслевой сленг, интеграция с телефонией. Средняя польза за максимальные усилия — не для старта.
Логика очерёдности не только финансовая, она психологическая. Первые процессы в проекте работают прежде всего на доверие, а уже потом на экономику. Руководству нужно увидеть результат быстро — иначе доверие тает раньше, чем приходит эффект. Несколько быстрых побед в первые месяцы создают кредит, под который потом можно браться за сложное и долгое. Начнёшь с тяжёлого процесса, который даёт эффект через год, — доверие закончится раньше эффекта. Формально делаешь самое ценное, фактически рубишь сук, на котором держится проект.
Решение третье: честно отказаться от того, что не готово
Тот самый контроль закупок клиент хотел автоматизировать в первую очередь. Боль реальная: закупки в обход тендера, завышенные цены у «своих» поставщиков, подмена номенклатуры. По влиянию — твёрдая восьмёрка, прямой запрос собственника. С точки зрения продаж — идеальный заказ: дорогой, важный, очевидная ценность. Мы сказали «рано».
Причина в природе задачи. Чтобы алгоритм квалифицировал завышение цены, ему нужно знать, какая цена нормальная, — нужен рыночный коридор по каждой позиции. А рыночная цена на материал или услугу не константа: она плывёт по регионам, скачет по сезонам, зависит от объёма и срочности. Установить этот коридор — не вычисление, а экспертное суждение, опирающееся на данные, которых у клиента пока нет в нужном объёме.
Но упрощать тут нельзя. Искать аномалии можно и без внешнего эталона цены: отклонения от собственной истории закупок, дробление сумм у порогового значения, необычная концентрация на одном поставщике, нетипичные связки «поставщик — сотрудник — номенклатура». Всё это система находит и без рыночного коридора. Но находит она кандидатов на проверку, а не доказанные нарушения. Без качественной базы и формализованных сценариев квалифицировать закупку как злоупотребление автоматически нельзя — можно лишь подсветить её человеку. А клиент хотел именно автоматический контроль, и вот его-то на текущих данных мы честно дать не могли.
Мы могли сделать вид, что это решаемо здесь и сейчас: запустить модель, показать интерфейс с «подозрительными» закупками. Она выдавала бы сигналы, половина из них ложные, потому что норма кривая. Через месяц-другой люди привыкают, что система ошибается, и перестают на неё реагировать. Реальное злоупотребление теряется среди ложных тревог так же надёжно, как терялось в ручном режиме. Клиент заплатил бы за инструмент, который не работает, а следующий разумный процесс встретил бы сопротивление: «мы уже пробовали ваш ИИ, помните, чем кончилось».
Зрелость подрядчика проверяется не тем, за что он берётся, а тем, от чего отказывается. Тот, кто говорит «да» на всё, либо не понимает рисков, либо понимает, но молчит ради денег. Мы предложили другое: запустить сначала процессы с быстрым и предсказуемым эффектом, накопить на них чистые данные, а контроль закупок вернуть в третью фазу — когда появится, из чего строить рыночный коридор. Тот же процесс, но запущенный тогда, когда он сработает.
Отсюда практический критерий, применимый к любому процессу: существует ли для него чёткое правило, отделяющее норму от отклонения? Если правило есть и оно стабильно — процесс автоматизируется хорошо. Если норму нужно каждый раз определять экспертно, с учётом десятка меняющихся факторов, — процесс либо не готов, либо требует долгой подготовки данных. Не «невозможно», а «не сейчас и не первым».
Решение четвёртое: сначала данные, потом модели
И вот мы подходим к тому, обо что спотыкается больше всего проектов, — к данным. Здесь показателен один момент аудита. Мы спросили у холдинга, сколько одно из предприятий заработало за вчера, и получили три разные цифры из трёх разных систем. Никто не врал. Просто у каждой системы была своя версия правды.
Холдинг вырос из девяти разных бизнесов — от вывоза отходов до производства и гостиницы. У каждого свой ритм, свои метрики, свои учётные системы. На одном только предприятии мы насчитали пять источников данных: отдельная 1С для финансов, ещё одна для кадров, своя система для производства, ещё одна для транспорта, плюс мобильное приложение, данные которого живут сами по себе. Никто не проектировал этот ландшафт целиком — он нарос слоями, каждый под свою задачу в своё время.
Скажу прямо, потому что собственники часто винят себя: это не бардак и не следствие плохого управления. Это норма для любой большой компании. Разнородность данных — побочный эффект роста: бизнес открывал направления, покупал компании, внедрял системы по мере надобности, и каждое решение в свой момент было правильным. Лоскутный ландшафт не означает, что где-то управляли плохо. Он означает, что компания достаточно выросла, чтобы перестать помещаться в одну систему.
Проблема в том, что для управляющей компании всё это должно сложиться в одну картину, а оно не складывается: один и тот же по смыслу показатель в разных системах считается по-разному, в разных разрезах, на разную дату. Дальше возникает соблазн, на котором горят проекты: взять современный BI-инструмент, подключить все системы, показать руководству красивые дашборды. На практике BI не примиряет разные версии правды — он показывает их рядом, ещё нагляднее демонстрируя, что цифры не сходятся.
Автоматизация не создаёт порядок в данных. Она показывает, сколько в них беспорядка. Прежде чем строить витрину, кто-то должен договориться о правилах: что считать выручкой, на какую дату, в каком разрезе, из какой системы брать первоисточник. Это не техническая задача, а управленческая работа по наведению порядка в смыслах, и сделать её одним махом сверху невозможно — слишком много частных договорённостей. Работающий путь обратный: идти по кусочкам, от процесса к процессу, на каждом навести порядок в данных локально, накопить чистую историю, и только потом сшивать в общую картину.
Поэтому автоматизировать имеет смысл не тот процесс, который громче болит, а тот, под который данные уже готовы. Модель, обученная на противоречивых данных, выдаёт мусор — и винить будут, конечно, модель.
Что объединяет эти четыре решения
Ни одно из них не касается технологий. Посчитать цену бездействия, выстроить очередь по двум осям, честно отказаться от неготового, навести порядок в данных — всё это происходит до того, как выбрана модель и написана первая строчка кода. И ровно здесь, а не в выборе между GigaChat и self-hosted, решается судьба проекта.
Технология предсказуема. Непредсказуемы люди, данные, приоритеты и терпение руководства в первые месяцы. Проект, в котором эти четыре решения приняты осознанно, переживает даже слабую технологию. Проект, где их проскочили ради быстрого старта, не спасёт самая лучшая модель.
Если свести к одной мысли: автоматизация — это на девяносто процентов подготовка и на десять процентов внедрение. Заманчиво начать с внедрения, потому что оно выглядит как настоящая работа. Но настоящая работа — раньше.
