Рейтинг решения инцидента рассчитывается по формуле: если фактическое время устранения (ti) меньше или равно Tmin, рейтинг составляет 100%; если ti превышает Tmax, рейтинг равен 0%. При времени между Tmin и Tmax рейтинг плавно снижается от 1 до 0 по формуле (Tmax - ti) / (Tmax - Tmin). Такой подход учитывает не только соблюдение сроков, но и степень влияния простоя на бизнес, поощряя максимально быстрое устранение инцидентов.

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

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

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

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

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

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

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

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

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