Considerable thought and planning is required to design a product configurator. There are no hard and fast rules about how to go about it. Treat the following as an initial guideline and topic list. If you wish, you can commission your Match-IT supplier to help you. These are the major planning topics that should be considered before you actually start defining the product configurator.
The first task is to realise that a product configurator will help you. A product configurator is likely to be useful if you find yourself creating very similar product structures on a regular basis.
The next task is to identify how many product configurators you need. You could have one large product configurator that covered all your requirement or a number of more specialised ones. Generally, creating several specialised ones is more convenient because they will be smaller, simpler and run faster.
The only reason for using a product configurator is if you wish to design specific variants of something. This implies choices. All the choices should be identified. These will becomes the questions that are asked when the product configurator is run.
The result of running the product configurator will be a product structure. The form of the product structure will dictate the form of the associated product configurator. You will find it helpful to draw the product structure you intend to create for easy reference when defining the product configurator.
You will also find it helps to create an example of the intended product manually first, noting what you did as you go. Essentially, all a product configurator does is generate the entries you just made in the various forms associated with creating a new product.
Identify all the processes, resources, inspections, parts and services that are required for your product structure. Identify where they all fit in on your diagram of the product structure.
Identify any new codes and code classes you require for your product configurator. You could use codes to present the user with a limited set of named options in response to a question. For example, you could define a colour code that only allows a response of a standard colour name.
Identify any qualifiers you wish to associate with the elements of your product structure. Qualifiers are useful to specialise something. For example, to define the surface finish of some material you might need.
All the elements of the product structure you are going to create with the product configurator are defined by records in files. For example, a component that goes into a 'widget' is defined to the system by a record in the mcb:Assembly Structure file. The product configurator will need to create all these records. Annotate you diagram with the records to be created.
All the responses you made when you manually created an example of the product are defined to the system by fields in records. For example, the class of the product is defined by the mch:Class field. The product configurator will need to create all these fields. The files reference section in the on-line help system lists fields that must be considered. Annotate you diagram with the fields to be created.
You may find that some elements of your product structure are dependent on choices made elsewhere. For example, which lathe you use to turn something may be dependent on the diameter of the 'widget' being turned. In these kinds of situations you will find that using a look-up table might be helpful (see How do I define a look-up table?). Note all these situations and what the dependencies are.
Many of the fields you identified earlier will need values that are calculated in some way from the choices selected. For example, the amount of time it takes to drill the holes in a printed circuit board is dependent (mostly) on how many holes have to be drilled. These calculations are defined by expressions. Note all the expressions required to define all your field values.
Many of the records and fields you identified earlier will need to be given names for the purposes of referencing them within the product configurator. Inventing names will be one of the hardest parts of the overall design task. It helps if you define a 'convention' that allows you to invent names quickly. One possibility is to use a convention that mimics the hierarchy of the product and the fields involved. For example, if making a 'widget' requires a quantity of 'gizmo' then the symbolic name for that field could be: WidgetGizmoQuantity (joining capitalised words like this is a common programming convention).