Учет времени в конце дня по памяти считается менее эффективным, потому что приводит к искажению данных и неточности отчетов. В примере, приведенном в материале, сотрудник сначала заявил о 215% загрузки за месяц, что после уточнения снизилось до 125%, а после более детального анализа — до реальных 85%. Это говорит о том, что память человека не позволяет точно воспроизвести прошедший рабочий день, что серьезно искажает реальную картину загрузки и распределения времени.

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

В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

Нормировать в процессе управления проблемами можно фазу диагностики (problem control - PC), но не всю обработку проблемы целиком. Нормирование проводится на основании уровня влияния проблемы на бизнес-процессы. Например, для проблемы с высоким уровнем влияния срок диагностики может быть установлен в 1 неделю, для среднего уровня - 2 недели, и так далее. Это обосновано тем, что диагностика проблемы, определение корневой причины и вариантов решения имеет более предсказуемый временной контур по сравнению с последующей реализацией решения.

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

Принцип ITIL 4, наиболее напрямую связанный с концепцией 'Целое больше суммы частей', - это 'Используйте целостный подход' (Think and work holistically), указанный в разделе 4.3.5 руководства ITIL 4. Этот принцип подчеркивает необходимость понимания того, как все части организации работают вместе интегрированным образом для предоставления услуг. Он включает в себя рассмотрение всех четырех аспектов управления ИТ-услугами как взаимосвязанных элементов, которые необходимо координировать совместно, а не работать с ними выборочно. Принцип предполагает, что услуги предоставляются посредством координации этих аспектов, и только такой интегрированный подход позволяет создать ценность, превосходящую сумму отдельных составляющих. Это означает, что любое управление отдельными элементами без учета их взаимодействия с другими приведет к снижению общей эффективности.

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

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

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

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