Архитектурные решения критически важны, потому что сложные, монолитные системы, созданные годами и состоящие из тесно связанных компонентов, просто не могут поддерживать высокую скорость разработки. Такие системы, где аббревиатура 'CI/CD' вызывает удивление или смех, принципиально не позволяют достигнуть кратного ускорения. Чтобы достичь значительного снижения Time to Market, необходимо провести работу над архитектурой: разбить монолит на микросервисы или модули, внедрить автоматизацию тестирования и развертывания, создать условия для параллельной работы нескольких команд без постоянных конфликтов. Эти изменения требуют значительных усилий и инвестиций, но без них реальное кратное ускорение невозможно.

Другие стандарты подходят к управлению доступностью иначе, чем ITIL. Например, ISO/IEC 20000 объединяет управление доступностью с управлением непрерывностью, COBIT5 и CMMI для сервисов связывают его с управлением мощностями, MOF включает его в функцию надежности вместе с управлением непрерывностью, мощностями и безопасностью. Авторы ISM Method относят управление доступностью к управлению качеством (Quality Management), наряду с другими аспектами, такими как безопасность и непрерывность. Это свидетельствует о том, что в других стандартах управление доступностью не выделено отдельно как самодостаточный процесс.

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

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

Основные ограничения гибких методологий в контексте эксплуатации ИТ связаны с их фокусом на разработке и временных целях, а не на долгосрочной поддержке. Гибкие методологии, такие как 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, что скрывает реальное отставание в сроках и вводит в заблуждение при оценке соблюдения временных рамок проекта.