You’ve got the perfect plan for implementing the new software system.  The requirements have been written, your plan includes 2 conference room pilots, and you’ve got time for practice, time for training and time for data migration.  How about reports?   When does that come in?

Your software vendor probably told you that they’ve got plenty of out of the box reports.  Those are probably great if your company used all standard processes and needed totally generic information.  I have yet to see a place where that works.  You probably have lots of reports that you use today, that you’d like to see recreated on the new system.  Maybe you think the reports will be better in the new system, have you allowed time to create them?  Do you know anyone who can create new reports on the new system?

The new software gives you the perfect opportunity to come up with all of the reports that you think will allow you to control your business better.  You can look at your sales orders by month, quarter or year; you can look at purchase orders, at what products are on backorder.  You can see who your most profitable customers are and who costs you the most money.

How do you forecast all of your report needs?  You don’t know what you need until you need it.  That is why the conference room pilots and dry runs are so important.  You need to use the reports to drive the process.  You need to study the reports generated by the practice data to see if they work for you.  You can design new reports based on the results.  Make sure someone has the time to write the reports.  If you go live too soon after your final dry run, you may not have enough time for important reports. 

Do you need the ability to export into Excel?  Will your people need to analyze their own data in a separate program like Excel?  You need to test the exporting function thoroughly before going to a Production environment.  I have seen weird things happen when exporting; the final column of data comes out completely wrong because it was defined as alpha-numeric instead of a date.  I have seen reports completely fail when the parameters don’t match up perfectly.  Testing will decrease the probability of those kinds of problems after go-live.

Will you have a new programming language or environment for your reports?  Does your new system come with Crystal Reports?  Will you get a new way to present dashboards?  All of the reporting needs to be thought out in advance.  After go-live all issues will have to be solved on an emergency basis and cost so much more.  Now is the time to solve the problems when they can be done during regular working hours at a normal pace, without stress.

Have you been in a situation where a report has to be done on an emergency basis?  Leave your story in the comments.

The other day I had a software problem.  My client had come to me with an issue and I had to come up with a solution.  I have been working with them for a while so I know their software pretty well.  I can usually figure out their problems and either solve them or come up with a workaround.  At the very least I can use their testing environment to document all the steps to recreate the problem as well as the steps taken to try to solve it.

My client has a valid contract with the software vendor and has full access to their help desk.  I am sure you have dealt with many ‘help’ desks and are completely familiar with what that means.  Some of them are very good and some of them are worse than a hot day in the desert.  I have to admit that this one is actually pretty good.

The trick is in the communication.  The people who I work with can’t always communicate their problems in such a way that the help desk can solve them.  They also have trouble understanding the responses.  Sometimes the tech-speak is just too complicated.  That’s where I come in.  I can help translate for both sides to get the problem solved.

Today, I found what I thought was a bug in the software.  The company that created this software is very sensitive about criticism of their programs.  I didn’t want to go to the help desk with this one until I had verified functionality with one of their senior consultants.  Since I am on good terms with several of them, my options were open.

The project manager for our implementation likes for me to go through him before talking to the consultants.  I shot him an email with my problem.  Within a few hours he had confirmed my problem, sent it off to tech support, and came back with a solution.  It wasn’t really a bug, but a setup problem.

I have dealt with many software companies throughout my career.  I have talked to people who were really good at their job, but the company was terrible; and I have talked to people who couldn’t help a cat out of a bag, even when their company was great.  A response within a few hours with a solution, going around the help desk, is above average support.  I would recommend that any day of the week.

When you are looking for software it is important to determine what kind of relationships they develop with their clients.  Sure, you will get references and talk to them about the pros and cons about the software; but you also need to find out about their responsiveness.  You need to find out about their personnel.  Do they stay in touch with their clients?  Do they come back to find out if there are any lingering issues?

Before you make a decision on your software, find out who your main contact will be.  Try to meet with him or her at a time and place where you have plenty of time for questions.  This person needs to be someone with whom you can trust and build a relationship.  They need to listen; you need to feel like they are listening to you and not thinking about what they will say next.  They need to be flexible.  Throw them a hypothetical curve ball; how do they react?

If this person doesn’t meet your criteria, don’t abandon the software vendor entirely, just ask for someone else.  Most companies would be happy to switch personnel if it means a chance for a sale.  Make sure you still have time to repeat the process with someone new.

My criteria is for someone who understands that it’s a global world out there and Technology makes it happen.

If there are three letters which can wreak fear in the “c suite” it’s the letters ERP.   Enterprise Resource Planning will bring visions of costs overruns, schedule delays and general havoc to most company officers, and with good reason;  most ERP Implementations fail to deliver the benefits promised in the sales cycle according to numerous studies into the success of these projects. 

It doesn’t have to be that way though.   We’ve studied these implementations for decades, and the causes for these substandard implementations are well known and widely documented, so why do we still have unsuccessful implementations.    The key to these failures is that there is a disconnect between what we know and what we actually do.  So let’s review what we’ve seen in the ERP implementation marketplace over the past few years.

•  Lack of Top Management Commitment

Clearly this is the most significant contributor to project success, and unless the top officers are part of the project from the beginning it’s a sign that you’ll have problems.  The litmus test for commitment is whether the top officers are willing to demand that the top salespeople change to best practices as part of the implementation.  When the salespeople say “our customers won’t support that change” the CEO usually will cave.   Unless there’s significant pushback by the CEO, you can rate the commitment as “lukewarm”     It’s easy to say, but it’s difficult to execute change.

•  Inadequate Requirements Definition

Failing to understand the detailed requirements accounts for nearly 60% of ERP implementation failures, based on our experience.  Creating an adequate Requirements definition document for a system selection is an effort that takes months and involves most of the company.  There are dozens of functions within most companies, and within these functions there are hundreds of processes.  Each of these processes can have hundreds of elements, so the requirements can be extremely complex, and unless each feature/function is properly defined, you will not find out until you well into the implementation, and generally this will require some pain (read: customization) to fix.  It’s important to understand not only what is done, but what is possible, and this requires a thorough understanding of the ERP marketplace.

•  Poor ERP Package Selection

How many ERP packages are selected based on a demo or set of demos done by the software vendor?   Too many, because unless the demo scripts are based on the requirements definition study, and scripted to follow the desired processes of the company then they’re not of much value.   A demonstration of a system should represent the business process of the company exactly.  If you make cement, than watching a demonstration of the software make a bicycle isn’t going to show you how the system will work in your business, and users who see the demo will be distracted by features, functions and the user interface, which may not be applicable to your business.   The script of a demo must reflect the requirements gathered in the requirements gathering phase of the selection.  If not, then don’t waste your time.

•  Inadequate Resources

Implementing a new ERP system involves re-designing processes, sometime from scratch.  Do you really want your processes designed by anyone less than the best person in your company?  Most ERP implementations involve creating a core team of full time employees to design, test and train.  Unless you pick your “best and brightest” you are short-changing the organization.  We like to tell our clients that they should pick the future leaders of the company, because this core team is going to completely re-engineer the company and it will be the group who knows all the new processes the best since they designed them.   Taking the ‘best and brightest’ out of the company for a significant period of time is expensive and painful, but it’s the way to succeed.  Short change the resources, or select less that the best at your own peril.   Easy to say, but tough to do.

•  Resistance to Change/Lack of Buy-in

“Paving Cow Paths” as Michael Hammer of “Reengineering the Corporation” is pretty easy to do, and it generally involves getting the new software to do what is being done now.   It’s difficult to comprehend why a company would buy a new system to improve its processes, and then try to get it to work exactly like the old system, but it happens every day.  Remember that the “institutional knowledge” or best practices of hundreds or thousands of other companies are  “baked into”  the new software, and you should take advantage of that knowledge by changing your processes to fit the new system.  Yes, it’s painful, but it’s the best way to succeed.

There are a number of other keys to success in implementing a new ERP system, but these are the ones we see most often, and the ones which are most troubling since they’re so well known.  The difference between knowing and doing is surprising and troubling, but it continues.    Share this list with your team and discuss how you can avoid the gap between knowing and doing.

A special thanks to Dan Gingras for this article: 

Gingras is a Partner in the New England practice of Tatum.

He has 25 years of experience as a technology executive with extensive qualifications in all facets of project life cycle, from initial feasibility analysis and conceptual design through documentation, implementation, user training and enhancement. He is well know as the author of numerous articles in trade magazines and writes a regular column for CIO Update.

I work with a number of accountants.  They were shocked to learn that I am about to implement an ERP system without including the accounting module.  I was told that they wouldn’t try it.  They didn’t see the purpose.  They said that the risk outweighed any reward.

I started thinking about that.  Would this really be worth it?  Could we make it work?  I once read an analogy that an ERP implementation was like heart surgery.  Holding to that, would we want to perform heart surgery, but only fix 3 of the valves?  You know you’ll have to open the patient up again eventually, to fix that 4^th valve.

If I am the doctor in that analogy (my dad would be so proud that I am following in his footsteps), then I have to make the call.  If the patient isn’t going to survive a full operation, then maybe we split the procedure into 2 separate operations.  We perform half now, let the patient recover, and then perform the next one when he is ready.  Hopefully the first operation will fix enough so that the patient will make it to the second one and then a full recovery.

OK, enough with the medical analogy.  I am not a doctor, I don’t play one on TV or the internet, and I know very little about performing surgery.

I do, however, know when a company needs to get off of its current software system.  When Excel spreadsheets are so big that the computer freezes trying to make a change, it’s time for a fix.  When you spend more time dealing with data problems than you do handling your ‘real’ job, it’s time for a fix.  When the system you’ve got doesn’t show you the data required by your corporate entity, it’s time for a fix.

So, we optimistically set the schedule too tight.  The accountants have been completely distracted from the project by other responsibilities.  The processes cannot be changed in a timeline that everyone will agree on.  Our only choice was to delay the project.  Our only choice, that is, until we came up with the brilliant idea of only turning on operations.  We will avoid accounting and finance for another few months; until the patient is healed enough to continue.

ERP without accounting just sounds silly; but we can make it work.  We will use the ERP system mainly for tracking inventory (yes, the cost and price of materials will be tracked, but not as the system of record).  We will be able to get new reports that will show what the company is producing, what they need to produce, and when they need to produce it.  We will eliminate the need for extremely large Excel spreadsheets by using a real database.

We then get 5 more months (3 if you remove the weeks that people will take off for the end of the year holidays) to prepare for accounting.  The accountants will have more time to figure out how to best use the new system.  They will have more time for validation and system testing.  They will have more time to design the reports they will need on the new system.

So, yes, I think we can make it work.  Yes, I think it’s worth it. Do you?

Imagine running a 20 million dollar manufacturing company on spreadsheets.  Oh sure, you can use Peachtree or QuickBooks for accounting, but what about manufacturing?  How many Work Orders are going on currently?  How many Sales Orders are due today? Or this week?  Can you determine what your margins are, when you can’t even track labor?

The obvious solution is an ERP system, but how fast can you implement it?  You need the new system yesterday: the spreadsheets are so big that the computers are crashing; there are numerous versions of each list and no one knows who has the latest version.  Can you get a project going fast enough to solve the problem?  What if you can’t?

Maybe now you can understand my dilemma; and why my solution makes sense.  The company has several factories already running a very good ERP system.  They use the accounting and manufacturing modules to coordinate with the corporate accountants and to track and plan the manufactured goods.  One factory, however, is not quite up to speed.  The project to put them on the system is falling behind and they will not be able to make their deadlines.

Their implementation team is small, which sped up the decision making process.  We were able to design their processes quickly, and understand most of the issues.  Next was loading, testing, and validating data.  The small team hurt them because each member had too much going on.  With several validation scripts each, plus their regular job, they couldn’t keep up.

We have to deal with the amount of time it takes the accountants to do a month-end and quarter-end close.  Corporate needs standard monthly statements in a timely fashion, and without a regular system, that takes a while.  The time they are working on that is time away from the ERP project.  We also lost a few days while they installed a new payroll system.  The problems encountered during that project took the accountants away for several days.

The solution is pretty elegant, even though it is convoluted.  We will implement the ERP system in a non-Production folder.  We will only use that system for operations to track inventory (POs, Receipts, Work Orders, Sales Order, Shipments).  We will not use that system for accounting (invoicing, A/R, payments, journal entries, corrections, etc.). 

Leaving out the accounting side should reduce the scope enough to allow us to finish on time.  By including the main functionality to track inventory they will have the tools they need to run the business.  They need to stop relying solely on giant spreadsheets, and this will give them the data they need to do it.  They will be able to download anything they still need into Excel format, but have a SQL database as their system of record.

There are risks, of course.  They will need to officially give up their spreadsheets and not rely on them anymore.  Some people were used to seeing the whole picture through the spreadsheet.  That picture could be limited and more condensed as seen through the ERP.  They will have to figure out what screens and what reports are equivalent to their old spreadsheets.

They will have to be able to synchronize some of the processes between the existing accounting system and the new ERP system.  Anything with money on it will need to be put into the accounting system, but the quantities will be in the ERP system.  They wouldn’t have an ‘old’ accounting system if they could just go-live with the whole ERP system.

What about dual entry?  Sales Orders will need to be on both systems.  Can they manage the ERP system without worrying about prices?  Can they keep the quantities in synch?  Invoicing will have to be done from the accounting system, but match with shipments from the ERP.  POs will need to be in synch as well.  How much time will be spent chasing down inconsistencies?

They will be using the ERP system only to track inventory.  The dollar amounts will, hopefully, be correct but irrelevant.  This is a temporary solution, so we still have to plan for an eventual go-live on the Production ERP system.  We still have to figure out when to move all the accounting information and processes along with the manufacturing data into the Production ERP system.

The bottom line is that they can’t go-live on the Production system; they can’t stay where they are now, with spreadsheets.  This is the next best alternative.  Do you have any alternatives?  Have you faced a problem like this?  Let me know.

Can we get it done in time?  We must, because it’s a global world out there and Technology makes it happen.