«Не бросай одного его», или Что делать после окончания ИТ-проекта

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

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

За что не надо браться самим

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

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

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

Интегратор или вендор?

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

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

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

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

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

Виды техподдержки

Какие же виды техподдержки бывают? По признаку конечного получателя услуги техподдержка может быть организована для сотрудников компании-заказчика или для ее клиентов. Структура поддержки для решения в первом и во втором случае будет разной.

Рассмотрим первый вариант: запросы в help desk поступают от сотрудников компании. Это могут быть жалобы на сбои и ошибки в программе, вопросы о работе пользовательского интерфейса, запросы на доработку функциональных возможностей, исправление программных ошибок, изменение настроек или даже просьбы типа «Я прочитал инструкцию и жду от вас подтверждения, что я понял ее правильно». По сути, это постпроектное сопровождение клиента, включающее также обслуживание системы и ее обновление. Как правило, для поддержки выделяется группа достаточно квалифицированных ИТ-сотрудников, работающая в офисе — специализированный контакт-центр не организуется (если речь не идет об уникальных проектах с десятками тысяч одновременных пользователей, работающих в крупнейших организациях типа РЖД или «Газпрома»).

«Тикеты», которые нужно отработать службе ТП, заводятся по заранее предусмотренной договором схеме: по телефонному звонку, через электронную почту или специализированную систему, доступную пользователям. Качество оказания услуги контролируется по показателям, заложенным в SLA: время реагирования на инцидент, время решения вопроса и так далее в зависимости от уровня поддержки — стандартного, оперативного, VIP и др. Режим работы службы также определяется индивидуально: он может включать в себя только рабочее время по будням или вестись в круглосуточном режиме 24/7.

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

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

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

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

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

В настоящее время крупные российские компании предпочитают выводить контакт-центры из Москвы и Санкт-Петербурга в регионы. Для их размещения они выбирают города с достаточным объемом квалифицированной рабочей силы (учитывается наличие профильных вузов) и приемлемой стоимостью расходов на зарплату, связь, аренду и т. д. Например, в одном из областных центров расположен контакт-центр крупного российского банка, поддерживаемый интегратором-поставщиком системы ДБО: за время своей деятельности он обработал уже свыше миллиона запросов клиентов.