Нужно закладывать в стратегию снижение количества обращений на пользователя в долгосрочной перспективе. Это связано с ростом компьютерной грамотности, внедрением self-service решений (например, баз знаний и чат-ботов) и улучшением качества услуг. При планировании важно анализировать не только текущие метрики, но и динамику факторов: переход на облачные технологии, автоматизацию рутинных запросов, обучение пользователей. Это позволит оптимизировать штат поддержки и перенаправить сотрудников на сложные задачи.

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

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

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

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

Роль формального менеджера и неформального лидера в проектной команде отличаются по источнику авторитета и способу влияния на команду. Формальный менеджер имеет официальный статус, назначенный руководством, и обладает правом давать указания, распределять задачи и оценивать результаты работы. Он обычно отвечает за соблюдение сроков, бюджета и качества проекта. Неформальный лидер, напротив, приобретает авторитет благодаря личным качествам, опыту или уважению со стороны коллег, и его влияние строится на доверии и уважении, а не на должностных полномочиях. Неформальный лидер может возникнуть на любой роли в команде, даже на позиции, не предполагающей руководства (например, как руководитель каменоломни в игре 'Египет'). В то время как формальный менеджер часто фокусируется на процессах и выполнении задач, неформальный лидер может сильнее влиять на мотивацию и командный дух.

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

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

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

Шаг Plan (Планируй) в цикле Деминга предполагает разработку плана улучшений, формулировку гипотез и определение метрик для измерения результатов. В то время как шаг Act (Корректируй) сосредоточен на принятии решений относительно дальнейших действий после анализа результатов проверки (Check). Act включает либо внедрение успешных улучшений в постоянную практику, либо игнорирование неудачных результатов, либо запуск цикла заново с учетом накопленного опыта. Таким образом, Plan направлен на планирование изменений, а Act — на определение дальнейшего развития процесса после реализации и оценки этих изменений.