Scope, scope, scope. Over the years, hundreds of articles, documents, and warnings about scope setting, scope control, and scope management with ERP and IT projects have been written. We’ve heard it all before. Project scope is one of the biggest ERP project risk factors, yet few articles offer practical insight on setting or managing scope. From an SAP perspective, all of the tools and resources have been provided to do the job correctly, right from the beginning, even before an RFP is issued.
Since the mid-late 90’s, SAP has provided an extensive implementation toolset that is not well understood by many, and is even less utilized to its fullest potential. First there was the ASAP Methodology (Accelerate SAP), then ValueSAP (an enhanced ASAP toolset), and finally Solution Manager. ASAP and ValueSAP were external to the SAP application, but Solution Manager is built in and incorporates the tools and resources available in the SAP ASAP “toolkit”. Since SAP has over 20 Industry Solutions, and literally tens of thousands of implementations, they have EVERY major process covered, to a tremendous level of detail, in spite of what competitors might claim. As a result, using the supporting tools correctly, there is little reason why anyone should be very far off in their scoping efforts.To get more insight and get specific details of the project scoping tools and resources SAP offers, as well as more details on how to do this scoping exercise see the article entitled “ERP and SAP Business Case for ROI, Business Benefit, and Success. It provides information on up front project activities, including preparation for your ERP implementation, upgrade, or enhancement RFP. The resources listed there can be obtained directly from SAP 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 helps to determine 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 with 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 to determine budget requirements, do an RFP, or ensure that their project has a good foundation. Having little or no experience with SAP terminology, or the depth and breadth of the SAP application, few companies are able to put together a thorough RFP to be able to truly compare vendor proposals. As a result there are times that a company may end up with a far less than optimal implementation partner. Where a well-defined scope and carefully structured RFP process helps weed out less than optimal implementation partners, poorly defined scope could cost much more than just a blown budget.
What to Consider in SAP Scoping
Obviously there are budgets and limits to what can be done in an implementation. The ideal situation for many companies is to determine a Phased scope right from the beginning.  You should know, even before submitting an RFP, whether or not you will add additional products or enhancements in future phases. If you are certain 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, it is important to know this right from the beginning. Even though this additional functionality may not be part of the initial project scope, it should be considered during the blueprint phase to ensure that there isn’t a significant amount of additional engineering to accommodate the extra functionality and applications 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 it may not be cost effective to implement in the first “Phase” of your SAP project. Depending on your needs and actual requirements of the business (not the technology) it may or may not make sense to implement some of these additional SAP functions in the future, but a detailed exploration of your scoping requirements will reveal this.
Some of the critical considerations for your company’s implementation or upgrade are whether or not you will need non-SAP “bolt-ons.” These should be considered and budgeted for right from the beginning. 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:
- Structured Compliance (SOX, ISO, TS, etc.)
- Training Documentation
- Change Management
- Fax Ouptut
- E-mail Output
- 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, it is crucial to be sure that any or all of these areas, and any other “specialty” solutions are addressed 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 will help to ensure 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 (this is an older ValueSAP scoping spreadsheet which should be sufficient for RFP preparation) updated with the ECC 6.0 version on 4/22/2010. Please note, this is a Microsoft Excel spreadsheet, it is fairly large so it may take a few moments to download, and then your virus scan software will probably check the file. Please be patient when opening the file by clicking on the link.
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.
3) Define a timeline for completing the initial RFP or Project scoping (expect anywhere from 2 – 12 weeks depending on your company’s complexity and size)
4) Identify the key business resources that will be needed for the effort.
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 might be needed.
Finally, if this is a scoping exercise to support an RFP, be realistic in your expectations of both scope and budget. If there is a significant amount of advanced functionality that you would like to implement, 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 but that might need a separate project phase, and a “3” for nice to haves but reserved for some yet to be defined future phase.
One of the keys to realizing benefit from an SAP implementation is in getting the application up and running as quickly as possible.
The more effort you put in early in the process, the clearer expectations are set and the more satisfied you will be with the end result.
 I’m 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 by the time the project is completed to see if they ever want to do business with that vendor again. Sometimes, for better or worse, once the vendor selection is made you may end up tied into that vendor for the duration of the project.
Having said this though, one of the side effects of this Phased approach which must be planned for is that many system integrators will “abandon” previously implemented sites as soon as they have to move on to the next one.
- write down the proposed targets and scope of the second phase of sap
- proposed targets and scope of the second phase of SAP
- proposed targets and scope of second phase of SAP
- second phase of SAP
- Proposed target and scope of second phase of SAP
- Write down the proposed target and scope of the second phase of sap
- proposed targets and scope of the second phase of social action plan
- proposed targets of second phase of sap
- targets and scope of the second phase of sap
- write down the proposed targets and scope of the second phase of sap in urdu
- targets of second phase of sap
- the proposed target and scope of the second phase of SAP
- SRM project scoping
- the proposed targets and scope of the second phase of SAP
- what are the proposed targets and scope of the second phase of social action plane