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

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

Удаленная работа существенно увеличивает запросы в краткосрочной перспективе, как это было в 2020 году (+16%). Это связано с необходимостью адаптации инфраструктуры (настройка удаленного доступа, обеспечение безопасности), а также с ростом числа проблем, возникающих из-за недостатка технических навыков у пользователей. Однако в долгосрочной перспективе, после стабилизации процессов, нагрузка снижается благодаря стандартизации решений и обучению сотрудников.

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

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

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

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

Управление доступностью и управление непрерывностью тесно связаны, так как оба процесса ориентированы на обеспечение бесперебойной работы ИТ-услуг. В некоторых стандартах, таких как ISO/IEC 20000, они объединены в один процесс. Это обусловлено тем, что оба процесса направлены на предотвращение сбоев и минимизацию их последствий. Управление доступностью фокусируется на обеспечении требуемого уровня доступности услуг, а управление непрерывностью — на восстановлении услуг после инцидентов, связанных с непредвиденными простоями.

Для построения дерева отказов для функции «Обработка обращений» следует выполнить следующие шаги: определить топ-событие (отказ функции обработки обращений); выявить прямые причины этого отказа на первом уровне (например: недоступность базы данных, ошибки в логике обработки, проблемы с сетью между компонентами); для каждой из этих причин определить более низкоуровневые события, пока не достигнуты базовые события, которые уже не требуют дальнейшей декомпозиции (сбои оборудования, программные ошибки, действия персонала). При этом следует использовать правильные логические операторы между событиями («И», «ИЛИ» и др.). Например, если для отказа обработки обращений необходимо одновременное отсутствие сетевой связности между сервером и БД, а также сбой в прикладном слое – используется оператор «И». Если же достаточно одного из этих условий – оператор «ИЛИ». Базовые события размещаются на листьях дерева и могут быть оценены количественно для последующего расчета вероятности топ-события.

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