На первый взгляд может показаться, что поддержка пользователей довольно простая и элементарная функция ИТ подразделения компании. И может быть это даже верно, если в компании небольшое число пользователей, ну, скажем, до 50 человек. А если больше? Если больше, тогда уже довольно сложно обойтись просто "эникейщиком" в штате, тогда уже нужно думать, как лучше организовать поддержку.
Первое правило ИТ-поддержки:
"НУЖНО РЕГИСТРИРОВАТЬ ВСЕ 100% ОБРАЩЕНИЙ."
Почему это важно:
Это достаточно простое правило сильно помогает в спорных моментах, поскольку позволяет зафиксировать факт обращения, перечень поступившей информации и наш ответ пользователю. Отсутствие зарегистрированного обращения, с одной стороны является нашим нарушением, а с другой не позволяет нам опираться на факты. Зарегистрированные заявки дают почву и базу для анализа количества и причин обращений. Кроме того сам факт регистрации заявки и сообщение срока ее выполнения зачастую снимает некий "негатив" пользователя в сторону ИТ, особенно в том случае, если обращение было вызвано какими-либо проблемами или инцидентами.
Регистрация обращений- это не самая главная, но одна из основных функций Службы поддержки пользователей.
Помимо всего прочего, соблюдение правила 100% регистрации находится в области моего акцентированного внимания, как руководителя ИТ, и первое, что я спрашиваю у пользователей при их обращении ко мне, например для эскалации решения какой-либо проблемы, - это регистрационный номер заявки в нашей системе управления задачами. Это дисциплинирует как сотрудников службы поддержки, так и самих пользователей, особенно самых громких и скандальных личностей. Они уже не могут безапеляционно заявлять "у вас ничего не работает", а вынуждены сформулировать суть своей проблемы, пусть и с помощью сотрудников службы поддержки.
Что обычно не регистрируется, а должно:
- непонятные запросы/требования/инциденты
- обращения с неполной информацией
- неподписанные бланки, пришедшие по электронной почте
- заявки, оправленные по электронной почте не на бланках
Все это также необходимо регистрировать, а уже после решать, что делать с этими обращениями.
Что нужно понимать:
Что "регистрация обращения" и "принятие решения" - это совершенно разные вещи. Т.е. сначала регистрируем, а потом думаем, что с этим делать. Например:
- уточняем у пользователя недостающую информацию,
- консультируемся по характеру задачи (задача / инцидент / разработка),
- консультируемся, что делать с заявкой нового типа,
- уточняем исполнителя и т.п.
Ну, а то, как дальше работать с заявками - это уже тема для другий постов. Уверен, что это мой не последний материал по теме поддержки пользователей. И вскоре здесь будут другие правила, которых придерживаемся мы у себя в компании. Надеюсь, что наш опыт может кому-нибудь помочь в более эффективной организации работы ИТ-поддержки.
Первое правило ИТ-поддержки:
"НУЖНО РЕГИСТРИРОВАТЬ ВСЕ 100% ОБРАЩЕНИЙ."
Почему это важно:
Это достаточно простое правило сильно помогает в спорных моментах, поскольку позволяет зафиксировать факт обращения, перечень поступившей информации и наш ответ пользователю. Отсутствие зарегистрированного обращения, с одной стороны является нашим нарушением, а с другой не позволяет нам опираться на факты. Зарегистрированные заявки дают почву и базу для анализа количества и причин обращений. Кроме того сам факт регистрации заявки и сообщение срока ее выполнения зачастую снимает некий "негатив" пользователя в сторону ИТ, особенно в том случае, если обращение было вызвано какими-либо проблемами или инцидентами.
Регистрация обращений- это не самая главная, но одна из основных функций Службы поддержки пользователей.
Помимо всего прочего, соблюдение правила 100% регистрации находится в области моего акцентированного внимания, как руководителя ИТ, и первое, что я спрашиваю у пользователей при их обращении ко мне, например для эскалации решения какой-либо проблемы, - это регистрационный номер заявки в нашей системе управления задачами. Это дисциплинирует как сотрудников службы поддержки, так и самих пользователей, особенно самых громких и скандальных личностей. Они уже не могут безапеляционно заявлять "у вас ничего не работает", а вынуждены сформулировать суть своей проблемы, пусть и с помощью сотрудников службы поддержки.
Что обычно не регистрируется, а должно:
- непонятные запросы/требования/инциденты
- обращения с неполной информацией
- неподписанные бланки, пришедшие по электронной почте
- заявки, оправленные по электронной почте не на бланках
Все это также необходимо регистрировать, а уже после решать, что делать с этими обращениями.
Что нужно понимать:
Что "регистрация обращения" и "принятие решения" - это совершенно разные вещи. Т.е. сначала регистрируем, а потом думаем, что с этим делать. Например:
- уточняем у пользователя недостающую информацию,
- консультируемся по характеру задачи (задача / инцидент / разработка),
- консультируемся, что делать с заявкой нового типа,
- уточняем исполнителя и т.п.
Ну, а то, как дальше работать с заявками - это уже тема для другий постов. Уверен, что это мой не последний материал по теме поддержки пользователей. И вскоре здесь будут другие правила, которых придерживаемся мы у себя в компании. Надеюсь, что наш опыт может кому-нибудь помочь в более эффективной организации работы ИТ-поддержки.
5 комментариев:
Вы испытали удовольствие, от цифр которые показал счётчик посещений с реферером хабрахабра?
Дурацкая привычка пиарить собственные блоги на Хабре, в результате только минусы и ловите. И в карму тоже.
Вот, не пойму, почему ссылка на мой блог является "дурацкой привычкой"? И собственно, что плохого в пиаре. Да, я хочу познакомить людей со своим блогом? Ссылки для этого и придумали.
Кому не интересно тот читать не будет.
А какую систему управления задачами используете?
Хотелось бы подробнее узнать про организацию поддержки пользователей. И как много пользователей поддерживаете.
Мы используем систему управления задачами Task Management System (TMS) на базе Axapta. Это нестандартный модуль системы Axapta, который использовался специалистами компании Columbus при внедрении системы Axapta на нашем
предприятии. Изначально он назывался GPT (global problem tracker). Мы его переименовали, чтобы было более понятно для чего он нужен :). Он изначально предназначен для планирования и управления проектами по разработке и внедрению информационных систем. После окончания проекта внедрения, мы продолжаем использовать эту систему уже не только для управления задачами разработки, но и для задач сопровождения пользователей. А так как это модуль системы Axapta, то у нас есть возможности по изменению и дополнению его функционала используя возможности среды разработки, чем мы и пользуемся, постепенно совершенствуя нашу систему, дорабатывая ее "под себя".
Мы поддерживаем более 2-х тысяч пользователей нашей компании.
Отправить комментарий