ERP-системы *

В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.

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

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

По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?

Я всё больше думаю, что это неправильный вопрос.

Бизнес должен иметь последнее слово в вопросах «зачем» и «что»: какую проблему решать, какого эффекта добиваться, чем пожертвовать и какие изменения считать приоритетными. ИТ отвечает за «как»: архитектуру, данные, технологические ограничения, интеграции и жизнеспособность будущего решения.

Склад может работать «в плюс» по всем видимым статьям — и при этом системно терять рентабельность. Не из-за ошибок персонала и не из-за дорогой аренды, а из-за структуры ассортимента.

Возьмём типичный пример: неликвидные позиции на складе оценены в 5 млн рублей. При обычной для рынка стоимости хранения запаса 20–30% в год, только за то, что эти позиции занимают место и держат замороженный капитал, склад теряет от 1 до 1,5 млн рублей ежегодно. Через 3–4 года такого хранения суммарные затраты превышают закупочную цену товара. Дальше держать — терять деньги наверняка, продать — терять деньги один раз.

Эта статья — о том, как увидеть эту математику в данных WMS и принять решение раньше, чем она окончательно съест маржу.

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

Полтора часа на десятерых — пятнадцать человеко-часов. Само исправление занимает полчаса работы аналитика с разработчиком.

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

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

Проект к этому моменту шёл третий год.

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

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

О том, как я это сделал и какие возможности получила моя система, — в этой статье.

Не только лишь 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 и почему преднастроенные решения становятся привлекательнее для сложных производственных и инфраструктурных предприятий...