Every year companies invest millions of dollars on SAP implementation, transformation, and support projects to improve their business processes and maximize their revenue and profits. For each such SAP project, the project manager’s objective is to lay out the most effective or efficient plan covering the project’s life cycle — from the initiation phase through a successful go-live. While each phase (e.g., pre-explore, explore, planning, development, and deployment) of a project requires close monitoring, the preparation for the go-live weekend demands the highest attention as the success or failure of the go-live directly affects the success or failure of the project.

I explain a methodology you can adopt for a successful go-live, based on my own experience working for various projects with a global SAP client. I won’t discuss deployment planning, which is a large topic; instead, I focus on a methodology using the Technical Implementation Gantt (TIG) as a tool. I also address areas such as:

• How to group activities based on their relevancy and dependency
• How to execute and track the activities leading to go-live on the TIG
• How control points on the TIG make it efficient and easy to reuse it for each phase of the project until go-live
• How the TIG may help avoid major pitfalls in the whole process
• How you can perform a slow start, a significant process by which it is confirmed that the system is operational before it is opened up to the larger user community

It is essential to identify all activities that are important for cutover, but what really makes a difference to the project is how extensively you identify these activities and how well you organize them for execution. The TIG proves to be a tremendous help in achieving these objectives.

Build the TIG

A typical deployment plan is used to track deliverables such as organization readiness plan; end user training plan; deployment communications; implementation tasks; tasks, resources, and metrics for stabilization and post-go-live sustenance; and end-of-life plan for implemented products. The TIG essentially focuses on the implementation tasks, so it is part of deployment planning. Define a proper structure for capturing various activities on the TIG to ensure effective use and smooth flow of execution of the TIG. For any go-live the most important implementation activities are to release configuration and code changes to the production system, convert the master and transactional data into production, and conduct post-go-live maintenance and validation activities. On the TIG, capture these implementation activities and practice them in development, quality, and performance testing systems before deploying them in the production system.

Figure 1 shows an example of high-level TIG structure.

Figure 1

High-level TIG structure

Conversions are run as pre-cutover and cutover conversions. Split the code release also into pre-cutover code release and cutover code release in line with your conversions. Bundle code and configuration required for pre-cutover conversions into one package and release it into production just before pre-cutover conversions. Similarly, bundle the code and configuration changes into another package and release it into production just before cutover weekend.

I explain how we structured these activities in multiple projects and the strategy we used to build the TIG and reap its benefits. Figure 2 shows some of the sections listed in Figure 1 along the timeline. Monday is represented by a 1, Saturday by a 6, and Sunday by a 0.

Figure 2

Milestones across timeline

Stakeholder Communications

This section captures all the important communications to the internal and external stakeholders of the project, including:

• Communication on freezing master data creation such as materials and bills of material (BOM)
• Freeze on transactional data creation such as purchase orders, sales orders, and scheduling agreements
• Freeze on inventory movements
• Cutoff of manual and Web invoicing
• Communication to suppliers or third-party logistics partners about deployment plans

Keep this as a separate section to easily access and track the status. A sample is shown in Figure 3.

Figure 3

Sample stakeholder communication section

Code release activities should be grouped under the following sections.

1. Pre-Cutover Code Release Preparation

The pre-cutover release preparation involves activities such as completing Solution Manager project documentation, including configuration guides, functional specifications, technical design documents, test plan, conversion scorecard, and back-out plan. You must ensure that all corrections are in the correct status. You also need to make system access requests for the analysts, developers, and conversion analysts. Another important activity is to set the system to modifiable status to allow system analysts to make manual configuration changes.

Release management preparation is also part of the pre-cutover code release preparation. In this phase all required approvals by platform integration managers are done and recorded along with all required documentation.

Preparation activities also include pre-staging of data and reporting applications such as SAP NetWeaver Business Warehouse (BW) or Enterprise Data Warehouse (EDW). An example screen in shown in Figure 4.

Figure 4

Pre-cutover code release preparation activities

2. Pre-Cutover Code Release and Check Out

This code release includes all the code and configuration required for pre-cutover conversions. This release could include both SAP and non-SAP code (for example, it includes custom conversion programs and plant-specific configurations to support conversions). It does not affect daily operations in a production system and hence can be released well in advance into the production system. You set the system to modifiable status for a brief period of time to allow code release, manual builds, and validations. You also maintain various custom table entries during this window. Once you complete all these activities, set the system back to non-modifiable. You can see an example in Figure 5.

Figure 5

Pre-cutover code release and check out

3. Cutover Code Release Preparation

The section repeats all those activities already captured through pre-cutover release preparations. In addition, you need to capture the test summary scorecard as a proof of successful test execution in quality and performance systems. Validation of batch jobs and variant maintenance is also part of this section. You can see an example in Figure 6.

Figure 6

Cutover code release activities

4. Cutover Code Release and Check Out

This code release includes all the code and configuration used to change the actual capabilities in production that affect daily operations. As a result, you complete this task outside of normal business hours. Update of various batch jobs and variants and validation of those changes are covered as part of the release and check out. You can see an example in Figure 7.

Figure 7

Cutover code release and check out

Conversion activities should be grouped under the following sections.

Conversion Preparation

This section captures all the preparatory activities needed for executing conversions. Sample preparatory activities are shown in Figures 8 and 9. Classify all the preparatory activities primarily as master data and transactional data. Further, group these by functional area (e.g., planning, procurement, accounts payable, managed inventory, or finance). The benefit of this grouping is that you can track progress of each functional area separately. Examples of the preparatory activities include vendor master setup, identifying a valid list of materials for conversion by involving various functional areas, performing validation of identified data, maintaining certain custom table entries, and coordinating activities between key contacts from different application areas. Plan these activities starting from eight weeks to go-live. Completion of these activities is a prerequisite for starting pre-cutover conversions. Data cleanup is also a prerequisite for conversions into the target system. You can capture and track all the data cleanup activities in this section.

Figure 8

Conversion preparation: master data

Figure 9

Conversion preparation: transactional data

Pre-Cutover Conversions

This conversion includes master data such as material masters and BOMs. It may also include some transactional data such as scheduling agreement header and line items and assets. Like the pre-cutover code release, this activity does not affect daily operations in the production system. Refer to Figure 10 for pre-cutover task grouping.

Figure 10

Pre-cutover conversion tasks

Cutover Conversions

This section includes all the transactional data that affects daily operations. Cutover conversions must be done outside of normal business hours so business is not disrupted. It includes purchase orders (POs) and inventory. These changes bring the system to a state of operational readiness and prepare you for the next stage: slow start. Figure 11 shows a sample.

Figure 11

Cutover conversion tasks

Slow Start

This section captures the processes that are used to complete critical transactions in production to make sure the systems, applications, and interfaces are working as expected before the broader user base starts normal daily operations.

Production Maintenance and Validation

This section captures all those activities that are critical for resuming business activities (e.g., enabling batch jobs in the new system and removing stock from the old system) in the new system after go-live. If it is a legal entity restructure project, then it is important to clean the data of old legal entities or plants. The activities include deactivating the BOMs, updating the plant material status, deleting the Material Requirements Planning (MRP) areas, locking the production versions, canceling or reducing the requirements on legacy POs, and removing stock from the old legal entity. If SAP SCM is used for planning, then a lot of cleanup activities need to be performed, including clearing demand, cleaning SCM master and transactional data, deleting planned orders, updating Core Interface (CIF) integration models, deleting transportation lanes and quota arrangements, and deleting the planning versions of product at locations.

Approach to Build a TIG

You need to keep four ideas in mind as you build your TIG:

• Include only those tasks in the TIG that are required to deploy the project designs (i.e., different functionalities developed as part of the project based on business requirements) into production
• Use functional area focus group meetings in your project for building the TIG
  • Involve the design system analysts, business leads, and conversion analysts in these meetings
  • Have a project manager and conversion lead facilitate these TIG meetings, as they are the people who primarily manage the TIG until go-live
  • Conduct cross-functional meetings when necessary as there would be dependency of activities across functional areas
• TIG is a living document and needs to be continuously revised all the way through cutover weekend
• Use a phased approach that builds on the lessons learned from each test phase — namely, functional test, systems test, and performance test

Approach to Review a TIG

Keep these four points in mind while reviewing the TIG:

• Build the TIG prior to functional testing with the bare minimum activities and start reviewing it before the beginning of each test phase as required through the cutover weekend based on learning from each phase
• Where needed, have smaller focus group sessions for the updates that require in-depth discussions
• Use a phased approach that focused on the near-term critical path activities
• Normally four weeks are spent for conversions in each environment. Figure 12 represents the conversion practice schedule, Figure 13 represents the development and testing schedule, and Figure 14 represents the deployment activity schedule.

Figure 12

Sample conversion schedule

Figure 13

Sample development and testing schedule

Figure 14

Sample deployment schedule

TIG building is an evolving process through several reviews in each test phase. Let’s now see how to review and build the TIG progressively during the various conversion test schedules along the timeline. Figure 15 shows how the TIG should be improved during the various conversion tests. The work weeks (WWs) shown correlate with the schedule shown above.

Figure 15

Conversion functional test schedule

Because these activities take place during the first round of conversions, the stakeholders to be involved are primarily the conversion team and some limited functional area support. Business involvement is not required at this stage.

Figure 16 shows a conversion quality test schedule.

Figure 16

Conversion quality test schedule

For the review and refinement of the TIG during quality test conversion, support is required from everyone, including members of the business.

Figure 17 shows the conversion performance test schedule.

Figure 17

Conversion performance test schedule

Performance testing is primarily for testing the performance of the code, so only the conversion team needs to be involved, and limited functional area support is needed.

Figure 18 shows the conversion production release schedule.

Figure 18

Conversion production release schedule

Production release and conversion need support from everyone, including all business stakeholders.

Pitfalls the TIG Identifies

I have learned a number of lessons in projects in which I’ve used the TIG review phase and dress rehearsals. These lessons helped my team avoid costly mistakes of schedule overrun, resource overload, and quality issues during production conversions. Here are seven pitfalls we were able to avoid:

• Missing dependencies on TIG created resource overload due to parallel conversion activities. To avoid this pitfall, build the dependency based on not only the sequence of execution but also on the capacity of each resource so that people don’t work on multiple tasks at the same time. Thorough review of TIG is needed to identify this problem.
• Look for opportunities to move around the tasks in the TIG to make sure the tasks are executed at the appropriate time so that the subsequent tasks have the required information available before they are executed in the system. For example, check thoroughly that master data from SAP ERP Central Component (SAP ECC) has been sent through CIF to SAP SCM before executing planning conversion activities in SCM. TIG helps execute the activities in a structured manner.
• Add as many validation checkpoints on the TIG as possible. This action provides better control for handling the complete flow of the data conversions over the cutover weekend. For example, all items and BOMs should be extended to the plants with appropriate cost or value so the downstream conversions do not fail.
• Identify bottlenecks or constraints and refine the execution processes or change the execution strategy. For example, in my project during the dress rehearsal we realized the planning functional area (in our case, we used SAP SCM for planning) was a bottleneck taking 50 percent more time than anticipated. We had to refine planning conversion activities, add more resources, and then start our cutover weekend one day in advance to complete the work on time. Another example is PO text conversion, which is a very time-consuming activity during which the standard SAP function module fails to retrieve all the data at a time. We had to figure out how to improve the performance of the program to run faster, for example, through the change in ABAP code logic and code optimization.
• TIG helps a lot in proper time management. For example, when checkpoint meetings are run during cutover, there is a natural tendency to review tasks belonging to each functional area in every checkpoint meeting. Instead of taking that approach, prioritize only functional areas that have immediate relevancy. This approach ensures effective use of time. For example, limit the finance agenda items to the next day if they don’t start on the first day of cutover.
• Sometimes during the cutover weekend checkpoint meetings, you end up spending a lot of time on status updates of one functional area, while others are waiting for their turn. Instead, start with smaller functional areas, finish with them, and let them go. Then spend enough time with bigger functional areas. The functional areas can share information with each other outside these meetings.
• In our project, during the dress rehearsal we realized that we were overwhelmed with the planning conversion activities and too many details were captured, so the TIG was cluttered. We then moved all the details of planning conversion activities from the TIG into an Excel sheet for the planning team to execute and maintained only the high-level tasks in the TIG for status tracking. We used Excel for task execution and TIG for high-level task tracking.

Best Practices for a Successful Go-Live

Now I’ll look at some best practices for a successful go-live in a number of areas.

Soft Freeze, Hard Freeze, and Catch-Up Conversions

It is practically impossible to stop the required master data changes in the production system for extended time periods for conversion purposes. The best practice is to implement a soft freeze, perform regular master data conversions starting four weeks before go-live, and then implement a hard freeze in the last week before go-live. Between the soft and hard freezes, users can change data in the system, but they need to track them in Excel sheets. After the hard freeze, perform catch-up conversions in the last week before go-live for delta changes that happened in the production system between soft and hard freezes. This methodology ensures that the master data conversions are complete and accurate without constraining the users from creating required master data in production systems. When data conversions completed using this strategy are captured on the TIG for execution, you achieve good control over the master data conversions in preparation for the cutover weekend. Figure 19 shows sample catch-up conversions.

Figure 19

Catch-up conversions

Production Data

Always perform mockups using the extracts from the production system. This action provides the opportunity to identify and fix the discrepancies that exist in production. By the time you go to production, you have very good control over the data conversions, which helps expedite the cutover.

Slow Start

Slow start is one of the best practices to follow during cutover weekend and ensures the system works before opening it up to all users. It also ensures that known workarounds are in place and work as expected. The success of the slow start process serves as an input toward the final go or no-go decision. Identify a few scenarios (five or six process steps) that are business critical and set the goal to accomplish them during the Sunday of the cutover after the conversions are complete.

Always identify simple business scenarios to test slow start instead of stand-alone tasks. Don’t have planning run as part of the slow start as it is an exhaustive activity, and you may not be able to complete it on time. Here is an example of a simple business scenario:

• Create or extend materials (finished material and raw material) to new plants and check if the values are copied correctly from the reference material
• Create a discrete PO for procuring raw materials from two different third-party suppliers
• Create intercompany and intracompany POs between plants
• Create delivery and perform manual goods issue
• Ensure that the goods issues (GI) and goods receipts (GR) are exercised during slow start and create a posting to the GL. You need to plan and reserve some GR and GI transactions from the old system to be tested as part of slow start.
• Create an Evaluated Receipt Settlement (ERS) invoice and validate posting

Backing out data from production due to serious issues found after go-live is a painful activity. Instead, dedicating some time for a slow start and testing basic scenarios benefits everyone in the project. The slow start may not be a foolproof solution for unanticipated issues, but it definitely enables you to catch certain issues early that would otherwise impede the business transactions in the new system.

Dress Rehearsal

Practice the conversion mockup in the QA or performance system as a dress rehearsal. This process provides you with an opportunity to learn from your mistakes in TIG execution. Set up checkpoint meetings similar to the way you would for production conversions. Based on the learning from the dress rehearsal, you may have to put some risk mitigation plans in place for your production conversions. Some of the ground rules for dress rehearsal should be:

• It’s OK to make mistakes — it’s a rehearsal. Learn from those mistakes.
• Communication is the key. When a task is complete, let the next person know and ensure he has received your message. Don’t wait for future checkpoint meetings.
• Time your work and provide actual updates to your conversion lead so that the TIG can be updated continuously
• Attend the checkpoint meetings so that you are aware of schedule changes during the course of execution

Control Points on the TIG

Set control point tasks before each section on the TIG and make those control points as predecessors for each section. For each test phase, change the dates on these control point tasks, and the dates for all dependent tasks are automatically set. This saves a lot of time in setting the dates for all the activities on the TIG for each mockup test. The prerequisite is that every task on the TIG should have a predecessor set. Of course, if you have any constraint set for a task, then you need to manually change the constraint date on the task to make it relevant for that particular test phase. With this approach, you don’t need to build a TIG for each test phase. Rather, you can use the same TIG for every test phase repeatedly and also improvise it progressively based on learning. Figure 20 shows that the start date for each section is governed by the start date of the control point, but the start date for each individual task in each section might vary based on the dependency it has on other tasks.

Figure 20

Control points on the TIG

Task Classification

Classify each task on the TIG based on the functional area. This helps in quickly pulling the tasks belonging to a functional area for review. It is useful for the project manager, conversion lead, or business lead to filter the tasks for their team to follow up. For example, in Figure 21 you can see some of the tasks filtered for procurement across various sections on the TIG. Note the value Y-Proc in the Biz column, specifically identifying all those tasks as procurement team tasks.

Figure 21

Task classification

You can also directly copy these tasks into Excel so that individual teams or users can use this checklist as a reference.

TIG Execution Using Multiple Time Zones

Sometimes the deployment team can be spread across locations for cutover. TIG easily manages deployment across multiple locations. For the convenience of executing such a TIG, I recommend that you maintain multiple time zones on the TIG for all TIG tasks by introducing a custom column and using a formula. In our project, we had deployed the solution for a business unit in Malaysia and the US. Because Malaysia is 15 hours ahead of the US, we started the deployment in Malaysia followed by the US. Figure 22 shows the Start and Finish columns that represent US time zones and the MY Start and MY Finish columns that represent Malaysian time zones. All resources can easily follow the timing on the TIG based on their locations. The formula to be used is ProjDateSub ([Scheduled Start],-900, Task Calendar) for the custom columns. The number in the formula is the number of minutes.

Figure 22

Multiple time zones on the TIG

Financial Constraint Calendar

It is important to integrate the financial constraint calendar into the TIG. The financial constraint calendar tells when the system is locked for code changes or conversions to facilitate the finance month- and quarter-end closing. This gives a good opportunity to plan your heavy and light conversions around those dates. Figure 23 shows an example as to how you need to represent the non-conversion days on the TIG and how to push out the tasks falling on such days.

Figure 23

Integrate a financial constraint calendar into the TIG

Benefits of Using This TIG Methodology

Here are six benefits of using the TIG:

1. The TIG is an excellent mechanism for progress tracking on each section across functional areas.
2. It makes hourly monitoring possible during cutover weekend.
3. The TIG is helpful in executing tasks across the geographies and time zones.
4. It provides opportunities to improve the efficiency of the execution process through mockups and dress rehearsals, such as these examples:
   • It provides an opportunity to redefine and resequence bottleneck conversion activities, thereby streamlining the process and allowing the resources to focus on their activities.
   • It provides an opportunity to reallocate resources to bottleneck activities and alleviate the resource constraints.
5. The TIG is helpful in overall as well as functional area-wise progress reporting during the course of execution.
6. The TIG provides great control over the whole process of execution, but also offers an excellent checklist for tracking at every phase until go-live.

Ramachandra Chemudupati

Ramachandra Chemudupati is a lead consultant at Infosys Ltd. His areas of expertise are SAP materials management, sales and distribution, plant maintenance, and project management. He has more than 12 years of consulting experience and has worked on multiple implementation, rollout, transformation, and data migration projects for several global Fortune 500 companies.

You may contact the author at cramac2011@yahoo.com.

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