Считаем лайки в реальной жизни или как правильно оценить сотрудника (концепция)

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

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

• массовость (масштабируется по мере роста компании)
• отсутствие субъективизма экзаменатора
• непрерывность бизнес-процессов (тестирование занимает не более 15 минут, что легко реализуется в рабочее время)
• географическая распределенность (тестирование в удаленных филиалах не требует особой организации, кроме стабильного VPN)

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

Как оценить отношение клиента к сотруднику?

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

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

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

Требования к системе

Итак, мы приходим к выводу, что в нашей идеальной системе должно все должно строиться на максимальной автоматизации всего процесса. При этом система должна обеспечивать разумный уровень защиты, который не позволит рядовому сотруднику исказить результаты, но при этом не усложнить чрезмерно процесс оценки (рассказ про хакера и солонку ^[1] все помним?). В качестве дополнительных требований добавим кроссплатформенность (работа серверной части на Linux позволит сэкономить на лицензиях), web-интерфейс на конечных терминалах (позволяет использовать практически что угодно от планшетов до моноблоков), нормальная SQL-база данных (даст нам возможность создавать произвольные запросы, формируя необходимую статистику). Система должна быть предельно проста в обращении для конечного пользователя. Сюда же добавим все вышеперечисленные пункты связанные с масштабируемостью.

Архитектура

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

• Ядро системы — обеспечивает логику всего комплекса и взаимодействие его элементов
• SLQ-база данных — хранит и структурирует весь накопленный материал
• Web-интерфейс — служит для подключения терминальных модулей и взаимодействия с ядром системы
• Терминальная часть на регистратуре/ресепшене — позволяет выводить на печать те самые листки для голосования
• Терминальная часть для голосования — позволяет выразить свое отношение к обслуживающему сотруднику и дать развернутый комментарий при необходимости
• Терминальная часть аналитика — для доступа руководителя/аналитика к результатам

Пример использования

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

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

В QR-коде имеется следующая информация:
3390537f980fbbc21eaf7da54b1e909b;12F2AA, где первая часть md5-hash от идентификатора сотрудника + соль, а вторая уникальный идентификатор приема, по которому из базы можно вытащить всю информацию, включая ФИО пациента и другие данные. Таким образом, сотрудник не сможет подделать голосование. Каждый код уникален и может быть использован один раз.

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

Единственное дополнение — вебкамера, встроенная в моноблок или отдельная.

Когда пациент подносит листок с QR-кодом к веб-камере, на экране появляется фотография сотрудника, краткое его описание (ФИО, должность), крупные кнопки понравилось/не понравилось, небольшие кнопки для того, чтобы оставить отзыв и получить справку. Экран сенсорный и клавиатура задействуется только для ввода развернутого отзыва/жалобы. Этим достигается минимализм и простота для клиента.

Аналитик подводит итоги с определенной периодичностью и получает следующую информацию:

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

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

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

Резюме

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

Автор: Meklon

Источник ^[2]