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

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

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

Причины для внедрения роли "Координатор релизов" в организациях, несмотря на её отсутствие в ITIL V3, включают: необходимость чёткого распределения сквозной ответственности за релиз; увеличение сложности и объёма релизов, что требует выделения отдельного координатора для эффективного управления; потребность в оперативном решении вопросов на уровне конкретного направления или услуги без участия менеджера процесса; повышение прозрачности и управляемости процесса релизов за счёт наличия единой точки ответственности. В то время как ITIL V3 фокусируется на описании процессов, а не организационных структур, реальные условия внедрения требуют адаптации подходов под специфику компании, что приводит к появлению таких дополнительных ролей.

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

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

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

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

Для разработки отчётности по измерению доступности бизнес-процессов необходимы следующие компоненты: 1) чётко определённые критические функции бизнеса (VBF) или упрощённые функциональные блоки; 2) установленные связи между VBF/функциональными блоками и конкретными ИТ-услугами/компонентами; 3) разработанные критерии доступности для каждого VBF/блоков и компонентов услуг; 4) механизмы сбора данных о доступности компонентов ИТ-услуг; 5) алгоритмы агрегирования данных о доступности компонентов до уровня VBF/функциональных блоков; 6) система визуализации и презентации этих данных в форме, понятной бизнесу. Отчётность должна позволять рассчитывать итоговые показатели доступности ИТ-обеспечения бизнес-процессов на основе данных нижнего уровня.

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