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

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

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

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

Тем, кто интересуется методикой измерения в ИТ, доступны следующие бесплатные ресурсы: заметки на портале Real ITSM, статьи на сайте Cleverics и вебинары CleverTALK. Эти ресурсы помогают получить первоначальное представление о теме и определить дальнейшие шаги: покупку книги, участие в учебном курсе, заказ диагностики или консалтинга.

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

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

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

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

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