Skip to main content

Broader Process Sharing - Service Request Fulfillment

While at a BMC UserWorld conference a few years ago, I wrote the following. It still applies and I wanted to put it down in a permanent spot where I could find it later.

==========

We're perfecting the Service Desk call center. What would it look like if we invited other campus support units to share our processes and tools, if not our Service Desk?

My recent experience moving into a new building has sharpened my focus on this issue. I'd like to share a taste of my experience by way of introduction and illustration of my implementation recommendation.

In my new office, I need to obtain keys, request door locks to be installed, deal with furniture alterations, move network and power outlets that were obstructed by furniture, request appropriate signage for our department, order new furniture, resolve electrical wiring problems involving and interface with the furniture, request building card swipe access, request thermostat adjustments, and request permanent placement of a projector in our conference room.

All of these tasks dealt with different departments, but involved a nearly identical process. I needed to locate the appropriate contact and submit a request, either via telephone, email, or web form. The service requests involved some degree of personal consulting and approval. I then had to track the progress of each request through to completion.

With each department, the procedure to request and track the service was different. Some of my requests were immediately taken care of. Others were more troublesome. In one case, the department marked the work as complete even though it hadn't been. There was no uniform way for me to learn the status of my multiple requests or to provide feedback to the various service entities.

It would be ideal to have a unified Service Request Management tool that allows users to browse a service catalog, understand pricing and billing options, request service, track order status, receive notifications, add comments, and evaluate completion. Such a system would act as a front-end interface to other existing systems. The work isn't completed in this system, but merely tracked within it. Since we expect each department is already tracking this workflow in some way, we wouldn't expect this to be an increase in work, just a modification.

The benefits in efficiency and customer satisfaction in such a system would justify a significant investment by the university in such a tool.

Comments

Popular posts from this blog

Hammers and Nails: Technology Push Design

"We need to refine our requirements first, before we look at tools." This is a common phrase that I hear. While I sympathize with the sentiment, I think it is frequently wasteful. I suspect that we'd get to the right requirements faster by looking at tools already available in a given problem space. Pushing the concept further, is it foolish to find a cool technology and then look for ways that that technology can apply to current problem spaces?  What if you don't even recognize you have a problem space? Without a constant search and openness, we'll miss many serendipitous opportunities. Here is BYU professor Larry Howell discussing this issue. I often enjoy doing something ... that is sometimes controversial. In this approach, rather than starting with a need, you start with a new technology and you search to identify a need that it can fulfill. This second more controversial approach is called "technology push design."   You can imagine t

The "True Cost" Phantom in Project Cost Tracking

I want to know if I should wear a coat when I go out the door on an unpredictable spring morning. The temperature from the weather app on my phone isn't going to match exactly the temperature just outside my front door, but it will be close enough to make the decision. If the question at hand is whether or not I should wear a coat, it would be a costly mistake to set up an elaborate system of thermometers around my property to try increase the precision of my measurement of the temperature. The added expense wouldn't yield any better decisions about whether to wear a coat, so why bother? We are interested in tracking the relative costs of the various projects we undertake in our organization. We must admit up front that we will never be able to measure the precise cost of each of our projects. Consider the following things you could include in the "true cost" measurement of a project. Where will you draw the line? An engineer reads an article on the bus that give

Process Ain't a Post-It

Some ITIL advocates insist that having a good process is separate from having a good tool. "If the process is right, you can do it on a post-it note. Putting it in the tool will speed things up, but it won't fundamentally change the nature of the process." This is rubbish. It may be true for small scale processes, but technology automation can open up new process possibilities that just wouldn't be possible without a technology assist. I think that we should plan our processes with a tool in mind that can accomplish the task. Think of a Service Catalog that gives an executive insight into the costs of the things he orders. He can dynamically scale up or down his order or services to meet his projected needs. He can tweak variables and make decisions because of the power of the tool. It gives him a visualization that simply wouldn't be available in a paper-based process. The NewScale demonstration (a prominent Service Catalog provider) really drove this point