Принцип 'Работать на людей' подчеркивает важность того, что бизнес заключается в том, чтобы люди делали что-то полезное для других людей. Основная задача ИТ-подразделений как сервис-провайдеров — обслуживать людей. Это принцип предполагает идентификацию ключевых точек контакта ('touchpoints') с клиентами, называемых также моментами истины ('moments of truth'), и сосредоточение усилий именно на этих точках для улучшения общего опыта клиентов.

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

В практике различать запросы и потребности бизнеса при работе над ИТ-проектами можно через систематическое применение методики «Пять почему» и глубокое погружение в контекст. При получении запроса необходимо задавать уточняющие вопросы: «Зачем вам это нужно?», «Как это связано с вашими бизнес-целями?», «Что произойдёт, если эта потребность не будет удовлетворена?». Например, если бизнес запрашивает отчёт по продажам, важно понять, для каких решений он будет использоваться, какие показатели критичны, в каком формате информация будет наиболее полезной. Эффективно проводить совместные сессии анализа требований, где ИТ и бизнес вместе формулируют цель проекта не в терминах функциональных требований, а в терминах ожидаемых бизнес-результатов. Также полезно создавать «карт потребностей», где каждому запросу ставится в соответствие бизнес-цель, которую он должен поддерживать. Ключевая проверка: если бы запрос был изменён или отменён, как это повлияло бы на бизнес-процессы? Если влияние незначительно, возможно, запрос не отражает реальную потребность. Различие между запросом («хотим таблицу с ежедневными продажами») и потребностью («нужно оперативно реагировать на снижение продаж в регионах») позволяет предложить более эффективные решения (например, систему предупреждений о резких изменениях, а не просто набор отчётов).

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

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

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

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

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

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

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