Balmori Software Inc.

[ Article ]

In a 1984 made-for-TV movie, Oscar winner Lou Gossett plays the overzealous head of security at a New York City condominium. He's obsessed with creating a perfectly safe environment for all his condo residents. He patrols the building constantly. He imposes a curfew on residents. He berates them when they're careless locking up. The guy is sincere and conscientious. Determined to ensure his tenants' safety, he goes as far as to stage a terrifying attack on one of them, rescuing him at the last minute to drive home the importance of security-consciousness, and not incidentally, his indispensability. At movie's end, Mr. Security Man has all his condo residents - his employers - firmly under his thumb.

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?" Let's see... The accountants ask the IT people a question about ... accounting policy? 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 into which all this data-inputting was going on.

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 addressed. 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. As late as today, the middle of 2014, many Philippine SMEs are still just dipping their toes into computerization of their business processes, so of course the topic is still terra incognita for them.

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, of course 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 issue was a matter of accounting policy, not IT infrastructure or software functionality.

Two valuable insights emerged from this workaday experience. First, our client needed a formal triage system for deciding whether a problem should be addressed by the IT department or by the accounting or a line department. Nothing fancy, just an explicit screening of work issues to determine if they should get kicked to accounting or to IT (or to sales, or to purchasing, or to logistics). 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



Title:   A not-so-funny incident uncovers a process re-engineering opportunity