подход
Зачем нужна автоматизация бизнеса и где в ней действительно нужен ИИ
Автоматизация бизнеса нужна не ради абстрактной экономии времени, а чтобы поймать решение до отгрузки. Разбираем, где в ней нужна модель, а где хватает обычного правила.
Директор возвращается с отраслевой конференции, где полдня показывали ИИ, и записывает в блокноте одно слово: автоматизировать. Через неделю на планёрке выясняется, что бизнесу нужна не автоматизация вообще, а две конкретные вещи: чтобы товар перестал уходить в списание молча и чтобы никто не продавал ниже минимальной цены. Ни в одной из них модель не участвует – обе задачи решаются правилом, которое умещается в одну строку.
Это не разочарование, а нормальный порядок вещей. Автоматизация нужна не для того, чтобы абстрактно «работать быстрее», а чтобы перехватить момент, когда решение ещё можно изменить: до отгрузки, до рейса, до списания. ИИ – один из инструментов внутри такого решения, и далеко не самый частый.
Зачем нужна автоматизация бизнеса, если процесс и так работает
Ручной процесс редко ломается заметно. Он работает – и одновременно тихо протекает. Данные о сроке годности лежат в базе, правило про минимальную цену записано в регламенте, сотрудники его знают и в большинстве случаев соблюдают. Дело не в знании, а в том, когда оно доходит до человека, который ещё может что-то изменить.
Отчёт за месяц, акт списания, сверка в конце квартала смотрят назад. К моменту, когда они показывают потерю, товар отгружен, партия просрочена, рейс уехал пустым. Разговор по их итогам – это воспитание, а не управление.
Автоматизация не добавляет компании новых знаний. Она переносит проверку в ту секунду, когда решение ещё не принято окончательно. В этом её смысл, всё остальное – детали реализации.
Что автоматизация не чинит
Она не превращает неописанный процесс в описанный. «Мы обычно не отгружаем таким клиентам без предоплаты» – это ещё не правило: непонятно, каким именно клиентам, кто решает и что считается исключением. Повторять тут нечего, а автоматизация умеет ровно одно – надёжно повторять.
Поэтому работа начинается не с выбора технологии, а со скучного разговора, в котором правило проговаривают вслух и записывают. Иногда на этом всё и заканчивается: выясняется, что два отдела понимали его по-разному, и достаточно договориться. Чаще правило формулируется за полчаса, и дальше вопрос только в том, кто его проверяет – человек по памяти или система в момент сделки.
Где в автоматизации нужна модель, а где она лишняя
Граница проходит по типу входа, то есть по тому, в каком виде задача приходит в компанию.
Если на входе структурированные данные – цена в поле заказа, дата в карточке партии, остаток на складе, срок действия полиса, – модель избыточна. Такие задачи закрываются правилами и связями между системами: сравнить, посчитать, сопоставить с порогом, сообщить тому, кто отвечает. Это арифметика, а не понимание.
Если на входе неструктурированный текст или документ – письмо в свободной форме, фото чертежа, расшифровка разговора, – без модели не обойтись. Человек читает такое письмо и понимает, что клиент просит; программа по правилам этого не умеет, потому что у свободного текста нет полей, из которых можно что-то взять.
Проверка, которую легко сделать самому: попробуйте записать задачу одной фразой «если X, то Y». «Если остаток срока годности меньше трети – позицию в список на акцию». «Если цена ниже минимальной наценки – заказ не проводить без подтверждения руководителя». Получилось – значит, ИИ здесь не нужен, и настаивать на нём означает платить за сложность, которая ничего не добавит к результату.
Почему правило дешевле в содержании
Описанное однажды правило работает годами и не требует внимания. Оно либо сработало, либо нет, это видно сразу, и его поведение не меняется само по себе.
С моделью иначе. Её ответы приходится проверять на качество – не потому, что она плохая, а потому, что у задач, которые ей отдают, обычно нет единственного правильного ответа. Плюс каждое обращение к ней чего-то стоит. Это не довод против модели, это довод за то, чтобы ставить её только туда, где иначе не выходит вовсе. Там она окупается наглядно.
Как это выглядит на живом наборе задач
Торговая компания, продукты питания: опт и несколько розничных точек, вся торговля в 1С. Набор решений вышел такой – контроль сроков годности, сторож минимальной наценки, сборка договоров и счетов из данных 1С, утренняя сводка по дебиторке и выгрузка прайса на Авито.
Модель не участвует ни в одном. Сравнить дату с сегодняшней, цену – с порогом, подставить данные в утверждённый шаблон, собрать список тех, кому пора напомнить об оплате: правила и интеграции. Что из этого получилось у клиента, показано в разборе кейса по оптовой торговле, а механика одного из решений – в статье про контроль минимальной наценки.
Встречный пример – производитель металлоконструкций под заказ. Заявка приходит письмом: свободный текст, иногда эскиз, иногда фото чертежа со стройки. Инженер тратил на разбор такого письма полдня, а предложение уходило клиенту через два-три дня, когда часть заказчиков уже успевала уйти к тем, кто ответил раньше. Здесь разбор входящего действительно опирается на модель: иначе письмо с вложениями в карточку расчёта не превратить. Что это изменило, разобрано в статье про коммерческое предложение в день обращения.
Разница между этими двумя примерами не в отрасли, не в размере компании и не в бюджете. Она в том, что приходит на вход.
С чего это начинают
С карты. Мы проходим по процессам и отмечаем места, где решение принимается вслепую или проверяется с опозданием. Карта отвечает не на вопрос «что можно автоматизировать» – при желании почти всё, – а на вопрос, что стоит трогать первым. Обычно это два-три места, и модель нужна в лучшем случае в одном из них.
Карту мы делаем бесплатно, первое решение по ней – за свой счёт. Дальше вы платите за результат, который видите у себя, а не за наши трудозатраты.
Запись в блокноте после конференции звучит как «внедрить ИИ». После карты она звучит иначе: «в момент оформления заказа проверять цену и не пускать её ниже порога без согласования». Второе короче, дешевле и заметно полезнее.