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

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

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

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

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

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

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

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

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

При изменениях структуры (слияние, разделение подразделений) нужно: 1) Определить тип изменений: 'старое-старое' (функции не меняются), 'старое-новое' (добавляются новые функции) или 'новое' (полностью новый набор функций). 2) Для 'старое-новое' комбинировать бизнес-роли основного и сливаемого подразделений (например, роли из объединяемых департаментов маркетинга и PR объединяются в единую модель). 3) Для 'новое' формировать уникальный набор ролей с нуля, если подразделение создаётся под новые задачи. Ключевой этап — перераспределение ролей между сотрудниками, учитывая новые зоны ответственности.