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

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

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

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

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

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

Местоположение потребителя может существенно влиять на уровень ИТ-услуг, так как одно подразделение организации может быть распределено по различным площадкам, городам или странам. В таких случаях недостаточно использовать только оргструктуру для определения уровня услуг, поскольку расположение пользователя становится отдельным критерием выбора подходящего SLA.

Подход с SLA 'AS IS' имеет практическую ценность, так как он позволяет быстрее запустить процесс управления сервисами, избежав длительных согласований на старте. Он решает проблему, когда ИТ-подразделение вынуждено 'бегать' за бизнес-заказчиками для получения подписей. При этом сохраняется гибкость - бизнес может в дальнейшем влиять на условия обслуживания через дополнительные соглашения. Этот метод уже проверен на практике в рамках реальных проектов и доказал свою работоспособность.

Инструменты Role mining могут анализировать отдельные подразделения или группы пользователей периодически, что позволяет поддерживать ролевую модель в актуальном состоянии. Ограничение области анализа одним подразделением или направлением бизнеса упрощает процесс и позволяет своевременно выявлять и исправлять несоответствия между реальными назначенными правами и ролевой моделью. Регулярный анализ отдельных частей системы также помогает обнаруживать несанкционированные или устаревшие привилегии.

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