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

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

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

Сначала стоит определить, какое решение требуется

Запрос «хотим измерять эффективность сотрудников» звучит понятно, но оставляет слишком много вопросов. По нему трудно определить, какие показатели нужны и что компания собирается менять после просмотра отчёта.

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

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

Я бы проверял состав отчёта простым вопросом: какое решение поможет принять этот показатель? Например, число встреч может объяснить, куда уходит рабочее время. Но само по себе оно мало говорит о том, справляется ли команда со своими обязательствами.

Как связать активность с результатом

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

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

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

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

Почему сравнение требует контекста

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

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

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

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

Как перейти от результата команды к конкретной задаче

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

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

Следующий уровень раскрывает этапы: где выполняется работа, где возникает ожидание и какие задачи возвращаются повторно. Например, если значительная часть срока проходит между подготовкой документов и их согласованием, нужно проверить причины задержки на этом участке. Увеличение числа задач у исполнителя в такой ситуации ещё не объясняет, почему они остаются открытыми.

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

Как увидеть реальную загрузку

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

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

На дашборде важно разделять активную работу и ожидание. Заявка может оставаться за специалистом, хотя он уже выполнил свою часть и ждёт ответа клиента. Если сложить все открытые задачи в один показатель загрузки, будет трудно понять, кому требуется помощь и где именно застрял процесс.

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

Когда данные помогают выбрать обучение

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

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

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

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

Как сделать правила аналитики понятными сотрудникам

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

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

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

Понятные определения и порядок исправления ошибок дают команде основания доверять отчёту. Руководитель тоже получает более надёжную картину, поскольку сотрудники могут дополнить её обстоятельствами, которых пока нет в данных.

Кому нужна персональная детализация

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

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

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

Что должно измениться после разбора

Результат встречи по дашборду стоит фиксировать через конкретное действие: что меняем, кто отвечает, к какому сроку и по каким показателям проверим результат. Просьба «работать быстрее» оставляет команде слишком много неопределённости, особенно если задержка связана с организацией процесса.

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

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

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

Пишу о BI, данных и управлении в телеграм-канале: https://t.me/smart3asy

Наш сайт https://smarteasybi.com