SAP ROI — Enterprise Architecture & Business Solutions

Strategic SAP & IT Program Development for Measurable Business Value

Using SAP to Improve Revenue and Profitability

January 17th, 2009

SAP ROI - Increasing Revenue and Profitability

For years CIOs have been under pressure to help cut costs, improve operational efficiencies, and automate the enterprise; CIOs implementing SAP have largely been effective at streamlining the back-office. They’ve also succeeded at optimizing the extended supply chain because SAP is well-suited to supporting execution activities, and therefore have been a good fit for reducing costs. However, times are changing.

 To successfully move IT and SAP in the direction of revenue and profitability growth it is important to understand where technology fits into the puzzle–, technology is not magic. When SAP is considered in its proper context as a “change enabler” or “change lever” rather than a “change driver” it is easier to understand how and where it can properly fit into a revenue and profitability context. In other words, technology works best when the rules, metrics, criteria, and the means to acquire, process, or analyze information which supports revenue and profitability are understood and defined. Organizations take on large projects like SAP or any other ERP system to achieve several business benefits, often those might include:

* Revenue growth
* Profit margins
* Customer acquisition and retention
* Sales conversion
* Customer profitability
* Product / product line profitability
* Incentive programs and monitoring
* Market penetration / market share
* Marketing program performance
* “Smart” growth (i.e. “good” customers vs. “bad” customers)
* Time to market

And even though these are the expectations companies have for their ERP or SAP implementation, upgrade, or other applications they rarely achieve these goals because they are looking at the application and technology investment in the wrong way.  They are looking at the technology as if somehow it will cause these things to happen rather than providing the key insights and information that management needs to enable them to happen.  Even though that is not said, when companies invest millions in SAP that is the underlying assumption that somehow the technology will just “cause” revenue and profitability increases.

For example, no amount of technology is going to make your sales people sell more if they are paid on salary, without commissions, and do not have objective sales targets and other performance measures. This comes back to the old adage of “what gets measured gets done” and it is no different with the sales force. However, depending on how you structure your sales and marketing programs SAP contains a number of tools, reports, resources, and other data analysis methods as well as bolt-ons like CRM to facilitate a change in sales and marketing programs and strategies.

In other words ERP, SAP, CRM, APO, BI, and all of the other technology tools must be driven by business needs, and to provide key information relevant to business decisions and processes to ensure success.  And even though that seems self-evident it is still not occurring even to this day at many organizations who implement these technologies.  They often start out with that ideal, however they usually get caught up in the technology and lose sight of the business drivers. 

Since doing SAP project work since 1994 I can only recall a couple of projects where the client spelled out the business drivers, and then communicated and reinforced them to the project team and the larger organization throughout the project.  If the project team performing the implementation does not know the underlying business drivers, or the reasons for the investment, how will they build those expectations into the technology?

What are the CIO and SAP Roles in Revenue and Profitability?

It is healthy that C-Level sponsors are beginning to press IT in the direction of supporting revenue growth and profitability, however, SAP by its nature is part of the execution processing and post-execution analysis process. This is where the expectation of driving revenue and profitability with SAP has to be decoupled from corporate planning and execution. The business side of the equation must be defined first, this supports the business case which in turn drives the technology in the direction of enabling necessary change.

The senior management discussions for the this global ERP system must be focused on what information and processes the organization needs to make the right management decisions, to be more competitive, to focus on the wider marketplace.

In many implementations the reason SAP works to reduce costs is because the reductions are based primarily on improving and integrating operational and accounting execution activities. Using SAP to drive revenue and profitability growth requires building another layer of data collection, data analysis, “tools,” and processes on top of the operational data that is processed. To work correctly this new revenue and sales support layer must be built on well defined sales and marketing programs and strategies that are then converted into processes with clear performance metrics and KPIs. A focus on process improvement, business process automation, efficiency gains, cycle-time reductions, and other business process management related issues is not enough.

Sales and marketing must do their part in integrating their strategies into clearer plans, programs, metrics, KPIs, and other measurable criteria that can then be executed on with IT / SAP supporting these processes. ERP systems like SAP do not exist in a vacuum; they are dependent on data from plans, strategies, and historical analysis based on some concrete or perceived KPIs and business metrics. Until a company’s customer touch points (sales, marketing, customer service, shipping, etc.) are able to provide quantifiable plans, goals, metrics, and KPIs for what is important, it is difficult for SAP initiatives to directly affect revenue and profit.

I’ll bet many C-level executives in SAP shops didn’t know that the ERP application contains standard functionality to integrate sales planning, sales forecasting, marketing expenditures, and product or service execution with financial budgeting and multiple dimensions of profitability. For example, over the years I’ve worked on clients that have used one or more of the following methods from standard or enhanced SAP functionality (and there are many, many more possibilities):

· Points loyalty program (ERP pricing and SIS or CRM)
· Trade Promotions Programs (CRM, bolt-on, or custom ERP app)
· Marketing Effectiveness (CRM, custom reporting, BI/BW)
· e-sales with catalogs and configurable products (R3 Internet Sales or CRM – they use the same backend)
· Sales or Marketing program budgeting (ERP CO and internal orders with SD user exits)
· Sales forecast to actual (ERP Sales and Operations planning, CRM, BI/BW)
· Order templates (Generic quotes as templates, ERP, R3 Internet sales, CRM)
· Potential Planning (customer potential buying and planning against marketing plan – ERP, CRM)
· Ticklers, Marketing, Sales activities and campaigns (limited ERP functionality or with CRM)
· Customer churn (standard ERP functionality, custom report, BI/BW, or CRM)
· Customer $$ sales growth, month over month, year over year (SAP ERP functionality, custom report, BI/BW, or CRM)
· Order frequency trends (standard SAP functionality, custom report, or with CRM)
· Upselling, cross-selling, product allocation, substitutions, free goods (standard SAP ERP functionality).
· Web based reports and mobile device sales support (ERP mobile device functionality or CRM)
· Commissions and incentives (SAP ERP functionality or CRM).

One of the things the companies that have implemented these solutions and others had in common was there were already reasonably well defined sales and marketing processes and programs in place. As a result, the SAP technology was used as a change lever to enhance and improve those existing processes and programs to achieve a measure of revenue growth, profitability, and competitive advantage.

Where to begin with a business and market centered approach to SAP?

  1. Develop your longer term business plans, define marketing and competitive pressures along with current and future value proposition(s).
  2. Define the business strategies to support them.
  3. Determine the goals that support those strategies.
  4. Derive your KPIs for those goals. To be successful these KPIs must include both lagging indicators (financial) and leading indicators (pointing to growth).
  5. From those metrics and KPIs determine which business processes and departments will be affected, sales, customer service, shipping, marketing, etc.
  6. Define the necessary reports that will be needed to report on those goals and KPIs. These reports should use both leading and lagging indicators.
  7. Operationalize the strategy by defining the processes that will support them.
  8. Assign responsibility for the reporting requirements to the proper department heads.
  9. Create an internal progress communication process.
  10. Implement the necessary technology solution(s) to support the new paradigm (SAP BI, SAP CRM, SAP ERP functionality, etc.)

By following these steps you will see business centered results that are enabled or empowered by technology, not the other way around. Below are some examples of key ideas for defining strategy, processes, and technology to help with revenue growth and profitability. While in no way comprehensive the following outline provides some steps to begin on this journey. Some type of plan or steps to produce metrics which can be turned into an IT and CIO supported system strategy for revenue and profitability growth are listed.

1. Senior executive sponsorship is needed to drive integration of sales, marketing, and customer service processes. Many of them can be very difficult to “pin down” on key measures for sales and marketing drivers. Without C-level direction here it will be difficult at best to achieve and impossible at worst.

2. Set clear expectations of cooperation between those processes which “touch” the customer.

3. Determine how baselines and benchmarks for KPIs will be determined. The best baselines, benchmarks, metrics, and KPIs will require interdepartmental support. Some of the KPIs, though not all, should be outside of the silo. For example, some of the KPIs should cross over sales and marketing together. Some should cross over sales and customer service, or shipping, etc. The more the KPIs are structured within a silo the more possibility there is for finger-pointing and deflection. It has to be everyone’s job to promote revenue and profitability.

4. Senior level sales and marketing managers must set specific KPI’s, strategies, and plans around customer “touch points” as they relate to revenue generation and profitability. For example:
  a. What processes or sales functions require your sales force to be in the office rather than in the field? How can these be automated or delivered remotely?
     i. Web based?
     ii. Hand held?
     iii. E-delivery through automated e-mail notices or text messages?
  b. What are important new markets and how do you conduct pilots or rollouts to new markets?
     i. Do you have preferred customers as partners who would be willing to cooperate and “pilot” new product or market rollouts?
  c. What about new products?
     i. Do you know what your concept to engineering to market to customer cycle times are?
     ii. Where are the bottlenecks in each of these sub-processes?
     iii. How can they be streamlined?

5. How will you measure customer retention, customer loyalty, and most of all, conversion of retained or loyal customers to actual sales? (after all, what difference does it make if you have retained and loyal customers if they don’t buy more of your products, or pay for premium services or products?)
  a. Do you have (or need) some type of metrics around defining “good” customers (high revenue or sales compared to the cost of doing business) vs. “bad” customers (low revenue or sales compared to the cost of doing business).
  b. How do you measure customer “churn” or attrition of “good” customers?
  c. How do you measure sales growth into the existing customer base?
     i. How do you segment or stratify that data, by product line, by geography, or by customer sales volume?
  d. How do you target new customer acquisition?
     i. In spite of what some salesmen may say, companies do not sell “everything” to “everyone,” so what are your target markets?
     ii. What are your key criteria to focus your sales efforts on your target markets?
     iii. Where are your “invest” opportunities for sales growth and how do you measure the effectiveness of that investment?
     iv. How do you integrate marketing, sales, and customer service into customer acquisition?

6. Define processes and reporting points for each of the key customer “touch” points, whether it is sales, marketing, service and support, or new product / new market entry.

7. What is your strategy for getting company knowledge about products or services closer to the customer?
  a. Are you tracking service or repair trends?
     i. Do you have standard defect codes or service delivery categories?
     ii. Do you have a solution database?
  b. How is engineering, R&D, or new product development integrated into the sales, marketing, and support feedback cycle?

8. What tools do you need to capture customer intelligence based on contacts, visits, and other information traditionally maintained in CRM systems?

9. What external data sources and information do you need for customer acquisition?

These and many, many more questions must be answered within your sales, marketing, and customer service organizations to drive strategies, plans, programs, and ERP investment opportunities for increasing revenue and profitability.

Once you define your revenue and growth plans and strategies, determine the key metric for how performance will be measured by developing a set of KPIs. From this set of KPIs, and from the plans and strategies that are developed, take the time to prioritize them based on a simple cost / benefit analysis. What costs the least (in terms of time, cash, resources, etc.) and has the biggest payback? Depending on your business, you may weight some of the cost factors differently, but try to keep the priority process as objective and clear as possible by creating some type of scoring protocol. Using some type of objective method to prioritize will help to keep the politics, personalities, and emotion out of the process. The approach may not produce a perfect result, but it will be focused on results rather than personalities.

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

Please see the article on Screening Methods to Find the Right SAP Consultant. This type of process analysis, business strategy, and help with development of the best possible plans for implementing your SAP solution is exactly why SAP consultants with real experience are necessary.


Related Posts:

Planning For a Smooth SAP Go-Live Part 1

October 27th, 2008
SAP smooth go-live requires a lot of coordination

SAP go-live issues

After you’ve done all the research, and gone to all the trouble to make your project a success, there are still four key areas that consistently cause trouble during your SAP go-live:

1.  SAP Security and Authorizations.

2.  Master Data.

3.  Business process changes, process gaps (missed processes and exceptions).

4.  SAP ABAP Custom Development.

While each of these areas consistently cause trouble at go-live, resolving the first item, Security and Authorizations, and the third item, Process issues, should be a standard part of every project no matter who does it.  There is just no real reason for authorizations or business process issues to be a problem on any project.

The Master Data and Custom Development are a bit more difficult to resolve.  Even companies that believe they have a good handle on master data often discover that it is not as “pristine” as they might believe.  Custom development can also be another source of headaches.  Often it is some “gee wiz gotta have it” improvement, automation, or rearranging a printed form 20 times to get it “right” where development can come back to bite you if you’re not careful.  This is especially true with inexperienced developers who read some ABAP programming book, or take some back room fly-by-night “certification” course and then get a fake resume presented.

1.  SAP Security and Authorizations…

To reduce SAP go-live headaches, security and user authorizations must be carefully tested.  By testing I am *not* referring to consultant testing, core team testing, or even extended user (power user) testing–, I mean actual end users logging in under their own SAP user ID’s and verifying they have what they need to get their job done.

The most effective method I’ve seen over the years is to incorporate authorization testing into the end-user training.  Usually end-user training has “dummy” training user ID’s created that are used during classroom training.  However, the best solution I have seen is for SAP end-users to use their own ID’s during training.  They log in under their own ID’s and then verify that they have access to all of the transactions they will need at go-live.

At one client the users had a form that matched their training classes and users had to initial a sheet next to each transaction they tested, sign the sheet, and then turn it in at the end of the course.  If there were problems they were noted on the form and sent in to security to be resolved.  The users then make use of their training ID’s for the classroom training.  While this is a little disruptive to the classroom training process, it is the most effective method I have ever seen.  The idea is that the end user must somehow log in and test their logon ID long before your SAP go live.  However you decide to do that is up to you, but doing so will reduce many headaches after go-live when everyone is focused on trying to resolve fires, gaps, process changes, and the users learning a new system.

Suggestions and ideas for handling SAP security

1)      Integrate the SAP security and training efforts.  Those identified for training should also have the tasks and transactions they will be trained on identified.  This is a good starting point for security access as well.

2)      Be sure to test security with every end user before you actually go-live.  This will help to reduce the production headaches with security and authorizations; unfortunately it will not eliminate them.

3)      Take the time and effort to carefully structure your security and authorizations.  Done properly authorizations should not be a maintenance nightmare.

Other than the obvious reasons, security maintenance after your SAP go-live can not be overemphasized; after the consultants leave this is one of the routine, regular, and ongoing maintenance areas and if there is not enough attention paid to it from a long term maintenance perspective you may have to live with a “nightmare.”  Aside from the normal security concerns an improperly designed security strategy will cause you ongoing maintenance nightmares because each person will eventually end up with completely “unique” one off security objects.  That translates into significant maintenance overhead that is not necessary with a properly designed security strategy.

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4
(custom development, costs and consequences of inexperienced developers)

Related Posts:

Planning For a Smooth Go-Live: Part 3

October 24th, 2008

 SAP smooth go-live process issues

3.      ERP or SAP Process issues 

Let me start with a caveat to this section.  No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, there will always end up being a few process gaps, and an occasional completely missing process discovered at go-live.  Now that the caveat is out of the way, there are many reasons for the process problems: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and other reasons. 

The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting, 2) change management, and 3) testing. 

SAP / ERP Design and Blueprinting 

Your business probably developed numerous processes and exceptions over many, many years.  Some of those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent inefficiencies.  SAP projects are generally tasked with replacing all of those years of collective knowledge and processes, as well as any “broken” processes in six months to a year, and on very large projects in maybe a couple years.  That is no small task and to be successful it truly takes an experienced consultant.  As I’ve previously written about, this is one of those areas that all of the fakes end up costing your SAP project and your company big money.  And I mean big money over and above what you pay them.
 
A good blueprint should translate your scope into all of the key business processes that your company does, and then the key process components needed to support those processes.  I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs.  It should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements) development objects, and the key business areas affected.  If there is sufficient time in the Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.

Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared tensions by constantly dragging your project back into “Design” mode when you should be in full project execution.  It takes up the time and effort of other integrated teams, and generally causes a “drag” on the overall project.  Obviously this burns up budgets too.  Worse still, a poorly designed Blueprint is often blamed on the company, the department, or the key resource on the project who is responsible for that area.  Unfortunately those “smokescreens” are often used by consultants who are not that skilled at extracting the necessary information needed for a good blueprint.  It’s always easy to “blame” the client through the backdoor by putting the responsibility on a core team member, or some other portion of the company / client team.
 
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the process when it is encountered.  Frankly, if it suddenly comes up AFTER the blueprint is due, it should be seen as nothing but an excuse by the consultant.

ERP Project Testing 

Another area to begin addressing processes is during testing.  Any integrated application like SAP should include at least 4 primary types of testing.  No matter what name is used, they are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”) and then full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community often called “user acceptance tests” or “day in the life” scripts, etc.
 
During testing, while it is important to follow the scripts to be sure that all of the proper “boxes” are checked off, it is equally important to test more.  “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps.  Sadly some consultants (and some consulting firms) see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings.  As a result, they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and no exception processing is allowed.  There is a legitimate need to control the process to ensure that the work is done and that the known processes work sufficiently as designed, however there should also be some mechanism to address gaps or exceptions.  One simple method to accommodate this is to create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed.  Final signoff of the testing should not be signed off until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing you may wish to pick random documents from your current business operations to run those through the system with the converted data.  This will give you the best test to ensure things are working correctly.  For example, you may wish to choose 10 or more each of the sales orders, purchase orders, production orders, reports, etc.  The key is to use something that is meaningful and can be verified back against your current system.  

ERP Project Change Management 

Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were done before, there will be change management issues to deal with.  And unless you also re-write the user interface, there will still be training and user acceptance to accommodate.  If you’re going to re-write everything, why bother with a packaged system application at all?  On the other hand, if you are putting in a package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
 
Change management generally encompasses a few key areas:  Training, communication, organizational change, process / job changes, and post production support.  Some change management is necessary on every project and if your company handles change reasonably well it may not be a struggle.  However, if your company has many employees who have done the same job for a long time, without much change taking place within the organization it will take a tremendous amount of “hand holding” to get them through even small adjustments. 
 
You will need to assess your own organization and its ability to absorb change for whether change management resources should be budgeted.  From a project perspective however, one of the key things to be wary of are consultants who want to add new functionality without understanding the impact on the organization. 
 
Business Change Management analysis case in point:  I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen.  They had high dollar custom made steel transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation.  From a functionality standpoint it was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.  However, a more careful look at the organization showed a very different picture.  The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past.  Also, because of the organization there was virtually no chance that would change in the future.  

A less experienced consultant with limited project or change management experience would have seen this as a great opportunity to throw some “gee whiz wow” new functionality at a company.  They keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they’ve got a great candidate to blame for why you have to keep paying them.  Sadly I’ve seen this scenario played out over and over again.  On a recent project I saw this with the implementation of SAP’s Customer Service and Solution Database functionality.  The company had an “ugly” but mature and working solution, they were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low.  The consultant convinced them to “replace” their solution database and customer service functions from a CRM application that they did not even retire.  So there weren’t even any software license savings.  The consultant got to stay on, support an unnecessary process (the legacy app was not going away and worked fine), and was needed for post production support.  

 The process related issues will quickly separate experience from inexperience.  There are lots of good consultants out there, and then there are lots of less than satisfactory fakes in the market as well.  Unfortunately it is it the “good” consultants who are often penalized for smooth and successful go-lives by early roll offs.  Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly designed processes and inadequately prepared user communities at go-live.  The old adage rings true here that “you get what you pay for” as long as you have a way to separate the genuine articles from the fakes.  In the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not the least of which are the many hidden ways their SAP implementation approach impacts your business.  A truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the overall satisfaction of the solution it can pay dividends for many years.  

 In essence, the need for careful process understanding can not be underestimated.  The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations. 

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4
(custom development, costs and consequences of inexperienced developers)

Related Posts: