ERP-системы *

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

Я работаю на стыке 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 без потери данных, людей и здравого смысла». Цена — миллион рублей, оплата — когда-нибудь потом. И всё это на фоне сертов «Проект года». Мы молодцы, выбери нас!

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

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

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

Качественное и своевременное внедрение корпоративных информационных систем как российского (1С, Галактика, Парус), так и западного производства (ранее преимущественно SAP, Oracle и Microsoft) требует досконального знания методологии имплементации, что накладывается свой отпечаток на жизненный цикл программного обеспечения. Несмотря на наличие гибких методов внедрения, жизненный цикл программных продуктов, по существу, остается единым: начиная с задумки и заканчивая выведением из эксплуатации. Внедрение корпоративных программных систем, представляющих собой имплементирование программного решения в масштабах предприятия или холдинга, имеет схожий жизненный цикл. Однако, если внимательнее к нему присмотреться, выходит, что процесс внедрения является не единственным, а фактически завершающим шагом. Не верите, тогда давайте разберемся в этом вопросе в рамках текущей статьи.

Приведем шаги классического жизненного цикла программного обеспечения [1]:

В этой статье — неочевидный взгляд на эффективность совещаний в ERP-проектах: не количество совещаний или участников, а результат.

Геополитические и экономические сдвиги последних лет привели к фундаментальной перестройке агропромышленного комплекса (АПК) на пространстве Содружества Независимых Государств (СНГ). Традиционная архитектура рынка, базировавшаяся на доминировании западных технологических гигантов (John Deere, CNH Industrial, AGCO, Claas), претерпела необратимые изменения, особенно на территории Российской Федерации и Беларуси. Этот процесс, часто характеризуемый как «поворот на Восток», повлек за собой не только замещение выбывающего парка техники машинами китайского производства, но и создал вакуум в цифровой инфраструктуре отрасли.

Западные производители поставляли на рынок СНГ не просто «железо», а интегрированные экосистемы: телематические системы, облачные платформы управления флотом и, что критически важно для дилеров, интерактивные электронные каталоги запчастей (EPC — Electronic Parts Catalogs) с глубокой детализацией и связью с ERP-системами. Китайские бренды (Zoomlion, Lovol, YTO, SANY), стремительно заполняющие освободившиеся ниши, пока находятся на этапе формирования аналогичных цифровых сервисов. Этот разрыв между привычными стандартами обслуживания, заданными западными вендорами, и текущими возможностями азиатских поставщиков формирует колоссальный спрос на услуги специализированной веб-интеграции.

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

Продолжаем обучать Ивана Ивановича Воякс (он же Woyax) особенностям работы программистом MS Dynamics AX 2012 (и любые версии, включая D365 FO).

Эта часть посвящена трём важным и интересным вещам:

Научили Воякс путешествовать по системе и запрашивать необходимые ему для выполнения задач или для анализа объекты

Научили Воякс пользоваться перекрёстными ссылками

Сформировали концепцию того, как и в каком виде Воякс будет предлагать модифицировать код и объекты системы

Или как я за 200+ внедрений научился отличать реальную боль от маркетинговой иллюзии

Знаете, что меня бесит больше всего в этой индустрии? Когда бизнес тратит 200–300 тысяч на «решение всех проблем», а через полгода система, на которую потрачены силы и время, не открывается и не используется. Деньги в трубу. И самое обидное — это не вина технологии или IT продукта. Это вина того, что никто не задал правильные вопросы ДО покупки.

За 200+ внедрений я насмотрелся на эту картину столько раз, что могу предсказать провал ещё на первой встрече. И сейчас расскажу, почему так происходит и как этого избежать.

Стандарты автоматизации корпоративных информационных систем развиваются эволюционно: от автоматизации небольшой предметной области, обеспечиваемую незначительным программным функционалом, до покрытия хозяйственных операций предприятий и даже холдингов, требующего масштабных программно-технических разработок. Это наглядно демонстрирует стандарт ERP, включавший в себя изначально класс систем MRP2, далее трансформировавшийся в ERP2 и ERP3, объединив множество прочих классов систем (SRM, CRM, PLM, SCM, FI и др.). Таким образом полнота охватов бизнес-процессов демонстрирует степень развития как предприятия, так и программного решения. Не стал исключением и класс автоматизации CRM: технологическое развитие и инновации в области управления взаимоотношениями с клиентами, их опытом и знаниями, позволил расширить данных стандарт и предложить новый – Customer Experience или CX.

В данной работе мы выполним обзор стандарта автоматизации CX, не так давно появившегося на рынке корпоративных программных систем. Рассказ будет построен следующим образом:

К моменту прихода Ли Якокки (легенда менеджмента производства авто, создатель Форд Мустанг) Крайслер находилась на грани банкротства. Чтобы не потерять бизнес Якока закрывал убыточные заводы, продавал непрофильные активы, изменил отношения с поставщиками, сконцентрировал все усилия на создании новой линейки автомобилей — K‑Car и другие. Принятые меры позволили оживить бренд, погасить долги и начать рост бизнеса.