Making sweet music between the IT department and the rest of the business was the theme of this week's IT Directors Forum at Cranfield School of Management.
It is a song with an old tune, but cover versions are issued annually, as the problem never goes away. What the problem does do, however, is track the contours of prevailing business management and best practice theory. To that end, the forum took the current craze for focusing - and about time too, most on the receiving end will assert - on customer relationship management (CRM).
CRM is usually regarded as another dreaded TLA (three-letter abbreviation) tannoyed down to the IT department by over-enthusiastic, under-researched business departments, who expect IT to produce instant systems to make it a reality by the end of last week. But, says Rob Lambert of Cranfield School of Management, CRM can be the lens through which the issue of IT's relationship with business is focused.
These days, Lambert says, companies have fewer and fewer options to differentiate themselves through their products. Increasingly, differentiation in the marketplace is achieved through how you sell, not what you sell. It is your relationship with your customers through the quality of your service that determines whether you get them and keep them. It is the same for the IT department.
"If IT only offers products, their customers can as easily go to product suppliers - or outsourcers," Lambert warns. It may be difficult to benchmark your service to your customers - the end-users - but be assured, says Lambert, "the outsourcers will have benchmarked your service."
The way you serve - or fail to serve - your customers determines where they fall on the loyalty ladder. Moving customers up the ladder is tricky, letting them slide down is all too easy. At the very top of the ladder your customer is your partner, holding total trust in you. At the base of the ladder your customers become terrorists, out to get you, shaft you, and badmouth you.
Customers who feel themselves badly treated never forgive and forget - they have long memories and hold grudges that they nurture and cherish. Bad service makes good enemies - as any badly treated consumer will testify.
But what can the IT department do to please its users? Does it even know the measures it should apply to discover if its users are satisfied? Or are they all too obvious?
One delegate simply said dolefully, "They're satisfied if IT just spends less money."
And that's the rub. Good service costs money. But bad service costs a whole lot more - ultimately a one-way ticket to the outsourcers.
"Can you get the margins to do IT well?" asked another delegate, clearly doubting an affirmative answer. Problems were thrown up thick and fast, "How do you measure return on investment from improving customer service?" "We'd like to improve, but where does the money come from?" " A high degree of user satisfaction is not set as a key management objective."
These questions will strike a sympathetic chord in most ears. Bootstrapping is often the only methodology available for improving service. Yet improving service isn't always a question of throwing money at the problem.
Small things count - in both directions. One delegate recalled that it took several months for the new corporate chief executive to get his desktop set up and a visiting executive had gone back to the USA before the laptop he had ordered arrived.
There is usually no reason why, as soon as a new recruit has accepted their job, the IT department shouldn't get in touch to identify their desktop requirements and get requisitions in the pipeline so that when they arrive their PC is ready and loaded on the desk.
Such things are not rocket science. Nor is adopting the methods of call centres. When a user calls the helpdesk it could immediately summon up the identity of the caller, their PC configuration, their history of problems, their priorities, their profile and so on.
To go one step further, trawl through the helpdesk data - if some people always have problems with some areas, book them on a training course. The IT department is ready enough to warehouse and mine everyone else's customer data, why not its own customers?
"We've already got a lot of data," said one delegate, "So why can't we analyse it to spot who gets problems with what, or what degree of usage the applications get?"
The bottom line payoff of taking a CRM approach to improving the IT department's service is to understand that the goal to be achieved is greater user productivity. IT is a tool - if it is not sharp enough, those who use it can't cut the candy.
Using the benefits dependency network
All too often, says Cranfield's Rob Lambert, the relationship between IT and the business is regarded as an input - whereas in reality it is an output. That is because it will determine what IT will end up producing for business - systems or value.
"IT delivers 'its'," says Lambert. The "its" are systems, and IT is concerned with delivering them faster, cheaper, better.
But the only useful output of IT is not systems, but business value, and business value is increased if business processes are improved.
IT should step back from focusing on delivering systems to see the bigger picture of how they can deliver benefits. To do this, Lambert recommends living life backwards. To find out what to do, find out first what needs to be done.
A benefits dependency network starts with the business strategy, or at least an item thereof, such as "cutting delivery from 48 to 24 hours". Before that can be achieved, it has to be understood what it is that makes delivery take 48 hours in the first place, and that means analysing every process that impacts, participates or contributes to that timescale - including the key question - how does IT slow the process down? Non-integrated systems between different processes is the favourite answer.
Once that process flow is precisely understood, improvements to those processes can be suggested which can cut the delivery time. Once measured and accepted, then and only then, should anything to do with the computer systems that execute those processes be touched on. Code in haste, repent at leisure, is the warning.
As for the danger that organisations can turn drawing up a BDN into a six month project all on its own, don't let it, says Lambert.
"Do it as a joint workshop with the key stakeholders - it shouldn't take more than a couple of days," he says.
This was first published in May 2000