Converting Existing Data

Usually the software vendor will have a technician committed to your organization. They may even come on site for a specific period. There will be some housekeeping items to take care of such as obtaining the appropriate IT platform, deciding how much past accounting data to convert over, determining the security of who has access to what, choosing your internal point person for implementation and support, and probably several other issues I’m forgetting. I won’t try to give you any recommendations on these, other than to think through them diligently prior to the actual conversion. Normally, time spent from the software vendor’s people is either limited, expensive or both so you’ll want to be as prepared as possible before that begins. They should also have a checklist of some sort which will give you some decisions and preparations to make during this time.

I believe that the data conversion is one of the more critical tasks and is the time to really get your hands dirty. Once you get the data converted for the most recent year, I like to go account code by account code to make sure the balances match between the two systems. For example, if you’re converting data today for calendar year 2008, I’d print out the balances for the lowest level of account code and compare between the two systems. Review the vendor balances also.  I wouldn’t necessarily print out the detail of transactions for the account codes unless you come across a discrepancy. This time of conversion and comparing data is not a time to take shortcuts.  Make sure that your past data has converted properly and follow up quickly on discrepancies.  When you find discrepancies, it usually uncovers more than just the error itself; it often uncovers a processing difference between the two systems that will need to be reconciled or fixed.  This is a crucial benefit of the conversion process and I would recommend significant time be allocated to this step.

Run Parallel Systems

Another crucial step in the process is the period of time that you operate both your old system and the new system simultaneously. This is a fairly labor intensive process that requires making dual entries for every transaction while running the parallel systems. I would recommend 6 months of running parallel systems, during which time the new system can be evaluated, the bugs worked out, and your processes developed related to the new system. Again, this is very labor intensive because each transaction is being entered into both systems, effectively doubling the data entry work. This may look differently depending on what kind of software you’re switching to and from, but I would definitely recommend some kind of parallel process, it is worth it.

As mentioned above, you may be able to negotiate with the software vendor for this to be a trial period, and you wouldn’t be required to purchase the software until the end of this period. This may be easier said than done, but it is worth a try, and software vendors will agree to quite a bit up front in order to get your business.

Once again, just like in converting existing data, you’ll want to spend significant time making sure that the two systems come up with the same results. Review the account balances comparatively for each month to make sure that transactions are being processed the same way. Any discrepancies in account balances between the systems should be investigated to determine if there is a processing difference that needs to be reconciled or fixed. Sometimes the difference is merely due to human error, but you’ll want to look into those and see if there’s something about the new system that increases the errors. Try not to berate your staff for these, they’re probably fairly stressed at this point.

Train Your Users ! 

This is mostly self explanatory and simple, but failing to do it can be catastrophic. Your end users should receive training on the new software before, during, and after the conversion. Most likely, there will be some fear and hesitation involved. Fear and hesitation can lead to resentment and complaining really quickly if there is not proper training for the end user. Training may take on several different forms and may even be web based. This will often depend on the software vendor and is something to be worked out in the initial negotiations. Whatever training method, be sure to take time to plan and schedule training that will get the end user up to speed on the new software. This is another pitfall of software conversion that many fall into and the very people that this is supposed to help, end up frustrated. 

Seamless for Management

One thing I’ve learned in my short career is that people in top management do not want to hear excuses or problems; they want their reports, they want solutions, and they want results. Whatever reports your superiors were getting before the conversion, make sure they get comparable reports after the conversion. If they want more detailed or different reports, make sure you understand their needs before beginning this process. Customization of reports is probably a good task to get assistance from the software vendor or support team. You’ll want to work hard to make this as seamless as possible for the end user, including the top managers that are reading the reports. I guarantee this will make life easier for you and the people above you. It may be easier said than done, but please do everything in your power to make the transition as seamless as possible for your users and supervisors.   

Document, Document, Document

From the very beginning, keep detailed notes of your staff meetings, vendor presentations and implementation team meetings. All of these will be helpful in the future.  Also, as you develop processes, I would suggest creating an internal manual, to be shared, updated and remembered. Use screen prints and step by step instructions so that you can go back to these learned processes and repeat them as necessary. Some processes may only be used once a year for tax purposes or year end close so it is very helpful to be able to refer back to the manual as opposed to re-learning difficult procedures at crunch time. The more documentation you produce during the process, the happier you’ll be going forward!

Final Thoughts

Goodness, even writing this blog entry makes me weary of software transitions.  My focus has been in switching accounting software but many of these concepts can be applied to switching any kind of key software for your organization. 

Again, of all these areas, I think the staff team, including the leadership, is the most critical by far. I would focus on clear communication of responsibilities, involvement of key people from the beginning, and keeping the end user in mind. Don’t let the process scare you.  If done correctly, a software transition can be a huge contributor to your organization’s future success.  I wish you the very best of luck and please call me if you would like to talk through this.

 This post will cover all the steps, in my opinion, you should take leading up to the point of actually converting your data. We’ll have yet another post dedicated to the technical side of working with new data and reports. Enjoy, and we of course appreciate your comments.

 Staff team

First things first, put your evaluation team together. It may be a staff team of 2, it may be 10. I would suggest a cross section of the organization for the group that helps make the decision, then a somewhat smaller implementation team. You need to get several groups on board with your decision on the actual software package, but it definitely should include individuals affected by the accounting software and/or the users. 

Next, assemble your other team, the implementation team. Make it very clear to them and the users that this will be no picnic. There will be times when everyone is frustrated and they need to be prepared for that. Those that are faint of heart or easily frustrated need not participate on the implementation team.

 Timeline

Develop at least a rough timeline for the project. Start at the end and work backward – the end being that the software is up and running without parallel use of the old system. You’ll have several landmarks on the timeline including, interviewing vendors, deciding on software, approval of final purchase, parallel running with old system, conversion of data, and probably several others. From the beginning, I would recommend staff meetings with the implementation team at least weekly. You can include the other groups helping with the decision early on and as needed, but make sure the implementation team meets regularly. Make sure that tasks are delegated in a way that will keep the team on schedule and that each person is clear about their individual responsibilities.

 Do your research on vendors

An initial search can be done over the internet. Find a group of vendors that provide accounting software to organizations like yours. You might even find vendor references that you can contact. I would also contact some similar organizations in your area to see what they are using. If you’re part of a national organization, contact the main headquarters and some of the other locations to possibly get some leads and information. Review a demo provided by the vendor, through an online meeting portal or in person if financially possible. This can not only introduce you to possible software choices, but will also get you familiar with some available features that you might want to be looking for.

Vendor presentations and/or bids

Hopefully, you have now accumulated a list of software vendors that will bid for your business. Depending on the size of your organization, the vendors will give you some type of demonstration.  This can be worked out when you first contact them and may or may not be in person.  If you’re in the DFW area, chances are there is a representative of the software company that can come give you a demonstration.  Typically, they at least will bring a sales person and a technical person to show you the screen shots of the software’s capabilities. I would recommend having no more than 5 vendors go through this process and have your larger decision group sit in on these demonstrations. 

One issue you’ll face during these meetings is that the salespeople will tell you that the software will move mountains. Not to generalize all software salespeople, but they generally answer “Yes” when you ask if the software can do something.  I would take detailed minutes of the demonstrations, ask the technical person the same questions, and also have them show you the software performing the task before taking their word for it.

 The Decision

This is probably a whole blog entry in itself, but I would obtain verbal and written input from each member of the group directly after each presentation. Sometimes the last presenting vendor has an advantage because it’s the most fresh on everyone’s mind. You’ll want to avoid that trap by taking good notes and talking amongst your team right after each demonstration so that you give each software package an equal chance to impress.

The decision itself ….. again, I could go on and on, but make sure you hear from each group member, try to accumulate and rank your needs and see how those are met by each software package, and make sure you get a true “apples to apples” comparison of the costs. There are different charges for different customizations and it is difficult to sort through that for a true comparison, but the effort is worth it. Finally, do some voting, ranking, eliminating, arm wrestling, or whatever else you need to do to come to a final decision. You might start with a vote on who to eliminate. You can’t make everyone happy, but it would not be good to pick anyone’s last/worst choice vendor. 

Once you make the decision, have some final comments to your team that will help get everyone on board for the conversion task ahead. Maybe that’s a Friday afternoon and then you can head somewhere for happy hour or some other well deserved break.

My last post in this series will go over the actual conversion and parallel systems, among other things.  Thanks for reading !!