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

Средний чек рассчитывается как общий объем продаж за определенный период, деленный на количество сделок за этот же период. Например, если за месяц продано товаров или услуг на сумму 1 миллион рублей при 100 сделках, то средний чек составит 10 000 рублей. В контексте планирования ИТ-инфраструктуры этот показатель используется для перехода от денежного выражения плана продаж к количеству транзакций, что позволяет спрогнозировать нагрузку на информационные системы и определить необходимые ресурсы для их эффективного функционирования.

Подход, при котором процесс Управления инцидентами (INC) организует эффективную проактивную коммуникацию с пользователями, способствует снижению нагрузки на Service Desk. Путём автоматических оповещений (например, по email или SMS при каждом изменении статуса инцидента) пользователи получают необходимую информацию без необходимости обращаться с запросом. Также важно обеспечить доступ к статусу инцидентов через портал самообслуживания, где пользователь может самостоятельно посмотреть текущее состояние своего запроса. Этот подход позволяет минимизировать количество повторных обращений пользователей по уже зарегистрированным инцидентам, что напрямую снижает нагрузку на Service Desk и позволяет сосредоточиться на обработке новых инцидентов.

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

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

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

Принцип 'Работать на людей' подчеркивает важность того, что бизнес заключается в том, чтобы люди делали что-то полезное для других людей. Основная задача ИТ-подразделений как сервис-провайдеров — обслуживать людей. Это принцип предполагает идентификацию ключевых точек контакта ('touchpoints') с клиентами, называемых также моментами истины ('moments of truth'), и сосредоточение усилий именно на этих точках для улучшения общего опыта клиентов.

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

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

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