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

Да, можно использовать CMDB для решения задач сервисной экономики. Основная задача CMDB — определение влияния одних элементов на другие, что по своей сути имеет экономический характер, поскольку влияние является производной от использования ресурсов. Например, сервер, использующий систему хранения данных для размещения информации, формирует взаимосвязь влияния, которая может быть использована при расчете TCO приложений. CMDB может содержать данные о всех необходимых ресурсах, включая виртуальные машины и логические диски, которые не учитываются в традиционном бухгалтерском учёте, но важны для расчёта стоимости услуг. При этом для решения экономических задач не требуется вводить специальные «экономические» связи, могут быть использованы существующие связи влияния.

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

Учет полосы видимости важен при анализе путешествия заказчика, потому что именно в этой зоне формируется клиентский и пользовательский опыт (CX/UX). Полоса видимости включает те виды деятельности потоков создания ценности, которые непосредственно взаимодействуют с потребителем. Хотя значительная часть работы провайдера может происходить "за кулисами" и быть не видна клиенту, именно точки контакта в полосе видимости определяют общее впечатление потребителя об услуге. Улучшая эти точки взаимодействия, провайдер может целенаправленно управлять клиентским опытом и повышать удовлетворенность клиентов, что критически важно для успешного предоставления услуг.

Добавление критериев завершения (Definition of Done) в визуализацию процесса важно потому что в вытягивающей системе (Pull System) каждый следующий шаг в потоке сам забирает задачи. Чтобы система работала правильно, необходимо четко понимать, какие задачи на предыдущем этапе завершены, а какие нет. Без явных критериев завершения невозможно определить, когда задача готова к переходу на следующую стадию, что нарушает принципы потока ценности и эффективности DevOps подхода.

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

Для управления критичными конфигурационными единицами рекомендуется: определить и закрепить перечень категорий и отдельных конфигурационных единиц, установив их уровень критичности; назначить ответственных лиц и ограничить доступ к критичным компонентам; внедрить централизованное планирование прерываний работы критичных компонентов; ограничить возможности удаленного доступа к критичным компонентам; обеспечить систему информирования смежных подпроцессов об изменениях, проводимых с критичными компонентами. Эти меры позволяют обеспечить контролируемое управление важными компонентами информационной инфраструктуры.

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

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

Средний чек напрямую влияет на количество транзакций, необходимых для выполнения плана продаж. Чем ниже средний чек, тем больше сделок необходимо обработать, что увеличивает нагрузку на ИТ-системы и повышает вероятность возникновения проблем, требующих обращений в Service Desk. Например, при низком среднем чеке и высоком объеме сделок, количество запросов в техническую поддержку будет выше, так как больше операций означает больше возможных сбоев и вопросов от пользователей. Это позволяет прогнозировать объем и структуру работы службы поддержки.