Высокий процент дефектов в бэклоге (от 50% до 70%) может считаться нормой в некоторых командах из-за искажения восприятия, вызванного изоляцией от внешних стандартов и отсутствием объективных метрик. В таких командах сложилась привычка, что большое количество ошибок — это обычная ситуация, особенно если нет возможности сравнить свою работу с работой других команд или отраслевыми стандартами. Коллективное мнение вроде «бывало и хуже» укрепляет это представление, и сотрудники перестают видеть проблему, так как ежедневно взаимодействуют с этим состоянием и перестают замечать его ненормальность.

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

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

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

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

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

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

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

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

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