BRM (Business Relationship Management) принципиально отличается от менеджера по продажам своей основной целью и фокусом деятельности. Основная цель BRM – построение и поддержание долгосрочных партнерских отношений с заказчиком, ориентированных не на продажи и прибыль сервис-провайдера, а на ценность и удовлетворенность заказчика. BRM выступает в роли «голоса заказчика» внутри сервис-провайдера, передавая понимание бизнес-задач и ожиданий заказчика. В отличие от менеджера по продажам, BRM не фокусируется на заключении сделок и достижении краткосрочных финансовых целей. Предостережение в тексте гласит, что неаккуратное сочетание задач BRM с sales и pre-sale активностями может быстро выхолостить понятие business relationships, так как истинные business relationships не про продажи, а про партнерство с заказчиком.

Для расчета интегрального показателя качества для множества услуг рекомендуется сначала разделить все услуги на группы по степени их важности: mission-critical, business-critical и обычные. Для каждой группы рассчитывается свой интегральный показатель, возможно, с использованием разных методов агрегирования. Например, для mission-critical услуг можно применять среднее геометрическое, так как здесь каждая метрика критически важна. Для business-critical услуг подойдет среднее арифметическое. Затем полученные групповые показатели объединяют в общий интегральный показатель с использованием среднего арифметического или геометрического, возможно, с присвоением различных весов каждой группе в соответствии с их важностью для бизнеса.

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

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

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

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

Книга рекомендует даже в ситуациях, когда ИТ-подразделение находится внутри компании, рассчитывать стоимость услуг и управлять ИТ-подразделением почти как бизнесом (more like a business), даже если фактических взаиморасчетов с бизнес-подразделениями нет. Это позволяет ИТ-руководству более четко обосновывать затраты, выстраивать сервисные отношения с бизнесом, определять приоритеты развития и доказывать ценность ИТ для компании. Учет стоимости услуг помогает в принятии решений о развитии или закрытии тех или иных сервисов и делает ИТ-менеджмент более прозрачным и понятным для бизнес-руководства.

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

Лидер-слуга не всегда эффективен, потому что его подход лучше всего работает с командами на поздних стадиях развития («Яркая молодость» и частично «Пубертат»), но не подходит для начинающих команд на уровне «Детский сад», которые еще не могут самостоятельно идентифицировать проблемы и решения. На первых этапах формирования команды необходим более директивный подход, когда лидер активно участвует в организации процессов и постепенно расширяет зону самостоятельности по мере развития способностей команды. На стадии «Пубертат» лидер-слуга может быть эффективен, но здесь также требуется умение «продавать» решения, так как директивное управление уже не работает. На уровне «Зрелость» лидер-слуга вообще не нужен, требуется лидер-партнер с высоким уровнем полномочий.

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