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

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

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

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

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

Аспект 'Информация и технологии' относится к информационным ресурсам и технологиям, использованным для хранения, обработки и создания информации в процессе предоставления ИТ-услуг. Он включает не только инструменты предоставления услуг (ITSM, совместной работы, инвентаризации, CMDB, анализа), но и передовые технологии вроде искусственного интеллекта, машинного обучения, облачных решений, мобильных платформ. Важно учитывать, какая информация управляется услугами, какая вспомогательная информация необходима, как информация защищается, управляется, архивируется и удаляется. Управление информацией должно быть целостным и соответствовать требованиям законодательства (например, соблюдение ФЗ 'О персональных данных'). Информация и технологии зависят от их использования и архитектуры, включая приложения, базы данных, системы связи и инфраструктуру.

Разные процессные модели объединяют базовые понятия (доступность, мощность, непрерывность, безопасность) по-разному из-за различий в методологических подходах и целях моделей. Например, ITIL разделяет их на четыре отдельных процесса, тогда как другие стандарты, такие как COBIT 5 и MOF 4, могут объединять доступность и непрерывность или все параметры — в понятие «надежность». Это связано с тем, что структура процессов и их группировка зависят от фокуса модели: одни делают упор на детализацию и специализацию, другие — на минимизацию количества процессов и упрощение управления.

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

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

Для улучшения процесса управления инцидентами с помощью цикла Деминга сначала нужно определить проблему (например, долгие сроки решения инцидентов). На этапе Планируй (Plan) анализируется процесс с использованием инструментов вроде Expanded Incident Lifecycle, выявляются узкие места и разрабатывается гипотеза решения (например, немедленное решение простых инцидентов). На этапе Выполняй (Do) реализуется гипотеза в течение определенного периода. На этапе Проверяй (Check) оценивается эффективность изменений через опросы пользователей и анализ метрик. На этапе Корректируй (Act) принимается решение о дальнейших действиях: если результаты неудовлетворительны, цикл запускается заново с новыми корректировками (разделение персонала на группы для простых и сложных инцидентов), а при успехе улучшения внедряются в постоянную практику.