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

Команда на уровне «Детский сад» представляет собой недавно сформированную группу, не способную самостоятельно выявлять внутренние проблемы и генерировать решения. Основная работа по организации процесса, поиску и решению проблем производится извне. Попытки дать самостоятельность приводят к хаосу. Здесь нет командных задач, только индивидуальные, а успехи и провалы также воспринимаются как индивидуальные. Признаками такого уровня являются жалобы на внешние факторы (плохой кофе, недостатки рабочего пространства, плохо описанные задачи, технические ограничения) вместо анализа внутренних проблем. Лидеру-слуге здесь недостаточно, поскольку команда еще не умеет самостоятельно идентифицировать проблемы, необходим директивный подход с постепенным вовлечением людей и расширением границ самостоятельности по мере проявления инициативы.

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

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

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

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

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

Процесс учета рабочего времени занимает значительно меньше, чем многие предполагают. За весь 2014 год на эту задачу потребовалось всего 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это опровергает распространенное мнение о том, что учет времени может занимать от 5% до 10% рабочего времени.

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

Мощность как компонент Warranty определяет, насколько услуга обладает достаточным запасом ресурсов для удовлетворения потребностей всех пользователей в пиковые периоды нагрузки. Высокая мощность означает, что услуга может справиться с максимальной нагрузкой без ухудшения качества. Например, для электрического света недостаточная мощность проявляется в том, что свет горит тускло, когда включено много приборов, так как электричества не хватает для всех устройств. В ИТ-услугах недостаточная мощность может проявляться в медленной работе приложения при большом количестве пользователей или низкой скорости соединения через VPN. Мощность критически важна для пригодности услуги к использованию, так как даже при наличии самой полезной услуги (высокая Utility) недостаточная мощность делает ее неудобной или невозможной для использования в реальных условиях.