Effectively Scope Your SAP Project

Over the years, people have written hundreds of articles, documents, and warnings about scope setting, scope control, and scope management with ERP and IT projects. Project scope is one of the biggest ERP project risk factors. Yet, a project may lack practical insight on setting or managing scope. SAP provides all of the tools and resources to do the job correctly–even before an RFP is issued.

Since the mid to late 90’s, SAP has provided an extensive implementation toolset that many do not fully understand, much less utilize. First, SAP provided the ASAP Methodology (Accelerate SAP), then ValueSAP (an enhanced ASAP toolset), and finally Solution Manager. ASAP and ValueSAP were external to the SAP application. However, Solution Manager is built in and incorporates the tools and resources available in the SAP ASAP “toolkit.” Since SAP has over twenty Industry Solutions, and literally tens of thousands of implementations, the program covers every major process to a tremendous level of detail. As a result, businesses that use the scoping tool correctly can achieve their scoping efforts.

To get more insight and specific details of the project scoping tools and resources SAP offers, see the article entitled ERP and SAP Business Case for ROI, Business Benefit, and Success. It provides information on upfront project activities, including preparation for your ERP implementation, upgrade, or enhancement RFP. SAP provides the resources there free of charge for carrying out some of the Discovery and Evaluation phases of your ERP project.

Where Do You Begin Your SAP Scoping Efforts?

A well-written, comprehensive scope document is critical to the success of a project. Even before the project begins, that initial scope can make a huge difference in RFP’s and setting the right tone and direction for a project. A good scope determines realistic expectations and can make the difference between an on-time, on-budget project or one that busts the bank.

When embarking on an ERP implementation such as SAP, many companies “don’t know what they don’t know.” In other words, how do they successfully translate their business requirements into a meaningful template? Otherwise, they may struggle to determine budget requirements, do an RFP, or ensure that their project has a good foundation. When they have little or no experience with SAP terminology, or the depth and breadth of the SAP application, companies struggle to put together a thorough RFP and truly compare vendor proposals. As a result, a company may end up with a less-than-optimal implementation partner. Whereas a well-defined scope and carefully structured RFP process helps weed out less-than-optimal implementation partners, a poorly defined scope could cost much more than just a blown budget.

What to Consider in SAP Scoping

Obviously, an implementation has budgets and limits. Many companies ideally determine a phased scope right from the beginning. [1] You should know, even before submitting an RFP, whether or not you will add additional products or enhancements in future phases. From the beginning, you need to know whether you will be adding on functionality in the future, such as CRM (Customer Relationship Management), SRM (Supplier Relationship Management), APO (Advanced Planning and Optimization), SEM (Strategic Enterprise Management), BI / BW (Business Warehouse), or other advanced functionality. Even though this additional functionality may not be part of the initial project scope, you want to ensure that the extra functionality and applications do not require a significant amount of additional engineering later.

You may also see some benefit from the SAP core ERP functionality, such as QM (Quality Management), PM (Plant Maintenance), PS (Project Systems) or other SAP functionality, but find that they are not cost effective to implement in the first phase of your SAP project. Because of this, you may want to implement some of these additional SAP functions once you have explored your scoping requirements in depth, so you can accommodate the needs and actual requirements of the business.

From the beginning, you also need to consider whether or not you will need non-SAP “bolt-ons.” Consider making a direct request to the vendors during the RFP process about how they will handle the following items, and what additional costs might be required:

• Training
• Structured Compliance (SOX, ISO, TS, etc.)
• Training Documentation
• Change Management
• Fax Output
• E-mail Output
• Taxes
• Bar Code Interface
• Data Transformation Middleware (for legacy system interfaces)
• EDI / XML or other electronic exchange
• J2EE (or other Java Platform for online functionality
• Web Extensions

If you are already past the RFP process, you need to address any or all of these areas, and any other “specialty” solutions, during the blueprint phase of the project. Each of these items may require additional software or expertise that may or may not have been budgeted. A well-done initial scoping requirement, along with a thorough RFP, ensures that you are truly comparing vendor bids in a more realistic fashion.

Where to Begin the SAP Scope Effort

A good scoping effort should address every process that your company needs to implement. Your scope does not need to address the details of every process, but it should address every major process and each major sub-process. SAP provides two outstanding tools for doing this (again, for other tools that are available read the article referenced above for more details):

1) A business process scoping spreadsheet, updated with the ECC 6.0 version on 4/22/2010
2) A comprehensive online help system

The new SAP Solution Manager has all of this built into the application, but before setting up a test or demo system, the Solution Manager application doesn’t do much good. Below are the next steps:

3) Define a timeline for completing the initial RFP or Project scoping (expect anywhere from two to twelve weeks depending on your company’s complexity and size).
4) Identify the key business resources the effort will need.
5) Avoid analysis paralysis and stick to the scoping timeframe (the blueprint phase of the project is to finalize scope).
6) Define any external system requirements or special “bolt-ons” that the company might need.

Finally, if this is a scoping exercise to support an RFP, be realistic in your expectations of both scope and budget. If you would like to implement a significant amount of advanced functionality, consider putting it in a future phase under a separate budget. When doing the scoping work, consider using phase numbers in your scoping exercise. For example, a “1” for the crucial core functionality, a “2” for important additional value added functionality that might need a separate project phase, and a “3” for nice to haves that are reserved for some yet-to-be-defined future phase.

To realize benefit from an SAP implementation, you need to get the application up and running as quickly as possible.

The more effort you put in early in the process, the clearer the expectations that are set, and the more satisfied you will be with the end result.

======================

[1] I am a fan of the phased project approach because it allows the company to develop some internal competency and skill with the product before adding on additional integrated functionality. It also allows for a company or organization to do an honest assessment of the implementation vendor and their consultants when the project is completed, so they can see if they want to do business with that vendor again. For better or worse, once you make your vendor selection, you may end up tied into that vendor for the duration of the project.

Having said this, one of the side effects of this Phased approach (which must be planned for) is that many system integrators will abandon previously implemented sites when they move on to the next one.