ERP-системы *

Сегодня уже можно говорить о том, что налоговый мониторинг перестал быть экспериментальной моделью. По данным ФНС России, с 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 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде.

Первое упоминание компьютерной программе было сделано практически век назад и датировано еще далеким 1833 годом. С тем пор были изобретены множество языков программирования, начиная от машинных и до современных C++, Java, Python. Постепенно понимание и сложность компьютерных программ менялось: если ранее максимальное внимание уделялось алгоритму, то сейчас в комплексных программных приложениях, акцент смещается в сторону данных. Изобретены множество прикладных методов внедрения информационных систем, которые по существу являются производными от трех классических моделей имплементации. Однако, неоспоримым является тот факт, что любая программа в первую очередь должна покрывать исходные потребности пользователей. Данная истина зачастую теряется рутинных активностях разработки приложений и их внедрения.

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

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

Перед нами проект Frappe.io с более чем 50 000 звёзд на GitHub. Это фреймворк, который позволяет создавать гибкие бизнес-системы с полноценным пользовательским интерфейсом. Платформа поддерживает множество интеграций, в том числе с n8n, что открывает широкие возможности для автоматизации и построения сквозных процессов.

Давайте перейдём к основным компонентам платформы, чтобы лучше понять её архитектуру и замысел разработчиков.

Не удалось сдержать желание сделать и продемонстрировать связку MS Dynamics AX (Axapta, D365FO) – Woyax (ИИ-агенты, маркетплейсы) – Мессенджеры / боты (Telegram, MS Teams, MAX), поэтому сначала сразу коротенькое видео (7 минут) с демонстрацией сценариев, а далее полученная в процессе информация и выводы...

Как это обычно бывает? Вот ты — руководитель, собственник или просто очень инициативный человек — в какой-то момент понимаешь: жить так дальше нельзя. Автоматизация и цифровизация не дают спать по ночам. От требований к опер/упр. учету зудит в мозгу.

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

На первой же встрече тебе выкатят кейс-сказку: «Agile-внедрение ERP за полгода, самописная MES-система и аналитика в BI без потери данных, людей и здравого смысла». Цена — миллион рублей, оплата — когда-нибудь потом. И всё это на фоне сертов «Проект года». Мы молодцы, выбери нас!

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

Еще есть «персонажи», у которых сценарий менее гуманный. Договор – оплата – работаем пока работается, главное акты подписывать, в идеале наперед – суд – возврат минимальной суммы. Таких мы обходим стороной, но именно у них будет самое вкусное КП.

Давай рассмотрим основные и не самые очевидные ошибки при выборе интегратора, терять деньги и время никто не хочет.