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

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

Для оценки результатов PIR применяются инструменты бизнес-аналитики (на пример, Power BI, Tableau), которые визуализируют данные по KPI, бюджету и срокам. Также используются опросники (например, SurveyMonkey) для сбора обратной связи от пользователей. В ИТ-сфере активно задействуются мониторинговые системы (Nagios, Zabbix), чтобы оценивать технические показатели после внедрения изменений.

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

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

Показатель SPI (Schedule Performance Index) в методике EVM работает адекватно в процессе выполнения проекта, показывая соотношение запланированного объёма работ к фактически выполненному. Например, если в проекте рытья канавы длиной 20 метров пришлось работать с меньшей производительностью из-за болезни одного рабочего, SPI в первые дни будет корректно показывать отставание (например, 50%). Однако к концу проекта, когда весь объём работ выполнен, даже с задержкой, SPI автоматически становится равным 1, что скрывает реальное отставание в сроках и вводит в заблуждение при оценке соблюдения временных рамок проекта.

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

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

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

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