Кто пишет техническое задание? Пользователи или технические специалисты, сторонние аналитики или представители вендора выбранной системы? Разбираемся, чья это работа и можно ли написать так, чтобы все были довольны?
Хорошее техническое задание – залог успешного внедрения. На этом этапе вы определяетесь «на берегу», что ваши сотрудники хотят от системы, а технические специалисты обозначают, как можно решить эти задачи в рамках существующих технических ограничений. Техническое задание –это документальная фиксация итога вашего большого путешествия в цифровизацию, без него будет просто не понятно, что цифровое будущее наступило. Кроме идеологической цели, ТЗ еще и помогает соблюсти баланс между бюджетом и функциональностью будущего решения.
Кто может писать ТЗ? Будущие бизнес-пользователи, ИТ-специалисты и внешние аналитики. Посмотрим на плюсы и ограничения каждого варианта.
Бизнес-пользователи.
Кто знает процедуру согласования договора лучше юристов? Кто понимает, как согласовывается счет-фактура, если не бухгалтер? Логично предоставить описания будущей системы им, потому что они будут ее использовать и их удобство превыше всего. С точки зрения бизнес-процессов, это оптимальное решение, но с технической стороны могут возникнуть ограничения:
- Излишняя детализация описания: пользователям хочется сделать свою работу максимально удобной и избавиться от рутины, поэтому они готовы буквально переложить всю свою работу на систему и описывают процесс со всеми подробностями;
- Упор на функциональность существующей системы: Сотрудникам без технического образования сложно мыслить абстрактными категориями, поэтому они опираются на знакомые паттерны и используют принятые сущности (отчет, карточка документа, задача, график). Те же потребности могут быть закрыты в новой системе другим путем, а реализация функциональности старой системы обычно ни к чему хорошему не приводит (это дорого, долго, нарушает логику работы системы и лишает ее всех преимуществ);
- Недостаточно подробное описание требований: юристу кажется, что его работа проста и прозрачна и не требует детализации, поэтому он просто указывает виды договоров, с которыми работает. Представители вендора оценивают проект, бюджет устраивает заказчика. Все довольны до опытно-промышленной эксплуатации, когда выясняется, что за каждым видом стоит сложная логика согласования. Здесь остается два пути: увеличить стоимость системы и доработать ее, оставить как есть и получить не полнофункциональное решение.
ИТ-специалисты
Они понимают логику работы существующей системы, настраивали все процессы, видели работу изнутри. Что может пойти не так? В область их интересов входят: масштабируемость системы, безопасность данных, интеграция с существующим ПО и встраивание в ИТ-ландшафт, серверные мощности и легкое сопровождение. А остальные важные детали могут быть легко упущены. Например, подробности бизнес-процессов, конкретные бизнес-задачи и «реальные боли» пользователей.
Сторонние аналитики
Они знают все о теории бизнес-процессов, могут непредвзято оценить существующие порядки в компании и предложить пути оптимизации. Аналитики могут понять потребность пользователей и соотнести ее с функциональностью системы наиболее оптимальным способом, предложить самое эффективное компромиссное решение.
Ок, как сделать, чтобы все были довольны?
Привлекайте всех. Не всех сотрудников, разумеется, а представителей всех заинтересованных в цифровизации отделов. Позаботьтесь о присутствии ИТ-специалистов и бизнес-пользователей.
Ограничьте рамки проекта и круг цифровизации: укажите конкретные виды документов, процессы, ответственных. Не выходите за рамки, это позволит сконцентрироваться и достичь максимальной эффективности, оставшись в заложенном бюджете.
#техническое задание #цифровизация #бизнес #документы #внедрение #управление проектами