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

Ограничение числа задач в работе (WIP Limit) положительно влияет на эффективность команды в DevOps следующим образом: оно предотвращает перегрузку команды слишком большим количеством одновременно выполняемых задач, что снижает переключение контекста и увеличивает концентрацию; помогает выявлять узкие места в процессе, так как когда определенный этап достигает своего лимита, становится очевидно, что требуется улучшение именно там; способствует более быстрой доставке ценных функций конечным пользователям, так как команда фокусируется на завершении текущих задач вместо начала новых; и улучшает качество работы, так как меньше задач в работе означает больше внимания к каждой из них и меньше вероятность ошибок. WIP Limit является фундаментальным механизмом управления потоком ценности в DevOps практиках.

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

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

Utility (Полезность) и Warranty (Гарантия) являются двумя основными характеристиками услуги. Utility отвечает на вопрос fit for purpose - пригодность к цели, помогает ли услуга пользователю достичь желаемого результата. Например, свет в темной комнате полезен для чтения книги. Warranty отвечает на вопрос fit for use - пригодность к использованию, представляет собой четыре компонента: доступность, мощность, безопасность и непрерывность. Услуга может иметь высокую полезность (помогает достичь цели), но низкую гарантию (например, свет мигает, что затрудняет чтение). Полезность определяет соответствие услуги цели, а гарантия - условия, в которых услуга может быть использована.

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

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

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

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

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