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

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

В тексте описаны несколько усиливающих петлей обратной связи, связанных с проблемами в ИТ. Первая отрицательная: увеличение числа проблем и обходных решений (Workarounds) приводит к росту сложности инфраструктуры (IT Infrastructure Complexity), что повышает хрупкость системы (увеличивает Change Risk) и затрудняет планирование (снижает Change Control Level), что в свою очередь ведет к новым ошибкам и проблемам, замыкая цикл. Вторая отрицательная: высокий Time to market вызывает давление со стороны бизнеса на срочные изменения (Emergency changes), которые проводятся с нарушением процессов (низкий Change Control Level), что приводит к новым ошибкам и росту бэклога, еще больше увеличивая Time to market. Третья отрицательная: постоянные провалы приводят к настороженности и страхову, усложнению коммуникаций, увеличению бюрократии (Bureaucracy), что замедляет изменения и усиливает проблемы. Также описана положительная усиливающая петля: высокий Release rate приводит к накоплению опыта (возрастанию Change capability), что позволяет еще чаще внедрять изменения, образуя позитивный цикл развития.

Жизненный цикл ИТ-услуг в рамках парадигмы ITSM включает пять основных этапов: стратегию услуг (определение бизнес-потребностей и стратегического планирования), дизайн услуг (проектирование и разработку сервисов), переход к эксплуатации (внедрение новых или изменённых услуг), эксплуатацию услуг (повседневное предоставление и поддержку сервисов) и постоянное улучшение услуг (анализ и оптимизацию процессов). Каждый этап имеет свои ключевые процессы, цели и результаты, что создаёт непрерывный цикл управления услугами от концепции до прекращения предоставления.

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

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

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

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

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

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