Oftentimes, when companies are implementing Global Shared Services organizations, they jump straight to new systems as the answer. However, our belief is in order to get the most out of a Global Shared Services organization, it’s important to determine the right combination of organization structure, work processes and systems to maximize the benefits. Making a decision on systems first, and then fitting everything else around that oftentimes creates a suboptimal solution.

Background

One of the first things a lot of companies do when implementing a Global Shared Services (GSS) organization is start determining what ERP system will be the foundation that they will build on. Granted, the ERP system decision is an important one. However, we believe it’s important, and necessary, to look at the systems, organization structure, and work processes together to ensure they all fit appropriately. If they don’t, then it will be very difficult to deliver all of the cost, quality, speed and stewardship benefits associated with a Shared Services structure.

Bringing the Pieces All Together

We view the systems, organization structure, and work processes as a 3 legged stool. If one of the legs doesn’t match the other two, then the whole structure is wobbly. Or at a minimum, it isn’t as comfortable as you imagined when you originally decided to build it. So when creating a GSS organization, it’s important to take all 3 components into consideration in the design phase, because a decision in one area can impact the others, and you need to be cognizant of that.

The Organization Structure

The choices involved in a GSS organization structure and the accompanying service centers are as follows:

1. Standalone vs. folded into Corporate or one of the BU’s – the GSS organization can either be its own standalone organization reporting to the CEO, or it can be folded into one of the other organizations in the company. We believe it’s best for GSS to be a standalone organization (as discussed in the paper “The 5 Building Blocks to Creating a Successful Global Shared Services Organization). However, if the GSS organization is going to be small, then it probably doesn’t make sense to be standalone, and instead it should either report up through Corporate or if there is one function that makes up the large majority of the Shared Services, then the global head of that function
2. Multifunctional vs. single function – will the GSS organization contain multiple functions or will it be dedicated to just one function. If the Share Services group is starting out with just one function, but there is a strong possibility that it will expand to include other functions, then the design should plan for it being multifunctional.
3. Global vs. local/regional – the next question is will the Shared Services organization support all of the BU’s around the globe, or just one country or region. If the intent is to eventually go global, then the organization should be designed with that end point in mind (which means the work processes and systems should be standard globally as well, with modifications only to meet local tax or legal requirements).
4. Onshore vs. offshore – will the service centers be located in the same country as the BU’s, or will they be located offshore in a low cost location. If they are going to be located offshore, then one needs to ensure that the service center has the right language skills and is available during the business hours for all of the BU locations it is supporting.
5. Captive vs. outsourced – which services will still be run by employees of the company and which will be outsourced to a vendor? And if there is outsourcing, what systems will the vendor be using and how do those fit with your policies and work processes?

Of note: we would recommend that the answers to #1, #2, #3 and #4 be one or the other. For example, all of the services should either be in a standalone organization together or report to Corporate together as one group. And all of the services are either going to be rolled out globally or kept locally/regionally. The answer to #5, though, can be include both options, ie. some services can be outsourced and others remain captive.

Work Processes and Solutions

There are four different categories of work processes or systems that need to be addressed in the design phase. They are:

A. Customer facing work processes and systems

B. Back office or transactional work processes and systems

C. Dashboards and reporting tools

D. User communications and tools

 

A. Customer Facing Work Processes and Systems – These are the work processes or systems that are used directly by the BU’s (hence the term customer facing). For example, a request by an  end user in the BU to process a cross charge or submit an expense report. These systems need to be easy to use to free the BU’s up to focus on running the business. However, the work processes need to collect enough data in the right format so the back office can properly handle the request efficiently and effectively.

B. Back Office or Transactional Work Processes and Systems – Once the appropriate inputs have been collected by the customer facing work process or system, then the data is passed on to the Back Office to process the transaction. There will also be some back office processes and systems that don’t require any input from the BU’s to occur. For example, some of the monthly close processes within the accounting back office are passed along with no input from the BU’s. Similarly, some IT system work processes occur regularly in the back office, i.e. monitoring if certain jobs have run correctly, and if they haven’t, troubleshooting and fixing them.

C. Dashboards and Reporting Tools – Processes should be established for automating scorecards and creating standard reports as much as possible. The 80 for the 20 theory should be applied here, where a small number of basic reports should meet 80% of the user needs. However, there will still need to be interactive orad-hoc reporting tools for the other 20% of the user requests. Because most of the users will be from the BU’s, the user interface should again be as easy as possible to use. Oftentimes, there is a trade-off between reporting capability (ie. the ability to slice and dice the data a number of different ways) and ease of use. The service owner will need to take that into account when deciding on a final solution.

D. User Communication and Tools – There should be a standard process for communicating different types of information out to the user community and also for accessing certain tools. Creating a standard template for communicating this information will make it easier for the user to quickly determine if the message is relevant to them or not, and if it is relevant, what they need to do with the information. Similarly, having a consistent, easy to understand user interface will make it easier for the end user to navigate through any GSS systems, ie. like the consistent user interface for all of the tools within Microsoft Office.

Finally, good documentation is critical in a Shared Services structure. As these work processes are being created, it is also important to create th necessary documentation so users of the system (both End Users and people in the Service Centers) can easily understand and follow them. And it’s important to include in the documentation who is responsible for what in each step of the process (both input and output), as well as a basic understanding of the business process, the policy that is behind the work process, and the SLA’s associated with the work process. This is the unheralded grunt work that nobody wants to do, but having this kind of documentation is critical for training and sustaining a GSS organization.

 

Summary

When implementing a new Global Shared Services (GSS) organization, it is important during the design phase to take into account not only the systems, but the work processes and the organization structure, so they all fit together appropriately. Too many times, people make a decision on the system, and then have to force fit the organization structure and work processes around that, sub-optimizing the potential benefits associated with moving to a GSS structure.

There are many questions that have to be answered when designing a GSS organization structure. The answers to some of these could impact the systems and work processes. Similarly, decision about systems can impact work processes, and vice versa. Bottom line, when the GSS design team is working through what the end state is going to look like, they need to take into account the interactions between these 3 different variables, and decide on the optimum combination.

To assist with this process, it often also helps to identify any hard boundaries that have already been established, ie. systems decisions that have already been made, or commitments that have been communicated about the organization structure. Those can then be taken into account and worked around as necessary, to come up with the solution that delivers the best overall cost, quality, speed and stewardship.