Though STEP is highly configurable with regard to the creation and maintenance of dimension and dimension points, certain implementation standards apply when they are created. This topic outlines some considerations to keep in mind when determining how to configure your system to handle dimension-dependent data.
Dimension Do's and Don'ts
Dimension Do's
- Use as few dimensions as possible—dimensions affect usability.
- Dimension-dependent data is a good concept but should not be taken too far.
- The more dimensions you introduce, the more likely it is that users will have to flip back and forth between contexts. At some point, users will forget to change contexts, and then mistakes happen, such as adding data in the wrong dimension for a long time before the mistake is realized. There is no easy way to find out what should be corrected.
- When lot of data must be entered while working in one context, and then some of it has to be entered in another context, there is a risk that the user will forget to break up the information into separate load files, or they will forget to change contexts for part of it.
Dimension Don'ts
- Do not introduce a dimension unless there is strong justification for it
- Do not use a dimension for any aspect of data that will be temporary, such as a website dimension, a print publication dimension, or promotions.
Note: Never use more than three dimensions. Typically, only two should be used, though it is possible to even use only one—language.
Additional Attributes as an Alternative to Additional Dimensions
As an alternative to dimensions, consider using additional attributes or additional reference types, which are acceptable if you only have a small amount of information that will vary by language or country.
|
Arguments for Additional Attributes |
Arguments for Additional Dimensions |
|---|---|
|
This is a simple approach for users to understand. |
Using the same attributes in layers enables re-use of integrations, saved imports / exports, and Web UI screens. |
|
Users can compare values for all versions side-by-side in an Excel file. |
Users can compare values for a single attribute across dimensions using the STEP context mode. Select this icon from the workbench to switch to STEP context mode. |
|
More dimensions will drive more contexts. More contexts means users have to be aware of which context they should work in, causing a high risk that people will make mistakes and put data in the wrong context. |
There will be fewer attributes. Separate attributes for each dimension could mean many hundreds more attributes. |
|
More dimensions will drive multi-dimensional attributes, which are to be avoided. |
|
|
To load via Excel, it is easier to add more attribute columns to Excel than it is to separate Excel files when some of the data has to be loaded to a different context. |
|
Language Dimension
There must be a language dimension. This is the only dimension that is supported by the STEP translation tracking and translation workflow features. For more information on the translation functionality of STEP, refer to the Translations documentation here.
Even if you do not use multiple languages, you must have a language dimension for the language in which you are maintaining your data. Choose a real language so that it is very clear what belongs there. The language dimension is special in STEP because it tracks changes between a source language and its translations. This means that there are no STEP tools to help users find instances where content in a country-dependent attribute value has changed and may need to be updated for other countries.
In many installations, only the language dimension point is required. Additional dimensions, such as country, are not needed if there is no country-specific data, such as warranty information that varies depending on which country a product is sold. The screenshot below shows a dimension hierarchy in System Setup and two contexts that only use the Language dimension.
Country Dimension
The Country dimension comes standard with STEP, but if you do not need it, remove it until you do.
You should only use a country dimension if the following conditions apply:
- You have products that are sold in more than one country and there are a lot of attributes with different values because of the country they are sold in.
- You have products that are sold in more than one country and there are a lot of references that are different because of the country they are sold in.
- You are using the Stibo Systems GDSN solution, which requires that each target market references a context containing a language and country dimension.
If there are only a handful of attributes and products are only sold in a few countries, use separate attributes to hold this information—for example, 'Description, English,' 'Description, German,' and so forth. Additional references might also be used if they are relating information that varies by country. For example, a product could reference a PDF document and the document contains different information in some countries. Instead of making the reference dimension-dependent, you could make separate reference types ('Warranty, United States,' 'Warranty, Canada'). For information on dimension-dependent references, refer to the Dimension Dependent Reference and Link Types topic here.
Business Unit Dimension
Business unit dimensions are sometimes used in larger enterprise implementations as well as in cases where customers start out with a STEP implementation, then acquire another business.
Business unit dimensions may be needed for enterprise-wide implementations if the following conditions apply:
- The exact same products, with the same internal ID, are sold by more than one business unit.
- Each business unit must share the same pool of attributes, and there are no clear 'owners' of the attributes. For example, an attribute like 'Description' is used for products across all business units instead of there being separate attributes for each business unit—'Acme Shoes Description,' 'Acme Electronics Description,' or 'Acme Clothing Description.'
Even if these conditions apply, it should not be an automatic decision to use a business unit dimension. Different customer-facing part numbers, for example, can be stored in separate attributes. If part numbers are different based on the business unit selling the products, you might need a business unit dimension, but this is not enough justification on its own to do so.
Market Dimension
Market dimensions are not recommended; however, this section addresses them mainly to provide alternatives to their use.
Any requirements for market-dependent data are typically for a small number of attributes or references, which can be handled by a less-complex approach of additional attributes and/or references.
- Most market-specific attributes typically are separate attributes
- Market-specific asset references can be handled by separate reference types
- People who maintain market-specific attributes would only be able to partially approve their own content, which is the case whether they use dimensions or separate attributes
Alternatives to market dimensions are:
- Use separate attributes for web copy, print copy, and so forth
- Use separate reference types for different markets
- Group the reference types for visual separation
Dimension Point Do's and Don'ts
Dimension Point Do's
- In most circumstances, dimension points should be created at the same level:
However, sometimes there may be a need to have parent / child relationships between dimensions if you need to maintain many versions of an 'almost the same' language, as pictured in the below screenshot. In this type of setup, parent values from the top-level dimension will be inherited by the child dimensions. If this is implemented, there must be clear ownership of the parent language. Otherwise, do not use one.
For more information on use cases and the value inheritance of parent / child dimensions and attribute values, refer to the Dimension Dependent Attributes topic here.
- Be consistent across all dimension points and use IDs based on ISO standards. More information about these standards can be found on the web.
- For languages, use IDs based on the ISO 639-1 Language Code (2 letter) + ISO 3166 alpha-2 Country Code. For example, US English: en-US.
- For countries, use IDs based on the ISO 3166 alpha-2 Country Codes. For example, United States: US
Dimension Point Don'ts
Do not use an All dimension point in a context. Nobody speaks All Languages, nobody lives in All Countries, and nobody will maintain All.
Note: When content is not dimension dependent it is already stored in the All Languages and All Countries dimension points.