На первый взгляд, если заказчик программного обеспечения точно знает, чего он хочет, и оформляет это в подробном документе на 100-150 страниц, то это самый эффективный подход к выбору решения. Ему достаточно будет пройтись по рынку и «приложить» свое техническое задание к существующим информационным системам. Ту, которая будет соответствовать ТЗ, заказчик и выберет. Теоретически. А на практике?
| С потенциальным заказчиком, одним из ведущих агрохолдингов России, мы ведем переговоры уже более трех лет. Почему так долго? Заказчик хочет приобрести «коробочную», т.е. готовую, электронную торговую площадку, но за это время так и не нашел ту, которая на 100% соответствует его техническому заданию. Таких просто нет на рынке. А платить за доработки заказчик не хочет. |
Получается, что компания сначала потратила деньги на разработку подробного ТЗ, а потом теряет время на поиск несуществующего идеала.
Значительная часть требований технического задания – это описание решений, а не проблем. Клиент сам придумал, как должна работать система, чтобы она решала его бизнес-задачи. Но это вовсе не значит, что его решение самое эффективное.
Гораздо выгоднее подключить к созданию ТЗ потенциального подрядчика — разработчика программного обеспечения. У него уже есть опыт внедрения десятков таких систем, и его опыт поиска самых удобных и выгодных вариантов решений задач заказчика может быть очень полезен.
Система управления закупками и поставщиками
- добиться снижения цен поставщиков
- автоматизировать рутинные операции закупщиков
- повысить надежность и прозрачность закупок
Главное, что должен сделать заказчик при совместной разработке технического задания – составить перечень функциональных требований. Его можно дополнить формализованным описанием бизнес-процесса, в виде текста или блок-схемы.
| Пункты функциональных требований | Чем это поможет | |
| 1 | Есть требования к API и документация с описанием работы с ними | У вас появится возможность интегрировать систему управления закупками с другими информационными системами — причем, без участия разработчика |
| 2 | Есть схема бизнес-процесса, который нужно автоматизировать. В бизнес-процессе выделены обязательные и необязательные этапы — с учетом того, что от необязательных можно безболезненно отказаться | Вы можете максимально точно представить, насколько информационная система соответствует вашему бизнес-процессу, какие доработки вас ожидают и ожидают ли вообще. Появляется возможность проверить соответствие информационной системы в коробочном виде схеме бизнес-процесса |
| 3 | Есть краткое описание обязательных этапов бизнес-процесса | Позволяет детально определить, способна ли информационная система поддерживать бизнес-процесс, сформулировать |
| 4 | Есть краткое описание результатов каждого обязательного этапа бизнес-процесса | Позволяет понять, как в информационной системе происходит переход от этапа к этапу и сравнить этот алгоритм с алгоритмом бизнес-процесса, который будет автоматизирован |
| 5 | Описаны роли пользователей. Лучше, если формат описания будет иметь вид матрицы RACI | Помогает формализовать работу участников бизнес-процесса, распределить их права и обязанности в информационной системе |
| 6 | Описание измеримых эффектов внедрения информационной системы | Возможность измерить результаты позволяет объективно оценить, насколько успешным было внедрение: например, увидеть, что закупки стали проводиться быстрее, а ошибки при оформлении заявок на закупки исчезли. В идеале — измерять эффект может не только заказчик, но и разработчик. Так он сможет предложить корректировки в работе информационной системы для достижения или улучшения ожидаемого эффекта. |
Значимость каждого требования может быть разной — поэтому оценка соответствия программного продукта функциональным требованиям возможна только после их ранжирования. Нужно разделить требования на важные, не важные и те, которыми можно пренебречь. Сделать это можно вместе с разработчиком: по тому же принципу, по которому дорабатывается техническое задание.
Пример блок-схемы, которая описывает бизнес-процесс заказчика
Простой алгоритм совместной доработки ТЗ включает в себя:
- Составление списка требований к системе.
- Pазделение требований из задания на обязательные и необязательные.
- Фильтрацию необязательных требований на нужные (их реализуют в будущем) и ненужные (от них отказываются навсегда).
- Сравнение списка необязательных требований с планом развития информационной системы — возможно, то, что заказчик требует сейчас, уже включено в будущие релизы.
- Сравнение стоимости информационной системы «по версии в ТЗ заказчика» и по новой версии ТЗ.
Подведем итоги:
Готовое многостраничное ТЗ не гарантирует 100% результат, зато совершенно точно заставит заказчика потратить деньги и время. Поэтому лучший вариант — составлять ТЗ вместе с потенциальным подрядчиком. А чтобы он не блуждал впотьмах, нужно предоставить ему перечень функциональных требований к ПО: на их подготовку уйдет в разы меньше времени, чем на составление подробного ТЗ.
Узнайте больше о возможностях решений для автоматизации закупок
SRM система — что это? Supplier Relationship Management System или управление взаимоотношениями с поставщиками
Стратегическое управление закупками или как повысить эффективность
