Что такое ценность в ИТ: ITIL 4, DevOps, бизнес и здравый смысл

Ценность в ITIL 4: не услуга, а результат

Базовое определение
ITIL 4 даёт, на первый взгляд, простое определение:
Ценность — это воспринимаемая польза, полезность и важность чего-либо.
Ключевое слово здесь — воспринимаемая. Ценность существует не в документации, не в SLA и не в отчётах. Она существует в голове потребителя.
Ценность в ИТ — это результат, который создаёт значимое положительное влияние для пользователя или бизнеса. Это может быть удобство, скорость, экономия, безопасность, устойчивость и т.д. Важно, чтобы то, что делает команда ИТ, имело смысл и приносило результат, а не просто «работало». Чтобы определить, есть ли ценность — задавай вопрос: кому это нужно и какую проблему это решает?

Совместное создание ценности
Один из главных сдвигов ITIL 4 — отказ от идеи, что ИТ «создаёт ценность» самостоятельно.
Ценность создаётся совместно (co-creation of value) между провайдером услуги и её потребителем.
ИТ предоставляет возможности, бизнес использует эти возможности, пользователи получают результат — и только в этот момент возникает ценность. Если результат не используется, ценность не возникла, даже если ИТ «сделало всё правильно».

Service Value System
В ITIL 4 ценность — это результат работы всей системы, а не отдельного процесса или практики. Service Value System связывает:
• спрос и возможности;
• управленческие принципы;
• цепочку создания ценности;
• практики;
• непрерывное улучшение.

Если хотя бы один элемент не работает или не согласован с остальными — ценность теряется по дороге.

Utility (Функциональная пригодность) и Warranty (Эксплуатационная гарантия)
Классическая пара, без которой ценность не возникает:
• Utility — что услуга делает;
• Warranty — насколько надёжно, доступно и безопасно она это делает.

Система может быть функционально идеальной, но если она нестабильна, медленна или небезопасна — воспринимаемой ценности не будет.

1. Utility — Функциональная пригодность
Определение:
Utility отвечает на вопрос: «Что услуга делает?» или «Нужна ли она для выполнения работы?»
То есть, Utility — это функциональная ценность услуги, то, как она помогает потребителю достичь своих целей. Полезность можно обобщить как «то, что делает сервис», и использовать для определения того, «является ли сервис пригодным для цели».

А. Фокус на потребностях пользователя:
Utility измеряется тем, насколько услуга удовлетворяет бизнес-требования.
Например: CRM-система помогает отделу продаж управлять клиентами — это её Utility.
Б. Не о качестве, а о функции:
Utility — это про функциональность, а не про то, как надёжно или удобно она работает.
Пример: сервис почты позволяет отправлять письма (Utility), даже если иногда письма приходят с задержкой.
В. Связь с «Функциональной пригодностью»:
ITIL4 называет Utility «fit for purpose» — пригодна для использования по назначению.

Примеры Utility:
Услуга - /Онлайн-банкинг/  Utility (функциональная пригодность) - /Возможность переводить деньги, оплачивать счета/
Услуга - /Видеоконференц-сервис/  Utility (функциональная пригодность) - /Возможность проводить видеозвонки с коллегами/
Услуга - /ERP-система/     Utility (функциональная пригодность) - /Автоматизация учёта товаров и финансов/

2. Warranty — Эксплуатационная гарантия
Определение:
Warranty отвечает на вопрос: «Как хорошо услуга работает?» или «Надёжна ли она?»
То есть, Warranty — это эксплуатационные свойства услуги, которые обеспечивают её надёжность, доступность и безопасность. В ITIL4 Гарантия - обеспечение соответствия продукта или услуги согласованным требованиям. Гарантию можно определить как пригодность к использованию.

А. Фокус на характеристиках качества:
Warranty измеряется SLA, показателями доступности, производительности, безопасности и т.д.
Пример: сервис доступен 99,9% времени, с резервным копированием каждые 12 часов.
Б. Не о функции, а о надёжности:
Warranty гарантирует, что функция (Utility) будет доступна и работоспособна тогда, когда это нужно.
Пример: CRM-система работает 24/7 без сбоев и обеспечивает защиту данных.
В. Компоненты Warranty в ITIL4: 
- Доступность (Availability): сервис доступен, когда нужен
- Надёжность (Reliability): сервис выполняет функцию без ошибок
- Мощность/Производительность (Capacity/Performance): сервис справляется с нагрузкой
- Безопасность (Security/Continuity): данные и процессы защищены

Примеры Warranty:
Услуга - /Онлайн-банкинг/   Warranty (эксплуатационная гарантия) - /Доступность 24/7, шифрование данных, защита от мошенничества/
Услуга - /Видеоконференц-сервис/   Warranty (эксплуатационная гарантия) - /Минимальная задержка видео, поддержка 50 участников, SLA 99%/
Услуга - /ERP-система/   Warranty (эксплуатационная гарантия) - /Резервное копирование ежедневно, высокая скорость обработки заказов/

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

Ценность в DevOps: быстрый и надёжный поток полезных изменений

DevOps редко говорит словом «ценность» напрямую, но фактически он полностью про неё.

Value Stream вместо процессов
DevOps смотрит на ИТ как на поток ценности — от идеи до пользователя. В этом потоке ценность появляется только тогда, когда:
• нужное изменение;
• доходит до пользователя;
• достаточно быстро;
• без разрушительных последствий.
Если релиз:
• быстрый, но ломает прод — ценности нет;
• стабильный, но раз в полгода — ценности почти нет;
• автоматизированный, но никому не нужный — ценности нет вообще.

DORA-метрики как прокси ценности
DORA-метрики часто ошибочно воспринимают как «метрики скорости ИТ». На самом деле они показывают, как быстро и стабильно ценность доходит до пользователя:
• Lead Time — время доставки ценности;
• Deployment Frequency — частота доставки ценности;
• Change Failure Rate — доля сломанной ценности;
• MTTR — скорость восстановления ценности.

DevOps не про скорость ради скорости. Он про сокращение времени между потребностью и пользой.

Ценность с точки зрения бизнеса: эффект, а не активность

Бизнес смотрит на ценность максимально прагматично.

Бизнес покупает не ИТ, а эффекты

Бизнесу не нужны:
• Kubernetes;
• микросервисы;
• CI/CD;
• «современная архитектура».
Бизнесу нужны эффекты:
• рост выручки;
• снижение издержек;
• снижение рисков;
• ускорение вывода продуктов;
• соответствие требованиям регуляторов;
• доверие клиентов.
Если ИТ-инициатива не влияет хотя бы на один из этих пунктов — её ценность под вопросом.

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

Ценность и здравый смысл

Если отбросить фреймворки, ценность сводится к простому вопросу:

Что станет лучше для конкретного человека или организации?

Полезный фильтр для любой инициативы:
• для кого это;
• какую проблему решает;
• что изменится после внедрения;
• что станет проще, быстрее или надёжнее;
• что будет, если этого не делать.

Если ответы размыты — проект опасен.

Типовые подмены понятия «ценность»
• Активность ≠ ценность — «мы много сделали» никого не интересует.
• Технологичность ≠ ценность — современно не значит полезно.
• SLA ≠ ценность — доступный, но ненужный сервис ценности не имеет.
• Экономия ИТ ≠ экономия бизнеса — сэкономить на инфраструктуре и потерять клиентов — плохой обмен.

Кейсы

Кейс 1. ERP: победа ИТ, поражение бизнеса. «Идеальный ИТ-проект без ценности»

Крупный ритейлер инвестировал $2 млн в двухлетний проект по замене устаревшей ERP. Проект был образцовым:
• Закончен ровно по deadline.
• Уложились в бюджет с экономией 5%.
• Реализованы все 127 требований из технического задания.
• Система показала 99,9% доступности на тестах.

Через 6 месяцев после «успешного» запуска выяснилось:
• 70% сотрудников отдела закупок продолжали согласовывать поставки в цепочке писем, а ключевые данные вносили в старые Excel-таблицы.
• Формирование ежемесячного управленческого отчета, по плану занимающее 15 минут, силами аналитиков занимало 3 рабочих дня ручной выгрузки и консолидации.
• Главный финансовый директор заявил: «Мы потратили миллионы, а прозрачность затрат не улучшилась ни на йоту».

Что пошло не так? Ключевая ошибка:
Ценность была определена как Артефакт(«развернуть систему с 127 функциями»), а не как Результат(«сократить цикл согласования закупок с 5 дней до 1» и «получать отчёт по затратам в один клик к 1 числу месяца»).
Проект отчитывался о закрытых задачах, а не об изменённых бизнес-процессах.

Как нужно было действовать?
1. Стартовать с Результата: До написания первого требования провести воркшоп с ключевыми бизнес-пользователями и спросить: «Какие три самых болезненных ручных операции вы хотите устранить с помощью новой системы? Как мы измерим успех?»
2. Запускать поэтапно по ценности: Вместо «Big Bang»-релиза запустить за 3 месяца минимальную версию, автоматизирующую один конкретный, но критичный процесс (например, согласование закупок). Получить обратную связь, доработать и только потом двигаться дальше.
3. Измерять адаптацию, а не доступность: KPI успеха — не uptime системы, а % сотрудников, перешедших с Excel на новый модуль и сокращение времени операций.

Правильный вопрос: «Какую бизнес-операцию мы улучшаем и на сколько процентов?»
Неправильный вопрос: «Какие технические функции нам нужно внедрить?»

Кейс 2. Супергеройская команда, доставляющая пустоту. "DevOps, который ускорял не то"

FinTech-стартап собрал звёздную DevOps-команду. За 9 месяцев они:
• Внедрили полноценный CI/CD-конвейер.
• Сократили среднее время релиза (Lead Time) с 45 дней до 3 часов.
• Достигли частоты деплоя (Deployment Frequency) 50 раз в день.
• Держали процент сбоев (Change Failure Rate) ниже 0.5%.

Парадокс: при таких блестящих метриках DORA продукт терял долю рынка. Бизнес-заказчики были в ярости: «Вы выпускаете по 10 версий в день, но когда же будет кнопка экспорта в 1С?!»
Расследование показало:
Команда, вдохновлённая новыми возможностями, оптимизировала локальный максимум. 95% релизов содержали:
• Рефакторинг кода «для поддержания здоровья».
• Обновления версий языков и фреймворков.
• Исправления гипотетических уязвимостей, не имеющих CVSS-рейтинга.
Пул-реквесты бизнес-логики (та самая кнопка экспорта) неделями висели в ревью, потому что «не были идеальными с архитектурной точки зрения».

Что пошло не так? Ключевая ошибка:
Команда подменила цель («быстрее доставлять ценность клиентам») средствами («создать идеальный технический конвейер»). Они оторвались от Value Stream и сфокусировались на Build Pipeline.

Как нужно было действовать?
1. Начать с конца: Внедрить практику единого бэклога, приоритизацию которого ведёт Product Owner, представляющий интересы бизнеса и пользователей. Ни один технический тикет не должен обгонять в очереди бизнес-фичу.
2. Метрики в связке: Рядом с DORA-метриками повесить бизнес-метрики продукта (конверсия, retention, NPS). Любое улучшение DORA должно быть обосновано тем, как оно улучшит эти бизнес-метрики.
3. Ввести правило «Ценности в каждой итерации»: Каждый спринт должен заканчиваться хотя бы одним изменением, заметным и полезным для конечного пользователя или бизнес-оператора.

DevOps — это не про то, чтобы быстро нажимать кнопку «деплой».
Это про то, чтобы укоротить путь от бизнес-гипотезы до её проверки на реальных пользователях.

Кейс 3. Самовлюблённый портал, или Симулякр ценности

Руководство ИТ-департамента крупного предприятия решило «повысить прозрачность и эффективность взаимодействия». Был инициирован проект «Единый ИТ-портал».
• Срок: 4 месяца.
• Бюджет: 500 тыс. руб.
• Результат: Современный портал на последнем React. На нём были: лента новостей ИТ-директора, библиотека регламентов в формате PDF, витрина SLA и форма создания заявки.

Финал: аналитика показала, что 92% пользователей (сотрудников компании) зашли на портал ровно один раз — в день обязательного инструктажа. Через 2 недели 100% заявок в службу поддержки снова шли по старой доброй почте help@company.com.

Что пошло не так? Ключевая ошибка:
Ценность определялась для ИТ-отдела («у нас будет красивая витрина наших услуг и регламентов»), а не для потребителя (сотрудника, которому нужно быстро решить свою проблему). Форма заявки технически была, но пользовательский опыт не изменился — в итоге он написал в привычную почту.

Как нужно было действовать? (Идеальный сценарий «от ценности»):
1. Обнаружить боль: Провести 10 интервью с обычными сотрудниками и спросить: «Что вас больше всего бесит в процессе обращения в ИТ-поддержку?». Ответ: «Я не знаю, к кому обращаться по разным вопросам, теряюсь в тредах писем и не понимаю, когда придут».
2. Спроектировать решение «от боли»: Не «портал», а служба одного окна. Не форма заявки, а интеллектуальный чат-бот, который по ключевым словам направляет в нужную группу и создаёт тикет сам. И обязательно — трекер статуса заявки, который виден пользователю.
3. Запустить «точечно» и проверить: За 2 недели сделать прототип чат-бота в Telegram для одного отдела. Измерить: сократилось ли среднее время первичного отклика? Удовлетворённость? Если да — масштабировать.

Ценность создаётся не тогда, когда вы напишете код.
А тогда, когда пользователь перестанет использовать обходные пути и начнёт пользоваться вашим решением, потому что оно решило его проблему ЛУЧШЕ, чем предыдущий способ.

Как связать ITIL 4, DevOps и бизнес в одну модель

1. Бизнес формулирует потребность и ожидаемый эффект.
2. ITIL 4 задаёт систему создания ценности.
3. DevOps обеспечивает быструю и надёжную доставку изменений.
4. Пользователь получает результат.
5. Возникает воспринимаемая ценность.

Если любой шаг выпадает — ценность теряется.

Итог

Ценность — это не система, не релиз и не процесс.

Ценность — это ощутимое улучшение, которое кто-то реально использует и считает важным.

Когда ИТ начинает мыслить ценностью, а не технологиями, оно перестаёт быть «центром затрат» и становится партнёром бизнеса.
Ценность — это не KPI, а постоянный диалог. Диалог, который начинается с вопроса «Для кого?» и заканчивается не отчётом, а изменением в реальном мире