Разработка проекта развития отдела клиентского сервиса компании ООО "Таймбук"

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

Рубрика Менеджмент и трудовые отношения
Вид дипломная работа
Язык русский
Дата добавления 04.12.2019
Размер файла 1,7 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Определение критериев для ServiceDesk системы и ее внедрение.

Подбор и расстановка персонала на соответствующие должности.

Внедрение системы отчётностей и культуры анализа результатов.

Выводы по главе II.

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

Для достижения этой задачи была дана технико-экономическая характеристика ООО «Таймбук». Была изучена история компания, предметная область деятельности компания, проведен анализ рынка на всех этапах роста компании и внутренняя структура компании.

Была проанализирована система управления ООО «Таймбук» на примере отдела клиентского сервиса. Для этого был проведен опрос всех специалистов и руководителей отдела. Выявлены процессы внутри отдела. Выявлены индикаторы результативности и эффективности отдела до проведения организационных изменений.

ГЛАВА III. Разработка проекта развития отдела клиентского сервиса в компании ООО «Таймбук»

Проект организационного развития отдела клиентского сервиса в компании ООО «Таймбук»

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

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

Задачи проекта:

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

Реализация задач отдела для достижения краткосрочной цели.

Анализ эффективности организационных изменений.

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

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

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

Стратегия достижения краткосрочной цели:

Подготовить платформу для масштабирования отдела в 2 раза за год.

Определить необходимый основным клиентам уровень поддержки и адаптировать процессы для соответствия ему.

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

Задачи в рамках отдела клиентского сервиса:

Определение основных внутренних процессов в отделе. Определение индикаторов результативности и эффективности для процессов.

Определение новой структуры отдела, должностей и должностных обязанностей согласно методологии ИТИЛ.

Определение внутренних нормативов и SLA.

Транслирование индикаторов результативности и эффективности на должности в рамках процессов.

Определение критериев для ServiceDesk системы и ее внедрение.

Подбор и расстановка персонала на соответствующие должности.

Внедрение системы отчётностей и культуры анализа результатов.

ИТИЛ - библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей «эффективности» (KPI), а также на ресурсах, затраченных на достижение этих целей. Википедия, свободная энциклопедия. https://ru.wikipedia.org/wiki/ITIL

Соглашение об уровне предоставления услуги (англ. Service Level Agreement, SLA) -- термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Википедия, свободная энциклопедия. https://ru.wikipedia.org/wiki/SLA

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

Определение основных внутренних процессов в отделе клиентского сервиса и их индикаторов результативности и эффективности.

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

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

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

Для процесса технической поддержки результативностью будет соответствие установленному внутреннему нормативу. Все заявки должны решать вовремя и реакция на них должна быть своевременной. Приемлемым процентом отклонения будет считаться 85-90%. Так как система только внедряется и сразу строгие требование будут порождать недовольства сотрудников, они могут саботировать процесс организационных изменений. Сначала нужно приучить работать по правилам, потом ужесточать правила. Для проверки процента отклонения от нормативов есть специальные отчеты в ServiceDesk системе. Это одно из требований к системе. Еще одним показателем результативности технической поддержки является соответствие качеству обслуживания. Этот параметр определяется по двум показателям: качество телефонных разговоров и индекс удовлетворенности клиента. Качество телефонных разговоров определяется путем прослушивания случайных разговоров каждого специалиста и оценки его по чек-листу. Чек-лист оценивает корректность и компетентность специалистов при общении с клиентами. 90% считается отличным результатом. Более низкий результат - пища для размышлений и работы со специалистами. Чек-лист оценки качества телефонных разговоров приведен в приложении 5. Индекс удовлетворенности клиента более сложный показатель. Для его подсчета мало простого опроса клиентов. Это будет не релевантный показатель. Необходимо обучать пользователей и собирать метрики удовлетворённости разными способами нарезных этапах работы. Поэтому внедрение этого показателя будет после первой волны организационных изменений.

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

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

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

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

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

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

Консолидированная таблица обновленных индикаторов результативности и эффективности приведена в приложении 6.

Согласно библиотеке ИТИЛ, классической организацией технической поддержки является разделение ее на 3 линии. Главный критерий распредели заявки на линию - это цена решения. Чем ниже линия, тем дешевле цена решения заявки. Это не всегда легкая заявка, это означает, что специалист первой линии знает, как ее решать. Решение описано и стандартизировано. Специалисты первой линии имеют малую стоимость часа работы, поэтому и решение заявки считается дешевым. Специалисты третьей линии самые дорогие. Для эффективной работы технической поддержки до третьей линии должно доходить как можно меньше заявок.

Рекомендованная структура отдела технической поддержки представлена на рисунке 1 и продублирована в приложении 7.

Рисунок 1. Структура технической поддержки.

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

Звонок от пользователя,

Письмо на почтовый ящик

Самостоятельное заведение заявок пользователем на сайте.

Здесь важно понимать значимость заведения абсолютно всех заявок. Для полной прозрачности процесса технической поддержки и возможности видеть динамику. Нельзя работать над результативностью и эффективность, если нет цифр результатов работы процесса. К сожалению, на момент первой аналитики процесса технической поддержки в компании ООО «Таймбук» не велась статистика вообще. Поэтому важно было ввести культуру работы с заявками. Каждый звонок пользователя должен быть заведен в систему. Любая консультация. Даже минутная. Большинство клиентов оставляют заявки на электронную почту. Первым действием специалистов должно стать заведение всех заявок из электронной почты в ServiceDesk систему. Далее этот процесс должен быть автоматизирован. Здесь не все просто, так как есть разные шаблонны ответов разным клиентам. Подробнее о процессе внедрения системы будет расписано в главе 3.2. Самостоятельное заведение заявок пользователями - это последний шаг внедрения культуры работы с заявками. С этим нельзя торопится. Так как интерфейс должен быть максимально понятный пользователю. Он должен безобидно понимать свои действия. Для этого необходимо накопить опыт работы с систему в качестве специалиста и администратора. Определить характеристики для заявок и маршрутизацию их распределения. Адаптировать под требования специалистов, руководителей и потом адаптировать под пользователей. Иными слова, сначала нужно внедрить культуру работы с заявками сотрудникам и руководителям, потом пользователям. В противном случае пользователи либо не будут пользоваться каналом самостоятельного заведения заявок, либо будут путаться и специалистам придется делать двойную работу. Пусть лучше пользователи пишут письма, а специалисты заводят заявки. Правильно и качественно. Так как на обучение пользователей тоже тратится ресурс. Не стоит распыляться сразу на все. Лучше удешевить ресурс, который заводит заявки.

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

Принимать звонки и заводить заявки из почты.

Консультировать по однозначно описанным в инструкциях заявкам.

Решать остальные заявки, если нет работы по первому и второму пункту.

Самый долгий временной ресурс, это смена контекста. Первая линия должна в первую очередь освободит специалистов второй линии от постоянных отвлеканий. Специалисты второй линии более квалифицированные и опытные сотрудники. Цена решения заявки увеличивается, когда она переходит на вторую линию. Поэтому необходимо максимально много заявок решать на первой линии. Где более дешёвые специалисты, за счет их меньшей квалификации. Для этого необходимо описывать все однозначно решаемые задачи и всегда пополнять инструкции. Если заявка не решается в течении 20 минут и есть очередь новых заявок, то заявку нужно переводить на вторую линию. Для первой линии необходимо всегда анализировать длину очереди заявок. Время реакции на заявку должно быть индикатором результативности работы. Так же необходимо всегда анализировать количество решаемых заявок на первой линии и увеличивать этот показатель. Тем самым удешевлять решение заявки. И разгружать вторую линию. На начальном этапе целью для первой линии решено обозначить решение 5% всех решаемых заявок. График работы специалистов первой линии: первый день в дневную смену по 12 часов, второй день в ночную смену по 12 часов, третий и четвертый день - выходной. Графики специалистов будут сменяться. Таким образом 4 человека будут оказывать поддержку 24 часа 7 дней в неделю. Статистика активности пользователей показывает, что основное количество заявок создается с 7 утра до 20 часов вечера. Поэтому смены будут начинаться в 6:30. Что бы новый специалист успел выйти на рабочее место и подготовится к активной работе.

Специалисты второй линии должны заниматься нетривиальными заявками. И наполнять базу знаний новыми инструкциями, скриптами, чек-листами. Иными словами, переводить заявки из статуса «нетривиальная» в статус «однозначно решаемая заявка». Не все заявки этому поддаются. Но всегда нужно анализировать заявки на такую возможность. Важно написание именно скриптов или однозначных инструкций. Что бы заявка решалась за 20 минут и менее квалифицированным специалистом. Для определения точных целей результативности второй линии необходимо собрать первую статистику и сформировать понимание объема заявок и скорости их решения. Для ориентира следует остановится на 65% всех заявок. Время реакции и время решение заявок будет более детально определено в таблице внутренних нормативов. В том числе на основе выполнения требований внутренних нормативов будет высчитываться результативность и эффективность отдела, считаться премия специалистам. Специалисты второй линии работают по будням. С 9 часов до 18. Когда самый активный поток заявок.

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

Так же в обязанности второй линии будет входить обучение. На данном этапе внедрения обучение просто будет отдельной заявкой у которой есть требования по времени исполнения. Выделять под отдельные показатели результативности нет необходимости.

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

Под процесс ведения первичной бухгалтерии и документооборота с клиентами будет выделены два специалиста. Для разделения информационных потоков специалистов и минимизации большого объема уникальной информации у разных специалистов. В течении 2х месяцев все специалисты вели таблицу с затратами временного ресурса на ведение первичной бухгалтерии и документооборота на своих клиентах. Получилось более 600 документов и 200 часов работ в месяц. Если усреднить, то это около 9 часов работы в день. Два специалиста имеют 16 часов работы в день. Оставшийся профицит времени будет переведен на помощь в решении заявок в дни высокой загруженности по заявкам. Два специалиста нужно не только по причине большого объема работы, но и для резервирования ресурса в дни больничный, отпусков. Важно понимать, что в ведении первичной бухгалтерии есть дни высокой активности. Это периоды выставления счетов, закрытия документов и прочее. Важной частью работы специалистов так же будет аудит всех действующих клиентов. А также всех клиентов, переходящих из отдела внедрения. Вопрос документооборота и первичной бухгалтерии важен для чистоты документов перед отчетными государственными органами. Решение с двумя специалистами временное. После выполнения ряда условий, второго специалиста можно полностью или частично загружать дополнительными функциями.

Что нужно сделать, для оптимизации временного ресурса документооборота и первичной бухгалтерии:

Структурировать и систематизировать ведение договоров и первичной бухгалтерии по всем клиентам.

Полностью перейти на логирование всех работ в виде заявок в ServiceDesk системе.

Провести аудит на всех клиентах и составить четкую форму аудита с инструкциями.

Перевести всех возможных клиентов на электронный документооборот и ведение закрывающих документов.

Организационные изменения должно двигаться постепенно. Что бы люди привыкали работать по-новому и с новыми инструментами. Что бы сотрудники и руководители привыкли жить по новым правилам. Все и сразу поменять не получится. Поэтому и документооборот будет реформироваться в несколько этапов.

Требования к качеству обслуживания должны быть агрегированы в единый документ. Этот документ будет представлять внутренние нормативы оказания технической поддержки. Глобально, этот документ определяет время реакции и время решения разной категории заявок и разного приоритета. Нормативы для технической поддержки компании ООО «Таймбук» представлен в приложении 8. Нормативы представляют из себя набор таблиц. Для каждой категории заявок определяется таблица приоритетов. Всего три вида приоритетов: критичный, высокий и обычный. Специально исключен низкий приоритет и добавлен критичный. Для каждого вида приоритетов свое необходимое время реакции на заявку и время решения заявки. Время реакции определяет промежуток времени, за который заявка перешла в статус «в работе». Это время от создания заявки до взятия в работу. То есть время, которое пользователь ожидал реакции на свою заявку. Время решения определяется момента первого перевода из статуса «в работе» в статус «решена». Время реакции и время решении заявок для всех видов приоритетов приведено в таблице 7.

Таблица 7 - Время реакции и время решении заявок для всех видов приоритетов

Время на реакцию и решение запроса

SLA

Критичный

Высокий

Обычный

Время реакции

до 10 мин

до 1 часа

до 2 часов

Время решения

до 4 часов

до 12 часов

до 48 часов

Если заявка типа «инцидент», то ей выбирается подтип. Если заявка типа «инцидент» и подтипа «доступ», то ей присваивается критичный приоритет. Для подтипа «карты» присваивается высокий приоритет. Для типа «консультации» и подтипа «документооборот» присваивается обычный приоритет. Все типы и подтипы заявок приведены в приложении 4. Согласно внутренним нормативам технической поддержки, время реакции на высокий приоритете составляет 1 час. Соответственно, специалист должен взять заявку в работу за 1 час после ее заведения. Взять в работу - это означает сменить заявке статус из «открыто» в «в работе». Пользователю, оставившему заявку, на почту приходит сообщение об изменившемся статусе. Если специалист оставит какие-то комментарии в заявке, то пользователю придет этот комментарий. Это необходимо для прозрачности ведения заявок клиента. Далее специалист выполняет свою работу по задаче. Для «инцидента» с высоким статусом задачу нужно выполнить за 12 часов. Согласно приоритету определяется время реакции и решения для каждой заявки. Такие сроки -- это индикаторы результативности процесса оказания технической поддержки, поэтому и индикаторы результативности специалистов должны ориентироваться на эти требования. Премиальная часть специалистов должна отражать выполнение этих требований. Специалист должен успевать реагировать и решать заявки в установленные временные рамки. Если специалист не успевает решать заявки в уложенные рамки, то это будет выявлено в соответствующем отчете. И скорректирована премия сотрудника. Если это происходит систематически и в достаточном объеме - с сотрудников необходимо беседовать. Если нет динамики изменений после бесед, то решать вопрос более кардинально. Переводить на другую должность или увольнять. Возможно применение других санкций по ситуации. Специалисты каждой линии поддержки должны иметь свои сроки реакции и решения. Для каждой линии разные. У первой линии более простые задачи. Поэтому время реакции и решения меньше, чем во второй. Но на первом этапе внедрения изменений внутренние нормативы будут одинаковыми для всех линий. После сбора полной статистики за несколько месяцев и привыкания сотрудников работать по внутренним нормативам, можно вводить новые изменения. Но только в том случае, если сотрудники привыкли работать с ServiceDesk системе и новые изменения действительно необходимы.

Каждой сервисной компании необходимо иметь свой SLA. В SLA прописывается уровень оказания услуг и период доступности. Период доступности - это все время оказания услуг, за исключением штатного времени профилактических работ на серверах. Время периода доступности согласовывается с клиентом. Неработоспособность сервиса во время профилактических работ допускается требованиями SLA. За остальные периоды простоя клиенту уплачиваются штраф, определенный в SLA. Многие крупные клиенты требуют подписывать SLA. Для оптимизации внутренних процессов каждая сервисная компания должна иметь свой универсальный SLA, удовлетворяющий требованиям клиентов на рынке. Универсальный SLA компании ООО «Таймбук» был разработан в рамках проекта организационных изменений. Он является интеллектуальной собственностью компании и коммерческой тайной. В рамках проекта рассмотрим только его часть, отвечающую за уровень компенсации, в случае сбоев предоставления сервиса. Уровень компенсации из универсального SLA представлен в таблице 8.

Таблица 8 - Уровень компенсации в универсальном SLA.

Обеспечение доступности (Д) (% в месяц)

Размер штрафных санкций*

99,44 > Д ? 99,16

5%

99,16 > Д ? 98,88

7%

98,88 >Д ? 96,66

10%

96,66 >Д ? 93,33

12%

93,33>Д

15%

* процент от платы Заказчика за Объект, в котором произошел Инцидент и в котором не обеспечивался гарантированный уровень Доступности в период (1 календарный месяц).

Доступность рассчитывается по формуле:

Д=(То-Тн)/То*100 , где:

Д - коэффициент доступности

Тн - время недоступности сервисов сайта, час. Без учета времени простоя, связанного с техническим обслуживанием

То - общее время в месяц, час.

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

Для агрегации всех заявок, ведения базы знаний и контроля внутренних нормативов, необходимо внедрить инструмент ServiceDesk. Критерии для выбора инструмента были определены исходя из анализа внутренних процессов отдела, рекомендаций ИТИЛ и опроса сотрудников компании. Критерии представлены в приложении 9.

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

Определим план внедрения, согласно предложенным рекомендациям:

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

Внедрить новые внутренние нормативы

Перестроить мотивацию сотрудников согласно индикаторам результативности и эффективности

Внедрить ServiceDesk систему

Внедрение системы отчётностей и культуры анализа результатов

Аккумулировать основные шаблоны базы знаний и запустить процесс написания инструкций и чек-листов

3.2 Внедрение проекта развития отдела клиентского сервиса в компании ООО «Таймбук»

Реализация предлагаемых в проекте решений началась в ходе написания выпускной работы. Она включала следующие этапы: подбор и расстановка персонала на соответствующие должности в рамках новой структуры отдела клиентского сервиса; внедрение новых внутренних нормативов и SLA; изменение мотивации сотрудников согласно индикаторам результативности и эффективности; внедрение ServiceDesk системы; внедрение системы отчётностей и культуры анализа результатов; создание основах шаблонов базы знаний и запуск процесса написания инструкций, и чек-листов.

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

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

Уверенное владение MS Word и MS Excel. Специалисты часто строят отчет и ведут статистику. Умение работать с офисными программами существенно повышает эффективность работы. Отдельно важно понимать, что умение работать с MS Excel существенно упрощает процесс вливание работу и понимания технического продукта. Сайт «timebook.ru» это технический продукт.

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

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

Поскольку компания ООО «Таймбук» сразу предлагала условия оплаты труда чуть выше рыночных, поток соискателей был стабильный и было из кого выбирать. Но и работа была сложнее обычного регламентированного центра технической поддержки. Были отобраны 4 специалиста. Разработан план обучения. Обучение специалистов заняло один месяц с еженедельным тестированием, и итоговым экзаменом. Все претенденты справились. Далее был выход работы по графику и постепенно работа начала стандартизироваться. Остальные специалисты перестали принимать звонки и обрабатывать входящую почту. Конфликты в отделе утихли. Все заявки стали заводится в ServiceDesk систему. Ранее работавшие специалисты перешли на вторую линию и документооборот. Один из самых опытных специалистов взял на себя функции администратора. Позиция администратора была самой сложной, так как найти человека со стороны и обучить работать с продуктом на уровне опытного специалиста было невозможно. Поэтому выбор был сделан в пользу опытного сотрудника, желающего повышения. Так же с ним были обговорены новые задачи и полномочия.

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

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

Переход на новую структуру прошел в плановом режиме и достаточно безболезненно.

Новые нормативы были разработаны и описаны в пункте 3.1 и приведены в приложении 8. Новая структура отдела и ориентированные на внутренние нормативы ключевые показатели эффективности позволили увидеть реальную картины работы отдела. В ведении заявок и построении отчетов помог внедренный ServiceDesk. Его критерии приведены в приложении 7. Описание критериев выполнено в пункте 3.1. Итоговый отчет по специалистам приведен в приложении 10. Переход на новые требования оказания услуг перед клиентами был безболезненным. Потому что инциденты возникали и ранее, а сейчас они регламентировались. Клиенты без проблем приняли новые требования. Переход на новые требования обработки заявок в рамках внутренних процессов был не так легок.

Мотивация сотрудников одна из главных тонкостей в работе компании. А изменение мотивации еще более сложный процесс. Материальная мотивация в процессе организационных изменений не должна меняться в более низкую стороны, тогда сотрудники не будут воспринимать изменения отрицательно и не будут саботировать процесс. Поэтому первый месяц все специалисты получили полную премию и отчет по допущенным ошибкам в работе. Основные проблемные места были в качестве звонков. Поскольку проверка качества звонков никогда не проводилась, специалисты не сразу понимали, как правильно действовать, а администратор не понимал, как правильно проверять. Совместный разбор ошибок дал результат и в третьем месяце специалисты выполняли оценку на 85% и более. Процесс решения заявок так же выявил много несостыковок. Система неправильно считала, потому что отчет нужно было до настроить. Специалисты неправильно заполняли заявки. Все эти доработки системы ведения заявок и построения отчетов не позволяли пользоваться системой для полного точного определения ключевых показателей эффективности. Пока показатели собирались неправильно специалистам платилась полная премия. Отчет по выполнению внутренних нормативов скорректировал ее в меньшую сторону. Но специалисты понимали, что им нужно делать для получения полной премии и процесс был нормализирован.

Премия для сотрудников первой линии зависит от 4 ключевых показателе эффективности. Процент принятых звонков не должен быть ниже 95%. Статистика по проценту пропущенных вызовов собирается автоматически в личном кабинете поставщика услуг виртуальной телефонии. Оценка качества телефонных разговоров должна быть не ниже 80%. Чек-лист проверки качества телефонных разговоров представлен в приложении 5. Специалистам первой линии ставятся отдельные задачи в ночные смены. Составить большой табличный отчет, ручное распознавание фотографий сотрудников клиентов, с которыми не справляется машинное распознавание и разные другие задачи. Половина премии зависит от выполнения внутренних нормативов оказания технической поддержки. Нормативы приведены в приложении 8. Структура премии специалистов первой линии приведена на рисунке 2.

Рисунок 2. Структура премии специалистов первой линии.

Премия для сотрудников второй линии зависит от 3 ключевых показателе эффективности. Оценка качества телефонных разговоров должна быть не ниже 80%. Специалисты второй линии так же общаются с клиентом и являются лицом компании в глазах пользователей. Чек-лист проверки качества телефонных разговоров представлен в приложении 5. Половина премии зависит от выполнения внутренних нормативов оказания технической поддержки. Нормативы приведены в приложении 8. Треть премии определяется успешностью выполнения задач, напрямую оставленных руководителем отдела. Это может быть помощь по ведению клиента, это могут быть более сложные отчеты по клиенту, написание инструкций и другие задачи. Премия зависит от качества выполнения задач. Задачи обговариваются в начале месяца и оцениваются в середине и конце месяца. Структура премии специалистов второй линии приведена на рисунке 3.

Рисунок 3. Структура премии специалистов второй линии.

Премия для администратора зависит от 4 ключевых показателе эффективности. Поскольку основные задачи администратора - помогать руководителю контролировать процесс оказания технической поддержки, то и ключевые показатели эффективности транслируются с показателей специалистов. Процент принятых звонков специалистами. Нужно помогать специалистам принимать звонки в моменты наплыва клиентов. Работать над качеством разговоров специалистов с клиентами, если у специалистов показатели ниже 80%. Поэтому качество разговоров специалистов является актуальным показателем и для администратора. Половина премии администратора зависит от выполнения внутренних нормативов всей технической поддержки. Администратор должен подстраховывать специалистов в моменты большой волны заявок и контролировать оптимизировать процессы решения заявок в рамках нормативов. Четверной показатель - ведение отчётности. Показатель появился в процессе внедрения, так как администратор не успевал вести все отчеты, а предпочитал самостоятельно решать заявки. Это не эффективно на дистанции. Структура премии администратора приведена на рисунке 4.

Рисунок 4. Структура премии администратора технической поддержки.

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

Рисунок 5. Структура премии специалиста по ведению документооборота и первичной бухгалтерии.

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

Самое сложное во внедрении новой системы - правильно определить критерии выбора. Определение требований к системе сложный процесс. На рынке много разного инструментария. Задачи ServiceDesk решает разные. Определением необходимого функционала при внедрении крупного ServiceDesk-решения занимаются аналитики, а само внедрение сложный и дорогой процесс. В небольших компаниях с этим проще. На рынке есть ряд готовых решений. Для понимания возможностей инструментов на рынке были заказаны презентации у основных представителей рынка ServiceDesk решений. Далее необходимо определить для ведения каких процессов нужен ServiceDesk. Какие задачи решаются в рамках процесса и какие необходимо автоматизировать. Все автоматизировать нельзя, это дорого и долго. Поэтому анализ процессов, анализ проблем этих процессов и анализ возможностей ServiceDesk систем позволил составить таблицу с критериями для выбора системы. Далее эти критерии были отсортированы по уровню значимости. Далее было подобраны разные производители ServiceDesk решений. У каждой системы был заявленный функционал и стоимость лицензии. Были отброшены все инструменты, которые не имели значимого функционала. Остальные сравнивались по цене, удобству интерфейса и скорости внедрения. Удобство интерфейса оценивалось после тестирования работы сервиса каждым специалистом. Итоговая оценка удобства представляла усреднённую сумму субъективных оценок каждого специалиста. Мнение специалистов важно при выборе системы. Так как им пользоваться этой системе. Когда специалисты понимают, что сами выбирали продукт, они меньше саботируют его использование. Это важно на этапе внедрения новых инструментов. Самый подходящий ServiceDesk имел приемлемую стоимость лицензии, понятный и удобный пользовательский интерфейс, и максимально подготовленные алгоритмы работы, и отчеты. Так как итоговый ServiceDesk позиционировался именно для рынка «бизнес для бизнеса». Это сильно упросило процесс внедрения и адаптации. Самостоятельно пришлось настроить только нормативы по каждому типу и подтипу заявок. А также внести в базу всех клиентов. Этот процесс был постепенным и прошел максимально штатно. Все технические интеграции были выполнены в течении недели. Только настройка авто заведения заявок, приходящих на электронную почту, немного затянулось. Потому что разные клиенты писали на разные электронные адреса. Это вызвало сложности в настройке. Еще больше сложностей вызвала настройка исключений авто заведения заявок при получении обращений от некоторых клиентов. Процесс внедрения стоит считать быстрым и эффективным.

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

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

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

Для систематизации знаний были выполнены следующие шаги:

Единым интерфейсом для ведения базы знаний был признан ServiceDesk.

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

Заявки определенных типов могут сразу иметь ссылки к нужным инструкциям. Сразу иметь ссылки на документацию по нужному клиенту. Это существенно упрощало писк информации по клиенту.

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

Мотивация сотрудников и руководителя была ориентирована на эффективность. Ведение инструкций позволяло повышать эффективность.

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

3.3 Анализ эффективности результатов внедрения проекта

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

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

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

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

Четких организационных показателей так же выделить не получилось. Есть важные показатели результативности и эффективности каждого процесса в отделе клиентского сервиса. Но все они были четко определены только в рамках проекта организационных изменений. Ранее их сбор и аналитика не проводились. До проекта организационных изменений никак не велась и не анализировалась активность в рамках процессов. Не было статистики по обработанным заявкам технической поддержкой. Не было таблиц по основной деятельности документооборота и первичной бухгалтерии. Обучение проводилось без каких ли записей и ведения статистики. Даже статистика по входящим звонкам не велась. Поэтому никакие основные показатели результативности, которые начали использоваться в рамках проекта не могут быть сравнимы.

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

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

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

С коммерческим директором был проведен повторный опрос для оценки системы управления реформированного отдела. Опрос проводился после 3 месяцев успешного внедрения. Ответы и оценки разбиты по блокам и приведены в таблицах 9-12. Критерии оценок описаны в таблице 1.

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

Таблица 9 - Оценка проработанности вопросов блока программирование на начало и конец проекта.

Вопрос

Оценка на начало

Оценка на конец

Мы понимаем какая первостепенная цель существования отдела клиентского сервиса?

1

3

Мы понимаем какие измеримые и конкретные цели стоят перед отделом в краткосрочной перспективе?

1

3

Мы понимаем какие измеримые и конкретные цели стоят перед отделом в долгосрочной перспективе?

1

3

Мы понимаем конкретный путь для достижения целей?

1

3

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

1

3

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

Далее коммерческий директор оценивал степень проработанности вопросов блока проектирования. Оценки на начало и конец проекта приведены в таблице 10.

Таблица 10 - Оценка проработанности вопросов блока «проектирование» на начало и конец проекта.

Вопрос

Оценка на начало

Оценка на конец

Мы можем измерить процесс и результат работы?

1

3

Наша работа построена на основе оптимально подобранных и понятных всем методах и технологиях работы?

2

3

У нас есть ясное согласованное представление о порядке и очередности работы в рамках процессов?

2

3

У нас четко определены сферы ответственности и должностные обязанности?

2

4

И в данном случае коммерческий директор так же положительно оценивает все вопросы блока проектирования. Для него стали прозрачны основные процессы отдела клиентского сервиса. Понятны и логичны индикаторы результативности и эффективности процессов. Внедрены новые методы работы и качественно подобранный инструмент ServiceDesk. Ответственности и должностные обязанности качественно определены, по мнению коммерческого директора. Коммерческий директор не ставит максимальную оценку в 4 балла по причине необходимости второй волны организационных изменений. В рамках нее необходимо будет снова анализировать процессы отдела клиентского сервиса и мигрировать их с процессами отдела внедрения.

В таблице 11 представлены оценки коммерческого директора проработанности уровня «сценирования» на начало и конец проекта.

Таблица 11 - Оценка проработанности вопросов блока «сценирование» на начало и конец проекта.

Вопрос

Оценка на начало

Оценка на конец

У наших лидеров (на разных уровнях) достаточно полномочий для реализации инициатив?

4

4

Мы умеем успешно работать вместе как единая команда?

3

3

У нас достаточная профессиональная квалификация?

2

3

Мы достаточно опытны в решении таких задач, что стоят перед нами сейчас?

3

3

У нас отлажена система коммуникаций и принятия совместных решений?

2

3

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

Оценка проработанности вопросов блока администрирования на начало и конец проекта приведена в таблице 12.

Таблица 12 - Оценки проработанности вопросов блока «администрирование» на начало и конец проекта.

Вопрос

Оценка на начало


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.