понедельник, 26 августа 2013 г.

К вопросу оборудования.

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


В качестве наглядного примера, могу привести ситуацию, актуальную, скажем для 2008 года, в то время безраздельно властвовали коммуникаторы на Win Mobile, и если вам нужно было недорогое и при этом надёжное аппаратное решение для мобильной торговли, я бы не раздумывая предложил HTC 3400 (кто знает – тот поймёт). Посудите сами, в продаже он находился чуть более 2х (!) лет, технических проблем не имел, построен был на распространённой платформе и в случае ремонта проблем бы, скорее всего не возникло, запчастей навалом и они не дорогие. Я даже пару постов в этом блоге написал, восхваляя многолетнюю работу этих девайсов в качестве тестовых машин. И кстати, большинство постов моих тогда было про коммуникаторы и опыт их использования, практически каждая модель, описанная тут, работала под моим наблюдением не меньше полугода, что в руках торгового представителя можно было запросто считать годом работы. Меня даже называли любителем гаджетов, хоть это и не совсем так.
Что же происходит сегодня. Полгода, а это минимальный срок, за который могут вылезти болячки – это срок жизни современного коммуникатора на конвейере. Дальше сильный дисконт и забвение, через год запчастей не найдёшь. Другими словами индустрия мобильных устройств на столько ускорилась за последние 5 лет, что на момент получения опыта использования устройства оно уже снято с производства и редко встречается в продаже, что делает его менее интересным для применения в корпоративном секторе, ведь парк устройств надо обслуживать, и, к сожалению, периодически производить ремонт (вспоминаем про жёсткую эксплуатацию).
По этому, на данный момент на этапе выбора чаще начинаем руководствоваться не опытом реальной эксплуатации, а техническими характеристиками, принимая во внимание бренд (в том числе и по причине гарантийного обслуживания) и дополнительными аспектами, влияющими на живучесть мобильного устройства. Вот об этих критериях выбора я напишу чуть позже.

понедельник, 12 августа 2013 г.

Секретность.

Сегодня в очередной раз получил вопрос, на который отвечал уже многократно, посему решил сделать пост - универсальный ответ на вопрос о защите данных в системе мобильной торговли.
Часто спрашивают, а как в мобильной торговле Наполеон обеспечивается защита передаваемых данных, дескать, у нас же: а) секретный ассортимент, о котором не надо знать конкурентам; б) у нас секретные цены, это наше преимущество; в) у нас засекречена наша клиентская база и взаиморасчёты. Согласен, обладай конкуренты этой информацией – конкурировать будет легче, проще будет перебивать предложения, и отвоёвывать торговые точки.
Но друзья, а мобильная торговля то тут причём? Нет, это я не к тому, что АСМТ Наполеон не защищает информацию.
К сведению, обмен данными у нас устроен по нестандартному (проприетарному) протоколу с архивацией и шифрованием данных. Проломать протокол, разобраться в потоках и получить информацию о клиентской базе агентов, возможно ценах и может быть дебиторке – сложно, но возможно. На это потребуется несколько месяцев работы действительно специалиста + не хилый бюджет в несколько десятков тысяч евро (примерно такие расценки, ага).
Но мы отвлеклись, почему некоторые владельцы или управляющие думают, что мобильная торговля – это единственная дыра, внедрив которую бизнес станет уязвим?
Рассмотрим другие варианты получения конкурентами вашей информации:
1. Торговая точка.
А) Товарные накладные. Часто был свидетелем тому, как эти самые ТТН в прямом смысле слова разбросаны чуть ли не на прилавке, да даже если и не так, простое предложение торгового представителя конкурирующей структуры посмотреть в эту самую накладную не думаю, что будет встречено непониманием, самой точке это тоже может быть выгодно, если ей предложат товар дешевле.
Б) Взаиморасчёты. Аналогичным образом можно узнать и объём отгрузок и частоту и т.д. Иногда, торговые точки упрощают задачу и вывешивают лист с оплатами контрагентам, сам тому был свидетелем.
2. "Коррумпирование" торгового представителя (либо других сотрудников), думаю, тут всё понятно.
3. Банальный "гоп-стоп" с реквизированием КПК и получением данных по конкретному торговому представителю.
Что-то мне подсказывает, что все эти методы получения информации (которые существовали и до мобильной торговли) на порядки дешевле и понятнее для конкурентов. А значит попытки взлома мобильной торговли это самый последний вариант получения информации, к тому же что-то подсказывает, что эта попытка не будет нести экономического смысла.
А по сему, советую обратить внимание на все аспекты защиты данных, есть сильно больше слабых мест, нежели ПО.










четверг, 8 августа 2013 г.

Всего и побольше!

Так уж получилось, что я имею непосредственное отношение к проектам мобильной торговли, на моих глазах росли и развивались в самостоятельные ветки множество клиентских версий, естественно это были обдуманные шаги, продиктованные особенностями бизнес-процессов и видением руководителей по улучшению своей же работы. Иногда эти изменения были продиктованы извне, например соблюдение дистрибьютором федеральных стандартов. Так или иначе, у нас появился достаточно большой перечень функционала, созданного в ходе этих доработок. Что-то мы добавляем в базовую версию, так как эти изменения действительно улучшали её и могли бы быть востребованы большинством клиентов, какие то функции мы описываем в нашей базе знаний, в дальнейшем их могут добавлять в свои проекты как текущие, так и новые клиенты. Вообще, добавление, каких либо функций в проект часто не требуют дополнительного бюджета, так как с 2008 года мы даём каждому новому клиенту бесплатные часы на кастомизацию своей мобильной торговли.

Такой подход помогает нам иметь весьма простую, но эффективную программу, которая не содержит багажа невостребованного функционала, она проста в освоении, проста в работе и не "напрягает" пользователя. Абсолютное большинство наших клиентов это тоже понимают, и не "жадничают" с добавлением дополнительных функций, а смысл, бесплатные часы не сгорают, на текущий момент это не надо для компании и команды торговых представителей, зачем лишняя работа на внедрении и постоянные помехи в работе.

Сегодня я столкнулся с обратным явлением, у заказчика, который уже запускает проект, внезапно разыгрался аппетит, и в качестве задания на доработку я получил копипасту практически всего дополнительного функционала мобильной торговли Наполеон. Сначала я не поверил в это, возможно ошибка, так много функций (даже взаимоисключающих) для регионального дистрибьютора на старте проекта – это как бы вообще неожиданно. Не в том дело, сможем ли мы это реализовать, сможем, вопрос в другом, зачем? Зачем добавлять в проект функционал по соблюдению регионального стандарта производителя (другой категории товаров) с которым он не сотрудничает? Или зачем ему сразу 5 (!) вариантов контроля дебиторки один другой во многом повторяющий, это, кстати, дополнительная нагрузка на интеграцию и однозначное увеличение бюджета интеграции мобильной торговли.

Мы часто вступаем в диалог с клиентом, если у него появляются такие фантазии, наверняка все его запросы можно решить малой кровью, предложить другой вариант реализации, уверен, это ТЗ будет изменено. Если этого не произойдёт, могу предположить такой сценарий развития данного проекта: через месяц после интеграции все поля не относящиеся к заказу, все эти смарт-задачи и прочее будет заполняться бессмысленными знаками препинания, у торгового представителя будет уходить заметно больше времени на работу в точке для того, чтобы просто выполнить базовые задачи (взять заказ, проверить задолженность, сделать фото-отчёт), о программе будут отзываться как о самой неудобной в мире, ни для нас, ни для заказчика это не интересно, так зачем это всё?

Я часто это говорю, повторюсь и сейчас, от заказчика должны поступать только реальные задачи, которые надо решить проектом, от исполнителя – вариант реализации, если заказчик хочет собрать все функции ради того "чтобы было", то это минимум глупо и не эффективно. Про то, что это увеличивает срок запуска проекта, бюджет и снижает удобство работы говорить уже нет необходимости – это очевидно.

Смотрите трезвее на вещи и не жадничайте, никуда этот функционал от вас не убежит.