Over time, successful companies grow organically and inorganically. Typically, organic growth brings a steady rise in business volume and increased depth to operations, while most business processes remain fairly unchanged. A rise in volume, however, can create significant challenges for the productivity and performance of the existing business processes, making them too inefficient to handle higher volume. On the other hand, increased depth of operations requires companies to adopt different ways of doing business. For example, a company trying to expand its customer base may have to significantly change its warehousing and distribution strategies. In addition, the customer may demand considerable freight cost optimization to control its supply chain costs. In this example, the existing process of source determination may prove to be inflexible, or less optimized.

Now think about inorganic growth. Typically, inorganic growth is driven by mergers, acquisitions, or other strategic initiatives. This brings additional variety and thus complexity to operations. For example, during an acquisition, it’s likely that the accounting structures of the acquiring and acquired companies are different. This may pose a significant challenge to the integration of the financial processes, and thus on the productivity of the financial processes.

Both organic and inorganic growth demand robust systemic business processes to manage scale, size, and complexity of operations. ERP solutions offer the capability to integrate processes. For companies that already have an ERP footprint that proves to be inadequate, the only option left is to completely revamp the current business processes and supporting ERP applications. Such a strategic exercise is an initiative called ERP-enabled business transformation. This type of program aims to match a company’s initiatives with its business strategies.

Key differentiators between ERP-enabled business transformation programs and conventional ERP programs are:

• Long-term benefits: Business transformation programs are more strategic in nature than conventional ERP implementations. A business transformation program is forward looking, and is designed to support long-term growth, including planned volume growth, future business plans, planned technology strategy, and planned financial growth.
• Value: Conventional implementations tend to either map what is there in the standard application or in the existing legacy system. However, business transformation programs focus mainly on the value. A special effort is made to automate a significant number of business processes to eliminate redundancy, automate non-value-added activities, and remove skill dependency. 
• Standardization: Due to the large scope and size of the change, focusing on standardization is quite important. The concept of a global template is critical when designing and implementing the business processes. A global template is a synergized approach for processes, systems, and data. For more details on this topic, refer to my GRC Expert article “A Checklist for Developing Your Global Template.”
• Change management: Change management is a significant challenge during business transformation programs as compared to conventional ERP implementations because, due to a higher number of business processes and multiple integration points, there is a greater possibility of missing requirements.

I’ve discussed how organic and inorganic growth can act as triggers. Now let’s turn to how business process obsolescence and technology obsolescence can be the key reasons for organizations to use an ERP-enabled business transformation program.

Business Process Obsolescence

Business process obsolescence is an insufficiency of a business process to support volume growth and process complexity. Internal factors such as volume growth and higher productivity expectations can make business processes obsolete. For example, as volume grows, a manual order acquisition process becomes obsolete and needs to be replaced by a more productive process, such as order acquisition through Electronic Data Interchange (EDI). Additionally, external factors such as mergers and acquisitions, changes to taxation, legal requirements, or outsourcing can bring about process obsolescence. The cost of business process obsolescence is typically an opportunity cost incurred due to low productivity or loss of sales.

Technology Obsolescence

Technology obsolescence is an obsolescence or redundancy that arises with the evolution of newer technology or better products to manage enterprise-wide processes. High-growth companies with old ERP footprints may find themselves uncompetitive or unproductive as they won’t be able to adapt to the offerings made by new technology. For example, companies running on mainframe-based ERP systems may find themselves less competitive compared to companies running on the latest integrated ERP systems because they struggle to adapt to newer technologies due to a lack of integration. Continuation of old technology may result in lesser productivity, higher response time to customers, or higher cost of operations.

Apart from being less competitive, old ERP footprints may attract a high cost of maintenance due to non-availability of resources, including people with the required technology skills and hardware. Also, old technologies are often not that robust and have serious integration limitations. Technology obsolescence applies to the infrastructure supporting the old ERP footprints as well. With growth, business volume eventually surpasses the infrastructure assumptions made during the setup of old applications, reinforcing the demand to upgrade the infrastructure.

Having understood why ERP-enabled business transformation programs are needed, and the key factors that drive them, it’s important to understand what makes an ERP-enabled business transformation program successful.

Foundation of ERP-Enabled Business Transformation Programs

The foundation of an ERP-enabled business transformation program has four pillars:

1. Scope and change management
2. Business process blueprinting, design, and implementation
3. Program management
4. Value management

I’ll look into these in more detail next.

1. Scope and Change Management

Scope creep is a top reason for program failure. The term scope is typically used in the context of coverage of geographies, systems, and business processes. Impact of scope creep in the context for geographies or markets can be evident; however, it may be latent in the context of applications, systems, or business processes. For example, after the blueprint decision, retiring an additional old application may significantly affect interface designs, business process integration, training, data migration, and other cutover activities.

Similarly, scope creep in the context of business processes can be a silent killer. It can cause serious cost overruns to implement the changes once the design is finalized. The scope creep risk increases during user acceptance testing (UAT), when a potential solution is exposed to business users for the first time. During UAT, users typically bring up several suggestions for how the solution can be improved. While it’s natural that users would like to maximize benefits, it’s important for the implementation team to weigh the risks and benefits of a change before deciding to implement it. Scope creep typically results in cost overruns, delays to program schedules, and degradation of solution quality, as new additions may have an undesired impact on the originally built solution. The risk to the solution quality grows during the advanced stages of testing and beyond. For example, identifying and fixing a change after UAT can be a significant risk because it may completely invalidate the non-negative testing that was done before.

Now that I’ve described the risks and their impact, it’s important to know what can be done to prevent scope creep, and yet deliver the intended value to the users. An answer lies with the change management process.

Change is any trigger that may affect the scope. Change management is a process of managing the change introduced in the originally defined scope of the program. Scope is applicable to several dimensions of the program, including resources, business processes, system landscape, and data. It defines the structured approach for dealing with changes throughout the life cycle of the program and sets important guidelines regarding scope inclusion and exclusions. Typically, the change management team consists of:

• Project managers — to qualify the impact on cost and timelines
• Technical experts — to quantity the risks and benefits
• Business representatives — to suggest any change proposals and then make joint calls with others to accept or reject a change after weighing its risks and benefits

To further explain, let’s look at an example. The original solution scope defines the system to generate the print copies of the delivery note that is manually picked up by the transporters and submitted to the ship-to party. The implementation team then builds the solution considering the above requirements. During UAT, the business team learns that the specific ship-to customer can now accept EDI transmission. A business representative approaches the project team to implement the EDI solution to send delivery notes instead of printing the delivery notes, as this change increases business productivity and reduces cost. If the process of change management is correctly implemented, then technical leaders from the implementation teams direct the business representative to give the request to the change management team. The change management team asks the business representative to:

• Quantify the benefits
• Address any potential legal implications of not implementing a change. This includes considering effects to external reporting, such as a balance sheet, or whether the change may violate a governmental regulation.
• Determine the impact on training
• Communicate any other concerns

The change management team also asks the implementation team to evaluate the:

• Change effort
• Cost implication
• Timeline impact
• Regression impact on the existing solution

Based on these inputs, a decision is made by the change management team to accept or reject the proposal. The change management team’s decision is final and can only be revoked by a steering committee.

2. Business Process Blueprinting, Design, and Implementation

Business process design and implementation is the process that converts the business requirements into the desired solution, and the implementation and use of that solution delivers value.

In the context of a business transformation program, the business process design begins with the validation of the business case and understanding the value levers. A value lever is typically a high-level approach or initiative that yields significant benefits. These value levers are then mapped back to operational levers, and are converted into a specific value proposal. For example, reducing the cost of system maintenance can be a value lever. This is then is mapped back to an operational lever, such as retiring an old application. This is in turn mapped back to specific value proposals, such as retiring system A and migrating the process into the new SAP system.

Once value proposals are studied in detail, the implementation team moves on to the five stages of solution design and implementation:

1. Business process blueprinting: Business process blueprinting consists of two subcomponents: as-is process mapping and to-be process design. In business transformation programs, as-is process mapping can be challenging because in most cases the existing process footprints are old and business teams can’t make necessary documentation readily available. Also, with a merger or acquisition, the team needs to evaluate business processes for both companies together. A to-be process design focus involves redesigning the business process in line with the value proposal. To-be processes are signed off by concerned business representatives and implementation teams jointly. All as-is and to-be processes are captured and stored for future reference. Signed-off to-be documents are typically useful for controlling scope creep, and are often referred to by the change management team. Typical blueprinting risks during business transformation programs include inadequate representation for a certain process or business segment, inadequate common understanding of an end-to-end business process (as the process may be long and with multiple owners), and insufficient capturing of the detailed requirements. All the risks can be mitigated with careful planning and use of proven blueprint templates to capture requirements.
2. Building the solution: Building the solution consists of nailing down functional and technical specifications, developing the solution, and unit-testing the solution. In the business transformation program, it’s important to do the developments right the first time, as the cost of the rework could be significant. Due to the scale and size of the business transformation program, the number of developments is also significant. Thus, it is important to focus on low-level standardization initiatives such as compliance with coding standards or performance standards. During UAT, realizing that the solution does not work at a higher intended volume can cause serious delays to the project timelines and may cause a cost overrun. A strong project plan, with monitoring and control mechanisms in place, is required to deliver this scale of developments. Some typical risks that arise while building the solution include adopting non-standardized coding practices, trying to build highly complex solutions, and prioritizing developments incorrectly. These risks can be mitigated with careful planning, and use of appropriate standards and design principles.
3. Integration testing: Typically, integration testing is done to validate the integration between two sets of functionalities or two separate systems. In the context of business transformation programs, integration testing is like putting together a jigsaw puzzle. It is more challenging in programs in which old systems are retired and their functionalities are moved to a new system, acquisition scenarios where systems from two different entities are tied together, or when a completely new solution (such as EDI) is set up. For example, interfaces between two systems are validated the first time during integration testing. For business transformation programs, integration testing is crucial for two reasons. First, business transformation programs handle large system landscapes and may expose serious gaps in the solution or overall system landscape, which could affect the project’s timeline. Secondly, it appears as a litmus test for the stakeholders to determine how close the solution is to the end requirements. Too many issues and delays in the resolution of those issues may increase anxiety levels among stakeholders. From an implementation team’s perspective, it’s crucial to determine the testing scope that ensures good testing coverage across all touch points, and good coverage for business processes built in the earlier phase of the project.
4. UAT: After successful integration testing, the system is handed over to the actual key users to perform UAT. Considering the scope of the business transformation programs, this phase is possibly the biggest challenge in the life cycle of the program. In this phase, business users validate the solution and process. This phase is also vulnerable to scope creep and thus emphasizing change management is crucial. As the business transformation program brings significant change to the system, the success of UAT is often driven ensuring the key stakeholders are involved and integration points are tested adequately. From a solution delivery perspective, major mismatches between the expected and actual results may derail the entire program if not handled appropriately. It’s important to identify the gaps in the solution that need to be taken up as a work process, rather than further complicating the solution or introducing untimely changes. The inputs from UAT go into training documentation. Typically, end-user training starts toward the end of this phase. During this phase, several other activities such as user setup and governance mechanism setup are performed.

5. Cutover: Cutover is a transition or actual migration from the old solution to the newer one. While back-up plans are prepared to avoid any catastrophe, from a business transformation program standpoint, it’s almost a point of no return at this point, as the stakes are so high. This phase involves close coordination with various stakeholders from the business and business partners. The implementation team prepares a detailed cutover plan with clear owners and challenging timelines. While some contingencies are added from a plan perspective, realistically there is not much room for the delays in cutover activities. The cutover process and plan need to be right the first time. For business transformation programs, approximately two-thirds of trial cutovers are done to ensure the readiness of the cutover strategy, cutover tools, data, and system at a point in time for cutover. Cutover generally includes running some controlled sample end-to-end cycles that most frequently occur or are the most complex. This trial cutover testing gives the implementation team the opportunity to make any needed corrective actions. Lack of communication, lack of involvement of the stakeholders, and an inadequately detailed plan are the biggest risks for the business transformation program.

3. Program Management

Due to higher complexity of the business transformation programs, the program management team needs managers with very strong program management skills and with the skills to influence solution definition. As mentioned above, during the change management process it is critical to make the right call after understanding the change impact and the business value together. Inability to weigh both these factors may cause a significant undesired impact to the project in terms of quality or cost. Like in any other conventional program, the team is responsible for budgeting and controlling cost, staffing, defining KPIs and monitoring status, risk planning, and organization structure setup.

4. Value Management

The whole premise for the business transformation program is based on value. Generally, value is defined in monetary terms and cost savings are expected out of the value proposal. The value management process identifies, analyzes, and ensures sustainability of the value from a business transformation program. The business case typically lists all the major value levers at a high level. During analysis, each value lever is broken down into a value proposal and then is weighed against the cost of change.

Consider an example in which a business case mentions one of the value levers, such as reducing the cost of maintenance on the existing systems. The value management team drills down on this value lever further to the value proposal and identifies the cost of the maintenance for systems with higher costs. The value proposal is then made to replace some of those systems, and the net cost savings are calculated. The value management team also works on the value proposals at the business process level. Typical value proposals include:

• Automating and optimizing specific business processes
• Eliminating processes
• Increasing EDI enablement with the business partners
• Real-time booking of inventory movements and accounting

Post-implementation review of the value proposals ensures that the cost advantages listed in the business case are considered. The success of the ERP-enabled business transformation starts with organizations defining a strong business case with a detailed value proposition, and is delivered with excellence by adopting best-in-class practices for program, change, and value management. 

Sameer Page

Sameer Page has more than 15 years of experience in supply chain management and information technology, with more than ten years in SAP program management and SAP consultancy. He has extensive knowledge of the tools and methodologies associated with a global template program, with vast experience across multiple industry verticals and geographies. His major strengths are in program management. He has proven analytical, organizational, and problem-solving skills that are complemented by the ability to communicate effectively with diverse teams and key stakeholders.

If you have any comments about this article or SAP Professional Journal, or want to submit an idea for an article, contact the SAP Professional Journal editor Scott Priest.

You may contact the author at sameerpage@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.