В последние несколько лет для многих продуктов сферы мобильной торговли отличительной особенностью была возможность on-line обмена (при этом каждый понимал его по-своему). Если попытаться проследить историю развития on-line обмена, то можно вспомнить, что когда-то «онлайном» назывался пакетный обмен по GPRS (хотя если на чистоту on-line обменом можно назвать его с большой натяжкой). Эта возможность заметно стала выручать оптовые фирмы, ведь, по сути, позволяла мобильным сотрудникам отвязаться от офиса и иметь при этом более-менее актуальный прайс (и другие данные) и возможность оперативно передавать заказы сразу для обработки. Вскоре стала актуальной другая проблема – продажа одного товара нескольким клиентам, в результате появилась функция on-line резервирования. В данном случае торговый представитель мог зарезервировать товар на складе и достаточно оперативно получить ответ системы о том, что заказ будет гарантировано собран. Казалось бы, этого более чем достаточно для нормальной работы, однако сейчас всё чаще обсуждаются решения для работы в терминальном режиме (среди программистов в основном). Довод в пользу отказа от on-line резервирования служит возможность «не угадать» с реальными остатками, после чего необходимо переоформить заказ с целью замены отсутствующих позиций. В случае, с терминальным доступом «не угадать» с заказом, говорят, можно только в промежутке времени от принятия решения до нажатия кнопки «заказать» - фантастика (лишь бы связь не подвела :)). Боюсь предположить, что будет в фаворе через 2-3 года, наверняка битва будет продолжаться за доли секунды, в получении оперативной информации… По большому счёту это не плохо, выиграет заказчик. Но к чему я это всё начал? Вот вам история аж 2004 года. Одному дистрибьютору известного украинского кондитерского завода потребовалось автоматизировать работу торгового отдела, дистрибьютор находился в Ярославле, автоматизировали его мы. Надо сказать, что требования к проекту были серьёзные, один из ключевых моментов – иметь возможность контроля наличия остатков на складе в режиме реального времени. Мы это реализовали (тогда ещё на платформе Palm OS), как на тот момент могли: заявка, приходя на сервер, запускала в 1с обработку, результат обработки заявки передавался обратно на КПК, в дальнейшем заявка проводилась и отправлялась клиенту.
Две недели спустя, после сдачи проекта, руководство было вынуждено отказаться от этой схемы в пользу элементарного пакетного обмена, и вопрос был не в технических проблемах, работало всё достаточно надёжно. Просто стали портиться отношения с клиентами! Поясню, как работали ранее, до автоматизации: приходили агенты с заказами в офис и после того, как их забивали в учётную систему, специально обученные операторы распределяли остатки по заказам, в первую очередь, формируя накладные для важных клиентов… Понимаете, есть ООО Важный клиент и ИП Пупкин, кому по логике надо везти последнюю оставшуюся коробку? А она часто уезжала к Пупкину, потому что агент его обслуживающий уже провёл её с утра в режиме on-line, это же в конце концов его работа.
Этим я хотел сказать только то, что не надо ударятся в крайности и пытаться максимально круто наворотить технологию, если она всё равно не сможет работать в существующем процессе.
Комментарии
Вот Вам пример на базе супер-онлайна. Приведу из нашего опыта примерчик.
У одной сибирской компании (алкогольного дистрибутора)был внедрен mySAP All-in-One с модулем мобильной торговли на тонком клиенте (специализированное решение из SAP-партнерских). Мобильная лицензия стоила порядка 2500 EURO на торгового представителя, также для торгового прилагался достаточно внушительных размеров "планшетник" (лист A4), тоже недешевый.
С одной стороны - красиво. Если говорить языком пресс-релизов, "торговый представитель обладает информацией в режиме реального времени о наличии товара на любом из складов (в том числе с учетом товара в пути), цене, количестве, наличия товаров-заменителей".
На деле выглядит так - торговый спускается в подвал в точку, там связи нет (оператор связи работает в стандарте CDMA). Товаровед точки быстро говорит, что нужно, показывая на полку. Некоторые поднимали планшет к потолку, "ловя сигнал", потом лихорадочно вбивали, лишь бы успеть. Резервировали также, планшет к потолку. Кто-то писал на бумаге, а потом делал заказ на улице, а кто предпочитал звонить по телефону :) Про снятие дистрибуции я не буду рассказывать, это еще грустнее.
Не знаю, приходилось связывать Вам НАПОЛЕОН с SAP, но ОПТИМУМ, продвигаемый нами, такую связку имеет, равно как и сертификацию на модуль интеграции со всеми продуктами SAP.
И даже безотносительно выбора системы мобильной торговли, оффлайн-решения уровня "коммуникатор+горячий резерв" стоило бы на порядок (!) дешевле, нежели то, которое использовалось.
А учитывая ситуацию со скоростями в мире подвижной связи в России на тот момент (2005 год), оно представлялось единственно возможным.
Вот такая история из Сибири.
по поводу SAP - интеграция возможна(мы не только с 1С работали, но и с Нави например, не считая местных программ), только сертификацию на модуль интеграции не имеем (ну.. ни к чему считаем, хотя это наше мнение). А к вопросу супер решений - спасибо, интересный случай.