Реализовавшийся риск - это уже наступившее (не потенциальное) негативное событие, которое наносит вред, приводит к потерям и затрудняет достижение целей. Хотя в ITIL4 нет точной формулировки «реализовавшийся риск», это понятие выводится из определения риска как потенциальной причины негативного воздействия.

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

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

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

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

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

RASCI-матрица - это расширение классической RACI-матрицы, где к стандартным ролям добавлено дополнительное значение S (Supports). Стандартные значения в RACI расшифровываются как: R (Responsible) - непосредственный исполнитель задачи, A (Accountable) - ответственный за конечный результат, C (Consulted) - те, кого нужно проконсультировать в процессе выполнения задачи, I (Informed) - те, кого нужно информировать о результатах. В RASCI добавляется S (Supports), что означает участников, которые поддерживают выполнение задачи и вносят вклад в результат, но не несут ответственности за процесс или конечный результат. Это позволяет более точно распределить роли, особенно когда в задаче участвует большое количество людей, и четко разделить тех, кто организует работу, и тех, кто просто оказывает поддержку в процессе выполнения.

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

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

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