Супер-онлайн.

В последние несколько лет для многих продуктов сферы мобильной торговли отличительной особенностью была возможность on-line обмена (при этом каждый понимал его по-своему). Если попытаться проследить историю развития on-line обмена, то можно вспомнить, что когда-то «онлайном» назывался пакетный обмен по GPRS (хотя если на чистоту on-line обменом можно назвать его с большой натяжкой). Эта возможность заметно стала выручать оптовые фирмы, ведь, по сути, позволяла мобильным сотрудникам отвязаться от офиса и иметь при этом более-менее актуальный прайс (и другие данные) и возможность оперативно передавать заказы сразу для обработки. Вскоре стала актуальной другая проблема – продажа одного товара нескольким клиентам, в результате появилась функция on-line резервирования. В данном случае торговый представитель мог зарезервировать товар на складе и достаточно оперативно получить ответ системы о том, что заказ будет гарантировано собран. Казалось бы, этого более чем достаточно для нормальной работы, однако сейчас всё чаще обсуждаются решения для работы в терминальном режиме (среди программистов в основном). Довод в пользу отказа от on-line резервирования служит возможность «не угадать» с реальными остатками, после чего необходимо переоформить заказ с целью замены отсутствующих позиций. В случае, с терминальным доступом «не угадать» с заказом, говорят, можно только в промежутке времени от принятия решения до нажатия кнопки «заказать» - фантастика (лишь бы связь не подвела :)). Боюсь предположить, что будет в фаворе через 2-3 года, наверняка битва будет продолжаться за доли секунды, в получении оперативной информации… По большому счёту это не плохо, выиграет заказчик. Но к чему я это всё начал? Вот вам история аж 2004 года. Одному дистрибьютору известного украинского кондитерского завода потребовалось автоматизировать работу торгового отдела, дистрибьютор находился в Ярославле, автоматизировали его мы. Надо сказать, что требования к проекту были серьёзные, один из ключевых моментов – иметь возможность контроля наличия остатков на складе в режиме реального времени. Мы это реализовали (тогда ещё на платформе Palm OS), как на тот момент могли: заявка, приходя на сервер, запускала в 1с обработку, результат обработки заявки передавался обратно на КПК, в дальнейшем заявка проводилась и отправлялась клиенту.
Две недели спустя, после сдачи проекта, руководство было вынуждено отказаться от этой схемы в пользу элементарного пакетного обмена, и вопрос был не в технических проблемах, работало всё достаточно надёжно. Просто стали портиться отношения с клиентами! Поясню, как работали ранее, до автоматизации: приходили агенты с заказами в офис и после того, как их забивали в учётную систему, специально обученные операторы распределяли остатки по заказам, в первую очередь, формируя накладные для важных клиентов… Понимаете, есть ООО Важный клиент и ИП Пупкин, кому по логике надо везти последнюю оставшуюся коробку? А она часто уезжала к Пупкину, потому что агент его обслуживающий уже провёл её с утра в режиме on-line, это же в конце концов его работа.
Этим я хотел сказать только то, что не надо ударятся в крайности и пытаться максимально круто наворотить технологию, если она всё равно не сможет работать в существующем процессе.