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

Заказчик в рамках BPO покупает не просто выполнение задач, а организацию и реализацию целого бизнес-процесса. Услуга включает в себя ответственность поставщика за управление ресурсами, обеспечение качества, выполнение процесса в соответствии с требованиями заказчика и долгосрочное сотрудничество. Это делает услугу более комплексной и стратегически значимой по сравнению с разовыми проектами.

ITIL и ISO/IEC 20000 ориентированы на управление ИТ-услугами с точки зрения потребителя, где ключевым аспектом является обеспечение функционирования системы для пользователя в нужный момент. ГОСТ 27.002-89 и ГОСТ Р 53480-2009 разработаны для технической надежности оборудования, где акцент делается на внутренние параметры системы. Разница обусловлена предметными областями: ИТ-услуги требуют учета внешних процессов, а техническая надежность — внутренних характеристик компонентов.

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

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

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

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

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

Если поток производства не работает круглосуточно (как это обычно бывает в ИТ), Time in Process должен рассчитываться только с учетом рабочего времени, а не полных календарных дней. Это означает, что период времени от начала до завершения задачи должен быть исчислен в рабочих часах или рабочих днях. Например, задача, которая начала обрабатываться в пятницу вечером и завершилась в понедельник утром, должна учитывать только рабочее время между этими временными точками, исключая выходные дни и нерабочие часы. Для этого необходима автоматизация или специальные правила обработки данных, учитывающие календари сотрудников, что значительно усложняет расчет по сравнению с простым вычитанием времени начала из времени завершения.

ISO 27031 (Guidelines for ICT Readiness for Business Continuity) описывает вопросы управления ИТ-системами для гарантии обеспечения непрерывности бизнеса в соответствии с подходом, установленным в стандарте ISO 22301. Стандарт был ранее известен как BS 25777 и практически не изменился при переходе в семейство стандартов по информационной безопасности.