“OKO” Induction

OKO – Dataflow

Зоны ответственности ключевых лиц

Ответственное лицо Зона ответственности Инструмент ответственного лица Контролирующие лица

Инструмент контролирующего

лица

ИТ дистрибьютора

Написание интерфейса обмена во время внедрения Методика написания

интеграции, консультации инженера внедрения

Инженер внедрения softserve/ DS / CD Operations

specialist / команда ОКО обновление статуса / email

Внесение доработок в интефейс и поддержка КП системы при возникновении технических

проблем

Служба поддержки / DS / CD Operations specialist

Ключевой пользовательПоддержка работоспособности системы

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

данных

Блок критических проверок НБД. Сравнение отчетов о

продажах SalesWorks и URA Sales Report и данных УС

дистрибьютора

DS / CD Operations specialist отчеты Web Tool

FSSПредоставление данных КП для внесения в систему (каналы новых точек, изменение ответственности SE). Работа с технической

поддержкой

Отчеты WT по выполнению KPI, автоматически

рассылаемые отчеты, результаты работы

проверок

DS / CD Operations specialistURA POP Analysis отчет, результаты работы проверок

Служба поддержки Soft ServeВсе вопросы, связанные с работоспособностью

системы, отчётов Web Tool, URA, методике расчёта показателей в отчётах KPI. Проведение

тренингов. Доработка системы.

Aqdev система запросов Координаторы проекта ОКОAqdev система

запросов / email-нотификации

DS| CD operations specialists Контроль качества работы КП, качества данных в системе

Отчеты WT по качеству данных, KPI, автоматически

рассылаемые отчеты

Координаторы проекта ОКО

Консультация сотрудников отдела продаж, CD operations spec. Помощь при работе с

тех.поддержкой SoftServe. Организация тренингов, еженедельной рассылки проблем качества данных. Согласование доработок в

системе

Настольный модуль поддерживает два режима синхронизации, экспорта информации:

•автоматический •ручной

Ключевому пользователю необходимо осуществлять контроль за ежедневным прохождением синхронизации следующими способами:

•открыть в НБД протокол синхронизации с ЦБД•проверить в самом протоколе синхронизации, который находится в каталоге

C:\SalesWorks Enterprise\Log\ DesktopSyncYYYYMM .log

Необходимо осуществлять контроль за ежедневным импортом/экспортом данных при помощи:

•протокола импорта в НБД•проверки лога импорта Справочника проверок•протокол импорта\экспорта можно в текстовом формате в файле C:\

SalesWorks Enterprise\Log\ ImportExportYYYYMM .log

Проведение импорта/экспорта информации должно быть завершено строго до начала синхронизации.

Ежедневные синхронизация с ЦБД и экспорт/импорт данных из SalesWorks

Блок проверок Проверка

Проверки транзакционны

х данных

* Наличие заголовков без деталей

* Наличие остатков на начало и конец месяца в открытых периодах

* Число дат с отсутствующими архивными остатками

Недопустимое значение НДС

Отрицательные остатки

Проверка лога импорта

Регулярность действий

* Регулярность выгрузок остатков

* Регулярность выгрузок продаж

* Регулярность синхронизаций с ЦБД

Блок автоматизации

работы КП

Генератор стандартных маршрутов

Преобразование простой ТТ в узловую при наличии подчиненных

Преобразование узловых торговых точек в простые при отсутствии дочерних

Блок автоматизации

работы с УТТ

Преобразование точек типа "Простая ТТ" в типы "Продажи FOOD" и "Продажи HPC"

Список точек типа "Простая ТТ" с продажами и FOOD и HPC

Точки типа FOOD или HPC привязанные к ТП другого направленияПроверка config.xml Проверка config.xmlПроверки рассылки

оповещений Наличие получателей рассылки

Работа с проверками SalesWorks

• Проверки блока «Проверки справочников» запускаются ежедневно автоматически

• Критические проверки (особо важные проверки) помечены в названии проверки «* »

• Подробная информация по проверкам: - зайдите в справочник проверок на НБД - выберите пакет «Проверки справочников», требуемую проверку - нажмите кнопку деталей проверки:

  

Работа с проверками SalesWorks

• Для просмотра результатов всех проверок, запущенных на дистрибьюторе, необходимо запустить отчет «Результаты проверок» (размещен в папке «Отчеты НБД Unilever»):

Подробное описание самих ошибок и методов их решения Вы найдете в аттаче Краткой инструкции КП, которая будет выслана вам после окончания тренинга

Поддержка базы ТТКлючевой пользователь должен на постоянной основе осуществлять следующие действия: постоянное отслеживание базы ТТ правильное заполнение параметров ТТ обеспечение реальной принадлежности ТТ к ТП (параметры ТТ) добавление новых ТТ (или загрузка из УС)

У каждой ТТ обязательно должны быть проставлены:• подтип (канал продаж) точки• статус• ответственное лицо (ТП)• тип ТТ (Узловая\простая и т.д.) • район, к которому принадлежит точка• параметры для SUBTYPE_ID • параметры для OWNER_ID

Существует возможность объединять несколько торговых точек по общему признаку.

Этот функционал носит название «функционал Узловых Торговых Точек (УТТ)»

УТТ

ТТ1 ТТ2

УТТ123

ТТ123 HPC

ТТ123 FOOD

УТТ123

ТТ123I

ТТ123IIДля изменения канала ТТ необходимо

обратиться в техподдержку с указанием кодов ТТ и данных о текущем и требуемом канале. Канал новой ТТ ключевой пользователь меняет самостоятельно.

Поддержка справочника ТППри создании торгового представителя обязательные поля к заполнению:

Код ТП – присваивается системой автоматически. Супервайзер – выбор супервайзера данного торгового представителя.

Важно! Если вам необходимо добавить супервайзера, необходимо написать запрос на адрес техподдержки UnileverSupport@salesworks.com.ua и команду ОКО , с указанием кода вакансии и ответственного FSS Важно! Миксовые ТП должны быть привязаны только к миксовому SV

Название ТП – Ф.И.О. торгового представителя. Сер. номер КПК – вставляется электронный серийный номер КПК/устройства Статус ТП – при создании автоматически устанавливается «Активный». Можно будет изменить при редактировании торгового представителя.

Префикс счетчика НН – Важно! служебное поле, заполняется следующим образом: DF – 100% финансируемый дистрибьютором SE Food, например 220050-DF-2 DH - 100% финансируемый дистрибьютором SE HPC, например 220050-DH-2 DFH - 100% финансируемый дистрибьютором SE Food+HPC, например 220050-DFH-2 WF – Миксовый SE Food, например 220050- WF-2 WH – Миксовый SE HPC, например 220050- WH-2 WFH - Миксовый SE Food+HPC, например 220050- WFH-2 Если ТП является SE Юнилевера, то проставляется код вакансии(спросить у DS)

Необходимо привязать ТП к типу деятельности Тип ТП (эксклюзивный,виртуальный и финансируемый дистрибьютором: типы 1 и 2; миксовый: прямые продажи тип 10)

Поддержка справочника продукции

Справочник глобальной продукции «Продукция» - эталонный справочник поставщика. Данные в этот справочник вносятся в центральной базе. Справочник «Локальная продукция» - справочник продукции дистрибьютора, корректность данных которого ключевой пользователь должен отслеживать ежедневно.

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

код товара производителя вес продукции количество продукции в упаковке(код из справочника глоб. продукции)

Для проверки справочника локальной продукции существуют специальные проверки: Активный товар без продаж за последние 45 дней с нулевым текущим остаткомДеактивированные товары с ненулевыми остаткамиНаличие непривязанных товаровНеверный учет комплекс-паковНепривязанные товары в продажахПустые смоткиСоответствие единиц учета

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

Проверка корректности данных в базе по остаткам на складе, фактическим продажам

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

Информацию об остатках можно увидеть в соответствующем

справочнике «остатки товара»

Для сверки информации об остаках и продаж в шт

необходимо использовать отчет «Еженедельный отчет о продажах» и

«Stock Report»

Проверка корректности данных в базе по остаткам на складе, фактическим продажам

Также для сверки продаж в руб. необходимо использовать отчет URA Sales:

Данные об остатках и продажах в системе SW должны быть актуальными – теми же, что в учетной системе дистрибьютора. Несвоевременное предоставление или представление некорректной информации грозит дистрибьютору лишением дистрибьюторской скидки! При обнаружении расхождения в данных об остатках или продажах, ключевой пользователь и совместно с IT-специалистом должны найти причину расхождения и устранить её. Проверки из блока «Проверки транзакционных данных» осуществляют контроль за выгрузкой остатков и продаж.

Работа с планами продаж

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

Элемент меню копирования планов продаж

Информация на КПК

Отображение на КПК информации о планах и выполнению по KPI:

Подсветка на КПК

На КПК регулярно подсвечивается следующая продукция:

• MML (маст лист):-КПК Android: шрифт жирный, розовый

-КПК WinMobile: розовый

• На зеленом фоне – позиции Топ 15 в точках канала традиционной торговли

• Красным – позиции non NPD и NPD (в месяца действия плана non NPD и NPD)

В случае, если у ESF на КПК отсутствуют анкеты для PerfectStore не выделяются соответствующие позиции необходимо проверить была ли проведена успешная синхронизация , если да- то сразу же обращаться в техподдержку по адресу:  unileverSupport@Salesworks.com.ua

Отчеты настольной базы данных – НБД Стандартные отчеты, содержащие общие данные по заказам, визитам,

каналам и Отчеты НБД Unilever:

OKO data and Reports

• URA/SWRA для анализа продаж, ключевых показателей и мастер данных

Журнал операцийДетальный реестр документовЗаказы по типам торговых точекЗаказы по типам продукцииКарточка ТТМаршруты ТПКоличество визитов на ТП в деньЭффективность визитов ТП, %Еженедельный отчет о продажах WSR (Локальная кодировка)Продукция Юнилевер (UL)Field Capability Score (UL)Sales Report (UL)Sales (ver.3.5)

DistributionDetailed (ver.3.0)Visits (ver. 3.0)POP_analysis (ver.3.7)Результаты проверокVirtual OSANew Products DeploymentStock ReportPOPs Analysis (ver.4.2)Детальный отчет о продажах (ver.4.2)Catalog of OutletsОписание отчетов НБДНекорректные привязки торговых точек к сетямSKU Coverage KPI (non NPD month) POP Level

Работа с технической поддержкой SoftServe

Запомните этот адрес:

UnileverSupport@salesworks.com.ua

Вам сюда, если: необходим доступ на web tool или к системе учета запросов Aqdev при возникновении любых вопросов/проблем в рамках

проекта ОКО

Настоятельно просим оперативно реагировать на уточняющие вопросы, задаваемые

тех. поддержкой и

инициировать закрытие

уже решенных

запросов! 21/01 СП запросила логи 26/02 - логи не предоставлены

Система учета запросов AQDevTeam, интернет-ссылка: http://support.ssbs.com.ua

Информация на КПК

Отображение на КПК информации о планах и выполнению по KPI:

Подсветка на КПК

На КПК регулярно подсвечивается следующая продукция:

• MML (маст лист):-КПК Android: шрифт жирный, оранжевый

-КПК WinMobile: оранжевый

• На зеленом фоне – позиции Топ 15 в точках канала традиционной торговли

• Красным – позиции non NPD и NPD (в месяца действия плана non NPD и NPD)

В случае, если у ESF на КПК отсутствуют анкеты для PerfectStore не выделяются соответствующие позиции необходимо проверить была ли проведена успешная синхронизация , если да- то сразу же обращаться в техподдержку по адресу:  unileverSupport@Salesworks.com.ua

Раздел Backup

Проект Perfect Store Анкеты по PerfectStore появляются на КПК с 15-го (RU)/6-го (UA) числа месяца после полного цикла

синхронизации ЦБД-НБД-КПК.

Анкеты привязываются к точкам, по которым были продажи за последние 90 дней. Если на момент выхода анкет у точки не было продаж, анкета при визите в такую точку не появится.

Анкеты обязательны для всех точек ModernTrade + TraditionalTrade, за исключением каналов Аптеки и Опт.

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

• Расчет VOSA производится на основании снятой дистрибьюции. При

расчете VOSA учитывается, какие категории точка продавала за последние 90 дней.

• Дистрибьюцию необходимо снимать при каждом визите, независимо от того, появляется ли в этот визит анкета или нет:

     - для точек ТТ по списку Top-15 SKU;

     - для точек МТ по всему списку продуктов.

Комплексная оценка эффективности работы SE (Store Executives) и FSM (Field Sales Manager) с использованием трех показателей – ECO, BP, TLS

Алгоритм расчета1. Отбираются только активные точки привязанные к ТП заданного направления2. Несколько визитов/продаж в них в один день будут засчитаны за 1 3. Отбираются только невырожденные строчки4. Накладные Undef пропускаются5. Не учитываются точки миксового ТП (Прямые продажи user_type=10)6. Отбираются точки каналов продаж, для которых задан таргет–лист и норматив посещений7. Подсчитывается число возможностей взять заказ исходя из числа точек привязанных к ТП и нормативов

их посещения. 8. Если число фактических визитов в точку превысило норматив – оно считается числом возможностей. 9. Число возможностей корректируется коэффициентом равным отношению числу календарных дней

прошедших с начала месяца к общему числу календарных дней в месяце. TLS (Total lines sold) – отношение суммарного к-ва проданных линий (TotalLines) к ожидаемому количеству

линий (Target TLS). Это ключевой показатель деятельности, достижение которого помогает поддерживать необходимый ассортимент за счет увеличения числа позиций в отгрузке (считается на базе счетов-фактур) для каждой торговой точки.

Показатель ECO отражает эффективность работы Store Executive с точки зрения покрытия.Показатель ВР отражает эффективность каждого визита Store Executive – был ли сделан в результате этого

визита заказ и соответственно сформирован счет-фактура на отгрузку товара.

В случае выполнения всех трех таргетов – FCS считается выполненным.

OKO: Field Capability Score (FCS)

Field Capability Score (FCS) – подведение итогов. Общий FCS показатель считается достигнутым, если достигнуты все три входящих в него показателя: ECO, BP, %TLS >= Tgt (таргет) по этим показателям.Данные в отчете расчитываются для SE, агрегируются до уровня Точки Синхронизации.На уровне Точки Синхронизации отображается процент Store Executives, достигших необходимого уровня по конкретному KPI ( ECO, BP), от общего числа Store Executives.По TLS: Tgt – таргет по TLS, Tgt = 100%Actual - Actual TLS  (сумма TotalLines по всем ТП) /Target TLS (сумма TLS_Target по всем ТП) %TLS – % ТП, выполнивших таргет TLS (% торговых, которые достигли таргета 100%)

OKO: Field Capability Score (FCS)

TLS

Сейчас вы можете посмотреть информацию по показателю TLS: 1. На WebTool доступны отчеты FCS с показателем TLS, которые базируются на контракт - листе (для ТТ сетей platinum, gold). Field Capability Score by SE (TLS)Field Capability Score by Organization (TLS)Field Capability Score by FSS (TLS)2. На НБД доступен отчет FCS с показателем TLS вместо LPPC. Отчет появится на НБД после синхронизации с ЦБД. 3. На КПК доступна информация по показателю TLS. Показатель появится после полного цикла синхронизации (ЦБД - НБД - полная синхронизация с КПК). Обращаем ваше внимание, что финальный таргет по TLS для SE на июль будет пересчитан ночью с 15.07 на 16.07 на основе текущих привязок ТТ к SE.

TLS

Таргет по TLS рассчитывается трижды, 1-го, 6-го и 15-го числа месяца, т.к. на 1-ое число не имеем финальных данных ни по продажам, ни по привязкам торговых к точкам (изменения маршрутов, зон ответственности и т.п.), 6-го имеем итоги продаж - по этой причине таргет по TLS пересчитываем. 15-го имеем сформированные измененные маршруты, зоны ответственности на текущий месяц. Заводить новые ТТ после 15-го числа можно и нужно, но в этом случае они не попадут в таргет по TLS в текущем месяце, только в следующем. Actual по TLS в текущем месяце будет считаться с учетом всех активных ТТ, закрепленных за SE (в т.ч. этих новых).

TLS (Total lines sold) - отношение суммарного кол-ва проданных линий (TotalLines) к ожидаемому количеству линий (Target TLS). Сумма позиций (SKU) всех счетов-фактур.

OKO: Virtual OSA

Соответствие ассортимента продукции, проданного в канале продаж, MUST List данного канала.

Алгоритм расчета

1. Отбираются все активные точки с продажами категории за последние 90 дней.

2. Берутся только торговые точки с каналами, по которым задан таргет лист.

3. Анализируются продажи каждой из категорий таргет-листа, признак продаж которой имеется для точки

4. Для каждой точки, для каждой из проставленных для нее категорий подсчитывается число проданных уникальных SKU из категории таргет-листа (COUNT_TARGET_SKU_CAT)

5. VOSA категории =(COUNT_TARGET_SKU_CAT)/(TOT_TARGET_SKU_CAT)

6. VOSA точки =SUM(COUNT_TARGET_SKU_CAT)/SUM(TOT_TARGET_SKU_CAT)

OKO: NPD

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

Алгоритм расчета1.TOTPOPS - все активные точки каналов таргет –листа NPD с продажами категории соответствующей продукту в NPD за последние 90 дней2.Для данных точек анализируются продажи таргет –листа NPD. 3.В точку должно попасть не менее N единиц продукции. (POP with Sales)4.Таргет по точкам TGTTOTPOPS =TOTPOPS * таргет-процент. 5.NPD = (POP with Sales) / TGTTOTPOPS

TGTPCT - таргет NPD, %NP_POP - количество точек, где присутствует новый продуктTot_POP - количество активных точек каналов таргет –листа NPD, для которых имеется признак продаж категории соответствующей продукту в NPD за последние 90 дней.TgtPOP = Tot_POP* TGTPCTActual NPD - процент магазинов (точек) с новым продуктомTgtAchievment - процент выполнения таргета NPD

SKU Coverage KPI (non NPD month) Оценка покрытия торговых точек (ТТ) приоритетными продуктами из заданного отделом СМ списка

регулярно продаваемых продуктов. Отношение кол-ва магазинов в канале продаж (находящихся в зоне ответственности сотрудника), которые осуществляли закупку SKU (из заданного в плане списка регулярно продаваемых продуктов), от планового кол-ва магазинов , находящихся в зоне ТП.

Actual_POP - количество точек с продажами SKU , по которым производится расчет. (из заданного в плане списка регулярно продаваемых продуктов)

Category_POP - количество активных точек в канале, для которых имеется признак продаж категории (на основании продаж за последние 90 дней) соответствующей SKU по которому производится расчет (из заданного в плане списка регулярно продаваемых продуктов)

Target number of POP – план в виде количества ТТ, в которые должен быть продан продукт . Комментарий: Таргет зависит от достижений (продаж) в предыдущем месяце, текущих категорийных

галок и индивидуален для каждого Торгового Представителя. Actual SKU Cov, % - процент магазинов (точек) с продажами SKU по которому производится расчет (из

заданного в плане списка регулярно продаваемых продуктов) от Category_POP. Actual SKU = [Actual_POP]/[ Category_POP] TgtAchievment - процент выполнения плана, используется в финальном расчете бонуса. TgtAchievment = [Actual_POP]/[Target number of POP]