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?

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!

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.

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!

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, 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!

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.

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.

Saturday, March 24, 2007

Stop the Short-Cutter!

I continue to be amazed at the number of Financial Systems out there that are designed with the stupid idea that users NEVER make a mistake.  The software developers assume that users will always post invoices, payments, etc. correctly.  Really I-G-N-O-R-A-N-T !

How can I say this?  Don’t these developers provide recovery procedures or methods to correct mistakes?  Well, yes, but clever users find ways to take shortcuts and circumvent the “safeguards.”

For example: Let’s say someone incorrectly posted an invoice to the wrong general ledger account and then updated the G/L with this incorrect account number.  The standard method to correct the problem would be to go back to the A/P system, void the invoice (creating a negative posting to the G/L for the incorrect account), and re-post the invoice with the correct account.  However, in a crunch, or if just a tad on the lazy side the “short-cutter” will just make changes in the G/L, leaving the A/P alone.  Auditors just love this!

Wouldn’t it be great if the System protected the integrity of the data and would not allow such “corrections?” It would be nice if software developers would provide tools to make corrections easier and be less time consuming for those overworked accounting types.  They stress out so easily.

Agree? 

Friday, March 16, 2007

Keep Your Pants Up!

What really gets to me is when Management doesn’t give a rip about security until it’s too late – what idiots!  The greatest danger is from “within” but Management remains oblivious to this danger.  Usually Management wants everything done NOW, and that applies to bringing new staff members up to speed on the applications they will be using.  That can lead to disaster.  Embezzlement can happen quicker than you ever thought possible!

Case in point:  A new Assistant Controller is hired, and Management says, “Get him trained on the financials this week.  He’s going to be managing the Payables section next week.  Give him whatever access he needs to do the job.” The IT Department explains that “everything” means having the ability to post invoices, payments, and to add and modify the Vendor’s master file which is a security risk.  Management responds, “We don’t care, just do it!” Oh, did I mention that these geniuses gave this individual check signing privileges as well?

The Assistant Controller they hired was a smart one.  Within a week this individual had the A/P system figured out.  He could modify an existing vendor name to his name, post a couple of false invoices, cut a check made out to himself, and change the master record back to the original vendor name.  Of course, he picked a vendor with high activity, so it wasn’t questioned because the A/P system reported these payments under the original vendor name.  Nobody was the wiser until the employee failed to show up for work after taking the company for thousands of dollars!  Management got caught with their collective pants down, and they had no one to blame but themselves.

We need to protect ourselves from incidents such as these!  We can’t do anything about Management. Stupid is, as stupid does.  Ideally, we would separate the duties, so that staff who create the master records (vendors, customers, and employees) aren’t the same people that post checks or payments.

We also need do something about Systems.  Systems need a way of tracking additions, changes, and deletes to all records.  Changes need to record a before and after image.  Additionally, there needs to be a time-stamp and operator ID as part of this record.  Most importantly, there needs to be a means to monitor and report this information, possibly with an alarm mechanism to an IT security person and/or to the Controller.  At least this way it’s faster to discover and easier to prosecute! 

What’s your horror story?

Sunday, February 25, 2007

SEE IT NOW!

This blog started off as an article about the shortcomings of several Payroll systems.  I then had an epiphany; the problem applies to almost every financial package! 

There are times when you need to research an employee’s pay history, a vendor’s invoice, a customer’s payment, or details behind a journal entry in the G/L.  The only way this information can be gathered, in some financial systems, is to run report after report (that’s if your lucky).  You go to all the effort to enter data, and then you can’t get to it.  How many times has management walked in and wanted to know why the A/P clerk hasn’t paid Dwarski Construction, or how much overtime has Ruthie Fredawitz been paid in the last 6 weeks?  Usually management wants that number NOW! 

How much effort do you go through with your current system to trace every action performed on a vendor’s invoice?  Wouldn’t it be nice to see when the invoice was received, posted, paid (and how), or what discounts were taken?  How about a digital image of the invoice and appropriate signatures without running reports or going to 10 different screens?  I have seen systems where this information was on 1 screen, but you needed special magnifying goggles to read it! 

There has got to be a better way.  Give us the ability to research at the screen without having to jump through hoops and definitely not by running reports.

This is a major challenge that must be overcome, and it’s a major rewrite to do it correctly.  The omission of this search capability is inexcusable.  It’s like software developers have never been in a true business office environment.  To be quite frank, a great many of them haven’t.

Agree or disagree?

Wednesday, January 31, 2007

Changes = Weekends Lost!

How many times have you needed to do a mass change in an application?  Let’s say the Controller comes in and says, “You need to change the department code for the Janitorial Service department, as they now report directly to Maintenance.” Do you tell the Controller that this should have been thought of before building the stupid chart of accounts?  Do you cancel plans for the weekend?  Worse yet, you need to ask the IT staff if they would write the script to make changes in the Database. You don’t want to ask them to do anything because of the never-ending !#@)☹! you’ll have to put up with.  Time for a career change?

There are 2 challenges here.  First, there needs to be a tool that creates a Database script that you can use without getting IT involved and without having to become a DBA yourself.  Second, the entire Database has to be restructured because the department code is a major key in the Database.  As it is now, this job translates into hours and hours of time and effort, and for Heaven’s sake don’t make a mistake!

It’s not just in General Ledger that this happens, it’s in all applications: changing 500 customers from one sales territory to another, giving everyone in a certain department a 5% raise, changing the default liability account on 1000 vendors, and the list goes on.

You would think that if we can put a camera, a calculator, a stereo, an e-mail device, a television, a Jacuzzi, and who knows what else in a small portable phone, they ought to be able to solve this problem.  (Just kidding about the Jacuzzi.)

Wednesday, January 10, 2007

Can the Buckets!

Certain big providers of today’s financial software continue to wrap a GUI interface around old ideas. Of course they think it’s a great product; you can tell that by the prices they’re charging! They should be ashamed! Let me explain…

One concept is a file architecture that summarizes transactions into what are called “buckets”. Their General Ledger uses period buckets, usually 12 monthly periods. Payroll uses year-to-date and in some cases quarter-to-date, while Accounts Receivable and Accounts Payable are usually only year-to-date. This concept makes any required reporting much easier for programming staff and reduces the number of transactions necessary to provide desired reports. Essentially, the boss is happy because bank auditors have their reports. However, these reports don’t provide meaningful detail information to aid in managing the company.

That was fine for the Stone Age, but not now.

Why is it a mistake to keep using systems based on this archaic method? There are a number of reasons, read on.

Occasionally “buckets” get out of sync when detail transactions don’t equal the summarized bucket total. This doesn’t happen often, but it does happen. If it isn’t a problem why do these financial systems have manually run “reconciliation programs” to re-sync the buckets? You bet it’s a problem and one that is not easy to detect. The software provider will tell you that it almost never happens, but they won’t be standing next to you when the president of the firm calls you on the carpet when his bank report shows an incorrect balance!

Everything has to be posted and balanced (as at year-end) before proceeding with the new period. This can delay reporting on the new period’s information for some time, depending upon the efficiency of the accounting department. This, in some cases, is not just a year-end problem but can occur throughout the accounting-year, reporting-period by reporting-period.

Because of this antiquated design, prior period detail information is usually LOST after a period close, especially at year-end closings. You’ll have summary data available as a prior-year history (again in buckets), but only for the immediate previous year.

This rigid accounting calendar, caused by this bucket concept, locks your company into the financial system’s way of reporting information, as opposed to adapting to your company’s business cycle needs. What if your fiscal year is July through June, but your business cycle is February through October (farming, construction, tourism, etc.)? Wouldn’t it be better to report your business cycle information at whatever frequency and level of detail you need?

What’s the solution? Can the BUCKETS!

Today, with the software tools and hardware capabilities now available, there is no excuse for “buckets.” Work with the RAW DATA! Let software perform data collections that are needed for whatever task is at hand. Develop software that allows the end-user to manipulate data in a form that they can work with. What a concept!

Remember, truth lies in the RAW DATA. We need systems that work directly with the detail transactions that are posted to the system.

It’s time that software developers pull their heads out of the sand and offer software that will provide the tools that we need! We’ve waited long enough! Why isn’t there something better?