Adopting new GP2010 features

I'm behind on my blogging this week!  Usually my weekends are my writing time, but instead of writing blogs, I was doing my own month-end and billings for January.

One of the clients I sent an invoice to emailed me today via the new GP2010 EFT Remittance email functionality with my remittance advice for their January invoice.  

This client has been using GP's EFT for Payables for years but only with a handful of vendors each month, the majority of their payments were still via cheque.  They had been paying me via EFT but without any remittances or notifications so far.  They started asking me about EFT remittance/email functionality as they wanted to expand this to more vendors but needed to have a plan for the remittance advice.  

Last year, I had gathered information for them on a few of the leading third party add-ons out there.  However, once the beta of GP2010 was released and the new functionality was announced, I went back to the client and introduced the upcoming functionality to them.  I could have easily sold them some third-party software add-on that would allow emailing of EFT remittances, they would have proceeded and been off to the races.  However, being on GP9, with Canadian Payroll and a product lifecycle end in sight, I recommended they wait until they upgrade and evaluate the “free” functionality they would get before committing to a software purchase they may not ultimately require anymore.

So, last summer the “test” upgrade began and once the usual upgrade formalities were out of the way and the core project deliverables were met, I worked with them on testing the EFT functionality.  It turns out they were happy with the functionality it provided.  They did their own testing and documented the configuration they found worked best, to use in the live upgrade.  We discussed the how this would change the existing A/P process, to re-design their existing process to incorporate this change.

Late last year, I completed their upgrade from GP9 to GP2010.  After the year end tax updates were done and out of the way, based on the testing work we did during the sample upgrade, the client took their configuration notes, and set up the new functionality.  

Being a little bit patient allowed them to take advantage of a new GP2010 feature – without purchasing additional software, and with relatively minimal additional consulting cost.  

How cool is that?!

By | 2017-08-13T11:46:31+00:00 February 2nd, 2011|General Stuff, Payables Management, Process Redesign|2 Comments

The cost of inefficient processes

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
By | 2017-08-13T11:46:32+00:00 December 19th, 2010|General Stuff, Process Redesign|0 Comments