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

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

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

Минимальная схема измерения доступности ИТ-услуг в бизнес-терминах включает следующие шаги: 1) выделение функциональных блоков (направлений) на стороне заказчика; 2) сопоставление ИТ-систем с функциональными направлениями заказчика; 3) определение критериев доступности для компонентов ИТ-услуг; 4) реализация сбора данных о (не)доступности ИТ-услуг и их компонентов; 5) расчёт доступности ИТ-обеспечения функциональных блоков на основе данных о доступности соответствующих ИТ-услуг и компонентов. Эта схема рассматривается как отправная точка, от которой можно постепенно двигаться к более детализированному учёту критических бизнес-функций (VBF).

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

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

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

Аспекты работы тимлида, которые снижают самоорганизацию команды, включают монополизацию принятия архитектурных решений («как папа скажет»), замыкание код-ревью только на себе, формальное согласование стандартов без реального участия команды, принятие решений по задачам и их распределению без участия всей команды, выступление единственным представителем команды во внешних коммуникациях. Эти практики приводят к тому, что команда перестает чувствовать ответственность за общий результат, полагаясь на одного человека в ключевых вопросах, и теряет возможность развивать навыки совместного принятия решений.

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

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