Tuesday, October 23, 2007

Four Simple Things

Does your company need to financially manage different projects, some taking longer than a year, such as in agriculture or construction?  Does your company have a business cycle that does not coincide with your fiscal year?  Do you have to manage and track many different events each year?

If your answer is, “Yes,” to any of these scenarios, you’re not alone.  Are software applications out there to help manage this dilemma?  Not many, and none I know of with seamless interfacing!  There are some job costing applications, but they’re a lot of additional work and don’t always have the complete financial picture.  The same is true for some project management systems, most of which are usually very structured and inflexible.

The general ledger (G/L) should be the application that you turn to, mainly because all financial data winds up there eventually.  Right?  We’re back to our old problem.  It seems to me that most general ledger packages out there today are trash!  From my past rants you know the following problems:

• Rigid account structure.  You can’t modify account structure (add additional sub-accounts, change the size of account numbers, etc.) once your initial general ledger is built.

• Restrictive calendar.  Usually G/L applications offer only one calendar, and it’s preset for 12 or 13 fiscal year “periods.” What happens if the project lasts for 18 months?

• Lost detail.  Detail is summarized into period reporting “buckets” and then deleted!  You should be able to hold onto the detail, and if you want summary totals on your report, let the report writer do the summarization, not the G/L.

• Statistics.  You can’t measure performance on dollars alone.

That’s it, just 4 simple things that need to be corrected in today’s G/L design, and you’ve got the tools you need.  I wonder when that’s going to happen.

Sunday, October 14, 2007

Disaster Awaits!

Pity the poor Systems Manager with the never-ending challenge of keeping every workstation current not only with Microsoft’s Windows™ updates, but updates, fixes, and new releases of the financial system.

Many financial systems require that the entire software package be “pushed” to each and every workstation when updates are applied.  Additionally, most of today’s financial systems are huge!  This data transfer takes valuable time.

Major release upgrades are a disaster waiting to happen.  If something goes wrong you may not be able process payroll, write accounts payable checks to pay the bills, or a plethora of other problems that could bring your company to its knees.

Consider what must take place before you go “live” with a new release:

• User training of the entire hands on staff, from managers and supervisors down to line clerks.

• File conversions:  Unload the database, apply changes, and reload the database.  Did you check to see if you are on the supported release of the database?  Oops!  Oh, no!

• “Push” the new release via remote access or, heaven forbid, visit every workstation and install the new software release.

• Of course, you have already spent weeks testing the software prior to installing.  As usual, you test the posting and processing procedures.  Then, you review all reports to make sure they still reflect information the way you expect.

• Do you have the staff and time to run parallel?

So what’s the problem here?  Software developers could help us save time, improve accuracy and reduce our stress in a number of ways:

• Provide accurate and complete release notes early on.

• Provide better training aids for users.  How about documentation?  (What a concept!)

• Finally, incorporate true 3-tier systems architecture.  This would eliminate, or at least minimize, the installation of software at individual workstations.

Why don’t developers do this?  Money, pure and simple.  They wouldn’t make their fat consulting fees if they made it too easy.

Sunday, October 07, 2007

WAKE UP, SLUGGARDS!

Of all of the major components of a financial system, Accounts Payable (A/P) is probably the most simple to design correctly; yet, it is often the most poorly designed of the entire system.  Why is that?

The truth is that A/P is not the flagship of the design.  It’s more like the supply ship!  Not fancy, not the center of most management meetings, just a valuable tool that manages expenditures. 

We all know that most developers are lazy by nature.  They don’t expend effort unless it’s required.

So what’s missing in most A/P designs?  The list is long, but how about the following for starters:

• We need the ability to research a vendor’s invoice from the vendor screen without having to run a report.  This would include the ability to see a digital image of the original invoice.  Invaluable for research.

• We need the ability to research payments made to a particular vendor’s invoice from the vendor screen without having to run yet another report.  We need the ability to see a digital image of a check or the posting of the electronic transfer of funds for that payment.  Again, invaluable when researching.

• Where are multiple discount options for a vendor?  Many vendors offer different payment discounts based on what you’re buying or the amount owed.

• Why not provide a flexible method for analyzing the benefit of maximizing float according to due dates versus the savings of using maximum discounts.

• We need the ability to access vendors by a meaningful code as opposed to some arbitrary, non-intuitive number or code.

• The package must have full support of 1099 type reporting.  (See article: “To 1099 or not 1099.”)

• Finally, give us detail information.  Don’t summarize into reporting periods or require a formal year-end close, losing prior year data.  How archaic.

There are more items that need to be included before we get a GREAT A/P application.  This is enough challenge for sluggard developers for a while!