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

Уровень зрелости процесса по модели COBIT 5 PAM определяется не количеством или формальным оформлением документов, а фактом систематического выполнения управленческих практик и наличием подтверждающих свидетельств. Документы рассматриваются как один из возможных источников доказательств, но не как обязательное условие. Если управление процессом организовано эффективно и стабильно, то будут существовать реальные свидетельства его работы — будь то планы улучшений, результаты измерений, записи встреч или устные подтверждения от участников. Формальные документы без реальной деятельности не создадут устойчивой способности процесса достигать целей и будут выявлены оценщиком как недостаточные или несоответствующие.

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

Availability (Availability) представляет собой показатель, определяющий, насколько система, компонент или услуга могут быть использованы в заданное время. В технической надежности, согласно ГОСТ 27.002-89 (ГОСТ Р 53480-2009), этот термин переводится как «готовность». В ITIL и ISO/IEC 20000 он трактуется как «доступность». Разница кроется в контексте применения: «готовность» акцентирует внимание на технической способности системы функционировать, тогда как «доступность» в ИТ-управлении связана с предоставлением услуги пользователю. Термины отражают разные аспекты одной метрики и требуют уточнения в документах для избежания неоднозначности.

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

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

На объединенном радаре линия результативности показывает текущую пользу, которую процессы приносят организации, измеряемую по шкале от 0 до 100%. Эта линия отражает фактическую эффективность выполнения процессов в свете бизнес-целей. Линия зрелости, в свою очередь, характеризует уверенность в том, что организация сможет продолжать получать эту пользу даже при изменяющихся условиях. Это показывает, насколько надежно процессы построены и документированы, и насколько легко их можно масштабировать или адаптировать. Другими словами, результативность — это «функциональность», а зрелость — это «гарантия», аналогично известной концепции ITIL.

Процесс управления проблемами инициируется не внешними событиями (в отличие от инцидентов), а внутренними механизмами: анализ тенденций множества инцидентов, плановые аудиты, результаты диагностики инцидентов, данные мониторинга систем и рекомендации экспертных групп (например, PRB). Для эффективной работы необходимо внедрить регулярные проверки этих источников и чётко прописать критерии создания записи о проблеме.

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

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