Organizational Change Management is a Two-Way Street

Organizational Change Management is a Two-Way Street

In recent postings, I have talked about the analytical elements of preparing for, organizing and directing the design, implementation and management of an ERP environment (specifically SAP).  I talked about the need to analyze and design approaches to:

Business processes

Cultural issues

IT applications strategy, and

Workforce Education Programs

Additionally, I talked about a governance process broad and robust enough to deal with on-going transformation in all areas requiring evaluation, design, and implementation. 

The key issue in all of this is: without positive change to the business, the reasons for the transition are unclear and willingness to adopt the changes extremely uncertain.  The key message of this article is that this applies not only to workers where most Organizational Change Management (OCM) activities have focused, but also to executives who enter into the program with perceptions of what is involved but without personal knowledge of process changes that directly affect them.  We have treated change as affecting workers, but the truth is that more dramatic and consequential change starts at the executive level, and this only becomes visible during the design of new functionality.  This article will explore this phenomenon and discuss how to manage the political process associated with these changes, while maintaining support of the leadership organization.

Many participants have differing views of what organizational change management is, how you plan and prepare to manage it, who should be responsible for it, whether it is hard or even possible.  I have mentioned the adage that “You cannot change business results without changing business processes” in several of these articles.  It stands to reason, therefore, that if you are seeking improved business results, you must change business processes.  Along the way there are a series of decision points that are both on the “critical path” and that require choices, both at the project and the executive level.  In order to effectively manage change in this environment, there must be a concerted effort that goes into:

1.  Identifying areas of intended change, up and down the organization

2.  Understanding the components of the organization that will have to change 

3.  Choice of tools that will have to be created/deployed to manage these changes

4.  Defining the educational needs that will provide skill sets to optimize results

Identifying areas of intended change, up and down the organization  

This is the crux of the issue.  Any time you are engaged in designing, implementing, or managing in an ERP environment (and specifically SAP because of its breadth) there are a series of design choices.  These choices result in changed business processes.  The changes go both ways – down to workers, and up to executives.  While enormous effort has gone into developing tools to manage change processes in the workforce, causes of failures often occur at executive levels, not because senior executives don’t care, but because the explanation of the changes to the leadership process that will result is not addressed or managed effectively.  Also, the career paths and areas of expertise of senior executives have not necessarily included sufficient exposure to the systems and processes they will now have to employ.  Time spent working with these executives, to redefine how they will manage their departments can avoid many issues, and turn resistance into support.  It will also determine when a level of resistance that will require convening several executives to work out an acceptable solution occurs (better to know that up front, when there is still time to remain on the critical path).  This process, however, has to be addressed by an appropriate part of the program governance design.  There is an important book on this subject, now 20 years old, by Chris Argyris, “Overcoming Organizational Defenses” (Chris Argyris, Prentice Hall, 1990), not an easy read, but extremely insightful. 

A few years after I started into the SAP consulting business, I was teaching the SAP course WB 100 at an SAP academy.  This was the first hands-on introductory course, a replacement for the Screen-Cam laced SAP 10, and predecessor to SAP 01.  At the start of the course, I asked the students how they were managing “re-engineering” business processes, and here is roughly the discussion that ensued: 

Class (actually a group from one company): “We aren’t!  Our management has decided that we are just going to implement SAP but we aren’t going to re-engineer our processes”. 

Instructor:  “Then, why do you think your organization is going to spend all of this money to get SAP implemented?”.

Class Group:  “Well, there are a lot of things that don’t work very well, and SAP is going to fix them.”

Instructor:  “How do you think that is going to happen?  What do you think is going to change so that these things get resolved?”

Class Group:  “Well, SAP will provide us business processes that straighten all of these things out.”

Instructor:  “You will find out that in SAP, organizational design, master data records design, design of transactions, and in many more areas, decisions will be made by the implementation team.  How will these be made if not by you?”

Class Group:  “That’s what the consultants are there for.”

Instructor:  “Are you really willing to turn all of these decisions over to consultants who have no knowledge of your business and will not be saddled with the results?”  

Class Group:   “No, of course we will not just turn it over to them.  We will have to make those decisions as a team as the functionality is designed.”

Instructor:  “Please tell me again that you are not going to “re-engineer” the business.”

Unfortunately, this is a true story (nearly word for word).  We have learned a lot about these systems over the years; however, various versions of this still occur today way too frequently.  Program leaders, with experience and knowledge, can generally find the quality of consultants needed to execute configurations, can find teams of people who know the business well enough to make informed decisions on options, and can design, implement and test the solutions.  What we continue to not do well is to gather all of the change implications of these actions and execute plans to get the changed organization implemented (re-engineered) — and this is really what it is all about, where the rubber hits the road. 

Components of the organization that will have to change 

It is standard to include an Organizational Change Management function within the SAP project team.  This is the person or group whose responsibility it is to work with the design teams, collect changes that will occur in the way the business processes operate; translate that into changes in job roles and assignments, assess the skills that will be needed by workers, and develop training and communications tools to be used to deliver information about the new processes to affected workers.  Better constructed programs will also include various “focus groups” to present proposed changes and get input and concerns back from group members that can then either be fed back to design teams or can be used to develop the materials used to promote acceptance of the program as implementation nears.  This is all good, all necessary, and thankfully we have recognized the need for all of these tools to help promote and manage organizational change.  I like the term “Expectations Management” to describe the end goal in this process, as creating the sense of need for doing this work is really all about defining and selling “expectations” that the affected community should embrace.  This starts when the program is announced and continues well past the implementation date to be effective. 

There is, however, another group of stakeholders who frequently get ignored in the OCM process.  It is much easier to sell a program down into the organization, than it is to sell it up the management chain into top executive ranks and this also requires a different set of skills, tools and focus to manage properly.  No matter how well an organization defines its scope before committing to an implementation program, there will always be discoveries during design that will cause either the scope to change or will cause a different, and hopefully equivalent (both in complexity and cost) process to be adopted.  These changes are part of an overall project management toolset that has to be defined and executed, and any changes that result in significant differences, either in cost or performance, need to be fully documented and approved at the Executive Steering Committee.  Again, this is a common component of any implementation program.

Beyond that, however, there are changes necessitated by new software logic that result in changes to the way executives of the client company have to operate.  These are numerous and result in decisions requiring changes at the executive level on what reports they will be able to see, how metrics may be rolled up, or may even have significant impact on how the enterprise is organized.  In a typical project, resolution of these issues is left to departmental representatives on the project team even though these team members may not have easy access to their top leaders or feel comfortable discussing issues at this level.  The crux of the issue, however, occurs when options at the top result in the necessity to change the way in which the organization is led and operates.  This can result in the need to change executive objectives (and therefore down the organization also) that compensation programs are built around.  This is not typically a subject that lower ranking subordinates can initiate or participate in, so another governance approach is necessary.  In my opinion, more projects fail for these upward looking OCM issues not being resolved than the inability to get the lower levels of the organization to accept new work processes.  This was not always the case, but today, I believe it is more prevalent.

Tools that have to be created/deployed to manage these changes

So, what are the tools that are needed to address these issues?  As indicated, tools and programs are available to address the issues of collecting current work processes, new work processes, analysis of change required and communications/training programs to prepare and support the workforce.  What is not addressed effectively is OCM at the executive level(s).  When you are in the Realization phase of an SAP project, when the scope has been clearly defined (in Blueprint, and hopefully, in Project Preparation), the unanticipated choices or options for higher level organizational issues become more clear, along with rationale for the necessity of changes.  When left to lower level team leaders, this results in discussion within functional silos.  Left to project managers this occurs at ESC meetings and may result in arguments or deferred decisions, primarily because the issues that are raised go too deep into the political structure of the organization to be resolved in open session (read blog article on Staffing for the General).  So, it is necessary to create a small empowered function that is tasked with managing OCM upward to get resolution of critical path decisions.  This function is created by the assignment of responsibilities and generally should not add costs to the program, unless the program is understaffed from the start. 

There are many good examples of this to study.  A couple examples are:

Inventory Control – Take the development of a common inventory control system that incorporates both positive purchase price variance objectives of the Procurement function with raw material inventory management objectives of the manufacturing function.  Since these two executives may be compensated upon performance against competing targets, resolution will require changing organizational responsibilities and objectives.  It will require changing the target metric to total cost of inventory, which includes purchase price variance and costs associated with working capital for inventory.

Management Accounting – Another example is when an organization has grown through acquisition and is now being consolidated under one system.  One of the divisions is organized functionally, where departmental cost budgets are the primary management tools used for evaluation and reporting.  Additionally the Sales department is judged upon revenue created.  In this system, the only place that profit is reported and managed is at division staff level, which is a shared responsibility among the staff officers.  The second division is organized in market segments, where leaders are evaluated based upon gross profit (revenue less costs), and the primary management tool is either profit center reporting, or segment profitability.  The project team, in consultation with the CFO, will determine which of the financial approaches are preferred and the new approach will be agreed upon.  Regardless of what the decision is, the results will require significant change in the approach, and management structure of some executives.  While this may seem obvious, the process of talking with senior executives to figure out how to change management tools and to identify reports and analytics they will need to see is often ignored.  If the senior executives responsible for a functional or business area are not comfortable with this process, they find it difficult to send positive messages to their organizations.  This, left unaddressed can lead to anything from mild pain and confusion to total resistance.  The Program Office in the three-tiered governance process is the tool specifically designed to deal with these issues.  Upward focus on OCM is a critical component of successful implementation.  It does not happen by accident.

Educational requirements to provide skill sets to optimize results

Now, let’s think for a couple of minutes about the knowledge that is necessary within a project team to get these issues resolved.  Certainly cross-functional process knowledge throughout the team is critical to ensure that the design options that are constructed represent a process that will optimally support the entire organization.  This can be achieved by delivering TERP 10 training to all of, or the leadership of, the project team during Project Preparation.  Next, you need to ensure that you have a support team (consultants for the most part) who are absolute experts in the many options of how to configure the system to achieve business results.  I know that there is a lot of discussion around whether or not certification should be required, but it is clear that certification will typically result in the designer having been exposed to more and broader depth in the development of options to resolve issues.   In simple designs this probably doesn’t matter, but when you are involved in complex designs that affect how the overall enterprise will operate and will potentially require rewriting executive compensation programs, you better have all of the knowledge available to ensure that you can meet the needs, and certification is part of that knowledge base. 

Lastly, all of this is about operating the business, not about simple IT supported transactional processes.  Just as we send leaders to educational opportunities from seminars to MBA programs, we need to ensure that these individual development programs include business education around how ERP functionality can be used to support business changes and how that can lead to a Return on Investment for companies.  This can include seminars built around a particular company’s functionality, basic elective courses (under or post-graduate), which exist in many Universities in SAP’s University Alliance Program, or can include an SAP Concentration in an MBA curriculum.  There are very few of these programs that exist today, but they can be found at Central Michigan University, the University of Scranton, Victoria University (Australia) and the new Master’s program pilot in Germany.  Each of these programs is quite different, but all address this issue specifically.  The development of more of these is critical to the ultimate goal of developing a workforce which has the understanding of how to deploy and manage a SAP environment to produce the potential business benefits.  This doesn’t stop at go-live; it is a career-long journey to achieve the true potential of your business.