The following are the stages in the development of a Product / Item or Materials Catalogue – the term used will depend on the software, for example Syspro uses the word “Product”, Lawson M3 and Infor LN use “Item”, SAP uses “Materials” – they all relate to the stuff the business works with.
In the case of a mine the catalogue will be a relatively static list of approved products, materials, consumables, etc that are used by the mine whereas in the case of a warehouse through which pass a rapidly changing range of products the catalogue may be very dynamic. In the case of a Professional Services company the catalogue will be different again. A fundamental understanding of the essence of the business and its dynamics is VITAL to the development of an effective catalogue.
In addition, different software may use the Product / Item / Materials master file for different purposes, for example, Lawson M3 includes all sorts of non-product items in the Item Master including invoice line text, project names, asset labels, etc and drives a huge range of configurable functionality off these records. A thorough understanding of how the software works and how it will be configured in order to best fit the business is essential.
In ALL cases precision configuration based on precision taxonomies is an essential element of a high value solution.
In some cases the Product / Item / Materials master may use a meaningless reference code such as an EAN Barcode while the intelligent logic sits in the class or group table which sits above the base table. In other cases the logic should sit in both tables with the master file mirroring the class / group logic and in other cases different logics might conceptually occur although I have not seen this.
This article the general steps that will be followed in developing a Product / Item / Materials master file catalogue taxonomy and coding scheme.
A highly experienced facilitator and supporting team is vital if this entire endeavor is to result in a high value outcome. Note that NOT all facilitators will produce the same outcome and that some designs will be radically better than others. Cutting corners in this process is asking for a long term low value outcome that will destroy value throughout the business for as long as the sub-standard configuration exists.
1. Overall configuration design
Depending on the nature of the business the product catalogue may drive the product master / material master / item master or equivalent or may drive the product class / material group / item group or equivalent table. In certain cases the group / class logic may be replicated and extended in the detail table while in other cases the two tables may bear NO correlation with one another. There is a great deal of diversity in developing the hierarchies for this component and the first stage in the development of a catalogue is to ensure that all team members understand exactly how the business works at a fundamental level AND how the software works at a fundamental level AND how the two are to be integrated in the precision configuration solution.
Undertaking this discovery and first principles analysis is critical and time consuming and it is likely to require at least three iterations to arrive at a solid understanding of how the software configuration is going to be populated to model the specific business in question. A highly experienced facilitator is vital.
Note that to the extent that strategic drivers such as finance, etc can be different for apparently similar businesses there is NO one-size-fits-all definition – the configuration logic must be assessed from first principles for every project.
2. High level catalogue logic
Development of the high level product / item / materials catalogue logic requires a fundamental first principles analysis of ALL components of the business. With tight facilitation this analysis is likely to require of the order of three to five iterations before it stabilizes. Further refinement down the track is common.
The first 3 or 4 levels of the hierarchy will require executive input with support from senior managers with each element of the master list potentially having radically different characteristics.
3. Harmonization across modules and tables
Harmonization of the high level taxonomy architecture across ALL related software modules should take place as an integral part of the iterations to develop the hierarchy of the product / item / materials master / class / group. Failure to do this in a controlled manner across ALL related modules and tables can give rise later to time consuming and highly inefficient iterations if not managed effectively from the start. The goal is to achieve logic that supports high level strategic and operational objectives harmoniously across ALL modules and ALL tables. Time required for these iterations is challenging to estimate – it is NOT finished until it is finished!
4. Comprehensive reference data
At an early stage in developing this hierarchy / catalogue it is vital to obtain comprehensive lists of all types of entity that have historically occurred or which can be reasonably anticipated in the future – effective strategic facilitation by a highly experienced facilitator is absolutely vital.
5. Extending the catalogue
Having developed the top 3 or 4 levels of the product / item / materials hierarchy with the executive team and having iteratively reviewed this logic across all modules where it is connected the remaining detail must be developed using the managers and supervisors responsible for each section in the code scheme. A responsible individual with a supporting team of people who know the data intimately must populate a draft list for each section within the high level framework guided by a senior facilitator who understands the parameters defined by business executives.
Once this detail has been collected a series of working sessions with a senior taxonomy facilitator will be required to drive the taxonomy down to the finest level of detail
Note that the same team of facilitators under the direction of one executive level strategic facilitator must facilitate ALL sessions in a highly structured manner that ensures that the body of knowledge and experience pertaining to the hierarchies is progressively elaborated as the project progresses.
Typically between three and five iterations will be required to achieve a high quality taxonomy with broad consultation each step of the way.
6. Sub-groups
Sub-group taxonomies such as mobile plant components, product sub-categories and other repetitive attribute code components may take 3 to 4 iterations to develop owing to the need to harmonize across the different modules.
7. Coding
At intervals throughout the process trial code designs must be built in order to ensure that all team members can clearly see how the taxonomies will summarize for operational and reporting purposes. The resulting periodic reviews of the design associated with these coding iterations may often result in dramatic restructuring of the hierarchy as business personnel become more conversant with how the final deliverable will appear in practice.
8. Operation and maintenance
Once completed the final taxonomy and code scheme should last for many years if properly maintained. Proper product / item / materials master maintenance together with associated class or group table taxonomies must be put in place using personnel who were involved in the development of the catalogue and under tight management and supervisory control.
I look forward to discussing how I can assist you in developing a strategically high value product catalogue -- James@James-A-Robertson-and-Associates.com