ERP-системы *

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

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

Станков девять, производители разные, возраст тоже. Я был уверен, что главная сложность будет в Odoo. Оказалось наоборот: Odoo здесь самая спокойная часть, а вся работа ушла на то, чтобы вытащить данные из самих станков.

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

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

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

Я помню, как сотрудники, работавшие с первичными документами, говорили об этом чуть ли не со слезами. Они ожидали, что новая система сократит ручную работу и поможет быстрее выполнять привычные операции. После перехода им пришлось вводить больше данных, и освоение системы эту нагрузку не сняло. При этом проект признали успешным: компания получила возможности развития, которых не хватало раньше. Заказчик сознательно принял дополнительную нагрузку как цену перехода, но сотрудникам, вводившим первичку, легче работать не стало.

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

Хотел разобраться с одним, казалось бы, простым вопросом: за что мы заплатили подрядчику? Платёж был в 1С, заявка была в Bitrix24, а договор и акты приходилось искать среди вложений. С поиска этой связи начался финансовый сервис, а вокруг него постепенно появились ещё четыре продукта. Расскажу, как они складываются в ERP‑контур для стройки, что уже работает и где автоматизация пока может уверенно ошибиться.

ИИ хорошо справляется с такими задачами как добавить колонку в печатную форму ERP или параметр в отчет. И возникает резонный вопрос «а зачем покупать чужой софт, если я могу навайбкодить свой?». Если и вы уже вкусили сладкий плод вайбкодинга, прочитайте мой разбор этой идеи с некоторыми граблями из 15 лет опыта.

В первой статье я разобрал аббревиатуры, встречающиеся на производстве: от 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. Нужны описанные операции, данные по их стоимости и производительности, а также владелец, который отвечает за изменение.