Product Databases – Requirements
|
|
Product databases contain both descriptive data, such as texts, images and prices, and ERP data, such as warehouse locations and availability. A large number of people collaborate to produce product data: graphic artists and shippers, materials requirements planners, accountants and many more besides. It’s a real challenge to set up and maintain an effective and efficient product database.
|
 |
|
 |
|
| What is product data? |
|
Product data consists of two main components, which are generally based in separate locations with different schedules.
|
 |
|
 |
|
Descriptive product data contains all information that could be relevant to a potential customer.
|
|
The ERP data contains all information required for purchasing and operation.
|
|
This includes, for example, texts, images, availability and prices.
|
|
This includes, for example, supplier data, warehouse locations, prices and availability.
|
|
The price and availability data do not have to be the same as ERP data.
|
|
ERP data are usually commercial data relevant to the flow of goods.
|
|
|
 |
|
 |
|
|
|
|
|
Descriptive product data |
|
|
Different teams with different skills work on the descriptive product data – at different times and from different locations.
|
|
Unlike the ERP data, descriptive product data is often collected and saved in a less structured way.
|
|
Different viewpoints and workflows are required to suit the needs of the different operators.
|
|
The real challenge consists of integrating all subprocesses to create a single, comprehensive and cohesive work process.
|
|
Parallel non-integrative processes should be avoided.
|
|
|
|
|
|
|
|
|
|
|
ERP product data |
|
|
The structure of a company’s ERP data is based on its business model and years of experience in handling the flow of goods.
|
|
Operators "work" with the data as information units that help them carry out their individual tasks (e.g. shippers --> parcel size).
|
|
|
|
|
|
|
The "make or buy" decision
|
Standard: generic data model
|
 |
Standard product databases (CatalogX, Jcatalog) use their own data models to map standing data (usually ERP data) very efficiently. Individual product attributes are saved according to a generic tag (e.g. "Name/Value"). |
|
However, hierarchically embedded data can be a problem. Here’s one example from the media sector: |
|
Die Verwendung von .NET und COM+ zeigt, das dieses Produkt neueste Technologien einsetzt. |
|
A music CD contains any number of titles by a variety of composers and artists. An individual title appears on several other CDs and the artist is only credited as a composer on other CDs. |
|
In Abhängigkeit der Komplexität der Quelldatenstruktur entstehen oft Redundanzen und/oder sehr tiefe Tabellen. |
|
Individual: proprietary data models
|
|
Data can be saved and maintained optimally using individual, user-specific data models – however, all of the data access paths must be developed and maintained individually. |
|
Object-oriented and component-based programming allows the number and extent of individual tasks to be reduced. |
|
In the context of complex corporate plans, individual projects are often seen as "semi-products" (Q/A, version creation, etc.). |
|
For individual projects, no server and/or client workplace license costs are incurred. |
|
|
If you require further information or would like to arrange a meeting with us, please click here.
|
|
