Когда закончено планирование новой структурной еденицы - службы поддержки пользователей, а оно обычно (для среднестатистической организации) заканчивается на определении ответственного, который собственно и станет ее организовывать.
И вот когда создана примерная модель функционирования службы, оказывается, что все как-то не так, как это виделось в начале проекта (в лучшем случае). Вот здесь и наступает момент, когда нужно наконец-то серьезно взяться за планирование, отложить сроки, молить руководство о дополнительных ресурсах, стоять на своем, кидаться на спину и сучить ногами, выбивая дополнительные средства.
Проблема в голове. А вернее в тех неправильных представлениях, которые, собственно, в этой голове и находятся. В момент первоначального планирования, служба поддержки пользователей, видится неким колл-центром, который маршрутизирует звонки и решает простые вопросы, типа "куда нужно кликнуть, чтоб было счастье".Но, внедри Вы такую модель, и через месяц ощутите, что нужно начинать планировать вновь.
Итак, суть - служба поддержки пользователей - это в первую очередь персонал, который там работает, те люди, которые изо дня в день занимаются не самой интересной, но крайне важной в масштабах всей службы работой. И кого туда набирать - решать Вам.
По моему мнению, выбор очевиден - необходимо набирать максимально квалифицированный персонал. Т.е. данная позиция ни в коем случае не должна быть начальной в масштабах отдела, управления, службы. Если у Вас есть хелп-деск, но единственная его работа в перераспределении поступивших заявок, их эскалация и минимальный контроль за ними, плюс решение мелких проблем - то Вы находитесь на тупиковой ветви развития. Все эти функции уже довольно давно умеют делать автоматизированные системы хелп-деск. Сами же специалисты хелп-деск должны владеть максимально возможным количеством технологий, которые внедрены в организации, и прав доступа для работы с ними. Желательно, чтобы на период организации службы поддержки пользователей, персонал туда был набран из числа уже работающих сотрудников.
Вполне естественно, что бонусы для таких позиций должны быть соответствующими.
Теперь поясню, допустим в вашей организации успешно внедрены и ежедневно используются 6-7 ключевых технологий, но абсолютно несхожих из разных областей. Пусть для примера это будут 1С - в нескольких конфигурациях, и с количеством разных баз от 25 до 50, корпоративный портал, развернутый на SharePoint со всеми рюшечками, которые были прикручены, несколько интернет-ресурсов, какая-нибудь ERP-система, а если не повезет то несколько, и это не беря в расчет базовых сервисов, локальной сети, домена\дерева доменов\леса ActiveDirectory, офисной техники, предоставления интернета, без которого никуда, тучи специфического софта, которым пользуется только два сотрудника, и который вы всем отделом устанавливали в течение недели, и то с костылями. Список сервисов можно составлять долго, а главное то, что специалист по поддержке пользователей должен обо всем этом знать, иметь представление. Довольно объемно. И одному человеку знать это все досконально не нужно, в рамках одной специальности.
Но поддержка пользователей это очень специальные люди, которые не всегда и во всем похожи на остальных. Дело в том, что все мы работает с железом, даже если нам иногда кажется, что у него есть душа. И это железо имеет одно очень нехорошее свойство - ломаться в самый неожиданный момент, а SLA таки да, - существует и от него не спрятаться не скрыться.
Конечно, у вас в компании есть много разных специалистов, каждый из них отвечает за какой-то свой сервис, работает с одной-двумя технологиями, но он. это специалист ни разу не железо, у него есть вполне себе такие осознаные потребности, нужности, интересы, ему нужно какое-то свободное время.
А разные поломки и косяки, только и ждут подходящего момента. и случаются, и вот тогда ведущий программист проекта, находясь у любимой бабушки на дне рождения диктует по телевону оператору поддержки пользователей свои учетки, расказывает куда тыкнуть, поправляет по телефону беду, и говорит себе, что как только окажется у компьютера, сразу подключится на работу и поменяет все пароли. И пусть даже так и будет, но на некоторое время, оператор имеет учетку ключевого сотрудника (замечу, что операторы обычно набираются из студентов, которым все по барабану, за то дешевые). И пусть даже ничего не случиться, но все же не красиво.
Придумать других ситуаций вагон не проблема, проблема уже озвучена - грамоная модель построения службы ИТ-поддержки.
Итак, мое виденье (фанфары)
1. составляем каталог услуг. смотрим и ужасаемся от числа ни за кем не закрепленных сервисов.
2. с боями составляем, согласованный с бизнесом, SLA.
3. создаем новую боевую еденицу из уже работающих сотрудников, желательно не junior, пусть даже от этого на определенное время пострадает бизнес. Важно, чобы они представляли разные отделы ИТ. Во время обкаточной работы они смогут создать начальную базу знаний, определят узкие места в работе службы.
4. в зависимости от предполагаемого количества специалистов поддержки пользователей, по желанию\жребию\на удачу назначаем руководителя вновь созданного подразделения, определяем обязанности.
5. Начинаем по одному выводить из работы по поддержке старых сотрудников и вводим в коллектив новых, сразу делая упор на комплексном обучении всем системам, в рамках администратора этих систем. Именно поэтому, на все позиции в поддержку пользователей, набираем не студентов, а системных администраторов со стажем, иначе не видать успеха. Настраиваемся на высокую цену таких специалистов и необходимость продалжительной работы по подбору.
6. Когда выучено достаточно технологий и так сказать получен некий кредит доверия - выделяем полноценные административные учетные данные необходимые для работы во всех системах. С одной стороны, это может показаться ударом по безопасности систем, ведь количество администрирующих возрастает. Здесь помогают административные меры и правило для поддержки - "работает не лезь!". Да им в принципе и так есть чем заняться:)
Вроде ничего сложного, но такая картина мира приходит только после продолжительного изучения работы уже существующих подразделений поддержки.
Все сказанное выше является сугубо моим личным мнением, применимым для компаний от средней до умеренно крупной, работающей с различными технологиями (ну т.е. для хостеров и провайдеров эти мои слова не представляют никакой роли, а только вред, их системы с "пожалуйста, подождите", "У вас вирусы, переустановите ОС", "мы все проверили у нас все нормально", "проблемы у сторонней организации" работают идеально, практически не дают сбоев и не поспоришь). Применено в организации с такими показателями - 70-100 заявок в день, 120-150 звонков, письменные обращения мимо всех и вся:), число сотрудников поддержки в смене - 2, процент закрытых заявок на первом уровне поддержки от 24 % до 36 % (месяц на месяц не приходится, смотря что сломается).
