I am always amazed at how many projects miss one of the most important (and relatively simple) scoping requirements. The worst part is that projects don’t just miss it, but they get it completely backward!
After doing SAP projects since 1994, I still cannot believe SAP’s customers don’t use the old “Seven Habits” step of starting with the end in mind. What do I mean by that?
Start Your SAP Project with Reports and Business Requirements
Why do so many projects wait until they are live with some new system to figure out what the reporting requirements are? Reporting requirements must become part of the initial SAP scoping exercise. Even if it is not stated, every business that undertakes a massive ERP or IT project like SAP wants actionable information from the system after it is installed. You want critical information that can enable you to do the following:
- Make better management decisions,
- Make better financial decisions,
- Determine what products or services have good margins (and which ones don’t),
- See how different product lines or geographies are performing,
- Know what future business directions you should take based on actionable information,
- Know what competitive pressures in the marketplace to focus on,
- Etc.
Aside from the operational automation and getting business processes defined, reporting is key for the following:
- compliance,
- operations decisions,
- sales and product (or service) decisions,
- and every other aspect of the business.
Reporting is critical to business, yet almost every project treats it as an afterthought. Too often, reporting projects start after the system is in place and people start working in it. From a budget and cost perspective, you do not need all of your reports done as soon as the system is installed, but the system must be designed from the beginning to support all of the data needed for those reports. The system must produce actionable information after the operational and automation components are implemented.
If you start from the beginning with your reporting requirements, you can ensure that the system design addresses any reporting gaps. This way, you will have the key actionable information you need for your business and avoid disappointment after you install the system.
Using Reports to Drive Meaningful Business to IT Alignment
Without knowing what the final actionable reporting requirements are in advance, you cannot take advantage of the information that a system such as SAP can offer. When an SAP system is properly implemented and constructed, SAP provides mountains of data and field options. You can also add custom fields, repurpose existing fields [FN1], and add other data dimensions to track and report on any piece of information. However, if you do not plan for this from the beginning, and then set up and train so that you can maintain that data, then you may experience disappointment after go live.
By defining end-state reporting needs and end-state actionable information needs, you can use this during vendor selection to separate the capable from the incompetent. The ideal situation would go so far as to provide actual desired end-state reporting examples (field names, field values, etc.).
By doing this exercise, you also have the additional benefit of focusing the entire project, right from the beginning, on the end-state goal. This concentrates the project into actual business needs and business requirements for success.
If you do not do this upfront exercise, you may discover that you need certain key data requiring expensive rework, expensive customization, and additional time budgeted. In the worst case, depending on the system design, you may end up creating a design dilemma that causes even more trouble down the road. You may even discover that the way the system was designed and implemented prevents you from ever realizing key decision-making information.
Where to Begin with SAP Scoping and Reporting
Every customer considering an SAP implementation should carefully read through the article on developing an SAP business case: ERP and SAP Business Case for ROI, Business Benefit, and Success (PDF version attached here).
To get the most from your SAP implementation or your SAP scoping exercise, you should start with the tools and resources SAP provides free of charge to their customers (and prospects). Every customer, or prospective customer should insist on working with a few tools before doing their SAP implementation. The first is the SAP Solution Composer [FN2]. It is a free download and a great tool for understanding how to scope your SAP implementation. As mentioned in the article linked above on developing the SAP business case, it is a great tool for the following:
- Developing an initial scope
- Creating process lists for starting some of the critical change management discussions
- Communicating in a new but common language about the processes.
The next tool available for a high-quality project is the ASAP methodology. ASAP is an active HTML and Java script based repository that contains templates, resources, materials, and a project plan to ensure you have a successful implementation or upgrade.
Take Inventory of Your Existing Reporting Landscape and Define Desired Metrics
After your initial SAP scoping exercise, you need to take an inventory of all of the spreadsheets, databases, and system reports that exist. From these, you can get a good idea of what you need accommodated in the system. From these existing reports, the master data requirements that are required can also be derived.
After gathering the existing reports, begin short duration management workshops to define desired reports. In other words, what has been lacking from the business decision-making process that would provide strategic or tactical insight going forward? For more information on one reporting and metrics strategy, see the posts related to defining and understanding real Key Performance Indicators for business performance (Why Indexed KPIs are Critical for Business Performance and Success, and Using Key Performance Indicators for Building a Strategy Focused Organization).
Once you define the initial operational requirements, existing reporting requirements, and desired reporting requirements, you can then determine a final scope and blueprint to propel the business forward strategically into the future.
Conclusion on Early Reporting Requirements in SAP Scoping and Blueprinting
In the end, I am still surprised at how many organizations finally get around to SAP reporting requirements after the system is already implemented. Just because you consider and plan for them from the beginning does not mean that you have to complete them by the time the system is in. On the other hand, you will need those requirements at some point, so having the key data and understanding the business drivers for key information is crucial in your SAP implementation.
Too often, the reporting metrics, goals, and drivers for business decision making are treated as an afterthought. Those reporting metrics and the business goals, key performance indicators, or business direction they represent are generally the reason for the huge investment in new systems to begin with.
Stop and think about it: how will you ever know if any of the business-centered success criteria were delivered if you don’t have a clear direction in advance? Those reporting requirements must include current and desired actionable data requirements in some measure of detail. Certainly as a company and then during the sales cycles, you should discuss the buzz words and generalities of the information end-state:
- during the early research,
- during RFP preparation, and then
- during the vendor sales cycles when all of those promises are made about a “future state” for your business.
Some of the actionable data requirements, or efficiency improvements, or competitive improvements, or other business drivers are also explored during this period. If you do not capture and distill them into some detail, and then include them in your RFP and project charter, how will you know if they were ever delivered?
One other thing to keep in mind is that no system, no matter how good or how well implemented, will change a business by itself. Properly implemented, it will provide the actionable information to make sound business decisions for marketplace success (see also SAP as a Change Enabler, Using SAP to Improve Revenue and Profitability, and Change How You Look at SAP to Create ROI).
_____________________________________________________________________________________________________________________________________________________
[FN1] SAP provides a huge number of fields that most projects never use. Some of them are directly tied to application functions and cannot be used; still, others are not. Without doing any custom coding or application changes, you can use some of these fields for other purposes. This repurposing of some fields is a very easy, cost-effective way to solve a number of issues.
[FN2] Go to http://www.sap.com and search for “Solution Composer” (or use this link http://www.sap.com/solutions/businessmaps/composer – retrieved 4/13/2010).
Additional SAP Project Success Reading:
ERP and SAP Business Case for ROI, Business Benefit, and Success
Why SAP Projects Fail to Deliver ROI (and How to Change IT)
what a fantastic article! This is EXACTLY what i have been trying to communicate too.. we put the cart before the horse – unfailingly, every single time :-) thank you. Its great to be here.