FastMBO - внутренняя система целеполагания и расчёта премий — всё вместе¶
Эта страница собирается из компактных разделов проектной документации. Отдельные файлы разделов остаются источником истины; эта страница предназначена для последовательного чтения, ревью и экспорта в стиле PDF.
Содержание¶
- Краткое описание
- Обзор
- Контекст и проблема
- Цели, требования и ограничения
- Роль и обязанности
- Модель системы
- Архитектура и интеграции
- Безопасность, качество и эксплуатация
- Решения, компромиссы и риски
- Дорожная карта и демонстрация
- Architecture Decision Records
Краткое описание¶
Статус¶
historical internal project / reconstructed case study
Роль¶
инициатор, системный аналитик, автор концепции, разработчик прототипа
Стек¶
Тип: Internal automation / MBO system / lightweight internal ERP; Масштаб: внутреннее использование в организации до 350 сотрудников; Период: ранний этап перехода от ИТ-администрирования к системному анализу и разработке внутренних систем
Ценность проекта¶
FastMBO - внутренняя система для автоматизации процесса целеполагания, сбора оценочных листов, согласования достижений и расчёта премий по MBO-модели.
Обзор¶
FastMBO - внутренняя система для автоматизации процесса целеполагания, сбора оценочных листов, согласования достижений и расчёта премий по MBO-модели.
Проект возник из реальной операционной боли: процесс оценки сотрудников выполнялся вручную через бумажные бланки, Excel, повторные проверки, ручную оцифровку и перенос итогов в учётные системы.
Идея заключалась в том, чтобы заменить хрупкий ручной процесс небольшой внутренней ERP-like системой: сотрудники заполняют оценочные листы онлайн, руководители согласуют достижения, ответственные лица управляют периодами, а система рассчитывает баллы, цену балла и итоговые премии.
Контекст и проблема¶
Контекст¶
До автоматизации процесс был сильно зависим от ручной координации:
- оценочные листы готовились и распространялись вручную;
- сотрудники заполняли бумажные формы;
- руководители валидировали достижения и метрики;
- изменения приводили к повторным согласованиям и перепечаткам;
- баллы переносились в Excel;
- премии рассчитывались вручную;
- итоговые данные передавались в кадрово-бухгалтерский контур.
Проблема¶
Основные проблемы:
- высокая трудоёмкость подготовки и обработки оценочных листов;
- риск ошибок при переносе данных;
- сложность контроля статусов заполнения и согласования;
- отсутствие единой цифровой истории по периодам оценки;
- слабая прозрачность процесса для участников;
- зависимость от отдельных сотрудников, знающих порядок ручного расчёта.
Цели, требования и ограничения¶
Цели и нецели¶
Создать внутреннюю систему, которая переводит процесс MBO из ручного документооборота в управляемый цифровой контур.
Требования¶
Система должна была позволить:
- создавать и настраивать периоды оценки;
- управлять метриками и шаблонами достижений;
- формировать оценочные листы для сотрудников;
- поддерживать онлайн-заполнение;
- согласовывать достижения и метрики;
- автоматически рассчитывать сумму баллов, цену балла и размер премии;
- поддерживать ручные корректировки;
- публиковать результаты в личном кабинете;
- готовить выгрузку итогов для дальнейшей обработки.
Ограничения¶
Роль и обязанности¶
В этом проекте я выступал как проактивный системный аналитик и внутренний разработчик.
Мой вклад:
- увидел повторяющуюся операционную проблему и предложил автоматизацию;
- сформулировал концепцию внутренней MBO-системы;
- разобрал AS-IS процесс и предложил TO-BE процесс;
- собирал и уточнял требования у будущих пользователей;
- выделил основные роли, сущности, статусы и этапы процесса;
- спроектировал доменную модель и верхнеуровневую архитектуру;
- начал самостоятельную реализацию системы как Java/Spring-приложения;
- позднее восстановил BPMN, C4, ERD, ADR и экономическое обоснование для портфолио.
Модель системы¶
Доменная модель¶
Роли пользователей (акторы)¶
- Сотрудник - заполняет оценочный лист, добавляет достижения, просматривает результаты.
- Руководитель - согласует достижения и метрики подчинённых.
- Ответственное лицо - контролирует период, проверяет полноту и корректность данных.
- Директор - утверждает результаты и контролирует фонд премирования.
- Администратор системы - управляет настройками, пользователями, периодами и аудитом.
Модель данных¶
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.
Дорожная карта и демонстрация¶
Дорожная карта¶
Скриншоты и демо¶
Что демонстрирует проект¶
FastMBO показывает ранний этап моей профессиональной эволюции: от инфраструктурной роли к системному анализу, внутренней автоматизации и архитектурному мышлению.
Проект демонстрирует:
- способность увидеть операционную проблему и предложить автоматизацию;
- переход от ручного процесса к цифровому workflow;
- работу с ролями, статусами, периодами, расчётами и согласованием;
- понимание экономического эффекта от автоматизации;
- ранний опыт проектирования внутренней ERP-like системы;
- переход от «написать утилиту» к «спроектировать систему».