Lean Service Request Management

With this article on lean service request management, I continue my analyses of lean service management processes. My earlier discussion of lean incident management may be found here. Any discussion of managing service requests should take into account John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My debt to that book should be obvious in what follows.

A vicious cycle in service management processes

Service request management suffers from the same vicious cycle that we saw in the discussion of lean incident management. The principal difference between incident management and service request management is in the way in which the customer values the output of the process. In managing incidents, the best the customer can expect is to limit the damage done by the incident. In the best of circumstances, the customer might appreciate the alacrity with which the incident is resolved, but will always wonder why the service provider was unable to prevent the incident in the first place. Service requests, however, are cases where the customer has specifically identified a value it wants to acquire, one requiring the help of the service provider. Thus, service request management is about maximizing gains, whereas incident management is about minimizing losses.

Service request management process scope

In this discussion of a lean service request management process, I limit the scope of the process to those types of requests that are well known or, at least, well knowable. From the perspective of the Cynefin framework (see Fig. 2), we are talking about service requests whose fulfillment should be Obvious or perhaps Complicated. Such requests are distinct from requests whose fulfillment would be complex or chaotic.

This framework inspired an analysis by Dimitar Bakardzhiev, where he relates the degree to which a customer understands its needs to the Obvious, Complicated and Complex practices as described by Cynefin.

I build on that analysis by adding the perspective of the provider’s understanding of how to fulfill the customer’s need (see Fig. 3). Our discussion of service request management processes concerns essentially the cases where the customer knows exactly or inexactly what is needed and the provider knows exactly (or perhaps inexactly) how to fulfill those needs. The gradient of background color, from the upper left of the matrix to the lower right, shows the propensity of the combination to be handled by the process that I consider within the scope of this discussion.

Thus, when the customer knows exactly what it needs and the provider knows exactly how to fulfill that need, the context is ideal for a service request management process. The farther away from that situation we are, the less suitable such a process might be. The gradient of color indicates that the perimeter of the process’ scope is not a hard and fast barrier. Some ambiguity must be accepted.

This way of distinguishing among service requests is at odds with the practices in many organizations. Often, a service provider distinguishes between the service requests concerned with “running the organization” and those concerned with “changing the organization”. Often, the latter type of request concerns the creation of or change to a software application, whereas the former type covers most every other type of request. And often, this distinction is further reinforced by the organizational structure, split between development and operations. So please be aware that I do not make such assumptions about the service provider.

The difficulties in so-called “best practice”

Before I address the question of what a lean service request management process might look like, let us consider the issues typically faced by organizations that attempt to follow a process recommended by certain so-called “best practice” frameworks. We frame this discussion with the process itself, as in Fig. 4.

The process shown in Fig. 4 might not look quite like the one found in standard publications. There are several reasons for the differences:

• The standard publications show a process flow that has many incoherencies. I won’t bother listing those incoherencies here, however. I remove them from the diagram, while maintaining the intention of the framework.
• I use BPMN notation, as discussed in my article on that subject. BPMN gives a much more accurate and simpler view of what really happens in a process.

So, why is that process not a lean service request management process? Here are the principle difficulties:

• There are four separate occasions where the process has been triggered but not completed. Each time this happens is a form of waste. These occasions are numbered in Fig. 4.
• The process includes authorization activities for which the service provider is not responsible
• The process makes assumptions about organizational structure that are not necessary and are probably not desirable.

Process triggered but not completed

Process triggered in error

The first case occurs on the assumption that a customer might trigger the process in error, submitting something other than a service request. The typical example would be signaling an incident, which then is to be handled by a different process. The existence of such a possibility is due to either:

• a lack of proper tools or proper tool configuration used for capturing the customer need; or
• a confusion between a user support process and a service request process

For a discussion of how user support integrates with incident management, see my article on lean incident management.

As with all lean processes, the correct approach is not to build into the process error handling, but rather to remove the causes of the error and simplify the process.

Requester not entitled or service not delivered

The second case of an abandoned process occurs when either:

• the customer is not entitled to request the service; or
• the requested service is not within the scope of what the provider is prepared to deliver.

It is not possible to avoid either of these possibilities, especially when a request may be submitted by an free format and asynchronous channel such as email. In theory, if requests can only be submitted via software or via an interactive channel such as telephony, then this form of waste can be largely eliminated. However, not every service provider is prepared to restrict communications to those channels alone.

Request rejected

The third case of an abandoned process occurs when a service request is not authorized. There are two separate issues here, depending on whether the request is rejected by the customer’s organization, or rejected by the service provider.

In my view, the service provide should not manage the customer’s approval of the request. Formulation of the initial request and its approval by the customer organization should be upstream from the triggering of the service request management process. For example, suppose an employee needs new equipment, whose cost must be approved by that employee’s line manager. The submission of the request and its managerial approval should be done before the request is ever seen by the service provider.

This is obviously how service requests are handled when the provider is not part of the customer’s higher level organization. It should be handled in the same way when the provider is internal to the customer’s organization. Whether the submission requires technical controls to ensure its pre-authorization or if the provider can trust the customer to avoid unauthorized submissions is a question that needs to be resolved for each organization. The more the partners trust each other to perform work as agreed, the more lean the resulting processes can be.

The second issue is whether the service provider authorizes the fulfillment of the request. If the provider is prepared to entertain requests that require a decision as to whether or not the provider will fulfill them, then such requests need to be handled by a process other than service request management. Returning to the framework described above in the context of process scope, provider authorization would be required especially if the provider is not very clear about how the request would be fulfilled, or if the fulfillment would require contravening a policy that the provider would really not want to violate.

There is an additional case where the service provider might wish to not fulfill a request that it might be happy to fulfill under different circumstances. For example, there might be a temporary situation during which the provider lacks the resources required to fulfill the request in a timely way. I would prefer to let the customer make the decision to withdraw the request, in such circumstances. Be that as it may, such cases should be exceptional. The basic process should not be determined on the basis of rare exceptions. And if the situation is not rare, then the service provider has severe capacity or organization issues that need to be resolved.

Change rejected

The fourth case concerns service requests that entail changes to components that are under change control. It imagines a case where the change would be rejected. Aside from the fact that it is a very bad strategy to makes such rejections after the customer has validated the request (according to the process), such cases should never really exist for service requests within the scope that I have defined here. We are assuming that both the customer and the service provider have a very clear, if not exact, idea of what the request is and how to fulfill it. If fulfillment does indeed involve changes to controlled components, those changes should be pre-authorized.

Take a simple example. Suppose a customer requests a second screen, which also requires the replacement of the video controller. If such services are available in the catalogue of the service provider, that is to say, the provider has already agreed, in principle, to perform the change, then it is completely inappropriate for change control to reject the change. If there are any criteria that must be fulfilled to succeed in performing the change, then these criteria should be checked at the initial qualification of the request, not late in the process as part of a separate change control activity.

Activities for which the provider is not responsible

I have already mentioned that any customer validations should be performed before the service request management process is even triggered. By doing so, much greater clarity is given to the measurement and the management of lead time for the fulfillment of the request.

One of the most issues I have seen with service requests is that the customer complains of long cycle times, but much of the delay is due to the waste of waiting for the customer itself to approve the request! This situation often leads to complex and wasteful management techniques, often implemented in the software, techniques which often only add to the overhead rather than improving performance. So, let’s let the customer be responsible for its own actions and not drag down the service provider with wasteful techniques.

Assumptions about organizational structure

The best practice framework process is strongly dependent on two assumptions about the organizational structure of the service provider:

• All service requests are received and first handled by a service desk
• Many of the requests must, at some point, by reassigned to other teams via a functional escalation.

As we have already seen in my discussion of lean incident management, it is inherently wasteful to build reassignment of work into a process. Most of us have often experienced the frustration of dealing with an organization that constantly reassigns our calls to someone else, often leading to long wait times, lost calls, cyclic handling and ineffective resolution.

From a lean perspective, all such activities are non-valuing adding. Therefore, we should endeavor to get the resolving team involved in handling the service request as early as possible in the process. Forcing an initial contact with a service desk, only to have the case reassigned, is forcing waste into the process.

I assume that the Pareto principle applies to service requests—that is, 80% of the requests reflect only 20% of the types of requests. For example, I suppose that the vast majority of service requests are limited to such types as setting up a workplace, gaining access to an application, removing access from an application and managing printer supplies. It would be easy enough to focus on the top types of request and take measures to ensure that they are always handled directly by the fulfillment team. This is especially easy to do if built into a self-service front end for customer service requests. That being said, I recognize that such tools are not perfect. They are often configured in labyrinthine ways that lose the customer or make it difficult to find the right type of support request. So there is inevitably an “other” category that requires some manual qualification to identify the right team to handle it.

There are two arguments, however, that have been used to support the use of a service desk as a first line of support. First, having a single point of contact for users obviates the need to know about the internal structure of the service provider organization. Second, it place the service desk agent in a position to “own” the call and manage the request throughout its lifetime.

I have discussed the first issue at some length elsewhere. Suffice it to say here that an organizational structure based on technological specialization, rather than one based on service or on customer specialization, only exacerbates the problem of finding the right group to handle a service request. If we structure our organizations to better reflect the needs of our customers, much of the issue of finding the right team disappears.

The second issue, regarding the supposed need to shepherd a service request through its lifetime, is precisely the sort of issue that lean management is designed to address. Fundamentally, the argument is that people are not performing their work adequately, so it necessary to add a level of organizational control to get everyone working correctly. The lean approach, however, tells us that we should identify the causes of poor performance and root them out, rather than adding a layer of control that only slows things down, in the long run, and costs more.

A lean service request management value stream

Given the way in which we have defined the scope of service request management, the value stream can be very simply described. Of course, there is no single lean value stream for service request management. But what I propose below is a generic approach that can be easily adapted to most contexts.

First, let’s look at the SIPOC diagram (Fig. 5):

The process flow itself is equally simple (Fig. 6):

Let’s walk through the lean service request management process.

1. A customer performs some work.
2. At some point, the customer requires a service from the service provider.
3. A request is submitted for the service. If any validations are required on the customer’s side, they are done before the submission.
4. a) The submission triggers the service request process. Note that request fulfillment may be triggered otherwise, such as according to a calendar.
   b) The customer waits for the request to be fulfilled.
5. The provider qualifies the request. Qualification may determine various actions, such as whether the request is in error, directed in error, or if the request requires resources other than the one currently handling it. In the latter case, the work is reassigned.
6. It might happen that the provider cannot or will not fulfill it, in which case the rejection is sent back to the customer.
7. Otherwise, the provider fulfills the request. To the extent that the request fulfillment requires the participation of third parties, this is handled by the provider as part of this activity. In a lean context, the fulfillment is handled through kanban, meaning that the class of service and its priority are assigned by the responsible team, as part of the fulfillment.
8. Upon completion, the provider informs the customer and sends the request output back to the customer. If the output is not a physical item (for example, the creation of an access right to an application), then the output might be sent to a system used by the customer, but not to the customer itself. In some cases, different components of the output are sent to different recipients.
9. The customer continues work, using the output of the service request.

Comments about the lean service request management process

No closure

There is no closing activity in the process. The activity ends when the customer has received the required output (or is otherwise cancelled). There is no need to spend additional administrative time in “closing” the service request, which is a non-value adding activity.

No error handling

As with any process, there are thousands of opportunities for errors: incorrect information, lost information, failures in execution, misunderstood needs, etc. There is no need to document these errors in the process. An activity is finished when its output is correctly created. If that entails rework, for any reason, so be it.

No escalations

Identification of the appropriate team to handle the service request is part of the qualification activity. If it is necessary to assign the task to another team, this is performed. However, it is not a necessary part of the process. Indeed, as discussed above, such functional escalations should be avoided, if at all possible.

No user satisfaction survey

As I already stated in my discussion of lean incident management, surveying user satisfaction is not part of the process. The process by which you get such feedback is not specific to service requests, to incidents or to any other type of interaction with a customer. See my article Three Process Architecture Principles, for the reasoning behind the removal of such survey activities from various processes.

Handling on a kanban board

Since each service request fulfillment is likely to entail a different set of steps, a team’s kanban board structure would not reflect all of those steps. Instead, a simple Ready/Doing/Done structure could be used. It is unlikely that “Qualifying” would be of sufficient duration to merit a separate column on the board. The overhead of managing that column and moving the kanban cards would likely be greater than the qualification effort, which would rarely last more than a minute.

Some teams might include a checklist on the kanban card for a service request if that checklist helps insure that all fulfillment steps are taken, and taken in the right order.

Conclusion

The satisfaction of customers and the value that they obtain, based of the service provider’s fulfillment of service requests, is largely determined by how service requests are managed. Using a lean service request management process is a key strategy for increasing that satisfaction, reducing the lead time need to fulfill requests, improving the satisfaction of service provider employees with their own work, reducing fulfillment costs and generally improving the reputation of the service provider in its market space.

The article Lean Service Request Management by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Summary

Article Name

Lean Service Request Management

Description

What would a lean service request management process look like? What is not lean in the best practice framework recommendations?

Author

Robert S. Falkowitz

Publisher Name

Concentric Circle Consulting

Publisher Logo