FastMBO - внутренняя система целеполагания и расчёта премий — архитектурное ревью¶

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

Содержание¶

Краткое описание
Цели, требования и ограничения
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация
Решения, компромиссы и риски

Краткое описание¶

Статус¶

historical internal project / reconstructed case study

Роль¶

инициатор, системный аналитик, автор концепции, разработчик прототипа

Стек¶

Тип: Internal automation / MBO system / lightweight internal ERP; Масштаб: внутреннее использование в организации до 350 сотрудников; Период: ранний этап перехода от ИТ-администрирования к системному анализу и разработке внутренних систем

Ценность проекта¶

FastMBO - внутренняя система для автоматизации процесса целеполагания, сбора оценочных листов, согласования достижений и расчёта премий по MBO-модели.

Цели, требования и ограничения¶

Цели и нецели¶

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

Требования¶

Система должна была позволить:

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

Ограничения¶

Модель системы¶

Доменная модель¶

Роли пользователей (акторы)¶

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

Модель данных¶

ERD¶

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

Архитектурный подход¶

Система проектировалась как монолитное веб-приложение для внутреннего использования.

Целевая архитектура включала:

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

Архитектурные артефакты¶

Бизнес-процессы BPMN¶

AS-IS¶

TO-BE¶

C4 Context¶

C4 Container¶

C4 Component¶

Потоки интеграции¶

Целевой TO-BE процесс¶

Целевой процесс предполагал переход к управляемому цифровому циклу:

Подготовка периода оценки.
Утверждение метрик и шаблонов достижений.
Сборка оценочных листов и привязка к должностям.
Запуск периода и разблокировка ввода.
Онлайн-заполнение метрик и достижений сотрудниками.
Параллельная валидация руководителями.
Закрытие периода и блокировка ввода.
Автоматический расчёт баллов, цены балла и премий.
Ручные корректировки при необходимости.
Утверждение итогов.
Публикация премий в личном кабинете.
Экспорт итогов в 1С через CSV или коннектор.

Безопасность, качество и эксплуатация¶

Модель безопасности и доступа¶

Роли пользователей¶

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

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

Режимы отказа¶

Оценка масштаба и стоимости¶

Экономический эффект¶

Проект был обоснован через сокращение ручного труда при подготовке, проверке, пересчёте и переносе данных.

Оценка показывала экономию времени более 300 тыс. рублей в год при годовом цикле оценки. При ежемесячном или более частом цикле эффект масштабировался кратно за счёт повторяемости процесса.

Дополнительный эффект:

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

Решения, компромиссы и риски¶

Ключевые решения¶

Компромиссы¶

Монолит vs распределённая архитектура¶

Монолит был оправдан контекстом:

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

Ограничения проекта¶

Проект не был доведён до уровня зрелой production-системы с полноценным жизненным циклом поставки, тестированием, релизным процессом и поддержкой.

Исходная документация была неполной и недостаточно формализованной. Часть текущих архитектурных материалов была восстановлена позднее как reconstructed case study для портфолио.

См. также Architecture Decision Records.