ERP-системы *

В первой статье я разобрал аббревиатуры, встречающиеся на производстве: от SCADA, PLC и MES до PLM, BIM, EAM и QMS. Получилась нижняя часть корпоративного ландшафта: системы, которые работают с технологическим процессом, оборудованием, проектными данными и производственными операциями.

Но аббревиатуры на этом, конечно, не заканчиваются. Над производством стоит корпоративный уровень, где планируются потребности в материалах и ресурсах, считаются финансы, собираются данные в отчеты и аналитику, а также работает всеми любимый HR. И, конечно, наборов заглавных букв тут тоже хватает. Во второй части я расскажу, как MRP привел к ERP, зачем нужны BI и EPM, чем HCM отличается от HR-систем и что здесь делают ATS, LMS и WFM.

Российский рынок систем электронного документооборота сформировался давно и сегодня остается одним из наиболее зрелых сегментов корпоративного ПО. Крупные решения закрывают десятки сценариев — от регистрации и согласования документов до специализированных процессов, которые отличаются в зависимости от отрасли, масштаба бизнеса и внутренних регламентов компании.

Такая функциональная насыщенность стала естественным результатом развития рынка. Однако вместе с возможностями росла и сложность систем: увеличивалось число настроек, интерфейсов и сценариев работы, а внедрение СЭД все чаще превращалось в отдельный ИТ‑проект, требующий настройки, интеграции и обучения пользователей.

Мы в «Диасофт» считаем, что следующий этап развития СЭД может быть связан не с дальнейшим расширением функциональности, а с изменением самого подхода к архитектуре. Вместо еще одной крупной системы, которая существует рядом с ERP, CRM и другими корпоративными платформами, функции работы с документами могут стать частью уже существующих бизнес‑процессов.

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

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

На этот раз мы решили взять другую задачу.

Рабочая карта: от исследовательской оптики и слабых связей до специализированных методов, проверки и работающего компонента.

В первой статье этой серии "От университета до искусственного интеллекта: как ускорялся генератор изобретений" мы смотрели, как человечество постепенно усиливало генератор нового: университеты, печать, научные общества, лаборатории, вычислительные сети и, наконец, искусственный интеллект. Во второй вопрос практичнее: что происходит, когда значительная часть этой мощности оказывается в распоряжении одного исследователя или маленькой группы?

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

Сначала нужно понять, какими предметными мирами смотреть на задачу. Только потом — какой метод применять.

1. Одиночный исследователь — не маленький НИИ

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

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

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

Привет, Хабр! На связи Володин Михаил, ведущий инженер по нагрузочному тестированию, и Смирнов Вадим, старший инженер по нагрузочному тестированию в IBS. В этой статье мы поделимся своим опытом НТ SAP BW для одного из крупнейших российских банков.

Большинство разговоров про ИИ в бизнесе пока заканчиваются примерно одинаково: написать письмо, пересказать документ, сделать картинку или проанализировать Excel.

Но нам было интереснее проверить другой сценарий: что произойдет, если дать ИИ доступ не к выгрузке, а непосредственно к учетной системе компании? Чтобы он сам посмотрел продажи. Проверил остатки. Нашел должников. Создал заказ поставщику. Заполнил карточки товаров. А при необходимости разобрался, кто вчера поменял цены и насколько. Для этого мы подключили МойСклад к ИИ-ассистентам через MCP и начали давать им обычные задачи предпринимателя.

Рассказываем, что получилось.

Когда говорят об электронном сбыте, первое, что приходит в голову, – интернет-магазин, личный кабинет или интеграция с маркетплейсом. Клиент оформил заказ, информация попала в учетную систему – задача вроде бы решена. 

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

В результате электронный сбыт оказывается не интерфейсом для создания заказа, а сквозным процессом, связывающим клиента, склад, производство, закупки и сотрудников компании.

И здесь возникает главный вопрос: как сделать так, чтобы заказ не потерялся между всеми этими этапами?

Что приходится собирать генеральному директору

Эта публикация — прежде всего о работе генерального директора сложного предприятия. Каждая функция видит свой участок, а ответственность директора остаётся целой. Новый контракт, срыв поставки, отказ оборудования, изменение условий заказчика, дефицит денег или редкой компетенции приходят из разных контуров, но решение всё равно приходится принимать от имени предприятия как одного целого.

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

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

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

Новая, предпоследняя статья серии.

На этот раз – о моменте, когда проект уже нужно перестать обследовать и начать брать на себя обязательства.

В кейсе из моей практики заказчик был уверен, что всё готово: требования собраны, ТЗ есть, срок установлен, приоритет максимальный. Мы отказались подписываться под исходными условиями. Позже, после пересборки объёма и оценки рисков, подписались – хотя полной определённости всё ещё не было.

Где проходит эта граница? Сколько нужно знать, чтобы уже отвечать за результат? Когда риск можно принять, а когда это уже авантюра? И в какой момент ИТ обязано снять собственное отлагательное вето?

Пароль от хостинга — в личных сообщениях. SSH‑ключ — в архиве на рабочем столе, который никто не чистил года три. Токен от CRM — в закреплённом сообщении в Telegram, которое уже никто не читает. Знакомо? У нас было ровно так, пока я не сел и не разобрался, что с этим делать.

Это не очередной «как поднять Vaultwarden за 10 минут» — таких гайдов хватает в вики проекта. Это история про то, что происходит после команды docker compose up: VPN‑периметр вместо открытого порта, самоподписанный CA, который красиво работает на десктопах и разваливается на Android, DNS-01 challenge с собственным хуком для acme.sh под провайдера, которого нет в официальном списке, бэкап в два независимых конца и восстановление, протестированное заранее, а не в момент паники.

Если вы технарь — здесь рабочие конфиги, а не псевдокод: Caddy, docker‑compose, скрипт под acme.sh ретеншен бэкапов без магии. Если интегратор на Bitrix — готовая структура коллекций и прав под клиентские проекты, роли Dev/Marketing/Infra, чек‑лист на нового клиента. Если тимлид — регламент, который реально прижился в команде, а не умер через неделю, как очередная табличка в Notion.

Отдельный мотивбыл личный: давно хотелось не просто читать про self‑hosted‑подход бигтеха к секретам, а руками собрать что‑то похожее у себя — без DevOps‑отдела и без бюджета на энтерпрайз‑решения — и посмотреть, где ручной, но осознанный self‑hosted реально ломается, а где отрабатывает не хуже платного SaaS.

В предыдущей статье было описано, как массово находить документы за выбранный период, отменять их проведение и помечать на удаление. Частая задача, а штатных средств для ее решения в программе нет. Мной была создана внешняя обработка, которая в несколько проходов последовательно удаляет доступные ей зависимости между документами, отменяет их проведение и устанавливает пометки удаления.

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

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

Начало в статье ERP внедрили. Что дальше?

Термины, используемые в статье

Project-DR ERP Technology Distribution — полное название технологической сборки. В дальнейшем — «технологическая сборка Project-DR ERP», версия.

Project-DR — Project Digital Replica, проектная цифровая реплика — внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Заказчику Project-DR как технологическая среда не передаётся.

Project Core — проектное ядро — проектный носитель специализированного ресурса, в котором хранится подробный результат его работы по конкретному проекту.

Unified Project Store — единое проектное хранилище — машиночитаемый слой Project-DR, в котором собираются принятые проекции результатов специализированных Project Core.

Enterprise-DR — Enterprise Digital Replica, цифровая реплика предприятия — эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Именно Enterprise-DR передаётся заказчику.

Enterprise-DR Runtime — эксплуатационная среда Enterprise-DR — физически работающая система, в которой клиентская модель загружена в базу данных и доступна через Enterprise-DR API.

Enterprise-DR Runtime Kit — комплект, передаваемый заказчику для развёртывания и эксплуатации Enterprise-DR.

PostgreSQL — система управления базами данных, используемая в версии 2.5.1 как эталонная реализация базы Enterprise-DR. Далее — «база Enterprise-DR».

Enterprise-DR API — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.

От работающей ERP к цифровой реплике и вычислимой модели предприятия

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

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

Это не научная статистическая выборка, и я не пытаюсь её так называть. Но когда за спиной уже не несколько кейсов, а больше сотни проектов, постепенно начинаешь отличать случайность конкретного внедрения от проблемы, которая повторяется при разных заказчиках, командах и информационных системах. Если один и тот же вопрос возвращается снова и снова, значит, дело, скорее всего, уже не в особенностях отдельного предприятия. Возможно, чего-то не хватает в самой технологии проекта.

Мы собирались начать автоматизацию закупок с одного завода: провести пилот, отладить решение и потом тиражировать его на остальные предприятия. План выглядел профессионально и безопасно – пока директор по закупкам не оценил пересечение процессов четырёх заводов в диапазоне 40–60% в зависимости от площадки и участка процесса. Это был не формальный расчёт, а суждение человека, который видел закупочную работу всех предприятий. Его хватило, чтобы увидеть риск: один завод не был уменьшенной копией остальных. Выбрав его пилотом, мы могли сначала автоматизировать значительную часть локальной специфики, а затем переделывать решение при каждом тиражировании.

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

Для этого недостаточно просто установить WMS. Нужны описанные операции, данные по их стоимости и производительности, а также владелец, который отвечает за изменение.

Массовое удаление документов по определенному отбору — стандартная задача при работе с экономическими программами. Но в 1С:ERP нет штатного инструмента, позволяющего выбрать, например, все документы за определенный период и удалить их.

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

Код внешней обработки, границы ее применения, а также описание необходимых настроек 1С:ERP и составляют содержание этой статьи.

Представьте типичный понедельник в отделе закупок производственного предприятия. Пришло пять коммерческих предложений на одну и ту же позицию – допустим, нужен стандартный компонент, который регулярно идёт в производство. Менеджер открывает таблицу, смотрит на столбец «Цена за штуку» и выбирает минимум. Это занимает десять минут. Решение кажется очевидным.

Через три недели выясняется, что на складе лежит втрое больше компонентов, чем нужно. Поставщик с самой низкой ценой работает только от крупной партии, а об этом менеджер не подумал, когда смотрел на цифру за штуку. Деньги заморожены на складе. Оборотные средства иммобилизованы. Реальная стоимость единицы нужного товара оказалась не самой низкой, а самой высокой среди всех предложений.

И это не исключение – это норма для большинства предприятий, где выбор поставщика до сих пор делается вручную, на глазок, без формализованной процедуры. Хуже того: даже если менеджер учитывает партионность, он всё равно не учитывает историю взаимодействия – сколько раз поставщик привозил вовремя, сколько раз приходилось оформлять рекламацию. Эта информация хранится в ERP-системе, но почти никогда не используется для принятия решений.

В этой статье мы разберём математическую модель, которая закрывает оба пробела. Три критерия – приведённая стоимость закупки с учётом минимальной партии, срок поставки и интегральный уровень доверия к поставщику, вычисленный из данных ERP. Один алгоритм, реализованный в Engee на языке Julia. И числовой пример, где поставщик с самой низкой каталожной ценой закономерно оказывается наихудшим выбором – а модель это выявляет автоматически.

В последнее время генеративный ИИ все чаще становится частью корпоративных систем, и российский бизнес активно ищет способы его применения в CRM и ERP. Интерес к таким решениям за последний год вырос в два-три раза. Количество запросов «Битрикс24 ИИ» увеличилось на 600%, «CRM с нейросетью» — на 550%, «ИИ в 1С» — на 85%. При этом, по данным «СберАналитики» и «Сбер Бизнес Софт», 39% российских организаций уже используют ИИ-агентов и ассистентов в документообороте, финансах и HR. Тем не менее, ERP в этом смысле остается более консервативной областью. ИИ чаще подключают к ней в виде отдельных сервисов. Давайте разберем, в каких задачах ИИ действительно оправдан, как выбрать подходящий способ интеграции и почему в большинстве случаев корпоративную ERP разумнее не заменять, а постепенно дополнять.

Рынок созрел, но внедрения с ИИ точечные

Объем российского рынка ERP-систем по итогам 2025 года оценивается примерно в 100 млрд. рублей и продолжает плавно расти. При этом интерес к использованию встроенных ИИ-инструментов в корпоративных системах огромный. Но пока еще процент компаний, реально применяющих ИИ в ERP, остается небольшим. Сейчас начинают появляться ИИ-сервисы, которые могут встраиваться по API в ERP-системы.

Но прежде, чем браться за внедрение, компаниям предстоит ответить на несколько принципиальных вопросов.

В предыдущих статьях серии было показано, как использовать функциональность FEB_FILE_HANDLING в качестве единой точки входа для импорта банковских выписок в SAP независимо от канала их получения — через прямые сервисы коммуникации с банковскими системами или файлы из систем «Банк-клиент» — и от используемого формата: XML или текстового. Также была рассмотрена классическая схема импорта промежуточных выписок в течение дня с созданием платёжных авизо для обновления данных финансовой диспозиции, или денежной позиции.

Когда смотришь на описание нового инструмента, обычно всё выглядит хорошо: список функций, скриншоты, сценарии использования. Но гораздо интереснее посмотреть, что происходит с продуктом после покупки — какие задачи им действительно решают, где он оказывается полезным, а где пользователи упираются в ограничения.

Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе: