ERP-системы *

Не только лишь Mistral

Что первое приходит вам в голову, когда вы слышите фразу «европейские LLM»? Опытный читатель наверняка вспомнит про французскую Mistral и... в целом, на этом всё.

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

История других отраслей показывает, что происходит дальше. До Uber цену поездки знал только таксист, и пассажир зависел от его решения. Как только маршрут и стоимость стали видны на экране, преимущество водителя исчезло. Booking сделал прозрачными цены на отели, маркетплейсы - на товары, Google Maps - на логистику. Строительство пока остаётся одним из немногих крупных рынков, устроенных «как такси до Uber»: полной картиной по стоимости и срокам владеет только одна сторона, а вторая оплачивает эту асимметрию перерасходами.

Дальше в статье - нидерландский строительный картель с двойной бухгалтерией и 1300 оштрафованных фирм; алгоритмы, которые находят следы сговора прямо в цифрах торгов; два миллиарда долларов SoftBank, сгоревшие в «кнопке Uber для стройки»; и рынок жилья, который свою уберизацию уже прошёл. Через историю и паттерны видно, какими будут инструменты уберизации строительной отрасли в следующие десятилетия.

Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки  различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.

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

Это 2 часть материала про переход, 1 часть про самые распространенные заблуждения и ошибочные представления о системе 1С:ERP в статье https://habr.com/ru/companies/infostart/articles/1051952/

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

В июньскую подборку Маркетплейса Инфостарта вошли решения для задач, которые регулярно возникают при сопровождении 1С: поиск дублей, массовая замена данных, загрузка Excel и CSV, интеграция с внешней площадкой и автоматизация производственных расчетов.

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

Без сервисной системы не построить качественную техподдержку — это база. Но в промышленных компаниях обслуживание выходит далеко за рамки ИТ. Требуются ли в этом случае дополнительные системы? Не обязательно — и это доказывают пять крупных производственных компаний от Росводоканала до Щербинского лифтостроительного завода. 

Какие результаты они получили и как именно применяют service desk в промышленности — разбираем в статье.

Выгрузил железо из 1С, рядом положил список из ITAM — цифры разные. Полдня искал, кто накосячил, и не нашёл: косячить некому. 1С и ITAM и не должны сходиться — они про разное. Одна считает деньги, другая — что реально стоит и работает. Рассказываю, как перестал сверять их руками и развёл раз и навсегда.

"Если вашего бизнеса нет в Интернете, то вас нет в бизнесе! Скоро на рынке останется два вида компаний: те, кто в Интернете и те, кто вышел из бизнеса." 

А потом вдруг интернета не стало и нужно было срочно что-то придумать для работы нашей ERP-системы оффлайн

Привет, Хабр! Мы — Владимир, Дмитрий и Константин — команда из логистики в торговой сети «Монетка» («Группа Лента»). Мы управляем процессами в одной из крупнейших розничных сетей в России, и у нас — 4+ тысячи магазинов, 40+ тысяч сотрудников и миллионы коробок товара, которые каждый день нужно отгружать со складов 24/7. А выходной – только один день в году, 1 января.

Детская футбольная школа имеет базу данных детей и их родителей, в которой более 7000 уникальных записей. На данный момент посещаемость, продление абонементов и напоминания об оплате происходять в ручном режиме через ERP‑систему.

Проблема: Администраторы тратят много времени на проверку платежей и ручную рассылку с напоминаниями об оплате родителям. Из‑за различных причин часть родителей не оплачивают абонемент на следующий месяц вовремя, что существенно снижает выручку школы.

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта:

Чтобы автоматизировать процесс и защитить систему от некорректных данных, в наешй работе — это попытки записать ребенка в группу, не соответствующую его возрасту, логика интеграции должна быть строго регламентирована. Валидация данных выполняется на стороне ERP‑системы до того, как транзакция попадет в базу данных.

Схема взаимодействия систем / UML Sequence Diagram

Многие российские компании привыкли к 1С:УПП (Управление производственным предприятием) и активно ее использовали. Но весной 2026 года разработчики прекращают поддержку этой программы. Это значит, что больше не будет ни обновлений, ни исправлений багов, ни технической помощи от создателей.

В I квартале 2027 г. вендор не будет выпускать обновления 1С:УПП кроме тех, которые потребуются для сдачи отчетности за 2026 г. Законодательные изменения, которые вступят в силу с января 2027 г., поддерживаться в УПП не будут. С 1 апреля вендор приостановит любые консультации по конфигурации (письмо 1С №30064 от 09.12.2022).

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

Так получилось, что я родился скромным Goфером и год назад начал работу над самописной ERP-подобной учётной системой для микробизнеса РФ…

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

Именно поэтому принцип GIGO — garbage in, garbage out, «мусор на входе — мусор на выходе» — в логистике звучит особенно буквально. Если в мастер-данные попал неверный габарит товара, WMS не начнёт спорить с пользователем. Она просто будет добросовестно рассчитывать всё дальше на основе неправильной цифровой модели.

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

EAM — это цифровая нервная система производства: она связывает гайку в цеху с бухгалтерским балансом. Ещё несколько лет назад этот рынок в России держали SAP, IBM Maximo и Infor EAM — на них строились процессы крупнейших заводов и энергохолдингов. Когда вендоры ушли, выяснилось, что «просто заменить» такую систему невозможно.

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

Именно поэтому рынок постепенно уходит от идеи универсальной «системы ремонтов» к отраслевым и преднастроенным EAM-контурам. Для бизнеса это уже не вопрос удобства интерфейса или количества модулей. Гораздо важнее, насколько точно система понимает модель активов предприятия, умеет работать с техническим состоянием, ремонтной логистикой, мобильными бригадами, МТО и обязательными процедурами.

В статье для журнала Connect WIT ведущие специалисты Инфостарта - руководитель отдела корпоративных решений Станислав Субботин, корпоративный архитектор Дмитрий Исаев и руководитель проектного офиса Александр Пищальников - разбирают, где именно проявляется отраслевая специфика EAM и почему преднастроенные решения становятся привлекательнее для сложных производственных и инфраструктурных предприятий...

Как мы превратили «исторические данные» в проактивные управленческие решения.

Этот выпуск о том, почему самые опасные бизнес-риски часто уже есть в ваших данных — просто никто их не видит.

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

Но через несколько лет после внедрения компания начинает сталкиваться с проблемами. Ассортимент увеличивается с сотен до тысяч позиций. Появляются разные схемы комплектации. Растет количество сотрудников и техники. Склад начинает работать в несколько смен. В учетной системе появляются новые доработки, которые должны решить очередную операционную задачу.

И тут уже большинство изменений в ERP связаны не с учетом, а с попытками управлять физическими процессами на складе.

Возникает вопрос: стоит ли и дальше развивать складской модуль ERP или мы уперлись в потолок и пора переходить в специализированную систему управления складом?

Перезалив. Хабр в очередной раз посчитал две ссылки на рабочий прототип рекламным объявлением - спасибо! Удалены все ссылки на продукт, за исключением исходников на githubе. Приятного чтения.

Зачем предприятия ведут учёт? Отчётность перед ФНС? Или может воронка клиентов? Сотни ответов российского рынка учётных систем на этот простой вопрос.

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

Год назад я невольно стал заложником терзающих мой разум раздумий о смысле учётных систем. Так был написан первый, второй… пятый модуль мультитенантной ERP-подобной системы для малого бизнеса (Go + pgx | Next.js + TS), вопреки рынку ставящей именно модуль финансов в центр системы.

В прошлых статьях мы разобрали, что такое цифровой двойник предприятия, а также механизм управления изменениями. Определили, как выстроить процесс изменения, чтобы изменения не привели к хаосу в ЦДП (Цифровом двойнике предприятия). Разобрали, что такое Задание на разработку, Релизный контейнер, Проект, и определили процессы для этих документов. Теперь приступим к рассмотрению того, каким образом необходимо реализовывать изменения в ЦДП.