Thursday, May 08, 2008

Blog Site Updates

Over the next few days, we will be performing a few site updates in hopes to get all features working a little better. All articles will be available most of the time during the updates. We apologize for any inconvenience.

Thank you.

Thursday, April 10, 2008

Apathy, but who cares?

It’s easy to point out that most of today’s current financial software is sorely lacking in features and usability.  The frustrating issue is the ongoing apathy by software developers and computer software users who just don’t care.

Why don’t they care?  The reasons are many:  too little time, too little money, someone else’s problem, or a let’s-just-get-by attitude.  With all that’s going on in the world today, the economy, wars, politics, office stress, etc., it’s hard not to blame them.

I am amazed how people will put up with things that don’t work.  They are willing to work around the shortcomings of their office tools, whether it be an accounting system, word processor, spreadsheet, or flaky operating system.  Users have learned the quirks and pit-falls of these applications and have developed work-arounds to the problems.  Even worse, they just put up with these headaches.  They just want to get through the day!

Software developers are the same way.  Why expend the effort when it may not increase their bottom line?  They have the attitude that if no one else is producing better code, why should they?  Since their user base isn’t demanding better software (apathy once again), there is no incentive to produce a better product.  The truth is, there is more demand for better cell phones or MP3 players than better computer applications.

Nobody has any PRIDE anymore!  There is no professionalism, no striving to do better.  Just get through the day, and Friday isn’t too far off! 

Who cares anyway?

Monday, March 31, 2008

Déjà vu All Over Again

In recent years, developers have introduced new tools for the end-user in the form of: (1) user-defined special sorts, (2) filters to limit viewed or reported data, (3) recorded procedural steps, (4) difficult calculation routines; or, (5) a combination of these processes. 

In addition to saving time, they reduce the chance of errors and, possibly, eliminate supporting spreadsheets.  Kudos to the developers for these features!

Having said that, these tools present a big problem.  I am amazed at the number of these user-developed tools that a typical work site can acquire in just of couple of years.  Why is that?  Here are a few scenarios that may be the reason:

• The tool was written by someone no longer there, and nobody knows how to use it. 

• The tool is so complicated that nobody can determine how it works.  This usually happens because of the above.

• The list of tools is so long, that it takes forever to find.  It is quicker to do the task without it.

• Nobody remembers writing a tool for the task, so they write a new one.

• No naming-standards are in place for identifying these tools, so no one knows what “Amy’s Fixer-Upper” really does, so they write the same tool under a different name, like “Bruno’s Bonus.”

Most software used to create these tools is not self-documenting unless you are a programming geek.  Using a word-processor or other text editor doesn’t link the documentation to the actual tool.  Will this ever end?

Neither software developers, nor end-users are anxious to address this issue.  The solution won’t bring developers any more revenue, and end-users just don’t have the time.  So, users keep rewriting the same tool, over and over again, because it’s easier. 

As Yogi Berra so eloquently put it, “This is like Déjà vu all over again.”

Wednesday, March 26, 2008

Will Things Ever Change?

While helping a local municipality get back on their feet after a recent disaster that destroyed most of their records and computer systems, I was amazed by the number of spreadsheets that they used to support their financial system.

Their financial system uses “Buckets” (see blog article “Can the Buckets!”), and their fiscal year-end is right in the middle of all of the summer-time projects.  Or, these projects extend beyond 12 months.  Because of this, the only way they were able maintain a complete accounting of these projects is by using spreadsheets.  LOTS of spreadsheets!  They also confessed that the accuracy of these reports was inconsistent and unreliable.  They spent many fruitless hours trying to reconcile.

To make matters worse, they didn’t have a set procedure on how information was to be posted.  At first, data was entered into the GL, and then the data was transferred to the appropriate spreadsheet from GL reports.  Later, they made the initial entry into the spreadsheet, and then posted it to the appropriate account in the GL from the spreadsheet report.  Phew!  I’m tired just thinking about it.

Of course, mistakes and transpositions were made using both methods.  Reconciling was next to impossible because they couldn’t be sure which posting method was used, or what baseline numbers were correct.

It’s the same old problem.  When will we get software that really addresses the needs of running a business? 

Will things ever change?

Wednesday, March 05, 2008

All Burned Up!

Another type of terrorism has raised its ugly head in the community where I live.  A nut case broke into the property owners’ association administration building, and set fire to the interior of the building totally destroying most of the files.

There was heavy smoke and water damage, even to areas that escaped the fire.  Office staff assumed that the computer equipment and phone system were OK and unwittingly attempted to power these units up!  It was a tragic mistake.

Whether you suffer from flood, fire, tornado, earthquake, etc., use caution when powering up any electronic equipment after such events.  A pre-defined disaster procedure must be followed before any attempts are made to power up.  The internal components need to be inspected, cleaned, dried, and reseated.  External wiring needs to be inspected and tested.  This applies to computers, network devices, telephone switches, and any other electronic devices.  These need careful inspection to minimize damage.  If you power up without these procedures, you can fry it all.

At the property owners’ association the most drastic damage was to the development’s critical building and planning records.  Hard copy reports, plans, and most documentation will be next to impossible to replace.  Before such a tragedy occurs, important documents should either be scanned into digital media and/or stored in a secure, fire resistant facility whenever possible.  Additionally, copies of key documents should be maintained at an off-site location, just like data back-ups of all computer files.

Needless to say, our community was not prepared for this.  A disaster plan should have been in force that included electronic recovery, and it should have been adhered to.  Our community will suffer a costly and time-intensive effort, but an important lesson was learned.  Could something have been done to prevent this from happening?  Maybe, but I doubt it; we’re just too trusting in this country.  You just never know.

I urge you to review your disaster plan regarding electronic equipment and data protection, and modify it to reflect changes in your business.  Don’t forget your hard copy documents that can’t be replaced.  Then, train staff routinely just like you do with any emergency drill.

Don’t let your records get all burned up!

Thursday, February 28, 2008

With A Little Help

The world’s best software won’t do your company any good unless the users know how to use it.  They may be able to post an invoice or run a report, but can they use the system effectively?  Usually the answer is that many of them can’t. Even if they were initially trained on the system they have not retained all of the little nuances of the system; and, if there have been upgrades to the system, they most likely haven’t had an opportunity to learn the new features.

When I questioned software providers about documentation, their universal response was, “It’s in the Help text.” I can think of only a few software packages with meaningful Help text.  How many times have you clicked Help to determine the purpose of a field only to find an ambiguous answer?  A typical example is when the definition of a field labeled, “Subject Discount Allowance” is defined in the Help text as, “subject discount allowance.” Big help!

Writing documentation is difficult, probably harder to do than writing program code.  At least there is defined logic in program code.  Nearly every programmer and analyst detests writing documentation. 

Good documentation specialists are harder to find than an honest politician!  They need to be able to understand the technical staff’s methods of communicating, and at the same time be able to convert that knowledge to documentation that can be understood by the rest of the human race! 

Additionally, the documentation writer needs to be consistent in the structure and presentation of the Help text.  It’s a very difficult job, one that is often overlooked, under-budgeted, or ignored, but is an essential element of good software.

Get with it!  Give us meaningful Help!

Thursday, February 21, 2008

A Rose By Any Other Name

It was known by many names, Accounting Rules & Procedures, Accounting Standards & Policies, “the Bible,” etc.  While it has fallen out of favor in the last few years, it was the guidebook on posting and processing for different financial functions for many companies.  Whenever there was a question of what to do and when, it was in the “book.”

Now, with domination of the “Windows” environment, there are so many ways to perform the same function or task that structured documentation approaches have fallen by the wayside.  Procedural steps can be omitted or taken out of turn and sometimes produce different results that aren’t apparent to the user. Disaster!

One of two things needs to happen.  Either we go back to the “book” and enforce it, or software needs the capability of creating macro procedures.  This process kicks off programs in a certain order with pre-recorded responses to program prompts to yield consistent results.

Option one is a throw-back to the old days.  Plus, it still doesn’t ensure that things will be performed correctly.  To make matters worse, rarely are these printed procedures timely updated as things change, causing further confusion and the possibility of errors.

Option two is available in very few software packages.  This is the best way to go, but you have to look for this feature.  Users prefer an automated procedure, as it lessens their workload and increases accuracy.  Macro-configurable procedures are more easily updated than written procedures.

You might work with your I.T. department or software provider to create macros and possibly automated procedures.  It may not be a doable solution with your current software, but it won’t hurt to at least look into it.  If you’re looking for a new system, be sure to include macro-configurable procedures on your checklist of important requirements!

Thursday, February 14, 2008

Unlike Taxes!

User Groups maybe the answer to increasing your knowledge to the inner-workings of your financial application.  How can that be true?  It is.

Where else will you find a knowledge pool of different ways to use the same application?  There are as many approaches to the way software is implemented and used as there are companies represented by members of the group. You will usually find someone who has encountered the same problem as you.  They may have the solution (work-around), or they could be a strong ally in your struggle with the Developer to fix the problem.

Besides a national user group there may be regional, or even local user groups.  If management doesn’t want to spring for travel and the associated costs of the national group, they may support your participation in a regional or local group.  While the total numbers of members vary, you may be surprised how different industries resolve software problems in a similar manner.

If you work for a large corporation that has multiple companies using the same software, even a corporate-wide user group could be very beneficial.  In addition to sharing ideas and discussing work-arounds to problems, it’s a great venue for networking and for establishing standards in accounting practices for the corporation.

All user groups can be beneficial depending how involved you become.  If one doesn’t exist, start one.  Find out who has the same software.  Be an advocate for participation.  You will receive more than you ever put in, so unlike paying taxes!

Thursday, February 07, 2008

Train Wreck!

When new employees are hired one of 3 methods of training will occur. 

• The old employee is already gone, and a manager or co-worker will attempt to train the new employee.  Of course, the manager doesn’t have the time, and the co-worker may be inept. 

• The employee that is leaving will train the new employee, and is so buried in work (the reason they are leaving in the first place) that there is practically no succession training.

• Or, the employee that is leaving will train the new employee, but their heart is not up to the task, as they can’t wait to get out of there!

Add to that, if there is any documentation (doubtful), it’s probably been lost or at best very outdated.

The result is that as time goes by staff becomes less and less efficient and is prone to making mistakes.  They become disenchanted with their job and quit.  This problem compounds itself with each new generation of employee.  Training equals satisfied employees and a job well done!

Responsible companies plan for ongoing, professional training for their staff, either by bringing in someone from the outside (Developer or VAR), or they have their own in-house training staff. 

Having someone on staff that is thoroughly trained on the software and who possesses teaching skills (something often overlooked) is the best solution.  It is far cheaper to train the trainer than to bring someone in on-site.  Or, even more expensive, send the employees to some remote training facility.  A side benefit of hiring your own trainers is that new employees will receive prompt and thorough training, and problems or questions can be managed timely as needed. 

Data shows that mandatory training has increased employee efficiency and reduced worker’s comp claims.  Sadly, company shortsightedness hasn’t brought those lessons into the general office environment.  Training your employees avoids a Train Wreck! 

Wednesday, January 30, 2008

R.T.D.M. !

A few questions to ponder:

• Are you aware of any new features in the latest version of your financial software? 

• When a new release of the software is installed, how are you informed of new functions, changes, or what “bugs” were fixed? 

• Have you ever read the developer’s documentation on what is new and different about this new release? 

• Does your software provider even offer such a document?

If you are the controller or manager of a financial department, you should know the answers to the above questions!  Even if you use a consulting firm or a Value Added Reseller (VAR), this information should be available to you.  If not, you should raise Havoc!  Without this information, how can you effectively use the software?  Once you have the information, train your staff.  I do mean TRAIN your staff, just don’t throw a piece a paper on their desk.

If you are an accounting clerk, and if you don’t receive either documentation and/or special training covering new features or revised procedures in the use of the software, talk to your manager.  If you receive only documentation, study it very thoroughly.  If you have any questions make sure you get clarification!

There are some software developers that don’t provide hard copy documentation on new releases and rely on their VAR’s to bring their clients up to date.  This is usually not very effective.  Thankfully, there are developers out there that do offer new release documentation and even training classes covering the features of the new release. 

The bottom line?  R.T.D.M. (read the dang manual) ! 

Thursday, January 24, 2008

Dummy Saves the Day!

Software is constantly changing.  Why?  There are 3 main reasons:

1. Marketing and management want new software and/or enhancements to existing software to help increase sales.

2. Constant demand for new features from the users of the software.

3. New releases in the Operating System may require modifications to software.

Most experienced developers try to make their software bug free.  But, it’s not uncommon for them to “break” working code with these enhancements.  This can cause error conditions, alter results, or change logic.  Can’t they test every piece of code?  Not realistically, especially in the timeframe in which they have to work.  How many times have you, yourself, written a document, spellchecked it, proof read it, even had someone else read it, and it still has errors in it?  You can’t always catch every mistake.

I’m urging you to take an important step before you go “Live.” When you acquire updates to software, before you go live, test it with your company’s data. Your data may create challenges that the developer never, ever, would have thought of.  Every company, no matter how big or small, has quirks that no other company has. 

I know you claim that you test, but I mean REALLY test it, right down to the most elementary item.  It makes sense to create a dummy company on your system, and include your company’s “quirks” to challenge the new software.  Make sure you document what the expected results should be, so you can compare results during your testing.  Be sure to include quarterly and annual procedures and reporting.

Regardless, always test each and every update.  I know this takes time, but it will be less time than the time required to recover from a serious error in the software.  Don’t be the dummy!  Let your dummy save the day!

Have fun!

Thursday, January 17, 2008

A Small World After All

Recently, friends from Switzerland visited me for the Holidays.  They have their own business back home, and we had an interesting discussion about the differences in financial software between our 2 countries.

As you can probably guess, with the exception of governmental regulations and reporting, there is very little difference in the software needs between the 2 countries.  My friends had just migrated to a new financial system after an extensive search for software that would meet their needs.  Guess what?  European software isn’t any better than ours in the U.S.  In fact, most of their packages are even more antiquated!

My friends’ previous software didn’t even offer interfaces between the different packages (A/P, A/R, G/L, etc.)!  They operate a medium sized company and don’t need a VLFS (see blog, “Beware of the Giant in the Mouse Disguise”), but they have many of the same financial reporting requirements.  Their new system that they selected does offer manual interfacing between some applications, but as with many financial packages, it’s “buggy.” Their major concern was whether their staff would be able to handle all the little nuances of the software in their absence, as support from the software provider was poor.

It is somewhat assuring to know that other countries in the world have the same problems as we do, and we are not alone.  Wouldn’t it be grand if software developers would get it together and really develop good systems, instead of this semi-cooperative, one-upmanship marketing, no-real-change-attitude that we now have?

It’s a small world – let’s pull together!

Thursday, January 10, 2008

Are You Really Prepared?

After surviving the “storm of the century” this past week in California I observed how ill-prepared the world is (computer-wise) when a disaster hits.  It’s not only a matter of the lack of electricity, but the possible damage or total destruction of your facilities.  Damage from flooding, snow, mudslides, and hurricane-strength winds can change your world in an instant.

Even though you religiously perform backups every night (you do, don’t you?) they won’t help if your computer system is damaged or destroyed.  Do you have another physical site that can offer even limited services?  Do you have a hardware vendor that can supply overnight replacement?  And, if so, do you have a facility in which can use the replacement equipment?  Probably, the answer to the above questions is “No!”

Do you have a manual operations plan for when your computer system is not available?  Has the plan ever been tested?  Do you have recent hard copies of work orders, inventory levels, customer and vendor information, etc.?  Is this information available for emergency access and quick removal?

If you’re on your own phone system, do you have at least one provider-powered or over phone devices that don’t rely on electrical power?  If you have any other equipment that requires power, do you have manual powered alternatives?

Is your UPS powerful enough to withstand multiple hits from brown outs and total power outages?  How old is it?  Eventually their ability to protect your system diminishes to a point where it is no longer protecting your equipment. 

If the answer to any of the above is basically “No,” you need to ask yourself how long can your business survive without serving your customers?  In watching the effects of the recent storms, I wonder if some of our local businesses will weather the storm, or will their customers find alternate providers for now and maybe for the future.

Sunday, January 06, 2008

Beware of the Giant in the Mouse Disguise

Beware of a Very Large Financial System (VLFS) software provider that has entered the Medium-Sized Financial System market (MSFS).  At least, that’s what their current advertising claims.  What do they mean by medium-sized business? Their web site and media advertising is very vague and not informative.  It is next to impossible to research their information without contacting a sales representative to breathe down your neck. Contacting their sales staff is like throwing raw meat into a tank of Piranhas.  Not for the weak of heart!

I don’t hold much hope that this MSFS will be very good.  Heaven already knows their VLFS is very expensive and difficult to install.  It’s not that it doesn’t work, but you’d better have a lot of spare cash lying around.  I don’t believe they have ever come in on budget on any install.  Also, plan on some live-in consultants for quite awhile.  It may be cheaper to buy them a house to live in rather than pay for hotel bills.  And, the hardware requirements are notorious for being undersized, so be ready to purchase forced upgrades.

So why am I ranting about this MSFS without even trying it?  Because, unless they totally re-engineered their offering, and only downsized (?) their product, you will only get a smaller version of a larger problem.  It is extremely rare (like never) that a software developer will take the time and the money to totally re-engineer their software to gain the advantage of new ideas and new technology!

Look for a software company that has a proven design that takes advantage of current technology and is designed for your business.

Once again, it’s “Buyer Beware!” Good Luck!

Tuesday, December 18, 2007

Behind the 8-Ball (Again)!

There was an interesting article in one of the trade magazines I was researching that brought up a good point.* A reader had posed a question about the best way to archive reports and still retain the ability to print these reports years from now.  Good question!

This same issue becomes very important with the archaic financial systems that we have today.  Until the use of “Buckets” and the automatic deletion of detail information are changed, reports need to be generated while the data is still present and somehow preserved electronically.  It’s impractical to keep these reports on paper for any extended period of time, as it usually requires special archival paper and ink, plus a great deal of storage space. 

You need to be thinking of the best way to store reports electronically in a format that would still be supported for at least 10 years from now or longer.  The author of the column discussed that Text File Format (“txt”) has been around for over 20 years, but its available fonts and formatting are extremely limited.  Rich Text (“rtf”) was discussed and discarded because of larger file sizes and frequent changes to format structure that require conversion in order to be printed.

One format that surfaced for consideration was Adobe’s Portable Document Format (“pdf”).  It has become the de facto standard for Government forms, and because Government is not noted for changing standards very often, the article surmised that “pdf” files would be around (and usable) for several more decades.

So, my question to you is: “Is your antiquated financial system able to produce/convert reports to Adobe’s Portable Document Format?” If not, you’re really behind the 8-ball!  Get with it!

* Acknowledgement to: 

Breen, Christopher. “Mac 911,” MACWORLD, January 2008, p.102-104.