INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Implementation Projects: Still Crazy After All These Years

August 16th, 2010 by

R3 Solution

The following is re-posted with the permission of my friend Michael Doane, see his site at http://sapsearchlight.blogspot.com/

———————————-

Through the good graces of my long-time associate Jon Reed (www.jonerp.com), I recently discovered a blog that covers the life of an SAP project: SAP: Loathe It or Ignore It, You Can’t Like It http://sapmesideways.blogspot.com/.

Shortly thereafter, Dennis Howlett posted about this blog “Your Implementations are Killing Us” http://blogs.zdnet.com/Howlett/?p=1075 and the next morning I received a frantic e-mail from a friend at SAP lamenting its posting. So I guess this blogger is gaining some buzz.

I take exception with the title of the SAP blog as I have seen countless clients who actually do like SAP. All the same, I find it a curious and worthwhile contribution. The writer maintains complete anonymity throughout. No profile or mention of his name, his company’s, the implementation partner’s identity. Mum. While this is largely understandable as a matter of the blogger’s self-protection, it also degrades the effect. All the same, the twenty-seven postings since January, 2009 vividly describe the mind-numbing frustrations, side-shows, and cul-de-sacs that a poorly-run implementation can engender.

The appearance of this blog is in parallel to some serious SAP head scratching on the subject of bad implementations. At the end of the day, when an SAP implementation project goes wrong, it is the joint fault (in varying measures) of the client and the systems integrator but it is usually SAP that gets the PR black eye.

I have been involved in SAP implementation work since 1995 and the balance of my book “The New SAP Blue Book, A Concise Business Guide to the World of SAP” provides guidance for the best practices for implementation. The book first appeared in 1998 and has been revised seven times as better practices continue to emerge. During this same time-period, I have done a considerable amount of primary research with more than 1500 clients reporting upon their SAP experiences and the performance of their SAP systems integrator.

SAP does not deserve the full black-eye for failed implementations. In my esteem, however, SAP does a poor job of policing its SAP partners. The 1500 clients reported upon the field performance of all of the leading integrators (Accenture, IBM, Deloitte, et al) and the following provider failures were chronically noted in regard to deficient project process (in order of importance):

  • Poor scope/resource management
  • Lack of adherence to methodology: all the systems integrators have sophisticated methodologies and tools; they just don’t use them consistently (if at all);
  • Ineffective partner management.

In this research, clients cited who they considered responsible for various issue. They tabbed themselves the guilty party for:

  • Over-engineered and difficult to use results
  • Insufficient post-implementation planning
  • Lack of client ownership.

What SAP Can Do to Address Implementation Issues

All the systems integrators, including SAP Consulting, regularly tout their client satisfaction ratings. When you scratch the surface, these ratings tend to be childish and generalized buckets for entire projects of Very Satisfied, Satisfied, and Not Satisfied. The first reaction is to ask who is satisfied, what are they satisfied with, and when were they satisfied. Many clients I have spoken to who claimed that they were satisfied added that the whole project was a bumpy nerve-wracking mess but they were finally satisfied that it was over.

In this light, SAP needs to finally recognize that implementation services are every bit as much about consulting as about software. While tools such as Solution Manager are excellent for tracking software issues, project issues relative to consulting, governance, etc. are not tracked. SAP should be working more closely with its largest implementation partners to create client-satisfaction tracking that continually addresses these issues from an SI perspective:

  • Business/IT Alignment
  • Governance & Control
  • Human Capital Management
  • Technology, Tools & Process
  • Service Delivery & Operations

Short of this, SAP should create and cultivate a network of objective, third-party quality assurance units (not SAP, not SAP implementation partners) to accomplish this tracking. When such a QA unit exists, life is better for both the client and the systems integrator as in many cases the QA group can point out to clients where they are going wrong. Again, each of the systems integrators have their own internal quality assurance but it is seldom demonstrably objective. By the same token, such QA should not be undertaken by SAP.

Quality assurance can add 1% to 2% to an overall implementation budget while resulting in a 10% to 30% savings in over-all implementation costs (primarily by fending off budget over-runs).

Value to Clients of Third Party Implementation Project Quality Assurance:

  • Cost containment, derived from progress monitoring
  • Time adherence, resulting from continuous (phase to phase) monitoring as well as scope management
  • Vision/benefits realization: assuring that the project will deliver the intended business value
  • Reduced administrative and strategic burden; fewer client/SI meetings for the purpose of progress reporting, issues management, and the like
  • Objective advisory as to what other services or support functions might be appropriate and desirable.
  • Quality assurance reporting would be most effective if it is directed to the client, to SAP, and to the systems integration partner.

In the field, I find that systems integrators initially balk at the inclusion of third party quality assurance on the premise that it will act as an audit of only their performance. Once they understand that the quality assurance role also focuses on client performance and SAP performance, the activity yields positive results.

It should be noted that the SAP/SI partner dynamic is not the same for all partners. Clearly, IBM and Accenture are not as malleable as a small partner such as Capgemini or any number of boutiques. However, it is evident that scrolling a third-party quality assurance activity into any SAP implementation will benefit all three parties (client, SI, and SAP).

It is probably too late for our anonymous blogger. I look forward to when he fills out his satisfaction rating.

—————————-

The original posting for this article can be seen at: http://sapsearchlight.blogspot.com/2009/07/sap-implementation-projects-still-crazy.html




Popular Searches:


  • ERP Project Names List
  • Best ERP Project Names
  • sap project names list
  • sap project name ideas
  • sap project implemation name
  • sap project hindi made
  • sap implementation project names list
  • sap implementation project names
  • project names for SAP implementations
  • names of projects for SAP implementations
  • name of the sap implementation project at trident
  • list of names given to to the sap implimentation project
  • erp project name suggestions in hindi
  • best sap project names
  • suggestion of sap project

Related Posts:

SAP Implementation is an Investment NOT an Event

July 12th, 2010 by

InvestmentThe other day I was talking to a pair of executives looking for a way to determine whether or not their SAP implementation cost was higher or lower than their competitors.  They had wanted benchmarks or some other way to know if they were in line with the marketplace.  The CFO was worried that they might have paid way too much for their SAP implementation.

After talking for a few minutes they realized that they were looking at the question the wrong way.  While they were asking about how their expenditure compared with other competitors, what they were having a hard time articulating is whether or not they got what they paid for.

I provided them a simple illustration to drive the point home quickly–, if they spent twice as much as their competitors, or if they spent half, what matters is the return on technology dollars.  The numerical illustration I gave them is if they spent $50 million and their next closest competitor spent $20 million, they are looking at the wrong thing.  What really matters is the return.  If they achieved a 10% financial return from process improvements, automation, task time reduction, etc., and their competitor was achieving a -3% return then even at 2 ½ times the cost of their competitor they got the better deal.

By the time we finished the conversation it was clear they were asking how to measure any return or business results they received from the implementation.  However, from the conversation it didn’t sound like they were very happy with their results.  And this leads us to the issue of whether you are focused on service delivery or business benefits delivery.

Control SAP Implementation Costs and Promote a Return on Investment by Focusing on Investment Drivers

The best way to understand how SAP can benefit your business is to start out by understanding what you are trying to accomplish with an SAP implementation.  This in turn will determine what your success criteria is and that success criteria is a critical factor in value realization from your SAP implementation.

As SAP Blue Book author Michael Doane says “just because a project is delivered on time and on budget does not make it a successful project.” To wring value out of SAP it must be seen as an investment, an important component of your company’s growth, its long-term health, and part of the investment portfolio much like capital equipment or financial leverage.

This investment paradigm out of necessity includes a component of return on that investment, and a view of the investment that goes beyond the delivery date for the project, therefore it must include more than a project that is delivered on time and on budget.

You wouldn’t define a successful stock investment as spending the money and then receiving the stock, over some period of time you would want a tangible return on your investment.  You should begin with that mindset from your SAP implementation.  Also, you generally wouldn’t expect that return the day you purchase the stock either.

———————————–

Stay tuned for the next installement, “Where do you start with SAP Return on Investment or ROI?”  This includes some of the details of what to consider for achieving ROI with SAP. 

After that, at some point over the next few months, I will release a complete ROI / TCO / payback system.  This set of evaluation tools and resources should be used for your initial implementation, however they can be used to help plan out an upgrade, enhancements, or possibly to evalaute the implementaiton you’ve already done.

If I can find one or two companies who are looking to evaluate their current implementations, or are looking at implementing SAP to try this out I will be happy to work through it with them.  Contact me for more information.

Related Posts:

Lower SAP Application Support Costs – TCO – by Reducing Custom Solutions

June 21st, 2010 by

Application SupportPreviously I explained the two primary types of implementations–, with SAP or any other ERP package you will do business process engineering or software engineering.  The differences in these two types of implementation approaches will have a major impact on your total cost of ownership (TCO) and your long term application life-cycle costs.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to gain the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

Software Engineering (SAP or ERP Custom Coding) Still Requires Change Management

If you choose software engineering you will still need change management processes but the transition will not be as extensive.  However by choosing the software engineering route (changing the system to match your business) up front development costs will be far higher, long term support will be far more expensive, and depending on the extent of the custom solution you will be tied into a particular vendor.

Generally less-experienced consultants choose the software engineering route over business process engineering because it reduces their experience requirements.  It is easier to insist that only a custom solution will work if they do not know how to use, setup, or support some standard functionality in SAP (see e.g. A Cautionary Tale About SAP Knowledge Transfer). This is also the “cop out” approach when some consultants (or system integrators) do not know how to guide a business through the critical change management and knowledge transfer efforts needed to accept new processes or concepts.

In some limited situations changing the software (or doing custom coding) to match your business is necessary.  If it is truly lined up with business goals and objectives, or if it addresses marketplace or competitive pressures so that it allows you to be a more effective business then the custom development is likely justified.  On the other hand if it is to avoid the difficult change management process in areas of the business that do not directly affect competitive pressures or reduce costs, etc., then it is probably not justified.  Instead you are better to engage in the intense change management strategies and processes to make the transition to a new way of operating.

In the short term custom coded solutions may “fit” your current business environment, and those custom solutions may reduce some of the resistance to “change,” but there are longer term consequences.  But there is a significant trade-off.  To the extent that you rely on custom coding and modify the system you are locked into your original vendor.  If you need something changed later, or if you want to add additional functionality you no longer have the option of selecting any number of qualified or skilled consultants from the general marketplace.  Therefore you have less leverage to contain costs (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?).  And while the change managements costs may be lower initially by changing the software, those costs are simply transferred to other areas of the project.  And often times at a much higher cost.  If you decide on modifying a package application like SAP then you will pay a higher cost for developer time than for the change management and training effort.  You will also have far higher support and maintenance costs making your entire application life-cycle far more expensive (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).

SAP Custom Coded Solutions Introduce Significant SAP Project Risk

As the number and complexity of development objects increases the risks to business operations increases.  This statement may seem obvious either before a project begins, during testing, or after a project is finished, but in the heat of an implementation it can easily be overlooked.  Along with this, to the extent that business operations are subject to risk so is a company’s financial performance.

Every time you custom code an SAP solution you introduce potential performance problems, additional processing overhead, potential coding mistakes, and worst of all, unforeseen process problems and gaps.  Along with these risks you do not have the benefit of the dozens, or hundreds, or in some cases even thousands of previous customers who have used, tested, fixed, and worked through the issues with new functionality offered by the application vendor.

It is all too common to find numerous bugs and fixes in custom programs once a system goes into the live production state.  Even the best coders can rarely account for every nuance, variance, or variable in processing that might occur.  When the development becomes even more complex it is even more important to evaluate whether there are standard system options which can handle some or all of the requirements.  Complex development often leads to much more significant bugs, including in areas that they might integrate to or transfer any data to or from.

Unplanned ERP Application Maintenance Costs Escalate Over Time

Once the custom coding is completed, if the software vendor (like SAP) releases patches or fixes to other functionality, or if you find a problem that the software vendor has a fix for you may in turn break some of your custom coded solutions.  Once those are broken, your business operations may suffer, and you are at the mercy and cost of getting the custom development fixed.  And on any large package application like SAP, you will likely be applying fixes (SAP OSS Notes) to the system from time to time for several years.  This doesn’t mean that the software is necessarily buggy, only that small nuances or optional functions have been discovered by some other customer that you might benefit from.  Each application of these changes then requires more extensive testing because of the custom coded solutions.

SAP or ERP Custom Solutions Still Need Sufficient Knowledge Transfer and Documentation

As part of my knowledge transfer techniques and plans in that situation I made sure that every small section of custom code was extremely well documented, and the entire solution was well-documented.  The client did the testing and was thoroughly trained on the custom solution, the dependencies, the master data requirements, the implications of master data throughout the process, the use of the coding, etc.  In other words, a thorough knowledge transfer process was carried out with the critical techniques and methods for the client’s long term independence.

There are times when a custom solution is necessary, but could you imagine a “con”sultant** trying to do this without deep knowledge and understanding of SAP’s Sales functionality?  This company had been told several times, by several “con”sultants** that what they wanted to do could not be done and there wasn’t an aftermarket product to support their need.

Custom Coded Solutions (Software Engineering) Limits Your Training Options

For the custom solutions and the customized functionality you no longer have the option of going to the SAP training programs to learn the system functionality (so you can configure it yourself).  You are tied into the original vendor at premium rates to maintain your system.  If the customizations are extensive enough, you will be pressed to use the original vendor to do any future upgrades or system work.  Essentially you have cut yourself off from competitive bidding because the cost of a complete re-implementation may be cost prohibitive.

Expect much higher application life-cycle costs.  Are you ready to be the only customer with that specific solution that is not supported by the application vendor (except at super-premium rates)?

An Example of a Necessary SAP Custom Solution With Business Justification

Don’t get me wrong, there are times when a custom coded solution is necessary.  While SAP’s application is very broad and very deep, it still has some gaps, or you may have some genuinely unique requirement.  For example I was at a client recently who wanted a Trade Promotion Execution solution.  Not just reporting or analytic functionality (like the CRM solution), but a true sales and marketing execution “cockpit”.  This cockpit had to be completely flexible so that they could do any mix of products, in any quantity they defined, to qualify for either additional free items or additional items at a discount, or some of the items ordered in that combination at a discount.  On top of that it had to be able to have limits so that as certain thresholds were reached, within a certain period of time, the customer would no longer be eligible for the promotion, or they would qualify for a different promotion.

The requirements and flexibility were so comprehensive that it would have entailed an entirely new application sub-module from SAP.  As a result I worked with them to design and implement a custom solution to handle all of these requirements.  This was mission critical for them, it was aligned with a key business need, and it was focused on customer retention and acquisition.  This was all done within the existing SAP provided order processing framework. On occasion I provide limited support for this custom solution (however they are fairly independent), but it was well documented, tested, and trained before I left.  In over a year in production there has only been a couple of minor issues with the entire solution and it has worked well for them with numerous creative order and marketing requirements.

Their sales and marketing programs have allowed them to profitably grow at a greater rate than any of their other competitors.  This growth and profitability has occurred during a major economic downturn.  I can’t say that my solution is completely responsible for that, but what I can say is that they were a sophisticated SAP shop who had clear processes and marketing requirements and the solution enabled them to be more efficient and effective with their marketing programs. This solution allowed them to reduce the previous 4 – 8 week development (custom coding), testing, approval, and roll out time line for each promotion or sales program to only a few days.   They also gained additional analytics of program and promotion effectiveness. This solution has allowed them to be very proactive in customer acquisition and almost instantly reactive to competitors for customer retention.  Their competitors have no competing solution and are subject to highly manual processes or long lead time custom solutions.

In this case the custom development was clearly connected to a specific business requirement that was mission critical and focused on customer and revenue growth.  In my opinion that is certainly an appropriate justification for a custom solution.

Conclusion on Custom SAP Solutions and Application Life-Cycle Support Costs

The costs and consequences of custom solutions to overall life-cycle support are generally far higher than they may initially appear.  For example there is the:

  • initial developer cost together with
  • the application consultant’s time,
  • additional documentation,
  • additional knowledge transfer,
  • additional testing beyond standard functionality requirements,
  • long term (unplanned) support costs with the incumbent vendor,
  • no standard or vendor provided training,
  • changes, fixes, or bugs are not included in vendor maintenance payments,
  • additional upgrade testing or “lock in”,
  • paid vendor maintenance may actually “break” custom solutions requiring additional rework,
  • etc.

If there is not a strong business justification for a custom solution you are much better off trying to make the standard system functionality work.  To the extent you do you will reduce overall long term support and maintenance costs.  One other key consideration is that by reducing the number and amount of custom solutions when it comes time for an upgrade your change management and testing time will be signifantly reduced.  You will have already made the initial process change requirements by changing to standard system options and you will not have to verify, fix, and extensively re-test all of the custom development.  Standard functionality is supported by the software vendors normal patches, fixes, or OSS Note based enhancements. 

In the end there should be a strong justification for custom coded fixes and solutions.  Carefully consider the cost / benefit ratio for any custom coded requirement.  Sometimes custom coded SAP or ERP solutions make good business sense, other times they are a train wreck waiting to happen.

Related Posts on SAP Change Management, Knowledge Management, and Training

——————————-

Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project
http://www.r3now.com/change-management-strategies-and-knowledge-transfer-processes-for-a-successful-sap-project
May 24, 2010

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. One of the biggest problems in workforce preparation for ERP applications like SAP is the type of training they receive. The types of training you decide to use are all part of the knowledge transfer strategies, techniques, or methods to support business transformation.

Most companies only perform the traditional scripted keyboard training which consists of carefully controlled individual transaction exercises. The typical system implementation focuses on training individual transactions without the explanation of dependencies or processes. This works for initial exposure to the system–, for learning the user interface and the new data entry requirements. Typical training methods generally do not transfer process related knowledge critical for success such as:

  • The significance of the data that is entered.
  • Where that data is integrated into other parts of the system.
  • What the underlying data dependencies are.
  • What types of troubleshooting steps to take.
  • What interdepartmental impacts exist.
  • What part of the overall process is affected.
  • Etc.

Together with these common gaps in knowledge transfer techniques and methods there is little ongoing follow-up after the system is live such as:

  • Communications about maintenance or performance tips and tricks after the system is live.
  • Additional troubleshooting training or techniques as they arise.
  • Where to find key data and information for decision making.
  • Etc.

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

**  Please pardon my periodic references to the con artists (“con”sultants) in the marketplace.  My frustration with the frauds and cons in the marketplace is the amount of damage they have done.  Frankly I believe it is a testament to SAP’s ability to produce implementation methodologies and control structures that the sheer number of frauds in the marketplace have not destroyed far more implementations.  I’ve paid my dues and have worked my way through the ranks in:

  • training,
  • then to configuration,
  • to project / module lead positions,
  • through numerous full-cycle projects in multiple modules,
  • to project management,
  • and then out on my own as an independent contractor,
  • and then to trying to strategically grow a business with only the very best.

——————————-

Leading Change (and Change Management)
http://www.r3now.com/leading-change-and-change-management
May 17, 2010

While there is little debate that the successful implementation of change can create an extreme competitive advantage, it is not well understood that the lack of doing so can send a company (or an individual’s career) into a death spiral. Companies that seek out and embrace change are healthy, growing, and dynamic organizations, while companies that fear change are stagnant entities on their way to a slow and painful death.

Agility, innovation, disruption, fluidity, decisiveness, commitment, and above all else a bias toward action will lead to the creation of change. It is the implementation of change which results in evolving, growing and thriving companies.

——————————-

A Cautionary Tale About SAP Knowledge Transfer
http://www.r3now.com/a-cautionary-tale-about-sap-knowledge-transfer
February 3, 2009

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?

——————————-

ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?
http://www.r3now.com/erp-consultants-is-the-promise-of-knowledge-transfer-just-part-of-the-sales-pitch
February 10, 2010

Most ERP projects are filled with promises of software knowledge transfer from the consultants to the client. Yet once a project is over, in many cases, the client is clueless when it comes to making software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?

In spite of all the lip service given to knowledge transfer, the problem is there never was a real strategy to make it more than just a dream. Secondly, when push comes to shove this once important concept of learning suddenly becomes something we worry about later (and of course, it never happens). This is similar to consultants building a spaceship to get you to Mars with the understanding we will not plan the return trip until after you get there.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to accomplish the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to accomplish the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

Related Posts: