Важно начинать с Continual Service Improvement (CSI) с первых этапов внедрения ITSM, потому что CSI является не просто надстройкой над базовыми процессами, а фундаментальным элементом системы управления. Если начать с CSI, то можно избежать ситуации, когда процессы внедряются формально и без возможности дальнейшего развития. Это позволяет органично 'достраивать' систему управления, ориентируясь на реальные задачи заказчика и используя непрерывное улучшение как основу для роста уровня зрелости процессов.

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

Для работы с массовыми обращениями, вызванными крупными инцидентами, следует применять следующий подход: 1. Оценить текущую способность процесса справляться с такими ситуациями, проверив наличие и эффективность специализированных процедур для массовых обращений 2. Если такие процедуры отсутствуют или неэффективны, разработать стратегию работы с массовыми обращениями, включая приоритизацию и распределение ресурсов 3. Создать специализированные шаблоны и стандартные ответы для типовых ситуаций 4. Усилить критические участки процесса дополнительным персоналом и ресурсами 5. Рассмотреть возможность временного отказа от необязательных этапов обработки для ускорения основного процесса 6. Внедрить специальные инструменты для быстрой классификации и маршрутизации массовых обращений 7. Организовать оперативный информационный центр для координации действий всех задействованных групп 8. Провести пост-инцидентный анализ для выявления уроков и внесения изменений в процессы, чтобы избежать подобных ситуаций в будущем Ключевым является оперативная реакция и четкая структура действий, которая позволяет минимизировать время простоя и негативное воздействие на пользователей.

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

Первый принцип DevOps по DASA — Деятельность должна быть ориентирована на заказчика (Customer-Centric Action). Этот принцип включает постоянные инвестиции в продукты и услуги, которые обеспечивают максимальную удовлетворённость заказчика. Также он подразумевает необходимость коротких циклов обратной связи с заказчиками и конечными пользователями. Кроме того, принцип включает деятельность в духе Lean-стартапов с постоянными инновациями, что помогает быстро адаптироваться к меняющимся потребностям клиентов и тестировать новые идеи в реальных условиях.

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

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

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

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

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