Skip to Content

The time may come in your career as a consulting SAP developer or analyst when you are asked to help de-implement one or more SAP modules from a customer site, including migration of data inside SAP to another product.

Although any consulting SAP developer or analyst will have mixed feelings about participating in such a project, SAP Mentors may feel even worse about doing a de-implementation, since their very mentor status indicates that they have made a significant personal commitment to preaching the virtues of SAP.

But if you think about it, participating in an SAP DE-implementation will actually make SAP mentors better mentors than they were before.

Why?

Because in a DE-implemenation situation, SOMEone at the client site is unhappy with SAP in one or more ways – unhappy enough to move to a different product.

And what the mentor can do is get down into the weeds and find out how much of the customer’s happiness is due to true weaknesses in SAP’s product, and how much due to other factors.   (I don’t mean what’s wrong with SAP in a general way – I mean – what’s wrong with this transaction, with this screen, etc.)

Such information is as invaluable to SAP (or should be as invaluable) as the most laudatory accolades you hear at Sapphire presentations from customers who just love every detail of SAP to death.

In fact, maybe there should even be a section of SDN/SCN entitled

“Lessons Learned from SAP DE-implementations”

where mentors and others could provide feedback on what they’ve learned about SAP product weaknesses during de-implementation projects.

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Alvaro Tejada Galindo
    David:

    You had bring a nice point to be table…In my 8 years of consulting I have never seen any company doing a DE-implementation…and actually I have never thought about such situation.
    I agree with you that in that kind of scenario, the best thing is to collect information about why are they making such a drastic decision…it could help of course to improve the quality of SAP products…

    Greetings,
    Blag.

    (0) 
    1. David Halitsky Post author
      There are more things in heaven and earth, Blag, than are dreamt of in your philosophy … (Just “funnin” with you – that’s a line that Hamlet says to Horatio in Shakespeare’s play.)  Nice to chat with you … long time no see …
      (0) 
  2. Harald Reiter
    Worked on a couple of projects where SAP was not chosen but other technology mainly due to immaturity of product at that time.
    Created various prototypes for clients using different technologies and then client selected the one that suited them best at the time – sometimes this was not a product from SAP.

    Did not really bother me – just my 0.02 cents
    ๐Ÿ™‚ Harald
    (0) 
    1. David Halitsky Post author
      Shoot-outs are very different than wars of attrition.  Shoot-outs can be influenced by all kinds of extraneous factors (think IBM’s country club at Sands Point in the old days), while wars of attrition are generally won due to real-life factors such as specific dissatisfacttions with the product.
      (0) 
    2. David Halitsky Post author
      But – I agree, when a mentor participates in a shoot-out that SAP loses, then there should also  be a place at SD/CN for reporting lessons learned from the loss.
      (0) 
  3. Stephen Johannes
    David,

    From a customer service perspective, it seems there had to been more than a serious “systems failure” for a company to de-implement an SAP solution, beyond a “merger/acuqisition” scenario.
    The real question in case of a de-implentation scenario, would not be one of why solution did not work, but rather why were the concerns of the customer not addressed. 

    An effective customer relationship management process would have addressed the issues that are causing the customer to look elsewhere.  In addition a strategic decision could have been made to determine whether it is better to try to retain the customer or let the customer leave on good terms.  I would even venture it would be better for the provider of the solution to help the customer leave(if that was the final choice), so they can get the required feedback to improve the solution and provide a true showing of customer-focused service.

    Then again I’m looking at this issue through my “CRM colored” glasses.

    Take care,

    Stephen

    (0) 
    1. David Halitsky Post author
      Hi Stephen – glad you chose to contribute here, because I agree – de-implementations are where CRM “meets the road”.  You make some very valid points that really shouldn’t be discussed in this fully open forum  – if you want to continue this conversation, look for a thread in the Mentor forum.
      (0) 
  4. Thorsten Franz
    Hi David,
    Just yesterday I thought it was well time for another thought-provoking DH blog, and here it is. ๐Ÿ™‚
    Being passionate about SAP technology, it pains me to read about customers who are so dissatisfied with their SAP solution (if you may call it that in such as case :)) that they de-implement it.
    A de-implementation means that something in the development, sales, implementation or maintenance process has gone seriously, seriously wrong. Someone must have screwed up or the customer (assuming they are sane) would not be unhappy. Being convinced of the generally good quality of SAP software, I would usually expect that good software makes a happy customer, unless something bad stands between the two. And I want to know what it is.
    This is why I am a big fan of the “SAP: Loathe it or ignore it, you can’t like it” weblog at http://sapmesideways.blogspot.com. As far as I can tell, this weblog is written by a brave and smart individual who is suffering from an SAP implementation project that is being screwed up by external consultants ranging between incompetence and criminality.
    On the one hand, it hurts me to read about the reputation of SAP software being damaged by bad consultants and flawed implementation projects. On the other hand, if you’re smart and willing to learn, you have to embrace failure as a great learning opportunity: identitify the point of failure, find our which errors were made, and try hard to prevent them from being repeated. Failed projects teach you what is important and must not be overlooked.
    We all have to work hard and deliver the best quality we can. Though we may not often be aware of it in the bubble of our seemingly secure jobs, the software we earn our bread with is under constant evaluation. If SAP projects are too expensive, or too many of them fail, or leave too many customers unhappy, we could find ourselves in a rather unfavourable position.
    I therefore ask the following from you, David. As a loyal mentor, please, in a compartment of your mind, try to perform the IT equivalent of a vehicular accident investigation during this project. If you find out which main errors have led to the de-implementation, please pass that knowledge on to the community and blog about it. We will be glad to learn.
    Cheers,
    Thorsten
    (0) 
    1. David Halitsky Post author
      Hi TF – always nice when you choose to riff on a motif that’s been laid down …

      That’s an interesting blog you’ve linked to, but I think it should be noted that most of the problems seem to be due to implementation issues, not product issues.

      I was thinking more of de-implementations due to product failures – cases in which even the best implementation doesn’t, in the final analysis, satisfy the needs and abilities of the customers’ workforce.

      Anyway, I found out yesterday that the de-implementation is not a complete move off SAP but rather a migration to a more specialized component of SAP that’s already been implemented elsewhere by the customer.

      So the lessons to be learned from this case will be far more subtle than those learned from cases where there is a total move away from the product.

      (0) 

Leave a Reply