Business Solutions with SAP

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

August 26th, 2009 by

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

When implementing or upgrading SAP too often I encounter back yard mechanics who changed the oil on someone’s cars and checked the tire pressure–, somehow they think that qualifies them to do engine overhauls on Formula 1 race cars.

And just in case the analogy doesn’t seem to make sense, why again do you expect old-style implementation vendors and consultants to transform your business into a competitive powerhouse by only addressing cost-focused ROI and TCO methods?

What About SAP and ERP Cost Savings for ROI and TCO?

Sure, cost-savings and process improvements are critical today, and they can not be ignored or dismissed on any ERP project, but they can NOT be the key focus of the project either if you expect your company to gain any marketplace competitive advantage.

No wonder survey after survey shows C-level executives disappointed by the return on their ERP investments. If you want Formula 1 results in the marketplace, use Formula 1 approaches, methodologies, vendors, and consultants on your SAP implementation or upgrade. I must warn you though, most consultants and vendors are clueless at how to do anything but take you down the same old tired cow paths to marketplace obscurity.

A cost based ROI or TCO implementation or upgrade approach will never make you a winner in the marketplace.

It’s certainly important to save you a few bucks and reduce some of your overhead, but you can only squeeze so much out before something else has to give. There is nothing about it that makes you unique that can’t easily be copied by all of your other competitors in the marketplace. Worse still, sometimes when you are the first to implement all of these new process improvements and automation methods your competitors get your lessons learned on what worked and what did not when it comes time to modify their own processes.[FN1] You pay the R&D premiums for the trial and error which they receive the benefit of in lower costs and reduced time. Sure, they may lag a little behind but in today’s world I can assure you they are not that far behind.

With today’s globally competitive environment focusing on cost-based metrics alone will not make you win in the market unless that cost decrease is a game changer. Many of today’s modern companies are in the last few miles of business process improvement in system design–, the last few miles of “better, faster, cheaper” ways of doing business. The drive to reduce cost has become so extreme that to squeeze the last few pennies out of products and services companies now outsource entire factories, plants, and operations to Third World countries. But now everyone is doing that too.

Except for some game changing process transformation (which is not likely) the last few miles of process improvement yield the smallest gains at the highest cost. ALL of these ROI and TCO methodologies use lagging indicators to measure success. And lagging indicators will not provide you with the forward business benefit you need to win in the marketplace.

Dusty Old Trails – Why ERP Implementations Focused on Cost

The herd mentality is alive and well with ERP implementatoin vendors. Marching down the ROI and TCO road all I find are the same old worn-out cow paths cut in the brush that everyone wants to follow. In the technology arena, known for innovation, cutting edge transformation, and forward thinking, these old dusty paths are silly. Sure, these implementation vendors try to re-package their offerings, try to suggest a focus on ROI, but they only understand cost-based lagging indicators because they don’t truly understand business.

The Perfect Lagging Indicator of Cost Control

Here’s an extreme example of why these methods are dangerous, unless there is a significant improvement in cost without a significant impact in operations or marketplace competitiveness.

It is the PERFECT lagging indicator or the “perfect” accounting scenario. It is a set of perfectly balanced books, with no deviations, no discrepancies and no risks. It is the model of absolute simplicity. The books close immediately with no lag, and they always balance to the penny. It is the company with no employees, no inventory, no products, no services, no buildings, no assets, no expenditures, no shareholders, no nothing. It is an empty, hollow shell. But that is the “perfect” lagging indicator of accounting and financial performance. It’s also an extreme illustration of some of the silliness in the marketplace around ROI and TCO for an implementation.

Cost savings are an important part of any implementation or upgrade. But unless the cost savings are dramatic, unless they provide you with a major improvement in the “operational excellence” value proposition, they are often hardly worth the effort. Using lagging indicators such as cost-based measures of implementations or upgrades does little to alter a company’s competitive landscape.

The last few miles of process improvement (i.e. cost reductions) yield the smallest gains at the highest cost.

So why won’t it work? Unless you have huge process improvement gaps either as an industry, or compared to your competitors, you just don’t gain that much from process improvement initiatives alone. Should you avoid it? Of course not, it would be both silly and absurd to suggest you should not take on process improvement initiatives. Every little bit helps, there’s no denying that. But without dramatic changes most process improvement initiatives are little more than tactics when your business needs strategies to address your competitive pressures and revitalize your value proposition. And then this needs to be translated into your SAP ERP or CRM implementation–, you need solid, strategy-based IT solutions!

SAP’s Rarely Used Tools and Techniques for Strategic ERP Implementation

It’s always shocking to me to find out how many vendors, consultants, and sales people have no idea about the value and strategy tools and resources SAP provides. And of the few that do, most of them have little idea or understanding on how to use them because they are not experts, they are merely technicians. Along the way they’ve found or developed their one or two “wrenches” and they’ve found “cool” ways to convince you their tire pressure gauge is the best at working on your race car. They’re not Formula 1 mechanics they are oil changers.

With so many vendors and consultants who are not aware of the SAP value and strategy tools, or how to use them, how can SAP customers be aware of them? Few vendors or consultants understand business strategy, competitive pressures, value propositions, and how to integrate them into an SAP implementation of the ERP package or CRM. They know how to change oil and and show you their cool tire pressure gauges. Sure, they’ve got slick presentations to try to convince you their wrench or pressure gauge is really a super-secret James Bond gadget that can do magic, but if that were the case there wouldn’t be so many frustrated C-level executives over the lack of ERP results.

Now that SAP is a very mature product with significant market penetration the focus of the conversation is changing. CIOs, CFOs, and CEOs are now starting to cut back on their SAP budgets, ignoring upgrade requirements, running to alternate support vendors, and generally have little or no desire to go through a painful upgrade process. And the number one reason why this is all happening is because C-level executives are not seeing the return promised by all those implementation vendors.

For over 10 years that I know of many of these tools and techniques have been available freely to customers and vendors in one form or another. Even though they are not used nearly as often as they should be, SAP continues to develop and invest in them but somehow they keep getting missed. While all of those consultants and implementation vendors are out there tuning up their oil changing techniques, and trying to build better tire pressure gauges, the market marches on and C-level executives continue to challenge the ERP paradigm.

The Future of SAP is in Leading Indicators of Business Success Like Customer Acquisition, Customer Retention, and Revenue Generation

Surveys of CIOs routinely show that top priorities for their IT department spend is to focus on business related issues like customer acquisition, customer retention, profitability, etc. And implementation vendors are unable to articulate how an SAP implementation or upgrade can enable that to happen. SAP provides the tools and resources to make that happen but no software company can change the skills, talents, and abilities of the implementation vendors or their consultants. That is up to the educated ERP consumer to ensure they are actually getting what they are paying for.

Significant SAP and ERP Success Criteria will not Change Until Business DEMANDS that Fakes and Frauds are Removed from the Marketplace

Business must become more savvy at “looking under the hood” of their implementation vendors. Vendor claims must be more carefully evaluated and the skills of the consultants they provide more thoroughly vetted.

To this day I’m still shocked by the number of resumes I see which show some 5 – 10 years, and 3 or more full lifecycle implementation projects in a country where the individual making these claims can barely understand or speak the language. Again I have to ask how did they lead the requirements discussions sessions to know what needed to be set up? And how do they lead meetings and discussions related to markets, company direction, or required processes to support your business? And who wrote their portion of the blueprint or logged their issues or resolved complex process and integration problems that came up during the project? Just exactly how does someone who barely speaks the native language of the company they are performing the work for take care of the communication intensive knowledge transfer and change management activities? Are you getting the picture here? [FN2]

In other words, do you really have to wonder why your implementation didn’t deliver to your expectations when so many of the consultants you bring onto your project can hardly understand the language?

It’s a testament to SAP’s ability to deliver methodologies like ASAP, Best Practices, and other materials that there aren’t more lawsuits for all of the outright fraudulent “consultants” with completely fake resumes in the marketplace.

Is it any wonder there is little genuine business awareness on what tools and techniques SAP offers to take your business to the next level?

Too often these vendors and their consultants are just like the carnies at the County fair on the midway hawking their “better, faster, cheaper” midway games to the unwary. And just like those carnies, they’ve got lots of slick marketing, slick packaging, and supposed unique methodologies and approaches to solve your problem and deliver to you cost-reduction based ROI.

They replace your legacy transaction systems with future legacy transaction systems in the form of your SAP implementation. But they have no idea on how to use the tools and techniques SAP provides to realize value based on a strategic implementation method.

SAP Tactics, Strategies, or Both?

So here we are, back to the old back yard mechanics, the ones who checked their tire pressure and changed the oil on a few cars but want to overhaul a Formula 1 race car engine. Good luck!

Doing research for an upcoming book on using a strategy based implementation or upgrade approach to SAP I’ve read probably thousands of pages of academic articles, research information, and company websites about “ROI” with IT systems, and more directly, “ROI” with ERP implementations. Maybe one percent (1%) of the material I read contains any substance about strategic options for ERP. This seems to be a “mystical subject” where the Formula 1 mechanics can’t be found so companies continue to rely on tire checkers and oil changers to overhaul their race cars.

Companies undertaking an ERP implementation will continue to be disappointed until they begin to demand the Formula 1 teams and realize they may cost a little more than the backyard mechanics. They will be disappointed until they begin to demand real business consultants from the marketplace who understand and can communite about competitive pressures, value propositions, and change management about the SAP application in terms of:

  • Knowledge transfer
  • Change management
  • Competitive pressures
  • Marketplace performance
  • Supply chain integration with the customer
  • Customer experience
  • Customer or sales conversion
  • Product or service innovation
  • Niche markets
  • Joint venture opportunities
  • Product or service portfolios

and a whole host of business issues that the application can enable. That list contains BUSINESS issues, not application issues. How is a company going to achieve real breakthroughs in SAP or ERP implementations or upgrades with-out focusing on business reasons for the system? And even if you do, you still need to find the vendors and consultants who understand how to translate these business-centered strategic initiatives into application solutions.

Why, why do you buy a Formula 1 race car and then bring in backyard mechanics to work on it?

Some of the research I read is plainly misplaced, it is more like marketing material for the backyard mechanics claiming they have the answer to working on your Formula 1 racer. One research piece that tried to make the case that just improving processes alone “supports” goals of revenue and profit growth. Sure, that’s a marginally true statement, but business doesn’t just need the “support” that process improvement offers (unless there are large improvements), business needs a new IT focus.

That same research paper went on to explain that business should not be cutting back on ERP IT spend during tough economic times. And while I agree, it is for an entirely different reason. ERP IT spend should be preserved, but with a new focus and direction. That direction is on strategic implementation and upgrade directed at business benefit along with the tactical cost-based process improvements. [FN3] In other words, IT spend should be focused on producing business centered solutions and results, not just replacing transaction systems with cool new best practice processes.



[FN1] Change How You Look at SAP to create ROI

[FN2] Screening methods to find the right SAP consultant

[FN3] Why SAP Projects Fail to Deliver ROI (and how to change it)

Related Posts:

SAP Development Landscape and Systems: Misguided Practices Carry Huge Costs

August 15th, 2009 by

SAP Development Environment and misguided Basis practices

Anyone who has implemented SAP for any period of time has seen the classic three tier system environment.  You have a Development landscape, QA landscape, and then a Production landscape.  Classic scenario is that you do your prototyping, system setup and design, and just initial first pass validation in the development landscape in the appropriate client. 

When it comes to development environments a consistent pattern has emerged where the Basis team will trip over buckets of dollars to save a few pennies by either painfully sizing the Development environment, or, at some point in the project they will pull so much hardware from Development for other parts of the landscape that the system just barely limps along.  And sometimes it doesn’t even limp or crawl, it just dies!
For some reason they and the client project management are unable to see that the cost of software licensing and consulting time in comparison to hardware makes even the best stuff really cheap.  And I mean absolutely dirt cheap by comparison.  Even the vaunted “heavy iron” hardware from some of the top tier vendors is still comparatively cheap. 

However, along with the relatively inexpensive hardware there is a second area that trips projects up and is probably the trigger for a lot of the hardware cost–, poor developer coding and poor database skills.

Even though these issues exist, and hardware is “relatively” cheap, after over 20 SAP projects I’ve seen a consistent Basis pattern that drives me berserk.  They KILL the Development environment’s performance when it is still needed for ongoing project or support efforts.
For some reason the folks in Basis never seem to understand the impact on the overall project when they do this.  The Development environment (in my opinion) does not have to have the same super-high-availability, ultra-redundancy, supercharged performance parts that the production environment does (but yes, it should generally be the same family of hardware for consistency purposes), but it should run well!  

For all you Basis gurus out there, have you ever considered what the actual cost to the company is of saving a couple dollars in pulling every bit of memory, processor, hard disk, and anything else you can get from that box actually costs your SAP project in real terms?  Okay, I’m fine with temporary pulls where you have to wait for replacement parts because the production system needs a boost, but come on, long term?

For companies that have “Basis” consultants who can’t seem to get the hardware properly tuned you may not have a qualified consultant. 

SAP is resource intensive, but it is quite capable of working in a distributed environment where you have a separate application server and a separate database server.  Or for that matter, multiple application servers where you can either load balance, or have one set of users logging into one app server and a different set in another.  

On top of that, SAP provides a significant number of performance monitoring tools if your Basis consultant has any idea how to use them.  They can evaluate custom program processing times, long database query times, search for SAP OSS notes for performance, and a whole host of other options.  Most often I have found that major processing problems are because there aren’t a lot of SAP Basis consultants who really understand database administration well enough to know how, when, or why to build custom indexes, or when to have a custom program reviewed for efficiency and performance improvements.  Those are just a few of the reasons SAP Basis resources struggle with maintaining decent system performance.

Here are some of the costs (both hard dollars AND in terms of risk to your project and company):

  • Transactions become so slow that high priced consultants are literally sitting around waiting to process.  Multiply that by the number of consultants, and the number of transactions, and the amount of time.  It can add huge $$$$ unnecessary cost to your project in wasted time and effort.
  • There is additional time wasted by the consultants bugging project management, the basis group, the client, etc.  This is a distraction waste that not only eats additional billable time, there are real costs associated with lost opportunities of those key individuals working on other pressing issues.
  • There is the “frustration factor” as well that unnecessarily creates a poor working environment for any kind of performance.  If you’re a project manager that believes in trying to develop “momentum” in the pace of your project, watch how fast a choked up Development environment can kill any momentum you build.  Then try to re-establish that momentum!  Good luck! 
  • End-users are given a bad impression when they access a Sandbox or other development area to try out other transactions.  User acceptance is compromised and the rumor mill starts about how badly the system runs.
  • The ability to test run “what if” scenarios, or other types of trials in a safe environment before trying it in a production system is compromised (once you are operational).  More wasted time and frustration.
  • Knowledge transfer is compromised in a painfully slow development environment.  Especially by any extended users who want to work in a safe environment before, during, and after go-live.  If the system is slow enough they just won’t bother.  This creates a more intense “valley of despair” as it is referred to in Change Management.  And that “valley of despair” is the productivity drop off that occurs right after go-live and continues for some period of time.  Effective knowledge transfer makes that “valley of despair” more shallow and not as wide.

You get the point.  I’m sure if I spent more time pondering it there are lots more reasons.  But this has got to be one of the absolutely dumbest practices I have ever seen consistently carried out on SAP projects.  I’m not opposed to stripping hardware from a Development environment, but the minute that Development environment’s performance negatively affects the people who use it the Basis team is not effectively carrying out their project responsibilities.  And that main responsibility is to ensure a technical landscape that supports the project and the company in an efficient manner.  So, the next time you are tempted to gut that Development landscape ask yourself, how much hardware can you take that will NOT negatively affect the landscape and would it be more cost effective to buy more hardware?

Related Posts: