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

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

При отсутствии ранее существовавшей документации по управлению активами и конфигурациями рекомендуется использовать название "План управления сервисными активами и конфигурациями" (SACM plan). Это соответствует рекомендациям ITIL v3 2011 (раздел Service Transition, 4.3.5.2). При необходимости, учитывая специфику организации, название может быть адаптировано к таким вариантам как "Положение" или "Регламент". Ключевой момент - документ должен описывать целевой уровень управления сервисными активами и конфигурациями, который организация определяет самостоятельно. Структура документа должна включать разделы по охвату, требованиям, политикам и стандартам, организационной структуре, описанию процедур и связям с другими процессами.

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

Предложенная метрика решает проблему отсутствия адекватного способа измерения эффективности процесса управления проблемами. Традиционные метрики, такие как отношение количества решенных проблем к количеству открытых, имеют существенные недостатки: они не стимулируют регистрировать новые проблемы и не нормированы, что делает сложным определение целевых значений. Новая метрика является нормированной (изменяется в диапазоне [0;1]) и стимулирует выявление и регистрацию новых проблем, так как её значение увеличивается при увеличении количества новых зарегистрированных проблем.

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

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

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

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

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