В продолжение цикла статей про построение службы ServiceDesk. В первых двух статьях мы пришли к выводу, что нам действительно нужен ServiceDesk и определились, какие услуги он оказывает. Сегодня поговорим о единой точке входа. Что это такое, для чего она нужна, какие дает преимущества.
Если у вас в ИТ несколько инженеров, то наверняка вы сталкивались с ситуацией, когда пользователи звонят им напрямую. причем звонят именно Васе, т.к. Вася сделает все быстро, а не Пете, который в прошлый раз 2 часа возился и так толком все и не починил.
Такие звонки напрямую специалистам приводят к следующим негативным последствиям:
Инженеры, выполняя работу по звонку, часто не вносят информацию об обращении (особенно если устранение заняло не более 10 минут). Квалифицированные инженеры более нагружены/перегружены, т.к. пользователи хотят общаться только с ними.
Инженеры с меньшим опытом оказываются задвинуты, и получают опыт медленнее, чем могли бы. Если пользователь не дозванивается до инженера, то он докладывает своему руководству, что в ИТ никто не берет трубку. При этом не пытается связаться с другими инженерами.
В результате вы не видите реальную картину происходящего: какие идут обращения от пользователей, как нагружены ваши специалисты. Появляются “слепые пятна” из-за которых могут быть приняты неправильные управленческие решения.
Например: удаленный офис, там штатный инженер. Согласно статистике у него 1-2 заявки в неделю. Принимается решение вывести его на аутсорс. Человека сокращают. И тут выясняется, что он целыми днями только то и делал, что бегал между пользователями и постоянно что-то чинил и настраивал. Вот только отчитываться об этом забывал/ не успевал.
Еще один минус при звонке напрямую — человека может просто не быть на месте. Он в отпуске, на больничном. Пользователь звонит, звонит, а ему никто не отвечает.
В нашем случае в роли единой точки доступа выступает отдельный номер, который был озвучен всем пользователям и много раз. В отделе были кадровые перестановки, менялась инфраструктура, система хождения звонка по очередям, была заменена АТС. Но для пользователей всегда был один номер, по которому надо звонить в случае проблем с компьютером.
Так же был заведен единый обезличенный почтовый ящик, на который все пользователи должны отправлять обращения. Мы всячески акцентируем, что лучше будет, если пользователи будут писать, а не звонить. Нам проще работать с почтой: меньше полей заполнять в заявке, можно быстрее обрабатывать, корректнее рассчитываются сроки.
Исходя из вышенаписанного, при построении службы ServiceDesk единая точка входа нужна. Все обращения пользователей (не важно как поданные) в итоге должны оказываться в одном месте. Для каждого канала передачи информации точка должна быть только одна. Это значит если телефон — то только один телефонный номер. Если почта — то только один почтовый адрес. Если скайп, то только один общий аккаунт для приема обращений.
Дальше ИТ отдел уже сам настраивает маршрутизации звонков и хождения писем.
После того, как вы создали единую точку для обращений следующий шаг — создание единой базы всех заявок. Т.к. звонки на один номер и все обращения в одном почтовом ящике это хорошо, но с ними еще надо работать. Делать аналитику, искать проблемные места и т.д.
Вид базы не имеет особого значения. Это может быть файл Excel, база 1С, самописное решение. Но она должна соответствовать вашим задачам. Уметь хранить информацию в удобном виде, предоставлять требуемую отчетность.
Что обязательно должно быть в заявке:
— Номер заявки (ее уникальный идентификатор)
— Инициатор
— Дата обращения
— Контактная информация
— Критичность
— Сервис
Это тот минимум, который необходим для того, чтобы инженер мог начать работать по заявке. Далее он уже вписывает требуемые комментарии, запрашивает дополнительную информацию и в итоге закрывает заявку.
В нашей практике был случай, когда один из пользователей отправлял письма на абсолютно чужую почту другой компании и жаловался, что ИТ отдел его игнорирует. Не разобравшись, пользователь донес жалобу до высшего руководства, по итогам разбирательства с пользователем еще раз провели беседу, куда звонить и писать в случае проблем.
Подводя итог: единая точка входа поможет уменьшить количество проблем связанных с коммуникациями и позволит иметь более полную картину по обращениям. На базе этой информации можно будет уже принимать управленческие решения.
Если у вас в ИТ несколько инженеров, то наверняка вы сталкивались с ситуацией, когда пользователи звонят им напрямую. причем звонят именно Васе, т.к. Вася сделает все быстро, а не Пете, который в прошлый раз 2 часа возился и так толком все и не починил.
Такие звонки напрямую специалистам приводят к следующим негативным последствиям:
Инженеры, выполняя работу по звонку, часто не вносят информацию об обращении (особенно если устранение заняло не более 10 минут). Квалифицированные инженеры более нагружены/перегружены, т.к. пользователи хотят общаться только с ними.
Инженеры с меньшим опытом оказываются задвинуты, и получают опыт медленнее, чем могли бы. Если пользователь не дозванивается до инженера, то он докладывает своему руководству, что в ИТ никто не берет трубку. При этом не пытается связаться с другими инженерами.
В результате вы не видите реальную картину происходящего: какие идут обращения от пользователей, как нагружены ваши специалисты. Появляются “слепые пятна” из-за которых могут быть приняты неправильные управленческие решения.
Например: удаленный офис, там штатный инженер. Согласно статистике у него 1-2 заявки в неделю. Принимается решение вывести его на аутсорс. Человека сокращают. И тут выясняется, что он целыми днями только то и делал, что бегал между пользователями и постоянно что-то чинил и настраивал. Вот только отчитываться об этом забывал/ не успевал.
Еще один минус при звонке напрямую — человека может просто не быть на месте. Он в отпуске, на больничном. Пользователь звонит, звонит, а ему никто не отвечает.
В нашем случае в роли единой точки доступа выступает отдельный номер, который был озвучен всем пользователям и много раз. В отделе были кадровые перестановки, менялась инфраструктура, система хождения звонка по очередям, была заменена АТС. Но для пользователей всегда был один номер, по которому надо звонить в случае проблем с компьютером.
Так же был заведен единый обезличенный почтовый ящик, на который все пользователи должны отправлять обращения. Мы всячески акцентируем, что лучше будет, если пользователи будут писать, а не звонить. Нам проще работать с почтой: меньше полей заполнять в заявке, можно быстрее обрабатывать, корректнее рассчитываются сроки.
Исходя из вышенаписанного, при построении службы ServiceDesk единая точка входа нужна. Все обращения пользователей (не важно как поданные) в итоге должны оказываться в одном месте. Для каждого канала передачи информации точка должна быть только одна. Это значит если телефон — то только один телефонный номер. Если почта — то только один почтовый адрес. Если скайп, то только один общий аккаунт для приема обращений.
Дальше ИТ отдел уже сам настраивает маршрутизации звонков и хождения писем.
После того, как вы создали единую точку для обращений следующий шаг — создание единой базы всех заявок. Т.к. звонки на один номер и все обращения в одном почтовом ящике это хорошо, но с ними еще надо работать. Делать аналитику, искать проблемные места и т.д.
Вид базы не имеет особого значения. Это может быть файл Excel, база 1С, самописное решение. Но она должна соответствовать вашим задачам. Уметь хранить информацию в удобном виде, предоставлять требуемую отчетность.
Что обязательно должно быть в заявке:
— Номер заявки (ее уникальный идентификатор)
— Инициатор
— Дата обращения
— Контактная информация
— Критичность
— Сервис
Это тот минимум, который необходим для того, чтобы инженер мог начать работать по заявке. Далее он уже вписывает требуемые комментарии, запрашивает дополнительную информацию и в итоге закрывает заявку.
В нашей практике был случай, когда один из пользователей отправлял письма на абсолютно чужую почту другой компании и жаловался, что ИТ отдел его игнорирует. Не разобравшись, пользователь донес жалобу до высшего руководства, по итогам разбирательства с пользователем еще раз провели беседу, куда звонить и писать в случае проблем.
Подводя итог: единая точка входа поможет уменьшить количество проблем связанных с коммуникациями и позволит иметь более полную картину по обращениям. На базе этой информации можно будет уже принимать управленческие решения.
