Что думают о заказчиках «по ту сторону баррикад», те, кто дежурят у телефонов и компьютеров в ожидании вопросов, порой весьма каверзных? Как они представляют себе точку зрения тех, кто платит за техническую поддержку? Информация об этом поможет пользовате
Систематизируя вопросы, поступающие в службу поддержки, мы выяснили, что у заказчиков порой складывается неверное представление о нашей работе. Мы бы хотели привести здесь несколько наиболее часто встречающихся мифов и предлагаем не только оценить, как обстоят дела в реальности, но и несколько практических советов, которые, на наш взгляд, помогут вам избежать проблем при сопровождении автоматизированной системы.
Миф о времени реакции
«Если клиент платит за сопровождение, техподдержка вендора обязана отвечать на любые вопросы немедленно». Безусловно, любой вендор заинтересован в том, чтобы его клиент был максимально удовлетворен работой службы поддержки. Однако далеко не каждую проблему можно решить за несколько минут, так как требуется выявить причины ее возникновения, проанализировать различные варианты и найти оптимальное решение. Все это требует времени. И чем сложнее проблема, тем больше времени требуется для ее решения.
Все это абсолютно очевидно. На практике существование самого мифа в большой степени обусловлено тем, что заказчик часто просто не хочет разобраться в том, за что конкретно он заплатил, хотя все аспекты взаимодействия со службой поддержки учтены в договоре на сопровождение, который заключается между клиентом и вендором. В договор включены не только сроки обработки запросов, но и регламент взаимодействия, лимиты на количество обращений в службу поддержки, обязательства вендора в случае нарушения сроков устранения сбоев и многое другое, не говоря уже о перечне самих услуг. Более того, как правило, у вендора существует не одна, а несколько категорий или уровней поддержки, разработанных для клиентов с разными потребностями.
Все это возникло не на пустом месте, а является результатом опыта взаимодействия между вендором и его заказчиками. Чтобы сократить время на ненужные объяснения в процессе оказания услуг, заказчику необходимо разобраться в этом вопросе еще на этапе внедрения системы, то есть до того момента, когда она будет сдана в эксплуатацию.
Необходимо добавить, что значительная часть запросов так или иначе связана с незнанием пользователем принципов работы с системой. Отсюда вытекают вопросы типа: «На какую кнопку нажать, чтобы получить тот результат, который я хочу?». Заказчик должен понимать, что обучение пользователей технологии работы с системой в функции службы поддержки не входит, ее основное назначение — решать проблемы, связанные с некорректной работой системы. Любой вендор старается свести количество таких запросов к минимуму. Для решения подобных проблем предлагаются разнообразные курсы по обучению персонала клиента. Причем наличие в вашем штате таких сотрудников не только сведет к минимуму количество проблем, но и значительно сократит сроки их решения, так как основные потери времени приходятся на формулировку, передачу и обработку запроса службой поддержки.
Миф о вреде формализации
«Излишняя формализация работы техподдержки мешает оперативному решению вопросов. Достаточно по телефону описать ошибку, и техподдержка должна во всем разобраться. Пользователи не должны терять свое время на письменные формулировки проблемы».Формализованный подход к работе — это не прихоть вендора, это необходимость, так как ежедневно служба поддержки обрабатывает достаточно большое количество запросов. Для того чтобы обеспечить контроль за ходом работ по каждому из них, отследить сроки и качество выполнения работ, необходим соответствующий регламент, призванный свести к минимуму влияние человеческого фактора, на борьбу с которым приходится самая большая потеря времени при приеме и обработке запросов.
К примеру, клиент позвонил и объяснил представителю службы поддержки суть возникшей проблемы, тот зафиксировал ее, причем сделал это не совсем точно, так как информация передана ему по телефону. В итоге работа по запросу была бесполезной, потеряно время, а, самое главное, проблема не решена.
Таким образом, если клиент предельно точно и в письменном виде сформулирует запрос и в дальнейшем будет работать в рамках регламента взаимодействия со службой поддержки, он получите не только гарантию того, что вопрос будет решен четко и в установленные сроки, но также сможет отслеживать ход работ по каждой своей заявке.
Остановимся еще на одном факторе, который всегда присутствует в регламенте взаимодействия со службой поддержки и влияет на оперативность решения вопросов. Срок обработки заявки вендор может регулировать в ту или иную сторону, привлекая различное количество специалистов или меняя квалификацию персонала. Весь вопрос в том, чтобы найти «золотую середину» между реально необходимыми заказчику сроками решения проблемы и уровнем подготовки персонала. Для этих целей разработана система статусов или приоритетов запросов. Чем критичнее сроки решения, тем выше статус.
Правила присвоения запросу приоритета прописываются в договоре сопровождения, изучив соответствующие пункты которого, можно самостоятельно регулировать сроки выполнения работ по своим заявкам.
Миф о вреде доработок
«Адаптация системы под собственные потребности приведет к расхождению с версией вендора, и, как следствие, к отказу в технической поддержке». Такая проблема действительно существует и суть ее в том, что вендор, поставляя систему заказчику, гарантирует ее работоспособность, то есть то, что она будет выполнять заложенные в нее функции. Любые дополнительные работы, связанные с адаптацией системы под индивидуальные потребности заказчика, производятся внутри системы и не могут существовать отдельно от нее. Иными словами, система в составе доработок представляет собой единое целое. В связи с этим имеет значение тот факт, чьи специалисты эти работы выполняют. Если модификация производится клиентом самостоятельно, вендор не может взять на себя ответственность за то, что работы выполнены корректно и впоследствии не произойдет сбой в работе. В некоторых случаях клиенту могут отказать в техподдержке. Таким образом, если политика вендора предусматривает прекращение поддержки, доработки вам потребуется заказывать непосредственно у вендора при условии, что вы заинтересованы в услугах по сопровождению.
Необходимо сказать, что политика вендора бывает более лояльной в данном вопросе, но существует один аспект, который нужно принять во внимание. Сама по себе система — величина непостоянная. Вендор периодически модифицирует ее в соответствии с требованиями бизнеса, для которого она предназначена, например, для учета изменений в действующем законодательстве. Такого рода работы выполняются в рамках версий системы. Наличие индивидуальных доработок создаст ощутимые трудности при смене версии. Для решения этой проблемы разработана «технология клонов», которая позволяет совместить наработки с базовой версией, после чего вендор будет сопровождать индивидуальную версию системы, то есть ее клон. У вендоров существуют и другие подходы к решению данного вопроса, однако в любом случае перед тем как выполнить или заказать доработку, необходимо выяснить для себя все аспекты. Это позволит избежать проблем с дальнейшим сопровождением системы.
В заключение добавим, что система в данном случае представляет собой тиражируемое программное обеспечение, и работы по ее адаптации под индивидуальные потребности всегда влекут за собой дополнительные расходы. В первом случае это оплата работ, а во втором — увеличение стоимости поддержки. Если вы заинтересованы в адаптации системы, необходимо резервировать для этих целей средства в бюджете компании.
Миф о равнодушном вендоре
«Вендор далек от повседневных проблем динамично меняющегося бизнеса и не может обеспечить оперативные изменения в системе под потребности заказчика». Безусловно, это не так. Вендор не может существовать отдельно от своих заказчиков, в противном случае его продукт не будет востребован на рынке. Поэтому каждый производитель программного обеспечения заинтересован в том, чтобы своевременно выявить потребности заказчика. Для этих целей проводятся разнообразные программы, направленные на определение перспективных направлений развития бизнеса. Заказчику предлагается участвовать в разработке новых продуктов как на этапе формирования бизнес-требований, так и на этапе тестирования.
Любая заявка, поступающая от клиента, всегда анализируется, а затем оценивается ее необходимость не только для конкретного заказчика, но и для всех клиентов вендора. Другими словами, рассматривается вопрос тиражируемости. Если доработка признается полезной, она реализуется, и заказчик получает ее в рамках очередной версии системы.
Конечно, заказчику придется подождать, пока она будет сделана, так как подобные доработки выполняются в порядке очередности. Однако он получит желаемое бесплатно в рамках договора на сопровождение. Если же сроки критичны, можно заказать работы вне очереди, заплатив за оперативность.
Миф о беспомощном заказчике
«Службы технической поддержки постоянно перегружены работой и не модернизируются. Заказчик не может влиять ни на процесс оказания услуг, ни на регламент работы службы». Компания может успешно существовать в условиях рыночной экономики только в случае ее соответствия требованиям бизнеса. Поэтому работа любой службы должна быть направлена прежде всего на повышение ее эффективности. Что касается службы поддержки, то за последние десять лет здесь многое изменилось. К примеру: возможны консультации не только по телефону, но и по icq, электронной почте; появились сборники часто задаваемых вопросов и ответов, форумы пользователей; внедрены системы учета клиентских заявок; ряд компаний открывает доступ к своим заявкам через Internet для просмотра их текущего состояния и т.д.
Партнерство
Грамотно организованная служба поддержки всегда анализирует свою работу на основе различных опросов и анкетирования. Но инициатором любых нововведений является прежде всего заказчик. Главным инструментом заказчика является договор сопровождения, на основании которого оказываются услуги. Заказчик может поднять любые интересующие его вопросы, включая регламент, сроки обработки заявок, а также санкции за невыполнение обязательств.
Ваши замечания будут основанием для того, чтобы вендор рассмотрел различные аспекты работы своей службы поддержки. Не забывайте: именно заказчик является равноправным партнером и имеет право урегулировать интересующие его вопросы.
Максим Захаров — руководитель управления внедрения и сопровождения, ЗАО «АО Кворум», Maxim.Zaharov@quorum.ru