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

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

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

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

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

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

Нужно подчеркнуть, что цель учёта — не контроль, а понимание распределения усилий для улучшения процессов. Например, если сотрудник тратит 30 минут на разговор и одновременное составление отчёта, реальное время на каждое действие меньше 30 минут (например, 20 и 10 минут соответственно). Точная фиксация позволяет выявить, как часто происходят такие совмещения, и, возможно, оптимизировать процессы (например, отделить консультации от документирования). Это помогает снизить нагрузку и повышает прозрачность работы команды.

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

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

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