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

Согласно ITIL 4, при формировании сервисного предложения (service offering) используются три типа сущностей: 1. Товары (goods) – то, что передаётся потребителю, после чего сам потребитель отвечает за их использование (например, wifi-маршрутизатор в подарок при подключении домашнего интернета). 2. Доступ к ресурсам – ресурсы, к которым получает доступ потребитель (например, сеть, к которой подключается абонент, или почтовый/прокси/p2p сервер). 3. Сервисные операции (service actions) – деятельность, выполняемая представителями поставщика, потребителя или ими совместно (например, взаимодействие со службой поддержки). Эти три типа сущностей позволяют комплексно описать то, что поставщик услуги предлагает потребителю.

В контексте противопоставления оперативных вопросов и развития под 'развитием' понимаются долгосрочные задачи, направленные на рост как личный, так и компании в целом. Это не те задачи, которые приносят немедленное удовлетворение или решают текущие проблемы, но которые необходимы для будущего успеха. К таким задачам можно отнести: - Стратегическое планирование - Обучение новым навыкам и технологиям - Создание новых бизнес-моделей и процессов - Развитие команды и культуры компании - Инвестиции в перспективные, но пока нерентабельные направления Автор отмечает, что на такие задачи время обычно выделяется по остаточному принципу, то есть почти не выделяется, что создаёт проблему для долгосрочного развития.

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

Поток ценности должен включать в себя как процессы 'изменения бизнеса' (change the business), так и процессы его 'функционирования' (run the business). Если в поток включать только процессы изменения, то существует риск потерять ту самую ценность, которую так тщательно создавали, так как без поддержки текущих операций невозможно обеспечить стабильную подачу ценности клиентам. Баланс между развитием и поддержкой критически важен для долгосрочного успеха бизнеса.

Для организации ИТ-систем с точки зрения обеспечения бизнес-непрерывности рекомендуются стандарт ISO 27031 (Guidelines for ICT Readiness for Business Continuity), который ранее был известен как BS 25777, и ГОСТ Р ИСО/МЭК 18044-2007 (Информационная технология - Методы и средства обеспечения безопасности - Менеджмент инцидентов информационной безопасности). Эти документы содержат руководства по управлению ИТ-инфраструктурой для поддержания непрерывности бизнес-процессов и организации реагирования на инциденты.

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

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

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

Предложенная метрика времени реакции на инциденты имеет три важные характеристики: 1) она нормирована в диапазоне от 0 до 1, что позволяет легко сравнивать результаты в разных группах и за разные периоды; 2) расчет рекомендуется проводить не для всего инцидента, а для каждого отдельного назначения в функциональные группы, учитывая возможные множественные обращения к одной и той же группе; 3) наиболее информативным является анализ метрики в разрезе по функциональным группам поддержки, что помогает выявить конкретные группы, требующие оптимизации в части времени реакции.