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

Деловая игра Grab@Pizza помогает участникам лучше понять процессы ITSM (управление сервисами информационных технологий), так как в игровой форме моделирует ситуации, в которых необходимо применять эти процессы. Участники учатся видеть карту процессов в голове, понимать, как различные элементы ITSM взаимодействуют между собой, и как они влияют на бизнес-результаты. Игра позволяет концентрированно проработать основные аспекты ITSM, что делает обучение более эффективным и запоминающимся по сравнению с традиционными методами.

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

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

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

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

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

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

Противоречие заключается в том, что процессы EDM01 и EDM05, которые должны описывать управление системой руководства ИТ, следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (например, EDM02–EDM04). При этом в COBIT 5 проводится чёткое разграничение между руководством и управлением. Если процессы EDM01 и EDM05 представляют собой процессы управления системой руководства, их структура должна быть ближе к управленческим циклам, например, PDCA (планирование-реализация-оценка-корректировка). А если это процессы руководства, тогда возникает вопрос о том, кем и в чьих интересах осуществляется руководство над системой руководства, что представляется избыточным.

Заинтересованные стороны играют ключевую роль в домене EDM COBIT 5. Процесс EDM05 напрямую связан с их потребностями, так как обеспечивает прозрачность и информирование заинтересованных сторон. Кроме того, все процессы домена EDM ориентированы на удовлетворение ожиданий и требований заинтересованных лиц. Например, процессы EDM02, EDM03 и EDM04 направлены на оптимизацию ценности, рисков и ресурсов именно с точки зрения интересов заинтересованных сторон. Таким образом, заинтересованные стороны выступают как основные получатели результатов деятельности системы руководства ИТ.