С ростом организации клубок чатов, почтовых ящиков и телефонных звонков затягивается на шее обеспечивающих подразделений. Гордиев узел можно распутать созданием единого окна заказов, но традиционные подходы и неформальные связи редко удаётся упорядочить изданием одного приказа.
И если крупные компании способны приобретать плоды трудов известных вендоров за многозначные суммы в иностранной валюте, то небольшим игрокам спасаться значительно сложнее. Вместе с учеником «Школы траблшутеров» Ильёй Куклиным расскажем, как разработали и внедрили Хелп Деск на платформе CRM.
Начали созданием карты маршрутов — схемы централизации единого окна заказов:
категории обозначили оранжевым жёлтым отметили созданные схемы и таблицы красным — направления широкой вариативности без необходимости жёсткого планирования: Рис. 0. Схема централизации управления Хелп Деском
Путь в Хелп Деск проложили от производственной надобности или отклонения в процессе. Решили проследить, чтобы коллеги знали куда и по какому поводу следует обращаться в непонятной и непредвиденной ситуации:
Рис. 1.1.1. Схема обработки и трансформации заявки в процесс. Сотрудник
Обращение фиксируем в CRM и ставим в очередь ожидания для последующего распределения на освободившегося сотрудника. Балансируем автоматический подсчёт трудочасов по заявкам и начислению заработной платы по объёмам выполненных работ:Рис. 1.1.2. Схема обработки и трансформации заявки в процесс. CRM
После принятия в работу запускаем обратный отсчёт времени, чтобы автор и исполнитель были равнозначно заинтересованы поскорее разобраться с проблемой или решить вопрос:Рис. 1.1.3. Схема обработки и трансформации заявки в процесс. Сотрудник
Предусмотрели ситуации недопонимания: учитываем и закладываем возможность проверки и доработки заявки:Рис. 1.1.4. Схема обработки и трансформации заявки в процесс. Сотрудник
Успешное выполнение поручения — первый уровень регулярного барахтанья в текучке. Было бы разумно интересоваться данными, анализировать и дифференцировать случайные препятствия от систематически повторяющихся, поэтому силами процессных экспертов выявляем и формализуем повторяющиеся сложностиРис. 1.1.5. Схема обработки и трансформации заявки в процесс. Эксперт по процессам
Схему обработки и трансформации заявки в процесс декомпозируем в таблицу, определяем SLA, рабочее время и нормо-часы, описываем условия преобразования задачи в понятные программной среде формулы:Рис. 1.2. Таблица планирования SLA, рабочего времени и нормо-часов
Конфигурируем бизнес-процесс (БП) в Битрикс 24, используем доступный функционал облачной версии. Для отделов создаём разделы, для типов заявок предусматриваем набор стандартных модулей:Рис. 2.1.1. Конфигурирование БП в CRM. Общая схема. Часть 1
Проектируем интуитивно понятную логику работы, стремясь обеспечить доступную простоту и высокую скорость обслуживания: нахождение специалистом требуемого места ветвления занимает секунды:Рис. 2.1.2. Конфигурирование БП в CRM. Общая схема. Часть 2
Подобно главам книги размечаем отделы, подписываем человекочитаемыми названиями:Рис. 2.1.3. Конфигурирование БП в CRM. Общая схема. Часть 3
Закладываем возможность дальнейшей модернизации разумными усилиями:Рис. 2.1.4. Конфигурирование БП в CRM. Общая схема. Часть 4
Финальную часть всех процессов замыкаем на сбор статистики, аудит и работу над ошибками:Рис. 2.1.5. Конфигурирование БП в CRM. Общая схема. Часть 5
На примере отдела аудита проектируем модули типовых заявок, демонстрирующих роли и сценарии поведения участников и наблюдателей, с фиксацией времён привязки задачи, реагирования и отчётности. Предложенный подход позволяет быстро модифицировать только изменившиеся данные:Рис. 2.1.6. Конфигурирование БП в CRM. Общая схема. Отдел аудита
Участников заявок предусмотрительно разделили на две группы: кто принимает участие в стандартном распределении и список тех, кого случайным образом выберет CRM, если заявку не взяли в работу типовым образом за установленное время:Рис. 2.1.7. Конфигурирование БП в CRM. Общая схема. Участники заявки
Исключая путаницу, для отделов создали группы и подключили участников к папкам ролей:Рис. 2.2. Создание и настройка рабочих групп отделов
Предусмотрели фильтрацию для дальнейшего анализа через критерии генерации выборки данных:Рис. 2.3. Подготовка фильтров для отбора тикетов по критериям
Спроектировали интерфейс запуска заявки с полями подстановки логина и пароля для удалённого доступа через TeamViewer. Используем типовые подсказки для уменьшения время поиска желаемого раздела:Рис. 3.1. Интерфейс создания заявки
Классификатором типов разбили иерархию компании на модули отделов, название заявки собираем по интуитивно понятному шаблону: «Номер отдела. Название отдела _ Номер категории. Название категории _ Номер типа заявки. Тип заявки»:Рис. 3.2. Классификатор типов тикетов
Для принятия очередной заявки в работу отображаем список назначенных, с возможностью ознакомления и выбором: взять в работу, отменить, назначить ответственного вручную:Рис. 3.3. Список заявок для взятия в работу свободными сотрудниками
Встроенными средствами отображаем карточку заявки с выбором целевых действий:Рис. 3.4. Карточка выбора заявки для взятия в работу
На странице тикета выводим исчерпывающую информацию о состоянии и изменениях:Рис. 3.5. Карточка заявки
Через настраиваемое отображение списка показываем сегмент, выбранный для аналитики:Рис. 3.6. Отфильтрованный список заявок
Взятием в работу создаём задачу с отображением в списке группы отдела:Рис. 3.7. Список задач подразделения
Далее с заявкой работают как с обычной задачей в понятном и привычном интерфейсе:Рис. 3.8. Задача на основе заявки
Для поиска отклонений импортируем данные в Excel и создаём сводную таблицу:Рис. 4.1. Сводный отчёт в Excel по просроченным задачам
Для уменьшения времени на анализ используем шаблон подсчёта нормо-часов...Рис. 4.2. Шаблон для импорта данных и подсчёта долевого участия
... необходимого для расчёта вознаграждения работников:Рис. 4.3. Дэшборд исполнительной дисциплины подразделения
Вот так без лишней помпы, флагов и транспарантов, разработали и внедрили Хелп Деск для небольшого заказчика. В процессе работы думали не о размере текущего проекта, а о том, чтобы построить масштабируемую модель, подходящую и для компаний гораздо более крупного размера.
По итогу расчёта окупаемости оказалось, что на деньги текущего клиента создали подход, не требующий значительных доработок в будущем, значит, дело за малым: станем тиражировать полученный опыт, оттачивая мастерство заведения сотен производственных ниточек в единое игольное ушко.
Читайте также:
Как житель Серпухова создает российский рынок каноэ
Как обычная подмосковная шаурма стала легендарной, выросла в сеть и уперлась в тупик
Как небольшая компания из России помогает армии США, Google и UEFA моделировать реальный мир
Как определить стадию роста своего стартапа: урок от инвестора