Как считать ошибки в рутинных задачах отдела СБ в логистике и зачем это надо?
📣 На примере реального кейса расскажу о важной составляющей как безопасности в грузоперевозках, так и любых других бизнес-направлений, а именно - контроль.
🔸Без воды: сегодня одна из задач, которая ставится директорами большинства транспортных компаний (свой автопарк, экспедиторы, агенты и т.п.) перед сотрудниками служб безопасности - это предварительная проверка физических и юридических лиц на предмет выявления рисков. В логистике можно разбить виды проверок на следующие составляющие (назовём это тип проверки):
- Проверка штатного сотрудника (например, логиста, специалиста документооборота, бухгалтера);
- Проверка водителя, которого принимают в штат компании;
- Проверка только водителя под рейс (например, ТС и юр. лицо уже вам знакомы);
- Проверка контрагента-плательщика (так называемые клиенты - грузовладельцы);
- Проверка контрагента-перевозчика (транспортная компания, экспедитор, агент);
- Проверка транспортного средства и собственника транспортного средства под рейс;
- Проверка водителя, транспортного средства, собственника транспортного средства под рейс;
- Проверка водителя, транспортного средства, собственника транспортного средства, перевозчика/агента/экспедитора под рейс.
🔸Помимо контроля исполнения работы задачей руководителя службы безопасности является и контроль качества выполненной работы. Важно понимать, что сами по себе ошибки довольно однотипны и их тоже можно "посчитать". Вот мой вариант ошибок специалистов СБ:
- Ошибка в выводе: неверный анализ и интерпретация информационно-аналитических инструментов (например, неверно интерпретировал ФХД организации, не обращено внимание на какой-то важный негатив по водителю и т.п.)
- Ошибка в выводе: неверный тип резолюции (например, попался косячный водитель, а запретили в работе зачем-то ещё и компанию);
- Ошибка в выводе: неполная причина отказа (например, когда провели неполный анализ и забраковали водителя или компанию только по одному критерию, хотя этих критериев намного больше);
- Ошибка в выводе: не указаны выводы/нет причины отказа (например, когда забыли вообще дать какой-то ответ по проверке);
- Ошибка в выводе: вывод не соответствует запросу (например, спрашивали одно, специалист дал ответ о чем-то другом);
- Ошибка: другое (когда не не хватило категорий выше и ошибка в другом, например, не очень понятная формулировка для заказчика проверки)
🔸Соответственно, мы можем подвести оценку под единую табличку, которой будет удобно пользоваться и выявлять тенденции по каждому конкретному специалисту. Что можно взять в заголовки:
- Где зафиксирована задача (ссылка на проверку, путь до папки, письмо в почтовом сервисе, ID задачи в 1C и т.п.)
- Специалист, который эту задачу взял в работу
- Тип проверки (категоризацию см. выше)
- Тип ошибки (категоризацию см. выше)
- Комментарий (что конкретно не так было сделано, можно добавлять хэштеги, чтобы было проще)
🔸В итоге мы получим что-то вроде этого:
Далее уже сможете выявлять: кто, в каком количестве, на каких именно задачах "проседает"в определенный период времени - и после этого сможете провести с ним работу по над ошибками.
Далее с помощью фильтров по каждому столбцу выбираете интересующие вас параметры. Можете выбрать конкретного специалиста и увидеть какие ошибки присущи именно ему. Можете отсортировать тип ошибок и увидеть, где проседает вся команда (общие тенденции). Можете посчитать кто ошибается меньше/больше для премирования/депремирования и т.п.
Плюс с учётом технологий эту систему можно автоматизировать.