Рубрика «helpdesk» - 5

Вы должны сказать: «Мы закончили это. Сделано!», а затем продолжить движение к следующей цели.
REWORK

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


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

Необходимость поддержки

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

Долгий цикл производства (time to market) — зло, тем более в сфере мобильных технологий, где операционные системы обновляются каждый год, а новые устройства появляются раз в два-три месяца. Если вы разрабатываете первую версию продукта более полугода, это означает, что он морально устареет еще до публикации.

Забавный факт. Год назад мы подписали договор на создание приложения, в котором указали, что минимальной поддерживаемой версией ОС будет iOS 7, к тому моменту еще не вышедшая. Нас заставили вставить примечание, что требование действительно, в случае, если новая версия ОС выйдет, и случится это в запланированные Apple сроки. В итоге Apple уже анонсировала iOS 8, но приложение до сих пор не опубликовано.

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

Основными задачами, решаемыми после публикации приложения являются:

  • мониторинг работоспособности;
  • получение обратной связи от конечных пользователей продукта и оказание помощи в решении их проблем;
  • улучшение стабильности работы и добавление новой функциональности;
  • адаптация приложения под новые устройства и версии ОС;
  • отслеживание степени удовлетворения бизнес-потребностей компании-заказчика;
  • корректировка плана развития продукта.

И вот, как мы решаем эти задачи.Читать полностью »

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

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

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

Читать полностью »

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

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

Некоторое время назад в нашей компании была внедрена система поддержки клиентов OTRS. OTRS легко интегрируется с Active Directory, существует масса пошаговых инструкций, в том числе на Хабре.
Практика использования системы поддержки показала, что ввести пароль а еще и логин доменной учетной записи задача, для пользователя весьма сложная, для руководителей вообще не приемлемая.

Читать полностью »

О проекте.

Доброго дня, уважаемые коллеги по отрасли. Сегодня я решился рассказать вам о своем небольшом проекте. Это helpdesk система, написанная под нужды собственной аутсорс — компании, а точнее её beta – версия. Проект написан на yii framework с использованием некоторых extensions сторонних авторов.

Простенький helpdesk

Встречайте vsDesk.
Читать полностью »

Техподдержка для чайников: счастье в один клик

Традиционная модель хелпдеск требует от пользователя и от техподдержки слишком много шагов:

  1. Пользователь звонит в поддержку / заполняет форму с описанием инцидента. Точность описания тут полностью зависит от компетенции пользователя, которая часто не высока, а иногда слишком высока, что тоже не лучший вариант.
  2. Сотрудник поддержки начинает/продолжает заполнять форму с описанием инцидента. Никакие организационные меры не позволяют свести к нулю количество заявок в которых инцидент описан недостаточно, неверно или не описан вовсе.
  3. Только после этого начинается реальная работа по диагностике и устранению инцидента.

Очевидно, что в этой схеме первые два шага лишние и избыточные. Не удивительно, что и пользователи и сотрудники техподдержки всеми силами стремятся увильнуть от почетной обязанности заполнения заявок. Мы придумали, как без них можно обойтись.
Читать полностью »

Здравствуйте!
Сразу к сути. Со мной поделились информацией, по которой теперь первая линия поддержки (helpdesk, service desk) должна принимать заявки, которые никак не относятся к области IT. Ну, примера ради: заказ такси, замена лампочки в потолке на каком-нибудь этаже, и т.п. Будучи сотрудником этой самой первой линии, меня немного озадачил данный момент. Отмечу, что речь идет именно о приеме заявки, а не исполнении её на первой линии.
В связи с этим хотел бы спросить у Хабрасообщества, принимает ли у Вас в организации служба технической поддержки, а конкретно — первая линия поддержки, заявки, которые никак не относятся к сфере IT.

Что такое хелпдеск? Система управления заявками пользователей, личинка сервисдеска, первый шаг эникейщика на пути к ITIL, бла-бла-бла…

Принудительно внедряем Helpdesk: опыт «Корпорации Зла»

Литература, посвященная вопросу организации системы управления инцидентами (заявками пользователей, проблемами в ИТ — называйте, как хотите) делится на две категории. Первая включает в себя технические низкоуровневые мануалы, посвященные, в основном, тонкостям настройки конкретных решений. Такие работы могут рассказать в подробностях, как добиться прироста производительности в WonderDesk величиной 0.001% под SuperSQL v.0.0001 alpha, но, как правило, ничего не говорят о том, зачем вообще нужен этот WonderDesk, и, главное, что с ним, существенно ускоренным, потом делать.

Вторая категория написана для… Даже не знаю, для кого. Я бы сказал, что для богов, но им, вроде, инструкции не нужны. «Нужно пересмотреть саму парадигму взаимодействия паттернов бизнес-процессов в рамках концепции корпоративных ценностей с целью повышения уровня зрелости...» Ага, пересмотрел (предварительно подглядев в словаре значения всех этих непонятных слов), дальше что? Как сделать, чтобы мое «пересмотренное понимание» заставило пользователей писать заявки, эникейщиков — обрабатывать их, а уровень зрелости — повышаться?! Предлагаете «постепенно внедрять лучшие практики управления»? Да, как же их внедрить, если я простой эникейщик и ничем не управляю?!

Остается одно — пытаться действовать «по наитию». О двух таких попытках, о том, как именно они предпринимались, какие имели предпосылки, к каким привели результатам, т.е. о практическом опыте внедрения хелпдеска в условиях агрессивной враждебной среды, и будет рассказано в этом топике. Надеюсь, он хоть немного заполнит образовавшийся пробел, предоставив эникейщикам и низкоквалифицированным админам сведения о том, как из состояния A, когда о хелпдеске и речи быть не может, перейти в состояние A', когда этот хелпдеск уже внедрен и работает.
Читать полностью »

Прошлая статья на хабре вызвала некоторый резонанс среди пользователей. Со многими удалось пообщаться в IM. Из разговоров стало ясно, что очень многие хотят сделать СВОЮ систему, заточенную под их нужды. Требования и желания различаются очень сильно и существующие на рынке решения не удовлетворяют потребностей.

В статье я постараюсь рассказать о технической стороне проекта. А начну с беглого осмотра существующих решений.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js