Рабочее место менеджера в ERP-системе
Спроектировала интерфейс рабочего пространства менеджера поддержки во внутренней ERP-системе, что помогло сократить время обработки −10%, время до первого действия −7%, обращения к наставникам −61%

Контекст
Менеджеры поддержки ежедневно обрабатывали поток клиентских обращений во внутренней ERP-системе на базе 1С. От скорости и точности их действий зависели качество сервиса, нагрузка на наставников и операционные показатели отдела
Рабочее место складывалось из карточки клиента, истории коммуникаций, статусов, служебных действий и показателей эффективности. Информация была доступна, но не собрана вокруг реальной последовательности работы сотрудника
Проблема
Чтобы начать работу, менеджеру приходилось восстанавливать контекст по разным зонам экрана и держать часть процесса в голове. Частые и рискованные действия находились рядом, отложенные задачи было сложно контролировать, а итоговая оценка не объясняла, как улучшить результат
Основной экран должен за несколько секунд отвечать на два вопроса: что произошло с клиентом и что нужно сделать сейчас
Исследование
Чтобы восстановить реальный рабочий процесс, я провела качественные и количественные исследования, шэдоуинг нескольких смен, 8 интервью с сотрудниками, 3 интервью с руководителями и опрос примерно 50 менеджеров



Дополнительно изучила продуктовые метрики старой системы, провела бенчмаркинг конкурентов, обращения к наставникам и структуру основного экрана 1С
| Метод | Выборка / объём | Цель |
|---|---|---|
| Шэдоуинг рабочего дня | Несколько смен | Увидеть реальный процесс, микрозадержки и обходные действия |
| Глубинные интервью | 8 сотрудников + 3 руководителя | Понять боли пользователей и бизнес-логику оценки |
| Количественный опрос | ~50 сотрудников | Проверить понимание метрик, отношение к рейтингу и личной динамике |
| Анализ данных и обращений | Метрики старой системы + обращения сотрудников | Найти задержки, ошибки, повторные действия и сценарные разрывы |
| Аудит интерфейса | Основной экран 1С | Выявить проблемы структуры, иерархии и частоты использования |
| JTBD, CJM и User Flow | Основной рабочий цикл | Связать пользовательские задачи со сценариями и состояниями интерфейса |
| Бенчмаркинг | ERP, CRM, support-системы | Найти устойчивые паттерны экспертных интерфейсов |
Главная задача сотрудника:
Быстро понять, кто клиент, что происходило с обращением и какое действие нужно выполнить сейчас, чтобы решить задачу без лишних переключений и ошибок
Аудит старого интерфейса

CJM

Разложила путь сотрудника от получения задачи до её завершения. Нашла болевые точки:
- долгое восстановление контекста
- неочевидные последствия действий
- сложность работы с отложенными задачами
- отсутствие уверенности, что результат сохранён правильно
JTBD
Главная работа: «Когда мне автоматически поступает новая задача, я хочу за несколько секунд понять, кто клиент, что происходило с обращением и какое действие нужно сейчас, чтобы качественно решить задачу, зафиксировать результат и перейти к следующей без лишних переключений и ошибок»

Сформулировала основные задачи сотрудника:
- быстро понять контекст и следующий шаг
- безопасно выполнить действие и не ошибиться
- понимать, что произошло с задачей после действия
- видеть свой результат и понимать, что можно улучшить
Бенчмаркинг и открытые источники
Изучила CRM, service desk и внутренние рабочие системы, чтобы посмотреть, как в сложных продуктах организуют контекст задачи, статусы, историю действий и показатели эффективности

Основные инсайты
Исследование свелось к трём ключевым проблемам
- Сотруднику сложно быстро понять, что происходит в задаче и что делать дальше
- Часть действий воспринимается как рискованная, потому что последствия не всегда очевидны
- Метрики эффективности существуют, но сотрудник не понимает, из чего складывается его результат и как на него повлиять
Гипотеза
Если перестроить экран вокруг текущей задачи, сделать частые действия заметными, а показатели эффективности прозрачными, сотрудники будут быстрее начинать работу, реже ошибаться и лучше понимать собственный результат
Ключевые решения
Рабочий экран вокруг текущей задачи
Данные клиента, контекст и основные действия собрала в одной рабочей зоне. Редкие и рискованные действия отделила от основного сценария

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

Эффективность за день
Добавила компактный блок с текущим результатом сотрудника, сотрудник видит не только итоговый балл, но и конкретные показатели, которые на него повлияли

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


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

В новой версии сотрудник сравнивает текущие результаты:
Показатели отдела могут использоваться руководителем для аналитики, но не становятся основой пользовательской мотивации сотрудника
64% сотрудников предпочли сравнение с собой, а не с командой
Тестирование и результат
Первый запуск дал просадку: сотрудники адаптировались к новой структуре, а сравнение с коллегами усиливало давление вместо мотивации. Перед вторым пилотом мы упростили основные сценарии, усилили обратную связь интерфейса и заменили рейтинг на личную динамику и достижения
Второй пилот: сократилось время обработки, уменьшилось количество повторных открытий и обращений за помощью, выросла точность работы со статусами
Решение проверяли в двух отделах примерно на 50 сотрудниках

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



