August 25th, 2008
Over my dead body
During last week’s discussion of the issues introduced by the use of spreadsheets in the preparation of financial reports, Kurio99 asked “What’s the alternative?”:
What’s the Alternative?
Could a company survive without Excel or any other flexible tool (ie paper) which is susceptable to error?
Corporate IT systems take time and money to implement. Business needs to be able to move fast, to address new issues.
I have seen situations where the IT estimates for a system or modification far exceeded the total value of the monies to be administered. Is Excel so wrong in those situations?
Most of my colleagues would happily dump their spreadsheets in exchange for a powerful, IT supported system. We know the risks and are not out to sabotage our firms by using Excel to bypass the appropriate controls.
You want a nice safe error-free system, forget about Excel, take the humans out of the picture altogether. Make everything 100% automated. Fun thing is, I suspect that such a company would not survive long in today’s competitive environment.
To some extent this misses the point: the problem with the use of Excel is that there’s no good way to know when the results are wrong and there is usually no good way to know when and where any errors that are recognized got into the system. You can audit paper, you can even audit a well configured SAP installation, you can’t effectively audit a process keyed to spreadsheets built up over many years by many players.
As several people, including _dietrich pointed out, however, you can combine technologies a bit by using the spreadsheet as a flexible reporting format loaded from the real (i.e. production) data. Note that this gives you the ability to automate many kinds of reporting without forcing the human judgement component out of the loop because easy replication means that people can use the data in simulations, assess its liklihood in forms comfortable to them, or modify things like formatting without destroying the auditability of the results.
In general I think that’s the right answer: don’t automate to the point that human judgement gets cut out of the process, but do automate to the point that the actual values shown always come directly and verifiably from the real production systems.
If yours is a big enough organization you can implement the technology for this fairly easily - the product combination cited in last Tuesday’s blog on this topic, hyperion + oracle enterprise can, for example, be run on Solaris with ZFS to produce a system that not only meets the criteria but can also be containerized to the point that you can save the state of the system at some standard time each day, and activate a copy of the system as it stood to that point at any time you want to - without interupting current processing.
What that lets you do is have the financial managers set the rules, have the computers produce the numbers according to those rules, and yet give auditors the ability to verify both what the rules were at daily points in the past and what outcomes they produced.
Even in big companies, however, it usually takes a fairly strong management edict to prevent “post filtering” - people making changes to the numbers shown in the automated reports as part of the process of turning them into final reports.
In smaller organizations, typically in the few hundred employees and smaller groupings, however, you won’t generally be able to afford this level of automation - and the Finance group is usually small enough that some guy who’s made himself the local PC maven can get away with taking an “over my dead body” stand against any change that diminishes his influence over the group.
In my experience people like this have significant clout with Financial management, inevitably play off emotional avoidance and a general distrust of computing, and will do almost anything to protect their positions - but when examined closely turn out to have a good command of the latest in PC buzzwords, but poor spreadsheet or local database programming skills, poor self discipline, and no real depth of understanding for either technical or organizational issues.
In the end people like this usually have to be fired - but you won’t typically get management to do that until they’ve been significantly embarrassed by exactly the kind of reporting failure you’re trying to avoid - and the smaller the business, the less likely it’s ever going to happen because the guy’s ability to influence how the data gets represented to the business owners often lets him survive even the worst failures by presenting himself as the savior and his manager and/or IT as the incompetents.
So what do you do? By far the most effective way of dealing with him is to get the business owners or top managers to pilot your new accounting system in an office or division where the guy doesn’t have daily influence - then, when it’s successful there, he’ll be forced into active (meaning “visible”) sabotage to prevent its successful migration to headquarters.
Mostly, however, you don’t have the opportunity to do things that way -and both the architecture and the people in place limit your software and staffing choices to the point that you probably can’t win - in which case the only really right answer may be to schedule an exit interview with the business owners or senior managers to tell them why you’ve decided to go work for a competitor.
Paul Murphy (a pseudonym) is an IT consultant specializing in Unix and related technologies. See his full profile and disclosure of his industry affiliations.
Subscribe to Managing L'unix via Email alerts or RSS.
| 08/25/08
