Help Desk Software *

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

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

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

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

Да, именно такие расхожие мнения можно услышать при обсуждении новости о получении сертификата производителем программного обеспечения или всего процесса сертификации ПО в целом. Хочется надеяться, что со временем таких реплик станет меньше, а ценность международного признания качества ПО в нашей стране возрастет. Этот небольшой рассказ об уникальном проекте международной сертификации нашего ПО: о его предпосылках и ключевых этапах с цифрами, о некоторых сложностях и итоговых результатах.

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



ИТ-аутсорсинговая компания работает как минимум с 2-3 разными клиентами, предоставляя каждому свои наборы услуги и возможно свои SLA. Сотрудник службы поддержки, принимая заявку от клиента, должен знать, какие услуги и с какими параметрами предоставляются этому клиенту, требуется ли дополнительное согласование работ и бюджетов и т.п. При этом внешняя ИТ-компания на площадке клиента управляет только базовыми процессами ITIL, такими как управление инцидентами, проблемами, изменениями и т.п. Все остальное требует намного большей зрелости отношений между ИТ и бизнесом. В результате ИТ-компании используют довольно ограниченный функционал HelpDesk решений.
Что же хочет получить от HelpDesk решения небольшая ИТ-компания?

Всем доброго времени суток!

Хочу поделиться с сообществом небольшим обзором HelpDesk системы, которую мы в своей компании выбрали в качестве боевой! Система выросла из Opensource-проекта, стартовавшего в конце 2012 года и доросшая до релиза в январе 2014 года. Может быть установлена, как на собственные сервера, так и на shared хостинг. Кстати, нашли мы этот проект здесь, на хабре. Итак, наш сегодняшний пациент vsDesk.

ITIL[1] — библиотека книг в которых подробно и всесторонне описываются различные «хорошие» практики управления ИТ-услугами (IT Service Management). У книг ITIL разные авторы, описанные в них процессы и рекомендации никто между собой не согласовывал, так что любимый тезис специалистов по ITIL — ITIL нельзя внедрить, только адаптировать. Логическим выводом из этого будет то, что ITSM-решение нельзя получить из коробки.

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

Исходный тезис про необходимость адаптации сам по себе правильный. Конечно, потребуется несколько лет, чтобы обнаружить и автоматизировать несколько десятков процессов, описанных в ITIL. Однако если компания вообще не сталкивалась с ITIL и ITSM, то ни большей части этих процессов, ни какой-либо потребности в них у нее просто еще нет.

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

Кругом одни стартапы. Некоторым уже надоело читать о них. Другие продолжают с неподдельным интересом изучать стартап за стартапом, потому что сами мечтают начать и заявить о себе. Успешные истории вдохновляют, ведь в них всегда можно найти сходство с теми, кто решается сделать мир лучше.

Мы скромно причисляем себя к таким энтузиастам, и вот наша история. Во многом знакомая, но от этого не менее интересная и поучительная.

Компания Naumen открыла публичный доступ к своему новому он-лайн сервису ITSM 365 — SaaS инструменту автоматизации работы ИТ-отдела, ориентированному на малый и средний бизнес. Сервис позволяет использовать типовые процессы управления ИТ-сервисами для ИТ-отдела из 10 — 30 сотрудников. Сервис позволяет компаниям перейти к управлению ИТ-сервисами на основе практик ITSM без долгого и дорогостоящего внедрения.

На Хабре уже неоднократно поднималась тема использования лучших практик ITIL для «улучшения климата» работы ИТ-специалистов в небольших компаниях. Первый и главный совет обычно — внедрение в соответствии с рекомендациями инструментария управления заявками в техническую поддержку пользователей. Главным образом такой подход позволяет перевести неприятные разговоры с бизнесом о полезности ИТ-службы на понятный обоим язык, как говориться, раскрыть карты и показать, что системные администраторы, на самом деле, целый день действительно заняты исполнением пожеланий бухгалтерии, администрации и т.п.


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

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

От переводчика: Часто сталкиваюсь с тем, что компании относятся к технической поддержке пользователей как к второстепенному процессу, а между тем качественная техническая поддержка, — это, выражаясь официальными терминами «основа устойчивого развития бизнеса и лояльности клиентов». В США и многих европейских странах поддержка пользователей возведена «культ», и когда сравниваешь то, как поддерживают клиентов «там» и «у нас», то становится печально (но ситуация постоянно улучшается). Действительно, для оказания отличной техподдержки знание предмета — это не самое главное и нужны дополнительные навыки общения. Но все исправимо и для того, чтобы вдохновиться и запустить собственную техподдержку на высоком уровне предлагаю перевод статьи «Customer service skills you need in 2013» посвященную рекомендациям по навыкам необходимым для оказания отличной технической поддержки.

В своей компании для тех. поддержки клиентов используем чат+хелпдеск от kayako, но столкнулись с необходимостью найти отдельный сервис онлайн чата для новых проектов. По старой привычке — выбор делаем так: составляем список минимальных требований, потом находим все подходящие под них сервисы и проводим их тестирование, и уже из них выбираем лучший вариант.

Исходные требования:

• Интерфейс полностью на русском языке
• Возможность вставить фото оператора
• Активные приглашения — когда оператор может пригласить клиента в чат
• Статистика по посетителям — откуда пришел, какие странички смотрел
• Возможность передачи клиента между операторами
• Сохранение истории общения
• Клиент под Windows

Изначально к стартовой линии подошли около 30 различных сервисов чатов для консультирования клиентов. Некоторые из них мы рассмотрим подробно, а по некоторым пробежимся лишь вскользь.

Используя Mantis для учета заявок от абонентов, часто приходилось сталкиваться со следующими сложностями:
1) При добавлении новой заявки приходится вносить или копипастить часть информации из карточки клиента в Mantis, что во-первых, лень, а во-вторых, потенциально может привести к искажению информации.
2) Не всегда получается оперативно прочитать предыдущие заявки по этому абоненту, во-первых, потому что лень, во-вторых, см. пункт первый, относительно искаженной информации.

Для решения этой задачи воспользуемся API от Mantis — mantisconnect.php.

При работе с OV SD 4.5 есть одно неудобство. Уведомления, которые приходят по почте, содержат слишком мало информации.
В нашей организации в письме содержится только краткое описание.
Получив такое сообщения, приходиться переключаться в окно толстого клиента и открывать заявку.
На открытие заявки может уходить до десяти секунд. При этом можно столкнуться с ситуацией, когда несколько сотрудников пытаются просмотреть заявку одновременно.
Поэтому была написана программа OV SD 4.5 Notifier, которая отображает уведомление с наиболее полной информацией о заявке.
О ней дальше и пойдет речь.

Пока готовится подробная статья про покупку на зарубежных аукционах и в интернет-магазинах, хочу рассказать вам о том, что делать в случае, если вы получили не то, что должны были.
После починки Epson Artisan 800 (см. топик о приключениях с ним), обзор которого уже числится в общем списке материалов к публикации, выяснилось, что СНПЧ для брата-близнеца Epson TX800FW не подходят к нему. Кто-то в комментах поглумился, сказав, что я попал на расходники, но на деле же все куда проще. Принтер покупался для дома, печать не горит, на первое время хватает ресурса родных картриджей. В качестве решения проблемы заказал СНПЧ на том же eBay.

Холодное утро морозной зимы не предвещало никаких новостей. Я зашел в свой мыльник, увидел там письмо от «Kaspersky Lab Support TEST» и удивился, ведь их антивирусом я не пользуюсь уже два года (не из-за качества, а просто взял бесплатный вариант). Любопытство взяло верх и я открыл письмо. Какого же было мое удивление, когда я вчитался в текст…



Во-первых, я не мог вспомнить, что я их спрашивал, ведь они даже не процитировали вопрос. Во-вторых, я терялся в догадках, почему их сервер внезапно вспомнил обо мне и решил оправдаться, что 3 с половиной года больше 24-х часов. Втретьих — что за TEST? Они проверяют на старых обращениях новую систему?
Остается только надежда, что когда-нибудь они обработают мой запрос и я вспомню что я хотел…

В свете последних постов Идеальная техническая поддержка — сон или реальность? и ему подобных (про линчеванее еще был) смотря на коментари нормальному здоровому человеку нельзя не проникнуться ненавистью. Собственно ее я и буду излучать в этом тексте :)
Особенно впечатляют бури негодования по поводу работы техподдержки.



Привожу особо бросившиеся в глаза ситуации:

1. Мы купили железку по цене бутылки хорошей водки которая должна исполнять функции роутера и она не работает либо работает коряво? Виноват провайдер!
2. Мы настолько круты что поставили убунту либо еще какой-то ширпотребный дистрибутив и мальчики с перфоратором осуществляющие подключение не горят желанием сделать ifconfig чтобы посмотреть MAC абонента? Аяяй какой плохой провайдер!
3. Вирусы скушали Нашу винду и кроме ICMP по интерфейсу ничего не ходит? Конечно же плохая поддержка не желающая лечить вирусы по телефону и исцелять своей карму пользователя дистанционно!
4. Мы ВНЕЗАПНО отключили сетевую карточку и негодуем что мальчик пришедший через пол города пешком требует $1.25/ 10 гривен / 38 рублей за вызов? Обдираловка и провайдерский беспредел!
5. Мы намеряли (как?) слишком мало скорости до Новой Гвинеи — где наш обещанный мегабит за 30 гривен / 100 рублей? Провайдер нас держит за дураков!
6. ВНЕЗАПНО со счета испарилось гиг траффика в денежном еквиваленте? Мы же ничего не качали! Мы всего лишь слушали музычку вконтактике, смотрели видео на ютубе, разговари с родственниками по скайпу и рассматривали тетенек на разных сайтиках. Но мы ничего не качали за что с нас сняли деньги? Провайдер нас обкрадывает!

Вам уже смешно? Может грустно?
Мне грустно – давайте погрустим вместе.

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

Естественно, большая часть хелпдеска лоббировала против откровения тех. директора контраргумент, что большинство пользователей просто ленивы, глупы или ленивы и глупы, и никакое количество улучшений это не изменит. Не то, чтобы их протест на что-либо повлиял…

Недавний пост об идеальной тех. поддержке меня, с одной стороны, воодушевил (восхищаюсь людьми, так любящими свою нелёгкую работу, как автор того поста), с другой стороны — озадачил. Можно ли следуя логике любой клиент всегда и полностью прав успешно организовать работу отдела тех. поддержки (а для многих IT-компаний эффективная поддержка — основа бизнеса)?

Основываясь на скромном (но собственном) опыте, я прихожу к выводу, что всё-таки нельзя. Разве что у вас в команде все, как автор упомянутого поста, самозабвенно любят свою работу и позитивно мыслят.

Далее я собираюсь обозначить некоторые проблемы (но их можно и нужно решать), с которыми, как мне кажется, столкнётся почти каждый, кто совсем не будет подвергать сомнению правоту клиента.

Последние пять лет я работаю в тех. саппорте. И у меня сложилось некоторые принципы, следование которым, на мой взгляд, сделает любой тех. саппорт клёвым и офигительным. А если им не следовать, то саппорт будет унылым и неклёвым.

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы

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

К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.

В этом случае нам поможет одна интересная штука.

Послал как-то письмо в Сбербанк, с рядом вопросов:

1) Реквизиты попросил на свою maestro карту.
2) Поинтересовался, можно ли сменить дизайн карты (а то осенний Летний сад, наводит осеннюю хандру даже летом).
3) Чем отличается MasterCard от Maestro и Visa Electron от Visa Classic.

зачем нужен paint, photoshop, corel? нам клиенты скриншоты ошибок рисуют. handmade