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

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

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

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

Для определения допустимого объема потери данных в случае аварии следует выполнить следующие шаги: - Провести анализ бизнес-процессов для определения критического времени, после которого потеря данных становится невосполнимой для бизнеса. - Оценить, сколько транзакций или операций может быть утеряно без серьезного воздействия на бизнес-операции. - Определить периодичность создания контрольных точек данных или моментов для восстановления. - Проанализировать исторические данные о частоте операций и объеме изменений данных в течение рабочего дня. - Согласовать с бизнес-владельцами максимальный допустимый период потери данных, выраженный в минутах, часах или количестве транзакций. - Учесть нормативные требования и обязательства перед клиентами, которые могут регламентировать допустимую потерю данных. - Рассмотреть финансовые последствия потери данных за различные временные интервалы. - Определить, какие данные являются критически важными и требуют более частого резервного копирования, а какие менее критичны и могут иметь больший допустимый период потери. - Фиксировать допустимый объем потери данных в качестве одного из ключевых показателей уровня обслуживания (RPO - Recovery Point Objective). Правильное определение этого показателя является критически важным для проектирования адекватной системы резервного копирования.

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

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

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

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

Некоторые организации продолжают использовать методы, восходящие к HPOVSD (Hewlett Packard OpenView Service Desk), из-за инерции мышления, привычки к традиционным подходам и недостатка осведомленности о современных практиках управления инцидентами. Часто решение о выборе метода основано не на текущих потребностях и возможностях, а на рекомендациях предыдущих консультантов или устаревших шаблонах внедрения. В ряде случаев отсутствует глубокий анализ эффективности используемых методов, что приводит к сохранению практик, которые когда-то могли быть оптимальными для конкретных систем, но сейчас уже устарели в условиях современных возможностей автоматизации.