Over the past few weeks that we’ve been writing about service management, it’s become very clear just how hard it is to hold the fort. Indeed, we wouldn’t be at all surprised if some of you don’t wonder – at least to yourselves – why bother? This is actually a very good question, and one which deserves just a little scrutiny. …
The "Right" Services
While I've never had to venture out into a business and ask "What do you do and how do you do it?" I been out performing the desktop infrastructure audit only to find a hitherto unknown system, normally running in parellel to a live system performing an identical function. When asked what it's doing the response tends to be something along the lines of "We're supposed to use XYZ but it's uselss so we all use this instead!"
Of course there are the right services and the "right" services, those procured in order to cozy up to a vendor or as a result of a director having been convinced of a system's superiority despite the ground troops' protests. I had an object lesson in this kind of thing watching our techies install a £3m VoIP system to acheive Gold Partner status when a raft of free frimware upgrades to the existing switches would've have done the same thing.
Assessing the IT needs of the business can best be acheived by a combination of orders from on high, good relations with all divisionsof the business, accurate incident trend analysis and maybe throwing up a wiki or analysing any self-help tools to guage user experience. Floor-walking's good albeit a little inconsistent!
Service management? Who cares?
Servicing not your customers but your customers' customers? What? What business are we in, anyway?
First thing I thought was "this isn't about IT, it must be larger". And now I am sure. It's another slap-on patch with a fancy name, specialised for the big bugaboo of business that everyone has to deal with, fails to understand, fails to make work, and actively refuses to understand: information management. But what the patch is supposed to fix it cannot fix, for the problem is more fundamental. And while the solutions are manifold, the result has but one name: Good management.
And that will possibly remain the elusive white elefant of business for years to come, at least until it stops staring itself blind on its bugaboos.
SM (or even a "naked" It department) doesn't have customers. A customer - supplier relationship implies a transaction: goods or services out, money in. It also implies choice - that a "customer" can either choose not to buy, or can buy elsewhere. None of this is valid when parts of an organisation interact with each other. At best you have a series of monopolies locked in a mutual pact - at worst each department acts like an independent regime: trying to screw all the ones around it, without getting shafted themselves - and the best way to do that, is to do nothing. In the real world, we put in place a regulator to stop these monopolies from exploiting their power (although, admittedly a lot of them are pretty close to useless) and to punish those which don't deliver the required levels of service, or who don't play nice with everyone else.
Businesses hardly ever have any form of internal regulation. Yes, they put in place wishy-washy SLAs and high falutin' "mission statements" none of which are worth the paper they are written on, as they cannot be enforced, punished, competed against or avoided. While the more enlightened employers will have a bonus scheme with gold stars for teams that meet their SLAs, the motivation these provide is often slight, sporadic and disproportionate to the effort required. Plus, they still don't offer anything close to a free market for internal customers to choose from.
Most businesses are closer to a medieval dukedom, with someone at the top meting out arbitrary justice (or not) in response to complaints after the fact. Although instead of "off with his head", the worst that usually happens is a review meeting and promises made to do better in future. So getting back to the "why do we do it?"` question. The answer is (still) for the money. Anyone who says otherwise is lying. [test: if an employee says the money is not important, stop paying them. See how long they keep coming to work for.] and until this basic truth is addressed both in terms of the reward and penalty structures, there's little point in trying to solve problems with services any other way.
 this can be quite a good motivator - provided the level of punishment is sufficiently hard and credible. As Machiavelli wrote in"The Prince" (probably the first real book about management techniques). It's better to be feared than loved, if you can't be both.
we discover yet another Microsoft Access 'database application' which the whole of one divison relies upon despite it never having been near any requirements or testing.
Flames, cos, they need killing with fire (.mdb files, not the users)
Small businesses and IT
I try to make things better for companies I'm well acquainted with -- helping out those that I understand the business for and those that I'm happy just to help even if not for a big pay day.
It's surprising, however, to go into small business and try to expand their horizons about what IT can do. Many, it seems, make do with repeated manual processes and don't even use rudimentary IT tools to help out. One reason, no doubt, is that many of these organisations have small IT budgets with little IT staff time available; often the IT department is someone who can plug things in, set up accounts and run the backups but isn't a coder or application developer and simply doesn't have the time to learn - and so often it's a part-time role. My experience with end-users in such organisations is almost always of suspicion about promising what IT can deliver and difficulties in specifying how they'd like things to work. Whilst it's one thing to understand, at a high level, what a business needs you still need user input and in smaller businesses it can be a challenge just to educate and identify the exact requirements from users who are foreign to IT projects where developers actually take heed of what they want.
I like to think I've helped and that by showing companies the capabilities of a small bespoke solution they may take it further or identify other opportunities to streamline their processes, but at the SMB level it's definitely a leap of faith towards enterprise-style solutions which all too often isn't made.
I guess the problem when you get to bigger organisations is that the end-users are suspicious of IT for different reasons - there's a much bigger chance of making processes so efficient your job disappears! In growing companies it can help a person do more, but in shrinking ones, it's a risk many people just won't to take.
Peeing in the Wind
I'm in the middle of trying to sort out a college's It infrastructure. They wont pay for quota software, or much of anything else. The entire system will collapse if they dont spend some money and their main concern is recruiting students to fill the coffers. It really doesnt seem to matter how much these problems are stressed, as long as the system is running, albit slowly, its fine.
In one industry I worked for an FM company, that like all others I've encountered, oversold its abilities. They couldnt deliver good service if they tried. That turned really nasty when their standard number of calls was exceeded and their customers ending up paying through the nose for extra calls. The client company ended up directing their employees not to raise calls until all the available machines were dead.
Its crazy, if I had experience in other sectors I would move from IT.
Trouble around every flowchart.
I venture out into "the business" to seek out new opportunities to help out on a regular basis. I am fortunate that the CEO of my company is fairly amenable to the idea of this level of interaction with IT, and we have regular conversations about all aspects of the business. There are places he sees inefficiencies, but some times has no ideas on how to improve them, whereas I know of a technology or a program that could be put into place to make that issue go away. Some days, he will walk in with a problem, and ask if we can form a solution for it.
This form of interaction is something I have found business owners very open to. Not only at my current place of employment, but top level individuals at our customers, previous places of employment, contracts I’ve worked, etc. These people have a stake in finding inefficiencies, and they are not above working with the grunts in IT to make things happen.
Rather the opposite is true the farther down the totem pole you go. When you wander about "the trenches" asking around about how things are done you have to be extremely careful how you go about it. Especially in these days, people are paranoid all over about job security. Many people take an envoy from IT asking about their jobs as a sign that they are about to be replaced by a shell script.
It is all about people management. There are ways to approach this "quest" that can inform you on how to "win friends and influence people." The further down the totem pole you are asking questions, the more you have to present it as researching ways to help that individual make their job easier, and the less you have to talk about anything related to "efficiency" or "to help the company."
Bearing all of the above in mind however, you need to talk to everyone you possibly can, up and down the entire stack of staffs to truly get a grip on how things are run. Only when you have a clear picture of what people do and why can you bring your technological expertise to bear finding solutions to the problem. The very last thing in the world you want to do is put in place a solution for the proles that only works around something the bigwigs purposefully wanted. Conversely you must be equally alert to situations where what the bigwigs are wanting is simply going to trigger the proles to develop a workaround.
I have often found that IT staffs for better or worse feel themselves "apart" from the rest of the company. While the purpose of much of the research that El Reg and Freeform Dynamics seems to be doing is about "bridging that gap, and making IT more apart of the company," I posit that it is our very distance from these business processes that gives us an edge. I have found an outsider’s perspective can be very useful, especially when that outsider’s job is to plug every hole he finds with a bit of technological wizardry aimed at solving problems.
In my case, this has worked best when I am doing so as a staff member in the company in question, and not as a consultant. There is less resistance to the advice, and less feeling that it is being offered "simply to get more work." I know it goes against what a lot of IT people believe to go actually looking for problems, however I suggest that in gaining a clearer understanding of the overall picture of business needs and processes, you will often find that less, more precise work will do far better than the large amounts of "change requests" that come from hunkering down behind the helpdesk and waiting for trouble to find you. A proactive approach versus a reactive one…that’s what the debate is about, hmm?