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

Традиционная схема оценки влияния инцидентов имеет несколько существенных недостатков: 1) Сотрудник может не знать, испытывают ли его коллеги аналогичные проблемы, что затрудняет оценку масштаба инцидента. 2) Не существует четкой границы между 'совсем не работает' и 'частично не работает' - пользователь, столкнувшийся с проблемой печати отчета, вряд ли согласится, что эта проблема малозначительна, даже если остальные функции работают нормально. 3) Базовая схема не учитывает критичность определенных ИТ-услуг в конкретные периоды времени или для определенных групп пользователей.

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

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

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

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

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

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

Шестой принцип DevOps по DASA 'Автоматизируйте всё, что можете' охватывает два основных аспекта автоматизации: во-первых, автоматизацию процессов разработки программного обеспечения, включая непрерывную поставку (continuous delivery), которая сама подразумевает непрерывную интеграцию (continuous integration) и непрерывное развёртывание (continuous deployment). Во-вторых, автоматизацию всего инфраструктурного ландшафта, что в современных практиках реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Такой широкий взгляд на автоматизацию позволяет снизить человеческий фактор, ускорить процессы разработки и доставки, повысить надёжность и воспроизводимость систем, а также обеспечить возможность быстрого масштабирования и восстановления систем при необходимости.

Процесс BRM в ITIL Service Strategy выполняет три ключевые функции: 1) Установление и поддержание отношений между сервис-провайдером и заказчиком на основе глубокого понимания бизнес-потребностей заказчика; 2) Помощь заказчику в определении ценности получаемых ИТ-услуг и понимании того, как эти услуги поддерживают его бизнес-цели; 3) Определение текущего и будущего спроса на услуги, а также обеспечение возможности сервис-провайдера удовлетворять эти потребности в различных условиях. BRM фокусируется именно на отношениях и удовлетворенности заказчика, в отличие от других процессов ITIL, которые сосредоточены преимущественно на техническом обеспечении качества услуг.