В разделе ИТ-department benefits (нижний правый квадрант) следует описать преимущества проекта для руководства ИТ-департамента. Эти преимущества должны отвечать на вопрос, какие проблемы ИТ-отдела будут решены в результате проекта. Примеры могут включать: «Основания для пересмотра ресурсного плана при превышении согласованных объемов потребления ИТ-услуг», «Сокращение числа аварийных изменений за счет улучшенного процесса управления изменениями», «Повышение эффективности распределения задач между сотрудниками ИТ-отдела». Важно сосредоточиться на тех аспектах, которые напрямую затрагивают работу и проблемы ИТ-руководителей.

График предоставления услуги определяет периоды времени, когда недоступность учитывается в расчетах уровня доступности. Например, отказы, произошедшие ночью или в выходные, праздничные дни, могут не учитываться, если это согласовано в SLA. Также исключаются из расчета периоды планового обслуживания. Таким образом, график предоставления услуги помогает отделить временные окна, когда доступность критична, от тех, когда сбои не влияют на бизнес-процессы.

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

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

Бизнесу предоставляется механизм взаимодействия, позволяющий по их собственной инициативе пересматривать соглашение. Конкретные заказчики могут заключать дополнительные соглашения по конкретным ИТ-сервисам, которые будут изменять положения общего SLA 'AS IS'. Это дает бизнес-подразделениям возможность выразить свои требования и скорректировать условия обслуживания под свои потребности, но при этом не блокирует старт процесса согласованием со всеми заинтересованными сторонами.

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

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

SIAM (Service Integration and Management) представляет собой подход к управлению услугами в условиях множества поставщиков. Его основная концепция заключается во введении уровня управления, называемого «сервис-интегратор», который располагается между организацией-заказчиком и её поставщиками услуг. Сервисный интегратор отвечает за управление, интеграцию и координацию различных поставщиков, чтобы клиент получал наилучшее качество сервиса и сокращал накладные расходы на управление множеством поставщиков. SIAM описывается в документе «SIAM Foundation Body of Knowledge», который предоставляет методологию для организации потребления услуг в моделях с несколькими внешними и внутренними поставщиками.

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

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