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

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

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

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

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

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

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

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

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

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