Техническое задание на аттестацию персонала: шаблон для запуска ИИ-экзаменатора

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

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

Шаблон ниже подходит для подготовки запроса предложений. Его нужно заполнить фактами о конкретном процессе и согласовать с HR, руководителями и специалистами по безопасности. Правила самой аттестации остаются во внутренних документах компании: техническое задание описывает, как система и подрядчик должны поддержать эти правила.

Что входит в техническое задание

ТЗ на систему аттестации описывает задачи проекта, участников, сценарии экзамена и ожидаемый результат работы подрядчика. В документе перечисляют исходные материалы, функции программы, ограничения и способы проверки. Его отправляют всем участникам отбора вместе с одинаковыми вводными и сроком подготовки предложения.

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

Полезно разделить обязательные условия и пожелания. Голосовой формат, утверждённая шкала и выгрузка результата могут быть обязательными, а дополнительный способ входа — желательным. Подрядчик отдельно укажет готовую функцию, доработку и её стоимость. Это снижает риск сравнить базовую поставку одного участника с расширенной поставкой другого.

Чем ТЗ отличается от положения об аттестации

Положение об аттестации персонала устанавливает внутренние правила компании, а ТЗ переводит нужные правила в требования к проекту. В положении могут быть описаны участники, периодичность, порядок уведомления и полномочия комиссии. Техническое задание не утверждает эти правила вместо работодателя и не заменяет локальные документы.

На настройки экзаменатора влияют утверждённые компетенции, допустимые попытки, проходной балл и порядок пересмотра оценки. Если положение предусматривает решение комиссии, система должна передать ей материалы для рассмотрения. Нельзя записать в ТЗ автоматическое увольнение по результату ИИ и считать это заменой установленной процедуры.

До закупки HR и юрист сверяют формулировки с действующими документами и трудовым законодательством. Если правила ещё не утверждены, в ТЗ отмечают зависимость проекта от их согласования. Подрядчик может помочь описать настройки, но не должен единолично определять последствия аттестации для сотрудников.

Что собрать до выбора подрядчика

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

По каждой группе определяют проверяемые компетенции и собирают доступные материалы: инструкции, действующие вопросы, примеры ответов и критерии оценки. Отдельно отмечают пробелы. Например, подрядчик должен знать, получит ли он готовую базу или сначала потребуется работа с экспертами заказчика.

Ограничения по срокам связывают с конкретным событием, например запуском ежегодной аттестации. Владельцы процесса согласуют состав групп, формат и ожидаемый результат до отправки запроса. Если решение по интеграциям или хранению ещё не принято, в ТЗ фиксируют открытый вопрос и срок, когда компания даст ответ.

Требования к ИИ-экзаменатору и сценарию

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

Сценарий должен объяснять, что происходит после полного, неполного или неясного ответа. Например, экзаменатор может один раз повторить вопрос, а при недостатке сведений задать уточнение по утверждённой теме. В ТЗ стоит ограничить число уточнений и указать, когда система переходит к следующему заданию.

Для ветвления задают понятные условия: при выборе сотрудником определённого варианта система переходит к соответствующему кейсу. Нужно также описать паузу, потерю связи и прерывание сессии. Заказчик решает, можно ли продолжить попытку с места остановки или её должен заново назначить ответственный сотрудник.

Готовность функции проверяют на примерах, а не по общей фразе «система поддерживает сценарии». В ТЗ можно включить тест: сотрудник даёт неполный ответ, получает допустимое уточнение и завершает экзамен. Для каждого теста указывают входные условия, ожидаемое поведение и того, кто принимает результат.

Роли, доступы и ответственность

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

Администратор управляет учётными записями и техническими настройками. Это право не обязано включать изменение оценок или утверждение вопросов. Аттестуемый сотрудник проходит назначенный экзамен и получает сведения, предусмотренные внутренними правилами. Доступ к чужим ответам для этой роли не нужен.

Для подрядчика указывают, кто получает доступ на этапе внедрения, к каким материалам и на какой срок. В ТЗ полезно запросить журнал действий и порядок отзыва прав после завершения работ. Владелец процесса со стороны заказчика утверждает роли, а технический специалист проверяет, что ограничения действительно работают.

Как подготовить базу вопросов

База вопросов связывает каждое задание с компетенцией, темой и уровнем сложности. Для закрытого вопроса фиксируют правильный ответ, для открытого — признаки содержательного ответа и допустимые ошибки. Ещё нужны идентификатор, автор, статус согласования и дата вступления версии в действие.

В ТЗ описывают формат исходных файлов и способ загрузки материалов. Например, заказчик передаёт таблицу с полями «компетенция», «вопрос» и «критерии», а подрядчик сообщает о строках, которые система не приняла. Если перенос требует ручной работы, предложение должно отдельно показывать её объём и стоимость.

Редактирование вопросов нужно отделить от их утверждения. Например, методист службы обучения обновляет формулировку после изменения инструкции, а руководитель направления проверяет и утверждает её. До согласования новая версия не попадает в действующий экзамен. Такие права и маршрут изменения стоит записать в ТЗ.

Версионирование позволяет понять, по каким материалам оценили конкретного сотрудника. В требованиях указывают, как сохраняются прежние версии и можно ли связать результат с использованным набором вопросов. Это особенно важно, если проходной уровень или содержание задания меняются между аттестационными периодами.

Шкала оценки и проверка результата

Шкала оценки должна показывать, за что сотрудник получает баллы и какой результат считается проходным. Для каждой компетенции задают критерии и вес, если одни навыки важнее других. Пример формулировки для ТЗ: «Показывать балл по каждой компетенции и итог с учётом утверждённых весов».

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

Оценка ОЭСР помогает увидеть контекст изменения рабочих задач, но не задаёт проходной балл для компании. Его определяют владельцы компетенций и утверждают по внутренним правилам. Перед запуском полезно проверить шкалу на примерах ответов разного уровня и обсудить расхождения с экспертами.

В карточке результата проверяющему могут понадобиться запись, расшифровка, вопрос, балл и обоснование по критериям. В ТЗ отдельно описывают порядок исправления ошибок и пересмотра спорных ответов. Автоматическая оценка системы не подменяет решение уполномоченного сотрудника или комиссии, если оно предусмотрено процессом.

Интеграции, хранение и безопасность

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

Интеграция с CRM нужна не каждому проекту. Она может пригодиться, если результаты проверки навыков отдела продаж должны быть доступны в связанной карточке. LMS, то есть система управления обучением, может получать сведения о пробелах для назначения курса. Возможность и состав передачи подрядчик подтверждает отдельно.

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

Какая отчётность нужна HR и руководителям

Отчётность для HR начинается со списка приглашённых, статусов прохождения и числа незавершённых попыток. Полезно предусмотреть отбор по подразделению, должности и периоду, а также выгрузку результатов в согласованном формате. В ТЗ стоит привести пример отчёта и указать, какие поля должны попасть в файл.

Руководителю подразделения важнее результаты своей команды по компетенциям и изменения между сопоставимыми периодами. При сравнении нужно учитывать состав группы и версию шкалы: иначе рост балла может объясняться изменением экзамена. Доступность нужных срезов и выгрузок подрядчик подтверждает в предложении.

Прогноз форума не означает, что навыки каждой команды изменятся на ту же величину. Для отчёта компании важнее собственные критерии и история их изменений. При пересмотре компетенций HR может сохранить прежний результат отдельно и указать, какие показатели больше нельзя напрямую сравнивать.

Сроки внедрения, тестирование и приёмка

Сроки внедрения зависят от готовности материалов, числа сценариев, интеграций и согласований. В ТЗ лучше запросить календарный план с условиями, а не назначать универсальный срок. Подрядчик должен указать, когда ему нужны вопросы, доступ к тестовой среде и решения со стороны заказчика.

План проекта обычно включает сбор требований, настройку сценария, тестирование, обучение пользователей и запуск. Для каждого этапа фиксируют результат и ответственных с обеих сторон. Например, обучение считают завершённым после передачи инструкции и проведения согласованной демонстрации для администраторов и HR.

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

Как сравнить предложения подрядчиков

Сравнение решений для аттестации строят на одинаковом наборе требований и проверяемых ответах. Каждый подрядчик должен указать, что доступно сразу, что потребует доработки и что не поддерживается. Полезно попросить не только описание функции, но и условия её демонстрации на примере заказчика.

Стоимость сравнивают вместе с объёмом поставки. В одном предложении перенос вопросов и обучение могут входить в цену, в другом — оплачиваться отдельно. Стоит запросить раздельную стоимость запуска, доработок, интеграций и поддержки. Также важно выяснить, какие действия команда заказчика выполняет своими силами.

Чек-лист проверки предложения

1. Функции и ограничения — Подрядчик перечислил доступные функции, доработки, неподдерживаемые сценарии и способ проверки каждого обязательного требования.
2. Материалы и ответственность — Указано, кто готовит вопросы, утверждает критерии, настраивает роли и предоставляет доступы.
3. Сроки и зависимости — Есть этапы, сроки, необходимые входные материалы и порядок изменения плана при задержках.
4. Приёмка и поддержка — Описаны тесты, порядок устранения замечаний, условия поддержки и отдельные платежи.
5. Работа с данными — Согласованы хранение, права доступа, передача сведений и возврат материалов после завершения договора.

ИИ-аттестацию OrbitAI с голосовым ИИ-экзаменатором можно включить в список решений для изучения наряду с другими предложениями. Состав конкретных функций, интеграций и условия проекта нужно уточнять у поставщика и проверять по тому же ТЗ. Без одинаковой демонстрации и расчёта стоимости объявлять победителя рано.

Что проверить перед отправкой ТЗ

Перед запросом предложений владелец процесса проверяет, что обязательные требования согласованы, исходные материалы перечислены, а открытые решения отмечены отдельно. Каждому подрядчику отправляют одну версию документа и одинаковые примеры. Ответы удобно заносить в общую таблицу с пометками о подтверждении и ограничениях.