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

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

Автор считает, что разграничение работы и личной жизни становится проблемой в современных условиях по нескольким причинам: 1. Люди ищут и находят работу по душе, что приводит к полному погружению в профессиональную деятельность 2. Появление гибкого графика без чётких временных рамок начала и окончания рабочего дня 3. Постоянное совершенствование в выбранной профессии, требующее дополнительного времени 4. Смешение сфер: выполнение семейных обязанностей в рабочие дни и рабочих задач в выходные дни В результате человек оказывается в ситуации, где от него ожидают высокой продуктивности как в профессиональной, так и в личной сфере, что создаёт дополнительное давление и сложности с управлением временем.

Согласно аналитике Pink Elephant, более половины компаний имеют долю экстренных изменений в пределах 10%. У почти 20% компаний этот показатель превышает 15%. Таким образом, доли экстренных изменений до 10% можно считать приемлемым уровнем, хотя идеалом является их минимальное количество. Если доля экстренных изменений превышает 30% и не снижается, это указывает на неполноценное или отсутствующее управление изменениями.

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

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

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

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

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

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