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

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

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

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

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

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

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

Референтная модель стандарта INCITS 359-2012 состоит из двух частей: референтная модель и административная функциональная спецификация. Референтная модель определяет множества элементов, которыми оперирует стандарт: пользователи, роли, права доступа, операции и объекты (доступа). В её состав входят четыре компонента: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро является обязательным компонентом при использовании подхода RBAC и определяет минимально необходимый набор элементов и связей для построения целостной системы.

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

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