ERP Software Logo1

Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process

 
 

Barry Knaster, the Knaster Technology Group

An ERP Implementation Failure Story – You be the Jury! (Part 1)


Email | Print

While stuck at home during a recent snowstorm I was digging through some old boxes and came across a stack of the “You be the Jury” books.

The premise of these fictional short stories (by author Marvin Miller) is for the reader to decide the guilt or innocence of the party in question based on the facts presented for each crime committed.

Relative to accounting software,  I can think of no bigger crime than ERP implementation failure. Who is to blame when it occurs, often over and over again?

Over the course of the next several blogs that is for you to decide!

The facts of this case are as follows: Mountain States Entertainment Corporation (MSEC) is a privately held company headquartered in Castle Pines, Colorado.  They own several regional local movie theatres, golf courses and restaurants. Their annual revenues are around $30 million and they employ 150 people. Growth has been robust – increasing about 20 to 25% per year over the past three years.

In 2008, as a startup company, they selected QuickBooks Enterprise (a crime in and of itself!) as their ERP solution – based on the ill advice of a now defunct financial advisory firm. MSEC quickly outgrew the capabilities of this entry level solution and realized it was not going to efficiently or effectively manage their future information technology needs, business processes or reporting requirements.

As a result, their newly appointed president tasked an in-house  committee to assess and select a new accounting software solution and provider.  Over the course of many months several meetings were held.

Finally, in June of 2010 a new ERP system was selected and went live later that summer but, to the dismay of all, by winter that same year the ERP implementation was declared a major disaster.

What went wrong?  Who is to blame for the ERP implementation failure?  That is for you to decide!

Each committee member was interviewed by the president to explain their role in this debacle.  Their key remarks will be presented over the next several blogs for your analysis and verdict..

Up first: the assistant controller – Julian

“ I personally don’t get why everyone is so upset.  When I was asked to provide my list of key items for software selection, I made it very clear to the committee that we could easily adapt our business processes to work with whatever ERP system was selected. So it wasn’t important to mention them all; given the flexibility of the ERP systems of today I was sure any one of them could easily do what I needed done.  And if not, so what - we would just change how we do things to accommodate any nuances of the new system.”

Is Julian guilty or innocent of contributing to the MSEC ERP implementation failure?

You be the Jury! (Provide your verdict and rationale using the comment section)

Next blog will reveal the results

By: The Knaster Technology Group, Colorado based Microsoft Gold Certified Partner

4 Responses to “An ERP Implementation Failure Story – You be the Jury! (Part 1)”

  1. Great idea for a blog post Barry. My verdict is… sack Julian! He has no idea what it takes to implement a successful ERP system.

    Firstly, a lot of time and money is spent choosing and implementing an ERP system so to brush off how upset a company might be when it fails is extremely thoughtless. The failure of an ERP system will definitely hurt a company and they will probably be paying for it for years (in more ways than one).

    Secondly, to assume any ERP system can ‘easily adapt’ to your business processes is falling at the first hurdle. There will always be a certain amount of flexibility within most ERP systems but when it comes to catering for the unique processes within your business, it is not always easy to get your software provider or OEM to adapt the software to meet your exact requirements. A key element to successful implementation of a new ERP system involves sitting down with your provider to identify the key processes within your business (and that means all of them!). Processes that can be achieved are ticked off and processes that can’t be achieved are adapted or tailored to work around the situation. We develop and support our own accounting and business management software called Intact. We strive to modify our software to fit almost every one of our customer’s individual needs because we know and understand that they’re uniqueness is what makes them successful. We’ve always believed that our customers should not have to alter their business processes solely to accommodate a software system. While many of the processes we’ve encountered over the years may seem a little quirky or even border on the bizarre, most, if not all, have served their designers well and in some cases provided a vital competitive edge. This is something we’ve always tried to respect. This brings me nicely to my next point.

    Thirdly, the processes you have developed over the years have been built upon to give you a competitive advantage over your competitors. To suggest that ‘we could just change how we do things to accommodate any nuances of the new system’ is ludicrous. You may have spent years perfecting what you do to beat the competition and to simply scrap them because the system can’t cater for them is crazy. Judging from this company‘s year on year growth rate, they are doing something right and shouldn’t change what they do to suit the software.

    Implementing a new ERP system can be a daunting task and not something that should be taken as lightly as this assistant controller has. I’m hoping the fact that he is only an ‘assistant’ that the company bosses didn’t take his comments too seriously. He certainly didn’t help the situation though.

    Ok, rant over! Looking forward to hearing what the next committee member has to say.

  2. Japheth Nolt says:

    I charge Julian guilty (based on the little bits of info we have so far). Often users think they are more willing to change their processes than they really are. Assuming software is flexible in the area you need it to be and being lazy about stating your requirements are common pitfalls.

  3. Thomas Widmer says:

    Probably Julian will also not need any training as he’ll find a way to work with/around any system…

  4. Engaging Post! I will get us started. This comment by the Controller sounds alarm bells in my mind, “So it wasn’t important to mention them all”. If the Controller did not mention all his requirements how could he be sure that he was getting what he needed? The software consultant is not a mind reader. All requirements, no matter how basic they may seem, should be flushed out during the software analysis stage. Perhaps the software has the features he wants, but the implementation team did not turn them on, as they were never told it was important. I look forward to Part 2!