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

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

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

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

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

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

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

  • 1
?

Log in

No account? Create an account