четверг, 24 декабря 2009 г.

Слагаемые успеха проекта.


Бытует мнение, что чем лучше (известнее) и функциональнее софт (можно добавить ещё переменных по желанию), тем успешнее проект автоматизации мобильной торговли. Мы (и я тоже) не согласны с этим утверждением, вернее не совсем согласны. Что мы понимаем под успешным проектом? Проект, в котором эффективно (с наименьшими затратами) решены поставленные задачи. То есть два основных момента: эффективно и решены. Сегодня хотелось бы сделать акцент именно на «решены».
Уже давно нами замечена одна тенденция: если руководство компании проявляет живой интерес к проекту, то он обычно успешный (если относится к нему попустительски – то автоматизация идёт «тяжело»). Трактовать это можно следующим образом: руководитель, понимая суть предстоящих мероприятий, старается принимать участие в управлении этими мероприятиями (занимается планированием, делегированием и, конечно, контролем процессов внутри организации), в этом случае он понимает, что купленное железо и софт всего лишь инструмент, который может и не работать, если не приложить к этому усилий (особенно в самом начале).
При этом, торговый персонал чаще в данной ситуации ведёт себя пассивно.

Понимая всё это, мы, кроме прочего, стараемся следовать следующим правилам при проведении работ по внедрению:
1. Чётко распределяем обязанности и ответственных за определённые операции внутри организации.
2. Стараемся максимально просто и доступно объяснить технологию и алгоритм работы системы для всего персонала причастного к её работе.
3. Стараемся дополнительно мотивировать торговый персонал, объясняя реальные выгоды от использования КПК (это один из важных моментов).
4. По окончанию обучения оставляем максимально возможные контактные данные специалиста проводившего внедрение (рабочий и сотовый телефоны, icq и т.д.) для всего персонала (каждый может обратиться и задать любой вопрос по работе программы или оборудования).
5. После завершения проекта периодически проверяем работу комплекса и персонала (особенно в первые недели).
Понятно, что трудно следовать этим правилам досконально, поэтому бывает, прибегаем вариациям этих пунктов (без ущерба для результата, естественно). Эти моменты помогают решить поставленные перед проектом задачи, при этом в весьма короткие сроки, но, это уже тема эффективности, это в другой раз.

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

четверг, 17 декабря 2009 г.

Топ 5 Фактов о нас.

Часто я пишу о том, что мы являемся разработчиками программного комплекса «НАПОЛЕОН», мы делаем проекты мобильной торговли, а кто мы – не пишу. Сегодня решил исправить это недоразумение и представляю вам топ 5 фактов о Гильдии Разработчиков…
Поехали:
1 Самый быстрый проект осуществлён нами за половину рабочего дня (проект удалённый). То есть, от момента предложения проекта автоматизации, до момента запуска базовой версии (её было достаточно) прошло не более 5 часов. Со стороны заказчика выступал Дмитрий Смирнов, ООО ЦВК.
2 Самый «долгий» проект начался в мае 2009 и до сих пор развивается. Заказчик просил не называть компанию… Неуёмной фантазии человек :).
3 Мы действительно работаем не только с 1С. Кроме 1С есть много проектов со СБИС++, есть с Microsoft Dynamics NAV, даже с Баланс+... Вообще, иногда возникает ощущение, что специализируемся на «геморройных» проектах (да простят заказчики за такую яркую формулировку).
4 14 декабря 2009 г. было выписано Лицензионное соглашение №300 (для ООО Балми, Ярославль).
5 На данный момент, средний возраст работников Гильдии – 33 года. Знаковый возраст…

На самом деле жаль, что ограничен только 5 пунктами, думаю в скором будущем появится Топ 5 Фактов о нас 2.
Успехов.

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

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


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