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

Business Relationship Management (BRM) и Service Level Management (SLM) служат основой для ИТ-бюджетирования, поскольку через них определяются потребности бизнеса и ожидаемые объемы потребления услуг. BRM обеспечивает понимание стратегических бизнес-планов и целей, а SLM переводит эти цели в конкретные соглашения об уровне услуг с заказчиками. Эти данные являются отправной точкой для всего процесса бюджетирования, обеспечивая, что ИТ-бюджет будет согласован с бизнес-потребностями и направлен на достижение конкретных результатов.

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

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

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

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

Для адаптации формулы FTR к расчёту в разрезе рабочих групп необходимо уточнить определение операнда Nj, заменив его суммой успешных решений (Cj) и возвратов на доработку (Sj). Формула принимает вид: FTR = (Nj - Sj) / Nj, где Nj = Cj + Sj. Также важно учитывать возвраты по каждой группе индивидуально, чтобы избежать искажения результатов из-за переназначения инцидентов между группами или повторных возвратов.

В тексте упоминаются несколько бизнес-игр, которые ярко демонстрируют проблемы с коммуникациями: Apollo-13, Grab@Pizza и 2020. Эти игры имитируют реальные ситуации, в которых участники сталкиваются с трудностями из-за неправильной передачи информации. Например, в игре Apollo-13 команде необходимо спасти космический корабль, но из-за недостаточной коммуникации может возникнуть ситуация, когда корабль «не возвращается» к Земле. В игре Grab@Pizza возникают проблемы с искажением бизнес-требований при передаче их от заказчика к исполнителю, что приводит к неверному выполнению задач. В игре 2020 участники сталкиваются с ситуацией, когда «наш айсберг тает» из-за неправильно организованных коммуникаций. Все эти примеры показывают, как незначительные ошибки в коммуникации могут привести к серьезным последствиям в выполнении задач.

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

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