Как увеличить на 30% эффективность работы сервисных подразделений компании

Меня зовут Алексей Тапилин, я представляю группу компаний «Агат», где работаю заместителем директора по ИТ. Я расскажу, как мы повысили эффективность нашей техподдержки на 30% – и что такое 30%, тоже поясню.

Группа компаний «Агат» – это крупнейший в России автомобильный холдинг, который имеет представительства в 12 регионах, 31 дилерский центр, обслуживает множество разных брендов, самые популярные из которых – Toyota, Huindai, и даже немного недвижимостью занимается. Еще у нас есть дополнительные смежные бизнесы типа кузовного ремонта и trade-in.

Все рынки конкурентные, и нет такого региона, где присутствовал бы только «Агат», поэтому компания вынуждена развиваться, постоянно идти в ногу со временем и как-то бороться за клиента.

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

• чтобы все решения в ИТ и других подразделениях принимались оперативно;
• чтобы была постоянная обратная связь от клиентов и от сотрудников компании;
• чтобы у нас была одна большая команда – одна семья, одна группа компаний;
• чтобы изменения происходили быстро, применялись сразу во всей группе компаний;
• чтобы мы могли быстрее работать и легче идти в ногу со временем,

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

Такие же проблемы были в ИТ-подразделениях, которые оказывали техподдержку 1С. Разработчики 1С у нас присутствовали в трех регионах, причем в различных регионах одни и те же задачи реализовывались по-разному.

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

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

Все это приводило к некому хаосу, который выражался в низком качестве выполнения задач – работа делалась плохо и медленно. Например, задачу могли реализовывать 2 месяца и 2 дня. При этом могло оказаться, что 2 месяца кто-то что-то согласовывал, утверждал и уточнял, а сделали в итоге за 2 дня. Сделали быстро и хорошо, но решения пришлось ждать долго, и виноватыми все равно остались ИТ-шники, как это часто бывает во многих компаниях. Так или иначе, скорость исполнения страдала, и это не нравилось бизнесу. Поэтому у руководства возник вполне логичный вопрос: «На что тратятся деньги?».

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

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

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

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

• Во-первых, это были проблемы при взаимодействии между сотрудниками;
• И, во-вторых, проблемы в организационной структуре – это, наверное, было самое сложное.

Подытожим, с чего все началось.

Сотрудники техподдержки 1С присутствовали в трех регионах – в общей сложности их было 16 человек. К ним можно еще приплюсовать 20 системных администраторов.

Задачу принимали в работу любым доступным способом – по телефону, по почте, лично (где-то кого-то в коридоре встретили). Все это нужно было сделать срочно, и, если что-то было сделано не так, найти виновного было очень сложно.

Происходило дублирование функций в различных программах. Front-line в группе компаний был реализован на разношерстных конфигурациях, основанных на «1С-Рарус: Альфа-авто». Для каждого бренда конфигурация была своя. Одни и те же задачи в разных конфигурациях решались разными людьми из разных регионов, и, так как люди между собой не общались, эти задачи были реализованы разными способами.

• Все это приводило к абсолютному хаосу – поддерживать такую систему было очень тяжело.
• Кто и чем занимается, было непонятно.
• И, как следствие, бизнес оценивал ИТ очень плохо. Постоянно задавал вопросы: «Где деньги? Чем вы занимаетесь? Давайте всех уволим и т.д.»

С чего мы начали? Со стандартизации!

Мы описали все бизнес-процессы, которые присутствовали в компании на front-line – это продажи, сервис, кузовной ремонт, CRM и прочие вещи (все, что связано с обслуживанием клиентов). Все эти документы прошли утверждение, и было решено, что компания будет обслуживать клиентов именно по этим документам.

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

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

Было решено перейти на единую конфигурацию информационных баз, причем, реализовать ее на «тонком клиенте». Это вызвало первую проблему, поскольку сначала мы работали с «1С-Рарус: Альфа-Авто», но в 2013 году она, к сожалению, еще не успела перейти на режим «тонкий клиент». А так как все свои бизнес-процессы мы уже описали, все свелось к тому, что мы от этой конфигурации отказались и реализовали полностью свою систему на основании тех бизнес-процессов, которые были описаны.

Получилось все очень удачно.

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

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

На втором этапе, после того как мы все стандартизировали, появился оптимизм – мы перешли к оптимизации.

ИТ-подразделение разделили по ITIL на два отдела – отдел внедрения и отдел технической поддержки, про который, собственно, и идет речь.

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

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

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

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

Например, задача – дать сотруднику доступ к программе. Как ее можно оценить?

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

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

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

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

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

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

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

После того как мы все это посчитали, и время работы по заявкам стало уже более точным, сразу стали понятны лидеры и неэффективные сотрудники:

Люди, которые реально хорошо работают, и ими все довольны, на слайде выделены зеленым. Это – лидеры.

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

Поэтому следующим этапом оцифровки подразделения для нас стало построение системы мотивации.

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

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

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

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

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

Что мы получили в результате:

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

Начали с автоматизации получения обратной связи от пользователей.

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

Тогда реализовали следующее: когда пользователь звонит, ему на e-mail автоматически приходит письмо с текстом: «Ваш звонок в техподдержку очень важен для нас, если вы хотите оценить наш сервис, нажмите ссылку». Мы не заставляем всех пользователей оценивать звонки, потому что это занимает определенное время – незачем людей зря отвлекать. Но тот, кто недоволен и хочет высказать какие-то претензии, нажмет на ссылку. Перед ним появится окошко, где написано, что звонок обработала Ольга Еремина, и ее можно оценить. И сразу в системе появится заявка, где будет видно, кто звонил, кто принял звонок, и будет приложена запись звонка, по которой можно уже оценить, в чем суть конфликта и кто виноват.

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

Что еще можно было автоматизировать из рутины? Конечно, допуск к программам.

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

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

У нас в день обычно подается порядка 200 заявок на доступ, и ранее на каждую из них у сотрудника уходило примерно 5 минут. Можете себе представить, сколько времени удалось освободить. Очень рекомендую автоматизировать этот процесс, если он у вас еще не автоматизирован.

Еще один успешный опыт – это внедрение автоматизированного тестирования.

Как я уже говорил, релизы у нас выпускаются раз в неделю, и сначала тестирование производилось вручную. В воскресенье садился сотрудник, проводил по чек-листам какие-то тесты – проверял, сломали программу в отделе внедрения или нет. Часто оказывалось, что сломали, он ее возвращал на доработку, ему опять присылали, и он опять тестировал. На то, чтобы единожды прогнать всю программу по чек-листу (при том, что это всего лишь 10-15% от всей конфигурации), уходило минимум 8 часов.

После того, как в 2015 году на конференции Инфостарта я узнал про Vanessa-Behavior, все стало намного проще. Мы реализовали тесты для Vanessa-Behavior, которые автоматически раз в неделю проверяют релиз. Если все хорошо, то на почту приходит письмо. А если все плохо, то в нашей системе заявок создается задача с описанием и скринами ошибок. И уже ответственный сотрудник по этому описанию проверяет, что не так.

В итоге удалось высвободить примерно 8 часов времени работы сотрудника.

На автоматический режим перевели и контроль над оборудованием.

Эта задача, конечно, касается больше системных администраторов, а не 1С-ников, но суть в том, что на всех серверах установили датчики, которые в случае каких-то критических проблем (например, повышение температуры) отдают команду на Zabbix, и из Zabbix в нашу систему задач отправляется заявка, которая также быстро рассматривается.

Контроль за оборудованием позволил организовать журнал отказов. Зачем он нужен? Например, где-нибудь в Ухте, в 8 часов вечера не обслужили клиента, потому что кассир ушел домой. Клиент на следующий день звонит, жалуется, что его вчера в автосервисе не обслужили, закрылись раньше срока. На что кассир говорит, что им пришлось закрыться, т.к. 1С не работала – не было доступа к серверу или еще что-нибудь. Теперь при рассмотрении таких случаев можно реально проверить, работала система или нет. После того, как это внедрили, оказалось, что в 92% случаев с системой все было в порядке, и проблема заключалась именно в сотрудниках.

А теперь результаты в цифрах.

В 2014 году, на момент, когда мы начали заниматься централизацией техподдержки, мы имели примерно 4 300 заявок в месяц, из них просроченных – 55. Средняя зарплата по подразделению была 36 700 рублей – для нашего региона это вполне достойные деньги, но нам, конечно, хотелось большего. А полный фонд оплаты труда подразделения составлял 552 тысячи рублей.

А уже в 2015 году, после того как мы внедрили эту систему и автоматизировали многие процессы, количество заявок увеличилось в 1,5 раза, а количество работников сократилось наполовину. При этом средняя зарплата каждого сотрудника выросла.

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

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

Что в итоге получилось?

Поскольку мы высвободили 30% времени персонала, следовательно, у сотрудников техподдержки появилось свободное время, которое надо было чем-то загрузить.

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

Таким образом, мы высвободили 30% времени, загрузили его и тут же высвободили опять на 20%, сэкономив при этом компании 62 миллиона рублей в год на бухгалтерии (бухгалтерию сократили на 20%).

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

Таких кейсов применения можно придумать очень много – например, можно автоматизировать получение справок 2-НДФЛ и т.д. Все, что касается зарплаты, приема на работу и увольнения, поиска вакансий – все это интеграционные вещи. Любое сервисное подразделение можно автоматизировать, любой бэк-офис.

Я постарался рассказать о нашем опыте применения тех практик, о которых впервые услышал на конференциях Инфостарта. Благодаря им мы смогли начать разговаривать с бизнесом на языке денег. Это очень полезно, если вы хотите, чтобы ИТ в компании ценились. Потому что тогда любые инициативы, которые исходят со стороны ИТ, воспринимаются очень хорошо.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.