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

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

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

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

Цели для каждого ITSM-процесса формулируются через его уникальное назначение. Например, для управления инцидентами цель: 'Сократить время устранения инцидентов на 10% к концу квартала'. Для управления проблемами: 'Уменьшить количество повторяющихся инцидентов на 15% через внедрение анализа корневых причин'. Все цели должны быть измеримыми, конкретными и напрямую влиять на качество ИТ-услуг, соответствуя принципам SMART и ориентируясь на потребности конечных пользователей.

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

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

Для траектории "Падшая звезда" рекомендуется дать агенту более узкое поле деятельности с конкретными одной-двумя целями, постепенно расширяя его при успешном освоении. Для траектории "Боевой товарищ" важно не расслабляться и продолжать поддерживать развитие специалиста, предоставляя возможностей чуть больше, чем требуется в текущий момент. Для траектории "Заряженная пружина" необходимо искать способы качественного развития (разные типы команд, дополнительные виды деятельности), а не только количественного увеличения задач, чтобы не потерять талантливого сотрудника.

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

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