Как я почти на полгода затянул запуск проекта перед Инвестиционным комитетом — и что понял об ошибке

В прошлой статье я разбирал ИИ-агента для сверки сделок — это был кейс с гладкой защитой перед Инвестиционным комитетом. Сегодня — про другой проект, PIX BI, где я допустил управленческую ошибку и получил единственное «против» на голосовании вместо единогласного «За». Это внешнее коммерческое BI-решение, поэтому его легко нагуглить — не буду скрывать название, а вот сам разбор процесса защиты и ошибки, думаю, полезен независимо от того, какой конкретно продукт вы внедряете.

● Как устроен процесс защиты бюджета

● Кейс: как я выбирал и защищал PIX BI

● Ошибка, которая стоила полгода

● Кто и что спрашивает на Инвестиционном комитете

● Что изменилось после провала

● Что Инвестиционный комитет требует всегда

● Выводы

Схема простая и, наверное, типовая для многих компаний: сначала готовятся материалы для защиты — бизнес-кейс, финансовая модель, презентация. Дальше — само заседание Инвестиционного комитета (ИК), где проект защищается перед его членами. По итогам — решение о финансировании: да, нет, или доработать и вернуться.

Дьявол, как обычно, в деталях — и лучше всего это видно на конкретном кейсе.

Всё началось со сбора потребностей. Я ходил по структурным подразделениям и спрашивал: какие отчёты вы готовите? Хотели бы их автоматизировать? С какой периодичностью обновляете данные? Какие источники используете? По итогам собрал таблицу потребностей по каждому подразделению — с указанием сроков обновления данных, значимости и срочности по каждому отчёту.

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

После выбора решения — определение команды внедрения и оценка стоимости проекта: ФОТ команды, капитальные и операционные затраты. Дальше — эффекты, риски, финансовая модель и презентация к защите на Инвестиционном комитете.

А вот дальше я допустил решение, которое обошлось в лишние полгода. Я захотел совместить внутренний проект внедрения PIX BI с амбициозной коммерческой идеей — сформировать в компании центр компетенций по внедрению BI-систем. Мотивация была понятной: в группе компаний ощущался дефицит компетенций по BI, и я хотел занять эту нишу — вывести направление на самоокупаемость, получить выручку и дополнительно повысить доверие топ-менеджмента материнской компании к моей команде на будущих, более крупных проектах.

Я провёл аналитику рыночного спроса на BI-внедрения, сузил её до контекста PIX BI, сформировал потенциальные лиды на внедрение собственными силами и заложил примерную выручку прямо в финансовую модель проекта — вместе со сроком окупаемости и дополнительными эффектами от такого расширения.

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

Состав комитета в моей компании был такой:
●Генеральный директор
●Финансовый директор
●Директор по цифровому бизнесу
●Заместитель генерального директора (ИБ, серверы, техническая инфраструктура)
●Главный бухгалтер
●Представитель инвестиционного блока материнской компании
●Заместитель генерального директора по бизнес-развитию

Вопросы, которые звучали на защите:
● Почему именно PIX BI, а не одно из множества других решений на российском рынке?
● Какая архитектура решения?
● Как обеспечивается безопасность данных с точки зрения ИБ?
● Как рассчитана экономика проекта?
● Откуда взялись лиды на коммерческое внедрение?
● Как эти лиды верифицированы и обоснованы?
● В чём значимость проекта для компании?

На большинство вопросов я ответил без проблем, и по самому факту внедрения PIX BI возражений не было — все члены комитета были «за». Пробуксовка случилась именно на вопросах про выручку от коммерциализации: директор по цифровому бизнесу начал последовательно спрашивать про верификацию лидов, источники выручки и оценку рынка. На мои ответы отреагировал отрицательно — доверия к цифрам по выручке не возникло. Итог: единственное «против» вместо единогласного «за».

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

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

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

Независимо от конкретного проекта, в моей практике ИК неизменно требовал:
● Бизнес-план на весь срок проекта — или на 5 лет, если решение бессрочное
● Рентабельность инвестиций (ROI) и срок окупаемости как ключевые показатели
● Поэтапный план внедрения
● Риски и меры по их снижению
● Альтернативные варианты решения и обоснование выбора

По сути — всё, что делает проект прозрачным и проверяемым, а не «просто доверьтесь мне».

● Не смешивайте внутренний проект с коммерческой амбицией в одной защите — даже если это кажется рациональным. Разные типы решений требуют разных типов доказательств.

● Для коммерческого довода одной аналитики рынка недостаточно — нужен подтверждённый спрос: контракт, письменная заявка, прямой запрос от смежной структуры.

● Если в комитете есть скептик по конкретному узкому вопросу — стоит поговорить с ним отдельно после заседания, а не считать голосование финальной точкой в диалоге.

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

В одной из следующих статей разберу, как устроен PMO, который пришлось строить с нуля — без готовой методологии со стороны компании.