Сервисная эмпатия (Service empathy) — это способность распознавать, понимать, прогнозировать и проецировать интересы, потребности, намерения и опыт другой стороны для установления, поддержания и улучшения сервисных отношений. Она не сводится к простому сочувствию, а включает в себя более сложный процесс — полное понимание, отражение и разделяние чувств, потребностей и мотивации клиента. Эмпатия в сервисе позволяет не только реагировать на уже существующие запросы, но и предугадывать скрытые потребности клиентов, предлагая решения, о которых они сами могли не думать. Это явление является ключевым элементом для создания позитивного клиентского опыта (CX) и пользовательского опыта (UX), формируя лояльность и доверие к компании. Основой сервисной эмпатии выступает умение «встать на место» клиента, что позволяет лучше понять его ситуацию и ожидания.

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

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

В ITIL определены несколько ролей в области управления изменениями: Владелец практики (Practice owner) - отвечает за общее управление, развитие и стратегическое направление практики; Менеджер изменений (Change manager) - управляет всеми аспектами практики 'Поддержка изменений', включая управление жизненным циклом отдельных изменений; Координатор изменений (Change coordinator) - выполняет те же обязанности, что и менеджер изменений, но в ограниченном контексте; Председатель Консультативного совета по изменениям (CAB chair); Участники Консультативного совета по изменениям; Инициатор изменений. Роли могут комбинироваться в зависимости от размера и структуры организации.

CMDB (Configuration Management Database) играет ключевую роль в оценке влияния major-инцидента на ИТ-услуги. С её помощью можно определить, каким пользователям и сервисам оказывается воздействие и насколько оно критично, что позволяет целенаправленно информировать затронутые группы и правильно оценивать последствия инцидента. Данные CMDB помогают установить причинно-следственные связи между компонентами ИТ-инфраструктуры и конечными сервисами, обеспечивая более точное управление инцидентом и снижение времени реагирования.

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

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

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

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

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