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

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

На данный момент основные методы включают замер трудозатрат по переводам статусов объекта и использование нормативов. Метод по переводам статусов предполагает, что отсчет времени начинается при установке статуса "в работе" и заканчивается при установке статуса "решено". Метод нормативов заключается в составлении стандартного времени на выполнение конкретных задач, из которых формируется общее время выполнения комплексной работы. Оба метода имеют свои недостатки и не обеспечивают полной достоверности данных.

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

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

Ошибка восприятия канбана как простого списка задач заключается в том, что канбан – это не только визуализация задач, сложенных по статусам ("Надо сделать", "Делаем", "Сделано"), но и инструмент управления потоком работы. Настоящий канбан позволяет выявлять узкие места процесса, устанавливать ограничение на количество задач в работе одновременно (WIP limit) и организовывать вытягивающую систему производства, где следующий этап берёт задачу только после освобождения предыдущего этапа. Простое размещение задач на доске без соблюдения этих принципов не делает процесс настоящим канбаном.

Основная цель системы Kanban, разработанной на производстве Toyota, заключалась в организации вытягивающего типа производства для построения системы «точно-во-время» (just-in-time, JIT). Это достигалось за счёт использования карточек для сигнализации между участками производственной цепочки. Когда на одном участке приближалось завершение производства или достижение определённого порога, карточка отправлялась предыдущему участку, указывая необходимость изготовления следующей порции продукции. Такой подход позволяет минимизировать складские запасы, избежать избыточного производства и повысить скорость выпуска продукции, так как материалы поступают именно тогда, когда они требуются для дальнейшей обработки.

Роль Service Owner в ITIL представляет собой позицию, ответственную за управление услугой на протяжении всего её жизненного цикла. Эта роль включает обеспечение соответствия предоставления и поддержки услуги заявленным требованиям, интерпретацию требований заказчиков в ИТ-терминах, взаимодействие с менеджерами процессов, участие в обсуждении SLA и OLA, представительство на встречах по оценке услуги, выступление единой точкой ответственности за работу услуги, точкой эскалации для значительных инцидентов, участие в совете по изменениям (CAB) и обеспечение актуальности информации об услуге в каталоге. Service Owner отличается от сервис-менеджера тем, что является скорее стратегической ролью, фокусирующейся на общих аспектах услуги и её соответствии бизнес-целям, тогда как сервис-менеджер обычно занимается оперативным управлением и поддержкой услуг.

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

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