Business Solutions with SAP

Using SAP Solution Composer for SAP Scope – Process Alignment

February 28th, 2011 by
SAP Solution Composer

SAP Solution Composer

If you haven’t noticed by now I’ve always been a proponent of using the tools and resources SAP already provides. After all, why should you pay for developing things SAP has already invested in?

Because of SAP’s huge installed base lots of customers before you have tried these tools and SAP has adjusted, changed, corrected, or modified them to improve their use and functionality. On top of that, if you manage to discover a defect or bug, as an SAP customer you can check OSS Notes to see if there is a fix. If a fix doesn’t exist you can open your own note to report the bug and get it fixed. Support for SAP tools is included in your maintenance fees.

One of those early solution prototyping tools I am particularly fond of is the SAP Solution Composer [FN1]. It has a number of benefits and I have defined a number of ways to use it in other posts:

The SAP Solution Composer tool provides a number benefits to help you quickly map processes and solutions:

  • It will map SAP’s software solutions to your business from a business process perspective.
  • It is free to anyone considering an SAP implementation and you do not already have to be an SAP customer.
  • You can publish a “Solution Composer” type PowerPoint scope presentation to mid-level and higher management to ensure their concerns are addressed.
  • It helps with “expectation setting” to reduce surprises that might come up later.
  • Creating process lists for starting some of the critical change management discussions
  • It provides a common language platform for communicating about process options and process change.
  • It comes with several business objectives, metrics, and other information to help you determine which areas of your business to focus on.
  • The SAP Solution Composer tool contains standard and customizable KPIs, business objectives, and other areas of business focus for evaluation.

Together with IDES [FN2] SAP’s Solution Composer provides a great Enterprise Architecture jump start for those who may not have 10, 20, or more years of experience. At least with SAP solutions the complex Enterprise Architecture software options are readily available.


[FN1] Information on the Solution Composer tool, and its use can be found here:

[FN2] See the previous post on:
Global SAP Instance Consolidations

Popular Searches:

  • sap solution composer

Related Posts:

SAP Implementation Partner or Company Selection Criteria

June 5th, 2010 by

Organization Change Management and Vendor Selection

Project success depends on an implementation partner’s ability to ensure business transformation occurs.

Can the SAP implementation partner or company deliver business process engineering together WITH the new system? Or, as with so many of them, do they just install systems and call that an implementation?

Lately I’ve been focused on developing a solid and repeatable ERP software and vendor selection process. 

While reviewing the academic literature and reflecting on my time working with SAP (since 1994) I found an interesting study from Romania.  The study addressed software vendor selection criteria and methods related to the limited information they had within the country.  The opening abstract certainly lines up with my personal experience about whether or not you will ever see ROI from your software investment:

Successful implementation of an ERP system is the result of knowledgeable and dedicated people working together. It entails 1) company-wide commitment, 2) openness to change, 3) good planning and 4) experienced guidance.

These key ERP implementation success criteria help you realize significant return on investment (ROI) from an ERP system. Using these criteria as guidelines during the system selection process and subsequent implementation can ensure that the chosen system will support and enable the business improvements many SAP implementation partners claim during the sales process (Hurbean 2009, pg. 1).

SAP or ERP Software Installation or Implementation?

There is a lot of substance to this study, for example it notes that the software implementation strategy and methodology are critical success factors for both the project and the software vendor selection.  One of the important differences they identified for ERP or SAP implementation companies is the idea of companies that merely install the application (more of a technical exercise) and companies that implement the software (focus on business drivers and business change in addition to the technical exercise).

The point of failure for many software vendor selection processes is a focus on the “product features” and “less or not at all the implementation.”

This study reaches the conclusion I have been pointing out for a long time on this site; there is a significant difference between software installation (with “technicians”) and software implementation (with “experts”) (see CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?). 

The Romanian study provides a meaningful definition between the two “goal posts” of software implementation methods and processes (see Software Engineering or Business Process Engineering?).  The goal of a software installation is to move from one software system to another with a minimum of disruption. An implementation focuses on the business drivers and business goals through a transformation of processes with the right software (paraphrased from Hurbean 2009, pg. 2) and the right implementation partner.

Key Implementation Success Factors that Apply to the Type of ERP or SAP Implementation Company or Partner

The key vendor factors identifying the differences between an implementation and an installation were:

  1. Lack of training and education to the company (typically a part of the change management process)
  2. Lack of in house expertise (related to a knowledge transfer strategy)
  3. Lack of clear goals or business objectives (poor business to IT alignment)
  4. Lack of companywide support and involvement (change resistance – insufficient change management)
  5. Lack of top management commitment and support (critical success factors and the senior leadership imprint)
  6. Lack of data accuracy.

Only items 3 (goals and business objectives) and 5 (top management involvement) are directly dependent on the company who selects the ERP implementation partner.  And even those two items can be strongly influenced by an ethical SAP implementation company.  For item #5 I have been on a few projects where the vendor project manager refused to engage company leadership even though the leadership was more than willing to step up but just needed some guidance.  And for item #3 I have seen many implementation vendors who bring unqualified “con”sultants to a project who were incapable of helping a company align an SAP implementation to business goals and drivers.  And then I have seen companies where the internal political culture or the company project team prevented these two success criteria.  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors is about another study I reviewed and wrote about which lines up with several of these key SAP implementation success criteria.

SAP or ERP Implementation Success Criteria

The study continues to provide some great insight into corrective actions that can be taken to ensure you more properly align your IT / ERP / SAP investment to your business goals and objectives.  They provided an overview of ERP implementation partner or implementation company selection criteria that helps to ensure SAP project success.  This site has addressed these key shortcomings in much detail.  Below you will see the numbered problem area from the list above, a summary explanation of how to address it, and then an in depth article on the topic or subject. 

  1. Lack of training and education – ensure you have carefully considered both knowledge transfer and training requirements (see e.g. Change Management and Knowledge Transfer for a Successful SAP Project)
  2. Lack of in house expertise – knowledge transfer and the best business employees to support your implementation efforts (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?)
  3. Lack of clear goals or objectives – if the project requirements are not carefully aligned to business needs even before you begin you will have trouble finding value and finding the right vendor (see e.g. Aligning SAP Scope to Meaningful Business Requirements and Business and IT Alignment – Integrating Technology and IT Spend with Business).
  4. Lack of companywide support and involvement – a solid change management focus and communication are critical which requires software implementation vendors who can help lead the change activities (see Leading Change (and Change Management)).
  5. Lack of top management commitment and support – senior leadership must be educated as to the business benefit and the business direction of the project, and the importance of their strategic imprint for success (see The Real Reason Executive Participation Creates IT Project Success).
  6. Lack of data accuracy – ensure that your vendors focuses on the right data migration strategy and using the right data transformation tools (see Planning For a Smooth SAP Go-Live: Part 2).

Doing the up front work to carefully understand your business requirements, and then to demand that an SAP implementation company or partner has the skilled and experienced consultants is critical to project success.


Hurbean, L. (2009). Factors influencing ERP projects success in the vendor selection process.  West University from Timisoara (Romania), MPRA Paper No. 14430, Faculty of Economics and Business Administration.


Note:  This post has been split into two key parts, this first part focuses on a review of the study and the second part More on Vendor Selection Criteria and Methods for ERP Project Success focuses on some specific methods or approaches for vendor selection.

Popular Searches:

  • what are criteria used in selecting for sap company

Related Posts:

Aligning SAP Scope to Meaningful Business Requirements

April 13th, 2010 by

ERP or SAP Business Case, CRM, ERP, BI, and IT investment, where is the business benefit?I’m 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 can’t 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! 

Come on now, 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 spoken, 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:

  • Make better management decisions
  • Make better financial decisions
  • Determine what products or services have good margins (and which ones don’t)
  • How different product lines or geographies are performing
  • What future business directions you should take based on ACTIONABLE information
  • What competitive pressures in the marketplace to focus on
  • Etc.

Aside from the operational automation and getting business processes defined, reporting is the key for :

  • compliance,
  • operations decisions,
  • sales and product (or service) decisions,
  • and for every part of the business. 

Reporting is so critical to a business yet on almost every project it is treated 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 don’t 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.  It must be designed from the start to 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.  By doing this from the beginning you will not have the system installed and then be disappointed that it does not provide you with the key actionable information you need for your business.

Using Reports for Driving Meaningful Business to IT Alignment

Without knowing in advance what the final actionable reporting requirements are you will not be able to take advantage of some of the really great information that a system like SAP can offer.  When an SAP system is properly implemented and constructed SAP provides mountains of data and field options.  There is the ability to add custom fields, re-purpose existing fields [FN1], and add other data dimensions so that you can track and report on any piece of information in any way you can imagine.  However, if this is not planned for in the beginning, and then set up and trained so that you can maintain that data, then after you go live you may be disappointed. 

If you do not do this up front exercise you may discover that you need certain key data requiring expensive rework, expensive customization, and additional time budgeted.  And in the worst case, depending on the system design, you may end up creating a design dilemma causing even more trouble down the road.  Worse still you may discover that the way the system was designed and implemented may prevent you from ever realizing key decision-making information.

There is one other benefit from this approach as well.  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 will help to distill the project down into actual business needs and business requirements for success.

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). 

The key steps to getting the most from your SAP implementation or your SAP scoping exercise is to start with the tools and resources SAP provides free of charge to their customers (and prospects).  There are a couple of tools in particular that every customer, or prospective customer should insist on working with before doing their SAP implementation.  The first is the SAP Solution Composer [FN2], it is a free download and it is 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:

  • 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.  It is an active HTML and Java script based repository which contains templates, resources, materials, and a project plan for ensuring you have a successful implementation or upgrade. 

Take Inventory of Your Existing Reporting Landscape and Define Desired Metrics

After your initial SAP scoping exercise it will be important 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 will need to be accommodated in the system.  And 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 (see Why Indexed KPIs are Critical for Business Performance and Success, and Using Key Performance Indicators for Building a Strategy Focused Organization).

Once the initial operational requirements, existing reporting requirements, and desired reporting requirements are defined a final scope and blueprint can then be determined which will propel the business forward strategically into the future.

Conclusion / Summary on

Early Reporting Requirements in SAP Scoping and Blueprinting

In the end I’m still suprirsed at how many organizations finally get around to SAP reporting requirements after the system is already implemented an in place.  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 them 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 was 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 the buzz words and generalities of the information end-state are discussed;

  • 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 they are not captured and distilled into some detail, and then included in your RFP and project charter how will you know if they were ever delivered without defining these critical business justifications for the system to begin with?

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, but 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 are never used on most projects.  Some of them are directly tied to application functions and can not be used, still others are not and without doing any custom coding or application changes you can use some of these fields for other purposes.  This “re-purposing” of some fields is a very easy, cost-effective way to solve a number of issues.

[FN2] Go to and search for “Solution Composer” (or use this link – 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)

Related Posts: