Техподдержка тиражных продуктов: как выбрать правильный путь
В "жизни" большинства приложений одно из ключевых мест отводится процессу техподдержки. Сам по себе данный сервис, помимо других факторов, определяется параметрами поддерживаемого решения. Чем выделяются тиражные продукты, на что стоит обратить внимание, каковы особенности процесса и как правильно подойти к организации работы?
Сервис технической поддержки играет важную роль в жизненном цикле программного продукта. Он не просто дополняет приложение, а неразрывно связан с ним, а если мы говорим о продуктах, доставляемых по подписке (Software as a Service — SaaS), стоит отметить, что сервис технической поддержки неотделим от них.
Вид технического сервиса зависит от многих параметров: кто является пользователем программного обеспечения — конечный потребитель или компания (бизнес), платный ли продукт или распространяется свободно, открыт ли исходный код. Например, для свободных продуктов, таких как браузеры Firefox и Chrome, вполне достаточно сформированного сообщества с форумами и базами знаний. Для игр уже нужен интерактивный сервис поддержки с участием производителя, причем на первое место выходит сам факт взаимодействия с разработчиком игры, но не параметры сервиса. ПО для бизнеса, к примеру, Microsoft CRM, уже требует поддержки с определенными параметрами доступности.
В данном материале хотелось быть остановиться именно на последнем случае и рассмотреть техническую поддержку тиражного продукта — бизнес-приложения с примерами из практики организации службы поддержки "ДоксВижн». А также отдельно коснуться вопросов специфики сопровождения продукта-платформы.
Участники и варианты доставки сервиса
В процессе технической поддержки бизнес-приложения задействованы как минимум два участника: производитель программного обеспечения, в обязанности которого входит обязательное оказание гарантийного обслуживания, и клиент, который использует данное ПО.
При расширенной модели бизнеса, как в случае с Docsvision, дополнительно в процессе могут принимать участие компании, внедряющие бизнес-приложения, и компании, оказывающие услуги по техническому сопровождению: аутсорсинг поддержки производителя, call-центры.
Соответственно, схема сопровождения может быть двусторонней (производитель—клиент), или трехсторонней (производитель—внедряющая компания—клиент).
Функции всех участников процесса довольно широки, но мы постараемся их обобщить. Так, производитель программного обеспечения несет ответственность за техническую поддержку в период гарантийных обязательств (как правило, в течение года). Кроме того, он может предоставлять за дополнительную плату расширенный пакет услуг — например, аудит внедренного бизнес-приложения или выезд технического специалиста на место.
Внедряющая компания может оказывать техническую поддержку заказчику своими силами: для этого организуется либо целый отдел или группа специалистов, либо прямой канал обращений к производителю ПО.
При участии внедряющих организаций в процессе оказания технической поддержки в подавляющем большинстве случаев используется вариант самостоятельного оказания сервиса, так как в этом случае остается постоянный контакт с заказчиком.
Наша компания выпускает систему электронного документооборота Docsvision, которая представляет собой мощную платформу для построения решений. Причем последние по сложности довольно часто превосходят саму платформу. Мы выступаем как производитель программного обеспечения, поэтому внедрением и созданием решений на базе Docsvision занимаются партнерские организации. Мы используем трехстороннюю модель расширенного сопровождения через партнерскую сеть, и все вопросы технической поддержки входят в компетенцию наших партнеров, но при этом представитель заказчика имеет право напрямую обратиться в нашу службу технической поддержки.
Внутренняя организация
Техническая поддержка тиражного продукта напрямую производителем имеет свою специфику среди других сервисов сопровождения и может соответствовать стандартам ITIL.
Цикл поддержки тиражного продукта включает следующие процессы:
• Управление инцидентами: описание схемы регистрации, решения, эскалации инцидента;
• Управление проблемами–причинами вызвавшими инцидент;
• Управление изменениями: регистрация и жизненный цикл предложений по доработке.
В случае предоставления сервиса технической поддержки, который оплачивается дополнительно, в процесс может быть включен сервис управления финансами.
В случае предоставления сервиса технической поддержки, который оплачивается дополнительно, в процесс может быть включен сервис управления финансами.
Участники процесса управления инцидентами — это непосредственно сотрудники службы технической поддержки. Процесс управления проблемами находится в зоне ответственности разработчиков и тестирования (производственных отделов). Управление изменениями контролируется группой требований к продукту.
При проектировании услуг технической поддержки нужно иметь в виду некоторые особенности, я остановлюсь на двух их них.
В первую очередь необходимо учесть тот факт, что прогнозировать сроки разрешения сбоя невозможно и, соответственно, нельзя указать этот параметр в описании услуги поддержки. Ошибка вполне может быть выявлена за короткий промежуток времени, но есть вероятность, что она потребует длительных исследований. Данная особенность вступает в разногласие с принятой у ИТ-отделов практикой гарантировать уровень доступности приложения для бизнеса.
Широкое региональное распространение продукта вызывает необходимость оказывать техническую поддержку в актуальное для каждого региона время. Соответственно, компания должна либо вводить расширенный график работы, либо работать с партнерскими организациями, которые будут предоставлять сервис в регионах.
Короткая ссылка на материал: //cnews.ru/link/a3035
