Организация эффективной техподдержки 1С внутри компании

Организация эффективной техподдержки 1С внутри компании

Как качество работы технической поддержки измеряют в мире, и почему этот способ меня не устраивал

Проблема, с которой я столкнулся, не нова. Тридцать лет назад англичане задались таким же вопросом — “а чем, собственно, занимаются айтишники в госучреждениях, и нужно ли их столько?”. Англичане подошли к этому вопросу фундаментально и провели исследование, итогом которого стали 30 (тридцать) томов рекомендаций по организации эффективной работы ИТ-службы и методам контроля ее работы.

Со временем, эти рекомендации уменьшились до 5 томов и получили мировую известность под названием “методология ITIL”. Вся суть методологии сводится к закреплению за специалистами узкой зоны ответственности: диспетчеры регистрируют заявки, есть первая, вторая, третья линия технической поддержки, есть менеджеры инцидентов, менеджеры проблем, менеджеры изменений, менеджеры конфигураций и так далее — список различных ролей можно продолжать.

Такая узкая нарезка на роли, с одной стороны, ограничивала задачи отдельного специалиста (а значит, упрощала его работу и повышала личную производительность), а с другой — делала невозможной работу ИТ-отдела без связывающей все роли системы учета, через которую одни специалисты как по конвейеру могли бы передавать задачу другим.

Именно необходимость использования учетной системы (которую англичане назвали гордым словом ServiceDesk) и помогает контролировать занятость специалистов и измерять различные метрики производительности всего ИТ-отдела в целом и отдельных сотрудников в частности.

У предложенной тридцать лет назад англичанами методики единственный недостаток — она нацеливает специалистов на выполнение своих рабочих процедур, а не на решение проблем клиента. Глобально, методика является процессно-ориентированной, а не клиентоориентированной, и недостаток предлагаемых в ней способов организации труда описывал еще Аркадий Райкин в своей миниатюре “кто сшил костюм?”.

К примеру, согласно методике ITIL, пользователь не может связываться со специалистами напрямую, а должен сначала пройти через диспетчера, который зарегистрирует его обращение в системе, передаст его специалисту и будет контролировать дальнейшее исполнение.

Такое усложнение содержит в себе разумное зерно — если регистрацию заявок переложить на самих технических специалистов, то часть обращений просто-напросто не будет зарегистрирована, потому что этот ритуал по большому счету не нужен ни пользователям, ни техническим специалистам.

В принципе, все недостатки методологии ITIL не являются таковыми, если у тебя достаточно денег, чтобы содержать штат диспетчеров, менеджеров и, непосредственно, специалистов технической поддержки, а также, если ты уверен, что твои пользователи от тебя никуда не денутся.

Но у меня небольшая ИТ-аутсорсинговая компания, и вся техническая поддержка — это 10 специалистов. Содержать выделенных диспетчеров для нас (не говоря уже о менеджерах) — это непозволительная роскошь. Кроме того, наши клиенты привыкли получать на свои вопросы незамедлительный и компетентный ответ.

Если бы я обязал наших пользователей при звонках в техподдержку смиренно ждать ответа диспетчера, чтобы тот сначала зарегистрировал заявку, а потом передал ее специалисту, то я мог бы потерять добрую половину клиентов уже через полгода. Поэтому единственное, что мне оставалось — это стимулировать специалистов технической поддержки самостоятельно вести учет всех без исключения поступающих к ним обращений, что я и попытался сделать:

Моя первая безрезультативная попытка что-то измерить, наводка

Тут стоит сказать, что в 2020 году в моей компании уже работала система учета задач технической поддержки (далее по тексту ServiceDesk). Правда использовалась она номинально — в ней автоматически регистрировались письменные обращения пользователей, и создавались регламентно-профилактические задачи, но получаемые по телефону заявки в систему попадали редко, особенно, если они решались в рамках одного звонка.

Кроме того, страдала и сама культура работы с системой — специалисты могли месяцами (а иногда и годами) не закрывать уже выполненные заявки, а об актуализации текущих статусов задач и вовсе не шло речи. В том виде, в котором система работала в 2020 году, что-либо измерить в ней просто не представлялось возможным.

Первое что приходило на ум в плане стимулирования специалистов регистрировать и закрывать заявки в ServiceDesk — это выплачивать специалистам премию за каждую зарегистрированную и закрытую заявку. Но такой подход, очевидно, скрыто мотивирует специалистов создавать как можно больше причин у пользователей для обращения в техническую поддержку, в то время как, куда правильнее стимулировать специалистов работать так, чтобы у пользователей не было причин для обращения в техническую поддержку.

По этой причине я решил сделать премиальный фонд фиксированной ежемесячной суммой, которая не зависит от количества заявок. Предполагалось, что фиксированная сумма будет делиться между всеми сотрудниками технической поддержки исходя из пропорции зарегистрированных и выполненных заявок каждым из специалистов.

То есть, если за месяц каждый специалист зарегистрировал и выполнил по одной заявке, то все специалисты делят премиальный фонд поровну. При этом предполагалось, что одна выполненная заявка будет равна двум зарегистрированным заявкам в рамках этих пропорций.

Первый премиальный фонд по заявкам я сделал символическим — 10 000 р./месяц. Чтобы парни не относились к этому как к какой-то системе премирования, которая определяет приоритеты в работе, я назвал данную систему «соцсоревнование» и в мае 2020 года разослал всем письмо следующего содержания:

“Парни, мы медленно, но верно движемся к разработке системы поощрения и мотивации.

Цель системы мотивации для компании – повышение внутренней эффективности. Цель системы мотивации для каждого из вас – получить возможность объективной оценки своего вклада в компанию и дать возможность зарабатывать вам больше, делая больше и делая качественней.
Понимаю, что оценивать объем проделанной работы в нашей сфере — это неблагодарная задача. По этой причине (дабы не наказывать невиновных и не награждать непричастных), для начала хочется объективно разобраться в текущей загрузке и провести аналитику по всем клиентам, стоящим по ним задачам, текущей удовлетворенности заказчиков и причин неравномерных объемов работ.

Для этих целей мы проводим небольшое “социалистическое” соревнование с призом в 10 000 р., который будет разделен между всеми участниками соревнования на основе следующих принципов: одна зарегистрированная заявка – 5 баллов, одна закрытая заявка – 10 баллов. Курс балла определяется как призовая сумма, деленная на сумму всех баллов по всем зарегистрированным и закрытым за месяц заявок. Например, если за месяц было закрыто 900 заявок и было зарегистрировано 200 заявок, то курс балла получается 1 рубль, стоимость одной зарегистрированной заявки — 5 рублей, а одной закрытой — 10 рублей.

Соответственно, в ваших интересах в июне месяце регистрировать (и закрывать) как можно больше заявок. Зашли в офис клиента, вам задали 3 вопроса, вы на них ответили – зарегистрировали 3 заявки, закрыли их и заработали в соцсоревновании 45 баллов, которые потом будут сконвертированы в рубли. Пожалуйста, регистрируйте любой писк пользователей – чтобы в дальнейшем мы смогли сделать целостную систему премирования, нам нужно видеть все возникающие сейчас задачи.”

Итогом первого месяца «соцсоревнования» стало… барабаннная дробь… ничего. В работе специалистов не поменялось ровным счетом ничего — парни не стали регистрировать больше заявок, выхватывать заявки друг у друга, биться за скорейшее закрытие заявок, чтобы сделать больше.

Все работали, как привыкли работать, а когда за заявки выдали пусть и смешные, но дополнительные деньги, ни у кого из парней не дернулась бровь, и не покатилась слеза умиления. Наверное, нормальный бизнесмен пришел бы в ярость от того, что подчиненные не оценили его барскую щедрость, но меня такое положение дел только раззадорило, и я решил наблюдать за дальнейшим поведением специалистов и постепенно повышать бюджет соцсоревнования.

Через 3 месяца бюджет поднялся до 15 000 р./месяц, еще через три — 20 000 р./месяц. Повышение бюджета все также не вызывало никакой реакции специалистов, и распределение премии из месяца в месяц было примерно одинаковым (реальные имена сотрудников тут и далее заменены по их просьбе):

Организация эффективной техподдержки 1С внутри компании
Таблица 1 (кликабельно). Расчет премии за работу с системой ServiceDesk в ноябре 2020 года.

Каждый месяц я делал рассылку с результатами «соцсоревнования», а парни получали небольшие премии за ведение заявок, говорили спасибо и убегали с премией в руке на обед в столовую. Если судить по размерам премий, то все работали примерно одинаково, но при этом в системе премирования учитывались только заявки пользователей, и не учитывались выполняемые сотрудниками регламентно-профилактические задачи. Наверное поэтому, спустя где-то 8 месяцев от начала «соцсоревнования» я получил письмо от одного из сотрудников следующего содержания:“А может разделить фонд на профилактики и обычные заявки, а то как-то уныло, никакой интриги?”

Интрига, нужна интрига! И тут

Остапа

меня понесло:

Результаты, что получилось и что не получилось на текущий момент

Благодаря системе премирования, за 4 года (уже практически за 5 лет) система учета заявок в моей компании стала более информативной — в ней стали регистрироваться все возникающие задачи, и большинство задач в системе стали закрываться своевременно. Сейчас в системе заявок в любой момент времени можно получить более-менее актуальную информацию о текущем статусе выполняемых задач.

Но главное — теперь можно более-менее объективно измерять качество наших услуг: сколько заявок сделали, сколько времени их делали, по каким сервисам были заявки, какая динамика со временем у наших услуг, какие затраты на поддержку каждого сервиса, кто у нас ударник труда и так далее. К примеру, можно сравнить результаты работы за два последних года:

2020 год2020 год
Устранено инцидентов32672535
Выполнено запросов на обслуживание14112373
Оказано консультаций113148
Выполнено регламентных задач41383940
Исправлено ошибок190340
Инцидентов устраненных с нарушением сроков569432
Запросов на обслуживание выполненных с нарушением сроков196200
Медианное время устранения инцидентов78 минут37 минут
Медианное время выполнения запросов на обслуживание61 минута43 минуты

Таблица 8. Сравнение результатов работы технической поддержки в 2020 и 2020 годах.

В предыдущем абзаце вы наверняка обратили внимание на использование оборота “более-менее”. Дело в том, что точность учета в системе заявок все еще оставляет желать лучшего. Так, из таблицы выше следует, что в 2020 году по сравнению с 2020 у нас количество инцидентов уменьшилось на 741, а запросов на обслуживание наоборот — выросло на 962.

Сейчас ищут техподдержку:  Как дозвониться до оператора Билайн

Причина такого изменения проста — заявки, приходящие по почте, у нас автоматически регистрируются как инцидентные. В 2020 году парни просто редко проверяли тип заявки при ее закрытии, а в 2020 стали делать это чаще, что и привело к такому перераспределению.

Такая же петрушка наблюдается и с определением категорий задач — не всегда специалисты техподдержки корректно связывают задачу с затрагиваемым ей сервисом. Если бы у нас в техподдержке были диспетчеры и менеджеры, то они бы отслеживали подобные ошибки в процессе работы, проводили разъяснительную работу, и точность нашего учета была бы выше.

Также, по отчетам выше, у нас просто гора заявок с нарушением сроков выполнения при том, что реальных нарушений сроков у нас единицы (ну ладно, ладно — десятки). Большинство же нарушений связано с расхождением особенностей формального учета задач и их реального исполнения. Например:

  1. Есть задачи, оперативное выполнение которых нанесет ущерба клиенту больше, чем пользы. К примеру, обнаружили что один из вентиляторов на сервере крутится плохо, но при этом сервер/диски не греются и причин бежать и судорожно менять вентилятор (останавливая работу компании) нет. Соответственно, заявка висит в ожидании удобного момента для проведения работ, а в системе заявок получается “висяк”.
  2. Не всегда специалисты ставят заявку на “удержание” (hold), когда задача выходит из нашей зоны ответственности. К примеру, получили жалобу на качество связи, провели диагностику — проблема у провайдера, передали ему обращение. В этот момент заявку можно/нужно ставить на “hold”, чтобы таймер остановился (поскольку сеть провайдера вне нашей зоны ответственности). В реальности же парни этого зачастую не делают, ожидая, что в скором времени провайдер все починит. Если же провайдер решает проблему долго, то получаем просрочку в нашей системе учета.
  3. Часть заявок все еще не закрывается вовремя, даже когда выполнена. Просто иногда такое случается — нужно было убежать с работы пораньше, сделал заявку и занялся другой задачей, забыл закрыть вовремя. Ну и некоторые специалисты (видимо, с сильно большой зарплатой), несмотря на все мои ухищрения, все еще работают с системой заявок постольку-поскольку.
  4. Пиковая нагрузка. Когда какая-то эпидемия выкашивает половину нашего коллектива, а у клиентов сотрудники наоборот пышут здоровьем, переполнены энергией и хотят именно сегодня разобраться с проблемами, до которых раньше у них не доходили руки. В такие дни не до соблюдения всех формальностей в ServiceDesk — успеть бы на звонки ответить.
  5. Часть заявок являются мини-проектами, на которые времени уходит больше, чем отводится для стандартных заявок. К примеру, клиент пишет, что собирается открыть новый офис, заявка автоматически регистрируется и остается “висеть” до банкета связанного с открытием офиса.
  6. Некоторые заявки по своей сути являются проблемами (в рамках терминологии ITIL). К примеру, когда база 1С у одного единственного сотрудника “подвисает” на несколько секунд в день или, когда первый запуск Outlook у пользователя проходит дольше обычного — в момент обращения в техподдержку ошибка уже не наблюдается, но поскольку она возникает регулярно, специалисту нужно найти и устранить ее причину. На поиски таких причин зачастую нужны недели, но в системе заявок самый большой срок, отводимый на выполнения заявок равен 3 дням.

Несмотря на все перечисленные выше недостатки, текущие качество работы специалистов технической поддержки с системой заявок меня устраивает и, что не менее важно, система мотивации по работе с системой заявок устраивает самих специалистов. Конечно, есть еще, что полировать и улучшать, но я считаю куда более правильным сосредоточить свое внимание не на повышении качества учета обращений пользователей, а на том, чтобы причин обращаться в техническую поддержку у пользователей не было.

Успехов!

Время реакции и режим работы

2.1 Служба технической поддержки работает по рабочим дням с 9 до 20 часов московского времени, кроме выходных и праздничных дней (по календарю праздничных дней РФ).

Обращения в службу технической поддержки обрабатываются в порядке их поступления. Вне очереди могут обрабатываться обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям могут быть отнесены вопросы восстановления работоспособности Интернет-проектов, или отдельных сервисов данных проектов.

Время решения обращения может зависеть от критичности обращения, сложности решаемой проблемы и необходимости передачи вопроса в отдел разработки.

2.2 При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта, передаются для решения в отдел разработки компании «1С-Битрикс», с последующим выпуском обновления программного продукта. Сроки выпуска обновления определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта.

2.3 Служба технической поддержки не может гарантировать время решения вопроса, т.к. на это могут влиять различные факторы, например, своевременность ответа клиента, своевременность ответа компании хостера, необходимость подготовки и выпуска обновления программного продукта и т.п.

Время реакции определяется общей загрузкой технической поддержки и может составлять от нескольких часов до нескольких дней. В некоторых случаях решение вопросов может производиться практически сразу же по получению вопросов или дополнительной информации от клиентов или пользователей системы.

Реакция сотрудников службы технической поддержки на поступление дополнительной информации может быть дольше, если требуется подключение инженера или разработчика. В указанных случаях нет необходимости обращаться в службу поддержки по телефону или создавать сообщения в форуме, как правило, это не ускорит процесс решения проблемы.

2.4 Спецобращения

После оформления заказа покупатели «1С-Битрикс: Управление сайтом». Лицензия Энтерпрайз и «1С-Битрикс24». Лицензия Энтерпрайз получают специальный купон (буквенно-цифровой код), который даёт возможность создать 15 спецобращений в службу технической поддержки.

Порядок создания спецобращения:

Особенности обработки спецобращений:

В рамках спецобращения не оказываются услуги разработки дополнительных компонентов и доработки существующих.

2.5 В одном обращении может решаться только одна проблема.

Вверх

3.      Программа гарантийной обслуживания прикладного программного обеспечения

Гарантийное обслуживание предоставляется бесплатно клиентам, которые приобрели прикладное программное обеспечение по договору разработки информационной системы. Срок гарантийного обслуживания определяется для каждого программного продукта отдельно и закрепляется в договоре.

В рамках гарантийного обслуживания может предоставляться следующий перечень услуг:

  1. Анализ выявленных и подтвержденных Заказчиком ошибок в базовом программном обеспечении и доработках базового программного обеспечения, если такие доработки выполнялись Исполнителем (производится на стенде производителя с применением используемой клиентом версии программного обеспечения и тестовыми данными, или на тестовом стенде клиента с реальными данными, или с применением удаленного доступа к рабочей системе клиента).
  2. Исправление по запросу ошибки программного обеспечения. Под ошибкой понимается ситуация полной или частичной неработоспособности программного обеспечения, вызванная неверной логикой, заложенной в информационную систему.

Ошибками не являются:

  • Ситуации, вызванные неверным функционированием оборудования, операционной системы, системного программного обеспечения, которые влияют на функционирование системы;
  • Ситуации, связанные с неверным функционированием системы при несоблюдении пользователями технических требований;
  • Ситуации, связанные с неверным функционированием системы, возникшие в результате самостоятельного вмешательства пользователей в устройство программного обеспечения или неверной его настройкой.
  1. Предоставление обновлений программного обеспечения с устраненными выявленными ошибками.
  2. Предоставление новых версий программного обеспечения до новой официально выпущенной версии в рамках второй цифры, с учетом выполненных ранее индивидуальных доработок программного обеспечения.
  3. Предоставление Заказчику удаленного доступа к информационной системе контроля выполнения запросов Исполнителя.
  4. Прием и обработка запросов Заказчика на получение консультаций и устранение ошибок в программном обеспечении.

Для выполнения работ по предоставлению услуг в рамках гарантийного обслуживания должны выполнятся при соблюдении следующих условий:

  1. Услуги по договору оказываются для базовой (разработанной по техническому заданию и принятой в эксплуатацию) версии программного обеспечения с выполненными Исполнителем индивидуальными доработками (если такие доработки выполнялись Исполнителем), внесенными в программное обеспечение при внедрении или в процессе эксплуатации.
  2. Доработки базового программного обеспечения, выполненные Заказчиком самостоятельно, или с привлечением третьих организаций, не учитываются при предоставлении услуг.
  3. При выявлении Заказчиком возможной ошибки в программном обеспечении или выполненных доработках, наличие ошибки определяется и устраняется Исполнителем на собственном стенде с применением используемой клиентом версии программного обеспечения и тестовыми данными, или на тестовом стенде клиента с реальными данными, или с применением удаленного доступа к рабочей системе клиента.
  4. Устранение выявленных ошибок в программном обеспечении возможно методом предоставления новой версии, с неизмененной второй значащей цифрой.

2. Обобщенная трудовая функция

Дополнительные характеристики

3.2.1. Трудовая функция

3.2.2. Трудовая функция

Трудовые действия

Выявление возможных причин неисправностей на основании обращений клиентов, переданных от работников консультационной поддержки по типичным вопросам эксплуатации технологических составляющих инфокоммуникационных систем

Консультирование клиентов по нетипичным вопросам, возникшим при первичном конфигурировании поддерживаемых инфокоммуникационных систем и (или) их составляющих, в рамках делегируемых клиенту полномочий

Выяснение деталей проблемной ситуации, возникшей при установке или использовании поддерживаемых инфокоммуникационных систем и (или) их составляющих, в обсуждении с ответственным представителем клиента

Проверка состояния аппаратного и программного обеспечения инфокоммуникационных систем и (или) их составляющих — дистанционно или с выездом на место установки инфокоммуникационной системы

Определение неисправности, возникшей при эксплуатации аппаратного или программного обеспечения инфокоммуникационных систем и (или) их составляющих, по данным, полученным от клиента

Устранение неисправности, возникшей при эксплуатации аппаратного или программного обеспечения инфокоммуникационных систем и (или) их составляющих

Необходимые умения

Анализировать поступающие обращения клиентов

Проводить диагностику инфокоммуникационных систем и (или) их составляющих

Настраивать технологические компоненты поддерживаемых инфокоммуникационных систем

Настраивать операционные системы, используемые для работы поддерживаемых инфокоммуникационных систем и (или) их составляющих

Настраивать прикладное и системное программное обеспечение, необходимое для работы поддерживаемых инфокоммуникационных систем

Настраивать абонентские оконечные устройства клиентов, необходимые для работы поддерживаемых инфокоммуникационных систем

Необходимые знания

Инфокоммуникационные технологии в части поддерживаемых инфокоммуникационных систем и (или) их составляющих, а также необходимые для обеспечения их работы

Технические характеристики и архитектура поддерживаемых инфокоммуникационных систем и (или) их составляющих

Инструкции по установке и конфигурированию поддерживаемых инфокоммуникационных систем и (или) их составляющих

Структура и содержание руководств пользователя и руководств по техническому обслуживанию/конфигурированию, предоставленных разработчиками поддерживаемых инфокоммуникационных систем и (или) их составляющих

Регламенты взаимодействия сотрудников подразделения технической поддержки со структурными подразделениями организации

Этика и психология общения с клиентом при оказании услуг по технической поддержке

Правила деловой переписки и делового общения

Требования охраны труда при работе с поддерживаемыми инфокоммуникационными системами и (или) их составляющими

Другие характеристики

Сейчас ищут техподдержку:  Как обратиться к президенту Путину на прямую линию

3.2.3. Трудовая функция

Порядок подачи и обработки обращений в службу технической поддержки

4.1
Основанием для выполнения работ является обращение пользователя продукта. Работа с обращениями ведется в специальном разделе поддержки на сайте компании «Битрикс» или в онлайн-чате Битрикс24. Обращение может быть создано любым из перечисленных способов:

  • с использованием формы «Задать вопрос» на сайте;
  • через онлайн-чат Битрикс24.

4.2
В обращении должны быть точно и грамотно сформулированы вопросы, требующие разъяснения, и описаны проблемы, требующие решения. Для более оперативного решения вопросов, обращение должно включать следующую информацию:

  • Описание проблемы и пошаговое описание действий по воспроизведению проблемы (по возможности).
  • Вопрос желательно задавать используя терминологию, принятую в продукте.
  • Адрес сайта, на котором наблюдается проблема.
  • Номер используемой версии программного продукта и редакция.
  • Дополнительно, службой технической поддержки может быть запрошена информация по настройкам серверного ПО, используемым версиям и настройкам клиентского ПО (браузера).

4.3 В случае, если для разрешения ситуации требуется произвести определенные действия на сайте (сервере) пользователя, сотрудник технической поддержки может запросить авторизационные данные на временный административный доступ к проекту и лицензионный ключ продукта.

Сразу после закрытия проблемы вы должны изменить данные авторизации или деактивировать временные аккаунты, предоставленные компании «Битрикс». Сотрудники поддержки не несут ответственности за сохранность информации после закрытия проблемы.

4.4 При получении обращения в службе технической поддержки, пользователь получает уведомление о начале обработки и указанному обращению присваивается уникальный идентификатор (ID). Идентификатор необходимо сохранять в заголовке письма во время последующей переписки со службой технической поддержки по данному вопросу.

4.5 Техническая поддержка не оказывается по другим каналам (например, телефон, GoogleTalk, Skype). Вопросы, заданные по этим каналам не являются официальными обращениями и не регистрируются в системе службы технической поддержки. Подобные средства связи рассматриваются только как средства общения и общих консультаций.

4.6 При создании обращения можно включать скриншоты и графические пояснения, которые могут помочь в решении проблемы. Скриншоты должны быть подготовлены в форматах: JPG, GIF, PNG. В случае использования скриншотов в форматах BMP следует их предварительно запаковать с использованием программы архиватора (RAR, ZIP).

4.7 Ответы на стандартные, часто задаваемые вопросы, могут быть даны в виде ссылок на соответствующую страницу онлайновой документации по продукту, на скачивание руководств, на обсуждение в форуме или раздел FAQ, сайты разработчиков программного обеспечения.

4.8 Решение вопросов обращения может быть отложено или даже невозможно по следующим основным причинам:

  • Невозможно повторить описанную проблему на аналогичной конфигурации оборудования и отсутствует доступ к проекту пользователя.
  • На проекте пользователя не установлены актуальные обновления продукта, а на установке с актуальными версиями модулей проблема не воспроизводится сотрудником поддержки
  • Пользователь не может предоставить достаточно информации для решения проблемы.
  • Вопрос требует детальной диагностики, доработки функционала и/или выпуска обновления для программного продукта.
  • Пользователь выполняет действия в нарушение технических требований по установке и использованию программного продукта, внесены изменения в ядро продукта, превышено количество разрешенных установок программного продукта и т.п.
  • Используется нелицензионная копия программного продукта.
  • Вопрос выходит за рамки технической поддержки.
  • Вопрос задан некорректно или обсуждение вопроса проводится неконструктивно, и решение проблемы затягивается из-за несвоевременного предоставления информации по обращению.
  • В обращении используется нецензурная лексика или оскорбления сотрудников компании

Вверх

Состав работ, включённых в Расширенную техническую поддержку.

4.1. Кроме работ, включённых в Базовую техническую поддержку, в состав Расширенной поддержки входят:

  • консультации по установке и настройке Продуктов в среде Клиента, в том числе и связанные с настройкой среды выполнения;
  • установка и настройке Продуктов в среде Клиента посредством сеансов удаленного доступа;
  • рекомендации для достижения оптимального функционирования Продуктов в конкретных условиях сети Клиента, в том числе по обеспечению оптимальной производительности и совместимости с используемым Клиентом ПО и техническими средствами;
  • консультации по взаимодействию Продуктов с другим ПО и средствами защиты информации;
  • консультации по интерпретированию результатов (анализу защищенности) сети Клиента с использованием Продуктов;
  • первоочередное предоставление HotFix (*Решение по срокам выхода исправлений и очередность их реализации принимается исключительно Вендором) с исправлениями критических ошибок. Консультирования по минимизации воздействий ошибок программы (в случае их подтверждения специалистами Вендора) до выхода очередного исправления;
  • адаптация (*Адаптация не подразумевает разработки новых конфигураций безопасности (и другого информационного контента), а также их существенной модификации) конфигураций безопасности Продуктов под условия применения (среду) Клиента;
  • предоставление актуальной документации и других информационных материалов по настройке и эксплуатации продукции АЛТЭКС-СОФТ;
  • предоставление новых релизов, обновлений программ в соответствии с их лицензионными соглашениями;
  • консультации по порядку доступа и использования Центра сертифицированных обновлений продуктов Microsoft;
  • консультации по реализации мер защиты с помощью Продуктов.

4.2. Клиент имеет право в Заявке указывать предложения по реализации новых функций Продуктов и модификации существующих. Решение по их имплементации в Продуктах принимает исключительно Вендор.

4.3. В особых случаях при приобретении Расширенной технической поддержки по решению Вендора и Клиента, оформленному в виде отдельного финансового договора, Вендор может оказывать услуги технической поддержки на объектах Клиента. В этом случае Клиент обязан оплатить свои обязательства по вышенобозначенным работам, а также транспортные и иные расходы Вендора, связанные с выполнением договора.

Борьба за своевременную актуализацию статуса задач в системе заявок

Чтобы побороться за своевременную актуализацию статусов и закрытие задач в системе заявок, я дополнительно разделил в системе премирования заявки пользователей на два типа — закрытые вовремя и закрытые с нарушением сроков выполнения. Заявки, закрытые вовремя, я сделал в три раза ценнее всех остальных задач.

При этом коэффициенты за лидерство оставались только по трем категориям — зарегистрированные заявки, закрытые в срок и профилактические задачи. Заявки, сделанные с нарушением сроков, не имели коэффициентов за лидерство. По новой системе, для получения хорошей премии уже было недостаточно весь месяц ударно работать, а в конце месяца скопом закрыть сделанные задачи — нужно было в течение всего месяца поддерживать информацию в системе ServiceDesk в актуальном состоянии.

Памятуя о своих прошлых управленческих “успехах”, прежде чем что-то менять в сложившийся системе премирования, я для начала оценил размеры изменений по старым периодам. В таблице 6 приведен расчет премии по новой системе за апрель 2020 года (в таблице 5 выше содержится расчет за этот же период по старой системе). Дополнительно в отчете я вывел число “висяков” — заявки, которые были просрочены и не закрыты в отчетном периоде:

Организация эффективной техподдержки 1С внутри компании
Таблица 6 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2020 год по новой системе учета.

Картина в отчетах вырисовывалась грустная — количество просроченных и зависших заявок превышало количество закрытых вовремя заявок. Однако, несмотря на всю грусть ситуации, новая система премирования не изменяла принципиально текущее распределение премиального фонда, а значит, не угрожала новыми конфликтами со специалистами техподдержки. Поэтому, перекрестившись, я сделал оповещение об изменении в системе премирования (на этот раз без изменения бюджета) и стал наблюдать.

Хотелось бы тут написать, что изменения не заставили себя ждать и, с введением новой системы премирования, жизнь наконец-то наладилась. Но в реальности, парни узнав об изменениях в системе премирования напряглись, закрыли большинство «зависших» заявок и… стали копить новые.

Заявок, сделанных с просрочкой и “висяков”, стало несколько меньше, но не настолько, чтобы можно было заявлять о каких-то серьезных победах на этом фронте. Причина же отсутствия сколь-либо значимых результатов оказалось банальной — часть сотрудников готовы были пренебречь лишней тысячей рублей премии, лишь бы не напрягаться с качественным ведением заявок в ServiceDesk, а некоторые индивиды даже целенаправленно жертвовали качеством ведения заявок в системе, чтобы младшие коллеги получили премию побольше.

Дабы подтолкнуть работать с системой заявок тех специалистов, которым премия от работы с системой не нужна, я сделал премиальный фонд динамическим, когда размер фонда изменяется в зависимости от соотношения закрытых в срок задач к общему числу задач в системе заявок (закрытых за период и “зависших”).

С таким подходом получалось, что сотрудники, которые плохо ведут ServiceDesk (не закрывают вовремя заявки, оставляют зависшие заявки), уменьшают премию не только себе, но и своим коллегам. Расчет мой был на то, что специалисты, которым премия не нужна, не заходят портить отношения с коллегами, которым премия все же нужна, и будут стараться более-менее качественно вести учет заявок — коварный план, не так ли? 🙂

Чтобы нововведение не ухудшило существующие условия, я рассчитал тот уровень “премиальной базы”, при котором текущий премиальный фонд (30 000 р.) соответствовал бы текущему качеству ведения ServiceDesk — вышло 47 000 рублей. Сделав очередную рассылку, я снова стал ждать и, спустя пару месяцев, увидел куда более фундаментальные в качественном отношении изменения — количество просроченных заявок и “висяков” уменьшилось в системе вдвое:

Организация эффективной техподдержки 1С внутри компании
Таблица 7 (кликабельно). Расчет премии за работу с системой ServiceDesk в октябре 2020 года с динамическим премиальным фондом.

На этом вносить изменения в систему мотивации я перестал. В последующие два года я один раз поднял премиальную базу, а все остальное время только своевременно считал и исправно платил премию, а также наблюдал за развитием событий.

Сейчас ищут техподдержку:  Как написать в техподдержку ВК

Как устроена поддержка программного обеспечения в edison

В соответствии со статьей

производитель должен давать гарантию на свои программные продукты, а именно: исправлять свои ошибки либо менять продукт на другую версию. Проблема в том, что по закону для этого требуется экспертиза, подтверждающая наличие сбоя, доказывающая вину разработчика, исключающая пользовательское вмешательство в код ПО, гарантирующая корректное использование продукта клиентом и т.д.

Услуга техподдержки, в соответствии с которой специалисты EDISON исправляют все недостатки, в том числе инициированные пользователем и не включенные в изначальное ТЗ, призвана компенсировать эти недочёты.

Независимо от того, требуется ли поддержка по корпоративному сайту или системе автоматизации на базе Oracle, порядок ее оказания одинаков (меняется лишь срок в зависимости от сложности задачи).

Техническая поддержка пользователей ПО может включать большое количество опций в зависимости от желаний клиента, например:

  • выделение горячей линии, консультации,
  • обучение пользователей системы работы с ней,
  • устранение любых проблем, возникающих в работе ПО,
  • любая доработка под нужны клиента, в том числе расширение функционала.

Оплата за техническую поддержку, как правило, осуществляется по факту в зависимости от затраченного времени.

За каждым клиентом мы закрепляем проект-менеджера, с которым ведется вся коммуникация. Для контроля за ходом работы и затраченным на выполнение задач временем клиенту предоставляются неограниченные по времени доступы к репозиторию, системе управления проектами и программе учета времени ББ, о которой мы писали выше.

Сайты могут управляться клиентами самостоятельно, используемые нами CMS: Bitrix, WordPress, Joomla, Drupal, Amiro, Frog, Kentico, AxCMS, Sitefinity. Поддержка веб-сайта включает в себя, в том числе, своевременное информирование о необходимости оплаты хостинга и домена.

Мертворожденная система мотивации за работу с системой заявок, читеры, бунт на корабле

Месяца два, в свободное от чтения хабра время, я думал о том, как разнообразить систему “соцсоревнования” и внести в нее интригу. Для начала, я собрал все объективные критерии для оценки работы по заявкам, которые можно было измерять на тот момент. Их получилось немного:

  1. Количество зарегистрированных заявок;
  2. Количество закрытых заявок;
  3. Количество выполненных регламентно-профилактических задач;
  4. Оценка пользователями работы специалиста по заявкам.

Поэтому интригу я решил создать за счет введения в систему мотивации дополнительных критериев, как то:

  1. Премиальный коэффициент 1,5 увеличивающий баллы на 50% для двух ударников в каждой из категорий (регистрация, закрытие заявок, выполнение профилактик).
  2. Депримирующий коэффициент 0,5, который уменьшает баллы на 50% для самого слабого специалиста в категории.
  3. Коэффициент субъективной оценки качества ведения ServiceDesk в течение месяца. Предполагалось, что такую оценку будет ставить один из специалистов, которому отводилась на этот месяц роль “диспетчера” (за эту роль полагался дополнительный премиальный коэффициент)
  4. Депримирующий коэффициент 0,5 за невыполнение норматива профилактических задач (40 задач в месяц). Данный норматив отсутствовал у трех самых крутых специалистов.
  5. Депримирующий коэффициент 0,5 за отклонение от регламентов выполнения профилактических задач. При этом вычтенные у провинившегося сотрудника баллы плюсовались тому сотруднику, который обнаружил отклонение от регламентов.

Еще в систему мотивации были защиты коэффициенты за составление статей в блог по всяким офисным премудростям (таким способом мы одно время приучали парней корректно составлять инструкций для пользователей), а также за участие в проектах. Как все эти коэффициенты были связаны между собой я сейчас не буду рассказывать — все это не имеет особого значения, так как от данной системы в скором времени пришлось отказаться.

Введя новые правила, я в очередной раз увеличил премиальный фонд и сделал рассылку. Изучив новые правила игры, Илья Муромец (напомню еще раз, что имена сотрудников изменены) сразу увидел ее несовершенство и заявил, что он “хакнет” премиальную систему, чтобы показать ее недостатки.

Для этого в течение всего месяца Илья делал как можно больше профилактических задач, чтобы остальные коллеги не имели возможности выполнить свой норматив по профилактикам и получили понижающий коэффициент к премии (а значит, уменьшили свою премию и увеличили его). У Ильи это почти получилось, и в марте он получил самую большую премию:

Организация эффективной техподдержки 1С внутри компании
Таблица 2 (кликабельно). Расчет премии за работу с системой ServiceDesk в марте 2020 года. Здесь и далее: N — количество заявок, P — цена в баллах, K — повышающий (понижающий) коэффициент.

Правда запала на апрель у Ильи уже не хватило (ну или коллеги устроили ему темную — история умалчивает), и премия за апрель напоминала старые отчеты:

Организация эффективной техподдержки 1С внутри компании
Таблица 3 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2020 года.

На третий месяц уже Добрыня Никитич оставил всех с носом, сделав чуть ли не все профилактики в одно лицо. У Добрыни для этого было техническое преимущество — он живет в Новосибирске и просыпался тогда на 3 часа раньше Московского офиса (сейчас уже на 4).

Организация эффективной техподдержки 1С внутри компании
Таблица 4 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2020 года.

Четвертого месяца работы по такой системе мотивации не было — в массах пошло роптание о том, что существующая система только демотивирует. В принципе, сейчас я понимаю, что такая система поощрения могла прижиться только в нездоровом коллективе, где каждый только и думает о том, как бы насолить другим.

В нашем же случае, парни не хотели оценивать качество работы других с системой заявок, не хотели “стучать” на соседа, если обнаруживали косяк в его работе (пожурить — безусловно, но в данном случае любая ошибка приводила к уменьшению премии), да и в целом, часть людей предпочитала просто не браться за какие-то задачи, если ошибки при их исполнении могут привести к уменьшению премии.

  1. Прямого участия коллег в оценке результатов труда и во влиянии на размер премии;
  2. Любых демотивирующих коэффициентов (за исключением объективной оценки качества работы пользователями);
  3. Любых привилегированных сотрудников в системе премирования.


После этого в системе “соцсоревнования” осталось только три категории с двумя лидерами в каждой из категорий и с оценкой качества работы по заявкам пользователями. До апреля 2020 года такая система работала без изменений:

Организация эффективной техподдержки 1С внутри компании
Таблица 5 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2020 года.

Единственным достижением системы мотивации на начало 2020 года стала повальная регистрация всех обращений пользователей в системе заявок. А вот со своевременным обновлением статусов заявок и их закрытием в системе дела обстояли все также плохо. При изучении заявок в ServiceDesk в середине месяца, волосы на голове вставали дыбом от объемов задач, на которые мы, не то забили, не то как-то делаем, не то уже давно сделали.

При этом, если пнуть специалистов техподдержки (что я и делал в конце каждого месяца), то заявки тут же закрывались в огромных количествах и картина происходящего становилась куда более лицеприятной. Но в 2020 года такое положение дел мне окончательно надоело, и я решился на еще один набег на систему премирования:

Самые важные функции систем техподдержки

  • управление заявками — это очевидная функция всех подобных решений. Однако стоит искать инструменты, которые просты в использовании, но при этом имеют достаточную гибкость настроек (возможность создавать собственные статусы заявок, доп.атрибуты, маршрутизацию и т.д.);
  • поддержка и настройка SLA — соглашений об уровне сервиса. Если у клиентов есть потребность в SLA, такая возможность должна быть и у выбранного решения;
  • категоризация заявок. Не все они имеют одинаковый уровень важности. Поддержка должна иметь механизмы классификации заявок. Кстати, категории могут помогать и с выбором ответственных лиц;
  • маршрутизация как таковая и настраиваемые шаблоны маршрутизации заявок, очереди и потоки;
  • настраиваемый статус заявок в соответствии с вашими бизнес процессами;
  • разграничение доступа к информации в заявке для внутренних и внешних лиц (для специалистов компании и клиентов). Эта функция может понадобится, если клиенты будут иметь доступ к системе, например, через мобильное приложение;
  • учет обслуживаемого оборудования и ПО клиента (терминалы, датчики, транспортные средства, сайты и т.д.);
  • агрегация заявок по клиентам или описанным в них проблемам. Кстати, анализ системных проблем в определенных условиях может сэкономить много денег;
  • интеграция с электронной почтой как на прием сообщений с адреса поддержки (с автоматическим созданием заявок), так и на отправку уведомлений сотрудникам и клиентам;
  • современные каналы регистраций заявок, кроме клиентского портала и email (телеграм бот, мобильное приложение заявителя и т.д.);
  • клиентский портал для самостоятельного создания заявок;
  • база знаний с доступом для сотрудников и/или клиентов;
  • инструменты совместной работы над заявками;
  • поиск заявок в базе;
  • поддержка вложений к заявкам;
  • функции отслеживания времени, потраченного сотрудником (особенно в том случае, когда у сотрудников почасовая оплата);
  • отчетность, позволяющая выявить нереализуемые шаблоны, сбои в жизненном цикле заявок и т.п.
  • аналитика для понимания бизнес-операций и возможностей для роста;
  • поддержка английского языка;
  • интеграция со сторонними инструментами: как через API, так и готовые интеграции с , АТС и т.д.;
  • техническая поддержка самого решения для автоматизации.

Конечно, это не исчерпывающий список. Однако большинству компаний такого функционала достаточно.Важно, что все эти и множество других функций есть в современных системах техподдержки.

Okdesk —  лидирующая Help Desk система (опыт более 5000 компаний) для автоматизации техподдержки. Бесплатное тестирование на 14 дней.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Оставьте комментарий

Adblock
detector