Thursday, August 09, 2007

Bean Counters’ Lament!

Most General Ledger applications are worthless as a financial management tool.  They report only historical “dollar” information, usually in a time frame that has nothing to do with your company’s business cycle.  I have alluded to this problem in past rants.  Here are some of the specific problems:

Typical G/L reporting is a P&L, Balance Sheet, and a summary Financial Statement.  This may satisfy the bank, but it does NOTHING for TIMELY information on the efficacy of your company!  What good does it do to sell a lot of Widgets if you are losing money on every one that you sell? 

Dollars alone are not a good measure of performance.  The value of money fluctuates over time, and comparative statistical data is required to evaluate a true picture of performance.  Few, if any, financial packages offer broad statistical information “within” the G/L, and those that do only have limited capabilities.  Every G/L account should have the capability of being supported by at least one statistical account.

Another requirement for an effective financial management tool is flexible reporting periods.  I have ranted on this subject before in, “Can the Buckets.” Does your business cycle revolve around the month-end reporting?  Would a weekly position report be more useful?  How about comparing last week to the same week a year ago?  What about a five-year comparison?  Why lose the detail information after the current year?

To perform effective analysis, interface data from ancillary systems (A/P, A/R, Inventory, and Payroll) must be timely and not tied to a laborious batch process that can only be run on a dictated schedule from the application developer.  This would have to include statistical.  Information will not be timely if it can only be updated on a weekly or monthly schedule.

Most accounting packages don’t provide this capability or even a decent report writer to work with.  Instead, the accounting staff is required to spend an inordinate amount of time preparing spreadsheet reports for management because their antiquated, poorly-designed, piece-of-trash financial package can’t get the job done!  I can’t believe that bean counters aren’t pitching a fit about this!

Tuesday, July 31, 2007

What’s Important?

When selecting a financial system today what applications within the system are the most important?  Where is your greatest need?  Where is your maximum exposure?

The goal of all financial systems should be to manage the company’s money and provide the required reporting for governments, banking, and internal management.  Certain applications should provide the tools and safeguards against making mistakes that could expose you to government and civil legal situations.

Accounts Payable needs to provide taxing authorities with the payment information that you made to your vendors.  Accounts Receivable needs to interface to your operational systems (ERP, etc.), as it is basically your “cash register.” Fixed Assets and Customer Management also come into play.  Having said all that, clearly the most important applications are Payroll-Human Resources and General Ledger.

Payroll and H/R are extremely important!  There are more blogs, chatrooms, and bulletin boards devoted to these applications.  Your company may face all kinds of legal and regulatory issues if these systems don’t provide you with the tools that you need! 

• Payroll must be timely and accurate.  The Payroll Department needs to have the ability to formulate any payment, voluntary deduction, or taxation that may occur. 

• H/R needs a close integration with Payroll to manage employee benefits. 

General Ledger is the “collecting pot” where everything financial comes together.  Without flexible, open-ended data collection, statistical information, and a powerful report generator, this application is worthless as a management tool.  Data needs to be stored without Date Restrictions (i.e., “Buckets”)! 

Your company needs to know its true financial status in a timely manner to determine where improvements can be made to make the bottom line better.

If you have any doubts about these applications in your current system, go look for a new one.  The cost of conversion is nothing compared to the cost of failure of one of these systems!  Don’t select a new system unless it addresses these needs!

Sunday, July 22, 2007

$5 Fixes

I have a wish list of 5 things I would like to see added to current Financial Applications.  They’re not that difficult (at least to the end-user’s way of thinking), and I call them, “$5 Fixes.” I realize they would take time to implement, and the impact on the system’s selling price would be nil.  However, the impact of these features for the end-user would be a day-to-day revelation!

Here they are:

Fix #1:  A visual-lock message on a record that is being modified by another user BEFORE you start to edit that same record, instead of when you try to write your edited record back to the file.

Fix #2:  A real-time update when someone has changed a record that you are currently viewing, so that your screen automatically reflects the changed information without you having to refresh the screen.

Fix #3:  Allow the end-user to build and save their own search filters.  This feature alone will save considerable time on daily, repetitive operations.

Fix #4:  Save answers to dialog questions for routine reporting and procedure functions.  Why enter the same information every time you run a routine report or update files?  Make sure you can also edit the dialog as needed when you run them.

Fix #5:  Accurate timestamps on ALL records.  If you have ever had to go back and reconstruct what someone did, this feature will save hours and help to analyze what happened.

Fix #6:  Okay, I lied.  There are at least 6 things I want changed.  Give the application administrator “column-level security” (read/write on each field in a record).  Some systems give “row-level security” (by record), but column-level security is really needed.

This is a short list.  I could go on and on, but I would really appreciate it if any developers would address these $5 Fixes.  You know how developers are, cheap and lazy!

Sunday, July 15, 2007

OOPS!  We’re Down, Now What?

Relying on an outside firm to handle your critical system needs became very painful recently for several companies.  A major satellite-based Internet provider lost their primary e-mail accounts during what was described as “routine maintenance,” and their recovery from back-ups failed!

Almost 2 days went by before accounts were re-established, and no one knows how many lost messages there were, especially for those that used web-based e-mail accounts.  Support was terrible.  There was a pre-recorded message that stated in effect, “Sorry, there’s nothing we can do right now.” Individual home users were inconvenienced, but many businesses were brought to their knees!

What has all this to do with accounting software?  It’s our ever-increasing dependence on other companies for mission-critical systems that puts us at risk.
So, how dependent is your company on outside software providers?  When you lose the use of your accounting system because of a design flaw or a system failure, how quick is the system restored, and how thorough is the recovery?  What would the loss of its use mean to your company?  Can your company survive a week, or even a couple of days without access to your business data?  Oops!

What should you do?  If you’re looking for a new system, consider the following questions for the software developer: 

• How strong is their knowledge of the actual system?  Did they just buy the source code from someone else? 

• What’s their track record?  Talk to their current user base.  If they won’t provide you with that information, pick another provider. 

• How long have they been in business?  Did the entire staff just graduate from business school? 

• How strong are they financially?  Are they a target for takeover? 

• How many levels of support are there?  Count the consultants, VARs, etc.  The more levels there are, the slower the response, and you’ll find more finger-pointing going on.

Even if you’re not looking for new software, you should ask these same questions of your current software provider.  The results could be scary!  Do your research, and get it right.  You could lose your job by making a bad decision!

Saturday, July 07, 2007

Communications, Get Involved!

It’s no wonder why software developers spend most of their time and money trying to attract prospective new clients.  After all, that’s where the money is, so you can’t blame them.  But, how well do they communicate with existing clients?

I’m so tired of developers who make little or no effort to inform their clients about new enhancements to the existing software.  Sometimes they don’t even provide this information to prospective clients (see the Smoke and Mirrors rant)!  These developers are the elitists, and you probably already know who they are.  They figure the client will discover these enhancements at the next major release, and that’s good enough!

Having said that, it’s not always the developer’s fault that their clients are not up to speed on the latest improvements and modifications to the software.  Often the client doesn’t put forth any effort to become informed.  The client’s reply to this accusation is that they don’t have the time to read all this information that inundates their e-mail and/or the Postal Service.  If they won’t read their mail, they for sure aren’t going to take a phone call from their sales rep.  Of course, when they do find out that the developer has a new feature (one that the client has needed desperately for 6 months), the client is going to be upset with the developer for not letting him know sooner!

What’s answer?  I don’t have the answer.  Apathy is hard to overcome.  Probably the best solution (as a client) is to belong to the software user group and get involved.  Participate at the conventions and establish contacts within the group.  If your developer does provide software update information, make sure you read and understand it.  It may be exactly what you need. 

A regular dialog with your software rep and a concerted effort to stay abreast the latest enhancements will keep you on the leading edge.  And, when the developer doesn’t furnish you with what you need, communicate – often and loud!

Thursday, June 28, 2007

Smoke and Mirrors

Trying to make an intelligent choice when selecting a new financial package can be a very exasperating experience!  Trade magazines of the past were useful, but today they’re more interested in covering the latest PC gadgets.  Now everyone uses the Internet for research, and that can lead to real frustration.

I like to do my research without outside interference.  This means I don’t want a salesperson breathing down my neck and calling me everyday.  Almost all web sites require you to provide complete information about yourself and your company before you can even peek at their product information.  I don’t mind sharing that information if it looks like they have a good product that might do what I need, but how would I know that without some preliminary information? I resent these demographic data collections and know at least one site that even requires a deposit (via credit card) before releasing product information!

Then, after you give them everything but the names of your first-born, they usually will do one of two things: send you a CD with a Power Point presentation (accompanied by annoying phone calls from a staff salesperson), or turn you over to one of their Certified Resellers.  Again, you’ll have a salesperson calling.  The Power Point presentation won’t answer your questions and neither can the salesperson, whose prior experience was selling used cars.

They don’t even know your company’s needs. So, now you have these idiots calling you everyday with such statements as, “We have a 83% fit for your company;” and, within the same breath ask, “What is it that your company does?” And you still have no idea if their software even begins to meet your needs!

Too bad they don’t have the “you know what” to provide REAL information without obligation.  What are they hiding?

Wednesday, June 27, 2007

Ridiculous Redundancy

I bet there isn’t a company out there that hasn’t had this problem.  You have a Customer that is also a Vendor.  Or how about an Employee that is both a Customer and a Vendor?  If employees purchase products or equipment they are customers, and if employees are reimbursed for expenses they are vendors.  This means you will have redundant information in the different applications.

The problem arises in trying to maintain consistent and timely information about these Companies/Employees throughout the various applications.  I wish I had a dollar for every time I found a name, an address, or phone number in one application that was not exactly the same as in another application.  There is a tremendous amount duplication of effort, and it is nearly impossible to maintain. 

With a little effort from developers, common related data could be shared among the different applications.  Linking this data is not impossible.  Accuracy of information would improve, and hours of maintenance would be saved.

In this day and age it’s just plain ridiculous that this hasn’t already been done.  There is no reason for it, EXCEPT for the fact that most developers are just plain LAZY!  They just repackage the same useless, antiquated software under a new name, increase the price, and give it a new name.

Tuesday, June 26, 2007

FLUSH PAYROLL!

I must sound like a broken record, but I know of no other way than to keep harping on how inadequate current Payroll & Human Resource packages are.  These packages should be flushed, and let’s just start over from scratch!

Of all of the financial applications that we run today Payroll requires more work-arounds than all the rest.  Current payroll packages FAIL in the following primary areas:

1. Unable to RECORD and MAINTAIN HISTORY of ad hoc payroll EARNINGS.

2. Unable to RECORD and MAINTAIN HISTORY of ad hoc payroll DEDUCTIONS.

3. LIMITED REPORTING capabilities.

4. DIFFICULT for payroll clerk to use.

Pertaining to the first 2 items, if developers didn’t provide for a specific pay type or deduction, you can’t add your own, especially if complicated calculations are involved.  This results in payroll departments maintaining spreadsheets outside of the payroll application.  These are dangerous as they are usually undocumented, usually not audited, and can lead to serious errors. 

The third item is somewhat self-explanatory and usually requires hours of IT time to develop outside applications that provide the needed reports.  Again, these can be dangerous, as they must be maintained whenever payroll packages change. 

The fourth item is hard to quantify.  But if any clerk has to activate more than one program to perform a simple function there is a loss of performance.  Stepping through several screens the operator can make mistakes.  Only an intuitive and experienced operator will remember the multiple application screens needed to perform a specific function.

As a manager I spent more time bailing out the payroll department than anything else.  Do you think anything will EVER be done?

Thursday, June 21, 2007

Immigration: The Challenge for Employers!

With all the flap about immigration, our government will eventually enforce the laws for employers who hire undocumented workers.  Employers that I have worked for have required documented proof in the form of a “valid” state ID and Social Security card.  The trouble is that these documents are easily counterfeited and available to those who want them.  If a job applicant presents these documents you cannot deny work.

Knowing this, how do you protect your company?  One way is to verify Social Security numbers with the Social Security Administration.  It can be done on-line for a few employees, or you can upload your entire payroll to the Social Security Administration. Social Security will then notify you of all those employees with phony SS numbers.  Wouldn’t it be nice if your H/R package would electronically do that for all new hires?  You bet it would!

Maintaining employee identification documents in the form of copies of the SS card, state ID, photos, etc., is time consuming, and documents could be misplaced, misfiled, or lost.  We desperately need an automated system that would have the ability to digitally record and assign these electronic documents to the employee’s H/R file in an easy to use, intuitive manner!

We need on-line verification and digital documents now, in time to meet regulatory standards.  Eventually, government will mandate we do it, and you can be sure they will want every piece of information gathered for the past 10 years!

Wednesday, May 30, 2007

THORNY THREE

There are 3 things that are common to General Ledger packages that prove that no thought process took place when these packages were written.  These 3 items have been a thorn in Controllers’ sides since computer-based General Ledgers were devised.

Thorn #1:  Account structure format is permanently defined when the system is initially installed, and therefore cannot be changed!  Eventually, business and accounting needs change.  Without the ability to modify the account structure format, the only way out is to start completely over again.  Only the mentally ill would want to do that.

Thorn #2:  For some unknown reason General Ledger accounts can be deleted if there is no apparent activity within the General Ledger.  On the surface this may make sense, but what about activity in the subsidiary systems, such as Accounts Payable, Receivables, Payroll, etc.?  Talk about a disaster!  When you buy a Financial System you would think that there would have been enough intelligent thought given to this problem.  Wrong!

Thorn #3:  Developers assume that only one calendar is needed to run a business and that it consists of 12 periods, period.  I guess they also assume that you only work 9 to 5, Monday through Friday, and that there are only 3 colors in the universe.

You’d think some intuitive software developer would have figured out the solution to these “thorns,” but it looks like we’ll have to live with them a few more years.  I hate to be so picky, but enough is enough. 

Friday, May 18, 2007

USER POWER!

I’ve been very critical of major accounting software developers, but my entire diatribe has neglected a key element of success: the USERS of this software.  That’s right, it’s now time to pick on YOU!

It’s easy to bitch and moan about the software, but what have you done to make a difference?  Do you belong to the software developer’s user group?  Do you participate?  Do you go to the conference?  Do you just sit there?  Is it your primary goal to see how many of their logo items you can walk away with?

Get up off your tush and raise a stink!  Don’t put up with days of their endless drivel on how great their software is, and what new features they have to SELL.  Tell them what’s wrong with their software, and why you think so.  Be prepared to back up your rants with facts.  Don’t let them divert attention away from your issue.  Be respectful and professional, but get your point across. 

Too many user groups today are fancy sales promotions and NOTHING else.  Don’t let this happen.  Other users probably share your intuitive ideas.  Contact them before the conference, and agree to present a united front.  Developers may resist and try to ignore the interruption, but be persistent.  It’s the only way to make things better.  Eventually, the developer will start to listen.  They’ll have to, or they will lose customers.  Changes will be made, the software will get better, and the relationship between developers and users will form a stronger partnership.

Users of the World UNITE!

Wednesday, May 16, 2007

PLEXONOMY!

Here’s another area where software providers need a Plexonomy.  For some reason they think that money spent on support staff is not a good investment.  The truth is, support staff is usually not paid enough for what they’re worth.  Hence, to save money we see outsourcing to foreign support staff or suffer from high staff turnover, both resulting lousy service.  As the old expression goes, this is a penny-wise and dollar-foolish approach.

The best service I ever had was with a software developer that was smart enough to realize that their primary support staff was the best sales representative that the company had.  A happy customer is a permanent customer who buys full-support contracts year after year and doesn’t go looking for another system.  A happy customer is also a great reference source for other potential customers.

When software breaks it’s reassuring to talk to a support representative who knows the system and, most importantly, knows how your business uses the software.  The support rep intuitively knows the right solution.  Down time is minimized.  You look good to management.  You get a fat bonus ( . . . sorry I got carried away).

Software developers need to provide timely, accurate, and comprehensive support (especially at the high cost of support contracts)!  Why don’t they do this?  Because they need a Plexonomy!  What’s a Plexonomy you ask?  It’s a new surgical procedure where surgeons install a flexible piece of Plexiglas™ in the stomach region.  It’s for people with their head up their backside so they can see where they’re going!

Monday, May 14, 2007

SLOPPY ENGINEERING

Whether you like Microsoft Windows® product line or not, we’re stuck with it.  These products have features that we‘ve become accustomed to, and we now expect things to work in a certain way.  The ability to customize the appearance and functionality of your screen, navigate, resize views, change fonts, cut & paste, etc., all work in a similar fashion.

I’m not talking about copyright infringement, but why can’t other software providers (in particular the accounting software providers) mimic these features?  Why do we always have to learn a new way of doing things?  You say, “What is the benefit of designing software to emulate these features?” Well, training time and cost for the accounting staff could be reduced, as the functionality would already be familiar to them.  More importantly, daily operational mistakes would also be reduced because everything would work in the same intuitive manner.

So what’s the problem?  Why don’t developers do this?  Most accounting packages today were NOT originally designed for a Windows® environment.  They were either ADAPTED from older character-based systems with a GUI interface, or the designers were just too lazy or in too big of a hurry, and didn’t do it right to begin with.

This sloppy engineering is also evident in other areas, such as file structures and processing techniques.  Oh well, Management keeps buying software by name recognition, not by what actually works.

Wednesday, May 09, 2007

IT’S LIKE A CURSE!

True Story:  Upper management wanted to prove that they knew more than the accounting and IT staff; so, against recommendations, management purchased an ERP package from a major software developer that they claimed was specifically designed for this company’s industry.

Off course, the software was NOT a good fit, and key components needed for that industry were MISSING.  “No problem,” the software developer promised to write software (for a price) that would fill in the gaps. They provided from 2 to 4 different software “specialists” (depending on the day of the week) who were there for over a year.

The software design was such that the entire software package had to be loaded on each and every workstation!  Do the terms 3-tier, thin-client, and distributed-processing come to mind?  Not with these idiots.  It turns out that the “major software developer” had actually purchased this software from another software developer that went out of business.

Does it work?  Yes, sort of.  Performance is terrible.  Every workstation had to be upgraded with faster processors and memory sizes that are usually reserved for servers.  On top of all this, every time the developer releases a new version of the software, they have to modify each and every one of those custom modules, of course, for a price.  It was like a perpetual CURSE.

The moral of the story: Investigate very carefully.  Let those with the knowledge (your accounting and IT staff) examine every piece of systems documentation, and demand a test demonstration with your data.  What?  They don’t have any documentation?  Find someone else!  Don’t let a developer’s big name be the reason you buy their software. 

Saturday, April 21, 2007

More Than a Paycheck!

Why should we have to accept a software developer’s idea of how a payroll system should be structured?  Most payroll systems available today are very limited in how payroll functions are computed and then reported.

For instance:  We have to accept their definition on “types” of pay; i.e., regular, overtime, double time, night differential, etc.  What if you need to calculate and report a type of pay that the software developer did not plan for?  What if your calculation is dependant upon historical data such as the accumulation of Month-To-Date regular hours?  The historical detail is gone too soon in some systems.  What about payroll deductions, such as health insurance, retirement, investments, and wage attachments?

The ability to report this information is just as important as the payroll function itself.  Most payroll packages have a simple departmental reporting structure, and that’s it.  Additionally, historical information is more than likely retained in summary records (see “Can the Buckets”).  You may not have access the detail data via this summary operation, and the report-writer software provided with these types of packages is generally weak.  Unless you have an I.T. department with the right reporting tools and plenty of spare time (yeah, right!), you may not be able to retrieve the particular information your management needs when they need it.

We need to demand that payroll systems be designed to include the ability to build your own methods of payment, calculations for payments, taxes, deductions, etc.  Why can’t we get a user-friendly, powerful report-writer as part of the system?

Payroll is more than just a paycheck!  Help!