Система сервис-деск: юзабилити vs функциональность
Иван Козлов | 05.11.2013
Сейчас, наверное, никто уже не ставит под сомнение необходимость использования систем сервис-деск в средних и крупных компаниях. И я не буду это очередной раз доказывать или пытаться опровергнуть.
Вопрос в том, какую систему выбрать и как ее использовать.
Я уже писал статью о сервис-деск в журнале IT Manager в августе 2010 года. Забавно было ее еще раз перечитать и «взглянуть» на меня тогдашнего, с учетом теперешнего опыта. Хотя всего-то три года
прошло. Но с тех пор я поменял четыре сервис-деск-системы и определенно изменил свое представление о «правильном» сервис-деске.
Но начнем по порядку. Напомню, что прошлая статья была посвящена ведению «сервис-деск на коленке», то есть в Microsoft Excel. И регистрировали мы не тикеты, а потраченное время на каждый вид
инцидентов, проблем и проектов. Статья моя закончилась на том, что с «Экселем» жить можно, но вот-вот подоспеет общехолдинговая система и наступит счастье.
Счастье в тот год не наступило, руководство тогда просто сообщило, что внедрение откладывается еще минимум на год и если мы хотим использовать нечто свое, то — пожалуйста. Обязательным условием
стала бесплатность решения: поскольку разработка центрального решения все-таки ведется, то вкладывать деньги во что-то временное нецелесообразно. Но время потратить разрешили. И я тогда обменял его
на опыт, так что не жалею.
Быстро, просто и бесплатно
Мне тогда под руку попало очень интересное решение под названием Spiceworks. Назвать это программой язык не поворачивается, потому что впервые я увидел концепцию, когда система состояла из
серверного компонента и облака. И клиент часть данных брал с локального сервера, а что-то из облака, где находилась база знаний, сообщество и еще много интересных функций. Не стану описывать
функционал этой системы — статья не о том, но одной из функций был именно сервис-деск. По функционалу довольно бедный, зато очень красивый по дизайну и простой в обращении. Я решил остановиться на
нем. Знал, что у меня есть год на то, чтобы его использовать, а потом придется его выбросить, каким бы хорошим он ни оказался, так что тратить время на внедрение не стоит — надо брать то, что
работает, и начинать действовать.
Самое сложное при внедрении любого сервис-деска — заставить пользователей создавать тикеты. Как я упоминал, у нас уже был «наколеночный сервис-деск», но информацией его наполняли сотрудники ИТ, на
которых я имел влияние как руководитель. Я мог их заставить, даже если они не хотели. Пользователей же я заставить не мог и не мог отказать им в обслуживании, если тикета нет. А пользователи
привыкли к старым каналам связи — телефон, почта и «схватить за куртку в коридоре». Мне повезло: по крайней мере к одному из этих способов я мог прибегнуть — Spiceworks интегрировался с почтой и
при поступлении е-мейлов на специальный адрес тикеты создавались автоматически.

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

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

У меня не было картины текущей ситуации на каждой точке, и сервис-деск требовался для понимания загруженности местных спецов. И мы совместно с генеральными директорами этих предприятий запустили в
эксплуатацию групповой сервис-деск. Да, пользователи жаловались, что на английском писать неудобно — и мы разрешили транслит. Пришлось отключить автоматическую маршрутизацию тикетов, потому что
тикеты, написанные на транслите, наши европейские коллеги не понимали. И все заработало — не сразу и не везде, но начали появляться тикеты и вырисовываться картина.
Мощно, но неудобно
А в это время я активно убеждал ИТ-руководство в необходимости добавления русского языка. Вскоре выяснилось, что русский язык в систему добавить невозможно, а так же то что ее разработка
прекращается (кстати, это была внутренняя разработка компании), а вскоре будет объявлен новый стандартный сервис-деск. Не знаю, связан ли был такой переход с моей заявкой и ограничениями системы,
но к новому сервис-деску я сразу выставил основное условие — нужна поддержка русского языка.
Требование мое было удовлетворено, и я должен был бы ликовать, но этого не случилось... пока не случилось. Дело в том, что новая система опять очень функциональна. В ней есть много наворотов, и,
наверное, она очень крутая. Но пользователям, а в общем-то, и рядовым айтишникам требуется возможность быстро и просто создать тикет и быстро его закрыть. Разумеется, усложнение системы — следствие
более полных и правильных аналитик, но усложнение интерфейса ведет к тому, что функционал просто не будет использоваться на этапе начального ввода данных.
Так что нам надо?
Я, наконец, сформулировал для себя, какой должна быть идеальная с моей точки зрения сервис-деск-система: она должна совмещать два на первый взгляд взаимоисключающих фактора — максимальную простоту
на входе и богатую аналитику на выходе. Совместить это возможно, если в системе заложена правильная логика обработки простых запросов и их сортировка. В конце концов, у Google в интерфейсе всего
одна поисковая строка, но аналитические отчеты он формирует по тысячам параметров, правильно разбирая данные из этой строки и используя вспомогательные источники, такие как кукисы, вводом данных в
которые пользователь не озабочен.
Новую систему мы начали использовать всего несколько месяцев назад и, конечно, у нее еще есть «детские болезни», и она пока не отвечает моим идеализированным представлениям, но путь ее модернизации
понятен. Удобно, что современные системы имеют документированные API, с помощью которых очень удобно создавать любые интерфейсы с другими сайтами. То есть можно нарисовать дополнительный упрощенный
интерфейс или даже несколько, под разные вкусы, и все они будут обслуживаться одним мощным ядром. И потом для удобного вывода информации так же можно воспользоваться API и забрать данные в
какую-нибудь систему построения графиков и отчетов. Мы запланировали большую работу по постепенному, но постоянному улучшению текущей системы.
Подводя итог, хочется отметить, что систем много: хороших и разных, и каждый выбирает для себя сам. Можно выбрать простую, и однажды столкнуться с недостатком информации в ней. Можно, наоборот,
взять сложную систему и мучиться, вводя в нее кучу непонятных параметров. Можно усложнять простую, но я для себя решил, что самое правильное взять сложную и мощную и упростить ее интерфейс для
простого ввода тикетов и простой обработки их ИТ-специалистами. И вот тогда можно начинать ликовать!
Поделиться:
Также по теме
Мысли вслух
В статье из Harward Business Review авторы задались целью выявить поведенческие индикаторы того, что сотрудник собирается уйти.
А можно ли обойтись без этого гадания на ромашке "уйдет-не уйдет". Может, все проще?
А можно ли обойтись без этого гадания на ромашке "уйдет-не уйдет". Может, все проще?
Облачные технологии стали применять даже там, где раньше они не пользовались популярностью. Сравнительно недавними пользователями можно считать ретейлеров и сферу питания.
Даже если электронная запись не работает, всегда найдется возможность пройти вакцинацию.
Компании сообщают
Мероприятия
Оффлайн-митап для IT-специалистов от Делимобиль
Москва, ул. Электрозаводская 27, стр. 1а, БЦ «Лефорт»
Бесплатно
26.02.2021
19:00