В статье рассматривается актуальная тема разработки и реализации программного комплекса для автоматизации управленческого контроля на средних и крупных предприятиях.

Ключевые слова: система управленческого контроля, микросервисная архитектура, REST API, Java Spring Boot, Apache Kafka, MySQL.

Введение

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

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

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

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

Особенности объекта автоматизации текущего процесса управленческого контроля на предприятии

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

Основной особенностью является фрагментарность данных. Информация о сотрудниках, их задачах, отпусках и организационных объявлениях зачастую хранится в не связанных между собой источниках: от Excel-таблиц и бумажных журналов до простых локальных баз данных отдельных отделов (например, HR-службы, бухгалтерии, руководителей подразделений). Это приводит к тому, что получение целостной картины по тому или иному сотруднику или проекту требует значительных временных затрат на сбор и согласование информации из разных источников, а также чревато ошибками из-за неактуальных или противоречивых данных.

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

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

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

Требования к разрабатываемому программному продукту

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

На основе анализа были структурированы требования по двум основным категориям:

Функциональные требования:

1. Управление доступом: Обеспечение безопасной аутентификации и авторизации пользователей на основе ролей (OAuth 2.0).
2. Управление персоналом: Ведение централизованного справочника сотрудников с данными о должностях, подразделениях и контактной информацией.
3. Управление задачами: Функционал для создания, назначения, отслеживания статуса выполнения и контроля дедлайнов задач с возможностью назначения ответственных и согласования.
4. Учет рабочего времени: Автоматизированный учет и согласование отпусков, больничных, командировок и иных видов отсутствий.
5. Информирование персонала: Механизм публикации, управления и архивации корпоративных объявлений, доступных всем сотрудникам.
6. Система уведомлений: Автоматическая рассылка уведомлений пользователям о новых задачах, изменениях в статусах, предстоящих событиях и новых объявлениях.

Нефункциональные требования:

1. Производительность и масштабируемость: Низкое время отклика API (менее 100 мс) и возможность горизонтального масштабирования отдельных модулей при росте нагрузки [1].
2. Надежность и отказоустойчивость: Обеспечение высокой доступности системы и минимизация простоев за счет изоляции сервисов [2].
3. Безопасность: Защита персональных данных и учетных записей, разграничение прав доступа.
4. Удобство сопровождения: Возможность независимого развертывания и обновления отдельных компонентов системы без остановки всей платформы [1].

Сформулированные требования стали основой для выбора архитектурного подхода и проектирования системы.

Программные средства автоматизированной системы

Для реализации системы был выбран следующий технологический стек:

1. Бэкенд: Java 17/21, фреймворк Spring Boot (Spring Security, Spring Data JPA, Spring MVC, Spring Cloud Stream) [4].
2. Базы данных: Реляционные СУБД MySQL (по одному экземпляру на каждый микросервис для обеспечения независимости и сохранения границ контекстов) [1].
3. Межсервисная асинхронная коммуникация: Брокер сообщений Apache Kafka для организации событийно-ориентированной архитектуры между сервисами задач/объявлений и сервисом уведомлений [3].
4. Тестирование: JUnit 5, Mockito для модульного и интеграционного тестирования; Apache Benchmark (ab) для проведения нагрузочного тестирования.

Результаты

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

Рис. 1. Структурная схема приложения

Архитектурное решение системы построено на принципах предметно-ориентированного проектирования (Domain-Driven Design), что позволило четко разграничить зоны ответственности между сервисами [1, 5]:

1. Auth Service: централизованно управляет аутентификацией и авторизацией по протоколу OAuth2.
2. User Service: хранит учетные данные и профили пользователей, выступая поставщиком данных для Auth_Service.
3. Employee Service: содержит бизнес-логику и данные о сотрудниках, их должностях и организационной структуре.
4. Task Service: реализует функционал постановки, назначения, контроля выполнения и согласования задач между сотрудниками.
5. Absence Service: отвечает за учет и управление всеми типами отсутствий сотрудников (отпуск, больничный, командировка и т. д.).
6. Announcement Service: обеспечивает создание, публикацию и хранение корпоративных объявлений.
7. Notification Service: управляет рассылкой уведомлений (например, о новых задачах или объявлениях) через различные каналы связи.

Взаимодействие между сервисами организовано двумя способами: синхронное через вызовы REST API для операций, требующих немедленного ответа, и асинхронное на основе событий через Apache Kafka [4]. Такое решение позволяет эффективно развязать сервисы-продюсеры (Task_Service, Announcement_Service) и сервис-консьюмер (Notification_Service), повышая отказоустойчивость и производительность системы в целом. Каждый микросервис управляет своей собственной базой данных, что обеспечивает четкое разделение ответственности и целостность данных в рамках своего контекста [5]. Схемы баз данных для каждого сервиса разработаны и представлены на рисунках 2–6.

Рис. 2. Схема БД Announcement Service

База данных сервиса объявлений организована вокруг единой таблицы announcements, которая хранит все корпоративные сообщения. Структура таблицы предусматривает хранение не только базовой информации (заголовок, содержание, дата публикации), но и поддерживает возможность прикрепления медиафайлов через поле img_url.

Рис. 3. Схема БД Task Service

Схема базы данных управления задачами реализует сложную бизнес-логику контроля выполнения работ. Основная таблица tasks содержит полный жизненный цикл задачи: от создания и назначения приоритета до контроля дедлайнов и статусов выполнения. Особенностью модели является разделение ролей исполнителя и проверяющего, а также флаг should_be_inspected, определяющий необходимость контроля качества. Дополнительная таблица comments обеспечивает сопроводительную коммуникацию по каждой задаче.

Рис. 4. Схема БД User Service

Модель данных пользовательского сервиса обеспечивает фокус на безопасности и управлении доступом. Таблица users хранит учетные данные с хешированными паролями и реализует систему ролевого разграничения прав (RBAC). Уникальные ограничения на поля username и email гарантируют целостность данных при регистрации и аутентификации пользователей.

Рис. 5. Схема БД Absence Service

База данных учета отсутствий отражает полный список отсутствия работника на рабочем месте. Модель поддерживает классификацию типов отсутствий с различными атрибутами (например, место командировки) и реализует многостадийный процесс согласования через поле status. Флаг is_approval определяет, требует ли конкретный тип отсутствия обязательного согласования руководителем.

Рис. 6. Схема БД Employee Service

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

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

Проверка технических характеристик программного кода

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

Модульное и интеграционное тестирование. На первом этапе была верифицирована корректность работы отдельных компонентов (модулей) каждого микросервиса. Для этого использовались фреймворки JUnit и Mockito, которые позволили изолировать тестируемый код и проверить его поведение в различных сценариях. Было разработано более 150 модульных тестов, покрывающих ключевые бизнес-процессы системы.

Интеграционное тестирование было направлено на проверку взаимодействия между компонентами внутри сервиса, а также с внешними зависимостями. Для тестирования REST-контроллеров использовался MockMvc, что позволило проверить корректность HTTP-ответов, валидацию входных данных и обработку ошибок. Тестирование репозиториев проводилось с использованием H2 базы данных. В результате был достигнут уровень покрытия кода тестами не менее 80 % для критически важных бизнес-модулей, что свидетельствует о надежности реализованной логики и соответствии принципам тест-ориентированной разработки [4].

Нагрузочное тестирование. Для оценки производительности и стабильности системы под нагрузкой был использован инструмент Apache Benchmark (ab). Тестирование проводилось на наиболее критичных с точки зрения пользовательского опыта эндпоинтах API. Нагрузка моделировалась в виде серии из 10 000 последовательных HTTP-запросов.

Параметры нагрузочного тестирования указаны в таблице 1:

Таблица 1

Сравнительная характеристика рассмотренных аналогов

Ключевые результаты тестирования представлены таблице 2:

Таблица 2

Результаты проведенного тестирования

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

Дополнительно были проведены проверки, подтверждающие безопасность передачи данных (использование HTTPS) и корректность разграничения прав доступа на основе ролей. Также была успешно протестирована согласованность данных в условиях асинхронной коммуникации через Kafka [3], что гарантирует доставку уведомлений и отсутствие потери событий.

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

Заключение

В статье описана успешная реализация системы управленческого контроля на основе микросервисной архитектуры. Примененный подход [1, 2, 5] позволил создать масштабируемое, отказоустойчивое и высокопроизводительное решение. Декомпозиция на независимые сервисы с четко определенными границами ответственности упрощает дальнейшую поддержку и развитие системы. Комбинация синхронного (REST) и асинхронного (Kafka) [3] взаимодействия обеспечила гибкость и эффективность обмена данными. Результаты всестороннего тестирования, включая нагрузочное, подтвердили высокое качество программного кода и готовность системы к промышленной эксплуатации. В перспективе возможно расширение функционала за счет добавления новых микросервисов, например, для аналитической отчетности.

Литература:

1. Richardson, C. Pattern: Microservice Architecture. [Электронный ресурс]. — URL: https://microservices.io/patterns/microservices.html
2. Fowler, M., Lewis, J. Microservices: a definition of this new architectural term. [Электронный ресурс]. — URL: https://martinfowler.com/articles/ microservices.html
3. Официальная документация Apache Kafka. [Электронный ресурс]. — URL: https://kafka.apache.org/documentation/
4. Официальная документация Spring Framework и Spring Boot. [Электронный ресурс]. — URL: https://spring.io/projects/spring-boot
5. Newman, S. Building Microservices: Designing Fine-Grained Systems. — O'Reilly Media, 2021.