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

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

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

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

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

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

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

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

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

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