Last week I sat with a user at a not-for-profit agency. This user is an older semi-retired gentleman who has a fairly strong accounting background, and is supposed to be working 3 days a week. They converted to Dynamics GP in October 2010 after using Simply Accounting for years.

The Executive Director called me to arrange for me to come in due to concerns that her financial co-ordinator had not, at that point, started entering any November activity. He had received what she deemed a lot of support from the folks who implemented them. They were rapidly approaching the end of a quarter (end of December) and she has only recently received October financials.

The Review

It didn't take long to see why the workload seemed insurmountable to the user.  Here are some of the things I noticed that were delaying the co-ordinator's efforts.

  • Continuing to run parallel systems entering all transactions in both Simply Accounting and Dynamics GP
  • Hand-writing the G/L account coding on every invoice twice – old G/L Account numbers for Simply and new ones for GP
  • Hand-writing document tracking items on the invoice like JE#, Voucher #, Batch # etc.
  • A highly inefficient payables entry process (see below), including mostly using the mouse to navigate instead of keyboard shortcuts or tabbing through fields.

Big Inefficiencies

It was clear to see that the training this user received perhaps wasn't well suited to him.  The accompanying documentation was little more than screen shots with what the fields meant, hardly something a new user could use to understand  where one thing fit into a larger process or cycle.  This user is incredibly detailed, and, dare I be the pot calling the kettle black, is highly anal, wanting to know all the nitty gritty details right now!  

The following is one of the observations of his A/P entry process, in this case, re-entering invoices that had already been paid out of Simply Accounting.  Before beginning he has already spent time coding his invoices with GL accounts and verifying HST amounts.

  1. Create a batch
  2. Enter a Payables Transaction Entry – “cheque on the fly” method if the SA cheque only paid one invoice, otherwise “on account”
  3. Adjust the distributions (thankfully he has default Purchases accounts in place on most vendors)
  4. Print the cheque (on blank paper)
  5. Remove the staple from the invoice and SA cheque stub
  6. Write down the voucher # on the invoice and payment # on the cheque stub
  7. Save the transaction
  8. Close the Payables Transaction Entry window
  9. Open the Payables Batch Entry window
  10. Post the batch
  11. Print the posting journals
  12. Write down the PMTRX audit trail code, GLTRX audit trail code, JE# on the invoice
  13. Staple the blank paper cheque, posting journals and invoice/SA cheque stub together
  14. Repeat

In case this doesn't sound too bad to some of you, this is his process for one invoice!  Yes, he was creating a batch, entering, posting, starting over each time.  This process took him about 20 minutes.  He had a pile of approximately 28 cheques to get through, some with multiple invoices.  At this rate, barring any complications, he would be entering at a rate of 3 invoices / hour, and it would take him 10 hours to get through this pile.  Wow.

The Analysis

Reviewing the steps, there are a lot of “why?” questions in my mind.  Part of process redesign has to include reviewing the process and trying to understand the rationale for why certain things are done certain ways.  There are lots of times when some wacky processes are in place for fairly legitimate reasons.  Most times however, no one knows why something was done a certain way and they cannot think of a reason not to change x or y.  

No one can make solid recommendations if you don't understand what they are trying to accomplish in the first place.  Armed with that knowledge, you can then help tweak, rewrite, or otherwise alter a process to accommodate their needs with fewer steps or less cost or whatever the improvement results in.

We reviewed the hot spots of this process – what he was trying to accomplish, why he was doing things a certain way etc.  It turns out for the most part, he wasn't confident that he was doing things right so he was going overboard documenting where things were posted to be able to find it after posting.  He also had a mistaken impression that he had to post things individually but still had to use batches.  He wanted to be able to attach the journal entry (GL Posting Journal) to every entry as backup.

The Recommendations

There were a lot of ways to improve his plight, and here are the high points we discussed.  More things will be reviewed in a subsequent visit.  With any changes, sometimes spacing out the changes and phasing things in over time helps with adoption, which is my plan with this client.

  1. Eliminate posting multiple batches and printing posting journals multiple times.  Create a batch, enter all the relevant invoices in it, then review it all and post.  Once.
  2. Keep the posting journals in a file by date for easy reference instead of having individual JE's to attach to each invoice.  Eventually, once he is more confident in the output and where to quickly find things in GP, this step can be eliminated.
  3. Review keyboard shortcut options and benefits of using the tab key to navigate through the screens instead of using the mouse.  Reducing minor “missing required fields” errors, and emphasis on navigating through windows in a desired order.
  4. Simplify the documentation on the hard copy invoices – voucher # should be sufficient in most cases to look up something after the fact.  Record the payment # on the cheque for the same reason.
  5. STOP USING THE OLD SYSTEM.  This was the biggest, being a part time resource, he had little time to spare getting used to a new system and running parallel was not helping him finish his month end on time.

There are more things that can be addressed but this was a starting point and by the end of that first day, we managed to get through all of the outstanding invoices to catch up in that area at least.  

The Cost of Inefficiency

For this organization, the cost of this user's inefficient methods were:

  • Higher payroll costs (longer hours, working more than scheduled 3 days a week)
  • Delays in reviewing financial statements, results outdated by the time they arrive
  • Delays in paying vendors, possibly missing payment discount opportunities
  • More time data entering than data reviewing or analyzing
  • Health costs: higher stress, losing sleep, creating cyclical issues – the more tired, the more likely to make mistakes, the more likely to be frustrated, increasing stress