| [Article] |
d
A common problem leads to a process re-engineering opportunity
Posted on 13 May 2009
It's a libertarian parable, warning that a society that grows so terrified of outside threats could end up abdicating its basic rights to its professional protectors, thus turning a country into a police state. But here at Balmori Software, this clunky B-movie also puts us in mind of a similarly unhealthy kind of relationship that can sometimes develop between a company's IT department and its traditional departments, like sales, purchasing, warehousing, or accounting.
When a company computerizes its accounting, inventory control, or A/R and billing, there is an unfortunate tendency for the non-technologists in the organization not only to defer, but sometimes actually to abdicate, to the technologists. We've seen finance and accounting people inexplicably asking IT to pass judgment on accounting policy issues.
In one recent case, accountants at a company asked their IT group, “Do we have to input sales transactions explicitly, and then after that input collections separately, in cases of cash sales?” That's like Manny Pacquiao asking us if we think he should put more hip rotation into his uppercut. How do we know about this incident? Because the IT department in turn passed the problem on to us, as the vendor of the application where all this data-inputting was going on.
(The answer of course is yes, even in cash sales situations, you should input sales first, then input collections afterwards. Why? Because inputting sales is what triggers the creation of the accounts receivable - in a well-designed application, at least. And you can't input a collection unless the receivable exists in the first place - in a well-designed application, at least. That's because a sale and a collection are two different financial events, even if they occur seemingly simultaneously, as in the case of a cash sale.)
We don't tell this little anecdote to poke fun at anyone. We tell it because it's a real problem in many organizations, and deserves to be examined. Fuzziness about areas of responsibility between operating departments and IT people is a common reality in many businesses. And that's not good for anybody. Not for the IT guys being asked to address problems in areas outside their expertise, not for the line and accounting people who are loosening their grip on their functional areas out of technophobia, and certainly not for day-to-day effectiveness of the business whose employees are, with the best intentions, misdirecting their energies and time.
If this is happening all across Philippine commerce and industry – and the experience of our help desk shows that it's very prevalent – then it's a serious drain on the productivity of a large part of the economy.
The problem, let's face it, is that too many business people are still too intimidated by computers and information technology to deal with it calmly. In the almost comical case described above, it wasn't that the accountants didn't know their accounting; it was simply that they had no self-confidence about IT matters; and when confronted with what was in fact a basic accounting issue, they lacked the assurance to peel away the accounting aspect from the IT aspect; and so they abdicated to the IT guys just because the issue arose within the context of a computerized accounting system. But the original question being a matter of accounting principle, not computers, the IT guys didn't know what to do with the question either.
To be fair, it's sometimes difficult to draw the line where one expertise ends and another takes over. This is because the IT presence is so pervasive in so many aspects of a business organization today. And this is why these jurisdictional confusions arise in the first place.
Because IT is typically so interwoven into all aspects of today's business, it's easy for a chief accountant to toss the ball to the IT department when an issue arises that seems to be a software problem, when in fact it's an accounting problem that just happens to occur within a software environment. When this happens, the problem usually gets batted back and forth between the two departments until somebody has the insight, or musters the courage, to say it's this or that department's responsibility. And by then a lot of time has been wasted.
What's to be done? We see that the usual, less-than-ideal pattern is:
1. An issue or problem emerges.
2. Toss the problem to IT automatically. IT here is being cast in the role of arbiter, which is anomalous because it has an interest in the outcome. This is not ideal for objectivity.
3. IT analyzes the problem, and decides it's an IT problem, or not an IT problem. The possibility remains that IT could come to the wrong conclusion. Why? Because, while IT people may be supreme in the area of IT, they are less expert in accounting matters. So the IT department could wrongly assume responsibility for an accounting policy problem and waste time on it. In the specific example cited earlier, the IT department, after mulling the problem over, ended up bringing the question to the vendor. The accountants could have gone directly themselves and saved some time.
The approach could be improved, as follows:
1. An issue or problem emerges.
2. A triage system kicks in. A responsible officer, acting as disinterested arbiter, consulting with peers, analyzes the problem to determine if it's an IT issue or an accounting issue (or a sales issue, or a purchasing issue, or a warehousing issue). Determine first if it's a problem of hardware, or IT infrastructure, or data corruption. If it's any of these, then no question it should be referred to the IT people. But if the problem involves an accounting or finance issue, (or a sales, purchasing, or a warehousing issue) then it should be addressed by the appropriate people outside IT.
3. What if it isn't readily apparent whether it's an IT, or say, an accounting, problem? We've found this helpful: Everybody pretend for a moment that your business is not computerized; is the problem still there? If the problem seems to fade away when you're “uncomputerized”, then the problem is probably an IT issue, and should indeed be turned over to the IT guys to dispatch. If on the other hand the problem remains even when you are “uncomputerized,” then it's probably an accounting issue, which probably requires an amendment or refinement to your accounting policies (this last definitely not the province of IT).
In our example of the company wondering whether cash sales should first be inputted as sales, and then recorded explicitly later as having been collected, the root problem was a matter of accounting policy, not IT infrastructure or software functionality.
The company accountants had been used to treating cash sales and credit sales differently in their manual (pre-computerization) accounting system, in order to save time. It's a common short-cut that accountants use to deal with a large volume of transactions in a manual accounting system.
But a computerized accounting system works so much faster that short-cuts are no longer necessary. The crucial realization is that proper, disciplined accounting procedures – which used to be non-viable because they took too long in a manual system – can now be observed without any huge consumption of time. Short-cuts no longer have to trump disciplined accounting practices.
And so the company realized that, in a computerized accounting system, it's okay, it's feasible, to return to basic principles that years of manual accounting short-cuts had led them to forget: that one should record all sales in the same subsidiary ledger - regardless of whether they're cash or on credit - then input the collections separately.
Two valuable insights emerged from this workaday experience. First, our client needed a better triage system for deciding whether a problem should be addressed by the IT department or by the accounting or a line department. Second – and this is the exciting one - such a triage approach can help identify seemingly sacred current practices that can profitably be re-engineered. - rsr
Questions? Reactions? Write to balmori@balmorisoftware.com.