В предыдущих двух постах писал о возможностях контроля работы торговых представителей, таких как GPS/GSM фиксация и синхронизация с сервером времени. Сегодня хочу рассказать о третьем возможном инструменте контроля торговых представителей – фото-отчете. Суть инструмента – проста, в процессе работы торговый представитель может сделать фотографию необходимого объекта, тем самым, косвенно подтвердив своё присутствие в точке. Я видел фото спидометра (в начале и конце рабочего дня), фото вывески торговой точки, фото витрины. Есть только одна проблема, необходимо убедить агента делать эти фотографии. Как простой вариант – жесткий или полужёсткий сценарий визита в торговую точку, иными словами, программа должна либо побуждать торгового представителя сделать фото, например, так:
Либо не давать возможность совершить дальнейшие действия в торговой точке, пока не будут выполнены предыдущие, например, так:
Оговорюсь, сценарии в проектах используются не всегда, но они возможны.
Что мы получаем в итоге? Супервайзеру или руководителю доступны фотографии (возможно с водяными знаками даты и времени создания и т.д.) на которых видны торговые точки или витрины, что говорит о том, что точки агент посетил.
Осведомлённый читатель скажет, что полной гарантии посещения фото-отчёты не несут, так как можно изменить время создания фотографии или же саму фотографию, хранимую на КПК. А вот тут и начинаются существенные отличия фото-отчётов разных систем. Как это сделали мы?
Во-первых: никакие свойства самой фотографии мы не используем для отчётности, следовательно, изменив время в свойствах файла – мы не изменим его в отчёте, а значит, не сможем таким образом изменить время визита в точку.
Во-вторых: удалив сам файл – мы не удалим документ, который будет фигурировать в дневном отчёте, а этот документ так просто не найти и не удалить.
Есть возможность обойти базовую версию – подменить фото файл, и в данном случае мы можем предложить вариант, при котором это сделать практически невозможно – хранить файл в SQL-базе программы. Внешне – он никак не сможет быть идентифицирован, открыт или подменён (для этого надо копировать базу на ПК и уже там пытаться её открыть). Минус такого решения – быстро растущая база на КПК, что мы считаем неоправданным, а по этому – оставляем право выбора за клиентом.
Таким образом, подводя итог последних трёх постов могу предложить оптимальный рецепт контроля торговых представителей – комплекс из GSM фиксации перемещения, синхронизации программы с сервером времени и полужёсткий сценарий с фото-отчётом. Этот комплекс мер позволит с высокой долей вероятности гарантировать достоверность данных о перемещениях агентов, при немаловажном факте: никаких, повторюсь, абсолютно никаких задержек в запуске приложения, его скорости работы пользователь не заметит – а это, на мой взгляд, главное. Гикам, желающим максимально урезать возможности для мухлежа хочу напомнить, что при наборе этих трёх инструментов торговому представителю становится уже не выгодно заниматься подлогом, опытами в экранировании устройств, или другими действиями. Чтобы не быть уличённым в обмане ему будет проще выполнить всё, что от него требуется или на крайний случай запустить своего "двойника" на маршрут, но ведь постоянно он это делать не сможет, а значит - цель достигнута, и мы либо имеем факты недобросовестной работы, либо, большую часть рабочего времени - добросовестного сотрудника. По опыту, за первые недели использования системы недобросовестные сотрудники сами увольняются.
Если есть добавления – пожалуйте в комментарии.
Либо не давать возможность совершить дальнейшие действия в торговой точке, пока не будут выполнены предыдущие, например, так:
Оговорюсь, сценарии в проектах используются не всегда, но они возможны.
Что мы получаем в итоге? Супервайзеру или руководителю доступны фотографии (возможно с водяными знаками даты и времени создания и т.д.) на которых видны торговые точки или витрины, что говорит о том, что точки агент посетил.
Осведомлённый читатель скажет, что полной гарантии посещения фото-отчёты не несут, так как можно изменить время создания фотографии или же саму фотографию, хранимую на КПК. А вот тут и начинаются существенные отличия фото-отчётов разных систем. Как это сделали мы?
Во-первых: никакие свойства самой фотографии мы не используем для отчётности, следовательно, изменив время в свойствах файла – мы не изменим его в отчёте, а значит, не сможем таким образом изменить время визита в точку.
Во-вторых: удалив сам файл – мы не удалим документ, который будет фигурировать в дневном отчёте, а этот документ так просто не найти и не удалить.
Есть возможность обойти базовую версию – подменить фото файл, и в данном случае мы можем предложить вариант, при котором это сделать практически невозможно – хранить файл в SQL-базе программы. Внешне – он никак не сможет быть идентифицирован, открыт или подменён (для этого надо копировать базу на ПК и уже там пытаться её открыть). Минус такого решения – быстро растущая база на КПК, что мы считаем неоправданным, а по этому – оставляем право выбора за клиентом.
Таким образом, подводя итог последних трёх постов могу предложить оптимальный рецепт контроля торговых представителей – комплекс из GSM фиксации перемещения, синхронизации программы с сервером времени и полужёсткий сценарий с фото-отчётом. Этот комплекс мер позволит с высокой долей вероятности гарантировать достоверность данных о перемещениях агентов, при немаловажном факте: никаких, повторюсь, абсолютно никаких задержек в запуске приложения, его скорости работы пользователь не заметит – а это, на мой взгляд, главное. Гикам, желающим максимально урезать возможности для мухлежа хочу напомнить, что при наборе этих трёх инструментов торговому представителю становится уже не выгодно заниматься подлогом, опытами в экранировании устройств, или другими действиями. Чтобы не быть уличённым в обмане ему будет проще выполнить всё, что от него требуется или на крайний случай запустить своего "двойника" на маршрут, но ведь постоянно он это делать не сможет, а значит - цель достигнута, и мы либо имеем факты недобросовестной работы, либо, большую часть рабочего времени - добросовестного сотрудника. По опыту, за первые недели использования системы недобросовестные сотрудники сами увольняются.
Если есть добавления – пожалуйте в комментарии.
Комментарии