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.