Tales From the Front Lines – The Tale of Wanting Too Much

Today I will discuss one of the most important facets of SAP design work, one  that affects design, implementation, and management of any SAP environment.  The following story will demonstrate the need to know the level of detail of data that is required to support effective business decision making, in order to properly design any business process.  It also demonstrates why certification and extensive experience with business for consultants (internal as well as external) is necessary to provide input for the discussion, analysis and design to arrive at an optimal solution for a given business.  And, finally, it demonstrates the importance of senior leaders managing the issues and details involved in this process, including the need for a comprehensive program governance function.  This article points to the need for business executives to either understand for themselves, or ensure they are staffed with trusted people who do have the understanding, of exactly what the business needs and how the data will be used.  I will focus on the following topics:

1.  The Tale(s) of Wanting Too Much

2.  Business process knowledge necessary for success

3.  SAP detailed knowledge necessary for success

4.  Integration into a successful solution

5.  Educational recommendations.

The Tale(s) of Wanting Too Much

Well, actually two tales that demonstrate two different types of problems created when process leaders (often senior executives) express what they believe they want without really knowing why or understanding all of the costs of what they are asking for. Obviously senior executives cannot have all of the necessary knowledge, however, they still need to understand what is required and to ensure that the organization has people who can resolve the design criteria, or else the organization essentially turns over the design of their future to outside agencies with different objectives and perceptions.  As much as the temptation is to say “We hired consultants to design that”, can it really be reasonable to allow them to make decisions that can dramatically affect not only how the business operates, but how it performs?  All design decisions like this need to be made based upon defining the needs of the business, translating that into business process statements and then evaluating the alternatives based upon the tangible value to the organization, and the costs that will be incurred in design, implementation and operations (with day to day operations being the least understood or analyzed costs during design work, but the ones that will be with you the longest).  If you read this last sentence again, you will start to see the collective amount of knowledge and experience that it takes to design an optimal solution to business issues using any ERP application. 

A valuable, but potentially expensive, characteristic of SAP is that in many (perhaps most) cases, SAP is capable of providing levels of detail/control/flexibility that are well beyond the levels that provide real business value, particularly when compared with the costs associated with using the design once implemented.  This is not a bad thing since it provides that level of detail for businesses where it may be of critical importance, however, that does not mean that it is appropriate for everyone.  It is easy to be presented an option like the two covered here that seem to address some particular problem/want, but without a discussion of the costs associated with both the design and implementation and the longer term costs of maintaining the level of accuracy the design requires.  Let’s look at these two Tales. 

The first tale involves an example in Product Costing (CO-PC), when designing the ways in which costs are assigned to individual Production Orders (could also be PM Work Orders, Internal Orders, PS Orders, etc.).  In this case, a client became enamored with the ability to assign costs directly to production orders and instead of determining which costs varied significantly from order to order, decided that “all” costs would be captured discretely.  While it is more typical to take costs that act more like overhead and assign them either as a set cost, or as a factor of time spent, in this case, the decision was made to have transactions that put “true” costs into the system, this despite the fact that the products were generally priced based upon market competition and not based upon margin on top of total costs.  All of what I just described (albeit briefly) is a perfectly legitimate way to do things, however, this client failed to recognize the cost of maintaining master data to the degree of accuracy that would be required for this approach to be effective.  In fact, they failed to put in place the management systems that it would take to get this data collected accurately.  A simple example is labor rates that were dependent upon the actual labor assigned to the task, rather than an average labor rate that would reflect the overall workforce average.  To add difficulty, they then set departmental objectives to “recover” all of the costs of running the departments as a zero sum game, but did not put in place the management practices that would ensure that the transactions were done accurately.  Since operators would often work on more than one job at a time, this led to costs being over-recovered, which made the apparent costs of the product higher than they actually were and the system was eventually abandoned, not because technically it did not or could not have worked, but because the management team should have been led through the design process to understand the total true costs.  This oversight contributed to reduced sales due to incorrect pricing decisions being made based upon “actual” costs.  This is a case of senior leadership not fully understanding the real effect of their decisions and, in my opinion, the failure of the consulting organization to effectively lead the client through this design discussion.  There was no effective governance process in place to ensure that this discussion happened and the results created a situation that ended up being a very expensive lesson. 

The second tale involves using a Purchasing organization design to solve a management issue.  In this case, the client was in financial difficulty and replacing their ERP system with SAP in order to deal with some issues with the existing system that were a major contributor to their situation.  One of the issues they faced was that they had more than 100 geographically dispersed locations where business was conducted.  Each of these branches only had a handful of workers who interacted directly with their clients on the client site, with a thin layer of administrative support at the local office.  Management controls over business practices were inadequate and consistency was very poor, resulting in lack of an effective audit trail on the use of local funds.  For the most part, this was very likely because of poor record-keeping, rather than actual misappropriation of funds or illicit spending patterns, but it was impossible to tell and local costs were an important issue to the credibility of the turn-around.  During the design stages, this issue was brought up to the consulting team who were leading the design of the SAP system.  The consulting recommendation was that due to the poor span of control over the remote locations, the organization should implement a central purchasing organization, where control could be overseen by a few well trained corporate employees, and that a local petty cash process be used to manage small local expenses like parking fees, lunch with clients and the like.  Executive leadership, however, decided to go to a strict local purchasing organization, no local discretionary spending (no petty cash drawer), and a strict three way match, which required a purchase order for even a parking fee, a receiver for every expense and a match with an invoice.  It should be noted here that this is all part of the value of SAP for many situations, however, in this case it was more like using a mortar to kill a fly.  Training, other than “how to” slide decks, was never conducted and, more importantly, no change in management oversight occurred, which would have created the expectation that behavior would change.  Any discrepancies between PO, Receiver and Invoice had to be resolved manually, however, local offices were not trained how to or required to do this.  Over the first two months of operation, the entire revenue side of the implementation behaved beyond expectations and all seemed to be going well, however, upon returning from Holidays, there was a two month backlog of bills that had not been paid, drivers not compensated, clients and suppliers not reimbursed for their invoices.  This had created a crisis that threatened the survivability of the company, even though significant progress had been made on their financial viability and the company operates successfully today, years later.  It did, however, require a reimplementation (of a central purchasing organization), redesign of local spending rules, further training of the workforce, and improvement in management oversight.  With proper guidance, consideration and evaluation of the difficulties that could be associated with the design of the procurement process this could have been easily avoided.  There are simply times that what is possible to do, is not what you should really use the system to do.  Better knowledge of SAP, of business process and of management oversight could have avoided this situation.   

Business process knowledge necessary for success

So what is the bottom line here?  SAP (and any other ERP application) will nearly always allow you to do things at a much lower level of detail than you should ever want to do as a business leader.  Leading businesses is not just the case of “if some is good, more is better”.  It is necessary for business leaders to find the right, trusted advisors to help them decide how they need to operate their business, what controls or information are important to support decision making, and then to design a program that provides the lowest necessary level of detail, with the corresponding least cost in actual dollars, but also includes the costs of work processes and managing cultural change.  There is nothing more difficult to implement than something that virtually everyone in the business but the business leaders knows makes no sense, won’t accomplish what he/she thinks is intended, and ultimately will fall into disuse (best case scenario) or result in some real failure.  It would be easy here to think that my comments are just another “blame the executive” comment, but they are not.  My comment is to point to the need for an increased level of knowledge about cross-departmental capability than currently exists in most organizations.  The business leaders need to understand that they should put the design into the hands of their workers who are best prepared to design an optimal business process, and they need to have thought through this need and arranged for their experts to acquire the education necessary to do this.  The IT business leader needs to have designed his/her department to include business analysts who are capable of providing good business process advice to the business teams (this includes the consultants).  In other words, business results are usually a product of the amount of preparation that the teams have done both before implementation and after, and business leaders, having assured this level of knowledge, need to listen to the advice of the teams. 

SAP detailed knowledge necessary for success

While detailed knowledge of SAP is necessary to help in the evaluation of design decisions, this doesn’t have to translate into complex designs that don’t meet the needs.  Often it is of critical importance that design team members, in addition to their functional assignment, have cross-functional knowledge of the overall business process.  This can be learned through business process education like TERP 10, which provides knowledge of supported business processes in SAP.  Having the detailed knowledge of what SAP is capable of producing, however, doesn’t mean that it makes business sense to use it wantonly.  Ultimately it is the responsibility of the business members of the design team to produce a process that supports the legitimate needs of the organization.  When a team is saddled with an edict from above intended to provide a technical answer to a management and leadership problem, the team must push back to get a process that meets the needs but doesn’t ultimately produce failure.  Senior leadership confidence in the individuals they have given this responsibility to is critical and often is dependent upon the level of education in the ERP product their advisors have achieved.

Integration into a successful solution

Now, we have the technical ability to define the capability of SAP (sizzle off the steak), and we have the business knowledge to understand the levels of detail and control that are necessary to produce optimal results.  These premises should be clearly defined and recorded because later in the program the implementation team will have produced a demo of the proposed solution, and it is easy to forget the original design criteria and why certain decisions were made.  This doesn’t mean that it can’t change as glitzy things are designed and demonstrated, but the same criteria needs to be employed to evaluate whether the expanded functionality or use methods really meet legitimate needs of the business or are just fun to have, and will eventually add cost without real benefit.  Again, this is the role of a combination of business team preparation combined with a technical team’s understanding of the potential of the solutions.  Finally, it is dependent upon thorough and supported governance leaders who have ensured that the initial scope documents have been thoroughly vetted and that any significant alterations are thoroughly evaluated on a “total cost of ownership” basis.  This should be recorded and managed through the Change Order process (part of governance). 

Educational recommendations

I have covered a lot of ground.  Let’s look at the skill sets required in total for the design team to avoid the problem of asking for more than the business should want.  Clearly there is a need for certification level knowledge in the consulting resources being used for the design.  While I would be foolish to insist that every consultant on the team be certified in the current versions of SAP, I will say that for every instance where this is not the case, it is the responsibility of the client to ensure that the consultant does have the level of knowledge and experience to properly fulfill this function on the design team.  In addition, there is a need for the entire team (consultant and client alike) to know how cross-functional business processes set up in SAP (knowledege gained through TERP 10 Boot Camp), and there is also a need for business executives to have included courses in IT Applications and SAP (if that is the package) in their business education.  This can be formal or informal, e-learning or face-to-face, but basic comprehension of how this works is becoming more and more a critical component of executive understanding.  Universities are including SAP (or ERP) courses in their programs (under and post graduate) in MIS and Business programs.  This trend must continue until knowledge of how to properly use IT Applications to produce improved business results is the rule and not the exception.  Many more programs like those at Central Michigan University, as well as Victoria University in Australia, and the new SAP Masters pilot running in Germany must be developed and available.