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

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

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

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

В COBIT 5 for Risk риски разделены на 20 категорий, охватывающих различные аспекты управления ИТ. Это включает категории, связанные с управлением ИТ-инвестициями, программами и проектами, рисками, связанными с поставщиками, вредоносным ПО, атаками, регуляторами и другими областями. Каждая категория содержит подробные описания типовых ИТ-рисков с рекомендациями по их снижению, основанными на семи факторах влияния, что позволяет применять эти рекомендации в различных сценариях управления рисками.

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

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

В IT4IT функциональные компоненты организованы вокруг сервисной модели (Service Model), которая представляет собой Service Backbone архитектуры. Эта модель охватывает все стадии, необходимые для создания и предоставления ИТ-услуг, что напрямую соответствует концепции жизненного цикла услуги из ITIL. Конкретно, функциональные компоненты в IT4IT распределены по четырем Value Streams, каждый из которых охватывает определенную фазу жизненного цикла: Strategy to Portfolio (S2P) - управление портфелем и стратегией; Requirement to Deployment (R2D) - разработка и развертывание; Request to Fulfill (R2F) - предоставление услуг; Detect to Correct (D2C) - управление эксплуатацией и решением проблем. Таким образом, набор функциональных компонентов в IT4IT охватывает все этапы от идеи услуги до ее непрерывного улучшения, полностью зеркалируя концепцию жизненного цикла услуги, только структурированную в виде потоков создания ценности.

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

В управлении внеплановыми простоем при срочном внедрении изменений задействованы три основных процесса ITIL: управление изменениями (Change Management), который отвечает за процесс внедрения изменений и формирование документа PSO; управление уровнем услуг (Service Level Management, SLM), который занимается обсуждением и согласованием с заказчиком целевых показателей доступности на период внедрения изменений; и управление доступностью (Availability Management), который проверяет соответствие плановой доступности целевым значениям и оценивает влияние изменений на доступность сервисов в долгосрочной перспективе.