Типичные ошибки: завышение данных из-за непонимания 'кванта времени', использование искусственных нормативов (например, минимум 15 минут), игнорирование параллельных задач, распределение времени по шаблону '100%', а также восприятие учёта как инструмента контроля, а не анализа. Это приводит к искажению данных и потере доверия. Важно избегать жёстких правил, обучать сотрудников методам оценки и фокусироваться на использовании статистики для улучшения процессов.

В ITIL4 по сравнению с ITIL V3 в управлении изменениями произошли следующие ключевые изменения: была введена официальная роль менеджера изменений (Change manager) как специфическая роль для практики 'Поддержка изменений'; практика управления изменениями получила новое название - 'Поддержка изменений' (Change enablement), что отражает более активную роль в поддержке изменений, а не просто их одобрении или отклонении; роль фокусируется не только на управлении отдельными изменениями, но и на развитии самой практики; была введена дополнительная роль координатора изменений для работы в ограниченном контексте; структура управления стала более четкой с разделением на владельца практики, менеджера изменений и возможных координаторов изменений.

Для траектории "Падшая звезда" рекомендуется дать агенту более узкое поле деятельности с конкретными одной-двумя целями, постепенно расширяя его при успешном освоении. Для траектории "Боевой товарищ" важно не расслабляться и продолжать поддерживать развитие специалиста, предоставляя возможностей чуть больше, чем требуется в текущий момент. Для траектории "Заряженная пружина" необходимо искать способы качественного развития (разные типы команд, дополнительные виды деятельности), а не только количественного увеличения задач, чтобы не потерять талантливого сотрудника.

Четвертый шаг цикла Деминга (Act) заключается в принятии решений относительно дальнейших действий после проверки результатов изменений. Он включает ответ на вопрос: 'Что делать дальше?'. Это может означать внедрение успешных улучшений в стандартную практику, игнорирование неудачных результатов без дополнительных изменений или запуск нового цикла PDCA с учетом полученного опыта. Act фокусируется на итоговой корректировке подхода и определении дальнейшей стратегии улучшений, что отличает его от этапа планирования, который предваряет непосредственное выполнение изменений.

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

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

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

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

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

Да, Ops входит в перечень технических направлений, которые может быть целесообразно привлекать со стороны, но с определенными нюансами. В контексте организации работы команды и делегирования ответственности, Ops (операционная деятельность, эксплуатация) может быть передана внешним исполнителям при условии наличия четкой архитектуры инфраструктуры, стандартизированных процессов и четких SLA. Однако стоит учитывать, что уровень ответственности за эксплуатацию напрямую зависит от критичности этих операций для продукта. Например, если продукт требует настройки и постоянного мониторинга кастомизированного middleware, то привлечение внешних экспертов может быть частичным и не подходит для критически важных систем. В идеале, команда должна сохранить контроль над конфигурированием и автоматизацией middleware, тогда как физическое развертывание и управление базовыми ресурсами (IaaS) могут быть переданы внешней стороне.