Разговор про «ИИ в 1С» почти всегда начинается с вопроса о цене и сроке. Честно ответить на него до двух встречных вопросов нельзя: какая конфигурация и что в ней уже переписано. Потому что за одной фразой прячутся четыре разных проекта.
В УНФ первый процесс запускается внешней обработкой, живет в сеансе пользователя и обсуждается с одним человеком, который тут же и решает. В 1С:ERP задача той же сложности упирается в закрытие месяца, дату запрета изменения и в пятерых согласующих, один из которых вообще не ваш сотрудник — он на стороне партнера, который держит поддержку конфигурации. Модель в обоих случаях одна и та же. Расходятся объем данных, число объектов метаданных, глубина кастомизации, цена ошибочно созданного документа и скорость, с которой компания внутри себя принимает решения.
Сами способы обмена — внешняя обработка, расширение с HTTP-сервисом, стандартный интерфейс OData, промежуточное хранилище — разобраны отдельно: как встроить ИИ в 1С и не трогать конфигурацию. Здесь речь о другом: какой из них под какую конфигурацию, какой процесс брать первым и почему выгрузку для обучения нельзя делать запросами по рабочей базе в рабочее время.
Пять осей, по которым конфигурации расходятся
Число пользователей и размер файла базы для оценки проекта бесполезны. Меряйте другое — пять параметров, каждый снимается за час, и вместе они определяют архитектуру, срок и цену.
- Объем и связность данных. Число документов в месяц и число строк в ключевых регистрах: остатки, расчеты с контрагентами, продажи. Это те таблицы, по которым пойдут запросы выгрузки, и именно их размер решает, можно ли брать данные напрямую.
- Число объектов метаданных. Откройте дерево конфигурации и посчитайте документы, справочники, регистры накопления и регистры сведений. В УНФ список умещается на экран, в ERP порядок другой. Каждый лишний объект — это еще один кандидат в источники данных и еще одна возможность выбрать неверный.
- Глубина кастомизации. Сколько объектов изменено относительно типовой, снята ли база с поддержки, есть ли расширения. Стандартный отчет сравнения конфигурации с поставляемой дает эту цифру за пятнадцать минут, и она честнее любых рассказов на созвоне.
- Цена ошибочного документа. Сколько регистров и людей затронет неверно проведенный документ и через сколько дней это заметят.
- Скорость согласования. Сколько человек обязаны сказать «да» до старта и за сколько дней каждый из них отвечает на письмо.
Первые три оси определяют техническую схему. Четвертая решает, разрешено ли машине проводить документы или ее потолок — черновик. Пятая определяет срок, и на крупных конфигурациях она обычно и оказывается решающей.
УНФ: короткий цикл и мало истории
Управление нашей фирмой — база, где обычно одно-два юрлица, сквозной контур от заказа покупателя до расходной накладной, кассовые ордера и заказ-наряды. Кастомизация чаще всего поверхностная: свои печатные формы, пара добавленных реквизитов, доработанный отчет. Решение принимает собственник или его заместитель, и принимается оно в одном разговоре.
Типичный первый процесс — ввод входящих счетов и накладных черновиком плюс ответы на повторяющиеся вопросы по остаткам и статусу заказа. Архитектурно этого хватает внешней обработке: пользователь открывает файл epf, жмет кнопку, обработка отправляет данные в сервис, получает разобранную структуру и создает документ. Ничего в конфигурации не меняется, файл удаляется одним движением, следов в базе не остается.
Главная засада на УНФ противоположна ожиданиям. Данных мало. Регистр соответствий номенклатуры контрагентов почти пуст, истории сопоставлений за годы нет, обучать модель на своих данных не на чем. Работать приходится на правилах, справочниках и языковой модели общего назначения, а качество растет медленнее, потому что и поток обратной связи от операторов меньше. Второй риск организационный: на маленькой базе легко согласиться сделать сразу все процессы и увязнуть.
УТ: номенклатура, цены и обмены наружу
Управление торговлей приносит первую серьезную сложность — справочник. Десятки тысяч позиций, артикулы поставщиков, единицы и кратность упаковок, соглашения об условиях продаж, сегменты, установка цен, обмены с сайтом и маркетплейсами. Документы простые по структуре, а вот связей вокруг них много.
Первый процесс здесь почти всегда лежит в закупках и сопоставлении: прайс поставщика против своей номенклатуры, подготовка заказов поставщикам, контроль дефицита. Как этот сценарий выглядит на большом справочнике и почему голый список рекомендаций создает двойную работу — разобрано в статье про 57 часов ручной закупки в день.
Внешней обработки на УТ уже мало. Поток приходит пачками, прайсы весят десятки тысяч строк, синхронно ждать ответа в форме нельзя. Рабочая схема — расширение с регламентным заданием и собственным регистром очереди: задание забирает порцию, отправляет в сервис, кладет результат обратно, помечает обработанное. Пользователь при этом видит результат в своем интерфейсе и не держит сеанс открытым полчаса.
Риск на УТ один и он предсказуемый: состояние справочника. Дубли позиций, «Товар без названия 3», разные единицы у одного товара, артикулы в поле наименования. Сопоставлять не с чем, пока это не разобрано, и никакая модель эту работу за вас не сделает.
ERP: документ, который никогда не одинок
В 1С:ERP документ живет в цепочке. Заказ клиента порождает потребность, потребность закрывается заказом поставщику или заказом на производство, производство разбивается на этапы, этапы дают выпуск, выпуск отражается в себестоимости, себестоимость считается регламентной операцией при закрытии месяца. Добавьте сюда несколько организаций, RLS по складам и подразделениям, отложенное проведение и дату запрета изменения.
Отсюда главная особенность внедрения. На УНФ ошибочный документ правится за минуту, и об этом знает один человек. На ERP тот же ошибочный документ уходит в обеспечение потребностей, тянет за собой пересчет партий и себестоимости, а всплывает через несколько недель на закрытии месяца, когда период уже почти закрыт и правка задним числом требует перепроведения цепочки.
На ERP машина создает черновики. Проведение остается человеку до отдельного решения по каждому типу документа — и принимается оно тогда, когда по этому типу накоплена статистика за месяцы работы.
Где проходит граница между записью и проведением, какие права выдавать служебной учетной записи и как устроена откатываемость — в разборе ИИ-агента с правом записи в 1С. На ERP его закрывают до того, как начинают рисовать схему обмена.
Самописные конфигурации на платформе 8.3
В опросниках такой класс обычно не значится, зато на обследовании обнаруживается регулярно: платформа типовая, метаданные свои, история с середины десятых. Плюс у такой базы реальный — снимать с поддержки нечего, добавить свой HTTP-сервис, регистр очереди или реквизит можно без страха потерять обновления. Внедрение технически свободнее, чем на типовой ERP.
Минусы начинаются на обследовании. Типовой семантики нет: имя регистра ничего не говорит о его содержимом, и какой из трех регистров остатков считается источником правды, знают два человека в компании. OData часто не опубликован вовсе. Права служебной учетной записи урезаны так, что половина справочников недоступна на чтение. Проведение переписано, и в модуле документа живет бизнес- логика, мимо которой записывать объект нельзя. Полный список граблей — в разборе что ломается в конфигурации с историей.
Рецепт простой и дешевый. До оценки проекта просите у своего разработчика три вещи: выгрузку структуры метаданных, по три реальных документа каждого типа из рабочего потока и текст на страницу о том, какие объекты считаются источником правды по остаткам, ценам и расчетам с контрагентами. Это день работы вашего человека, и он снимает недели пресейла и половину риска в смете.
Сводка: первый процесс, срок, главный риск
Таблица собирает то, что выше, в вид, пригодный для совещания. Сроки даны относительно базовой вилки: первый процесс на нашем направлении — от 250 000 ₽ и 3–5 недель до пилота.
| Конфигурация | Типичный первый процесс | Срок до пилота | Главный риск |
|---|---|---|---|
| УНФ | Ввод входящих счетов и накладных черновиком, ответы по остаткам и статусу заказа | Нижняя граница вилки 3–5 недель | Истории сопоставлений мало, учиться не на чем |
| Бухгалтерия | Первичка и разнесение по статьям затрат | Нижняя граница, если выборка документов собрана заранее | Закрытый период и требование проверяемости каждой цифры |
| УТ | Сопоставление прайсов с номенклатурой, подготовка заказов поставщикам | Верх вилки: неделя уходит на разбор справочника | Дубли и мусор в номенклатуре |
| 1С:ERP | Один узкий участок: приемка на склад, проверка заказов, подсказки по обеспечению | Вилка на разработку плюс срок согласований, считается отдельно | Ошибка всплывает на закрытии месяца, через недели после создания документа |
| Самописная на 8.3 | Определяется после обследования метаданных | Срок называется только после обследования | Нет документации и неочевидный источник правды |
Строка про Бухгалтерию здесь сжата до одной клетки — задачи и запреты этой конфигурации разобраны отдельно в статье про шесть задач и четыре запрета в 1С:Бухгалтерии.
Архитектура: обработка, расширение с очередью, витрина
Технических схем ровно три, и выбор между ними определяется объемом и режимом работы, а не размером компании.
| Что у вас | Схема обмена | Что обязано быть в ней |
|---|---|---|
| Одна база, сценарий по кнопке, десятки документов в день | Внешняя обработка epf, синхронный вызов сервиса из сеанса пользователя | Таймаут, понятная ошибка на форме, документ создается черновиком |
| Поток идет пачками, ждать в форме нельзя | Расширение: HTTP-сервис плюс регламентное задание и свой регистр очереди | Идемпотентность по бизнес-ключу, повтор не создает дубль, счетчик попыток |
| ERP, несколько баз, большой объем истории | Брокер очередей между базой и сервисом плюс отдельная витрина данных | Обратное давление, ретраи с задержкой, разделение чтения и записи |
Витрина — отдельная база вне контура 1С, куда данные складываются плоско: строка документа со всеми нужными реквизитами шапки, справочники развернуты в атрибуты. Модель читает витрину и в рабочую базу за историей не ходит. Первый полный слепок снимается с копии, дальше идет инкремент. Раскладка по слоям и нагрузке — в разборе интеграции ИИ с 1С и ERP.
Правило перехода между схемами: как только в проекте появляется слово «история» — за месяц, за год, за три года, — появляется и витрина. Пока задача сводится к обработке приходящего документа здесь и сейчас, хватает первых двух строк таблицы.
Почему на ERP начинают с узкого участка
Просьба «сделайте нам ассистента по всей базе» на ERP не выполняется, и причин четыре.
- Нет источника правды. В базе несколько регистров с похожими по смыслу остатками: свободные, к отгрузке, в резерве, по организациям. Человек знает, какой из них отвечает на конкретный вопрос. Модель без явного указания выберет любой и ответит уверенно.
- Нет владельца. У процесса приемки есть начальник склада, у ассистента по всей базе нет никого, кто примет работу и скажет, что стало лучше.
- Нет метрики. Узкий участок меряется долей документов без правок или минутами на операцию с секундомером. Общий ассистент меряется ощущениями, и на приемке это превращается в спор.
- Права. Доступ ко всей базе — это отдельное согласование с безопасностью на месяц, тогда как доступ к трем справочникам и двум документам согласуется на встрече.
Рабочая формулировка узкого участка: один тип документа, один регистр, одна метрика приемки, один владелец процесса, право записи только в черновик. После двух-трех таких участков появляется и накопленная разметка, и доверие внутри компании, и осмысленный разговор про расширение периметра.
Нагрузка: почему выгрузку нельзя брать с рабочей базы днем
Самая частая техническая ошибка на старте — запрос по рабочей базе в рабочее время, чтобы «быстренько посмотреть данные». На УНФ это пройдет незаметно. На ERP так можно остановить отгрузку.
- Длинное чтение конкурирует с проведением. Запрос по регистру накопления на миллионы строк держит соединение и блокировки, а проведение документов в ERP само по себе тяжелое: движения по нескольким регистрам плюс контроль остатков.
- Вымывается кеш СУБД. Разовая выборка «всего за три года» вытесняет из памяти сервера то, чем живет оперативная работа, и тормозить начинает вся база, включая тех, кто ничего не выгружал.
- OData построчно — это десятки тысяч запросов. Тысяча документов по сорок строк: тысяча вызовов на шапки плюс табличные части. Если строки тянутся по одной, выходит сорок тысяч вызовов, каждый со своим сеансом, своей авторизацией и своей транзакцией. Это нагрузка на сервер приложений и расход лицензий, который заметит администратор.
- Ночное окно тоже занято. Там уже стоят регламентные задания: обновление информационной базы, обмены между узлами, расчет себестоимости, обслуживание индексов. Расписание надо спросить у администратора до того, как назначать свое.
Правильный порядок такой. Первый полный слепок берется с копии базы, восстановленной из резервной копии на отдельном сервере, — это ноль нагрузки на продуктив. Дальше идет инкремент: регистрация изменений через план обмена, служебный реквизит с датой последнего изменения или захват изменений на уровне СУБД. Последний вариант с разбором задержек и подводных камней описан в статье про потоковую выгрузку изменений из 1С.
Порционность обязательна в любом варианте: выборка ограничивается периодом и числом строк, курсор двигается по последней обработанной дате, каждая порция — короткая транзакция. Объем прикидывается на салфетке: средний размер строки выгрузки в json — сотни байт. Триста байт на строку и два миллиона строк продаж за три года дают около 600 мегабайт в одном срезе. Столько в память сервиса поднимать незачем, тут сразу нужен поток на диск.
Запись обратно подчиняется тому же правилу. Пять тысяч черновиков, залитых одной пачкой в одиннадцать утра, — такой же удар по базе, как выгрузка. Заливка идет фоновым заданием порциями, с паузой между ними и с остановкой по сигналу администратора.
На крупных конфигурациях срок определяют согласования
Разработка первого процесса укладывается в те самые 3–5 недель. Календарный срок проекта на ERP определяется другим — числом людей, которые обязаны подтвердить решение.
Соберите список: ИТ-директор, главный бухгалтер или финансовый директор, владелец процесса на производстве или складе, служба безопасности, партнер, который держит поддержку конфигурации. Умножьте число согласующих на средний срок ответа. Пятеро по три рабочих дня — это пятнадцать рабочих дней, три недели чистого ожидания, если все отвечают с первого раза и никто не в отпуске. Разработка при этом идет параллельно и на срок не влияет.
Что реально сокращает календарь:
- Одна стартовая встреча со всеми согласующими вместо последовательной переписки.
- Письменно зафиксированный владелец процесса и тот, кто подписывает приемку.
- Доступы, полученные до начала работ: копия базы, служебная учетная запись, описание опубликованных сервисов.
- Согласованное окно выгрузки и подтвержденное расписание регламентных заданий.
- Пилот на копии базы. Рабочая база подключается последним шагом, после демонстрации результата.
Когда не надо
- Поток в десяток документов в день на УНФ. Замерьте секундомером время операции, умножьте на число операций в месяц и переведите в деньги по стоимости часа сотрудника. Если получившаяся сумма за год меньше стоимости первого процесса — тема закрыта, автоматика не окупится.
- Идет обновление ERP на новый релиз или переход с УПП. Метаданные поедут, ссылки поменяются, выгрузки развалятся. Стартовать имеет смысл после стабилизации.
- Самописная база, логику которой не знает ни один действующий сотрудник. Сначала обследование и документация силами вашего разработчика, потом разговор про модели.
- Запрос звучит как «ассистент по всей базе для всех». Без владельца процесса, метрики и границ прав такой проект нечем принимать.
- Справочник номенклатуры в состоянии, когда его дешевле пересобрать заново. Дубли, позиции без артикулов, свои единицы у каждого филиала. Порядок в данных идет первым.
Чек-лист: выбрать первый процесс за один день
- Выпишите пять мест, где люди перекладывают данные руками, и замерьте секундомером время одной операции в каждом.
- Для каждого посчитайте, сколько объектов метаданных он затрагивает. Берите первым тот, где их меньше всего при сопоставимой экономии.
- Проверьте, есть ли у процесса живой владелец, который готов принимать результат и разбирать спорные случаи.
- Сформулируйте метрику приемки одной строкой, с числом и способом замера.
- Спросите администратора: что опубликовано через OData и HTTP-сервисы, есть ли расширения, снята ли база с поддержки, каково расписание регламентных заданий, есть ли свежая копия базы для работ.
- Оцените цену ошибки: какие регистры затронет неверный документ и через сколько дней это заметят. Ответ определяет, черновик или проведение.
- Соберите всех согласующих на одну встречу и зафиксируйте решение письменно.
Ответы на эти семь пунктов — почти готовое техническое задание, и работают они одинаково на УНФ, УТ и ERP. Отличается календарь: на УНФ пятый и седьмой пункты закрываются за один день, на ERP они и есть тот срок, который потом называют в договоре.
Что дальше
Состав работ, вилки и порядок этапов — на странице ИИ в 1С: первый процесс от 250 000 ₽, 3–5 недель до пилота. Работы до 300 000 ₽ берутся разово, свыше — 50% на старте, 30% после демонстрации на ваших данных, 20% после передачи. Права на код и модели переходят заказчику после оплаты этапа.
Быстрее всего разговор идет так: вы присылаете название конфигурации и релиз, отчет сравнения с типовой, список процессов из первого пункта чек-листа и три реальных документа того типа, с которого хотите начать. По этому набору видно и схему обмена, и достижимый результат, и честный срок — до договора и без обязательств с вашей стороны.