7.7 KiB
Подсистема D «Компетенции сотрудников» — Design Draft
| Дата | 2026-05-13 |
| Статус | Draft — может реализовываться параллельно с MVP-2/3 или после |
| Зависимости | MVP-1 (есть core.work_log + core.employee + core.project) |
| Срок | 1-2 недели работы (зависит от того, насколько детально нужен механизм распределения) |
Назначение: зафиксировать обсуждённый подход к компетенциям. Это набросок.
Ключевое решение пользователя
Цитата: «таблицу по компетенциям возможно придется собирать по проделанным зафиксированным работам в БИТ.РА, портфолио проектов возможно тоже».
Why: ручное ведение справочника компетенций сотрудников — нерабочая практика (устаревает, субъективно, никто не обновляет). Объективная компетенция = что человек реально делал в последний период.
См. identity-and-scope.
Цели Подсистемы D
- Автоматически рассчитать матрицу «сотрудник × компетенция × уровень» на основе истории работ.
- Использовать матрицу для:
- Подсказки распределения проектной команды Битрикс-сделок на конкретных сотрудников (улучшение MVP-1 — сейчас наивно поровну).
- Автоматического распределения SD-задач по компетенциям (бэклог-айтем MVP-2).
- Подсказки руководителю «кто свободен и умеет делать X».
Что такое «компетенция» в нашем контексте
Двухмерное определение:
- Конфигурация = с каким продуктом сотрудник работал (1С:ERP, 1С:ЗУП, БИТ.ФИНАНС, и т.д.). Берём из
core.project.bitra_id→BIT.RA.Catalog.Проекты.Конфигурация(Catalog.Конфигурации). - ВидРаботы = что делал (ЛУРВ / ЛТ / ИТС / Пресейл и т.п.). Берём из
core.work_log.work_type_code(см. reference-bitra-work-types).
То есть компетенция = пара (Конфигурация × ВидРаботы).
Расчёт уровня компетенции
weight(employee, config, work_type, period) =
Σ(hours) where work_log.employee = employee
AND work_log.project.config = config
AND work_log.work_type = work_type
AND work_log.period >= period - 12 months
Уровень владения = относительный вес:
- «Эксперт» — > 100 часов за последние 12 мес.
- «Опытный» — 30-100 часов.
- «Знаком» — 5-30 часов.
- «Нет опыта» — < 5 часов.
Пороги — конфигурируемые в core.config.
Расширение core
core.employee_competence (
employee_id bigint REFERENCES core.employee,
config_code text, -- Конфигурация (1С:ERP, БИТ.ФИНАНС и т.д.)
work_type_code text, -- Вид работ
hours_12m decimal(15,2), -- часы за последние 12 месяцев
hours_3m decimal(15,2), -- за последние 3 месяца (для свежей картины)
level text, -- эксперт | опытный | знаком | нет_опыта
last_work_date date, -- когда последний раз делал
PRIMARY KEY (employee_id, config_code, work_type_code)
)
Заполняется materialized view'хой, обновляется раз в сутки (после ежедневной синхронизации BIT.RA).
Применение в системе
1. Распределение проектной команды сделок Битрикс (улучшение MVP-1)
Сейчас (MVP-1): часы делятся поровну между членами UF_CRM_1729244690 (проектная команда).
С компетенциями (улучшение): часы распределяются с учётом уровня компетенции каждого члена команды по Конфигурации сделки (UF_CRM_1729244070). Эксперт получает больше, новичок — меньше. Веса можно править в NocoDB вручную.
2. Автоматическое распределение SD-задач (бэклог-айтем)
В SD-задачах часто нужно быстро назначить исполнителя. Если задача относится к 1С:ERP (по cf_konfiguracziya1), система предлагает топ-3 сотрудника с подходящей компетенцией и низкой текущей загрузкой.
3. Дашборд «Компетенции команды»
Витрина mart.competence_matrix:
- Heatmap: сотрудники × Конфигурации, цвет = уровень компетенции.
- Таблица «Узкие места» — конфигурации, по которым у компании только 1 эксперт.
- Таблица «Покрытие команды» — какие компетенции есть в команде, какие нет.
Open questions
- Маппинг
Catalog.КонфигурацииBIT.RA ↔ BitrixUF_CRM_1729244070— это разные справочники, но семантически похожие. Нужна ручная таблица соответствий вcore.identity_map_config. См. также reference-bitrix24-classifications. - Учёт пресейла как компетенции. Если сотрудник делал только пресейл по конфигурации (без ЛУРВ/ЛТ) — он эксперт по продаже, но не по реализации. Различать.
- Перевод сотрудника — если человек 5 лет делал 1С:Розница, потом переключился на 1С:ERP, окно «12 месяцев» это покажет, но текущая компетенция = ERP. Можно добавить «свежесть» (hours_3m).
- Подсистема D vs MVP-2. Если автоматическое распределение SD-задач нужно как часть MVP-2 — D становится зависимостью MVP-2. Если как улучшение MVP-1 — параллельно с MVP-2. Решить после MVP-1.
Зависимости от MVP-1
Подсистема D стартует когда:
- ✅ MVP-1 работает.
- ✅
core.work_logстабильно заполняется из BIT.RA. - ✅
core.projectмаппится с конфигурациями (черезCatalog.Проекты.Конфигурация).