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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги: Help Desk

Журнал IT-Manager    [ PDF ]    [ Подписка на журнал ]

Об авторе


Иван Козлов

Иван Козлов

Директор по ИТ, Россия Metsa Group


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru


Другие материалы рубрики

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

Мероприятия


08.09.2016
Санкт-Петербургский клуб ИТ-директоров «SPb CIO Club» и компания Event House приглашает Вас принять участие во втором Форуме по промышленной автоматизации «Industrial IT-Forum»! Промышленная автоматизация на предприятии – важная область, которой уделяется повышенное внимание. Использование информационных технологий - один из немногих технологически и экономически выгодных способов повышения эффективности подготовки производства. На современных предприятиях автоматизируются по максимуму все возможные участки работ. Новый взгляд на проблемы и тенденции информационных технологий в области промышленной автоматизации будут рассмотрены на II Форуме по промышленной автоматизации «Industrial IT Forum»

22.09.2016
24 июня 2016 года Госдумой шестого созыва был принят законопроект «Антитеррористический пакет» Яровой, который назван одним из самых резонансных. Существенная часть законопроекта призвана регулировать деятельность телекоммуникационных и интернет компаний. Согласно документу, операторы связи и «организаторы распространения информации» должны в течение полугода хранить вообще всю переданную информацию, то есть и записи телефонных звонков, и содержание смс-сообщений. В течение трех лет они также обязаны хранить сведения о переданных данных. Наконец, компании должны помочь ФСБ расшифровать весь трафик. Как законопроект повлияет на рынок? Смогут ли крупнейшие интернет-компании отстоять свою позицию? Готово ли государство прислушиваться к мнению бизнеса? На конференции Право.ru участники обсудят скрытые и явные угрозы «пакета Яровой», а также о другие законодательные изменения.