ERP-системы *

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

Привет, Хабр! Меня зовут Александр Зыков, я архитектор 1С в СДЭК. В этой статье расскажу про реализацию высоконагруженного биллинга на 1С взамен устаревшего Java‑модуля. Система обрабатывает более 1 миллиарда событий в месяц, формирует около 3 миллионов актов для 700 тысяч клиентов компании.

Разберу архитектуру решения: слои данных, ретроспективность, drill‑down до первичной операции, многопоточный конвейер, RabbitMQ, REST API, Grafana, партиционирование и охлаждение данных. Объясню, почему именно архитектура данных стала ключом к производительности, масштабируемости и устойчивости системы.

Привет, Хабр! Меня зовут Егор Шлюпиков, и я работаю старшим бизнес-аналитиком в YADRO в большой команде, которая менеджерит IT-оборудование. Мы следим за парком готовой техники и комплектующих, нужных для работы сотрудников. Сколько нужно купить, что залежалось, что в ремонте и утилизации и так далее — плюс финансовая аналитика.

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

Мы начали переход раньше, чем он стал неизбежным. Ещё в 2021 году собрали на 1С прототип для учета закупки, транспортировки и реализации нефти и проверили, справится ли платформа со сложным отраслевым контуром. Типовая 1С:ERP для этого не подходила. Чтобы сохранить привычные для пользователей процессы, её пришлось бы почти полностью переписать. Поэтому новую систему начали строить с нуля на БСП, а функциональность переносили из существующей ERP по частям. Ядро команды досконально знало первоначальную ERP и реализованные в ней бизнес-процессы, поэтому людям предложили переучиться. В итоге около 30 специалистов перешли на новую платформу, а недостающих экспертов добрали с рынка.

Мы сделали классную штуку. Сейчас пойдём и порвём рынок. Примерно так думала команда после нескольких лет работы, когда появился интерес у внешних компаний. Код ведь работает, есть первые пользователи, и остаётся «красиво» упаковать разработку. Но на практике быстро выяснилось, что работающий код ещё не продукт. Ему нужны оформленные права, дистрибутив, лицензирование, конкурентная цена, правила развития и поддержка. Пришлось меняться и самой команде. Люди, которые десять лет обсуждали задачи с одними и теми же внутренними заказчиками, теперь должны были показывать продукт незнакомым компаниям и не закапывать их в ГУ-12 (заявка для РЖД на перевозку).

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

Проблемы подготовки отчетности на основе данных, собранных от разных сотрудников, хорошо известны: длительные сроки, ошибки, высокая стоимость процессов и влияние человеческого фактора. Однако переход на новую систему часто вызывает сопротивление персонала: сложившиеся за годы схемы работы никто не хочет менять. А что, если сохранить привычный формат работы, но отказаться от ручной обработки файлов, сверок и бесконечных согласований? Именно такой подход мы реализовали в Smart Forms Pro. В этой статье вас ждет базовый разбор нашего нового решения: я расскажу об основных возможностях и покажу его интерфейс.

Когда сборка привязана к ПК и стационарному сканеру, сотрудник несёт найденный товар к рабочему месту, подтверждает его и снова идёт к полкам. Чем больше заказов, тем чаще повторяется этот маршрут. ТСД с приложением «Маркетплейс 15» переносит точку сканирования к товару: сотрудник за один обход подбирает позиции сразу для нескольких заказов, а у упаковочного стола распределяет их по заказам и печатает этикетки. Серверная часть продукта служит связующим слоем между Ozon, Wildberries, мобильным рабочим местом и «Честным знаком». Пятым подключаемым компонентом станет 1С.

В интерактивном демо можно переключиться между сборкой у стационарного ПК и подбором с ТСД, а затем сравнить длину маршрута. Та же разница показана на схеме ниже.

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

Ананас, ТУРБО, Jmix, Odoo, lsFusion и другие альтернативы: что предлагали, где обсуждались и что о них известно сейчас.

В октябре 2026 года на Хабре появилась статья «Как умрет 1С». Поводом стал эксперимент с переносом конфигураций на другую технологическую основу. На Мисте обсуждают реализацию: TypeScript, Bun, Vue и знакомые объекты метаданных.

Причем такие обсуждения идут давно. За все время существования 1С появились открытые учетные платформы, альтернативные ERP и инструменты разработки бизнес‑приложений на других языках. Одни прямо предлагают заменить 1С, другим роль «убийцы» присвоили участники форумов.

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

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

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

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

Мы написали свою CRM. Раньше от заявки до подписанного договора проходило около двух месяцев, теперь — около месяца: сделки закрываются примерно вдвое быстрее. Сильнее всего сократился первый отрезок: раньше КП уходило заказчику через 3–4 дня после заявки, теперь — на следующий день. Ниже — где на самом деле терялось время, что мы для этого сделали и на какие грабли наступили.

Большинство обменов 1С с внешними системами, которые мне приходилось поддерживать, устроены одинаково: в конфигурации или во внешней обработке лежит процедура на несколько сотен строк, которая разбирает JSON и заполняет документ. Работает она, пока никто не трогает ни источник, ни 1С.

Я попробовал описывать обмен не кодом, а данными, а настройку предлагать AI-помощнику: он получает задачу словами, пример сообщения и объект-образец из базы и собирает черновик, который проходит через человека. Разберу, что он получает на вход, что возвращает, где ошибается и как это ловится до записи в базу.

Продолжение серии «Автоматизация для новичков на примере малых предприятий»

В прошлой главе я спас «Непревзойдённую шаверму» от биологической опасности порождённой недочётом в WMS. Мы внедрили учёт партий, разобрались, почему FIFO — это не только про модемы, а FEFO лучше съесть пораньше...

Сегодня же мы поговорим о маржинальности и других важных терминах, знание которых спасёт вас от убытка в первый же год.

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

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

Станков девять, производители разные, возраст тоже. Я был уверен, что главная сложность будет в 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. Языковая модель помогла нам построить роботов и управление ими, но когда процесс был формализован, дальше вполне успешно работали обычные алгоритмы и сценарии.

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