Невозможность установить нормативы обработки проблем в ITSM объясняется несколькими факторами. Во-первых, для решения проблемы часто требуется реализация нетипового изменения, срок которого определяется индивидуальным планированием. Во-вторых, у проблемы может существовать несколько вариантов решений, различающихся по надежности, стоимости и срокам реализации, что требует выбора оптимального варианта. В-третьих, время тестирования результативности решения не поддается нормировке, так как зависит от частоты проявления проблемы - если проблема проявляется ежедневно, тестирование можно завершить за 2-3 дня, а если она связана с квартальной отчетностью, придется ждать до следующего квартала (от недели до трех месяцев).

Выделяются две основные роли: менеджер изменений и координатор изменений. Менеджер изменений несет ответственность за общий контроль исполнения и организацию работ по проведению изменений в целом. Координаторы изменений отвечают за организацию обработки отдельных запросов на изменения. Координаторы обычно назначаются по функциональному или географическому признакам либо по обоим признакам одновременно. В некоторых моделях, например в IBM Tivoli Unified Process, роль координатора называется 'Владелец изменений'

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

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

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

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

Назначение процесса определяет его базовую функцию и место в общей процессной модели без привязки ко времени, тогда как цели процесса – это конкретные измеримые результаты, которых нужно достичь в определённый период. Ключевые отличия: - Назначение формулируется как описание общей задачи (например, "обеспечение качества услуг через устранение инцидентов"). - Цели формулируются в формате SMART: с глаголами совершенного вида ("увеличить долю решённых инцидентов до 95%"), измеримы и привязаны к срокам (квартал, год). Цели регулярно пересматриваются, в отличие от назначения, которое стабильно. Ответственность за назначение несёт дизайнер процессов, за цели – владелец процесса.

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

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

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