ISO 27031 (Guidelines for ICT Readiness for Business Continuity) описывает вопросы управления ИТ-системами для гарантии обеспечения непрерывности бизнеса в соответствии с подходом, установленным в стандарте ISO 22301. Стандарт был ранее известен как BS 25777 и практически не изменился при переходе в семейство стандартов по информационной безопасности.

Таблица соответствия необходима для фильтрации установленного программного обеспечения, чтобы учитывать только те продукты, требующие лицензирования. Поскольку сканер сети возвращает данные обо всех установленных программах (включая те, которые не подлежат лицензированию), а названия ПО в результатах сканирования часто не совпадают со стандартными наименованиями, человеку требуется вручную сопоставлять записи. Это позволяет исключить из учёта массу ненужного ПО и сосредоточиться на критически важных для лицензирования продуктах.

Обучение помогает преодолеть проблемы с внедрением измерений потока создания ценности, так как оно даёт участникам процесса необходимые знания и навыки для правильной работы с метриками. Проходя специализированные курсы, такие как 'Flow Metrics', участники учатся не только интерпретировать данные, но и формулировать правильные вопросы для анализа. Это помогает тим-лидам, членам команды и руководителям понять, как измерения могут быть полезны в их повседневной работе и улучшить результаты бизнеса.

Подход с разделением ALM для разработки и ITSM для эксплуатации соответствует уровню зрелости «Controlled» в модели KPMG maturity phases model of the IT organisation. На этом этапе операционные процессы, такие как управление инцидентами, изменениями и релизами, контролируются и стандартизированы, но отсутствует сквозная ответственность за ИТ-услуги как целостные элементы, влияющие на бизнес-процессы. Такой уровень зрелости может быть достаточным для организаций, где нет высокой потребности в изменении ИТ-инфраструктуры ради поддержки бизнеса.

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

Метод EVM нельзя считать полноценной системой измерения успешности завершённых проектов, прежде всего из-за недостатка показателя SPI, который теряет информативность к концу проекта, автоматически становясь равным 1, что не отражает реального соблюдения сроков. Хотя EVM предоставляет ценные метрики для текущего управления проектом, особенно в части контроля бюджета через CPI, его структура не позволяет провести адекватную пост-оценку проекта по временным показателям, что критично для комплексной оценки успешности проекта, включающей качество, сроки и соответствие бюджету.

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

Перед внедрением системы измерений необходимо ответить на следующие ключевые вопросы: что, как и зачем мы измеряем; когда начали измерять и когда планируем завершить; на кого ориентированы результаты измерений и как они будут использоваться. Без ответов на эти вопросы работа по составлению раздела KPI будет бессмысленной и поверхностной.

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

В ITIL 4 роль менеджера уровня услуг не упоминается в руководстве по одноименной практике, потому что картина с ролями в новой версии ITIL была значительно упрощена. В отличие от ITILv3, где эта роль была более четко определена, в ITIL 4 акцент сместился на упрощение и практическую применимость, что соответствует общему направлению развития фреймворка. Это решение помогает избежать избыточного усложнения системы управления и бесплодных споров о распределении задач между различными ролями, что согласуется с применением принципа 'Keep it simple and practical'.