Business Solutions with SAP

CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?

September 19th, 2009 by

CRM, ERP, BI, and IT investment, where is the business benefit?

Retool, retool quickly!

Most companies want to use CRM applications as a way to “supercharge” their sales forces.  They want to gain some advantage with customer retention and acquisition, to manage the sales pipeline and to have better market insight.  But few companies realize these goals. 

After going through some of the academic studies and literature about CRM implementation there is evidence to suggest that some companies see some limited benefit from their CRM implementations, but overall they are not happy.  These anecdotal accounts show the primary reasons companies benefit from their CRM implementations at all is because the project itself causes the company to look more closely at their customers.  Even then, with few exceptions, the way the CRM software is often implemented does little to provide significant market-focused benefits.

It doesn’t have to be that way, and you as a customer can change it. It’s not the SAP CRM application that is the problem.  Between CRM, ERP, and BI, the tools are all there, but an instrument in the hands of a journeyman musician sounds far different than the same instrument handled by the journeyman’s apprentice, or a novice.

Where Things Get Off Track on CRM projects – Why CRM Projects Go Bad

Most SAP CRM implementations relied on retooled, post-Y2K HTML and Java consultants who flocked to the CRM space. Because the SAP “New Dimension” products were new the screening was not sophisticated and the experience requirements were low.

These web techies had little or no business experience and certainly little (if any) understanding of competitive pressures, value propositions, business strategies to retain or acquire customers, or a whole host of key issues that a good CRM consultant must know.  They were (and still are) completely clueless about marketing, customer / sales conversions, product development cycles, solution databases, improving service cycle times, etc.  They might know how to set some switches, or make some coding changes, but they have little ability to help transform your business or in how to move you forward in the marketplace.  Basically they had little, if any business experience.  

These consultants learn to talk the application talk, and they can spout some of the tools available, but when you drill down deep into their experience you find they are an empty shell.  They are like apprentice “musicians” who can read a few notes on a page of sheet music but they lack the years of practice and do not have the musician’s “soul” to understand and appreciate business.  These application technicians lack the critical transformational understanding your business needs.  True CRM success stories require consultants who have some measure of business or marketing background, not just an IT background. 

If you’re running a Formula 1 race team you don’t go to your nearest garage with a great tune-up special and hire them to do your tune-up before a race.  They MIGHT be able to keep the car running but you have no chance of winning the race with their expertise.  Their garage serves an important purpose, and it fills a particular niche, but if you are looking for race winning results they are not the right folks for the job.

Do CRM Consultants or CRM Vendors Know What You Need? 

What are your goals, your reasons, or your business triggers for doing CRM, ERP, or BI applications?  Did your implementation vendor assessment or consultant review include a detailed exploration of exactly how they would help you achieve those goals? 

Does the vendor or their consultants have any real business change management experience to help focus the company on a commitment to the customer experience?  Do they have the critical communication skills to support a communication program to the larger organization about the crucial role the new CRM application will fill?  Can they help guide the business in understanding how each person’s job or responsibility affects the marketplace, how the ERP system extends into the supply chain, or how the BI system supports the key data for reporting on various goals and performance metrics?  Do they even have strong enough communication or language skills to have actually done the things they claim to have done before?

At the start of the CRM project, did they explore where you might gain value in customer retention?  Do they even understand general sales, marketing, business, or operations concepts around customer retention?  Did they ask the critical questions showing they know how to define what you need to improve the quality of your customer touch points? Does your CRM implementation vendor or their consultants have a clue? 

I find it funny that to this day I frequently receive calls from recruiters and companies who are interested in me helping them do a CRM project.  This is even though I make it clear that I have no SAP CRM experience and my resume does not list any SAP CRM experience.  However many customers are beginning to realize that the SAP Sales and Distribution background (SD), with its sales and marketing implementation focus helps to ensure good integration between the CRM application and the ERP product, as well as the business experience that a good SAP SD consultant has.  On top of that, many highly experienced SD consultants have developed customer focused reports and tools to address some of the customer issues.  As a result a solid SD consultant has a fair understanding of the types of data points and BI reports that are necessary to report on.  An SAP SD consultant who is skilled and diligent has also encountered many of the issues related to customer retention and customer acquisition.

First Things First – Basic Business Strategy 

The difference between an application technician and a business consultant who knows the application is in knowing what questions to ask to determine what the true underlying business need is.  Even when technicians learn the business need they often have no idea how to convert that into a solution outside of their very narrow focus.  For example, if you have service or repair requests that seem high, do you focus on solving a quality problem, or on shipping processes, or packaging, or other reasons? And to resolve these issues, do you have or need a solution database?  Do you need some form of Engineering Change Management process integrated within the Customer Service processes?  Do you need Quality Management (QM)?  Is full blown SAP style QM overkill?  Is there a way to promote customer self-service with solving some of their own problems, both to empower them and to reduce your own internal costs?  Did the ERP or CRM consultant have basic business and troubleshooting skills to ask such questions? If you want ROI for IT expenditures, if you want SAP ERP, CRM, BI, or SOA to deliver business related results, start asking business questions about why you are looking at any technology spend to begin with: 

  • How do you determine customer needs and wants?
  • How do you track changing dynamics in customer needs and wants?
  • How do you convince your customer base to execute a purchase based on their needs or wants? 
  • How do you anticipate new products or services your customers may need or want next? 
  • How do you track market spend to new customer or enhanced existing customer product spend? 
  • Do you measure, or need to measure cost per lead and then lead conversion rates? 
  • How do you compare to your competitors? 
  • Is, or should, opportunity tracking be embedded into the customer service process? 
  • Do you know what opportunities can be converted into new customers or into new (or enhanced) products or services? 
  • How do you track opportunity costs? 
  • Do you link complaints / repairs / service / opportunity reporting back to customer attrition? 

Does your BI consultant know what to ask or do they just ask you what reports you need?  In other words, what are you paying them for?  To make a few system settings or for some business benefit?  How often does a completely accurate order get to the customer on time?  How quickly are orders processed through to delivery, and then how long does delivery take?  Are order to receipt to cash cycle-times in line with your competitors, and can you beat your competitors without additional costs?

In other words, if you want ROI it is going to take a genuine focus on the business drivers for why you are even considering some IT application to begin with.  And if you want the greatest return, and the best competitive posture in the market it will take some effort in finding consultants who not only know the application but who understand business as well.  Without them all you get is another IT application when what you need is business transformation.

Even if your consultant or vendor did some homework and started asking you some of these questions, do they have the depth of experience or business insight to help you understand how to convert your answers into real solutions? Do they know how to help you bridge the entire supply chain process all the way to the customer whether it is in the “back office” ERP application and its direct or indirect connections to the CRM system?

Until you as a customer begin to demand that consultants and implementation vendors come to the table with real business experience nothing will change.  It’s time that IT decision makers started demanding that their short list vendors demonstrate an ability to SOLVE real market based problems that you are facing as a company.  SAP’s ERP products are mature, the consultants to implement and support them have been around for some time, start insisting that vendors present “A” list players to even be considered for a short list. 

Start asking the tough questions from a business perspective and be more proactive in managing the vendor resources you select.  You might finally see the results you’ve been looking for.  And in case you think you can ignore this, not only are you facing economic and global competition pressures, there are new pressures emerging as well with technology itself.

A Technology Change that will Force You to Work More Closely with Customers 

Recently Google announced the availability of “SideWiki,” it is a web browser add-on to Internet Explorer or FireFox that allows users to comment on any page, of any site, anywhere. It also allows others to see the comments that are left.  So if you think you can hide from the Internet or from your end customers any longer, perish the thought. 

If you don’t already have some type of online “customer community” you had better develop one right now.  You can no longer control the message and your PR or marketing departments can no longer cover for inadequate customer focus.

At least gain some ability to understand and address your customers before there is more widespread adoption of these kinds of customer feedback tools over which you have no control.  Do you need an online “customer community” to be able to more directly and more carefully address customer concerns before they get reported to some of the rating and complaint services?  Or, outside of the CPG (Consumer Package Goods) space do you need to move further into the value stream to find a way to get close to the end customer of your product or service?  Should this online community also support gathering marketing intelligence, new product or service ideas, and generally engaging customers?

Are there areas of your customer experience where you must rely on third parties who are not as focused on customer experience as you are?  How do you measure and track that interaction and then how do you change it?

Even if these consultants manage to ask the right questions, do they know how to convert the answers to those questions into real solutions that meet business needs?  After all, there is lots of great source material right here in this article, and much more on my web site.  But asking the right questions and converting the answers to those questions into business solutions, generating solution scope, determining the right technologies and then understanding what is needed to bring the organization along behind this type of strategic initiative is an entirely different matter.

In other words we’re back to the same issue as I’ve written about in doing ERP implementations, what is the business reason for the IT investment?  Why are you putting CRM in?  Do you need CRM at all?  Do you need a different solution?  Are you better off investing in BI or would you be better at working through process issues and using SOA to embed yourself further into the extended value chain? 

This and many other articles point out the importance of having a focus on business needs, market forces, and competitive pressures for finally realizing business benefit and ROI from your implementation.  This type of focus can’t be achieved by technicians, even skilled technicians who might be talented at setting up a particular application.  A system alone only processes information and no system will change your position in the market.  However, done properly, and with the right strategy focused direction, a well-deployed ERP, CRM, and / or BI system can empower your company to more aggressively and more effectively compete in the marketplace.

Additional Resources on ROI, TCO, Business Benefit, Revenue and Profitability with ERP Projects:

Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP

Using SAP to improve Revenue and Profitability


Technology Evaluation Centers Listing:


Related Posts:

Opportunities for INNOVATION SAP, HELLO?

September 19th, 2009 by

SAP Opportunities for Innovation

What if some little guy like me–, a lowly contract consultant came along and said “SAP, I’ve got some really, really great ideas on how you can dramatically change the application for far greater success in the marketplace!” 

What if it would make a significant change in the usefulness of the application, AND would not cost that much in developer time or resources. 

What if it could be done with almost completely pre-existing functions, functionality, and code that SAP already has but has not done a good job themselves of integrating?

Low cost, high benefit, game changing scenarios in the ERP application space.  Game changing because the changes below and many more I know of cover the vaunted three areas of value proposition all at once–,  product innovation, operational excellence, and customer experience.

What if these changes demonstrated enough benefit to create a compelling case for version upgrades without expiring support as the reason? 

What if these changes made it an easier sell into the Small and Midsized Business (SMB) space?
Would SAP take up the cause?

I’ve got just such a set of propositions for you.  Just the thing to completely change the ERP competitive landscape and move the application to the next level without much cost, complexity, or difficulty involved.
Remember when you paid millions upon millions of dollars to do the “EnjoySAP” design work, employ the consultants (internal and external), developer coding, and lots of expenses to build that user experience.  I’m giving you the next generation application process FREE and it will make a huge difference in the application experience. 

SAP, knock, knock, anybody there?  You know basic value proposition issues like “customer experience” leading to better user acceptance.  These and other solutions also cover the operational excellence value proposition of reducing the post-go-live change management “valley of despair”?
SAP, what if I can deliver without all the bucketloads of cash you paid for “EnjoySAP”?  Are you interested?


Years ago I remember when SAP embarked on a transformation project called “EnjoySAP.”  The idea was to design the application to be more user friendly, and to be just plain more usable.  Along the way we ended up with a new GUI interface and lots of “N” transactions for the new interaction paradigm.  That was about 10 years ago.  It’s time for a change…

SAP has the ability today to add tremendous value to its transaction processing and to be able to take the application to the next level by doing a few “relatively minor” changes.  These would appear to be dramatic changes on the surface, but underneath they are relatively simple and low cost.  Best of all, all of them can be made 100% backward compatible, and most of that even without having to use a “switched framework.”  How’s that for benefit?
Most can be done with few or no core application code changes to existing transactions, and even when there must be a few changes, they can still be done without tremendous difficulty.  Even when those changes are necessary, SAP can simply incorporate its “switched framework” for coding enhancements and add the switches to the IMG to give customers the option of using the old, existing ways, or the new, significantly enhanced methods.

Here we Go…   

For many years I’ve done full-cycle, full-module, functional configuration in SD, MM, and PP.  Along the way I’ve encountered some interesting things that have made me wonder why in the world SAP hadn’t done more work on application “usefulness” to the end user.  We’re talking one of the vaunted three value proposition pillars here SAP –, “customer experience.”

DIMP solution add-on transaction, ADSUBCON 

The SAP subcontracting functionality has always been a royal pain in the backside.  Separate t-codes for nearly every process, separate inventory management processes, separate stock report t-codes (forget about MMBE here), you name it.  Overall it is a disjointed and painful process.  However, one day on a DIMP project at an automotive company I accidently ran into this absolutely amazing subcontracting processing cockpit transaction called ADSUBCON.  It is probably one of the most useful, well thought out, and well-designed transaction options in the system.
Why isn’t this included in the core application for every customer, whether they use DIMP or not?  SAP, are you listening?  This is a BIG win for end customers.
This “cockpit” paradigm should be extended to other process areas of all of the modules.  Simply create the transaction code process flows, with all of the options, and enable configuration to be done to include or exclude certain transaction “buttons” or “options” in the cockpit.  Here are the advantages of the cockpit paradigm.  Users are exposed automatically to the full breadth of the process so they gain a more holistic business process perspective (even if they can’t execute certain transactions).  Knowledge transfer and usability are facilitated by the common look and feel of the cockpit.

ME21N – Do we need a VA01N? 

One of the really useful functions in ME21N is the document overview and the ability to drag requisitions to the shopping cart to create new POs.  Why doesn’t this exist for Sales Orders?
Come on SAP, you could easily incorporate the VA05 transaction processing behind the scenes to make this more usable.  The VA05 could be the document overview like what is used in ME21N.  The copy control could easily be used to copy document to document, or item to item.  And on top of that, depending on how the transaction is structured, it could also include a list of the last X orders / deliveries / invoices (based on configuration settings) for that Ship-To party as soon as that customer number is entered and you press ENTER.  Wow, now that would be useful.
On top of that, the development for a lot of this has already been done in several function modules that are used for the R3 Internet Sales application.  What are you waiting for?  This would create a dramatic change in usability for a key transaction string.  Along with that it would not require a huge amount of development work. 
SAP, can you see the benefit to the end customer who uses these transactions?

Document Flow in MM and PP 

The PO History was a good start in the ME”xx”N transactions, but this should be extended to material documents, accounting invoice displays, etc.  This was done in SD and has been a tremendous asset and help for troubleshooting, understanding document history, etc.  Why hasn’t this same paradigm been applied to MM and PP yet?  Come on SAP, the info is already there, it’s not that hard to attach the data.

Pricing, Schmicing, SD-MM coordination 

This one would require some re-design but in the end it would be worth the pain.  I’ve always been baffled by the “differences” between SD “Pricing Procedure” maintenance and MM “Schema” maintenance.  A significant amount of the backend plumbing, tables, etc. are the same between the two modules.  Even a lot of the programs are the same but are separated by application area settings.  Why again are they named differently?
In reality lots of these things should be made exactly the same, but in reverse.  I’ve even been on many clients where they wanted to do similar types of posting functionality that is available on the SD side but on the MM side.  Instead of revenue accounts, maybe expense and liability account determination. 
The consistency in naming conventions in the IMG for SD and MM pricing would be helpful.  The similarity in functionality would open doors to more consistent thought and condition setup leading to better business benefit.  The ability to be able to drive more granular General Ledger level spend tracking on PO’s by having similar functionality to SD’s Revenue Account Determination functionality would provide greater ability for business to track discrete components of the competitive pressures that vendor power creates.

Making the pricing processes both similar and just as robust on both the SD and MM side, along with the expanded FI integration opens a whole new world of possibilities for business.

Output Processing WMTA-Style 

On nearly every project I’m on there is always some request to automate this transaction into that one, etc.  The process chain automation seems to be a consistent and routine theme no matter what module it is. 
Over the years I’ve used Lean WM and the Auto TO creation through the standard WMTA condition. 
This paradigm is a great solution to performing any kind of auto processing throughout the system.  Because of the number of BAPIs and Function Modules that are already produced for most of the document creating (or changing) transactions, this would be relatively easy to do.  Simply include a BAPI or function module in a condition to create the follow-on document and pass the data to the function module or BAPI through the print program.
This solution is tremendously flexible because of the ability to control the individual behavior of each output through the use of the condition technique and access sequences.  What a great way to get the job done!
On top of that, you could develop a standard print program with all of the standard supported output options, and a configuration switched framework that uses the application area and standard or custom condition type to be processed.  Then unnecessary processing would not be required, only a single print program would need to be maintained, and the output condition could have its own separate BAPI or function module assigned.
Do I hear highly flexible workflow without all of the difficulties, pain, and setup work of normal workflow?  This is a great way to enable business process flows with standard functionality and standard programs for processing or re-processing outputs.  This is the type of innovation that small and midsized businesses badly need.


SAP, if you’re listening at all, I have many more areas where you can substantially improve the ERP application, without significant expense, time, or resources.  These and many other improvements begin to provide a compelling case for upgrades even without support ending.  Between these and several other ideas I have you could make the case so compelling for an upgrade that it might create a rush to “keep up with the SAP Jones’s” so that their competitors don’t gain too much of an advantage.
With some of these enhancements, the case for ease of use, business process focus, and innate knowledge transfer are so strong that it provides reasons for small and midsized business sales as well.  
If you’re listening and interested have one of your key developers from Palo Alto or Waldorf call me.  After over 20 implementation projects I have a pretty good idea what customers are looking for and what is meaningful to the small and midsized business space.  Let’s work together to “supercharge” the ERP application and in the process shoot for 90% of the entire ERP application space!  It’s time for order of magnitude changes on the customer experience and business process side of the house.

Think about it, these changes cover the vaunted three areas of value proposition all at once–,  product innovation, operational excellence, and customer experience.  How could you possibly go wrong! 

Related Posts:

ERP Failure: The Organization is More Than Partially To Blame

September 15th, 2009 by

Organizations must take ownership of their projects for success

You really have to wonder, does any organization spend millions of dollars on SAP (or any other software) with the goal of failing?

The scope of a typical ERP project impacts almost every aspect of the organization and the implementation risks are real. It is not unusual when actual project timelines exceed the original schedule by well over 100%. The cost of consulting services alone can grow to 4 – 5 times the cost of the ERP software (with even greater upside risk potential). Finally, we have all heard the horror stories…expensive ERP initiatives that never go-live, or worse yet those that do and hamper the business for years after cutover. That is in spite of all the “proven implementation methodologies”, an alarming number of ERP projects have unhappy endings.

While the help of consultants is probably required, leaving the fate of your ERP project in the hands of consultants in many cases only creates a false sense of security. Regardless of the right intentions and what we may like to believe, software consultants are not all knowing, they benefit from cost overruns, and in the end have limited control of the key factors that enable ERP success (discussed later).

Software consultants certainly want the client to succeed, but in world of ERP consulting the game is “billable hours”. When it comes to ERP software vendors I can say only one thing, regardless of what the sales people claim the software can do, they will be long gone when it comes time to implement.  Therefore, more internal project responsibility, ownership and managing vendors is the key to developing better business solutions, mitigating project risk, and significantly reducing implementation cost.

In many cases consulting firms or software vendors take the heat (and lawsuits) for ERP disasters when in fact it was the organizations own doing. Any list of the “top five reasons for ERP failure” makes it clear the organization is more than partially to blame.

When the client becomes disengaged and the project falls hopelessly behind schedule, consultants are left with no choice but to do it on their own. This not only feeds the consulting cost frenzy but management is left scratching their heads wondering why their ERP software (used successfully by many in the same industry) failed to meet their business needs.

Yes, many clients like to blame software vendors and consultants for their ERP failures; and in many cases it may be true.  However, guess who bought the software and selected the consultants? On the other hand, why would any consulting firm not want the client organization to be knowledgeable, feel accountable and fully engaged?  Sure consultants make a lot of money on uninformed or disengaged clients, but no consulting firm wants a black mark on their resume.

The reality is consultants and software vendors have no direct authority to “make” management or anyone else in the organization to do much of anything.

Consultants can provide expertise, perform tasks, make suggestions and can “insist” on many things; but at the end of the day only the organization can:

– Insure executives are educated, on board and understand their roles.
– Own the business case and drivers for the change.
– Clearly define, own, and communicate project objectives.
– Implement internal measurements systems to support the desired changes.
– Approve and contain the project scope.  
– Require (not just sell) the cooperation of employees at all levels of the organization.
– Assign the right internal employees to the project team.
– Free-up the required time for those assigned to participate.
– Expect (not hope) the internal team and IT support eventually become software experts.
– Hire as internal employees people with the right skills and knowledge when necessary (you will need them longer than you think).
– Plan and utilize outside project management, application consultants, technical consultants, and programmers correctly.
– Hold functional (middle) managers, the project manager, the project team, and IT staff accountable for doing what they are suppose to do.
– Make necessary changes in business policies, practices, and procedures to take advantage of the software.
– Limit software modifications through business justification or changing business processes.
– Remove the people barriers and naysayers that get in the way.
– Tackle project business issues and decisions in a timely fashion.
– Take end-user training seriously and require employees attend.

No matter how great your consultants or ERP software, these are things only the organization can really do. In addition, these factors have the biggest impact on project success. Finally, they are just a few more reasons why consultants and software vendors cannot save the day (or own your project even if they want to).

No one said it would be easy; but an important question to ask is….. Why would any management team spend hundreds of thousands or perhaps millions of dollars on ERP with the goal of failing? The other question is: Do people rise to senior management levels within most organizations because they are totally incompetent? Generally the answer is no. So what gives? One answer is organizations do not plan to fail rather they fail to plan. However, it actually goes much deeper than that.

Implementing an ERP system is not something most organizations do every day. Unlike more frequently occurring internal projects such as new product development or pure technology projects, not everyone knows the ERP implementation drill, subtle pitfalls, and the consequences of certain decisions.  ERP comes along every ten years or so and the opportunity for learning through repetition simply does not exist. Also, those involved with the previous ERP project have probably left the company or want to stay as far away from this project as humanly possible.

The good news is ERP project management deals primarily with management issues that decent managers can understand and do something about. The old saying “you don’t know what you don’t know” certainly applies. However, successful ERP does not require a PHD in computer science but a management team with practical insight, some common sense, and one that is willing to expect something from internal folks. No doubt, some outside coaching from consultants is normally necessary but this is very different from a “consultant driven” project.

Believe it or not, management can understand what must be done, the important questions to ask, the key decisions to be made and the potential implications of those decisions. Furthermore, this can be accomplished without spending a boatload of money on outside consultants. In addition, companies can develop and/or acquire the internal software expertise to be successful. Organizations have been doing this for years and ERP is really no exception. Contrary to popular belief, the need for the right internal skills and software knowledge does not end when the system is initially implemented. That is unless you want to spend a fortune in consulting fees for many years after go-live for the support typical of any ERP system (on-going training, configuration changes, future phases, upgrades, etc).

In many ways, controlling your ERP destiny is about getting “street smart” on how to implement ERP; since there are plenty of important things that most consultants and software vendors are not going to tell you.  This enables the organization to engage their project, leverage internal resources, manage vendors, and make informed decisions that yield predictable results.


The author runs a blog called “Street Smart ERP” from the perspective of an ERP practitioner with over 25 years of IT and ERP experience.  For more information please see

Related Posts: