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

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

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

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

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

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

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

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

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

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