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

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

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

Факторы успеха практик (PSF) не ограничиваются только отдельными задачами или видами деятельности, а представляют собой комплексные функциональные компоненты, которые охватывают все аспекты управления услугами: Организации и люди, Информация и технологии, Потоки ценности и процессы, Поставщики и партнёры. Это означает, что PSF объединяют в себе различные элементы, необходимые для успешной реализации практики, включая человеческие ресурсы, технологии, процессы и взаимодействие с поставщиками и партнёрами. Например, PSF для раннего выявления инцидентов предполагает не только наличие инструментов мониторинга, но и обученных специалистов, эффективные процессы обнаружения и надежные технологии для оповещения.

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

Основные ошибки при применении COBIT 5 PAM заключаются в излишней формализации и концентрации на создании документов, а не на реальном управлении процессами. Многие стремятся просто «заполнить требуемые шаблоны», не задумываясь о смысле и практической пользе. Другая распространенная ошибка — ожидание быстрого результата без учета того, что построение стабильной управленческой надстройки требует времени и постепенных улучшений. Также часто недооценивается роль профессионального суждения оценщика, из-за чего попытки механического следования формальным требованиям приводят к искажению результатов оценки. Важно помнить, что модель предназначена для поддержки управления, а не для создания бумажной волокиты.

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

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

Одним из эффективных подходов к освоению новых практик при внедрении CI/CD является планомерное и ритмичное внедрение изменений в рамках выделенного времени, например, так называемого «налога в 20%». Это означает, что команда регулярно выделяет часть своего времени (примерно пятую часть) для постепенного внедрения необходимых технических изменений и улучшений процессов. Важно, чтобы команда сама проходила этот путь, возможно, с временной сторонней помощью, но при этом самостоятельно осваивала новые практики и отказывалась от старых. Такой подход позволяет команде не только технически реализовать изменения, но и глубоко понимать их ценность. Команда сама себе объясняет, почему теперь она делает что-то иначе — это создает внутреннее принятие новых процессов и устойчивость изменений в долгосрочной перспективе. Постепенное внедрение также снижает стресс от масштабных перемен и позволяет корректировать процесс на ходу, основываясь на получаемом опыте.

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