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

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

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

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

Одной из распространённых ошибок при внедрении системы управления конфигурациями является обращение самой CMDB (Configuration Management Database) в самоцель. Организации часто сосредотачиваются на создании и наполнении базы данных конфигураций, забывая о том, что её основное назначение – поддержка других процессов ИТ-управления. В результате CMS начинает работать как бы сама на себя, без чётко определённых потребителей информации. Такой подход приводит к избыточному сбору данных, которые никем не используются, и к неэффективному использованию ресурсов. Правильная практика предполагает, что построение CMS должно начинаться с определения потребностей бизнес-процессов и конкретных задач, которые эта система должна решать.

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

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

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

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

Четвертый шаг цикла Деминга (Act) заключается в принятии решений относительно дальнейших действий после проверки результатов изменений. Он включает ответ на вопрос: 'Что делать дальше?'. Это может означать внедрение успешных улучшений в стандартную практику, игнорирование неудачных результатов без дополнительных изменений или запуск нового цикла PDCA с учетом полученного опыта. Act фокусируется на итоговой корректировке подхода и определении дальнейшей стратегии улучшений, что отличает его от этапа планирования, который предваряет непосредственное выполнение изменений.