Система сервис-деск: юзабилити vs функциональность

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

Я уже писал статью о сервис-деск в журнале IT Manager в августе 2010 года. Забавно было ее еще раз перечитать и «взглянуть» на меня тогдашнего, с учетом теперешнего опыта. Хотя всего-то три года прошло. Но с тех пор я поменял четыре сервис-деск-системы и определенно изменил свое представление о «правильном» сервис-деске.

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

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

Быстро, просто и бесплатно

Мне тогда под руку попало очень интересное решение под названием Spiceworks. Назвать это программой язык не поворачивается, потому что впервые я увидел концепцию, когда система состояла из серверного компонента и облака. И клиент часть данных брал с локального сервера, а что-то из облака, где находилась база знаний, сообщество и еще много интересных функций. Не стану описывать функционал этой системы — статья не о том, но одной из функций был именно сервис-деск. По функционалу довольно бедный, зато очень красивый по дизайну и простой в обращении. Я решил остановиться на нем. Знал, что у меня есть год на то, чтобы его использовать, а потом придется его выбросить, каким бы хорошим он ни оказался, так что тратить время на внедрение не стоит — надо брать то, что работает, и начинать действовать.

Самое сложное при внедрении любого сервис-деска — заставить пользователей создавать тикеты. Как я упоминал, у нас уже был «наколеночный сервис-деск», но информацией его наполняли сотрудники ИТ, на которых я имел влияние как руководитель. Я мог их заставить, даже если они не хотели. Пользователей же я заставить не мог и не мог отказать им в обслуживании, если тикета нет. А пользователи привыкли к старым каналам связи — телефон, почта и «схватить за куртку в коридоре». Мне повезло: по крайней мере к одному из этих способов я мог прибегнуть — Spiceworks интегрировался с почтой и при поступлении е-мейлов на специальный адрес тикеты создавались автоматически. 

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

Сервис-деск на CRM

Сначала я сильно удивился: где сервис-деск, а где — CRM. Потом поразмышлял, что пользователи, в общем-то, клиенты, и подход с точки зрения управления коммуникацией с ними в целом не лишен логики. Но требовалось значительно дорабатывать систему, чтобы она выполняла задачи сервис-деска. Вероятно, именно поэтому внедрение заняло столько времени. У решения огромный функционал, но кому это надо, если на создание тикета у пользователя уходила одна-две минуты, а на его обработку ИТ-сотрудником — пять-семь минут. Сервер находился в Европе, и то ли связь оказалась довольно медленной, то ли сервер не справлялся, но все работало не слишком быстро. И так полюбившейся мне функции создания тикета из электронной почты здесь не было. Как следствие, пользователи прекратили создавать тикеты, а мы перестали их требовать, поскольку зачастую решить проблему удавалось значительно быстрее, чем пройти тернистый путь сервис-деска.

  

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

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

Опять просто, но нефункционально

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

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

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

 

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

Мощно, но неудобно

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

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

Так что нам надо?

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

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

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