Разработка программного обеспечения для автоматизации бизнес-процессов снабжения предприятия на основе каскадной модели внедрения (часть 1)

Подробности

Опубликовано: 03.03.2026 10:05

Автор: Латыев Ахмат Рамазанович

Просмотров: 22

Аннотация: в статье исследуется процесс снабжения предприятия и реализуется веб-приложение, позволяющее автоматизировать формирование заявок на закупку. Собранные бизнес-требования использовались для выбора наиболее подходящего программного решения: AGORA SRM, Comindware SRM, ELMA365 SRM и Максмарт SRM+. По результатам анализа сильных и слабых сторон ПО, сформулирован вывод о необходимости ведения собственной интернет-разработки. Следуя каскадной модели внедрения, на фазе проектирования проведено описание процессов в графических нотациях IDEF0 и BPMN2.0 для моделей AS-IS и TO-BE, обеспечивающих выявление и устранение недостатков реализации бизнес-операций.
Ключевые слова: взаимоотношение с поставщиками, управление взаимоотношениями с поставщиками, управление поставками, закупочная деятельность, SRM, SRM системы управления, AGORA SRM, ELMA365, ER диаграмма, нотация ER диаграмм, rest интерфейс, файл json, API вызов, библиотека axios, backend разработка, веб разработка backend, разработка backend сайта.
Скачать: PDF (статья), PDF (выпуск №33).

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

1. Проблематика

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

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

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

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

2. Идентификация требований

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

• управление поставщиками: регистрация и ведение контактной информации, просмотр, редактирование, удаление;
• оформление заявок: формирование состава заявки, выбор поставщика, указание сроков, редактирование и удаление;
• контроль исполнения: фиксация фактических поставок, отслеживание статуса, учёт расхождений и инициирование возвратов;
• управление товарами: ведение справочника номенклатуры, отображение остатка, возможность добавления и редактирования,

были собраны и идентифицированы функциональные и нефункциональные требования, ранжированные по степени значимости в табл. 2.1 [4].

Табл. 2.1. Реестр требований к ПО

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

3.  Выбор программного решения

На российском рынке представлено несколько платформенных программных решений, относящихся к классу SRM-систем и ориентированных на автоматизацию закупочной деятельности и управление взаимодействием с поставщиками: AGORA SRM, Comindware SRM, ELMA365 SRM и Максмарт SRM+. Каждое приложение имеет свою специфику, сильные и слабые стороны, а также определённые ограничения, которые необходимо учитывать при их сравнительном анализе.

AGORA SRM считается одним из наиболее функционально насыщенных и зрелых закупочных решений (рис. 3.1) [5]. Его ключевым преимуществом является наличие полного цикла управления поставщиками: от аккредитации и тендеров до оценки эффективности взаимодействия. Доступны механизмы интеграции с такими ERP-системами как: SAP, 1С и Oracle, а также аналитический модуль, позволяющий формировать детализированные отчёты и прогнозы. Среди недостатков решения следует отметить высокую стоимость внедрения, избыточность функционала для малого и среднего бизнеса.

Рис. 3.1. Интерфейс программы AGORA SRM

Comindware SRM выделяется благодаря своей архитектуре на базе Low-code-платформы [6], что позволяет без привлечения разработчиков адаптировать систему под конкретные потребности заказчика (рис. 3.2). Это делает её особенно привлекательной для компаний с ограниченными техническими ресурсами. В числе преимуществ программы отмечаются продвинутая аналитика, автоматизация процессов ведения тендеров и контрактного контроля, а также удобный пользовательский интерфейс. Тем не менее система может ограничивать возможности расширения в условиях нестандартных сценариев. Также ее Low-code архитектура может не подойти компаниям, нуждающимся в глубокой кастомизации и реализации сложных интеграций.

Рис. 3.2. Интерфейс программы Comindware SRM

ELMA365 SRM как облачное решение демонстрирует высокую степень доступности и простоту внедрения [7]. Среди ее сильных сторон можно выделить интуитивный интерфейс, удобство ведения реестра поставщиков, а также надёжную интеграцию с системами бухгалтерского и складского учётов. Использование данного приложения снижает нагрузку на внутреннюю IT-инфраструктуру. Ограничения состоят в меньшей гибкости по сравнению с системами, установленными на собственных серверах, а также возможной зависимости от качества интернет-соединения и политики провайдера по хранению данных.

Максмарт SRM+ ориентирован на комплексное управление поставщиками и отличается модульным подходом, позволяющим подключать только необходимые компоненты [8]. Это снижает сложность внедрения и делает систему удобной для постепенного расширения. Платформа поддерживает электронные закупки, контроль качества поставок и предоставляет расширенную финансовую аналитику. К преимуществам приложения можно отнести простоту его масштабирования и высокий уровень визуализации процессов. Вместе с тем система может показаться избыточной для предприятий с ограниченным количеством поставщиков, а также требовать дополнительную настройку в случае сложной логистики процессов и нестандартной оргструктуры компании.

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

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

В первую очередь планировалась реализация высокоприоритетных функций, критически необходимых для базовой работы программной системы, потребности средней и низкой приоритетности предполагалось внедрить по мере развития продукта (табл. 2.1). Данный подход обеспечивает логичную последовательность разработки системы и соответствует каскадной модели внедрения программного обеспечения [9].

4.  Постановка задачи

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

• спроектировать процессы в нотациях IDEF0 и BPMN 2.0 для моделей AS-IS и TO-BE до 4-го уровня детализации. Построить карту бизнес-процессов;
• смоделировать ER-диаграммы данных, включая нормализацию таблиц баз данных до третьей нормальной формы;
• сформировать структуру разрабатываемого приложения;
• разработать программу в среде IntelliJ IDEA с использованием языка программирования Java;
• выполнить качественную оценку работы программы путём проведения функционального тестирования.

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

5.  Проектирование решения

Следуя своду знаний по корпоративной архитектуре TOGAF [10], проектирование будущего программного продукта должно вестись в разрезе таких параметров как: бизнес-процессы, приложения, данные и техника. В контексте текущего исследования мы не затрагивает техническую инфраструктуру, в связи с чем последним параметром моделирования можно пренебречь.

5.1.  Моделирование бизнес-процессов

Для проектирования бизнес-процессов использованы нотации IDEF0 и BPMN 2.0, позволяющие моделировать операции на верхних и нижних уровнях декомпозиции. Выбор указанных графических нотаций неслучаен: первая позволяет наглядно продемонстрировать процесс с учетом ограничений, вторая – детально описать выполнение операций, а также связанные события, документы, системы и ответственных. Используя лучшие практики BPM CBOK [2], построение схем процессов осуществлялось в моделях AS-IS и TO-BE, что обеспечивало устранение «узких мест» бизнес-операций.

Рис. 5.1 демонстрирует ключевой процесс обработки поставок на верхнем уровне, описанный в IDEF0 для модели «Как есть». Его дальнейшее уточнение порождает бизнес-операции (рис. 5.2):

• инициирование заявки на поставку;
• связь с поставщиком и подтверждение заказа;
• приёмка товара и возврат.

Рис. 5.1. Верхнеуровневое описание ключевого процесса управления поставками в нотации IDEF0 и модели AS-IS

Рис. 5.2. Схема процесса управления поставками на 1-м уровне декомпозиции в нотации IDEF0 и модели AS-IS

Каждый из процессов 1-го уровня дополнительно раскрыт в нотации BPMN2.0, это позволяет отразить порядок действий, участников и точки принятия решений:

• операция «Инициирование заявки на поставку» начинается с формулировки потребности менеджером, после чего вручную выбирается поставщик и оформляется заявка. Далее поставщик уведомляется посредством электронной почты и/или телефонного звонка. Все действия выполняются одним участником без использования какой-либо информационной системы (рис. 5.3);

Рис. 5.3. Описание процесса инициирования заявки на поставку на 2-м уровне декомпозиции в нотации BPMN2.0 и модели AS-IS

• подпроцесс «Подтверждение заявки поставщиком» характеризует отклик поставщика, проверку остатков на складе и отправку подтверждения. В зависимости от наличия товаров поставщик формирует полную или частичную поставку. Менеджер, в свою очередь, вручную фиксирует дату поставки. Взаимодействие происходит через неструктурированные каналы связи, такие как телефон и электронная почта (рис 5.4);

Рис. 5.4. Схема процесса подтверждения заявки поставщиком на 2-м уровне декомпозиции в нотации BPMN2.0 и модели AS-IS

• бизнес-операция «Приёмка товара и возврат» охватывает приемку поставки и возможное оформление возврата. Менеджер вручную проверяет товары на соответствие, при обнаружении отклонений уведомляет поставщика, который может предложить возврат или компенсацию. Возврат осуществляется неформально, не отражается в программной системе и не фигурирует в какой-либо аналитике (рис. 5.5).

Рис. 5.5. Описание процесса приемки товара и его возврата на 2-м уровне декомпозиции в нотации BPMN2.0 и модели AS-IS

Анализ состояния AS-IS показал, что процессы сильно зависят от человеческого фактора, в них отсутствует централизованный контроль, невозможно отслеживать статусы и затруднена аналитика. Выявленные недостатки подлежат устранению в модели TO-BE, верхнеуровневая схема ключевого бизнес-процесса в которой представлена на рис. 5.6. Детализация процесса управления поставками дает подпроцессы (рис. 5.7):

• формирование заявки;
• взаимодействие с поставщиком;
• приёмка поставки и возврат.

Рис. 5.6. Верхнеуровневое описание ключевого процесса управления поставками в нотации IDEF0 и модели TO-BE

Рис. 5.7. Схема процесса управления поставками на 1-м уровне декомпозиции в нотации IDEF0 и модели TO-BE

Последующая декомпозиция бизнес-процессов на 2-й уровень описания с использованием нотации BPMN2.0 демонстрирует автоматизацию выполняемых операций за счет использования разрабатываемой SRM-системы:

• подпроцесс «Формирование заявки» начинается с анализа остатков программным решением. Менеджер подтверждает потребность, выбирает поставщика из списка предложенных и формирует содержание заявки. Заявка сохраняется в ПО, получает уникальный идентификатор и статус, а поставщик автоматически уведомляется о поступлении нового запроса (рис. 5.8);

Рис. 5.8. Описание процесса формирования заявки на 2-м уровне декомпозиции в нотации BPMN2.0 и модели TO-BE

• в рамках операции «Взаимодействие с поставщиком» поставщик получает уведомление, сообщает о сроках отгрузки, после чего информация фиксируется программной системой. Менеджер утверждает предложенную дату, при необходимости ПО позволяет изменить или отменить ее, заявке же автоматически присваивается соответствующий статус (рис. 5.9);

Рис. 5.9. Схема процесса подтверждения заявки поставщиком на 2-м уровне декомпозиции в нотации BPMN2.0 и модели TO-BE

• функция «Приемка поставки и возврат» охватывает одноименные операции. После прибытия товара на склад ПО предлагает проведение поставки, формирует документы и проводит сверку с заявкой. При наличии отклонений инициируется процесс возврата. Все действия сопровождаются автоматической фиксацией результатов в реализуемом решении: обновляются остатки, регистрируется возврат, изменяются статусы заявки и поставки (рис. 5.10).

Рис. 5.10. Описание процесса приемки товара и его возврата на 2-м уровне декомпозиции в нотации BPMN2.0 и модели TO-BE

Таким образом переход от модели AS-IS к TO-BE позволяет устранить чрезмерный ручной труд, обеспечить прозрачность и аналитическую наблюдаемость процесса поставки. Совмещение графических схем в IDEF0 и BPMN2.0 обеспечивает поведенческое представление процессов, что формирует основу для проектирования структуры данных и интерфейсов разрабатываемого ПО.

Литература

1. Логистика / Дыбская В.В. и др. – М.: Эксмо, 2009. – 944 с.
2. Свод знаний по управлению бизнес-процессами: BPM CBoK 4.0 / Бенедикт Т., Кирхмер М., Шарсиг М., Франц П., Саксена Р., Моррис Д., Хилти Д. – М.: Альпина Паблишер, 2024. – 504 с.
3. Стандарты корпоративных информационных систем [Электронный ресурс] // База знаний научно-популярного сетевого журнала «Корпоративные информационные системы». – Режим доступа: http://corpinfosys.ru/knowledgebase/standards (дата обращения 31.03.2026).
4. Демьянов Н.А. Требования к программному обеспечению: от подготовки до управления изменениями (часть 1) // Корпоративные информационные системы. – 2024. – №1 (25) – с. 16-22. – URL: https://corpinfosys.ru/archive/2024/issue-25/271-2024-25-requirements.
5. Официальный сайт AGORA SRM [Электронный ресурс]. – Режим доступа: https://agora.ru (дата обращения: 31.03.2026).
6. Официальный сайт Comindware [Электронный ресурс]. – Режим доступа: https://comindware.com (дата обращения: 31.03.2026).
7. Официальный сайт ELMA365 [Электронный ресурс]. – Режим доступа: https://elma365.ru (дата обращения: 31.03.2026).
8. Официальный сайт Максмарт SRM+ [Электронный ресурс]. – Режим доступа: https://maksmart.ru/ (дата обращения: 31.03.2026).
9. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
10. Harrison R. TOGAF certified study guide. Van Haren Publishing, Zaltbommel, 2013. – 324 p.
11. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
12. Bootstrap.com [Электронный ресурс] // Документация. – Режим доступа:
    https://getbootstrap.com/docs/5.3/getting-started/introduction/ (дата обращения: 31.03.2026).
13. Axios [Электронный ресурс] // Документация. — Режим доступа: https://axios-http.com/docs/intro (дата обращения: 31.03.2026).
14. React.dev [Электронный ресурс] // Документация. — Режим доступа: https://react.dev/learn (дата обращения: 31.03.2026).
15. Терентьев И.М. Стратегия тестирования в проектах имплементации ERP-систем. – 2018. – №3 – с. 39-45. – URL: https://corpinfosys.ru/archive/issue-3/141-2018-3-testingstrategy.

Выходные данные статьи

Латыев А.Р. Разработка программного обеспечения для автоматизации бизнес-процессов снабжения предприятия на основе каскадной модели внедрения (часть 1) // Корпоративные информационные системы. – 2026. – №1 (33) – c. 8-25. – URL: https://corpinfosys.ru/archive/2026/issue-33/321-2026-33-srm.

Об авторе

Латыев Ахмат Рамазанович – выпускник кафедры корпоративных информационных систем института информационных технологий РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Веб-приложение управления цепочками поставок электронного магазина велотоваров». Электронная почта автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №33

1. Разработка ПО для автоматизации процессов снабжения (часть 1);
2. Реализация SOD-контролей в бизнес-процессах и ERP-системах.