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

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

Для крупных ИТ-департаментов особенно критично наличие качественной системы управления по следующим причинам: - Больший размер создает сложность в координации и управлении процессами. - При наличии 1000 человек в департаменте может потребоваться 100-120 руководителей, для которых сложно найти квалифицированных кандидатов. - Отсутствие подходящей системы управления приводит к мультипликации ошибок из-за неэффективной работы управленческой надстройки. - Крупные компании не могут конкурировать за лучших специалистов высокими зарплатами с крупными ИТ-гигантами и стартапами. - В условиях высокой конкуренции за квалифицированных специалистов необходима система, которая могла бы эффективно развивать имеющийся персонал. - Иерархические структуры становятся особенно неэффективными при масштабировании. - Увеличивается необходимость в координации между разными частями организации.

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

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

Ключевые метрики относительно проще внедрить, потому что современные инструменты вроде Jira позволяют грамотно настроить учет задач с необходимыми отсечками времени, как минимум по статусам, что уже является существенной частью реализации. С метриками сложнее, но инструменты есть, а стандарты и практики представляют большую сложность, так как требуют четкого определения для компании, что является хорошим и плохим в организации работы. В одной и той же организации могут существовать разные мнения и практики (например, по поводу тестирования кода), когда одни считают автоматизированное тестирование лишней тратой ресурсов, а другие строго следуют практике TDD (разработка через тестирование). Чтобы разработать единые стандарты, необходимо провести серьезную работу по согласованию подходов и методов, что требует значительных усилий и времени.

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

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

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

Чтобы проверить систему на наличие ненужных показателей, необходимо убедиться, что каждый показатель напрямую связан с конкретной целью и используется для принятия решений. Если на вопрос «Зачем это измеряется?» нет чёткого ответа, такой показатель, вероятно, лишний. Также важно проверять, влияет ли показатель на поведение сотрудников в нужную сторону и можно ли его достаточно точно измерить без риска фальсификации.