support пользователь что это
Специалист техподдержки: Кто это и сколько зарабатывает
Специалист техподдержки работает в соответствующей службе или отделе, который занимается поиском и устранением пользовательских проблем по части программно-аппаратного обеспечения.
Для каждой конкретной организации отдел техподдержки формируется по-разному:
Отдел может как обслуживать клиентов извне (в этом случае он еще и выполняет функции колл-центра), так и быть частью организации, будучи включенным в IT-отдел. Это характерно для крупных предприятий и международных корпораций.
Пользователи обращаются в службу технической поддержки (ее еще называют «саппорт») не только с целью решить проблемы, но и для получения консультацию. Поэтому служба часто занимается еще и информационной поддержкой.
Векторы техподдержки
Можно выделить здесь три основных направления:
Порог вхождения в профессию специалиста техподдержки
На базовом уровне, когда работник отвечает только за прием телефонных звонков, нужны лишь начальные познание в информационных технологиях. Здесь важно быть уверенным пользователем персонального компьютера и грамотно использовать специализированное ПО.
И-за этого в техподдержку часто идут подрабатывать студенты и работать выпускники вузов. Между тем, из года в год все больше закрепляется требование к сотрудникам знать английский язык, чтобы умело давать подсказки, данные в англоязычных инструкциях и прочей технической документации.
Если у человека есть желание двигаться дальше – на следующий уровень – ему нужно наращивать свой багаж знаний – тут и системное администрирование UNIX-платформ, и программирование, и даже умение проводить мелкий ремонт устройств.
Чтобы начать работать специалистом технической поддержки второго уровня, необходим запас технических знаний (например часто в описаниях вакансий можно встретить требование опыта системного администратора Linux или Windows от года).
Должностные обязанности
Навыки специалиста техподдержки
Зарплата специалиста техподдержки
Данные на июнь 2020 года:
К сожалению, в IT заработные платы специалистов техподдержки остаются одними из самых низких, если вести речь про обслуживающий персонал. Между тем, даже «джуниоры» в этой профессии могут получать больше, чем не относящиеся к сфере информационных технологий.
Карьера специалиста технической поддержки
В саппорте, как и в программировании существуют три ступени компетенций:
Базовое отличие уровней между собой — сложность решаемых задач и ответственность за их решение.
Junior предполагает работу для начинающих и малоопытных специалистов, которые решают простые задачи – выставляют тикеты клиентам, следят за состоянием их выполнения, а также обрабатывают телефонные звонки.
Middle решает задачи серьезнее и часто выполняет административные функции.
Senior — это специалисты с опытом и квалификацией, они решают глобальные вопросы технической и информационной безопасности предприятий и управляют командами специалистом техподдержки.
Плюсы и минусы профессии
Плюсы
Минусы
В заключение стоит отметить, что техническая поддержка может оказываться как на платной, так и на бесплатной основах.
Поддержка пользователей, или экстренная компьютерная помощь. Как это делается и сколько стоит
Восстановление работоспособности компьютеров на рабочих местах и решение проблем бизнес-пользователей в случае каких-либо инцидентов часто напоминает тушение пожаров – реакция на сбои и поломки должна быть как можно более оперативной. Без специальной службы здесь не обойтись. Но не так-то просто без цифр и примеров ответить на вопрос, стоит ли создавать собственный отдел или лучше обратиться к аутсорсеру. Я посчитал, во сколько может обойтись техподдержка для средних и крупных компаний.
За статью я взялся, потому что мне и моим коллегам из «Онланты» часто приходится разъяснять потенциальным заказчикам, как формируется стоимость техподдержки пользователей. Разговор об адекватном сравнении цен и организации работы ИТ-аутсорсера и собственной ИТ-службы остается актуальным, хотя услуга стандартная и хорошо известная.
«Поддержка пользователей» — самая что ни на есть типовая задача как для ИТ-служб предприятий, так и для ИТ-аутсорсинговых компаний. Здесь речь идет об обслуживании автоматизированного рабочего места (АРМ) каждого сотрудника, в которое кроме компьютера могут входить также принтер, сканер, другая периферия.
Читатели, которые хотят познакомиться с тем, как организуются процессы технической поддержки пользователей и какие специалисты задействованы в этих процессах, могут заглянуть под кат. Мы же перейдем к примерам расчета стоимости технической поддержки.
Источник
Чтобы понять структуру стоимости и методику подсчета итоговой цены, давайте разберемся, из каких элементов и процессов обычно состоит услуга техподдержки пользователей и какие специалисты ее реализуют. Пока нам не важно, собственная ли эта ИТ-служба или аутсорсинговая компания.
В сознании многих службу поддержки олицетворяет инженер (или несколько инженеров), который, как в поговорке, «и швец, и жнец, и на дуде игрец». В идеале он работает 24 часа в сутки, доступен по всем каналам связи и готов устранить любую проблему в срок менее получаса. А иначе — «простой по твоей вине»!
Для небольших компаний так оно и есть. Но если счет обслуживаемых рабочих мест идет на сотни, то один инженер точно не справится. Здесь за дело должна взяться команда специалистов, вооруженная специализированным ПО (ITSM) и задействующая ряд других составляющих сервисов, о которых пойдет речь ниже.
В общем виде схема работы выглядит следующим образом:
Кто есть кто на этой схеме?
Служба Service Desk – это единое окно «входа» обращений пользователей. Специалисты Service Desk в режиме 24х7 принимают все поступающие обращения по почте, телефону или через веб-интерфейс и фиксируют все заявки в ITSM-системах (IT Service Management, управление ИТ-услугами).
ITSM-системы позволяют следить за этапами работ и придерживаться сроков, прописанных в договоре или регламенте. Специалисты Service Desk – «первая помощь» при неполадках в работе АРМа. Они должны понять причину проблемы со слов пользователя или диагностировать её, подключившись удаленно к АРМу.
В ответ на обращение пользователя специалист Service Desk либо дает сотруднику рекомендации, либо удаленно устраняет проблему, используя накопленную базу знаний (перечень типовых обращений).
Если специалист Service Desk не может решить проблему, то он перенаправляет заявку на следующую линию «обороны» – инженерам технической поддержки второй линии.
Инженеры второй линии поддержки, или аникейщики, определяют дальнейшие шаги: решить обращение удаленно или выехать на место.
Служба Service Desk и вторая линия составляют «ядро» процесса технической поддержки. Процесс может показаться громоздким, но когда он отработан, то это конвейер, функционирующий согласно регламентам, которые обеспечивают эффективность оказания услуги и соблюдение SLA.
Какие еще специалисты и ресурсы задействованы в процессах оказания услуги «Поддержка пользователей»?
Источник
Руководитель проекта
Если поддержкой ИТ занимается аутсорсинговая компания, то каждый заказчик взаимодействует с выделенным менеджером — руководителем проекта, который контролирует работу служб, готовит ежемесячные отчеты для заказчика и фактически в режиме 24х7 готов разруливать возникающие вопросы взаимодействия ИТ-специалистов и пользователей. В собственной ИТ-службе такая роль тоже есть, только она может называться иначе.
Специалист службы качества
Этот специалист выполняет следующие функции:
Сервис-партнеры
Если нужно поддерживать ИТ заказчика в регионах, а у аутсорсера там нет филиалов, то он обращается к сервис-партнерам — небольшим ИТ-компаниям на местах, с которыми аутсорсер заключает договор на тех же условиях, что и с заказчиком, а иногда и на более «жестких». Собственная ИТ-служба при организации централизованной поддержки пользователей также может работать с сервис-партнерами в регионах, чтобы не держать в штате не всегда загруженных специалистов. В этом случае придется самостоятельно «строить» партнеров: налаживать процессы взаимодействия и документооборот (договоры, акты, заявки…), производить расчеты, решать возникающие по ходу взаимодействия вопросы и проблемы.
Заказ материалов, доставка и хранение
Для техподдержки требуется подменная техника на время ремонта сломанной, запчасти и расходные материалы, которые нужно быстро доставлять на места, в том числе в регионы. Для этого нужна грамотно организованная логистика и складские помещения вблизи объектов обслуживания (относится и к собственной ИТ-службе, и к аутсорсинговой компании).
Источник
Я перечислил основные составляющие услуги «Поддержка пользователей». Немаленький список, который должен работать как единый слаженный механизм. Эти составляющие, соответственно, входят и в расчет стоимости поддержки.
Расчет стоимости поддержки пользователей
Предлагаем расчет и сравнение стоимости услуг «Поддержка пользователей» собственной ИТ-службой и при аутсорсинге в четырех вариантах: при количестве пользователей 200 человек, а затем при увеличении этого количества до 400, 1000 и 3000 пользователей.
Ниже приведена таблица результатов типовых расчетов, которая показывает, сколько придется потратить на поддержку при разном количестве пользователей.
В таблице приводятся практические расчеты стоимости, подготовленные в рамках технико-экономических обоснований для ряда заказчиков. В стоимость аутсорсинга включены также налоги и накладные расходы компании.
Отметим, что в варианте с собственной ИТ-службой заказчик при увеличении объемов вынужден брать в штат дополнительных специалистов, чтобы укладываться во внутренний SLA. А аутсорсинговая компания имеет возможность увеличить долю (%) занятости специалистов необходимой квалификации.
Источник
При сравнении своей ИТ-службы и аутсорсинга при объеме до 200 АРМов стоимость поддержки будет выгоднее для собственной ИТ-службы. Но при увеличении штата сотрудников более 400 АРМов стоимость услуг аутсорсинговой компании становится привлекательнее, чем своей ИТ-службы. При дальнейшем увеличении рабочих мест аутсорсинг наращивает преимущество благодаря нелинейному увеличению задействованных специалистов по поддержке АРМов и отлаженных процессов по поддержке.
Важные финансовые и нефинансовые аспекты
Выше мы сравнили стоимость поддержки пользователей для аутсорсинговой модели и силами своей ИТ-службы. При выборе своего варианта реализации услуги вот еще что стоит учесть.
Пример эластичности аутсорсинга
Компания «Айс Крим Аквамарин» продает мороженое. Представим, что в каждой палатке установлен один АРМ, один принтер, касса и камера, и таких палаток в Москве около 100 шт. Пусть SLA будет «лайтовым»: решение инцидента в течение 8 часов в режиме 8х5.
В таких условиях и аутсорсеру, и своей ИТ-службе потребуется по меньшей мере два сотрудника. Но когда для палатки с мороженым наступит «мертвый сезон» (осень-зима-весна) и продажи мороженого упадут в разы, компания решит сократить количество мобильных палаток до 50.
Теперь один специалист собственной ИТ-службы станет недозагруженным и заказчику в течение примерно полугода придется платить зарплату впустую (при средней з/п с учетом налогов это 80 тыс. х 6 мес. = 0,5 млн в течение сложного для бизнеса периода затишья. В это же время аутсорсинговая компания задействует инженера с малой загрузкой на других проектах, а заказчик будет платить лишь за поддержку оставшихся в работе АРМов.
Если добавить эти 43%, то, скорее всего, цены будут сопоставимы.
Помимо налогов в список затрат на собственную ИТ-службу нелишним будет включить оплату рекрутинга, то есть расходы на поиск работников, размещение вакансий, собеседования и т.д.
* Цифры приведены для случая, когда суммы выплат сотрудникам не превышают предельную базу для начисления страховых взносов, устанавливаемую Правительством РФ (для наших расчетов это, как правило, так).
Пример из практики
Буквально несколько месяцев назад ко мне поступил запрос рассчитать стоимость поддержки рабочих мест пользователей. Объемы были не очень большие – в районе 200 пользователей плюс серверное и сетевое оборудование. Расчет я красиво обернул в коммерческое предложение и направил заказчику.
Через два дня заказчик сообщил, что ему понравился состав нашей команды и принципы работы, а вот со стоимостью услуг он совершенно не согласен. Оказалось, что заказчик рассуждал достаточно банально: «Я плачу за двух специалистов порядка 80 тысяч рублей в месяц – по 40 каждому. А ваше предложение содержит цифру почти вдвое выше».
Мы посчитали и добавили к стоимости специалистов заказчика все налоги, и цифры оказались сопоставимы. Заказчик оценил, что мы можем при необходимости выделять инженера нужной специализации, который бы решал узкопрофильные задачи, а также заменял отсутствующих специалистов (в отпуске, на больничном), и все-таки выбрал аутсорсинг.
Источник
В целом ряде случаев от штатных ИТ-сотрудников бывает «физически» нелегко добиться приемлемого уровня SLA. Например, небольшие и средние компании, как правило, берут ИТ-специалиста на фиксированную оплату. Он – «единица», которая должна поддерживать в рабочем состоянии технику. С таким сотрудником не подписывают SLA на выполнение работ – он просто делает работу по мере возможности.
Источник
Пример из практики
Аутсорсинговая компания платит штрафы за нарушение SLA. Точнее, сумма счета снижается на размер штрафа. В нашей практике такое случается редко, и все же никто от этого не застрахован.
Однажды мы не выполнили SLA из-за того, что региональный партнер в «неподходящий момент» решил отказаться работать по договору. Нам пришлось оперативно (в течение суток) искать нового партнера. Но за время поиска случился инцидент – не работал один ПК пользователя. Наш инженер приехал, выполнил необходимую работу и восстановил АРМ, но уже с некоторым нарушением SLA. В конце месяца, когда выделенный заказчику менеджер нашей компании писал отчет, он сделал перерасчет в пользу заказчика из-за этого нарушения SLA.
При выборе аутсорсинговой схемы заказчик снимает с себя проблемы, связанные с отсутствием специалистов на время отпусков и больничных.
Источник
Пример из практики
Небольшая туристическая компания имела в своем штате администратора, который верой и правдой приходил обслуживать ИТ-инфраструктуру. Никто не задумывался о том, что один администратор в офисе – это риск оказаться в ситуации, когда инфраструктура не работает из-за его неожиданного увольнения, болезни или даже планового отпуска. Так и произошло. На неделе, когда администратор попал в больницу, в компании случился сбой на АТС и вышло из строя несколько АРМов. К тому моменту, когда администратору нашли замену, убытки компании от простоя насчитывали сотни тысяч рублей.
Еще один момент — у аутсорсинговой компании есть накопившиеся компетенции в виде базы знаний, сокращающие время на решение некоторых инцидентов.
Какие еще вопросы волнуют компании, когда они рассматривают вариант аутсорсинга
Возможное повышение стоимости услуг. В рамках действующего контракта повысить цену сложно, а вот при подписании нового договора — возможно. Снизить такую вероятность можно, выбирая исполнителя на основе конкурсных процедур, условия которых в числе прочих параметров учитывают и стоимость услуг.
Переходный период. Поставщику услуги нужно освоиться с ИТ-инфраструктурой заказчика, отладить процессы – на это может уйти от нескольких недель до нескольких месяцев. Срок зависит от опыта аутсорсинговой компании и от размера компании-заказчика. Во избежание спорных ситуаций прописывайте адекватный переходный период в договоре и по возможности предоставьте аутсорсеру максимально полную информацию и средства для оказания услуг (базу знаний, перечень и состав поддерживаемого оборудования и т.д.).
Вопросы информационной безопасности. Чтобы гарантировать заказчикам соблюдение требований информационной безопасности при оказании ИТ-услуг, сервис-провайдер ежегодно проходит сертификацию на соответствие международному стандарту ISO 27001. И сервис-провайдер должен быть готов по требованию ознакомить заказчика с принятой у него политикой информационной безопасности.
Вот такая получается картина.
Считайте, анализируйте, выбирайте. Как организовывать поддержку пользователей – решать вам. И меньше вам «пожаров» в ИТ-инфраструктуре!
Источник
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»
С чего все начинается
что есть служба поддержки и для чего она нужна?
Хотя вопрос звучит просто, но ответ на него дать не так то и просто. И причиной этому является далеко не сложность этой сферы деятельность. Причина в том, что тут присутствует маленькая особенность — «служба поддержки», равно как и «поддержка» вообще, не являются универсальными понятиями. Их значения очень сильно зависят от конкретной ситуации, которую мы рассматриваем. И чтобы это показать, я приведу один, очень схематичный пример.
Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:
Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.
Давайте попробуем разобраться несколько подробнее.
Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает. Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления бизнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?
Возьмем другой пример, чуть более приближенный к нашей тематике. Итак, у нас есть компания, которая использует некую «стандартную» конфигурацию учетной системы (неважно какой). Поскольку конфигурация стандартная, то компания не имеет в штате разработчиков для внесения исправлений и изменений в используемую систему. Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.
На этом моменте давайте остановимся чуть подробнее. Итак, у нас это чистая компания – потребитель. То есть сама компания не производит продукт, которым пользуется, а покупает его на стороне. В этом случае, если нет своей «службы поддержки», то конечные пользователи сами пытаются решать возникающие проблемы. В результате теряется много времени, нервов, начинаются чудеса с данными и т.д. В общем, все как всегда.
И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.
Едем дальше, а как же оценивать работу сотрудников этой службы? Скоростью решения проблемы? Скорее нет, чем да, поскольку они не могут, да и не должны лезть вовнутрь конфигурации или платформы учетной системы. Поэтому немного утрируем, и получается, что их задачи тоже вполне очевидны — удостовериться, что:
Итак, на текущий момент мы, в общем, двигаемся в верном направлении. Примерно об этом нам говорят книжки из ITIL, множество прочитанных статей, да и логика тоже это подтверждает. И на самом деле, тут откровений нет. Но они будут дальше.
Итак, у нашего руководителя все получилось хорошо, все счастливы, и уже компания – производитель этой самой учетной системы, пригласила его/ее наладить их «службу поддержки». И вот тут начинаются чудеса. На новом месте он/она вновь задается теми же самыми вопросами, что и ранее:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании. И получается, что при отсутствии «службы поддержки», именно разработчики вынуждены отвлекаться от своей основной работы и заниматься пустяковыми (по их мнению) проблемами, в то время, когда «вселенная нуждается в идеальной учетной системе». 
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решать большинство проблем. Понимаете разницу?
Получается, что при похожем названии, и вроде бы, как одной функции, у отделов совершенно разные требования к их работе. То есть мы имеем два полюса, два чистых и совершенно противоположных подхода к организации работы «службы поддержки». К большему сожалению, эту разницу мало кто видит, а из тех, кто видит, ее часто игнорируют.
Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.
Резюмируя, мы получаем следующую картину:
Очевидно, что в реальной жизни нам приходится использовать некий компромисс и смешение этих двух противоположностей, но, тем не менее, зная эти «ингредиенты» руководитель уже сможет подготовить свой собственный рецепт, наиболее полно соответствующий условиям конкретной организации, выстроить соответствующие процессы и подготовить SLA, которые будет отвечать интересам всех заинтересованных сторон (включая отдел поддержки/сопровождения).
К чему обычно приходим
Ну и в качестве бонуса, небольшой список неудачных подходов к организации работы службы поддержки.
С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкретному инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.
Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.
Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.
Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.
На этом у меня все. Ваши комментарии и аргументированные замечания – всячески приветствуются.
Всем удачи и успехов.
1. «Мерзлый» песик — отсюда
2. «Суровый» пес отсюда
3. Call-центр: отсюда
4. Автобусный сервис отсюда