Метрики экономики здравоохранения

Тема 72 из 91· Разработка ПО и цифровая доставка

Разработка против покупки

Разработка против покупки — это структурированное сравнение индивидуальной разработки против коммерческого приобретения, по дисконтированной ПСВ, срокам поставки и риску. Эмпирические предпосылки однозначны: фактические затраты на разработку обычно превышают прогнозы на 30-40%, купленные решения развёртываются на 40-60% быстрее, а исследование генеративного ИИ MIT 2025 года показало, что купленные инструменты ИИ успешны ~67% времени, тогда как внутренние разработки успешны примерно в треть от этой частоты.

Почему это важно

Системы здравоохранения постоянно сталкиваются с этим решением («сделать против заказать» на языке NHS), и инженерные организации систематически ошибаются в направлении разработки — потому что разработчики оценивают разработку, а не ПСВ, и потому что разработка веселее. Экономическая рамка заставляет проводить честное сравнение: оба варианта оцениваются на одном горизонте, оба скорректированы на риск, а разница во времени оценивается как стоимость задержки — термин, который чаще всего определяет ответ и чаще всего упускается.

Расчёт

Сравнивайте на одном 3-5-летнем горизонте, дисконтированном:

ЧПС_вариант = ТС(выгоды, сдвинутые временем до ценности) − ТС(ПСВ)

Корректировки риска (схема «предвзятости оптимизма» Зелёной книги):
  стоимость разработки × 1,3–1,4        (предпосылка перерасхода)
  время до ценности разработки + 40–60% (предпосылка задержки развёртывания)
  покупка: вместо этого добавьте проверку реалистичности интеграции и затраты на выход

Драйверы решения, в порядке, в котором они обычно определяют:
  1. дифференциация — эта возможность — ваш продукт или инфраструктура?
  2. время до ценности × СЗ
  3. ПСВ с поправкой на риск

Разобранный пример

Трасту нужна система электронного согласия. Покупка: £150 тыс/год SaaS, запуск через 3 месяца. Разработка: оценочно £600 тыс + £120 тыс/год обслуживания, запуск через 12 месяцев.

Разработка с поправкой на риск: 600 тыс × 1,35 = £810 тыс; время до ценности ≈ 18 месяцев
ПСВ за 5 лет:  покупка = 150 тыс × 5 = £750 тыс
           разработка = 810 тыс + 120 тыс × 5 = £1410 тыс
Член задержки: оцифровка согласия экономит £25 тыс/месяц; разработка приходит на 15 месяцев
            позже → СЗ = 15 × 25 тыс = £375 тыс

Реальное сравнение: £750 тыс против £1785 тыс — покупка выигрывает примерно на £1 млн, и крупнейший
единственный член после самой разработки — это стоимость задержки, которую никто не оценил.

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

Связь с программной инженерией

Переносимая дисциплина экономики здравоохранения тройная: корректировка риска на основе предпосылок (надбавка за перерасход в 30-40% — это предвзятость оптимизма Зелёной книги для ПО — применяйте механически, аргументируйте исключения, а не исходите из них); честность компаратора (альтернатива разработке — это не «ничего», это лучшая доступная покупка — см. альтернативные издержки); и тест на эквивалентность перед сравнением затрат (если покупка и разработка действительно соответствуют одной спецификации, это анализ минимизации затрат, и побеждает более дешёвый вариант; если нет, разницу в результате нужно оценить, а не декларировать).

Подводные камни

  • Сравнение прайс-листа поставщика с неоткорректированными на риск оценками разработки — двойная лесть в сторону разработки.
  • Внутренний труд по нулевой цене («команда уже здесь»).
  • Неоценённая зависимость в обоих направлениях: затраты на выход от поставщика, но также фактор автобуса и срок обслуживания разработки.
  • Разработки, движимые идентичностью: «это для нас основное», заявленное для инфраструктуры — проверьте дифференциацию, задав вопрос, заметили бы клиенты.

Источники