В российской ERP-повестке за последние несколько дней почти одновременно сошлись несколько показательных сюжетов.
Недавно Сбер рассказал, что готовит к выводу на рынок собственную ERP-платформу SberERP — внутри банка она создается как замена прежнему контуру на базе SAP, но важная деталь здесь не только в уходе от западной системы. Финансовый директор Сбербанка Тарас Скворцов фактически описал старую систему как «СберСАП»: SAP использовался как технологическая платформа, а значительная часть логики была собственной разработкой банка. Поэтому даже переход на новую версию системы означал бы не обновление, а переписывание большого корпоративного слоя заново.
Почти в то же время «Ростелеком» описал свой подход к переходу с крупного зарубежного ERP-контура на решения «Галактики». Заместитель президента — председателя правления компании Дарий Халитов сформулировал мысль, которая хорошо объясняет состояние рынка: для большого заказчика сильной разницы между российскими ERP-платформами может и не быть, потому что все равно потребуется глубокая кастомизация под собственные процессы. По его оценке, в крупной компании речь может идти примерно о 80% кастомизации.
Рядом в той же повестке появилась и «Почта России»: по сообщениям TAdviser, компания подключила «Галактику» к импортозамещению Microsoft Axapta и IBM Cognos.
Получается некая цепочка сигналов: банки, телеком, логистика и крупные распределенные компании пересматривают системы, через которые проходят финансы, закупки, склад, HR, отчетность и управленческие данные.
Еще несколько лет назад это все можно было легко упаковать в простую формулу: западные ERP уходят, российские решения приходят им на замену. Теперь этого объяснения уже недостаточно. Крупные компании выясняют, что заменить нужно не только продукт и не только поставщика. Старые ERP-контуры давно стали частью внутренней архитектуры бизнеса — с доработками, отчетами, справочниками, интеграциями и правилами, которые годами собирались вокруг конкретной компании.
Поэтому вопрос «какую российскую ERP выбрать» оказывается только верхним слоем. Глубже лежит другой: что делать со старым корпоративным порядком, который держался на прежней системе.
🟡 В этой статье Уточка не будет выбирать победителя среди российских ERP-решений. Ей интереснее объяснить момент, когда в проекте открывают старую систему и понимают: вместе с ней придется разбирать не только настройки и доработки, но и многолетнюю память компании.
Что компании на самом деле меняют вместе с ERP
В слове «замена» есть подвох: оно делает ERP-переход похожим на техническую операцию. У компании была одна система, теперь будет другая: старую отключили, новую включили, данные перенесли, пользователей обучили. Но в случае с ERP все немного сложнее.
За годы ERP становится способом договориться о реальности внутри компании. Не в красивом теоретическом смысле, а в самом прикладном: какая операция считается завершенной, какие данные можно брать в отчет, кто имеет право исправить ошибку, где проходит граница между учетным фактом и управленческой оценкой. В регламентах это обычно выглядит аккуратнее, чем в жизни, которая часто добавляет свое: срочные доработки, временные исключения, ручные проверки, внутренние отчеты, обходные сценарии. Часть из них действительно спасает процесс. Часть давно потеряла смысл, но уже успела стать привычной.
Поэтому ERP-переход редко начинается с простой на первый взгляд задачи «перенести функциональность». Старая система приносит с собой накопленный слой решений, которые когда-то помогали компании работать. Этот слой нельзя переносить механически: если делать это полностью, новая платформа унаследует не только полезную специфику, но и старые слабости. Но и полный отказ от старой логики рискован: часть этих правил действительно поддерживает ежедневную работу.
Как раз здесь и появляется настоящая управленческая работа. Нужно понять, где перед компанией действительно особенность бизнеса, а где след прежних ограничений. Что должно стать правилом новой системы, а что лучше оставить в прошлом контуре. Какие доработки оправданы, а какие просто продолжают жизнь старого беспорядка под новым названием.
Именно поэтому разговор о российской ERP быстро выходит за рамки выбора платформы. Система может быть отечественной, современной, модульной, с поддержкой ИИ и low-code. Но она не отменяет вопрос, который компания должна задать себе сама: какую версию собственного порядка она переносит в будущее.
LAB Industries: когда одна ERP должна собрать несколько разных бизнесов
Кейс LAB Industries интересен тем, что показывает не очередной проект перехода на 1С, а то, что вообще скрывается за словом «ERP» в производственной компании.
Формально заказчик один — ООО «ЛАБ Индастриз», но внутри этого контура находились 11 обособленных подразделений, около 1200 пользователей и 3 разных направления бизнеса: косметика, чистящие и моющие средства, клеевые продукты. Причем у каждого направления была своя производственная и складская логика: где-то один завод и 3PL-склад, где-то несколько площадок и отдельная WMS, а клеевое направление дополнительно усложнялось разной природой продукции — от бытовых клеев до сухих строительных смесей и промышленных составов.
За проектом стоял не перенос учета из одной системы в другую, а попытка собрать в одном управляемом контуре несколько разных способов производства, хранения и отгрузки.
Проект начался в конце 2022 года, когда LAB Industries приняла решение перейти на российское решение — 1С — из-за рисков, связанных с использованием импортной информационной системы. Сначала нужно было провести предпроектное обследование ключевых бизнес-процессов, затем запустить MVP с 1 января 2023 года, а уже с 1 января 2024-го расширить функциональность и вывести систему в промышленную эксплуатацию на всех участках. Параллельно 5 распределительных центров переводились на 1С:WMS.
Эта последовательность очень важна. Запуск ERP — не единомоментное событие, а поэтапный ввод в работу разных контуров системы: один контур нужен, чтобы компания могла отражать хозяйственные операции и выполнять требования законодательства; второй — чтобы склады, производство, лаборатория, финансы и управленческий учет начали работать как связанная система. У LAB Industries использовались 1С:Корпорация, 1С:WMS и 1С:LIMS — то есть рядом с ERP сразу появились складская логистика и лабораторный контроль качества сырья и готовой продукции.
Масштаб проекта хорошо передает объем формализованных требований: их было больше 2000. Еще важнее, что свыше 800 из них частично или полностью не закрывались типовым функционалом, что однако не стоит рассматривать как проблему. Скорее это нормальная картина для крупной производственной компании, где за одним процессом в описании скрываются десятки правил в реальной работе.
🟡 Уточка бы сказала, что 2000 требований — это не «много хотелок», а момент, когда устное знание производства наконец превращается в язык системы: что можно, что нельзя, при каких условиях и кто за это отвечает.
Например, складская логистика в таком проекте — это не только приемка, размещение и отгрузка. В доработках по 1С:WMS описаны SSCC-этикетки на готовую продукцию, приемка из производства по номеру SSCC, упаковочные листы на паллеты, блокировка ячеек на время пересчета, ручные перемещения между зонами склада и подбор ячеек с учетом ограничений вроде класса опасности. Система должна была работать не с абстрактным «товаром на складе», а с движением паллеты, партии, ячейки и отгрузочного заказа.
🟡 Для Уточки здесь важна простая вещь: две одинаковые коробки в ERP могут быть совсем не одинаковыми. У них разная партия, срок, статус качества, место хранения или клиентское ограничение — и система должна это различать без подсказки человека.
Отдельный слой — срок годности. В проекте нужно было учитывать минимальный остаточный срок годности в разрезе клиента и конкретной номенклатуры или группы номенклатуры. Причем правило по номенклатуре имело приоритет над общим правилом по клиенту. За этим нюансом стоит целая цепочка: коммерческие условия, качество, складской подбор, планирование отгрузки и финансовые последствия, если клиент получит продукцию с неподходящим сроком.
В старой системе такие правила могли быть частью привычной логики. В новой их пришлось описывать явно: где хранится ограничение, какая система его проверяет, что делать при конфликте правил.
Не менее показателен блок продаж. Там дорабатывали скидки и наценки, EDI-обмен, автоматическое формирование документов, резервирование и обеспечение заказов, перераспределение запасов по приоритетам связки «клиент — завод», механизм аналогов и замену номенклатуры с учетом приоритета клиента. Согласитесь, это уже не уровень «есть модуль продаж», а отдельная управленческая логика: кому отгружать первым, чем можно заменить товар, какие условия применяются к конкретному клиенту, как это отразится в документах и финансах.
Через производство и качество видно то же самое. Система должна была интегрироваться с маркировкой и печатью этикеток на линии, планировать выпуск по линиям и времени, учитывать результаты входного контроля. Если материал не прошел контроль, дальнейшие действия с ним блокировались. Менялся статус качества: блокировка, перевод на контроль, возврат в свободный сток. Для производственной компании это не «дополнительная функция», а правило допуска материала к дальнейшему движению. Ошибка здесь быстро переходит из лаборатории в производство, склад и отгрузку.
Еще один важный слой — НСИ. В проекте разрабатывали статусную модель номенклатуры для разных заводов и складов: запрет на продажу, запрет на производство, разрешение закупать и другие проверки в зависимости от статуса, завода и операции.
🟡 НСИ обычно выглядит как тихий технический участок проекта. Но именно там, по мнению Уточки, часто спрятаны управленческие решения: что компания разрешает покупать, производить, продавать или блокировать. Ошибка в справочнике позже всплывает в закупках, на складе или при отгрузке.
Поэтому LAB Industries здесь интересна не фактом перехода на 1С, а тем, какой объем старой операционной логики пришлось заново описать. Компания не просто заменила импортную систему российской, а полностью заново описывала, как продукция движется от производства к складу, как качество влияет на дальнейшие операции, как клиентские условия становятся правилами отгрузки, как НСИ управляет допустимыми действиями, как складская физика превращается в данные для ERP.
Именно здесь становится понятнее мысль Сбера про «СберСАП» и мысль «Ростелекома» про глубокую кастомизацию. У крупных компаний старая ERP почти никогда не бывает «чистым продуктом». Это слой собственных правил, доработок и управленческих решений. LAB Industries показывает, что при переходе на российскую платформу этот слой нельзя перенести механически — его приходится разбирать, описывать и решать, какие правила действительно нужны будущей системе.
У разных компаний сложность находится в разных местах
LAB Industries хорошо показывает производственный контур, где ERP связана со складом, качеством, сроками годности, клиентскими условиями и НСИ. Но это не единственный сценарий. В других проектах та же проблема проявляется иначе.
У Самарского металлургического завода главная сложность была в учетном контуре. Предприятие переходило с зарубежной системы на отечественное ПО в сжатые сроки: проект шел с ноября 2022 года по апрель 2023-го, охватывал казначейство, закупки, склад, бухгалтерский и налоговый учет. В описании проекта отдельно указано, что завод оказался в зоне риска отключения зарубежного ПО и потери накопленных учетных данных, а регламентированная отчетность и налоговый учет велись с использованием офисных приложений и электронных таблиц.
Для промышленного предприятия это не просто неудобная организация работы. Если учетный контур держится на ручных таблицах и системе без устойчивой поддержки, риск быстро переходит в закрытие периода, налоговую отчетность, закупки и контроль денег. Здесь ERP-переход нужен не для того, чтобы заменить один интерфейс другим, а чтобы вернуть учет в управляемую среду, где данные можно проверять, сопровождать и использовать без постоянных ручных страховок.
У МАЗ «Москвич» другая ситуация: ERP-проект был связан с экстренной миграцией с зарубежных информационных систем Renault, запуском производства, конвейера и технологической независимостью оборудования. После отключения исторических информационных систем в декабре 2022 года предприятию нужно было собрать единый контур управления на российских разработках. За месяц команда обследовала подразделения и собрала около 500 бизнес-требований.
В таком проекте ERP нельзя воспринимать как систему, которая подключается «после» производства. Она становится частью условий, при которых производство вообще может работать: материалы, операции, оборудование, качество, ремонт, логистика, финансы. Если этот контур не собран, проблема проявляется не в отчете и не в удобстве пользователя, а влияет на способность завода управлять выпуском.
Воткинский завод показывает еще более низкий уровень — уровень цехов. В проекте ПАРУС речь шла о системе управления ФХД и оперативном учете в производстве: внутри- и межцеховом партионном учете деталей и сборочных единиц, электронных накладных, контроле местонахождения ДСЕ, выполнении ГОЗ, загрузке рабочих и оборудования. Систему используют 4500 сотрудников, с ней работают 30 цехов основного и вспомогательного производства.
В этом случае цифровая система касается ежедневного движения производства: какая партия где находится, какой цех ее передал, какие ресурсы заняты, как выполняется заказ. Ошибка в данных здесь перестает быть только учетной и становится производственной.
Эти примеры важны не для сравнения платформ, они показывают другое: у каждой крупной компании есть свой участок, где ERP перестает быть программой и становится частью управления бизнесом. У одной это срок годности, склады и лабораторный контроль. У другой — учет и отчетность. У третьей — запуск производства. У четвертой — движение деталей между цехами.
В какой-то момент вопрос «какую ERP выбрать» сменяется другим: компания вообще готова честно описать, как она работает на самом деле?
🟡 В этот момент Уточка обычно уточняет: «как работает компания» — это еще не один ответ. У склада, финансов, производства и продаж могут быть разные версии одной и той же реальности. ERP-проект неприятен, но полезен тем, что заставляет эти версии свести в одну систему.
Почему выбор платформы — только начало
После таких проектов спор о платформе уже выглядит слишком узким. Конечно, компании будут сравнивать функциональность, архитектуру, опыт внедрений и скорость развития вендора. Но сама по себе платформа не отвечает на главный вопрос: какую логику бизнеса заказчик собирается закрепить в новой системе.
ERP-проект вытаскивает наружу то, что в обычной работе можно не пересматривать годами: старые правила, ручные проверки, спорные отчеты, доработки, исключения, привычные способы закрывать слабые места в данных и процессах. Часть этого действительно нужна бизнесу. Часть просто давно живет внутри системы и кажется нормой только потому, что к ней привыкли.
Кастомизация в крупных внедрениях сама по себе не проблема. Вопрос в том, что именно компания закрепляет в новой системе: рабочую логику или прежний порядок работы. Тогда российская ERP становится не новым корпоративным ядром, а аккуратной копией старого контура — с теми же обходами, зависимостями и неочевидными рисками.
Сильный переход устроен иначе. Он заставляет компанию решить, какие правила должны остаться как часть будущей архитектуры, а какие необходимо отложить в сторону вместе со старой системой. Именно поэтому российская ERP сегодня — не просто замена SAP, Oracle или Microsoft Axapta, но редкий момент, когда крупная компания может пересобрать свой управленческий контур, а не просто сменить программную платформу.