Документ регламентирует взаимодействие компании RDV с компанией — пользователем услуг поддержки систем на условиях SLA
Назначение документа
Данный документ регламентирует взаимодействие компании RDV с компанией — пользователем услуги поддержки систем с которыми заключен договор на оказание услуг поддержки на условиях SLA.
Классификация обращений
Обращение — любое обращение пользователя в рамках оказания сервисных услуг. Обращения в процессе работы с ними классифицируются на следующие типы:
| Управление инцидентами | Управление запросами на обслуживание | Управление изменениями |
|---|---|---|
| Инцидент (INC) — Обращение пользователя, с указанием на факт неработоспособности системы или функции системы / сервиса, влияющее на работу пользователей /выполнение бизнес-процессов. Другими словами, инцидент — это зарегистрированная ошибка функционирования системы. | Запрос на консультацию (CON) — обращение, решаемое без внесения изменений в программный код или настройки системы, например, пояснения по правилам работы в системе. Запрос на настройку или массовое изменение данных (SDС) — запрос на изменение настроек или пользовательских данных в системе или ее окружении, не связанное с неработоспособностью системы или сервисов. Например, развертывание еще одной базы в подразделении компании или обновление данных по причине связанного дефекта. Запрос на предоставление доступа (ACS) — запрос на предоставление доступа в систему, изменение имеющихся прав в системе. Запрос имеет этап согласования с бизнес- владельцем системы или сервиса. | Запросы на изменения (RFC) — запрос на создание новой /изменение существующей функциональности системы / функции системы / сервис. Доработка с изменением программного кода или объектной модели. |
Уровни сервиса поддержки
Решение обращений выполняется различными уровнями сервиса поддержки. Каждый уровень сервиса выполняет свою роль в решении обращений:
| 1 Линия поддержки | 2 Линия поддержки | 3 Линия поддержки |
|---|---|---|
| · Запрос на консультацию (CON) · Прием и классификация обращений. Решение типизированных инцидентов · Запрос дополнительной информации от инициатора · Информирование инициаторов о закрытии инцидентов · Эскалация инцидентов на 2 и 3 линию · Администрирование системы
| · Запрос на настройку или массовое изменение данных (SDС) · Решение нетиповых инцидентов, без изменения программного кода системы · Изменение настроек · Поддержка пользователей по вопросам методологии, разработанной в ходе Проекта
| · Запросы на изменения (RFC) · Анализ требований, подготовка дизайнов / технических заданий на требуемые изменения · Доработка функциональности системы с изменением конфигурации, программного кода · Разработка методологии учета новых бизнес-процессов в системе (не было в ходе проекта) |
Классификация обращений по приоритету
| КРИТИЧНЫЙ | СУЩЕСТВЕННЫЙ | СРЕДНИЙ | НЕЗНАЧИТЕЛЬНЫЙ |
|---|---|---|---|
| 1. Ошибки, блокирующие выполнение операции в рамках процесса:
2. Недоступность системы
| 1. Ошибки, блокирующие выполнение операции:
2. Проблемы инфраструктуры
3. Ошибки интеграции, приводящие к постоянной загрузке некорректных данных
| 1. Ошибки, не блокирующие выполнение операций, но требующие устранения проблем:
2. Изменение данных НСИ
3. Массовое изменение операций по согласованию с бизнесом
4. Ошибки остановки интеграции по сервисным процессам (администрирование)
5. Администрирование пользователей и прав доступа
| 1. Консультации пользователя по методологии отражения операций в типовых продуктах
2. Консультации по стандартным настройкам в рамках инструкций пользователя
3. Настройка сервисных функций в рамках типового функционала (оповещения, варианты отчетов, типовой интерфейс)
|
Сроки реагирования и обработки обращений (за исключением RFC)
Максимальный срок реагирования: Время, затраченное на первичный анализ обращения, с момента его инициации до момента передачи обратной связи инициатору о взятии обращения в работу.
Максимальный срок решения: Время, затраченное на устранение обращения, с момента взятия обращения в работу до момента запроса у инициатора подтверждения решения.
Данные сроки являются нормативными, и их превышение сроков фиксируется системой управления обращениями и используется для дальнейшей эскалации.
Каждое обращение при приемке в работу получает ожидаемый срок решения. Данный срок является оперативным и может корректироваться при работе над обращением.
| Критичность инцидента | Максимальный срок реагирования | Максимальный срок решения | График работы |
|---|---|---|---|
| Критичный | 20 мин | 1 - 4 часа | 9/5 |
| Существенный | 30 мин | 4 - 8 часов | 9/5 |
| Средний | 2 часа | 2 рабочих дня | 9/5 |
| Незначительный | 1 рабочий день | 5 рабочих дней | 9/5 |
Рабочее время службы поддержки с 10:00 до 19:00 (МСК) по будням.
Сроки реагирования и обработки RFC
Максимальный срок реагирования на запрос изменения — время, затраченное на первичный анализ обращения, с момента инициации обращения до момента передачи обратной связи инициатору о взятии обращения в работу.
Срок решения запроса — время, затраченное на разработку и тестирование функциональности, с момента взятия запроса на изменения в работу до момента передачи результата запроса инициатору на тестирование.
Срок реагирования анализируется для всех запросов, но в расчете эффективности выполнения работ по договору участвуют только те запросы, которые создаются ключевыми пользователями.
| Критичность запроса | Максимальный срок реагирования | Срок решения запроса | График работы |
|---|---|---|---|
| 1 | 1 рабочий день | Срок решения согласовывается с заказчиком в зависимости от оцененного объема изменений и выделенных на запрос ресурсов | 8/5 |
| 2 | 3 рабочих дня | 8/5 | |
| 3 | 3 рабочих дня | 8/5 |
Способы коммуникации
Для обращения на линию поддержки пользователи направляют свои запросы/вопросы на электронную почту support@rdv-it.ru.
Поддержка осуществляется с 10.00 до 19.00 ежедневно по будням.
Срок получения обратной связи от пользователя
Обращение закрывается автоматически, в случае, если обратная связь от пользователя не предоставлена в течение заданного срока:
| Критичность инцидента или обращения | Срок предоставления ответа |
|---|---|
| 0 | 1 рабочий день |
| 1 | 2 рабочих дня |
| 2 | 5 рабочих дней |
| 3 | 5 рабочих дней |
Закрытие запроса
При закрытии запроса, технической поддержкой, автору запроса направляется уведомление об успешном выполнении запроса. Уведомление направляется автоматически с целью подтверждения выполнения запроса.
Уведомление направляется на электронная почту инициатора запроса.
Запрос считается закрытым после получения подтверждения исполнения от автора заявки.
Запрос закрывается автоматически через 3 рабочих дня, при отсутствии подтверждения со стороны автора запроса.
Алгоритм работы с заявкой:
Подтверждения исполнения запроса автоматически возвращается в SD и присваивает статус заявки «Исполнено».
Алгоритм работы при невыполнении запроса пользователя
При невыполнении запроса от пользователя, Служба поддержки действует по следующему алгоритму:
| Вид обращения | Критичность | Алгоритм действий при невыполнении запроса |
|---|---|---|
| Инцидент, Запрос на консультацию | Критичный, Существенный | При неисполнении срочного вопроса, представитель линии подключает к Техническому специалисту и Руководителя службы поддержки |
| Изменение данных (справочников, журналов документов, групповое изменение данных) | Критичный, Существенный | |
| Консультации пользователей по закрытию периода | Критичный, Существенный | |
| Поддержка интеграционных потоков | Критичный, Существенный |
Все остальные запросы решаются согласно представленному регламенту, с учетом согласованных сроков между Исполнителем и Заказчиком.