ERP-системы *

Внедрение связанных между собой бизнес-решений чревато тем, что любое изменение — новый метод продаж, продукт или процесс — превращается в хаос.  Традиционный подход «начнём с системы» ведёт в тупик точечных доработок и несогласованности. Выход — цифровой двойник предприятия, но не как красивая 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С.

Загнивая от усталости, дописывая последнюю строчку последнего (или не очень) модуля системы, теша себя мыслями о скорой зарплате, каждый уважающий себя философ задаётся вопросом - а как контролировать в бою всё то, что мы написали¿¿

Глупец скажет - никак, мы же покрыли тестами.

Хитрец скажет - Grafana+Prometheus отдельными сервисами.

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

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

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

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

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

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

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

Внедрили MES, а производство как работало, так и работает? Интегратор обещал прозрачность, а руководство предприятия получило гору отписок в духе «некогда сканировать»? Разбираемся, что с этим делать.

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

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

Можно попытаться разобраться в крайностях реинжиниринга, используя свод знаний по корпоративной архитектуре, представленный методологией TOGAF [2], который говорит о том, что во главе всего должна стоять прежде всего бизнес-архитектура. Именно через ее призму необходимо рассматривать все происходящее в компании и ИТ-архитектуре, в частности. Более детальное погружение в тематику бизнес-процессов обратит нас к набору знаний BPM CBoK [3].

Текущие сложности в экономике напрямую отражаются на повседневной деятельности предприятий агропромышленного комплекса. Дорожает топливо, удобрения, корма и средства защиты растений, сохраняется высокая стоимость техники, а результаты принятых решений можно оценить лишь спустя месяцы из-за длинного производственного цикла и зависимости от погодных условий.

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

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

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

Команда аналитического проекта SaaS Rating представила ежегодный рейтинг крупнейших SaaS-компаний России по итогам 2025 года. Исследование подготовлено под руководством Аскара Рахимбердиева, сооснователя и генерального директора ERP-сервиса МойСклад.

Рейтинг SaaS-компаний формируется на основе выручки от B2B SaaS-продуктов в России и включает компании с годовой выручкой от 200 млн рублей. При определении SaaS используется международный стандарт NIST: сервис должен соответствовать ключевым характеристикам облачной модели — on-demand self-service, доступ через сеть, масштабируемость, объединение ресурсов и оплата по мере использования.

Когда в третий раз за год реализуешь интеграцию ERP с внешней системой и ловишь себя на мысли «мы это уже делали», возникает закономерный вопрос: почему каждый проект на платформе 1С до сих пор начинается почти с нуля? В какой момент все согласились, что интеграции, миграция, нормативно-справочная информация и контроль доступа — это обязательно кастом? Мы решили, что изобретать велосипед каждый раз крайне неэффективно, и попробовали изменить сам подход.

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

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

На этой неделе на Бирже заказов заметно, что бизнесу по-прежнему нужны практические задачи: синхронизация между системами, настройка ЭДО и маркировки, доработка типовых конфигураций, работа с учетом, отчетностью и обменами. Есть и точечные консультации, и задачи под полноценную разработку или сопровождение.

Ниже — подборка заказов, опубликованных с 22 по 28 апреля....

Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70.

Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).

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

Раньше все было иначе. Изначально данные рассматривались как составной, но обязательный элемент компьютерной программы, наряду с командами и алгоритмами. Постепенный функциональный рост софтверных программ от приложения до программного обеспечения, программной системы, информационной системы и корпоративной информационной системы менял взгляд на данные. Уходя от рассмотрения данных только лишь в контексте нормализации данных и СУБД, акцент последовательно перешел к вопросам миграции данных, поддержания их качества и, наконец, бизнес‑процессу управления данными.

Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки ERP домена и требует особо пристальной реализации. Это особенно применимо для коммерческих систем (коей и является Kroncl - название системы), в которых классический RBAC требует определённых доработок, включающих адаптацию к упрощённой features-based access control (в народе - FBAC, является своего рода реализацией ABAC). Кроме того, технологические компании крайне редко (уникальные случаи всё же есть) посвящают публичные статьи внутреннему устройству своих систем тарификации, что крайне печально, ведь это буквально могли быть рассказы о том, как архитектурные решения напрямую влияют на маркетинг и как следствие доходность компании.

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

Привет, Хабр! В условиях импортозамещения и ухода западных вендоров перед крупными холдингами остро встает вопрос быстрой замены тяжелых корпоративных систем продуктами из линейки 1С. Один из самых болезненных участков бизнеса — трансформация и консолидация МСФО/УУ отчетности. Исторически сложилось, что связка 1С (оперативный учет) → Excel → SAP BW → Excel → МСФО была стандартом для многих крупных компаний.

Мы, команда практиков внедрения 1С, хотим поделиться опытом, как заменить SAP.BW в контуре подготовки МСФО и управленческой отчетности на 1С:Управление холдингом (1С:УХ) в кратчайшие сроки (за 3-5 месяцев работающая базовая версия продукта). Кейс основан на реальном проекте для крупнейшего частного оператора ЖКХ (~30 юр. лиц, ~12 000 сотрудников, 7,2 млн абонентов). Главное требование было: «Реализовать гибкость SAP.BW, но быстрее и без Excel-ада».

Автор прекрасно понимает, что тема ERP/CRM систем обсосана со всех сторон ещё десятилетие назад. Огромное количество разработчиков и по сей день зарабатывают на внедрении систем на подобии 1C:ERP в предприятия. Однако поспешу обрадовать читателя, сегодня я попытаюсь описать процесс создания своего рода аналога такой системы на довольно необычном для этой сферы стеке и углубиться в тонкости её устройства.

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