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

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

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

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

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

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

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

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

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

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