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 систем.

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

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

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

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

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

Вообще в 1С ERP очень много проблем которые я знаю, но опишу я пока одну.

Автоматизация на пищевом предприятии давно перестала быть данью моде. Сегодня это базовое условие конкурентоспособности: ERP-системы, MES-решения, датчики на линиях и интеграция с «Честным Знаком» стоят почти у всех. Но вот парадокс: у одних компаний после внедрения кривая прибыли уверенно ползет вверх, а у других — растут только расходы на IT-инфраструктуру.

По данным аналитики за 2025 год, около 60% предприятий пищевой отрасли не добились заявленного возврата инвестиций (ROI) от цифровизации, а четверть и вовсе зафиксировали рост издержек. Причина кроется не в программном обеспечении. Главная проблема — отсутствие управленческой зрелости. Это неспособность менеджмента корректно интерпретировать данные, принимать на их основе решения и оперативно перестраивать процессы.

Международный стандарт интеграции управления производством ISA-95 наглядно это подтверждает: автоматизация без выстроенной архитектуры уровней управления и без культуры анализа превращается в центр затрат, а не в драйвер роста.

Эволюция управления: от тушения пожаров к стратегии

Управленческая зрелость не появляется по щелчку мыши в день запуска новой системы. Это процесс системного взросления команды. От реактивного латания дыр завод должен перейти к осознанному планированию.

Логика развития управленческого контура выглядит так:

На производстве это повторяется слишком часто.

1С:ERP уже есть.

Заказы в системе есть.

Нормативы есть.

Остатки, графики, ресурсы - тоже.

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

То есть учетный контур в системе уже живет, а оперативное планирование — еще нет. И это как раз тот сценарий, который описан в материалах к вебинару: типового планирования в 1С:ERP часто недостаточно для сложного производства, а Excel остается “рабочим костылем” там, где нужно быстро перепланировать реальную ситуацию…

Поддержка УПП официально превращается в тыкву. В 2026 году последние обновления, а к 2027 — привет, каменный век. Ваша учетная система — это старая «Волга»: вроде едет, но если сломается на трассе, запчастей уже не найти. Рассказываем, как спрыгнуть с уходящего поезда и не убить при этом команду и бюджет.

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

Остаться на УПП после прекращения поддержки — это не хардкор, это глупость. Давайте разбираться, как переползти на ERP без боли, потери данных и демотивации бухгалтерии.

Через пять месяцев электронные перевозочные документы станут обязательными для всех участников грузоперевозок в России. Штрафы доходят до 3% годовой выручки. Но настоящая проблема не в штрафах. Она в том, что у большинства компаний транспортная логистика устроена так, что подключать ЭПД физически не к чему.

По данным ComNews, специализированные TMS-системы используют только 28% российских компаний. Остальные 72% работают в Excel, на самописном ПО или в учётных системах с минимальной автоматизацией. По нашим наблюдениям за клиентами, приходящими на внедрение, структура этих 72% выглядит примерно так: около 30% управляют перевозками в Excel, ещё 30% — на самописных решениях, 40% используют учётные системы с минимальным функционалом автоматизации транспортной логистики. И вот в эту конструкцию нужно «просто подключить ЭПД».

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

Существует множество литературных источников, досконально описывающих процесс программной разработки, а также имплементирования и поддержки реализованного решения [1-3]. Это неспроста. Ведение разработки программного обеспечения – это кропотливый и долгий процесс, требующий от человека глубоких технических знаний. Изменение требований к приложению чаще всего приводит к переписыванию программного кода. Как результат доступность программистов на рынке труда стала дефицитной, а их стоимость довольно высокой. Стараясь нивелировать высокую стоимость человеческих ресурсов, были разработаны No-code платформы, позволяющие реализовать программные приложения за считанные минуты даже не технических специалистам.

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

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

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

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

Данные примеры затрагивают вопрос понимания потребностей и способов их реализации, чем занимается дисциплина под названием бизнес-анализ. Ключевым источником информации по данному вопросу является свод знаний по бизнес-анализу или BABoK [1], не так часто освещаемый в литературных источниках. Следуя PMBoK, SWEBoK, BPMCBoK, TOGAF и другим сводам знаний [2-5], BABoK может быть применен в проектах разработки и внедрения программных систем.

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

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

В предыдущих публикациях было описано, как использовать функциональность FEB_FILE_HANDLING как единую точку входа для импорта банковских выписок в SAP, независимо от каналов получения выписок (прямые каналы связи с банковскими системами или выгрузка файлов из систем «Банк‑клиент») и используемых форматов (XML или текстовые форматы). При этом рассматривалась только обработка итоговых банковских выписок.

Ссылки на предыдущие публикации:

Всем привет! Меня зовут Дмитрий Воронцов и я хочу кратко рассказать о своей новой low-code платформе NodaLogic, построении решений с помощью узлов(нодов) и свое видение будущего. Я автор мобильного фреймворка SimpleUI которому скоро исполняется 7 лет и в этой статье будут некоторые пересечения с ним – я хочу рассказать, зачем я сделал отдельную архитектуру, а не стал продолжать SimpleUI.

7 лет назад, когда я начинал Simple я хотел сделать LowCode фреймворк на котором разработчик может быстро разработать мобильное решение, как дополнение к своей учетной системе. Тогда еще не было LLM.  Но ориентиры во все времена одинаковые – чтобы решение было легко поддерживать и развивать, масштабировать – оно должно быть простым, компактным, читаемым. Объем кода может быть и не точный показатель, но когда на один и тот же функционал требуется в 10 (а то и в 100) раз больше/меньше строчек это сигнал. Этот ориентир у меня остался и для новой системы, как важнейший. Ведь не важно, что теперь разработчику не нужно писать, но ему нужно «читать решение», анализировать что ему нагенерила  нейросеть, чтобы направлять ее. И понятно, что можно взять любой стек и язык программирования и сгенерировать решение на нем, но будет ли при этом достигнут тот уровень простоты и читаемости как в LowCode фреймворке?

Платформа позволяет делать клиент-серверные решения с мобильными самостоятельными оффлайн/онлайн фронтами-приложениями (Android) веб-клиентами и серверами. Естественно, единая семантика на веб и на мобильную платформу. Также можно делать и чисто мобильные фронты, мобильные приложения без сервера.  

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

Доступен ряд научно-популярных работ, описывающих различные подходы к построению ИТ-архитектуры, которые обобщены в терминах корпоративная архитектура и архитектура предприятия. Методологии построения корпоративной архитектуры представлены такими подходами как: FEAF, DoDAF [1], а также широко известная и наиболее популярная TOGAF [2]. Несмотря на кажущееся обилие стратегий к формированию ИТ-архитектуры, по большому счету, они апеллируют едиными сущностями, изначально предложенными в модели Захмана.

Не взирая на то, что модель Захмана предоставляет широкий теоретический аппарат, который лежит в основе понимания любой архитектуры предприятия, ее использование как в контексте разработки, так и непосредственно в ходе имплементации корпоративного ПО, часто остается незамеченным [3]. Однако применение именно данной модели делает методологии внедрения ИС такими, какие они есть сейчас: структурированными и гибкими, генерализованными и специализированными, а также прозрачными и эффективными.

Цель текущей работы состоит в анализе модели Захмана и ее применимости в проектах реализации корпоративных информационных систем. Достижение сформулированной цели потребует решения следующих задач: