ERP-системы *

Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки 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]. Однако применение именно данной модели делает методологии внедрения ИС такими, какие они есть сейчас: структурированными и гибкими, генерализованными и специализированными, а также прозрачными и эффективными.

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

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

Меня зовут Герман, я 8 лет занимаюсь B2B‑продуктами и сложными производственными системами.

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

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

Рынок медицинских услуг в России продолжает расти как на дрожжах. По данным аналитиков, в 2025-2026 годах мы наблюдаем устойчивый рост частной медицины на 12-15% ежегодно. Вслед за этим бумом неизбежно следует лавинообразный рост предложений IT-услуг. Кажется, что для каждой, даже самой узкой задачи, существует отдельное SaaS-решение: агрегаторы записи, ORM-системы для сбора отзывов, CRM для колл-центра, ERP для склада, МИС для врачей... Список можно продолжать бесконечно.

Добавьте сюда ужесточение контроля со стороны государства (ЕГИСЗ, РЭМД, маркировка, ЭДО, новые приказы Минздрава), и вы получите идеальный шторм.

Я занимаюсь автоматизацией бизнесов и IT-консалтингом в медицине уже много лет. Недавно мне довелось сравнить, как выглядит IT-ландшафт стоматологии в 2018 году и многопрофильной клиники в 2026-м. И знаете что? Картина, за редким исключением, абсолютно идентична. Разве что зоопарк стал больше, а сотрудники в регистратуре матерятся громче.

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

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

Бывает и по-другому: настройки выглядят вполне корректно, но на самом деле содержат скрытые проблемы, проявляющиеся по мере эксплуатации.

Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты.

Я участвовал в разработке этой системы и покажу, как она работает на реальных примерах.

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

На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.

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