serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Монетизация техподдержки
serge_gorshkov

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



Отдел поддержки в нашей компании едва ли не более важен, чем оба отдела разработки (систем автоматизации бизнеса и веб-сайтов). Главная задача, ставившаяся при его создании – любой ценой решать проблемы клиентов. С ней отдел уже несколько лет успешно справляется. А вот с рентабельностью, а значит – и с оплатой труда программистов, все было не так гладко.

Бизнес-модель поддержки довольно проста: каждое выполненное обращение клиента оценивается исполнителем в часах, регистрируется в системе Service Desk. Затем на основании этой оценки взимается плата с клиента, и производится начисление зарплаты сотрудникам. Казалось бы, программисты должны быть заинтересованы в том, чтобы выполнять больше работы, и выставлять за нее больше часов клиентам – однако, на практике все выходило не так. Сотрудники поддержки обладают особым психологическим складом, который мы сами же в них долго воспитывали: они настолько сопереживают клиенту, что не только хотят решить все его проблемы, но и готовы встать на его точку зрения в оценке работ. Еще одно стремление проявить лояльность выражалось в том, что сотрудники поддержки имели склонность классифицировать многие обращения как ошибки – ведь для клиента исправление ошибок бесплатно (по гарантии), а сотруднику за такую работу деньги все равно выплачиваются! В результате такой работы отдел функционировал практически «в ноль», и периодически получал дотации от отделов разработки.

Несложно посчитать, что при 22 семичасовых рабочих днях в месяц суммарное рабочее время сотрудника составляет 154 часа. Так как мы регистрируем в нашей системе Service Desk ровно то самое время, которое сотрудник потратил на выполнение каждого обращения, теоретически именно такой и должна быть выработка каждого программиста. На практике, год назад средняя выработка по отделу составляла 48 часов в месяц на сотрудника, то есть две трети рабочего времени уходили неизвестно куда. Естественно, клиенты платили нам за 48 часов (и то – за вычетом ошибок, которые составляли до половины этого времени), а мы в любом случае вынуждены были обеспечивать сотрудникам такой уровень зарплаты, при котором они были согласны у нас работать… Что делать?

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

Слово «повысилась» я взял в кавычки, потому что на самом деле сотрудники не стали больше работать – они стали аккуратнее записывать выполненную работу. Добиться этого было непросто.

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

Тогда мы решили применить на практике метод уговоров и разъяснений. Было проведено несколько планерок, на которых сотрудникам детально рассказывалось, откуда именно поступают те средства, из которых формируется фонд их заработной платы, и почему компания не может выплачивать им больше денег, чем поступает от клиентов… В общем, мы не пожалели красноречия, взывали к логике, лучшим чувствам и т.д. Эффект был, но он оказался намного слабее, чем можно было рассчитывать. Скромные результаты дали и изменения в схеме оплаты, в сторону большей зависимости денег от выработки: сотрудники стремились выполнять примерно одинаковое количество работы, и бюджет отдела в любом случае делился между ними примерно поровну. Максимум, чего удалось достичь этими методами – средней выработки 90 часов в месяц. 40% рабочего времени все еще куда-то улетучивались…

Мы, конечно, понимаем, что добиться 100% выработки невозможно; такой задачи мы и не ставили. А вот цифра в 80% выглядела в наших глазах вполне разумной. Было решено исследовать, как именно сотрудники регистрируют свое рабочее время, и подумать над тем, как помочь им делать это эффективнее. Сначала мы выполнили несколько однодневных срезов – эталонные сотрудники в течение одного рабочего дня вели детальный реестр своих дел и регистрировали переключения между задачами. Затем мы сравнили эти записи со временем, зафиксированным в Service Desk, и пришли к выводу, что основным источником потери времени является кратковременное переключение между задачами, а также выполнение коротких (до 15 минут) задач. Сотрудники не регистрируют их, поскольку время на регистрацию сопоставимо с самим временем выполнения задачи. Необходимость тратить время на запись каждого действия их просто раздражает. Наконец, при напряженном ритме работы есть вполне реальный риск забыть зафиксировать какие-то из выполненных задач…

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



Инструмент был назван «таймер», и на очередной планерке триумфально презентован персоналу. Что тут началось… Если честно, мы никак не ожидали того, что произошло. Начался саботаж таймера. Программисты устроили многостраничный флуд в форуме на внутреннем портале. Некоторые сотрудники рисовали «юмористические» картинки про таймер:







Устные обсуждения этой темы в офисе пришлось просто запретить… Срочно созванные совещания, на которых людям объясняли пользу этого инструмента, были похожи на заседания российского парламента в начале 90-х. В следующем месяце после введения таймера выработка упала со 110 до 75 часов в месяц, а в воздухе витала идея создания профсоюза для противостояния капиталистической эксплуатации.

От идеи немедленного обязательного использования таймера пришлось отказаться, и создать рабочую группу из сотрудников техподдержки, для разработки эффективного инструмента контроля времени. Было сформулировано и реализовано техническое задание; кстати, оказалось, что полученный инструмент не так уж сильно отличается от первоначального варианта таймера. Но теперь сотрудники, которые сами участвовали в создании второй версии таймера, отнеслись к нему намного лояльнее. Средняя выработка выросла до 120 часов в месяц, или 78% от суммарного рабочего времени, что является для нас вполне приемлемым результатом.

Благодаря этому, за истекший год средняя зарплата сотрудника поддержки выросла на 50%, а компания наконец-то начала получать прибыль от этого вида деятельности. А самое главное – сотрудники стали в большей степени сочувствовать интересам компании, нежели наших клиентов; честно говоря, именно этого мы от них и добивались. Впрочем, выгоду от новшеств почувствовали и клиенты – их обращения стали исполняться быстрее, и с большей охотой.

Еще одним компонентом изменений является борьба за сокращение процента ошибок. В начале реформ на устранение ошибок тратилось 46% времени работы сотрудников поддержки, что является совершенно неприемлемым – ведь за эти работы клиенты нам не платят. Мы совершенно уверены, что наши разработчики пишут не настолько плохой код, чтобы на его исправление нужно было тратить такие усилия. Приемлемым процентом ошибок является уровень 15-20%. К настоящему времени, через год после начала реформ отдела поддержки, нам удалось довести это значение до 25% - значит, есть к чему стремиться дальше.

Анализ показал, что причина возникновения «мнимых» ошибок лежит как раз в области сопереживания клиенту. Сотрудник поддержки склонен классифицировать как ошибку все, что считает ошибкой клиент; между тем, на практике это далеко не всегда так. Например, системный администратор клиента «уронил» сервер, и система перестала работать; с точки зрения клиента, не желающего вникать в причины – это ошибка, а с точки зрения нашей компании – дополнительные работы. Или ситуация, когда клиент, не очень хорошо обдумав последствия, требует внести в систему какие-нибудь изменения, а затем решает их отменить. У сотрудника поддержки обычно нет ни времени, ни желания спорить с клиентом; ему проще всего квалифицировать такое обращение как ошибку, чтобы и самому получить свою оплату, и клиента не обидеть.

В течение последних месяцев мы ведем постоянный контроль всех обращений с типом «ошибка», и во всех сколько-нибудь сомнительных случаях проводим разъяснительную работу со специалистами. Еще одним новшеством стало требование к работникам поддержки обосновывать в специальном комментарии, почему то или иное обращение является ошибкой; те ошибки, по которым такой комментарий отсутствует, специалистам не оплачиваются.

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

1.            Единственный способ добиться чего-либо от персонала в ИТ-компании – это договориться с людьми. Давление и манипуляции, даже с самыми лучшими намерениями, ни к чему не приводят.

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

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




  • 1
:) очень знакомо, хоть и не похожая область. Решил у себя в отделе (работаю начальником участка в телеком. компании, устанавливаем Интернет, телефонию), ускорить установки наших услуг клиентам. Провел реорганизацию движения документов, распаралелил, получил результат в 2 раза, с 4-5дней в среднем до 1-2 дней. Что само по себе конечно хорошо, но останавливаться на достигнутом мне показалось мало. Решил ввести мотивацию.
По принципу: есть регламент, скажем установка в 3 дня. Если установщик справляется за 1 день, он получает деньги.
Для автоматизации расчетов сделал программу.
Скриншот вот http://lenbiz.ru/out/abonents.jpg
Суть проста, сделал какое то действие, заходишь жмешь на задачу, которую сделал, оставляешь комментарий если нужно, жмешь кнопку ОК. все :) занимает 2 секунды.
У меня тоже саботаж, работники инертны, не хотят ничего нового :( ругать и лишать премии тоже не вариант :( разговаривать бесполезно, понимающе кивают, и продолжают ничего не делать.
Планировал на подобии этой системы сделать СервисДеск для тех.поддержки Интернета, только боюсь нарвусь на точно такое же безразличие :(

"У меня тоже саботаж, работники инертны, не хотят ничего нового"
Не знаю, как у вас, а вот про компанию автора скажу точно, ибо именно я была главой оппозиции:

1. Никакого саботажа не было. Если в какие-то месяцы идет снижение выработки, то речь ни о намеренных действиях, а об объективных причинах - например, в один месяц весь срок все на местах, в другой месяц кто-то в отпуске, кто-то на больничном, в итоге средняя выработка логично падает.

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

Представьте, что ваши сотрудники на работу ходили пешком, а теперь вы выдали им велосипеды с квадратными колесами и приказали: теперь вы будете ездить только так, и это повысит вашу выработку, это же велосипед! А то что на квадратных колесах ездить нельзя - это пофиг, ага-ага, сотрудники на квадратных колесах оказывается не ездят из саботажа и лени. Вам самому не смешно?
Потом из-за протестов колеса допилили сперва до двенадцатиугольных, сейчас примерно шестнадцатиугольные - трясет, но на них уже можно ездить, и даже несколько быстрее, чем пешком. Но пока не круглые. ;)

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

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


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

Я просто что начал разговор, тоже вопрос о тех.поддержке же стоит. Так вот, есть наверное набор типов работ, привести все это к списку, при регистрации заявки чтобы можно было выбрать список проблем клиента, в зависимости от этого создается список работ которые нужно сделать, и программист в Вашем случае, инженер в моем, сделав работу, просто отмечает её галкой и все. Это я к тому что:
"поскольку время на регистрацию сопоставимо с самим временем выполнения задачи".
Т.е. постараться максимально автоматизировать вот именно это, чтобы избежать длительного описания проблемы.
Хотя наверное у Вас чужая СервисДеск система стоит?

"есть наверное набор типов работ" - в том-то и дело, что нет.

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

"у Вас чужая СервисДеск система стоит?" - полностью свой продукт. Но это классический сапожник без сапог. :)

Но безусловно время занесения обращения надо уменьшать и максимально автоматизировать. Что-то уже сделано (например, часть полей автоматически заполняются при создании/смене статуса), что-то в планах. Тут же не только в том, чтобы руководство сотрудников убедило инструментом пользоваться, надо еще сотрудникам ответно убедить руководство в необходимости внесения доработок инструмента и выделении ресурсов на эту доработку. ;)

1. "Сотрудник видит список обращений, назначенных ему для выполнения, и может одним щелчком мыши указать, каким обращением он занят в данный момент."
В работе у каждого сотрудника одномоментно 25-50 обращений - чтобы кликнуть на нужное, надо его сперва найти. Исходно НИКАКОЙ сортировки или фильтрации списка обращений, откуда рабоатл таймер, не было. Поэтому "одним щелчком мыши" - это только писать хорошо, а в реали очень долго приходилось скролить и искать, куда щелкнуть.

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

2. "Занести новое обращение также не составляет особого труда – можно сделать это прямо в процессе телефонного разговора с клиентом"
Вот это вообще гон. Нереально одновременно говорить с клиентом и обращение заносить. Даже сейчас. Я говорю с клиентом, а тем временем нахожу его в списке, открываю его систему (вводя логин-пароль), и только потом уже начинаю проверку по обращению, и только повесив трубку могу занести обращение. Или вы предлагаете чтобы я в разговоре с клиентом сказала: погодите, не рассказывайте проблему, я обращение занесу? Да клиент меня убьет! И так-то клиентов бесит, когда я говорю: "Подождите, я открою вашу систему", - все очень нетерпеливы.

3. "полученный инструмент не так уж сильно отличается от первоначального варианта таймера"
Ага, не так уж сильно квадрат от шестнадцатиугольника отличается - и то, и то правильный выпуклый многоугольник. Вот только катятся они всё ранво с разными усилиями.

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

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

Разговоры у нас записываются! В качестве АТС используется Астериск. Но вот к Service Desk'у он, к сожалению, не прикручен. Разговоры приходится искать, зная примерное время контакта и специалиста, который разговаривал. В принципе, найти несложно.
Другое дело, что сейчас эта возможность используется для контроля каких-то спорных ситуаций с клиентами, то есть "разборов полета". Дать возможность сотруднику самому прослушивать свои состоявшиеся разговоры - интересная идея...

  • 1
?

Log in

No account? Create an account