Крупный ретейлер завершил пилот корпоративной WMS-системы. Результаты выглядели неплохо: складские операции ускорились, ошибки сократились. Руководство решило масштабировать. Через полгода выяснилось: при нагрузке на 12 складов система не выдерживает, пользователи саботируют новый интерфейс, а 15 млн рублей уже потрачены. Причина — решение о масштабировании принималось на основе интуиции, а не структурированного Go/No-Go фреймворка.
Эта история — не исключение. По данным Gartner, 60% корпоративных пилотов масштабируются преждевременно, потому что у команды нет формализованных критериев go no go IT проект. Решение «масштабируем» или «останавливаем» принимается эмоционально: «пользователям понравилось», «директор хочет быстрее», «конкурент уже запустил». В результате компании теряют бюджеты на проектах, которые следовало остановить или доработать. Особенно болезненно это выглядит в enterprise-сегменте, где цена ошибки измеряется десятками миллионов рублей и месяцами упущенного времени.
В этой статье — готовый фреймворк решений после пилота: матрица критериев, скоринговая модель и алгоритм для комитета, который превращает субъективное «вроде работает» в обоснованное инвестиционное решение.
Почему интуиция — худший инструмент для решения о масштабировании
Пилотный проект длится 6-8 недель. За это время команда эмоционально привязывается к продукту. Она потратила силы, показала промежуточные результаты руководству, получила одобрение. Признать, что пилот провалился, психологически сложно. Именно поэтому субъективные решения о масштабировании чаще всего дают ответ «Go» — даже когда данные говорят обратное.
Go/No-Go decision framework решает три проблемы одновременно:
- Убирает когнитивные искажения — решение основано на заранее определённых критериях, а не на впечатлениях
- Снижает политические риски — никто не обвинит конкретного руководителя, если решение принято коллегиально по формализованной модели
- Ускоряет процесс — вместо трёх недель обсуждений на совещаниях, комитет проводит скоринг за 2-3 часа
Однако фреймворк работает только в том случае, если критерии и пороговые значения определены до начала пилотного тестирования. Иначе возникает соблазн подбирать критерии под желаемый результат. А это — прямой путь к повторению ошибки из начала статьи.
Фреймворк Go/No-Go: матрица критериев и скоринговая модель
Структура фреймворка строится на четырёх измерениях. Каждое отвечает на свой вопрос — и все четыре ответа вместе дают итоговое решение.
Четыре измерения Go/No-Go
ИзмерениеКлючевой вопросВес в итоговом скорингеКто оценивает
Техническая готовностьВыдержит ли система промышленную нагрузку?25%CTO / техлид Бизнес-эффектПодтвердил ли пилот экономическую гипотезу?30%CFO / бизнес-аналитик Пользовательское принятиеГотовы ли сотрудники работать в системе каждый день?25%Продакт-менеджер / HR Организационная готовностьЕсть ли ресурсы, процессы и бюджет на масштабирование?20%COO / PMO
Почему именно четыре, а не три? Большинство команд забывают про организационную готовность. Продукт может быть технически стабильным, экономически выгодным и пользователям нравиться — но если в компании нет ресурсов на обучение 500 человек, масштабирование всё равно провалится.
Скоринговая модель: от данных к решению
Каждый критерий внутри измерения оценивается по шкале 0-3:
БаллЗначениеОписание
3Превышает ожиданияМетрика значительно лучше порогового значения 2СоответствуетМетрика в пределах целевого диапазона 1Частично соответствуетМетрика ниже порога, но устранимо за 2-4 недели 0Не соответствуетКритический разрыв, требует фундаментальных изменений
Итоговый скоринг определяет решение:
- Go (80-100%) — масштабировать. Все измерения выше порога, риски управляемы
- Conditional Go (60-79%) — масштабировать после доработок. Указать конкретные критерии для повторной оценки через 2-4 недели
- No-Go (<60%) — остановить или перезапустить пилот с изменённым скоупом
При этом есть абсолютные блокеры — критерии, при нулевой оценке которых решение автоматически No-Go, независимо от итогового балла. К примеру: uptime ниже 95%, adoption rate ниже 30% или отрицательный ROI.
Пример: как выглядит Go/No-Go скоринг на практике
Рассмотрим конкретный случай. Компания (логистика, 2 000 сотрудников) завершила 8-недельный пилот системы автоматизации документооборота на группе из 40 человек.
ИзмерениеКритерийРезультат пилотаПорогБалл
Техническая готовностьUptime99.2%99%2 Response time P951.8 сек<2 сек2 Нагрузочный запас1.5x2x1 Бизнес-эффектROI пилота45%20%3 Time saved на документ62%30%3 Error reduction71%50%3 Пользовательское принятиеAdoption rate68%60%2 NPS34302 Task completion rate87%85%2 Организационная готовностьБюджет утверждёнДаДа2 Команда поддержки2 из 4 нанято4 человека1 План обученияЧерновикГотов1
Итоговый балл: 24 из 36 = 67%. Решение: Conditional Go. Бизнес-эффект отличный — ROI и экономия времени значительно превышают пороги. Тем не менее есть два слабых места: нагрузочный запас недостаточен для масштабирования на 2 000 человек, а команда поддержки укомплектована наполовину.
Конкретные условия для перехода к Go: оптимизировать производительность до 2x запаса за 3 недели, нанять оставшихся 2 специалистов поддержки, финализировать план обучения. Повторный скоринг — через 4 недели.
Без фреймворка эта компания, скорее всего, сказала бы «Go» сразу — ведь ROI великолепный. Однако нагрузочный тест показал бы проблемы через 3 месяца, когда 2 000 пользователей одновременно начнут работать в системе. Потеря — не 15 млн, но несколько месяцев и репутация проектной команды.
Комитет Go/No-Go: кто принимает решение
Фреймворк без правильного комитета — это просто таблица в Excel. Решение о масштабировании должны принимать люди, которые видят картину с разных сторон.
Рекомендуемый состав комитета
РольЗона ответственностиЧто оценивает
**Спонсор проекта (VP / CDO)**Финальное решениеСтратегическое соответствие CTO / техлидТехническая оценкаГотовность архитектуры Бизнес-владелец процессаБизнес-эффектROI, операционные метрики Продакт-менеджерПользовательский опытAdoption, NPS, обратная связь Руководитель PMOРесурсы и срокиОрганизационная готовность
Три правила работы комитета:
- Каждый оценивает только своё измерение. CTO не голосует за бизнес-эффект, CFO не оценивает техническую готовность. Это исключает ситуацию, когда авторитетный руководитель «продавливает» решение.
- Решение — не голосование. Комитет заполняет скоринговую матрицу, и формула определяет результат. Если балл 67% — это Conditional Go, и никакие аргументы «но ведь ROI отличный!» не меняют решение.
- Conditional Go требует конкретного плана. Не «доработать и посмотреть», а «оптимизировать P95 до 1 сек, нанять 2 специалистов к 15 марта, повторный скоринг 1 апреля». Без конкретики Conditional Go превращается в бесконечную доработку.
Когда фреймворк нужно адаптировать
Стандартная модель работает для 80% корпоративных пилотов. Однако есть ситуации, где скоринг требует модификации.
Пилот с внешними пользователями. Если продукт — клиентский (портал, мобильное приложение), пользовательские метрики весят больше. Рекомендация: увеличить вес «Пользовательское принятие» до 35% за счёт «Организационная готовность» (15%).
Регуляторные ограничения. В банках и фармацевтике compliance — абсолютный блокер. Даже при 90% скоринге, если продукт не прошёл аудит безопасности, решение автоматически No-Go. Добавьте отдельный чек-лист compliance как пятое измерение.
Стратегический пилот «must win». Иногда пилот запускается по стратегическому решению CEO, и вопрос не «масштабировать ли», а «как масштабировать». В таких случаях фреймворк помогает определить условия для масштабирования — но порог для Go снижается до 50%, а Conditional Go становится основным сценарием.
Мультивендорный пилот. Когда параллельно тестируются два-три решения от разных подрядчиков, фреймворк превращается в инструмент сравнительного анализа. Каждый продукт проходит одинаковый скоринг — и решение принимается не на основе презентации продавца, а на основе данных. В таком случае добавляется этап нормализации: критерии приводятся к единой шкале, чтобы сравнение было корректным.
Важно понимать: адаптация фреймворка — это нормально. Однако адаптация должна происходить до начала пилота, а не после получения неудобных результатов. Иначе это уже не адаптация, а подгонка. Проектируйте корпоративный MVP с учётом будущего скоринга — тогда данные для фреймворка собираются автоматически.
FAQ о Go/No-Go
Чем Go/No-Go отличается от обычного отчёта по пилоту?
Отчёт описывает, что произошло. Go/No-Go фреймворк определяет, что делать дальше. Отчёт — это данные. Фреймворк — это заранее определённые критерии, пороги и алгоритм принятия решения. Без фреймворка отчёт остаётся информацией для обсуждения, с фреймворком — становится основой для действия.
Что делать, если комитет не согласен с результатом скоринга?
Если скоринг говорит Conditional Go, а спонсор хочет Go — это сигнал пересмотреть веса критериев или пороговые значения. Но менять их ретроактивно нельзя: это подрывает весь смысл фреймворка. Рекомендация: зафиксировать разногласие в протоколе, принять решение спонсора, но включить risk mitigation план на случай, если «проигнорированные» критерии окажутся критичными.
Сколько времени занимает Go/No-Go процесс?
При подготовленном фреймворке — 1 день. Каждый участник комитета заполняет свою часть скоринга заранее (30-60 минут). Совместная сессия длится 2-3 часа: обсуждение расхождений, формулировка условий для Conditional Go, утверждение решения. Без фреймворка тот же процесс растягивается на 2-3 недели совещаний.
Можно ли использовать фреймворк для небольших пилотов (до 1 млн рублей)?
Да, но в упрощённой версии. Для пилотов с бюджетом до 1 млн достаточно трёх измерений (без «Организационной готовности») и 6-8 критериев вместо 12. Скоринг проводит один человек — владелец продукта. Принцип тот же: заранее определённые критерии, пороги и формальное решение. Даже упрощённый фреймворк лучше интуиции.
Как встроить Go/No-Go в архитектуру MVP?
Лучший вариант — заложить сбор данных для скоринга на этапе проектирования IT-проекта. Встроенные дашборды мониторинга, product analytics, инструменты для NPS-опросов — всё это должно быть в MVP до начала пилота. ITESCO проектирует каждый корпоративный MVP с учётом будущего Go/No-Go: метрики собираются автоматически, а скоринговый отчёт формируется за 15 минут.
Итого
Go/No-Go фреймворк — это не бюрократия, а страховка от потери бюджета на преждевременном масштабировании. Четыре измерения (техническая готовность, бизнес-эффект, пользовательское принятие, организационная готовность), скоринговая модель 0-3 и комитет из пяти ключевых ролей превращают субъективное «вроде работает» в обоснованное решение с конкретным планом действий.
Главное правило: критерии и пороги определяются до начала пилота, а не подбираются задним числом под желаемый ответ. Conditional Go — это не провал, а зрелый подход к управлению рисками корпоративного проекта.
Если вы планируете корпоративный пилот и хотите, чтобы архитектура MVP изначально включала инструменты для Go/No-Go скоринга, запишитесь на бесплатный Zoom-колл с командой ITESCO. Обсудим, как спроектировать продукт, который не только пройдёт пилот, но и пройдёт скоринг комитета.