Оценка ИТ‑проекта до старта работ: как спрогнозировать бюджет и сроки

Что такое оценка проекта

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

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

Какие выгоды получает бизнес, заказывая оценку проекта:

• знакомство с командой ИТ‑подрядчика дает понимание, как будет строиться взаимодействие в дальнейшем на проекте, насколько комфортным окажется сотрудничество;
• предпроектный анализ подсвечивает потенциальные риски и нюансы;
• возможность совершить референс‑визит к действующим клиентам подрядчика и узнать от первого лица, как используется продукт в боевых условиях;
• помощь в планировании проекта — выделении укрупненных стадий, сроков и результатов, которые должны быть достигнуты;
• получает документ, в котором расписан бюджет на реализацию желаемого функционала, указаны примерные сроки и скоуп проекта (четко определенные границы работ).

Первым делом — определить рамки проекта

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

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

Что если клиент дает мало вводных, не описывает бизнес‑задачу, а только говорит, что ему нужно автоматизировать некий функциональный блок (например, Demand planning — планирование спроса)? В таком случае оценка будет носить индикативный характер и в итоге будет представлена вилка стоимости внедрения конкретного модуля.

Список вопросов, чтобы «разговорить» клиента

Для анкетирования используем открытые вопросы. Ниже приведем примеры, которые используем в собственной практике:

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

Как выглядит оценка проекта

В «ОптиТим Консалтинг» процесс включает следующие шаги:

• наладить коммуникацию с клиентом;
• продемонстрировать функциональные возможности ИТ‑решения, например, с помощью демостенда;
• обсудить реализованные кейсы и организовать референсы;
• получить вводные данные от клиента (функциональные требования, техническое задание, укрупненную постановку задачи и т.п.);
• подключить экспертов из консалтинга (партнеров, проектных менеджеров, архитекторов, бизнес‑аналитиков) для анализа полученных вводных;
• при необходимости предоставить первую индикативную оценку (например вилку цен, без конкретики);
• при необходимости организовать встречу с командой заказчика и экспертами консалтинга, чтобы обсудить вводные по проекту, уточнить вопросы, поделиться опытом и экспертизой, совместно заполнить опросник;
• сформировать оценку проекта и составить коммерческое предложение;
• встретиться с клиентом для защиты КП и обсуждения дальнейших шагов.

Кто занимается оценкой

В зависимости от стадии пресейла оценку проводят разные сотрудники. Это командная работа, к которой привлекаются специалисты с релевантным опытом. Например, оценка лицензий лежит на плечах Business Development Manager. Оценка внедрения обычно формируется командой консалтинга. Драфт оценки (этапы, сроки, допущения и ограничения, стоимость работ) готовит эксперт, за плечами которого уже есть подобный опыт. Он же выделяет ключевые моменты проекта и согласовывает всё с руководством.

Сколько времени занимает оценка

Всё зависит от объема и качества вводных данных, количества необходимых стримов, сложности задачи. Так, если заказчику требуется реализовать сразу несколько функциональных блоков (Demand, Promo, Supply, MRP, Delivery, Production Planning, Production Schedulling, Finance, S&OP), потребуется расширить круг экспертов для оценки, объем изучаемых материалов, совместных встреч. Следовательно, сроки формирования оценки тоже увеличатся.

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

Какие инструменты используются для оценки

Иногда для формирования оценки требуется навык построения схем (архитектурных, функциональных), чтобы визуально показать клиенту объем, сложность и специфику проводимых работ.

Также, когда необходимо сформировать требования к серверам, может использоваться расчет (прогноз) сайзинга моделей.

Важность отраслевой специфики

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

В зависимости от отрасли, к которой принадлежит бизнес клиента, потребуется выполнять специфические задачи. Например, использовать оптимизатор — специальный модуль в Optimacros, который помогает решать оптимизационные задачи — максимизацию/минимизацию целевой функции через перебор аргументов в рамках заданных ограничений. Следовательно, набор вопросов для клиента будет иным — с уклоном в сторону размерности задачи, алгоритмов и так далее. Аналогично, если обсуждать ML — то также уклон в сторону количества данных, их полноты, структуры, готовности, алгоритмов (моделей) и так далее.

Пример из практики: оценка ИТ‑проекта для FMCG‑компании

1. Мы получили от клиента список пожеланий — функциональных и нефункциональных требований по автоматизации двух блоков Demand Planning (прогнозирование спроса) и Promo (промомаркетинг). Ознакомившись со списком пожеланий, мы подготовили вопросы и направили их клиенту для письменных ответов.
2. Получив драфт и погрузившись в проблематику кейса, наша команда организовала первую встречу с представителями клиента для уточнения требований. Всего потребовалось два созвона и одна живая встреча с ключевыми специалистами для того, чтобы собрать всю необходимую информацию для оценки проекта.
3. На основе полученной конкретизированной информации мы провели оценку проекта, в которой в том числе прописали допущения и ограничения, и сформировали коммерческое предложение на работы.
4. Далее помогли коллегам подготовить презентацию для внутренней защиты перед ЛПР‑ами и совместно с ними приняли участие в процедуре защиты.
5. После состоялась встреча‑знакомство команды клиента с командой подрядчика. Часть сотрудников «ОптиТим Консалтинг» присутствовала в офисе, а часть подключилась онлайн. Во время беседы мы рассказали о внедряемом продукте — CPM/IBP‑платформе Optimacros, о членах команды, их экспертизе, опыте работы. В результате клиент принял решение в нашу пользу.

Памятка для компаний, которые планируют запустить проект автоматизации

1. Сформулируйте ожидания от проекта и определите место предполагаемого решения в вашей ИТ‑инфраструктуре (сроки, бюджет, список функциональных требований).
2. Выделите зоны ответственности между представителями ИТ и бизнес‑командой, в том числе распределите ее между стримами (если проект предполагает несколько стримов).
3. Подготовьте методологическую базу по процессам (при наличии готовой методологии).
4. Соберите данные из сторонних систем для дальнейшей интеграции с предполагаемым ИТ‑решением. Данные должны быть «чистыми» (без смысловых ошибок, спецсимволов и прочего). На этом этапе можно сформировать список предполагаемых витрин данных для интеграций, их источников, размерностей (количество строк), количество и типы данных в столбцах, а дальнейшую подготовку отложить на первые стадии проекта.
5. Обратитесь к ИТ‑подрядчику для оценки будущего проекта и передайте ему упомянутый выше список вводных.