Чистый ABAC редко применяется из-за высокой сложности управления правилами. Большое количество атрибутов и условий приводит к трудночитаемым, запутанным политикам, которые сложно поддерживать и обновлять. Кроме того, отсутствие явных прав, как в RBAC, затрудняет аудит и анализ привилегий. Поэтому чаще используют гибридные подходы, где ABAC дополняет RBAC, например, добавляя контекстные ограничения к ролям.

Нельзя заменить обучение сотрудников автоматическим контролем. Обучение необходимо для понимания сотрудниками целей процесса, их роли в нем и последствий отклонений. Автоматический контроль может выявлять отклонения, но не объясняет, почему процесс важен, как его правильно выполнить и какие последствия будут за нарушение. Без обучения сотрудники действуют механически и не способны реагировать на исключения и нестандартные ситуации.

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

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

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

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

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

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

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

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