INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

ERP and SAP Business Case for ROI, Business Benefit, and Success

November 23rd, 2009 by
ERP or SAP Business Case, CRM, ERP, BI, and IT investment, where is the business benefit?

SAP Business Case Target

Your company’s SAP or ERP business case should start before your RFP, and not just at a high level. It is important to take some time up front to get educated and develop some key understanding before ever issuing an SAP RFP.

There are a number of steps you can and should take, first among them is to get educated.  Educated software buyers are more sophisticated, and the more sophisticated you are the better your results will be.

There are many benefits to being an educated software buyer.   The more educated you are:

  • The better the quality of the ERP RFI or RFP.
  • The better choice you will make at vendor selection (you’ll be able to see past sales pitches to the substance).
  • You’ll be able to make a more objective assessment during demonstrations.
  • You’ll be able to focus on ensuring vendors show you what is really important to make a better decision.
  • The better your project will be scoped and blueprinted, and;

Ultimately, you will end up with a better project and results overall.

The most successful RFP business case for an SAP, ERP, or IT project will include several components:

ERP Project Value Proposition Elements

  • Operational Excellence – expected cost reductions from automating and improving ongoing operations and their processes.
  • Customer Focus – how will people, processes, and technology enable operations, goals, and reports to focus on the customer needs and wants? How will sales, marketing, and customer service be integrated and extended to delighting the customer? Tools and resources to empower customers for success with the organization’s products and services.
  • Innovation – Tools and resources to support internal and external collaboration, engineering efforts, and market intelligence.

Business Competitive Pressures to consider for your SAP Project

An honest assessment of the organization’s strengths and weaknesses in the four core competitive pressures businesses face [FN3]:

  • Customer options
  • Vendor power
  • Existing competitors
  • New (innovative) products or services.

Underlying the value propositions and the competitive pressures is the need for solid business goals and metrics that you expect the software application to enableI’ve provided some insight on the process of developing meaningful KPIs which can become the basis for a solid business case.  That article helps to define the business drivers that are necessary to intersect with technology.  By changing how you look at SAP to focus on the business rather than the technology you are far more likely to achieve great results and more satisfaction with your implementation.   And on top of that, by making the business drivers the focus of all of your efforts you will also gain more meaningful insight into aligning the right implementation vendor with your technology project.

For success in highly competitive global markets your organization must be agile enough to change and adapt as necessary. This is true no matter what the size of the organization is.  And by focusing on business needs rather than just on the technology you are far more likely to design processes, goals, metrics, and project expectations that will help to keep you from getting locked into rigid technology restrictions.

Where to start with developing a solid SAP business case based on business and IT strategy:

  1. Get your company “A” team together to work on the initial project definition. Be sure they are the people that will have key responsibilities for the SAP project (and they should be key decision makers for the vendor selection process).
  2. If you have not acquired an SAP software agreement yet then contact an SAP sales rep and ask about getting a copy of the ASAP toolset as part of your evaluation process for software selection.  Be prepared for the sales pitch but if you have not yet decided on SAP just insist that you are going through the up front due diligence of Discovery and Evaluation of what SAP might be able to offer.
  3. If you’ve already agreed to purchase the SAP software then have your sales rep give you access to SAP’s ASAP toolset. Install it on any web server (Apache, IIS, etc.) and begin getting your team familiar with it.
  4. Set a timeline and deadline for the initial project team to produce a business case with your company’s core strategic direction.
  5. Get familiar with the ASAP tool set.
  6. IF you have an SAP software agreement then you also have something called “IDES” available to you free from SAP. That is a complete SAP system used for training by SAP America. It is the full and complete application with pre-loaded data for a fictitious company. If you are a licensed SAP customer it is NOT a trial version, it is an educational version that does not have some short term expiration date. Along with it you can also go through installing some of SAP’s Best Practice scenarios to get more familiar with the Best Practices resources SAP provides.
  7. If you do NOT have an SAP software agreement or if you do not have the time or resources to set up an internal educational system there are several reasonable online services for direct SAP access.
  8. If you set up the SAP IDES system, or decide to get remote access, then have several key decision makers about the SAP vendor selection begin to get familiar with the software to help with your own understanding.
  9. Get familiar with the ASAP tool set.
  10. Plan on spending about 3 – 6 months on all of this PRE-project prep work depending on the size and complexity of your company and implementation requirements.  It may take 2 – 4 weeks or more just to put the RFP together after you have had a few months exposure to SAP’s resources and tools.

From this exercise one of the most critical drivers of success in the initial business case will be the ability to define outcome based business drivers for the project. These outcome based business drivers should be articulated in such a way as to be able to be verified after go-live and sufficient enough to write a contract with a vendor to include them along with penalties for lack of compliance.

SAP Business Case critical elements

No matter how you draft, define, or craft your business case it should contain a few critical elements:

  • People – the expected organizational effects or company changes such as: changes in workforce behavior, more collaboration, greater cross-functional cooperation, more customer focus, etc.
  • Process – the existing business processes will be implemented along with any expected cost savings from improvements or automation (lagging indicator processes).
  • Process and Technology – any new business processes that will address competitive pressures or value propositions and any expected savings or revenue opportunities (lagging and leading indicator processes).
  • Technology – the Key Performance Indicators (KPIs), reporting requirements, goals reporting, and other metrics that the SAP implementation will address and provide the details for (lagging and leading indicator reports). This would also include any new technology that is needed or desired to reduce operational costs or improve revenue and profitability.

Notice that this business case includes the three key areas of business process and technology intersection in the marketplace–, people, process and technology. It is equally as important to note that the best business case will also focus on both lagging and leading indicators of success. And one other key point to keep in mind is that this type of business case is focused on business transformation. Transformation in the form of developing an organization that is more focused on competitive pressures, company value, and growth. As a result all any application can do is to enable those transformation efforts, and it can lead them, but it cannot make them happen.

The best measure of success of your SAP project is whether the tools, resources, and means to achieve that business transformation were delivered as expected.

In other words, did the software and implementation vendor provide you with the tools and resources you need as a business to address your business drivers and your business reasons for doing the project?

No software, technology, or even capital equipment is going to suddenly make you money by itself.  Even capital equipment needs the raw material, labor, or service inputs that produce the products or services you make in a new, cheaper, or better way.  In other words, no equipment or technology investment alone is going to create revenue, profitability, or cost savings without having proper inputs and outputs to use that resource.  It is the new or more effective way of processing those inputs and outputs that makes the difference and this is where your business case should focus.  What do you hope for SAP or any other technology to enable your business to do better.

Business transformation must come from the business although it is enabled by the technology.

From this business case a set of “success criteria” and of strategic goals, initiatives, processes and reports can be defined to be included in an RFP to a vendor. And although I’ll write another post on RFPs another day, one of the most important focal points of an RFP and of an SAP project is in achieving “operational independence” which is just a fancy way of saying that you have developed the internal competence to be able to process day to day SAP related issues without outside vendor involvement.

Consider Independent SAP Contractors as SAP Project Auditors and Coordinators

If there is sufficient funding available it would also be helpful to bring in one or two very seasoned contract veterans at this point to help educate you and your team about the ASAP methodology, SAP’s Best Practices, solutions options, help with an RFP, and in learning how to use the SAP system, etc.  And even if you don’t have an SAP license yet, your company may wish to use one of the many SAP educational services that provide access so you can get some initial exposure to the application with no risk and no obligation.

If you decide to bring on an outside contractor or outside vendor resources to help with the initial efforts it would be to your advantage as a company to insist that by accepting that responsibility they will not be allowed to participate as a competitive vendor during the RFP.  This will prevent your up front efforts from being skewed or distorted  to have the “deck stacked” to ensure only they get the project. And by employing one vendor’s resources for that portion of the project with an absolutely clear expectation that they will not replace the final vendor you help to avoid some of the finger pointing and “gaming” between the vendors.

In spite of an incumbent vendor or consultant’s claims, or their sales pitches on how they know your business the best, you are likely better off using their talents for the vendor selection and for guidance during the actual project.

Whoever you bring in during the Discovery or Evaluation phase (independent contractor or implementation vendor) it would be best to draft an agreement that they are not allowed to participate in the RFP process as a competitive vendor. However, depending on your vendor selection it might be a good idea to work out an arrangement with the incumbent vendor who helped during the Discovery or Evaluation phase to be first choice for project staff augmentation of your internal resources or staff augmentation for the prime vendor only if that vendor does not have certain key resources during the course of the project.

SAP Business Case conclusion

Good luck on your SAP business case, it will be the beginning of a business focused journey that will help to move your SAP implementation, SAP upgrade, or SAP development work in the right direction toward realizing real business benefits. You might actually discover that elusive “ROI” and recognize the ERP system’s promise of enabling your organization to be more competitive in the marketplace and enhance your value proposition.  Using your new system to enable the business to focus more effectively on the underlying measures that are important for revenue and profitability should be your primary goal.  And defining what those measures and processes look like creates the foundation for the success criteria you need for your project.

For a little more insight read the article on effectively scoping your SAP project [4] to get some initial scoping for the SAP RFP. Being able to do some initial SAP scoping work before your SAP vendor RFP will help to level the playing field some.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[1] SAP as a Change Enabler
http://www.r3now.com/sap-as-a-change-enabler

Change How you Look at SAP to Create ROI
http://www.r3now.com/change-how-you-look-at-sap-to-create-roi

Why SAP Projects Fail to Deliver ROI (and How to Change IT)
http://www.r3now.com/why-sap-projects-fail-to-deliver-roi-and-how-to-change-it

Using SAP to Improve Revenue and Profitability
http://www.r3now.com/using-sap-to-improve-revenue-and-profitability

[2] SAP PDF files with overviews of the toolsets for use on your SAP business case.
ASAP Methodology and Tools Overview (KEY Resource)
ASAP Proven Methodology for Fast Successful Implementation (similar to the one above)
Additional Resources for Using SAP Tools and Methodologies for Success (similar to the ones above)

Nearly every SAP vendor claims they use the SAP ASAP methodology but few actually follow it.

[3] Adapted from Harvard Professor Michael Porter’s “Five Competitive Forces” model. Professor Porter adds a fifth consideration–, the entry of new competitors. This author believes that while the fifth “force” might be a valid consideration for academic purposes that in practicality if an organization were able to master the other four competitive pressures then the barrier to entry for new competitors would be so high as to make that competitive pressure irrelevant. That fifth force only becomes a real factor if one or more of the other competitive pressures sufficiently lower the barriers to entry.

[4] Effectively Scope Your SAP Project
http://www.r3now.com/effectively-scope-your-sap-project




Popular Searches:


  • SAP Business Case Template
  • ERP business case
  • HCM Business Case
  • business case for an ERP
  • sap business case
  • SAGES ERP business case
  • erp business case change request
  • creating a business case for s/4 hana assessment
  • business case outcome based for erp cloud
  • business case for changing otc vendors
  • software investment business case roi template ppt

Related Posts:

A Cautionary Tale About SAP Knowledge Transfer

February 3rd, 2009 by

SAP Project Knowledge Transfer of Technical Requirements

The first few years of my SAP career was spent doing SAP training and documentation. That time in front of a classroom doing SAP courses helped me gain an understanding of the user perspective, the client perspective, and the ability to facilitate effective requirements gathering sessions.

Many SAP trainers do not have the “luxury” of specializing in a single module.  Usually you learn the transactional processing of whatever module you end up being responsible for on each project.  As a result, many SAP trainers with a few years and a few project experiences have a fair process understanding of the application.  During my first few years of training I covered most of the major SAP modules [FN1].  This background was an invaluable experience for me.  Because of the results I’ve seen when knowledge transfer is done correctly I’ve become a real fan.

Experienced SAP Consultants and Knowledge Transfer

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer; therefore, they are not threatened by encouraging your understanding.  Many talented consultants thrive in an environment where they are challenged, and learning, and solving problems.  It is a dimension of a successful consultant’s personality and character.  So transferring knowledge is second nature to a skilled and experienced consultant.

Most often the truly skilled consultants with practical business and work backgrounds are the ones who can speak to issues in plain, understandable terms.  They have been through the go-lives, they have done the production support for the user community, they have had to work through the complex or thorny processing issues, they’ve seen where things were done right (and not so well) and they have gained a solid process understanding.  They do not have to rely on “fast talking techie speak” to keep you confused and in the dark.  And if you’re not clear on what they are saying how are the project team and user community going to understand them?

Having explained my bias, one of the most important things a company can require of their software vendor is knowledge transfer.  Done correctly this leads to operational independence.  Done poorly, or not at all, it leads to perpetual vendor dependence.  Worse still, done poorly the long-term organizational change and acceptance of the new system, new processes, and new way of doing business is much slower and more painful. In some of the worst cases strong enough resistance to the needed business change may lead to resistance and eventual failure of the implementation.

More on SAP Knowledge Transfer and Process Communication Skills

Most consultants come to a project with resumes that claim several years of full life-cycle project experience:

  • leading requirements gathering sessions,
  • developing blueprint documents,
  • producing option assessment whitepapers,
  • logging and troubleshooting complex issues with users,
  • performing actual knowledge transfer,
  • training client-side core team members,
  •  and post-go-live support.

For many companies looking to install SAP or other ERP applications many of the consulting companies deliver “generalists.”  These “generalists” do not have the critical application and process knowledge to ensure that your company will gain the critical “operational independence” you need for long term success.  Ask yourself how you are ever going to acquire the knowledge transfer your organization needs if the consultants who you are paying are also learning “on your dime.”

SAP Knowledge Transfer Requires Good Communication Skills

How can a consultant do any of the communication intensive project requirements without strong native language skills?  Any language barrier is a red flag that you may not receive the critical knowledge transfer you need for operational independence. The lack of ability to do knowledge transfer is a serious red flag which should be a warning that the consultant may not have the level of experience required for results.

I have seen the results of projects where the vendor team would not effectively transfer knowledge, and projects where it was effectively transferred.  While there are lots of reasons, some of the danger and warning signs of a problem vendor and of problem consultants are those who will not, or cannot, share their knowledge and move the dependent organization toward independence.

There are a number of warning signs indicating a serious problem.  For example:

  • Fast talking “jabber” that sounds sophisticated but is difficult to really understand.
  • “Techie” terms and jargon rather than plain native language terms that make sense and even help the uninitiated to understand (frequently this is an indication of a LACK of experience because the exposure the individual has is to the “technical” material they have reviewed or are learning online).
  • Lots of “consultant only” meetings where client counterparts are not invited to participate (some of these, like weekly team lead meetings for consultants only may be needed.  But excessive use of these should be seen as a red flag).
  • Layers of bureaucracy to get answers or to resolve problems from the “keepers of the knowledge” by the active or extended implementation team members (again, some of this is necessary as a practical measure from the extended user community).
  • Frequent failures to communicate changes in direction, or new requirements.
  • Constant refrains like “you don’t need to worry about that now” or “we’re not there yet” or “don’t worry, we’ve got that covered.”  Or worse still, “why do you need that?”  If you’re getting these types of responses without adequate explanations this should be seen as a danger sign.
  • Or, the all time classic “I’m (or we’re) too busy to worry about that now.”  And while many projects are busy, the knowledge transfer can not be neglected.

Effective SAP Knowledge Transfer Requires the Ability to Make the Complex Seem Simple

The important skill in all of this is the ability to take the complex and make it simple.  Anyone can take the complex and keep it that way, or even make it more complex, however those with real talent can help you understand what you need to know for success.  They are often able to do this in terms that you understand, and when the introduction of completely new and foreign concepts are introduced if they have enough experience they will have worked through it enough internally to be able to present understandable explanations.  Often times those fast talking consultants, who are hard to understand and use lots of jargon or technical talk that “sound” so brilliant are most often the fakes.

All of these fakes are more common than many clients realize, and more damaging to your implementation than you can imagine.  Even many vendors are duped and hire these consultants who hide behind their own lack of knowledge or experience by preventing you from gaining knowledge, or the ability to meaningfully challenge or review their work.  By preventing meaningful review of the consulting work you are billed for it is difficult or impossible to recognize the level of competence and skill (or more likely, the lack of it).

Knowledge Transfer Exceptions

There is one other perspective and cause to consider here: there are some projects where the client company (not the vendor) does not provide enough resources for the project, or will not commit enough of their core team member time that makes it very difficult to transfer much knowledge.  To achieve operational independence a company MUST commit their resources to learning the system, and learning it well, for long term health.

Trying to have core client team members do an SAP project while maintaining some additional responsibilities of their other job only hurts you (the client) in the long term.  The reason is that once you go live things will change, SAP will be your new system and the old ways of doing business will not all be supported.  As a result the more knowledgeable and capable your core team is the better and more productive it is for your business.

If you’re one of those clients where you really don’t care, money is virtually limitless, and you just want a warm body, then these types of consultants, their vendors, and the long term dependence on them are ideal for you.  If you’re looking for results and meaningful long term value, run from these consultants and their vendors like the plague.

Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer

To avoid this problem, your vendor contract might include a provision where you commit to the number of resources and time (client staffing levels) and the vendor is required to reach a point of operational independence within 2 (or 3, or whatever number) months after go-live.

Define operational independence as the client resource’s ability to troubleshoot and resolve transaction problems within the scope (or list) of the transactions that are implemented.  Also, the terms of your agreement might spell out that as of “x” date, the vendor agrees to support all client resources at “y” discounted rate (say 50% or less of the project rate) until operational independence is achieved.  See how your vendor reacts to this.  If they raise concerns, and want some contract language changed or modified to make things fairer and to spread the responsibility more appropriately that is fine.  But if they are resistant to such an arrangement without a clearly compelling reason you may want to reconsider whether they are the right fit for your project.

Combat this throughout the project by building some of these knowledge transfer expectations into other parts or phases of the project.  For example, by the time the project begins integration testing, the client resources should be able to configure or resolve “x” or “y” as part of the knowledge transfer.

How you resolve this is up to you, but let me assure you that knowledge transfer is a key component of every GOOD SAP project.  If your project is lacking in the knowledge transfer and you have provided sufficient resources you may want to take a long, hard look at your vendor and consultants.  You may be headed for more problems and more unnecessary expenses and cost than you know.

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

[FN1] I had trained classes on various parts of PP (Production Planning), SD (Sales and Distribution), MM (Materials Management), WM (Warehouse Management), FI (AR, AP, GL, and Asset Management)




Popular Searches:


  • yhs-fullyhosted_003
  • can sap experience be transferred

Related Posts: