Система Kanban предотвращает перегрузку участков производственного процесса за счёт принципа вытягивающего производства и явно установленных ограничений на количество работ в процессе (WIP). Последующий этап процесса может «заказать» следующую работу у предыдущего этапа только тогда, когда готов её принять, что предотвращает накопление избыточных запасов. Если на этапе достигнуто ограничение WIP, то дальнейшие задачи не могут быть переданы на этот этап до тех пор, пока не освободится место. Такой подход обеспечивает баланс загрузки между участками и не позволяет одному этапу перегружать следующий, что ведёт к более равномерному потоку и сокращению времени ожидания.

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

Иерархия ролей (цепочки 'родительская-дочерняя') позволяет упростить управление доступом за счёт наследования прав. Например, родительская роль 'Менеджер отдела' может включать права 'Создание отчётов' и 'Утверждение заявок', а дочерняя 'Старший менеджер' добавляет к ним право 'Контроль бюджета'. При этом дочерняя роль автоматически получает все права родительской. Это избавляет от дублирования настроек, ускоряет назначение сложных ролей и обеспечивает консистентность прав. Иерархия также поддерживает градацию полномочий (например, junior/senior) без необходимости перенастройки базовых прав.

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

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

Необходимость новой метрики определяется через ответы на три вопроса: 1) Решает ли она конкретную управленческую задачу? 2) Можно ли изменить действия команды на основе ее значений? 3) Соизмеримы ли затраты на сбор данных с ожидаемым эффектом? Например, метрика «доля обращений с некорректной классификацией» оправдана, если данные искажения приводят к ошибкам в отчетности или ухудшению качества сервиса. Если улучшение метрики не влияет на другие показатели, от нее стоит отказаться.

Учет рабочего времени начался в октябре 2013 года и к моменту написания текста продолжался почти полтора года. Более подробно, первые 13 недель (до конца 2013 года) учет велся по упрощенной системе с тремя цветовыми категориями, а с 1 января 2014 года система была усовершенствована и расширен до 18 категорий с ведением полного листинга затраченного времени.

Основные стандарты управления бизнес-непрерывностью включают ISO 22301:2012 (Societal security – Business continuity management systems – Requirements), который устанавливает требования к системе управления непрерывностью бизнеса; ISO 22313 (Societal Security – Business continuity management systems – Guidance), содержащий руководство по реализации требований ISO 22301; ISO 27031 (Guidelines for ICT Readiness for Business Continuity), описывающий вопросы управления ИТ-системами, и ГОСТ Р ИСО/МЭК 18044-2007, касающийся менеджмента инцидентов информационной безопасности.

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

Role-Based Access Control (RBAC) - это подход к управлению доступом, основанный на назначении пользователей ролям. RBAC состоит из четырех основных компонентов: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро - это обязательный компонент, который определяет минимально необходимый набор элементов (пользователи, роли, права доступа, операции и объекты) и связей для построения системы управления доступом. Оно реализует основную идею RBAC - объединение прав доступа в роли и последующее назначение ролей пользователям вместо прямого назначения прав доступа. Иерархичность добавляет возможности наследования прав между ролями. Статическое и динамическое разделение обязанностей вводят правила ограничений на назначение и совмещение ролей.