|
First let’s take a look at the typical IT Request Management environment from the perspective of the “requesters” and the “service delivery” teams responding to the request.
One of the most immediate observations is that there are many different types of IT requests. These range from end user move-add-change requests (e.g., onboarding a new employee, upgrading a laptop), to work requests for a business application (e.g., hosting an application for the marketing department, changing a report), or more technical requests where one IT group requests services from another IT group (e.g., deploying a new application environment, setting up a new server in the data center). Depending on the type and nature of the request, each is handled differently.
- For requesters: Most companies have multiple, confl icting and disparate mechanisms for ordering or requesting internal services on the front end. Does this sound familiar? Multiple intranets, web forms, Lotus Notes databases and custom applications all over the place; new forms getting developed all the time; employees and managers are forced to retype the same data again and again; end users continue to call the help desk or use the “shoulder tap” method to submit service requests; and business leaders are frustrated by their inability to order just once and then have IT deliver the service reliably.
- For service delivery teams: On the back end, most IT operations are organized around functional silos, characterized by their own set of processes, systems, and standards. Relatively few IT organizations offer a central catalog of standard service options appropriate for the user’s business needs; even fewer have automated delivery of those services. Lack of coordination between service delivery teams and a reliance on multiple offline and online service request systems leads to service delays and inconsistent service quality. This creates chaos and confusion for both the requester and the IT service delivery professional – the burden is on the requester (or designated ‘process shepherds’ and coordinators) to navigate through these various ordering mechanisms, determine who does what, manage the various tasks associated with every service, and ensure that the end-to-end service is fulfilled. And the service delivery teams spend an inordinate amount of time responding to requests, researching requirements, validating information, and providing status updates.
To further illustrate what a mess this can create, consider these examples:
- For end user services: Let’s look at the example of on-boarding a new employee. A computer must be ordered and configured with the necessary applications. Email and voicemail need to be set up, and the physical workspace must be ready and available. A hiring manager will typically need to consult the IT Desktop and Facilities teams, and possibly the Telecom or Network groups – and be the champion pushing to get these various service activities done on time and in the right sequence – through phone, email, and various paper or electronic forms. This takes up valuable time for the hiring manager, and it reinforces the perception that IT is difficult to deal with, that IT doesn’t understand his/her needs or those of the business as a whole, and is simply too slow.
- For IT-to-IT services: Within large IT organizations, the application development group experiences similar frustration when they request infrastructure services (set up a server, provision storage capacity, etc.) from other groups within the IT organization. Lack of standards results in each request being treated as a one-off project – even if that same request is made dozens or hundreds of times. Without a standardized, repeatable process, these services take longer than is required. And without a centralized way to track and prioritize each request, IT resources can be misapplied. These lapses can result in costly delays – both in hard dollars and in lost productivity.
Given the current state of Request Management within most IT organizations, this is clearly a challenge and a priority that must be addressed.
|
