Tuesday, December 11, 2007

Identity Theft: Ripe for the Picking!

The scariest scenario that we are presented with today is the amount of private information that we are required to maintain on our employees.  When you gather all of the information that government bureaucracies (especially the Feds) require, and then add insurance companies and the court systems to the mix, there isn’t much left that is truly private about the employee or his/hers spouse and children.

All this data is maintained in the Payroll/Human Resources database.  This can be risky!  How secure is this information?  How well do you trust your Payroll and H/R staff?  I’m sure that you verified the security of the software application and have split the areas of responsibility between different individuals, so that one person doesn’t do everything.  Right?  You’ve also verified that the Payroll and Human Resource departments are locked every time the staff is not there.  Right?  Can an outsider get to this information?  Here are a couple of additional items you might have over-looked:

• Do you allow them to maintain any of this information on a Laptop? 
• Do they have a CD burner on their workstation? 
• What about USB Memory Sticks and are the USB ports active? 
• Can they Email a file to an outside source? 
• Do you allow them to “work from home?”
• What access does the janitorial staff have to these areas?

All of the above are potential security risks.  Remember, most company theft comes from within!  Identity theft is a very real problem today, and millions of dollars are being spent trying to prevent it.  But, sometimes we tend overlook the obvious.

Monday, November 26, 2007

One Step Forward in Technology, A Giant Leap Backwards in Functionality

When software developers went to a GUI (Graphic User Interface) design for their financial accounting systems, everyone was excited.  Both young MBA’s and Geeks had demanded GUI for screen navigation.  A click here, a double click there, and all would be right with the world.

Of course, these geniuses never checked with the people that actually USE the system.  Suddenly, it took longer to add employees, pay invoices, and post receipts.  Why?  Because clerks have to move to the next field by using the Mouse or by hitting the Tab key.  Using the Mouse requires removing your hand from the keyboard and the Tab key is inconvenient when entering numeric data on the 10-key pad.  Both methods cause a pause in entry, slowing the clerk down, and opening the door for data entry errors.  Then you have the “Keyboard Commands” to alleviate using the mouse.  Anyone remember WordStar?  Yipes!

Sorry to sound like the Ancient Mariner.  I’m not proposing that we go back to “cell-based” terminals.  But, maybe some of the old methods are still the best for large amounts of data.  Developers don’t know everything.  Talk to the users before making product changes!

Monday, November 19, 2007

Thanks to the Special People!

It’s the season to be thankful for many things, not the least of which are those who work so hard in your office.  I’m talking about the A/P clerks, the Payroll department, those in A/R, and Human Resources that are still working while the office parties are in full swing.  Let’s not forget the I.T. staff, as well.  They’re still manning the support lines.  Holidays may be the only time that I.T. can shut down systems, so they can install new hardware and software.

As usual, management overlooks these people.  After all, they’re not at the company party and don’t have the opportunity to run around with a lampshade on their head to be noticed.  If they are missed, some middle executive will make a snide remark about them being “anti-social” or “not a team player.” This pinhead doesn’t realize that the Payroll clerk is generating this jerk’s bonus check, and the I.T. department is installing the new PC that he/she has demanded.

To all those that go unnoticed at this time of year – A SINCERE THANKS!

Friday, November 16, 2007

You Got the Time?

You should be aware the shortcomings of many payroll systems when it comes to interfacing with Time & Attendance (T&A) systems.  The real questions are, “Do you need a T&A system?  What should you look for?”

This determination should be more than how many employees you have.  Consider the following:

• How difficult is it to determine regular hours, versus overtime and double time hours?  How many errors are made converting time to hours worked? 

• Do you have complicated union rules regarding hours? 

• Is accrued vacation time dependent upon hours worked? 

• Do you have remote locations?  Do you need to track each location separately?  Are your supervisors responsible for employees at multiple locations?

• Do you need project management accounting?

• Do your employees work different jobs at different pay rates?

• Does your payroll department have adequate time to process payroll, or is their hair-on-fire every pay period?

• Do you need to control access to certain areas of your buildings and offices?  Do you know that some T&A solutions offer this feature?

The good news is that the cost of T&A systems is coming down.  Time collection devices are getting cheaper and have more features (wireless, portable, easier configuration) than ever before.

Time spent on implementing a T&A system (providing you pick the right one) will be time well spent.  I would choose a T&A supplier that also has the time collection devices that you need.  Less finger pointing!

Before looking at or selecting a T&A system make sure that you have ALL of your policies and procedures regarding employee time keeping, organized and in WRITING.  This will ensure you select the right system and make installation easier and more cost effective. 

Decide on an employee identification system.  Don’t mix types.  Make sure it’s compatible with the time collection devices.  You’d be surprised how many times this step is overlooked.

Be certain that your payroll software supplier is kept in the loop and that they sign-off on this project BEFORE you commit to the T&A system, because they may have to provide an interface.

It will be up to you to push all parties to make this work, but it saves time and reduces errors!

Monday, November 12, 2007

How Did We Get So Messed UP?

It’s Simple.  The wrong people could be choosing your new financial system!  I have seen companies using a good financial package that met their needs, and a “New” Manager demands a change in financial systems.  It doesn’t matter that this new system doesn’t work as well as the existing system or doesn’t even come close to meeting the needs of the business.  Mix this with Upper Management that is totally inept in choosing software, and you have a disaster in the making.

The objections of the Controller and the I.T. department are totally ignored.  Logic and knowledge have nothing to do with this new decision.  No research is performed on the doability of the new software; or, if research is performed, findings are totally ignored.

How does this happen?  You start off with a Board of Directors that are all “Yes-Men” who want to hang on to their fat bonuses.  The CEO and/or President, who can’t even spell “G/L,” make the decision based on one or more of the following:

• How cute is the salesperson?  Or, they a best friend?

• How closely is management related to the “New” Manager?

• How good does the “New” Manager looks if he or she has an attitude of “I know what I’m talking about!”

• What “gifts” the proposed software company is offering.

• Their belief that the new software company is a safe bet because they are a big name company.  (How many big companies from 10 years ago are still around?  Besides these big companies buy and sell applications and each other every day.)

• Finally, which way is the wind blowing? 

The resulting situations that can occur from such scenarios are too numerous to cover in this rant, but here are some possibilities to ponder:

• Payroll insurance premium notifications to insurance companies may no longer be generated.

• The same could hold true for 401K’s and other benefits that require communication with outside providers.

• Interfaces to and from time keeping systems could fail.

• Possible loss of ability to have direct deposits or positive pay programs with your bank.

• Incomplete 1099 reporting could occur due to lack of withholding capability.

• May require entire new check designs resulting in a lengthy process with bank approvals before check processing can begin.

• Reports may not provide the information management needs to conduct business without costly custom reporting.

• Possible lack of garnishment capabilities in the payroll system.

• Possible inadequate reporting to federal and state authorities for your type of business.

• The list goes on and on . . .

What are your choices?  Well, you can grin and bear it, and maybe in 2 to 4 years someone will realize the mistake and fire the “New” Manager along with his or her cronies.  Maybe it’s time to polish off the resume and look for another job.  Believe it or not, there are well run companies out there!

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!

Wednesday, September 26, 2007

Power to the People!

I have recently seen with my own eyes an example of the power that users have over developers.  My wife has a business that relies on a rather expensive computer-guided machine.  The software that controls this machine works well, but is complex and has limitations.  Users of this product are a vocal group with well-organized, active user-group and on-line forums.  They’re not afraid to share their opinions with the developer and have made numerous suggestions of what was needed to improve the product and bring it to a state-of-the-art design.

The developer listened, making users part of the design team.  As a result new software, not a minor upgrade or bug fix, but an entirely new version has been released, and it’s at zero cost to the users!  Why did the developer do this?  They wanted to hold on to existing customers and increase their market share.  They’re smart, they are a leader in this industry, and their customers are loyal and appreciative of this innovative approach. 

What does this have to do with Accounting Software?  Everything!  Developers can’t make money if they lose their customers to other accounting software providers.  Keeping competitors away can only be accomplished if you have a better product.  Sleazy sales gimmicks and creative pricing may work for the short term, but eventually customers become aware of the deficiencies and will find another provider of software they need and demand.

Users have the power to force developers to update software if they present their demands in a professional, unified, and organized manner.  If the developer doesn’t respond, find a better solution.  There must good accounting software out there.  Do your research!

Sunday, September 16, 2007

Drill Down!

Ever been to a financial presentation before the Board, and watch the Controller trying to substantiate dollars in a particular account?  I have, many times, and it “tain’t funny McGee.” There he is, frantically thumbing through reams of paper looking for that lost posting.  Sounds of stuttering and a lot of sweating occur at moments like this. 

There is a better way, providing you have the right software!  A good G/L system needs to have the ability to “drill down” into an account and present to the viewer all postings to that account.  Sadly, there are only a few G/L systems that can do this, and even some of those are hampered by lack of historical detail data because they accumulate detail transactions into summary accounts every time a reporting period is closed.

Imagine how nice it would be having this type of software connected to a projection system on the Controller’s laptop.  When a Board member asks the question, “Why is the Board’s entertainment account 50% over budget?” The Controller can instantly display the fact that the Board consumed 3 cases of Scotch at the last quarterly meeting!  It may not have been the answer that they expected, but at least this time the Controller would not be the one stuttering and sweating!

This is but one example, albeit rather whimsical, on how this type of software can be used.  Think of all the uses it would have in everyday situations.  Rather than have to dig through all of the posting reports (if you can even find them) to determine what happened to an account, just drill down to the detail. 

Drill down is a fantastic tool, and every system should have this ability.  Are you listening, developers?

Tuesday, September 11, 2007

Risky Business!

I have been reading some very interesting accounting forum articles lately, and I am shocked by some of the questions and even more so by some of the answers posted on these forums.

It appears that many companies (even some governmental and non-profit agencies) are operating without written polices or procedures!  There seems to be no resource for a clerk to go to for answers on how to do his/her job; nothing on how things should be posted, how something or someone is to be paid, or how an employee’s benefit is to be applied.  Every decision is a throw of the dice!

When I first started in I.T. I was assigned the task of developing a financial system for my company (back when we wrote our own systems using clay tablets).  I was given the firm’s Polices and Procedures manual (P&P).  It covered everything from Accounts Payable to Payroll.  If you had a question, you went to the P&P manual.  There was rarely a question that it did not cover.  If the answer wasn’t in the manual a meeting of the Board was held, and a new entry was added.  We did not operate without written P&P’s! 

Today, companies have a risky, shoot-from-the-hip mentality with a “get’er done” attitude.  Maybe that’s why there are so many lawsuits filed by employees, so many recalls on products, and why so many businesses FAIL!  That first company I wrote the financial system for is still in business and has grown to be a leader in its field. 

I can’t impress upon you enough how important it is that you prepare a thorough and clear Policy & Procedures manual, which includes all accounting “rules” and how to apply them.  The very life of your company may depend on it! 

Tuesday, August 28, 2007

Where Is My GPS Now That I’m In A/R?

Software developers have NEVER expended any effort in designing a good Accounts Receivable.  Maybe it’s stupidity on their part, or maybe it’s because they’re just plain lazy.  I don’t know the reason, but I do know their design results are a load of horse pucky!

Examples: 

1. Developers never consider “employee” receivables.  There is no capability of passing of data from Payroll to A/R.  There is no way to identify a customer as an employee.  What you wind up doing is reserving a series customer numbers for employees, and all postings are done by hand from a spreadsheet.  Right?  Some only allow you identify a customer as “active” or “inactive,” and that’s it.

2. “Customer numbers” are another problem.  They’re not an instinctive way to reference a customer.  If you have several hundred or thousands of customers it’s a real challenge to find the customer that you’re dealing with.  A/R needs better methods to access customer records than the limited methods that now exist.  Expanding use of search fields, more effective wildcard searches, filters, and consolidated screens would be a good start.

3. Lastly (at least for this rant), the navigation through the plethora of screens is anything but intuitive!  You almost need a GPS to get around.  The result is that time is lost, mistakes are made, and training takes much longer.  You’ll be doing a lot of training, as terrible software is frustrating and stressful to use.  The result of these faults is high staff turnover!

Of all the applications within a financial system A/R is probably the most poorly designed and the most neglected by developers.  Why is this?  Upper management has no clue as to what is needed by the accounting department, and they are the ones who make the decision as to what system to buy. They are wined and dined by software salesmen and are promised that their problems will be solved.  Yeah, right!  As long as companies keep buying useless software there is no incentive for developers to spend time and money to make things right. 

Saturday, August 25, 2007

Accounts Receivable, Ignored Once Again!

Accounts Receivable (A/R) is the most ignored application by software developers.  It has been superseded by other applications with fancy acronyms.  A/R is still there but pushed to the background.

A/R is the cash register for your company.  EVERYTHING your company sells must pass through A/R.  It is instrumental on how this information is posted to your G/L.  If it weren’t for poorly designed software, A/R could provide you with useful tools to help manage this revenue!

Typically, developers follow the folly of summarizing monthly activity into the arcane design based on “Buckets.” Yes, once again they took the easy way out and eliminated all chances of having meaningful analysis data!  Did anyone ever explain to them that “Buckets” are subject to errors?  Evidently they did, as they all seem to include elaborate methods of reconciling “Bucket” totals once reports don’t cross-foot.

Speaking of reports, those supplied with the system are extremely limited in their ability to provide useful information.  For example, aging reports can’t be modified at run time.  Even worse, Balance-Forward customers can only be reported as to what amounts are current or non-current.

Reporting periods have to be closed before charge and payment amounts for a new period can be posted.  Timing of closing a period, especially at year-end, becomes a CRITICAL!  Your company’s cash position hangs in the balance until your position is current!

There are many more issues to address than what I have mentioned.  It’s the same old story.  Developers are lazy, and their sales staff should be selling used cars or doing Infomercials for cheap jewelry on some shopping network!

In this day of tight money your company’s cash analysis is extremely important.  Can you count on your A/R, or does it leave you hanging in the balance?

Tuesday, August 21, 2007

Time & Attendance Nightmares!

I have been ranting about current payroll package nightmares.  I have barely scratched the surface!  Here are some additional points to ponder:

It’s hard to believe that there are some payroll applications where overtime is hard-coded for only a 40-hour week!  That’s it, just a 40 hour a week limit!  What are they thinking?  Overtime calculations vary with state regulations, occupation, union contracts, etc.  As an example, some California employee wage orders say overtime is anything over 8 hours a day, 40 in a week, and the first 8 hours if the employee works on the seventh day.  Agricultural and Hospital workers have different regulations.  Then there are double-time considerations!  If you have a union, all bets are off because the labor contract often contains minutia that supersedes everything else.  Employees under different wage orders don’t mix, as the system can’t determine proper overtime calculation methods for different types of employment.

Rarely do payroll applications provide a means to import payroll hours from a Time & Attendance (T&A) system.  Because of this, interfaces must be written in-house, or, heaven forbid, by the application developer or a VAR.  Even then it is never seamless. 

Communications between Payroll and T&A must go both ways.  I am sick and tired of entering the same information in both systems.  After a new employee is created in Payroll the T&A must be updated with his/her name, employee #, supervisor, etc.  T&A then determines regular hours, overtime, etc. at the end of each pay period and transfers this into Payroll.  In this day-and-age it should be mandatory that payroll applications have tools that will allow users to manipulate data to and from T&A without cumbersome interfaces.

I could go on and on about the current state of payroll applications, but I don’t have the time.  If you’re involved with your company’s payroll YOU know what the problems are.  It’s time to rise up and demand developers get off their collective tushes!

Thursday, August 16, 2007

Payroll Nightmares

I have recently been ranting about faulty G/L packages.  Now it’s time to turn my attention again to the sorry situation with Payroll packages.  Of all the financial packages Payroll is perhaps where the most improvement is needed. 

Here are some payroll points to ponder:

Can you believe that some payroll packages don’t distinguish the different status classifications that an employee may have?  Magically, they are either Active or Terminated!  What about on L.W.O.P., COBRA, Family Leave, Part-Time, Full-Time Exempt, Full-Time Non-Exempt, etc.?  Without this distinction certain benefits cannot be offered, leave balances may not be computed correctly, pay cannot be correctly computed, and the list goes on.  Without proper status codes the payroll application cannot process employees without manual intervention.

In addition, most payroll applications can’t handle multiple state income tax calculations within the same dataset!  If you are processing payroll for offices that are in different states, the payroll application software and data files will have to be duplicated in another dataset for each different state.  That means separate runs for each occurrence!  Another example is what professional sport teams have to deal with when they play away-games in another state.  Reporting these earnings to state and federal agencies becomes an even bigger nightmare!

Another pain in the backside is the inability to “post date” tax tables and pay rates.  In other words, you need to have the ability to set up new tax tables or a pay rate increase in advance and have it become effective on a given date.  We also need an “obsolescence date” to disable a table or rate when no longer active.

Now you have to remember to make table and rate changes between payrolls.  What happens if you have to re-issue a check that was originally issued with the old rates?  Tax tables and pay rates must be date driven!

Most current payroll applications are so terrible they shouldn’t be on the market.  Frustration with this situation just keeps building because developers don’t care! 

Stay tuned.