Анализ чувствительности ИТ-проекта показывает, какие допущения превращают прибыльную идею в убыток

Сохраните исходный расчёт и измените один вход. Пересчёт покажет его влияние на итог. Это однофакторный анализ чувствительности.

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

Green Book 2026 называет порог смены решения switching value. В нашем примере это точка, где денежный итог равен нулю.

Компания автоматизирует заявки, за обработку которых платит внешнему оператору. Каждая принятая операция снимает один платёж.

Считаем шесть месяцев от первой оплаты. Два месяца идёт разработка, затем она на паузе. Работающий продукт приносит пользу четыре месяца.

Цена подписки на разработку взята с /services: 250 000 ₽ за месяц на 8 октября 2026. Остальные входы условные.

За месяц остаётся 175 000 ₽: тысяча операций по 200 ₽ минус 25 000 ₽ расходов. За четыре месяца это 700 000 ₽ при вложениях 600 000 ₽.

Остаются 100 000 ₽ за шесть месяцев. Это денежный итог в выбранном окне. Польза за всю жизнь системы здесь не считается.

Сохраните все расходы исходной модели. Если убрать проверки или продлить окно только в плохом сценарии, сравнение потеряет смысл.

Риски ИТ-проекта связывают с пределом расходов до следующей проверки полезности продукта.

Считаются только принятые операции. Заявка, которую пришлось повторить у платного оператора, не снимает платёж и не приносит эту пользу.

Меняем только объём. Вместо 1 000 операций берём 900, затем 875 и 800. Срок и расходы остаются исходными.

При 875 операциях после расходов остаётся 150 000 ₽ в месяц. За четыре месяца это ровно 600 000 ₽ вложений. Порог найден.

Падение объёма на 12,5 % обнуляет плюс при остальных исходных условиях. Это запас расчёта, а не вероятность падения спроса.

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

Свободные часы сотрудника оцените отдельно. Если зарплата и выпуск не изменились, денежной экономии от этих часов в расчёте нет.

Месяц задержки съедает 175 000 ₽ пользы. При прежних расходах итог станет −75 000 ₽. Окно заканчивается шестым месяцем.

Вернём запуск к базе и добавим одну полную оплату. Расходы вырастут на 250 000 ₽, итог станет −150 000 ₽, хотя польза началась вовремя.

Если задержка требует ещё одной оплаты, проверяем их вместе. Запуск с четвёртого месяца и три оплаты дают −325 000 ₽.

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

На сроки разработки влияют очередь и приёмка, а не только набор кода. Подтвердите дату первой принятой операции.

Причины, по которым ИИ не ускорил выпуск, разобраны отдельно. В расчёт чувствительности перенесите проверенную дату.

Фикс за месяц убирает новую смету на каждую правку. Число месяцев до принятого результата остаётся допущением. Его нужно проверить.

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

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

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

В примере 25 000 ₽ включают проверки и обслуживание. Если они подорожают, пересчитайте эту строку отдельно от цены сборки.

В постановке задач агенту нужен критерий готовности. Здесь это подтверждённый расход или принятые операции, а не новая кнопка.

Порог меняет следующую задачу. Если итог держится на 875 операциях, сначала подтвердите полезный объём, затем оплачивайте расширение.

До старта согласуйте предел потерь до первой пользы. В примере руководитель выбрал 750 000 ₽. Это условное решение, а не норматив.

Если запуск тоже сдвинулся, три оплаты и подготовка обойдутся в 850 000 ₽ до первой пользы. Решите вопрос паузы до третьей оплаты.

Пауза не возвращает потраченные деньги. Для продолжения сравните новые расходы с будущей пользой. Прошлые вложения не обязывают платить дальше.

У нашей подписки пауза переносит оплаченные дни. Она откладывает новый расход на разработку. Расходы работающего продукта остаются.

Если срок и приёмку пока некому подтвердить, пройдите тест для руководителя. Он поможет проверить условия работы с агентами.

1. Зафиксируйте окно и входы. Меняйте одно допущение, остальные возвращайте к базе.

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

3. Считайте принятые операции и денежную пользу. Заявки, написанный код и свободные часы сами по себе не дают эту сумму.

4. После отдельных проверок свяжите задержку с платными месяцами и расходами продукта. Не продлевайте окно, чтобы спрятать минус.

5. До следующей оплаты назначьте предел расходов, сигнал паузы и человека, который проверит его.