ERP-системы *

Многие российские компании привыкли к 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), вопреки рынку ставящей именно модуль финансов в центр системы.

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

Ошибочным будет пытаться рассмотреть разработку программного обеспечения с момента его реализации и внедрения. В литературных источниках по этому поводу говорится, что жизненный цикл программной системы начинается с момента понимания необходимости в ней и завершается ее заменой на аналогичные или более новые образцы [1-2]. Более того, проекту имплементации предшествуют активности предпроекта, включающие бизнес-кейс, проведение тендера и, наконец, заключение договора на внедрение, а завершается все задачами поддержки имплементированного решения и прекращением его применения.

Анализ программного продукта через призму его жизненного цикла позволяет увязать бизнес-потребности организации и технические возможности их воплощения [3-4]. В проектах разработки высокосложного программного обеспечения жизненный цикл рассматривается с точки зрения репетиций внедрения, что позволяет понизить риск неуспешного продуктивного запуска. При этом вопросам построения масштабируемой, гибкой и отвечающей запросам бизнес-пользователей корпоративной ИТ-архитектуре в классических проектах имплементации программных систем уделяется меньшее внимание.

Отдельное научное направление, отличающееся по содержанию от типовых подходов к разработке и внедрению программного обеспечения и обращающее должное внимание к ИТ-архитектуре, формализовалось в методологии TOGAF [5]. Жизненный цикл программного продукта с точки зрения принципов TOGAF сопровождается непрерывной и устойчивой взаимосвязью между бизнесом, разработкой приложений и ИТ-архитектурой для их развития, что является существенным преимуществом в конкурентной борьбе.

Ограничения ППР и почему переход к прогнозной модели становится необходимым

Планово-предупредительные ремонты (ППР) — стандарт для большинства промышленных предприятий. Логика проста: замена узлов или материалов через фиксированный интервал времени или наработки. Однако на практике этот подход всё чаще приводит к трём проблемам:

Привет, Хабр!

Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud. В этой статье расскажу, зачем мы интегрировали MCP в собственный продукт, как определяли сценарии для внедрения и что из этого получилось.

Внедрение связанных между собой бизнес-решений чревато тем, что любое изменение — новый метод продаж, продукт или процесс — превращается в хаос.  Традиционный подход «начнём с системы» ведёт в тупик точечных доработок и несогласованности. Выход — цифровой двойник предприятия, но не как красивая 3D-модель, а как механизм управления изменениями. В предыдущей статье мы рассмотрели, как управлять изменениями в одном ИТ-ландшафте, а если их несколько? Сейчас познакомимся с тем, как синхронизировать миры бизнес-процессов и ИТ-ландшафта, чтобы эволюция компании стала управляемой, а не хаотичной.

Привет, это Илья, технический директор 2PEOPLE IT. Иногда бизнесу хватает готовой CRM, таблиц и пары интеграций. Но со временем процессы усложняются: данные живут в разных местах, отчеты собираются руками, сотрудники обходят систему через Excel и чаты.

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

Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.

Как с помощью Clean ABAP и Low‑code ускорить выгрузки в 5 раз

Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес‑цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.

Внедрение корпоративных информационных систем ведется по определенным правилам, есть три классические модели имплементации: каскадная, итерационная и спиралевидная. Также доступно множество прикладных методологий внедрения, представленных ASAP, Activate SAP, OUM, MDSS, ADM и расширяющих классические модели. Принимая во внимание то, что ERP-системы представимы коробочными программными продуктами, их имплементация преимущественно ведется на основе каскадно-ориентированных методов и с использованием знаний PMBoK [1].

PMBoK один из наиболее узнаваемых и популярных сводов знаний для менеджмента всевозможных проектов, в том числе в области ИТ. Однако существуют и другие области знаний, относящиеся к ИТ: BABoK, EABoK, BPM CBoK, а также SWEBoK [2-5]. SWEBoK как свод знаний программной инженерии, наиболее близко соотносится с тематикой проектирования и имплементации корпоративных информационных систем, представленных комплексным платформенным программным обеспечением.

Несмотря на очевидную близость к ERP-системам, SWEBoK не так знаком читателям как PMBoK или BABoK. Действительно ли применение SWEBoK дает преимущества работе над комплексным программным продуктом? С данным вопросом мы разберемся в содержании текущей статьи. Цель работы состоит в анализе методологии SWEBoK для повышения качества разрабатываемого и внедряемого программного продукта. Для решения данной цели необходимо:

Обычно те, кто выбирает направление разработки в IT, идут учить Python, Java или JavaScript. 1С в этот список не попадает: платформа и профессия, связанные с ней, часто воспринимаются менее «модными», хотя по сложности и масштабу задач это не всегда справедливо.

Но в 2026 году есть несколько обстоятельств, которые влияют на восприятие 1С. На российском рынке у 1С очень сильные позиции, особенно в учёте и ERP (Enterprise Resource Planning — система планирования ресурсов предприятия). Зарплаты 1С-специалистов в 2025–2026 годах заметно выросли, а на уровнях мидл и сеньор они стали сопоставимы с доходами в других популярных IT-направлениях. 

В этой статье мы делаем честный обзор того, как сегодня обстоят дела в 1С-разработке, какие преимущества и недостатки есть у этого направления и стоит ли учиться на программиста 1С.

Перечитал две страницы материалов по ценностному предложению на Хабр и понял, что мне есть, что сказать основываясь на реальной практике

Сейчас на дворе 2026 год и на рынке поменялся фильтр с которым клиент смотрит на ваш продукт. Покупают то, что уменьшит потери, ускорит процесс или даст измеримый эффект в деньгах. 

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

В этой статье — про то, как устроено ценностное предложение, которое выдерживает этот вопрос с живым примером из практики.

Олег Линьков, Webformula-Agro

Компания с оборотом 300 млн рублей, хорошим продуктом и конкурентной ценой не попадает в шорт-лист крупного агрохолдинга. Причина — несоответствие адреса в ЕГРЮЛ и на сайте. Для алгоритма скоринга это «красный флаг». Для закупщика — достаточный повод не продолжать.