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

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

Утверждение «простаивающий ресурс - это потери для бизнеса» может быть ошибочным, потому что простой часто является естественной частью рабочего процесса и может указывать на баланс системы. В системах с последовательными этапами работы небольшие простои на отдельных участках предотвращают перегрузку последующих этапов. Простой может быть сигналом о сбое на предыдущих участках, который нужно изучить, а не маскировать дополнительной работой. Фокус на 100% загрузке ресурсов приводит к перепроизводству и создает заторы в цепочке создания ценности. Таким образом, оптимальная эффективность системы достигается не максимальной загрузкой каждого отдельного ресурса, а сбалансированной работой всей системы.

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

Ежедневный контроль по критически важным проектам позволяет выявлять отклонения на самых ранних стадиях, когда их еще легко исправить. Это предотвращает накопление проблем и больших отставаний в будущем, поскольку, как отмечается в тексте, 'опаздывают не поздно, опаздывать начинают всегда рано'. Такой подход обеспечивает более высокую степень уверенности в соблюдении сроков, позволяет быстро корректировать планы и распределять ресурсы, а также поддерживает высокий уровень ответственности у команды проекта.

Для учёта степени превышения срока обработки метрика может быть модифицирована за счёт добавления весового коэффициента wi, который учитывает, насколько сильно просрочен инцидент. Если инцидент решен в срок, wi=1. Если срок превышен, wi определяется как отношение фактического времени решения инцидента Ti к установленному сроку. Формула переписывается в виде: Кгруппы = (1/N) * Σ(wi * (1 - (ti/Ti) * vi)). Также можно ввести рейтинг ответственности ri = (ti/Ti) * vi. Тогда метрика принимает вид взвешенного арифметического среднего: Кгруппы = (1/N) * Σ(wi * (1 - ri)).

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

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

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

Могут использоваться как вопросы с единственно возможным ответом (выбор одного варианта из предложенных), так и вопросы, допускающие выбор нескольких вариантов ответа. Выбор типа вопроса зависит от целей опроса и характера информации, которую необходимо собрать.