Иллюзия конкуренции проявляется в том, что формально рынок может содержать несколько компаний, но их количество недостаточно для реального соперничества. Например, в городах может быть 2-3 прокатные конторы, тогда как для здоровой конкуренции требуется гораздо больше игроков. Бизнесы не конкурируют за клиентов через улучшение сервиса, так как спрос превышает предложение, и владельцы считают излишним уделять внимание обслуживанию. Это приводит к ситуации, где клиенты не получают преимуществ конкуренции: выбор ограничен, качество услуг не растет, а компании остаются пассивными в улучшении условий для потребителей.

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

История с мылом в английском отеле иллюстрирует, как формальное отслеживание и выполнение запросов заказчика приводит к нежелательному результату, даже когда персонал отеля следует всем регламентам и процедурам. Постоялец хотел, чтобы ему не приносили отельное мыло, так как он пользуется собственным, но персонал интерпретировал его просьбы буквально, не пытаясь понять истинную потребность. Когда постоялец попросил убрать мыло, его убрали, но затем в следующий день принесли новое, поскольку по регламенту в номер должны класть мыло каждый день. Когда постоялец пожаловался, что остался без мыла, ему тут же принесли дополнительное. Ситуация усугублялась тем, что разные сотрудники отеля по-разному понимали суть проблемы, но никто не задал вопрос, зачем постояльцу нужно именно убрать мыло или почему он просит вернуть своё. Это напрямую отражает ситуацию взаимодействия ИТ и бизнеса, когда технические специалисты формально выполняют требования, но не понимают бизнес-цели, что приводит к ненужным усложнениям и неэффективным решениям.

CleverKPI предлагает несколько вариантов решения задач по измерению ИТ-управления в зависимости от потребностей клиента: бесплатные ресурсы для первоначального ознакомления, недорогая книга за 500 рублей, авторский курс за 29 500 рублей для углубленного изучения, экспресс-диагностика от 360 000 рублей для практической оценки текущего состояния, консалтинговые услуги для корректировки системы управления и преднастроенное программное обеспечение для автоматизации процессов измерения. Это позволяет клиенту выбрать наиболее подходящий уровень взаимодействия для решения его задач.

Другие стандарты подходят к управлению доступностью иначе, чем ITIL. Например, ISO/IEC 20000 объединяет управление доступностью с управлением непрерывностью, COBIT5 и CMMI для сервисов связывают его с управлением мощностями, MOF включает его в функцию надежности вместе с управлением непрерывностью, мощностями и безопасностью. Авторы ISM Method относят управление доступностью к управлению качеством (Quality Management), наряду с другими аспектами, такими как безопасность и непрерывность. Это свидетельствует о том, что в других стандартах управление доступностью не выделено отдельно как самодостаточный процесс.

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

Роль менеджера уровня услуг характеризуется двойственной природой в контексте отношений между ИТ-поставщиком и клиентом. Этот специалист выступает как 'свой среди чужих, чужой среди своих' - действует в качестве неофициального представителя клиента при общении с ИТ-персоналом и как представитель ИТ-поставщика при взаимодействии с клиентами. Из-за этого двойственного положения менеджер уровня услуг может вызывать определенное подозрение как со стороны ИТ-персонала, так и со стороны клиентских представителей.

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

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

Правила регистрации инцидентов должны основываться на четком определении нормальной работы услуги и согласованных уровней качества. Нужно определить, какие отклонения от нормы требуют немедленного вмешательства, а какие могут обрабатываться в плановом порядке. Критерии регистрации могут включать как технические параметры, так и субъективные факторы, например, недовольство пользователей. Важно, чтобы ответственные лица понимали, при каких условиях регистрировать инцидент, и имели четкий алгоритм принятия решений. Например, руководство ITIL 4 предлагает использовать такие критерии, как «пользователь несчастлив?», чтобы определить, стоит ли классифицировать ситуацию как инцидент.