A key purpose of an organization design is to improve efficiency, and there are two commonly used constructs that can help achieve that goal. The first is setting up a center of expertise (CoE) to manage a specific complex business task. The center is comprised of a team with specialized expertise in a specific area whose members work together to develop best practices in their area of responsibility, which is often something technical or specialized. Rather than having everyone in an organization serve as an expert in a technical skill, the organization looks to set up a CoE with a few people who are trained in those unique, specialized skills and processes. When that specialized capability is needed, it can be leveraged by the CoE team rather than expecting everyone in the organization to know how to properly perform the specialized tasks and processes.
Shared services is a similar organizational construct that allows resources to be leveraged across an organization like a CoE; however, the focus is on performing a high-volume of activities or transactions in a scaled delivery model. This approach typically lowers costs, with service levels that are agreed upon by the users and the shared service team. The shared service model is usually set up to offload high-volume, transactional work to free up others in the organization to focus on their primary purpose rather than trying to work through activities that have to be done but are not always strategic or pertinent to a team or person’s core set of responsibilities. A common example is having a sales operations team handle order and shipping paperwork, so the salespeople can devote their time to making more sales. It’s essentially moving work off the plate of certain employees—in this case, sales—and handing it to others (the sales operations team).
When defining the terms center of expertise and shared-service work, it can sound as if these constructs are obvious, logical, dedicated, or clearly defined standards that are applied like a recipe. But in real-world practice they are not because how they are implemented and defined depends on the organizational context.
Sometimes I’ll have a client say: Well, what exactly do we mean by a CoE? or That is shared service work, right? In theory we should all be on the same page about what these two organizational constructs are and how they are applied, but in reality we’re not always 100 percent clear on what these constructs mean. To determine the right use of a CoE or the right use of a shared-service organization, we need to analyze the work to be done, breaking it down from a broad construct into its component parts.
While the idea of setting up a shared service to take all the paperwork off a salesperson’s plate sounds logical and desirable, some people might find certain aspects of the paperwork beneficial to the core selling process. You can’t use a cookie cutter approach to designing and setting up CoEs and shared services because there’s no template. If you just view it at the construct level, you run the risk of missing important nuances. What I’d like to advocate, whether it’s a shared service or a CoE, is to analyze its component parts. Once you figure out the optimal way to deliver the work to be done, then the CoE or shared service constructs can be defined and designed. In the hundreds of organizations I’ve worked with, the definition—and more importantly, the application—of CoE and shared service is never the same; it’s unique to each organization.
The devil is in the details. I was once in a work session with a client when leaders decided the company would move to a CoE model. Everybody in attendance—and it was a large group—agreed. A short time later we had to stop the session and take about 20 minutes to clarify what it seemed we had all aligned on earlier; we had to define what we meant by a CoE. While nobody could argue with the concept, the details of what that meant was open to a lot of interpretation. In short, to do good organization design work, you have to be willing to break the work down to its component parts, analyze it, and make decisions about it rather than talking in broad conceptual notions.
Sometimes lingo can cause confusion. For example, organizations often design around functions—the IT function, the sales function, etc. But if you think about it, function is just another way to say CoE—a specialized group of resources that focus on more highly specialized work. It’s up to the leader and design teams to make sure everyone is not only speaking the same language, but the same dialect, or else you will spend a lot of time debating an assumed self-evident organizational set of terms that really aren’t all that self-evident.