jump to navigation

ERP – Who to Choose 12/30/2012

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

I’ve often been asked “Did we choose the right system?”  Usually it is right after we experience a serious bug, or something goes wrong causing a project delay.  Would another system have prevented this particular issue?

The answer is always ‘Yes’.  We did pick the right software, despite the current problems.  And ‘Yes’ another system would probably have allowed us to avoid this problem, but would have caused others.  As long as we followed our plan, identified our priorities and compared correctly, we know we chose as best we could.

So what was the plan?  What do you need to plan in order to choose a new software system?

Requirements

The single most import aspect of choosing your new software is the list of requirements.  You need to understand what you need to succeed, and a list of benchmarks so that you know when you get there.  Everyone in the company should have the opportunity to help prioritize the requirements.  This is the chance to visualize the company running at peak operational efficiency and growing as fast as possible.  The new software needs to be able to accomplish all of the current requirements plus future needs.

You need to think about your requirements from a perspective of the future.  Will it be scalable enough?  Does it have the modules to cover functionality that you don’t need now, but could find a use for when there is time to experiment?  What other tools will you need to go along side your new software?  How much data does it need to accept and how?  What other systems will you connect it to?

I make a long list of requirements, and then prioritize them from most important to least important.  Then I like to make a single sheet listing the top requirements with room for evaluation and notes.  These note pages can be used as a scoring sheet for objective comparisons between systems.

Support

You will need a lot of support during the years of using this software.  Make absolutely certain that the company you choose will have smart people who can guide you when you have problems.  You might have to call other companies already using the system to get a good idea of how their support program works.

Some companies charge extra for support, and some have fixed contracts that automatically include support.  You will need to know the structure of support before going into negotiations to buy your new software.

Implementation

Working with another company to implement new software is not an easy project.  You must be ready to accept them as partners.  They should have lots of experience working with companies in your industry and of your size.  They should be ready to explain the process, their expectations, how long it should take and how many people need to be involved.   You need to get a feel for the difficulty of an implementation, and how much work your team will do compared to how much work will be done by outsiders.  Training will take up a large amount of implementation and could be done in different ways; how much time will this one take? 

When getting trained, you will have to make choices on the basic setup of the system and how much to change the out-of-the-box configurations.  Most large software allows you to process similar functions differently depending on requirements; you must have an idea of how many different choices there are to be able to compare the different choices of software.

Loading Legacy Data

Your system will begin either fresh with no data, or have old data loaded into it.  You will need to get some idea of the difficulty of loading data into the system.  Some data may be easily added using standard formats like Excel; and some may require more effort.  You may have to load data compiled from different systems; it will have to be mapped to the new system.  How much help will you get?  How much experience do they have mapping data from your old system?  How successful have other companies been with loading data?

Setup

Obviously your new software will need to run on a computer.  Whether that computer is located in your own office, at a server farm, hosted by a third party, or transparent to you in a SaaS environment is totally up to you.  Make sure that your needs are covered by the company producing your new software.  It would be a regrettable decision to buy software that couldn’t be run as a service and then ask them to setup SaaS.

Interfacing with Other Systems

Any software your run should not be run in a vacuum.  It will need to create send data to people and systems, as well as receive data from people and systems.  You may want automatic interfaces setup to continuously communicate with existing systems.   This should all be possible on any new software that you choose to buy.

One of the main reasons I left my first job was that the software I used couldn’t communicate with anything.  Even creating a report was difficult.  I knew that software like that was doomed to obscurity and I needed to get out before I was left in the dust.

Make the Choice

Using your prioritized criteria, you should be able to make a good decision of which software to purchase.  Don’t look back for regrets; you made your decision the best way you could.  There will be problems that you will be able to solve, don’t let that destroy all of the hard work you put into making the right decision.

Have you been through the decision process?  Did it work for you?  Do you like the new software?  What would you have done differently?  Let me know in the comments.

Be happy with your new software.  You now understand that it’s a global world and Technology makes it happen.

Choosing Your New ERP System 11/29/2012

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

After you’ve gotten the approval to start the process for a new ERP software system, it is time to start the search and make the decision of what to buy.  It is a project on its own just to make that decision.  It should take one to three months to go through all of the options to determine the best solution.

The way to begin this project is to lay out your plan.  You need to have an idea of what steps you will take and how long you have to finish.  The plan needs to include who will be involved, how much, and who gets to make the final decision.

The first part of the plan is who will be included.  This is an important project and the right people need to be included on the team.  A senior manager that knows how important the project is, and has authority to set priorities needs to be on the team.  Others as representatives of major departments need to be included.  The best person to represent the department doesn’t have to be the highest manager; you need to include the one who understands what is needed, but also has the time to attend the meetings.

As you get a commitment from enough people to fairly represent the company, you will create a meeting schedule.  Once a week may be enough to start, but eventually you will have vendor responses to review and demonstrations to watch.  This will increase the time commitment from the team.  These people need to understand that this project is just as important as their ‘day jobs’.  They will need to dedicate some time to this project, even if it means doing overtime on their normal responsibilities.  This part is crucial because ignoring the project for too long will ensure failure.

Probably the most important part of the selection process is the requirements.  The team needs to define their requirements for the new system and prioritize their needs.  Not all software will do exactly what they need in the way that they want it, so they need to be ready to determine what is critical and what is nice to have.  The requirements should start with replacing what they already do, and then consider what is needed for the future of the company.  You will need to include the details of current operations such as Purchasing, Selling, Accounting, etc.  Also think about reporting, dashboards, paper output and screen design. 

Along with the processes, you will have to consider the technical aspects of the software.  Will you want it in the cloud or on premises?  If you are thinking about the cloud, do you want software as a service (SAAS) or platform as a service (PAAS)?  You need to know the difference, and understand the language so that when a vendor describes their solution you can correctly interpret what they are saying.

Can your IT department support the new demands of the software?  Will you need new people to create reports, customize the software, and support the growing demand for security?  These are import discussions to have before choosing the final software.

Once you have a good set of requirements, you can send out some sort of questionnaire, request for proposal (RFP), or other document to a list of vendors.  Their responses should be evaluated by the full team to determine a short list for demos.

You can have 4 or 5 short demos if your list of vendors is still too long to decide.  That should help you narrow the choice down to 2.  These demos need to be held to under two hours, and the vendor needs to be aware that you will cut them off if necessary.  Doing a lot of demos can be overwhelming to the team and they will forget what the first demo looked like at the end of the process.  You need to make sure that discussions are timely and that notes are taken for later review.

Your final choice should be made from the top 2 vendors.  These final vendors should be given the opportunity to show you their best presentation.  Give them the amount of time that they need to impress you.  This might take several hours for each of them and require a couple of days worth of time from your committee.

I like to prepare a document for the team that lists out the requirements and gives them the ability to write notes about each requirement and give each a grade.  The grades can then be tallied to objectively decide which software is better.  If notes are made using the same format, they are easier to compare.  The notes also make it more difficult to forget the important parts.

One of the hardest parts of this process will be to notify the losing company that they were not chosen.  They may come back with lots of questions that will require more work and put you in an uncomfortable position.  One time, I had a salesman email my boss describing how unfair my process was, and how they thought they were being strung along when the decision had been made in advance.  While embarrassing, I had the full documentation to show that no decision was made until the end, and the notes showed the grades where the number 2 company was very close, but clearly the second choice.

Once you make the decision and notify the winning company of your intentions, it is time to sign a contract.  Make sure that you have professional negotiators at the table to get the best deal possible.

Now that you have decided on your new ERP or other large software project, the fun is just beginning.  You already have a good team who understands the issues, and are ready to work.  They know that it is a global world, and Technology makes it happen.

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.

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