Following are some thoughts on the knowledge, experience, etc that I apply in doing ERP and other taxonomy work which I hope you will find of interest and value.

In reading this please keep in mind that you have probably never seen a taxonomy suite that meets the standards set out below, they are very few and far between.

The absence of such precision strategic taxonomies is, I am increasingly seeing, the BIGGEST SINGLE REASON for sub-optimal ERP and other sub-optimal IT implementations:

1.   Business knowledge and experience

Broad based understanding of the different aspects of business that the taxonomies under development will address.

Includes understanding of headline accounting principles (balance sheet and income statement) if working on financially related taxonomies.

Headline understanding of all the components of business.  Detail understanding is where client personnel live their lives, it is the responsibility of the taxonomist, in consultation with executives to lift out the high level order and hierarchical logic that will make the system implementation strategically valuable and model the real world of the business.

When an executive sees any final taxonomy they should immediately say "YES, that is my business".

2.   Strategic insight

Rapidly grasp the essence of the business and how it thrives (strategy) and how this impacts reporting and therefore taxonomies.

Without strategic insight the outcome is a ho-hum configuration that does not support high value decision making.

Taxonomies designed with primary focus on the essence of the business, the business fundamentals, the core drivers, the basis on how the business competes and differentiates itself will ensure that this critical information is at the forefront of reporting and analysis and, indeed, at the forefront of how the software is operated in practical terms in the business.

This will facilitate and support optimum high value decision making as the primary deliverable of the ERP and, it so happens, will result in optimum operational and tactical decision making as well.  Coupled with well designed, logical and intuitive code schemes and rigorous hierarchical taxonomic layout strategic insight in taxonomies results in drop down lists, validation lists, charts of accounts, materials master lists, item master lists, employee categories, plant categories, asset categories, product classes, etc, etc that are intuitive and easy to use.

Clerks remember the codes more readily, navigate to the codes they do not know faster, make fewer posting errors and overall operation of the system becomes easier and more fluid with proper training.

The precise modelling of the real world means that reports can be segmented precisely to correspond to the staff accountable for particular expenditure and revenue and management reporting down to the most junior supervisor becomes more precise and more convenient.  This results in operational efficiencies, improved delegation and resulting broader effective span of control.  The same management team can do more with the same overhead resources.

Strategic focus in all code schemes ensures that when making decisions the focus is always first on the most strategically appropriate information and activities and this, in turn, assists the business to become more competitive and more profitable.  Non-profit organizations will focus most appropriately on their core reason for existence.

3.   Decision making principles

Basic principles of decision making, governance, accountability, reliability of information, cognitive span, drill down, fundamental first principles design.

Understanding how people make decisions and how to present information to facilitate high value decision making, as summarized under the previous point is vital to designing taxonomies.

Information that is laid out in a manner that facilitates rapid and precise inquiry, the ability to get answers to questions that have never previously been asked and were never foreseen are essential elements of a well-designed ERP implementation.

From a decision making perspective the fundamental requirement for an ERP is "provide the answers to every question for which data can reasonably be expected to be in the database".

The flip side to this requirement is "ensure that all classifiers regarding every item of information in the ERP are presented as well structured precision strategic taxonomies and that ALL classification information is contained in the ERP -- add custom fields as necessary".

A further extension of this is "ensure that you activate and productively employ ALL modules of your ERP that have relevance to your business".

Yes, it IS possible to account for everything in the General Ledger, a General Ledger IS just a large book with lots of columns so you can account for anything you like in the GL if you really want to.  BUT there are other modules that are more appropriate to managing components of your business such as projects, plant, people, production lines, product marketing, etc, etc.

Depending on the size of your business you should move more and more information out of the general ledger into sub-ledgers and sub-systems.  A one man business is quite able to manage everything in the GL, a business turning over billions and with thousands of employees should be operating a diverse suite of specialist modules to manage these components.

Each of these modules should be strategically implemented with one overarching taxonomy architecture that extends end to end through the entire suite of business software with the same code segment used everywhere.

The ease of use that results from such rigour and precision in taxonomy design and coding gives huge benefits in terms of ease of use, precision of inquiry, ability to quickly and easily ask and answer questions that would otherwise be difficult, time consuming and expensive to answers.

Executives, managers and supervisors do NOT want to spend time trying to figure out how to ask the question and get the answer, they want an immediate answer to the question or a rapid answer to complex questions and then they want to be able to ask more and more questions.

Inherently this implies that the data from your operational database will be uploaded daily into a data warehouse equipped with an appropriate business intelligence tool (read sophisticated data analysis and reporting tool) which enables them to quickly and easily make complex inquiries.

BI tools are ONLY truly powerful, valuable and cost effective WHEN they are commissioned to sit on ERP and other data that is highly structured with highly effective precision strategically aligned taxonomies.  In the absence of precision strategically aligned taxonomies NO software (ERP, CRM, ECM, etc, etc) will deliver high value strategic outcomes.  There are ADDITIONAL factors that must be addressed which are discussed at the Executive Briefing listed at the end of this email and also discussed in various previous newsletters and articles copies of which are available on request.

Where it can be reasonably foreseen that a particular measurement will be required at some time in the future this should be accommodated in the ERP implementation, either by user defined fields or through customization or the development of supplementary tables alongside the ERP.

Medium sized businesses and larger businesses should employ a full time or part time analyst to design and execute sophisticated queries, build complex economic and other models and generally assist the business to harvest the strategic insight that well designed taxonomies give into operational data.

4.   Semantics

Semantics of the target language (English or other) for the taxonomy are vital.

The words in the drop down lists, chart of accounts, etc are the ONLY basis on which the operator or the person producing a report have to choose where to post or what to report on.

Precision choice of language and abbreviations is absolutely essential, choose words that accurately and distinctly describe a specific line in the taxonomy.  “Hear” what the client is “actually” saying and interrogate inconsistencies and anomalies.  Meaningful abbreviations and, where applicable, code mnemonics.

In developing taxonomies give the client what they NEED NOT what they say they want.

The role of the strategic taxonomist is to understand the business sufficiently to engage in the facilitation process in such a manner that where client representatives use language which is not precise they pick this up, ask questions and investigate until the correct languaging and hierarchical content is defined.

This can be a tedious and at times frustrating and even emotional process.

People are used to using imprecise language such as "factory" when they mean "manufacturing" and such-like inconsistencies.  The problem is that the person who types in factory may know they actually meant manufacturing but the next person to post to the taxonomy or to draw information out based on it will NOT know this and will frequently make mistakes.

Note that very few code schemes that I have seen in implementations across the full spectrum of small and big ERP products would meet even the most basic criteria to be classified as taxonomies, let alone hierarchical taxonomies and even less Strategic Engineered Precision Taxonomies (SEPT).

In reading this article it is vital to consider that I am writing about something that you may NEVER HAVE SEEN IN PRACTICE...

5.   ERP / IT knowledge

In order to design really effective ERP taxonomies it is vital that the taxonomy architect knows how ERP's work, the essence of IT, the essence of databases, what programming languages do, the basics of numeric processing, the reality that computers work with binary data, principles of grouping, etc.

The ability to quickly grasp how the individual tables will interact with one another and the software, the distinction between configuration relating to parameterization and configuration relating to integration, etc must all be understood.  A clear headline understanding of entity relationship mapping and other data modelling concepts is also vital in the context of deducing the entity relationship model on which the software is based and identifying the optimal code design and information gathering approach for that software and business.

There must also be informed insight as to alternative courses of action in cases where specific data is required which the standard product cannot accommodate.  When to use user defined fields, when to add custom tables and custom software functionality.  The taxonomy architect must understand the technology in sufficient detail to give guidance with regard to all aspects of the technology implementation and to steer the overall project to the desired strategic outcome.

This includes a robust understanding of the compromises that result from failing to use all relevant modules in an ERP, the problems associated with overloading the General Ledger with detail that should be managed in sub-modules, the implications of using third party modules instead of the modules that come with the EPR and the basis of decision making whereby a third party module would be selected in preference to a standard module.

Together with this must be a very high level of awareness that integration is primarily a data and corporate politics (people) issue and a strong focus on achieving integration by maintaining precise data and taxonomy harmony and correlation between software from different suppliers that may not integrate at all electronically but which share the same data.

Awareness that the best ERP implementations are meticulously planned and that the coding schemes are developed as part of a single over-arching integrated view of the business and ALL modules is vital.

Taxonomies are one of the front end inputs to an ERP implementation and are FAR MORE IMPORTANT THAN PROCESS MAPPING.  Headline level understanding of business processes is relevant at the start of an ERP project but the DETAILED specification of business processes is a project OUTPUT and should be defined in concert with the laboratory stage.  Thereafter the process specifications should ideally be embedded in Computer Based Training  (CBT) material.

The solution architect should insist on rigorous testing in a formal laboratory where a laboratory is a test set up which accurately simulates the real world and rigorously tests ALL valid scenarios with small quantities of high quality representative data that tests every facet of the implementation at a level that can be signed off by the auditors BEFORE GO LIVE.

6.   Coding / taxonomies

Fundamental principles of taxonomies and code schemes.  Different types of code schemes (I have identified nine distinct categories), coding principles, use of delimiters, when mnemonic codes are appropriate, principles of numeric and alphanumeric coding, how people interact with code schemes, how taxonomies and code design drive ease of use and value delivery exponentially.

Formal training in a taxonomic discipline such as Information Management (Library Science), Zoology, Botany, or similar is helpful (I have formally studied and applied zoological taxonomies in detail and also studied and applied information management catalogue design in detail in my PhD research, knowledge and experience of large corporate filing systems is also a relevant source of experience.

I have experience in all these areas and first applied this knowledge practically and in depth with regard to ERP implementations over 23 years ago.  Ever since then "data engineering" or "precision strategic taxonomies" have been a central and vital element of my approach to every ERP implementation I have been involved in.

The benefits are huge, a wealth of management information, the answers to every practical question, greatly improved efficiencies, better decision making, increased profitability, leaner growth, operational efficiencies including unplanned headcount reduction and reduction in audit fees to name but a few.

I have been using complex taxonomies since 1978 and structured taxonomies with ERP and other IT projects since 1987 with great success and huge productivity and strategic decision support benefits.

I suspect that there is an element of "I do not know what I know at a conscious level"!!

 7.   Attention to detail and precision

Precision in code table design and maintenance is vital to a high quality, sustainable outcome that is truly efficient and effective.  An effective suite of software tools will assist with this.

 The person doing the detail design of the taxonomy and the coding scheme must be a high detail person who is naturally precise to a level of being pedantic and who will be rigorous and consistent.

It is a reality that many people do not have the knowledge and experience to develop precision strategic taxonomies and code schemes so the personnel to be deployed in this area must be carefully selected and trained.

The use of Psychometric instruments such as the Predictive Index and others should be seriously considered to help select the right people.

It is vital that the person who maintains the code schemes after deployment has training in these principles and is precise.

The opening of a single code or account in completely the wrong location leads to an IMMEDIATE DEGRADATION in the effectiveness of operation of the ERP or other IT system in the same way that leaving one bolt out of a critical component of a motor car can result in major damage.

The value of a dedicated coding professional, even if only on a part time contract basis, cannot be over-stressed.

8.   Analytical thought leadership

The person who leads the taxonomic (and solution architecture) functions must analyse the requirement from a fundamental first principles perspective and tie semantics, business understanding, ERP understanding, etc, etc together to deduce what will actually work in practice and guide the client to a high value outcome.

The client knows their requirement in broad terms but seldom if ever in a structured manner.

As a general principle it is a mistake for the client to lead the project and dictate strategic architecture and taxonomy design decisions.  The strategic solution architect is the translator who is required to understand the essence of the clients business and interact with the client to facilitate a high value outcome.

It is a serious mistake to undertake any major ERP or IT project without a highly experienced strategic solution architect leading the team.

This person must have strong analytical and deductive skills, excellent command of language and the ability to distill the essence of the problem and the requirement and develop a solution architecture and high level strategic design that will deliver exceptional lasting business value.

9.   Other

There may be other elements I apply without thinking but I think these are the main knowledge and experience areas that I use in developing taxonomies.

Excellent taxonomies are the difference between ho-hum or frustrating outcomes and high value outcomes.

There ARE many other facets to achieving successful outcomes such as executive custody, strategic alignment and architecture, change facilitation, an engineering approach to project design and operation, etc but the ONE factor above all others that will destroy value in an ERP implementation if not correctly executed is the data engineering in the form of precision strategic taxonomies.

Sort by: Newest First Oldest First Most Popular Most unliked