Преодоление сопротивления требует времени, упорства и воли. 'Человек процесса' должен четко объяснять цели изменений, демонстрировать их выгоды и последовательно работать над улучшением процессов. Важно создать культуру, в которой изменения воспринимаются как неотъемлемая часть развития, а не как временное явление. Это требует постоянного обучения и коммуникации с сотрудниками.

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

Модель изменений должна настраивать параметры, связанные с порядком обработки и спецификой применения. Во-первых, необходимо определить порядок обработки изменения — через какие этапы оно проходит, на каких этапах требуется согласование, необходимо ли включение в релиз и другие регламентированные действия. Для некоторых направлений возможно предусмотреть опциональные этапы, например, работы по ИТ-инфраструктуре, которые можно выполнять только в рабочей среде. Также может существовать общий мастер-порядок для всех информационных систем, включающий обязательное приёмочное тестирование в выделенной среде. Во-вторых, необходимо задать параметры, которые модель должна учитывать при применении одного и того же порядка обработки к различным информационным системам или направлениям в ИТ-инфраструктуре. Это могут быть: - лица, ответственные за координацию изменений данной категории или направления, - лица, уполномоченные на согласование этапов, - конкретные результаты, ожидаемые на выходе определённых этапов (например, документы). Структура классификатора для таких параметров будет матрично-иерархической, где для групп систем или направлений определены типовые порядки обработки и соответствующие наборы параметров.

В контексте оценки качества ИТ-услуг термин 'utility' (полезность) относится к функциональной пригодности услуги для удовлетворения потребностей заказчика, то есть предоставлению необходимых функций и возможностей. Термин 'warranty' (гарантия) касается надежности, доступности, безопасности и других аспектов, обеспечивающих качество выполнения услуги. Таким образом, utility отвечает на вопрос 'делает ли услуга то, что нужно?', а warranty – 'делает ли она это стабильно и безопасно?'

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

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

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

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

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

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