Идеализированный вариант «Клиенты мечты» (высокая отзывчивость и высокая полезность) редко встречается в реальности, так как активные и конструктивные клиенты обычно слишком заняты личными делами, чтобы тратить время на детализацию отзывов. По оценкам, более 99,9% полезной обратной связи поступает в формате «Hard Candy» — кратких, но ценных замечаний. Идеальные клиенты, готовые подробно делиться опытом и предлагать решения, нехарактерны для массового сегмента, так как их вовлеченность требует значительных временных затрат, которых большинство потребителей не готовы выделить.

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

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

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

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

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

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

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

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

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