Автоматизация учета времени собирает табель по проектным задачам: события поступают из рабочих систем, получают категории, проходят согласование и проверку распределения часов. ИИ в этом контуре ищет аномалии, а утверждает табель руководитель. Граница принципиальна: контур помогает вести проектный учёт времени без скрытого мониторинга продуктивности сотрудников.
Круг табеля
Маршрут из пяти шагов: источник события, категория, согласование табеля, исключения, проверка распределения. Скрипт сверяет выгрузки, модель объясняет аномалии, руководитель подписывает итог.
Основу табеля составляют записи затраченного времени, которые вводит сотрудник или сохраняет разрешённый трекер. События из задач, календаря и репозитория помогают найти пропущенную работу, а длительность работы подтверждает запись времени. Запись для расчёта содержит проект, задачу, исполнителя, дату, длительность и категорию; сотрудник проверяет её до согласования. Скрипт выявляет записи без задачи, длительности или допустимой категории. Период в контуре закрывается в три прохода: сбор, согласование, утверждение. Каждый проход заканчивается артефактом: журнал, подписанный табель проекта, итоговая запись. Граница контура важна: учёт ведут по согласованным проектным работам без наблюдения за человеком. Сценарий проектного чат-бота со статусами и эскалациями разобран в материале про чат-бота для проектов; здесь же маршрут табеля.
В качестве понятного примера можно взять журнал работы Jira: официальная документация описывает, как сотрудник записывает время на задачу и при наличии прав исправляет запись. Коммит в репозитории или встреча в календаре показывают активность, а длительность проектной работы берут из подтверждённой записи времени. Если команда собирает табель для расчётов, она должна заранее определить, какие записи служат первичными, кто их подтверждает и какие данные доступны руководителю.
Участники контура: сотрудник, руководитель проекта, руководитель направления, бухгалтерия для расчётов. Роли фиксируются до запуска: кто подтверждает событие, кто согласует табель, кто утверждает исключения. Если утверждённые часы используются в расчётах, бухгалтерия получает только согласованные данные и пояснения к исключениям. Разбор аномалий остаётся у руководителей. Владелец контура утверждает источники и словарь категорий до тестового запуска. Конфигурация контура короткая: источники, словарь категорий, маршрут согласования. Новый участник входит в контур по этим трём артефактам.
Источники и категории
Записи времени и вспомогательные события получают из разрешённых систем: трекера задач, календаря и при необходимости репозитория или документооборота. Каждый источник подключается со служебной учётной записью, а разрешение на чтение согласует владелец системы и настраивает её администратор. Список прав читается перед каждым подключением: владелец подтверждает состав доступов. Список источников и прав хранится рядом с конфигурацией контура. Служебные записи заводятся с минимальными правами: чтение событий без доступа к содержимому документов. Права пересматриваются вместе с изменением контура. Новый источник подключается через владельца контура: заявка, проверка прав, запись в конфигурацию. Решения о доступах остаются прослеживаемыми.
- Перечислите системы с событиями: трекер, репозиторий, календарь, документы.
- Подключите каждую через служебную запись с минимальными правами.
- Составьте категории работ: разработка, аналитика, встречи, ожидание согласований.
- Зафиксируйте владельцев категорий и порядок добавления новых.
Категории работ утверждаются один раз и хранятся в словаре: код, название, примеры событий. Категории покрывают типы работ команды: разработка, аналитика, тестирование, встречи, ожидание согласований. Каждая категория имеет владельца и примеры событий — словарь читается без устных пояснений. Новая категория добавляется через заявку владельцу словаря: разбор событий, решение, запись с примерами. Прямые переименования в выгрузках запрещены регламентом. Категория «ожидание согласований» нужна, только если команда действительно учитывает такое время по правилам проекта. Период ожидания согласования может совпадать с другой задачей сотрудника, поэтому часы подтверждают отдельно. Скрипт раскладывает события по категориям по словарю, модель разбирает спорные случаи списком, владелец словаря подтверждает решения.
Сбор и согласование
Сбор событий идёт по расписанию: скрипт забирает выгрузки из источников и складывает их в единый журнал. Полные выгрузки обрабатываются скриптом: парсер нормализует строки, модель объясняет расхождения, человек сверяет итог. Расписание выгрузок хранится в конфигурации: источник, частота, владелец. Сбой источника определяют по ошибке подключения или расхождению с ожидаемой контрольной записью: пустая выгрузка сама по себе возможна в день без новых записей. Журнал событий версионируется: выгрузка, версия скрипта, результат нормализации. Разбор любой строки табеля опирается на запись журнала вместо воспоминаний. Сверка журнала с задачами выявляет записи времени без задачи и завершённые задачи без учтённых часов; второй случай требует уточнения, поскольку по некоторым задачам правила проекта могут исключать фиксацию часов. Обе сверки пишутся в один список расхождений.
- Настройте расписание выгрузок из каждого источника.
- Прогоните нормализацию событий по словарю категорий.
- Соберите проектный табель: задача, исполнитель, часы по категориям, пометки о спорных строках.
- Отправьте табель руководителю проекта на согласование.
- Запишите итоги согласования в журнал и передайте табель дальше.
Согласование строится на подтверждении: руководитель проекта сверяет табель с картиной работ и ставит статус. Расхождения с его картиной возвращаются с комментарием исполнителю и владельцу источника. Возвраты от руководителя получают статус: уточнение у исполнителя, исправление источника, исключение. Статус закрывается до следующего прохода согласования. Если расхождений нет, руководитель может утвердить табель за один проход. Спорные строки выносятся отдельно и закрываются до утверждения итога.
Аномалии и исключения
Проверка распределения ищет аномалии в записях часов: необычные длительности, пересечения интервалов, запись без проекта и пропуски в периодах, для которых команда ожидает учёт. Скрипт выписывает аномалии списком с координатами — дата, задача, категория, часы. Аномалии ранжируются по размеру отклонения: крупные попадают к руководителю первыми. Если правил немного, руководитель просматривает список отклонений и выборку обычных записей: после автоматической проверки нужен выборочный контроль. Повторяющиеся аномалии пополняют словарь проверок: новое правило сверки добавляется владельцем контура. Изменения правил фиксируют в конфигурации и проверяют на прошлых периодах. Модель получает таблицу аномалий; сырые выгрузки обрабатывает скрипт. Объяснения модели помечаются как гипотезы до подтверждения руководителем. Модель предлагает объяснения аномалий, подтверждение остаётся за руководителем.
| Аномалия | Как находит скрипт | Что решает руководитель |
|---|---|---|
| Всплеск часов по категории | Сравнение с типичным распределением | Подтвердить или вернуть с вопросом |
| События без проектной задачи | Сверка журнала с реестром задач | Отнести к исключению или задаче |
| Задача без событий | Обратная сверка реестра и журнала | Уточнить статус у исполнителя |
| Нет записей за период обязательного учёта | Календарь периода против журнала | Уточнить статус периода и первичные записи у сотрудника |
Исключения оформляют отдельно. Отпуск и больничный сверяют с разрешёнными кадровыми данными и помечают как отсутствие проектных часов; в проектный табель передают только необходимый статус отсутствия. Ожидание согласования учитывают только по правилам проекта и по подтверждённой записи сотрудника. Спорное распределение часов руководитель возвращает на уточнение с комментарием.
Как ищете аномалии в табеле вашей команды сейчас?
Утверждение табеля
Итоговый табель утверждает руководитель направления после двух проверок: согласование проектов чистое, аномалии разобраны. Утверждённый табель уходит в расчёты с пометкой о периоде и владельце подписи. Утверждение фиксируется в журнале решения: период, владелец, состав табеля, замечания. Архив утверждённых табелей ведётся по периодам: свежий табель читается из журнала, история — из архива. Разбор любого периода начинается с записи журнала. Откат на ручной учёт описывается в том же журнале до старта пилота. Старт автоматизации удобно ставить пилотным контуром: один проект, один период, тестовые выгрузки. Пилот — предложение формата: состав и критерии подбираются под вашу систему учёта. Критерии пилота пишут до старта: записи времени сопоставлены с задачами, расхождения разобраны, руководитель утвердил итог. Для оценки пользы сравнивают трудозатраты на подготовку и число исправлений с прежним ручным процессом. Расширение идёт по тем же критериям: чистое согласование, разобранные аномалии, подписанный итог. Формат пилотов и карт задач в смежных сценариях разобран в материале про автоматизацию рутины.
Соберите список источников и словарь категорий — этого хватает для первого контура. Прогоните прошлый период, сверьте табель с ручным эталоном и разберите аномалии с руководителями. Первый прогон делайте в присутствии руководителя направления: он сверяет словарь с реальной картиной работ. Критерии пилота: чистое согласование, разобранные аномалии, утверждённый табель без возвратов. Итог пилота сохраняют как пример правил и формата, но часы следующих периодов проверяют по новым первичным записям. Для контура с расписанием и приёмкой полезна помощь с аудитом и внедрением.