Hmmmm, shiny graphs!
What does this button do....?
< . >
The results are in from yesterday’s mini-poll, and they are pretty conclusive – even if we take into account that removing users altogether is not an option. The top two types of call may be quite easily balanced – as you can see from the chart, between ‘don’t know how to do something’ and ‘application not responding’. When …
Hmmmm, shiny graphs!
What does this button do....?
< . >
The atrocious nature of the Help function on most software is the primary reason that I get calls.
As an example, if you ask Excel "how do I widen a column" the top help hit is "preventing objects from moving and sizing with cells", which to the innocent user is impenetrable tech-talk. You'll find the correct help for this most basic of functions down at No3, two more than the average user is prepared to read. In such circumstances the poor secretary who can't read the spreadsheet will call IT.
Mine's the one with the manual in the pocket.
To be effective this should er must include the carrot and stick approach. With stick I mean cattle prod. And with carrot I mean to threaten user with cattle prod.
An MIS team who fuck up a build can cause all sorts of issues.
While locking down a PC can prvent idiots changing stuf, it can cause issues as well.
Its not just user training that is required but training of the people that look after the systems.
Perhaps IT might consider testing their new policies before enforcing them? In our R&D environment it is IT that are a problem, not vice-versa.
And what are most companies doing these days?
Cutting back on training budgets, and outsourcing technical documentation departments to cheap non-technical people who think that a wiki is the answer to everything.
Gun, foot: FIRE!
In the mid-90s I was running IT Service Delivery for a couple of thousand users. We employed 3 dedicated trainers, who covered use of Windows, Office* and our own bespoke systems. I'm sure they more than paid for themselves in reduced helpdesk staff - and that's not counting the 'hidden' benefits that staff were able to use systems more effectively and consistently.
Of course, when money is tight, it's always easy to cut the training budget for a year or two. This is usually a false economy, often to be found in businesses driven by beancounters.
* Maybe you can assume that everyone knows how to use Word these days, but my experience would suggest not 8(
As a developer who works closely with the "Service Delivery" function, the service guys often don't help themselves. I notice there was no option for "we fucked up and the phones started flashing".
A couple of weeks ago, a system "just stopped working" (it was a Monday morning - warning bells start ringing in my head). The Service Delivery boys called me up to see if I could help. It was immediately obvious the software couldn't access the database so I asked SD whether anything had changed over the weekend. They denied having changed anything.
To cut a (very) long story short, over the next two hours, in dribs and drabs, they confessed to;
1) Upgrading the version of SQL Server over the weekend
2) Moving SQL Server to a new physical Server
3) Renaming the SQL Server instance
4) Changing the name of the admin account
5) Changing the password for the admin account
Once we had the truth, it was a 30 second fix. But Network administrators (or whatever they're called where you work) acting as if they own (rather than maintain) all the hardware and making changes without following proper processes and procedures account for a fair proportion of phone calls in my experience - and I've worked on both sides of the divide and caused a fair few outages myself!
you can get quite a few support calls when the latest update for your anti-virus software decides that your line-of-business app is dangerous malware.
Which isn't to say that other self-updating software can't get a dodgy update occasionally.
Updates: damned if you do, damned if you don't.
Despite my first rant I absolutely agree with you. There are, however, some well managed IT departments with well established test and migration procedures (thorough testing in sepatate environments, test approvals, etc.). And then, there are the others of which one case you described and they cover the whole spectrum of incompetence from "no test environment" to "I tested whether it could be installed and thought it was o.k." or "we haven't thought of this specific case" or "we didn't know that application X queried data from database Z" and also an IT manager inserting a contaminated CD. And it goes up to my all time favourite which occured about two years ago: deadline approaching and the sub project managers said it wasn't ready, the project managers said it wasn't ready, etc. But the director said (well, actually he wrote it in an e-mail which I carefully retain): "I'm aware of the risks. Now go live!" And down it went.
Having worked in helldesk myself though back yonks I know users can be a pain in the arse. But the really serious troubles are usually caused by IT itself.
Bassey, Evil Auditor: In your example the Service Delivery people are the users except that they even more ought to know better. Doing this properly requires something called "change management", and is a basic skill required for smoothly running a shop.
Of course, it's extra jarring if your IT guys can't do basic things like, oh, streamlining routine tasks like OS installs, or setting up a working DNS+reverse, that sort of thing (and yes, I've heard about those too). They're the ones that run the operations end so if it breaks there it breaks spectacularly. To me lack of skill is a good reason to either train them or ditch them and get competent people, much the same as should happen with ordinary users. However, doing that requires basic skill assessment skills in the people charged with running the people: management. In that sense it's a big large epic phailfest of incompetence. Yay IT.
Sure, users can do some very silly things and some times malicious things as well, and they rarely confess to what they do. However, to them a computer is just another tool to do their jobs: accounting, scheduling, reporting, engineering, etc. I have yet to work at a place that bothered to train the user in how to use this tool; they were given a computer and some credentials and set on their own. Training simply is not a priority with businesses. So, even though I agree with the basic results of the survey, that users are the casue of most calls, the root cause is management refusing to train the users in how to use the computers and networks.
I wasn't trying to ruffle your feathers, Jon ... Surely that was obvious from mine ...
Or was Goodin moderating again?
Email works ...
Biting the hand that feeds IT © 1998–2017