Service Desk *

Случилось так, что назначили меня начальником ИТ отдела. В бытность того времени я занимал должность начальника группы разработки и эксплуатации электронных информационных систем, и, благодаря то тому что вся группа на тот момент состояла из одного человека – меня, я легко с ней управлялся. Однако же мои рационализаторские таланты не прошли мимо руководства, и, в период реорганизации компании, группу ИТ (с парой админов и начальником) решили вывести из под отдела инженерно-технического департамента и сделать отдельный ИТ отдел. Меня же в свою очередь вывели из отдела обеспечения качества (не спрашивайте, что там делала группа РЭЭИС) и сделали начальником этого «новосозданного» отдела. С одной стороны, это тешило самолюбие. С другой стороны, помимо той работы, которую я выполнял, мне еще придется заботиться о ковриках для мышек, и «у меня курсор не мигает» … Отказаться тоже было не особо возможно. Собственно, мне просто положили на стол приказ о том, что теперь я начальник. Предполагая, что количество работы от этого назначения не уменьшится, я уведомил начальство (которое, видимо, думало, что я ничем не занимался), что руководить группой у меня скорей всего времени не хватит, хватит только управлять. Начальство махнуло рукой – для него видимо разницы не было.

Всем доброго дня!
Когда-то в прошлом, мы решили приобрести продукт для организации приема заявок ИТ в своей компании и наш выбор пал на Российскую разработку vsDesk. Купили мы ее еще в версии 1.0, потом успешно в течение первого года использования обновились до 2.0 ПРО. Сейчас вышла версия 3.0 и руководство не готово оплатить обновление, но мой интерес к проекту не угас и я решил установить версию Старт, которая распространяется бесплатно.
В данной статье хотел бы описать процедуру установки под Ubuntu server, так как пакет установки для Windows не требует особых навыков, а мне хотелось поразмяться и вспомнить былые админские навыки.

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

Встает вопрос: какое средство автоматизации выбрать, чтобы уже “навсегда” (или хотя бы надолго)? Какой Help Desk поможет принимать взвешенные решения, специфичные для сервисного бизнеса, например, о повышении стоимости услуг или найме новых сотрудников?

Если ваша деятельность связана именно с предоставлением услуг:

• ИТ-обслуживание (IT-аутсорсинг);
• вендорская или дилерская тех.поддержка;
• управление коммерческой недвижимостью;
• поддержка сайтов;
• обслуживание промышленного оборудования, инженерных коммуникаций, систем видеонаблюдения и т.д.

и описанная выше проблема вам не чужда — давайте разбираться!

/ фото Juhan Sonin CC

Постоянно меняющиеся требования, предъявляемые к облачной инфраструктуре, ведут к необходимости проработки новых бизнес-моделей и создания архитектурных решений. Это позволяет постоянно повышать уровень защищенности и управляемости данных.

В нашем блоге на Хабре мы уже писали о решениях и сервисах для управления данными и организации резервного копирования в облако IaaS-провайдера.

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

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

Зачем выписывать счёт вручную, если это может сделать программа? Зачем держать логиста, если система сама сможет сформировать акты, поставить подпись в виде картинки и отправить клиенту? Зачем платить зарплату операторам колл-центра, если можно организовать поддержку на сайте через новомодные тикеты и давать небольшому денежку одному человеку начального уровня, который будет на эти тикеты отвечать?

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

Первое время все счастливы, собственник хвалит директора за экономию (сейчас это обтекаемо называется оптимизацией расходов). А вот потом начинаются проблемы.

В предыдущих статьях было рассказано о системе электронного документооборота easla.com и о том, как можно быстро начать с ней работать на примере одного процесса и одного пользователя. Тем, кто заинтересовался, наверняка интересно узнать, как организовать работу с системой всех пользователей организации. Особенный акцент сделан на совместителях — специально для сервисных компаний (service desk и help desk).

В easla.com зарегистрированный пользователь — это администратор, пользователь созданный администратором — это сотрудник, а сотрудник работающий в нескольких организациях — это совместитель! Заинтриговал?

Easla.com – новая онлайн система электронного документооборота (платформа). Предназначена для управления, как данными, так и документами. Позволяет поэтапно или разом автоматизировать бизнес-процессы любой сложности в организации любого масштаба.

— А-а-а, опять новая система… — подумаете вы. Но, предлагаю чуть придержать скептицизм и ознакомиться с возможностями и особенностями системы, прежде, чем записывать ее в «длинный список» под названием «слышали — знаем».

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



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

Привет, Хабр! Я работаю в Mail.Ru Group в отделе разработки плагинов JIRA. Плагины позволяют расширять или изменять функциональность приложения. Например, с их помощью можно создавать новые типы полей, гаджеты, JQL-запросы, панели с различной информацией, графики и многое другое.

Большинство наших плагинов требуют хранения дополнительных данных, которые они используют. В этой статье я хочу рассказать, как мы решаем эту задачу. Существует два основных способа хранения таких данных: Active Objects и Plugin Settings. Рассмотрим их поподробнее и разберемся в каком случае лучше и удобнее использовать один, а в каком — другой.

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

Зачем ВАМ эта статья? Так сложилось, что я работал и работаю с огромным количеством интернет магазинов (в сфере онлайн продвижения), и 80 процентов покупок обычно совершаю в интернете. Мне мучительно больно от того, что люди вкладывают миллионы в разработку и продвижение своих магазинов и сервисов, накидывают никому не нужные фишки, но упускают из виду такой чрезвычайно важный, по-моему мнению, элемент, как адекватная служба поддержки.

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

В этой статье я расскажу об одном из способов, которым мы пользуемся в компании Parallels.

Друзья, всем привет!

Мы продолжаем переводить и публиковать для вас лучшие материалы о поддержке клиентов. В данном материале речь пойдет о том, что использование определенных фраз может изменить восприятие информации вашими пользователями. «Словом можно убить, а можно вылечить человека» (с) — в отношении службы поддержки эта пословица особенно актуальна! Ниже приведены и разобраны шесть конкретных фраз, которые способны сделать ваших клиентов более счастливыми.



От переводчика: С оригинальной статьей вы можете ознакомиться по ссылке. Список ранее переведенных материалов доступен в конце поста. Приятного чтения, команда сервиса для поддержки клиентов Teamdesk.

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



Сегодня мы публикуем отличную статью из блога компании Groove о поддержке клиентов. В материале идет речь о том, как правильно и неправильно использовать скрипты в поддержке по Email. Также приведены шаблоны ответов на самые каверзные вопросы клиентов о скидках и фичах, ответы на гневные письма и “когда все пропало”.

С каким бы приложением ни была связана ваша работа и в каком бы качестве вы ни присутствовали в процессе, рано или поздно наступит тот момент, когда к вам впервые явится пользователь и, доверчиво моргая, спросит: а почему у меня пимпочка не пимпает? Чтобы пимпочка пимпала, – скажете вы, погибая от умиления (поставил! пользуется!), – нужно сперва покрутить крутёлочку. К десятому пользователю умиления поубавится. К пятидесятому вы, вероятно, заведете пару-тройку шаблонов для ответа на наиболее популярные вопросы. К сотому наймете с полдесятка студентов на должность инженеров технической поддержки и вздохнете с облегчением – ровно до того момента, пока один из них не образуется у вашего рабочего стола с вопросом: а у меня тут пользователь пришел, и у него пимпочка не пимпает – почему? Крутёлочка? Какая крутёлочка?

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

Во вторник, 21 апреля, Mail.Ru Group организует первый Moscow Atlassian Meetup. В офисе компании соберутся эксперты в области организации общения с пользователями и управления проектами. В программе события — доклады по продуктам Atlassian (JIRA, Confluence и другим), а после — их обсуждение и общение единомышленников в свободной обстановке.

FYI: пост рассчитан на руководителей, занимающихся вопросами ИТ и ИТ-аутсорсинга.

Аутсорсинг нужен, чтобы:

1. освободить персонал (в нашем случае – ИТ-персонал) от рутинных и непрофильных задач;
2. сконцентрировать силы сотрудников на главных для бизнеса функциях;
3. снизить финансовую нагрузку на компанию.

Добиться всего перечисленного вполне реально – если правильно подойти к аутсорсингу. Этот пост о том:

• как подготовить и начать кампанию ИТ-аутсорсинга;
• как выбрать надежного поставщика;
• что можно и нельзя отдавать на ИТ-аутсорсинг.

Мы пытаемся делать Яндекс.Почту такой, чтобы в ней всё всем сразу было очевидно и никакая помощь не была нужна. Увы, это не всегда получается, поэтому у нас есть служба поддержки. Думаю, на Хабре многие понимают, что очень непросто организовать службу поддержки так, чтобы она могла быстро отвечать всем пользователям такого огромного сервиса, как Яндекс.Почта, и при этом не рассылала полуавтоматизированные отписки, а помогала по существу и разбирала проблемы в самом сервисе.



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

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

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

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

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

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

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

На этой неделе вышел очередной релиз SmartNut-а — Service Desk системы для ИТ-компаний и ИТ-отделов.

Самое приятное из новостей: теперь появилась возможность автоматической обработки писем, приходящих на email техподдержки, и регистрация на основании этих писем заявок от пользователей/клиентов.

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

Под хабракатом — подробнее и в деталях.