Дипломный проект «АВТОМАТИЗИРОВАННАЯ СИСТЕМА УЧЕТА И РАСПРЕДЕЛЕНИЯ ЭЛЕКТРОННОЙ КОРРЕСПОНДЕНЦИИ»
ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 СЛУЖБА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ
Служба технической поддержки или техподдержка (Technical support, Helpdesk, Service Desk) — сервисная структура, разрешающая проблемы пользователей с компьютерами, аппаратным и программным обеспечением. Важная функциональная составляющая ITIL (библиотека инфраструктуры информационных технологий), позволяющая выявить проблемные участки инфраструктуры ИТ, оценить эффективность работы подразделения ИТ.
Методология организации службы технической поддержки
Служба технической поддержки на каждом предприятии может быть построена разнообразными способами (имеется в виду реализации процессов поддержки). Существует несколько моделей службы поддержки, например: централизованная, локальная, виртуальная – с единым телефонным центром и т.д. Служба технической поддержки может быть организована как в целях обслужить внешних клиентов (аутсорсинг, обслуживания компьютеров и т. п.), так и внутренних (подразделение ИТ — департамента на крупных предприятиях).
В описании концепции ITIL, построенной на процессном подходе, Service Desk является единственным описанным функциональным подразделением. Это исключение сделано ввиду большой важности подразделения техподдержки при внедрении практическом использовании современных ИТ — подходов и методик.Правильно организованная техническая поддержка (Service Desk) всегда начинается с регистрации всех обращений конечных пользователей, служит единой точкой для обращений пользователя с ИТ — службой. Наиболее популярные решения по практической организации техподдержки часто строятся на базе «Call-center» (иногда даже пользователи их отождествляют). Он является начальной точкой контактов конечных пользователей со службой техподдержки и служит источником информации об их фактической удовлетворенности уровнем сервиса, что дополняет информацию о технических параметрах качества обслуживания компании-клиента (внешнего или внутреннего). На больших предприятиях или в крупных компаниях — аутсорсерах служба технической поддержки часто организована по следующему многоуровневому принципу:
Пользователь – обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки;
Оператор (1-я линия поддержки, «Call-center») – регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки;
Вторая линия поддержки – получает заявки от первой линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из смежных отделов (системные администраторы, поддержка POS-терминалов, поддержка специального ПО, поддержка специального оборудования и т. д.).
Основополагающие принципы организации службы
В соответствии с жизненным циклом информационных систем, включающим периоды проектирования, внедрения, эксплуатации и развития, единственный период, когда система приносит реальную пользу организации -это период ее производственной эксплуатации. За весьма редкими исключениями, эксплуатация информационной системы предполагает использование ее сотрудниками организации, не входящими в службу ИТ (службу поддержки) – конечными пользователями информационной системы. При этом в большинстве случаев именно по повышению эффективности и качества работы этих конечных пользователей судят об эффективности и качестве информационной системы и качестве работы информационной службы. По сути, конечные пользователи являются заказчиками и потребителями информационно-технологических услуг (сервисов ИТ).
В [1] предлагается рассматривать отношения между конечными пользователями и службой ИТ как традиционные рыночные отношения. То есть имеется некоторая услуга, имеется поставщик соответствующей услуги и имеется покупатель соответствующей услуги. Поставщик и покупатель заключают некоторое соглашение, которое определяет условия предоставления услуги, ее качество и т.д. Конечно, такой подход не столь уж очевиден для традиционной ситуации, когда служба ИТ является частью организации – «покупателя». Но мировая практика показывает, что только при организации взаимодействия именно на основе таких принципов возможно достижение полного контроля над инфраструктурой ИТ и существенное сокращение расходов на ее обслуживание.
Предметом договоренности в предлагаемой модели является некоторая услуга, предоставляемая сотрудникам компании департаментом информационных технологий («сервис ИТ»). Понятие «сервис ИТ» обычно употребляется в нескольких различных смыслах. С одной стороны – это услуга, которую служба ИТ предоставляет конечному пользователю. Например, доступ в интернет. Или применение автоматизированной системы управления складом для выполнения учетных операций. С другой стороны, предоставление услуги связано с использованием целого ряда технологий и решений, а возможно – и иных сервисов. В этом смысле всякий сервис ИТ — это структурированный набор оборудования, программного обеспечения, технологий, других сервисов (иногда -более низкого уровня, но вовсе не обязательно). Например, предоставление доступа в интернет предполагает наличие доступа к внешнему провайдеру, каналов связи, корпоративной сети передачи данных, сервера доступа к корпоративной сети, персонального компьютера с установленным на нем системным программным обеспечением и браузером. Эта сторона сервиса ИТ не представляет и не должна представлять большой интерес для конечного пользователя. Но она очень важна для организации деятельности службы эксплуатации.
В рамках модели отношений «поставщик сервиса – потребитель сервиса» достижение успеха находится в существенной зависимости от действий обеих сторон. Это обуславливается высокой сложностью современных информационных систем, в том числе – клиентского оборудования и программного обеспечения (той части компонент сервиса ИТ, которая размещена непосредственно у конечного пользователя). Одной из острых проблем остается обучение пользователей работе с информационной системой. И поскольку система постоянно развивается -обучение должно происходить регулярно. Это позволит более качественно готовить сотрудников. Но обучение, ни в коей мере не снизит собственно сложность системы. И в процессе работы с системой у пользователя все равно будут возникать различные вопросы и проблемы, связанные с сервисами ИТ. То есть будут возникать ситуации, когда ему будет нужна помощь.
В этом случае пользователь может выбрать различные варианты поведения:
заняться «самолечением» – то есть попробовать самостоятельно решить проблему;
обратиться за помощью к коллегам;
обратиться к поставщику сервиса.
У каждого варианта существуют свои достоинства и недостатки.
Самостоятельное решение проблемы – наиболее быстрый способ, поскольку нет необходимости искать кого-нибудь ждать, объяснять и т.д. Но к сожалению далеко не все пользователи обладают необходимой квалификацией. Да и далеко не все проблемы могут быть решены самостоятельно: например, никакой пользователь не сможет устранить сбой сервера. В общем, можно рекомендовать такой вариант только для простейших ситуаций и только при остром дефиците времени.
К помощи коллег прибегают, как правило, тогда, когда самостоятельно ничего не получается. Плюс – это возможность обратиться быстро и непосредственно. Минусы – те же, что и в предыдущем случае, дополнительная трата времени на объяснение проблемы, не гарантированность получения квалифицированной помощи. Такой вариант поведения вообще сложно рекомендовать.
Наиболее правильным является обращение за помощью к поставщику сервиса ИТ. Основной проблемой при таком обращении обычно является отсутствие качественного механизма для данных целей. Иными словами – пользователю предельно неудобно обращаться за помощью к провайдеру. В остальном – только плюсы: имеются квалифицированные специалисты; проблема будет проанализирована со всех сторон и решена оптимальным образом; имеются все необходимые для решения проблемы права; наконец, имеется база знаний, которая может помочь в решении проблем. И еще одно неоспоримое преимущество перед другими способами: дело в том, что заключая соглашение с поставщиком сервиса, пользователь тем самым имеет право требовать от поставщика нормальной работы сервиса, в то время, как требовать это от себя или коллег невозможно.
Вывод: по всем вопросам, связанным с использованием сервисов ИТ, конечные пользователи должны обращаться только в службу ИТ.При развитии компании, увеличении количества пользователей и сервисов обращение за помощью в департамент информационных технологий становится нормой, так как качественный и гарантированный уровень обслуживания пользователь сможет получить только в департаменте ИТ.
При решении обратиться за помощью возникают новые вопросы.
Приняв решение о необходимости обратиться за поддержкой в службу ИТ, пользователь обычно оказывается в несколько неопределенной ситуации:
кому именно можно обратиться.
Здесь тоже возможны различные ситуации:
Обратиться к знакомому. Легче всего обратиться к человеку, которого знаешь. И он обязательно поможет, если конечно это в его силах. Данный вариант не всегда подходит для решения поставленной задачи. Знакомого может не оказаться на месте, он будет занят или, возможно, он сам не будет знать куда можно обратиться.
Спросить любого сотрудника службы ИТ. Он, скорее всего посоветует к кому именно следует обратиться по данному вопросу. Далее – спросить у рекомендованного. Возможно дальнейшее продолжение цепочки. Пользователю действовать таким способом неудобно. Такая организация работы не удобна пользователям и самим сотрудникам отдела ИТ.
Возникает очень важная проблема: отсутствие ответственных за работу с пользователями сотрудников приводит к беспорядку в деятельности службы ИТ. При поступлении заявки невозможно отследить, кто и когда ее выполнил. Зачастую, при выполнении заявок через 1-2 месяцев невозможно установить, кто давал заявку, и кто ее выполнял.
Поэтому единственный вариант, когда любой пользователь точно знает к кому именно следует обращаться с вопросами, и при этом соответствующий представитель службы ИТ всегда готов выслушать обращение пользователя и предпринять необходимые шаги для решения поставленного вопроса – это создание в рамках департамента информационных технологий службы поддержки пользователей.
Вывод: в рамках службы ИТ должна существовать выделенная группа сотрудников, которые будут отвечать на запросы пользователей.Но нельзя ограничиться только созданием такой группы. Чтобы запрос пользователя не оказался «повисшим в воздухе», а попал нужному специалисту и рассматривался в допустимые сроки, и созданная группа, и конечные пользователи должны работать в соответствии с определенными правилами. Дело в том, что с момента обращения пользователя в информационную службу за помощью, он в общем снимает с себя ответственность и может абсолютно ничего не делать, поскольку при разборе ситуации виноватой все равно окажется служба ИТ. Таким образом, уже сама служба становится заинтересованной в формализации поддержки пользователей, разграничении полномочий и упорядочении деятельности сотрудников при оказании помощи пользователям. Последовательность обработки обращений пользователей должна помочь сосредоточить силы сотрудников службы ИТ на наиболее важных и критичных событиях, происходящих в инфраструктуре ИТ, но вместе с тем не оставить без должного внимания и все остальные обращения пользователей.
Происходит своеобразное разделение труда. Пользователи тоже участвуют в таком разделении труда, поскольку обращаются за помощью только к диспетчерам и не отвлекают своими вопросами остальных сотрудников департамента информационных технологий, давая им возможность работать более продуктивно.
Вывод: порядок оказания поддержки конечным пользователям должен быть четко формализован для всех участников процесса: пользователей, диспетчеров, специалистов информационной службы и внешних поставщиков сервисов.
С формально-организационной точки зрения, все перечисленные возможности и пути улучшения позволяют построить реально полезную для организации систему поддержки конечных пользователей. Они содержат рекомендации по изменению фундаментальных оценок роли департамента информационных технологий в деятельности организации и соответственно – в повышении его ответственности перед организацией и конечными пользователями как основными потребителями услуг ИТ.
Для дальнейшего восприятия будет полезно определить более точно предмет деятельности службы поддержки, определить – какого типа помощь может понадобиться конечным пользователям.
Без этого определения в крупной Компании, в которой работают большое количество пользователей, построение службы технической поддержки просто не предоставляется возможным. Разделение на отдельные сервисы уже является обязательным.
Обращения пользователейВ [1] предлагается следующий вариант классификации обращений пользователей в службу поддержки:
Запрос обслуживания. Запрос, связанный с необходимостью обслуживания оборудования или иного компонента сервиса ИТ со стороны службы ИТ. Например, это может быть замена картриджа в лазерном принтере или переконфигурирование программного обеспечения на персональном компьютере пользователя.
Запрос информации (консультации). Пользователю нужна дополнительная информация по сервису ИТ, порядку работы и т.п.
Инцидент. Пользователь не может нормально работать: сервис ИТ недоступен или качество сервиса не удовлетворяет пользователя.
Запрос документации. Пользователю необходима документация по применяемому оборудованию и программному обеспечению.
Запрос на внесение изменений. Пользователь хотел бы изменить параметры сервиса ИТ либо изменить список получаемых сервисов. Часто такие запросы связаны с низким (не удовлетворяющим пользователя) качеством сервиса по вине оборудования или программного обеспечения.
Такая классификация позволяет более эффективно строить дальнейшую обработку обращений. В зависимости от типа обращения оператор диспетчерской службы принимает решение о том, кто будет исполнителем данного обращения. Наиболее критичным для бизнеса типом обращения по понятным соображениям является инцидент.
Обработка инцидента – основной процесс, выполняемый службой поддержки пользователей. Он включает в себя выполнение мероприятий по восстановлению работоспособности сервиса ИТ в кратчайшие сроки. В некоторых организациях приоритет данной задачи настолько выше остальных, что деятельность службы поддержки пользователей практически полностью сводят к устранению инцидентов.
Формирование правил взаимодействия
На основе выше изложенного можно сделать следующие выводы:
Вывод первый: необходимость оказания поддержки пользователям однозначно следует из сложности и комплексности современных информационных систем.
Вывод второй: конечных пользователей интересуют сервисы ИТ — услуги, предоставляемые департаментом ИТ при помощи различного оборудования и программного обеспечения.
Вывод третий: оказание поддержки — обязанность службы ИТ; пользователи имеют право обращаться за поддержкой только к ней.
Вывод четвертый: должны быть четко определены ответственные за оказание поддержки сотрудники службы ИТ.
Вывод пятый: поддержка должна оказываться в соответствии с однозначно определенными правилами для всех участников процесса.
Перечисленные принципиальные выводы лежат в основе успешной деятельности информационной службы и являются основой построения службы поддержки. Действительно, создание службы поддержки пользователей – это в первую очередь четкое определение: правил взаимодействия конечных пользователей со службой ИТ, правил работы сотрудников службы поддержки пользователей и правил взаимодействия сотрудников службы ИТ между собой.Данные правила должны содержать ответы на перечисленные ниже вопросы.
Вопросы взаимодействия конечных пользователей со службой ИТ:Каким образом конечный пользователь может обратиться за поддержкой;Какие запросы пользователя должны быть обработаны службой ИТ;Каким образом конечный пользователь может уточнить текущее состояние обработки своего запроса;Каким образом пользователь подтверждает закрытие своего запроса;Вопросы, относящиеся к Работе сотрудников службы поддержки пользователей:Каким образом осуществляется учет обращений пользователей;Каким образом определяются приоритеты обработки обращений пользователей;Каким образом определяются исполнители, ответственные за обработку обращений пользователей;Каким образом специалист, ответственный за обработку обращения пользователя, осуществляет данную обработке;Каким образом сотрудники службы поддержки учитывают выполненные действия, и отчитаться в проделанной работеВопросы, относящиеся к взаимодействию сотрудников службы ИТ между собой:Каким образом специалист назначается ответственным за обработку обращения пользователя;Каким образом осуществляется контроль процесса обработки;Каким образом может быть изменен ответственный за обработку обращения пользователя.
Конечно, перечень вопросов может быть продолжен. Но грамотно проработанные ответы даже только на перечисленные вопросы уже позволят организовать хорошо функционирующую службу поддержки.
Можно ответить на каждый из поставленных вопросов в отдельности, но будет правильнее это делать сгруппировать ответы в некоторые последовательности действий — в процедуры и процессы.
На самом деле данные правила являются формальными процедурами, реализующими отдельные бизнес-процессы департамента информационных технологий. Для их описания могут быть применены любые способы, применяемые для описания всяких бизнес-процессов и процедур: текстовое изложение, представление в виде диаграмм в стандартизованных нотациях, иное графическое представление.
Поскольку процессы, как правило, достаточно сложные, рекомендуется применять при описании декомпозицию на модули и последовательную их детализацию. Основным критерием при выборе варианта представления является удобство восприятия правил их исполнителями. С этих позиций графическое представление имеет существенное преимущество перед простым текстовым изложением. Выбор строгой стандартизованной нотации позволит в дальнейшем эффективно анализировать процессы, и при необходимости – реорганизовывать.
Но при этом стандартные нотации все — же требуют определенной предварительно подготовки как «писателя», так и «читателей». Поэтому в большинстве организаций останавливаются на некотором упрощенном и интуитивно понятном способе отображения, добавляя к графическим данным необходимые текстовые пояснения.
Роли в службе поддержки пользователей.
Следующим важным элементом при создании службы поддержки являются люди. Как правило, приходится несколько менять организационную структуру информационной службы. Это связано с необходимостью выделения группы сотрудников, которые будут исполнять обязанности диспетчеров – то есть именно тех, к кому непосредственно будут обращаться пользователи со своими запросами. В случае небольшой организации это может привести к возложению таких обязанностей на одного или нескольких сотрудников службы ИТ дополнительно к существующим обязанностям.
В крупных организациях, а также в организациях, где техническая поддержка очень важна, следует создавать специальное подразделение — диспетчерскую службу поддержки пользователей.
В общем случае необходимые изменения в организации службы ИТ связаны с возникновением новых ролей в результате формального описания процессов взаимодействия.
Роль – это набор обязанностей, прав и ответственностей. Это понятие близко к понятию «должность», отличается от последнего тем, что не предполагает штатного закрепления: исполнитель роли может меняться в соответствии с графиком или по иным правилам. В отдельных случаях для исполнения роли может быть создана специальная штатная единица. Но в основном роли распределяются между имеющимися сотрудниками службы ИТ.
В ходе организации поддержки пользователей могут возникнуть различные типы ролей.
Диспетчеры.
Диспетчеры организовывают «первую линию поддержки». Диспетчеры являются «лицом» службы поддержки и отвечают за организацию взаимодействия с пользователями, своевременное информирование пользователей о прогрессе в рассмотрении их запросов, закрытие запросов. Кроме этого диспетчеры инициируют рассмотрение обращения пользователя путем его регистрации и назначения ответственного за его обработку, а также контролируют процесс обработки. На них могут быть возложены и иные обязанности. Диспетчер, обладающий необходимым опытом, решает более половины поступающих заявок при первом обращении к нему.
Руководитель службы поддержки пользователей.
Основной задачей этой роли является: организация поддержки пользователей; координация действий сотрудников в процессе их обработки; контроль эффективности работы службы поддержки; организация обучения персонала службы ИТ, задействованного в поддержке пользователей; обучение конечных пользователей и другие. Для исполнения данной роли тоже рекомендуется выделить отдельную штатную единицу.
Специалисты по различным направлениям деятельности службы ИТ открывают «вторую линию поддержки».
Специалисты второй линии – основные исполнители запросов пользователей. Для повышения уровня взаимодействия они могут быть объединены в рабочие группы (например, комплексная группа по поддержке определенного сервиса ИТ, включающая в себя специалистов по всем образующим данный сервис технологиям). Как правило, это сотрудники, специализирующиеся на определенных отдельных сервисах (обслуживание учетных записей, программирование, почта, администрирование, обслуживание баз данных). При возникновении ситуации, когда имеющихся сотрудников не хватает для быстрого решения этой задачи, следует рассматривать вопрос о расширении штата службы. С другой стороны, четкое распределение обязанностей как правило резко сокращает непроизводительную деятельность персонала службы ИТ, так что на самом деле очень редко оказывается необходимым увеличивать численность службы, чаще речь идет о сокращении.
Возможно построение службы поддержки с большим числом уровней. При этом предполагается, что роли последующих уровней исполняются более квалифицированными и опытными сотрудниками, чем предыдущих. Обращения к ним редки и возникают только в действительно важных, критичных для организации случаях.
Еще одна группа ролей – внешние поставщики сервисов.
Порядок взаимодействия с ними определяется в соответствии с сервисными контрактами.
Последняя роль – это конечный пользователь сервиса ИТ.
Данную роль можно специально не выделять, поскольку эта роль изначально подразумевается. Тем не менее, лучше еще раз подчеркнуть, что конечный пользователь на самом деле является активным участником процесса поддержки и имеет не только определенные права, но и обязанности.
1.2 ПРИНЦИПЫ АРХИТЕКТУРЫ «КЛИЕНТ – СЕРВЕР»
Так как вся структура блока построена на клиент-серверных связях, а создание резервной системы предполагает его постоянную связь с основным блоком посредством подобной коммуникации, разумно будет рассмотреть некоторые аспекты организации такого рода отношений.
Клиент-сервер – это модель вычислений, в которой нагрузка по обработке запросов распределяется между компьютером-клиентом и компьютером-сервером, совместно использующим информацию с помощью сети.
Архитектура «клиент-сервер» является актуальной на сегодняшний день, прежде всего потому, что обеспечивает простое и относительно дешевое подключение персональных компьютеров (ПК) к серверам, обеспечивая тем самым оптимальное соотношение цены и производительности. Суть идеи «клиент-сервер» заключается в повышении мощности распределенной информационной системы (РИС) за счет суммирования вычислительных ресурсов многих компьютеров, а не за счет повышения производительности одного компьютера. Реальное распространение архитектура «клиент-сервер» получила благодаря внедрению в практику концепции открытых систем. В основе этой концепции лежит идея упрощения комплексирования вычислительных систем в локальных сетях за счет международной и национальной стандартизации аппаратных и программных интерфейсов.
Наиболее важными свойствами открытых систем являются свойства мобильности и интероперабельности.
Мобильность – возможность относительно простого и быстрого переноса программной системы с одной платформы на другую.
Интероперабельность – возможность упрощения комплексирования систем на основе использования готовых компонентов со стандартными интерфейсами.
Пользователи могут постепенно заменять компоненты системы на более совершенные, не утрачивая её работоспособности. Интероперабельная форма архитектуры «клиент-сервер» – это разделение вычислительной нагрузки между двумя отдельными процессами:клиентом и сервером.
Система разбивается на две части, которые могут выполняться в разных узлах сети, клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто над- сетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части.
1.3 ОБЗОР АНАЛОГОВ
В [2] приводится краткий обзор систем для автоматизации работы служб поддержки, а также приводятся некоторые вопросы, на которые стоит отсеивать перед тем, как выбирать систему из готовых коммерческих решений. Большой список систем типа Help Desk приведен в [3].В любом случае наиболее удобной системой для уже существующей компании будет система, созданная внутри компании, удовлетворяющая ее нуждам и наиболее полно соответствующая структуре компании. Это будет одним из достоинств разрабатываемой системы.
Рассмотрим возможности некоторых коммерческих систем.
ANDesk Service Desk (ранее Touchpaper IT Business Management Suite) – коммерческий программный комплекс с закрытым кодом, предназначенный для автоматизации работы службы технической поддержки в соответствии с рекомендациями ITIL/ITSM.LANDesk Service Desk реализован на базе технологии Microsoft .NET
Framework и построен по архитектуре клиент/сервер. Серверные модули функционируют под управлением операционной системы Windows 2008 Server, Windows 2003 Server или Windows 2000 Server. В качестве СУБД поддерживаются Microsoft SQL Server или Oracle. LANDesk Service Desk поддерживает четыре типа консолей пользователя. Полнофункциональная консоль работает под управлением операционной системы Windows 2000, Windows XP или Windows Vista или Windows 7. Данная консоль предназначена для выполнения всех операций по настройке и администрированию системы и для работы сотрудников службы технической поддержки. Web-консоль функционирует под управлением Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator и Safari. Данный тип консоли предназначен как для работы сотрудников службы технической поддержки, так и для работы конечных пользователей по медленным каналам связи. Мобильная Web-консоль функционирует на карманных персональных компьютерах под управлением браузеров, поддерживающих HTML 4. Консоль WebDesk предназначена для работы сотрудников технической поддержки и реализована на базе Ruby.
Пока все. Рекомендую дополнить более широким спектром аналогичных коммерческих систем.
msbro.ru
До того как появилась служба поддержки, жизнь была гораздо проще. Один ИТ-специалист обслуживал около сотни сотрудников, он был доступен по телефону, электронной почте, в чате и просто ходил по офису. Времена меняются, компании растут, технологии усложняются, поэтому приходится двигаться дальше. На смену знакомому ИТ-специалисту пришли безликие ИТ-отделы, до которых, как правило, очень сложно «достучаться». Случаются инциденты, приходят запросы, есть каталоги, но все, что нужно знать пользователю это: «Почему я не могу войти в свою почту?» и «Не могли бы вы исправить это побыстрее?» По мнению Стивена Манна, старшего аналитика Forrester, служба технической поддержки должна, с точки зрения пользователя, принять к сведению следующее:
1. Никогда не ставьте ИТ выше пользователей. Не используйте строгие процедуры, из-за которых вам приходится иметь дело только с вопросами, представленными в виде запросов в службу поддержки. Вместо этого используйте более доступные для пользователей способы связи. Вы должны поддерживать пользователей, а ИТ-процессы.
2. Внимательно слушайте пользователей. Недостаточно просто услышать слова клиента, нужно понять его интонацию, и, самое главное, оценить важность обращения. Даже если с вашей точки зрения у пользователя несущественная проблема, для него это очень важно, потому что, обращаясь за помощью, он теряет свое драгоценное рабочее время.
3. Реагируйте на проблемы пользователей. Никому не хочется слышать: «Мы не можем Вам помочь». Даже если вы не можете удовлетворить все потребности клиентов и исправить все их проблемы, всегда можно сделать что-то, чтобы помочь пользователям справиться с возникшими трудностями в работе с ИТ.
4. Думайте о потребностях пользователей. Не принимайте решения, исходя исключительно из интересов ИТ-отдела. Вы должны думать о том, как это решение повлияет на сотрудников компании. Если ИТ-системы дадут сбой, люди не смогут выполнять свою работу должным образом, а ведь они делают деньги для компании, из которых вы получаете свою зарплату. Так поставьте себя на их место.
5. Относитесь к пользователям по-человечески. Узнаете, кто они, как их зовут и в чем заключается их проблема. Не забывайте, что это – люди, а не запросы.
6. Расскажите пользователям о работе службе поддержки. Если бы пользователи знали проблемы, с которыми вам приходится иметь дело, они бы меньше жаловались на службу поддержки. Расскажите им, как работает ваша служба. У вас может быть лучшая ITSM система, но если пользователи не понимают, как она работает, они могут попросту запутаться, потерять терпение и разозлиться на вас.
7. Научитесь извиняться. Нужно уметь извиняться за ошибки ИТ-отдела, даже если виноваты не вы. Пользователю неважно из-за кого возникла проблема, ему нужен кто-то, кто возьмет на себя ответственность за допущенную ошибку и поможет ее исправить.
8. Цените обращения пользователей. Даже если они вам не нравятся, но, в конечном счете, эти жалобы могут вам помочь. Когда из-за вируса на рабочей машине теряются данные, виноват не пользователь, загрузивший что-то из Интернета, а служба ИТ-безопасности, которая не выполнила свою работу должным образом.
9. Организуйте регулярную обратную связь. Поощряйте и приветствуйте предложения пользователей по улучшению работы службы поддержки. Это поможет вам предотвратить вероятные проблемы с поддержкой и лучше понять своих клиентов.
10. Обеспечьте открытость работы службы поддержки. Клиенты должны знать, какие работы по улучшению предоставления ИТ-услуг были проделаны и ведутся в настоящее время. Нужно информировать пользователей о потенциальных проблемах или предстоящих простоях. Они должны знать, когда планируется техническое обслуживание ИТ-систем, из-за которого у них не будет доступа к корпоративным сетям или услугам.
11. Поддерживайте всех сотрудников компании. Вы должны понимать, что не все работают в офисе, есть сотрудники, которые работают удаленно. Им нельзя сказать: «Мы решим проблему, когда Вы будете в офисе». Они так же важны для компании, как и сотрудники, которые работают в офисе, и их проблемы не менее критичны.
12. Не обращайтесь с пользователями как с детьми. ИТ-безопасность, конечно, важна, но вводить пароль администратора, чтобы запустить MS Office – это уж слишком. Много лишнего рабочего времени теряется из-за незначительных проблем, которые быстро и эффективно могли бы устранить сами пользователи, если бы имели соответствующие права.
Кто-то скажет, что все вышеперечисленное очевидно. Если так, возможно, вашим пользователям повезло. Однако то, что вы об этом знаете, не обязательно означает, что вы осуществляете это на практике. Как сказал Гете: «Недостаточно только получить знания; надо найти им приложение. Недостаточно только желать; надо делать».
По материалам blogs.forrester.com
Дополнительные материалы
smartsourcing.ru
Первым делом конечно необходимо знать на сколько хорошо работают сотрудники технической поддержки. Зачем? Все очень просто, ведь это те самые люди которые являются «лицом» вашей компании. Именно с ними в первую очередь общаются люди, которые несут вам деньги. Именно от их компетенции и их работы, в большинстве случаев, зависят хорошие или плохие будут отзывы о вашей компании в интернете. Качество технической поддержки может сыграть решающую роль для ваших будущих клиентов, которым порекомендуют те, кто уже имел опыт общения с вашей компанией.Как определить, на сколько все плохо?
Для начала необходимо определить критерии, по которым мы будем судить о том, как должна работать техническая поддержка. Это выяснить, естественно, не составит большого труда. Большинство компаний определяют стандарты обслуживания клиентов. Это важно, так-как в большинстве случаев сами клиенты доплачивают за качественный сервис той или иной компании, за частую не взерая даже на то, что цена его несколько выше чем у конкурента. Это утверждение легко доказуемо, так-как мы сами повседневно сталкиваемся с сферой обслуживания, например приходя в продуктовые магазины, покупая одежду или бытовую технику. Мы сами, будучи клиентами выбираем места, где нам нравится совершать покупки. Нам может нравится то, как представлен товар в торговом зале, где светло и чисто, а также где приветливые продавцы дадут компетентную консультацию, где доставят крупногабаритный товар в день покупки и т.д. Поэтому я, как клиент хостинговой компании, с одной стороны, выставляю ряд важных требований и критерий к службе которая должна осуществлять техническую поддержку, к примеру, моих интернет-проектов. С другой стороны я, как руководитель этой самой службы, должен сделать так, чтобы мои сотрудники не только соответствовали этим критериям, но также превосходили все ожидания клиента.
Итак, что я хочу видеть как клиент:
1. Телефон. Позвонив по телефону своему провайдеру услуг, я хочу чтобы трубку взяли уже в течение 30 секунд, а предельный максимум который я готов ждать — это 1 минута. Согласитесь, сильно раздражает, когда приходится висеть на телефоне по 20 минут слушая ужасную музыку и рассказы про то, как им важен мой звонок. Режим работы определенно должен быть 24 часа в сутки 7 дней в неделю. Это нормальное желание клиента, так-как проблемы у меня могут возникнуть не только будним днем, а также и в воскресенье. Более того, я хочу получить грамотные и вежливые ответы на свои вопросы, а не общие фразы.
2. Тикет-система. Хочу чтобы она тоже присутствовала. На самом деле я вообще отношусь с опаской к сервисам, которые мне предлагают общаться с ТП через недобитый пережиток 90-х, как например ICQ. Это показатель не зрелости компании в плане сервиса вообще, так-как скорее всего работ по улучшению качества обслуживания клиентов скорее всего в ней не ведется, ниже объясню почему. Мои сообщения в техническую поддержку должны обрабатываться в течение 10 минут, т. е. Я как клиент должен иметь информацию хотя бы о том, что моей проблемой занимаются. В течение 20 минут, я должен получить краткий доклад о том, что уже сделано по моему сообщению и какое время приблизительно потребуется для решения озвученной мной проблемы.
3. Я хочу что бы сотрудники ТП (компании) были честны со мной. Т.е если проблема с работой сервиса произошла по их вине, они в этом честно сознавались и не делали из меня дурака. Я все равно правду узнаю, но заработать мое доверие заново, этой компании будет уже очень тяжело.
4. Техническая поддержка должна быть бесплатна. Да-да. Именно бесплатна. Почему я должен платить дополнительно? Я уже заплатил, к примеру, за аренду нескольких серверов, а также за их не прерывную работу. Не путать с услугами администрирования этих серверов — эти должны быть в априори платными.
Для начала, я думаю хватит. Конечно, желания клиента могут быть вообще безграничны, но как говорится, «с чего-то надо начинать», и мы приступаем к аудиту.
Обычно процесс аудита занимает приблизительно от 2-х недель до месяца. За это время вы получаете практически самую полную картинку происходящего в отделе ТП. Вам придется много времени провезти в наблюдениях. Поэтому начнем с первого критерия по порядку.
Телефонные звонки. Каждый звонок в техническую поддержку должен логироваться, а также обязательно должна везтись запись разговоров. По сути вам нужна информация о дате звонка, времени звонка, времени начала записи разговора и конечно запись самого диалога. Путем несложных манипуляций в Exсel или Calc вы сможете получить очень важную статистическую информацию, которая сильно поможет вам в улучшении KPI показателей по телефонным звонкам в будущем. Запись разговоров, даст вам отличную почву для развития и обучения персонала.
Тикет-система. Придется не только читать то, что пишут сотрудники ТП, отвечая на вопросы клиентов, но также следить за временными промежутками и интервалами. Я думаю не надо объяснять то, что все действия в тикет-системе должны логироваться. Здесь необходимо вычленить информацию о времени когда был получен тикет, времени когда был первый ответ, времени начала выполнения тикета, времени подачи запроса клиенту о выполнении задания по тексту тикета, а также ФИО сотрудника который выполнял данный тикет. Если данные вещи не реализованы в тикет-системе, то их непременно надо реализовать. Это очень важная статистическая информация, которая даст вам представление о скорости обработки сообщений клиентов, а также поможет оценить скорости работы сотрудников вашей компании, которые задействованы в решении проблем возникающих у клиентов в процессе использования ими ваших услуг. Поэтому для этих целей совсем не подходят ICQ, Skype и прочие чатеки.
Честность ответов. Информацию кропотливо придется собирать из конфликтных тикетов и звонков. После чего объяснять нерадивым сотрудникам (естественно которые подозреваются во лжи) политику «партии». Убедите персонал в том, что лучше всего открыто признаться клиентам в собственных косяках и выплатить предусмотренные договором компенсации, чем поиметь в рунете ярлык компании которая обманывает своих клиентов.
Как добиться нужных результатов?
Мой многолетний опыт не просто подсказывает, а громко орет во всю глотку о том, что любое изменение в требованиях к персоналу влечет за собой массовое и ожесточенное сопротивление со стороны сотрудников к которым данные требования предъявляется. Хорошо если вы давно работаете в одной связке с этими людьми и вдруг начальство с небес спускает на вас подобные изменения. В таком случае у вас всегда есть шанс пообщаться с негласными лидерами вашего коллектива и вы сможете найти в их лице союзников, которые помогут вам реализовать эти планы. Но что делать если вас только-что назначили на место руководителя? Вы некого не знаете, вас никто не знает, более того вам не будет никто помогать в реализации целей которые либо вы сами, либо перед вами поставили. Второй вариант обычно самый распространенный. Самой главной причиной плохих результатов является плохо замотивированный персонал от которых этот самый результат зависит. Поэтому лучшим лекарством всех времен и народов является грамотно построенная…
Система мотивации персонала
Не думаю, что открою великую тайну если скажу, что мотивация должна быть направлена на достижение конкретных целей путем выполнения определенных задач. Про систему мотивации вообще-то холиваров достаточно много, даже на хабре иногда происходят ожесточенные баталии в комментариях по этому поводу, свое же ИМХО я постараюсь описать поподробнее.
Итак, материальная мотивация:
Определенно эта штука может быть завязана либо на личные достижения результатов по KPI которые мы себе наметили, либо на коллективное достижение KPI. Лично я в своей работе обычно использую некий гибрид коллективной и личной. Т.е создаю некий рейтинг, который обновляю еженедельно, ежедневно, ежечасно. В рейтинге должна прослеживаться определенная зависимость личных результатов и денежной премии. Эту информацию должны видеть все, это прибавит соревновательного духа в ваш коллектив. Также в этом рейтинге должны присутствовать общие KPI показатели отдела при достижении которых всем сотрудникам выплачивается дополнительная премия. Т.е. достиг отдел среднего показателя за месяц, к примеру, 30 секунд на взятие трубки телефона, всем начислена премия и т. д. Также лучше всего проработать оценки от клиентов за хорошие и плохие комментарии. Т.е дать возможность клиентам ставить плюсы и минусы за качественные и не качественные ответы. Эти оценки также можно использовать в системе премирования.
Не материальная мотивация:
Она также обязательно должна существовать. ДМС, обеды, корпаративы — это конечно все хорошо. Но нас-то интересует достижение определенных результатов. Поэтому можно разыграть между сотрудниками по итогам квартала или года пару Айфонов, ноутбуков, походов в кино или в ресторан и т. д. Также элементом не материальной мотивации может служить и обучение персонала, которое повышает их в профессиональном плане.
Обучение сотрудников
Не надо обучать сотрудников ради обучения. Каждое ваше действие должно приводить к определенным результатам. Вы можете сколько угодно говорить сотруднику, как он должен выполнять свою работу — он вам никогда не поверит, более того вы его будете просто раздражать. Здесь вам придется сесть за рабочее место сотрудника и на собственном примере показать, как выполняются нормативы, которые вы от них требуете.
Я сторонник того, что разный уровень квалификации сотрудников должен оплачиваться по разному. Поэтому скорее всего вам придется ввести категорийность сотрудников. В зависимости от категории сотрудникам начисляется разная окладная часть их зарплаты. Отличатся она может не на много, но тем не менее это может поселить в сотруднике желание развивать себя в профессиональном плане. Категории сотрудников можно выставлять в зависимости от результатов ежеквартального тестирования.
Заключение
Здесь важно понимать, что не все сотрудники захотят играть по вашим правилам. Не бойтесь избавляться от таких людей, они вам потом поставят палки в колеса. Один такой не согласный, может с легкостью намутить воду в коллективе таким образом, что в итоге вся ваша задумка сорвется. Вычислить таких людей иногда бывает сложно, но можно. Достаточно просто чаще общаться с персоналом. Они сами вам расскажут, что им нравится, а что нет.
Конечно это не все приемы достижения нужных результатов работы. Это всего лишь личный опыт, который возможно кому-нибудь поможет, а может и натолкнет на новые идеи. Хотелось бы обсудить данные приемы с хабрасообществом.
habrahabr.ru
