Our priorities often conflict, each of us speaks a jargon that is impenetrable to the other and there's a lingering suspicion on both sides that we're being set up to take the blame for the other side's mistakes.
But the days of the handwritten general ledger are gone - not mourned by anybody – and with them are gone the accountant's absolute control over the tools of our trade. Today, our relationship with members of the IT department is probably the single most important one we have: we can't do our jobs without the systems that the members of the IT department develop, install, maintain and support.
This is a mixed blessing. On the one hand it makes our jobs easier and faster, enables us to handle volumes of information that would have been unthinkable fifteen to twenty years ago, and gives us insights we couldn't achieve otherwise. On the other hand, it makes us vulnerable to events over which we have no control, that happen in a black box sitting in a server room far away, administered by somebody we may never have met.
So, we ask the IT department “Can I process a journal entry here that will show up in the Pofadder branch?” and they mumble something about network topologies, server configurations and user licences that we interpret as a yes. So, when we don't get what we expected, whose responsibility is it – theirs, for cloaking themselves in jargon? Or ours, for not taking the trouble to learn enough of the jargon to know how to ask the right questions?
The hard fact is, the smatterings of IT lore we learned as students are probably long out of date and, without at least some knowledge, we can't inform clients.
I use the word “client” because in theory, that is the relationship we have with IT departments nowadays. The official line is that “IT is an enabler” – it exists to provide the essential infrastructure and services the rest of the business needs so that the business can operate.
It would be fantastic if this meant IT had to give us whatever we wanted, but in reality things, as always, are not that simple. IT's job is to provide a stable, reliable environment; their success is measured in terms of things like uptime, system stability, network availability and project delivery. This will often lead them to make choices and decisions that profoundly impact the rest of us, but to which we can make little or no input.
For example, if the IT department decides that the company should be an Oracle or a SAP shop, there's very little anyone else can do about it. But it does place very real constraints on what becomes possible afterwards. That nifty piece of new software you've seen that promises to solve all your problems? Sorry, it won't fit in. Even worse is when the tried and trusted system that's worked perfectly for years is suddenly “no longer supported” and has to go.
One could be forgiven for muttering cynical comments about empire-building and over-caution in cases like this. But before you do, think for a moment what the IT department may be muttering about the accountants.
One of the ways we can be better clients of IT is to become better at specifying exactly what we need, and to consider how our future needs might influence what we ask for. To use an analogy: If I go to a car dealership and say I want a blue car with four wheels, an accelerator, brakes, a manual gearbox and a nice stereo system, an entry-level car will perfectly suit those requirements. If I buy the car, I can't go back six weeks later and complain that its off-road handling is poor; the dealer will quite reasonably say that if I wanted to go off-road, I should have said so in the first place and bought a different car.
In the same way, when we discuss our IT requirements, we'll get more of what we want when we can express what we want clearly.
Yes, IT departments should also learn to communicate more clearly: but, until then, let the accountants do what we can. The more we know what questions to ask and what answers not to accept, the higher our credibility will rise and the more seriously we will be taken.
Kevin Phillips CA(SA) is Managing Director, idu Software.