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

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

Разработка своими силами или покупка готового решения (Build vs Buy)

Build-vs-buy — это структурированное сравнение собственной разработки с коммерческим приобретением по дисконтированному TCO, срокам поставки и риску. Эмпирические априорные данные однозначны: фактическая стоимость собственной разработки обычно превышает прогнозы на 30–40%, купленные решения развёртываются на 40–60% быстрее, а исследование MIT по GenAI 2025 года обнаружило, что купленные ИИ-инструменты успешны в ~67% случаев, тогда как внутренние разработки успешны примерно в трети случаев от этого.

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

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

Математика

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

ЧПС_вариант = ПС(выгоды, смещённые на срок до ценности) − ПС(TCO)

Корректировки риска (паттерн Green Book «смещение в сторону оптимизма»):
  стоимость разработки × 1.3–1.4        (априорная оценка перерасхода)
  срок до ценности разработки + 40–60% (априорная оценка задержки развёртывания)
  покупка: вместо этого добавьте проверку реалистичности интеграции и издержки выхода

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

Практический пример

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

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

Эффективное сравнение: £750k против £1,785k — покупка побеждает примерно на £1M, и крупнейшая
отдельная статья после самой разработки — это стоимость задержки, которую никто не оценил.

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

Связь с разработкой программного обеспечения

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

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

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

Источники