TxM 101 Taxonomy Manual Part 2: Why Use JAR&A, Required Knowledge and Experience, Cubic Business Model and Chart of Accounts and Taxonomy Software Created by James on 8/21/2014 9:57:15 AM
A discussion of why James A Robertson and Associates are the leaders with regard to this field, a discussion of the knowledge and experience necessary to develop high quality precision configuration, factors causing business information system failure, discussion of the differences between the work of different practitioners, some important principles, giving executives REAL information, the power of an executive with a blank sheet of paper, common mistakes, risks, the Cubic Business Model, Group Consolidation Charts of Accounts and why it is necessary to use software to build and maintain code schemes
Why JAR&A, Who is James Robertson, required Knowledge and Experience
Why not do it yourself without JAR&A?
Once you have read this manual and become sensitised to the issues you may consider doing the work yourselves. Following are some reasons why it would be advisable to have some level of involvement from JAR&A:
1. Like engaging an architect to design a complex building
As a general guideline, the process of designing a suite of SEPT Taxonomies and Configuring your system is like the architectural design of a large and complex building. It requires a highly experienced architect with an intuitive ability to discern what is best for your organization to design a building that really "works" for you.
So it is with a suite of Taxonomies, the high level architecture needs to be crafted in close consultation with your executives by a senior architect and then fleshed out to give the total design. This work needs to be performed with painstaking attention to detail. JAR&A offer such services.
2. Years of experience
James Robertson has over 22 years' experience building taxonomies in the ERP, DW and BI domain and 43 years' experience with taxonomies. The design of really well designed taxonomies is abstract and complex.
3. Exceptional outcomes yield exceptional returns
The value of an exceptional, high value outcome is huge and dwarfs the investment in time and money many times over. It is not wise to place this return at risk. This is NOT the place to economize.
4. Mediocre outcomes are not immediately evident
A mediocre or poor outcome is not evident unless you really understand the real potential of what has been missed. You will only recognize a mediocre outcome if you dig into the standards and protocols that JAR&A apply and by then it will be too late.
Once you have fully configured and fully commissioned a business information system the cost of reconfiguring it is huge and out of reach of even the largest organization. This really is a "once in a lifetime" opportunity and it is therefore important to do it right first time J
5. High precision outcomes cut costs
High precision designs properly implemented drive operating costs down and dramatically increase business benefit. This requires mature knowledge and experience to unlock the full solution potential. Cutting corners and saving money at the start is NOT the right thing to do.
6. Mediocre solutions drive up costs
A mediocre or poor design, whether well implemented or badly implemented, will drive operating costs up in perpetuity with no easy way to remediate the sloppy investment.
7. 20:80 -- NOT the place to economize
The SEPT precision configuration represents the 20% of the investment that will deliver 80% of the value return – this is NOT the place to economize.
8. We will train your staff
We will work hand-in-hand with your staff and train them in our methods to the extent necessary for them to deploy and maintain the solution but we will provide the high level strategic facilitation to ensure that the proper precision strategic framework is created.
JAR&A are the best route to follow to provide you with this service.
Introducing Dr James Robertson, PrEng
The ERP Doctor
Why should you engage with Dr James Robertson to advise you with regard to your IT and ERP issues?
Deep understanding of why IT and ERP investments do not deliver what was promised and how to rectify this problem
In 1989 James Robertson set out to "bring the disciplines of engineering" (high reliability, high value outcomes) "to the IT and ERP industry". He soon discovered that 70% of IT investments fail outright and only 10% meet or exceed expectations. By 1991 he was speaking regularly at public conferences on these findings and outlining methods to solve the problem.
As a consequence he has been engaged by numerous clients to evaluate failed and sub-optimal IT and ERP installations, turning most around but in a very few cases, advising clients to terminate the investment.
In 2003 he catalogued his findings and wrote the book "The Critical Factors for Information Technology Investment Success". That same year the Financial Mail reported that "19 out of 20 ERP implementations do NOT deliver what was promised". Gartner subsequently reported that "most organizations are NOT making better decisions than five years ago".
Since 2004 James has presented regular courses, advised numerous clients and continued to refine his techniques. This has brought us to a point where today Dr Robertson is a significant thought leader with regard to effective application of ERP in South Africa and possibly worldwide.
An executive level advisor for over thirty years – discusses IT and ERP in language executives understand
James first consulted to senior executives in Europe in 1982, he has been comfortable in the executive suite ever since.
As a consequence he knows what is important to executives and is able to speak their language.
James is an executive advisor first and an IT and ERP specialist second.
Over thirty years' experience in economics and decision support – understands the REAL issues required for your business to prosper
James "cut his teeth" in economics and decision support in 1982 and has a thorough grounding in the essential principles of economics. From this grounding he has developed a thorough grasp of the sort of information that executives need to make high value business decisions.
His first commercial IT project enabled the firm to double their turnover by taking on new international clients. This dramatic growth was as a consequence of capability conceptualized and implemented by James that enabled the firm to do things that much larger firms were unable to do.
A strategist with deep grounding in strategic thinking and methods – quickly grasps the essence of your business and how it thrives and how to use IT and ERP to support strategic functioning
James demonstrates an intuitive grasp of strategy and has been speaking about the importance of the strategic alignment of IT and ERP since 1990. He has pioneered the StratSnap critical issues thinking method and toolset and facilitated many strategic sessions for clients. The method systematically and rigorously leads clients through a step by step process to develop robust critical issues based strategic plans, requirement definitions, etc which focus on the essence of the business and how it thrives.
James regards strategic alignment as an integral and non-negotiable element of any IT or ERP investment and seeks to understand the essential drivers of the client business from his first engagement interview with new clients.
An engineering approach to IT and ERP – Engineers design bridges NOT to fall down
In seeking to "bring the disciplines of engineering to the IT industry" James has clearly identified that the design, deployment and operation of IT and ERP systems is fundamentally an engineering endeavour – a rigorous, precise and systematic method of working fundamentally attuned with creating new systems that fully meet client executive requirements.
At the same time, James has recognized that traditional engineering training fails to provide grounding in the soft issues like facilitation of change, strategy, corporate governance, communication, etc and he has integrated all of these disciplines into the approach that he advocates and the methods that he uses.
During this journey one of the fundamental observations that he has made is that:
"Engineers do NOT design bridges to stand up . . .
. . . Engineers design bridges NOT to fall down"
This understanding supports James' fundamental approach to "design for success by engineering against failure", an approach that underpins all the work that he does.
James maintains that it is not possible to produce a successful IT or ERP outcome without being blunt about the issues that are causing failure and systematically eliminating those factors from the project or operational environment.
Rapid and effective diagnosis of IT and ERP ills – the "Pulse Measurement" – what is wrong and how to fix it in 1 to 10 days – frequently saves clients millions
Since 1989 and the outset of his Professional Consulting Business Systems Engineering practice, James A Robertson and Associates, James has specialized in short sharp diagnostic interventions. These concentrate on the critical issues required to deliver the required business outcome in the shortest possible time.
This critical issues approach led to the creation of his flagship offering, the IT and ERP "Pulse Measurement" – a one to ten day intervention in which he systematically investigates the health of the designated IT or ERP system, department or other operational or project area that is giving cause for concern to executives.
These interventions always commence with interviews with the Chief Executive and other executives.
A key goal in these interviews is to understand the strategic essence of the business and the "burning issues" of concern to the executive team.
Informed by this high level understanding of the issues facing client executives, James then interviews mid-level managers responsible for the operation of the systems in question. This is followed by sessions with the operational staff and service providers culminating in a hands-on look at the systems and sometimes an end to end "walkthrough" of the system in order to understand the exact technical elements that are contributing to the problem.
The deliverable from the Pulse Measurement is a concise report listing approximately seven Critical Findings which are prioritized and weighted in terms of their relative importance in giving rise to the problem in question. These are followed by approximately seven Critical Recommended Actions, also prioritized and weighted, this time in terms of their importance in rectifying the problem. The findings and recommended actions are presented in simple language that is entirely understandable to executives.
James is able to deliver this high value outcome in such a short period of time by operating in much the same way that a Medical Practitioner is able to rapidly diagnose a medical condition and prescribe treatment.
He does this by holding up key observations against a body of thirty years' experience of what works and what doesn't and so a simple phrase like "I cannot get the information I am looking for from my ERP system" (a frequent complaint) instantly enables James to access a body of knowledge based on thousands of hours of practical experience as to what causes such a problem and how it can be fixed. Further investigation is geared to confirming the initial diagnosis and homing in on the specific issues.
Recommendations can be as simple as a change in policy or as drastic as a recommendation to abort a project or system and return to the previous systems. Recommendations frequently address issues of governance, executive custody, staffing, strategic alignment, communication and diverse other issues. The exact mix is unique to every organization but the range of diagnoses and treatments prescribed are frequently variations on themes encountered many times before.
Pulse Measurements frequently lead to significant changes in direction and sometimes save clients millions of Rands.
In all cases, the executives of the client organization have a much clearer view of the way forward and what the REAL ISSUES are once the Pulse Measurement is complete.
Clients regularly engage James to advise at some level with regard to the implementation of his recommendations.
Specializes in the practical high value application of IT and ERP in business – how to unlock the true potential of your ERP investment
James says "I get my adrenalin rush out of solving problems no one else can solve, I like achieving practical outcomes that work and I hate failure".
Based on this ethos, James has invested huge amounts of unremunerated time to understand the real issues in IT and how to achieve successful outcomes and how to achieve the true potential of ERP investments.
The techniques that James has pioneered are so innovative that it has recently become apparent that the standard of implementation of ERP that James regards as essential are such that dramatically better business outcomes are achievable for similar capital investment and lower operating cost than traditional approaches as illustrated in the figure below.
The right hand bar represents the standard of excellence that Executives think they bought (and that James champions) whereas the left hand bar represents the standard that is commonly delivered.
Strategic Engineered Precision Taxonomies (SEPT)
Over forty years ago James had his first encounter with taxonomies in a zoological context with taxonomy projects at school.
Subsequently he researched cataloguing principles and standards for classifying the test specimens for his award winning PhD research and was later exposed to the NATO document classification scheme.
When he first started working with ERP and other IT projects James automatically started applying taxonomies and rapidly achieved some major successes.
At first he thought that what he knew was common place and therefore he did not place much emphasis on it but has now come to realize that the standards that he developed in 1990 and has applied with great success on a number of projects constitute a standard that he has come to refer to as Strategic Engineered Precision Taxonomies which enables users of ERP's and Data Warehouse / Business Intelligence systems to raise the bar dramatically, as indicated by the diagram above.
In the process James has designed software to assist with taxonomies and there is a major development project in process at the time of writing.
If you have not yet spoken to James about Precision Taxonomies please give this serious consideration.
If you are frustrated that you cannot get the answers you need when you need them, feel that your IT staff live on a different planet and do not understand your needs, are not sure whether to replace your ERP or data warehouse, are being told you have bought the wrong ERP or Business Intelligence tools or are in any other way dissatisfied with your current IT or ERP dispensation James Robertson may well be the person to help you.
James Robertson's knowledge and experience
as applied to taxonomy development
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.
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 Pshychometric 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 overstressed.
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 distil 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.
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.
Knowledge and experience required for a senior SEPT taxonomist
This document outlines what currently seem to me to be the requirements for a taxonomist. I have encountered a few people who seem to intuitively understand taxonomies because they have been working with data and classification schemes for a long time and I regularly encounter people who think they understand but do not. It seems that there may be more women than men who have this aptitude.
It is important to understand that there are taxonomies that work and taxonomies that get in the way – there is a lot of skill required to produce a taxonomy that really works – once complete they look deceptively simple and it is not always immediately apparent that a taxonomy will not work – the art and science of the facilitator is a BIG factor here.
This is an area that requires a highly knowledgeable and highly experienced person in the appropriate fields as set out below.
At this stage the following should be taken as guidelines rather than as absolute rules.
Excellent command of English – the development of a taxonomy is fundamentally an advanced English language semantic exercise – I think an A or B Matric Higher Grade may be a minimum requirement with a Bachelor's degree majoring in English perhaps the ideal.
2. Track record with cataloguing
I find that people who do not have significant experience with cataloguing and adding logic to data struggle with taxonomies to the standards we are talking about here and most of them simply cannot get it right.
First prize would be a Bachelor's degree in Information Management (Library Science) and about five years post graduate experience or similar cataloguing qualification.
In the absence of a formal degree I think that at least five years experience or on-the-job in a related field is likely to be required.
3. Business understanding
Solid understanding of the basic principles of business – preferably some sort of business course or a good few years of hands-on business experience. Must be able to determine the essence of the business and how it thrives – strategy. Or, alternatively can only work under a senior taxonomist fleshing out detail.
4. Information system understanding
In order to produce taxonomies that work in an information systems context the aspirant taxonomist must understand how computerized information systems work, the basics of database design, etc so that they can ensure that there are discrete logical entities in each table and can identify when different entities or attribute lists need to be defined.
The taxonomist facilitator must be able to provide thought leadership and guidance to workshop delegates.
5. Practical common sense understanding of the real world
Sadly many personnel from the Information Technology space are out of touch with reality and do not have a solid practical common sense understanding of the real world and the ability to act as interpreters and translators of the inexact language that business people use and convert this language into precise taxonomies.
Careful selection of candidates requires that they have a practical sense of the real world.
6. Strong grounding in logic (mathematics?)
Hierarchical structured taxonomies are intensely logical devices, a Matric pass in Mathematics at least a grade C higher grade may well be necessary otherwise candidates must demonstrate exceptional logical ability.
7. Communication and facilitation skills
The facilitator must have well developed communication and facilitation skills and must be able to lead a group of frequently strong willed delegates down a road of progressive discovery to develop a viable taxonomy.
Time management is a critical skill.
8. Patience and other personal attributes
The facilitator needs to be patient, pay high attention to detail, systematic, methodical, precise. Precision taxonomies are very finicky and require fine attention to detail, logic, etc.
The facilitator must be willing and able to spend hours away from delegate groups cleaning up the results of workshops, adding structure, correcting logic, etc so that they can revert to the delegate groups with a quality working draft.
The above may look like a rather onerous specification, it is, there are very few people who I have met who have real skill when it comes to taxonomies. This is an area where a client cannot afford to cut corners, mediocre taxonomies will undermine the entire investment.
Causing Integrated Business Information System (IBIS)
The Critical Factors causing failure were identified starting in 1990 and were catalogued in 2002. They have been refined over time to the factors set out below:
1. I.T. Mythology – 30%
All the mistaken and false beliefs, believing computer are magic, believing you can have anything you say, using traditional methods that have consistently failed and expecting a better outcome, do-it-yourself mentality, delegation of executive level decisions to junior staff, the audit project model, process obsession, lack of precision, etc. Expecting computers to do things only people can do. Thinking you can use any team who work any way they like and it will work.
2. Lack of Executive Custody – 19%
A huge issue. The CEO must be the custodian of the IBIS / ERP / DW / BI investment – see article on this subject. Executives must drive the project and the taxonomies and high level configuration must be determined by executive level advisors assisting client executives.
SEPT taxonomies are one manifestation of a project with excellent executive custody and their absence is generally an indication of poor or absent executive engagement.
3. Poor strategic architecture and alignment – 16%
Lack of a clear definition of the essence of the business and how it thrives, lack of focus on configuring the fundamentals of the business, failure to accurately model the real complexity of the business. SEPT taxonomies result in part from excellent strategic definition and engagement and their absence is frequently an indication of a lack of strategic engagement.
4. Poor or absent Information Engineering – 14%
While the SEPT taxonomies and precision configuration are a reflection of the previous weaknesses they are an essential component of a high value configuration. They are the piece that stays behind when all the stuff in 1, 2 and 3 above and 5 and 6 below have moved on.
SEPT Precision Configuration is THE ESSENCE of a high value configuration.
5. Soft issues – change impacts – 12%
All change produces resistance. It is vital that this is managed by way of high levels of strategic executive direction, leadership and custody, excellent and compassionate communication, effective training, proper support, etc. SEPT configuration, by being practical and making sense reduces the resistance to change.
6. Lack of an Engineering approach – 6%
Lack of rigour, sloppy work, use of poorly trained or untrained personnel, lack of precision, everything that is the antithesis of "engineering" contributes to project failure.
7. Technology issues – 3% or less
Today technology is hardly an issue. For the most part major hardware or software failures are relatively infrequent. It is the way the technology is configured and commissioned that causes the problems. Poor software configuration can make software clumsy and difficult to use and in extreme cases can render it unusable – consider the big brand ERP implementation where the business was being run on Excel.
The Critical Factors
For Integrated Business Information System (IBIS)
The Critical Factors for information system investment success (includes ERP, Data Warehouse, Business Intelligence, legacy systems, etc), derived from the factors that I identified about nine years ago and which are documented in my book "The Critical Factors for Information Technology Investment Success", updated recently are:
All of these aspects must be managed in order to achieve a high value outcome...
1. Executive custody – 22%
This includes the CEO as sponsor for any overarching information integration project (see the paper on this topic), the role of the strategic solution architect, the role of the business systems executive and the appointment of an executive level strategic advisor to provide guidance on the project and personally provide high level facilitation on the high level frameworks of the SEPT taxonomies, etc.
2. Effective change facilitation – 20%
Today just about any significant project involves replacing systems or methods or classification schemes, etc that are at some level working. The psychological resistance to change is frequently very substantial and must be very carefully managed, preferably using a facilitator and advisor with a formal qualification in Psychology and considerable experience in the field of facilitating change.
3. Strategic solution architecture – 19%
Effective solution architecture that accurately reflects the essence of the business (the business fundamentals) and how it thrives is vital.
This architecture most critically manifests in the design of the SEPT taxonomies and configuration.
4. Information engineering including SEPT and Precision Configuration – 17%
The entire Strategic Engineered Precision Taxonomies and Precision Configuration domain as set out in the JAR&A Taxonomy Handbook.
5. An engineering approach – 14%
A robust, rigorous approach which seeks to succeed by engineering against failure (engineers design bridges NOT to fall down) – understanding what causes failure and preventing its occurrence.
Summed up by the statement that "if you contract an engineer to design a bridge you will get the bridge that you asked for and it WILL stand up".
6. Business integration, training, processes, CBT, etc – 6%
All the aspects of fitting the solution into the business – training, computer based training materials, process mapping and automation, etc.
7. Technology – 2%
Technology is only an issue when it does not work.
There ARE visible differences in quality of taxonomies
Recently I made the assertion that a particular taxonomy was "a 0 or 1 out of 10" as a quality rating.
One of the people in the meeting challenged me as to whether it was possible to rate configuration data.
It is my assertion that this is categorically so, refer to the section on "What is NOT a Strategic Engineered Precision Taxonomy?" in the Taxonomy Handbook for some really weak examples.
Such a rating is inherent in the diagram below which summarizes the relationship between Precision and Value:
Following is a rating scale from 0 to 10 out of 10 where 0 = absolutely no precision, could not be worse and 10 = best in the world, could not be better:
0. Abysmal -- could not be worse
I once saw a list that I would classify as a zero, there was absolutely no logic whatsoever. Characteristics of such a list include assets, liabilities, income and expenditure all jumbled together, highly variable granularity from very coarse large bins to very fine bins, ambiguous wording, child and parent elements on the same level, messy capitalization and spelling, duplication of items, totally devoid of logic, totally lacking semantic precision, codes are meaningless.
With such a list it is extremely difficult to produce even the most elementary report – in one case a lady with a Bachelor of Commerce degree and five years post graduate experience was unable to produce a reliable income statement after trying for six months. In the same organization the senior bookkeeper took six months to produce a list of 16 pages of accounts out of an original list of 25 pages where the accounts removed were either not applicable, redundant or in some other way inappropriate. A portion of this item is shown below.
1. Extremely weak
Slightly better than above but not materially different from a practical point of view.
3. Very weak
Slightly better than above. Following is an example of a Chart of Accounts that I would rate at 2 to 3 out of 10:
This list is only classified as a 3/10 because it is possible to produce an even bigger mess.
7. Mediocre – some elements of precision taxonomies but inconsistent and not fully functional
9. Very strong – limited deviation from standard – the point at which real value starts to be unlocked in the long term
10. World class – exceptional
Fully compliant with the SEPT standards presented in the JAR&A Taxonomy Manual. Developed by a senior taxonomist in close consultation with executive and senior management.
The following Chart of Accounts is probably about a 9.5/10 – there is some room for improvement but it is very close to the standard that I regard as essential.
It is vital to understand that the total cost of ownership of the Chart of Accounts in the figure above is WAY LOWER than the total cost of ownership for the list categorized as a 3/10 – I hope from sober consideration of the two lists you will be able to see the difference.
In fact, the total cost of ownership drops as dramatically with precision as the value increases.
How to give executives REAL information
Strategic engineered precision taxonomies (SEPT) are THE way to give executives REAL information:
1. Not about technology, about INFORMATION
2. Strategic understanding
3. Fundamental first principles
4. Long term view
5. Complex, challenging and costly BUT substantial net value
6. Perhaps the greatest "I.T." BUSINESS VALUE opportunity at present
7. Do not scrap your existing systems UNTIL you have thoroughly evaluated and costed this option - look at customisation and re-implementation
The Power of an Executive with a Blank Sheet of Paper
(Reprint from one of my newsletters)
For many years I have encountered executives who when interviewed with regard to their sub-optimal ERP or IT investments say something to the tune of "Dr Robertson, I do not understand IT, I may be wasting your time."
In the last few months I have gained new insight into this statement AND how to rectify the problem.
We take taxonomies for granted when we visit a library or use a product catalogue or similar but, for the most part, taxonomies are weak or entirely absent when it comes to the classification of information in ERP systems and other business information systems.
Once a taxonomy is linked to a precision code scheme it becomes the most important means of communication between a business information system or ERP and people. The creation of taxonomies is both an art and a science and at some level is quite obscure.
But once a well-designed taxonomy has been created it is obviously right.
With the correct facilitation it does not take long to create a high value taxonomy but that requires that the right people are in the room.
1. "I do not understand – maybe I am stupid"
Many times when undertaking a pulse measurement (diagnostic assessment of an ERP or other IT implementation that is not meeting management expectations) I find in conducting executive interviews that executives make a statement to the effect that they do not understand IT.
This time I was sitting with the Chief Financial Officer of one of my clients and he made the statement about some work that I had done in the preceding weeks.
I had facilitated a series of workshops with him and his team and then undertaken one on one working sessions with team members.
The goal was a Chart of Accounts that would work for all divisions across the business.
I thought we were making good progress.
The Chart of Accounts did not make sense to him and he was almost embarrassed to admit it.
I wonder how many times this has happened before, work for days or weeks, think you have a good solution and the executive sponsor is too embarrassed to admit that the work done does not make sense – after all, IT is magic and he might expose his ignorance if he said anything!?
2. We stop here until this makes sense to you
This time though, I did something different – I said something to the effect of "that is important, I need to understand why you say that and we are not doing anything until I understand what is concerning you and we have a solution you are entirely satisfied with".
I actually had to talk quite hard to get him to agree with me.
He was convinced he was missing something and that if we continued it would eventually all make sense.
Problem is, I have learned that if it does not make sense today it is not likely to make sense tomorrow and, if the person it does not make sense to happens to be an executive, a solution that does not make sense is a recipe for executive opt-out (as opposed to executive custody) and that is a recipe for disaster.
So, I suggested we start with a clean spreadsheet and start from scratch.
3. The power of an executive with a blank sheet of paper
It was an interesting experience.
He pushed back hard, he was concerned he was wasting time and, by implication, money,
I pointed out that the work that had been done served as a brainstorm list and that we would go through the whole list in due course to make sure that all the information we had gathered was retained in the final design.
But I managed to persuade him to start with a clean slate.
I explained the principles of taxonomy design, the emphasis on strategic (thrive) decision support, putting the most strategically important information at the top of the list, aiming for about seven items at any level in the hierarchy -- and so we got going.
In one day we captured the entire high level structure of the key elements of the Chart of Accounts design and, most importantly, the client was enthusiastic about what we were creating.
He could now see how what we were creating would impact executive information and decision making long term going forward. His view of the business and strategic priorities were being accurately reflected.
He was excited!
4. What is a taxonomy? And why is it important?
We were creating a taxonomy, in this case a General Ledger Chart of Accounts, but the same principles apply to any classification scheme in your ERP or other IT system.
Examples of taxonomies would include your Product Class, Item Master, Customer Class, Supplier Class and all other drop down lists and validation lists in your system.
What IS a taxonomy?
It is a logical semantic (word) structure which provides a precision vocabulary of preferred terms which conveys understanding between human beings with relevant knowledge and experience.
An example of a taxonomy would be:
§ Domestic Cats
· Persian Cats
The most important aspect of all of this is to capture this information in strategically (thrive) aligned taxonomies (SEPT) throughout ALL components of the ERP.
5. Executives are the custodians of the thrive (strategic) view of the business
Increasingly I am realizing that in defining the taxonomies for your ERP system implementation, it is the executives of the business who should be primarily involved -- assisted by the staff who report directly to them.
It is the executives who are the custodians of the strategic executive (thrive) view of the business and therefore they are the most important people when it comes to defining how the business is modelled strategically through the taxonomies.
Executives hold the integrated holistic view of the business, its customers and markets, its suppliers, its personnel, its future direction.
They are the people who know best how they want these items segmented in terms of the three, five or ten year view of where the business is going.
Accordingly they are the most important people to consult when it comes to developing taxonomies.
The MOST important output of an ERP or any business system is information that enables executives to make better strategic (thrive) decisions.
It is not difficult today to get technology to facilitate processes, enforce policies, etc but that is not enough for the organization to thrive. An organization will thrive if the correct decisions are taken by those at the top. So an ERP must facilitate the supply of the information that is required for such thrive decisions to be taken.
6. The most important requirement – answer the questions I have not thought of
By extension this means that the ERP must be able to answer the questions that executives have not yet thought of.
That sounds crazy, doesn't it?
After all, traditional ERP and other business systems implementations spend days, weeks or even months on user requirements workshops specifying all the reports that are required and now I am saying that is not required or not enough or both?
Well, at the start of an ERP project what matters is what the outcome will be in five or ten years' time, NOT what the outcome will be at go-live.
The issue is answering questions executives and managers have not thought to ask.
How do you do that?
Firstly, ASK, what the business will look like in five or ten years' time – what expansion, what acquisitions, etc – executives do not necessarily have all the answers but at a headline level they have CLEAR views of where the business is going WHEN you ask them and WHEN they think about it.
But most of the time IT and ERP implementers never ask the question. They ask lots of operational and tactical questions but they seldom ask the really important questions and so they start off the journey going in the wrong direction based on the right answers to the wrong questions.
And then, what questions will you ask that you have not thought of yet?
No, I don't think you will find the answer that way!
7. Model the business accurately – large numbers of small bins
In order to answer that question there is something else you must do.
Ask them to identify ALL the possible attributes of the components of the business, the products, the customers, the suppliers, the staff members, a widget, etc.
You goal is to classify every attribute that can realistically be identified because, IF you have all the attributes that they use consciously AND unconsciously to define a product or whatever you have the information that is required to answer most, if not all, of the questions they might ask in the future.
And, if you configure or customize the software in such a way that all these attributes are available, with drop down lists configured with carefully thought out taxonomies AND you make provision for additional fields to be added, you are likely to have a lot of the building blocks in place to answer those difficult questions sometime in the future.
Then, in addition to this, make sure that the level of detail in your taxonomies is sufficiently fine that the taxonomy divides your products or whatever into a large number of small bins (categories). This means that the data can be added up just about any way you want.
And, if you do this at the design stage it costs almost nothing to make provision for this.
The relevant metaphor is screws in a hardware store – if you go to a hardware store to purchase screws you expect to find them stored in little plastic sleeves or bins neatly organized by length, diameter, head type, etc – in other words, you expect to find a taxonomy.
If the screws were all dumped in one large bin that you had to scratch in you would go to another hardware store.
This is often why companies replace their ERP systems, they are frequently configured with large haphazard bins with little or no taxonomic logic with the result that the systems are clumsy to use and do not package the data in such a way that intelligent analysis is possible.
So, the obvious conclusion is that we have bought the wrong ERP -- not so?
No, the problem is almost NEVER the software, it is the way the software is configured and implemented!
In such a case there is frequently an opportunity to reconfigure and re-implement the same software or fix the data in the Data Warehouse.
8. Use the technology appropriately to its full potential appropriate to the business
Re-implementing your ERP is frequently a major consideration in achieving the full potential of the software.
Another aspect of getting the full potential of the software AND of ensuring that the scope of an ERP project is correct is to apply the same principle – a blank sheet of paper – to the specification of the requirements for an ERP project.
In simple terms a key element of the requirement for an ERP project should be "implement this software in a manner that fully exploits the capabilities of the software to add real value to the business in a practical manner" – in other words, do not expect the business to tell you what it wants, other than a highly effective and efficient (thriving) business, understand the business, understand the software and then identify ALL possible synergies that will enable the tool properly used in the business to add value.
Rather than expending massive amounts of time trying to understand the "as is" condition of the business, understand the essence of the business and what causes the business to thrive (the strategy), understand the full potential of the software and then facilitate the EXECUTIVES of the business to define the high level requirement based on how the software can best be utilized to assist the business to thrive.
This could give rise to a three year or five year implementation plan during which the functionality of the software is progressively mobilized to support the business in achieving its strategic objectives.
Do NOT constrain the executives or the business by spending detailed time on what they currently do, they KNOW THAT, focus on where they are going and what they need to get there.
Build all taxonomies according to the blank sheet of paper principle using the fundamental principles of ERP taxonomy design in terms of number of levels, spacing of levels, etc.
And, remember, you can ONLY build all the taxonomies in your ERP from scratch IF you re-implement your entire ERP – or do this in your Data Warehouse and then trickle down the new taxonomies into your existing ERP configuration over a period of years.
If you do, you will unlock huge value.
If you cut corners you will achieve a major loss of value.
Do it right first time.
I would be happy to discuss how we can assist you to implement effective taxonomies and give a new lease of life to your existing ERP or create a platform for unlocking exceptional value from your new ERP.
Why ERP can make the blood boil
(Reprint from one of my newsletters)
The apparent tension between high precision strategic configuration and operational / tactical configuration is arguably the greatest challenge within ERP implementations today.
Introspection of several key aspects and grey areas will hopefully make the situation a lot clearer.
The conundrum – 19 out of 20 dissatisfied vs most are satisfied
It is an all-too-familiar conundrum in business – surveys that emerge with completely opposite conclusions about the same subject. There have been surveys that state ”19 out of 20 ERP implementations do not deliver what was promised" and yet others that indicate a high level of satisfaction with ERP.
The resolution of this conundrum lies in the disparity between the successful tactical and operational implementation of ERP and the near total failure to implement ERP as a strategic resource in support of corporate competitive decision making that enables the organisation to thrive.
ERP is necessary for most medium and large businesses to compete
The reality is that ERP is necessary for most medium and large businesses to be credible contenders in the current global and local economy.
Without the inventory, warehouse management, replenishment and other operational and tactical agility that is afforded by big brand ERP systems, many organisations would not make it onto the playing field at all.
An ERP is necessary to support the ever increasing complexity and velocity of business in most sectors. Many implementers are able, to some degree, to successfully implement ERP at this level -, albeit frequently with massive cost and time overruns.
The problem arises when executives want answers to strategic and competitive questions, and justifiably expect their ERP to supply the necessary hard measurements required.
Process efficiency is generally tactical NOT strategic
Process efficiency or ‘business process optimisation’ or other similar nomenclature is viewed by many as being synonymous with ERP and represents the core emphasis of the vast majority of ERP implementations.
Due to the fact that process efficiency is inherently operational most ERPs are implemented by the operational personnel in the organisation and not by the strategic personnel - and particularly not the executive team.
In focussing on process most implementation companies and most software companies lose sight of the fact that process efficiency is a natural outcome of a strategically implemented ERP.
It is not necessary to place great emphasis on process efficiency PROVIDED that the implementation of the software accurately models the real world in which the business operates at a strategic level. In other words, it models the ESSENCE of the business and how it thrives. Once this is done process efficiency almost ‘falls out of the tree’ – it is inevitable.
Thus, a large amount of the effort that is devoted to traditional ERP implementations is, in fact, not required IF the ERP is strategically implemented – a significant amount of the time on operational configuration is replaced by comparable time and effort on top down strategic configuration.
And this, in turn, as a by-product, gives rise to greatly increased efficiency of operation of the ERP and resulting reduced life-time costs and in many cases reduction in overall implementation cost.
Automatic micro level daily replenishment is increasingly necessary for many businesses to compete and grow
The speed of replenishment and complexity are vital to competing in many sectors today.
A visit to your local big brand supermarket will show what I mean. There is massive complexity in terms of the mix of products on the shelves and, in the case of low volume products, there may only be one or two items on the shelf.
Replenishment takes place daily and the entire manufacturing network and supply chain is geared to this level of just-in-time micro replenishment.
A retailer that is not able to maintain these micro levels of inventory replenished daily will be rapidly defeated by others that have this ‘licked’. The same comment applies to logistics and distribution organisations and to manufacturing organizations. It also applies to banks and, interestingly, even applies to the national Revenue Service – ERP HAS enabled MUCH greater levels of complexity and flexibility at the operational level than was the case a few years ago.
But most organizations are NOT making better decision than they did five years ago?
Countering this, Gartner reported a few years ago, following a survey of 1,300 CIOs of major corporations that had made substantial investments in ERP and Business Intelligence software, that "most organizations are NOT making better decisions than five years ago".
And so we find ourselves faced once again with that apparent conundrum – ERP and BI have enabled many businesses to maintain their competitive edge and even become more operationally competitive, but executives are not making better decisions than they did five years earlier.
One of the great promises of ERP is failing to deliver.
Why? Because a bottom-up operational ERP or BI implementation will never tie the logic of the business together strategically.
The implementation must start top-down commencing with a high level strategic view of the business and where it is going to be in five or ten years' time. Then it must drill down to the detail within this high level strategic framework.
The core frustration
One of the core elements of frustration can be summed up by the statement "I cannot get answers to the questions I have only now thought to ask".
It is a fallacy of modern ERP implementation that “User Requirements Workshops” that are focused on the current reports and ways of doing things, will do anything other than deliver a new system that works the way the old system worked – not meeting the strategic needs of the business.
At the strategic level the issue is NOT "can I get the report I have had for the last ten / five / two years?” it is "can I get the report I have never previously thought to ask for".
And, can I get it NOW?!... Will it be accurate and reliable? And if I ask the question three or five or ten different ways, will the answers correlate and be consistent and congruent?
After all, surely it is reasonable to expect that if the data is in the system I can get answers to any question I can conceivably think to ask?
Yes, of course it is reasonable!
Problem is that most implementations are executed in such a way that it can take days, weeks or months to get answers and it is quite common that the answer is simply not available without massive manual effort or even not available at all.
Why? Because the system was not implemented with this goal in mind.
In order to achieve this outcome the software must be configured from the ground up to contain strategically logical "information bins" in the information warehouse that is the ERP database.
This requires design at a sufficiently fine level of strategic granularity that the data can be added up every conceivable way possible in accordance with a clearly defined high level strategic (thrive) view of the business, one that accurately models the essence of the business and how it thrives.
This applies to the Item Master or Product Class, the Customer Class, the Supplier Class, the General Ledger Chart of Accounts, the plant maintenance classifications, etc, etc. AND it applies to the fine nuances of what differentiates products, services, etc viewed from the perspective of the executives of the business AND their customers.
Precision engineered strategic configuration and taxonomies – the greatest ERP opportunity today
The answer to the problem outlined above is what I term "precision engineered strategic configuration" at the heart of which are "precision engineered strategic taxonomies". These taxonomies catalogue every possible attribute of the business, its products and its services in such a way that they can be quickly and rapidly summarized in ways that make sense strategically in response to questions that have never been asked before.
Coupled with this is the use of advanced statistical and other analytical tools operated by highly qualified statisticians, economists, engineers and the like in order to better understand the economic dynamics of the business and optimize the operation of the business in accordance with the insights that flow from precision analysis of the data.
The big opportunity today is – precision taxonomies coupled to precision configuration coupled to precision operation of the ERP coupled to precision analysis of the information in the data warehouse resulting in significantly better business decisions than the competition are making.
Thus, the taxonomies and the analysis of data made available via the taxonomies are essential attributes of a high value ERP implementation.
Increasingly I am recommending to clients that in addition to the taxonomies, they look at hiring an analyst with a Bachelor of Commerce degree majoring in statistics and economics with ten years' experience in advanced statistical economic analysis. The challenge is that the analyst only becomes economically viable once the precision taxonomies and configuration are in place.
The total cost of a precision strategic configuration with precision taxonomies is roughly the same or less than the cost of a conventional configuration. However the life-time operating cost is substantially less and the strategic and competitive return on investment is orders of magnitude greater. Software is under development by the writer in order to maintain the integrity of the configuration and taxonomies.
The CEO MUST be the custodian of ERP
(Reprint from one of my newsletters)
The debate over who should serve as guardian over an organisation’s ERP can be settled with one answer - the Chief Executive Officer.
My ERP is not integrated and I do not have an end-to-end view of the business
I regularly encounter executives and managers who complain that their ERP is not properly integrated or that they do not have an end-to-end view of products, costs, inventory, etc.
The implication is that the ERP is defective or that the ‘wrong’ ERP was purchased. But this is not accurate.
Such problems are indicative of a poorly configured ERP which has not been implemented with end- to-end strategic information objectives in mind.
The most significant reason for this problem is inappropriate governance of the ERP project during the implementation - and the key issue here is that the only person who can provide this governance is the CEO and the CEO is seldom the custodian of the ERP implementation project, or, for that matter, the operation of the ERP.
The worst big brand ERP implementation I ever saw reported to the Legal Affairs executive – they had an amazing contract but the rest of the implementation was a mess and the contract was worthless.
ERP under finance – a historical disservice to business
Historically ERP has mostly resided under finance. The result is that finance irritates other functions by forcing cooperation and, more seriously, the ERP implementation ends up as a finance implementation with the other operational elements tacked on as an afterthought.
The worst example I ever encountered was a big brand ERP with a domineering Chief Financial Officer who forced everything from people, to plant to projects into the General Ledger - and then verbally abused anyone who suggested that the solution was technically fundamentally unsound.
The organisation could not get the plant maintenance module to work because most of the information was in the General Ledger and not in the operational modules of the ERP.
Many organisations resolve this problem by having financial (or commercial) systems reporting in to finance and operational systems reporting into manufacturing, production, mining, etc because they cannot get end-to-end cooperation in the business. These silos feed on themselves creating more and more problems because the two camps cannot collaborate in a constructive manner.
Only the CEO can resolve these problems.
The CEO is the custodian of the integrated view of the business and hence the ERP
Fundamentally the CEO is the custodian of the integrated view of the business. It is one of the principal functions of the CEO – to get all the divisions and functions of the business to pull together coherently.
Inherently, therefore, only the CEO can be the custodian of the ERP, or the data warehouse and business intelligence systems.
There is no practical alternative.
I have repeatedly seen sub-optimal ERP implementations (and I have seen dozens) where the lack of CEO custody is a significant and frequently dominant factor in an unsatisfactory situation.
Frequently the viability of the business is placed at risk.
Only the CEO has the authority to get all functions and divisions to collaborate as peers without bias and domination
Getting an ERP properly configured and operating effectively requires that all business units and functions operate collaboratively in the best interests of the collective whole that is the entire enterprise.
This requires that all disparate business elements work together collectively and harmoniously for the good of the whole.
This requires trade-off, strong leadership and guidance.
Firm discipline may be required if one or more business units fail to contribute and collaborate as peers.
Only the CEO has the authority and mandate to demand such collaboration and make it happen.
Where the CEO abdicates, massive system problems will follow which are frequently taken to be technology problems.
But the CEO does not have the time / knowledge / … to manage the ERP – not so!
I have been told by more than one client that the CEO does not have the time or the knowledge or the interest or the … to manage ERP.
Well, if the CEO does not know how the business should operate as an integrated whole then the business has greater problems than the ERP. If the CEO does know how the business should operate as an integrated whole then the CEO does know how the ERP should work.
A fundamental principle of an excellent ERP implementation is that the ERP implementation should accurately model the REAL WORLD characteristics of the business. Any executive or business user should be able to look at the configuration of the ERP and say "yes, that IS my business".
If you cannot say that about your ERP it is because it is badly implemented.
When an executive says to me "Dr Robertson, I do not understand IT" experience has shown me that this translates to "I have seen the jumbled mess in my ERP and I cannot comprehend how that can do all the things the consultants say it can do, so, obviously, I do not understand IT"
NOT SO! The correct translation is "the consultants clearly do not understand my business and the way they have implemented this system bears absolutely no correlation with my strategic understanding of the business and this is a multi-million Rand mess" – the problem is NEVER your big brand ERP, it is how it was implemented and the almost universal lack of precision engineered strategic configuration in the form that I regard as essential and non-negotiable.
If the CEO does not have time to take custody of the ERP then, in the world of 2011, you should probably start looking urgently for a buyer for your corporation whose CEO does have the time. The future of business today will increasingly be determined by the ability of executives to take high value strategic decisions that lead to growth - while those that cannot do this will be taken over by those that can. Otherwise it may be more cost effective to replace the CEO than it will be to replace the ERP!
I am NOT advocating that the CEO spends a lot of time managing the ERP, but I AM advocating that the CEO gives high level guidance and takes custody – once effective governance is in place this should require at most a couple of hours a week.
If strategic decision support, that relies on information in your ERP, is necessary for your business to thrive - then it must be managed by a person reporting to the CEO
If you want to manage your business at a strategic level from information in your ERP then it is essential that the person who manages the ERP reports directly to the CEO.
Depending on the size of your organisation this is NOT necessarily an executive but should at least be a senior manager and they should at least be present at EXCO when system related matters and matters that impact systems are discussed – which is probably all the time J
This person should NOT be a technology person but a business person.
If necessary appoint an executive level strategic advisor to assist with bridging the technology to business gap – someone who can operate at a peer level with the CEO and who understands both business AND ERP.
Strategic decision support NOT process is the essence of the investment case for ERP and resides with the CEO
The general view of ERP is process, but process is operational and at the bottom of the organisational pyramid.
There is no such thing as "the strategic process". If there were it would look like:
Identify need for decision --> convene EXCO --> present information --> deliberate --> take decision …
Reference to "strategic process" is one of the absurd ‘jargonistic’ sayings that characterise the mystical mumbo-jumbo of the management consulting and IT / ERP fraternity and clouds the issues. The real issue is to supply the right information to the right people at the right time and in the right form in order to make the RIGHT DECISION.
In the absence of the "right decisions" the business will eventually go out of business – highly optimised business processes will simply help it to go out of business faster!
With consistent "right decisions" the business will thrive and optimized business processes will assist with this.
Professor Malcolm MacDonald defines strategy as "doing the right things" and, since the CEO is the custodian of the right (strategic) things the CEO must be the custodian of the systems that supply strategic information to support strategic, high value, decisions.
Overall governance of the ERP rests with the EXCO – precision configuration starts with the EXCO and so executives must understand the essence of the business and own the BUSINESS outcome
From the above it will be apparent that overall governance of the ERP flows from the CEO to the EXCO and then to the rest of the business.
Accordingly precision configuration starts with the CEO and EXCO and therefore executives must understand the essence of the ERP and own the business outcome of the use of the ERP.
By way of example, I am currently busy with a series of workshops with the EXCO of a mid-size South African company to develop the high level structure of all major taxonomies in their ERP system in order to ensure that the configuration of the ERP reflects their strategic view of the business.
This is the only way that we will ensure that the default view of the information in the ERP reflects the strategic executive view of the business and its long term priorities.
Only 15% of executive decisions are based on hard information, but without that information they are flying blind - strategic decision support should be the primary consideration in ERP implementation
But, I hear you cry, "executives only base strategic decisions 15% on hard information" – that is true, BUT, if they do not have that information they are flying blind on gut feel or by the seat of their pants.
That hard information is critical BUT it must be packaged in a way that accurately reflects the essence of the business and how it thrives (the strategy of the business). That is why the CEO - and through the CEO the EXCO, must be the custodians of the ERP.
Precision strategic taxonomies can be retrofitted to an operational ERP implementation through a data warehouse
I have written previously about the importance of precision engineered strategic taxonomies and configuration in ERPs.
Problem is that the cost of completely re-implementing an ERP in order to introduce rigorous precision configuration is more than most organisations can justify spending, particularly considering that at an operational and process level the ERP is probably working quite well – so we find ourselves faced with having to spend 80% of the budget re-implementing the stuff that is working in order to fix the 20% of the stuff that is causing 80% of the strategic pain.
There is, however, an alternative – leave the ERP implementation largely unchanged, develop precision engineered strategic taxonomies for all the tables in the ERP. Then map the old codes onto the new codes and transform the data in the load component of the extract, transform, load (ETL) portion of a new data warehouse and then build high value reports, graphs and models in the business intelligence environment.
This will require some changes to the configuration of the ERP but they will be incremental – provided they are carefully planned by someone with strategic insight into what is REALLY important.
Over time the high quality taxonomies and other configuration elements can be dropped into the ERP in small controlled deployments. As such unexpected impacts can be carefully trapped and managed until after a year or two a reasonably high quality precision configuration has been achieved in the existing ERP.
This represents a major opportunity for many businesses with established investments in ERP today.
The metaphor is one of taking a badly maintained and operated factory and systematically refurbishing it, one part at a time, until after a couple of years the whole factory has been refurbished.
CEO custody is critical to successful long term high value ERP operation
As with all the other components identified above, CEO custody and direction is vital to achieving a high value integrated business outcome cost effectively and sustainably.
Where necessary the CEO should seek to secure high level strategic advisory services at an appropriate scale to support them in taking on this responsibility.
Understanding strategy and how ERP fits in
(Reprint from one of my newsletters)
The high level of dissatisfaction with ERP amongst executives is compounded by the absence of strategic alignment in virtually all ERP implementations. The inevitable, unavoidable truth is that ERP must fit into strategy.
Strategy is one of those strange words that is widely used but seldom understood.
Ask ten people to define "strategy" in one sentence and you will get a wide diversity of answers with interpretations that range from plans to tactics to deceitful manoeuvres to …
In 1990 I wrote a paper on the importance of aligning IT with business strategy and then found that I could not define strategy in one sentence.
As I sought an answer to this conundrum I encountered various definitions and found that even internationally acclaimed and recognised ”gurus” did not have concise definitions that matched.
I also found that very few organisations were successful in developing strategic plans that worked and even fewer organisations actually managed to execute strategic plans successfully.
In my search I encountered the work of Professor Malcolm McDonald who defines strategy as "doing the right things" as determined by the customer with tactics defined as "doing things right".
McDonald plots this on a matrix with strategy horizontally and tactics vertically and asserts that if an organisation "does the right things well, it will thrive" and that if it "does the wrong things well, it will die quickly".
The essence of the business and how it thrives
As I investigated further I encountered other definitions of strategy but always came back to the concept of doing the right things in order to thrive.
Painstaking research has led me to the conclusion that strategy is “the essence of the business and how it thrives".
That has become my focus in delivering high value solutions – understand the essence of the business and then put in place measures to assist clients to use Information Technology / ERP to support high value "thrive" decisions. All the rest, the operational benefits, etc follow automatically from an ERP implemented with strategy as its focus.
Generally I commence my Pulse Measurement interviews with questions directed at establishing the "essence of the business and how it thrives".
ERP versus IBIS – the mixed bag of software
ERP stands for "Enterprise Resource Planning" and many organisations do NOT use their ERPs for ERP. Frequently the resource planning for the enterprise gets done somewhere other than in the ERP.
Frankly, if you scratch beneath the surface you will find that most ERP implementations are actually accounting and workflow implementations and there is little or no RP done in the so-called "ERP"!
If the resource planning IS being done in the ERP it is being done in a very tactical and operational manner with absolutely no thought to strategic considerations. Huge unstructured lists are the order of the day associated with huge maintenance bills for expensive contractors on an on-going basis.
As far as the application of information systems in business is concerned, it is better to think in terms of "Integrated Business Information Systems" or IBIS ("ERP Plus" if you like).
Fact is that in my experience I have not encountered a single ERP installation that is not surrounded with other pieces of software. Most ERP implementations live in a sea of customization, Excel spreadsheets and other custom development such that many times the business is hardly using any of the ERP at all.
"Zero customization" is seductive but in real life it is almost universally a myth. As a basic minimum sub-optimally configured ERP systems immediately create a substantial requirement of customization and custom development outside the ERP.
Accordingly, in evaluating your current system, whether it is labelled "ERP" or not, consider ALL the surrounding systems and custom development and soberly assess how you will replace that system with another system without falling into the same traps again. It is very easy to believe that your organisation does things differently and therefore customization is called for.
The real criterion of customization is what I term "strategic customization" – custom development that is necessary to support the business to thrive, that is that supports the essence of the business. This criterion requires robust and sober assessment at the executive level associated with high level strategic advice that ensures that only customization that is really required and that really adds value is entertained.
And remember that you may well end up retaining many of your satellite systems because they are industry specific or perform functions that standard software does not cater for – so replacement of your ERP requires very careful consideration.
ERP implementations are typically tactical and operational not strategic – 80% of effort for 20% of value
As noted above, very few ERP implementations are truly strategic, most are operational and tactical.
They address the 80% of the configuration and implementation that will deliver 20% of the value while the strategic elements are largely or entirely overlooked.
One of the major reasons this happens is as a consequence of a lack of strategic guidance from the executive suite and the lack of strategic translation from an executive level strategic solution architect advisor to the CEO. These are vital requirements for a high value implementation that supports high value decision making.
Leaving your ERP to your mid-level operational and administrative staff to implement and operate guarantees you what you have commissioned: a mid-level operational and administrative system. If you want executive information out you must provide executive level input across all domains of the business into the ERP implementation project.
Strategic decision support – the essence of how an organisation thrives – the right decisions
It is my contention that the major reason any organisation should invest in upgrading or replacing its current ERP should be to support strategic decision making – that is to supply the information that allows executives, managers, supervisors and staff to take decisions which enhance the essence of the business with a view to enabling the organisation to thrive – that is, the right decisions.
The absence of this decision support is the fundamental reason why a survey of executives in the Financial Mail found that "19 out of 20 ERP implementations do not deliver what was promised" and why a Gartner survey of 1,300 organisations in Europe reported that "most organisations are not making better decisions than five years ago".
Precision engineered strategic configuration and taxonomies – the 20% of the effort that will deliver 80% of the strategic value
How does this work in practice? All of the issues touched on above may seem very theoretical – how to do it?
Firstly, define, document and publish "the essence of the business and how it thrives". Then define precision engineered strategic taxonomies as discussed in previous articles.
These taxonomies must be highly structured, highly hierarchical and strategically focussed.
What do I mean by "strategically focussed"? Simple – every level of the taxonomy should have between five and ten items in the hierarchy (seven is optimal).
These should be ordered where appropriate in such a way that the most strategic elements are at the top of the list and the most operational at the bottom of the list with the caveat that where there is a logical progression viewed in terms of the essence of the business then this logical progression should dictate the default sort order.
Once the content of every taxonomy in each module has been determined this way, it will form the basis of precision configuration of the entire ERP and associated systems to one consistent, congruent and uniform standard across all systems in the enterprise and all modules in the ERP.
Uniform and consistent taxonomy standards rigorously enforced with stringent discipline across the entire enterprise will ensure that all systems integrate seamlessly.
There is a catch, however, the real cost of a comprehensive, engineering standard (zero probability of failure) full blown ERP implementation is very substantial. If the basic ERP is functioning reasonably well at a tactical and operational level, it is almost impossible to justify the real cost of a full implementation or re-implementation. A full blown re-implementation will re-do the 80% of the work that is already working more or less reliably before the 20% of strategic investment can be leveraged.
There is, however, an alternative course of action.
Precision engineered strategic taxonomies and the data warehouse – the REAL opportunity
One of the reasons most organisations do not get executive value is that the operational ERP implementation is so poorly structured that it is extremely time consuming and costly to extract the most basic strategic information let alone to create a competitive resource.
This manifests frequently in a sub-standard or almost non-existent data warehouse or a data warehouse that is extremely costly to operate but which fails to deliver strategic information.
This introduces an interesting and highly attractive opportunity. You could leave the operational ERP configuration largely unchanged, save for limited incremental enhancement and introduce an excellent new data warehouse implementation using the same strategic taxonomies as described in the previous section - with the exception that you may not develop the taxonomies in master lists like the Item Master or Materials Master down to the full level of detail.
Map the unstructured data in the operational ERP onto the new precision engineered strategic taxonomies and then build the data warehouse reports, models, dashboards, etc. on top of the strategically transformed data.
This should take place in a new data warehouse instance and the existing data warehouse should remain in operation until such time as the new data warehouse is able to fully replace the old warehouse.
This will deliver the 20% of the strategic information that will deliver 80% of the value of the strategic investment for a fraction of the cost of a full ERP re-implementation, I estimate probably about 20% of the cost of a full implementation.
Once this is in place and a comprehensive suite of strategic reports, models, dashboards, etc. are in place you can trickle the new taxonomies down into the operational ERP on an incremental basis over a number of years until the operational ERP is configured to the new standards, again on an 80:20 basis – make the 20% of the configuration changes that will provide 80% of the investment value.
While this will take longer than a full blown ERP re-implementation it will cost much less, the business disruption will be greatly reduced and the risk to the business will also be dramatically reduced.
I am convinced this is the highest value, lowest risk opportunity facing virtually all corporations of any size that are currently operating a brand name ERP and are dissatisfied with the decision support outputs at an executive level.
Risks and common mistakes
when developing taxonomies and configuring systems
Following are the major risks and common mistakes when configuring systems and should be read in conjunction with other sections in the Taxonomy Handbook:
1. The factors causing Integrated Business Information System (IBIS) failure
The factors discussed in my book "The Critical Factors for Information Technology Investment Success" and refined in the intervening years – see section on these factors in the Handbook. Includes "IT Mythology", lack of executive custody, lack of strategic alignment, lack of an engineering (rigorous) approach, lack of change facilitation and inadequate information engineering (the subject of the Taxonomy Handbook).
2. Lack of executive level facilitation
The development of really effective taxonomies, or at least the development of the high level frameworks of such taxonomies requires a senior facilitator who can engage with client executives and guide the design process in order to ensure that the framework is strategically relevant at the executive level.
Most lists in business systems are developed by mid-level or even junior consultants working with mid-level or junior client personnel who are focussed entirely on operational issues or do not even understand the need for some form of logic with the result that at best the configuration might be described as "clerical". Often these personnel do not really even understand the "business of the business".
3. Do-it-yourself mind-set
Many clients try and develop lists themselves without an understanding that the development of really effective taxonomies requires detailed knowledge and experience.
4. Process-centric approach
Many clients and implementers place high reliance on "Business Process" not realizing that executive decision support should be the primary driver in defining the contents of lists and that process related definitions flow naturally from an executive strategic decision support focus with proper senior facilitation. The result is that lists are defined "back to front".
5. Failure to fully understand and apply "strategic", "engineered", "precision" or "taxonomy"
Elsewhere in this document the concepts of "strategic", "engineered", "precision" and "taxonomy" are defined in detail. Most clients and most implementers do not know or understand any of these principles in the context of taxonomies let alone the integrated concept of all of them applied at once and accordingly the lists created frequently only partially comply with these principles, if at all.
6. Insistence on backward mapping
Perhaps the single biggest mistake that is made is that people try and build new lists based on old lists – the old list is a vital source of information in terms of what is required to be included in the new taxonomy but UNLESS the old list is extremely well structured it should NOT under any circumstances form the basis of thinking with regard to the structure of the new list. And, since if the old list was well structured there would be no need to replace it, there is never a basis to build the new list using the old list as anything else but a brainstorming list and then doing detailed mapping at the end.
7. Lack of software to enforce and maintain precision
I have progressively come to see that in the medium to long term it is very difficult for organizations to maintain the precision of taxonomies and for this reason we are developing software for this purpose. I am of the opinion that the use of software is a vital component of maintaining taxonomies and this implies that the taxonomies are developed in the first place to the standards and conventions applied by the software.
8. Failure to implement effectively
The implementation of effective taxonomies is not trivial and includes the facilitation of the change process, proper testing, proper training and general preparation to use the tools effectively and this includes making sure there are adequate reports on the new taxonomies from the start.
It is a serious mistake to assume that because the taxonomies make so much sense that people know how to implement them intuitively.
It is also a mistake to assume that people know how to exploit the taxonomies and use them to their full potential without guidance. People are so locked into a mind-set of mundane detailed mapping of very basic and very simple reports that very few people seize the opportunity to build sophisticated reports and models and do complex analysis which is opened up by really précised engineered strategic taxonomies.
These are the major factors that I have encountered that result in sub-standard or non-existent precision in the configuration of systems.
Risks and common mistakes
when developing Group-Wide Charts of Accounts
Following on from the previous section dealing with risks and common mistakes with regard to Precision Taxonomies generally, this section looks at Financial Taxonomies and Group-Wide Charts of Accounts based on the Cubic Business Model specifically.
The following risks and common mistakes frequently are made:
All the issues relating to Strategic Engineered Precision Taxonomies apply to Charts of Accounts as well.
2. Failure to recognize hard reality and real complexity
Failure to understand that the Cubic Business Model is a reflection of hard, real world, logical reality and business complexity resulting in lack of precision in the model.
3. Resistance to change by finance staff
Finance staff and accountants are trained to resist change – we do NOT hire creative accountants – they therefore find the substantial change in working practices and ways of thinking difficult to accept and may well resist.
"There is something wrong with this" – is a response quite frequently encountered.
Robust executive adoption of the concepts and the design and involvement in the implementation is therefore vital.
4. No software to maintain the integrity of the model
It is extremely difficult to maintain the integrity of the Chart of Accounts and the model without software to assist.
5. Seeing the project as an Accounting project not an Information Engineering project
Treating the project as an Accounting project and looking to accountants for all the answers instead of seeing the project as a strategic information engineering project and looking to information engineers for the solution. The Do-It-Yourself phenomenon coupled to "that is too much money" are extensions of this issue.
6. Failure to go to the finest level of detail
It is seductive to say "we will add the detail later" but it is advisable to go right down to the detail in the project.
7. Failure to recognize that the Cubic Model is also a Governance Model
The Cubic Model is also a logical Governance Model, if this is not recognized and taken into account in implementation problems can result.
8. Failure to implement effectively
There are many change implications that can get in the way of a successful implementation. It is vital to treat the project as a full blown technology implementation project and manage accordingly.
Any of the above, if not properly dealt with, will cause problems.
What is an IT Pulse Measurement?
Do you have concerns about your I.T. function or about a specific project?
Are you debating whether to replace your existing financial and operational systems with a new E.R.P.?
Are you concerned that your company is not keeping pace with I.T. or is going in the wrong direction?
Are you wondering where you can obtain an independent third party opinion?
An I.T. pulse measurement by Dr James Robertson may be just what you need.
What IS an IT Pulse Measurement?
Dr Robertson's pulse measurement is a structured, interview based investigation into a problem that YOU define.
The pulse measurement comprises:
1. One on one interviews with your executive team.
2. One on one interviews with key business users of I.T. at various levels as appropriate to the focus of the investigation.
3. Interviews with I.T. staff and service providers coupled with review of critical systems as appropriate to the focus of the investigation.
4. A structured analysis resulting in a concise structured report based on the factors discussed in Dr Robertson's book "The Critical Factors for Information Technology Investment Success".
This analysis identifies and prioritizes the "Critical Findings" and recommends prioritized "Critical Actions" arising from the investigation.
This is accompanied by a concise evaluation of the problem under investigation in terms of the criteria presented in the book.
5. Optionally the report may be followed with a formal presentation or briefing to your executive team and possibly other audiences.
6. Optionally Dr Robertson offers a critical issues workshop process to formulate specific response to the findings, such as definition of critical business requirements for a system (new or existing).
7. Optionally Dr Robertson offers advisory services with regard to implementation of his recommendations. This can comprise ad-hoc consultation or scheduled consultation which can take place on a retainer basis if that is appropriate to your requirements.
The I.T. pulse measurement has been developed to give a concise assessment of the health of your I.T. or other organizational issue through a limited scope, limited cost professional intervention that will give you greatly improved understanding of the problem in question and how to resolve it.
The findings are presented in a practical, no nonsense, manner that cuts to the chase in terms of the action required.
The pulse measurement is tailored to your exact requirements and will typically require from two to ten days of Dr Robertson's time giving a cost effective, high value, high impact diagnostic intervention.
"The lights have just gone on" -- exclamation by Executive Director of a client organization at the end of the second day of a pulse measurement when Dr Robertson provided a summing up of the investigation to that point and diagnosed the root cause of a project that was nine months behind schedule.
Over the years Dr Robertson has conducted dozens of pulse measurements for organizations of all types and sizes with regard to the full diversity of business systems, ERP’s, etc.
Outcomes have included turning around a decision of a client executive to scrap a system based on a one day investigation, turning around a failing four hundred million Pound Sterling project with a one day visit to London, identifying a fundamental defect in an implementation that was in the process of putting a client organization out of business and equipping the chief executive to take a new direction. There have been many other cases of IT departments turned around and major expenditure prevented.
It is not uncommon for an IT pulse measurement to save a client millions and sometimes even tens of millions.
Defining an ERP Implementation Engineering Laboratory
Following are the major components of the ERP Implementation Engineering Laboratory approach which is applicable to full-scale ERP implementation or re-implementation based on the Strategic Engineered Precision Taxonomy and Precision Configuration models. This only applies to ERP implementation or re-implementation and NOT to data warehouse implementation:
The goal of the laboratory is to ensure that the final live installation is an excellent fit to the business, that all staff are properly trained at go-live and that there are no surprises and no risk to the business on go-live.
b. Engineering is the discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge, in order to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of people.
The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property. (Wikipedia)
c. A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from. (Wikipedia)
A prototype is a carefully and professionally constructed test sample of a system that in final form is intended to be put into economic operation by the developers (Robertson)
d. Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy. (Wikipedia)
e. A test can be considered as a technical operation that consists of determination of one or more characteristics of a given product, process or service according to a specified procedure.
f. In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems".
A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed, its lack of a direct focus on training and process improvement, and its omission of process and product measurement. (Wikipedia)
2. Prototyping environment
The laboratory is a rigorous, carefully controlled prototyping and testing environment managed by a very senior, very practical and very detail oriented manager who clearly understands the critical role of the laboratory.
The laboratory is populated with comprehensive, carefully selected representative data – perhaps 1% or even 0.1% of the data that is in the live system but representative of all possible scenarios. There are very specific principles to be applied in the selection of this data.
The laboratory is situated in a permanently assigned, well appointed and well furnished room with five to ten high performance workstations, a high performance server, high performance backup device, data projector, flip charts, white board, etc.
The laboratory is established at the very start of the project and runs until the data warehouse and business intelligence environment are fully operational.
6. Accurately model the real world
All configuration settings are tested in the laboratory until they accurately model the precise desired operation of the business and all required customization and custom development has been comprehensively and rigorously tested and accepted.
Executives and managers must be able to undertake structured facilitated walkthroughs of the laboratory configuration and see their business at all times – if it does not make sense to the CEO the process stops until the configuration has been modified so that it does make sense to the CEO.
7. Break it till it breaks no more
The primary goal of the laboratory is to break the configuration and once it cannot be broken to optimize it, document it, develop training material and CBT in it, use it as a training environment, use it for the testing of reports and establish the data warehouse operating against it.
8. Basis of go-live certificate
The configuration does NOT go-live until it has been comprehensively tested in the laboratory and accepted by all senior project team members.
The go-live certificate will be issued at the end of a structured walkthrough of the entire configuration by the entire top management of the project – this walkthrough may take several days and may have to be suspended several times for minor adjustments.
If the top team are not satisfied with the results of the walkthrough further walkthroughs, will be held until all members of the top team are willing to accept the configuration.
9. Basis of live instance
The laboratory configuration forms the basis of the live instance of the software – the entire configuration is to be copied onto the production server and rigorously tested software used to clear out all transaction data files and reset all counters – this reset software must be supplied and certified by the software vendor who shall be liable for damages should the reset software be found to be defective.
The final empty configuration will be reviewed and tested during a trial run of the start-up process in the laboratory.
The cubic business model and group chart of accounts
The JAR&A SEPT Cubic Business Model
and Group-Wide Chart of Accounts
One of the cornerstones of the JAR&A Strategic Engineered Precision Taxonomies approach is the Cubic Business Model which, in turn, relates to the Group-Wide Chart of Accounts.
This section discusses this particular component:
1. Our flagship SEPT offering based on 22 years of experience built on 1,000 hours of R&D – huge opportunity
In 1987-88 I was directly involved in the design, construction, testing, commissioning and implementation of a fully integrated "Management Information System" for the firm I worked for. The system included fully integrated Debtors, Creditors, General Ledger, Work in Progress and Time Based Billing and Management. In today's terms it was a fully-fledged ERP.
We designed the entire solution to be tightly integrated at the data level and created a seamless integration that has gone on to underpin the dominant specialist ERP in the Consulting Engineering fraternity in South Africa, "ProMan" – which stands for "Professional Practice Management Information System" and which is installed in over 70 firms including many of the largest.
We struggled for weeks to get the General Ledger integration to work exactly the way we wanted and spent many late nights ticking transactions until eventually we discovered that there were some very rigid technical rules underpinning the geometry of financial data in terms of location – function – account and that, unless one got these dimensions absolutely precisely defined the full richness of the integration was not achieved.
We incorporated the findings into the software design and it has operated reliably ever since with what is probably still the tightest integration I have ever seen in the ERP space, and I have seen dozens of ERP implementations across the full spectrum of brands.
In 1989 I left the Engineering firm concerned and set out on my own with the objective of bringing "the disciplines of engineering to the Information Technology (and by extension ERP) industry".
As I have described elsewhere this was the start of a long and arduous journey that has brought me to the point where it now finally seems appropriate to write this manual.
In 1990 I was approached by another firm of consulting engineers to assist them to implement the software referred to in their business. Flushed with the success of the previous implementation I confidently quoted for 40 hours of my time to design a Chart of Accounts for their business – which was larger and more complex than my previous employer.
Very aware of the importance of the Cubic Business Model as I started to call it I decided to generate the Cubic Model using spreadsheet macro's.
1,000 hours later I finally hit the button and generated the full Chart of Accounts having learned a whole lot more critical lessons with regard to the effective design of financial data taxonomies.
The lessons learned in this painful period of unremunerated Research and Development have remained with me to this day and the standards and conventions developed then infuse the entire Strategic Engineered Precision Taxonomy and Precision Configuration approach that is discussed at length in this manual.
I have not encountered any other person who has attempted what I achieved in 1990 and I have not encountered anyone else who is fully aware of the underlying principles and complexities that I uncovered at that time and which underpin the whole SEPT approach set out in this manual.
I can therefore say with a high level of confidence that it is improbable that another firm has the intellectual property in this area to create a solution of the strategic robustness and value that is being discussed in this section.
I honestly believe that the SEPT Cubic Business Model and Group-Wide Chart of Accounts approach discussed here is head and shoulders above any other offering that I have ever encountered and that this therefore represents a MAJOR OPPORTUNITY to create strategic value for any significant organization.
2. An integrated governance, leadership, accountability and management model in addition to an accounting model
Inherent in the approach that is advocated as part of the SEPT Cubic Business Model and Group-Wide Chart of Accounts approach discussed here is an integrated governance, leadership, accountability and management model IN ADDITION to an accounting model.
The approach produces a Chart of Accounts that is designed for ease of management application, that ensures high levels of accountability and therefore facilitates ease of delegation and overall improvements in governance by providing precise measures of financial performance for every unit and sub-unit of the business to whatever level of detail is required by Executive Management.
It so happens that this design is ALSO easy to use from an accounting point of view (although it does require significant training and re-orientation of financial operational personnel) AND it is largely self-auditing so that the duration and cost of the audit are drastically reduced in most cases once it is bedded down and operating effectively. This of course assumes that the Chart of Accounts is properly integrated with the ERP with SEPT taxonomies throughout the ERP or Data Warehouse and that all change and other issues are dealt with during the implementation in order to ensure that the tool is used to its full potential.
3. BUT James, you are an engineer – what do YOU know about accounting?
Some years ago the Chief Financial Officer of a client rejected what I was proposing on the grounds that I was an engineer and therefore in his opinion knew nothing about accounting.
At one level he was right, I AM an engineer and I do NOT claim to be an expert on accounting practices, standards, conventions, interpretation of financial statements, etc.
I DO claim to be an expert on information engineering, taxonomies, decision support and other elements that are necessary to ensure that computerized information systems fully support the business in a manner that results in high value implementations.
I hold that one of the fundamental principles of what I term "the engineering approach" is that engineers work in multi-disciplinary teams – for example, it takes about 250 different professional disciplines and trades to design and build a 50 story office building ranging from the senior strategic architect, through the architectural draftsman to the tradesman who lays the carpet.
Accordingly, I hold that it is desirable that I am NOT an accountant – I work closely with the Chief Financial Officer and other financial personnel of client organizations and, where necessary, with the senior partner responsible for their account from their auditors.
I have also designed numerous charts of accounts with diverse clients and therefore have the benefit of insight into different ways of thinking and, the reality is, there ARE different schools of thought in the Accounting fraternity on how things should be done. That is desirable, each business is different and the goal is to craft the best Chart of Accounts for the client organization.
My role is as a facilitator and thought leader in terms of the mechanics of Chart of Accounts design, the Chief Financial Officer, the CEO and other senior executives are the customers for the resulting output and the Chart of Accounts must make perfect sense to them – when they look at the Chart of Accounts I want them to have an "Aha" moment and say "YES, this IS MY business!"
So I support the client to develop carefully thought out hierarchies, make sure the progression of content follows strategic logic, ensure fine granularity of posting level accounts that models the real world and generally make sure that the final product is a high value taxonomy that will serve the organization well for many years to come – I hold that a well-designed and well maintained JAR&A financial taxonomy (AKA Chart of Accounts) should easily last for twenty years or even longer.
I look to the Financial officers of the client, assisted as necessary by their Auditors and other financial advisors in order to ensure that the taxonomy we produce complies with accounting standards such as IFRS, GAAP, etc.
In doing this I have found that provided the level of detail in the Chart of Accounts and the overall model are fine enough compliance with accounting standards is very simple, it just follows automatically from an experienced professional (the CFO) defining his or her information needs in a logical and structured manner assisted by an expert information engineering facilitator.
The same applies to alternative accounting treatments and report groupings such as are necessary to compute EBITDA and other ratios, etc. Once the data is extremely well organized all these alternative accounting forms are easily accommodated, far more easily than with the legacy Charts of Accounts I see in all organizations I evaluate.
Thus, to answer the question, I think it is an advantage to my clients that I am an engineer...
Oh, and by the way, I CAN draw AND interpret T diagrams!
4. Ties the entire enterprise together in a systematic structured manner – a group consolidation model and an integration model
The JAR&A SEPT Cubic Business Model and Group-Wide Chart of Accounts coupled with the full range of JAR&A SEPT hierarchy design and coding conventions provides an information CONTENT mechanism to tie the entire organization together in a logical structured manner that permits "slicing and dicing", "drill-down" and "roll-up" to be done quickly and easily harnessing the FULL potential of whatever investment in Information Technology the client organization has made to this point.
Using this approach your ERP will fly, so will your Data Warehouse and so will whatever query and reporting tools, Business Intelligence tools, etc that you may have purchased.
Even your Excel spreadsheets will be easier, faster and more reliable and all sorts of advanced analyses that currently you may only dream off will become easily and practically achievable.
The Cubic Business Model provides a Group Consolidation model that will accommodate the most complex organization structures through a systematic approach to modelling the real world legal complexity of the organization.
The entire logical solution provides a foundation for tying together all aspects of the integration of your ERP or Business Data Warehouse information in a manner that facilitates drill down from one line of inquiry and drill up into other sources of information – launch an inquiry into the asset costs in the General Ledger and drill up easily into the Assets Register or Plant Maintenance Module to obtain the detailed analysis of well-structured financial AND OTHER information in those modules.
5. Facilitates strategic (thrive) financial analysis
By starting the design in consultation with the Executive Team and Chief Executive and then working in depth with the Chief Financial Officer constantly testing against the strategic goals and parameters of the organization all dimensions of the model (Locations, Functions and Accounts) are hierarchically described in a manner that places strategic information in the forefront of the default reporting sequence and therefore in the forefront of all query and reporting and even posting of information in the entire ERP environment.
This ensures that one consistent strategic view of the business is conveyed throughout the organization.
There is no "gee wiz" in this, it is simply the consequence of a senior and very experienced facilitator working with the executives of the client organization to design a high level structure that accurately reflects the strategic parameters of the organization – the essence of why it exists and how it thrives – the essential economic and other fundamentals of the business.
There is no short cut; the ONLY way to achieve a high value strategic focus is to start with the custodians of the strategic view of the business – the CEO, CFO and other members of the Executive team.
6. Structured financial taxonomy that covers the entire enterprise and ties it all together
The final result is a structured financial taxonomy that covers the entire enterprise and ties it all together.
The cubic model – made up of individual businesses, locations, functions and accounts is all designed at the executive level to accurately reflect the real world in such a way that executives, managers and supervisors down to a fine level of detail are each presented with an accurate and entirely consistent income statement and balance sheet for the part of the business for which they are personally DIRECTLY ACCOUNTABLE.
Coupling this to accounting disciplines and policies ensures that journal entries are minimized and ownership of information is maximized. Other JAR&A principles in the design greatly reduce the need for overhead apportionment journals and the like. This approach is a radically better paradigm for most organizations.
Having said this it is important to recognize that the vast majority of business units in most organizations manage expenses and to a lesser extent assets so, in most cases, the sub-unit financial statement is purely a very detailed expenditure statement that can be readily measured against planned budgets and rolled up to achieve views for individual plants, functions, business units – any grouping that is relevant.
The Cubic Business model provides a robust model of the real physical world – locations are places you can walk to and kick, functions are tasks for which you will find personnel and sometimes machines doing things aligned with the fundamentals of the business.
The governance of this physical model sits in another layer, a reporting model that is implemented ABOVE the Chart of Accounts, NOT in the Chart of Accounts – the impacts of corporate restructuring and other reorganization are minimized and generally reduced to different groupings of the same building blocks in the reporting layer.
7. Radically improve accountability, governance, decision support, empowerment …
As indicated above the Cubic Business model is designed from a fundamental first principles strategic (essence of the business) approach that accurately reflects the physical (location) and functional dimensions of the business at a level of fine granularity that allows the business to present every executive, manager and supervisor with a precise financial statement that reflects ONLY those expenses and other components over which they have personal control and accountability.
Correctly implemented the Cubic Business Model can eliminate private calculations of performance and gets everybody managing off the financial system as they should.
With strong emphasis on holding all who control expenses and other financial components accountable for their exact numbers and through ensuring that those exact numbers come directly out of the General Ledger we find that the entire enterprise starts managing off the same source data.
The result is that the General Ledger becomes largely self-auditing – everybody is using it, everybody knows exactly where every transaction came from and everybody is held accountable. This is NOT a technology thing – the JAR&A SEPT Cubic Business Model and Group-Wide Chart of Accounts provides the logical content mechanism to make such rigorous use of systems possible BUT management focus and commitment to making the model work is VITAL to achieving a the benefits touched on above.
Once these mechanisms are in place the high levels of accountability immediately has a dramatic impact on governance AND leads to empowerment – as long as Joe is performing relative to budget and everybody trusts the numbers his superiors can leave him to run his business unit or sub-unit and concentrate on strategic issues and growing the business.
Because Joe has accurate, dependable, up-to-date numbers Joe can make better decisions and manage better and in his own right assist the organization to thrive.
The logical next step is that the audit bill goes DOWN!
The first time this happened I was caught completely by surprise – the audit was cut from 6 months to 6 weeks and the balance sheet was unqualified for the first time in 15 years!
8. Supported by sophisticated "GL Builder" software
As I mentioned in the history of the approach, I have always used computer software to help me assemble the model, it can be done manually in a spreadsheet but that is extremely tedious and error prone and maintenance becomes a MAJOR headache.
We have developed a suite of software which we call "GL Builder" which we use to assist us in building the Chart of Accounts and the Cubic Model.
This tool allows us to select the locations, functions and accounts that apply to a particular business unit, then select the functions and accounts that apply to a particular location and then the accounts that apply to a particular cell (location – function intersection) on the cubic model.
Thus we have an absolutely harmonized Chart of Accounts for each cell on the matrix – "Sales Personnel Commission" is ALWAYS the same account across the entire model, even if we have 500 branches in 50 countries we will always be able to compare like with like across the entire enterprise.
And the above matrix concept can be used as a presentation tool over the entire Chart of Accounts to display specific costs for example across the entire enterprise – your imagination is the limit in terms of what you can do in your Business Intelligence Tool and the data will now SUPPORT your imagination instead of getting in the way.
9. Can be implemented as a mapping layer in your Data Warehouse and used for acquisitions
Much of the above discussion has related to the use of the Cubic Model in an ERP, however, it can be used very effectively in the mapping layer (Transform element of the Extract, Transform, Load mechanism) of your Data Warehouse to unscramble the spaghetti on a 20:80 basis – 20% of the cost and effort to give you 80% of the strategic benefit.
Because of the highly structured nature of the Cubic Model and Chart of Accounts and the use of computer software to generate the model a model can easily be created for a potential acquisition at a summarized level and used in due diligence investigations in order to evaluate the viability of the proposed acquisition. The standard financial reports of your organization can be easily and quickly applied to the Trial Balance of the target organization so that you can evaluate their figures against your proven reports and analytical techniques.
For the same reason, once an acquisition goes through it is a relatively simple matter to map their existing Chart of Accounts onto your operational SEPT Chart of Accounts and start reporting to the same standards as the rest of your group.
As with all information technology the realization of the benefits outlined above requires effective implementation, proper training and rigorous discipline in the use of the computer based solution.
Benefits of developing group wide
Precision strategic master taxonomies
and data attributes to JAR&A standards
The following are conceptually the major benefits of implementing group-wide master taxonomies to the standards of precision, structure and discipline that I advocate.
Relative value is expressed in percentage out of total value delivery from the complete solution through the different factors – total for all factors is 100% -- these numbers are indicative based on my observations over the years and will vary from organization to organization.
In presenting these benefits it is perhaps important to note that my benchmark is the first commercial business computer solution I ever developed which enabled the client to double their turnover in twelve months because they could do things that competitors many times larger could not do by making better investment decisions.
I would like to stress that all the above harnesses existing technology to its full potential – this is NOT a technology solution.
1. Strategic executive view of the data – 2%
All data is sorted and grouped in a manner that makes most sense from a strategic executive perspective of the organization.
Hierarchical taxonomies sorted from most strategic (essence of the business / thrive) information at the top of the taxonomy down to the most routine at the bottom with ease of drill down that reflects the strategic perspective on the business ensures that all users of the data share the same strategic view of the strategic priorities of the business.
If these taxonomies are deployed in operational software then these priorities are communicate throughout the organization simply by use of the software. In principle, however, it is recommended that these taxonomies should FIRST be deployed in a tailored data warehouse.
The remainder of this document assumes that taxonomies are first deployed at the data warehouse level.
These benefits are material, but they are NOT where the true return on investment lies.
2. Presentation of detail, roll-up and drill down are logical, intuitive and fast – 4%
Hierarchical logic and supporting code schemes make presentation of detail and roll-up to summary logical, intuitive, flexible and fast.
The strong hierarchy design principles ensure that there are generally between five and ten items at any level in the hierarchy which facilitates ease of use, speed of interpretation and speed of drill down. These design principles recognize the cognitive span of the human mind and take account of the psychology of decision making.
The code scheme and hierarchy design rules that I apply ensure that the drill down capability of all reporting and analysis tools operates at peak performance, in some cases orders of magnitude improvement in ease of report construction with associated reductions in development and maintenance costs result provided that developers understand the logic and conventions and work with them.
3. Operational reporting and system operation is streamlined and operational efficiencies result – 6%
Because the raw data is so highly structured and classified operational reporting and system operation is streamlined and operational efficiencies result provided that reports etc are designed to work WITH the taxonomies.
An extension of the previous point in terms of delivery of value.
4. Emphasis on content precision improves data quality – 8%
Emphasis on content precision improves data quality throughout the organization with resultant low-key second order efficiency and presentation gains – reports, etc are neater and more accurate.
This is an overall cultural benefit that I did not anticipate but was lifted out as a key element by a client a few years ago.
5. Datawarehouse mapping is greatly simplified resulting in a much higher level of report and model reliability and sustainability – 10%
If the precision strategic taxonomies are introduced between the ERP / Business Information System layer and the data warehouse / business intelligence layer ETL (extract, transform, load) is simplified and a much higher level of report and model reliability and sustainability is achieved.
If the taxonomies are introduced in the ERP the ETL in the Data Warehouse is massively simplified.
Providing highly structured strategic business logic in the input mappings to the data warehouse with either scenario opens the door for massive improvements in effectiveness and efficiency in the business intelligence layer – this is where the real benefits are delivered.
Implementing the taxonomies in the operational software must go hand-in-hand with a comprehensive re-implementation or new implementation of the business information systems and I am increasingly seeing that this should only happen once there is a comprehensive solution in the data warehouse space. Refinement of code schemes in the operational software will be necessary during data warehouse design and construction.
The points that follow assume that the taxonomies are implemented in a clean, green fields data warehouse instance built from scratch to maximize the effective exploitation of the taxonomies.
6. Enables greatly improved due diligence and ease of integration of acquisitions – 12%
This approach makes it possible to rapidly map data from potential acquisition targets during due diligence in order to evaluate performance using standard reports and models in use for the rest of the Group.
This same capability opens the door for greatly accelerated integration of acquisitions into Group standard analysis reports and models.
This is a spin-off benefit that may not be that material in your organization, however, if you are considering acquisitions this benefit alone could more than pay for the entire investment.
The key benefit of this approach is that because you have the tools to quickly and easily map source data to the new highly structured taxonomies you can then easily apply standard reports to the mapped data and produce comparative analysis of the target firms' financials and other data using exactly the same reports and models you use for the rest of the Group.
Effectively what this does is it enables you to analyse the target as though it was already part of the Group and get a good feel for its real performance using your own metrics.
By extension, immediately the acquisition has taken place these same mappings can be used to start reporting on the new member of the portfolio to the same standards of the rest of the group from month one.
This obviously assumes your acquisition is in the same business as the rest of the companies in the group. If you are a bank and purchase a fleet of fishing trawlers there will be challenges – you will have to extend your existing taxonomies to accommodate the new business area first!
7. Greatly improved sophistication of management reports improves operational and tactical (things right) decision support dramatically – 18%
Because of the highly structured logic of the data much more sophisticated management reports and graphs become readily achievable giving a quantum improvement in sustainable management information which greatly improves the quality of operational and tactical decision support.
At this point the investment really starts to pay for itself by enabling the capability to build robust reports and analysis tools that evaluate whether the business is doing things right.
A significant investment is required over and above the development and deployment of the taxonomies in order to develop reports to the same standards of precision and excellence that are inherent in the taxonomy approach which I advocate.
Once this investment has been made it becomes orders of magnitude faster and cheaper to produce reports and undertake more complex analysis which in most organizations would be impossible with the sort of data that is in general existence.
In order to understand this point it is important to note that I am coming from a perspective of practical experience in the application of really sophisticated graphical and statistical techniques which are seldom understood by people in the IT or management space and which few people know how to apply.
These techniques, if appropriately applied, open the door to a much more meaningful and much deeper understanding of the business, trends, relationships, sensitivities, correlations, etc than is possible with the data that is typically found in business information systems.
This is the point at which the concept of a dashboard as a range of precision instruments taking precision measurements starts to become really valid.
8. Enables advanced sophisticated analytical models with greatly improved support for strategic (right things) decision making – 40%
This in turn makes it possible to construct sophisticated economic and other analytical models and use sophisticated analytical techniques which greatly improve the quality of strategic decision support information which facilitate decisions that enable the business to do the right things well (thrive).
This is where a quantum level of return on investment results IF executives exploit the resources created in order to make better competitive decisions.
This builds on the previous point but extends it into advanced economic and other models which permit the executive team to really manage the future long term direction of the business and supports them with the information they need in order to achieve exceptionally high value business decisions.
One high quality business decision that results in a high value sustainable business investment or divestment decision will pay for the investment in technology and services with geared multiples that cannot be realistically quantified.
The real value of an executive lies in the strategic decisions they make and the real value of what is being proposed here lies in the ability of the information infrastructure that is created to support such high value decisions.
The true value of your organization being able to make much better decisions than its competitors cannot be quantified in currency terms – it could be the difference between being the target of a take-over as opposed to being the acquiring firm in a take-over.
In moving into this dimension it must be stressed that it is necessary to bring in information that is not contained in the operational business information systems. This would include soft information and there are robust techniques which, if implemented to the same standards of rigour, precision and taxonomy design will provide all sorts of possibilities in terms of analysis and decision support.
For years people have been trying to develop technology that compensates for mediocre or poor data quality.
The approach advocated here is different, this approach treats the problem at its root and provides exceptional structure from a strategic business perspective together with logical conventions that make the technology perform at exceptional levels.
This is the next frontier of business information – it is the next major opportunity – organizations which seize this opportunity will definitely gain an advantage over their competitors.
Achieving these benefits today is NOT trivial, there are lessons to be learned and software tools to be developed. I have been doing the basic things described here for about 24 years but it is only in the last few years that I have realized that most people are not aware of this opportunity and that what I do is radically different to standard practice.
It is only in the last two years that we have started to develop software to facilitate and support what is described above. The full magnitude of benefits cannot be accomplished without specialised software tools to assist with the development and maintenance of code schemes. We have an overall concept design for the entire software solution and are in development of the software at this time.
In summary the final benefit of this investment is that strategic business information is provided in such a way that the factors that give rise to the phenomenon of 19 out of 20 businesses being dissatisfied with their ERP / business systems investment are overcome and the organization moves from the realms reported by Gartner of not making better decisions despite huge investments to a space of exceptional decision support.
This investment has the potential to equip executives with the resources that will allow them to make strategic decisions at a far more reliable and far more sophisticated level than competitors thereby opening the way for greatly enhances strategic competitiveness and therefore profitability.
Key Components of the
JAR&A SEPT Cubic Business Model
and Group-Wide Chart of Accounts
Further to the previous section the following elements are key to the Cubic Business Model and Group-Wide Chart of Accounts developed and implemented to JAR&A Standards:
The most essential element of the Cubic Business Model is the logical concept – the realization that each of the dimensions of the model are as hard as concrete and must be precisely and consistently defined and maintained.
It is a highly modular concept and therefore scalable and portable to any enterprise. I have applied the model conceptually in a wide diversity of enterprises including National Government Departments and large multi-business commercial groups.
2. Divisions – the real commercial elements
This is where the commercial reality is modelled, certain principles apply to take account of foreseeable growth, restructuring, etc. Operating divisions / business units / legal entities – as big and as complex as the biggest organization.
Highly modular and hierarchical – SEPT taxonomies apply.
3. Locations – walk to and kick it – WHERE we do what we do
The physical dimension of the business – actual places where things happen – you can always associate a person or an asset with a location. Ships and aircraft are movable locations.
Highly modular and hierarchical – SEPT taxonomies apply.
4. Functions – people (and machines) doing things – WHAT we do
A function is about what we do – it is a collection of activities performed by a person or group of persons, frequently utilizing one or more assets in order to perform a function that is necessary for the operation of the organization.
Highly modular and hierarchical – SEPT taxonomies apply.
5. Accounts – Revenue, Assets, Liabilities, Capital and Reserves
The accounting dimension determined by the CFO in conjunction with Executive Management – exact logic varies from organization to organization:
- Revenue structured from core revenue to ancillary revenue and "Other".
- Assets structured from least liquid Assets to most liquid. High level categorization of fixed Assets carried through all areas of asset related accounts.
- Liabilities structured from long term to short term and "Other".
- Capital and Reserves to standard accounting conventions.
Highly modular and hierarchical – SEPT taxonomies apply.
6. Accounts – Expenses – critical element of the model
Expenses are listed here separately because, in practice, in most enterprises there are far more units in the Cubic Model that have expenses than have the other categories of account.
Generally there are far more personnel who are managed in terms of expenses than in terms of the other elements.
The expense chart needs to be very carefully thought out from a strategic (essence of the business) perspective and takes by far the most time to define and refine. It is really important that all lists, but particularly expenses, are as comprehensive and finely granular as practical.
Highly modular and hierarchical – SEPT taxonomies apply.
As mentioned under Assets, there are logical sub-modules, for example the main headings under which Fixed Assets are reported in the General Ledger ranging across Asset Cost, Accumulated Depreciation, Insurance, Repairs and Maintenance, Spares, Leases, etc, etc.
Similar categorizations may apply to Personnel costs, products, related parties, etc.
There are important rules relating to how these are all defined in order to ensure that the categorization across all modules of your systems is harmonized and exactly consistent so that reports in one module integrate seamlessly with those in others thereby allowing you to use software in your Data Warehouse to quickly and easily drill down and drill up between modules in order to get answers to your questions – including those questions you have never previously thought to ask.
Highly modular and hierarchical – SEPT taxonomies apply.
8. Assembly of sub-charts per location and function
The GL Builder Software enables the rapid selection of the accounts for every sub-chart of accounts across the entire model and the assembly of these sub-chart blocks to build the entire Chart of Accounts so that the account codes are 100% uniform and consistent across the entire enterprise.
9. Reporting and modelling layer
In understanding this approach it is vital to understand that a whole lot of management accounting "things" and reports are removed from the General Ledger and instituted in the Data Warehouse.
- The modelling and reporting of current governance should NOT be in the Chart of Accounts or in the General Ledger at all.
- The distribution of overheads should NOT be in the General Ledger.
- These are best accommodated by sophisticated query and reporting and modelling capability within the Data Warehouse and Business Intelligence environment.
This enables a high level of stability in the General Ledger and a high level of confidence in the figures which in turn results in all personnel managing from the General Ledger and the reports and models in both the GL and DW / BI components.
Ultimately, the most important element of the JAR&A SEPT Cubic Business Model is that it is a WAY OF WORKING, it is a culture, it is a set of rules and protocols and practices that take the management of financial information to a new level of precision and value add for the enterprise.
Suggested basis of attribution of
overheads and production costs in
a cubic business model environment
One of the points made in previous sections relating to the philosophies and operational practices recommended for a JAR&A SEPT Financial Taxonomy (Cubic Business Model and Group-Wide Chart of Accounts) is that journal entries in the General Ledger should be cut to a minimum.
1. Journal corrections fall away
Experience indicates that in a properly configured and properly implemented SEPT GL environment journal entries to correct posting errors hardly occur.
2. Operational people distrust journals
Probably the biggest single reason that most operational managers and supervisors do NOT use the General Ledger for management information and decisions is because of the presence of management journals such as proportional overhead distribution, split invoices, etc.
Frequently the basis of attribution of these journals is not made clear or is disputed and, as a consequence, most managers and supervisors ignore reports from the GL and maintain their own records which reflect the reality of their part of the business – which generally is the real view anyway.
Part of the SEPT concept is to provide an alternative method of allocating overheads and introduce disciplines to minimize or prevent split allocations.
This document outlines a proposed method for allocating overheads that builds on the logic and structure of the JAR&A SEPT Cubic Business Model and Group-Wide Chart of Accounts.
3. Post to the unit that incurred the cost
Since in most cases we are concerned with expenses I will use language relating to costs.
The fundamental principle is that the costs should be posted to the unit that incurred them, or that signed the order. Provision should be made for the complexities of the real world and for notional accounting business units, with real designated managers, that account for:
- Location costs that cannot be allocated directly to function – electricity is frequently an example – generally there is one set of electricity meters serving the entire location.
- Function costs that cannot be allocated to specific locations – for example the development of Human Resources policy incurs external costs which cannot be allocated to a particular location and which should be applied across the entire enterprise or at least across all locations.
- Corporate costs that cannot be allocated to locations or functions – for example much of your financial balance sheet such as bank accounts, debtors control account, etc frequently are located here.
These and other rules are determined as the model is constructed in the GL Builder tool.
4. Functions are categorized into major categories
In general I recommend that Functions are divided into the following categories:
- Revenue is categorized separately so that all operational business units have costs allocated on the same basis without having revenue distort the operational financial reports – this does NOT impact the macro corporate financial statements which are driven off the Master Chart of Accounts
- Core – the essence of the business (the strategic heart of the business) e.g. the factory
- Core – support, that which we do to make sure the essence of the business operates effectively e.g. the technical service and engineering staff who look after the machines in the factory
- Some clients separate out "Sales, Marketing and Distribution" although these can be separated out using other techniques
- Administration – all the other stuff which is not core or core support e.g. business administration, finance, etc
Some clients use the same categorization in the Chart of Accounts.
These major categories of functions provide a mechanism for consolidating and rolling up costs off overhead business units onto production business units and then tying them in to revenue.
The following sections explain how this works. As you develop understanding of how this model works you will be able to add in additional layers of cost distribution.
5. Build the model OUTSIDE the General Ledger
In the steps that follow please see this model as built either in a spreadsheet (OK for prototyping but NOT recommended for long term operation) or in a model in the Data Warehouse and Business Intelligence environment which is what is recommended.
Alternatively this can be constructed in a consolidation tool.
The model should be modular and incremental and designed in such a way that all cost drivers, ratios, etc used in the model can be quickly and easily changed to allow scenario computations to be performed. Cross casting and other spreadsheet quality control techniques and disciplines are VITAL – the bottom line of the income statement must always be the same at all levels of the model as a minimum quality check, there are many others that should be incorporated.
6. Corporate costs independent of location and function
Take the costs from the cell named "Corporate costs independent of location and function" (bottom right above) and spread them over the entire model on a pro-rata basis using appropriate cost drivers.
7. Location costs independent of function
Take the costs from the "function" named "Location independent of function" (third row from bottom) and spread them UP THE COLUMN over the functions for that location only.
8. Function costs independent of location
Take the costs from the "location" named "Function independent of location" and spread them ALONG THE ROW over the locations for that function only.
Take the costs from all the cells corresponding to functions categorized as "Administration" and spread them UP THE COLUMN over the Core Support and Core functions above them.
Take the costs from all the cells corresponding to functions categorized as "Core Support" and spread them UP THE COLUMN over the Core functions above them. This leaves you with only Core functions and Revenue Functions. If you have categorized "Sales, Marketing and Distribution" separately you would distribute them up the column first.
11. Core costs onto Revenue
Take the costs from all the cells corresponding to functions categorized as "Core" (which now contain the ENTIRE spread of costs) and spread them UP THE COLUMN over the Revenue functions.
If you have been thorough and accurate in the determination of cost drivers, which costs to apply them to and how to distribute them up the model this should leave you with a very precise activity based computation of net profit contribution for each of your major revenue streams.
This model will take significant work to develop and calibrate but, provided it is well designed and well built, it will provide you with a learning environment in which you will progressively gain greater insight into the real cost dynamics of your enterprise.
With a well-designed model it is now possible to produce income statements for each cell which show the attribution of overheads to that cell in such a way that the custodian of that cell may engage with the model and management and assist in making the model more precise over time.
Fundamental to this approach is that performance incentives are ONLY computed based on the measures over which the manager or supervisor has direct control plus an agreed logic for the overheads IF it is intended that the manager should influence other parts of the organization to manage their contribution more effectively.
This approach allows the organization to progressively build more complex and more reliable costing models based on accurate measurements linked to cost driving activities and become a learning organization.
Why taxonomy software?
Why Taxonomy and Configuration Management software is necessary
Having outlined the conceptual elements of an ERP configuration management software suite the question arises "why is this necessary?" The points that follow headline the reasons why such software is vital to any organization:
Consistency and precision of hierarchy and code schemes is central to the concept of precision configuration and therefore the use of software is vital.
2. Only to JAR&A standards
Software is only possible with precision configuration to JAR&A standards and then all sorts of powerful automation and intelligent processing become possible.
3. Alternative is expensive people
Rule based taxonomy and ERP configuration management without software can only be achieved by highly trained and expensive personnel with robust succession planning. Alternatively clever software must be used.
4. The concept powers the opportunity
The very patterns that make precision configuration so powerful as a source of management information ALSO open the door for automated software tools to assist with building precision configurations.
5. Greatly improved long-term taxonomy and configuration quality
The use of precision ERP configuration management software greatly improves quality.
6. Software cuts in where manual costs escalate
Manual taxonomy construction becomes increasingly costly as the detail expands exponentially down the hierarchy but at roughly the same point that manual construction and coding become unwieldy and costly software will start to perform at its best.
7. Reduced life time operating costs
ERP configuration management software will drastically reduce ERP life-time operating costs IF consistently and reliably employed AND greatly improve sustainable ERP performance with particular emphasis on the quality of management information.
I am firmly convinced that an investment in ERP configuration management software will serve any organization extremely well and will offer a sizeable return on investment. This is the way of the future for ERP and business information (including BI and DW) generally.
What is the JAR&A taxonomy software?
What is the James Robertson and Associates taxonomy software?
The JAR&A taxonomy software is a set of software tools designed to assist with the development, deployment and maintenance of high precision taxonomies to JAR&A standards
JAR&A standards lend themselves to the creation of software tools and require high levels of taxonomy precision in order to operate at full potential. These tools facilitate the creation of taxonomies to these high standards of precision and the high standards of precision in turn make the tools possible.
3. Taxonomy Builder
The basic taxonomy builder elements are a range of tools to assist with the creation and manipulation of hierarchies, addition of suffixes and coding of hierarchies to high levels of consistency with high levels of compliance with JAR&A standards.
4. GL Builder
General Ledger Builder is a sophisticated suite of software specifically designed for the precision specification and assembly of three dimensional code schemes such as the Location – Function – Account structure that is fundamental to the assembly of precision General Ledger Charts of Accounts – first prototype developed in 1990 as part of a 1,000 hour research and development project.
GL Builder is one of the two deployment modules that form the commercial software suite – the other elements are included in both of these modules as they relate to the main module concerned.
5. Complex List Builder
The complex list builder contains many of the other elements of the software designed as a sophisticated tool for the construction and maintenance of classification schemes associated with lists such as the SAP Materials Master, Lawson M3 and Infor LN Item Master, etc. The tool caters for very complex open ended coded logistical taxonomies and other complex lists.
The same tool is used for simple taxonomies.
Complex List Builder is the other deployment module that forms the basis of the commercial software offering – the other elements are included in both of these modules as they relate to the main module concerned.
6. Taxonomy maintainer
The taxonomy maintainer functionality is an integral part of the solution and provides facilities for code scheme maintenance.
It is one thing to build a precision taxonomy with a highly experienced facilitator, it is another to maintain the precision over time as people change and forget the finer nuances of the code scheme. Code scheme maintenance functionality provides tools to only allow addition of entries in valid locations, maintain the integrity of hierarchies and code schemes, check for duplicates and then generate the update files for all dimensions of all tables to be updated.
7. Report and BI builder
The Report and BI builder functionality are a planned future module that will exploit the highly structured list designs to provide the ability to rapidly generate and deploy diverse standard reports, dashboards and BI models taking account of the full complexity of the taxonomies.
This functionality is based on the realization that the full potential of the investment is only realized when information is delivered in a format that will give rise to high quality high value business decisions – this capability was first developed as a prototype in 1993.
Taken together this suite of tools offers clients an unsurpassed opportunity to obtain value from their existing business information system investments in ways that were never previously possible on a sustainable basis.
It is planned that the current versions of the software will eventually form the basis of a range of products to be marketed internationally.
To the best of my knowledge there is nothing that even vaguely compares to this software and methods available elsewhere.
Why use the JAR&A taxonomy software?
Why should you use the James Robertson and Associates taxonomy software?
1. 34 years' experience
James Robertson has been developing and building taxonomies and catalogue schemes since 1977 and developing taxonomies for ERP and other business information systems since 1987. This software provides expert guidance – like having James to help you.
Benefits: improves quality, reduces risk of poor design, speeds up work.
2. Expert guidance for maintenance
Where taxonomy development has been facilitated by James these tools provide expert guidance to assist with the maintenance of taxonomies designed by him in order to maintain the integrity of the design.
Benefits: improves quality long term and reduces or prevents degradation, reduces support costs.
3. Tools used by James
Many of the tools have been designed for use by James to help speed up taxonomy development and to ensure high precision consistent lists.
Benefits: precision, quality, time, reduced costs.
4. Enable larger and more complex taxonomies
The tools make it easier to accurately build large and complex code schemes – for example James will not attempt a Cubic Business Model Chart of Accounts project without the GL Builder software module.
Benefits: major time savings, greatly improved accuracy, ability to do things that are impossible manually.
5. Full Material and Item Master complexity only possible with tools
The complexity of content and the open ended nature of Materials Master and Item Master tables is so great that it becomes almost impossible to build and maintain the full-house complexity of such lists manually.
The Complex List Builder provides the tools to do this.
A later edition is planned to include full intelligent Master Data maintenance capability.
Benefits: support full potential of Materials Master and Item Master tables, unlock full potential value of ERP software, support greatest intelligence with highest quality on a sustainable basis.
6. Avoid degradation of taxonomies
When a new taxonomy is deployed those involved in its development understand it intimately but as time passes and staff change, or just get out of touch, the quality of taxonomies tends to degrade
In some cases degradation significant enough to fundamentally damage the functionality of the taxonomy can occur within weeks without proper training.
The taxonomy maintenance tools provide expert guidance to minimize degradation and prevent it altogether when used by a well-trained senior staff member.
Benefits: sustainability, minimized cost of operation, maximize reliability, ease of maintenance, preserve investment.
7. Precise maintenance
In complex taxonomies where the addition of one entry can generate multiple entries the taxonomy maintenance functionality automates the generation of update entries for uploading into master data tables.
Benefits: ensures that updates are precise and easy to load, guarantees accuracy of updates even in complex taxonomies like the GL Cubic Business model for a large and complex enterprise.
8. Support sophisticated and comprehensive reporting
Building taxonomies is the foundation of the investment, it is only when there is a comprehensive collection of reports ranging from simple tables to complex models that fully exploit the potential of the taxonomies that value is truly unlocked.
The Report and BI Builder tools will provide a mechanism for replicating reports across the full range of taxonomies together with a report library management facility.
Benefits: ease of replication and management of reports, move from a scrappy collection of ad-hoc reports to a well ordered portfolio of well-designed reports designed for all eventualities, particularly important with the Cubic Business model in order to give every supervisor and manager a comprehensive portfolio of operational management reports.
The JAR&A Taxonomy software provides a range of tools that open the door to levels of strategic, tactical and operational information efficiency that have been promised for decades but seldom if ever delivered.
Further information on the use of software
to develop and manage Taxonomies
and Precision Configuration
Following are headline comments on the technical approach supported by software that I think is most appropriate in developing and maintaining taxonomies:
Fundamental concept is to design and maintain precision configuration sustainably.
1. High level structure of main taxonomies including – Item Master / Material Master / Product Master, Chart of Accounts, Customer and Supplier Line of Business, Locations, Functions, Assets and Machines, People categories, etc developed manually in Excel using standard JAR methods.
2. Attributes of all the above – standard system attributes to use and NOT use and clear definition of those used and of client and industry specific attributes logically and hierarchically grouped on maintenance forms that correspond to different categories of products and services for ease of access and posting and to Item coding.
3. Custom Screen forms to capture data – rule based from attributes.
4. Grid based (Excel like) view of configuration master files with ability to hide levels of hierarchy and columns based on the attributes, drag and drop, etc to quickly and accurately configure master files all the way through to process files, routers, Bills of Materials, etc.
5. Master file maintenance – dropping default parameters down the hierarchy as done at ASCO all the way to the SKU.
6. Auto-build the Item code and other code fields from the attributes dropping down the hierarchy including provision for counters (sequence numbers).
7. Write content into target ERP data tables.
8. Documentation of coding standards and conventions in such a way that they can be printed as manuals or used in on-line help.
9. Generation of simple standard reports based on the hierarchies – rich variety of standard reports quickly and easily maintained.
10. Maintain code functionality – limit the addition of items, build the code for insertions of items, look for synonyms, etc tightly linked to role based permissions and access control with knowledge based rules to control additions.
More sophisticated reports and models in business intelligence environment based on hierarchies.
Benefits of taxonomy software
Following are the benefits which will result from use of the JAR&A software:
Overall a necessary and cost effective adjunct to providing and maintaining sustainably and affordably high quality code schemes.
1. Senior users will be able to add additional line items into a taxonomy using a well trained staff member without needing external consultants.
2. Reduce the overall cost of developing, deploying and maintaining large taxonomies like the Item Master / Materials Master / Product Master and the Chart of Accounts.
3. Greatly improve the ability of own personnel to extend hierarchies to accommodate growth in the business with improved precision over manual techniques and reduced cost relative to bringing in a consultant.
4. Greatly reduce risk of degradation of hierarchies and code schemes with resultant increase in risk of making bad business decisions based on poor data – safeguard the investment.
5. Facilitate and enforce standards and allow narrow focus of responsibility for different people in different business areas to maintain codes in a way that does not adversely affect the rest of the business, reduce risk and reduce long term operating cost.
6. Codes built largely by the software ensuring consistent application of standards and improved sustainable quality.
7. Precision engineered strategic configuration coupled to strategic customization can deliver a threefold or greater improvement in performance from an ERP which is easily lost if hierarchies and / or code schemes degrade. The software greatly reduces the cost of maintenance and risk of degradation thereby improving overall reliability of reports, dashboards, models, etc.
8. Greatly reduces time and cost of master data configuration and maintenance of master data.
9. Greatly improves quality and reduces time and cost of mapping old codes onto new taxonomies.
10.Deliver many of the benefits of having James Robertson maintain the hierarchies himself at much lower cost and greater convenience.
11.Largely eliminate finicky and highly time consuming drudge repetitive work while building hierarchies and code schemes.
12.Facilitate much more complex code models like the cubic business model in the GL which because it is so abstract is very difficult to build and maintain manually.
The comment feature is locked by administrator.