During the process of making the procedures of various supporting departments uniform, one department often takes the lead. Here, we explore establishing a shared procedure derived from the overarching agreement between the departments while supplying services to an organization’s same customers.

No matter the organization size, many take to setting up a shared service desk in an effort to streamline some of the obvious operational issues related to managing cumbersome process and the “spaghetti” of multiple systems and workflow service management solutions. By taking a synergized approach, organizations experience the opportunity to overcome many obstacles, like sharing functionalities in their project management solutions. However, moving to a shared service management system can be especially difficult for organizational departments as many may be forced to compromise on a number of issues if they are joining another department, which has been working with a system for a long time and already has its own processes in place.

Making a step toward a one-department model that organizations implement to streamline their operations may be as simple as beginning with shared processes. However, this can also be a difficult first step. When speaking with clients, I have seen that the procedures of one department can take precedent over another. Problems arise when, suddenly, teams are required to follow another department’s procedures, which may lead to more obstacles than actions for sharing a tool. For example, which department’s procedures should take precedent, and is it the largest department with high process maturity or the one with the least process maturity? Of course, forcing one existing procedure on multiple organizational departments is not always the best way to proceed.

Agreement as a process starting point

An approach for reaching a uniform internal procedure that works well is to start by letting go of all the different internal procedures and take the existing agreements between departments as a starting point. However, 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 current internal processes then we need to ask ourselves the following questions:

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

To successfully supply services to the organization, it is important to answers all these questions to achieve the greatest level of efficiency and success.

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 organizational services can be supplied to which situations and under which conditions. To start, the first thing to do is to define and describe services already supplied. This is contrary to what we usually see our customers do, namely in that they usually 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 is 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 rejected or approved then assigned to someone. All adjustments to the PSC are 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 available services first and organizing management based on this. This is 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?