Отель, ферма и полигон ТКО автоматизируются одинаково?

«Мы под эти параметры не подходим — в связи с особенностью своих предприятий».

Так главбух холдинга объясняет, почему типовые правила в 1С не ложатся на их учёт.
Та же уверенность у гостиницы, у фермы, у мусорного оператора из того же холдинга: свой бизнес не похож на соседний, готовое решение не подойдёт. Когда мы разложили работу всех этих предприятий на автоматизацию, уникальности в ней оказалось процентов десять. Остальное — пять повторяющихся паттернов, одинаковых что для коровника, что для полигона ТКО.

Это выводы с аудита того самого холдинга ^[1]: девять предприятий из совсем разных миров — переработка отходов, молочная ферма, гостиница, юрслужба, общая бухгалтерия. Изучили сорок семь процессов, в программу автоматизации отобрали двенадцать.

Пять паттернов на девять бизнесов

Двенадцать отобранных процессов — управленческая отчётность, протоколирование совещаний, контроль поручений, NPS/eNPS, непрерывный финаудит, согласование договоров, судебные документы, ввод персональных данных, контроль закупок, управление БДДС, работа с корпоративной базой документов и виртуальный консьерж — свелись к пяти паттернам. Внутри каждого оказались процессы из совершенно разных бизнесов, которые технически решаются по одной и той же логике ^[2].

Первый — извлечение структуры из документа. В бухгалтерии это согласование договоров: на входе текст договора, на выходе стороны, суммы, сроки, рискованные пункты. В мусорном дивизионе — судебные обращения и ввод данных из паспортов, где на входе скан. Вход разный: цифровой договор читает LLM, скан сначала проходит через OCR, но дальше задача одна — не просто «прочитать» документ, а превратить его в конкретные данные, с которыми может работать система. Если такой механизм уже настроен для договоров, для паспортов или судебных документов не нужно строить всё заново: меняется то, какие именно данные надо найти и как их проверить, а основная схема работы остаётся той же.

Второй — сведение данных из разных источников в одну картину. Это процессы, где нужная цифра или показатель не лежит в одном месте: часть данных находится в учётной системе, часть в таблицах, часть приходит от других подразделений. Управленческая отчётность сводит данные девяти предприятий; БДДС на ферме — платежи, остатки и плановые движения денег. Задача общая: собрать данные из нескольких источников, привести их к единому виду и при этом сохранить возможность понять, откуда взялась каждая цифра.

Третий — поиск отклонений от нормы. Мы называем такой механизм детектором аномалий: система просматривает большой поток операций и поднимает наверх только то, что выбивается из заданных правил или привычного диапазона. Для непрерывного аудита это может быть нетипичная проводка, для контроля закупок — цена выше обычной, лишняя закупка при наличии товара на складе или превышение тендерного порога. Предмет разный, принцип один: сначала описать норму, затем автоматически искать всё, что на неё не похоже.

Четвёртый — превращение речи в конкретные действия и данные. Сама расшифровка разговора мало что даёт: ценность появляется, когда из неё автоматически вытаскиваются нужные сущности. В протоколе совещания это решения, поручения, исполнители и сроки; в звонке гостя в отель — тема обращения, запрос, тональность и то, кому его передать. Источник один — речь, а на выходе получается структура, с которой уже может работать человек или система.

Пятый — классификация и обработка входящих запросов. Иными словами — понять, что пришло, и решить, что делать дальше. Сюда попадают маршрутизация поручений, разбор NPS-опросов, гостевой консьерж в отеле и работа с корпоративной базой документов. Система сначала определяет, к какому типу относится запрос, а потом либо направляет его нужному человеку, либо сама отвечает по доступным документам. Консьерж и внутренний диспетчер поручений выглядят как совершенно разные продукты, но внутри делают одну и ту же работу: распознают намерение и выбирают следующий шаг.

Что это меняет на практике

Если смотреть не на холдинг как на набор отдельных компаний и функций, а на саму работу как на набор повторяющихся типов задач, меняется способ планировать автоматизацию. Обычная логика — отдельно идти в бухгалтерию, отдельно в снабжение, отдельно в отель и каждый раз начинать с вопроса «что уникального именно здесь?». Мы разворачиваем подход: сначала определяем, к какому паттерну относится задача, подбираем под него архитектуру и инструменты, а уже потом адаптируем решение под данные, правила и интеграции конкретного подразделения.. Так мы отделяем общую техническую механику от специфики конкретного отдела.

Отсюда меняется и экономика. Первый процесс внутри паттерна самый дорогой: на нём приходится собрать и отладить основную механику — распознавание, извлечение данных, проверки, маршрутизацию, интеграции. Когда появляется следующий процесс того же типа, значительная часть этой работы уже сделана. После контура для договоров судебные документы или паспорта — не новый проект с нуля, а адаптация готовой схемы под другие данные и правила. Поэтому второй и последующие сценарии одного паттерна обходятся кратно дешевле первого. Если считать каждый из них отдельным проектом «под свою специфику», заказчик несколько раз оплачивает одну и ту же базовую работу.

Паттерн нужен первым не потому, что он важнее отраслевой экспертизы, а потому, что помогает отделить общую механику от действительно уникальных правил. Сначала понимаем, что можно переиспользовать, а потом вместе с экспертами конкретного бизнеса настраиваем то, что переносить нельзя.

Где отрасль всё-таки решает

Теперь честно про обратную сторону, иначе выйдет плоское «ИИ универсален». Из того, что процессы повторяются, совсем не следует, что отраслевую экспертизу можно убрать из проекта. Наоборот: именно она определяет, что в конкретном бизнесе считать нормой, какие исключения допустимы, какие данные обязательны, где находится риск и в какой момент система должна остановиться и передать решение человеку. Паттерн отвечает на вопрос «как технически решать такую задачу», а отраслевой эксперт — «что именно в этом бизнесе считать правильным результатом».

Архитектура поиска аномалий может быть общей, но норма для бухгалтерской проводки и норма для закупки запчастей — совершенно разные вещи. В первом случае эксперт задаёт допустимые корреспонденции, суммы, периоды и исключения, во втором — ценовые диапазоны, остатки, поставщиков, тендерные правила. С документами то же самое: механизм извлечения данных общий, но из договора нужны стороны, сумма, сроки и ответственность, а из паспорта — ФИО, дата рождения, серия и номер. Справочники у полигона и у фермы тоже свои, и приводить их в порядок приходится под каждый бизнес отдельно. Добавьте регуляторику — у перевозки отходов свои требования, у персональных данных 152-ФЗ, у юрфункции свои сроки и формы, — и становится видно, где именно заканчивается универсальность.

Про это была прошлая статья: технический каркас решения можно переносить между отраслями почти без изменений, а данные, справочники, правила проверки и ограничения приходится собирать под конкретный бизнес заново. Так что «у нас своя специфика» — чистая правда. Просто эта специфика чаще находится не в самой архитектуре решения, а в том, что система должна знать о конкретной отрасли и по каким правилам она должна работать.

Что из этого следует

Отсюда для нас практический вывод. Заходя в незнакомый бизнес, мы сначала не делим задачи на «гостиничные», «бухгалтерские» или «фермерские». Сначала раскладываем их по типу работы: документы, консолидация данных, поиск аномалий, речь, классификация и ответы. Это сразу показывает, какую техническую основу можно собрать один раз и использовать снова, а где придётся отдельно разбираться в правилах конкретной отрасли. Так сразу видно границу между тем, что можно переносить из проекта в проект, и тем, что каждый раз приходится настраивать заново. Поэтому тип процесса помогает не переплачивать за одинаковую разработку, а отраслевая экспертиза не даёт применить универсальную схему там, где она начнёт ошибаться. В этом и есть рабочий баланс: не строить решение с нуля для каждого отдела, но и не делать вид, что все отделы одинаковые.