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

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

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

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

Да, геометрическое среднее легко обобщается на произвольное количество tension-метрик. Для N метрик K = N√(K1 × K2 × ... × KN). Однако на практике случаи с тремя и более tension-метриками встречаются редко, так как сложность балансировки между большим количеством конфликтующих показателей затрудняет управление и анализ. Обычно ограничиваются парой ключевых метрик, которые наиболее точно отражают критические аспекты процесса.

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

Подходы управления цепочками поставок могут быть эффективно применены к непрофильным ресурсам в компании, которые не формируют основную ценность для потребителя, но необходимы для поддержки основных потоков. Поскольку многие ресурсы (например, услуги по обеспечению compliance или тестированию надежности инфраструктуры) могут рассматриваться как самостоятельные отчуждаемые результаты, их можно приобретать у третьих сторон, аналогично тому, как это делается в традиционных цепочках поставок. Для этого необходимо: 1) четко определить требования к качеству и количеству ресурса; 2) разработать метрики для измерения соответствия поставок этим требованиям; 3) установить надежные каналы коммуникации с поставщиками; 4) создать механизмы управления запасами ресурсов, чтобы обеспечить их постоянную доступность без излишков; 5) внедрить систему оценки и мониторинга поставщиков для поддержания качества поставок на необходимом уровне. Применение подходов управления цепочками поставок позволяет компании фокусироваться на своем основном бизнесе, снижая издержки и повышая гибкость в управлении непрофильными функциями.

Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.

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

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