ERP без кнопок. MCP — начало конца привычного интерфейса?
Сразу уточню: речь пойдёт не об использовании MCP для разработки конфигураций, а о работе AI непосредственно с данными и бизнес-операциями действующей учётной системы.
Еще уточнение: в статье я пишу для простоты "ERP", подразумевая контур функциональных модулей для управления предприятием, а не 1С:ERP и даже не конкретно платформу 1С. Это чисто умозрительная статья, где я методически пытаюсь нащупать ниши применения и горизонты возможностей инструмента с небольшим практическим примером в конце.
Недавно я подключил ChatGPT через MCP к собственной конфигурации для торговли и склада на своей платформе. Он анализировал остатки и потребности, создавал и проводил заказы, строил фин. прогнозы. Причём непосредственно из чата, без открытия форм учётной системы.
И тут возник вопрос: а зачем вообще пользователю интерфейс ERP, если он может просто сказать системе, что ему нужно? И "чтобы не платить лишний раз за токены, а пользоваться запрограммированным алгоритмом/отчетом" не тот ответ, тут все гораздо тоньше. Да и к тому же "запрограммирует" его тот же ИИ, это уже новость вчерашнего дня.
Попробуем разобраться, какие рабочие места в 1С действительно можно заменить чатом с искусственным интеллектом, какие — лишь частично, а какие переживут эту революцию почти без изменений. С примерами реальных экспериментов, классификацией пользователей и прогнозом, который наверняка понравится не всем.
Но прежде чем разбирать конкретные рабочие места, предлагаю посмотреть на возможности AI немного шире. Потому что простая замена кнопок на текстовые команды, на мой взгляд, далеко не самое интересное, что нас ожидает.
Самая дорогая ошибка ERP — правильно проведённый документ
Представим предприятие. Внедрена 1С, настроены закупки, производство, бюджетирование, казначейство, расчёт себестоимости, ценообразование. Всё работает.
Товары приходуются, заказы обеспечиваются, производство планируется, себестоимость рассчитывается, прибыль определяется.
А теперь вопрос: откуда предприятие знает, что зарабатывает столько, сколько могло бы?
Допустим, отдел закупок заказал товар на 20 миллионов рублей. Потребность рассчитана правильно, остатки учтены, заказ поставщику согласован.
Через три месяца товар продан. Прибыль получена. Все счастливы.
Но что, если при другой комбинации закупок предприятие могло бы заработать на пять миллионов больше?
Что, если часть оборотных средств следовало направить не на товар А, который прекрасно продаётся, а на товар Б, который продаётся медленнее, но обеспечивает гораздо большую маржинальную прибыль?
А может быть, наоборот, на товар с меньшей наценкой, но значительно более высокой оборачиваемостью?
Или стоило уменьшить закупки, погасить кредит, пересмотреть цены на несколько товаров и направить высвободившиеся средства на расширение производственных мощностей?
ERP прекрасно зафиксирует любое из этих решений. Рассчитает его последствия. Отразит хозяйственные операции.
Но кто выберет лучшее решение из тысяч возможных комбинаций?
Конечно, существуют специализированные оптимизационные системы, математические модели, алгоритмы планирования. Да и сама 1С содержит немало развитых механизмов планирования.
Но для решения межфункциональных задач обычно требуется отдельная модель, подготовка исходных данных, настройка ограничений, интеграция разных подсистем и работа специалистов.
А если попробовать поставить задачу обычным человеческим языком?
У нас есть 50 миллионов свободных оборотных средств. Предложи оптимальное распределение между закупками, производством и погашением кредитов на ближайший квартал. Цель — максимальная ожидаемая прибыль при сохранении платёжеспособности и выполнении обязательств перед ключевыми клиентами. Рассмотри несколько сценариев, включая пессимистичный.
Вот это уже интереснее, чем «Создай заказ поставщику».
Именно в таком контексте я предлагаю обсуждать перспективы ChatGPT + MCP.
Не как замену одной формы ввода другой, а как возможность перейти от учёта решений к систематическому поиску лучших решений.
Да, это оптимизационная задача и статья получилась с некоторым перекосом в эту сторону, понятно что не все из этого прям каждый день применяешь.
Почему раньше для этого нужен был целый отдел аналитиков
Поиск оптимальных решений — идея далеко не новая. Существуют методы линейного и целочисленного программирования, прогнозирования, имитационного моделирования, управления запасами, теория ограничений (ТОС), производственное планирование и так далее. ERP тоже далеко не ограничиваются регистрацией документов.
Проблема в другом.
Для решения сложной задачи необходимо сначала превратить бизнес-вопрос в математическую постановку, определить целевую функцию, собрать данные, установить ограничения, подобрать алгоритм, проверить результаты и представить их в форме, пригодной для принятия решения.
Причём реальные задачи почти никогда не укладываются в одну подсистему.
Например, оптимальный план закупок зависит от прогноза спроса с учётом сезонности, трендов и возможных всплесков, текущих остатков, оборачиваемости, резервов, цен поставщиков, скидок за объём, минимальных партий, отсрочек платежа, стоимости и сроков доставки, ожидаемых продажных цен, стоимости финансирования и рисков. И это далеко не полный перечень!
Часть информации находится в ERP. Часть — у поставщиков. Часть — в банке, CRM, файлах Excel, внешних аналитических сервисах, интернете.
Традиционный путь — построить интеграции, разработать специализированную модель и интерфейс, обучить пользователей.
AI с доступом к инструментам потенциально способен взять на себя существенную часть этой подготовительной работы: разобраться в задаче, определить необходимые данные, организовать их получение, предложить модель расчёта, запустить соответствующие алгоритмы и интерпретировать результаты.
Обратите внимание: я не утверждаю, что языковая модель должна самостоятельно перебирать миллионы комбинаций в своём контекстном окне.
Для этого существуют нормальные математические решатели. Но AI может выступать посредником между человеческой постановкой задачи, корпоративными данными и специализированными расчётными инструментами.
И это принципиально новая экономическая роль интерфейса.
Есть ещё одно важное обстоятельство. Условия бизнеса постоянно меняются. Сегодня требуется оптимизировать закупки при ограниченных деньгах. Завтра поставщик изменил сроки доставки. Послезавтра появился новый канал продаж. Затем изменился валютный курс, подорожала логистика, а конкурент начал демпинговать.
Создавать отдельную обработку под каждую комбинацию условий практически невозможно.
Возможность быстро сформулировать новую задачу, собрать для неё данные и построить расчётную модель без длительного цикла разработки — пожалуй, одно из наиболее интересных преимуществ AI.
MCP: от одной ERP к целому цифровому предприятию
Собственно, при чём здесь MCP?
Model Context Protocol позволяет AI-клиенту получать доступ к данным и функциям внешних систем через стандартизированный механизм инструментов.
В нашем случае ChatGPT может быть подключён к корпоративной системе и выполнять доступные ему операции.
Если говорить совсем просто, раньше ChatGPT мог рассказать пользователю, как сформировать заказ поставщику в 1С. Теперь, при наличии соответствующего подключения и прав, он способен сформировать этот заказ самостоятельно.
При этом модель не обязана знать внутреннее устройство конкретной конфигурации. MCP-сервер предоставляет ей набор доступных инструментов: получить данные, выполнить поиск, вызвать бизнес-операцию, создать документ, получить отчёт.
Но самое интересное начинается, когда источников информации становится несколько.
Представим следующую конфигурацию:
| Источник | Что может получить AI |
|---|---|
| 1С | Остатки, себестоимость, заказы, производство, бюджеты |
| 1С:ЗУП | ФОТ, графики работы, доступность персонала |
| CRM | История клиентов, сделки, прогноз продаж |
| Банк | Остатки денег, платежи, кредитные обязательства |
| Поставщики | Прайс-листы, условия оплаты, наличие, сроки |
| Логистические сервисы | Стоимость и сроки перевозок |
| Маркетплейсы и сайты | Конкурентные цены, ассортимент, доступные рыночные сигналы |
| Внешняя аналитика | Сезонность, рыночные тренды, факторы спроса |
| Оптимизационный сервис | Расчёт вариантов при заданных ограничениях |
Не обязательно, чтобы все эти системы имели собственный MCP-сервер. Часть данных можно получать через обычные API, веб-инструменты или специализированные сервисы, доступные AI. Главное — чтобы необходимая информация была действительно доступна и её использование было разрешено.
При этом MCP сам по себе не создаёт интеграции, которых не существует, и не обеспечивает достоверность данных.
Но он создаёт удобный механизм для объединения доступных инструментов в рамках одной задачи.
И здесь возникает интересная ситуация.
В традиционной архитектуре для межсистемного сценария мы обычно проектируем специальную интеграцию или отдельную обработку.
AI может динамически выстраивать последовательность действий с уже доступными инструментами.
Сегодня пользователь исследует влияние сроков доставки на закупки. Завтра — влияние изменения курса валют на себестоимость. Послезавтра — последствия изменения графика производства для денежных потоков.
Не обязательно каждый раз разрабатывать отдельный пользовательский интерфейс.
Конечно, сложные устойчивые сценарии всё равно потребуют формализации, тестирования и настройки. Но стоимость проверки новой управленческой гипотезы потенциально может стать существенно ниже.
Вот где, на мой взгляд, скрывается наиболее интересный эффект.
Рабочие места ERP: кого отправляем в чат, а кому оставляем привычный интерфейс?
Теперь перейдём к главной теме исследования.
Было бы довольно наивно заявить, что завтра бухгалтеры, кладовщики и менеджеры закроют 1С и перейдут в ChatGPT. У разных пользователей совершенно разные способы взаимодействия с системой.
Причём здесь необходимо разделять два вопроса.
Первый — можно ли заменить привычный интерфейс диалогом (даже у учетом того ЧТО сейчас может вам LLM нарисовать в диалоге: таблицы, графики, формы и т.д.)? Насколько удобнее будет человеку работать, если вместо форм, обработок и отчётов он сможет просто поставить задачу?
Второй — что нового AI может дать этому рабочему месту? Может ли он не только выполнить те же действия, но и помочь принимать более выгодные решения, автоматизировать ранее недоступные сценарии или объединять данные нескольких подсистем?
Эти показатели далеко не всегда совпадают.
Попробуем пройти по основным рабочим местам — от аналитических до сугубо операционных.
Здесь необходимо разделять два вопроса:
- Можно ли заменить привычный интерфейс диалогом? Насколько удобнее будет человеку работать, если вместо форм, обработок и отчётов он сможет просто поставить задачу?
- Что нового AI может дать этому рабочему месту? Может ли он не только выполнить те же действия, но и помочь принимать более выгодные решения, автоматизировать ранее недоступные сценарии или объединять данные нескольких подсистем?
Эти показатели далеко не всегда совпадают. Далее попробуем пройти по основным рабочим местам-от аналитических до сугубо операционных.
Закупщик: покупать не то, что заканчивается, а то, что принесёт деньги
Закупки — практически идеальная область для диалогового взаимодействия. Почему? Потому что закупщик обычно не выполняет сотни однообразных операций в минуту. Он принимает решения.
- Что необходимо заказать?
- Почему именно столько?
- Когда ожидается дефицит?
- Какому поставщику отдать предпочтение?
- Что изменится, если увеличить страховой запас?
Такие вопросы гораздо естественнее формулировать человеческим языком, чем выражать через последовательность отчётов, отборов и обработок.
Представим запрос:
| Проанализируй ассортимент и предложи план закупок на следующие 60 дней. Цель — максимизировать ожидаемую прибыль с учётом ограниченного бюджета, сезонного спроса, оборачиваемости, маржинальности, сроков поставок и стоимости финансирования. Не стремись обеспечить 100% наличие всего ассортимента. Покажи, где выгоднее допустить дефицит. |
Последняя фраза особенно важна. Обычная логика закупщика часто направлена на предотвращение дефицита. Но устранение любого дефицита любой ценой не обязательно выгодно.
Предприятие может держать товар на складе полгода ради продажи нескольких единиц и при этом испытывать нехватку оборотных средств для более прибыльных операций.
Самый дешёвый поставщик не всегда самый выгодный
Поставщик А предлагает товар за 820 рублей, но требует предоплату. Доставка занимает 34 дня и стоит ещё 80 рублей на единицу.
Поставщик Б предлагает тот же товар за 900 рублей, доставка стоит 30 рублей и занимает четыре дня, а оплатить товар можно через 30 дней.
Казалось бы, А дешевле.
Но если сезон продаж заканчивается через три недели, дешёвая партия может приехать слишком поздно.
Пока первый поставщик везёт товар, его ожидаемая продажная цена может упасть с 1 200 до 980 рублей.
Тогда расчётная разница между продажной ценой и закупкой с доставкой составит всего 80 рублей.
У второго поставщика — 270 рублей при продажной цене 1 200.
А дополнительно мы имеем преимущество в условиях оплаты: товар может быть реализован ещё до наступления срока платежа поставщику.
Разумеется, реальные цены и объёмы нужно прогнозировать, а не объявлять известными заранее.
Но принцип понятен: разница в 80 рублей закупочной цены сама по себе практически ничего не говорит о выгодности сделки.
AI мог бы получить коммерческие предложения нескольких поставщиков, проверить доступность товаров, рассчитать логистику, сопоставить условия оплаты и оценить прогноз спроса к моменту фактического поступления.
А затем предложить не просто самого дешёвого поставщика, а наиболее выгодную комбинацию поставок.
Например, небольшую срочную партию у местного поставщика и основную — у более дешёвого зарубежного. Или, наоборот, вообще отказаться от второй партии, если к моменту её поступления сезонный спрос уже закончится.
Сезонность, всплески и статистические аномалии
Представим, что мы планируем закупки товаров с выраженным сезонным спросом.
У нас есть история продаж за три года.
В прошлом году в какой-то момент продажи выросли втрое.
Почему?
Возможно, проводилась рекламная акция. Возможно, конкурент временно прекратил поставки. Возможно, произошёл реальный рыночный всплеск спроса. А может быть, в данных просто оказалась ошибка.
Если механически включить этот всплеск в сезонный прогноз, получим завышенные закупки. Если механически исключить его как выброс, можем пропустить реальную закономерность.
Нужен анализ причин.
| Проанализируй продажи за три года. Отдели сезонность от тренда, рекламных акций, разовых аномалий и изменений доступности товаров. Найди периоды необычного спроса и проверь возможные внешние причины. Построй несколько сценариев прогноза, а не одну усреднённую цифру. |
Для такой работы AI может использовать исторические данные ERP, информацию о рекламных кампаниях, динамику цен, календарь праздников и доступные внешние индикаторы.
При этом сам статистический прогноз желательно рассчитывать специализированными моделями, а не поручать языковой модели угадывать цифры.
Дальше интереснее.
Предположим, внезапно появился новый фактор: изменение погоды, прекращение поставок у конкурента или скачок спроса на определённую категорию товаров.
Промпт:
| Внешние данные указывают на возможный двукратный рост спроса в течение ближайших двух недель. Пересчитай план закупок. Проверь, какие товары действительно стоит заказать дополнительно, а какие уже не успеют поступить к пику спроса. Учти возможность ускоренной доставки, частичной замены ассортимента и повышения продажных цен. Ограничение — не допустить кассового разрыва. |
Здесь прогноз спроса является лишь входными данными.
Результат — новый экономически обоснованный план действий.
Выбор товара под бюджет, у кого и по какой цене продавать? Комбинаторная задача.
Допустим, у нас 15 миллионов рублей, которые можно направить на пополнение ассортимента. Есть несколько тысяч товаров и десятки поставщиков. По каждому товару имеются предложения от нескольких поставщиков, разные условия доставки, минимальные партии, скидки за объём, отсрочки платежа.
История продаж позволяет оценить спрос в зависимости от цены, сезонности и доступности товара.
Нас интересует не максимальная закупка, не максимальная выручка и даже не максимальная процентная наценка.
Нужно найти такую комбинацию закупок, поставщиков, объёмов и продажных цен, которая принесёт максимальную прибыль за следующие 90 дней с учётом ограничений по деньгам.
Это означает, что необходимо одновременно решить несколько взаимосвязанных задач: выбрать товары, поставщиков, размеры партий, график закупок, определить оптимальные продажные цены и убедиться, что во все моменты времени предприятие сможет оплачивать свои обязательства.
Заметим, что это уже задача не только закупщика. Она одновременно относится к ценообразованию, финансовому планированию, маркетингу и казначейству.
Почему товар с наибольшей маржой может оказаться худшей покупкой? Для наглядности возьмём два условных товара.
| Показатель | Товар А | Товар Б |
|---|---|---|
| Закупочная цена | 900 | 700 |
| Продажная цена | 1 300 | 1 000 |
| Дополнительные переменные затраты | 100 | 90 |
| Маржинальный доход с единицы | 300 | 210 |
| Полный цикл оборота денег | 80 дней | 20 дней |
На первый взгляд товар А выгоднее. Он приносит 300 рублей против 210.
Но товар Б возвращает вложенные деньги в четыре раза быстрее.
За 80 дней при условии устойчивого спроса, доступности товара и возможности повторных закупок деньги, вложенные в товар Б, теоретически можно использовать четыре раза.
Получается совершенно другая экономика.
На каждый первоначально вложенный рубль товар А принесёт примерно 33 копейки маржинального дохода за 80 дней, а товар Б — по 30 копеек за каждый из четырёх оборотов.
Это упрощённая иллюстрация, без учёта реинвестирования прибыли, ограничений спроса, изменения цен и других факторов.
Но она демонстрирует важный момент: маржинальный доход с единицы товара ничего не говорит о том, насколько эффективно используется ограниченный оборотный капитал.
Конечно, нельзя просто выбрать все товары с максимальной прибылью на рубль за день.
У каждого товара ограниченный спрос, закупочные партии могут быть неделимыми, поставщики предоставляют ступенчатые скидки, товары конкурируют друг с другом, а денежные поступления распределены во времени.
Поэтому показатель отдачи на вложенный капитал полезен для предварительного сравнения, но настоящая целевая функция должна максимизировать суммарный ожидаемый экономический результат за заданный период с учётом всех ограничений.
И вот мы уже получаем вполне серьёзную задачу оптимизации.
Быстрая перестройка при изменении внешних условий
Предположим, закупочный план уже согласован, заказы размещены.
Внезапно транспортная компания сообщает, что срок доставки по одному направлению увеличился с 20 до 45 дней. Одновременно выросла стоимость перевозок.
В традиционной системе это может запустить цепочку совещаний между логистикой, закупками, продажами и финансами.
А здесь можно сформулировать задачу:
| По группе поставщиков срок доставки увеличился на 25 дней, стоимость перевозки выросла на 18%. Пересчитай оптимальный план. Найди критичные товарные позиции, оцени альтернативные маршруты и поставщиков. Определи, какие закупки следует отменить, какие ускорить, а какие заменить. Учти изменение ожидаемой прибыли и потребности в финансировании. |
Именно быстрая перестраиваемость плана под новые условия кажется мне одним из наиболее перспективных направлений.
Разумеется, альтернативные предложения должны быть актуальны, расчёт — проверяем, а изменение уже размещённых заказов — согласовано.
А что с интерфейсом закупщика?
Вернёмся к первоначальной теме.
В традиционной ERP закупщик открывает рабочее место обеспечения потребностей, отчёты по запасам и продажам, заказы поставщикам, цены и условия закупок. Анализирует, корректирует, согласовывает, создаёт документы.
А в чате его работа могла бы выглядеть так:
| Проверь обеспеченность на следующий месяц и предложи план закупок с максимальной ожидаемой прибылью при бюджете 15 миллионов. |
| Почему ты выбрал этих поставщиков? |
| А если учитывать только поставщиков с отсрочкой оплаты? |
| Хорошо. По этим трём позициям увеличь страховой запас. Остальное оставь как предложено.Создай заказы поставщикам и отправь на согласование. |
И всё.
Конечно, для просмотра больших таблиц, массовой корректировки строк и визуального сравнения предложений могут потребоваться привычные элементы интерфейса.
Но сам процесс планирования, принятия решений и запуска операций потенциально можно перенести в чат практически целиком.
Ценообразование: почему «средняя цена по рынку» — плохая цель
На мой взгляд, здесь вообще открывается огромное поле для экспериментов.
Предприятия часто используют достаточно простые правила ценообразования: себестоимость плюс наценка, ориентация на конкурентов, целевая маржинальность, правила округления, акции.
Но максимальная наценка не означает максимальную прибыль.
Допустим, товар продаётся за 1 000 рублей и приносит 300 рублей маржинального дохода на единицу. Если снизить цену до 950 рублей, объём продаж может увеличиться на 40%.
Выгодно ли это?
Возможно. А возможно, нет.
Всё зависит от эластичности спроса, дополнительных расходов, наличия товара, реакции конкурентов, влияния на продажи других позиций и множества других факторов.
Давайте посмотрим на условный расчёт.
Полная переменная стоимость продажи товара, включая закупку и непосредственно связанные затраты, составляет 790 рублей.
История продаж позволяет предположить следующие варианты:
| Цена продажи | Ожидаемые продажи за месяц | Маржинальный доход с единицы | Общий маржинальный доход |
|---|---|---|---|
| 990 | 1000 шт. | 200 | 200000 |
| 1090 | 750 шт. | 300 | 225000 |
| 1190 | 530 шт. | 400 | 212000 |
По этим исходным предположениям лучшая из трёх цен — 1 090 рублей.
Но что будет, если деньги ограничены?
При цене 990 рублей мы продаём больше товаров и потенциально быстрее возвращаем капитал в оборот.
А при цене 1 090 рублей получаем больше маржинального дохода за месяц.
И это ещё без учёта стоимости хранения, финансирования и риска неликвидных остатков.
Теперь представим, что у компании тысячи таких товаров.
По каждому есть история продаж, несколько поставщиков, разные сроки доставки, эластичность спроса и ограничения по запасам.
И нам необходимо одновременно решить:
Что купить, у кого купить, в каком количестве, по какой цене продавать и как быстро вернуть деньги в оборот, чтобы максимизировать итоговую прибыль компании?
Это уже не обычный расчёт наценки, а оптимизация целого товарного портфеля при ограниченном оборотном капитале.
А если товары влияют друг на друга?
Ещё интереснее становится ассортиментная оптимизация.
Например, снижение цены одного товара увеличивает продажи сопутствующих товаров. Но одновременно может переключать спрос с более прибыльного аналога.
Один товар привлекает покупателей в магазин, хотя сам по себе приносит небольшую прибыль. Другой имеет высокую маржу, но продаётся преимущественно в комплекте с первым.
Третий занимает дефицитное место на складе и требует дорогостоящего хранения. Четвёртый хорошо продаётся только во время сезонных пиков. Пятый покупают почти исключительно постоянные клиенты, которые не особенно чувствительны к цене.
Система, оптимизирующая цену каждой позиции независимо, может принять неоптимальное решение для всего ассортимента.
Промпт:
| Найди оптимальный набор изменений цен для товарной группы. Цель — максимизировать ожидаемую маржинальную прибыль за квартал с учётом взаимного влияния товаров, доступных запасов, сроков пополнения и стоимости оборотного капитала. Для неопределённых оценок эластичности предложи небольшие контролируемые эксперименты. |
Здесь AI не должен придумывать коэффициенты эластичности. Он может организовать их оценку, выявить недостаток данных, предложить эксперимент, вызвать оптимизатор и объяснить результат.
Возможно, итоговая рекомендация будет выглядеть неожиданно.
Увеличить цену на один товар на 8%, несмотря на ожидаемое снижение продаж. Снизить цену другого на 5%, потому что он стимулирует продажи более прибыльных сопутствующих товаров. Отказаться от закупки третьего, поскольку с учётом оборачиваемости и складских затрат он фактически уничтожает доходность оборотного капитала.
Для четвёртого — перейти на более дорогого поставщика с коротким сроком доставки, чтобы не замораживать деньги в больших запасах.
Главное — оптимизируется не отдельная цена, а результат предприятия.
А теперь представим, что цены конкурентов изменились, поставщик внезапно объявил скидку или спрос неожиданно вырос.
AI может предложить пересчитать оптимальную стратегию на новых данных, не дожидаясь следующего планового пересмотра прайс-листа.
И где здесь привычный интерфейс?
Специалисту по ценообразованию необязательно вручную редактировать тысячи строк документа установки цен.
Он может обсуждать с AI ценовую стратегию, проверять расчёты, анализировать последствия изменений, уточнять ограничения и утверждать результат.
Разумеется, для визуальной проверки предложений ему может понадобиться таблица с текущими и новыми ценами, маржой и ожидаемым эффектом.
Но это уже скорее интерфейс контроля результата, а не основное рабочее место планирования цен.
И здесь особенно хорошо видна разница между простой заменой UI и появлением новых возможностей: AI не просто заполняет цены, а помогает выбрать, какими они должны быть.
Производство: не просто составить план, а выбрать, что выгоднее производить
Современная ERP может рассчитывать потребности в материалах, планировать выпуск, учитывать производственные мощности, этапы, маршруты и операции.
Но у предприятия зачастую существуют конкурирующие цели.
Необходимо выполнить заказы клиентов, обеспечить загрузку оборудования, минимизировать простои, не допустить дефицита материалов, сохранить денежные средства и получить максимальную прибыль.
Предположим, предприятие получило больше заказов, чем способно произвести.
Какой заказ выполнять первым?
Тот, у которого раньше срок отгрузки? Тот, который принесёт больше выручки? Тот, у которого выше маржа? Тот, который быстрее освободит производственные мощности?
А может быть, заказ стратегического клиента, несмотря на относительно низкую прибыльность?
Прибыль на единицу дефицитного ресурса
Представим простой пример.
Завод выпускает два изделия.
Изделие А приносит 500 рублей маржинального дохода на единицу, но требует двух часов работы дефицитного оборудования.
Изделие Б приносит 420 рублей, но занимает тот же станок всего на час.
Если смотреть только на прибыль с изделия, выгоднее А.
Но при ограничении по времени работы станка изделие Б приносит 420 рублей на час дефицитного ресурса против 250 рублей у изделия А.
Следовательно, при прочих равных и достаточном спросе производить Б экономически выгоднее.
Это классическая логика теории ограничений.
Никакой ChatGPT для такого расчёта не требуется.
Но теперь сделаем задачу похожей на реальную.
У нас не один станок, а несколько производственных участков с разной загрузкой. Изделия используют общие материалы. Переналадка оборудования занимает время и требует расходов. Заказы имеют разные сроки и штрафы за просрочку.
Существуют альтернативные технологические маршруты, возможность сверхурочной работы и передачи части операций подрядчикам.
Кроме того, у предприятия ограничены деньги на закупку материалов.
И вот теперь нужно найти наиболее выгодную комбинацию производственных заказов, последовательности выполнения, закупок, сменности и привлечения подрядчиков.
При этом оптимальный план должен учитывать не только маржу на единицу продукции, но и использование дефицитных ресурсов, сроки оплаты клиентов и потребность в оборотных средствах.
Промпт:
| У нас ограничены мощности участков мехобработки и покраски. Определи производственную программу на следующие шесть недель, максимизирующую ожидаемую маржинальную прибыль. Учти заказы покупателей, сроки, штрафы, переналадки, доступность материалов, ограничения по рабочим центрам и оборотным средствам. Предложи варианты с дополнительными сменами и передачей отдельных операций подрядчикам. |
Уже неплохо.
Но можно интереснее.
Что выгоднее — срочный заказ или крупная серия?
Предположим, поступил срочный заказ от крупного клиента.
Выручка привлекательная, маржа высокая.
Однако для его выполнения необходимо остановить текущую серию, переналадить оборудование, докупить часть материалов по повышенной цене и перенести несколько других заказов.
Возможно, в итоге этот срочный заказ принесёт убытки, несмотря на красивую плановую маржинальность.
А может быть, наоборот, его выполнение крайне выгодно, если перенести менее прибыльные операции на другой участок.
| Оцени экономическую целесообразность принятия срочного заказа. Рассчитай несколько вариантов включения его в производственную программу. Учти затраты на переналадку, дополнительные закупки, штрафы за перенос других заказов, загрузку оборудования и сроки получения денег. Покажи не только прибыль самого заказа, но и изменение общего финансового результата предприятия. |
Здесь требуется решить задачу, которую сложно свести к отдельному документу или отчёту. Мы оцениваем последствия управленческого решения для всей производственной программы.
А если поставщик сорвал доставку?
Допустим, план уже утверждён. И внезапно поставщик сообщает, что критичный материал поступит на две недели позже.
У предприятия несколько возможных вариантов: купить материал у альтернативного поставщика дороже, перестроить очередь производства, заменить материал допустимым аналогом, изменить технологический маршрут, передать часть работ подрядчику, перенести клиентские заказы или организовать дополнительные смены.
Причём возможна и комбинация нескольких вариантов.
| Поставка материала М задерживается на 14 дней. Найди производственный план с минимальными совокупными потерями. Рассмотри альтернативных поставщиков, замену материалов по утверждённым спецификациям, перераспределение мощностей, сверхурочные смены и субподряд. Учти штрафы, изменение себестоимости, стоимость финансирования и влияние на денежные потоки. |
Планировщик производства в этой ситуации вынужден взаимодействовать с закупками, финансами, снабжением, логистикой и коммерческой службой.
В традиционной ERP необходимые данные могут находиться в разных подсистемах. В диалоговой модели их можно объединить в рамках одной постановки.
Разумеется, изменение спецификации или маршрута должно проходить технологические проверки, а расчёт расписания — выполняться соответствующими алгоритмами.
Но потенциальный эффект уже измеряется не сэкономленными минутами работы планировщика, а стоимостью предотвращённого простоя, снижением потерь и дополнительной прибылью.
А если оптимизировать весь производственный цикл?
Предприятие выбирает, стоит ли увеличивать выпуск существующей продукции или переходить на новую.
Новые изделия обещают более высокую маржу, но требуют оснастки, обучения персонала, дополнительных запасов и изменения технологических процессов.
| Определи, при каких объёмах продаж переход на новую продуктовую линейку экономически оправдан. Учти инвестиции, освоение производства, кривую обучения, прогноз брака, загрузку оборудования, изменение потребности в персонале и оборотных средствах. Найди точку безубыточности и сравни альтернативные сроки запуска. |
Это задача инвестиционного и производственного планирования одновременно.
Особенно интересно, что параметры такой модели могут изменяться по мере получения новых данных — фактической скорости освоения, брака, спроса, стоимости материалов.
И тогда AI сможет регулярно предлагать пересмотр решений, а не просто показывать отклонения от первоначального плана.
Но заменит ли чат рабочее место производственника?
Здесь очень важно разделить пользователей.
Планировщик производства большую часть времени анализирует ограничения, принимает решения, пересчитывает планы и согласовывает изменения.
Он вполне может ставить задачи через чат, изучать предложения AI, корректировать ограничения и поручать системе перепланирование.
Однако диаграмма Ганта, визуальная загрузка рабочих центров или график производственного расписания по-прежнему могут быть удобнее текстового ответа.
А вот мастер смены или оператор производственной линии работает совершенно иначе.
Ему необходимо регистрировать выполнение операций, фиксировать выпуск продукции, сканировать материалы, отмечать брак и простои.
Всё это должно происходить быстро и предсказуемо. Заставлять оператора вести диалог с AI вместо нажатия кнопки «Операция выполнена» — довольно странная идея :)
Получается, что внутри одной производственной подсистемы AI способен радикально изменить рабочее место планировщика и почти не затронуть интерфейс оператора станка.
Казначейство: максимальная прибыль ничего не стоит, если завтра нечем платить
Допустим, мы нашли план, обеспечивающий максимальную ожидаемую прибыль за квартал.
Есть небольшая проблема: через две недели у предприятия заканчиваются деньги.
Получается, что найденный оптимум практически бесполезен.
Здесь появляется ещё одно измерение задачи — движение денежных средств.
| Построй прогноз денежных потоков на 90 дней с учётом текущих обязательств, планируемых закупок, производственной программы и ожидаемых поступлений покупателей. Найди сценарий, при котором максимизируется прибыль без нарушения обязательных платежей и минимального остатка денег на счетах. |
А теперь добавим возможность управлять некоторыми параметрами:
| Проверь, что выгоднее: воспользоваться банковским кредитом, договориться об отсрочке с поставщиком, предложить скидку клиентам за досрочную оплату или сократить закупки отдельных товарных групп. |
Здесь возникает настоящая комбинаторная задача. Её нельзя решить простым сортированием платежей по дате.
Нужно учитывать стоимость денег во времени, штрафы, потери маржи, надёжность поступлений, допустимые кредитные лимиты и стратегические ограничения.
Иногда выгоднее взять кредит, чем пользоваться бесплатной отсрочкой
Рассмотрим интересный пример. Поставщик предлагает условия: скидка 2% при оплате в течение 10 дней или полная оплата через 40 дней.
Если заплатить на 30 дней раньше, предприятие экономит 2% цены.
В пересчёте на стоимость финансирования отказ от скидки соответствует примерно 25% годовых по простой годовой ставке.
Если предприятие может привлечь деньги существенно дешевле, использование кредита ради досрочной оплаты потенциально может оказаться выгоднее отсрочки поставщика.
Но только если не возникнут другие ограничения по ликвидности и кредитным лимитам.
А теперь представим, что у нас сотни поставщиков с разными условиями оплаты и тысячи платежей.
У одного поставщика выгодная скидка за предоплату. У другого — длинная бесплатная отсрочка. Третий предоставляет дополнительные скидки за увеличение партии, но тем самым заставляет замораживать оборотные средства.
Четвёртый предлагает факторинг. Пятый готов поставить товар с оплатой после реализации.
И нужно выбрать комбинацию платежей и закупок с максимальным финансовым результатом.
В этом случае даже стоимость привлечения кредита становится элементом оптимизации закупочного плана.
Мы уже не можем отдельно оптимизировать закупки, отдельно — платежи и отдельно — продажи.
Деньги связывают эти процессы между собой.
Где оптимальное количество кредита?
Кредит увеличивает доступный оборотный капитал, но одновременно увеличивает расходы на проценты.
Дополнительные закупки могут принести прибыль, превосходящую стоимость финансирования.
Следовательно, вопрос состоит не просто в том, брать или не брать кредит.
Нужно определить, какой объём заёмных средств действительно способен принести дополнительную прибыль после вычета стоимости финансирования и с учётом риска.
| Рассчитай оптимальный объём использования кредитной линии на следующие четыре месяца. Учти прогнозируемую прибыль от дополнительных закупок, оборачиваемость товаров, стоимость кредита, кредитные ковенанты, обязательные платежи и риск снижения спроса. Покажи, при каком объёме финансирования дополнительная ожидаемая прибыль перестаёт оправдывать дополнительные риски. |
Для такого анализа нужны сценарии и оптимизационные модели.
Но сформулировать задачу и организовать получение необходимых данных AI вполне способен.
Заменит ли чат рабочее место казначея?
В части анализа денежных потоков, моделирования сценариев, подготовки платёжного календаря и обоснования решений — вполне возможно.
Но согласование платежей, изменение финансовых обязательств и особенно отправка денежных средств требуют строгого контроля и формальных процедур.
Здесь я скорее ожидаю смешанную модель: диалог для анализа и планирования, специализированные интерфейсы для исполнения и подтверждения операций.
Финансовый директор
Финансовый директор, как правило, не хочет изучать структуру регистров и особенности настройки отчётов. Да что там говорить, мы все знаем, что любит - Excel.
Ему нужно понять финансовое состояние предприятия и принять решение.
Например:
Почему в сентябре упала валовая рентабельность? Разложи отклонение по товарным группам, клиентам и изменениям себестоимости.
Или:
| Построй прогноз движения денежных средств на шесть недель. Учти текущую дебиторскую задолженность, графики оплат поставщикам, зарплатные выплаты и налоги. Покажи недели с ожидаемым кассовым разрывом. |
Или совсем просто:
| Можем ли мы сейчас позволить себе закупку оборудования за 15 миллионов без привлечения кредита? |
Последний вопрос особенно показателен.
В традиционной ERP пользователь должен знать, какие показатели ему потребуются и где их получить.
AI же может самостоятельно определить необходимые данные, запросить их, выполнить расчёт и сообщить, чего не хватает для обоснованного решения.
Конечно, это предполагает доступ к корректным данным, утверждённой модели финансового планирования и правилам расчёта.
Но именно здесь меняется концепция интерфейса: вместо того чтобы самостоятельно собирать информацию из различных отчётов, руководитель формулирует вопрос, на который хочет получить ответ.
Более того, он может продолжить анализ:
| Хорошо, а теперь рассчитай тот же сценарий, если покупатели задержат оплату на десять дней. |
Или:
| Как изменится результат, если мы откажемся от двух инвестиционных проектов и направим освободившиеся средства на финансирование оборотного капитала? |
Для полноценной системы бюджетирования подобные расчёты должны опираться на формальные модели, а не на фантазию языковой модели.
Однако ничто не мешает использовать AI для постановки задачи, вызова расчётных механизмов ERP и интерпретации результата.
Финансовый директор может получить ответ на сложный вопрос, вообще не открывая ни одного отчёта. Оценка потенциала замены - очень высокая.
Генеральный директор
Управление предприятием не сводится к получению отчётов.
Но представим типичный вопрос собственника:
| Почему мы увеличили выручку на 18%, а свободных денег стало меньше? |
Для ответа может потребоваться анализ дебиторской задолженности, закупок, запасов, оборачиваемости, затрат, производственного цикла и финансовых обязательств.
В классической модели руководитель ставит задачу финансовому директору. Тот собирает сведения у подразделений. Аналитики готовят отчёты, объяснения, презентации.
И через некоторое время руководитель получает ответ.
А если он сможет обратиться непосредственно к AI, имеющему доступ к соответствующим данным?
Причём не просто получить диаграмму, а продолжить исследование:
| Хорошо. Какая часть проблемы связана с ростом складских запасов? |
| А почему выросли именно эти запасы? |
| Что будет, если сократить закупки этих товарных групп на 30%? |
| Как это повлияет на продажи и прибыль? |
| Подготовь три варианта действий и укажи риски каждого. |
Здесь появляется возможность практически непрерывного сценарного анализа. Но можно пойти ещё дальше.
Ведь руководителя интересует не только объяснение того, что уже произошло. Ему необходимо определить, что делать дальше.
| На следующий квартал у нас есть три альтернативы: вложить 20 миллионов в увеличение запасов, расширить производственные мощности или досрочно погасить кредит. Сравни варианты по ожидаемой прибыли, денежному потоку, окупаемости, риску и устойчивости к снижению спроса. Предложи оптимальную комбинацию, включая возможность разделить инвестиции между направлениями. |
А теперь добавим, что рынок изменился: оновной конкурент сократил производство, спрос на часть товаров вырос, а стоимость оборудования увеличилась.
AI может получить новые данные и предложить пересмотреть первоначальные приоритеты.
Конечно, подобные решения нельзя принимать только на основании ответа языковой модели.
Но сама возможность быстро исследовать множество альтернатив, учитывать информацию из разных систем и вести диалог с расчётной моделью выглядит крайне привлекательно.
Речь не о том, чтобы доверить LLM руководство предприятием, а о резком снижении стоимости получения ответа на сложный управленческий вопрос.
И вот такому пользователю традиционный интерфейс ERP действительно может оказаться нужен меньше всего.
Бухгалтерия
С одной стороны, многие бухгалтерские операции прекрасно формализованы. С другой — бухгалтерия требует очень высокой точности. Никому не нужен AI, который творчески интерпретирует правила начисления НДС или самостоятельно придумывает проводки.
Но теперь посмотрим на задачи главного бухгалтера.
| Проанализируй закрытие месяца. Найди нетипичные операции, подозрительные отклонения себестоимости, зависшие авансы, отрицательные остатки и расхождения между бухгалтерскими и управленческими данными. Расставь проблемы по степени риска. |
Это уже гораздо интереснее обычного запуска контрольного отчёта.
AI может сопоставлять множество показателей, искать необычные взаимосвязи, формулировать гипотезы и предлагать направления проверки.
Ещё один сценарий:
| Сравни налоговую нагрузку при нескольких допустимых вариантах организации операций. Учти действующие ограничения, сформируй расчёты и перечисли риски каждого варианта. |
Разумеется, здесь необходимы актуальные нормативные данные, специализированные расчётные механизмы и обязательная проверка специалистом.
Но для поиска проблем и анализа альтернатив AI может оказаться весьма полезен.
А бухгалтер по первичке?
Если он обрабатывает сотни однотипных документов, привычные формы, массовые обработки и автоматическое распознавание документов могут быть значительно эффективнее последовательного диалога.
Впрочем, когда возникает нестандартная ситуация, например, сложное расхождение между документами поставщика, поступлением и взаиморасчётами AI может помочь разобраться в причинах.
Получается, что даже внутри одной подсистемы ERP перспективы очень разные.
AI может заменить многие способы поиска и анализа бухгалтерских ошибок, но не должен заменять правила бухгалтерского учёта.
ТОиР: купить запчасть или подождать
Возьмём управление техническим обслуживанием и ремонтами. Здесь можно найти прекрасные задачи для оптимизации.
Например, предприятие использует дорогостоящее оборудование. Некоторые узлы периодически выходят из строя.
Аварийная остановка обходится дорого, но профилактический ремонт тоже требует денег и времени.
Нужно выбрать оптимальную стратегию обслуживания.
| Проанализируй историю отказов оборудования, наработку, загрузку производственных линий, стоимость запасных частей и последствия простоев. Предложи план профилактических ремонтов с минимальными ожидаемыми совокупными потерями. |
Здесь необходимо найти баланс между стоимостью профилактики и риском аварии.
А если добавить производственный график?
| Перенеси ремонты на периоды минимальной производственной загрузки. Проверь, есть ли необходимые запчасти. Если нет — сравни варианты закупки с учётом сроков доставки. |
Мы снова получаем межфункциональную задачу.
Причём экономический эффект от предотвращения одной серьёзной аварии может многократно превысить стоимость всех использованных токенов.
Но можно сформулировать и ещё более интересный вопрос:
| Для каких узлов экономически выгоднее держать резервные запчасти на складе, а для каких- рассчитывать на срочную доставку? Учти вероятность отказа, стоимость простоя, срок доставки, стоимость хранения и возможность использовать запасную часть на нескольких единицах оборудования. |
Это практически задача управления страховыми запасами, но с целевой функцией, учитывающей вероятные потери производственной прибыли.
Вполне возможно, что дорогую деталь, которая годами лежит на складе, действительно стоит продолжать хранить. А дешёвую-наоборот, заказывать только по необходимости.
Всё зависит от экономических последствий отказа.
Конечно, оценка вероятности отказа требует качественной истории эксплуатации и соответствующей модели, а рекомендации должны проходить инженерную проверку.
С точки зрения интерфейса ситуация аналогична производству: инженеру по надёжности или руководителю ТОиР чат может заменить значительную часть аналитических инструментов.
А вот для регистрации выполнения работ, технологического контроля и обслуживания оборудования специализированные интерфейсы по-прежнему будут необходимы.
ЗУП и HR: оптимизация персонала, а не генерация приказов
На первый взгляд, кадровый учёт не самый очевидный кандидат для AI.
Массовый ввод кадровых документов удобнее выполнять привычными средствами.
Однако представим предприятие, где необходимо составить график работы нескольких сотен сотрудников.
Нужно учитывать квалификацию, сменность, допустимую нагрузку, отпуска, законодательные ограничения, стоимость сверхурочной работы и план производственной загрузки.
| Сформируй варианты графиков на следующий месяц, обеспечивающие план производства с минимальными затратами на персонал. Учти квалификации, обязательные периоды отдыха, отпуска и допустимое количество сверхурочных часов. |
Здесь снова возникает классическая оптимизационная задача.
AI может подготовить постановку, собрать необходимые данные, вызвать решатель и пояснить компромиссы.
Другой пример-анализ фонда оплаты труда:
| Какие изменения системы премирования позволят увеличить производительность без существенного роста ФОТ? Построй несколько сценариев на основании исторических данных. |
Последняя задача, конечно, значительно сложнее: простой анализ корреляций не позволяет достоверно предсказать реакцию сотрудников на изменение мотивации.
Тем не менее как инструмент построения и сравнения гипотез AI здесь весьма интересен.
И ещё одна ситуация - предприятие планирует расширить производство.
Возникает выбор: нанять дополнительных сотрудников, использовать сверхурочную работу, изменить сменность или передать часть операций подрядчику.
Какое решение обеспечит наибольшую прибыль при сохранении требуемых сроков?
Здесь снова необходимо объединить данные производства, ЗУП, закупок, подрядчиков и финансов.
Ограничения очевидны: конфиденциальность персональных данных, требования трудового законодательства, проверка допущений и человеческий контроль решений, затрагивающих работников.
Таким образом, в кадровой подсистеме повторяется знакомая картина: для планирования персонала и анализа ФОТ чат может быть очень полезен, но для оперативной обработки кадровых документов и сложных начислений традиционный интерфейс сохраняет преимущества.
Продажи: почему я не верю в скорую смерть интерфейса менеджера
Представим реальную работу менеджера, который разговаривает по телефону с клиентом.
-Давайте двадцать штук. Нет, пятнадцать. А другого цвета есть? А какая скидка? А что на складе? А с доставкой завтра получится?
В такой ситуации хорошо спроектированная форма ERP может оказаться гораздо удобнее чата.
Скорость реакции критична. Менеджеру не нужно каждый раз объяснять системе, что он хочет изменить количество в строке документа - он просто меняет количество.
Если ChatGPT будет несколько секунд рассуждать над каждым действием и вызывать инструменты, клиент успеет положить трубку.
Поэтому я довольно скептически отношусь к идее полной замены интерфейса оперативных продаж диалогом.
Но теперь представим другую задачу:
| Проанализируй клиентов, сокративших закупки за последние три месяца. Определи возможные причины, оцени риск ухода и подготовь персональные предложения с учётом их истории, доступного ассортимента и маржинальности. |
Или:
| Выбери клиентов, которым стоит предложить индивидуальные скидки. Цель - увеличить общую прибыль, а не объём продаж. Не предлагай скидки тем, кто с высокой вероятностью купит и без них. |
Вот это уже совсем другой уровень. А если ещё учесть стоимость привлечения клиента, вероятность повторных покупок и ожидаемую прибыль за весь период отношений?
Тогда оптимизация может привести к тому, что предприятию выгоднее временно пожертвовать частью прибыли на первом заказе, чтобы приобрести долгосрочного клиента.
Или, наоборот, прекратить дорогостоящую индивидуальную работу с клиентом, который приносит большую выручку, но фактически не обеспечивает положительного экономического результата после учёта логистики, отсрочек и обслуживания.
AI может плохо заменять менеджеру форму создания заказа, но очень хорошо заменять часть аналитической работы, которую раньше вообще никто не выполнял.
Есть и ещё один сценарий: клиент самостоятельно общается с AI-агентом, который подбирает ассортимент и оформляет заказ непосредственно в ERP.
В этом случае интерфейс менеджера может оказаться вообще не нужен - но это уже вопрос автоматизации самой функции продаж, а не только пользовательского интерфейса.
Склад и розница: здесь ChatGPT лучше не мешаться
Приёмка, размещение, отбор, упаковка, инвентаризация, кассовые операции.
Всё это процессы, для которых критически важны скорость, предсказуемость и удобный интерфейс.
Кладовщику не нужен философский диалог со сканером штрихкодов.
Он хочет отсканировать товар, получить результат и перейти к следующему.
Поэтому в оперативной складской работе привычные интерфейсы, ТСД и специализированные мобильные приложения ещё долго сохранят преимущество.
Но руководитель склада решает совсем другие задачи.
Например:
| Проанализируй перемещения товаров и историю комплектации заказов. Предложи перераспределение товаров по ячейкам, минимизирующее время отбора. |
Или:
| Найди причины роста складских затрат и предложи изменения процессов с оценкой экономического эффекта. |
Здесь уже появляются задачи оптимизации размещения, маршрутов и использования ресурсов. Причём здесь тоже можно пойти значительно дальше классической оптимизации маршрута сборщика.
Допустим, у компании несколько складов. Один расположен ближе к основным покупателям, но хранение на нём дороже. Другой дешевле, однако доставка клиентам занимает больше времени. Третий позволяет быстро обрабатывать небольшие заказы, но ограничен по площади. А товары постоянно перемещаются между складами.
| Определи оптимальное распределение товаров между складами на следующие два месяца. Минимизируй совокупные затраты на хранение, перемещения, комплектацию и доставку с учётом сезонного спроса и требований клиентов по срокам. Учти стоимость замороженных запасов и потерянную прибыль от возможного дефицита. |
Это уже задача оптимизации логистической сети. В рознице аналогично. Кассовый интерфейс останется.
Но задачи формирования ассортимента магазинов, управления ценами, запасами и маркетинговыми акциями могут существенно измениться под влиянием AI.
Граница между классическим интерфейсом и AI проходит не по подсистемам ERP, а по характеру выполняемой работы.
Сведём результаты: какие рабочие места действительно можно заменить?
Попробуем оценить перспективы по пятибалльной шкале. Первый показатель - потенциал замены традиционного интерфейса диалоговым. Второй - потенциальный экономический эффект, включая возможности оптимизации, анализа и улучшения решений.
| Рабочее место | Замена UI | Экономический потенциал |
|---|---|---|
| Генеральный директор | 5/5 | 5/5 |
| Финансовый директор | 5/5 | 5/5 |
| Экономист, финансовый аналитик | 5/5 | 5/5 |
| Руководитель закупок, закупщик | 5/5 | 5/5 |
| Специалист по ценообразованию | 5/5 | 5/5 |
| Коммерческий директор | 5/5 | 5/5 |
| Планировщик производства | 4/5 | 5/5 |
| Казначей | 4/5 | 5/5 |
| Главный бухгалтер | 3/5 | 4/5 |
| Специалист по ТОиР | 3/5 | 5/5 |
| HR, кадровое планирование | 3/5 | 4/5 |
| Логист, диспетчер | 3/5 | 4/5 |
| Начальник склада | 3/5 | 4/5 |
| Менеджер по продажам | 2/5 | 4/5 |
| Бухгалтер по первичке | 2/5 | 3/5 |
| Расчётчик зарплаты | 2/5 | 3/5 |
| Кладовщик, оператор ТСД | 1/5 | 2/5 |
| Производственный рабочий | 1/5 | 2/5 |
| Кассир | 1/5 | 1/5 |
На мой взгляд, прослеживается довольно чёткая закономерность: Чем больше рабочее место связано с анализом, планированием и принятием решений, тем выше вероятность перехода к диалоговому интерфейсу. И наоборот: чем больше коротких повторяющихся операций, тем выше ценность специализированного UI.
Менеджер по продажам может продолжать пользоваться привычной формой заказа, но AI будет помогать ему выбирать более прибыльных клиентов и формировать лучшие предложения.
Кладовщик продолжит сканировать товары, а руководитель склада может поручить AI оптимизировать размещение запасов.
Для финансового директора и закупщика ситуация другая: именно чат способен стать основным способом взаимодействия с бизнес-системой.
Возможно, наиболее масштабные изменения произойдут не там, где интерфейс проще всего заменить, а там, где стоимость неправильного решения значительно выше стоимости его анализа.
Небольшая практическая проверка идеи
Чтобы не оставаться исключительно в области фантазий, я подключил ChatGPT через MCP к работающей конфигурации торговли и склада. Эксперименты проводились на моей платформе NodaLogic. Это не 1С, но не имеет никакой роли, в душе то я - 1Сник. Для этого я по быстрому сгенерил учётную конфигурацию (про генерацию писал тут), близкую по структуре и основным процессам к 1С:УТ: документы продаж и закупок, склады, остатки, резервы, себестоимость, обеспечение потребностей, финансовые показатели и другие механизмы.
Вы тоже можете зайти в NodaLogic, завести демо базу, подключить MCP к своей модели, попросить LLM
заполнить тестовые данные по образцам как вас надо и поэкспериментировать.
ChatGPT получил возможность работать с данными и вызывать бизнес-операции через MCP.
Несколько характерных примеров.

Планирование пополнения запасов. По запросу на естественном языке AI собрал необходимые данные, проанализировал потребности и предложил закупки.

Финансовое прогнозирование. На основании имеющихся данных AI подготовил прогноз финансовых показателей, учёл текущие обязательства и указал на ограничения расчёта.
Я сознательно не хочу представлять эти эксперименты как доказательство способности AI самостоятельно оптимизировать целое предприятие - конфа, на которой я гонял тесты - простенькая.
Однако они демонстрируют принципиальную возможность: AI может работать не только как консультант, но и как исполнитель, обращающийся к реальным данным и бизнес-операциям.
Важно также, что эксперименты проводились именно на NodaLogic, а не на типовой конфигурации 1С. Поэтому нельзя автоматически переносить результаты тестирования на функционал конкретных конфигураций 1С.
Но сама схема применения MCP не зависит от платформы учётной системы. При наличии соответствующего MCP-сервера или адаптера аналогичные механизмы можно реализовать для 1С:УТ, 1С, КА, Бухгалтерии и других решений.
И, собственно, именно поэтому я предлагаю обсуждать перспективы технологии не применительно к конкретной демонстрационной системе, а ко всему классу корпоративных информационных систем.
А стоит ли вообще менять интерфейс на чат?
Вернёмся к вопросу, с которого всё начиналось. Допустим, ChatGPT умеет создавать документы, искать товары, строить отчёты и выполнять расчёты. Но становится ли от этого работа удобнее?
Не всегда.
Если пользователь за пять секунд создаёт документ в привычной форме, а AI выполняет ту же операцию за тридцать, выгода сомнительна. Добавим стоимость токенов, задержки обращения к инструментам и необходимость проверки результата. Получаем довольно дорогой способ нажимать кнопки.
Но теперь рассмотрим другую ситуацию: пользователь хочет узнать, почему снизилась рентабельность товарной группы. В обычной ERP ему необходимо определить подходящие отчёты, выбрать аналитики, настроить отборы, сравнить периоды, проверить себестоимость, посмотреть динамику продаж и цен.
В диалоговой модели он просто задаёт вопрос. И затем уточняет:
- А что изменилось по основным поставщикам?
- Покажи влияние закупочных цен.
- А если исключить разовые продажи?
- Какие товары дали наибольший отрицательный эффект?
Здесь чат заменяет не отдельную форму отчёта. Он заменяет целую последовательность действий по поиску, подготовке и анализу информации. Именно поэтому я считаю, что оценивать замену интерфейса по числу автоматизированных кнопок неправильный подход. Необходимо сравнивать выполнение законченной пользовательской задачи.
Сколько времени понадобилось, чтобы получить результат? Сколько действий пришлось выполнить? Насколько понятен ответ? Потребовалось ли обращаться к специалистам? Можно ли сразу продолжить работу?
А если интерфейс вообще не нужен - даже чат?
Мы до сих пор обсуждали ситуацию, когда пользователь обращается к AI с запросом. Но почему обязательно пользователь должен инициировать работу? Представим систему, которая регулярно проверяет ключевые показатели предприятия.
Она обнаруживает изменение спроса, рост дебиторской задолженности, риск дефицита материалов или угрозу кассового разрыва. Затем самостоятельно выполняет анализ и предлагает варианты действий.
Например:
| По трём ключевым товарным группам прогнозируется дефицит через 12 дней. Подготовлены два варианта закупок. Первый дешевле, но создаёт риск опоздания к пику спроса. Второй требует дополнительных оборотных средств, но обеспечивает более высокую ожидаемую прибыль. Рекомендую второй вариант при условии согласования отсрочки платежа. |
Или:
| Появилась возможность увеличить прибыль производственной программы за счёт перераспределения загрузки двух участков. Для этого необходимо перенести выполнение трёх заказов и организовать дополнительную смену. Подготовлен сравнительный расчёт. |
Или:
| Прогноз денежных потоков показывает высокий риск кассового разрыва через три недели. Предлагаю изменить график платежей и сократить закупки товаров с низкой оборачиваемостью. Возможный эффект и риски рассчитаны. |
А теперь представим, что система не просто сообщает об отклонениях, но и регулярно пересматривает экономические возможности.
Например, обнаруживает, что один из поставщиков снизил цену, а другой сократил срок доставки, и предлагает перераспределить закупки, потому что новая комбинация позволит увеличить прибыль при том же уровне оборотного капитала.
В этой модели пользователь уже не ищет информацию.
Система сама обнаруживает ситуацию, требующую внимания, и обращается к пользователю с подготовленными вариантами решения.
Технически это потребует событийных механизмов, расписаний, внешних инструментов и контролируемого автономного исполнения. Сам MCP не является готовым планировщиком таких процессов. Но направление развития выглядит вполне логичным.
Возможно, интерфейс будущей ERP - это не набор форм и даже не чат, а поток управленческих ситуаций, по которым системе требуется решение человека.
Причём для части операций вмешательство человека вообще не понадобится- если они заранее разрешены, ограничены и безопасны.
И кстати мы возможно, мы слишком много внимания уделяем пользовательским интерфейсам и слишком мало - доступности бизнес-логики как самостоятельного сервиса.
Я вовсе не веду к тому что интерфейсы не нужны. Мы уже выяснили что где то они необходимы, а использование ИИ сводится к их генерации 1 раз чтобы потом использовать бесконечно.
Я к тому, что возрастает ценность хорошо спроектированных механизмов бизнес-логики и сервисов.
Например: получить потребности, рассчитать доступность, спрогнозировать денежные потоки, оценить производственный сценарий, рассчитать себестоимость, проверить возможность проведения, сформировать документы.
Меньше уникальных интерфейсов для каждого сценария. Больше качественных бизнес-методов, API, расчётных инструментов и средств контроля.
И не исключено, что через несколько лет наличие удобного машинного интерфейса к бизнес-логике станет таким же естественным требованием к ERP, как сегодня наличие веб-клиента или мобильного приложения.
А что если MCP будет у всех?
Небольшое отстутпление. Недавно я оказался проездом в другой стране и городе и у меня случилась небольшая неприятность с зубом. Я решил обратиться к стоматологу, открыл Гугл карты и стал всех обзванивать и рассказывать про свою беду. Выяснить мне надо было 1) делает ли это вообще 2) может ли меня принять и когда и 3) далеко ли находится. Короче мне надо было прямо сейчас потому что через несколько часов у меня был рейс в третью страну и я хотел лететь уже отремонтированным ну и чтобы не ехать далеко. И тут я подумал. Есть платформы, такие как NodaLogic где MCP (как и REST) например делается автоматически в придачу так сказать к объектам, т.е. вы конфу пишите (будем откровенны - генерите), а MCP уже готов. И вот было бы здорово если бы здорово чтобы все стоматорогии, автосервисы и т.д. имели бы MCP. Тогда бы я открыл свой чат и написал "Запиши меня как можно скорее до 15-00 с такой то проблемой к тем, кто это сможет сделать". А он бы там связывался с каждым MCP выяснял это вот все и в конечном итоге нашел подходящий вариант.
Вместо заключения
Когда я начинал эксперименты с ChatGPT и MCP, меня интересовал довольно простой вопрос. Какие интерфейсы уже сейчас можно не проектировать, а просто выставить в MCP? Можно ли работать с учётной системой через чат вместо привычного интерфейса? Оказалось, что во многих случаях- действительно можно.
Но чем дальше я размышлял над перспективами такого подхода, тем интереснее становился другой вопрос: а стоит ли вообще ограничиваться повторением привычных пользовательских операций? Да, можно грузить данные из кучи экселей, делать какие то интеграции, перегоны данных, формализовывать то, что не формализовано. Но это все мелочи, это как микроскопом гвозди забивать.
Кстати, еще одна мысль - я рассматривал укомплектованное штатом предприятие, а что если это малое предприятие, где нет таких штатных единиц, а потребности есть? В этой плоскости еще больше смысла, да? Помните, как в фантастике, 1 человек управляет космическим кораблем, стоя на мостике и общаясь с ИИ корабля голосом? Такая ассоциация с бизнесом не приходит в голову в свете новых возможностей? Я подумаю об этом в NodaLogic...
ERP давно умеют создавать документы, рассчитывать остатки, формировать отчёты и выполнять бизнес-операции. Настоящая ценность AI может оказаться совсем в другом - делать то, чего ERP не умеет, давать бесконечную гибкость, вместо запрограммированых алгоритмов и отчетов, решать сложные задачи оптимизации на лету.
ERP при этом никуда не исчезнет. Более того, требования к качеству её бизнес-логики, данным и механизмам контроля только возрастут. Но сама модель взаимодействия с системой может существенно измениться.
Если LLM сможет не только выполнять работу пользователя, но и предлагать решения, до которых пользователь сам не додумался,какой процент традиционного интерфейса ERP действительно останется нужен?
Может быть, мы стоим на пороге нового этапа развития корпоративных систем. А может быть, это очередная технологическая мода, которая разобьётся о реальные требования бизнеса.
Думаю, ближайшие годы дадут ответ. Но обсуждать это стоит уже сейчас.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.