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

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

Учет «человеческого фактора» в системном подходе к ITSM критически важен, потому что технологии могут работать идеально в изоляции, но когда их начинают использовать люди, возникает множество непредвиденных проблем. Люди имеют свои ценности, интересы, привычки и особенности поведения, которые игнорирование может привести к провалу любого преобразования. Модель системного подхода подчеркивает необходимость оценки удобства и полезности инструментов для пользователей, достаточности знаний и навыков сотрудников для использования новых технологий, а также наличия механизмов обеспечения надлежащего использования инструмента и контроля ошибок. Без учета человеческого фактора даже самые продуманные процессы и технологии могут не принести ожидаемого результата.

Улучшение клиентского опыта достигается через идентификацию и оптимизацию точек взаимодействия с потребителем, которые находятся в полосе видимости. При синхронизации потоков и путешествия заказчика необходимо определить, на каких этапах путешествия происходит взаимодействие с клиентом и какие потоки при этом запускаются. Сфокусировавшись на этих точках, можно непрерывно улучшать CX/UX, делая взаимодействие более эффективным и приятным. Например, упрощая процессы сбора требований на этапе Offer или оптимизируя решение инцидентов на этапе Co-create. Это позволяет целенаправленно управлять клиентским опытом и повышать удовлетворенность потребителей.

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

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

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

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

Комбинирование RBAC и ABAC позволяет сохранить структурированность ролевой модели и добавить динамические условия проверки доступа. Например, роль «Менеджер» может быть дополнена правилом ABAC, ограничивающим редактирование заказов только при соблюдении условий: стоимость заказа не превышает 1000 руб., заказ находится в филиале менеджера. Это делает систему более гибкой, так как роли становятся контекстно-зависимыми, но при этом остаётся удобной для аудита благодаря явному разделению прав по ролям.

Средства измерения и контроля в ИТ-службах часто имеют три основных недостатка: они неполны (предоставляют информацию только о некоторых аспектах работы), неточны (основаны на низкокачественных данных и некорректных расчетах) и недостоверны (содержат ошибки и подвержены манипуляциям). Это связано с тем, что такие средства обычно добавляются позже, не учитывают специфику задач и не формируют единую систему контроля.