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

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

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

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

Рассматривается два варианта обработки сроков при статусе 'Ожидание': первый - приостанавливать отсчет времени, увеличивая общий срок на период ожидания; второй - не приостанавливать, считая время ожидания частью общего срока. При выборе первого варианта важно четко фиксировать периоды ожидания и прозрачно сообщать заказчику о продлении. При втором варианте задача будет считаться просроченной, если время ожидания превысит допустимый лимит, что повышает ответственность, но может создать недовольство у заказчика в случае объективных задержек. Наиболее распространенный подход - приостанавливать отсчет времени только при подтвержденных объективных причинах ожидания, с обязательным согласованием с клиентом.

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

Ценность «гарантии» обеспечивает уверенность в том, что добавленная ценность через развитие (utility) не будет обесценена из-за недоступности или некачественной работы услуги. Она измеряется через комбинацию доступности услуги, активной пользовательской базы и управления рисками (снижение негативных или усиление положительных). Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются, поэтому игнорирование «гарантии» может обнулить общий результат.

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

Сервисное мышление состоит из следующих ключевых компонентов: 1) знаете ли вы своих заказчиков/пользователей, 2) понимаете ли вы их ожидания, 3) фокусируетесь ли вы на создании ценности для заказчика, 4) берете ли на себя ответственность (включая за бизнес-результаты), 5) проявляете ли эмпатию, 6) осознаёте ли вы культурный контекст и адаптируетесь к нему, 7) способствуете ли вы сотрудничеству, 8) соблюдаете ли этичные нормы поведения. Все эти компоненты вместе формируют целостный подход к предоставлению услуг.

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