CIO Expert Witness

A primer to understanding where (else) to look for clues during dispute analysis.

Introduction: ERP – Today and Tomorrow

Before delving into the discussion, a reminder of what constitutes an Enterprise Resource Planning (ERP) system, and an insight into the current and future state of the ERP marketplace is useful. ERP software is a comprehensive suite of applications that is meant to replace disparate systems in business areas such as accounting, finance, HR, manufacturing, and logistics. An ERP system is a single software package divided into modules, each delivering a set of functionality broadly similar to individual standalone systems, but operating in an integrated and interdependent way. Examples of the largest and most widely deployed ERP systems are SAP, and Oracle, now combined with the recently merged PeopleSoft/JD Edwards.

While usually thought of as systems for large companies, and as we’ll see this is true to a certain extent, the ERP market has always been, and is increasingly more so, made up of mid-market companies having less than $1B in revenues. SAP reports that out of 18 categories of Fortune Global 500 companies, their market share exceeds 75% in 12 of those, and averages 55% in the remaining six. However, SAP also states that 31% of their revenue, and 60% and 50%, respectively of Oracle’s and PeopleSoft/JD Edwards’ revenues, come from the mid-market. In spite of SAP’s dominant position in the Global 500 market, they estimate that they only have an 18% share of the potential market for ERP class software.(1) The point being that the adoption of ERP software, although already widespread among large companies, is a solution that mid-sized companies will continue to explore and implement.

The key concept of this class of software is that it is meant to address the business process needs of a large part, or perhaps even all, of the enterprise within a single system. Due to their comprehensive nature, these systems are notoriously complex, and implementing the software frequently forces changes to a company’s existing business processes. These projects are also expensive relative to a company’s size. A META Group survey showed the average implementation cost for SAP, Oracle, Peoplesoft, and JD Edwards, to be over 1.5% of company revenue. (2) It should not be surprising then that because of these characteristics, ERP implementations will continue as a likely source of disputes between the many parties involved.

Balancing the Dispute Review – Putting Flesh on the Bones

There will certainly be a multitude of issues to consider when assessing the merits of an ERP implementation dispute. A piece of cautionary advice is to resist the natural urge to conclude that because the topic is a complex computer system, the definition and resolution of the dispute will occur solely in terms of complex technical issues. While getting a grasp on the technical issues will likely be necessary for a complete understanding of the dispute, they will certainly not tell the whole story.

This article will focus on the non-technical aspects of ERP projects that will have a major impact on its outcome. First will be an insight into the key differences that distinguish an ERP implementation from the traditional computer programming process. This is important, as an understanding of “traditional” programming projects does not necessarily transfer to an ERP implementation. The next topic will be how addressing the change brought by an ERP implementation, through training and a comprehensive communication process, can affect the outcome of the project. Finally, a suggested series of questions will be reviewed that will help in determining a complete picture of the dispute.

The intent of this approach is not to ignore other possible areas of causality, but rather to ensure that the most comprehensive view possible is taken of the dispute. The more technical areas such as the appropriateness of the systems methodologies applied, and/or the technical nuances of the software and hardware used in the particular circumstance, are the “bones” of the dispute’s definition. Exploring these areas is essential. However, the issues spawned from these are often dry and difficult to relate to the judge and jury.

The “flesh” of the dispute’s definition should be thought of in terms of the issues raised in this article. These will have to do with interpersonal relations, office politics, and the impact of the change brought by ERP systems to people and organizations. These literal, flesh and blood, issues are naturally easier to relate to the triers of fact, and therefore easier for them to achieve a level of comfort with when rendering their judgments.

The ERP implementation process (over) simplified

At its most simplistic, the implementation of an ERP system is the process of codifying the entire enterprise’s existing and/or desired business procedures into a set of standardized processes, and then the realization of these in the ERP application. To be successful, this process requires the careful alignment of the business processes with the available options in the application.

To accomplish this alignment successfully, the client company brings its personnel, business experience, and business requirements to the project. The implementation partner, or consulting vendor, brings its personnel experienced with the specific ERP application, and experience with managing large-scale projects. Ideally, these partners would then work together towards the desired solution.

In simplifying the implementation process for the purpose of this article, the myriad of technical issues that can arise are ignored to concentrate on the people issues. A host of possibilities surrounding the applicability and/or performance of software tools, hardware platforms, or the adherence to critical contractual or schedule milestones by the various vendors, all bear looking into.

What Makes an ERP Implementation Different

The implementation of an ERP system is neither like traditional development of custom computer programs, nor like the installation of fully functional, “shrink-wrapped,” software. In an acknowledgement of this, the process of establishing the business processes within the ERP system during implementation is typically known as “configuration” rather than “programming.”

The implication, and its underlying reality, is that those doing the configuration have a range of options provided by the ERP application from which they can choose to “configure” the application to accommodate the client’s business process. A key point of understanding is that while an ERP system does not arrive as “ready-to-use,” as is the case with fully functional software, neither is it infinitely flexible in the same way as a custom written program.

An apt analogy for this is; “Programming is to Configuration, as modeling clay is to Lego® blocks.” In the case of programming, there is what can be thought of as the raw modeling clay, the computer programming code, which is shaped into the desired product with a high degree of control over the resulting product. In the case of configuration, there are a collection of “Lego® block” units of predefined functionality within the ERP application that represent a portion of an overall business process.

These blocks, and the options each contains, are selected and configured to suit the desired business process. As the configuration options are pre-existing, it is important to understand that there is significantly less fine control in the configuration scenario than in the programming scenario. It is also important to understand that the business processes embodied in the ERP application represent a distillation of “Best Practices” derived from the evolution of the application over time. In fact, what the customer might perceive as a lesser degree of control over the configuration of a business process in reality might be a conflict between the desired process and the “Best Practices” that the ERP application is trying to emulate. That is to say, “Best Practices” are exactly that, and in most instances, it behooves the company to realign their business processes accordingly.

If the implemented ERP system contains true programming modifications to add functionality to meet the desired business processes that is outside of the configuration options offered in the ERP application, this is usually a good indication that the “Best Practices” were not given sufficient consideration during the implementation process. In other words, if the Lego® blocks have been cut and shaped, the likelihood is that these modifications could underlie at least a portion of the system’s difficulties.

Collaboration is crucial, or as Will Rogers said, “Everybody is ignorant, only on different subjects”

Appreciating how the configuration process should work is crucial to understanding the importance of the “flesh and blood” component, the people, who participate in it. To achieve a successful project, the configuration process itself should be collaborative and cooperative. This is crucial because it is the uniting of the specialized knowledge of the customer’s business representative with that of the consultant which will result in a system that meets the company’s business process requirements.

For this process to have the highest chance of success, it dictates that the “best and brightest” business minds from the client company be focused on the project, ideally to the exclusion of day-to-day activities. The position and experience of the client’s business personnel assigned to the implementation project is a key indicator of the importance the company attached to the ERP implementation. The presence of inexperienced, or part-time, distracted, client team members in key decision-making positions is a warning flag. To no lesser degree, having consultants who are experienced in the ERP application, and ideally having some relevant business process background, is also a crucial element of success.

Having the most knowledgeable participants also allows for accurate and timely decisions. Swift and effective decision-making is critical to a successful ERP project. By definition, the scope of an ERP implementation is broad. Delays introduced into the project due to untimely decision-making will translate into not only higher cost, but also more time for some component of the business environment to change, with the likely effect of decreasing the fit of the ERP system to the business requirements.

Either the client or consultant team members can have an impact on this process, but because of the nature of an ERP system, the likelihood is that the client company participants will be making the majority of the decisions. The desired business processes are the template for the outcome. However, in most cases some degree, and in many cases a high degree, of “molding” of these desired business processes is required over the course of the implementation to fit the available options in the ERP application. As there are at least many hundreds, and possibly many thousands, of configuration options available across the breadth of an ERP system, there are a similar number of potential choices to be made during the implementation.

Gaps in functionality, real and perceived, will be identified in the configuration process and must be resolved. Ideally, the consultant performing the configuration for a particular business process has practical experience in that area. They are there to collaborate with the business representative in arriving at a solution. If this resolution process is one-sided in either direction, the likelihood that poor choices will be made, and a problematic implementation will occur, is increased.

What must be understood as the review of the dispute progresses is that in a traditional systems development project, i.e. programming, a “mistake” will likely be easier to recognize than in an ERP project. A “programming” mistake will take the form of an application that does not meet some specification provided by the client that is absolutely expected to be met by the delivered software. An example of this might be a screen or report that does not match the desired layout.

In an ERP implementation however, a “mistake” may be harder to identify. Unless the ERP application simply does not function, the “mistake” will likely be only a question of the applicability of the configured solution to the business process requirements of the client company. The configured solution may be technically complete and correct, but not meet the requirements of the client. An example of this might be an expense review process configured so that it does not require review by the corporate controller, although this is the company’s unwritten policy. The source of this type of situation can usually be traced back to a lack of communication on one, or both, sides of the implementation team.

Managing Change Management, or as Will felt about it, “I’m all for progress, its change I don’t like”

By its nature, the implementation of an ERP system introduces change into a wide swath of an organization. These changes can alter the fabric of the business, and carry the potential to create massive disruption if not introduced to the organization in an appropriate manner. While a business process can be represented by words on a page, it will ultimately be controlled and executed by people. Those people will need to develop an understanding of the change that is coming to their professional lives.

The concept of Change Management both includes, and goes beyond, simply training a user on how to use the system. The comprehensive nature of ERP dictates that they must also develop an understanding of the impact errors or delays can have on the interrelated business processes across the entire system.

Shortchanging, or worse yet ignoring, this reality will create a situation in which it is possible to deliver a perfectly configured application into user communities that are at best uninformed and ill-equipped to manage this complex new system, or at worst hostile and unreceptive. These communities are the very people that must understand, embrace, and use it. Chances for success in this situation are understandably slim.

What is clear is that for an ERP implementation to be most successful it must be an initiative driven by the whole business itself, not solely by the Information Technology department, or even just by the uppermost management of the company. Anything less than the total commitment of the business community to support the design and implementation process, reduces the chance for success. The climate of commitment that must exist to ensure success in an ERP implementation should extend from the company’s Board of Directors, down well into the ranks of at least the middle managers of the company. Any lack of focus on the ERP implementation will predictably communicate to the company’s employees the lack of importance placed on it.

However, all too often elements of the business community are not sufficiently involved in the decision-making process, or perceive the ERP implementation as either being a threat or something that needs to be controlled to gain additional power within an enterprise. Resolution of these sorts of territorial issues typically involves the active involvement of the uppermost management of the enterprise.

Any ERP implementation dispute almost certainly involves some issues related to Change Management. It is human nature to be disinclined to change without a benefit being perceived or explained, to have respect for authority within our social and business environments, and to have a generally positive work ethic – if allowed the time and tools to do a good job. However, each of these can work against success in an undertaking that requires change, demands the commitment of our authority figures, and consumes such a large amount of our time and intellectual resources, it is understood to be conflicting with doing our “real” job.

While these behaviors can be influenced to promote the chance of success, the approaches required can tread on entrenched political, personal, and territorial boundaries. This kind of business environment shaping generally lies within the domains we call “Management Style” and “Corporate Culture.” Two realms as varied as the people that populate them. Precisely because these are “soft” questions of style and culture, not “hard” questions of technology, there is the possibility that consultants will shy away from pressing it with clients, and company management will perceive it as not related to technology and therefore not really part of a technology project.

As such, the degree to which Change Management contributes to the dispute in any given implementation will depend upon two things, the extent to which the client is informed by the implementation partner of the need to address it, and the willingness of the uppermost management of the client to heed that advice.

An aside on Change Management, or “GIGO” Revisited

A flawlessly constructed system can still result in erroneous output if the inputs it is given are in error. This is the well-understood axiom of, “Garbage In, Garbage Out.” Well-trained system users, who ideally were involved in the configuration of the system, have a chance to recognize the erroneous output for what it is, and take corrective steps.

In a situation where training has been shortchanged, or when pivotal business process decisions have been made by the consultants rather than the clients, a lesser-known corollary to the above can take place; that is of, “Garbage In, Gospel Out.” (“Gospel,” in the sense of something accepted as being unquestionably true.) In this situation, erroneous output is not recognized for what it is, and business judgments are based upon it. Without an appreciation of the underlying business processes that led to the creation of the output, the person acting on this information has no way to gauge its validity.

An ERP system is nothing if not highly integrated. While desirable from the standpoint of having information available system-wide, any input related to the business transaction, correct or not, moves throughout the system instantly. Unlike an environment made up of disparate, loosely coupled, systems, this propagation of erroneous data will be swift, and can have serious consequences. Likewise, the integrity of the system’s master data - the more static data used by the system to make various sourcing, costing and movement determinations, is essential to its proper operation. All this highlights the need to have the most accurate information entered into the system at all times.

In an ERP implementation, one of the more elemental changes that can occur to a company’s business processes is in the sources of data input that drive the system. In a typical legacy, or non-ERP system, knowledgeable, experienced users in the “back office” of a department in the company are likely performing the input. In an ERP system, the primary input source changes from the “inside” to the “periphery” of the company. Stock-keepers, order entry personnel, warehouse dock employees, and stock receiving clerks become the originators of critical business transactions that instantly flow across former departmental boundaries. Their training, and understanding of the consequences of their actions, becomes fundamental to sound and reliable data entering the system. Any implementation that does not give due consideration to this principle during the change management process is destined for problems.

Reality Check: How important is all this really?

Thus far as promised, our focus has been on people topics. We’ve talked about how the composition of the project team is critical, about how a climate of commitment must exist in the company’s management ranks, and about how a receptive environment must be created in the rank and file of the client company by properly introducing the change brought by the ERP implementation. Well surely, topics more technical in nature are important too.

As mentioned before, they are, but what might offer some insight into their relative importance is a study conducted from the perspective of the Chief Information Officer, or CIO. This study asked CIOs to rank the various Critical Success Factors, or CSFs, for a successful ERP implementation. (3)

Let’s pause for a moment to reflect on the role of the CIO in an organization. This position is the senior management “bridge” between the technical and business segments of the company. The establishment and maintenance of peer relationships with the other senior managers in the company is crucial to being effective as a CIO in the normal course of business, and doubly so when commitments for personnel resources and support are required from those managers to ensure the success of a major corporate undertaking such as an ERP implementation.

The best CIOs understand that they must maintain a balance of competencies in both technology and politics. To be an effective bridge, the CIO must understand both the political realities of their particular company’s current environment, and the specific technical issues that are likely to influence a project’s outcome. In short, the CIOs must position themselves to understand the “Critical Success Factors” for their ERP projects, or risk the consequences.

In reviewing the CSF ranking assigned by these CIOs, we find that the top three, having Top Management support for the project, having a high profile Project Champion, and having an ERP Team that works well together and is composed of the correct people, all relate to the people and/or political issues we’ve already discussed. Coming in at fourth on the list is Project Management. As we’ve mentioned, understanding the applicability of the project management methodologies and techniques used on a project are vital to understanding the dispute. However as we move on through the list with; Change Management, Communication, Business Plan and Vision, and Business Process Reengineering coming next in the order, we see a reflection of more of the sensitivity-to-change, people-focused, climate-of-commitment, issues that have already been raised.

It is only as we get to the lower reaches of the list with items nine through eleven being; Software Development/Testing, System Monitoring and Evaluation of Performance, and Appropriate Business/IT Legacy Systems, do we start to see a collection of issues that are clearly technical. This is not to say of course that these issues are not important, but the position accorded by the CIOs reflects their relative importance in the ERP implementation process.

In summary, "Good judgment comes from experience, and a lot of that comes from bad judgment." (W.R.)

Now that we’ve explored and explained the nature of the people issues that are crucial in an ERP implementation, the conclusions we can draw are two-fold. First, in an ERP implementation the people issues are much more likely to be central to the dispute than the technology issues, and second, absolutely because these are people issues, the missteps and mistakes on ERP projects are certain to continue.

The capabilities of the technologies involved will continue to develop at a rapid pace, and project methodologies will evolve and become more comprehensive of the project process. The one element of a project that will continue to remain contentious is the management of the people that of necessity makes up such a large portion of the variables on an ERP implementation.

We have uncovered the simple secrets to a more complete understanding of an ERP implementation dispute. First, think like a CIO. Understand what elements of the business environment had an impact on the project. Second, weigh the issues. If the technical issues appear to outweigh the people issues, chances are excellent that more exploration is required.

Start by Asking these Questions

The following list of questions is by no means comprehensive. It is intended to lead the reviewer into areas of investigation that might not be addressed if the project were approached from a purely technical perspective. The particulars of the dispute, along with the responses to these questions, will likely uncover areas that warrant additional probing.

How was the decision made to select and implement the ERP application, and did it involve commitment from the client company’s business community?

What kind of emphasis was the client company’s upper management advised to give by the consultant, and how much did they actually place, on the implementation project relative to other initiatives at the time?

What was the client company’s internal “political” environment when the implementation project was undertaken, and was it conducive to the focus and support required for the success of the project?

Was a plan to address the organizational change brought by the ERP implementation appropriately recommended by the consultant and fully executed by the client company?

Did the client company’s project team members have appropriate and sufficient business experience, and were they allowed sufficient time to focus on the project?

Were the client company’s project team members, or the consulting vendor’s personnel, given any performance-based incentives for their participation on the project?

Did the client company’s project team members have the authority to make timely decisions regarding deviations from the desired business processes?

Did the consulting vendor’s personnel have appropriate and sufficient ERP application, and business, experience?

Was sufficient training recommended by the consultant and given by the client, to the appropriate end-users of the application?

Were the client company’s expectations of financial improvement, labor savings, or otherwise, that were to have resulted from the ERP implementation realistic, and who developed them?

Were the consultants with the appropriate application and business experience available to the client team members during the configuration and testing phases?

What was the financial position of the client company during the course of the implementation project?

What was the financial position of the consulting vendor during the course of the implementation project?

----------------------------------------------------------------------------------------

(1) SAP CORPORATE OVERVIEW - Fiscal Year 2004 and First Quarter 2005, SAP Corp., 2005.

(2) Deriving Value from Twenty-First Century ERP Applications, META Group Inc., 2003.

(3) Nah, Zuckweiler, Lau, ERP Implementation: Chief Information Officers’ Perceptions of Critical Success Factors, International Journal of Human-Computer Interaction, 16(1), 5–22, 2003.