Шестой принцип DevOps DASA предполагает широкий взгляд на автоматизацию, включая не только процессы разработки программного обеспечения, но и весь инфраструктурный ландшафт, что реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Это означает, что конфигурация и управление инфраструктурой должны быть определены через код и версионироваться, как и любое другое программное обеспечение. Такой подход позволяет автоматически воссоздавать инфраструктуру, обеспечивать её согласованность в разных средах, быстрее разворачивать новые экземпляры и легко откатываться к предыдущим версиям при необходимости. Инфраструктура как код также интегрируется в процессы непрерывной поставки, что позволяет тестировать изменения инфраструктуры так же, как и изменения приложения, повышая общую надёжность и стабильность системы.

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

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

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

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

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

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

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

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

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