Simple steps towards sharing processes

During the process of making the procedures of various supporting departments uniform, one department often takes the lead. In this article I will explore whether it is better to search for a shared procedure derived from the overarching agreement between the departments: supplying services to the same customers.

From one tool to one department

Many of our customers work in one TOPdesk with several departments. Some of these customers went as far as setting up a shared service desk. They had to overcome many obstacles during this process, such as sharing certain functionalities. Drop-down list content and mandatory fields can lead to discussions, for example. It can be especially difficult to compromise when one of the departments has been working in TOPdesk for a long time.

The next step towards one department is following the same procedures: shared processes. This can also be a difficult step. While visiting several customers, I have seen the procedures of one department take precedent. Suddenly having to follow another department’s procedures may even lead to more discussion than sharing a tool. And which department’s procedures should take precedent? Is it the largest department with high process maturity, or the one with the least process maturity? I believe that forcing one existing procedure on the departments is not the best way to proceed.

Agreements as a starting point

An approach for reaching a uniform procedure that I think does work is to let go of all the different procedures, and take the agreements between departments as a starting point. The most important agreement between collaborating departments is that they supply services to the same customers. If we really start to work from this agreement and not from internal processes, then we need to ask ourselves these questions:

• Which services do we supply?
• How do we make sure that these services are reliable for our customers?
• How do we deal with the need for change and new services?
• What of our strategy and policy do we need to record?

In order to successfully supply services, it is important to answers all these questions.

Available services

A condition for supplying services is that it is known which services the organization can actually supply. A Products and Services Catalogue (PSC) can help. A PSC describes, in user-friendly terms, which services can be supplied in which situations and under which conditions. The first thing to do is to define and describe the services already supplied.  This contrary to what I usually see our customers do, namely start with supporting processes like call and asset management.

Supporting available services

With this new approach, all customer and employee questions relating to services described in the PSC are no longer divided and processed in different procedures. There is one process, and therefore one process manager responsible for keeping everything up and running. All these calls have one thing in common: a certain action needs to be taken to help the customer. The process manager is responsible for prioritizing, scheduling and executing these actions.

Adjusting the services

Questions that don’t refer to the services in the PSC are processed in a second procedure.  This procedure ensures that all requests for new or adjusted services are either rejected, or approved and assigned to someone. All adjustments to the PSC are thus the responsibility of a single process manager.

Larger role for policy

Certain matters that are often described as a process are never actually treated as a process in practice. It is often more convenient to include them in your policy instead. Take configuration management: when an operator is processing a call and performs an action that leads to an adjustment in an object’s registration (like replacing a broken monitor), this registration can easily be done within an administrative step of the call process. Why should this registration fall under another process, and therefore a different process manager? Another important aspect of configuration management is checking the registration is best done as a periodical project based on policy.

The future

The bottom line of this new outlook is putting your available services first and organizing your management based on this.  This contrary to what I see in practice: taking existing internal management processes as a starting point. After this first attempt we can take a closer look at the questions posed earlier in this article: What do these management processes look like exactly, and what should your policy cover?

More Shared Service Inspiration? Read about the scare-free benefits of SSM. Or – if you want some more hard data – we have a report from the Service Desk Institute on the benefits of Sharing Services.