Как обосновать инвестиции в IT-проект перед руководством

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

Хорошее обоснование строится от решения, которое нужно принять, а не от решения, которое уже выбрано.

1. Бизнес-задача, а не технология

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

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

2. Варианты, включая «ничего не делать»

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

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

Если какой-то вариант отклонён, укажите почему. Это снимает большую часть вопросов на защите.

3. Затраты — со всеми допущениями

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

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

4. Ожидаемый эффект и способ его проверить

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

5. Условия реализации и риски

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

6. Рекомендация и следующий шаг

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

Кто должен готовить обоснование

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