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

Согласно информации из текста, значительная часть ITSM-проектов (от 60% до 80%) являются провальными в той или иной степени. Это подчеркивает важность правильного подхода к управлению изменениями, включая уделяемое внимание обучению и вовлечению сотрудников, чтобы повысить шансы на успешное завершение проекта.

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

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

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

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

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

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

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

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