Автор полагает, что в книгах ITIL разделение назначения (purpose), целей (goals) и задач (objectives) сформулировано небрежно, потому что: - Отсутствует чёткая и однозначная терминология, что приводит к путанице между этими концепциями. - Не раскрыты практические аспекты применения: например, где и как документировать назначение, цели и задачи процесса. - Нет явного указания на различную стабильность этих элементов (назначение стабильно, цели часто меняются), что влияет на способы их фиксации в документации. - Не указана ответственность по уровням: кто именно (дизайнер, владелец или менеджер процесса) должен работать с каждым элементом. Это заставляет практиков "долго доходить" до понимания этих различий, несмотря на их относительную простоту и важность для практического внедрения ITIL.

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

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

Тело делового письма должно быть кратким и структурированным по следующей схеме: 1) Приветствие – например, «Петр Петрович, добрый день!», которое настраивает коллегу на позитивный лад; 2) Благодарность – выражение признательности за прошлую помощь, что поддерживает положительные отношения; 3) Основание – указание причины обращения, например, «На основании приказа №…» или «По результатам встречи…»; 4) Суть – краткое изложение текущей ситуации без эмоционального окраса; 5) О чем просим/требуем – четко сформулированный запрос или требование с указанием сроков; 6) Подпись – полная информация об отправителе, включая должность и контактный телефон. Такая структура помогает получателю быстро понять суть запроса и необходимые действия.

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

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

Эффективным методом является постоянное ответы на четыре базовых вопроса: Зачем? Что? Кто? Как? Такой подход применяется на каждом этапе — при определении бизнес-задач, процедур, элементов учёта и информационных объектов. Он позволяет отделить ключевые задачи от второстепенных, корректно выстроить процесс и ролевую модель, а также сформировать точные требования к инструменту автоматизации.

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

Референтная модель стандарта INCITS 359-2012 состоит из двух частей: референтная модель и административная функциональная спецификация. Референтная модель определяет множества элементов, которыми оперирует стандарт: пользователи, роли, права доступа, операции и объекты (доступа). В её состав входят четыре компонента: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро является обязательным компонентом при использовании подхода RBAC и определяет минимально необходимый набор элементов и связей для построения целостной системы.

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