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.
Where do you begin your 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.
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.
What to consider
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. [1] 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 these extra functions 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 not make sense to implement some of these additional SAP functions even in the future.
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:
- Training
- Structured Compliance (SOX, ISO, TS, etc.)
- Training Documentation
- Change Management
- Fax Ouptut
- 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
Where to begin
A good scoping effort should address every process that your company needs to implement. It does not need to address the details of every process, but it should address every major process and each 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)
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 this 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.
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[1] 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.
Very interesting article I enjoy your website carry on the great posts
I bookmarked your site, this is very useful, thank you.
It looks that you’ve put a good amount of effort into your article and I require a lot more of these on the web these days. I sincerely got a kick out of your post. I do not have a bunch to to say in reply, I only wanted to register to say fantastic work.
Wonderful post, I have to dig this further I believe. Sure visit this blog more often.