|
|
|
 |
|
|
|
E-commerce
Myths and legends, traps for the unwary
For those thinking of building an online shop, e-commerce initially appears to be a solved problem. By that I mean there are tens of thousands of eCommerce sites on the internet - so it must be easy right? Wrong. Whilst the tools and techniques for selling over the web are well established, applying them to your project, on time and on budget is far from easy. Sure a non-techie can download a free shopping cart system and maybe even connect it to their merchant or Pay Pal account. After this we see people running into the same problems time and time again. This article aims to give you some pointers and tips to think about so that your ecommerce project is a success. First, things to think about ...
Catalogue of errors
Loading products into the e-shop's catalogue.
If you're only selling a few products this isn't a big deal, however for most people with a reasonably comprehensive online store you quickly run into thousands of products across dozens of categories and sub-categories. Often these products are sourced from a variety of suppliers, so there's no single source of data. Even when all of the data exists within a single organisation we find that the Accounts package has a different version of the product data than Sales. Which to use? Is one more authoratative or up to date than the other? Are some fields only present in one source - do they need to be merged? What started out as a web project quickly becomes an internal IT data integrity issue. The upshot for the project is feature creep, delay and a budget that now looks woefully inadequate.
Eventually you get your hands on the data whether its internally, an XML feed from trusted suppliers, lots and lots of typing from the hard copy price list or wherever. This is often the first time this data has existed in a single database, so the first time you load it up you notice that some products get rejected because of duplicate product codes. Of course Jimmy in Sales knows that an XYZ001 in blue is different to a green one, but if they both have the same product code your shiny new relational database will choke. There's nothing for it but to bite the bullet and assign unique product codes to these, which may be fine, but then again may be different to that used by your supplier. Upshot? You end up maintaining two product codes, the one you and your supplier have been using for years, plus a new unique one to get this project off the ground.
The next thing you notice is the variation in the product data. The vast majority of product web pages use a handful of templates to display your wares to the world. If some products have a piece of data missing there's going to be a hole in your product page that sticks out like a sore thumb. Worse, it may be an essential part of the buying process, so now you have to clean the data too. Who was saying this stuff was easy?
Assuming you managed to import data into the shop's catalogue in the first place you may now be wondering how to get some products listed under more than one category.
|
| |
|
|
|
