Учёт участия нескольких групп поддержки в обработке одного инцидента реализован через пропорциональное распределение ответственности за нарушение срока. Для каждого инцидента, в обработке которого участвовала группа, рассчитывается доля времени (ti/Ti), которое группа потратила на его обработку. Эта доля учитывается при определении степени ответственности группы за просрочку. Если инцидент просрочен, то штрафное значение для KPI распределяется между всеми участвовавшими группами пропорционально их доле в общем времени обработки (ti/Ti). Таким образом, чем больше группа «задержала» инцидент, тем более значительным будет снижение её KPI.

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) имеют несколько преимуществ перед классическим подходом. Они позволяют: 1) Более точно оценить влияние доступности ИТ-услуг на конкретные бизнес-процессы; 2) Учесть специфику разных видов бизнеса - для некоторых критичны долгие простои, для других частые кратковременные; 3) Принимать обоснованные решения по повышению надежности систем с учетом реального бизнес-влияния; 4) Создать более прозрачные SLA с учетом особенностей воздействия простоев на бизнес; 5) Лучше оценить успешность мероприятий по повышению надежности на основе их реального влияния на бизнес-процессы.

Правильно построенная система измерения и оценки соответствует критериям SMART: показатели конкретные, измеримые, достижимые, релевантные и ограниченные по времени. Особенно важно, чтобы каждый показатель был соотнесён с реальными управленческими задачами, а данные использовались для принятия решений. Система не содержит «отчётности ради отчётности», исключает искажение поведения через неправильные стимулы и основана на каскаде целей от стратегического уровня до операционного.

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

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

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

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

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

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

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