Вертикальное разделение (чередующиеся периоды) может создать дисбаланс в выполнении задач — например, накопление технического долга из-за длительных периодов разработки. Горизонтальное разделение (фиксированные доли трудозатрат) заставляет распределять фиксированные объемы усилий вне зависимости от текущих потребностей, что иногда приводит к недоиспользованию ресурсов или их перегрузке в конкретном направлении. Оба подхода требуют гибкой корректировки, чтобы избежать потери эффективности.

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

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

Компании вроде McDonald's следуют второму типу клиентского сервиса: продают недорогие товары в промышленных масштабах. Стандартные запросы обрабатываются быстро и качественно, но нестандартные вопросы либо игнорируются, либо ставят персонал в тупик. Акцент делается на стандартизации и скорости обслуживания для массового потребителя.

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

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

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

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

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

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