Shifting support: A battleground view of the evolution of the Service Desk Jaime Garcia-Zamorano, Carleton University
Agenda - How come we have a Service Desk? - What is it that they do? - Can the value of the Service Desk be improved?
In the beginning. There were typewriters and phones.
Then we started to modernize There still were typewriters and phones. But Computer Terminals started appearing on some desks.
The need for IT support started. But the scope was limited. Support was provided by developers and computer operators. Developers addressed software. Computer operators addressed hardware.
Of course it wasn t that simple. But The System was centralized, and most issues were addressed by specialized staff: the end users were not expected/allowed to try to solve them.
But then, things started to change: enter the Personal Computer
As Personal Computers and commercial software became more accessible, slowly but surely these started showing up on all desks.
PCs really brought about the need for usercentric IT support. Reason #1: Users were new to computers, and most had been using typewriters and desktop calculators, pen and paper all their lives.
PCs really brought about the need for usercentric IT support. Reason #2: PCs and PC software were awkward for new users and, let s face it, pretty crappy.
Users would phone the computer guys to ask questions and report problems. Usually more problems than questions. Questions got answered. Usually.
A lot of these problems required an on-site visit: Remember this is before networks. With PCs, computing became decentralized, sort of. Although users had personal computers, there remained the need for midrange/mainframe computers to process the bulk of the administrative transactions.
The responsibility of keeping the PC system operational fell, in theory, upon the end user but more realistically, it fell upon the IT support staff. The ability to solve problems became the distinguishing trait of SD technicians.
Thus SD duties split up: Very, very often, technician A ended up having to go to the user s desk to either fix, change or explain something. However, technician B needed to stay at the office, to answer calls from the other users.
And so, 2 groups were defined within the Service Desk: One, to answer the first call; answer questions (typically the simpler, quicker to address issues), and do a first pass at diagnosing more complex issues.
And so, 2 groups were defined within the Service Desk: The second group would go to the user s office and solve questions/issues/problems, hands on.
Computer networks were then added to the mix. The network is the computer. John Gage, Sun Microsystems (1984).
The Network brought about the possibility of sharing a number of resources, as well as recentralizing the control of some computing assets/systems. And, let s not forget, it brought us The Internet.
Networks augmented the complexity, but initially not the nature of the Service Desk Users still called to get their problems solved. These problems shifted from My Lotus 123 won t run, to I forgot my network password. The tasks changed slightly, but the job remained the same.
Networks augmented the complexity, but initially not the nature of the Service Desk More complex issues still needed the presence of a technician on site. These issues also became more complex.
But then, slowly but surely, the network became more robust. It went from being a collection of standalone computers plugged into the same backbone, to becoming a real network, where resources are shared, centrally managed and where everybody can connect with anybody.
The network gained speed. The network gained stability. Computers and software also became better integrated, more robust and more uniform in their usability. Applications became more broad ranging.
Remote access and administration tools also improved and have become the norm. These tools have changed the nature of the Service Desk. Technicians can now solve a good percentage of the issues remotely.
Whatever happened to on-site technicians? are they no longer needed? Of course they are. Hardware and software still do fail. And of course, users will be users.
The typical catalog of computer services delivered by IT has also grown significantly. All those services that used to be accessible only to folks who had terminals (remember?), plus many new, additional services, are all available via the network. These services may be more or less complex in their operation.
And so, the width and often the depth of the knowledge required from the SD technician has increased many fold. Compare a simple web page to an enterprise application like Banner. Now consider the number of IT services and applications provided. That s a lot.
Moreover, SD technicians end up dealing with all areas on campus. SD technicians know who does what. If we can t fix it, we know someone who does. We also become aware what s going on around campus, sometimes deliberately, often by accident, but always by necessity.
One thing to consider: The SD technician s job is repetitive in nature: Computing problems are going to occur, and they then will reoccur again to somebody else. And to the same person too. Users come in all sizes, but most tend to. not read not heed common sense All of this also be in contributes a hurry to make the job frustrating, quite often. not be patient yell be annoyed all of the above
Side note: All those jokes, cartoons, etc. about IT support and end users derive, sadly, from true stories.
But in the end, all of these tidbits can end up pushing the SD technician to look for greener pastures. If it s on Campus, it s not too bad. But the know-how accrued by the SD technician may go elsewhere.
And this matters because the learning curve is very steep and very elongated. For an entry level SD technician, it takes between 3 and 6 months to be proficient enough to be productive. That s a long time before a person can carry their own weight.
At the same time, technology-driven initiatives pop up across campus. Some of these initiatives need just a wee bit of help to get started. Others end up becoming on-going engagements. http://carleton.ca/1125/about/ http://carleton.ca/discoverycentre/
These initiatives do not necessarily originate within the University s IT organization. But more often than not, folks involved in these initiatives end up calling the number they call for other IT related questions. And the SD ends up getting involved as well.
Although they may represent more work, the SD technician usually welcomes these projects. Really, we do. Mostly because we enjoy the challenge of solving a problem. And in most cases, we are the right fit for these gigs. http://carleton.ca/discoverycentre/our-spaces/gaming-lab/
Case in point: Video games as a way of writing history (HIST3812A Fall 2014). more informally known as Minecrafted History https://github.com/shawngraham/hist3812a
Case in point: Minecrafted History got a lot of traction outside of Carleton. And within Carleton as well https://www.library.carleton.ca/research/course-guides/emcp-2015/building-future-minecraft-and-lebreton-flats
Some of these examples were not part of a master plan. They almost just happened to happen. There have been other projects where the SD was involved from day 1, and things went smoothly. More significantly, there are some not-so-positive stories about times when the SD s input was not considered.
Summing up: SD technician s job: Requires special skills, it s technically challenging but can be repetitive and frustrating. Technology-driven Projects: Often need and lack the resources the SD can provide.
So, what if involving the SD was to become a matter of good practice, rather than an afterthought? One might guess, based on our experiences, that if anything, this good practice could help these initiatives move forward, at least during their initial stages.
Further, what if the SD technicians were to be inventoried as resources? Having an inventory of skills, and publicizing these could also help the folks behind these initiatives get off the ground quicker, by allowing them to reuse existing resources while their own skillset builds up.
Questions and (hopefully) answers. Comments welcome as well.
Thank you. jaime.garcia@carleton.ca +613-520-2600 x8512