TxM 066 Section 7.10 Steps in developing a hierarchy Created by James on 7/4/2013 3:09:39 PM
Strategic engineered precision taxonomies (SEPT) require the development of highly structured taxonomic hierarchies, the steps in developing such hierarchies are as follows:
1. Accurate identification of the list
Make sure that you clearly understand the purpose and the ambit of the list from careful consideration of the exact name of the list and also understanding of how the software references and uses the list elsewhere (if applicable).
I frequently encounter lists which contain content that bears no relation to the name of the list or the purpose of the list in the software. Then people blame the software for not working correctly and build workarounds that get more and more complex and remove the operation of the software further and further from its original design.
It is vital to understand that it is extremely bad practice to use a list for something other than its intended purpose.
If you identify an information need and there is not a suitable list then it is preferable to add a user defined field rather than bastardize an existing list.
2. Entity-relationship logic
Entity-relationships define the relationship between different logical entities and their corresponding data tables, thus, for example, a business has customers and customers have orders and orders have order lines. Validation and other lists and fields should be incorporated on the data tables that are appropriate to the logic of the REAL WORLD.
Failure to do this will result in all sorts of apparently aberrant behaviour by the software and all sorts of workarounds, etc. It is vital that the real world logic is accurately modelled.
If you are not familiar with the rules of entity-relationships I recommend that you find someone who is to advise you before you use a list for a purpose other than that for which it is intended. It is no good setting up well designed content in a list that is in the wrong logical location in the database and then complaining that the software does not work properly.
3. Start with a clean sheet
Start the design of the hierarchy with a clean sheet of paper / spreadsheet / worksheet, do NOT under any circumstances try and fix an existing list (unless you are cleaning up a really well designed list that has been badly managed) – you will waste large amounts of time and produce a sub-optimal outcome.
The human brain is a highly powerful, abstract, cognitive super-computer – use the existing lists as a source of brainstorm material but build the new taxonomy on a clean sheet. See the article "The Power of an executive with a clean sheet of paper".
4. Cascade
The hierarchy MUST cascade. Indent each row down the hierarchy by one character in the form of a leading blank space.
This is vital in order to ensure that the hierarchy is easy to read by personnel posting against it in the future and also to ensure that the logic of the hierarchy flows smoothly. The visual effect of the indents ensures that the hierarchy is easy to interpret.
5. Capitalize headings
In building the taxonomy capitalize the headings and in application of the hierarchy train staff NOT to post to headings EXCEPT in the case of budgets and mappings which may post to headings.
All possibilities that apply to a heading should be listed under the heading.
The use of capitals is also for ease of reading when posting and when summarizing reports.
Posting level lines should be in lower case with the first character of the description and proper nouns capitalized.
6. Identify the type of list
Refer to the different types of list and make sure that you have correctly identified the type of list (and data) that you are working with and that a hierarchy is, in fact, applicable. Note that there are distinct principles that apply to developing hierarchies for different types of data.
7. Comprehensive view
Develop a high level view of the total ambit of the information required in the hierarchy through intuitive understanding and / or getting the right person or people in the room and / or through research.
Generally this means consulting with senior business people, particularly with regard to something like a group-wide Chart of Accounts or Item Master, etc.
8. Push the envelope
Push the envelope in terms of possible future growth – consult with executives in terms of possible future growth and provide headings and gaps to accommodate foreseeable growth.
9. Develop major categories – 5 to 9 optimum
Formally or informally develop the major categories that describe the content of the hierarchy. Generally aim for between 5 and 9 headings with the optimum being 7.
If there are 5 or less items look for ways to split some of the headings into more than one category and increase the number aiming for 7.
If more than 9 look for ways to group categories to reduce the number, aiming for 7.
With large hierarchies you may need to iterate several times before you get this right.
I consistently find that where I take more time to refine to close to 7 categories the final list is tighter and makes more business sense than lists with 5 or less or 9 or more items.
10. Multiple dimensions
Sometimes you will find that you come up with more than one set of equally valid groupings.
This may indicate that the naming of the list is too broad or is ambiguous in which case you may need to split the list into two or more attribute sets and add one or more additional user defined fields to the relevant data table.
Alternatively you may duplicate the second list down the first list for every instance to create a simulated matrix list. The correct treatment for such a situation is to recognize that you have identified a matrix type of relationship and then to build the resulting matrix or cube in accordance with the principles applied to the Cubic Business Model for financial data.
The key consideration is to accurately model the real world.
11. Locations
Locations should follow a logical geographic progression that makes sense in the context of the geographic distribution of the organization – for example clockwise round the country, or the world, etc.
12. Functions
Functions should be arranged logically such that the most core functions are at the top of the list and the least core functions at the bottom. A useful test is "is this something that I could easily outsource?" — if so this is NON-core. If you cannot outsource it easily because it is a key differentiator or represents the essence of the business then it is CORE.
13. Iterate to fine granularity
Depending on the scale of the subject area iterate down the hierarchy in each segment until you reach the posting level as determined by the "screw metaphor"—that is small and unambiguously unique bins each of which contains data with one explicitly unique and mutually exclusive combination of attributes such that ALL permutations are catered for by explicit bins.
Take time to brainstorm and research ALL possible elements for any component of the hierarchy.
14. Element sequencing
Sequence the elements in any component from a strategic fundamental first principles view point such that the strategic (essential) elements are at the top of the list segment and the most operational (least strategic) are included at the end of the segment.
15. Multi-faceted hierarchies
Note that on large complex hierarchies such as the Item Master or Materials Master or for document filing schemes there may be different logic for different components of the hierarchy. These will ultimately give rise to compound, complex code schemes.
16. Languageing the hierarchy
As you build the hierarchy language each level of the hierarchy very carefully so that reading down the hierarchy tells a very detailed story – a comprehensive and unambiguous reading down to the posting line.
This must take account of the different rules that may apply to different levels of the hierarchy – for example core operating consumables for an earth moving machine may be identified explicitly, as in the case of an air filter whereas seldom purchased body parts may be classified using a sequence number in the code scheme and only added when required,
17. Exceptions -- Other
Where "Other", "Unknown" or "Not applicable" are valid options provide for them at the end of the relevant hierarchy list components and code appropriately.
Note that there ARE times when one or more of these logical elements IS valid and needs to be provided. If they are provided they should be coded appropriately and managed with appropriate exception reporting, that is a report listing all instances of "Other".
By way of example I nearly always code "Other" as "9" in a numeric code scheme or "Z" in an alpha or alpha-numeric code scheme so that it is at the end of the list element. The fundamental logic is that operators must scroll past all valid options before selecting "Other" and that accordingly "Other" will only be used under exceptional valid situations.
Basically "Other" should only be used when an operator requires training as to where to post or where some instance occurs where there genuinely is a transaction that is not catered for in the body of the code scheme. In the first instance training should be given and in the second an additional code should be added if "Other" is occurring reasonably frequently. With this philosophy "Other" is valid and should be catered for and managed.
During implementation it is recommended that reports are produced to list all instances of "Other" so that they can be managed as suggested above.
18. Calibration
Once the lists are thought to be complete, hold up the new lists against the old lists and tick off line by line to ensure that everything on the old lists is catered for on the new lists. Sometimes this can be done as part of the mapping process linking old to new codes but this checking should generally take place well before the mapping stage in order to avoid having to add codes during the mapping process. This will ensure that the mapping process will proceed quickly and smoothly.
The above is an outline of considerations and steps in the development of a hierarchy. I hope to produce more detailed material in due course.
[MAKERATING]
The comment feature is locked by administrator.
Return