Сегодня поговорим о синхронизации, то есть о передаче
информации с КПК торгового представителя на сервер – и, соответственно,
менеджеру в приложение и на склад для формирования поставок.
В разных приложениях для мобильной торговли процесс
синхронизации реализован по-разному. И мы, признаться, не только сами
размышляем, как сделать его удобнее, но и посматриваем, что там у соседей,
потому что одна голова хорошо, а две – сами знаете.
Между прочим, видимо, не все наши коллеги осознают,
насколько важно организовать процесс синхронизации. Видели мы недавно систему,
в которой вся синхронизация представлена двумя кнопками: «Загрузить» и
«Выгрузить». Да-да, всю базу целиком, каждый раз, как нужно передать хоть
строчку, хоть бит информации. А если связь плохая? А если агент наделал фоточек
на сто мегабайт? Честно говоря, не знаем, как их клиенты справляются.
В общем, решили мы поделиться со всеми, кому интересно,
своими наработками.
По сути, какая информация передается при синхронизации?
Агент посылает на сервер следующее:
– все основные жизненно важные документы: оформленные
заявки, продажи, визиты, съем остатков, списки выполненных задач, информация о
возврате товара;
– все остальные документы, менее срочные, но тоже нужные:
результаты разного рода мониторингов и анкетирования, фотографии из торговых
точек,
– контрольная информация: о маршруте торгового
представителя, километраже, о его рабочем времени и времени простоя.
Помимо этого, с сервера агент также получает важное:
– информация о долгах и просрочках всех контрагентов;
– данные по прайсу, количество товаров на складе по всем
позициям (а оно может меняться по несколько раз в день);
– актуальные данные по скидкам и акциям на определенные
товары;
– стоп-лист, то есть с какими контрагентами на данный момент
не работать;
– рабочие планы, маршруты, разнарядки, которые ему посылает
руководитель;
– какие-то срочные сообщения: о собраниях, документах,
чем-то еще, о чем может быть менеджеру понадобится срочно сообщить.
То есть синхронизация – это процесс, который должен быть
двухсторонним (агент – серверу и обратно), динамичным (как минимум несколько
раз в день) и в идеале быстрым – чтобы при попытке обновить информацию аппарат
не зависал на пятнадцать минут из-за плохой связи.
Если держать в уме тот факт, что информация бывает разной не
только по типу, но и по важности, все это легко устроить. Важно только
продумать структуру.
Мы довольно давно остановились на таком варианте, и пока
ничего лучше не придумали.
«Очистить базу при приеме» – кнопка, которая «подчищает»
память приложения.
«Основные данные» – то, что приходит на КПК с сервера:
прайс-лист, список контрагентов, сообщения и задачи от менеджера (если есть),
бланки анкет и мониторингов (если есть)
«Остатки >0» – в прайс-лист придут только те товарные
позиции, остаток которых на складе ненулевой.
«Документы» – то, что агент передает с КПК на сервер:
заявки, визиты, съем остатков, заполненные анкеты и т.д.
«Фотоотчеты» – все фотографии, которые агент сделал в
торговых точках. Вместе с документами они не передаются для экономии трафика.
«Презентация» – фотографии товара с сервера для электронного
«презентера» на КПК.
«Отгрузки и долги» – тоже с сервера: информация о задолженностях
контрагентов и об отгрузках товара.
«Восстановить заявки» – если агент делал зачистку базы, а
теперь ему вдруг понадобилась какая-то прошлая информация, он может запросить
ее с сервера.
Перед синхронизацией агент выставляет и снимает галочки во
всех пунктах – в зависимости от того, какой кусок информации ему надо
передать/получить. Противники ручного труда, уверенные в скорости и качестве
интернет-соединения, могут выставить любое количество галочек по умолчанию и
синхронизироваться автоматически, одной кнопкой.
Но это, так сказать, только видимая часть синхронизации. А
есть еще невидимая, то есть фоновая. Вот ее вручную совершать не надо, она
просто есть. Фоном у нас передается информация о перемещениях агента (то есть
трек), о его действиях (когда какие документы составлены – переданы) и лог
приложения – то есть когда приложение было включено, выключено, когда не было
связи, когда был отключен сам аппарат. Про контроль перемещений и действий
торговых представителей мы много писали, знаем, что многих наших клиентов эта
тема берет за живое.
Вы, может быть, спросите, а почему бы и документы так фоном
не передавать? Ну, допустим, не все, понятно, что фотографии и прочие анкеты
слишком «тяжеловесны», да и не так срочны. Но вот заявки хотя бы – самый же
срочный документ, чем быстрее на складе ее получат, тем лучше.
Клиенты нас постоянно просят включить заявки в фоновую
синхронизацию. А мы сопротивляемся и отговариваем.
Потому что, во-первых, тогда надо усложнять структуру самого
документа «Заявка». Как минимум вводить для него статусы «Черновик» и «Готов к
отправке». Чтобы полузаполненные заявки не уходили на сервер. И менять эти
статусы придется вручную, для надежности. То есть никакой экономии времени и
действий в рабочем процессе мы особо не получаем.
Во-вторых, даже если документ готов к отправке – у нас нет
стопроцентной гарантии, что он немедленно отправится. Глюкнул КПК, глюкнула
сеть, просто слабый сигнал, еще что-то – и вот вам сбой, документ никуда не ушел.
А агенту не придет в голову проверить – синхронизация-то фоновая, его участия
не требует. Вот и окажется, что документ может опоздать к месту назначения на
несколько часов, а то и на день. А в торговом деле это может быть очень
критичный срок. Если же заставлять агента каждый раз проверять, отправлен ли
документ – то смысл фоновой синхронизации? Никакого, одни тревоги и лишняя
суета.
Заявка – слишком важный документ, лучше потратить немного
времени и усилий, чтобы убедиться, что с ним все в порядке. А чтобы свести эти
усилия к минимуму, мы ко всем важным документам прикрутили собственные кнопки
отправки на сервер в один клик. Составил документ – нажал кнопку «отправить» –
тут же убедился, что документ отправлен.
Ну вот, что знали – рассказали. Очень ждем ваших мнений и
пожеланий.
Комментарии