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

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

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

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

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

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

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

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

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

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