Смартсорсинг.ру

Крупные компании сталкиваются со сложностями организации Сервис Деск (Service Desk). Это не правило, но трудности встречаются очень часто. Исходя из практического многолетнего опыта, эксперты ИТ-сервисной компании ICL Services собрали ключевые тезисы об аспектах внедрения и функционирования службы Сервис Деск и создали инструкцию, которая поможет наладить эффективную работу сервиса единого окна.

С 6 апреля по 15 мая 2015 года пройдет Всероссийская викторина по ИТ-менеджменту, организуемая компанией NAUMEN совместно с издательством «Открытые системы». Викторина предоставит возможность участникам проверить глубину своих знаний в области управления ИТ, получить признание профессионального сообщества, став экспертом (гуру) в сфере ИТ-менеджмента, а также побороться за ценные призы.

Участвуйте, получайте признание российского сообщества экспертов в области ИТ управления и выигрывайте ценные призы!

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

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

Известно также, что значительная часть пользователей стараются всеми силами избежать пользования базой знаний (а часто и порталом самообслуживания, с которым база знаний часто бывает связана). Вместо этого пользователи звонят по телефону и пишут e-mail’ы, а уж базы знаний, т.е. самостоятельного поиска информации стараются избегать, как огня. Забавный рассказ на тему внедрения HelpDesk’а можно прочитать здесь, но, уверен, у многих из читателей есть что рассказать на эту и сходные темы своего.

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

Главная претензия к Красной Кнопке, высказанная уважаемыми коллегами Александром Фроловым и Андреем Ланцевым, заключается в следующем. Недалёкие пользователи, вместо того чтобы изучать продукт, поддержку по которому оказывает компания, начнут нажимать кнопку по поводу и без повода и "заддосят" техподдержку бессмысленными или незначительными запросами. В качестве мер противодействия пользовательским безобразиям называются: а) обучение пользователей; б) ограничение свободы действий пользователя посредством, в данном случае, "систем автоматической регистрации заявок" (Help Desk & Service Desk). Красная Кнопка же, облегчающая вызов поддержки, расхолаживает пользователей, а значит, работает в обратном направлении, коварно повышая энтропию в мире ITSM.

В принципе, в качестве ответа можно было бы указать на принцип клиентоориентированности (а с точки зрения ITIL / ITSM внутренний пользователь является таким же клиентом, как и внеший). Но что толку в клиентоориентированности, если такая клиентоориентированность разрушает все бизнес-процессы? Я постараюсь показать, что Красная Кнопка, облегчая обращение в поддержку, в то же время не способствует ни валу бессмысленных заявок, ни безграмотности пользователей.

Ключевым изменением релиза Naumen Service Desk 4.0.1 стали инструменты визуализации отчетных данных. Всего в релиз вошло более 200 доработок и изменений.

Недавно Gartner представил квадрант ITSSM — инструментов для управления поддержкой сервисов. Казалось бы, квадрант Gartner должен служить для ориентации клиентов на рынке ITSM решений. Однако посмотрим насколько этот квадрант подходит для российского рынка.

Аналитикой Gartner не особо довольны, как компании, попавшие в квадрант, так и те, кого обошли вниманием.  Вот несколько мнений экспертов о квадранте Gartner.

На днях у моего горе-провайдера интернета, с которого я так и не слез после описанного давным-давно случая, произошел очередной fail — что-то сломалось и интернета не было двое суток. Упал и упал интернет, с кем не бывает. Ну и пусть с ним, что услуга не предоставлялась вообще в течение 2-х дней. Технические сложности восстановления работоспособности меня мало интересуют.

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

Рефлексии по этому поводу далее.

Не секрет, что отношение пользователей к ИТ в целом, и к процессам поддержки в частности, далеко от идеальной. Где-то ситуацию внутренними или внешними (привлечение консультантов, например) силами удается сломать. Попробуем это сделать без привлечения консультантов? ;)

Добрый день!

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

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

В первом посте данного блога хочу написать о хронологии событий последних 6 месяцев.