Согласно ITIL, в управлении мощностями выделяются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), Service Capacity Management (управление сервисной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Первый подпроцесс связан с прогнозированием и управлением мощностью на уровне бизнеса, второй – на уровне предоставляемых ИТ-услуг, третий – на уровне физических и виртуальных ресурсов.

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

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

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

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

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

Если гнаться за идеальным значением одной из сопряженных метрик, не учитывая взаимосвязь с другой метрикой, это приведет к критическому ухудшению второй метрики. Например, достижение 100% доступности первой линии при ограниченных ресурсах приведет к тому, что операторы будут торопиться и не решать обращения на месте, а лишь регистрировать их для последующей обработки, что резко снизит процент решенных обращений на первой линии, что в целом ухудшит качество сервиса.

Практическое применение модели Compass Model для улучшения услуги такси для командировочных позволяет выявить и структурировать ключевые элементы клиентского опыта: 1) По Северу (потребности) необходимо гарантировать своевременную, надёжную доставку из аэропорта до места назначения без исключений, так как это базовая необходимость. 2) По Западу (желания) можно внедрить стандарты обслуживания: обучение водителей вежливому поведению, настройка приятной музыки по умолчанию, запрет на навязчивые разговоры. 3) По Югу (стереотипы) нужно целенаправленно разрушать негативные установки: обеспечить точную подачу автомобиля по указанному адресу, пропагандировать плавную манеру вождения через обучение и мониторинг. 4) По Востоку (эмоции) важно создать комфорт с самого начала взаимодействия: например, отправлять уведомление с фотографией водителя и номером машины, обеспечивать возможность выбора музыки, предоставлять информацию о времени в пути. Это комплексный подход, который не только удовлетворяет базовые потребности, но и создаёт превосходящий ожидания опыт.

В описанной визуализации ограниченность ресурсов команды учитывается несколькими способами: во-первых, явно указываются ресурсные ограничения на доске канбан, что позволяет видеть максимальную загрузку; во-вторых, введено разделение на плановую и неплановую работу, где выделяется определенная часть ресурса на неожиданные задачи вроде инцидентов и исправления дефектов; в-третьих, используется ограничение числа задач в работе (WIP Limit), чтобы не перегружать отдельные этапы процесса; и, в-четвертых, есть ясная картина загрузки ресурсов и ограничений, которая помогает принимать решения о том, какие задачи брать в работу, а какие отложить.

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