ERP-системы *

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

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

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

Перед вами человеческий лонгрид без капельки участия ИИ. Неприлизанный, с ошибками, нестыковками и потерей нити изложения. Ещё и про 1С.

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

Подход холиварный, не всем понравится, не всем подойдёт. Но проектов, выполненных по этому концепту, становится всё больше (да их и было много). А сейчас – становится всё больше, по совокупности причин.

Ну всё, переходим к делу. Итак, у нас УПП, и нам надо перейти на ЕРП – побыстрее и подешевле.

В первой публикации «Автоматический импорт банковских выписок в SAP с использованием FEB_FILE_HANDLING» был рассмотрен базовый сценарий применения FEB_FILE_HANDLING для автоматического импорта банковских выписок в XML формате, получаемых через сервисы коммуникации с банками. Именно под такой сценарий FEB_FILE_HANDLING изначально спроектирована.

В данной публикации показывается, как использовать функциональные возможности FEB_FILE_HANDLING для импорта текстовых форматов, специфических для стран, в том числе получаемых из систем «Банк-Клиент» через выгрузку файлов. Под этими форматами имеются в виду форматы выписок странового уровня: формат обмена «Клиент -> 1С» для России и Казахстана (с некоторыми различиями) и типы запросов 400 и 600 национальной системы электронных платежей Республики Беларусь, которые, в отличие от международных форматов MT94x, достаточно информационны и не зависят от особенностей заполнения конкретными банками.

Эти свойства формата «Клиент -> 1С» (для России и Казахстана) и типов запросов 400 и 600 (для Беларуси) делает переход на XML‑форматы и использование сервисов коммуникации с банковскими системами не столь обязательным решением и «горящей» задачей для улучшения процессов обработки банковских выписок, например, повышения оперативности получения информации об остатках и операциях на банковских счетах и ускорения разнесения входящих платежей.

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

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

Данная публикация открывает серию материалов, посвященных автоматическому импорту банковских выписок в SAP с использованием функциональности FEB_FILE_HANDLING (New Bank Statement Import). В центре внимания — как выстроить в системе единый сквозной процесс обработки выписок: от получения файлов из банков до автоматического разнесения платежей с оперативным предоставлением информации для управления остатками денежных средств (денежной позиции).

Данные материалы будут полезны SAP‑консультантам и архитекторам, работающим с модулями FI и Cash Management, а также специалистам казначейства и финансовых служб по банковским выпискам, разнесению платежей и управлению ликвидностью.

Сегодня уже можно говорить о том, что налоговый мониторинг перестал быть экспериментальной моделью. По данным ФНС России, с 1 января 2026 года в этом режиме уже работают 870 компаний из более чем 20 отраслей экономики. Это подтверждает, что мониторинг становится устойчивым форматом взаимодействия с налоговой службой для крупного бизнеса. А с учетом текущего вектора цифровой трансформации налогового администрирования можно предположить, что в ближайшее время количество участников режима будет только увеличиваться.

В статье «Налоговый мониторинг: режим «постоянной готовности»» я подробно разбирал саму модель налогового мониторинга, какие требования предъявляются к компании и как строится взаимодействие с ФНС. Поскольку налоговый мониторинг - это постоянное раскрытие данных, передача первичных документов и функционирование системы внутреннего контроля, для многих компаний, рассматривающих переход на этот режим, ключевым становится выбор подхода к организации этого процесса. А от того, насколько удобно выстроен процесс, зависит и то станет ли мониторинг управляемым инструментом или дополнительной нагрузкой.

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

Привет! Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. В нашей практике — проекты со сложной архитектурой, высокой нагрузкой и широким функциональным объемом. В прошлом году, например, мы рассказывали, как за семь месяцев перевели крупное химическое предприятие ПАО «КуйбышевАзот» с Oracle на 1С:ERP. И в таких проектах быстро становится понятно, что успех зависит не столько от количества разработчиков, сколько от методологии. Если этапы не структурированы, роли не определены, а результаты не отделимы друг от друга, даже сильная команда будет постоянно «догонять» сам проект.

Это первая статья из цикла о нашем подходе к крупным внедрениям 1С. Берите на вооружение — наша методологию сэкономила нам сотни часов на реальных проектах.

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

В законодательстве как Российской Федерации, так и прочих стран земного шара, возможно найти противоречия, когда одно и то же событие в разных нормативно-правовых актах трактуется взаимообратно. Последнее приводит к необходимости судебных разбирательств. Казалось бы, какое это имеет отношение к информационным системам и технологиям? Несмотря на то, что внедрение программного обеспечения сводит до минимума случаи мошенничества и воровства сотрудников за счет прослеживаемости операций, находятся и те, кто умело пользуется недоработками системы.

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

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

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

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

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

В последнее время ФНС все активнее смещает фокус в сторону цифрового контроля за операциями бизнеса. Я отчетливо наблюдал зарождение этого тренда, еще работая внутри системы налоговых органов. Налоговый мониторинг и АУСН - яркие тому примеры: стартовав как экспериментальные пилотные проекты, они быстро масштабировались и стали одними из важнейших инструментов налогового контроля.

Именно такой формат электронного онлайн-взаимодействия то будущее, которое готовит нам ФНС. Техническую и правовую базу АУСН я уже разбирал в статье «АУСН: налоговый оазис или цифровой концлагерь для бизнеса?». А в этой статье разберу инфраструктуру налогового мониторинга. Что этот режим представляет собой на практике, и где чаще всего «ломается» интеграция.

Привет, меня зовут Дмитрий Черняев, я руководитель отдела аналитики в компании «Эволюция». Как партнеры Битрикс24 мы помогаем компаниям внедрять CRM, автоматизировать бизнес-процессы и с 2022 года, создаем решения для автоматизации.

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

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

Мы собрали разрозненные HR-сценарии в едином контуре, создали раздел «HR-департамент» — отдельное цифровое рабочее место, в котором реализованы 4 инструмента:

Привет, Хабр! Меня зовут Евгений и я ведущий разработчик отдела SAP разработки.

Большинству из нас рано или поздно приходится сталкиваться с задачами оптимизации ПО. Последние пару лет мне пришлось плотно поработать в этом направлении, и в итоге решил поделиться некоторыми своими наблюдениями\выводами.

Статья описывает общий подход к увеличению производительности ПО. Для новичков в подобном "развлечении", она позволит понять что делать и куда смотреть в первую очередь. Опытные разработчики, надеюсь найдут для себя что то полезное, или смогут упорядочить свои знания.

Интересно? Читайте статью под катом.

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

Я работаю на стыке UX и бизнес-аналитики, и почти в каждом продукте вижу одну и ту же картину: команды годами решают проблемы через оперативную поддержку, игнорируя очевидный источник — пользовательский интерфейс и сценарии взаимодействия.

В этой статье разберём:
• какие типы запросов в поддержку можно убрать дизайном;
• как находить точки, где продукт «ломается»;
• какие UX-решения реально снижают нагрузку на поддержку;
• с чего начать, если ресурсы ограничены.

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

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

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

Когда речь заходит о выборе ERP-платформы и системного интегратора, почти всегда звучит слово «конкурс». Формально процесс выглядит структурированным: несколько поставщиков, демо, презентации, референсы, коммерческие предложения.

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

Не потому, что компании «не умеют выбирать».
А потому, что процесс выбора нередко начинается с инструмента, а не с методологии.

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

Недавно я обсуждал проект с партнёром, который предложил:
«Давайте сделаем серию демо и на основе впечатления выберем».

В разговоре выяснилось, что на старте отсутствовали:

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

Микросервисы стали стандартом построения масштабируемых и надежных корпоративных систем, особенно для таких классов, как ERP-системы, для которых важны детерминизм, воспроизводимость результатов, контроль и соответствие регуляторным требованиям [1][2][5].

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

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

В этой статье впервые представлена архитектурную модель, которая позволяет объединить эти два подхода в единую управляемую архитектуру.

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

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

Подготовка план-графика внедрения информационной системы требует от автора детального понимания всех аспектов выполняемых задач, возможности его сравнения с бенчмарками, привлечения экспертов для детальной проработки технических вопросов, а также терпения при многократных процедурах балансировки четверки «содержание-срок-ресурсы-стоимость». Несмотря на наличие в литературе детально описанных способов формирования планов работ на основе методов критического пути и критической цепи [1], вводящего резервные временные интервалы для обработки непредвиденных ситуаций, их использование в ИТ-проектах не всегда возможно и целесообразно.

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

Я в экселях полный "тук-тук кто там", точно знаю что он понимает в его сортах гораздо круче меня, поэтому заинтересовался и за кружкой пенного стал выведывать его истинную боль. Ага, примерно как делают настоящие взрослые дяди-аналитики перед постановкой задачи нам, разрабам.

Потому что у заказчиков так бывает: в ТЗ написали одно, думали при этом другое, а на самом деле проблема предприятия в третьем.

Оказалось что у друга моего проблема вовсе не в экселе.

Преамбула.

Если вас позвали работать в компанию, то почти всегда это означает одно: там есть работа, и что-то уже идёт не так.

Введение. Почему цепочки поставок ломаются

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

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

Физически цепочка может работать нормально: склад грузит, машины ездят, люди на местах делают свою работу. И при этом управляемости — ноль. Самое интересное начинается, когда в процессе появляется человек, который реально хочет отвечать за результат. Не просто «нажимать две кнопки», а думать. Его первый вопрос почти всегда одинаковый: «Алекс, а сколько товара нам заказывать в следующем месяце?»

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

ERP-системы непрерывно развивались с самого начала своего создания. Но их архитектура до сих пор опирается на принципы, сформулированные до эпохи повсеместного распространения данных в реальном времени и развития автономного агентного искусственного интеллекта. 

Соответственно, можно с утверждением говорить, что текущая архитектура ERP-систем не отвечает современным вызовам. В этой статье разберем, почему ей нужен принципиально иной фундамент. Я предлагаю строить его на трех китах: семантический слой данных (USDL), открытая интеграционная среда и продвинутая мультиагентная платформа (AMAP).

Далее я подробно представлю архитектуру такой ERP-системы, типы AI-агентов и примеры их работы в реальных бизнес-процессах. Ключевая идея — гибкая автономия под контролем человека. В статье я опираюсь на актуальные разработки и аналитику 2025 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде.