 |
|
Во-первых, рекомендую сразу избавиться от иллюзий. Если вы думаете, что решения "на заказ" делаются следующим образом: программист включает компьютер, сплевывает три раза через левое плечо, запускает текстовый редактор и начинает ваять с чистого листа, – могу сказать, что вы серьезно заблуждаетесь. Как правило, все "заказные" решения представляют собой модификацию уже существующих наработок.
Если же это не так, можете уверенно разворачиваться на 180 градусов и идти искать другого, более опытного, разработчика. Потому что оттачивать мастерство поставщика услуги на собственном проекте – дело не слишком выгодное. Лучше, если компания уже "набила шишки" на заказах, выполненных для ваших конкурентов.
Во-вторых, определитесь, что именно вас не устраивает в готовом решении. Так ли уж вам нужны управление взаимоотношениями с клиентами, интеграция с ERP-системой предприятия (если таковая вообще есть) или сравнение товаров? Зависит от масштабов бизнеса. Большинство "излишеств" в реальной жизни либо не используются, либо стоят слишком дорого, чтобы окупиться в обозримом будущем.
Если вы все-таки решились на "заказную" разработку, поинтересуйтесь, на какой базе какой платформы планируется осуществить проект. Не буду вдаваться в подробности той или иной реализации, однако грань между специализированными платформами и платформами общего назначения все-таки обозначу.
Итак, решение может базироваться на специализированной платформе, наподобие IBM WebSphere или Oracle E-Business Suite. Безусловно, подобная база обеспечивает более гибкие возможности по созданию систем электронной коммерции, нежели платформы общего назначения, большие возможности по масштабированию и расширению функциональности решения.
В защиту платформ общего назначения, вроде связки *nix+Perl или NT+ASP можно сказать, что решения, построенные на базе этих технологий, стоят дешевле как при первоначальной разработке, так и в дальнейшей эксплуатации. Они не требуют дорогостоящего оборудования и, отсутствие мощных возможностей и гибкости компенсируют относительной дешевизной.
Большим недостатком разработки на заказ является "иллюзия эксклюзивности". Помните легенду о том, что Иван Грозный приказал ослепить зодчих, построивших Собор Василия Блаженного? Вне всякого сомнения, многим заказчикам хочется поступить так же. Ну не глаза выколоть, но руки разработчикам укоротить – это точно. Увы, сейчас на XVI век, и всегда следует быть готовым к тому, что возможности, созданные специально для вас за 20 тысяч долларов, через несколько месяцев появится в очередной версии готового решения, которое стоит в 10 раз дешевле. Заключайте договоры о нераспространении, не заключайте, все равно не узнаете об этом.
Разработка решения на заказ – удовольствие дорогое и может обойтись в тысячи, десятки а то и сотни тысяч долларов, в зависимости от сложности. Перед тем, как сделать выбор в пользу этого варианта, надо точно выяснить: нет ли уже готового пакета, обеспечивающего нужную вам функциональность. Расчет возврата инвестиций – обязательный этап любого проекта, однако, при заказе таких решений следует провести этот расчет особенно тщательно и для различных параметров развития ситуации. И уж точно не вкладывать весь бюджет проекта в техническое решение. Техническое решение – это всего лишь одна из многочисленных составляющих успеха проекта. Будут и другие, в том числе, и более важные. Так что желательно "семь раз отмерять", а уж потом заказывать.
К расходам на разработку волей-неволей придется добавить расходы на поддержку и эксплуатацию, которые будут наверняка выше, чем при покупке "готового" решения. В особенности, если заказанное решение разработано на основе одной из специализированных платформ.
Не видать и бесплатных обновлений – все, что не в ТЗ – за дополнительные деньги. Так что задумайтесь: а нужна ли вам нужна развитая система управлением взаимоотношениями с клиентами (если на рекламную кампанию по привлечению этих самых клиентов ничего не останется), подключение к десятку платежных систем (все равно предпочтительный способ оплаты – наличными курьеру), интеграция в реальном времени со складскими и бухгалтерскими программами (если прогнозируемый объем заказов – 3-5 единиц в день, а своего склада нет и не предвидится).
Надеяться на особую оперативность и думать, что заказанный магазин начнет работу уже через месяц, тоже не стоит. Если решение вам нужно "вчера", лучше поступиться некоторыми возможностями и хотя бы на время арендовать готовое решение, а уже затем делать индивидуальный заказ.
Когда планируется серьезный (заметим в скобках, "и в перспективе окупаемый") проект, решение должно быть функциональным и масштабируемым. Ни о какой аренде (даже временной) или, тем паче, размещении в торговом центре, речи здесь идти не может.
В заключение, хотелось бы обратить внимание на то, что многие МАГАЗИНЫ уже поднакопили опыт и, помимо непосредственно торговли, занимаются и разработкой интернет-магазинов для сторонних организаций. Преимущества таких компаний очевидны: в отличие от теоретиков электронной коммерции, они сами набивали шишки и преодолевали трудности, и – главное –знакомы не только с языками программирования, но и с практической стороной интернет-торговли.
Продолжение: "Создание интернет-магазина: разработка собственного решения"
|
|
|
