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

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

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

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

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

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

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

Тип поставщика услуг согласно ITIL значительно влияет на структуру раздела штрафных санкций в Соглашении об уровне обслуживания (SLA). Для внутренних поставщиков (Тип I и Тип II) штрафы редко выражаются в денежной форме, а чаще затрагивают систему премирования сотрудников ИТ-подразделения. Для внешних поставщиков (Тип III) штрафные санкции обычно фиксируются в контракте как процент от суммы договора и могут варьироваться в пределах 20-30%. При этом, даже для внешних поставщиков, структура и размер штрафов могут быть ограничены законодательством, например, как в случае с 44-ФЗ, где размер штрафа составляет всего от 0,5% до 2,5% от суммы контракта.

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

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