Postcards From the Edge of GBS: Building GBS Solutions

Do your business unit colleagues ask your GBS organization for help with their problems? What happens when they need something out of the ordinary? Is your team equipped to confidently build new capabilities that work, seamlessly, as one unit? Is there a group of talented people willing to step up and take the lead on such difficult to do challenges?

This post kicks off a second series of "Postcards From the Edge of GBS". I will talk about edgy practices for bringing together the capabilities of GBS to build solutions for your business unit and functional colleagues.  This will take us over the edge of the typical scope of GBS, and into the business processes of the front office. As before, I’ll draw out lessons learned and techniques, and it would be great to hear your ideas and feedback in return.

There are three reasons why I chose this practice to focus on next.  

1. GBS organizations should be good at this. If we are as operationally excellent as we say we are, our GBS teams should be able to take the lead on converting ideas into well run operational solutions, whatever part of the business uses it.
2. GBS leaders want to be good at this. Many of us aspire to work beyond our initial scope and do other things. Building solutions helps GBS teams become ‘transformation partners’ to the organization.
3. It is hard to do well. We’ll come back to this point in a moment.

A solution is an answer to a business opportunity or problem

Where a business wants to do something, a GBS organization can often create a solution. We have many of the tools needed (such as process experts, procurement, service centers, operational controls, and technology), but we must assemble them correctly and help our colleagues through their design, implementation, and use.  

Solutions might be relatively simple, for example, the implementation of a service by an existing team, such as a new type of country brand reporting, delivered by an existing analytics team with existing technology. It would take work to properly specify and train the team, but it is not a major effort.   Solution thinking might also be relevant in established GBS scope areas. For example, when looking at how to structure travel and expenses, onboarding, contingent labor, customer services, or even payroll or accounts payable, the discipline of a solutions development approach can help achieve well designed operational services.  

Solutions can also be complex, especially where they extend into new areas, and require multiple GBS and other teams to work together. Care is needed to ensure the work is well led and held together to achieve the desired business value. An example of a complex, multi-team solution, would be data management. This is a service already provided by many GBS organizations, at least for people, supply chain, and financial data sets. What would happen if the enterprise wanted GBS to extend data management best practices into customer, product, and R&D data? How would a GBS respond to that?  What could a solution look like?

In many cases, I suspect IT would take the lead for GBS. This would result in some good technology, developed under business unit leadership. But is that GBS putting all its cards on the table and its best foot forward? A full solution might require multiple elements delivered by several teams, for example:

 This complex solution would take months to define and probably years to implement. Most, but not all, could be delivered in a low-cost way by a well-organized, center-based GBS team. My questions to you are: who in your organization would have the accountability for designing and building something like this, so that it fits your business and works as intended? What method would they use? Are there any human reactions within your teams that would help or get in the way of the process?  

My argument for this series of postcards is that a GBS organization should know how to do this, it should have people that are ready to lead it, and, because the GBS organization should be comfortable in its ways of working, it should already know broadly how to do it.   

Solutions can be created across your company’s value chain

My day job for the past 11 years was leading the team that took demand from business unit leaders and converted it into working operational solutions.  I have heard colleagues refer to this as ‘value-chain services’ or ‘capabilities as a service’.  The result of our work was 100s of fully designed and costed services that combine process, procurement, technology, and people elements. 

Over those years we worked across the full life sciences value chain, building operational solutions for activities that were decidedly not the norm for back-office GBS organizations.  Below are some generic examples of life sciences ‘capabilities as a service’.  How could these look for your industry and your company? 

I am not advocating that a GBS organization should take on all these areas at once, nor is this list comprehensive, that would require detailed work within an organization, but each of these areas could benefit from the structure and discipline that a well-managed GBS would bring. In my experience it is possible to build GBS-led solutions for almost all business processes. The key question is which are the right ones to focus on. I’ll discuss the identification of those that are likely to succeed in later posts. There are two points that show the importance of process design to solutions work, which I will also explore in more detail in subsequent posts.  

• Firstly, all solution development work should be done within the context of defined enterprise processes. The GBS scope should fit within them. In areas covered by good practice guidelines and regulations (referred to as GxP in the pharma industry), this will typically not be a problem.  In areas not covered by GxP, such as sales and marketing, processes may not be clear and there may be no obvious owners. In such cases the solution design team may need to do more work to set the proper process context.
• Secondly, the role of the GBS team should be to support colleagues in the business units and functions, not to try to run the business for them. The internal owners, non-GBS colleagues, must continue to be accountable and run ‘their’ processes. This truly is ‘the edge’ of GBS, and if you step over it you may fall.  So be careful and modest with the scope. More on this later.

So why is this hard, and isn’t it just a project?

There are three key challenges to overcome to make such solutions work well: 

The need can be ambiguous. Business leaders often know broadly what they want to do, but do not know exactly how to do it, or what support they can get from GBS. The GBS team should be the experts taking their colleagues through the process in a structured way, showing them the art of the possible. This is best achieved with a standard approach (method) that is understood and practiced by all. For example, if designing meetings support services, you might start with a general intent to enable a medical function to have virtual and hybrid meetings with health care practitioners. You will need a structured process to clarify the types of events needed, and detail of the level of support required, before moving on to create a design.  

GBS organizations work in silos. Even agile organizations find new business solutions disruptive. The design effort needs a leader who can drive and decide, collaborating across teams, bringing colleagues with them. Established processes may need challenging, and human questions (e.g., ways of working, resistance to change, and even egos) need to be worked through at the fast pace required to succeed. A great way to get into this would be an end-to-end process design, clarifying scope, setting out which teams would be involved at each step, and agreeing on handoffs, controls, and governance. 

The solution must work in practice. I am sure you have experienced solutions that sounded good in principle but failed to hit the mark on the ground – I know that I have! To achieve ‘in practice’ performance, you need to understand the intent, do the work with agility, embed it in the organization, and measure the outcome. 

I will base subsequent posts in this series on at least five pieces of advice to get this done. These apply whether you are working in a large mature GBS organization, or a smaller one, looking to grow new capabilities:

I Have a specialist design team, with the delivery team signing off 
II Have a method, used by all 
III Prioritize and choose where to play 
IV Move with agility and pace 
V Follow-through and revisit

Please stay tuned for the next postcard.   
Tim Palmer, Basel, August 2023