среда, 18 декабря 2013 г.

Автоматизируй это

Мы уже писали однажды о том, как у нас бывает устроен прайс-лист, и о том, как можно встраивать в него не только описания, но и фотографии товара. Но это было давно. А мы продолжаем работать и совершенствовать свои приложения, поэтому с тех пор многое изменилось.

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

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

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

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

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

Спешим на помощь! Попробуем автоматизировать поиск вариантов и принятие решений. Вот общий вид прайс-листа.



Все как обычно – каталоги сформированы по категориям, а внутри категорий товар рассортирован по алфавиту.



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



Какова бы ни была структура каталога, цель одна – быстро ищем нужную товарную позицию. И не забываем про красивые фото – они всегда только в плюс.



Легким нажатием на фото переходим в карточку товара – и вот тут-то самое интересное! Видите маленькие картинки внизу? Их там много, «бегунок» внизу экрана это показывает.



В данном случае мы «присортировали» сюда разных рыб, непротиворечивых по условиям содержания. Нет нужной рыбы – замени близкой по смыслу.

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






Пока так. Когда поймем, как сделать еще удобнее – будем дорабатывать.

пятница, 25 октября 2013 г.

Режим работы кассы - круглосуточно

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

Документом типа «Инкассация» оснащено любое приличное приложение для мобильной торговли. Оно может как-то иначе называться – «ПКО», например, или еще какое «Изъятие средств». Но суть та же – документ для фиксации приема денег в торговой точке.

Мы тоже приличные. У нас «Инкассация» есть в нескольких вариантах. Первый, самый простой – взял денежку, записал сумму, черкнул оператору записку, если надо.


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


Если клиент хочет оплатить накладную в полном объеме, то выбираем режим «Вручную». 


Нажимаем на нужную накладную, документ автоматически оформляется, а клиент выкладывает на бочку ровно восемь тысяч семьсот шестьдесят рублей семьдесят девять копеек.

При передаче информации на сервер накладная будет закрыта автоматически. Ergo, никакой бумажной волокиты.



Если же клиент просто вручает нам энную сумму, не равную задолженности по какой-то накладной, выбираем режим «Автоматически». Сумму указываем в поле сумма…



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

Накладную необязательно закрывать одним платежом. Можно просто оформить сколько-то денег в счет нее и уменьшить долг только на эту сумму.




Ну и записка оператору, как же без нее.




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

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

В следующую базовую версию нашей программы мы включим «Инкассацию» как обязательный элемент. По умолчанию – простую. Полезная вещь, все про нее спрашивают.

Инкассацию можно привязать к стоп-листам, и внесших деньги клиентов тут же и разблокировать. Особенно полезно это для van-selling`а, то есть продаж «с колес». Хотя и pre-seller`ам тоже – не затягивать с прощением штрафников, а получить деньги – и тут же им можно дальше продавать.

А о стоп-листах и прочих полезных напоминалках у нас вот тут написано. Читайте. Обсудим.
 
 

пятница, 11 октября 2013 г.

Кейс: Поставщик из 3х букв.

2010 год, Москва. Компания Винный стиль уже 2 года использует Мобильную торговлю от компании, позиционирующей себя как №1 в РФ по количеству реализованных проектов и проданных лицензий.

Текущему IT директору этот проект достался от предшественника, с рядом не решённых вопросов. Несмотря на минимальные требования к системе (приём заявок в торговых точках, контроль долгов, фиксация координат GPS созданных документов) уже долгое время не удаётся решить, казалось бы, мелкие недочёты, которые выливаются в большие неудобства, а именно:
  1. Ограничение на длину наименования товара (приложение умеет показывать товар только в одну строку), что существенно замедляет работу;
  2. Только 2(!) уровня в прайс-листе (в прайсе алкогольных компаний чаще всего номенклатурных уровней гораздо больше), что так же замедляет работу с каталогом продукции.
Справедливости ради следует отметить, что в данном случае система вела себя достаточно стабильно.

Руководству заказчика пришлось вступить в переговоры с исполнителем для решения этих "мелких" недочётов, на согласование ушло 2(!) месяца, в ходе которого удалось достигнуть договорённости только в вопросе увеличения уровней вложенности номенклатуры, эти доработки предполагали некое "обновление" стоимостью 80000 (восемьдесят тысяч) рублей. Что в свете предполагаемого увеличения количества лицензий (порядка 7000 р. за лицензию (кстати, не самая большая стоимость от этой компании)) формировала бюджет в несколько сотен тысяч рублей, эта цифра показалась неразумной и IT отдел приступил к поиску альтернативных решений, благо исходя из предъявляемых требований к мобильной торговле у компании был выбор.

В процессе выбора представитель компании – заказчика договорился о демонстрационной версии АСМТ Наполеон со всем необходимым минимумом (который был в базовой версии) для тестовой эксплуатации. Далее был не самый простой переход, так как пользователи "вкусившие" и отчасти "наевшиеся" передовыми технологиями от самой крутой компании в РФ воспринимали в штыки любую попытку изменить их работу. Так или иначе, но постепенно были переведены самые активные пользователи, получены положительные отзывы и далее по накатанной был автоматизирован весь штат торговых представителей.

Бюджет автоматизации ВСЕХ мобильных пользователей был, сопоставим со стоимостью "обновления" предыдущего решения, в этот же бюджет вошли индивидуальные доработки. Следующий небольшой функциональный апгрейд и сборка мобильного клиента под Android OS (лицензии остались прежние) был произведен примерно через год в относительно небольшой срок (полторы-две недели). По сей день Винный стиль пользуется этим продуктом.

Выводы, которые можно сделать:

  1. До приобретения мобильной торговли нужно понимать, соответствует ли система предъявляемым требованиям.
  2. При выборе поставщика решения "на берегу" обсудить возможности доработок и обновления системы (об этом уже писал), как вариант – предложить техническое задание на доработку (пусть даже фейковое) и оценить срок реакции, бюджет доработок и срок реализации – кстати, хороший показатель работы с компанией в будущем.
  3. В самую последнюю очередь слушать песнь о том, какие исполнители крутые, всемогущие и вообще, а лучше договориться о визите к действующему клиенту и выяснить вопросы эксплуатации, поддержки и обновления проектов или просто попросить контакты этих клиентов. Сканы благодарственных писем – не расскажут об этом, у них другая задача.
  4. Если вас пытаются развести на большой бюджет (опираясь на то, что внедрение произведено и уже куплена часть лицензий) – посмотрите по сторонам, многое вокруг могло уже измениться.

понедельник, 7 октября 2013 г.

Три магнитофона, три портсигара отечественных, куртка замшевая…



Торговый представитель не только заказы составляет. Он еще должен подсчитать количество заказываемого товара.

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

Если он будет ошибаться в меньшую сторону, то повысится риск вымывания товара из ассортимента. Не проследили динамику – насколько хорошо, например, продаются вот эти чипсы, сколько было в прошлый раз заказано, а в позапрошлый, сколько в остатке тогда и сейчас – взяли поменьше, а потом вовсе засомневались и не стали брать. А потом как-то забыли…

А ведь важны не только количество заказов и выручка. Важно, чтобы количество товарных позиций, которые заказывает контрагент, не сокращалось, а росло.

Чтобы поменьше всяких сложностей в уме держать, мы тут тоже попытались автоматизировать, что можно. Вот результат – опция «Сложная история продаж»! Очень полезная, все всегда пользуются. Поэтому мы ее даже в базовую версию включили.

Итак, ставим в настройках галочку, что она нам нужна.



Тогда в окне товара внизу появляется три строчки циферок. С датами.




А еще упрощается съем остатков. «В точке» - это как раз сколько сейчас этого товара осталось в точке. Эта же цифра – первая в столбике.

Вводишь ее – и программа автоматически считает вторую цифру, off-take. Предыдущий остаток плюс предыдущий заказ минус остаток.

Ну и третья цифра, тоже автоматически считается. Это, собственно, количество товара, которое программа рекомендует заказать.

У нас на двадцать восьмое число пока «В точке» ничего не записано, значит ноль. Смотрим данные за двадцать седьмое: 6+8-0=14. То есть off-take равен 14. Сошлось? Сошлось.

А рекомендованный заказ выводится по формуле off-take* k, где k – назначенный нами коэффициент. Обычно это 1,5, по умолчанию эта цифра всех устраивает. Но понятно, что она может варьироваться – если товар сезонный, например, или еще почему. Варьировать ее тоже можно, но это уже хитрее делается.

Окей, с количеством товара разобрались. А с количеством товарных позиций? Где записано, что в этой точке обычно заказывается и как часто? Чтобы уж точно ассортимент не сузить.

Для этого у нас тоже опция есть. Напомните, потом расскажем.

понедельник, 30 сентября 2013 г.

Решение задач по озадачиванию

Мы стали замечать, что клиенты все реже заказывают АСМТ «Наполеон» в базовой комплектации (заявки – посещения – долги - остатки) и все чаще интересуются разными дополнительными функциями.

С чем это связано?

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

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

С крупными и очевидными допзаданиями мы быстро разобрались. Например, инкассация, продажи «с колес», разная хитрая работа с прошлым и будущим ассортиментом, сбор статистики и всякой прочей информации.

А вот как быть с мелкими и разовыми заданиями? Не хочется записывать на бумажке, как в прошлом веке.

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

Сегодня мы вам покажем, как этот документ у нас выглядит сейчас. По-моему, мы уже пришли к удобному варианту, лаконичному, но емкому.

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



Агент на своем КПК будет видеть список задач в разделе контрагента, которому эти задачи назначены.



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


А если ему все понятно – просто ставить галки о выполнении.


У менеджера на ПК ведется статистика – сколько задач назначено, сколько из них выполнено, а сколько нет.  


А легким движением руки, то есть нажатием на одну единственную кнопку, менеджер составляет отчет о выполнении задач. Со всеми комментариями агента.  



Хороший, годный документ. К мелочам ведь тоже внимание нужно.

Пожалуй, в следующую базовую версию «Наполеона» включим его по умолчанию.
 

среда, 4 сентября 2013 г.

Утром стулья, вечером деньги


Как скажет вам любой классик нашего дела, "важнейшей из функций для нас является подсчет дебиторской задолженности".
Ну конечно, что есть дебиторка, если говорить простым языком? Это деньги, которые твое предприятие уже заработало. Надо только их получить.
Приравнять работу с дебиторкой к одному варианту реализации невозможно. То есть возможно, конечно, но получится так себе.  Потому что у всех клиентов к ней разный подход. Кто-то устанавливает отсрочку, и если контрагент даже пару миллионов задолжает, лишь бы платил потом вовремя. Кто-то ориентируется на объем - сто кило он в долг доверит, а сто один уже нет. Когда-то важны оба параметра, и контора их регулирует то так, то этак для каждого контрагента. При работе со скоропортящимися товарами оплата заказа логичным образом привязывается к отгрузке. Вообще вид товара сильно влияет на то, как лучше организовать дебиторку.
Помимо общей логикии процесса клиент выбирает показатели - какие будут постоянными, а какие переменными, и от чего эти переменные будут меняться - скажем, объем от типа товара, отсрочка платежа от типа оплаты, скидка от общей суммы покупки, штрафные проценты от величины просрочки.
Поэтому мы с каждым клиентом уточняем, что нужно именно ему. Мы предлагаем несколько базовых вариантов, но в двух третях случаев заказчик не выбирает один готовый, а комбинирует несколько или вовсе придумывает свое.
Не хвастаясь, скажем, что за немалые наши годы мы автоматизировали продажу, наверное, всего, что вообще можно продать - от запчастей до колготок, от котлет до элитного алкоголя. Разве что борзых щенков с нами не продавали. Но лекарства и корма для них - было дело.
Однако требования очередного нового клиента к контролю дебиторской задолженности нет-нет да и заставят нас задуматься.
Всегда есть общие данные, которые непременно будут - общая сумма задолженности каждого контрагента и список накладных формата номер накладной/дата/сумма.


Можно на этом остановиться, а можно еще данные об отсрочке и частичных оплатах выводить:


Можно каждую накладную разворачивать и смотреть список товаров с ценами.


 Можно красить накладные в разные цвета в зависимости от просрочки.


Можно ставить всякие флажки и напоминалки, чтобы, например, при составлении заказа агенту ни с какими списками не сверяться, а программа бы ему сама напомнила.


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

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

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

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


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

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

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

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










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

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

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

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

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

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

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

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

четверг, 4 июля 2013 г.

Бойцы невидимого фронта

Как сегодня сказал Вова, «мерчендайзинг – странный объект: вроде он есть, но его как бы нет».

В этот раз предлагаем поговорить не о достижениях и фичах.
А о людях.
Есть такие очень важные работники торговли – мерчендайзеры, которые занимаются очень важным и сложным делом – мерчендайзингом. Сложна эта работа потому, что, с одной стороны все, кто в теме, по-разному понимают круг обязанностей мерчендайзера. А кто не в теме, относятся к такой работе скептически и даже высмеивают. Видели скетч Реввы про мерчендайзеров? Престиж профессии как-то не очень высок, мда.

С другой стороны, вот в Википедии кто-то умный попытался датьопределение и составить список должностных обязанностей мерчандайзера. Собственно, список обязанностей и стал определением. И, положа руку на сердце, я бы на место такого бедолаги не подписалась. Должен ВСЕ, но так расплывчато…

Но тут же, в той же Википедии: «В результате своей эволюции, мерчандайзинг стал ещё и инструментом, дающим ощутимые конкурентные преимущества. Статистика свидетельствует, что покупатели оставляют на 13 % больше денег в тех магазинах, где мерчандайзинг продукции безупречен».

«Мерчандайзинг продукции так же важен, как разработка бренда товара, наружная реклама или проведение рекламных акций» (тоже Вики).

Все, кто занимаются торговлей, это понимают. Поэтому и мы над этим задумываемся – стараемся им помочь.

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

Снова Вики: «Очень часто внедрение мерчандайзинга начинают именно с контроля и анализа выкладки товара».

Ну это просто. Для этого у нас есть функция «Мониторинг», про которую мы даже как-то писали.

«Основная задача — контроль наличия всего ассортимента компании на полках магазина и расположение его в наиболее благоприятных для покупки местах.» (тут).

Отлично. У нас есть функция «Посещение», где агент делает заметки и фотки. Составляем сценарий из посещений, указываем, что фотографировать и о чем писать.


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

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

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

Кто не согласен?

пятница, 7 июня 2013 г.

Рутина и как ее организовать.


Обычно когда говорят, что «никто другой, только мы» - это о каком-то поводе для гордости.

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

Красивая фраза, которую мы приготовили для вас сегодня, а вы сами судите, есть ли тут чем гордиться: ни одна другая российская программа мобильной торговли не дорабатывается так часто, как АСМТ «Наполеон». Ручаемся.
Почему? А все из-за того же курса на кастомизацию, а не на «продукт в коробочке».

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

Вот пример программы для клиента, с которым мы работаем несколько лет. Название компании закрашу, простите, privacy. Двадцать семь раз дорабатывали. И это не предел.


Эта статья – про то, как мы организовали процесс доработки. Про то, как не утонуть в море обновлений, мы говорили в прошлый раз.

А сегодня про то, как не увязнуть в доделках.

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

Но если вдруг клиенту ничего не глянулось и он хочет чего-то принципиально нового – мы готовы. Оцениваем срок и, если надо, стоимость. После чего менеджер назначает специалиста-кодера, который будет осуществлять доработку, и тестировщика, который примет работу. То есть в одной доработке задействованы только три человека, притом менеджер – минимально. Кодер и тестировщик условия и сроки знают, дальше в их работу никто не вмешивается.

В означенный срок клиент получает версию не только готовую, но и проверенную. Это не гарантирует, что ошибок вообще совсем не будет. Бывают всякие ситуации – например, какой-то кусок кода плохо ляжет на какую-то версию OS Android, на которую клиент перешел, а нас не предупредил. Или особенности конкретных коммуникаторов и планшетов, связанные, например, с разрешением экрана – мы стараемся обговаривать с клиентами допустимые варианты, как раз во избежание, но случаи бывают разные.
В целом это исключения, а не правила.

И как показывает наша практика, двух с половиной человек на доработку более чем достаточно. Не надо разводить лишнюю бюрократию и лишний контроль. Если вы можете доверять своим работникам – оставьте их в покое. Они не подведут.

вторник, 28 мая 2013 г.

Подождите … Осталось 3 ч. 59 мин…


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

Для нас этот вопрос особенно важен, потому что мы ориентированы на кастомизированные проекты. Причем мы не просто берем конструктор, собираем, меняем настройки – вуаля, новый проект. Наши проекты новые без дураков, у каждого куча собственных фишек и индивидуальных особенностей. Соответственно, обновляются они тоже по одному, и не регулярно, а по мере пользовательской необходимости, так что, например, для OS Android нас Google Play как механизм обновления не устроит.

Проще говоря, обновления чего-нибудь для кого-нибудь – это то, чем мы занимаемся постоянно, проектов-то много. Придем с утра в офис и давай обновлять…

Не подумайте, что мы жалуемся. Вовсе нет! Курс на кастомизацию мы взяли сознательно и точно знали, на что идем. А проблему обновлений мы решили. Как? Секрет, но вам скажем.

Давным-давно, во времена Palm OS, мы решали ее очень просто. Удаленного обновления тогда не существовало, и все делалось одним-единственным способом – через программу HotSync.

Когда мы выпустили версию 3.0, мы в числе прочего поменяли и способ обновления. Сделали  в программе «Наполеон – Администратор» закладку «Обновления». Сейчас мы таким способом только лицензии подгружаем (о чем, кстати, в прошлый раз писали), а тогда эта закладочка много для чего использовалась.


Так вот. Формировали пакет со всеми данными, которые в программе поменялись, передавали, а на месте они аккуратно раскладывались. Не подменой программы, а именно обновлением самого кода программы. Сам файл весил немного, килобайт сто. Тогда еще 3G практически не было и вообще не так-то просто было что-то передать, так что маленький размер был существенным плюсом.

Мы очень собой гордились – филигранное же дело! Но потом от этого варианта пришлось отказаться, потому что Windows Mobile начал стремительно устаревать, меняться, производители его все время дорабатывали, о чем не всегда сообщали. Это создавало кучу неудобств и пользователям, и нам, всячески нарушало стройность и красоту нашей системы.

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

На нашем сервере есть директория каждого нашего проекта. Дорабатываем программу – выкладываем обновления в эту директорию – сообщаем заказчикам, что обновление готово, можно загружать.

Кстати, мы никогда не делали и не сделаем принудительного обновления. Вас когда-нибудь раздражал девайс, который в середине вашего рабочего процесса вдруг начинает перезагружаться и тупить? Спорю, что да. Поэтому мы против того, чтобы мешать пользователю, когда он работает. Будет свободен – нажмет кнопку и запустит процесс.

Выглядит так: идем в раздел меню «О программе»…
…и нажимаем кнопку «Проверить обновления».
Если обновления есть, программа ими займется, а по окончании процесса отчитается.
Если обновлений нет, она вам об этом скажет.

Плюсы этого подхода:

- не надо иметь в виду какие-то отдельные устройства с их особенностями, загрузить файл сможет любой «Андроид»;
- файл обычно в пределах полумегабайта, в самых исключительных случаях (при очень больших обновлениях) – до мегабайта. Редко, но бывает. Но редко. Словом, при современном уровне связи вполне симпатичный размер файла;
- он отлично дополняет наш сервис баг-репорта (о котором мы писали тут). Случается ошибка (ой, не говорите про мифические программы, с которыми ошибок не случается никогда), программа отправляет нам сообщение, мы его получаем, чиним, что надо, отправляем им – и все это без участия ИТ-представителей и вообще без лишних переписок и растолковываний.

Да, не самый утонченный вариант и не самый изящный. Но утонченный у нас уже был. А сейчас мы пришли к выводу, что обновления – это не та задача, где стоит гоняться за красивыми решениями.

Гоняться надо за надежностью.