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

Признаки, указывающие на возможную неэффективность предложения консультантов, включают: утверждение, что предыдущие попытки внедрения не удавались из-за неправильного подхода, а у консультантов есть единственно верный метод; обещание внедрить все необходимые процессы за один проект и за ограниченный срок (6-12 месяцев); гарантии, что процессы «точно заработают» и ИТ-отдел станет намного эффективнее; предложение фиксированной суммы оплаты без гибкости в зависимости от сложности проекта; утверждение, что метод работает, несмотря на предыдущие неудачи с ITIL или другими методологиями; использование термина «гарантия» применительно к управлению ИТ-процессами, что сомнительно в контексте организационных изменений, требующих времени и адаптации.

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

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

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

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

Отсутствие культуры автоматизированного тестирования серьёзно препятствует внедрению CI/CD, потому что конвейер развёртывания требует надёжной и быстрой проверки изменений перед их выпуском в продакшен. Без достаточного количества актуальных автотестов невозможно гарантировать, что каждое изменение кода не нарушает существующую функциональность. Если команда до сих пор ведет дебаты о том, 'стоит ли', 'нужно ли' или 'можем ли мы себе позволить писать автотесты', это указывает на фундаментальную неготовность к CI/CD. Автотесты являются неотъемлемой частью конвейера, они должны запускаться автоматически на каждом этапе и блокировать дальнейшее продвижение изменений при обнаружении ошибок. Отказ от постоянного обновления автотестов приведет к тому, что со временем они перестанут быть актуальными, будут «краснеть» и вынуждать команду вручную обходить проблемы, что полностью разрушает идею непрерывной интеграции и развертывания.

Основная ценность SWOT-анализа при работе с рисками заключается в его способности выявлять не только отдельные риски, но и их корневые причины, которые делятся на внешние угрозы и внутренние слабости. Это позволяет сосредоточить усилия на устранении источников рисков, а не просто управлять их проявлениями. Такой подход помогает разработать более целостную стратегию, которая решает системные проблемы организации и повышает ее устойчивость к различным угрозам.

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

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