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

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

Архитектурные решения критически важны, потому что сложные, монолитные системы, созданные годами и состоящие из тесно связанных компонентов, просто не могут поддерживать высокую скорость разработки. Такие системы, где аббревиатура 'CI/CD' вызывает удивление или смех, принципиально не позволяют достигнуть кратного ускорения. Чтобы достичь значительного снижения Time to Market, необходимо провести работу над архитектурой: разбить монолит на микросервисы или модули, внедрить автоматизацию тестирования и развертывания, создать условия для параллельной работы нескольких команд без постоянных конфликтов. Эти изменения требуют значительных усилий и инвестиций, но без них реальное кратное ускорение невозможно.

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

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

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

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

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

Основные требования к KPI для использования в системе оценки руководителей включают: сопоставимость между разными процессами (метрики должны иметь единую шкалу, обычно от 0 до 1), единое направление оценки (как правило, чем ближе к 1, тем лучше результат), возможность агрегации на разных уровнях управления. Метрики должны отражать реальный вклад подразделения в процессы, быть измеримыми и объективными. Примерами подходящих метрик могут служить: доля заданий, выполненных в срок, от общего числа; доля инцидентов, принятых в работу своевременно; доля инцидентов, решенных в срок и с первой попытки; коэффициент обновления по проблемам. Важно, чтобы метрики не только измеряли результат, но и стимулировали правильное поведение сотрудников и руководителей, поддерживая цели бизнеса.

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