jump to navigation

Why do you need ERP System Testing? 05/23/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , ,
1 comment so far

Testing is one of the first items that are removed from a project when time becomes tight.  Many people wonder why they have to spend so much time doing formal testing when they have spent so much time training with informal tests.  They have spent so much time with the new system that they just know it works.  What is the point of spending a large amount of time on formal system testing?

First and foremost, you need to validate that you are getting what you think you are getting.  A new ERP system is a large complicated piece of software.  Just because individual sections are working, doesn’t mean that each module is sharing data the way it should.  A plan for system testing should include many of the core team, so they can see the larger picture.  You also need to be sure that the right communication is happening between team members.

You need to make sure that when a PO is created and received, that the inventory is added correctly and the journal entries are made appropriately.  You should review the documents and reports generated from the process to make sure that everybody is satisfied with the results.  When the PO is tested separately from the accounting module, it seems to work fine.  However, did anyone from accounting notice that the manufacturing group has automated the POs for inventory differently than expected?  This would be found in System testing with good communication between core team members.

You need to be absolutely certain that each process is testing using the same parameters.  There could be hundreds or even thousands of parameters in a good ERP system.  These parameters should be set based on the way your company does business.  For example, FIFO, LIFO, or Standard should be set to account for product costs.  I have seen software fail because no one realized that parameters were different than expected, or were changed during go-live.

The CYA reason for system testing applies for consultants and/or public companies.  A team who delivers a working ERP system takes a large risk of someone coming back with complaints.  Users can always find something to complain about.  A full, well documented, system test will reduce the risk for the implementation team.  If they have tested every scenario possible, then any complaints should already be documented and signed off. 

Auditors may be allowed to review the implementation process, especially if something goes wrong because of the software.  A good system test would be enough to hand over to show that you did everything you could think of to prevent problems.  When problems occur, you should be able to point to the system testing documentation to show that something new or different has occurred to cause the issues. 

Problems that arise after the system has been in use could become very large problems.  It is much better to find them early on.  A small problem could grow into something much bigger over time.  A problem that is found after a time lag will be more difficult to find and could be more difficult to fix.  System testing should be designed to follow all your processes to a logical conclusion.  If you are using the system for accounting, then journal entries and account balances should be watched during system testing.  If the software is used to run a call center, then you need to run rollup reports containing all possible call types.

IT projects are constantly delayed and have scope cut to meet deadlines or budgets.  A user will be much more forgiving of a delay in a project than he would for bugs in the software.  A problem that should have been caught in testing will be remembered far longer than any scope issue or delay.  Users will grumble and gather to complain about the software, keeping the errors at the top of their mind.  Delays, however, will be forgotten as the software finally comes out to make their lives a little easier.

A good system test will prove that you have done your job well and completely.  You can be positive that the system meets the requirements you were given, and you have documentation to back that up.  You will be able to move on to the next phase of the ERP system, or move on to your next project with confidence.  You know that it’s a global world, and Technology makes it happen.

Have you been involved in a project where testing was shortened, or removed, to the detriment of the company?  Leave your comment below.

Advertisements

Building an ERP team 02/29/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , , ,
1 comment so far

Half the team wanted to delay, half the team wanted to move forward with the existing schedule.  What could we do?  We didn’t want to make anybody so mad that they would quit the project, or worse yet, quit their job.  If the team as a whole couldn’t agree, who would stand up and be the bad guy to delay the project?

This was the dilemma I was in recently.  We were doing a dry run for the go-live of an ERP implementation.  Corporate was already using the system, as well as a few other locations.  This last team to join the system was not ready; they were way behind schedule.  However, they didn’t understand what they were missing.  They felt like they had more important projects to concentrate on and the ERP project was getting in their way.  They just wanted it to be over; put them on the live system and work out the bugs later.

All of the meetings with this company so far had been as a team.  We made positive decisions with everyone’s input where everyone could agree at the conclusion of the meeting.  The other locations had seen some setbacks, but everyone had seen the need for a delay or change in the project.  We had always been a solid team who understood the decisions made.

This was different.  The on-site team wanted to go-live, no matter the consequences.  There are always problems at go-live; we should just handle them as we get them.  So what if we didn’t understand all of the setup codes now, we can change them later when we figure them out.  All of the reports won’t be ready, but every group had needed new reports after go-live.

The problem, of course, was one of risk.  If this one group couldn’t close their accounting in a timely manner, corporate wouldn’t keep the books open just for them.  They had several other sites to think about, and they can close their books on time.  Closing the books quickly, each month, is important to a public company, and it is one of the reasons we were implementing the ERP system.

The on-site team thought that if something went extremely wrong, we could just figure out everything on paper.  They actually said that.  A multi-million dollar public company writing their monthly reports using paper and a calculator.  I can see it now.

The manager on-site wanted to know what problems would cause them to not be able to close the books at the end of the month.  If we could list out all the glitches, difficulties, snags, hitches, or complications, then they would just avoid those and be successful.  It was a great strategy for him.  We would come up with a list of problems and then if we missed one, the problem would not be his fault.  He wanted to put the blame on everyone else if there was a problem.  Let’s just go-live now and get this stupid project behind us.

The rest of us in the room wanted to delay the project.  Give them more time to figure out what is going on.  Extend the schedule so that they can keep the doors of the factory open, and still spend some quality time on the ERP project. 

The problem is that we needed to work as a team.  How do we come to an agreement when we are on completely different sides of the same coin?

We gave them another couple of weeks to ‘catch up’ on what had already been scheduled.  To their credit, they worked extremely hard to get it all done.  I was getting emails at 3 in the morning.  Unfortunately it was too little, too late.  When the new deadline passed we were at the exact same spot.  Most of us wanted to delay the project, but the team on-site didn’t understand why they couldn’t just proceed.

I actually practiced my bad-cop speech.  I stood in front of the mirror and explained why proceeding down this path was a bad idea.  When we came to go-live and had to give a thumbs-up thumbs-down vote in front of the CFO, I would have to vote thumbs-down.  That is what I would have said had we gotten to that point.

The director of IT beat me to it.  He said in plain language that the deadline was missed; it’s time to change the schedule.  Thank goodness.  Everyone agreed at that point, even if the on-site manager only agreed under protest.

Going forward, I need to get them to understand that their job is to convince me that they are ready.  It isn’t just to go through the steps needed to finish the project.  There are people who are going to evaluate their readiness at the end of this project.  We will have help in deciding whether or not to go-live, based on their performance.  If they can understand that, then we have a shot at once again working as a team and getting the job done.

Anyone else have some fun stories about getting a team to work together?  Tell the world about the time you worked with a group to come to the conclusion that It’s a global world and Technology makes it happen.

The Hidden Costs of ERP – Reporting 01/08/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , , ,
2 comments

Have you figured out when you will get the reports done for your new ERP system?  Who’s going to do them, how long will it take, and what will it cost?

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.

ERP implementation can be successful if… 08/27/2011

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
1 comment so far

This is a special contribution from one of my Tatum colleagues.  See below for a short bio on Dan Gingras.

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.

ERP Without Accounting? 08/11/2011

Posted by TBoehm30 in ERP.
Tags: , , , , ,
3 comments

ERP (Enterprise Resource Planning) is usually defined as more than one software module that helps you run your business.  Usually that means that accounting is connected to another aspect of the company.  The manufacturing would automatically load the cost of goods produced into the accounting module.  The invoices can automatically be generated from the Sales Orders.  It saves time for the accountants.  It is also far more accurate that any sort of manual effort, and more timely than intermittent interfaces.

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 4th 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?