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