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

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

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

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

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

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

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

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

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

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