5 ошибок при составлении ТЗ на автоматизацию HR-процесса

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

В закладки

Мы в FORMATTA несколько лет внедряем IT-решения в HR и консультируем компании по вопросам автоматизации HR-процессов. В этой статье я собрал 5 типичных ошибок, которые делают заказчики при составлении ТЗ: наш опыт поможет вам сфокусироваться на главном, а вашему подрядчику — предложить оптимальное решение для автоматизации процесса.

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

Ошибка № 1. Описывать не процесс, а отдельные особенности системы

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

Опишите в ТЗ поэтапно весь процесс, который вы хотите автоматизировать

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

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

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

Ошибка №2. Не указывать цели и предпосылки проекта

Чтобы предложить лучшее решение, подрядчику важно знать, почему появилась потребность в автоматизации. Ситуации могут быть разные:

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

Укажите, чем обусловлен проект автоматизации — уже имеющимся негативным опытом или же стратегией на будущее

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

Ошибка №3. Указывать сроки внедрения без объяснения, к чему они привязаны

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

Укажите в ТЗ, чем обусловлены сроки проекта

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

Ошибка №4. Не указывать требования к проектному управлению и организации работ

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

Укажите все внутренние требования к IT-проектам, в том числе приведите примеры документов, которые нужно будет подготовить

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

Ошибка №5. Не прикладывать документы бизнес-процесса

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

Предоставьте файлы и формы, которые используете в процессе и хотите перенести в IT-систему. Или же опишите, чем они не устраивают вас на данный момент, если планируете в автоматизированном процессе использовать другие документы

{ "author_name": "Герман Коренблюм", "author_type": "self", "tags": [], "comments": 2, "likes": -1, "favorites": 9, "is_advertisement": false, "subsite_label": "services", "id": 126774, "is_wide": false, "is_ugc": true, "date": "Wed, 13 May 2020 15:42:16 +0300", "is_special": false }
IPQuorum
Развитие технологических стартапов в России: барьеры и возможности
Внедрение решений Индустрии 4.0 в крупных промышленных предприятиях тормозят не только кризис и условия пандемии…
Объявление на vc.ru
0
2 комментария
Популярные
По порядку
0

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

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

Ответить
1

Да, абсолютно верно. Этим мы и отличаемся, так как изначально мы консультанты и имеем большой опыт в оптимизации бизнес-процессов и во время автоматизации (наше новое направление) мы можем детально проанализировать процессы и предложить оптимальные варианты для клиента.

Ответить

Прямой эфир